www.digitalmars.com         C & C++   DMDScript  

D - Active Projects

reply "C" <dont respond.com> writes:
I was just wondering what everyone else is working on.  I think it would be
cool to have a refrence , so were not duplicating each other and stuff :).

Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
start a mysql module soon.

You guys ?

C
Jan 09 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
 I was just wondering what everyone else is working on.  I think it would


be

 cool to have a refrence , so were not duplicating each other and stuff :).

 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.

 You guys ?


Matthew:

For the foreseeable future (next 3 months):

1. I've written the MmFile (memory mapped file) and ExeModule (dynamic lib
loader) modules, and they're with Walter ATM. It's my understanding that
he's busy with his presentation so 0.78 might be some while. I'd like to get
them out sometime soon, so that people can give me feedback, since each was
done in half a day, and there may well be more features that can be easily
and orthogonally added. I'm hoping my friend Greg can help with these, as
he's interested in getting into D, but he's busy as well at the moment.

2. I'll be working with Walter (he'll be the much-needed compiler/language
guru) on DTL in Feb/March, once the book deadline's past. The plan is to do
a bit of a Stepanov and Lee in the first instance, and just get on with it
in private. There are several reasons for this is (i) I work fast alone and
time will be pressing, and (ii) I'm a real f-wit when it comes to discussing
high-level things in writing, resulting in my getting unproductively
confused (typical mentally challenged picture thinker). But the main reason
is that if there are separate attempts going on, as I assume there are, then
each will not pollute the other. I think in the early stages it'll be good
to get separate, and potentially unique, ideas for the DTL, and then when
each is at a cogent stage they can be presented to the community and
well-criticised. Then the best parts can be fed from to form a final,
world-beating, template library, with all the necessary support from the
compiler. Walter and I've said we'd both like a template library that's more
powerful, efficient and simple than STL, Boost, STLSoft, or any of the C++
libs.

In the dim and distant future (3-24 months):

1. I'd like to see a neat and macro free equivalent to ATL for COM
programming. It'd be good to rewrite the shell-extensions
(http://shellext.com/) in D at some point. :)

2. I'd like to see D become the best language for writing Python extensions.
Same goes for Perl and Java.

3. I'd like to see a Visual Studio.NET plug-in editor for D.

4. I'd like to see DIDE and leds have a shared pluggable architecture

5. I'd like to see the D compiler have a pluggable architecture, and would
love to write DLint (or should that be MDLint?) and DStrip plug-ins for
that.

6. I plan to write a book on D sometime in the non-too-distant future.
Jan 09 2004
prev sibling next sibling parent reply Cloud9 Virtual <cloud9virtual yahoo.com> writes:
Greetings. First post, but I've been following the group for some time.
My interest with D is primarily as an embedded systems language. To that 
end at least two things need to happen:
- integration with the GCC backend so we get access to the embedded 
targets used in the industry; someone on D.gnu is looking into that (as 
have I).
- the garbage collector needs a real-time variant. I am currently 
studying the Metronome garbage collector, part of IBM's Jikes JVM. 
Hopefully I will produce a D version soon enough.

Alex M.

C wrote:

 I was just wondering what everyone else is working on.  I think it would be
 cool to have a refrence , so were not duplicating each other and stuff :).
 
 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.
 
 You guys ?
 
 C
Jan 09 2004
parent "Walter" <walter digitalmars.com> writes:
"Cloud9 Virtual" <cloud9virtual yahoo.com> wrote in message
news:bto931$ggi$1 digitaldaemon.com...

 Greetings. First post, but I've been following the group for some time.
 My interest with D is primarily as an embedded systems language. To that
 end at least two things need to happen:
 - integration with the GCC backend so we get access to the embedded
 targets used in the industry; someone on D.gnu is looking into that (as
 have I).
 - the garbage collector needs a real-time variant. I am currently
 studying the Metronome garbage collector, part of IBM's Jikes JVM.
 Hopefully I will produce a D version soon enough.


Cool! Keep us informed of the progress.
Jan 10 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
1.  I was attempting to write a D port of Jalopy, a source code formatter, and 
it looked doable for a while.  Then I realized how dependent it was upon ANTLR, 
a lexer/parser written in Java.  So it quickly turned into two ports.  I am 
still toying with porting lex/yacc or ANTLR first, and then getting back to 
Jalopy.  I guess I could kick the tires on std.regexp and do the lexer/parser, 
although my programming skills are intermediate at best.

2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.

If anyone else is working on similar tools, let this thread know...

Brad


C wrote:


 I was just wondering what everyone else is working on.  I think it would be
 cool to have a refrence , so were not duplicating each other and stuff :).
 
 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.
 
 You guys ?
 
 C
Jan 20 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...

2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.


Before you start that maybe you could influence us to change to 
SWT instead of wxWindows. maybe it's better!

we are not married to wxWindows. SWT looks very good actually.
As a more recent toolkit it has all the probability of being better.

(the wx Project probably will not have a GTK soon.
I thought we were going to do the native windows and one X11
(or universal) to start with.)

Will you be interested in join us if we change to SWT?

What do you say guys is SWT better then wxWindows (I'm telling you,
it might be - not that I looked in detail to any... ;)

these projects are huge (unless you have full time for it)
so 4/1 is better then (3+1)/2.

Ant
Jan 20 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
It is nothing more than a "gut" feel on SWT.  You touched on some of the
issues. 
    (More recent toolkit, heavy support from IBM).

SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a sense, 
we would be replacing DUI with SWT-4D/GTK, and making the calls to native Win32 
have the same wrappers.

I have thought that maybe DUI's wrappers of GTK could be modified to use native 
Win32 calls and then we have the beginnings of a platform independent GUI. 
Then 
we've created a third option in addition to wxWindows and SWT.  But I'm pretty 
sure that the Eclipse/SWT group at IBM has had experience far beyond GTK/linux 
and Windows, as has wxWindows with their long history.  So I lean toward one of 
the existing two, and for some reason I lean further toward SWT.

