www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WeakRef updated to support Tango, too

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

I updated the WeakRef class I posted a while ago to work under Tango too.

Can I maybe put this in Scrapple, Oh Master of the Scraps?
(dsource login is 'baxissimo')

--bb
Feb 12 2008
next sibling parent reply Moritz Warning <moritzwarning _nospam_web.de> writes:
On Wed, 13 Feb 2008 16:23:42 +0900, Bill Baxter wrote:

 I updated the WeakRef class I posted a while ago to work under Tango
 too.
 
 Can I maybe put this in Scrapple, Oh Master of the Scraps? (dsource
 login is 'baxissimo')
 
 --bb

I'm no maintainer of Scrapple, but making a ticket is certainly a good idea. http://dsource.org/projects/tango.scrapple
Feb 13 2008
parent jcc7 <technocrat7 gmail.com> writes:
== Quote from Moritz Warning (moritzwarning _nospam_web.de)'s article
 On Wed, 13 Feb 2008 16:23:42 +0900, Bill Baxter wrote:
 I updated the WeakRef class I posted a while ago to work under
 Tango too.

 Can I maybe put this in Scrapple, Oh Master of the Scraps?
 (dsource login is 'baxissimo')

 --bb

good idea. http://dsource.org/projects/tango.scrapple

Since his code works with both Phobos and Tango (via some versioning), he probably meant Scrapple (Original Flavor): http://dsource.org/projects/scrapple/ (Though I wouldn't be surprised if tango.scrapple would accept it, too.)
Feb 13 2008
prev sibling next sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Minor issue, the 'string' alias should be private, or it may conflict with
aliases made by the 
user.

To others:

Please go to http://dsource.org/projects/tango/ticket/548 and add your support
for tango 
adopting this alias. This kind of issue is the main reason I want them to add
it.
Feb 14 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:
 Minor issue, the 'string' alias should be private, or it may conflict 
 with aliases made by the user.

As far as I know, private aliases conflict just like public ones, not so?
 To others:
 
 Please go to http://dsource.org/projects/tango/ticket/548 and add your 
 support for tango adopting this alias. This kind of issue is the main 
 reason I want them to add it.

I seem to have already done that. And filed a very similar bug to boot that larsivi closed as a dup. :-) --bb
Feb 14 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Bill Baxter wrote:
 Tomas Lindquist Olsen wrote:
 Minor issue, the 'string' alias should be private, or it may conflict 
 with aliases made by the user.

As far as I know, private aliases conflict just like public ones, not so?

Bugs that look relevant: http://d.puremagic.com/issues/show_bug.cgi?id=463 http://d.puremagic.com/issues/show_bug.cgi?id=1161 http://d.puremagic.com/issues/show_bug.cgi?id=1238 http://d.puremagic.com/issues/show_bug.cgi?id=1441 --bb
Feb 14 2008
prev sibling parent reply Tomas Lindquist Olsen <tomas famolsen.dk> writes:
Bill Baxter wrote:
 Tomas Lindquist Olsen wrote:
 Minor issue, the 'string' alias should be private, or it may conflict 
 with aliases made by the user.

As far as I know, private aliases conflict just like public ones, not so?

The problem is in the modules that import your weakref module. When the alias is public it becomes part of the global symbol table (of the importing module) and conflicts with ones own alias. If you make it private, imports will not see the alias and you thus wont cause conflicts. Hope that makes more sense.
 
 To others:

 Please go to http://dsource.org/projects/tango/ticket/548 and add your 
 support for tango adopting this alias. This kind of issue is the main 
 reason I want them to add it.

I seem to have already done that. And filed a very similar bug to boot that larsivi closed as a dup. :-)

That's why I wrote 'To others' :)
 
 --bb

Feb 14 2008
next sibling parent Bill Baxter <dnewsgroup billbaxter.com> writes:
Tomas Lindquist Olsen wrote:
 Bill Baxter wrote:
 Tomas Lindquist Olsen wrote:
 Minor issue, the 'string' alias should be private, or it may conflict 
 with aliases made by the user.

As far as I know, private aliases conflict just like public ones, not so?

The problem is in the modules that import your weakref module. When the alias is public it becomes part of the global symbol table (of the importing module) and conflicts with ones own alias. If you make it private, imports will not see the alias and you thus wont cause conflicts. Hope that makes more sense.

Oh I see. So it doesn't help avoid conflicts in the module importing weakref, but it helps avoid them in the modules that import the modules that import weakref. Well anyway, the code probably needs big changes to be a good WeakRef class for D2 anyway, so I might as well just ditch the alias and use char[] directly. But anyway, no one has given me access to scrapple. Thanks for the feedback. --bb
Feb 14 2008
prev sibling parent Bruno Medeiros <brunodomedeiros+spam com.gmail> writes:
Tomas Lindquist Olsen wrote:
 Bill Baxter wrote:
 Tomas Lindquist Olsen wrote:
 Minor issue, the 'string' alias should be private, or it may conflict 
 with aliases made by the user.

As far as I know, private aliases conflict just like public ones, not so?

The problem is in the modules that import your weakref module. When the alias is public it becomes part of the global symbol table (of the importing module) and conflicts with ones own alias. If you make it private, imports will not see the alias and you thus wont cause conflicts. Hope that makes more sense.

