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!?)

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!?)
>
>

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