I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some tomorrow; we should have quite a few before the application deadline (March 29) in order to strengthen our application.

Please chime in!


Andrei

Andrei Alexandrescu:

> I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some tomorrow; we should have quite a few before the application deadline (March 29) in order to strengthen our application.
>
> Please chime in!

LDC is based on LLVM, so this suggests several small project ideas, like porting some of the LLVM tools/features designed for C/C++ to the D-LDC world. Things like:
- Perform more static analysis, like abstract compilation or linting (Clang does both);
- Develop a simple way to compile D for the browser with Emscripten to "asm.js" (this is a very small project);
- Perform other run-time tests as done by Clang;
- Use some of the D semantics to improve D code optimization (Walter talks about this all the time);
- Implement better high level optimizations for D code that uses array ops.

Bye,
bearophile

On 3/26/2013 8:24 PM, bearophile wrote:
> Andrei Alexandrescu:
>
>> I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some tomorrow;
>> we should have quite a few before the application deadline (March 29) in order
>> to strengthen our application.
>>
>> Please chime in!
>
> LDC is based on LLVM, so this suggests several small project ideas, like porting
> some of the LLVM tools/features designed for C/C++ to the D-LDC world. Things like:
> - Perform more static analysis, like abstract compilation or linting (Clang does
> both);
> - Develop a simple way to compile D for the browser with Emscripten to "asm.js"
> (this is a very small project);
> - Perform other run-time tests as done by Clang;
> - Use some of the D semantics to improve D code optimization (Walter talks about
> this all the time);
> - Implement better high level optimizations for D code that uses array ops.

Add 'em to the wiki, bearophile!

Once remaining issues with shared libraries are resolved, it becomes feasible to use D code from dynamic languages. Clearly it's vital to provide easy path for calling it from Python, as it's used by most scientists. Although there's PyD, last few years saw rising interest in PyPy because it shows much better performance than CPython.
For PyPy, the way to go seems to be generating extern(C) wrappers for classes/functions/etc. + CFFI bindings (http://cffi.readthedocs.org/) for that C code.
First part of this can be reused for producing C++ wrapping code -- this is similar in goals to dtoh (http://d.puremagic.com/issues/show_bug.cgi?id=9285) but here entities to be wrapped should be explicitly mentioned. Extra benefit of producing C++ bindings is ability to call SWIG on them to support other languages. So, perhaps, C++ is the number one target in this respect.

On 3/26/13 11:00 PM, Andrei Alexandrescu wrote:
> I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some
> tomorrow; we should have quite a few before the application deadline
> (March 29) in order to strengthen our application.
>
> Please chime in!
>
>
> Andrei

I seeded http://wiki.dlang.org/GSOC_2013_Ideas with some of the ideas posted here. Please add to them, thanks!

In order to get accepted and fetch more than the customary 1-3 slots, we need to have a strong mentors lineup (check) and a good pool of ideas ready before deadline on Friday. At this point we're brainstorming, so no idea is too crazy. Do it!!!


Andrei

On Wednesday, 27 March 2013 at 14:56:08 UTC, Andrei Alexandrescu wrote:
> On 3/26/13 11:00 PM, Andrei Alexandrescu wrote:
>> I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some
>> tomorrow; we should have quite a few before the application deadline
>> (March 29) in order to strengthen our application.
>>
>> Please chime in!
>>
>>
>> Andrei
>
> I seeded http://wiki.dlang.org/GSOC_2013_Ideas with some of the ideas posted here. Please add to them, thanks!
>
> In order to get accepted and fetch more than the customary 1-3 slots, we need to have a strong mentors lineup (check) and a good pool of ideas ready before deadline on Friday. At this point we're brainstorming, so no idea is too crazy. Do it!!!
>

Proposed some idea around SDC. I'm also available to mentor anything around druntime or phobos (I'm way less confident with dmd).

On 03/27/2013 04:00 AM, Andrei Alexandrescu wrote:
> I just started http://wiki.dlang.org/GSOC_2013_Ideas. I'll add some tomorrow; we should have quite a few before the application deadline (March 29) in order to strengthen our application.
> 
> Please chime in!

A few for people to comment on before anything gets added to the page:

   -- QtD and GtkD.  I'm not 100% up to date on the status of these (I write
      numerical simulations, not applications...) but these should surely be
      brought up to date with the latest versions of Qt and GTK+.  Having a
      well-working QtD seems to me important given the recent announcements
      by Ubuntu favouring Qt (I'm thinking, Qt + Ubuntu Touch + D compiling on
      ARM offers some nice opportunities...).

   -- I'd second the call for really good integration with Python and for
      ARM support.

   -- Making the frontend, runtime and Phobos fully backend-agnostic so that
      new versions can be merged into other compilers (GDC, LDC, ...) with a
      minimal amount of work.

   -- A complete set of containers (emphasis on Set:-) for std.containers, and
      also address the performance issues that have been identified with current
      implementations.

   -- Reimplement random number generators as well designed reference types.

   -- A std.bigfloat to go alongside std.bigint.

   -- Didn't someone say std.numeric needed to be rebuilt from the ground up?

On Wednesday, 27 March 2013 at 20:19:22 UTC, Joseph Rushton Wakeling wrote:
>    -- A complete set of containers (emphasis on Set:-) for std.containers, and
>       also address the performance issues that have been identified with current
>       implementations.

I think std.container is basically waiting for custom allocators before expanding in full force, as it is predicted that a custom allocator interface integrated into Phobos will affect both new and old containers.

What is the status on allocators, anyway?

On 03/27/2013 09:41 PM, Jakob Ovrum wrote:
> I think std.container is basically waiting for custom allocators before expanding in full force, as it is predicted that a custom allocator interface integrated into Phobos will affect both new and old containers.
> 
> What is the status on allocators, anyway?

One more for GSoC, then? :-)

On Wednesday, 27 March 2013 at 20:53:48 UTC, Joseph Rushton Wakeling wrote:
> One more for GSoC, then? :-)

Indeed, though a word from the present author of the custom allocator interface (I believe dsimcha/David Simcha was working on it?) would be nice.