One reason may be that it's in Java, a language far easier for me to port to D 
than C++.  (By the way, we are talking about a port to D, right?  I wouldn't be 
interested in wrapping the Java and requiring a JVM.)  That just has to do with 
my skill set.  The C portion of SWT source has to do with the JNI/native calls, 
and the meat of SWT is in the Java classes.  D doesn't need JNI, except to wrap 
the calls in an *.h file.

I am only investigating SWT, but everything looks favorable.  I haven't 
downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of 
sense, and looks like it could be moved to D.  If you want to research SWT
more, 
that would be great.  And I'll definitely join you and help however I can...

Cheers,
Brad



Ant wrote:


 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...
 

2.  I am investigating porting SWT to D to have a GUI that would use native 
widgets on the host OS when possible, and implemented widgets otherwise.  IBM 
has had great success with this library, its primary use being Eclipse IDE.  I 
know this is YAGUI (Yet another GUI) - however I want a platform-independent
GUI 
without having to distribute GTK+ or any other library on Win32.


 
 
 Before you start that maybe you could influence us to change to 
 SWT instead of wxWindows. maybe it's better!
 
 we are not married to wxWindows. SWT looks very good actually.
 As a more recent toolkit it has all the probability of being better.
 
 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)
 
 Will you be interested in join us if we change to SWT?
 
 What do you say guys is SWT better then wxWindows (I'm telling you,
 it might be - not that I looked in detail to any... ;)
 
 these projects are huge (unless you have full time for it)
 so 4/1 is better then (3+1)/2.
 
 Ant
Jan 20 2004
next sibling parent Brad Anderson <brad sankaty.dot.com> writes:
Further, nobody is talking about XUL.  That's the XML User Interface Language 
that was used to build Mozilla, Firebird, Thunderbird, etc.  Maybe we strap a 
parser onto some code and go to work implementing XUL-4D.

See here for info:

http://www.mozilla.org/projects/xul/
http://luxor-xul.sourceforge.net/talk/vanx-mar-2003/slides.html#rich-41  (but 
look at the whole page, as it discusses SWT, wxWindows, Qt, etc...)

BA





Brad Anderson wrote:


 It is nothing more than a "gut" feel on SWT.  You touched on some of the 
 issues.    (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a 
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls 
 to native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use 
 native Win32 calls and then we have the beginnings of a platform 
 independent GUI.  Then we've created a third option in addition to 
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at 
 IBM has had experience far beyond GTK/linux and Windows, as has 
 wxWindows with their long history.  So I lean toward one of the existing 
 two, and for some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to 
 port to D than C++.  (By the way, we are talking about a port to D, 
 right?  I wouldn't be interested in wrapping the Java and requiring a 
 JVM.)  That just has to do with my skill set.  The C portion of SWT 
 source has to do with the JNI/native calls, and the meat of SWT is in 
 the Java classes.  D doesn't need JNI, except to wrap the calls in an 
 *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't 
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot 
 of sense, and looks like it could be moved to D.  If you want to 
 research SWT more, that would be great.  And I'll definitely join you 
 and help however I can...
 
 Cheers,
 Brad
 
 
 
 Ant wrote:
 

 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...


 2.  I am investigating porting SWT to D to have a GUI that would use 
 native widgets on the host OS when possible, and implemented widgets 
 otherwise.  IBM has had great success with this library, its primary 
 use being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - 
 however I want a platform-independent GUI without having to 
 distribute GTK+ or any other library on Win32.




 Before you start that maybe you could influence us to change to SWT 
 instead of wxWindows. maybe it's better!

 we are not married to wxWindows. SWT looks very good actually.
 As a more recent toolkit it has all the probability of being better.

 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)

 Will you be interested in join us if we change to SWT?

 What do you say guys is SWT better then wxWindows (I'm telling you,
 it might be - not that I looked in detail to any... ;)

 these projects are huge (unless you have full time for it)
 so 4/1 is better then (3+1)/2.

 Ant
