www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - [GSoC] Container proposals by Ishan and Christian

reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
We are honored to receive a fair amount of interest from students at our 
GSoC 2011.

One issue is that at least one student (who contacted me off-list) 
couldn't find a project to work on that would best play into his 
strengths. I think it's not too late to improve our GSoC ideas page 
(http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

Another issue is that we have competing proposals on identical or 
overlapping projects. I am trying to solve one of these matters 
privately, and I think it would be best if we could solve the others in 
the community.

I'm referring to Ishan's and Christian's proposals for containers. Both 
proposals have pros and cons, and I predict it would be very difficult 
to make a decision. Therefore, I'm trying to avoid that "by design", 
i.e. by finding a solution that would keep both busy on useful work that 
is in line with their capabilities.

First, I suggest that anyone interested gives a thorough read to the two 
proposals:

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1

Both students seem to be quite enthusiastic and capable. Two things that 
I'm worrying about are:

1. Both seem to be quite fresh on D, so they'll need close coaching at 
least in the beginning.

2. Both students seem unfamiliar with the STL, which is a difficult 
skill to acquire in a short time frame and is quite recommended for 
working on D's containers.

If the students could comment on that, that would be helpful.

Here's how I think we can solve the problem of overlapping projects:

1. One way is to convince one of the students to work on a different 
topic that would also play into his strengths and is of interest to him. 
Any suggestions are welcome, both from the students and the community.

2. Another approach would be to expand the scope of the project. There 
are plenty of interesting containers out there (see e.g. 
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-c
ol-data-structures) 
that are darn useful. I suggest students to look over those and answer 
if they'd fell comfortable about implementing e.g. a Bloom filter or a trie.

With an expanded containers project we could (assuming all goes smooth) 
benefit of a host of solid containers by fall. The thing is that would 
definitely require very intensive mentoring. I'd probably be a mentor, 
and I'd need at least one to be comfortable about putting this option on 
the table.

Any thoughts, please share.


Thanks,

Andrei
Apr 03 2011
next sibling parent reply Matthias Pleh <matthias none.net> writes:
On 2011-04-03 21:05, Andrei Alexandrescu wrote:

 I think it's not too late to improve our GSoC ideas page


So here come my ideas



There is still the lack of a good D Gui Library.
Currently some GUI's are still under development (most projects on 
dsoure are abandoned!), but none of them are really perfect D-GUI's
* GtkD -> good and stable, but a D wrapper around a C-library
* DWT  -> also good, but a port from Java and not really D-like coded
* DFL  -> windows only, a way too .Net-like, is currently not very 
active (abandoned?)
* ... all others I know are unmature and abandoned (tell me, if I'm 
wrong here!)

So there comes 2 ideas to my mind:


- Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development
   * Just basic structures/functions/classes for Window creation,
   event handling, ...
   This could be used not only by a Standard-D-Gui-library,
   but also by other Gui-libraries for D

- Design of a OS independent GUI-toolkit
   * class-diagramm, basicstuctures, ...

This could be the beginning of a Community-driven development of a good 
D-GUI-library which eventualy could find its way into phobos ... ?
Apr 03 2011
next sibling parent Matthias Pleh <matthias none.net> writes:
On 2011-04-03 23:23, Matthias Pleh wrote:

 * GtkD -> good and stable, but a D wrapper around a C-library
 * DWT  -> also good, but a port from Java and not really D-like coded
 * DFL  -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)


Ok, I've forgotten some

* QtD  -> the same as GtkD, just a wrapper
* dgui -> windows only, also really .Net-like
Maybe there are more?
Apr 03 2011
prev sibling next sibling parent reply spir <denis.spir gmail.com> writes:
On 04/03/2011 11:23 PM, Matthias Pleh wrote:

 So there comes 2 ideas to my mind:


 - Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development
    * Just basic structures/functions/classes for Window creation,
    event handling, ...
    This could be used not only by a Standard-D-Gui-library,
    but also by other Gui-libraries for D


Do you mean something analog to the database-access interface project, but for 
GUI? (Meaning a standard GUI-programming interface for D.)
If yes, I find this *very* interesting, and certainly highly useful for the 
language. However, it may be somewhat complicated (but that's the charm of it 
;-) because of differences of design in existing GUI frameworks, of the the 
bigger complexity of GUI programming on the other; and there may be no prior
work.


 - Design of a OS independent GUI-toolkit
    * class-diagramm, basicstuctures, ...


A fairly big project, I guess! (even for a toy...)

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
parent reply Matthias Pleh <matthias none.net> writes:
On 2011-04-03 23:48, spir wrote:

 (Meaning a standard GUI-programming interface for D.)


