On 03/09/2011 01:21 AM, Jens Mueller wrote:
> %u wrote:
>>> I just submitted an application for GSoC 2011 on behalf of Digital
>> Mars. Please review and contribute to the project ideas page:
>>> http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas
>>> Thanks,
>>> Andrei
>>
>> Uh... how helping fix compiler bugs? Could we help with that? I feel
>> that's *much* more important than benchmarking, for instance, since it
>> doesn't make sense to benchmark something if it has bugs. :\
>
> I have the same feeling. I'd like to see such projects. But I believe
> students are more likely to pick feature-oriented projects. The stuff
> that sounds cool. Compare: I implemented a Garbage Collector for D that
> improved performance dramatically vs. I fixed bugs in the compiler.
> I do not think that fixing bugs is less demanding. Actually I do believe
> it's more difficult and it is fun. You know the feeling, when you
> finally understand what's the cause of the problem and when you know how
> to fix it properly.
> Do you have an idea for packaging fixing bugs in a way that makes it
> look more interesting?

The real issue, I guess, is that fixing bugs (efficiently) require getting an intimate knowledge of the app.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

On 03/09/2011 01:52 AM, Andrei Alexandrescu wrote:
> On 3/8/11 4:11 PM, %u wrote:
>>>> Uh... how helping fix compiler bugs? Could we help with that? I
>> feel that's *much* more important than benchmarking, for instance,
>> since it doesn't make sense to benchmark something if it has bugs.
>> :\
>>> The funny thing is that sometimes it makes perfect sense, as
>> benchmarks _do_ push the limits of, for instance, GC and may reveal
>> a latent bug ;)
>>
>> Those are a very specific class of bugs -- bigger bugs like compiler
>> errors with handling templates are completely unrelated to
>> benchmarking, and they can be a deal breaker for many people.
>>
>> I don't think anyone cares about *speed* as much as *correctness*...
>> would you rather have your 50% accurate program be twice as fast, or
>> have your 100% accurate program be half as fast?
>
> In machine learning it's very common to trade off accuracy for speed.

Accuracy is not correctness. A result can be inaccurate and correct inside a tolerance field, which is precisely one common path for machine learning. If the program were incorrect, the machine would not learn (what one expects it to learn).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

spir wrote:
> On 03/09/2011 01:21 AM, Jens Mueller wrote:
> >%u wrote:
> >>>I just submitted an application for GSoC 2011 on behalf of Digital
> >>Mars. Please review and contribute to the project ideas page:
> >>>http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas
> >>>Thanks,
> >>>Andrei
> >>
> >>Uh... how helping fix compiler bugs? Could we help with that? I feel that's *much* more important than benchmarking, for instance, since it doesn't make sense to benchmark something if it has bugs. :\
> >
> >I have the same feeling. I'd like to see such projects. But I believe
> >students are more likely to pick feature-oriented projects. The stuff
> >that sounds cool. Compare: I implemented a Garbage Collector for D that
> >improved performance dramatically vs. I fixed bugs in the compiler.
> >I do not think that fixing bugs is less demanding. Actually I do believe
> >it's more difficult and it is fun. You know the feeling, when you
> >finally understand what's the cause of the problem and when you know how
> >to fix it properly.
> >Do you have an idea for packaging fixing bugs in a way that makes it
> >look more interesting?
> 
> The real issue, I guess, is that fixing bugs (efficiently) require getting an intimate knowledge of the app.

That is true. But I believe there are students who are amazingly good at this. Further there is always the mentor who can give advice and of course the community. If %u really likes fixing bugs and has enough time over summer he/she should submit it as a project. To attract more students for this kind of work one needs a good project description. That is what I find difficult.

Jens

On 03/09/2011 10:57 AM, spir wrote:
> On 03/09/2011 01:52 AM, Andrei Alexandrescu wrote:
>> On 3/8/11 4:11 PM, %u wrote:
>>>>> Uh... how helping fix compiler bugs? Could we help with that? I
>>> feel that's *much* more important than benchmarking, for instance,
>>> since it doesn't make sense to benchmark something if it has bugs.
>>> :\
>>>> The funny thing is that sometimes it makes perfect sense, as
>>> benchmarks _do_ push the limits of, for instance, GC and may reveal
>>> a latent bug ;)
>>>
>>> Those are a very specific class of bugs -- bigger bugs like compiler
>>> errors with handling templates are completely unrelated to
>>> benchmarking, and they can be a deal breaker for many people.
>>>
>>> I don't think anyone cares about *speed* as much as *correctness*...
>>> would you rather have your 50% accurate program be twice as fast, or
>>> have your 100% accurate program be half as fast?
>>
>> In machine learning it's very common to trade off accuracy for speed.
>
> Accuracy is not correctness. A result can be inaccurate and correct inside a
> tolerance field, which is precisely one common path for machine learning. If
> the program were incorrect, the machine would not learn (what one expects it to
> learn).

