www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - ANN: DLI 0.1.2 ported to BeOS

reply "me" <memsom interalpha.co.uk> writes:
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 ;-)
Jun 26 2004
parent reply "me" <memsom interalpha.co.uk> writes:
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...)
Jun 27 2004
next sibling parent reply J C Calvarese <jcc7 cox.net> writes:
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/
Jun 27 2004
parent reply "me" <memsom interalpha.co.uk> writes:
"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
Jun 27 2004
parent J C Calvarese <jcc7 cox.net> writes:
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/
Jun 27 2004
prev sibling parent reply John Reimer <jjreimer telus.net> writes:
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
Jun 27 2004
next sibling parent "me" <memsom interalpha.co.uk> writes:
(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.
Jun 28 2004
prev sibling parent "me" <memsom interalpha.co.uk> writes:
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
Jun 28 2004