Yes, exactly! Just a really small Api to abstract the OS.
- Application -> as a representation for the process
- Window -> create, show, hide
- Canvas/Image -> to draw on
+ No buttons/textbox or other widgets, this would be part of the higher 
level
   (some GUI's on this basic API could use native controls / others may 
draw it itself / or draw it with GPU ...

I mean, there were several attempts to create a GUI, each with a 
different approach, and most of them are unfinished and abandoned.
This could be a base for all GUI's


 A fairly big project, I guess! (even for a toy...)


It haven't to be complete. Just a start, with the most important corner 
cases.


- Matthias
Apr 03 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 15:11, Matthias Pleh wrote:

 On 2011-04-03 23:48, spir wrote:

 (Meaning a standard GUI-programming interface for D.)


 
 Yes, exactly! Just a really small Api to abstract the OS.
 - Application -> as a representation for the process
 - Window -> create, show, hide
 - Canvas/Image -> to draw on
 + No buttons/textbox or other widgets, this would be part of the higher
 level
    (some GUI's on this basic API could use native controls / others may
 draw it itself / or draw it with GPU ...
 
 I mean, there were several attempts to create a GUI, each with a
 different approach, and most of them are unfinished and abandoned.
 This could be a base for all GUI's
 
  > A fairly big project, I guess! (even for a toy...)
 
 It haven't to be complete. Just a start, with the most important corner
 cases.


 I do _not_ think that generic GUI layer is a good idea. GUI toolkits all act 
very differently about a lot of things. Abstracting them is not easy and tends 
to result in you losing a lot of their power. It's better to just use the 
appropriate GUI toolkit and be done with it. Only a _very_ simple GUI 
application would ultimately be very well served by a generic GUI layer. Not 
to mention, that's just adding yet _another_ layer of abstraction on top of 
who knows how many layers of abstraction, and D is supposed to be a _systems_ 
programming language. Extra layers of abstraction generally harm efficiency, 
and in this case, they don't really help the programmer all that much in 
writing their application anyway. You just can't abstract diverse GUI toolkits 
in an efficient or particularly useful manner. Only the really simplistic 
stuff would work.

What we need is for projects such as qtd to get the proper support that they 
need to make progress and be completed.

- Jonathan M Davis
Apr 03 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 00:36, schrieb Jonathan M Davis:

 On 2011-04-03 15:11, Matthias Pleh wrote:

 On 2011-04-03 23:48, spir wrote:

 (Meaning a standard GUI-programming interface for D.)


 Yes, exactly! Just a really small Api to abstract the OS.
 - Application ->  as a representation for the process
 - Window ->  create, show, hide
 - Canvas/Image ->  to draw on
 + No buttons/textbox or other widgets, this would be part of the higher
 level
     (some GUI's on this basic API could use native controls / others may
 draw it itself / or draw it with GPU ...

 I mean, there were several attempts to create a GUI, each with a
 different approach, and most of them are unfinished and abandoned.
 This could be a base for all GUI's

   >  A fairly big project, I guess! (even for a toy...)

 It haven't to be complete. Just a start, with the most important corner
 cases.


   I do _not_ think that generic GUI layer is a good idea. GUI toolkits all act
 very differently about a lot of things. Abstracting them is not easy and tends
 to result in you losing a lot of their power. It's better to just use the
 appropriate GUI toolkit and be done with it. Only a _very_ simple GUI
 application would ultimately be very well served by a generic GUI layer. Not
 to mention, that's just adding yet _another_ layer of abstraction on top of
 who knows how many layers of abstraction, and D is supposed to be a _systems_
 programming language. Extra layers of abstraction generally harm efficiency,
 and in this case, they don't really help the programmer all that much in
 writing their application anyway. You just can't abstract diverse GUI toolkits
 in an efficient or particularly useful manner. Only the really simplistic
 stuff would work.

 What we need is for projects such as qtd to get the proper support that they
 need to make progress and be completed.

 - Jonathan M Davis


I agree.
And please: let's not do it the Java Swing way, i.e. look and feel 
crappy and out of place on any platform for the sake of being consistent 
between platforms.

Cheers,
- Daniel
Apr 03 2011
parent Matthias Pleh <jens konrad.net> writes:
Am 04.04.2011 01:09, schrieb Daniel Gibson:

 I agree.
 And please: let's not do it the Java Swing way, i.e. look and feel
 crappy and out of place on any platform for the sake of being consistent
 between platforms.



Java Swing is an extreme example. Everything is selfdrawn.
Qt makes it much better. Most widgets are selfdrawn. Only some use the 
native widgets, e.g. Filepicker, ContextMenu, ...


Matthias
Apr 04 2011
prev sibling next sibling parent spir <denis.spir gmail.com> writes:
On 04/04/2011 12:11 AM, Matthias Pleh wrote:

 On 2011-04-03 23:48, spir wrote:

 (Meaning a standard GUI-programming interface for D.)


 Yes, exactly! Just a really small Api to abstract the OS.


... and the actual GUI framework, I guess?


 - Application -> as a representation for the process
 - Window -> create, show, hide
 - Canvas/Image -> to draw on
 + No buttons/textbox or other widgets, this would be part of the higher level
 (some GUI's on this basic API could use native controls / others may draw it
 itself / or draw it with GPU ...

 I mean, there were several attempts to create a GUI, each with a different
 approach, and most of them are unfinished and abandoned.
 This could be a base for all GUI's


Hum, I think you'd need to go much further for the API to be of any use. 
Defining the notions of widget, event & callback, read-only (label) vs 
read/write (textbox), parent <--> child(ren) relation, styling & style cascade, 
many more... all of this as a coherent system.
Also, like in many other cases, simplicity of use/interface may hide much 
complication & magic in the background (think Python). But this may be a fairly 
motivating project.


  A fairly big project, I guess! (even for a toy...)


 It haven't to be complete. Just a start, with the most important corner cases.


That would be very cool. Actually, both projects could help & design each other 
(just like in the case of the standard DB API project).

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 03 2011
prev sibling parent Michel Fortin <michel.fortin michelf.com> writes:
On 2011-04-03 18:11:38 -0400, Matthias Pleh <matthias none.net> said:


 On 2011-04-03 23:48, spir wrote:

 (Meaning a standard GUI-programming interface for D.)


 
 Yes, exactly! Just a really small Api to abstract the OS.
 - Application -> as a representation for the process
 - Window -> create, show, hide
 - Canvas/Image -> to draw on
 + No buttons/textbox or other widgets, this would be part of the higher level
    (some GUI's on this basic API could use native controls / others may 
 draw it itself / or draw it with GPU ...


I wouldn't build a GUI on top of that, but having a standard way to 
open a window and draw things in it would be great for prototyping 
algorithms or to make simple data visualization programs, or just make 
it fun to learn programming.

I did something similar for C++ at the request of a professor as a 
summer project when I was at the university...

-- 
Michel Fortin
michel.fortin michelf.com
http://michelf.com/
Apr 03 2011
prev sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Matthias Pleh (matthias none.net)'s article

 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL  -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)


Not abandoned, just updated very sparsely.  The DFL API is IMHO much easier to
use
than GtkD, which is why I wrote the first version of my Plot2kill lib for it
before I ran into limitations I couldn't get around.  (These were mainly lack of
support for non-Windows OS's and lack of builtin vector graphics support a la
GTK-Cairo.)

I wonder how hard it would be to port DFL to Linux using Winelib.  Wine's gotten
pretty good lately, and the whole point of Winelib is to compile code that calls
the Windows API on Linux.  (Wine is for running Windows **binaries**, but it
has a
companion library, Winelib, for **compiling** Windows API code to native Linux
binaries.)
Apr 03 2011
parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:11, schrieb dsimcha:

 == Quote from Matthias Pleh (matthias none.net)'s article

 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL  ->  windows only, a way too .Net-like, is currently not very
 active (abandoned?)


 Not abandoned, just updated very sparsely.  The DFL API is IMHO much easier to
use
 than GtkD, which is why I wrote the first version of my Plot2kill lib for it
 before I ran into limitations I couldn't get around.  (These were mainly lack
of
 support for non-Windows OS's and lack of builtin vector graphics support a la
 GTK-Cairo.)

 I wonder how hard it would be to port DFL to Linux using Winelib.  Wine's
gotten
 pretty good lately, and the whole point of Winelib is to compile code that
calls
 the Windows API on Linux.  (Wine is for running Windows **binaries**, but it
has a
 companion library, Winelib, for **compiling** Windows API code to native Linux
 binaries.)


May be possible, but would probably look crappy - just like windows 
applications in wine look crappy (as long as you don't have a win2k like 
theme for GTK/QT so all your applications look like windows applications..).
This may be acceptable to port or emulate windows applications, but not 
for developing new cross-platform applications.

SWT looks great (==native) on Windows and Linux/GTK (probably also 
OSX?), so why not push DWT? Don't know what programming for it is like, 
though.

Cheers,
- Daniel
Apr 03 2011
next sibling parent reply dsimcha <dsimcha yahoo.com> writes:
== Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.


IDK why people are bothered so much by this.  I hate Swing only because it's so
sluggish-feeling, but GTK on Windows doesn't bother me even though it looks
non-native.  Similarly, I doubt DFL on Linux would bother me if I used Linux as
my
desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too
much
other stuff on my plate to fix this myself.
Apr 03 2011
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On 2011-04-03 16:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article
 

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.


 
 IDK why people are bothered so much by this.  I hate Swing only because
 it's so sluggish-feeling, but GTK on Windows doesn't bother me even though
 it looks non-native.  Similarly, I doubt DFL on Linux would bother me if I
 used Linux as my desktop OS.
 

 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 
 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got
 too much other stuff on my plate to fix this myself.


If swing actually had a good-looking look and feel, it probably wouldn't be 
that big a problem, but it's ugly. Still, for a lot of people, the fact that 
something doesn't look native is a major problem.

Regardless, SWT has a great solution to making the GUI look native and 
generally is extremely well-designed as I understand it (though unfortunately, 
it considers GTK to be native on Linux, and I hate the look of GTK). Pretty 
much every major Java GUI application that I'm aware of uses SWT, not swing.

It would certainly be great if DWT were brought up-to-date at some point, but 
personally, I'm far more likely to pick qtd if I do a GUI application, simply 
because I use KDE, and qtd would look native on my desktop and generally 
integrate better (and it would still be cross platform). I don't do much in 
the way of GUI applications though.

- Jonathan M Davis
Apr 03 2011
next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:46, schrieb Jonathan M Davis:

 On 2011-04-03 16:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article


 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.


 IDK why people are bothered so much by this.  I hate Swing only because
 it's so sluggish-feeling, but GTK on Windows doesn't bother me even though
 it looks non-native.  Similarly, I doubt DFL on Linux would bother me if I
 used Linux as my desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got
 too much other stuff on my plate to fix this myself.


 
 If swing actually had a good-looking look and feel, it probably wouldn't be 
 that big a problem, but it's ugly. Still, for a lot of people, the fact that 
 something doesn't look native is a major problem.
 
 Regardless, SWT has a great solution to making the GUI look native and 
 generally is extremely well-designed as I understand it (though unfortunately, 
 it considers GTK to be native on Linux, and I hate the look of GTK). 


Maybe http://code.google.com/a/eclipselabs.org/p/swtqt/ could fix that
for you? Don't know how stable and maintained that is, though.

Cheers,
- Daniel
Apr 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:58, Daniel Gibson wrote:

 Am 04.04.2011 01:46, schrieb Jonathan M Davis:

 On 2011-04-03 16:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article


 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.


 IDK why people are bothered so much by this.  I hate Swing only because
 it's so sluggish-feeling, but GTK on Windows doesn't bother me even though
 it looks non-native.  Similarly, I doubt DFL on Linux would bother me if I
 used Linux as my desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got
 too much other stuff on my plate to fix this myself.


 If swing actually had a good-looking look and feel, it probably wouldn't be
 that big a problem, but it's ugly. Still, for a lot of people, the fact that
 something doesn't look native is a major problem.

 Regardless, SWT has a great solution to making the GUI look native and
 generally is extremely well-designed as I understand it (though unfortunately,
 it considers GTK to be native on Linux, and I hate the look of GTK).


 Maybe http://code.google.com/a/eclipselabs.org/p/swtqt/ could fix that
 for you? Don't know how stable and maintained that is, though.

 Cheers,
 - Daniel


That's interesting.

-- 
/Jacob Carlborg
Apr 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:46, Jonathan M Davis wrote:

 On 2011-04-03 16:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article


 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..). This may be acceptable to port or emulate windows
 applications, but not for developing new cross-platform applications.


 IDK why people are bothered so much by this.  I hate Swing only because
 it's so sluggish-feeling, but GTK on Windows doesn't bother me even though
 it looks non-native.  Similarly, I doubt DFL on Linux would bother me if I
 used Linux as my desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got
 too much other stuff on my plate to fix this myself.


 If swing actually had a good-looking look and feel, it probably wouldn't be
 that big a problem, but it's ugly. Still, for a lot of people, the fact that
 something doesn't look native is a major problem.

 Regardless, SWT has a great solution to making the GUI look native and
 generally is extremely well-designed as I understand it (though unfortunately,
 it considers GTK to be native on Linux, and I hate the look of GTK). Pretty
 much every major Java GUI application that I'm aware of uses SWT, not swing.


I think the reason why Eclipse chose GTK and not Qt is the previous 
license issues, GPL and EPL is not compatible. Now this is no longer a 
problem and I've heard that someone is working on a Qt port of SWT, 
don't know the status. Anyone is also free to make a Qt port of DWT.


 It would certainly be great if DWT were brought up-to-date at some point, but
 personally, I'm far more likely to pick qtd if I do a GUI application, simply
 because I use KDE, and qtd would look native on my desktop and generally
 integrate better (and it would still be cross platform). I don't do much in
 the way of GUI applications though.


Have a look at my answer to dsimcha.


 - Jonathan M Davis



-- 
/Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 01:38, schrieb dsimcha:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.


 
 IDK why people are bothered so much by this.  I hate Swing only because it's so
 sluggish-feeling, but GTK on Windows doesn't bother me even though it looks
 non-native.  Similarly, I doubt DFL on Linux would bother me if I used Linux
as my
 desktop OS.
 

 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 
 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too
much
 other stuff on my plate to fix this myself.


I think Jacob Carlborg mentioned that he was working on that recently.
Also there was a commit to dwt2's hg 2 weeks ago by somebody else
("kntroh") "Update to compile and execute with dmd 2.052." so it /may/ work.

BTW: Besides looking crappy (which could probably be fixed with
theme-support) my main issue with non-native GUIs is that they don't
have standard filepickers.
The GTK filepicker allows to save bookmarks to directorys and not having
those annoys me. Furthermore those filepickers often just suck
usability-wise.

Cheers,
- Daniel
Apr 03 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:50, Daniel Gibson wrote:

 Am 04.04.2011 01:38, schrieb dsimcha:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.


 IDK why people are bothered so much by this.  I hate Swing only because it's so
 sluggish-feeling, but GTK on Windows doesn't bother me even though it looks
 non-native.  Similarly, I doubt DFL on Linux would bother me if I used Linux
as my
 desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too
much
 other stuff on my plate to fix this myself.


 I think Jacob Carlborg mentioned that he was working on that recently.
 Also there was a commit to dwt2's hg 2 weeks ago by somebody else
 ("kntroh") "Update to compile and execute with dmd 2.052." so it /may/ work.


This is correct. I got a patch from kntroh and DWT should work with D2 
on Windows.


 BTW: Besides looking crappy (which could probably be fixed with
 theme-support) my main issue with non-native GUIs is that they don't
 have standard filepickers.
 The GTK filepicker allows to save bookmarks to directorys and not having
 those annoys me. Furthermore those filepickers often just suck
 usability-wise.

 Cheers,
 - Daniel



-- 
/Jacob Carlborg
Apr 04 2011
prev sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.


 IDK why people are bothered so much by this.  I hate Swing only because it's so
 sluggish-feeling, but GTK on Windows doesn't bother me even though it looks
 non-native.  Similarly, I doubt DFL on Linux would bother me if I used Linux
as my
 desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've got too
much
 other stuff on my plate to fix this myself.


I was planing to give this a proper announcement when the linux version 
is working as well but anyway: DWT works with D2 on Windows.

http://hg.dsource.org/projects/dwt2

-- 
/Jacob Carlborg
Apr 04 2011
next sibling parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Jacob Carlborg <doob me.com> wrote:

 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2


How do we build?

I've tried `rake all`, but I get back errors:
https://gist.github.com/901684
Apr 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-04 16:08, Andrej Mitrovic wrote:

 On 4/4/11, Jacob Carlborg<doob me.com>  wrote:

 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2


 How do we build?

 I've tried `rake all`, but I get back errors:
 https://gist.github.com/901684


Oh, I probably should have mentioned that I'm currently only updating 
the base and SWT libraries, so run "rake base swt". The SWT snippets 
also compile: "rake swtsnippets".

-- 
/Jacob Carlborg
Apr 04 2011
parent reply Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Jacob Carlborg <doob me.com> wrote:

 Oh, I probably should have mentioned that I'm currently only updating
 the base and SWT libraries, so run "rake base swt". The SWT snippets
 also compile: "rake swtsnippets".


Yeah that worked. However not all of the snippets managed to compile,
and some of them fail at runtime. Most seem to work though.
Apr 04 2011
parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 20:55, Andrej Mitrovic wrote:

 On 4/4/11, Jacob Carlborg<doob me.com>  wrote:

 Oh, I probably should have mentioned that I'm currently only updating
 the base and SWT libraries, so run "rake base swt". The SWT snippets
 also compile: "rake swtsnippets".


 Yeah that worked. However not all of the snippets managed to compile,
 and some of them fail at runtime. Most seem to work though.


Yeah I know, some of the fail at runtime, I think some of them always 
did that. But I'm pretty sure all should compile.

-- 
/Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
On 4/4/11, Andrej Mitrovic <andrej.mitrovich gmail.com> wrote:

 On 4/4/11, Jacob Carlborg <doob me.com> wrote:

 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2


 How do we build?

 I've tried `rake all`, but I get back errors:
 https://gist.github.com/901684


Oops nevermind, I should have used `rake base swt`.
Apr 04 2011
prev sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/4/11 3:55 AM, Jacob Carlborg wrote:

 On 2011-04-04 01:38, dsimcha wrote:

 == Quote from Daniel Gibson (metalcaedes gmail.com)'s article

 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.


 IDK why people are bothered so much by this. I hate Swing only because
 it's so
 sluggish-feeling, but GTK on Windows doesn't bother me even though it
 looks
 non-native. Similarly, I doubt DFL on Linux would bother me if I used
 Linux as my
 desktop OS.


 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


 My only gripe with DWT is, AFAIK, it doesn't work for D2 yet and I've
 got too much
 other stuff on my plate to fix this myself.


 I was planing to give this a proper announcement when the linux version
 is working as well but anyway: DWT works with D2 on Windows.

 http://hg.dsource.org/projects/dwt2


You may want to post that to reddit.

Andrei
Apr 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 01:14, Daniel Gibson wrote:

 Am 04.04.2011 01:11, schrieb dsimcha:

 == Quote from Matthias Pleh (matthias none.net)'s article

 On 2011-04-03 21:05, Andrei Alexandrescu wrote:
 * DFL -> windows only, a way too .Net-like, is currently not very
 active (abandoned?)


 Not abandoned, just updated very sparsely. The DFL API is IMHO much
 easier to use
 than GtkD, which is why I wrote the first version of my Plot2kill lib
 for it
 before I ran into limitations I couldn't get around. (These were
 mainly lack of
 support for non-Windows OS's and lack of builtin vector graphics
 support a la
 GTK-Cairo.)

 I wonder how hard it would be to port DFL to Linux using Winelib.
 Wine's gotten
 pretty good lately, and the whole point of Winelib is to compile code
 that calls
 the Windows API on Linux. (Wine is for running Windows **binaries**,
 but it has a
 companion library, Winelib, for **compiling** Windows API code to
 native Linux
 binaries.)


 May be possible, but would probably look crappy - just like windows
 applications in wine look crappy (as long as you don't have a win2k like
 theme for GTK/QT so all your applications look like windows
 applications..).
 This may be acceptable to port or emulate windows applications, but not
 for developing new cross-platform applications.

 SWT looks great (==native) on Windows and Linux/GTK (probably also
 OSX?), so why not push DWT? Don't know what programming for it is like,
 though.


