Am Wed, 17 Nov 2004 09:09:43 -0800 schrieb Walter <newshound@digitalmars.com>:

> D is good for any project you'd consider using C or C++ for. Sometimes using
> a particular existing library may dictate what language you use, but other
> than that, why?

Some time ago I have been thinking about creating a nine men's morris game. The first attempt was in pure C and directly using the Win32 API. Because it was rather a horrible 'ad hoc' hack instead of structured programming it soon became clear that I'd have to start from scratch again. Since I generally try to learn from my mistakes and I didn't want to waste time again I decided to better plan and anticipate possible later requirements.
Aside from things like considering morris variants other than the "classical" I found it would be nice to make the game open source, and platform independent if possible. It seemed that wxWidgets was the best solution for the GUI and I finally managed to get it to work with DigitalMars C/C++. The drawbacks, however, are that the EXE files quickly become larger than 1 MB even for a simple Hello World program, and that I must learn how to use C++ *and* wxWidgets (I only know C at the moment).
Around this time I discovered the D programming language which offered a far easier alternative to C++. I liked the run-time array-bounds checking and I often find D's error messages more helpful than C's, I love garbage collection, and so on. Although the D way of writing Win32 GUI apps looks weird it seems close enough to C that I think I can get used to it.
The problem is that my program would still be chained to Win32. Admittedly, that would also be true if it was written in pure C using the Win32 API, but there are C compilers for platforms other than Win32 and Linux (DOS, Win 3.x, MacOS X, MacOS classic, etc.), so at least the morris playing 'engine' could actually be ported. I know there are ports of GUI libraries to the D language on the dsource.org site, but it seems there isn't any usable yet (except unDig but this is only for Win32) and I don't feel adventurous enough to test an alpha release.
One idea of open source is that people can help each other. If I use a rather unknown language like D, how many people could contribute to the project?
Sorry for this long-winded and potentially off-topic message. It's not meant as a rant. I'd really appreciate suggestions and ideas how to tackle this morris project with D. Thanks!

Mathias

Mathias Bierschenk wrote:
> Am Wed, 17 Nov 2004 09:09:43 -0800 schrieb Walter  <newshound@digitalmars.com>:
> 
>> D is good for any project you'd consider using C or C++ for. Sometimes  using
>> a particular existing library may dictate what language you use, but  other
>> than that, why?
> 
> 
> Some time ago I have been thinking about creating a nine men's morris  game. The first attempt was in pure C and directly using the Win32 API.  Because it was rather a horrible 'ad hoc' hack instead of structured  programming it soon became clear that I'd have to start from scratch  again. Since I generally try to learn from my mistakes and I didn't want  to waste time again I decided to better plan and anticipate possible later  requirements.
> Aside from things like considering morris variants other than the  "classical" I found it would be nice to make the game open source, and  platform independent if possible. It seemed that wxWidgets was the best  solution for the GUI and I finally managed to get it to work with  DigitalMars C/C++. The drawbacks, however, are that the EXE files quickly  become larger than 1 MB even for a simple Hello World program, and that I  must learn how to use C++ *and* wxWidgets (I only know C at the moment).
> Around this time I discovered the D programming language which offered a  far easier alternative to C++. I liked the run-time array-bounds checking  and I often find D's error messages more helpful than C's, I love garbage  collection, and so on. Although the D way of writing Win32 GUI apps looks  weird it seems close enough to C that I think I can get used to it.
> The problem is that my program would still be chained to Win32.  Admittedly, that would also be true if it was written in pure C using the  Win32 API, but there are C compilers for platforms other than Win32 and  Linux (DOS, Win 3.x, MacOS X, MacOS classic, etc.), so at least the morris  playing 'engine' could actually be ported. I know there are ports of GUI  libraries to the D language on the dsource.org site, but it seems there  isn't any usable yet (except unDig but this is only for Win32) and I don't  feel adventurous enough to test an alpha release.
> One idea of open source is that people can help each other. If I use a  rather unknown language like D, how many people could contribute to the  project?
> Sorry for this long-winded and potentially off-topic message. It's not  meant as a rant. I'd really appreciate suggestions and ideas how to tackle  this morris project with D. Thanks!

I think we - as D programming community - are at the point to start
serious work.

Maybe the signal is the sourceforge recognition of D, maybe the signal
will be Walter's 1.00 release. Maybe it's not now, maybe it will be in
a couple of weeks.