Jan 20 2004
prev sibling next sibling parent reply Andy Friesen <andy ikagames.com> writes:
Brad Anderson wrote:


 It is nothing more than a "gut" feel on SWT.  You touched on some of the 
 issues.    (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a 
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls 
 to native Win32 have the same wrappers.


This is an awesome idea.  I've since learned that GTK takes a very.... 
unique approach to grouping and arranging widgets.  For one, I can't for 
the life of me find *any* way to simply set the position/size of a UI 
element.  While it's commendable that GTK+ takes the layout manager 
notion to this extent, it makes wrapping it and win32 a serious pain.

For this reason, converting DUI to call win32 instead of GTK would be 
difficult.

Now it's apparent why this crossplatform GUI thing is so hard. ;)

(it's all GTKs fault!)

  -- andy
Jan 20 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:


 Brad Anderson wrote:
 
 
 This is an awesome idea.  I've since learned that GTK takes a very.... 
 unique approach to grouping and arranging widgets.


I fond it natural and familiar!?...
Maybe I on the past I used the same toolkit the designer of GTK did.


 For one, I can't for 
 the life of me find *any* way to simply set the position/size of a UI 
 element.


I'm still looking for the xtToolkit way; I think is the best:
you just say this widget goes to the left or that
and the other goes bellow that one over there...


 While it's commendable that GTK+ takes the layout manager 
 notion to this extent, it makes wrapping it and win32 a serious pain.
 
 For this reason, converting DUI to call win32 instead of GTK would be 
 difficult.


If DUI get's extremelly popular someone will do it (not me:)


 
 Now it's apparent why this crossplatform GUI thing is so hard. ;)


That's why we are going to base the work on some proven existing one.
In your GUI you have 2 complete independent implementations 
of your API.


 
 (it's all GTKs fault!)


???

So, do we think that SWT deserves a look right.
(I kinda don't like the look of wxWindows web page and the demos
are crappy).

Again without looking in detail seems to me that wxWindows
is more like a cross platform "environment"
and SWT a cross platform GUI toolkitk.
It's confusing seeing ODBC as part of wxWindows...

I wanna look in more detail to wxWindows and SWT.
(but leds is is dragging me away)

Ant
Jan 20 2004
parent Andy Friesen <andy ikagames.com> writes:
Ant wrote:

 On Tue, 20 Jan 2004 18:09:42 -0800, Andy Friesen wrote:
 

This is an awesome idea.  I've since learned that GTK takes a very.... 
unique approach to grouping and arranging widgets.


 
 I fond it natural and familiar!?...
 Maybe I on the past I used the same toolkit the designer of GTK did.
 


I'm not judging, I just mean that it's very different from most 
everything else I've used.


 

For one, I can't for 
the life of me find *any* way to simply set the position/size of a UI 
element.


 
 I'm still looking for the xtToolkit way; I think is the best:
 you just say this widget goes to the left or that
 and the other goes bellow that one over there...
 


wx does quite a lot of work to make GTK+ behave like the other 
implementations. (not the least of which is the custom GtkPizza widget)


 

Now it's apparent why this crossplatform GUI thing is so hard. ;)


 
 That's why we are going to base the work on some proven existing one.
 In your GUI you have 2 complete independent implementations 
 of your API.
 


Yup.  I never expected to get anywhere.  I'm just prototyping for my own 
amusement.

(by the way, I intentionally took exactly the same approach as SWT)


 

(it's all GTKs fault!)


 
 ???


That was a joke. ;)


 
 So, do we think that SWT deserves a look right.
 (I kinda don't like the look of wxWindows web page and the demos
 are crappy).
 


SWT already looks like the better choice to me.  D has more in common 
with Java than it does C++.  The similarities run deep enough that the 
conversion would be pretty easy.  (large amounts of it could be automated)

  -- andy
Jan 20 2004
prev sibling next sibling parent reply John Reimer <jjreimer telus.net> writes:
On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:


 It is nothing more than a "gut" feel on SWT.  You touched on some of the
 issues.
     (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to
 native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use
 native Win32 calls and then we have the beginnings of a platform
 independent GUI.  Then we've created a third option in addition to
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM
 has had experience far beyond GTK/linux and Windows, as has wxWindows with
 their long history.  So I lean toward one of the existing two, and for
 some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to port
 to D than C++.  (By the way, we are talking about a port to D, right?  I
 wouldn't be interested in wrapping the Java and requiring a JVM.)  That
 just has to do with my skill set.  The C portion of SWT source has to do
 with the JNI/native calls, and the meat of SWT is in the Java classes.  D
 doesn't need JNI, except to wrap the calls in an *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of
 sense, and looks like it could be moved to D.  If you want to research SWT
 more, that would be great.  And I'll definitely join you and help however
 I can...
 
 Cheers,
 Brad



After a basic investigation of SWT, I have to admit that it looks
promising, probably much more promising than wxWindows.  The C++ code in
wxWindows along with it's religious use of macros makes it a difficult
port to D.  It's possible, but not easy.  SWT uses JNI to connect
to platform specific C code.  It looks like it is designed to do what we
really wanted to do with D.  If we could do a D version of SWT, it likely
would be a much easier port than wxWindows.  The similarities between D
and Java are extremely useful in this case (garbage collection,
programming style) as was mentioned.

I guess my question is, developing ease aside, what would attract more D
users? Is SWT as popular as wxWindows?  Would the general consensus within
the D community be to use one over the other?  Since SWT is java oriented
thing, I don't know if C++ developers would even be interested in it (as a
way to attract them to the D language).  On the other hand, perhaps we
just need to take the plunge, and get a good solid, crossplatform GUI
library implemented.  One modeled after SWT might be a good bet.  So what
would we call it? DWT? :-)

Later,

John
Jan 20 2004
parent reply Ant <duitoolkit yahoo.ca> writes:
On Tue, 20 Jan 2004 19:40:34 -0800, John Reimer wrote:


 On Tue, 20 Jan 2004 17:15:07 -0600, Brad Anderson wrote:
 

 It is nothing more than a "gut" feel on SWT.  You touched on some of the
 issues.
     (More recent toolkit, heavy support from IBM).
 
 SWT-4D will need to wrap GTK for the *nix world (like SWT does), so in a
 sense, we would be replacing DUI with SWT-4D/GTK, and making the calls to
 native Win32 have the same wrappers.
 
 I have thought that maybe DUI's wrappers of GTK could be modified to use
 native Win32 calls and then we have the beginnings of a platform
 independent GUI.  Then we've created a third option in addition to
 wxWindows and SWT.  But I'm pretty sure that the Eclipse/SWT group at IBM
 has had experience far beyond GTK/linux and Windows, as has wxWindows with
 their long history.  So I lean toward one of the existing two, and for
 some reason I lean further toward SWT.
 
 One reason may be that it's in Java, a language far easier for me to port
 to D than C++.  (By the way, we are talking about a port to D, right?  I
 wouldn't be interested in wrapping the Java and requiring a JVM.)  That
 just has to do with my skill set.  The C portion of SWT source has to do
 with the JNI/native calls, and the meat of SWT is in the Java classes.  D
 doesn't need JNI, except to wrap the calls in an *.h file.
 
 I am only investigating SWT, but everything looks favorable.  I haven't
 downloaded SWT's Linux/GTK source yet, but the Win32 source makes a lot of
 sense, and looks like it could be moved to D.  If you want to research SWT
 more, that would be great.  And I'll definitely join you and help however
 I can...
 
 Cheers,
 Brad


 
 
 After a basic investigation of SWT, I have to admit that it looks
 promising, probably much more promising than wxWindows.  The C++ code in
 wxWindows along with it's religious use of macros makes it a difficult
 port to D.  It's possible, but not easy.  SWT uses JNI to connect
 to platform specific C code.  It looks like it is designed to do what we
 really wanted to do with D.  If we could do a D version of SWT, it likely
 would be a much easier port than wxWindows.  The similarities between D
 and Java are extremely useful in this case (garbage collection,
 programming style) as was mentioned.
 
 I guess my question is, developing ease aside, what would attract more D
 users? Is SWT as popular as wxWindows?  Would the general consensus within
 the D community be to use one over the other?  Since SWT is java oriented
 thing, I don't know if C++ developers would even be interested in it (as a
 way to attract them to the D language).  On the other hand, perhaps we
 just need to take the plunge, and get a good solid, crossplatform GUI
 library implemented.  One modeled after SWT might be a good bet.  So what
 would we call it? DWT? :-)
 


very well said.

I don't believe there are many project using SWT

What's the license on SWT?

(One detail I just saw on SWT it uses the beloved listener interfaces.
we would probably change the entire event processing (?))

A couple of (almost random selected) SWT links
(go to IBM.com and search for SWT):
http://www-106.ibm.com/developerworks/opensource/library/os-ecgui1/
http://www-106.ibm.com/developerworks/java/library/j-nativegui2/

(DWT as name is awfull)

Ant
Jan 20 2004
parent reply "Walter" <walter digitalmars.com> writes:
"Ant" <duitoolkit yahoo.ca> wrote in message
news:pan.2004.01.21.03.44.02.162329 yahoo.ca...

 What's the license on SWT?


That's the first thing to check. If it doesn't have a compatible license,
there's no point in looking at it any further. It must be one of:

1) public domain
2) copyrighted, but freely modifiable and redistributable for any purpose
3) GPL
Jan 22 2004
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Walter wrote:


 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 