I think the SWT API is really nice. The Mac OS X port is still in 
progress. Later versions of SWT looks more native on osx, sheets and 
native toolbars.


 Cheers,
 - Daniel



-- 
/Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Andrei Alexandrescu wrote:

 We are honored to receive a fair amount of interest from students at
 our GSoC 2011.
 
 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).
 
 Another issue is that we have competing proposals on identical or
 overlapping projects. I am trying to solve one of these matters
 privately, and I think it would be best if we could solve the others
 in the community.
 
 I'm referring to Ishan's and Christian's proposals for containers.
 Both proposals have pros and cons, and I predict it would be very
 difficult to make a decision. Therefore, I'm trying to avoid that
 "by design", i.e. by finding a solution that would keep both busy on
 useful work that is in line with their capabilities.
 
 First, I suggest that anyone interested gives a thorough read to the
 two proposals:
 
 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1


That proposal is not made public. I.e. I cannot access it.


 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1
 
 Both students seem to be quite enthusiastic and capable. Two things
 that I'm worrying about are:
 
 1. Both seem to be quite fresh on D, so they'll need close coaching
 at least in the beginning.
 
 2. Both students seem unfamiliar with the STL, which is a difficult
 skill to acquire in a short time frame and is quite recommended for
 working on D's containers.


Both valid points. I'd like to help. But how do I know that I'm familiar
with the STL? It's containers and generic algorithms glued together via
iterators. I've read Effective STL and used the STL but I have never
looked at an implementation of the STL. On rare occasions I dived into
GNU STL to figure out what was going on.
Regarding the former: They should start reading your book, if they
haven't. What do you mean by coaching? Looking at their code and giving
feedback?


 If the students could comment on that, that would be helpful.
 
 Here's how I think we can solve the problem of overlapping projects:
 
 1. One way is to convince one of the students to work on a different
 topic that would also play into his strengths and is of interest to
 him. Any suggestions are welcome, both from the students and the
 community.
 
 2. Another approach would be to expand the scope of the project.
 There are plenty of interesting containers out there (see e.g.
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-cool-data-structures)
 that are darn useful. I suggest students to look over those and
 answer if they'd fell comfortable about implementing e.g. a Bloom


