www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - std.loader comments

reply "Ben Hinkle" <ben.hinkle gmail.com> writes:
2 comments/questions about std.loader:
1) can we change the vocabulary from using "module" to something like 
"library"? The word "module" already has meaning in D and it isn't what 
std.loader means.
2) why do we need init and uninit? They just inc and dec a counter. It seems 
odd to me. 
Jul 06 2005
next sibling parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Ben Hinkle wrote:

 2 comments/questions about std.loader:
 1) can we change the vocabulary from using "module" to something like 
 "library"? The word "module" already has meaning in D and it isn't what 
 std.loader means.
 2) why do we need init and uninit? They just inc and dec a counter. It seems 
 odd to me. 

That whole module needs to be rewritten from scratch... I think Matthew already apologized publically for it ? :-) (as it looks like it was just a quick port over from C++) I believe there is a re-implementation in "Derelict" already, since std.loader was also *missing* from libphobos.a in earlier versions of the Linux DMD ? --anders
Jul 06 2005
next sibling parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Anders F Björklund" <afb algonet.se> wrote in message 
news:dagi4h$251d$1 digitaldaemon.com...
 Ben Hinkle wrote:

 2 comments/questions about std.loader:
 1) can we change the vocabulary from using "module" to something like 
 "library"? The word "module" already has meaning in D and it isn't what 
 std.loader means.
 2) why do we need init and uninit? They just inc and dec a counter. It 
 seems odd to me.

That whole module needs to be rewritten from scratch... I think Matthew already apologized publically for it ? :-) (as it looks like it was just a quick port over from C++) I believe there is a re-implementation in "Derelict" already, since std.loader was also *missing* from libphobos.a in earlier versions of the Linux DMD ? --anders

Without knowing what the plans are for phobos and/or std.loader I hope it gets attention sooner rather than later. I'm using it now and it work ok. Can the derelict version be sent to Walter for replacement? Anyone want to stand up for the derelict version?
Jul 06 2005
prev sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Anders F Björklund wrote:
 Ben Hinkle wrote:
 
 2 comments/questions about std.loader:
 1) can we change the vocabulary from using "module" to something like 
 "library"? The word "module" already has meaning in D and it isn't 
 what std.loader means.
 2) why do we need init and uninit? They just inc and dec a counter. It 
 seems odd to me. 

That whole module needs to be rewritten from scratch... I think Matthew already apologized publically for it ? :-) (as it looks like it was just a quick port over from C++) I believe there is a re-implementation in "Derelict" already, since std.loader was also *missing* from libphobos.a in earlier versions of the Linux DMD ?

As far as I know, std.loader was never compiled into the linux version of phobos. That's why derelict implemented its own, that and well, std.loader is a mess.
 
 --anders

I'd vote to replace the current std.loader with this http://svn.dsource.org/projects/derelict/trunk/DerelictUtil/derelict/util/ (name changes from 'derelict' to 'phobos' might be needed), but Walter has to remember to compile it into the linux version of phobos! (you can double check by using 'grep 'loader' libphobos.a') Otherwise, the linux users will still have to provide their own.
Jul 06 2005
next sibling parent pragma <pragma_member pathlink.com> writes:
In article <dagufn$2euf$1 digitaldaemon.com>, clayasaurus says...
Anders F Björklund wrote:
 Ben Hinkle wrote:
 
 2 comments/questions about std.loader:
 1) can we change the vocabulary from using "module" to something like 
 "library"? The word "module" already has meaning in D and it isn't 
 what std.loader means.
 2) why do we need init and uninit? They just inc and dec a counter. It 
 seems odd to me. 

That whole module needs to be rewritten from scratch... I think Matthew already apologized publically for it ? :-) (as it looks like it was just a quick port over from C++) I believe there is a re-implementation in "Derelict" already, since std.loader was also *missing* from libphobos.a in earlier versions of the Linux DMD ?

As far as I know, std.loader was never compiled into the linux version of phobos. That's why derelict implemented its own, that and well, std.loader is a mess.
 
 --anders

I'd vote to replace the current std.loader with this http://svn.dsource.org/projects/derelict/trunk/DerelictUtil/derelict/util/ (name changes from 'derelict' to 'phobos' might be needed), but Walter has to remember to compile it into the linux version of phobos! (you can double check by using 'grep 'loader' libphobos.a') Otherwise, the linux users will still have to provide their own.