What's the license on SWT?


 
 
 That's the first thing to check. If it doesn't have a compatible license,
 there's no point in looking at it any further. It must be one of:
 
 1) public domain
 2) copyrighted, but freely modifiable and redistributable for any purpose
 3) GPL
 
 


Not really. AFAIK it is quite possible to implement the same interface
as long as neither implementation or documentation is copied from the
other. An example is Coin (www.coin3d.org) that is an implementation
of the Open Inventor API. The rights to the name is owned by a totally
different company. My impression is that TGS (todays owners of Open
Inventor) sees SIM's Coin as healthy competition. Coin from SIM and
Open Inventor from TGS is fully compatible (except where they have some
differing extra features).

When it comes to SWT, it isn't even the same language and the problem
should be even less. Of course, IBM is a huge company and might think
in other ways than TGS.

Lars Ivar Igesund
Jan 22 2004
parent "Walter" <walter digitalmars.com> writes:
"Lars Ivar Igesund" <larsivar igesund.net> wrote in message
news:bup1o3$2k3i$1 digitaldaemon.com...

 Not really. AFAIK it is quite possible to implement the same interface
 as long as neither implementation or documentation is copied from the
 other.


True, that's called a "clean room" implementation. It's not worth the
bother, though, if the original meets one of those 3 requirements.
Jan 23 2004
prev sibling next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:

from below, but I'm not sure why it has to be the GPL.

Also, I don't know if we have to use the CPL if we rewrite the entire thing in
D 
code.  We would not be changing/modifying any of their Java code.  We could 
choose any number of licenses to use.  I would probably just continue on using 
the CPL, and at the same time, give credit to the original contributors of the 
SWT Java code as providing us with a framework / starting point.

But I'm not a lawyer.

BA

Walter wrote:

 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 

What's the license on SWT?


 
 
 That's the first thing to check. If it doesn't have a compatible license,
 there's no point in looking at it any further. It must be one of:
 
 1) public domain
 2) copyrighted, but freely modifiable and redistributable for any purpose
 3) GPL
Jan 22 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:



 
 Also, I don't know if we have to use the CPL if we rewrite the entire 
 thing in D code.  We would not be changing/modifying any of their Java 
 code.  We could choose any number of licenses to use.  I would probably 
 just continue on using the CPL, and at the same time, give credit to the 
 original contributors of the SWT Java code as providing us with a 
 framework / starting point.
 
 But I'm not a lawyer.


I'm not a lawyer either, but it seems to me that what you're talking 
about doing (some sort of port) would be considered a "derivative". 
Thus, the GUI library itself would have to be open source (the Common 
Public License in particular).

"Contributions do not include additions to the Program which: (i) are 
separate modules of software distributed in conjunction with the Program 
under their own license agreement, and (ii) are not derivative works of 
the Program."
http://www.opensource.org/licenses/cpl.php

But commercial applications ("separate modules") could utilitize this 
SWT-based library without going open source ("their own license 
agreement").  I should probably stop now, since I'm already in over my 
head. :)

Another fun link:  http://sourceforge.net/projects/libswt

 
 BA
 
 Walter wrote:
 

 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...


 What's the license on SWT?




 That's the first thing to check. If it doesn't have a compatible license,
 there's no point in looking at it any further. It must be one of:

 1) public domain
 2) copyrighted, but freely modifiable and redistributable for any purpose
 3) GPL


 


-- 
Justin
http://jcc_7.tripod.com/d/
Jan 22 2004
parent Brad Anderson <brad sankaty.dot.com> writes:
 I'm not a lawyer either, but it seems to me that what you're talking 
 about doing (some sort of port) would be considered a "derivative". 
 Thus, the GUI library itself would have to be open source (the Common 
 Public License in particular).


