FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

SWT 3.0 Released
Goto page 1, 2  Next
 
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT
View previous topic :: View next topic  
Author Message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sat Jun 26, 2004 12:59 pm    Post subject: SWT 3.0 Released Reply with quote

Eclipse 3.0 final has been released and with it the SWT 3.0 final.

Perhaps we should consider syncing with this version?
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun Jun 27, 2004 2:28 pm    Post subject: Reply with quote

I think we should switch. But it may be worth doing a diff and seeing how much it's changed since M6. I say this, because there's a fair amount of work already put into the implementation of 3.0M6 code to DWT. We may even want to get our M6 working (to an extent) in DWT and then do the port, rather than waste more time scrapping what we have.

What would be even more fabulous is a tool that reads the SWT code and converts it into DWT, but that's probably a pipe-dream.

Can we get more people working on /branches/0.1 where I think we are closest to getting a Hello World example to work?

In my post to Yuriy on DWT Status thread, I think we need:

1. version blocks instead of OS.isUnicode type properties.

2. Merge #1 into our conversion of Java classes to D structs

3. Delegates for the event sub-system.

I can work on #1 and #2, but would want someone else to take the lead on #3.

Thoughts?
_________________
I really like the vest!
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Sun Jun 27, 2004 3:26 pm    Post subject: Reply with quote

Man, a conversion tool would be VERY nice, but beyond my know-how ATM. I guess we can just stick to what we've got now, but be ready for a change to 3.0 release sometime soon.

I'll help on the 0.1 branch because that's where the majority of the work has been done anyway.

#3 is a tough one for me because the event system is a little tricky and I'm not sure how to make things "thread-safe." I have no real experience with threads and event-system design so I'm not too sure if I'm doing things "right" (and the Java approach does not translate directly across to D... nor should). I can start plugging away at the problem again, but it sure would be nice to have more experienced help backing me up. I guess, for now, I can try progressing with my original ideas. Then people can start improving, changing or updating from there. Last time, I started the large task of reading up on different event systems to see where D fits in. It's an interesting deal here, because of the new opportunities to use D capabilities. I remember looking at a number of different toolkits like (like Fox and wxWidgets) to help me get a perspective on these things; I was totally disgusted by there copious use of C++ macro for message maps. I guess C++ is far from accomodating in implementing an event system smoothly -- so ugly preprocessor macros are used. Delegates and d change much of that, thankfully.

By the way, Brad, how far have you got the dwt library compiling? Are there still forward reference errors? Or are we passed that now?

Later,

John
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Sun Jun 27, 2004 4:50 pm    Post subject: Reply with quote

Still Forward References, but it's a function of a downstream file not compiling. If we can get every file compiling, I think the issues go away.
_________________
I really like the vest!
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Sun Jul 25, 2004 11:14 am    Post subject: Reply with quote

brad wrote:
1. version blocks instead of OS.isUnicode type properties.

Just a tiny note.

SWT as it is, makes the decision whether to work with Unicode or ASCII at runtime as opposed to compile-time. I'm not sure whether there's much of a performance impact, but the result is that it does not require a recompile to work on Windows 9x.

Switching to version blocks would change this, obviously.
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
stonecobra



Joined: 25 May 2004
Posts: 48
Location: Rough and Ready, CA

PostPosted: Tue Aug 10, 2004 12:42 pm    Post subject: Reply with quote

brad wrote:
What would be even more fabulous is a tool that reads the SWT code and converts it into DWT, but that's probably a pipe-dream.


I know it is a pipe dream, but I have started one (java to D converter).

Do you guys want to try what I have?

It still needs a lot of hand holding, but it does get most of the major syntax stuff right.

Oh yeah, it also wipes out all comments (don't know if that is good or bad for DWT).

Scott
Back to top
View user's profile Send private message
brad
Site Admin


Joined: 22 Feb 2004
Posts: 490
Location: Atlanta, GA USA

PostPosted: Tue Aug 10, 2004 12:53 pm    Post subject: Reply with quote

Yes, we'd like to try it. However, I've been really struggling for free time recently.

Sad

Maybe JJR or Yuriy would like to give it a go??
_________________
I really like the vest!
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Tue Aug 10, 2004 2:57 pm    Post subject: Reply with quote

Hi guys. I'm back. This time I'm taking matters on my job after a rest. I'm starting work with DWT this week a little and I hope to have more time on the next week.

brad wrote:
Yes, we'd like to try it. However, I've been really struggling for free time recently.
Maybe JJR or Yuriy would like to give it a go??

I can try it. Don't think it'll help much but... who knows? I'm interested if 'lib/tool' can be additionally configured and how easy to do it (I'm not very famous in XSLT)? We know some specific places in DWT where 'conversion routine' might be 'tweaked' a much obviously.

