March 09, 2011
> In machine learning it's very common to trade off accuracy for
speed.
> Andrei

Er... do you _honestly_ think people will start writing machine learning programs in D, when we're even having trouble getting them to use D for more typical applications (because of bugs)?

Also, I (obviously) used the word "accuracy" to mean "predictability", not "approximation". If you can't predict whether your program is multiplying the result by zero or by one (because of a lambda template bug in the compiler), that's quite different from having inaccurate floating-point implementations that change the number 1.000 to 0.998. People using D for machine learning might tolerate the latter, but I doubt they can tolerate the former...
March 09, 2011
>> 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.

Wait, I think I'm confused -- which ones are "feature-oriented projects" and which ones aren't?

I'm only a single voice, but for my student perspective, I frankly wouldn't waste my time joining a benchmarking project; however, I would definitely consider helping get the compiler bugs fixed. After all, if it's open-source, then students should be able to help contribute, right? What's the point of restricting the compiler work to beyond their reach, especially if that's what needs some of the most help in and especially if they might be more interested in it?
March 09, 2011
On Tuesday 08 March 2011 20:34:00 %u 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.
> 
> Wait, I think I'm confused -- which ones are "feature-oriented projects" and which ones aren't?
> 
> I'm only a single voice, but for my student perspective, I frankly wouldn't waste my time joining a benchmarking project; however, I would definitely consider helping get the compiler bugs fixed. After all, if it's open-source, then students should be able to help contribute, right? What's the point of restricting the compiler work to beyond their reach, especially if that's what needs some of the most help in and especially if they might be more interested in it?

The compiler is just one component. druntime and Phobos are part of it as well. A good example of a feature-oriented project for druntime would be working on the GC. For Phobos, stuff like a logging module or an xml module would be good examples of feature-oriented projects. They're tasks to implement or significantly improve a specific feature, not work on general bugs.

- Jonathan M Davis
March 09, 2011
On 3/8/2011 8:34 PM, %u 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.
> 
> Wait, I think I'm confused -- which ones are "feature-oriented projects" and which ones aren't?
> 
> I'm only a single voice, but for my student perspective, I frankly wouldn't waste my time joining a benchmarking project; however, I would definitely consider helping get the compiler bugs fixed. After all, if it's open-source, then students should be able to help contribute, right? What's the point of restricting the compiler work to beyond their reach, especially if that's what needs some of the most help in and especially if they might be more interested in it?

Out of curiosity, what's stopping you from helping fix bugs right now?  I agree that being paid for it adds motivation, but if it's something you want to do, do it.
March 09, 2011
On 3/8/11 8:30 PM, %u wrote:
>> In machine learning it's very common to trade off accuracy for
> speed.
>> Andrei
>
> Er... do you _honestly_ think people will start writing machine
> learning programs in D, when we're even having trouble getting them
> to use D for more typical applications (because of bugs)?

Yes. I've already written a ton of ML code in D. I predict actually that D will be a prime language for ML - it has quite what it takes.

> Also, I (obviously) used the word "accuracy" to mean
> "predictability", not "approximation".

Then you were being inaccurate :o).


Andrei
March 09, 2011
> Out of curiosity, what's stopping you from helping fix bugs right
now?  I agree that being paid for it adds motivation, but if it's something you want to do, do it.

Great question! :)

Right now? The fact that I'm in school and have other things to do. :(

During the summer? The fact that I might have an internship or something else to do. :\

If I have time, though, I'll definitely give it a shot! :)
March 09, 2011
>> Also, I (obviously) used the word "accuracy" to mean
"predictability", not "approximation".
> Then you were being inaccurate :o).
> Andrei

I thought the meaning was predictable. :P
March 09, 2011
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.

> (I post this here for discussion before inserting it in the wiki).
>
> Cheers,
> - Daniel


-- 
/Jacob Carlborg
March 09, 2011
Andrei Alexandrescu wrote:
> 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.

I added those.

Jens
March 09, 2011
On 2011-03-08 20: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

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

-- 
/Jacob Carlborg