www.digitalmars.com         C & C++   DMDScript  

D - Announce leds 00.07 for linux ( and java to D)

reply Ant <Ant_member pathlink.com> writes:
I uploaded some improvements to leds (still Linux only).
This release is aimed to make leds more user friendly.

You need DUI 00.09_85 to go with it.

see the manual at:
http://leds.sourceforge.net/userManualPage.html

get it at:
http://sourceforge.net/projects/leds

main page at:
http://leds.sourceforge.net/

have fun.

------------------

Java support.
The leds D parser now understands java.
Actually it just knows that package is module and that the constructores
names are not 'this'.
The idea was to parse a java source file and save it as D.

I still think we should create D Vector and String classes.
that will be easy and save us a lot of trouble on the conversion)
java hash tables should be easy to convert to object[object]
or something like that.
For the D gui project, and in fact any java conversion,
it would be smart to have quite a few of java "basic" classes
implemented in D. That will depend on the project but I'm
foreseeing a wide D implementation of java.lang, java.util
maybe io and... I guess Walter won't like the idea but a 
full D implementation of the java core packages could
be a good thing (I'm familiar with java, and not with
python so maybe the java libs aren't as good as I think
but a lot of java already exists out there).

The idea of using my D parser is that it understands the
structure of the java code (as it is a subset of D,
well not really but the only thing I can remember that
D doesn't support are the java static initializations;
maybe putting them in a method to be called by
all constructores that don't have a call to other constructor(?))
If we understant the code structure the conversion
could be done at 2 levels, structure and function bodies,
that might be essencial.
I'm not sure it's a good idea. A few new projects to parse D
were announced recently. Maybe one of those could better
be adapted for this task. Mine was design to understand
only the outline of a program.

nevertheless under the "Tools" menu there is an item "new as D".
Open a java source file and "new as D" will create a new buffer
with package replaced by module and the constructores names
replaced (maybe, can't remember).
(my parseD package can be compiled independently of leds
with a couple lines commented out an a new main function)

The first problem are the comments. The parser was designed to
remember the doc comments only (/** */). patches are in but
not complete.

I'm not too confident about this my idea of java to D... :(

This efford, even if useless for java to D conversions,
was good for leds because it showed that java support
is easy to implement for leds.
That will broden the potencial users base of leds.

Ant
(did I write all that!?)
Jan 31 2004
parent reply "Ben Hinkle" <bhinkle4 juno.com> writes:
Glad to see you are still posting and contributing!

"Ant" <Ant_member pathlink.com> wrote in message
news:bvgtpm$28bk$1 digitaldaemon.com...
 I uploaded some improvements to leds (still Linux only).
 This release is aimed to make leds more user friendly.

 You need DUI 00.09_85 to go with it.

 see the manual at:
 http://leds.sourceforge.net/userManualPage.html

 get it at:
 http://sourceforge.net/projects/leds

 main page at:
 http://leds.sourceforge.net/

 have fun.

 ------------------

 Java support.
 The leds D parser now understands java.
 Actually it just knows that package is module and that the constructores
 names are not 'this'.
 The idea was to parse a java source file and save it as D.

Fun, but that sounds hard to do. Is the generated code readable? I've run Pascal code through a Pascal-to-C converter (Google on p2c or something like that) and an important part is adding comments in the generated code that point back to the source. That way humans can go through it afterwards and make sense of it all. As you say below, the hardest part will be figuring out what to do with the library calls.
 I still think we should create D Vector and String classes.
 that will be easy and save us a lot of trouble on the conversion)
 java hash tables should be easy to convert to object[object]
 or something like that.

Personally
 For the D gui project, and in fact any java conversion,
 it would be smart to have quite a few of java "basic" classes
 implemented in D. That will depend on the project but I'm
 foreseeing a wide D implementation of java.lang, java.util
 maybe io and... I guess Walter won't like the idea but a
 full D implementation of the java core packages could
 be a good thing (I'm familiar with java, and not with
 python so maybe the java libs aren't as good as I think
 but a lot of java already exists out there).

What does the "mapping" of J2SE to Phobos look like? I haven't tried to match packages up to modules.
 The idea of using my D parser is that it understands the
 structure of the java code (as it is a subset of D,
 well not really but the only thing I can remember that
 D doesn't support are the java static initializations;
 maybe putting them in a method to be called by
 all constructores that don't have a call to other constructor(?))
 If we understant the code structure the conversion
 could be done at 2 levels, structure and function bodies,
 that might be essencial.
 I'm not sure it's a good idea. A few new projects to parse D
 were announced recently. Maybe one of those could better
 be adapted for this task. Mine was design to understand
 only the outline of a program.

 nevertheless under the "Tools" menu there is an item "new as D".
 Open a java source file and "new as D" will create a new buffer
 with package replaced by module and the constructores names
 replaced (maybe, can't remember).
 (my parseD package can be compiled independently of leds
 with a couple lines commented out an a new main function)

 The first problem are the comments. The parser was designed to
 remember the doc comments only (/** */). patches are in but
 not complete.

 I'm not too confident about this my idea of java to D... :(

It seems like a big job, but go for it if you want to. Maybe a smaller goal would be to have a partial translator and a document aimed at Java programmers describing how to switch to D from Java. Kindof like the semi-tutorials about switching to D from C and C++ that Walter has in the D documentation.
 This efford, even if useless for java to D conversions,
 was good for leds because it showed that java support
 is easy to implement for leds.
 That will broden the potencial users base of leds.

 Ant
 (did I write all that!?)

Jan 31 2004
parent Ant <Ant_member pathlink.com> writes:
In article <bvh0v3$2dj9$1 digitaldaemon.com>, Ben Hinkle says...
Glad to see you are still posting and contributing!

"Ant" <Ant_member pathlink.com> wrote in message
news:bvgtpm$28bk$1 digitaldaemon.com...
 Java support.
 The leds D parser now understands java.
 Actually it just knows that package is module and that the constructores
 names are not 'this'.
 The idea was to parse a java source file and save it as D.

Fun, but that sounds hard to do. Is the generated code readable?

Absolutly! it's surprising how java looks so much as a D subset! I'm not concerned about formating there are enough utils out there for that. Eventually leds will have it's own as an addition to the code parser.
I've run
Pascal code through a Pascal-to-C converter (Google on p2c or something like
that) and an important part is adding comments in the generated code that
point back to the source. That way humans can go through it afterwards and
make sense of it all.

I don't think we need to do it from java to D... It's very similar.
As you say below, the hardest part will be figuring out what to do with the
library calls.

 I still think we should create D Vector and String classes.
 that will be easy and save us a lot of trouble on the conversion)
 java hash tables should be easy to convert to object[object]
 or something like that.

Personally
 For the D gui project, and in fact any java conversion,
 it would be smart to have quite a few of java "basic" classes
 implemented in D. That will depend on the project but I'm
 foreseeing a wide D implementation of java.lang, java.util
 maybe io and... I guess Walter won't like the idea but a
 full D implementation of the java core packages could
 be a good thing (I'm familiar with java, and not with
 python so maybe the java libs aren't as good as I think
 but a lot of java already exists out there).

What does the "mapping" of J2SE to Phobos look like? I haven't tried to match packages up to modules.

uggly. phobos is a mixure of procedural on OO !? At first I thought phobos was suppose to be a very low level lib and that an OO lib would be created on top of it. That's not the case obviously.
 The idea of using my D parser is that it understands the
 structure of the java code


 If we understant the code structure the conversion
 could be done at 2 levels, structure and function bodies,
 that might be essencial.
 I'm not sure it's a good idea.

It seems like a big job, but go for it if you want to.

I have enough projects already but it might not be that difficult... not aiming for 100% conversion, the last 10% might be very complex, human intervention would be needed after. Anyway java support for leds is climing up on the priority list. Ant
Jan 31 2004