Add support for saving and restoring procedures
As reported by @swrh and discussed with @ebknudsen on SF.net back in 2011 (https://sourceforge.net/p/gnudatalanguage/feature-requests/100/):
The current implementation of SAVE and RESTORE procedures supports saving variables only. IDL allows to save also procedures.
To summarise the discussion (also the one with Marc during the GDL workshop in Paris):
- binary compatibility with IDL is not attainable by design, and is not an aim,
- the key rationale is the potential speed gain due to the option of skipping lengthy compilation of large codebases (effectively, this could be a similar mechanism as the one in Python that produces .pyc files),
- it would be needed to serialise the ProgNode instances.
Esay as a breeze as soon as ... serializing Prognodes instances is done! Please open a dedicated enhancement issue on this serialization need.
I also share the desire of this request. Some legacy applications that I work with utilize .sav files as essentially .dll files with respect to IDL. Looking briefly at the code, it appears that the gdl interpreter internally converts the source into bytecode. If we could dump this memory to a file and restore to memory that would be all I would be interested in - even if this requires the same machine / architecture to read in.
Hi @GillesDuvert and @slayoo, I saw that @swrh wants to work on saving and restoring procedures:
https://github.com/gnudatalanguage/gdl/issues/126#issuecomment-819871174
Who could answer his questions so that he can try working on this issue?
I am asking because it would be a very nice feature to have.
I've just pointed out the HACKING file, but I guess it will be of very limitted help...
strange, I was sure I wrote a rather long topic on this to answer @ramueller11 . GH seems to have swallowed it.
Hi guys, is there any news on saving and restoring procedures? How complicated is this to implement? Who could work on this?
I have this in mind so it's going to arrive... eventually. Any help will be warmly welcome of course.
#1681 goes a long way into solving this. Stay tuned.