View previous topic :: View next topic |
Author |
Message |
pcsapo
Joined: 30 Jan 2006 Posts: 4
|
Posted: Mon Jan 30, 2006 2:15 pm Post subject: What's the status?? |
|
|
Hi Ant
There's been no activity for several months here.
I am interested in using dool/DUI. Having trouble compiling things from svn snapshot.
Have you lost interest in maintaining this project?
pcsapo |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Thu Feb 16, 2006 1:11 pm Post subject: Re: What's the status?? |
|
|
pcsapo wrote: | Hi Ant
There's been no activity for several months here.
I am interested in using dool/DUI. Having trouble compiling things from svn snapshot.
Have you lost interest in maintaining this project?
pcsapo |
I'm reviewing DUI to drop the dependence on Dool.
Please join the discussion on the Dui forum.
Dool had a very low acceptance from the D community, are you interested in Dool or just as support for DUI?
I'll check if there is any problem with compiling Dool - I just did that for DUI and it's fine.
Ant |
|
Back to top |
|
|
pcsapo
Joined: 30 Jan 2006 Posts: 4
|
Posted: Thu Feb 16, 2006 4:07 pm Post subject: |
|
|
I was just interested in using DUI, and I was trying to compile dool as a first step to DUI.
I had some problems, but its not really fresh in my brain right now what they were. Hmm.. the makefile was kinda weird and I think there was some issue with C string conversions .. I'll have to get to you on just what.
Anyway, I am glad that you are breaking the dependance of DUI from dool. |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Thu Feb 16, 2006 9:23 pm Post subject: |
|
|
pcsapo wrote: | the makefile was kinda weird and I think there was some issue with C string conversions .. I'll have to get to you on just what. |
Oh! yes, the Makefiles - forgot those.
I use leds to compile my libs and programs.
I also use leds to generate the makefiles,
but leds is evolving and I'm not sure it can generate valid makefiles rigth now (even if weird...)
... testing ... no go. :) the make fails...
Ant |
|
Back to top |
|
|
pcsapo
Joined: 30 Jan 2006 Posts: 4
|
Posted: Thu Feb 23, 2006 6:51 pm Post subject: |
|
|
Ok, I figured out where I had trouble with the build.
The constructors in String.d make, in a couple places, a reference instead of a copy. The test program fails at one place because of this, because a String object is initialized from a temporary C string passed from a library call. (I think it was one to make a date string or something.. not important which one.)
You may actually want the String object to behave this way, but I doubt it. Here is the diff from the changes I made.
Code: |
Index: trunk/src/dool/String.d
===================================================================
--- trunk/src/dool/String.d (revision 69)
+++ trunk/src/dool/String.d (working copy)
@@ -139,23 +139,30 @@
}
/**
- * Creates a String from a pointer to memory.
+ * Duplicates a String from a pointer to memory.
* The string length will be the length from the pointer until the next null char;
* @param str The pointer.
*/
this(void* str)
- {
- this.str = str ? (cast(char*)str)[0 .. strlen(cast(char*)str)] : "";
+ {
+ if (str)
+ {
+ uint len = strlen(cast(char*)str);
+ this.str.length = len;
+ this.str[] = (cast(char*)str)[0..len];
+ }
+ else
+ this.str[] = "";
}
/**
- * Create a String from a pointer to chars.
+ * Duplicate a String from a pointer to chars.
* @param str the pointer to chars
* @param length the length of the new String
*/
this(char* str, int length)
{
- this.str = str ? str[0 .. length] : "";
+ this.str[] = str ? str[0 .. length] : "";
}
/**
|
As you can see, I changed the code so that it makes a local copy of the string instead of a reference.
Pete |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Fri Feb 24, 2006 1:02 pm Post subject: |
|
|
pcsapo wrote: | Ok, I figured out where I had trouble with the build.
The constructors in String.d make, in a couple places, a reference instead of a copy.
...
You may actually want the String object to behave this way.
|
well, that was the idea. It was to be used when you own the string
(of course it wasn't properly documented and it would leak memory...).
I believe I use that on leds when grabbing text from the editor to browse or process - it would avoid duplicating the string.
But you're right, I'll apply the fix and create a couple of explicit function to keep the functionality.
Be aware the DUI has the same problem: not knowing when it needs to free the memory (in whatever form) received from Gtk+.
This will lead to memory leaks.
It is not going to be possible to fix DUI code.
The next version (Duit) will copy and free the memory when necessary to allow normal D memory management (gc).
That will be coded by the automatic Gtk to Duit code biding and wrapping.
Ant |
|
Back to top |
|
|
pcsapo
Joined: 30 Jan 2006 Posts: 4
|
Posted: Fri Feb 24, 2006 4:01 pm Post subject: |
|
|
It's the same old issue with container classes, especially string libraries. When to make a copy and when to store a reference. It bit you in the arse in the getcwd() method when you freed the string that the getcwd() c-library call allocated.
Just making a copy (or at least copy-on-write) is pretty much the safe solution. I suggest that if you want store a reference to the string you name the method along the lines of package_cstr or something similar, and don't let it be a constructor.
Pete |
|
Back to top |
|
|
CharlesH
Joined: 07 Jul 2004 Posts: 2 Location: Oakland
|
Posted: Tue Jul 11, 2006 5:55 pm Post subject: Re: What's the status?? |
|
|
Quote: |
I'm reviewing DUI to drop the dependence on Dool.
Please join the discussion on the Dui forum.
Dool had a very low acceptance from the D community, are you interested in Dool or just as support for DUI?
I'll check if there is any problem with compiling Dool - I just did that for DUI and it's fine.
Ant |
I'd be in favor of removing a dependendy on Dool. I haven't been able to compile it. The leds executable worked, but since I can't compile Dool, well, I can't compile duit or leds.
My suspicion is that the main reason that Dool had a very low acceptance from the D community is that few could install it. (Makefile-s with the absolute path name hard coded in of a library that isn't on anyone's system but the developer's could have something to do with it. That's probably leds, since the makefiles clearly say they were generated by leds.)
OTOH, most D developers seem to be MSWind users, so my guesses may be totally wrong.
P.S.: Does it matter whether the compiler is dmd or gdc? I note that the makefile has dmd hardcoded in, but many other programs on Linux appear to prefer gdc if they are linking to external libraries. |
|
Back to top |
|
|
Ant
Joined: 06 Mar 2004 Posts: 306 Location: Canada
|
Posted: Wed Jul 12, 2006 11:39 am Post subject: Re: What's the status?? |
|
|
CharlesH wrote: | Quote: |
I'm reviewing DUI to drop the dependence on Dool.
Please join the discussion on the Dui forum.
Dool had a very low acceptance from the D community, are you interested in Dool or just as support for DUI?
I'll check if there is any problem with compiling Dool - I just did that for DUI and it's fine.
Ant |
I'd be in favor of removing a dependendy on Dool. I haven't been able to compile it. The leds executable worked, but since I can't compile Dool, well, I can't compile duit or leds.
My suspicion is that the main reason that Dool had a very low acceptance from the D community is that few could install it. (Makefile-s with the absolute path name hard coded in of a library that isn't on anyone's system but the developer's could have something to do with it. That's probably leds, since the makefiles clearly say they were generated by leds.)
OTOH, most D developers seem to be MSWind users, so my guesses may be totally wrong.
P.S.: Does it matter whether the compiler is dmd or gdc? I note that the makefile has dmd hardcoded in, but many other programs on Linux appear to prefer gdc if they are linking to external libraries. |
I had very little free time on the last couple of months.
Duit (SVN repository) doesn't depend on Dool anymore.
leds still does and I have no plans to drop it.
but I have no problems compiling Dool - I use the internal leds compilation tool.
leds improved a bit since the last released executable - I see about releasing another one (not today unfortunatly...)
I agree with you. If the distribution of any of the libs and leds was cleaner, easear to install,... we would have more users.
I probably need to reset my priorities in that direction.
Ant |
|
Back to top |
|
|
|