Okay, so I've ported DLI (latest version I could source on the 'Net) to BeOS (well Zeta RC3, but same difference.) This was no mean feat as there is some funky Linux specific code in it, I also struggled slightly with compilers (as BeOS has a limited set of options.) Phobos is a static lib rather than a shared one (as this didn't want to work - getting Phobos to compile at all meant a lot of hoop jumping and the eventual abandoning of aged makefiles..)

Okay, so you're all thinking "why doesn't he just use gdc" - well BeOS has only got a 2.95 compiler (and a C++ based API which makes it pretty much stuck at this level.) I sourced a gg3.4 build, which turned out to be far too broken to be an option. gcc3.4 does kind of build with 2.95, but the resulting compiler (at the stage when the makefile is trying to use xgcc to verify the compiler) fails to build an exe because gcc3.4 inserts a weird additional symbol into the object files (something like _gxx__personality__v0) which BeOS's ld can't understand (and we're stuck with this ld because bintools builds even more broken under BeOS.) Let's not even consider the d section of the process, as idgen and impcnvgen don't even build... lol. It's the UTF-8 stuff that does it, which is ironic given that BeOS uses UTF-8 exclusively.. I could almost cry ;-)

Anyway.. my version of dli - named bdc for no really good reason - will probably never evolve past a toy (unless some kind soul writes a d compiler in d), but I have achived something that I found pretty cool ;-)

Just to reply to myself - I altered the legacy Phobos with the dli source to mimic the current phobos structure. I took a couple of liberties, but it's more or less the same. I then altered a hard coded string that was causing anomolies in the name mangling/symbol resolution, and the new version now compiles and seems capable of building exe's.

At the moment the backend has two targets, nasm(w) and (g)as... I'm thinking
of adding a third one which will basically pile assembler into rough C
wrappers. This would then allow for adding features more quickly (by adding
C based implementations - something I can do more easily..)

I'm also going to add some of the missing features and get some of the anomolies ironed out.

I'm also probably going to make a Windows build as the sourcecode looks like it should compile. I've gourced some garbage collection code too, so that will wend it's way on to both platforms at some point (and it's a mark and sweep collector too, so will hopefully sit well with D proper.)

Features will then be added as and when I need them! I'm going to try and resist adding my own ideas in ;-)

(this is just in case anyone cares...)

me wrote:
> Just to reply to myself - I altered the legacy Phobos with the dli source to
> mimic the current phobos structure. I took a couple of liberties, but it's
> more or less the same. I then altered a hard coded string that was causing
> anomolies in the name mangling/symbol resolution, and the new version now
> compiles and seems capable of building exe's.

Sounds like fun.

> 
> At the moment the backend has two targets, nasm(w) and (g)as... I'm thinking
> of adding a third one which will basically pile assembler into rough C
> wrappers. This would then allow for adding features more quickly (by adding
> C based implementations - something I can do more easily..)
> 
> I'm also going to add some of the missing features and get some of the
> anomolies ironed out.

Does it compile any modern DMD features (like templates or mixins) or does it still only support the DMD language that was around back when Burton last released DLI. I'm guessing this is what you mean by "missing features", but I thought I might as well ask.

> 
> I'm also probably going to make a Windows build as the sourcecode looks like
> it should compile. I've gourced some garbage collection code too, so that
> will wend it's way on to both platforms at some point (and it's a mark and
> sweep collector too, so will hopefully sit well with D proper.)

I'm usually on Windows, so I'm in favor of you producing a Windows build. ;)

> 
> Features will then be added as and when I need them! I'm going to try and
> resist adding my own ideas in ;-)
> 
> (this is just in case anyone cares...)

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

"J C Calvarese" <jcc7@cox.net> wrote in message news:cbnnub$1pt2$1@digitaldaemon.com...

> Sounds like fun.

