• Achilleas Margaritis (6/6) Sep 05 2003 I found an article about component programming that I completely agree w...
• Charles Sanders (8/14) Sep 05 2003 I see all this talk of signals and slots, cant these things be implement...
• Jotham (6/9) Sep 06 2003 If something is "implemented really easily", the fact that you can do so...
• Andy Friesen (3/17) Sep 06 2003 Sounds like all we need is for a slot template to be added to Phobos.
• Daniel Yokomiso (39/53) Sep 06 2003 with.
• Jeroen van Bemmel (1/3) Sep 06 2003 I tend to disagree here. What is the basis for this statement?
• Achilleas Margaritis (6/9) Sep 08 2003 The amount of articles and internet "noise" around the subject. From rea...
• Ilya Minkov (8/12) Sep 08 2003 Just look at MONO and DOTNET - this projets got a boost hardly
• Matthew Wilson (5/7) Sep 08 2003 I agree with this. No-one really kids themselves that Java's efficient o...
• Riccardo De Agostini (11/14) Sep 09 2003 is
• Achilleas Margaritis (7/21) Sep 09 2003 D will make it on the available libraries. .NET is an attractive proposi...
• Matthew Wilson (6/32) Sep 09 2003 "market"
• Achilleas Margaritis (20/55) Sep 09 2003 "destructor")
• Matthew Wilson (20/49) Sep 09 2003 D has the advantage of being able to talk directly to C.
• Daniel Yokomiso (31/53) Sep 09 2003 [snip]
• Achilleas Margaritis (19/75) Sep 10 2003 One year ? two years ? already late!!!
• Ilya Minkov (5/9) Sep 10 2003 Would you also be available to help write a C header -> D import convert...
• Benji Smith (21/29) Sep 10 2003 The D Repository website is very close to being finished. I just posted ...
• Ilya Minkov (6/9) Sep 10 2003 Frankly, i cannot think out anything else to wish. :)
• Daniel Yokomiso (53/110) Sep 11 2003 ----- Original Message -----
• Matthew Wilson (4/9) Sep 11 2003 projects,
• Achilleas Margaritis (60/175) Sep 11 2003 I disagree with you. Read on:
• Daniel Yokomiso (34/58) Sep 13 2003 [snip]
• Walter (9/18) Sep 17 2003 are
• Mark T (3/19) Sep 17 2003 Do you mean a cross platform GUI? Why not a Java based one like SWT (wh...
• Walter (9/29) Sep 17 2003 have
• Benji Smith (10/14) Sep 17 2003 I agree 100%.
• Ant (16/30) Sep 17 2003 Maybe it's time to make a conversion tool.
• Walter (6/21) Sep 18 2003 I wonder if it all needs to be converted for a first pass. After all, D ...
• Walter (2/2) Sep 18 2003 Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc...
• Andy Friesen (6/8) Sep 18 2003 !
• Benji Smith (13/16) Sep 18 2003 I've just spent the last 20 minutes or so reading up about swig (
• Ant (8/18) Sep 18 2003 You're probably right. It might be the second most important ever for D
• BenjiSmith (16/17) Sep 18 2003 1) Because I'm not up to the job myself. I'm not a competent enough C/C+...
• Ant (7/24) Sep 18 2003 3 very good reasons! but not good enough :)
• Benji Smith (21/21) Sep 18 2003 Holy cow. I just downloaded the SWIG sources and I've been looking aroun...
• Walter (17/38) Sep 18 2003 Cool! Also, let's start a new thread on this!
• Walter (15/25) Sep 18 2003 take
• Benji Smith (15/20) Sep 18 2003 I'm glad to hear that the language is stable enough for this type of wor...
• Benij Smith (16/21) Sep 18 2003 I got a reply (already!) to the email that I sent to this guy. According...
• Walter (13/24) Sep 18 2003 creating
• Walter (9/22) Sep 18 2003 other
• Walter (28/43) Sep 17 2003 Walter)
• Matthew Wilson (3/8) Sep 17 2003 There should only ever have been one reworking of the iostreams, and I t...
• Walter (6/14) Sep 17 2003 woefully
• Matthew Wilson (4/18) Sep 17 2003 The iostream include I would be looking for would involve no characters ...
• Sean L. Palmer (37/48) Sep 19 2003 ----- Original Message -----
• Matthew Wilson (13/22) Sep 17 2003 things
• Walter (11/21) Sep 17 2003 Write me a brief text, and I'll update it with that text. And that goes ...
• Matthew Wilson (9/31) Sep 17 2003 Well, that'll teach me! I thought I was writing an email.
• Daniel Yokomiso (7/9) Sep 17 2003 But can you do it... with... a herring?
• Walter (3/8) Sep 17 2003 Monty Python?
• Felix (17/17) Sep 17 2003 Hi,
• Matthew Wilson (22/41) Sep 18 2003 There is a good, though not great, basis in the language for component
• Felix (3/46) Sep 18 2003 Thanks for answers. Forget the last issues in my message. Maybe I am too...
• Mike Wynn (6/17) Sep 18 2003 my code for imbedding an instance of MSIE in a D window (using my win32
• Daniel Yokomiso (8/18) Sep 18 2003 and
• Olaf Rogalsky (9/13) Oct 02 2003 I like your sig :-)
• Jeroen van Bemmel (20/23) Sep 06 2003 with.

"Achilleas Margaritis" <axilmar b-online.gr> writes:

I found an article about component programming that I completely agree with.
Here it is:

http://www.artima.com/intv/simplexity.html

First class support for properties, delegates, signals and slots will open a

becomes the most preferred programming language around the globe.

"Charles Sanders" <sanders-consulting comcast.net> writes:

I see all this talk of signals and slots, cant these things be implemented
really easily ?  Im not sure I see any merit it making it part of the
language.

Charles
"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

with.
 Here it is:

 http://www.artima.com/intv/simplexity.html

 First class support for properties, delegates, signals and slots will open

a

 becomes the most preferred programming language around the globe.

Jotham <jotham ourbrisbane.com> writes:

Charles Sanders wrote:
 I see all this talk of signals and slots, cant these things be implemented
 really easily ?  Im not sure I see any merit it making it part of the
 language.

If something is "implemented really easily", the fact that you can do so 
should not need to be phrased as a question.

I think the article makes some excellent points.  Simplicity for me is 
not when its easy for me to do, but when its easy for someone else to 
understand and use straight away.

Andy Friesen <andy ikagames.com> writes:

Jotham wrote:

 Charles Sanders wrote:
 
 I see all this talk of signals and slots, cant these things be 
 implemented
 really easily ?  Im not sure I see any merit it making it part of the
 language.

 
 
 If something is "implemented really easily", the fact that you can do so 
 should not need to be phrased as a question.
 
 I think the article makes some excellent points.  Simplicity for me is 
 not when its easy for me to do, but when its easy for someone else to 
 understand and use straight away.

Sounds like all we need is for a slot template to be added to Phobos.

  -- andy

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Achilleas Margaritis" <axilmar b-online.gr> escreveu na mensagem
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

with.
 Here it is:

 http://www.artima.com/intv/simplexity.html

 First class support for properties, delegates, signals and slots will open

a

 becomes the most preferred programming language around the globe.

Using your example (from other thread) I don't see why signals and slots
should be part of the language, but I see why implicit template
instantiation is desirable. Your example was:


 class Window {
     public signal onMouseMove(Event &event);
 }

 class Button {
     public slot mouseMoved(Event &event);
 }

 Button btn;
 btn.onMouseMove += mouseMoved;


With implicit template instantiation you could write:


class Window {
    public Signal onMouseMove = ...;
}

class Button {
    public Slot mouseMoved = ...;
}

Button btn;
btn.onMouseMove ~= mouseMoved;


and everything should work ok (I use ~= instead of += because it's D way of
appending to a data structure). Today with explicit template instantiation
we need some more keywords:


class Window {
    private alias instance TSignal(Event).Signal Signal;
    public Signal onMouseMove;
}

class Button {
    private alias instance TSlot(Event).Slot Slot;
    public Slot mouseMoved;
}

Button btn;
btn.onMouseMove ~= mouseMoved;