Are you sure of that? I've tested it with DMD 2.011 and making an alias private makes no difference: in either case it does not become part of the "global symbols" of the importing module. It only becomes so if the *import* is public, which is a different thing. Or maybe I misunderstood your example? Here's what I tried: --- pfx.bar --- module pfx.bar; alias int thealias; --- pack.foo --- module pack.foo; import pfx.bar; --- pfx.bar2 --- module pfx.bar2; alias char thealias; --- test --- module test; import pack.foo; import pfx.bar2; thealias al; // No conflicts, pfx.bar2.thealias is chosen -- Bruno Medeiros - MSc in CS/E student http://www.prowiki.org/wiki4d/wiki.cgi?BrunoMedeiros#D
Mar 05 2008
prev sibling parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

The unittest in the previous version didn't actually work under Tango... 
oops.  This version also eliminates the string alias and puts imports 
for unittests inside version(UnitTest) {...}

Also I realized Myron Alexander had made a weak ref class a while back 
called WeakObjectReference, and posted under D.announce.  The main 
difference seems to be that his version uses malloc to allocate one 
pointer, whereas I just use a size_t to hold the pointer so that the GC 
won't see it.  Is there some reason why that won't cut it?

Still hoping someone will let me add this to scrapple and/or 
tango.scrapple.  Hint hint.

--bb
Feb 14 2008
parent reply Jason House <jason.james.house gmail.com> writes:
I'm getting:
  undefined reference to `rt_attachDisposeEvent'
  undefined reference to `rt_detachDisposeEvent'

What can I do to fix that?  I must admit that I didn't use the code as is, but
instead mutated it for my own purposes...  Essentially, I have an AA-like object
that needs to remove the AA entry instead of invalidating a pointer.

Here's the code I used for the function prototypes:
private{
	alias void delegate(Object) DisposeEvent;
	extern(C) void rt_attachDisposeEvent(Object obj, DisposeEvent event);
	extern(C) void rt_detachDisposeEvent(Object obj, DisposeEvent event);
}

== Quote from Bill Baxter (dnewsgroup billbaxter.com)'s article
 This is a multi-part message in MIME format.
 --------------060908030803020302060805
 Content-Type: text/plain; charset=ISO-8859-1; format=flowed
 Content-Transfer-Encoding: 7bit
 The unittest in the previous version didn't actually work under Tango...
 oops.  This version also eliminates the string alias and puts imports
 for unittests inside version(UnitTest) {...}
 Also I realized Myron Alexander had made a weak ref class a while back
 called WeakObjectReference, and posted under D.announce.  The main
 difference seems to be that his version uses malloc to allocate one
 pointer, whereas I just use a size_t to hold the pointer so that the GC
 won't see it.  Is there some reason why that won't cut it?
 Still hoping someone will let me add this to scrapple and/or
 tango.scrapple.  Hint hint.
 --bb
 --------------060908030803020302060805
 Content-Type: text/plain;
  name="weakref.d"
 Content-Transfer-Encoding: 7bit
 Content-Disposition: inline;
  filename="weakref.d"
 /*==========================================================================
  * weakref.d
  *    Written in the D Programming Language (http://www.digitalmars.com/d)
  */
 /***************************************************************************
  * Creates a weak reference to a class instance.
  *
  * A weak reference lets you hold onto a pointer to an object without
  * preventing the garbage collector from collecting it.
  * If the garbage collector collects the object then the weak pointer will
  * become 'null'.  Thus one should always check a weak pointer for null
  * before doing anything that depends upon it having a value.
  *
  * Tested with:
  *    DMD 1.025 / Phobos 1.025
  *    DMD 1.025 / Tango 0.99.4
  *
  * Usage example:
 ---
  class Something {}
  auto a = new Something();
  auto wa = new WeakRef!(Something)(a);
  std.gc.fullCollect();
  // Reference 'a' prevents collection so wa.ptr is non-null
  assert(wa.ptr is a);
  delete a;
  // 'a' is gone now, so wa.ptr magically becomes null
  assert(wa.ptr is null);
 ---
  *
  *
  * Author:  William V. Baxter III
  * Contributors:
  * Date: 21 Jan 2008
  * Copyright: (C) 2008  William Baxter
  * License: Public Domain where allowed by law, ZLIB/PNG otherwise.
  */
 //===========================================================================
 module weakref;
 version(Tango) {
     private {
         alias void delegate(Object) DisposeEvt;
         extern (C) void  rt_attachDisposeEvent( Object obj, DisposeEvt evt );
         extern (C) void  rt_detachDisposeEvent( Object obj, DisposeEvt evt );
     }
 }
 class WeakRef(T : Object) {
 private:
     size_t cast_ptr_;
     void unhook(Object o) {
         debug { writefln("Unhook! [%s]",o); }
         if (cast(size_t)cast(void*)o == cast_ptr_) {
             version(Tango) {
                 rt_detachDisposeEvent(o, &unhook);
             } else {
                 o.notifyUnRegister(&unhook);
             }
             cast_ptr_ = 0;
         }
     }
 public:
     this(T tptr) {
         cast_ptr_ = cast(size_t)cast(void*)tptr;
         version(Tango) {
             rt_attachDisposeEvent(tptr, &unhook);
         } else {
             tptr.notifyRegister(&unhook);
         }
     }
     ~this() {
         T p = ptr();
         if (p) {
             version(Tango) {
                 rt_detachDisposeEvent(p, &unhook);
             } else {
                 p.notifyUnRegister(&unhook);
             }
         }
     }
     T ptr() {
         return cast(T)cast(void*)cast_ptr_;
     }
     WeakRef dup() {
         return new WeakRef(ptr());
     }
 }
 version(UnitTest) {
 version(Tango) {
     import tango.core.Memory;
     alias GC.collect collect;
 } else {
     static import std.gc;
     alias std.gc.fullCollect collect;
 }
 unittest {
     class Something {
         int value;
         this(int v) { value = v; }
         ~this() { value = -1; }
     }
     WeakRef!(Something) wa;
     auto a = new Something(1);
     wa = new WeakRef!(Something)(a);
     assert(a is wa.ptr);
     collect();
     assert(a is wa.ptr);
     delete a;
     // a now gone so should be collected
     collect();
     assert(wa.ptr is null);
 }
 }
 //--- Emacs setup ---
 // Local Variables:
 // c-basic-offset: 4
 // indent-tabs-mode: nil
 // End:
 --------------060908030803020302060805--