Yeah, I was going to mention that it would be a derivative work.  I have no 
problem making this library open source.


 "Contributions do not include additions to the Program which: (i) are 
 separate modules of software distributed in conjunction with the Program 
 under their own license agreement, and (ii) are not derivative works of 
 the Program."
 http://www.opensource.org/licenses/cpl.php
 
 But commercial applications ("separate modules") could utilitize this 
 SWT-based library without going open source ("their own license 
 agreement").  


I would think that if they change the code to suit their needs (i.e. a 
derivative work of the original), that they would have to put their changes
back 
in the public domain.  But just using it would be no problem.

We'll most likely need to consult a lawyer if the effort looks like it could be 
feasible and we have momentum...

BA
Jan 22 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bup242$2kgr$1 digitaldaemon.com...






 from below, but I'm not sure why it has to be the GPL.


We need one of the three, not all of them.


 Also, I don't know if we have to use the CPL if we rewrite the entire


thing in D

 code.  We would not be changing/modifying any of their Java code.  We


could

 choose any number of licenses to use.  I would probably just continue on


using

 the CPL, and at the same time, give credit to the original contributors of


the

 SWT Java code as providing us with a framework / starting point.

 But I'm not a lawyer.


Doing a line by line translation of the code makes it a derived work,
subject to the original copyright.
Jan 23 2004
prev sibling parent Andy Friesen <andy ikagames.com> writes:
Walter wrote:

 "Ant" <duitoolkit yahoo.ca> wrote in message
 news:pan.2004.01.21.03.44.02.162329 yahoo.ca...
 

What's the license on SWT?


 
 
 That's the first thing to check. If it doesn't have a compatible license,
 there's no point in looking at it any further. It must be one of:
 
 1) public domain
 2) copyrighted, but freely modifiable and redistributable for any purpose
 3) GPL


I would argue that SWT would be useless to us if it was GPL.  D needs a 
toolkit for everybody, not just open source developers.

(of course, this is a nonissue, as SWT is not GPL)

  -- andy
Jan 22 2004
prev sibling parent reply "Walter" <walter digitalmars.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...

 One reason may be that it's in Java, a language far easier for me to port


to D

 than C++.


I never thought about that. It might even be possible to do machine
translation of Java to D. (Of course, that wouldn't help with the
differences in the underlying runtime libraries, and one has to be careful
that the Java code being translated is public domain or freely
redistributable or GPL.)


  (By the way, we are talking about a port to D, right?


Yes.


  I wouldn't be
 interested in wrapping the Java and requiring a JVM.)


I doubt many would be interested in the results of that, either <g>.
Jan 22 2004
parent reply Ant <Ant_member pathlink.com> writes:
In article <buougc$2f48$1 digitaldaemon.com>, Walter says...

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...

 One reason may be that it's in Java, a language far easier for me to port


to D

 than C++.


I never thought about that. It might even be possible to do machine
translation of Java to D. (Of course, that wouldn't help with the
differences in the underlying runtime libraries,


maybe creating String and Vector classes
(maybe a couple more, Array template class?)
would be easier then doing some complex conversion.
(will D purists complain?)

then just add "alias bit boolean;" and rename to .d,
should compile.

Ant
Jan 22 2004
next sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
It's not quite that easy...  I'm trying to get the interfaces and abstract
class 
calls correct with all of the objects currently (in our port of SWT to D). 
Things like:

    public class Canvas extends Composite {}

becomes

    public class Canvas: Composite {}

and I have no idea what to do with:

    public abstract class Control extends Widget implements Drawable {}

Any thoughts?

BA


Ant wrote:


 In article <buougc$2f48$1 digitaldaemon.com>, Walter says...
 

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...


One reason may be that it's in Java, a language far easier for me to port


to D


than C++.


I never thought about that. It might even be possible to do machine
translation of Java to D. (Of course, that wouldn't help with the
differences in the underlying runtime libraries,


 
 
 maybe creating String and Vector classes
 (maybe a couple more, Array template class?)
 would be easier then doing some complex conversion.
 (will D purists complain?)
 
 then just add "alias bit boolean;" and rename to .d,
 should compile.
 
 Ant
Jan 22 2004
next sibling parent "Carlos Santander B." <carlos8294 msn.com> writes:
"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bupcdr$3v1$1 digitaldaemon.com...
| It's not quite that easy...  I'm trying to get the interfaces and abstract
class
| calls correct with all of the objects currently (in our port of SWT to D).
| Things like:
|
|     public class Canvas extends Composite {}
|
| becomes
|
|     public class Canvas: Composite {}
|
| and I have no idea what to do with:
|
|     public abstract class Control extends Widget implements Drawable {}
|
| Any thoughts?
|
| BA
|

I believe it'd be:

public abstract class Control : Widget , Drawable {}

-----------------------
Carlos Santander Bernal
Jan 22 2004
prev sibling parent Ant <Ant_member pathlink.com> writes:
In article <bupcdr$3v1$1 digitaldaemon.com>, Brad Anderson says...

It's not quite that easy...


you whish... ;)


 I'm trying to get the interfaces and abstract class 
calls correct with all of the objects currently (in our port of SWT to D). 
Things like:

    public class Canvas extends Composite {}

becomes

    public class Canvas: Composite {}

and I have no idea what to do with:

    public abstract class Control extends Widget implements Drawable {}

Any thoughts?


The abstract classes are going to be a problem.
The D abstract classes are still a mistery to me,
I thing the java abstract classes work better.
Other people have reported issues with D abstract classes.

(At the first sign of trouble with abstract classes on 
my D projects I just do an empty implementations of the
methods. That works for small projects, we need real
abstract classes on D.)

I expected abstract classes to be all over...

the "extend, implement" are part of a simple conversion:
`replace all "extends" with ":"`
`replace all "implements" with ","`

of course it's not that simple either (what if there is no "extends")
but that's why we still have a job (the lucky ones)!

I'm dreaming that my leds D parser can easelly be modified to parse
java; then we would say "save as D" :)

Actually I can't think of any java construct that cannot be handled
by my parseD... oh yea: {} static initilization blocks.
And of course the parser is not married to leds.
When I started it it was suppose to be flexible for most "{" languages
but some uggly patches got in...