Anyway, within 12 months there will be a hundred D project at
sourceforge and dsource. All major task - like interfacing
wcWidgets, building a gaming engine, a native portable D GUI,
... - will be tackling.

Of course, no-one can know which projects will get support and will
succeed in the short run. But I think it's a good time to try.

> D is good for any project you'd consider using C or C++ for. Sometimes
using
> a particular existing library may dictate what language you use, but other than that, why?
>
I personally use it a little but until there is an IDE and Debugger like "Digital Mars C/C++", CodeWarrior or Visual Studio, I would not use use it for any serious projects, some people I work with would not even look at it for this reason (and yes we would buy a development tool if there was one available).

Zz

Mathias Bierschenk wrote:
> Some time ago I have been thinking about creating a nine men's morris  game. The first attempt was in pure C and directly using the Win32 API.  Because it was rather a horrible 'ad hoc' hack instead of structured  programming it soon became clear that I'd have to start from scratch  again. Since I generally try to learn from my mistakes and I didn't want  to waste time again I decided to better plan and anticipate possible later  requirements.

...

> Around this time I discovered the D programming language which offered a  far easier alternative to C++. I liked the run-time array-bounds checking  and I often find D's error messages more helpful than C's, I love garbage  collection, and so on. Although the D way of writing Win32 GUI apps looks  weird it seems close enough to C that I think I can get used to it.

I think the "D way of writing Win32 GUI apps" is going to vary widely depending on the particular GUI library.

> The problem is that my program would still be chained to Win32.  Admittedly, that would also be true if it was written in pure C using the  Win32 API, but there are C compilers for platforms other than Win32 and  Linux (DOS, Win 3.x, MacOS X, MacOS classic, etc.), so at least the morris  playing 'engine' could actually be ported. I know there are ports of GUI  libraries to the D language on the dsource.org site, but it seems there  isn't any usable yet (except unDig but this is only for Win32) and I don't  feel adventurous enough to test an alpha release.
> One idea of open source is that people can help each other. If I use a  rather unknown language like D, how many people could contribute to the  project?

Do you require a GUI library that works for Linux and Win32?

If Linux alone is good enough, you might try DUI (it uses GTK+): http://dui.sourceforge.net/

Ant, DUI's creator, is working on supporting Win32/GTK+. It sounds like he's close to releasing a new version of DUI that works with Windows, but I think he's still kicking the tires on it.

> Sorry for this long-winded and potentially off-topic message. It's not  meant as a rant. I'd really appreciate suggestions and ideas how to tackle  this morris project with D. Thanks!

Thanks for your comments. They didn't come off as a rant or off-topic at all.

> 
> Mathias


-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Mathias Bierschenk schrieb:

> One idea of open source is that people can help each other. If I use a  rather unknown language like D, how many people could contribute to the  project?

Frankly: it is very hard to expect other people to help, be project open-source or anything at all. Open-source is good when the author ends the effort, but someone else wants to build on it.

Apart from that, D will seem very familiar to programmers who have worked with C++ and some Java. We shall also have a port of wxWidgets, as it seems. And yes, smaller binaries than you get *are* possible, in C++ definately (depends on compiler and linker), but also in D.

I am using D for my next project. Why? Because i can. :>

-eye

In article <cngn0t$2gmg$1@digitaldaemon.com>, J C Calvarese says...
>
>
>Do you require a GUI library that works for Linux and Win32?
>
>If Linux alone is good enough, you might try DUI (it uses GTK+): http://dui.sourceforge.net/

???
DUI always worked on windows!
(sure, it's has a few more problem on windows then on linux, but
those are getting solved)
the released versions of DUI don't work with dmd 0.106.

beside unimplemented features and a couple of bugs
I had only types 2 complaints about DUI
1. it's a wrapper (can't to anything about it)
2. there are too many libs to install and link and whatever.

I spend the last few weeks trying to come up with a solution to the
second problem:
1.a - I created an installer to unzip GTK+ dll files and the import libs
(generated by implib). This is ridiculous! Every windows Gtk application
has it's own Gtk+ installer. mine is no exception - I have to say
something to the win32 Gtk guy. In addition there are several independent
projects that only install Gtk. The windows Gtk community has to select
one as the 'official' installer.
1.b - I'm finishing a GUI wrapper for the DMD compiler that imports
and links with all the necessary libraries.

