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

What's the status??

 
Post new topic   Reply to topic     Forum Index -> dool
View previous topic :: View next topic  
Author Message
pcsapo



Joined: 30 Jan 2006
Posts: 4

PostPosted: Mon Jan 30, 2006 2:15 pm    Post subject: What's the status?? Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Thu Feb 16, 2006 1:11 pm    Post subject: Re: What's the status?? Reply with quote

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
View user's profile Send private message
pcsapo



Joined: 30 Jan 2006
Posts: 4

PostPosted: Thu Feb 16, 2006 4:07 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Thu Feb 16, 2006 9:23 pm    Post subject: Reply with quote

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
View user's profile Send private message
pcsapo



Joined: 30 Jan 2006
Posts: 4

PostPosted: Thu Feb 23, 2006 6:51 pm    Post subject: Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Fri Feb 24, 2006 1:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
pcsapo



Joined: 30 Jan 2006
Posts: 4

PostPosted: Fri Feb 24, 2006 4:01 pm    Post subject: Reply with quote

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
View user's profile Send private message
CharlesH



Joined: 07 Jul 2004
Posts: 2
Location: Oakland

PostPosted: Tue Jul 11, 2006 5:55 pm    Post subject: Re: What's the status?? Reply with quote

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
View user's profile Send private message
Ant



Joined: 06 Mar 2004
Posts: 306
Location: Canada

PostPosted: Wed Jul 12, 2006 11:39 am    Post subject: Re: What's the status?? Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Post new topic   Reply to topic     Forum Index -> dool All times are GMT - 6 Hours
Page 1 of 1

 
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