Also I can take a look to the changes between 'old SWT' and 'SWT 3.0' for the DWT converted files. If it's worth to 'start from the stratch of 3.0' <g> or better to find differences 'by hands'.

andy wrote:
SWT as it is, makes the decision whether to work with Unicode or ASCII at runtime as opposed to compile-time. I'm not sure whether there's much of a performance impact, but the result is that it does not require a recompile to work on Windows 9x.

I think Andy is right.

Did someone succeed in the DWT linking? I've read JJR posts about linking but didn't understand if he has succeeded in it at last. Also I didn't see changes in the svn....\internal\win32 mentioned by JJR ('external' moved out of OS.d).

I see in the 'DMD 0.98 changelog': Fixed name mangling of D __import__ symbols from DLLs.
Does this change has some effect on DWT? It seems to me - 'NO'.

I haven't tried compile DWT using 0.98 yet. How is it now?

stonecobra wrote:
It still needs a lot of hand holding, but it does get most of the major syntax stuff right.

The sintax itself is not a very big problem. As I remember the first sintax changes was: 'boolean' -> bit, SWT... -> DWT... But the rest part of conversion is really hard.

I can write the 'main global conversion rouine' for SWT to -> DWT as:
1. convert in the dwt\internal\win32 classes to the Structs (now it's types.d)
2. change in the dwt\internal\win32\os.d 'calling conventions' for the 'system calls' and 'external' function into the 'pointers to structs' (but it's not all)
3. add all 'simplifying utility classes'
4. make a lots of changes in the rest of classes (dwt\graphics, dwt\widgets) - it's a HUGE work Sad. This point has some 'typical java->D conversion places' I won't mention them now but I think they can be expressed as 'something like a templates'. I don't mean 'D templates' of course but something similar to 'text templates' which could be 'converted smartly'.

stonecobra wrote:
Oh yeah, it also wipes out all comments (don't know if that is good or bad for DWT).

I think it's bad for DWT. Sometimes they can help to find 'code place' (as for me) and they will help in 'DWT documenting' in the future.
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Tue Aug 10, 2004 7:10 pm    Post subject: Reply with quote

Blandger wrote:
Did someone succeed in the DWT linking? I've read JJR posts about linking but didn't understand if he has succeeded in it at last. Also I didn't see changes in the svn....\internal\win32 mentioned by JJR ('external' moved out of OS.d).


My posts were rather confusing. I thought I succeeded it linking at first but then realized that I actually didn't succeed. I managed to compile and create a dwt.lib file, but any attempt to link that file to the hellodwt sample app showed tons of link errors. DWT still has some undefined symbols, almost all of which consist of Win32 functions that are either incorrectly defined in the OS.d or are not correctly linked with external win32 libs. I've solved a very small number of the undefined symbol errors by linking more win32 libraries on the command line with dwt.lib.

Another problem is that the OS.d module is literally a mess. First the bool type was incorrectly being used in all extern(windows) function declarations instead of BOOL. I fixed that. Then there was the problem that none of the win32 functions can be declared inside the class without making correct external linkage impossible. I had to move all the extern windows functions out of the OS class and into another module by itself and then import it internally to the class to make these functions accessible locally without having to fully qualify them. Unfortunately, internal class imports are considered bad practice now because of the way D performs name resolution. So it would be better to have an external import and then local aliases or fully qualified win32 function calls within OS.d. Yet another problem is that OS.d is not the only class that tries to make direct use of the win32 functions. Other dwt classes make direct reference to OS.winfunc() type calls thus forcing all winfunc calls to be recognized as members of the OS class. We may have to change all such references to actual win32 (ie, not part of the OS class) calls all throughout DWT to make things work smoothly. Really what should be done is just modify the DWT source and import a complete ready-made windows import that we can count on.

One more issue is the strange declarations of an overloaded windows function within the extern(Windows) group called MoveMemory(). There's a long list of variations. This makes no sense! But all variations of this function are used throughout the DWT source. It will take some manipulation to fix this issue. Step one would be to declare the single proper extern windows function, then create several seperately overloaded MoveMemory() functions as part of the OS class that call the actual win32 MoveMemory. As its stands now, it would never work or link properly.

Blandger wrote:
I see in the 'DMD 0.98 changelog': Fixed name mangling of D __import__ symbols from DLLs.
Does this change has some effect on DWT? It seems to me - 'NO'.

I haven't tried compile DWT using 0.98 yet. How is it now?


I haven't tried it either. I'll probably give it another go later on today. But I don't expect a whole lot of changes until we fix some of the big issues currently in OS.d.

I'll comment on some of the other issues later. Some ot the changes I made, includeing a brand new makefile that I use to compile DWT have not made it to the SVN repository yet. This is because I made so many changes that I was afraid I might mess the current state up. If you are interested in seeing these changes I can perhaps forward them to you or just take the plunge and update the SVN. It's up to you. The makefile at least will be a good solid addition. Right now, I'm primarily concerned about the current state of the MoveMemory problem because without that being fixed their will be no such thing as a linkable dwt.lib.

Sorry for the long post. I think I covered most of the issues I ran it to. After getting frustrated with it again, I haven't touched the thing for about a week.

Later,

John R.
Back to top
View user's profile Send private message
andy



Joined: 15 Mar 2004
Posts: 71

PostPosted: Wed Aug 11, 2004 9:47 am    Post subject: Reply with quote

JJR wrote:
Unfortunately, internal class imports are considered bad practice now because of the way D performs name resolution. So it would be better to have an external import and then local aliases or fully qualified win32 function calls within OS.d.


This isn't a big deal at all.

It's "bad practice," but the OS class is never instantiated or subclassed, so there's no real chance of it biting back later, and it's simple enough to change. (just a sed script or somesuch)

Quote:
One more issue is the strange declarations of an overloaded windows function within the extern(Windows) group called MoveMemory(). There's a long list of variations. This makes no sense! But all variations of this function are used throughout the DWT source. It will take some manipulation to fix this issue. Step one would be to declare the single proper extern windows function, then create several seperately overloaded MoveMemory() functions as part of the OS class that call the actual win32 MoveMemory. As its stands now, it would never work or link properly.


MoveMemory is just memcpy(). Its overloads can trivially be re-implemented directly in the OS class:

Code:
static int MoveMemory(byte[] src, LOGFONT dest) { // or whatever the argument list happens to be
   assert(src.length == LOGFONT.sizeof);
   (cast(byte*)&dest)[0 .. LOGFONT.sizeof] = src[]; // just a copy
}


No extern (Windows), no link issues. Wink
_________________
"Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Aug 11, 2004 9:09 pm    Post subject: Reply with quote

andy wrote:
JJR wrote:
Unfortunately, internal class imports are considered bad practice now because of the way D performs name resolution. So it would be better to have an external import and then local aliases or fully qualified win32 function calls within OS.d.


This isn't a big deal at all.

It's "bad practice," but the OS class is never instantiated or subclassed, so there's no real chance of it biting back later, and it's simple enough to change. (just a sed script or somesuch)


I disagree. It's bad practice even if you don't subclass because a method within the class that happens to have the same name as a locally imported windows function will be completely overriden no matter how different it's signature is. Perhaps it's not an issue with DWT currently, but from past experience, one wouldn't necessarily find out until an inconvenient time. That's why Walter recommended to stay away from it. In this situation, it DOES seem to be a convenient solution for the DWT D'ized Java. It's just doesn't appear safe. If you are satisfied that it's easy enough to change.... good enough.

Andy wrote:
Quote:
One more issue is the strange declarations of an overloaded windows function within the extern(Windows) group called MoveMemory(). There's a long list of variations. This makes no sense! But all variations of this function are used throughout the DWT source. It will take some manipulation to fix this issue. Step one would be to declare the single proper extern windows function, then create several seperately overloaded MoveMemory() functions as part of the OS class that call the actual win32 MoveMemory. As its stands now, it would never work or link properly.


MoveMemory is just memcpy(). Its overloads can trivially be re-implemented directly in the OS class:

Code:
static int MoveMemory(byte[] src, LOGFONT dest) { // or whatever the argument list happens to be
   assert(src.length == LOGFONT.sizeof);
   (cast(byte*)&dest)[0 .. LOGFONT.sizeof] = src[]; // just a copy
}


No extern (Windows), no link issues. Wink


Good. Then it looks like you figured out the solution, and I ended up throwing a fit for nothing.
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Wed Aug 11, 2004 10:55 pm    Post subject: Reply with quote

Quote:

MoveMemory is just memcpy(). Its overloads can trivially be re-implemented directly in the OS class:

Code:
static int MoveMemory(byte[] src, LOGFONT dest) { // or whatever the argument list happens to be
   assert(src.length == LOGFONT.sizeof);
   (cast(byte*)&dest)[0 .. LOGFONT.sizeof] = src[]; // just a copy
}


No extern (Windows), no link issues. Wink


I'd suggest to put such functions into the dwt\util\system.d somewhere near the System.arraycopy() function.
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Wed Aug 11, 2004 11:24 pm    Post subject: Reply with quote

Blandger wrote:
Quote:

MoveMemory is just memcpy(). Its overloads can trivially be re-implemented directly in the OS class:

Code:
static int MoveMemory(byte[] src, LOGFONT dest) { // or whatever the argument list happens to be
   assert(src.length == LOGFONT.sizeof);
   (cast(byte*)&dest)[0 .. LOGFONT.sizeof] = src[]; // just a copy
}


No extern (Windows), no link issues. Wink


I'd suggest to put such functions into the dwt\util\system.d somewhere near the System.arraycopy() function.


I don't think that would work since MoveMemory functions are called throughout the DWT source as OS methods.

ie. OS.MoveMemory().

Keeping them in OS and using Andy's technique should be sufficient, don't you think?
Back to top
View user's profile Send private message
Blandger



Joined: 21 May 2004
Posts: 50
Location: Ukraine, Kharkov

PostPosted: Thu Aug 12, 2004 2:19 pm    Post subject: Reply with quote

JJR wrote:

Keeping them in OS and using Andy's technique should be sufficient, don't you think?

Yes. I think you are right. So what is with current sources now? Where I should take last one ??
_________________
Regards, Yuriy
Back to top
View user's profile Send private message
JJR



Joined: 22 Feb 2004
Posts: 1104

PostPosted: Thu Aug 12, 2004 4:17 pm    Post subject: Reply with quote

Blandger wrote:
JJR wrote:

Keeping them in OS and using Andy's technique should be sufficient, don't you think?

Yes. I think you are right. So what is with current sources now? Where I should take last one ??


Yeah, I'll try to get what I've got posted to svn soon. Here's a few notes for when I submit it to svn:

1) In it's current form, all you should have to do is type \dm\bin\make -fwin32.mak on the commandline (from the parent directory of dwt), and it should output a dwt.lib file. Verbose compile is currently enabled.

2) typedlistener is still not working, so I've commented it out again. (this is a real pain because everytime you want to test if it's working, the compiler thrashes the computer/hard drive).

3) I've moved the extern(Windows) functions to a file internal\win32\func.d. Feel free to change that modules name and it's import within OS.d to a more palatable name. That was just a quick fix.

4) I had to rename internal\types.d to \internal\ttypes.d because for some wierd reason it was conflicting with \internal\win32\types.d.

5) I've started moving many internal class imports to the module scope. So far this seems to be working. As long as it is working, we may as well continue the practice.

6) MoveMemory needs to be fixed using the method Andy outlined.

7) still need to continue figuring out undefined symbols in the link stage.

That's it for now, I think.


Last edited by JJR on Fri Aug 13, 2004 3:32 am; edited 1 time in total
Back to top
View user's profile Send private message
Display posts from previous:   
This forum is locked: you cannot post, reply to, or edit topics.   This topic is locked: you cannot edit posts or make replies.     Forum Index -> DWT All times are GMT - 6 Hours
Goto page 1, 2  Next
Page 1 of 2

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group