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

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

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

> 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

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

>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

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

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

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

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