That is a nice list. I myself don't know most of these. I find extending
each project with an additional data structure more appealing. But the
students have to decide between those two options. I like the second one
more because then I learn something new.


 With an expanded containers project we could (assuming all goes
 smooth) benefit of a host of solid containers by fall. The thing is
 that would definitely require very intensive mentoring. I'd probably
 be a mentor, and I'd need at least one to be comfortable about
 putting this option on the table.


Can you express intensive monitoring in hours per week from your
experience?

BTW I never introduced myself and seeing all of the students submitting
proposals and gently introducing themselves I feel kind of cheap. The
applications are very good.
My name is Jens Mueller. I earned my CS degree from Humboldt University
Berlin in 2008. Currently I'm struggling as a PhD student.

Jens
Apr 03 2011
next sibling parent Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 5:06 PM, Jens Mueller wrote:

 Andrei Alexandrescu wrote:

 We are honored to receive a fair amount of interest from students at
 our GSoC 2011.

 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).

 Another issue is that we have competing proposals on identical or
 overlapping projects. I am trying to solve one of these matters
 privately, and I think it would be best if we could solve the others
 in the community.

 I'm referring to Ishan's and Christian's proposals for containers.
 Both proposals have pros and cons, and I predict it would be very
 difficult to make a decision. Therefore, I'm trying to avoid that
 "by design", i.e. by finding a solution that would keep both busy on
 useful work that is in line with their capabilities.

 First, I suggest that anyone interested gives a thorough read to the
 two proposals:

 http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1


 That proposal is not made public. I.e. I cannot access it.