It was not fun ;-) More necessity!! Once the legacy was removed (e.g. c.XXX -> std.c.XXX, XXX -> std.XXX or internal.XXX) the symbol resolution stopped working. The legacy stuff seems to have prefixed "phobos" to every symbol representing a function (if not every symbol - I didn't delve too deeply) and this just didn't work anymore. I had to alter to "std", but I suspect when I hit an "internal" item, it'll throw a fit for that (do we ever need to import internal.* in user apps?)

> > I'm also going to add some of the missing features and get some of the anomolies ironed out.
>
> Does it compile any modern DMD features (like templates or mixins) or does it still only support the DMD language that was around back when Burton last released DLI. I'm guessing this is what you mean by "missing features", but I thought I might as well ask.

As I have only worked on it since Thursday afternoon (5 or 6 hours total as I wasted a lot of time on Saturday failing to get gcc to build on Zeta) it's still prety much Burton's code. So no new features :-(

Though, reading some old posts about gdmd from Walter, it seems templates may be possible as they seem to be completely handled in the front end. Just a case of me porting over the front end code as it stands now then, I guess.

> I'm usually on Windows, so I'm in favor of you producing a Windows build.
;)

Me too. It'll speed things along as I'm more likely to steal a few hours at lunch etc whilst working at my day job. I also have a far better sourcecode comparison tool (Beyond Compare) available to me!

My main plan is to finish some of the parts stopping phobos (in its legacy form) from compiling.. adding in native BeOS threading support and Sockets support (should be fairly simple - there are two versions of the netstack, and one is BSD based and should probably be compatible with Linux.) I'll also add in a "beos" and/or "zeta" platform define. At the moment "linux" is defined - which could be causing some of the issues to be honest!!

Matt

me wrote:

> Just to reply to myself - I altered the legacy Phobos with the dli source to mimic the current phobos structure. I took a couple of liberties, but it's more or less the same. I then altered a hard coded string that was causing anomolies in the name mangling/symbol resolution, and the new version now compiles and seems capable of building exe's.
> 
> At the moment the backend has two targets, nasm(w) and (g)as... I'm
> thinking of adding a third one which will basically pile assembler into
> rough C wrappers. This would then allow for adding features more quickly
> (by adding C based implementations - something I can do more easily..)
> 
> I'm also going to add some of the missing features and get some of the anomolies ironed out.
> 
> I'm also probably going to make a Windows build as the sourcecode looks like it should compile. I've gourced some garbage collection code too, so that will wend it's way on to both platforms at some point (and it's a mark and sweep collector too, so will hopefully sit well with D proper.)
> 
> Features will then be added as and when I need them! I'm going to try and resist adding my own ideas in ;-)
> 
> (this is just in case anyone cares...)

Yes, this is fascinating, all right.  I haven't been using BeOS for awhile but I follow the opensource developments, ie OpenBeos -> Haiku.  I bought one of the original releases of BeOS (3 I believe) many years ago when it's hardware compatibility was very limited (Matrox cards, etc).  I'll probably give BeOS a try again sometime; I usually try to install it in my Virtual PC emulator every now and again.  I used to install 4 or 5 different OSes on my desktop, but eventually got tired of the partitioning issues that would crop up.

I must admit I was a little surprised to see that someone had ported DLI to BeOS;  I just wasn't sure what to say.  That compiler is VERY outdated! But then again perhaps its the best/easiest place to start for porting the D language to BeOS.  You seem to have made some phenomenal headway with it. So just maybe it can slowly catch up in language features to the current language specs.

BeOS isn't what you would call a incredibly popular OS anymore, but it's still a fun hobbiest OS.  I think D's use on it may be a pretty limited though.  Since the API in BeOS is C++, getting D to interoperate with it's GUI won't be easy. Nonetheless congrats on your accomplishment! I'd like to play with it a bit when I get the chance.

Later,

John

me wrote:
> "J C Calvarese" <jcc7@cox.net> wrote in message
> news:cbnnub$1pt2$1@digitaldaemon.com...
> 
>>Sounds like fun.
> 
> It was not fun ;-) More necessity!! Once the legacy was removed (e.g.
> c.XXX -> std.c.XXX, XXX -> std.XXX or internal.XXX) the symbol resolution
> stopped working. The legacy stuff seems to have prefixed "phobos" to every
> symbol representing a function (if not every symbol - I didn't delve too
> deeply) and this just didn't work anymore. I had to alter to "std", but I
> suspect when I hit an "internal" item, it'll throw a fit for that (do we
> ever need to import internal.* in user apps?)

I guess I meant the whole project sounds like fun. But I guess the whole project is necessary for using D on BeOS.

>>>I'm also going to add some of the missing features and get some of the
>>>anomolies ironed out.
>>
>>Does it compile any modern DMD features (like templates or mixins) or
>>does it still only support the DMD language that was around back when
>>Burton last released DLI. I'm guessing this is what you mean by "missing
>>features", but I thought I might as well ask.
> 
> 
> As I have only worked on it since Thursday afternoon (5 or 6 hours total as
> I wasted a lot of time on Saturday failing to get gcc to build on Zeta) it's
> still prety much Burton's code. So no new features :-(
> 
> Though, reading some old posts about gdmd from Walter, it seems templates
> may be possible as they seem to be completely handled in the front end. Just
> a case of me porting over the front end code as it stands now then, I guess.

I'm under the impression that many cool things are magically handled by the front end. I'm sure there will be some tricky parts, but you might be able to get some hints from David Friedman's GDC project.