With implicit instatiation the compiler should be able to figure out the
template parameter "Event" on the body of the "onMouseMove" and "mouseMoved"
declarations (essentially delegates).

    Best regards,
    Daniel Yokomiso.

"Daddy, why doesn't this magnet pick up this floppy disk?"


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 29/8/2003

"Jeroen van Bemmel" <someone somewhere.com> writes:

 becomes the most preferred programming language around the globe.

I tend to disagree here. What is the basis for this statement?

"Achilleas Margaritis" <axilmar in.gr> writes:

"Jeroen van Bemmel" <someone somewhere.com> wrote in message
news:bjclpp$1vvr$1 digitaldaemon.com...

 becomes the most preferred programming language around the globe.

 I tend to disagree here. What is the basis for this statement?

The amount of articles and internet "noise" around the subject. From reading
newsgroups, message boards and articles I highly get the impression that

in my hand, nor I imply that it is the most used development environment.

Ilya Minkov <minkov cs.tum.edu> writes:

Achilleas Margaritis wrote:
 The amount of articles and internet "noise" around the subject. From reading
 newsgroups, message boards and articles I highly get the impression that

 in my hand, nor I imply that it is the most used development environment.

Just look at MONO and DOTNET - this projets got a boost hardly 
comparable with any other compiler development effort out there!


around...


to a further extent than C++ and certainly more than Java.

-eye

"Matthew Wilson" <matthew stlsoft.org> writes:

 to a further extent than C++ and certainly more than Java.

I agree with this. No-one really kids themselves that Java's efficient on
Win32. And few C++ people (myself included) think that D is a rival. I see D
as being primarily a better .NET, though not 100%. Probably its "market" is
20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of course.
;) )

"Riccardo De Agostini" <riccardo.de.agostini email.it> writes:

"Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its "market"

is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

course.

With properties (including static ones, of course), constructors and
destructors being called by their name ("constructor" and "destructor")
instead of the C++ way, plus an IDE and a standard library, D may even
attract current Delphi users...

(...and with a little tomato ketchup on it, it may even be a threat to
McDonald's... :-) )

Ric

"Achilleas Margaritis" <axilmar in.gr> writes:

"Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its "market"

 is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

 course.

 With properties (including static ones, of course), constructors and
 destructors being called by their name ("constructor" and "destructor")
 instead of the C++ way, plus an IDE and a standard library, D may even
 attract current Delphi users...

 (...and with a little tomato ketchup on it, it may even be a threat to
 McDonald's... :-) )

 Ric

D will make it on the available libraries. .NET is an attractive proposition
because of its vast arrays of libraries. Especially for the GUI. The same
situation is with Java, plus the fact "write once, run everywhere".

What good does a super programming library like D makes, if there is no
standard libraries to work with ?

"Matthew Wilson" <matthew stlsoft.org> writes:

"Achilleas Margaritis" <axilmar in.gr> wrote in message
news:bjk4i8$nbk$1 digitaldaemon.com...
 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its



"market"
 is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

 course.

 With properties (including static ones, of course), constructors and
 destructors being called by their name ("constructor" and "destructor")
 instead of the C++ way, plus an IDE and a standard library, D may even
 attract current Delphi users...

 (...and with a little tomato ketchup on it, it may even be a threat to
 McDonald's... :-) )

 Ric

 D will make it on the available libraries. .NET is an attractive

proposition
 because of its vast arrays of libraries. Especially for the GUI. The same
 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is no
 standard libraries to work with ?

Well none, but the implied suggestion in your question, i.e. that none will
be forthcoming, is erroneous.

"Achilleas Margaritis" <axilmar in.gr> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bjkoth$1kek$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> wrote in message
 news:bjk4i8$nbk$1 digitaldaemon.com...
 "Riccardo De Agostini" <riccardo.de.agostini email.it> wrote in message
 news:bjjv11$f8b$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> ha scritto nel messaggio
 news:bjj6h8$2c34$1 digitaldaemon.com...
 [...] I see D
 as being primarily a better .NET, though not 100%. Probably its



 "market"
 is
 20% C, 20% C++, 50% .NET, 10% Java. (But that's only my opinion, of

 course.

 With properties (including static ones, of course), constructors and
 destructors being called by their name ("constructor" and



"destructor")
 instead of the C++ way, plus an IDE and a standard library, D may even
 attract current Delphi users...

 (...and with a little tomato ketchup on it, it may even be a threat to
 McDonald's... :-) )

 Ric

 D will make it on the available libraries. .NET is an attractive

 proposition
 because of its vast arrays of libraries. Especially for the GUI. The


same
 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is no
 standard libraries to work with ?

 Well none, but the implied suggestion in your question, i.e. that none

will
 be forthcoming, is erroneous.

No, I did not imply that there will be no libraries. There will be, but the
questions are:

1) when ?


difficult is to get rid of a legacy language, with millions of lines of
source code behind them.

2) how good will they be ?

    Will the open source community have the resources to pull this off ? is
the open source community a match for the big workforce of companies like
Microsoft or Sun ? especially in a limited time period from one release to
another ?

3) will they be cross platform ?

    Most companies would like their apps to run both in the Windows and
Linux environment. Java is preferrable for this reason by a large
percentage.

"Matthew Wilson" <matthew stlsoft.org> writes:

 D will make it on the available libraries. .NET is an attractive

 proposition
 because of its vast arrays of libraries. Especially for the GUI. The


 same
 situation is with Java, plus the fact "write once, run everywhere".

 What good does a super programming library like D makes, if there is



no
 standard libraries to work with ?

 Well none, but the implied suggestion in your question, i.e. that none

 will
 be forthcoming, is erroneous.

 No, I did not imply that there will be no libraries. There will be, but

the
 questions are:

 1) when ?


 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.

D has the advantage of being able to talk directly to C.

Of course, .NET and Java have enormous (though often badly designed)
libraries. D has a big hill to climb, there's no denying that.

 2) how good will they be ?

     Will the open source community have the resources to pull this off ?

is
 the open source community a match for the big workforce of companies like
 Microsoft or Sun ? especially in a limited time period from one release to
 another ?

Dunno. I have this same concern myself.

We desperately need some kind of libraries group to ensure it all does not
become a wild-woman's knitting. I think it can be done - we recently had a
good debate about exceptions/errors, which ended with a pretty good
concensus.

IMO D needs to provide a small set of essential libraries, all well
designed, which can act as the basis for, and examples to, the development
of third-party libraries, in much the same way that Java packages by
3rd-party vendors have become de-facto standard (e.g. those of Apache).

 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

I think D can do well here. There's nothing stopping things being
cross-platform, but it's also good to be able to have platform-specific
code, which Java does not (apart from costly JNI calls)


But your basic thesis is correct. There's a huge amount of work waiting to
happen. We need some early libraries to set the examples.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
news:bjkrm2$1og0$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjkoth$1kek$1 digitaldaemon.com...

[snip]

 Well none, but the implied suggestion in your question, i.e. that none

 will
 be forthcoming, is erroneous.

 No, I did not imply that there will be no libraries. There will be, but

the
 questions are:

 1) when ?


Real Soon Now ;)



 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.


When Java started people said that about C++. Java won.


 2) how good will they be ?


Probably better than Java. At least we have DbC in the language so the
operation's contracts won't be just some fancy documentation.


     Will the open source community have the resources to pull this off ?

is
 the open source community a match for the big workforce of companies like
 Microsoft or Sun ? especially in a limited time period from one release to
 another ?


People said the same about GNU/Linux, *BSD, etc. Time proved that the
community can beat companies. Also Sun and Microsoft have very large release
schedules, usually more than one year, while the Open Source is release
early, release often.


 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

That will depend on three things: conforming compilers, reliance on embedded
asm and linked libraries. I would bet that the portability problems will be
few, specially when we can create contract layers around plataform
dependent, so a new release will be tested in the available plataforms and
most bugs will appear on the test builds.

<rant>
People should stop posting about lack of libraries in D and start coding
them. It's been almost a year since I released DTL 0.0.1, and I know there's
no excuse for my lack of work in the library, but since then nobody come
with another such library, just discussed about how they should look.
</rant>

    Best regards,
    Daniel Yokomiso.

