how it the SWT port going?

I a week or two I'll finish a big project at work
and take a few weeks (2003) vacations. I would like to help.

Beside partial implementation of interfaces on abstract classes how did you solve the other java->D conversion problems:

- How automatic did you made the conversion?

- library
did you create a lib with String, Vector and other very common
java classes (I would have done so, Walter expressed disagreement)

and mostly I'm curious on how to you do the static initializations
(I don't think is called static initialization, here is the example):
class A
{
   B b = new B();    // illigal in D (right?)
   public A()
   {
      //
   }
}

Ant

Ant,

We welcome the help.  John and I have sporadic time to work on it, and are using it to teach ourselves OO and D.  We are by no means experts, so if we ever get anywhere with this, we are going to need some experts to get into our code and fix our bonehead mistakes.  I realize that posting some of our progress may scare the hell out of some people who may want to use this lib in the future, but here goes:

<comments embedded>


Ant wrote:
> how it the SWT port going?

Ugh.  John is tweaking the makefile to see if we can get around the forward references (remember those from your earlier posts with Lars?).  I'm just trying to get the thing to compile with our Hello World app.

> 
> I a week or two I'll finish a big project at work
> and take a few weeks (2003) vacations. I would like to help.

Sweet.  Send me an email and I'll get you set up to check out the code from our Subversion server.  There's also a forum up and running so we can keep track of our questions and not bother the NG here.

> 
> Beside partial implementation of interfaces on abstract classes
> how did you solve the other java->D conversion problems:
> 
> - How automatic did you made the conversion?

Beyond doing a find/replace for the following, the conversion has been totally manual:

boolean --> bit  (could have used aliased bool)
String --> char[]
SWT --> DWT  (mostly consts and exception names)
static {} --> commented out
instanceof --> marked with TODO: (John may have one of these done in point.d or rectangle.d somewhere, using typeof)
array initialization { } --> [ ]
listeners --> commented out, waiting for delegates
classes as structs --> kept them classes for now, but may convert later.

Also, I have only worked on the Win32 port, and we will have a bunch of work using the version() {} construct in D when it comes time to fold in linux (gtk+).  John is working on linux some, and I know your preference.  I just don't have access to a linux box right now...


> - library
> did you create a lib with String, Vector and other very common
> java classes (I would have done so, Walter expressed disagreement)

We did not choose to make libs/utils with common Java classes (String, Vector), but wanted to port to the D way (i.e. try to go with Walter's thoughts).


> and mostly I'm curious on how to you do the static initializations
> (I don't think is called static initialization, here is the example):
> class A
> {
>    B b = new B();    // illigal in D (right?)
>    public A()
>    {
>       //
>    }
> }
>

Not sure what you're getting at here.  Maybe you could look at the code when your project is done...


> Ant
> 
> 

Brad Anderson wrote:

> 
> Ugh.  John is tweaking the makefile to see if we can get around the forward references (remember those from your earlier posts with Lars?).  I'm just trying to get the thing to compile with our Hello World app.

Hmm, if you are interested in using A-A-P recipes instead of makefiles,
you can do as such:

(Assuming you are making a dll, although static libs are made the same way):

"
:dll {onestep} dswt : sources
"

The {onestep} argument compiles all the files at once instead of one by
one. With dmd, this is both faster and removes many forward reference
problems. Sadly, it makes it more troublesome to find some types of
errors due to a limitation in dmd.

The forward reference problem itself should be possible to remove by
using private imports, but since it don't I assume it's a bug (it is
IMHO).

Lars Ivar Igesund

"Ant" <Ant_member@pathlink.com> wrote in message news:c1asee$t82$1@digitaldaemon.com...
> (I don't think is called static initialization, here is the example):
> class A
> {
>    B b = new B();    // illigal in D (right?)
>    public A()
>    {
>       //
>    }
> }

class A
{
    static C c;
    B b;
    this() { b = new B(); ... }        // for dynamic members
    static this() { c = new C(); }    // for static members
}

On Sun, 22 Feb 2004 18:29:35 +0000, Ant wrote:

> how it the SWT port going?

Brad is responsible for the majority of what's been done already. I've just been helping out here and there as I can.

As Brad mentioned, recently I've been working on a comprehensive make file.  There have been major headaches with forward references throughout the dwt code (apparently acceptable in Java), and I've been trying to set up the makefile just so. D is quite intractable when it comes to forward references and file arrangement. It's by far one of the most frustrating and NON-user friendly aspects of the language.  I've experimented and found that d doesn't even allow forward references with definitions that appear in the same file.  Private imports have only solved a small subset of the problems.  Unfortunately a large portion of the classes in SWT are highly interdependent.  There are forward references all over the place with inheritance and aggregates.

> I a week or two I'll finish a big project at work and take a few weeks (2003) vacations. I would like to help.

If the SWT port is of much interest to people, we desperately need experienced developers to help work on DWT.  Your experience with DUI will be particularly invaluable because of all the troubleshooting you've done on similar issues already.  Even if nobody was really interested in this project, Brad and I decided that we would just continue on as best we could, and learn as we go.  We figured we just won't advertise our work to get hopes up unnecessarily.  If we get more help, it may actually turn into something useful to everyone.

> Beside partial implementation of interfaces on abstract classes how did you solve the other java->D conversion problems:

To be honest, our primary goal was just getting things to compile.  We dealt very little with the actual details of the conversion although in some places the changes necessary were obvious and necessary.  Some interfaces and abstract classes should be easily converted.  Some may be trouble.  I certainly underestimated the difficulty of the project even though there are plenty of similarities to D in the Java code.

> - How automatic did you made the conversion?

No automation currently.  It's all done by hand.

> - library
> did you create a lib with String, Vector and other very common java
> classes (I would have done so, Walter expressed disagreement)

We have a template string class that's been borrowed from another project (I believe by Christopher Miller). It was to take the place of the Java String class.  It doesn't work flawlessly in all instances.  There are some significant conflicts that I've noticed.  As for other java utility classes, they should be replaceable with d designed ones.  That's one of the lesser issues, I think.  We just need consensus on what to do here.

> and mostly I'm curious on how to you do the static initializations (I
> don't think is called static initialization, here is the example): class
> A
> {
>    B b = new B();    // illigal in D (right?) public A() {
>       //
>    }
> }

We haven't worried about such issues unless they show up as dmd compile errors.  Valid or not, our technique has been to try to get as much compiled as possible, and deal with errors as they show up in the compile process.  There are likely plenty of logic/conversion errors undiagnosed as a result.  Some are obvious. Some are subtle.

So far, the issue you describe above has not really surfaced.

Later,

John

John Reimer wrote:
> If the SWT port is of much interest to people, we desperately need
> experienced developers to help work on DWT.  Your experience with DUI will
> be particularly invaluable because of all the troubleshooting you've done
> on similar issues already.  Even if nobody was really interested in this
> project, Brad and I decided that we would just continue on as best we
> could, and learn as we go.  We figured we just won't advertise our work to
> get hopes up unnecessarily.  If we get more help, it may actually turn
> into something useful to everyone.

Is there someplace I can download a snapshot?  I wouldn't mind taking a crack at it.

>>- How automatic did you made the conversion?
> 
> No automation currently.  It's all done by hand.

eek.  sed is awesome.


 -- andy

On Sun, 22 Feb 2004 20:07:13 +0100, Lars Ivar Igesund wrote:

> Brad Anderson wrote:
> 
> 
>> Ugh.  John is tweaking the makefile to see if we can get around the forward references (remember those from your earlier posts with Lars?). I'm just trying to get the thing to compile with our Hello World app.
> 
> Hmm, if you are interested in using A-A-P recipes instead of makefiles, you can do as such:
> 
> (Assuming you are making a dll, although static libs are made the same
> way):

We currently have not even considered a dll.  The primary goal is to get a static lib built first.  A makefile was a way for us to learn about how they were built. It was quite educational :).  By all means, if you find an easier, better way, go for it.

> "
> :dll {onestep} dswt : sources
> "
> 
> The {onestep} argument compiles all the files at once instead of one by one. With dmd, this is both faster and removes many forward reference problems. Sadly, it makes it more troublesome to find some types of errors due to a limitation in dmd.

We tried single step compile.  As you know, this is useless for dealing with the forward references especially in dwt.  I'm currently using a combined file build step in the makefile (as originally Brad was to). This eliminated about half of the current forward references; but, because of the significance of interdependence in swt, it could not remove them all. I tried many permutations of file compile order which also didn't make it work (it some situations it did).

> The forward reference problem itself should be possible to remove by using private imports, but since it don't I assume it's a bug (it is IMHO).

Private imports didn't even fix the issues we had in this situation.  They may have improved it a bit, but, believe me, it's bad.  I vacillated between frustration with the d compiler and what I decided must be java OOP spaghetti.

> Lars Ivar Igesund

In article <pan.2004.02.22.23.02.23.100448@telus.net>, John Reimer says...
>

>Private imports didn't even fix the issues we had in this situation.

It's common believe that the "private" for imports is broken.

Did you move the imports to inside the class bodies?
(of course leave the super class and interfaces out of the class)

That might help (It worked for me)
it seems to make scope of the
import the same as any member of the class.

Ant

> 
> 
> It's common believe that the "private" for imports is broken.
> 
> Did you move the imports to inside the class bodies?
> (of course leave the super class and interfaces out of the class)
> 
> That might help (It worked for me)
> it seems to make scope of the
> import the same as any member of the class.
> 
> Ant
> 

No, I hadn't tried that yet.  Though, after reading some of your experiences, I was planning on doing that but fogot.

I think Brad tried this already.  I'll try it later and see if it helps.
Frankly, though, that doesn't seem a very intuitive use of D, unless you can clarify why it works.  I won't complain too much if it works, though.

> 
> Is there someplace I can download a snapshot?  I wouldn't mind taking a crack at it.
>

Talk to Brad.  He's the one maintaining the project files.  I just sent him my changes earlier today.

>>> - How automatic did you made the conversion?
>>
>>
>> No automation currently.  It's all done by hand.
> 
> 
> eek.  sed is awesome.

Our handle of advanced tools is not our forte yet.  We started the project to learn, even if it is the hard way ;-).

Later,

John