Mar 22 2008
parent reply Bill Baxter <dnewsgroup billbaxter.com> writes:
Jason House wrote:
 I'm getting:
   undefined reference to `rt_attachDisposeEvent'
   undefined reference to `rt_detachDisposeEvent'
 
 What can I do to fix that?  

Those are Tango's names for the functions. Are you using Tango? If you are using Tango, then maybe you need to link with tango-user-dmd.lib? If that ain't it, then someone who knows more about Tango will have to help. --bb
Mar 22 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Bill Baxter wrote:

 Jason House wrote:
 I'm getting:
   undefined reference to `rt_attachDisposeEvent'
   undefined reference to `rt_detachDisposeEvent'
 
 What can I do to fix that?

Those are Tango's names for the functions. Are you using Tango? If you are using Tango, then maybe you need to link with tango-user-dmd.lib? If that ain't it, then someone who knows more about Tango will have to help. --bb

Tango 0.99.4 with gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1). I'm linking with gtango. I have Memory.di, but can't find Memory.d or related files that may give me a hint what to do.
Mar 23 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Bill Baxter wrote:
 
 Jason House wrote:
 I'm getting:
   undefined reference to `rt_attachDisposeEvent'
   undefined reference to `rt_detachDisposeEvent'
 
 What can I do to fix that?

Those are Tango's names for the functions. Are you using Tango? If you are using Tango, then maybe you need to link with tango-user-dmd.lib? If that ain't it, then someone who knows more about Tango will have to help. --bb

Tango 0.99.4 with gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1). I'm linking with gtango. I have Memory.di, but can't find Memory.d or related files that may give me a hint what to do.

Those should be in your libgphobos (for gdc). -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 23 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Lars Ivar Igesund Wrote:

 Jason House wrote:
 
 Bill Baxter wrote:
 
 Jason House wrote:
 I'm getting:
   undefined reference to `rt_attachDisposeEvent'
   undefined reference to `rt_detachDisposeEvent'
 
 What can I do to fix that?

Those are Tango's names for the functions. Are you using Tango? If you are using Tango, then maybe you need to link with tango-user-dmd.lib? If that ain't it, then someone who knows more about Tango will have to help. --bb

Tango 0.99.4 with gdc (GCC) 4.1.3 20070831 (prerelease gdc 0.25, using dmd 1.021) (Ubuntu 0.25-4.1.2-16ubuntu1). I'm linking with gtango. I have Memory.di, but can't find Memory.d or related files that may give me a hint what to do.

Those should be in your libgphobos (for gdc).

I'm still confused. I did not need to link to Phobos for a Tango project before. Why now? How do I generalize for both dmd and gdc?
Mar 24 2008
parent reply e-t172 <e-t172 akegroup.org> writes:
Jason House a écrit :
 I'm still confused. I did not need to link to Phobos for a Tango project
before. Why now? How do I generalize for both dmd and gdc?

When you install Tango, libphobos.a is actually replaced with the core Tango library. This is because it is not yet possible to link to a different standard library than libgphobos, so Tango replaces libgphobos with his own library. (Note: Tango also replaces libgphobos with GDC, even though GDC permits the use of a different standard library through the -nophoboslib switch and manual linking) Normally, libphobos is automatically linked in by dmd/gdc. If you have to add -lphobos (or -lgphobos) to your command line, this is not normal.
Mar 24 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
e-t172 wrote:

 Jason House a écrit :
 I'm still confused. I did not need to link to Phobos for a Tango project
 before. Why now? How do I generalize for both dmd and gdc?

When you install Tango, libphobos.a is actually replaced with the core Tango library. This is because it is not yet possible to link to a different standard library than libgphobos, so Tango replaces libgphobos with his own library. (Note: Tango also replaces libgphobos with GDC, even though GDC permits the use of a different standard library through the -nophoboslib switch and manual linking) Normally, libphobos is automatically linked in by dmd/gdc. If you have to add -lphobos (or -lgphobos) to your command line, this is not normal.

Actually, some inaccuracy here: Since 0.99.2 or 0.99.3, Tango has installed libtango-base-dmd.a for DMD, used via the -defaultlib switch. For GDC we indeed install libgphobos, since there is no equivalent switch for GDC that also can be put in a .conf file like with dmd.conf. In both cases, you should not notice the use of that library, as it happens "behind the scenes". So in the case of libgphobos - if the wrong one is installed, Tango's runtime features will not work. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 24 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8Bit