I was going to review the properties UI on leds today,
maybe I'll look into the parser instead...
(hmmm... if I do the properties UI I can do a usable leds release...)

Ant
(vaporware? like the windows version of leds, sorry...)
http://leds.sourceforge.net
Jan 22 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Ant" <Ant_member pathlink.com> wrote in message
news:bup1eo$2jj6$1 digitaldaemon.com...

 In article <buougc$2f48$1 digitaldaemon.com>, Walter says...

"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:bukd2i$17hb$1 digitaldaemon.com...

 One reason may be that it's in Java, a language far easier for me to






port

to D

 than C++.


I never thought about that. It might even be possible to do machine
translation of Java to D. (Of course, that wouldn't help with the
differences in the underlying runtime libraries,


 maybe creating String and Vector classes
 (maybe a couple more, Array template class?)
 would be easier then doing some complex conversion.
 (will D purists complain?)

 then just add "alias bit boolean;" and rename to .d,
 should compile.


A proper D conversion should at least make the effort to replace the String
class with D char arrays <g>.
Jan 23 2004
prev sibling next sibling parent reply John Reimer <jjreimer telus.net> writes:
Ok, I guess you guys are discussing the possibility of dropping wxWindows
for SWT.  Keep discussing it a little bit more before you do, please.  It
would be nice to see both sides of the argument.  I'll take a peek at SWT
since I have little knowledge of it (other than having played with
Eclipse).  The interface looks good.  It's developed in Java, you say?
Does it have it's own widget set or does it interface to an underlying
platform API? Unfortunately I'm not a Java developer and don't much like
Java. But since there appear to be more people interested in this port
than wxWindows, it's really hard to argue against it.


On Tue, 20 Jan 2004 22:55:31 +0000, Ant wrote:


 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...

2.  I am investigating porting SWT to D to have a GUI that would use
native widgets on the host OS when possible, and implemented widgets
otherwise.  IBM has had great success with this library, its primary use
being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - however I
want a platform-independent GUI without having to distribute GTK+ or any
other library on Win32.


 
 Before you start that maybe you could influence us to change to SWT
 instead of wxWindows. maybe it's better!
 
 we are not married to wxWindows. SWT looks very good actually. As a more
 recent toolkit it has all the probability of being better.
 
 (the wx Project probably will not have a GTK soon. I thought we were going
 to do the native windows and one X11 (or universal) to start with.)
 
 Will you be interested in join us if we change to SWT?
 
 What do you say guys is SWT better then wxWindows (I'm telling you, it
 might be - not that I looked in detail to any... ;)
 
 these projects are huge (unless you have full time for it) so 4/1 is
 better then (3+1)/2.
 
 Ant
Jan 20 2004
parent reply "Matthew" <matthew.hat stlsoft.dot.org> writes:
My undoubtedly unpopular opinion:

I think that the GUI should _never_ be in the standard library, and that
there should _always_ be at least two competing GUI libraries. Otherwise,
stagnation beckons.



"John Reimer" <jjreimer telus.net> wrote in message
news:pan.2004.01.21.02.23.37.232507 telus.net...

 Ok, I guess you guys are discussing the possibility of dropping wxWindows
 for SWT.  Keep discussing it a little bit more before you do, please.  It
 would be nice to see both sides of the argument.  I'll take a peek at SWT
 since I have little knowledge of it (other than having played with
 Eclipse).  The interface looks good.  It's developed in Java, you say?
 Does it have it's own widget set or does it interface to an underlying
 platform API? Unfortunately I'm not a Java developer and don't much like
 Java. But since there appear to be more people interested in this port
 than wxWindows, it's really hard to argue against it.


 On Tue, 20 Jan 2004 22:55:31 +0000, Ant wrote:


 In article <buka0h$12k4$1 digitaldaemon.com>, Brad Anderson says...

2.  I am investigating porting SWT to D to have a GUI that would use
native widgets on the host OS when possible, and implemented widgets
otherwise.  IBM has had great success with this library, its primary use
being Eclipse IDE.  I know this is YAGUI (Yet another GUI) - however I
want a platform-independent GUI without having to distribute GTK+ or any
other library on Win32.


 Before you start that maybe you could influence us to change to SWT
 instead of wxWindows. maybe it's better!

 we are not married to wxWindows. SWT looks very good actually. As a more
 recent toolkit it has all the probability of being better.

 (the wx Project probably will not have a GTK soon. I thought we were




going

 to do the native windows and one X11 (or universal) to start with.)

 Will you be interested in join us if we change to SWT?

 What do you say guys is SWT better then wxWindows (I'm telling you, it
 might be - not that I looked in detail to any... ;)

 these projects are huge (unless you have full time for it) so 4/1 is
 better then (3+1)/2.

 Ant
Jan 20 2004
next sibling parent Ant <duitoolkit yahoo.ca> writes:
On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:


 My undoubtedly unpopular opinion:
 
 I think that the GUI should _never_ be in the standard library,


I thing you're right.

The idea is to create something that would
be widelly used for D GUI development
and that attracts support from many developers.

How is distributed is irrelevant.
If it has quality it will be used
and DM will endorse it.
(hey, even DUI has a link from the D pages ;)


 and that
 there should _always_ be at least two competing GUI libraries.
 Otherwise, stagnation beckons.


You can always start your own;)
(that why I'm gonna start the D++ project
it's a joke)

DUI is here to stay, don't worry.
Already has (almost complete) support to Linux and Windows.
(but still is going to have a major change on the
event processing)

Ant

http://dui.sourceforge.net
Jan 20 2004
prev sibling next sibling parent John Reimer <jjreimer telus.net> writes:
On Wed, 21 Jan 2004 15:00:16 +1100, Matthew wrote:


 My undoubtedly unpopular opinion:
 
 I think that the GUI should _never_ be in the standard library, and that
 there should _always_ be at least two competing GUI libraries. Otherwise,
 stagnation beckons.
 
 


The GUI in the standard library? I don't think that was our intention. I
may have slipped and made it sound that way earlier. All we want to do is
make a good crossplatform GUI toolkit for D. Where it goes can be decided
later. I guess some competition would be very good, yes. But at this point
there aren't an over abundance of developers to try developing
different GUI toolkits. One good solid kit would be nice for now with
several people contributing.  Otherwise, we still have DUI and
DIG.

Our main goal, so I thought, was to develop a comprehensive,
well-supported, crossplatform library for D, something it does not have at
the moment (DUI comes closest).  This library could, at some point
perhaps, be included as an extra with the compiler suite (it doesn't have
t be THE standard library, though). This library should provide an
interface that should compile without changes on either platform.
wxWindows almost achieves this goal for C++. That's why it was one of my
first interests as a port. But C++ does not translate well to D, so it may
not be a wise initial task to take on.  Not without experienced help at
least.  I may play with it a bit behind the scenes for interest sake, but
I still want to see a main GUI project come to fruition.

Later,

John
Jan 20 2004
prev sibling next sibling parent Georg Wrede <Georg_member pathlink.com> writes:
In article <buktia$212c$1 digitaldaemon.com>, Matthew says...

My undoubtedly unpopular opinion:


Er, let's change that to 'controversial'. :-)


I think that the GUI should _never_ be in the standard library, and that
there should _always_ be at least two competing GUI libraries. Otherwise,
stagnation beckons.


You're absolutely right, on both accounts.

However, we do need a gui that comes with at least Digital Mars D,
and which has precisely the same API on both Windows and Linux.
And, while DMD is not Open Source, the GUI should be. (I think Walter
would okay this?)

As to stagnation, while you're right there too, I think it is a matter
of _perceived_ competition. For the time being, the D community 
perceives other languages that have GUI libraries, as competition.
Later, when D gets established, stagnation becomes a risk unless
we then have more than one GUI.

Also, we do not have to, and actually should not, divide our powers
between GUIs right now! We are too few to pull it off.

If all goes like we wish, then by this time next year, D has a
large enough following that we will see another port emerge anyhow.
This would give us more than one good, working, GUI by the time any 
risk for GUI stagnation would emerge.
Jan 21 2004
prev sibling parent "Walter" <walter digitalmars.com> writes:
"Matthew" <matthew.hat stlsoft.dot.org> wrote in message
news:buktia$212c$1 digitaldaemon.com...

 My undoubtedly unpopular opinion:

 I think that the GUI should _never_ be in the standard library,


I agree. That said, I still think a GUI should ship with D as an add-on.


 and that
 there should _always_ be at least two competing GUI libraries. Otherwise,
 stagnation beckons.


As many as D users want to create!

The thing SWT may have going for it over wxWindows is it may be far easier
to do a D conversion of it. I looked over the wxWindows source, and while
fortunately it doesn't mire itself in weird C++-isms, it will require a lot
of hand work. The conversion of memory management to garbage collection
comes to mind, along with being careful not to goof up other resource
management.
Jan 22 2004
prev sibling parent reply Ilya Minkov <minkov cs.tum.edu> writes:
Ant wrote:

 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)