While we're on the topic of std.loader, has anyone taken a look at the one I wrote for DSP? http://svn.dsource.org/projects/dsp/trunk/misc/Library.d I haven't had a chance to compile it on Linux, but in theory the Linux portion should work fine. There are some companion classes (also in the /misc directory) that are designed to work with it too, such as the LibraryCache and DllStub that make some dll-related chores easier to handle. - EricAnderton at yahoo
Jul 06 2005
prev sibling parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 I'd vote to replace the current std.loader with this  
 http://svn.dsource.org/projects/derelict/trunk/DerelictUtil/derelict/util/  
 (name changes from 'derelict' to 'phobos' might be needed), but Walter  
 has to remember to compile it into the linux version of phobos! (you can  
 double check by using 'grep 'loader' libphobos.a')

 Otherwise, the linux users will still have to provide their own.

Very nice, but please provide some meaningful error messages. It cannot be that all that is done on *any* failure is throwing an exception with the reason "i could not do that, sorry." If you don't know how to do that on the different systems, educate yourself our steal from Indigo. This is the documentation for the dynloader: http://www.uwesalomon.de/code/indigo/files/core/dynload-d.html And you will find the code for it in this archive: http://www.uwesalomon.de/code/indigo/indigo.tar.gz It is the following file: indigo/core/dynload.d It has operating-system independent checking of error messages. As you can see, the skeleton is from Kris' Mango library, but the rest of the code is mine. I release that part of indigo (dynload.d) into the public domain hereby, it is no longer under the GPL. Ciao uwe
Jul 06 2005
next sibling parent =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Uwe Salomon wrote:

 It has operating-system independent checking of error messages. As you 
 can  see, the skeleton is from Kris' Mango library, but the rest of the 
 code is  mine. I release that part of indigo (dynload.d) into the public 
 domain  hereby, it is no longer under the GPL.

There's some questions about the Mac OS X specific parts of that code, so it will either need to be replaced with some new code - or have a special license provided - was using some sample code from dlcompat: /* Copyright (c) 2002 Peter O'Gorman <ogorman users.sourceforge.net> Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy, modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software is furnished to do so, subject to the following conditions: The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software. THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE. */ Besides, the old darwin code is rather horrible and would be much shorter if just using CoreFoundation instead of dyld directly... So I think I will just "clean-room" rewrite it from scratch instead. This applies to Mango as well as Indigo and to the GDC Phobos patch too. (i.e. the stuff within the version(darwin) { } blocks) Sorry about that. Also put up a stuff on the Wiki4D, about remaining PhobosLicenseIssues. --anders
Jul 06 2005
prev sibling next sibling parent reply clayasaurus <clayasaurus gmail.com> writes:
Uwe Salomon wrote:
 I'd vote to replace the current std.loader with this  
 http://svn.dsource.org/projects/derelict/trunk/DerelictUtil/derelict/util/  
 (name changes from 'derelict' to 'phobos' might be needed), but 
 Walter  has to remember to compile it into the linux version of 
 phobos! (you can  double check by using 'grep 'loader' libphobos.a')

 Otherwise, the linux users will still have to provide their own.


I didn't write it (Mike Parker aka aldacron did), but it works well on both windows and linux. Here are the docs that explain how it works... http://svn.dsource.org/projects/derelict/trunk/docs/util.html Yes, it does need mac support, but adding that should be trivial.
 Very nice, but please provide some meaningful error messages. It cannot 
 be  that all that is done on *any* failure is throwing an exception with 
 the  reason "i could not do that, sorry." If you don't know how to do 
 that on  the different systems, educate yourself our steal from Indigo. 
 This is the  documentation for the dynloader:
 
 http://www.uwesalomon.de/code/indigo/files/core/dynload-d.html
 
 And you will find the code for it in this archive:
 
 http://www.uwesalomon.de/code/indigo/indigo.tar.gz
 
 It is the following file:
 
 indigo/core/dynload.d
 
 It has operating-system independent checking of error messages. As you 
 can  see, the skeleton is from Kris' Mango library, but the rest of the 
 code is  mine. I release that part of indigo (dynload.d) into the public 
 domain  hereby, it is no longer under the GPL.
 
 Ciao
 uwe

Jul 06 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
clayasaurus wrote:

 Here are the docs that explain how it works...
 http://svn.dsource.org/projects/derelict/trunk/docs/util.html
 
 Yes, it does need mac support, but adding that should be trivial.