Lars Ivar Igesund wrote:

 e-t172 wrote:
 
 Jason House a écrit :
 I'm still confused. I did not need to link to Phobos for a Tango project
 before. Why now? How do I generalize for both dmd and gdc?

When you install Tango, libphobos.a is actually replaced with the core Tango library. This is because it is not yet possible to link to a different standard library than libgphobos, so Tango replaces libgphobos with his own library. (Note: Tango also replaces libgphobos with GDC, even though GDC permits the use of a different standard library through the -nophoboslib switch and manual linking) Normally, libphobos is automatically linked in by dmd/gdc. If you have to add -lphobos (or -lgphobos) to your command line, this is not normal.

Actually, some inaccuracy here: Since 0.99.2 or 0.99.3, Tango has installed libtango-base-dmd.a for DMD, used via the -defaultlib switch. For GDC we indeed install libgphobos, since there is no equivalent switch for GDC that also can be put in a .conf file like with dmd.conf. In both cases, you should not notice the use of that library, as it happens "behind the scenes". So in the case of libgphobos - if the wrong one is installed, Tango's runtime features will not work.

Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues. Below is a copy and paste of the complete output. I also attached my TT code that's causing my problem. gdc -funittest -w -g -fversion=Posix hb_version.d gogui.d gtp.d housebot.d ipc.d log.d random.d sgf.d sleep.d tangoBind.d timecontrol.d game/definition.d game/definitions.d game/go.d search/alphabeta.d search/amaf.d search/control.d search/controllers.d search/ihr.d search/montecarlo.d search/transposition.d search/uct.d -Wl,-lgtango,-lgphobos -o housebot-0.7 /tmp/cchUQ681.o: In function `_D6search13transposition64__T18transpositionTableTC6search9alphabeta19alphaBetaSearchNodeZ18transpositionTable13opIndexAssignMFC6search9alphabeta19alphaBetaSearchNodemZv': /home/jhouse/housebot/0.7/search/transposition.d:62: undefined reference to `rt_attachDisposeEvent' /tmp/cchUQ681.o: In function `_D6search13transposition64__T18transpositionTableTC6search9alphabeta19alphaBetaSearchNodeZ18transpositionTable6removeMFmZv': /home/jhouse/housebot/0.7/search/transposition.d:65: undefined reference to `rt_detachDisposeEvent' /tmp/ccC0WgII.o: In function `_D6search13transposition52__T18transpositionTableTC6search3uct13uctSearchNodeZ18transpositionTable13opIndexAssignMFC6search3uct13uctSearchNodemZv': /home/jhouse/housebot/0.7/search/transposition.d:62: undefined reference to `rt_attachDisposeEvent' /tmp/ccC0WgII.o: In function `_D6search13transposition52__T18transpositionTableTC6search3uct13uctSearchNodeZ18transpositionTable6removeMFmZv': /home/jhouse/housebot/0.7/search/transposition.d:65: undefined reference to `rt_detachDisposeEvent' collect2: ld returned 1 exit status
Mar 24 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House Wrote:

 Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues. 
 Below is a copy and paste of the complete output.  I also attached my TT
 code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you please take it to the Tango forum or create a ticket? Lars Ivar
Mar 25 2008
parent reply Jaaon House <jason.james.house gmail.com> writes:
Lars Ivar Igesund Wrote:

 Jason House Wrote:
 
 Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues. 
 Below is a copy and paste of the complete output.  I also attached my TT
 code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you please take it to the Tango forum or create a ticket? Lars Ivar

Given that I must continue using 0.99.4, and the ensuing pain to rebuild and install Tango without the installer, what is the easiest way to test this?
Mar 25 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jaaon House (jason.james.house gmail.com)'s article
 Lars Ivar Igesund Wrote:
 Jason House Wrote:

 Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues.
 Below is a copy and paste of the complete output.  I also attached my TT
 code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you


 Lars Ivar


Use any non-template Tango routine and see if you get a linker error when building the app. But I'll admit to being a bit surprised that the Tango build process is painful. It amounts to running one script, at least for the base lib. Sean
Mar 25 2008
next sibling parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly Wrote:

 == Quote from Jaaon House (jason.james.house gmail.com)'s article
 Lars Ivar Igesund Wrote:
 Jason House Wrote:

 Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues.
 Below is a copy and paste of the complete output.  I also attached my TT
 code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you


 Lars Ivar


Use any non-template Tango routine and see if you get a linker error when building the app.

They're sprinkled throughout the 9000+ line code base. It all worked before I tried using the weak ref stuff. I also know that -lgtango was required with gdc to compile with gdc. I added -lgphobos based off of this thread.
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, 
 at least for the base lib.

I'm not set up for building Tango every day. The code I used to build/install 0.99.4 was purged from my machine. I can't go to the Tango web site and download 0.99.4 anymore. I have to go to svn. That means looking up the svn repository, finding the code, and checking it out. Then I have to poke around the Tango web site until I find the instructions on building and installing Tango (again, I don't do it every day). Running the build script is a step in the process, but I know it isn't everything. The build script creates stuff, but then the proper files have to get moved to the proper locations. That includes stuff like tracking down which directories gdc uses. Maybe I'm slow, but that's not a 2 minute task for me.
Mar 25 2008
next sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Sean Kelly Wrote:
 
 == Quote from Jaaon House (jason.james.house gmail.com)'s article
 Lars Ivar Igesund Wrote:
 Jason House Wrote:

 Regardless, adding -lgtango and -lgphobos doesn't solve my linking
 issues.
 Below is a copy and paste of the complete output.  I also attached
 my TT code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you


 Lars Ivar

rebuild and install Tango without the installer, what is the easiest way to

Use any non-template Tango routine and see if you get a linker error when building the app.

They're sprinkled throughout the 9000+ line code base. It all worked before I tried using the weak ref stuff. I also know that -lgtango was required with gdc to compile with gdc. I added -lgphobos based off of this thread.

libgtango was never required, but recommended (and possibly not even that if using dsss (rebuild)). libgphobos has always been required, but should normally be linked automatically by GDC.
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script,
 at least for the base lib.

I'm not set up for building Tango every day. The code I used to build/install 0.99.4 was purged from my machine. I can't go to the Tango web site and download 0.99.4 anymore. I have to go to svn. That means looking up the svn repository, finding the code, and checking it out. Then I have to poke around the Tango web site until I find the instructions on building and installing Tango (again, I don't do it every day). Running the build script is a step in the process, but I know it isn't everything. The build script creates stuff, but then the proper files have to get moved to the proper locations. That includes stuff like tracking down which directories gdc uses. Maybe I'm slow, but that's not a 2 minute task for me.

0.99.4 is easily available from http://www.dsource.org/projects/tango/wiki/PriorReleases. -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 25 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Lars Ivar Igesund Wrote:
 0.99.4 is easily available from
 
 http://www.dsource.org/projects/tango/wiki/PriorReleases.

Both with and without the trailing period generate the following: Not Found 404 Not Found (Page %s not found)
Mar 25 2008
parent Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Lars Ivar Igesund Wrote:
 0.99.4 is easily available from
 
 http://www.dsource.org/projects/tango/wiki/PriorReleases.

Both with and without the trailing period generate the following: Not Found 404 Not Found (Page %s not found)

Sorry, tried to write that from memory: http://dsource.org/projects/tango/wiki/PreviousReleases -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 25 2008
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article
 Sean Kelly Wrote:
 == Quote from Jaaon House (jason.james.house gmail.com)'s article
 Lars Ivar Igesund Wrote:
 Jason House Wrote:

 Regardless, adding -lgtango and -lgphobos doesn't solve my linking issues.
 Below is a copy and paste of the complete output.  I also attached my TT
 code that's causing my problem.

I wasn't suggesting that these were missing, but rather that you got the Phobos version of the runtime. If that is not the case, could you


 Lars Ivar


Use any non-template Tango routine and see if you get a linker error when building the app.


I was actually suggesting creating a simple "hello world" app and see if it links.
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script,
 at least for the base lib.


the Tango web site until I find the instructions on building and installing Tango (again, I don't do it every day). Running the build script is a step in the process, but I know it isn't everything. The build script creates stuff, but then the proper files have to get moved to the proper locations. That includes stuff like tracking down which directories gdc uses.
 Maybe I'm slow, but that's not a 2 minute task for me.

I'm not sure if you're aware of it, but all previous Tango releases are still available on the website. Here's the page: http://dsource.org/projects/tango/wiki/PreviousReleases As for building the base lib, run /trunk/lib/build-dmd.sh or /trunk/lib/build-gdc.sh as appropriat. For the user portion that typically is built into libtango- user-dmd.a (or libgphobos.a, I beleive), you can call trunk/lib/build-tango.sh to generate this lib or simply use DSSS/rebuild/Bud and forget about building the lib altogether. There are also install scripts in /trunk/lib called install-dmd.sh and install-gdc.sh to automate the install for you, or you can copy the libs to /usr/lib and the import files to wherever your include path is set to find them. In short, /trunk/lib is where you go to build and install Tango at the moment. We've been discussing restructuring things to make the location of scripts, etc, a bit more self-evident, but that hasn't happened yet. As for this particular issue, the most likely explanation is that you're not linking against the proper lib for Tango as Lars said previously. Sean
Mar 25 2008
prev sibling parent reply Jason House <jason.james.house gmail.com> writes:
Sean Kelly wrote:

 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, at
 least for the base lib.

Ok, so here's my latest experience *after* learning about http://dsource.org/projects/tango/wiki/PreviousReleases... I clocked myself at 45 minutes to do it (with recornding my steps here). After breaking my system completely at a few points, I'm now back where I started, with the two linker errors from the other day :( Did I do anything wrong? Any *other* ideas what could be going wrong? 1. http://dsource.org/projects/tango/wiki/PreviousReleases, poke around 2. http://dsource.org/projects/tango/wiki/0_99_4_GdcDownloads (for binary releases -- to make my life easier, right?) 3. Download Tango-only 4. tar -xzf ... 5. ls, etc 6. examine install script (I'm always suspect of Tango installers) 7. sudo ./install-gdc.sh -> You must uninstall your old copy of Tango before installing a new one. 8. re-examine install script 9. sudo ./install-gdc.sh --uninstall -> Done! 10. sudo ./install-gdc.sh Copying files... `libgphobos.a' -> `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libgphobos.a' cp: cannot stat `../object.di': No such file or directory Failed to copy source 11. re-examine install script 12. locate object.di 13. cp /path/to/random/object.di .. 14. sudo ./install-gdc.sh -> You must uninstall your old copy of Tango before installing a new one. 15. sudo ./install-gdc.sh --uninstall -> Done! 16. sudo ./install-gdc.sh Copying files... `libgphobos.a' -> `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libgphobos.a' `../object.di' -> `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/../include/d/4.1.3/object.d' Done! 17. Rebuild my project -> 6585 linking errors 18. Back to web, download source only from http://dsource.org/projects/tango/wiki/0_99_4_download 19. tar -xzf ... 20. Copy proper object.di to binary only package 21. sudo ./install-gdc.sh --uninstall 22. sudo ./install-gdc.sh 23. rebuild project (make clean, make) -> 6585 linking errors 24. Lookup your NG instructions 25. cd lib; ./build-gdc.sh 26. ./build-tango.sh -> Error 27. Examine help 28. ./build-tango.sh gdc 29. sudo ./install-gdc.sh You must uninstall your old copy of Tango before installing a new one. 30. sudo ./install-gdc.sh --uninstall Done! 31. sudo ./install-gdc.sh Copying files... `libgphobos.a' -> `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/libgphobos.a' `../object.di' -> `/usr/lib/gcc/i486-linux-gnu/4.1.3/../../../../lib/../include/d/4.1.3/object.d' Done! 32. Rebuild my project -> Two linking errors All said and done, I took 45 minutes and am now back to where I started. I still have two linker errors... rt_attachDisposeEvent rt_detachDisposeEvent
Mar 25 2008
next sibling parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from Jason House (jason.james.house gmail.com)'s article
 Sean Kelly wrote:
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, at
 least for the base lib.

