www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - WeakRef updated to support Tango, too

reply Bill Baxter <dnewsgroup billbaxter.com> writes:
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


 I'm no maintainer of Scrapple, but making a ticket is certainly a
 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:
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:
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




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?

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




 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?
 
 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




 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?
 
 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




 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?

 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.

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.


 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.


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.


 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?


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).


 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).


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




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, 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




 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, 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




 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, 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.


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