It's trivial if you require that support for dlopen and friends is present, which is easy to add for older Mac OS X by installing the dlcompat library (the "dl" API is included in Mac OS X 10.4) http://www.opendarwin.org/projects/dlcompat/ As usual, I recommend against using the version(linux) - use version(Unix) instead and do a special case for DMD's "linux" ? In this file, perhaps a version(DLOPEN) or something is better ? version(linux) // for DMD version = DLOPEN; version(Unix) // for GDC version = DLOPEN; Hope that DMD adds the Unix version soon, as it is missing there. (as most of the portable stuff seems to be missing from the usual DMD Windows/Linux binary installation, and is only found in GDC) --anders
Jul 06 2005
parent reply Uwe Salomon <Uwe_member pathlink.com> writes:
As usual, I recommend against using the version(linux) - use
version(Unix) instead and do a special case for DMD's "linux" ?
In this file, perhaps a version(DLOPEN) or something is better ?

version(linux) // for DMD
      version = DLOPEN;
version(Unix) // for GDC
      version = DLOPEN;

Hope that DMD adds the Unix version soon, as it is missing there.
(as most of the portable stuff seems to be missing from the usual
DMD Windows/Linux binary installation, and is only found in GDC)

Is it allowed to write: version(linux) version = Unix; version(Unix) { // Complicated code here... Will that unify the two compilers' behaviour? Ciao uwe
Jul 06 2005
parent reply =?ISO-8859-1?Q?Anders_F_Bj=F6rklund?= <afb algonet.se> writes:
Uwe Salomon wrote:

 Is it allowed to write:
 
 version(linux)
 version = Unix;
 
 version(Unix)
 {
 // Complicated code here...
 
 Will that unify the two compilers' behaviour?

That is "allowed", it just gets a little tedious around the eleventeenth file you have to add it to ? Note that you can still use "linux" if you really mean Linux and not just any old UNIX/Posix thing... But for 99% of the time, import std.c.unix.unix is the one (this file is *also* missing from DMD) And workarounds for that is even more tedious, so it would be a *good* thing if DMD supported Unix... --anders PS. No, it won't be version(Posix). It's "Unix", as per discussions on D.gnu. Live with it. :-)
Jul 07 2005
parent reply "Uwe Salomon" <post uwesalomon.de> writes:
 Note that you can still use "linux" if you really
 mean Linux and not just any old UNIX/Posix thing...

It always annoys me a bit that "linux" and "darwin" are written in small letters, while "Windows" and "Unix" have capital letters... Strange inconsistency.
 But for 99% of the time, import std.c.unix.unix
 is the one (this file is *also* missing from DMD)

I noticed that std.c.unix.unix imports gcc.configunix, which is autogenerated. Would you mind sending me some "finished" gcc.configunix files for the platforms you can get a hold on, please? If it does not make too much work, as it is useful for me, but not terribly important. Thanks uwe
 PS. No, it won't be version(Posix). It's "Unix",
      as per discussions on D.gnu. Live with it. :-)

Aug 08 2005
parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Uwe Salomon wrote:

 It always annoys me a bit that "linux" and "darwin" are written in 
 small  letters, while "Windows" and "Unix" have capital letters... 
 Strange  inconsistency.

Yeah, it's a tad annoying and has caused a few version(Linux) bugs. :-( But even more troublesome is that "Unix" is missing from DMD altogether.
 But for 99% of the time, import std.c.unix.unix
 is the one (this file is *also* missing from DMD)

I noticed that std.c.unix.unix imports gcc.configunix, which is autogenerated. Would you mind sending me some "finished" gcc.configunix files for the platforms you can get a hold on, please? If it does not make too much work, as it is useful for me, but not terribly important.

I can send you the darwin (Panther) and linux (Fedora), if you like. The discussion was actually mostly about the inconsistent naming, and not so much about the actual contents of the import module...
 PS. No, it won't be version(Posix). It's "Unix",
      as per discussions on D.gnu. Live with it.  :-) 

Argh! Wait until i've positioned my forces. Posix will strike back! :)

One can argue that it should have *both*, since DMD defines both Windows and Win32... But in the end, David went with the current: version(Unix) --anders
Aug 08 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 But for 99% of the time, import std.c.unix.unix
 is the one (this file is *also* missing from DMD)

autogenerated. Would you mind sending me some "finished" gcc.configunix files for the platforms you can get a hold on, please? If it does not make too much work, as it is useful for me, but not terribly important.

I can send you the darwin (Panther) and linux (Fedora), if you like.

That would be very nice, thanks! I only need the darwin one, as i run Fedora myself.
 The discussion was actually mostly about the inconsistent naming,
 and not so much about the actual contents of the import module...