Ur, what? wxWindows compiles using DMC++, and there were plans on 
wrapping it using SWIG. This would make all wxWindows ports available at 
once and with no effort. Wrapping instead of porting.

Btw, to drop an idea: to have a lightweight GUI working right off and 
easy to port, FLTK has the best architecture and shoud be a snap to port 
*completely*. However, it's by its sole idea program-drawn, not OS or 
underlying toolkit! Skinning is done easily, attempts to "native" look 
are bound to have "the Swing problem" multiplied by 10!

-eye
Jan 23 2004
parent Ant <Ant_member pathlink.com> writes:
In article <burnut$vst$1 digitaldaemon.com>, Ilya Minkov says...

Ant wrote:

 (the wx Project probably will not have a GTK soon.
 I thought we were going to do the native windows and one X11
 (or universal) to start with.)


Ur, what?


Out of context. I meant "our" wx project.
But after all seems that's the most recent idea is to wrap
GTK in SWT talk.


Btw, to drop an idea: to have a lightweight GUI working right off and 
easy to port, FLTK has the best architecture and shoud be a snap to port 
*completely*. However, it's by its sole idea program-drawn, not OS or 
underlying toolkit! Skinning is done easily, attempts to "native" look 
are bound to have "the Swing problem" multiplied by 10!


There are many toolkits out there...
probable more toolkits then people able to work on them on D.

Ant
Jan 23 2004
prev sibling parent reply "Kris" <someidiot earthlink.net> writes:
A couple of years back I wrote a standalone Java servlet-server; totally
secure and faster than anything else available. I've been thinking about
porting this to D (perhaps using the OpenD.org Sockets package), if there's
not already something similar?

What do you think -- a servlet-style HTTP server in D, for D?

- Kris


"C" <dont respond.com> wrote in message
news:btnk5a$2hrc$1 digitaldaemon.com...

 I was just wondering what everyone else is working on.  I think it would


be

 cool to have a refrence , so were not duplicating each other and stuff :).

 Im working on Windy as you might know ( GUI toolkit ).  I'm also going to
 start a mysql module soon.

 You guys ?

 C
Feb 20 2004
next sibling parent "Matthew" <matthew.hat stlsoft.dot.org> writes:
Excellent! Do it.

I'll be happy to review it when you're done.




"Kris" <someidiot earthlink.net> wrote in message
news:c1646d$164u$1 digitaldaemon.com...

 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if


there's

 not already something similar?

 What do you think -- a servlet-style HTTP server in D, for D?

 - Kris


 "C" <dont respond.com> wrote in message
 news:btnk5a$2hrc$1 digitaldaemon.com...

 I was just wondering what everyone else is working on.  I think it would


 be

 cool to have a refrence , so were not duplicating each other and stuff