Thanks for letting me know. I made sure I logged out before trying it, 
but probably I was still logged in in gmail.

I think I need at this point to ask the students to allow me to make 
their proposals public.


Andrei
Apr 03 2011
prev sibling parent reply Andrei Alexandrescu <SeeWebsiteForEmail erdani.org> writes:
On 4/3/11 5:06 PM, Jens Mueller wrote:

 Andrei Alexandrescu wrote:

 1. Both seem to be quite fresh on D, so they'll need close coaching
 at least in the beginning.

 2. Both students seem unfamiliar with the STL, which is a difficult
 skill to acquire in a short time frame and is quite recommended for
 working on D's containers.


 Both valid points. I'd like to help. But how do I know that I'm familiar
 with the STL? It's containers and generic algorithms glued together via
 iterators. I've read Effective STL and used the STL but I have never
 looked at an implementation of the STL. On rare occasions I dived into
 GNU STL to figure out what was going on.


That would be "STL internals". If you've used the STL systematically 
then it can be assumed you're familiar with it.


 Regarding the former: They should start reading your book, if they
 haven't. What do you mean by coaching? Looking at their code and giving
 feedback?


More than that: guiding the next step. That would entail understanding 
the high level issues quite well.


 With an expanded containers project we could (assuming all goes
 smooth) benefit of a host of solid containers by fall. The thing is
 that would definitely require very intensive mentoring. I'd probably
 be a mentor, and I'd need at least one to be comfortable about
 putting this option on the table.


 Can you express intensive monitoring in hours per week from your
 experience?