http://dsource.org/projects/tango/wiki/PreviousReleases... I clocked myself at 45 minutes to do it (with recornding my steps here). After breaking my system completely at a few points, I'm now back where I started, with the two linker errors from the other day :( Did I do anything wrong? Any *other* ideas what could be going wrong?

Unfortunately, no. My exposure to GDC has been extremely limited, and I didn't write that particular install script. Perhaps one of the more GDC oriented Tango users could help you out. In my defense, the Win32/DMD process really does work as I described. Really! :p Sean
Mar 25 2008
prev sibling parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Sean Kelly wrote:
 
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, at
 least for the base lib.

Ok, so here's my latest experience *after* learning about http://dsource.org/projects/tango/wiki/PreviousReleases... I clocked myself at 45 minutes to do it (with recornding my steps here). After breaking my system completely at a few points, I'm now back where I started, with the two linker errors from the other day :( Did I do anything wrong? Any *other* ideas what could be going wrong?

I am awfully sorry for not having noticed this before, those two functions were not part of 0.99.4, but 0.99.5 (they were added to Tango svn immediately after 0.99.4 release). I won't speculate as to how difficult it is to backport just that part, so I will instead ask why upgrading to 0.99.5 is a problem? As for the build process, I believe the documentation is correct and concise and there is little more I can do, especially if you're suspicous of all automatic scripts we create. ;) -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 25 2008
parent reply Jason House <jason.james.house gmail.com> writes:
Lars Ivar Igesund wrote:

 Jason House wrote:
 
 Sean Kelly wrote:
 
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, at
 least for the base lib.

