View previous topic :: View next topic |
Author |
Message |
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Tue Oct 26, 2004 8:18 pm Post subject: Update 41 |
|
|
I know, I know. It's been a long time since any updates to or comments on DWT. Well, here's a small update:
Changed:
1) Class internal imports moved to module scope for all classes. Doing this brought out numerous missing import errors that were otherwise invisible for some reason previously. Fixed those. No forward reference problems surfaced.
2) More String -> char[] conversion within widgets directory to maintain consistancy with rest of library (and to succeed in compile). I'm finding that, overall, replacing String with char[] may not be such a good idea. Change back to a String type may eventually be necessary again to generalize the situation of variable character widths (unicode). I'm sticking to char[] for now for library consistancy.
3) Callback.d renamed callbacktable.d for now. A Callback class still needs to be created/implemented before the auto generated callback functions can be used. Callback.d, then, will contain the Callback class and will import callbacktable.d.
4) Callbacktable.d appears to be missing some critical initialization. No linkage of delegates to provided function callbacks seems to actually take place. For example, int callback_arg#_###(void*) are nowhere linked into the Function tables that I can see. Perhaps I'm missing something (entirely possible: I found the mechanism somewhat confusing to read).
5) A new obj directory was created for object file storage during the compile process.
6) win32.mak updated as needed.
Current Issues:
1) Infinite loop in dmd during semantic anaylisis still present when compile phase reaches the widget directory (button). I haven't yet figured out the source of this problem. Search ongoing. At present, dmd eventually will exit with "Error: out of memory" after a minute or two of processing "dwt\widgets\button.d"
2) OS.func may still cause some issues with windows linkage because of the need to do the confounding internal class imports. I'm considering the possiblility of going through dwt and replacing all windows calls of the kind OS.winfunc() with merely winfunc(). Containing these calls in OS appears to do nothing for the D version of DWT.
I'll be plugging away at this as I find time. No timeline here. It's better that something gets done with DWT than nothing at all.
Later,
John R. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Mon Jan 03, 2005 1:00 am Post subject: Revision 42 |
|
|
I had to change all the char[]s back to String because it doesn't seem at all clear what DWTs preferred char type should be. So, failing that, I set up the alias to use a version flag to decide which. (DwtChar, DwtWchar, or DwtDchar) So far, I've only tested with DwtChar.
I also replaced lots of instances of "x == null" with "x is null" (and its compliment), thereby resolving a lot of real or inevitable future segfaults, and some other tiny things.
HelloDWT now makes it through the Shell constructor, which is a step in the right direction. The call to shell.open() is the next problem that needs addressing. _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Mon Jan 03, 2005 1:07 am Post subject: |
|
|
Nice work Andy! I'm afraid that I haven't looked at the project for awhile. I forgot about the potential problems with "x == null" so I'm glad you brought that up. Did you submit the changes to svn?
DWT's direction with char[] vs String is problematic. I think you're taking it in the right direction.
I'll be looking at improvements to DWT time to time, especially as the compiler updates fix different issues. DWT certainly warrants some attention. As I understand D more, slowly but surely, I begin to understand the potential for moving DWT to a more operable state.
Thanks for taking the time to look into it again.
- John R. |
|
Back to top |
|
|
andy
Joined: 15 Mar 2004 Posts: 71
|
Posted: Mon Jan 03, 2005 10:28 am Post subject: |
|
|
Thanks.
Everything is in the repository, yes.
Also one other thing that I just remembered: I replaced dwt.util.thread with std.thread, as it seems to be able to do everything it needs to. _________________ "Complacency is a far more dangerous attitude than outrage." - Naomi Littlebear |
|
Back to top |
|
|
JJR
Joined: 22 Feb 2004 Posts: 1104
|
Posted: Wed Feb 23, 2005 3:11 am Post subject: |
|
|
Andy,
If you are still around...
I've been looking at callbacktable.d, the file generated by the python script (yours?). It's incomplete because each element in the function arrays need to be assigned to the extern(Windows) functions defined later in the file before anything will work. The bind method merely attaches a submitted delegate to the appropriate delegate array and then returns a function pointer from the function array at the appropriate index.
Unfortunately, the appropriate function has not been assigned to that index yet. Do you know how this was supposed to be done? From what I can see, this will be another job for a script to assign all possible "callback_argX_X" functions to there location in the functionX arrays.
Once that's done, the indexed array can return the appropriate function. I was thinking, if it would work with D, function literals would fit this situation well, except that they can't be extern(Windows) at the moment.
For now we have to assign them one by one causing the file to grow to huge proportions. Of course, a static initializer will work.
- John R. |
|
Back to top |
|
|
|
|
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
|