I don't have experience as a GSoC mentor, but I assume it should be 
doable in addition to a normal job. The main challenge is having the 
background.


Andrei
Apr 03 2011
parent reply Jens Mueller <jens.k.mueller gmx.de> writes:
Andrei Alexandrescu wrote:

 On 4/3/11 5:06 PM, Jens Mueller wrote:

Andrei Alexandrescu wrote:

1. Both seem to be quite fresh on D, so they'll need close coaching
at least in the beginning.

2. Both students seem unfamiliar with the STL, which is a difficult
skill to acquire in a short time frame and is quite recommended for
working on D's containers.


Both valid points. I'd like to help. But how do I know that I'm familiar
with the STL? It's containers and generic algorithms glued together via
iterators. I've read Effective STL and used the STL but I have never
looked at an implementation of the STL. On rare occasions I dived into
GNU STL to figure out what was going on.


 
 That would be "STL internals". If you've used the STL systematically
 then it can be assumed you're familiar with it.


I see. I hope I've been using it in an appropriate manner. I find it
sometimes difficult. Getting the functors to work etc.


Regarding the former: They should start reading your book, if they
haven't. What do you mean by coaching? Looking at their code and giving
feedback?


 
 More than that: guiding the next step. That would entail
 understanding the high level issues quite well.


Unfortunately I think I don't overlook the high level issues. Maybe it's
something obvious but right now I feel baffled. I should reread what you
have said about the intended container design in previous posts.


With an expanded containers project we could (assuming all goes
smooth) benefit of a host of solid containers by fall. The thing is
that would definitely require very intensive mentoring. I'd probably
be a mentor, and I'd need at least one to be comfortable about
putting this option on the table.


Can you express intensive monitoring in hours per week from your
experience?


 
 I don't have experience as a GSoC mentor, but I assume it should be
 doable in addition to a normal job. The main challenge is having the
 background.


I agree. It's the background that matters most here.

Jens
Apr 04 2011
parent reply Christian Hotz-Behofsits <chris.hotz.behofsits gmail.com> writes:
Hi there!

Now I read Ishan's idea of a expansion of the scope and I think it's a
good one! We can split a greater topic in smaller ones and can
complement each other! There are a lot of cool containers and so the
library would get even mightier.

Now we are prepared (I ordered some books on that topic last week) and
another topic would be like a setback!
Apr 07 2011
parent reply Christian Hotz-Behofsits <chris.hotz.behofsits gmail.com> writes:
I thought a lot about the project, the possibility to switch to
other topics and why I really want to work on containers. So I wrote

long. It was a fulfilling and positiv conversation with a clear
result:
We both would like to work on containers in a way of cooperation[1]
- Containers are a big topic and so we can make D to a really
powerful language. I like them, because they have a very
interresting theoretical side and they consists of logical
considerations.


knew what a blooming filter is until I looked it up, but: Who fights
can lose, who doesn't fight has already lost.

And no, we are not stubborn - we only know what we want :-)

[1]Same topic, but not on the same data structures.
Apr 09 2011
parent Ishan Thilina <ishanthilina gmail.com> writes:
I thought a lot about the project, the possibility to switch to
other topics and why I really want to work on containers. So I wrote

long. It was a fulfilling and positiv conversation with a clear
result:


Yes, Christian did mail me regarding this matter :-) .


We both would like to work on containers in a way of cooperation[1]
- Containers are a big topic and so we can make D to a really
powerful language. I like them, because they have a very
interresting theoretical side and they consists of logical
considerations.


Yes, I agree with Christian. Containers are a big topic and you can add much as
you like to make it even bigger. (The scope will just keep expanding ;) ). So
the
topic contains enough work to be covered by two students. So who ever the
students
that gets selected to do the project should be able to cooperate with the other
student. We must not forget that at the end of the day the whole work that is
done
goes to the benefit of the company no matter who ever does it.