Ok, so here's my latest experience *after* learning about http://dsource.org/projects/tango/wiki/PreviousReleases... I clocked myself at 45 minutes to do it (with recornding my steps here). After breaking my system completely at a few points, I'm now back where I started, with the two linker errors from the other day :( Did I do anything wrong? Any *other* ideas what could be going wrong?

I am awfully sorry for not having noticed this before, those two functions were not part of 0.99.4, but 0.99.5 (they were added to Tango svn immediately after 0.99.4 release). I won't speculate as to how difficult it is to backport just that part, so I will instead ask why upgrading to 0.99.5 is a problem?

Tango 0.99.5 has two independent implementations of split, and both were broken. I submitted a bug report and they are now fixed in SVN. Last night, I upgraded to the latest svn and found string concatenation was broken (which I then told to others on #d.tango who verified it)
 As for the build process, I believe the documentation is correct and
 concise and there is little more I can do, especially if you're suspicous
 of all automatic scripts we create. ;)

I'm only suspicious because I've historically had so much trouble with them. The worst was the self-installing binaries that wouldn't print anything and fail. You'll noticed buried in my replay of events that the binary-only download for 0.99.4 was missing a file. Even worse, the installation failed miserably after using the installer from it. The source download of 0.99.4 worked better. My chats on #d.tango yesterday indicate that the user libraries are not installed by default with the installation scripts in lib... another small oversight with the installers. dsss users won't notice because dsss takes care of that part (but not other parts) Later in the night, when I did upgrade to the latest svn version using the automated install scripts from the source, I still had the two linking errors. To my utter horror, what I thought was working with the automated install scripts from source-only downloads were either failing completely or doing the wrong thing! I then ripped out old Tango copies throughout my computer and systematically forced files to be int he right spots. I don't know why I tend to have so much trouble installing Tango, but I always seem to :(
Mar 26 2008
parent reply Lars Ivar Igesund <larsivar igesund.net> writes:
Jason House wrote:

 Lars Ivar Igesund wrote:
 
 Jason House wrote:
 
 Sean Kelly wrote:
 
 But I'll admit to being a bit surprised that the
 Tango build process is painful.  It amounts to running one script, at
 least for the base lib.

Ok, so here's my latest experience *after* learning about http://dsource.org/projects/tango/wiki/PreviousReleases... I clocked myself at 45 minutes to do it (with recornding my steps here). After breaking my system completely at a few points, I'm now back where I started, with the two linker errors from the other day :( Did I do anything wrong? Any *other* ideas what could be going wrong?

I am awfully sorry for not having noticed this before, those two functions were not part of 0.99.4, but 0.99.5 (they were added to Tango svn immediately after 0.99.4 release). I won't speculate as to how difficult it is to backport just that part, so I will instead ask why upgrading to 0.99.5 is a problem?

Tango 0.99.5 has two independent implementations of split, and both were broken. I submitted a bug report and they are now fixed in SVN. Last night, I upgraded to the latest svn and found string concatenation was broken (which I then told to others on #d.tango who verified it)

Yes, the breaking "fix" has been reverted.
 
 As for the build process, I believe the documentation is correct and
 concise and there is little more I can do, especially if you're suspicous
 of all automatic scripts we create. ;)

I'm only suspicious because I've historically had so much trouble with them. The worst was the self-installing binaries that wouldn't print anything and fail. You'll noticed buried in my replay of events that the binary-only download for 0.99.4 was missing a file. Even worse, the installation failed miserably after using the installer from it.

That's too bad :(
 
 The source download of 0.99.4 worked better.  My chats on #d.tango
 yesterday indicate that the user libraries are not installed by default
 with the
 installation scripts in lib...  another small oversight with the
 installers.  dsss users won't notice because dsss takes care of that part
 (but not other parts)

Not oversight, more a lack of time to make all parts consistent (DMD and GDC scripts for instance).
 
 Later in the night, when I did upgrade to the latest svn version using the
 automated install scripts from the source, I still had the two linking
 errors.  To my utter horror, what I thought was working with the automated
 install scripts from source-only downloads were either failing completely
 or doing the wrong thing!  I then ripped out old Tango copies throughout
 my computer and systematically forced files to be int he right spots.
 
 I don't know why I tend to have so much trouble installing Tango, but I
 always seem to :(

I would appreciate it very much if you could post tickets for any installation script failures you may still have -- Lars Ivar Igesund blog at http://larsivi.net DSource, #d.tango & #D: larsivi Dancing the Tango
Mar 26 2008
next sibling parent Jason House <jason.james.house gmail.com> writes:
Lars Ivar Igesund wrote:
 I would appreciate it very much if you could post tickets for any
 installation script failures you may still have

I'll do that for future installations. For now, I submitted tickets two tickets. 1003 - make installer operation less opaque (will help me identify future installer problems) 1004 - Missing user library installation script
Mar 26 2008
prev sibling parent reply e-t172 <e-t172 akegroup.org> writes:
Lars Ivar Igesund a écrit :
 That's too bad :(
 
 The source download of 0.99.4 worked better.  My chats on #d.tango
 yesterday indicate that the user libraries are not installed by default
 with the
 installation scripts in lib...  another small oversight with the
 installers.  dsss users won't notice because dsss takes care of that part
 (but not other parts)

Not oversight, more a lack of time to make all parts consistent (DMD and GDC scripts for instance).

I'd like to convert all the Tango compilation and installation scripts to Makefiles. I already wrote some Makefiles to compile and install Tango for my personal usage because I was pissed off by the shell scripts. I'd like to "proper" them and propose them for inclusion in Tango. Are the Tango developers interested in this ? (please note that these Makefiles will only be tested with DMD and GDC on Linux).
Mar 27 2008
next sibling parent Lars Ivar Igesund <larsivar igesund.net> writes:
e-t172 Wrote:

 Lars Ivar Igesund a écrit :
 That's too bad :(
 
 The source download of 0.99.4 worked better.  My chats on #d.tango
 yesterday indicate that the user libraries are not installed by default
 with the
 installation scripts in lib...  another small oversight with the
 installers.  dsss users won't notice because dsss takes care of that part
 (but not other parts)

Not oversight, more a lack of time to make all parts consistent (DMD and GDC scripts for instance).

I'd like to convert all the Tango compilation and installation scripts to Makefiles. I already wrote some Makefiles to compile and install Tango for my personal usage because I was pissed off by the shell scripts. I'd like to "proper" them and propose them for inclusion in Tango. Are the Tango developers interested in this ? (please note that these Makefiles will only be tested with DMD and GDC on Linux).

I'd rather you tell more about your plans first, why, what, gains, etc - over in our forum. At least I have somewhat of an allergy against makefiles and potential helper tools like autocrap. Lars Ivar
Mar 27 2008
prev sibling parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from e-t172 (e-t172 akegroup.org)'s article
 Lars Ivar Igesund a écrit :
 That's too bad :(

 The source download of 0.99.4 worked better.  My chats on #d.tango
 yesterday indicate that the user libraries are not installed by default
 with the
 installation scripts in lib...  another small oversight with the
 installers.  dsss users won't notice because dsss takes care of that part
 (but not other parts)

Not oversight, more a lack of time to make all parts consistent (DMD and GDC scripts for instance).

to Makefiles. I already wrote some Makefiles to compile and install Tango for my personal usage because I was pissed off by the shell scripts. I'd like to "proper" them and propose them for inclusion in Tango. Are the Tango developers interested in this ? (please note that these Makefiles will only be tested with DMD and GDC on Linux).

Can you produce makefiles that do everything required and also work with the DigitalMars make tool? Even better, can you get the makefiles to optionally generate a debug build as well, and still with with DigitalMars make? It's that requirement that has forced us into using scripts in some instances, for better or worse. Sean
Mar 27 2008
parent reply e-t172 <e-t172 akegroup.org> writes:
Sean Kelly a écrit :
 Can you produce makefiles that do everything required and also work with the
DigitalMars make tool?
 Even better, can you get the makefiles to optionally generate a debug build as
well, and still with with
 DigitalMars make?  It's that requirement that has forced us into using scripts
in some instances, for
 better or worse.

Huh. I thought that nobody used make on Windows (except with MinGW)... well, if I understand correctly, that means that, currently, there are different build systems (different scripts) for Windows and for Linux, right ? Therefore, using Makefiles on Linux and the "old" system on Windows would still be an enhancement.
Mar 27 2008
parent reply Sean Kelly <sean invisibleduck.org> writes:
== Quote from e-t172 (e-t172 akegroup.org)'s article
 Sean Kelly a écrit :
 Can you produce makefiles that do everything required and also work with the
DigitalMars make


 Even better, can you get the makefiles to optionally generate a debug build as
well, and still with


 DigitalMars make?  It's that requirement that has forced us into using scripts
in some instances, for
 better or worse.


Well, Tango builds on Windows as well as *nix, so we need makefiles in both places.
 well, if I understand correctly, that means that, currently, there are
 different build systems (different scripts) for Windows and for Linux,
 right ? Therefore, using Makefiles on Linux and the "old" system on
 Windows would still be an enhancement.

It also creates maintenance issues. Right now, the makefiles are basically identical but for changing ".obj" to ".o" and the like. The user portion of Tango doesn't use a makefile but that's because it's simply easier to use a script there--the actual build process is much simpler than the runtime library. Sean
Mar 27 2008
parent reply e-t172 <e-t172 akegroup.org> writes:
Sean Kelly a écrit :
 == Quote from e-t172 (e-t172 akegroup.org)'s article
 Sean Kelly a écrit :
 Can you produce makefiles that do everything required and also work with the
DigitalMars make


 Even better, can you get the makefiles to optionally generate a debug build as
well, and still with


 DigitalMars make?  It's that requirement that has forced us into using scripts
in some instances, for
 better or worse.


Well, Tango builds on Windows as well as *nix, so we need makefiles in both places.

Yes. I've never built anything on Windows, I thought it used something different. I was wrong.
 well, if I understand correctly, that means that, currently, there are
 different build systems (different scripts) for Windows and for Linux,
 right ? Therefore, using Makefiles on Linux and the "old" system on
 Windows would still be an enhancement.

It also creates maintenance issues. Right now, the makefiles are basically identical but for changing ".obj" to ".o" and the like. The user portion of Tango doesn't use a makefile but that's because it's simply easier to use a script there--the actual build process is much simpler than the runtime library.

Before: - Three completly different shell scripts: build-dmd.bat, build-dmd.sh and build-gdc.sh - Three similar (but still different) makefiles: dmd-win32.mak, dmd-posix.mak, and gdc-posix.mak After: - One shell script: build-dmd.bat - Two different makefiles: dmd-win32.mak and posix.mak (which covers both DMD and GDC on POSIX) From my understanding, it does not create maintenance issues. I'd rather think it removes some of them.
Mar 27 2008
parent Sean Kelly <sean invisibleduck.org> writes:
== Quote from e-t172 (e-t172 akegroup.org)'s article
 Sean Kelly a écrit :
 == Quote from e-t172 (e-t172 akegroup.org)'s article
 Sean Kelly a écrit :
 Can you produce makefiles that do everything required and also work with the
DigitalMars make


 Even better, can you get the makefiles to optionally generate a debug build as
well, and still with


 DigitalMars make?  It's that requirement that has forced us into using scripts
in some instances,




 better or worse.


Well, Tango builds on Windows as well as *nix, so we need makefiles in both places.

different. I was wrong.
 well, if I understand correctly, that means that, currently, there are
 different build systems (different scripts) for Windows and for Linux,
 right ? Therefore, using Makefiles on Linux and the "old" system on
 Windows would still be an enhancement.

It also creates maintenance issues. Right now, the makefiles are basically identical but for changing ".obj" to ".o" and the like. The user portion of Tango doesn't use a makefile but that's because it's simply easier to use a script there--the actual build process is much simpler than the runtime library.

- Three completly different shell scripts: build-dmd.bat, build-dmd.sh and build-gdc.sh - Three similar (but still different) makefiles: dmd-win32.mak, dmd-posix.mak, and gdc-posix.mak After: - One shell script: build-dmd.bat - Two different makefiles: dmd-win32.mak and posix.mak (which covers both DMD and GDC on POSIX) From my understanding, it does not create maintenance issues. I'd rather think it removes some of them.

Ah gotcha. Well if you're inclined then go for it and submit them in a ticket. The current setup works, but I agree that it could be improved. Sean
Mar 27 2008