"(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Achilleas Margaritis" <axilmar in.gr> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...
 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bjkoth$1kek$1 digitaldaemon.com...

 [snip]

 Well none, but the implied suggestion in your question, i.e. that none

 will
 be forthcoming, is erroneous.

 No, I did not imply that there will be no libraries. There will be, but

 the
 questions are:

 1) when ?


 Real Soon Now ;)

One year ? two years ? already late!!!


 difficult is to get rid of a legacy language, with millions of lines of
 source code behind them.


 When Java started people said that about C++. Java won.

But C++ did not have standard libraries like Swing that work in any
platform.

 2) how good will they be ?


 Probably better than Java. At least we have DbC in the language so the
 operation's contracts won't be just some fancy documentation.


     Will the open source community have the resources to pull this off ?

 is
 the open source community a match for the big workforce of companies


like
 Microsoft or Sun ? especially in a limited time period from one release


to
 another ?


 People said the same about GNU/Linux, *BSD, etc. Time proved that the
 community can beat companies. Also Sun and Microsoft have very large

release
 schedules, usually more than one year, while the Open Source is release
 early, release often.

But OSS people have a motive to code for Linux and BSD. And it took 11 years
for Linux to reach the current status. And it lacks several things Windows
has, especially on the usability front.

 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

 That will depend on three things: conforming compilers, reliance on

embedded
 asm and linked libraries. I would bet that the portability problems will

be
 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms and
 most bugs will appear on the test builds.

The important compatibility is at source code level, not at binary level.

 <rant>
 People should stop posting about lack of libraries in D and start coding
 them. It's been almost a year since I released DTL 0.0.1, and I know

there's
 no excuse for my lack of work in the library, but since then nobody come
 with another such library, just discussed about how they should look.
 </rant>

Most definitely they should. I am available. We need to form a group, a
coordinator...we need a virtual meeting room where we can discuss
ideas...there is a lot of things to be done on the organizational front that
I don't know anything about (and I am not willing to do).

     Best regards,
     Daniel Yokomiso.

 "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

Ilya Minkov <minkov cs.tum.edu> writes:

Achilleas Margaritis wrote:

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front that
 I don't know anything about (and I am not willing to do).

Would you also be available to help write a C header -> D import converter?

BTW, we really need a sourceforge-like community website! Wasn't there 
anyone who just promised to get one running a few weeks ago?

-eye.

Benji Smith <dlanguage xxagg.com> writes:

In article <bjnjdk$2iqc$1 digitaldaemon.com>, Ilya Minkov says...
Achilleas Margaritis wrote:

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front that
 I don't know anything about (and I am not willing to do).

Would you also be available to help write a C header -> D import converter?

BTW, we really need a sourceforge-like community website! Wasn't there 
anyone who just promised to get one running a few weeks ago?

The D Repository website is very close to being finished. I just posted another
thread with more details about completion dates and testing schedules and stuff
like that, but I didn't mention much about features in that other thread, so I
should mention here that each project in the new site will have its own:

- source code repository
- download area
-  (for binary files, docs, archives, and for people without
a subversion repository client)
- bug tracking database
- customizable web area at http://projectname.xxxxxxx.com or
http://xxxxxxx.com/project/projectname (I'm not telling anyone the main site
domain yet; that's why I used xxxxxxx)
- discussion forum

The software that will be in use at the new site will be the G-Forge code. It's
an open-source branch of the SourceForge code. You can read more about it at
http://gforge.org . I'm making a few customizations to the code (so that it can
connect to svn rather than cvs) but nothing major. I'll also be changing the
template, so that our site will have its own look-and-feel. Over time, I may add
other features to the code, by popular demand. For now, the features will be
exactly the same as what's offered in the default gforge installation.

Ilya Minkov <minkov cs.tum.edu> writes:

Benji Smith wrote:
 The D Repository website is very close to being finished.

Thanks!

 For now, the features will be exactly the same as what's offered in
 the default gforge installation.

Frankly, i cannot think out anything else to wish. :)

I'm not of any help with software, but i could do design or something... 
Never mind if you're ready with that. :)

-eye

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

----- Original Message ----- 
From: "Achilleas Margaritis" <axilmar in.gr>
Newsgroups: D
Sent: Wednesday, September 10, 2003 4:48 AM
Subject: Re: The importance of component programming (properties, signals
and slots, etc)


 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...


[snip]

 1) when ?

 Real Soon Now ;)

 One year ? two years ? already late!!!



So, what's your point? We're doomed, destined to failure ;)






how
 difficult is to get rid of a legacy language, with millions of lines



of
 source code behind them.

 When Java started people said that about C++. Java won.

 But C++ did not have standard libraries like Swing that work in any
 platform.


It's true, but there were "millions of lines of source code behind them"
written in C++. People moved on no matter what. Also C++ has several GUI
libraries, so I don't bite this "holy grail of Swing".

[snip]

     Will the open source community have the resources to pull this off



?
 is
 the open source community a match for the big workforce of companies


 like
 Microsoft or Sun ? especially in a limited time period from one



release
 to
 another ?


 People said the same about GNU/Linux, *BSD, etc. Time proved that the
 community can beat companies. Also Sun and Microsoft have very large

 release
 schedules, usually more than one year, while the Open Source is release
 early, release often.

 But OSS people have a motive to code for Linux and BSD. And it took 11

years
 for Linux to reach the current status. And it lacks several things Windows
 has, especially on the usability front.



Again, what's your point?


 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows



and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

 That will depend on three things: conforming compilers, reliance on

 embedded
 asm and linked libraries. I would bet that the portability problems will

 be
 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms


and
 most bugs will appear on the test builds.

 The important compatibility is at source code level, not at binary level.



I don't understand what are you trying to say here. What is "source code
level"? Conforming compilers? Platform dependent APIs?


 <rant>
 People should stop posting about lack of libraries in D and start coding
 them. It's been almost a year since I released DTL 0.0.1, and I know

 there's
 no excuse for my lack of work in the library, but since then nobody come
 with another such library, just discussed about how they should look.
 </rant>

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front

that
 I don't know anything about (and I am not willing to do).


The open source developement model has lots of projects with maintainers and
contributors. Period. We don't need no "coordinator", nor "a virtual meeting
room". We have IRC and CVS (or whatever). Now we need people interested in
writing code in D. People code, publish the CVS tree, contributors submit
patches and maintainers either accept or reject. Someday we'll need to
integrate two projects and then people will talk (IRC, email, usenet).
Everything else is crap. Code matters. Working, tested, reliable code. And
documentation. Note that I'm not in rant mode.

If Walter waited to form this newsgroup then listened to everyone talking
and discussing on how D should be then formed working groups to come with
proposals then waited for voting then published a spec then started
implementing, I (and most of the people here, if not all, including Walter)
would be elsewhere, doing something else. Instead he banged out a compiler,
released it, formed a newsgroup, listened to people (ignored most of them
;), modified and patched, and rinse and recycle. It works, people are happy
with D. But it is still an infant (pre 1.0 yet, thank god for Walter not
rushing it), so we won't have a large user base. What we need is to test it,
try it, complain about something (templates anyone? ;) and see the changes.
We need code and binaries to make it happen (or else we couldn't test), the
same thing with libraries. We need working libraries to see what is good and
what is crap, else we'll over-engineer it. Java libraries are
over-engineered, they wrote all of them before someone used it in projects,
and we don't need to follow that model.


    Best regards,
    Daniel Yokomiso.

"If you want to be happy be."


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Matthew Wilson" <matthew stlsoft.org> writes:

 We need code and binaries to make it happen (or else we couldn't test),

the
 same thing with libraries. We need working libraries to see what is good

and
 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

projects,
 and we don't need to follow that model.

Heartily agreed

"Achilleas Margaritis" <axilmar in.gr> writes:

I disagree with you. Read on:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjpjs7$2bsh$1 digitaldaemon.com...
 ----- Original Message -----
 From: "Achilleas Margaritis" <axilmar in.gr>
 Newsgroups: D
 Sent: Wednesday, September 10, 2003 4:48 AM
 Subject: Re: The importance of component programming (properties, signals
 and slots, etc)


 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjlr65$4fg$1 digitaldaemon.com...
 "Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
 news:bjkrm2$1og0$1 digitaldaemon.com...


 [snip]

 1) when ?

 Real Soon Now ;)

 One year ? two years ? already late!!!



 So, what's your point? We're doomed, destined to failure ;)

