Re: [Chicken-users] Some questions about loading libraries

[Felix]

> [BTW .... my understanding of the module system is a bit vague, but I've
> seen that the docs say something like "modules are purely a syntactic
> construct" ... so am I right in thinking that means that modules really
> don't exist at runtime ... and thus, if conditional imports were possible
> at all, they would only be possible at compile time?]

Only with interpreted/evaluated code.

> 
> The other problem is loading the arbitrary extension libraries that users
> of my CMS can install at will from a huge online collection (there's my
> megalomania talking again ;). Although there would be a potentially
> infinite number of different extensions, [I think] they would really all be
> fancy HTTP request handlers. Here the main problem is just having a
> reliable way to find the appropriate library in the filesystem. Regarding
> compilation or lack thereof, my plan is to recommend compiling all
> libraries, but as mentioned above, I expect there are use cases where users
> would not be able to compile any code, so I would like to give them the
> option of installing a binary that could load the extensions as interpreted
> code--if it's not unreasonably difficult to do so.

That should be possible. Procedures are first-class, so a plugin could
register procedures somewhere globally.  Perhaps you could use some
form of OOP, where plugins derive from a common base class/object and
so support a given interface.

> I tried this, and on my system it only works for 'include', not for
> 'require'. BTW, I have Chicken 4.8.0 on Arch Linux. I compiled the package
> myself, but only in order to have the latest version; i.e. I didn't hack
> anything. There were no patches, and the build() function in the PKGBUILD
> script is:
> 
> build() {
>   cd ${pkgname}-${pkgver}
> 
>   # parallel builds are not supported..
>   export MAKEFLAGS="${MAKEFLAGS/-j?/}"
> 
>   # some yummy make options there. check out README in the tarball.
>   make PLATFORM=linux PREFIX=/usr
> }
> 
> Nothing unusual there, right?

No, looks fine. You can simply use "load" and scan a list of
"plugin-directories" to locate the necessary .so files. Or perhaps I'm
misunderstanding your intentions?

> 
> See above re: compilation/evaluation. As far as using symbols goes,
> I've haven't gotten to a detailed plan yet, but I think each plugin
> would register itself/its functions in a data structure established
> by the main library. With an open-ended collection of arbitrary
> components, I can't see any other sane way to do it.

Sounds good. "load" can handle both source-files and compiled code.

> Ah, thank you! I was planning to look for a function something like that,
> but had no idea what its name might be. I'll try it. Are there any
> non-obvious pitfalls I should be aware of in using this?

I don't think so, with the exception that it's quite horrible and
gnarly platform-specific code. That functionality could be provided in
a more convenient way, so apologies for the crudeness of the API.

> Ohhhh, I see. This works for interpreted but not compiled code. At least
> that's how it is for me. Is that expected behavior? I didn't understand
> that from the docs.

It should work for compiled code and for interpreted code.


cheers,
felix