Forum TI-Planet.org

Hello,

I am still working on my GUI toolkit but I can see one possible problem in a near future : size of the executable may quickly become sufficiently big to limit the use of the toolkit for numerous projects / applications.

The best would be to be able to create a library containing all the classes and methods and link this library dynamically to the application program(s), so what the "repetitive" part of the code would just be written once on the calculator and hence save a large amount of "disk" space.

I tried to check if it is possible to create dynamically linked libraries with Ndless on TI NSpire, but just found this Github https://github.com/nspiredev500/nspire-dynamic-linking-PoC from nspiredev500 through the codewalr.us page here : https://codewalr.us/index.php?topic=2554.0 ... and to be honnest, it is not cristal clear if the PoC can be transferred to an actual "full size program". It also seems to be based on a replacement OS called OSExt, so no proof it is actually working on a "standard" (I don't think the wording is correct, but I cannot find something better ) Ndless program.

Considering the fact that the last update of the GitHub repository is quite old (almost one year and half), maybe is there a better way (or at least better documented way) of making a dynamic library and to link to an application program on NSpire with Ndless.

Does anyone already encountered that issue and managed it ?

Thanks in advance

Sly

Hi,
I'm the one who made the dynamic linking PoC.
Sorry for replying so late, I had another project and I'm now studying computer science, so I don't have so much free time anymore.
For now the PoC cannot be used easily, but I'm working on something like that. I want to develop a on-calc C toolchain an a part of that is a linker.
When the linker is finished, I will make it a separate program that can open elf files and automatically links in the libraries at runtime.
I actually want to submit some changes to Ndless to make it even more efficient, e.g. sharing the code segment in memory with other programs, so If resident programs depend on the library, only one copy is using up RAM.
I looked at my linker and I think it can already sucessfully link an ELF file to a ZEHN file. At that point I can just include the ZEHN loader and the program can run linked from RAM.
I think I will be finished with it this year, at least the basic version without the optimizations that have to be integrated into Ndless itself.

By the way, I think I will use your widget library for the on-calc IDE .

nspiredev500

Hi Nspiredev500,

very nice to read you are still working on that.
I had also to pause the development of the GUI Toolkit for 2 months as I was extremely busy at work, but even if my fingers where not hitting the keyboard for some weeks, I am thinking on the new revision (let say rev 1.0+) with rewritten code and introduction of new architecture.
The target is to be more efficient and more versatile. i will try to take benefit of the first revisions mistakes to improve the toolkit.

Please let us know when you have something working, for sure it would be a great enhancement of Ndless.

Sly

Hey, I'm back to nspire development right now, and started working on the Ndless improvements and dynamic linker.
After looking a bit into dynamic linking I realized that sharing code segments isn't possible when all programs share an address space, but not sharing segments just makes linking easier. I'm rewriting the linker in C++, using proper data structures should make it much easier. But reading my last post here, I'm not making any time gurantees this time .

But another thing I'm looking into is sort of dynamic static linking: newlib can only be linked statically, so if my linker can also do static linking and you copy libc.a to the calculator, you won't have to include libc in every executable.

nspiredev500

The menu options for the nspire CAS are a bit different: menu>actions(1)>library(7)>refresh library(1)