Basically, yes. Except if libraries are available real soon. (that's my
opinion, please respect it. I don't want a flame war).





 how
 difficult is to get rid of a legacy language, with millions of lines



 of
 source code behind them.

 When Java started people said that about C++. Java won.

 But C++ did not have standard libraries like Swing that work in any
 platform.


 It's true, but there were "millions of lines of source code behind them"
 written in C++. People moved on no matter what. Also C++ has several GUI
 libraries, so I don't bite this "holy grail of Swing".

C++ does not have any open source cross platform GUI library. The only cross
platform library that I know of is Qt. WxWindows is not a trustworthy
solution yet.

 [snip]

     Will the open source community have the resources to pull this




off
 ?
 is
 the open source community a match for the big workforce of companies


 like
 Microsoft or Sun ? especially in a limited time period from one



 release
 to
 another ?


 People said the same about GNU/Linux, *BSD, etc. Time proved that the
 community can beat companies. Also Sun and Microsoft have very large

 release
 schedules, usually more than one year, while the Open Source is



release
 early, release often.

 But OSS people have a motive to code for Linux and BSD. And it took 11

 years
 for Linux to reach the current status. And it lacks several things


Windows
 has, especially on the usability front.



 Again, what's your point?

My point is that if there are no cross-platform standard libraries for GUI
and other stuff, D won't succeed.

 3) will they be cross platform ?

     Most companies would like their apps to run both in the Windows



 and
 Linux environment. Java is preferrable for this reason by a large
 percentage.

 That will depend on three things: conforming compilers, reliance on

 embedded
 asm and linked libraries. I would bet that the portability problems



will
 be
 few, specially when we can create contract layers around plataform
 dependent, so a new release will be tested in the available plataforms


 and
 most bugs will appear on the test builds.

 The important compatibility is at source code level, not at binary


level.
 I don't understand what are you trying to say here. What is "source code
 level"? Conforming compilers? Platform dependent APIs?

Source code-level compatibility is when I take the source code from one O/S,
then compile it under another O/S and it runs the same without modification.
The underlying implementation may be totally different though.

 <rant>
 People should stop posting about lack of libraries in D and start



coding
 them. It's been almost a year since I released DTL 0.0.1, and I know

 there's
 no excuse for my lack of work in the library, but since then nobody



come
 with another such library, just discussed about how they should look.
 </rant>

 Most definitely they should. I am available. We need to form a group, a
 coordinator...we need a virtual meeting room where we can discuss
 ideas...there is a lot of things to be done on the organizational front

 that
 I don't know anything about (and I am not willing to do).


 The open source developement model has lots of projects with maintainers

and
 contributors. Period. We don't need no "coordinator", nor "a virtual

meeting
 room". We have IRC and CVS (or whatever). Now we need people interested in
 writing code in D. People code, publish the CVS tree, contributors submit
 patches and maintainers either accept or reject. Someday we'll need to
 integrate two projects and then people will talk (IRC, email, usenet).
 Everything else is crap. Code matters. Working, tested, reliable code. And
 documentation. Note that I'm not in rant mode.

Don't be so absolute. We don't just need code. We need a plan. For example,
if I start to write a GUI, and you start to write to right your own GUI, a
dichotomy will be created...much like KDE vs GNOME. This should be avoided.
Of course, I am talking about D being really successful, not just endorsed
by open source. Mostly about adopted by corporate environments.

 If Walter waited to form this newsgroup then listened to everyone talking
 and discussing on how D should be then formed working groups to come with
 proposals then waited for voting then published a spec then started
 implementing, I (and most of the people here, if not all, including

Walter)
 would be elsewhere, doing something else. Instead he banged out a

compiler,
 released it, formed a newsgroup, listened to people (ignored most of them
 ;), modified and patched, and rinse and recycle. It works, people are

happy
 with D. But it is still an infant (pre 1.0 yet, thank god for Walter not
 rushing it), so we won't have a large user base. What we need is to test

it,
 try it, complain about something (templates anyone? ;) and see the