Sorry, I was unclear. I meant inaccuracy and incorrectness can often two different notions, depending on the topic. Just like simplicity and difficulty. While people often mistake one for the other.

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

> How about a GUI library. Probably helping with an already existing one, DWT for example.

Good idea, but rather improve GtkD or QtD.

On 2011-03-09 11:11, Trass3r wrote:
>> How about a GUI library. Probably helping with an already existing one,
>> DWT for example.
>
> Good idea, but rather improve GtkD or QtD.

Too bad that's the general opinion people seem to have about GUI libraries. I don't understand what they don't like about DWT.

BTW, I received a patch for DWT which makes it work with D2.

-- 
/Jacob Carlborg

On 03/09/2011 11:46 AM, Jacob Carlborg wrote:
> On 2011-03-09 11:11, Trass3r wrote:
>>> How about a GUI library. Probably helping with an already existing one,
>>> DWT for example.
>>
>> Good idea, but rather improve GtkD or QtD.
>
> Too bad that's the general opinion people seem to have about GUI libraries. I
> don't understand what they don't like about DWT.

I think the advantage of gtk or Qt is people can reinvest previous knowledge of the framework. (I mean, they are cross-language in addition to be cross-platform ;-) I would personly prefere a clearly designed D-specific GUI system than gtk's huge mess. (Dunno about Qt, people seem to find it far better designed, but recent events...)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com

> I think the advantage of gtk or Qt is people can reinvest previous
knowledge of the framework. (I mean, they are cross-language in addition to be cross-platform ;-) I would personly prefere a clearly designed D-specific GUI system than gtk's huge mess. (Dunno about Qt, people seem to find it far better designed, but recent events...)
> Denis

There's something I absolutely ***HATE*** about Gtk, and it's the fact that the controls aren't real controls: The buttons don't fade the way they're supposed to in Windows 7, because they aren't even buttons in the first place. (They're just rectangles drawn to _look_ like buttons, but they fail at imitating them.)

Maybe I'm OCD, but I just can't stand developing with Gtk. :(

Am 09.03.2011 09:39, schrieb Jacob Carlborg:
> On 2011-03-09 00:14, Daniel Gibson wrote:
>> Am 08.03.2011 20:37, schrieb Andrei Alexandrescu:
>>> I just submitted an application for GSoC 2011 on behalf of Digital Mars.
>>> Please review and contribute to the project ideas page:
>>>
>>> http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas
>>>
>>>
>>> Thanks,
>>>
>>> Andrei
>>
>> Two (ok, maybe three) IDE related ideas:
>>
>> 1. integration of the profiler (use profilers output to directly jump to
>> related sections in the code, mark time-intensive sections, stuff like
>> that)
>>
>> 2. possibility to show assembly code from (de-)compiled executable
>> inline in source so it's easier for developers who don't know much
>> assembly language to understand how much machine code is generated by
>> their code, possibly creating bottlenecks from harmless-looking
>> statements etc.
>>
>> 3. Any work on IDEs should be for cross-platform IDEs, maybe eclipse DDT
>> or codeblocks. Or maybe somebody could port D-IDE (d-ide.sf.net), which
>> is pretty good as far as I know, to mono so it can be used on other
>> platforms than windows?
>
> Wouldn't it be better to use a platform independent GUI library.

When starting from scratch - certainly.
But if D-IDE should be improved/ported - which currently uses .Net - mono is probably the best choice (better than rewriting it completely).
Or do you think it should be ported to Qyoto (Qt for C#) or GTK# or something like that for a more native look and feel?

And if some other IDE should be improved (probably it should be discussed what specific IDE this should be anyway) then *please* improve a cross-platform IDE like eclipse DDT or codeblocks (and not, e.g. Visual D or Posedion, because those are only available on Windows anyway).

Something else to consider: For improvements-of-existing-IDEs the current IDE developers should probably be involved as mentors.

Cheers,
- Daniel

Am 09.03.2011 11:55, schrieb spir:
> On 03/09/2011 11:46 AM, Jacob Carlborg wrote:
>> On 2011-03-09 11:11, Trass3r wrote:
>>>> How about a GUI library. Probably helping with an already existing one,
>>>> DWT for example.
>>>
>>> Good idea, but rather improve GtkD or QtD.
>>
>> Too bad that's the general opinion people seem to have about GUI
>> libraries. I
>> don't understand what they don't like about DWT.
>
> I think the advantage of gtk or Qt is people can reinvest previous
> knowledge of the framework. (I mean, they are cross-language in addition
> to be cross-platform ;-) I would personly prefere a clearly designed
> D-specific GUI system than gtk's huge mess. (Dunno about Qt, people seem
> to find it far better designed, but recent events...)
>
> Denis

AFAIK DDT is modeled after (Java) SWT (used in eclipse).

I'd love to see DWT improved, so it really works on all/most platforms that are supported by SWT, especially Linux i386/amd64 and OSX.
(I haven't looked at DWT's homepage for some time and it currently seems to be down due to dsource issues).

Cheers,
- Daniel