| On other systems, such as PD, there is a naming convention
that matches the library name with the init function. So
when
a user tries to use a class that has not been loaded, the
system
looks for a library that matches the name of the function.
(Not
all classes use that mechanism, though. Most of them are all
packed up in single libraries that need to be loaded at
start time.)
I agree though that something like this might not be worth
our
while, as the libraries would be tiny and numerous.
Victor
>
> On Saturday 11 March 2006 04:26, Anthony Kozar wrote:
>
> > I do not care whether the functionality is kept or not.
> > (But I do wonder how it is implemented -- I haven't look
> > at the code yet. If the file opcodes.dir has to be
> maintained, then it might be awkward).
>
> There is not really any other way to know which opcodes
> are contained in a particular library. If the library
> needs to be loaded to find out the list of opcodes, that
> makes the whole idea pointless as the goal was to avoid
> loading the plugins in the first place.
>
> > In general though, I do not agree with the philosophy of
> > merging most opcodes into a single plugin. That was
> > fine for the 5.00 release, but I would hope that new
> > opcodes from now on will be added to new libraries
> (unless they fit into an existing group). Since it is
> > jpff's intention to add more opcodes to the barmodel
> > library, I hope that it will stay separate.
> > My reasoning is that that is the purpose of having
> > plugins in the first place -- modularity. It would
> > certainly run faster if everything was merged back into
> Csound5Lib, but I like the flexibility of multiple
> > libraries. I also think that it could be confusing if
> > the contents of "old" libraries change too much.
>
> In other words, merging libraries benefits the majority of
> users who do not fiddle with deleting separate plugin
> libraries by hand, and do not want to worry about not
> being able to compile an orchestra that contains opcodes
> that were previously considered unimportant and were
> deleted. Without deferred loading, very few users would
> bother selecting plugins manually for a small reduction in
> memory usage and start-up time, yet a single large library
> loads faster and uses less memory than the several dozen
> small ones it replaces. It also means fewer build targets
> and fewer files in the binary distributions. Also, the
> stdopcod library is very small by modern standards: with a
> typical computer that has 512 MB of memory, it only uses
> about 0.1% of the total available space (anything with
> external dependencies, like the python opcodes, is likely
> to be larger). It does not really make much sense to have
> a seprate DLL for something that has only about 2K of
> useful code (like the new barmodel plugin) when the
> overhead of library headers, startup code, page alignment,
> etc. is already larger than that.
>
> Plugins are really mostly useful to have third party
> modules that are distributed separately from the canonical
> package, but so far that was not taken advantage of at all
> , as everything just ended up in the csound5 CVS anyway.
> The other advantage is to separate functionality with
> external dependencies (e.g. FLTK or Python) so that if the
> dependency is not found at run-time, that will not prevent
> the rest from working. That is why the stdopcod library
> only contains code with no dependencies (that includes the
> standard C++ library) other than what is already required
> by the main library.
>
>
> -------------------------------------------------------
> This SF.Net email is sponsored by xPML, a groundbreaking
> scripting language that extends applications into web and
> mobile media. Attend the live webcast and join the prime
> developer group breaking into this new coding territory!
> http://sel.as-us.falkag.net/sel?
cmd=lnk&kid=110944&bid=241720&dat=121642
> _______________________________________________
> Csound-devel mailing list
> Csound-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/csound-devel
-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642
_______________________________________________
Csound-devel mailing list
Csound-devel@lists.sourceforge.net |