changes.
 We need code and binaries to make it happen (or else we couldn't test),

the
 same thing with libraries. We need working libraries to see what is good

and
 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

projects,
 and we don't need to follow that model.

But D is the base of our trials. Writing a compiler may be hard to do, but
that amounts of %1 of work needed for a modern app to develop. If you ever
tried to code a GUI library, you will see that to do it properly you would
have to code hundends of thousands of lines of code. A GUI, properly
written, is no small task. And then, there are other things that matter:
databases, networking, math, etc. GUI is the most important though. Without

GUI. And when I say it goes nowhere, I am talking about adoption by software
development companies (and the big corporations that dish out the
contracts).

Let me give you an example: I work for a company that makes apps for THALES
(ex Thomson). Our apps are defense applications, i.e. military stuff like
radar consoles, message interfaces, radar kernels, etc. Up until recently,
C++ and ADA was the preferred language. But they had a problem with GUI,
because either language lacks a decent cross-platform GUI. So now they are
using Java instead. The result is that applications run everywhere (so I can
take, let's say, the tactical system main MMI and test it on a PC), but in
expense of processing power. It needs a twice as fast PowerPC processor to
run the Java-based MMI. C++ has many other deficiencies as a language, which
D nicely fixes. If D had all the libraries, it would be preferred over Java
and Ada, especially since it supports 'programming-by-contract' (because
military apps are strictly tested with every kind of test imaginable,
including unit testing). D has a chance of combining speed, programmability
and speed of development. All it needs is some decent cross platform
libraries.

     Best regards,
     Daniel Yokomiso.

 "If you want to be happy be."


 ---
 Outgoing mail is certified Virus Free.
 Checked by AVG anti-virus system (http://www.grisoft.com).
 Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Achilleas Margaritis" <axilmar in.gr> escreveu na mensagem
news:bjq2js$2vn1$1 digitaldaemon.com...
 I disagree with you. Read on:

 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bjpjs7$2bsh$1 digitaldaemon.com...

[snip]

 So, what's your point? We're doomed, destined to failure ;)

 Basically, yes. Except if libraries are available real soon. (that's my
 opinion, please respect it. I don't want a flame war).


So, what are you doing here? You believe D is destined to failure, because
libraries will take time to be written, and offer no solutions. There's
nothing for you here. Seriously.


[snip]


 Again, what's your point?

 My point is that if there are no cross-platform standard libraries for GUI
 and other stuff, D won't succeed.



isn't everything in the world.


[snip]


 The open source developement model has lots of projects with maintainers

 and
 contributors. Period. We don't need no "coordinator", nor "a virtual

 meeting
 room". We have IRC and CVS (or whatever). Now we need people interested


in
 writing code in D. People code, publish the CVS tree, contributors


submit
 patches and maintainers either accept or reject. Someday we'll need to
 integrate two projects and then people will talk (IRC, email, usenet).
 Everything else is crap. Code matters. Working, tested, reliable code.


And
 documentation. Note that I'm not in rant mode.

 Don't be so absolute. We don't just need code. We need a plan. For

example,
 if I start to write a GUI, and you start to write to right your own GUI, a
 dichotomy will be created...much like KDE vs GNOME. This should be

avoided.
 Of course, I am talking about D being really successful, not just endorsed
 by open source. Mostly about adopted by corporate environments.


So what, we'll have two, three, ten different gui libraries. Today we have
thousands of different languages, the mainstream has at least five, GUIs are
written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
WxWindows). Competition is good. If we spend all our time trying to reach a
consensus on what is the best way to write a library we'll become a comitee
and spend months to decide if a widget should be named ListBox or
ListControl. Even if people decide to form a D library group someone will
write a different independent GUI library (I have some ideas) and some
people may like it better. Like Java with Swing and SWT.


[snip]


    Best regards,
    Daniel Yokomiso.

"In emptiness there is good but no evil. Wisdom exists, logic exists, the
Way exists, mind is empty."
 - Miyamoto Musashi


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.514 / Virus Database: 312 - Release Date: 28/8/2003

"Walter" <walter digitalmars.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we have
 thousands of different languages, the mainstream has at least five, GUIs

are
 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to reach

a
 consensus on what is the best way to write a library we'll become a

comitee
 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone will
 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. (Assuming of course the license
to it allows that.) It won't achieve perfection that way, but it should get
closer to it than starting over from 0.

Mark T <Mark_member pathlink.com> writes:

In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we have
 thousands of different languages, the mainstream has at least five, GUIs

are
 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to reach

a
 consensus on what is the best way to write a library we'll become a

comitee
 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone will
 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. 

Do you mean a cross platform GUI?  Why not a Java based one like SWT (which has
an open license).  I think it is a mistake to create a Windows only GUI.

"Walter" <walter digitalmars.com> writes:

"Mark T" <Mark_member pathlink.com> wrote in message
news:bkaji9$b7s$1 digitaldaemon.com...
 In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjv01i$pqt$1 digitaldaemon.com...
 So what, we'll have two, three, ten different gui libraries. Today we



have
 thousands of different languages, the mainstream has at least five,



GUIs
are
 written using different libraries (MFC, GTK, QT, Swing, SWT, Fox,
 WxWindows). Competition is good. If we spend all our time trying to



reach
a
 consensus on what is the best way to write a library we'll become a

comitee
 and spend months to decide if a widget should be named ListBox or
 ListControl. Even if people decide to form a D library group someone



will
 write a different independent GUI library (I have some ideas) and some
 people may like it better. Like Java with Swing and SWT.

Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D.

 Do you mean a cross platform GUI?  Why not a Java based one like SWT

(which has
 an open license).  I think it is a mistake to create a Windows only GUI.

Yes, of course, a cross platform one. I haven't used the various ones,
though, so I am not in a position to judge their relative merits.

Benji Smith <dlanguage xxagg.com> writes:

In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. (Assuming of course the license
to it allows that.) It won't achieve perfection that way, but it should get
closer to it than starting over from 0.

I agree 100%.

Personally, I think somebody should be working on rewriting wxWindows in D. The
object hierarchy has already been fleshed out. They've already mapped out
workable parallelism between win32 and gtk and mac os x. There are already
visual desginers for it. It's a mature project, and we could translate it into
D. Yes, it's a huge project. And, yes it would take lots of work. But it will
take _even_more_work_ to design and build an entire GUI library from scratch to
replace it.

--Benji

Ant <Ant_member pathlink.com> writes:

In article <bkanum$hcq$1 digitaldaemon.com>, Benji Smith says...
In article <bkac7h$6c$2 digitaldaemon.com>, Walter says...
Frankly, the best way I believe to do a GUI library for D is to take the
best C++ one and simply translate it to D. (Assuming of course the license
to it allows that.) It won't achieve perfection that way, but it should get
closer to it than starting over from 0.

I agree 100%.

Personally, I think somebody should be working on rewriting wxWindows in D. The
object hierarchy has already been fleshed out. They've already mapped out
workable parallelism between win32 and gtk and mac os x. There are already
visual desginers for it. It's a mature project, and we could translate it into
D. Yes, it's a huge project. And, yes it would take lots of work. But it will
take _even_more_work_ to design and build an entire GUI library from scratch to
replace it.

--Benji

Maybe it's time to make a conversion tool.
It would help a lot on this project and be very usefull
for others.

wxWindows GTK only has 194301 lines in .cpp files alone
(DUI and tests is now with 43000 in .d files).
I don't advice any single person to look at 200000 lines of code.

I saw at some page from the D links a description of an .h to .d
processor, but I didn't see any download link...

Did any one start such a tool?
That looks like a one person project.
(hey, don't look at me, I have 2 other projects to finish)

I did made a small .h to .d to convert the OpenGL headers
(quick and dirty)
but they use just a small set of c and pre-processor directives.

Ant

"Walter" <walter digitalmars.com> writes:

"Ant" <Ant_member pathlink.com> wrote in message
news:bkaqhf$l6t$1 digitaldaemon.com...
 Maybe it's time to make a conversion tool.
 It would help a lot on this project and be very usefull
 for others.

 wxWindows GTK only has 194301 lines in .cpp files alone
 (DUI and tests is now with 43000 in .d files).
 I don't advice any single person to look at 200000 lines of code.

I wonder if it all needs to be converted for a first pass. After all, D can
easilly interface to C code. Can much of wxWindows be wrapped in C?

Is there a usable subset of wxWindows?

 I saw at some page from the D links a description of an .h to .d
 processor, but I didn't see any download link...

 Did any one start such a tool?
 That looks like a one person project.
 (hey, don't look at me, I have 2 other projects to finish)

Doing C headers to D is one thing, but doing C++ is another.

 I did made a small .h to .d to convert the OpenGL headers
 (quick and dirty)
 but they use just a small set of c and pre-processor directives.

 Ant

"Walter" <walter digitalmars.com> writes:

Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc.
Perhaps it won't be so hard to do a D version.

Andy Friesen <andy ikagames.com> writes:

Walter wrote:
 Followup: There appears to be wxWindows wrappers for Python, Eiffel, etc.
 Perhaps it won't be so hard to do a D version.

!

wxWindows uses SWIG to generate all those other language bindings.  It 
would probably be worthwhile to look into getting SWIG to make D 
bindings as well.

  -- andy

Benji Smith <dlanguage xxagg.com> writes:

In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It 
would probably be worthwhile to look into getting SWIG to make D 
bindings as well.

I've just spent the last 20 minutes or so reading up about swig (
http://www.swig.org ) and I'm impressed. Since there are already language

languages), it shouldn't be too difficult to use those implementations as a
reference for creating a D SWIG extension.

In my opinion, this is the most important project for D in the upcoming year.
Because if we can assemble a general purpose method for creating bindings
between C++ and D, we'll open up access to lots of existing libraries that we
can't use now.

As soon as I've got the repository site up and running, this is one of the
projects I'g going to create.

--Benji Smith

Ant <Ant_member pathlink.com> writes:

In article <bkcgu9$1d2$1 digitaldaemon.com>, Benji Smith says...
In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It 
would probably be worthwhile to look into getting SWIG to make D 
bindings as well.

I've just spent the last 20 minutes or so reading up about swig (
http://www.swig.org ) and I'm impressed. Since there are already language

languages), it shouldn't be too difficult to use those implementations as a
reference for creating a D SWIG extension.

In my opinion, this is the most important project for D in the upcoming year.

You're probably right. It might be the second most important ever for D
(after the creation of the compiler)

now, why the upcoming year?
maybe with SWIG a D GUI lib can be created faster then finishing DUI...

Some body dismissed SWIG as usable for some other D project.
Why? (just insanity or is there some reason?)

Ant

BenjiSmith <dlanguage xxagg.com> writes:

In article <bkcjko$5cd$1 digitaldaemon.com>, Ant says...
now, why the upcoming year?

1) Because I'm not up to the job myself. I'm not a competent enough C/C++
programmer to build the bridge between SWIG and D. And even if I was competent
enough, I'm incredibly busy. Everybody else seems to be incredibly busy, too, so
I don't know who has big chunks of free time.

2) I don't know how difficult it would be. How many lines of code would it take
to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea.

SWIG Extension source code).

3) [I think this is the most important reason] The language isn't finished yet.
There are still significant semantic changes being made to the D language spec.
I don't know how much (if any) impact those semantic changes would have on the
creation of a SWIG extension, but I'd certainly want to know that I wasn't going
to waste time reworking a SWIG extension following a significant language
change.

--Benji

Ant <Ant_member pathlink.com> writes:

In article <bkckt2$79l$1 digitaldaemon.com>, BenjiSmith says...
In article <bkcjko$5cd$1 digitaldaemon.com>, Ant says...
now, why the upcoming year?

