El 08/04/2008 01:20 PM, Pau Arumí escribió:
On dl, 2008-08-04 at 12:12 +0200, David García Garzón wrote:
El Monday 04 August 2008 11:15:20 Pau Arumí va escriure:
LAZY is needed there. It checks for a given symbol that is only present
on Ladspa plugins to avoid loading a dynamic lib that is not a ladspa.
BTW, are we still trying to open _any_ file? We should restrict
to .so, .dylib and .dll, and save time (and traces).
Another related feature: as Hernan suggested, we should support "reload
clam plugins" from NE. I think Natanael can code this with the eyes
closed :-) -- It actually could be a _general_ (clam, ladspa) reload
option if it is easier.
For ladspa plugins is really simple, is basically the same code used for
the faust ones. But I have to check how are working the others plugins
constructors, and I don't have Windows to check how the libraries
management works on it. So, for the release I'm a little afraid to do
that...
Maybe, the fist goal should be obtaining (and keeping) a list of the loaded
plugin libraries (and maybe a list the processings they contain) so that we
can provide a unload/reload dialog with the list.
Why not just "reload" and avoid putting duplicate keys in the factory --
which AFAIK, is what is done for Faust?
Much more simpler first goal, I'd say.
I agree. Anyway, at least the first point of David suggestions would be
needed:
El 08/04/2008 07:12 AM, David García Garzón escribió:
My suggestion:
* First move all dl_ calls to the base RunTimeLibraryLoader primitives (see
LoadLibraryError and FullyLoadLibrary) so that we can encapsulate the
platform dependant bits.
* Add in the same class some static structure that holds the list of
libraries.
* Add also a static state that holds the currently loading library and set it
and unset it when appropiate.
* When registering a factory entry check that state and if set, populate the
structure or just add some metadata.
* The factory registrator destructor should remove the processing type from
the factory (this should be TDD) in order to allow unloading the library.
I was to ask about TDD, but google helped me:
http://en.wikipedia.org/wiki/Test-driven_development :-)
I'm learning a lot of terms and concepts about software design lately. :)
I am not sure whether this should work. But, anyway, be carefull, remember
that we are in release!!! The plugin system cannot be broken!
As I wrote above, I can test it only under Linux, so if you agree and
the code works I could commit just for the non-windows environments for now.
Regards,
Natanael.
P
My suggestion:
* First move all dl_ calls to the base RunTimeLibraryLoader primitives (see
LoadLibraryError and FullyLoadLibrary) so that we can encapsulate the
platform dependant bits.
* Add in the same class some static structure that holds the list of
libraries.
* Add also a static state that holds the currently loading library and set it
and unset it when appropiate.
* When registering a factory entry check that state and if set, populate the
structure or just add some metadata.
* The factory registrator destructor should remove the processing type from
the factory (this should be TDD) in order to allow unloading the library.
I am not sure whether this should work. But, anyway, be carefull, remember
that we are in release!!! The plugin system cannot be broken!
David.
_______________________________________________
Clam-devel mailing list
[email protected]
https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
_______________________________________________
Clam-devel mailing list
[email protected]
https://llistes.projectes.lafarga.org/cgi-bin/mailman/listinfo/clam-devel
