March 09, 2011
On 09.03.2011 2:50, %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. :\
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 ;)

-- 
Dmitry Olshansky

March 09, 2011
On 08/03/2011 23:07, Andrei Alexandrescu wrote:
> On 3/8/11 2:35 PM, Bruno Medeiros wrote:
>> On 08/03/2011 19:37, Andrei Alexandrescu 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
>>
>> Hum, is it important to flesh these out before the deadline for applying
>> to be a mentoring organization (11th of March)?
>
> The document is an evolving entity, but the better it is before the
> deadline, the more chances we have to secure admission.
>
> Andrei

Hum, I guess that counts as important then.

-- 
Bruno Medeiros - Software Engineer
March 09, 2011
>> 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?
March 09, 2011
On 03/08/2011 08:37 PM, Andrei Alexandrescu 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

Added topic "D tools in D".

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

March 09, 2011
On 3/8/11 3:11 PM, Jens Mueller wrote:
> Andrei Alexandrescu 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
>
> Great. I find all of the provided projects useful. Maybe one should add
> ZeroMQ to the bindings project. I haven't used it myself. But it seems
> useful.
> Before I change the wiki page I'd like to receive some feedback for some
> ideas. Somehow I think it's important to offer not too much. Just tell
> what's important for you and what you really miss in D.
>
> =Improved documentation=
> I think there should be a standard theme (like the one you find for
> Java; Candydoc is a good step in that direction) and unittests should be
> included in the documentation
> (http://d.puremagic.com/issues/show_bug.cgi?id=2630).
> This is not much. Maybe more can be added.
>
> =Testing Framework=
> Building a testing framework on top of the available built-in unittests
> and assertions. Includes maybe also improving the built-in assert and
> build-in unittests (named unittests). Something like GoogleTest.
>
> =Logging Library=
> It was once on the list but it didn't lead to anything. Something like
> Google-glog.
>
> =Units Library=
> It was once on the list but it didn't lead to anything. Like
> Boost.Units.
>
> =Containers=
> What about better/more containers for std.container. Which?
>
> =std.sysinfo/core.cpuid=
> There is core.cpuid. I think it has no unittests which is bad. At least
> on Linux one could try parsing /proc/cpuinfo to have some tests.
> std.sysinfo would be an extension to core.cpuid providing system
> specific information that are not covered by core.cpuid.
>
> I'm going to write better descriptions in the wiki page if a project is
> considered interesting.
>
> Jens

Of these I think logging, units, and containers would be good.

Andrei
March 09, 2011
%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?

Jens
March 09, 2011
Am 09.03.2011 00:50, schrieb %u:
>> 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 don't know if 3 months(?) are enough time to become acquainted with the compiler *and* do something useful with that knowledge.
March 09, 2011
>> 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?


100% agree. :) I'm a student myself and I'm really considering GSoC for D, but from my own perspective I'd only do it if I could fix bugs in the compiler -- *that* is what I truly enjoy doing (since I really want to help D become more popular), and _not_ timing the application's performance. Benchmarking would just be like mopping the floor for me... it's important in its own right, but I'm not sure if college students would actually enjoy doing it; I certainly wouldn't.

(Personally, I think *THE* most important factor that's hindering the adoption of D are the compiler bugs, _not_ performance. If people can't write correct code, they wouldn't even give a second thought to optimizations; I think putting workforce toward optimization is a bit premature at this moment.)
March 09, 2011
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.

Andrei
March 09, 2011
On 09/03/2011 00:21, Jens Mueller wrote:
> 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.

And I wouldn't be surprised if Google as well is also more likely to accepted feature-oriented projects than bug-fix ones.

-- 
Bruno Medeiros - Software Engineer