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


Argh! Wait until i've positioned my forces. Posix will strike back! :)
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)


  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.


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