1) Because I'm not up to the job myself. I'm not a competent enough C/C++
programmer to build the bridge between SWIG and D. And even if I was competent
enough, I'm incredibly busy. Everybody else seems to be incredibly busy, too, so
I don't know who has big chunks of free time.

2) I don't know how difficult it would be. How many lines of code would it take
to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea.

SWIG Extension source code).

3) [I think this is the most important reason] The language isn't finished yet.
There are still significant semantic changes being made to the D language spec.
I don't know how much (if any) impact those semantic changes would have on the
creation of a SWIG extension, but I'd certainly want to know that I wasn't going
to waste time reworking a SWIG extension following a significant language
change.

--Benji

3 very good reasons!  but not good enough :)

I wasn't implying that you should start it sooner,
sorry if it looks like that.
I was just stating the obvious that nobody should feel any
constraint by the "upcoming year" thing...

Ant

Benji Smith <dlanguage xxagg.com> writes:

Holy cow. I just downloaded the SWIG sources and I've been looking around at
what it would take to write a SWIG extension for D. And this is the answer:

NOT VERY MUCH

In order to customize SWIG for any given language, there is only one source file

file called "csharp.cxx". Each of these files is moderately complex. The java
file, with all of the comments and newlines stripped out, is about 1400 lines of
code (in C++). The csharp file is about 1600 lines.

That's not very much code.

Plus, I'm guessing that much of the code for the D extension would look an awful

from the existing implementation.

However, this project is not for the faint of heart. Even if it only requires
writing 1500 or so lines of code, the author will have to have a pretty good
command of C++ (I'm already out of the running) and an excellent understanding
of D semantics (that eliminately most of us).

But, on the upside, once it's done we'll have access to millions of lines of C++
code to use as imports and libraries for our own projects. I'm just giddy at the
notion that we could suddenly have access to the entire wxWindows library, after
writing only 1500 lines of code.

--Benji Smith

"Walter" <walter digitalmars.com> writes:

Cool! Also, let's start a new thread on this!

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkctb3$j5j$1 digitaldaemon.com...
 Holy cow. I just downloaded the SWIG sources and I've been looking around

at
 what it would take to write a SWIG extension for D. And this is the

answer:
 NOT VERY MUCH

 In order to customize SWIG for any given language, there is only one

source file


it's a
 file called "csharp.cxx". Each of these files is moderately complex. The

java
 file, with all of the comments and newlines stripped out, is about 1400

lines of
 code (in C++). The csharp file is about 1600 lines.

 That's not very much code.

 Plus, I'm guessing that much of the code for the D extension would look an

awful


heavily
 from the existing implementation.

 However, this project is not for the faint of heart. Even if it only

requires
 writing 1500 or so lines of code, the author will have to have a pretty

good
 command of C++ (I'm already out of the running) and an excellent

understanding
 of D semantics (that eliminately most of us).

 But, on the upside, once it's done we'll have access to millions of lines

of C++
 code to use as imports and libraries for our own projects. I'm just giddy

at the
 notion that we could suddenly have access to the entire wxWindows library,

after
 writing only 1500 lines of code.

 --Benji Smith

"Walter" <walter digitalmars.com> writes:

"BenjiSmith" <dlanguage xxagg.com> wrote in message
news:bkckt2$79l$1 digitaldaemon.com...
 2) I don't know how difficult it would be. How many lines of code would it

take
 to build the SWIG extension for D? 1,000? 10,000? I honestly have no idea.


Java
 SWIG Extension source code).


D version.

 3) [I think this is the most important reason] The language isn't finished

yet.
 There are still significant semantic changes being made to the D language

spec.
 I don't know how much (if any) impact those semantic changes would have on

the
 creation of a SWIG extension, but I'd certainly want to know that I wasn't

going
 to waste time reworking a SWIG extension following a significant language
 change.

I'm very careful not to change the language in any fundamental way, exactly
because of this problem. There may be a bit of tweaking required (things
like changing the names of the operator overload functions), but I seriously
doubt anything more than that. I can't think of anything that would require
a rewrite.

Benji Smith <dlanguage xxagg.com> writes:

In article <bkcp02$d2r$1 digitaldaemon.com>, Walter says...
I'm very careful not to change the language in any fundamental way, exactly
because of this problem. There may be a bit of tweaking required (things
like changing the names of the operator overload functions), but I seriously
doubt anything more than that. I can't think of anything that would require
a rewrite.

I'm glad to hear that the language is stable enough for this type of work to
commence.

Apparantly, the swig wrapper generators are based on the notion of creating
typemaps between the type systems of the two different languages. I'm not sure
how much of that typemapping is implementation dependent, but I'm curious to
hear your opinion. If another compiler vendor makes different implementation
decisions about type sizes and whatnot, how do you think that might affect the
mapping of types between D and C++?


libraries for the swig project, asking him some questions about the current
state of the modules and for advice about any implementation hurdles that could
get in the way of a D implementation. I'll post more information when I get his
reply.

--Benji Smith

Benij Smith <dlanguage xxagg.com> writes:

In article <bkd3bl$rdh$1 digitaldaemon.com>, Benji Smith says...

libraries for the swig project, asking him some questions about the current
state of the modules and for advice about any implementation hurdles that could
get in the way of a D implementation. I'll post more information when I get his
reply.

I got a reply (already!) to the email that I sent to this guy. According to
him...

<quote>

two. To begin with don't change the source code in csharp.cxx (or a new d.cxx),
just modify the typemaps in csharp.swg. (What are you going to call it? d.cxx,
class D and d.swg is rediculously short!) I suspect that after 2 weeks it will
be in a fairly reasonable shape. A month later quite polished. It will probably
never be perfect!
</quote>

So, there's the possibility of having some swig compatibility very shortly. If
anyone is interested in working on this project, let me know (through the ng,
not email), and I'll forward you the rest of the above email, which has quite a
few more helpful hints and suggestions for creating the D swig implementation.

--Benji

"Walter" <walter digitalmars.com> writes:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkd3bl$rdh$1 digitaldaemon.com...
 Apparantly, the swig wrapper generators are based on the notion of

creating
 typemaps between the type systems of the two different languages. I'm not

sure
 how much of that typemapping is implementation dependent, but I'm curious

to
 hear your opinion. If another compiler vendor makes different

implementation
 decisions about type sizes and whatnot, how do you think that might affect

the
 mapping of types between D and C++?

D specifies the sizes of all the types except real. So that shouldn't be a
problem.


 libraries for the swig project, asking him some questions about the

current
 state of the modules and for advice about any implementation hurdles that

could
 get in the way of a D implementation. I'll post more information when I

get his
 reply.

Thanks!

"Walter" <walter digitalmars.com> writes:

"Benji Smith" <dlanguage xxagg.com> wrote in message
news:bkcgu9$1d2$1 digitaldaemon.com...
 In article <bkcbf8$2r06$1 digitaldaemon.com>, Andy Friesen says...
wxWindows uses SWIG to generate all those other language bindings.  It
would probably be worthwhile to look into getting SWIG to make D
bindings as well.

 I've just spent the last 20 minutes or so reading up about swig (
 http://www.swig.org ) and I'm impressed. Since there are already language


other
 languages), it shouldn't be too difficult to use those implementations as

a
 reference for creating a D SWIG extension.

 In my opinion, this is the most important project for D in the upcoming

year.
 Because if we can assemble a general purpose method for creating bindings
 between C++ and D, we'll open up access to lots of existing libraries that

we
 can't use now.

I agree. A D binding for SWIG looks like it'll be a very valuable project.
Since SWIG already works on wxWindows, doing SWIG for D seems to be a better
first step.

"Walter" <walter digitalmars.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bjpjs7$2bsh$1 digitaldaemon.com...
 If Walter waited to form this newsgroup then listened to everyone talking
 and discussing on how D should be then formed working groups to come with
 proposals then waited for voting then published a spec then started
 implementing, I (and most of the people here, if not all, including

Walter)
 would be elsewhere, doing something else. Instead he banged out a

compiler,
 released it, formed a newsgroup, listened to people (ignored most of them
 ;), modified and patched, and rinse and recycle. It works, people are

