View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0000200 | ascend | packages | public | 2006-01-05 09:19 | 2009-05-01 17:48 |
| Reporter | john | ||||
| Assigned To | john | ||||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | |||||
| Target Version | Fixed in Version | 0.9.5.x | |||
| Summary | 0000200: ascFreeAllVars should be self-registering | ||||
| Description | Perhaps 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. | ||||
| Tags | No tags attached. | ||||
|
|
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 Cheers JP |
|
|
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) specifically, 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. |
|
|
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 pkgben.so, 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? JP |
|
|
External packages are working on linux, mac and win32 now, so I will close this bug for now. |
| 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 |