Mr. Alexandrescu points out from the email he sent to the GSoC participants
before
the application deadlines that "we will allow
only 1-2 applications on containers" . So there is a possibility of the
container
project getting two students accepted. As the D community we should come up
with a
plan to decide which data structures should be implemented and seperate and
assign
them between the students. It's another story if only one student gets selected
to
the project, but it is always good to be prepared early. So if we start early we
will be able to create a solid and a well seperated two project plans on
containers before 25th of Apr letting the students who gets selected( whoever
they
are) for the project to start the work early without debating on which data
structures to implement.

Earlier the project starts more data structures will be created ( --> more for D
 :-D)...!
Apr 10 2011
prev sibling next sibling parent reply Zz <zz nospam.com> writes:
You can look at IUP which is simple written in C and comes with the MIT licence.

http://www.tecgraf.puc-rio.br/iup/

Zz

Matthias Pleh Wrote:


 On 2011-04-03 21:05, Andrei Alexandrescu wrote:

 I think it's not too late to improve our GSoC ideas page


 
 So here come my ideas
 
 
 
 There is still the lack of a good D Gui Library.
 Currently some GUI's are still under development (most projects on 
 dsoure are abandoned!), but none of them are really perfect D-GUI's
 * GtkD -> good and stable, but a D wrapper around a C-library
 * DWT  -> also good, but a port from Java and not really D-like coded
 * DFL  -> windows only, a way too .Net-like, is currently not very 
 active (abandoned?)
 * ... all others I know are unmature and abandoned (tell me, if I'm 
 wrong here!)
 
 So there comes 2 ideas to my mind:
 
 
 - Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development
    * Just basic structures/functions/classes for Window creation,
    event handling, ...
    This could be used not only by a Standard-D-Gui-library,
    but also by other Gui-libraries for D
 
 - Design of a OS independent GUI-toolkit
    * class-diagramm, basicstuctures, ...
 
 This could be the beginning of a Community-driven development of a good 
 D-GUI-library which eventualy could find its way into phobos ... ?
Apr 04 2011
next sibling parent Ishan Thilina <ishanthilina gmail.com> writes:
Sorry,my project proposal was not visible to the public earlier. It is now can
be
seen by anyone. Sorry for the inconvenience.

My project proposal:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/ishanthilina/1

Christian's project proposal:
http://www.google-melange.com/gsoc/proposal/review/google/gsoc2011/murphy/1
Apr 04 2011
prev sibling next sibling parent reply Daniel Gibson <metalcaedes gmail.com> writes:
Am 04.04.2011 17:01, schrieb Zz:

 You can look at IUP which is simple written in C and comes with the MIT
licence.
 
 http://www.tecgraf.puc-rio.br/iup/
 
 Zz
 


This actually looks pretty good (in their gallery).
It lacks native OSX support, though.
Apr 04 2011
parent reply Jacob Carlborg <doob me.com> writes:
On 2011-04-04 17:10, Daniel Gibson wrote:

 Am 04.04.2011 17:01, schrieb Zz:

 You can look at IUP which is simple written in C and comes with the MIT
licence.

 http://www.tecgraf.puc-rio.br/iup/

 Zz


 This actually looks pretty good (in their gallery).
 It lacks native OSX support, though.


Looking at the Comparing page: "We plan for the future to build a native 
Carbon driver.". I don't understand why anyone would waste resources on 
Carbon when Cocoa is available.

-- 
/Jacob Carlborg
Apr 04 2011
parent Andrej Mitrovic <andrej.mitrovich gmail.com> writes:
It seems to use some specialized language to create the GUI elements,
or am I wrong? Refering to IUP.
Apr 04 2011
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2011-04-04 17:01, Zz wrote:

 You can look at IUP which is simple written in C and comes with the MIT
licence.

 http://www.tecgraf.puc-rio.br/iup/

 Zz


No Mac OS X support as far as I can see.


 Matthias Pleh Wrote:


 On 2011-04-03 21:05, Andrei Alexandrescu wrote:

 I think it's not too late to improve our GSoC ideas page


 So here come my ideas



 There is still the lack of a good D Gui Library.
 Currently some GUI's are still under development (most projects on
 dsoure are abandoned!), but none of them are really perfect D-GUI's
 * GtkD ->  good and stable, but a D wrapper around a C-library
 * DWT  ->  also good, but a port from Java and not really D-like coded
 * DFL  ->  windows only, a way too .Net-like, is currently not very
 active (abandoned?)
 * ... all others I know are unmature and abandoned (tell me, if I'm
 wrong here!)

 So there comes 2 ideas to my mind:


 - Abstraction Layer for OS independent (Win/Linux/OSX/?) GUI development
     * Just basic structures/functions/classes for Window creation,
     event handling, ...
     This could be used not only by a Standard-D-Gui-library,
     but also by other Gui-libraries for D

 - Design of a OS independent GUI-toolkit
     * class-diagramm, basicstuctures, ...

 This could be the beginning of a Community-driven development of a good
 D-GUI-library which eventualy could find its way into phobos ... ?






-- 
/Jacob Carlborg
Apr 04 2011
prev sibling next sibling parent reply Ishan Thilina <ishanthilina gmail.com> writes:
Here's how I think we can solve the problem of overlapping projects:

1. One way is to convince one of the students to work on a different
topic that would also play into his strengths and is of interest to him.
Any suggestions are welcome, both from the students and the community.


After all the time and energy that I have sacrificed for this project it's
really
sad to let go of this project. But if I get an idea I'll definitely post it
here :)


