View Issue Details

IDProjectCategoryView StatusLast Update
0000200ascendpackagespublic2009-05-01 17:48
Assigned Tojohn 
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version0.9.5.x 
Summary0000200: ascFreeAllVars should be self-registering
DescriptionPerhaps the ascFreeAllVars external package should be self-registering, in order to simpilfy the code.

Also, I wonder if a default name for the package registration function should be incorporated into the ASCEND syntax, so that instead of

IMPORT myregistrationfunction FROM mylibrary;

we can use

IMPORT mylibrary;

Probably the current implementation has something to do with avoiding name clashes in the case of static linking of packages.
TagsNo tags attached.




2006-01-18 17:18

administrator   ~0000238

Reminder sent to: ben

Hi Ben

I wonder what you think about this one then. I would propose to create the necessary extra functions in ascFreeAllVars.c to makes this a completely self-sufficient dlopenable library, rather than the static-linked one it currently is. This only means adding the 'registration function' to the ascFreeAllVars.c and cleaning up some stuck in packages.c



2006-01-24 09:22

manager   ~0000254

This was discussed at the time we implemented packages and
the syntax needs to remain the same because nothing has changed since.
(unless we go to requiring a metadata file)

a) as you say, static linking will not tolerate conflicting
symbol names and we do require the ability to static link.

b) there are still mainstream os out there that do not support
(and situations where even if they do, one may not want the support)
loading the library into a private symbol table. The notion
that there is a single name for the registration is *highly*
pythonesque and should not be forced on people who use ascend.

What we probably should consider (and haven't yet) is whether
in addition to a .so (.dll) file, we also define a standard for
a small metadata (probably xml) file describing each extension.
Simple tools in ascend or pyascend could easily parse all the
.a4x files (containing xml) in some path and offer the list
that result to the user (of which plugins to load) or lookup
the symbol to dynamically load. This would get us to the syntax
you propose:
import mylibrary;
but the import process would first find the mylibrary.a4x
and from the a4x file determine the symbol to dlsym with.

Would this make things satisfactory?
It turns out the metadata files come in handy for other things
as well.


2006-01-24 14:11

administrator   ~0000258

Last edited: 2006-01-24 14:12

Hi Ben

I don't think I support the idea of an extra XML file. There's nothing you can do with that that you can't do with a well-designed shared-object.

The 'mainstream operating systems' that don't support dlopening - what are they? I believe CRAYs or the big multiprocessor unices, maybe. Is that right?

Perhaps it would suffice to have a default registration function name derived from the .so filename: for example, for, assume 'pkgben_register'. If it's not found then

IMPORT pkgben

would throw an error. That would work for both static and dynamic linking. How would that be, then?



2008-07-10 16:42

administrator   ~0000472

External packages are working on linux, mac and win32 now, so I will close this bug for now.

Issue History

Date Modified Username Field Change
2006-01-05 09:19 john New Issue
2006-01-18 17:18 john Note Added: 0000238
2006-01-24 09:22 ben Note Added: 0000254
2006-01-24 14:11 john Note Added: 0000258
2006-01-24 14:12 john Note Edited: 0000258
2006-02-07 13:17 john Target release => 1.0
2006-02-07 13:24 john Target release 1.0 => 0.9.6
2006-05-10 02:39 john Target release 0.9.6 => 1.0
2008-02-10 17:59 john Status new => assigned
2008-02-10 17:59 john Assigned To => john
2008-07-10 16:42 john Status assigned => resolved
2008-07-10 16:42 john Resolution open => fixed
2008-07-10 16:42 john Note Added: 0000472
2008-07-10 16:44 john Fixed in Version => 0.9.5.x
2009-05-01 17:48 john Status resolved => closed