>>I'm usually on Windows, so I'm in favor of you producing a Windows build.
> 
> ;)
> 
> Me too. It'll speed things along as I'm more likely to steal a few hours at
> lunch etc whilst working at my day job. I also have a far better sourcecode
> comparison tool (Beyond Compare) available to me!

I've never used Beyond Compare. I have used used WinMerge (http://winmerge.sourceforge.net/). It seems to work well for me. The price is right for a cheep guy like me.

> 
> My main plan is to finish some of the parts stopping phobos (in its legacy
> form) from compiling.. adding in native BeOS threading support and Sockets
> support (should be fairly simple - there are two versions of the netstack,
> and one is BSD based and should probably be compatible with Linux.) I'll
> also add in a "beos" and/or "zeta" platform define. At the moment "linux" is
> defined - which could be causing some of the issues to be honest!!
> 
> Matt 

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

(oops.. hit "reply sender" not "reply group".. sorry John)

> Yes, this is fascinating, all right.  I haven't been using BeOS for awhile but I follow the opensource developments, ie OpenBeos -> Haiku....

BeOS/Zeta are in a weird place at the moment. If Zeta picks up pace, things could get intersting again, but Haiku is the great hope. Interestingly for me, Haiku R1 (possibly 2+ years away) will be BeOS R5.03 binary compatible. This means that they'll need to use a GCC 2.95 level compiler to support the C++ ABI at BeOS R5 (released in 2000) used. Therefore the exact same GCC issues happen even then :-(


> I must admit I was a little surprised to see that someone had ported DLI
to
> BeOS;  I just wasn't sure what to say.

Yeah I agree. It was a shock for me when, after struggling for a while on Wednesday and Thursday with GCC3.4 and 3.3.4, I saw dli mentioned for the first time in the newsgroups here. I eyeballed the code and saw no reason why it wasn't going to compile, so I ran with it. I'm still interested in getting gdc to compile - it *should* work, it's just odd things in the C that stop it. I think it's partially to do with the difference between C++ and C... I think BeOS's GCC sees the .c and .cc files as plain C, and this is causing some of the issues. Certainly all of Burton's code is in .cpp files and frightingly similar code *just compiles*. If I could get GCC 3.X to build, sans D, I'd make more effort. As I can't yet do that, I'm not going to make additional effort. Coding is more my style, so dli is suiting me more at the moment.

> That compiler is VERY outdated! But then again perhaps its the
best/easiest
> place to start for porting the D language to BeOS.  You seem to have made some phenomenal headway with it. So just maybe it can slowly catch up in language features to the current language specs.

As it stands, dli is a subset of the current language - this is how it'll be billed. After getting all the stuff that's there to work, I'll start looking at integrating the current 9.X front end code. This may well give me some features (templates for example) for free.

> BeOS isn't what you would call a incredibly popular OS anymore, but it's still a fun hobbiest OS.  I think D's use on it may be a pretty limited though.  Since the API in BeOS is C++, getting D to interoperate with it's GUI won't be easy.

True, but there's also a Pascal project, which odly I started, which is in the same boat. Believe me, it's not as big a problem as you'd think ;-)

Besides.. I managed to source a slightly working but severly problematic prebuild GCC3.4 (absolutely no help in *building GCC3.x  as "gcc -g ..." creates code that BeOS version of the ld can't handle..) I started wrapping the BeAPI in C that night. I forsee this being useful to D too!

Matt

> Nonetheless congrats on your accomplishment! I'd like to play with it a bit when I get the chance.

English is my first language, honest... I had my 2yo daughter attempting to press keys whilst typing that message. Rereading it it is somewhat incoherent ;-)

> Besides.. I managed to source a slightly working but severly problematic prebuild GCC3.4 (absolutely no help in *building GCC3.x  as "gcc -g ..." creates code that BeOS version of the ld can't handle..) I started
wrapping
> the BeAPI in C that night. I forsee this being useful to D too!

To make it clearer; I started the GUI section of the BeFPC (now BePascal) project about 2002. I did a large proof of concept code wrapping/flattening exercise, which worked quite well. I stood down from active development circa September 2002, and they took a completely incompatible routce from then on it - nicer approach, useless for non-Pascal implementations. Shame really, because otherwise it would be usable by now.

> > Nonetheless congrats on your accomplishment! I'd like to play with it a bit when I get the chance.

(Forgot to reply to this.. LOL)

It'll go up on BeBits in a while - mainly when it will compile stuff a little better. The compiler works, but it sometimes crashes if a declaration is wrong (there are places, for example, where modules use declarations like "c.string" but now it should be "std.c.string" and I have to weedle ot a few of the more subtly of these unfortunately.) stdio.d fails to compile too, which is a shame.

Matt