2. Another approach would be to expand the scope of the project. There
are plenty of interesting containers out there (see e.g.
http://stackoverflow.com/questions/500607/what-are-the-lesser-known-but-cool-data-structures)
that are darn useful. I suggest students to look over those and answer
if they'd fell comfortable about implementing e.g. a Bloom filter or a trie.


I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
was listed in that page. Yes, things such as Skip list and Binary decision tree
looks interesting. But to be honest I have never heard about those data
structures
before. So how can I guarantee and point out to a data structure and say that I
will be able to implement this before the end of GSoC ? I may be only able to
implement only two or three data structures before the time ends? It's very hard
to predict on things that you don't know of.

I think learning about these data structures won't be a problem. As there was a
link for a video tutorial for skip list on that page We'll be able to find more
and more resources if we try hard enough( MIT provides lot's videos and we
should
be able to find good tutorials). But it'll take some time to learn about them.
So
I really can't give a guarantee in the project proposal( if I was asked to
implement these data structures) that I'll be able to implement this much of
data
structures.

This is solely my idea, Christian may have a different idea :)
Apr 05 2011
parent reply bearophile <bearophileHUGS lycos.com> writes:
Ishan Thilina:


 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.


Some data structures useful for Phobos:
- a graph;
- a hash set;
- A deque made with a dynamic array of fixed sized arrays;
- a Union-Find (not too much hard);
- a Bloom filter (easy with the already present bit arrays);
- a dawg;
- a simple trie;
- a BK-tree;
- a bidirectional associative array;
- a parallelizable immutable finger tree.

Bye,
bearophile
Apr 05 2011
next sibling parent spir <denis.spir gmail.com> writes:
On 04/05/2011 11:48 AM, bearophile wrote:

 Ishan Thilina:


 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.


 Some data structures useful for Phobos:
 - a graph;
 - a hash set;
 - A deque made with a dynamic array of fixed sized arrays;
 - a Union-Find (not too much hard);
 - a Bloom filter (easy with the already present bit arrays);
 - a dawg;
 - a simple trie;
 - a BK-tree;
 - a bidirectional associative array;
 - a parallelizable immutable finger tree.


Do you really find it appropriate to throw an avalanche of new data structure 
over Ishan when he just said he has "never heard about" "Skip list, Binary 
decision tree, Trie, rope"?

Denis
-- 
_________________
vita es estrany
spir.wikidot.com
Apr 05 2011
prev sibling parent KennyTM~ <kennytm gmail.com> writes:
On Apr 5, 11 17:48, bearophile wrote:

 Ishan Thilina:


 I looked at few things( such as Skip list, Binary decision tree, Trie, rope)
that
 was listed in that page. Yes, things such as Skip list and Binary decision tree
 looks interesting. But to be honest I have never heard about those data
structures
 before.


 Some data structures useful for Phobos:
 - a graph;
 - a hash set;
 - A deque made with a dynamic array of fixed sized arrays;
 - a Union-Find (not too much hard);
 - a Bloom filter (easy with the already present bit arrays);
 - a dawg;
 - a simple trie;
 - a BK-tree;
 - a bidirectional associative array;
 - a parallelizable immutable finger tree.

 Bye,
 bearophile


 From this list, I'd only want to see 'hash set', 'deque', 
'bidirectional AA' and maybe 'trie' in std.container.

Union-Find - Maybe useful, but when did you need a union-find structure 
outside of Kruskal's algorithm?

Bloom filter - I've never hit a case where a hash set is too big and a 
bloom filter is enough.

Dawg, BK-tree, finger tree - What are these? Why are they useful for 
Phobos?

Graph - Yes it is useful, but there are too many operations associated 
with it, which should better live as its own module (std.container.graph?).

P.S. Here I'm talking about future addition to std.container in general, 
not about the two GSoC projects.

P.P.S. if you don't mind I'd like to add 'interval set' to the list. See 
Boost.Icl.
Apr 05 2011
prev sibling next sibling parent bearophile <bearophileHUGS lycos.com> writes:
spir:


 Do you really find it appropriate to throw an avalanche of new data structure 
 over Ishan when he just said he has "never heard about" "Skip list, Binary 
 decision tree, Trie, rope"?


If you are going to design collections for Phobos, you want to know a long list
of the ones that are interesting, to choose from.

-----------------------

KennyTM~:


 Union-Find - Maybe useful, but when did you need a union-find structure
 outside of Kruskal's algorithm?


Union-Find is easy to implement and it's useful in lot of situations. One
example:
http://www.vdrobot.com/UnionFind/UnionFind.html



 Bloom filter - I've never hit a case where a hash set is too big and a
 bloom filter is enough.


I have used Bloom Filters twice so far, in filtering strings and genomic
processing/search. I agree it's not so widely useful, but it is not hard to
implement for a student in the summer.


Dawg, BK-tree, finger tree - What are these? Why are they useful for
Phobos?

Dawgs and BK-trees are useful if you search strings, etc. I have not used a
finger tree yet, it's probably not immediate to implement, but it's a building
block of several purely function data structures, so it's a good starting point
for functional (immutable) data structures in D2/Phobos.



 Graph - Yes it is useful, but there are too many operations associated
 with it, which should better live as its own module (std.container.graph?).


You design the core and its interface, then the graph functions are often free
function external to the core data structure.



 P.P.S. if you don't mind I'd like to add 'interval set' to the list. See
 Boost.Icl.


Good idea.

Bye,
bearophile
Apr 05 2011
prev sibling parent Jonas Drewsen <jdrewsen nospam.com> writes:
On 03/04/11 21.05, Andrei Alexandrescu wrote:

 We are honored to receive a fair amount of interest from students at our
 GSoC 2011.

 One issue is that at least one student (who contacted me off-list)
 couldn't find a project to work on that would best play into his
 strengths. I think it's not too late to improve our GSoC ideas page
 (http://prowiki.org/wiki4d/wiki.cgi?GSOC_2011_Ideas).


* Web development framework - e.g. inspired by Ruby on Rails.
Apr 05 2011