I know. I'm needing the stat() related functions and data types now, and remembered that i discussed something related some time ago. :) Ciao uwe
Aug 09 2005
prev sibling next sibling parent reply "Ben Hinkle" <bhinkle mathworks.com> writes:
"Uwe Salomon" <post uwesalomon.de> wrote in message 
news:op.sth4q1rx6yjbe6 sandmann.maerchenwald.net...
 I'd vote to replace the current std.loader with this 
 http://svn.dsource.org/projects/derelict/trunk/DerelictUtil/derelict/util/ 
 (name changes from 'derelict' to 'phobos' might be needed), but Walter 
 has to remember to compile it into the linux version of phobos! (you can 
 double check by using 'grep 'loader' libphobos.a')

 Otherwise, the linux users will still have to provide their own.

Very nice, but please provide some meaningful error messages. It cannot be that all that is done on *any* failure is throwing an exception with the reason "i could not do that, sorry." If you don't know how to do that on the different systems, educate yourself our steal from Indigo. This is the documentation for the dynloader: http://www.uwesalomon.de/code/indigo/files/core/dynload-d.html And you will find the code for it in this archive: http://www.uwesalomon.de/code/indigo/indigo.tar.gz It is the following file: indigo/core/dynload.d It has operating-system independent checking of error messages. As you can see, the skeleton is from Kris' Mango library, but the rest of the code is mine. I release that part of indigo (dynload.d) into the public domain hereby, it is no longer under the GPL. Ciao uwe

It looks like a downside of that API is that you have to know what functions you want to load before you call "bind". You can't load a library and then look up symbols later as needed. In a perfect world I'd like to use something like LibHandle loadLibrary(char[] name); void* lookupSymbol(LibHandle lib, char[] name); int unloadLibrary(LibHandle lib); since then the bind() function can be a layer on top of that that loads a library and then loops over a set of names and looks them up.
Jul 06 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
 It looks like a downside of that API is that you have to know what  
 functions
 you want to load before you call "bind". You can't load a library and  
 then look up symbols later as needed.

Yes. I did not want to propose that you use my API, or even copy&paste the module. I just wanted to advertise my error-handling code, which fetches the error message from the OS, and throws it with the exception, to provide the user some more useful information. Ciao uwe
Jul 06 2005
prev sibling parent reply =?UTF-8?B?QW5kZXJzIEYgQmrDtnJrbHVuZA==?= <afb algonet.se> writes:
Uwe Salomon wrote:

 It is the following file:
 
 indigo/core/dynload.d
 
 It has operating-system independent checking of error messages. As you 
 can  see, the skeleton is from Kris' Mango library, but the rest of the 
 code is  mine. I release that part of indigo (dynload.d) into the public 
 domain  hereby, it is no longer under the GPL.

BTW; The comments in that file are (a little) wrong: // Function: libraryName() // // Produces a filename for a library out of a name and a version. This can // be used as the library argument for <bind()>. The function acts // differently depending on the platform. If the name is "bibo" and the // version is "3", it returns: // // Win32 - "bibo3.dll" // linux - "libbibo.so.3" // darwin - "libbibo.dylib.3" That should be "libbibo.3.dylib" for Darwin / Mac OS X. Otherwise it seems OK, using "dl" which means you need either dlcompat or Mac OS X 10.3 or later (note that this is a *runtime* requirement) As you're not using the code from dlcompat, no extra copyright required. --anders
Jul 06 2005
parent "Uwe Salomon" <post uwesalomon.de> writes:
      // Win32  - "bibo3.dll"
      // linux  - "libbibo.so.3"
      // darwin - "libbibo.dylib.3"

 That should be "libbibo.3.dylib" for Darwin / Mac OS X.

Argh. Bugs in the docs... Thanks! uwe
Jul 06 2005
prev sibling parent reply Dejan Lekic <leka entropy.tmok.com> writes:
Ben, I think phobos authors perhaps decided to reserve init and uninit for
apropriate init() and fini() library functions (usually something like
__attribute__ ((constructor)) void init() for example) , which is IMHO
good...
Anyway, I think working (on Linux) std.loader is a very needed feature.

Kind regards

Dejan

-- 
...........
Dejan Lekic
  http://dejan.lekic.org
  
Jul 06 2005
parent "Ben Hinkle" <bhinkle mathworks.com> writes:
"Dejan Lekic" <leka entropy.tmok.com> wrote in message 
news:dah4r4$2k1g$1 digitaldaemon.com...
 Ben, I think phobos authors perhaps decided to reserve init and uninit for
 apropriate init() and fini() library functions (usually something like
 __attribute__ ((constructor)) void init() for example) , which is IMHO
 good...

Are init/uninit for the library being loaded? They are just globals for the std.loader module independent of the library being loaded. I'm not sure why init/uninit aren't static ctor/dtor if the std.loader module needs initialization.
Jul 06 2005