:).

 Im working on Windy as you might know ( GUI toolkit ).  I'm also going




to

 start a mysql module soon.

 You guys ?

 C
Feb 20 2004
prev sibling parent reply Brad Anderson <brad sankaty.dot.com> writes:
Kris wrote:

 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if there's
 not already something similar?
 
 What do you think -- a servlet-style HTTP server in D, for D?


<drool>

I think this would be fantastic project.  I'd like to help, but I'm busy on 
other things at the moment.  I will, however, join Matthew in offering review 
and testing.

D Server Pages or DSP

</drool>
Feb 21 2004
parent reply "Kris" <someidiot earthlink.net> writes:
DSP huh?  Funny, I was (ESP) thinking the same thing .... that's a cool name
Brad :-)

Didn't Nicholas Wirth once say "designing a Language is easy, but coming up
with a great name is really hard" ?

- Kris


"Brad Anderson" <brad sankaty.dot.com> wrote in message
news:c18vgh$9tr$1 digitaldaemon.com...

 Kris wrote:

 A couple of years back I wrote a standalone Java servlet-server; totally
 secure and faster than anything else available. I've been thinking about
 porting this to D (perhaps using the OpenD.org Sockets package), if




there's

 not already something similar?

 What do you think -- a servlet-style HTTP server in D, for D?


 <drool>

 I think this would be fantastic project.  I'd like to help, but I'm busy


on

 other things at the moment.  I will, however, join Matthew in offering


review

 and testing.

 D Server Pages or DSP

 </drool>
Feb 22 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
Yeah, I'm really *original*.  All by myself, I came up with the name for the 
port of SWT to D:  dwt

I think I've found my calling :D  - Anyone else out there need a name for their 
project?  Bring it on.

BA

Kris wrote:


 DSP huh?  Funny, I was (ESP) thinking the same thing .... that's a cool name
 Brad :-)
 
 Didn't Nicholas Wirth once say "designing a Language is easy, but coming up
 with a great name is really hard" ?
 
 - Kris
 
 
 "Brad Anderson" <brad sankaty.dot.com> wrote in message
 news:c18vgh$9tr$1 digitaldaemon.com...
 

Kris wrote:


A couple of years back I wrote a standalone Java servlet-server; totally
secure and faster than anything else available. I've been thinking about
porting this to D (perhaps using the OpenD.org Sockets package), if




 
 there's
 

not already something similar?

What do you think -- a servlet-style HTTP server in D, for D?


<drool>

I think this would be fantastic project.  I'd like to help, but I'm busy


 
 on
 

other things at the moment.  I will, however, join Matthew in offering


 
 review
 

and testing.

D Server Pages or DSP

</drool>
Feb 22 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:


 Yeah, I'm really *original*.  All by myself, I came up with the name for 
 the port of SWT to D:  dwt
 
 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.
 
 BA


Ben Hinkle is looking for a name to his compiler that hooks up to GCC: 
http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462.

I think there have been some good suggestion so far, but he hasn't named 
a winner yet.

-- 
Justin
http://jcc_7.tripod.com/d/
Feb 22 2004
parent reply Brad Anderson <brad sankaty.dot.com> writes:
J C Calvarese wrote:


 Brad Anderson wrote:
 

 Yeah, I'm really *original*.  All by myself, I came up with the name 
 for the port of SWT to D:  dwt

 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.

 BA


 
 
 Ben Hinkle is looking for a name to his compiler that hooks up to GCC: 
 http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462.
 
 I think there have been some good suggestion so far, but he hasn't named 
 a winner yet.
 


I've been watching, but you've taken all of the ones I might have used.  I'm 
such a blatant acronym whore.
Feb 22 2004
parent reply J C Calvarese <jcc7 cox.net> writes:
Brad Anderson wrote:

 J C Calvarese wrote:

 Brad Anderson wrote:




[snip]

 I think I've found my calling :D  - Anyone else out there need a name 
 for their project?  Bring it on.

 BA


 Ben Hinkle is looking for a name to his compiler that hooks up to GCC: 
 http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462.

 I think there have been some good suggestion so far, but he hasn't 
 named a winner yet.


 
 I've been watching, but you've taken all of the ones I might have used.  
 I'm such a blatant acronym whore.


I think the challenge is threefold:

1. There's an obvious reluctance to reuse an existing name or a name 
that's too similar (can we call it "dig"? D Interface to GCC).

2. The desire for shortness (who wants to type "OPENSOURCEDFRONTTOGCC" 
to invoke their favorite compiler?).

3. A sensical name is better than nonsense (let's call it "marmalade" 
just because it's fun to say).

-- 
Justin
http://jcc_7.tripod.com/d/
Feb 22 2004
parent C <dont respond.com> writes:
On Sun, 22 Feb 2004 13:13:55 -0600, J C Calvarese <jcc7 cox.net> wrote:

Marmalade IS fun to say!  I change my vote.

C


 Brad Anderson wrote:

 J C Calvarese wrote:

 Brad Anderson wrote:




 [snip]

 I think I've found my calling :D  - Anyone else out there need a na=








me =


 for their project?  Bring it on.

 BA


 Ben Hinkle is looking for a name to his compiler that hooks up to GC=






C: =


 http://www.digitalmars.com/drn-bin/wwwnews?D.gnu/462.

 I think there have been some good suggestion so far, but he hasn't =







 named a winner yet.


 I've been watching, but you've taken all of the ones I might have =





 used.  I'm such a blatant acronym whore.


 I think the challenge is threefold:

 1. There's an obvious reluctance to reuse an existing name or a name =



 that's too similar (can we call it "dig"? D Interface to GCC).

 2. The desire for shortness (who wants to type "OPENSOURCEDFRONTTOGCC"=


 =


 to invoke their favorite compiler?).

 3. A sensical name is better than nonsense (let's call it "marmalade" =



 just because it's fun to say).




-- =

Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/
Feb 22 2004