On linux it's trivial to use DUI as most developer's systems will have
the Gtk+ developement environment setup - I'm not changing anything
on the DUI linux distribution.
(beside that I also offer leds for linux that make seasy to manage and
compile multiple projects)

>Ant, DUI's creator, is working on supporting Win32/GTK+. It sounds like he's close to releasing a new version of DUI that works with Windows, but I think he's still kicking the tires on it.

big tires. and when I started to project had 4 tires and it's now up to
18...
but every thing it's now ready (unless I find another tire to kick).
I should do a clean up today.
I should package it and upload it tomorrow.

that will mark the end of the changes I thought were necessary after
the changes on dmd 0.91 - several months ago! many more headaches.
I hope I can now continue with improving DUI
and get the first Beta version out soon.
I also hope to come up to leds for windows as I'm planing to do
some development on windows.

http://dui.sourceforge.net
http://leds.sourceforge.net

Ant

Am Wed, 17 Nov 2004 17:31:33 -0600 schrieb J C Calvarese <jcc7@cox.net>:

> Do you require a GUI library that works for Linux and Win32?
>
> If Linux alone is good enough, you might try DUI (it uses GTK+): http://dui.sourceforge.net/
>
> Ant, DUI's creator, is working on supporting Win32/GTK+. It sounds like he's close to releasing a new version of DUI that works with Windows, but I think he's still kicking the tires on it.

The main point of my post was that it's a pity that currently D is less cross-platform than C/C++. On the other hand, it's great to hear that work on D and its GUI libraries still goes on.
I decided to give D a try for my Morris project. I start with the engine stuff on the commandline, and then see what's available for GUI programming. Could take some time anyway... ;-)
Ah, by the way: As already mentioned, I come from the C programming language and always considered C++ as too difficult. Now that I start with D it seems to make sense to learn something about object oriented programming. But the tutorial at dsource.org doesn't cover the basics about object orientation with D (or I didn't find them?), and the official D documentation is not suitable for beginners.
Do I have to learn C++ first, anyway? ;-)

Mathias

On Thu, 18 Nov 2004 16:11:21 +0000, Ant wrote:

<snip>

> beside unimplemented features and a couple of bugs
> I had only types 2 complaints about DUI
> 1. it's a wrapper (can't to anything about it)
> 2. there are too many libs to install and link and whatever.
> 
> I spend the last few weeks trying to come up with a solution to the
> second problem:
> 1.a - I created an installer to unzip GTK+ dll files and the import libs
> (generated by implib). This is ridiculous! Every windows Gtk application
> has it's own Gtk+ installer. mine is no exception - I have to say
> something to the win32 Gtk guy. In addition there are several independent
> projects that only install Gtk. The windows Gtk community has to select
> one as the 'official' installer.
> 1.b - I'm finishing a GUI wrapper for the DMD compiler that imports
> and links with all the necessary libraries.

Are the windows Gtk+ libraries dll's?  If they are, you could simply do
what what Derelict and the mango icu port do:  runtime dynamic loading of
the function names from the dlls (using std.loader).  That way the
user doesn't even have to think about compile time linkage and gtk+
packages. You would just have to ensure that the dll's were installed.

Also std.loader works on both linux and win32 (while, it's not as critical on Linux, using std.loader there sure would make things easier). This would make DUI much more attractive to me and other's, I'm sure. I've avoided it for some time because of reason #2.

It would take more work, but the benefits would be significant. :-)

Later,

John

John Reimer wrote:
> Also std.loader works on both linux and win32

And Mac OS X! ("darwin")


GTK+ still sucks on Mac, though, but there is some progress:
http://gtk-osx.sourceforge.net/ (Carbon)
http://gtk-quartz.sourceforge.net/ (Cocoa)

Meanwhile the X11 version works, if you run the X11 server...
http://www.apple.com/macosx/features/x11/

--anders

In article <pan.2004.11.19.16.49.58.678433@yahoo.com>, John Reimer says...
>
>On Thu, 18 Nov 2004 16:11:21 +0000, Ant wrote:
>
><snip>
>
>Are the windows Gtk+ libraries dll's?  If they are, you could simply do
>what what Derelict and the mango icu port do:  runtime dynamic loading of
>the function names from the dlls (using std.loader).  That way the
>user doesn't even have to think about compile time linkage and gtk+
>packages. You would just have to ensure that the dll's were installed.

thanks, I'll look at that.

Ant