happy
 with D. But it is still an infant (pre 1.0 yet, thank god for Walter not
 rushing it), so we won't have a large user base. What we need is to test

it,
 try it, complain about something (templates anyone? ;) and see the

changes.
 We need code and binaries to make it happen (or else we couldn't test),

the
 same thing with libraries. We need working libraries to see what is good

and
 what is crap, else we'll over-engineer it. Java libraries are
 over-engineered, they wrote all of them before someone used it in

projects,
 and we don't need to follow that model.

One amusing thing about D is about everyone tells me I'm going to fail with
it. Of course, I've been told that about every single successful project
I've worked on. The irony is that the projects people have told me were sure
things have been the failures <g>.

Anyhow, D has already been a dramatic success. That's easy to see given the
activity in the D newsgroup and the high quality of discussion here and the
high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even a
rubber axe can chop down an oak tree if you keep on swinging, and that is
certainly what I intend to do. The language is steadilly improving, it's
just received a foreach, I'm working on fleshing out the operator
overloading, and I have several ideas and suggestions from you guys for
improving templates percolating around. We'll keep plugging away, and things
will only get better.

For those concerned about the libraries - sure, D's libraries are woefully
inadequate right now. But don't worry about writing library code that is
less than perfect, just write it. Evolve it over time into perfection. Look
at how C++ libraries changed over time. How many times has iostream been
re-engineered from scratch? <g>

"Matthew Wilson" <matthew stlsoft.org> writes:

 For those concerned about the libraries - sure, D's libraries are woefully
 inadequate right now. But don't worry about writing library code that is
 less than perfect, just write it. Evolve it over time into perfection.

Look
 at how C++ libraries changed over time. How many times has iostream been
 re-engineered from scratch? <g>

There should only ever have been one reworking of the iostreams, and I think
you know what that would have been ...

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkaipi$a1i$2 digitaldaemon.com...
 For those concerned about the libraries - sure, D's libraries are


woefully
 inadequate right now. But don't worry about writing library code that is
 less than perfect, just write it. Evolve it over time into perfection.

 Look
 at how C++ libraries changed over time. How many times has iostream been
 re-engineered from scratch? <g>

 There should only ever have been one reworking of the iostreams, and I

think
 you know what that would have been ...

There have been at least three reengineerings of it. That's why DMC++ has
<iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

"Matthew Wilson" <matthew stlsoft.org> writes:

 "Matthew Wilson" <matthew stlsoft.org> wrote in message
 news:bkaipi$a1i$2 digitaldaemon.com...
 For those concerned about the libraries - sure, D's libraries are


 woefully
 inadequate right now. But don't worry about writing library code that



is
 less than perfect, just write it. Evolve it over time into perfection.

 Look
 at how C++ libraries changed over time. How many times has iostream



been
 re-engineered from scratch? <g>

 There should only ever have been one reworking of the iostreams, and I

 think
 you know what that would have been ...

 There have been at least three reengineerings of it. That's why DMC++ has
 <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

The iostream include I would be looking for would involve no characters at
all ...

"Sean L. Palmer" <palmer.sean verizon.net> writes:

----- Original Message ----- 
From: "Matthew Wilson" <matthew stlsoft.org>
Newsgroups: D
Sent: Wednesday, September 17, 2003 4:26 PM
Subject: Re: The importance of component programming (properties, signals
and slots, etc)
 at how C++ libraries changed over time. How many times has iostream



 been
 re-engineered from scratch? <g>

 There should only ever have been one reworking of the iostreams, and I

 think
 you know what that would have been ...

 There have been at least three reengineerings of it. That's why DMC++


has
 <iostream>, <iostream.h>, <iosold\iostream.h> and <oldstr\iostream.h>.

 The iostream include I would be looking for would involve no characters at
 all ...

What don't you like about it?  The overloading abuse or the layering and
buffering?  Or the naming scheme for member functions?  Or the clutter that
allocators and traits bring to the debug info?

Surely it can be done better, but it's not a horrible piece of engineering.
Input and output iterators aren't such a bad idea.  They can let you use
some of the generic data handling mechanisms in STL to manipulate file data.

for instance this probably works (though I haven't tried it, it does at
least compile):

#include <fstream>
#include <functional>
#include <algorithm>
using namespace std;
void print_int_after_first_int_in_this_file_thats_at_least(ostream& so,
istream& si, int at_least)
{
    typedef istream_iterator<int> it;
    it found = find_if(it(si),it(),bind2nd(less<int>(),at_least));
    if (!(found == it()))
        *ostream_iterator<int>(so) = *found;
}

That's a lot of power, speed be damned.  Surely it could look prettier or be
friendlier or easier to use, but this is certainly a step in the right
direction.  You can actually implement your own ostream and istream above
and hook this function up to any data pipe you can imagine.  Pass in any
function you can build for the test as unary_function<int,bool>.  There are
all kinds of algorithms too,  stuff like copy_if and replace_if, that are
useful for moving and filtering data.
Check out the notes on the operator* and operator= in the
std::ostream_iterator class.  ;)

Sean

"Matthew Wilson" <matthew stlsoft.org> writes:

 Anyhow, D has already been a dramatic success. That's easy to see given

the
 activity in the D newsgroup and the high quality of discussion here and

the
 high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even a
 rubber axe can chop down an oak tree if you keep on swinging, and that is
 certainly what I intend to do. The language is steadilly improving, it's
 just received a foreach, I'm working on fleshing out the operator
 overloading, and I have several ideas and suggestions from you guys for
 improving templates percolating around. We'll keep plugging away, and

things
 will only get better.

Any chance of you updating the SynSoft link to mention the Performance,
String Tokenisation and Registry libraries? :)

Also, have you had a look at the reg stuff yet? I started work on some
reg-writing code (porting a set of C++ utility fns of my own, that have
served almost all my needs over the last 5 yrs) last night - when I should
be writing my article; deadline today!! - and that all went really easily. I
plan to implement a synsoft.win32.regutil module, on which the
synsoft.win32.reg will be implemented. That way, if the class-based registry
stuff falls short in some esoteric way, the user can get whatever they want
from the free function API, rather than trying to write the catch-all API.

"Walter" <walter digitalmars.com> writes:

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkakce$cb8$1 digitaldaemon.com...
 Any chance of you updating the SynSoft link to mention the Performance,
 String Tokenisation and Registry libraries? :)

Write me a brief text, and I'll update it with that text. And that goes for
all! I try to keep up with the dlinks, but if the descriptions fall short,
need updating, or are missing, please provide the text for me and I'll fix
it.

 Also, have you had a look at the reg stuff yet? I started work on some
 reg-writing code (porting a set of C++ utility fns of my own, that have
 served almost all my needs over the last 5 yrs) last night - when I should
 be writing my article; deadline today!! - and that all went really easily.

I
 plan to implement a synsoft.win32.regutil module, on which the
 synsoft.win32.reg will be implemented. That way, if the class-based

registry
 stuff falls short in some esoteric way, the user can get whatever they

want
 from the free function API, rather than trying to write the catch-all API.

I looked at the reg stuff. It needs write capability, and after looking at
it, it really does need properties to look its best!

"Matthew Wilson" <matthew stlsoft.org> writes:

Well, that'll teach me! I thought I was writing an email.

Good job I didn't say anything rude!! <blush>

"Matthew Wilson" <matthew stlsoft.org> wrote in message
news:bkakce$cb8$1 digitaldaemon.com...
 Anyhow, D has already been a dramatic success. That's easy to see given

 the
 activity in the D newsgroup and the high quality of discussion here and

 the
 high quality of code apparent on www.digitalmars.com/d/dlinks.html. Even


a
 rubber axe can chop down an oak tree if you keep on swinging, and that


is
 certainly what I intend to do. The language is steadilly improving, it's
 just received a foreach, I'm working on fleshing out the operator
 overloading, and I have several ideas and suggestions from you guys for
 improving templates percolating around. We'll keep plugging away, and

 things
 will only get better.

 Any chance of you updating the SynSoft link to mention the Performance,
 String Tokenisation and Registry libraries? :)

 Also, have you had a look at the reg stuff yet? I started work on some
 reg-writing code (porting a set of C++ utility fns of my own, that have
 served almost all my needs over the last 5 yrs) last night - when I should
 be writing my article; deadline today!! - and that all went really easily.

I
 plan to implement a synsoft.win32.regutil module, on which the
 synsoft.win32.reg will be implemented. That way, if the class-based

registry
 stuff falls short in some esoteric way, the user can get whatever they

want
 from the free function API, rather than trying to write the catch-all API.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Walter" <walter digitalmars.com> escreveu na mensagem
news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging, and
 that is certainly what I intend to do.

But can you do it... with... a herring?


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

"Walter" <walter digitalmars.com> writes:

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
news:bkaqbj$kpl$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging, and
 that is certainly what I intend to do.

 But can you do it... with... a herring?

Monty Python?

Felix <Felix_member pathlink.com> writes:

Hi,

I do not remember this topic's thread very well, but I think the title is very
interesting. So, to bring the discussion back where it belongs, what about
component programming?

Could somebody put some ActiveX programmed controls, by example? I think is the
widest spreaded component interface. I know it is possible to program ActiveX
controls/forms in D but I found no real example. As a beginner, I would need
that.


Further, I know that D classes are compatible with this kind of components (even
ActiveX). But, there is a real internal support for that? I mean, are the
classes conceived as components? Are they really supporting (internally) events,
properties and methods? I do not like very much to imagine first the entire
application's class tree and to implement each class afterward as an extention
of the (same) ancestor. Reusing components, aggregating and connecting them is
simpler, I think. You can easily change the message trajectories at the
run-time, by example. Anyway, just an opinion.

Please be kind with me....

"Matthew Wilson" <matthew stlsoft.org> writes:

 Hi,

 I do not remember this topic's thread very well, but I think the title is

very
 interesting. So, to bring the discussion back where it belongs, what about
 component programming?

There is a good, though not great, basis in the language for component
programming. There are (AFAIK) no libraries yet for doing it.

 Could somebody put some ActiveX programmed controls, by example? I think

is the
 widest spreaded component interface. I know it is possible to program

ActiveX
 controls/forms in D but I found no real example. As a beginner, I would

need
 that.

My plans, once the Registry library is complete, and ensconced in Phobos, is
to implement a COM library. (Since COM relies so heavily on the registry, we
need a registry API first.) I hope to get something that is as small and
flexible as ATL, but without its flaws, and without all that macro gunk.
I've written my own COM libraries, and have used ATL and MFC's COM
extensively, so hopefully I can do something that combines the good and
leaves out the bad. (Famous last words ... ???)

As to what form it will actually take, however, it's all just meandering
around in my subconsious at the moment, I'm afraid.

 Further, I know that D classes are compatible with this kind of components

(even
 ActiveX). But, there is a real internal support for that?

Don't know what you mean. :(

 I mean, are the
 classes conceived as components? Are they really supporting (internally)

events,
 properties and methods? I do not like very much to imagine first the

entire
 application's class tree and to implement each class afterward as an

extention
 of the (same) ancestor.

Sorry, I don't follow.

 Reusing components, aggregating and connecting them is
 simpler, I think. You can easily change the message trajectories at the
 run-time, by example. Anyway, just an opinion.

 Please be kind with me....

Of course. :)

Felix <Felix_member pathlink.com> writes:

Thanks for answers. Forget the last issues in my message. Maybe I am too old ;)
already ;)




In article <bkbq7a$23lj$1 digitaldaemon.com>, Matthew Wilson says...
 Hi,

 I do not remember this topic's thread very well, but I think the title is

very
 interesting. So, to bring the discussion back where it belongs, what about
 component programming?

There is a good, though not great, basis in the language for component
programming. There are (AFAIK) no libraries yet for doing it.

 Could somebody put some ActiveX programmed controls, by example? I think

is the
 widest spreaded component interface. I know it is possible to program

ActiveX
 controls/forms in D but I found no real example. As a beginner, I would

need
 that.

My plans, once the Registry library is complete, and ensconced in Phobos, is
to implement a COM library. (Since COM relies so heavily on the registry, we
need a registry API first.) I hope to get something that is as small and
flexible as ATL, but without its flaws, and without all that macro gunk.
I've written my own COM libraries, and have used ATL and MFC's COM
extensively, so hopefully I can do something that combines the good and
leaves out the bad. (Famous last words ... ???)

As to what form it will actually take, however, it's all just meandering
around in my subconsious at the moment, I'm afraid.

 Further, I know that D classes are compatible with this kind of components

(even
 ActiveX). But, there is a real internal support for that?

Don't know what you mean. :(

 I mean, are the
 classes conceived as components? Are they really supporting (internally)

events,
 properties and methods? I do not like very much to imagine first the

entire
 application's class tree and to implement each class afterward as an

extention
 of the (same) ancestor.

Sorry, I don't follow.

 Reusing components, aggregating and connecting them is
 simpler, I think. You can easily change the message trajectories at the
 run-time, by example. Anyway, just an opinion.

 Please be kind with me....

Of course. :)

Mike Wynn <mike l8night.co.uk> writes:

Felix wrote:
 Hi,
 
 I do not remember this topic's thread very well, but I think the title is very
 interesting. So, to bring the discussion back where it belongs, what about
 component programming?
 
 Could somebody put some ActiveX programmed controls, by example? I think is the
 widest spreaded component interface. I know it is possible to program ActiveX
 controls/forms in D but I found no real example. As a beginner, I would need
 that.
 

my code for imbedding an instance of MSIE in a D window (using my win32 
wrapper classes) can be found on
http://www.geocities.com/one_mad_alien/dcom_not_dcom.html

you may have to tweek it a bit it is all 0.68 not 0.7x and my windows 
machine has blown up so I'm only using linux at present.

"Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> writes:

"Walter" <walter digitalmars.com> escreveu na mensagem
news:bkb2mm$10cd$1 digitaldaemon.com...
 "Daniel Yokomiso" <daniel_yokomiso yahoo.com.br> wrote in message
 news:bkaqbj$kpl$1 digitaldaemon.com...
 "Walter" <walter digitalmars.com> escreveu na mensagem
 news:bkac7h$6c$1 digitaldaemon.com...

 Even a rubber axe can chop down an oak tree if you keep on swinging,



and
 that is certainly what I intend to do.

 But can you do it... with... a herring?

 Monty Python?

Yes.


---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.518 / Virus Database: 316 - Release Date: 11/9/2003

Olaf Rogalsky <olaf.rogalsky theorie1.physik.uni-erlangen.de> writes:

Daniel Yokomiso wrote:

     Best regards,
     Daniel Yokomiso.
 
 "(define (.sig) (cons 'my (list 'other 'car 'is 'a 'cdr)))"

I like your sig :-)
-- 
+----------------------------------------------------------------------+
I Dr. Olaf Rogalsky                         Institut f. Theo. Physik I I
I Tel.: 09131 8528440                       Univ. Erlangen-Nuernberg   I
I Fax.: 09131 8528444                       Staudtstrasse 7 B3         I
I rogalsky theorie1.physik.uni-erlangen.de  D-91058 Erlangen           I
+----------------------------------------------------------------------+

"Jeroen van Bemmel" <someone somewhere.com> writes:

"Achilleas Margaritis" <axilmar b-online.gr> wrote in message
news:bjb5df$2o5p$1 digitaldaemon.com...
 I found an article about component programming that I completely agree

with.
 Here it is:

 http://www.artima.com/intv/simplexity.html

BTW, the fact that delegation does not break overloading to me makes it look
more like syntactic sugar that is really an interface. I wonder how they can
claim to resolve such overloads at compile time. For example, given some
method

m ( X someObject )
{
    delegate d = someObject.func;
}

and a class Y : X {
    void func()  { ... }     // overloads X.func
}

how can they know in advance that d will be pointing toY.func() when m(y) is
called? Y could be compiled separately. Perhaps the virtual table needs only
be walked once (at the point where d is assigned) and then calling the
delegate becomes a simple call instruction. But to me it needs to be
resolved at run time. And moreover, you lose the information that the object
being called was 'y' (or not? do they store the reference too?)