### Author Topic: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)  (Read 22985 times)

0 Members and 1 Guest are viewing this topic.

#### Jim Bauwens

• Lua! Nspire! Linux!
• Editor
• LV10 31337 u53r (Next: 2000)
• Posts: 1881
• Rating: +206/-7
• Linux!
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #30 on: August 09, 2013, 01:06:40 pm »
nRemote or NspireHub take screenshots and decode pixels that represent data (that we put there at 0,0 absolute position of the display). It then sends a trigger to the calc to let know that it received the data.
« Last Edit: August 09, 2013, 01:12:56 pm by Jim Bauwens »

#### Lionel Debroux

• LV11 Super Veteran (Next: 3000)
• Posts: 2135
• Rating: +290/-45
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #31 on: August 09, 2013, 01:15:36 pm »
Quote
Quote
Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)
Oh, that wouldn't be a good idea. I prefer having a single repo.
Yeah, a single repo is less of a maintenance problem.

Quote
That's good, although some things like
Code: [Select]
#define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }can already be called obfuscation
I removed a number of uses of that ugly, bug-inducing macro over time, but there remain many of them...

Quote
Does "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!
For our purposes, ticalcs_calc_execute (calc_xx.c) calls into the ".execute" field of the calc_nsp structure defined in calc_nsp.c, which itself points to a function whose entire source code is
Code: [Select]
static int execute (CalcHandle* handle, VarEntry *ve, const char *args){ return 0;}So libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).

Quote
Oh, I don't think sending keys is a good solution.
For most models, it's the only solution - only the newest protocols (latter DBUS, DUSB) have a proper remote exec command, and maybe the Nspire doesn't

Quote
What if the user presses a key manually or disconnects the calc?
PEBKAC is not much of our concern ^^

Quote
Why separate conversion from file types?
For character conversion outside of files directly suitable for the calculator - for instance, in program editors. The author of the unfinished, long-unmaintained, buggy KTIGCC considers two-way translation between calculator charset and computer charset as a major feature of his program, but unsurprisingly, it has seen pretty little usage in the wild...

Quote
Why seperate libticables from libticalcs? Calcs without cables don't work
Sending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.

Quote
The code base is too huge to be maintainable.
I don't think so, the TILP code base is far from being unmaintainable. It's in a reasonably usable state, and most of the code evolves pretty little, if at all. TIEmu is an unmaintainable code base, however, due to the fragile integration of outdated versions of a patched GDB, Tk, Insight, all of that mixed in the same event loop and sticked together by a fragile build system.
When I made the strip_tilp_nspire experiment, I didn't expect TI to come up with a new crappy, totally non-innovative TI-Z80 model, aimed at milking customers and expanding the lifespan of the TI-Z80 series by years...

Quote
A complete rewrite would take years, though.
A partial rewrite of <35K RLOC (some of the code could be copied with little in the way of changes) doesn't take years full-time, but it's still too lengthy a task for me to take on. There are other, more fun and more productive tasks to work on...

Quote
Browsers having USB support? Why not integrate firefox in the linux kernel and booting firefox directly?
Well, people do lots of crazy stuff with browsers nowadays
Even TI-Z80 and TI-68k emulators, and emulators for ARM cores as well.
« Last Edit: August 09, 2013, 01:21:14 pm by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #32 on: August 09, 2013, 01:39:36 pm »
Quote
Does "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!
For our purposes, ticalcs_calc_execute (calc_xx.c) calls into the ".execute" field of the calc_nsp structure defined in calc_nsp.c, which itself points to a function whose entire source code is
Code: [Select]
static int execute (CalcHandle* handle, VarEntry *ve, const char *args){ return 0;}So libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).
I doubt it. What do you want to execute without ndless?
Quote
Quote
Oh, I don't think sending keys is a good solution.
For most models, it's the only solution - only the newest protocols (latter DBUS, DUSB) have a proper remote exec command, and maybe the Nspire doesn't
Or giving up this communication and letting the app store handle everything. A version on-calc would still be needed to install an app on a friend's calculator without any PC near.
Quote
Quote
What if the user presses a key manually or disconnects the calc?
PEBKAC is not much of our concern ^^
It is at least a bit. Imagine after the file transfer finished the user presses escape (to play the game) and the appstore displays an error message?
Quote
Quote
Why separate conversion from file types?
For character conversion outside of files directly suitable for the calculator - for instance, in program editors. The author of the unfinished, long-unmaintained, buggy KTIGCC considers two-way translation between calculator charset and computer charset as a major feature of his program, but unsurprisingly, it has seen pretty little usage in the wild...

Quote
Why seperate libticables from libticalcs? Calcs without cables don't work
Sending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.
Why not both layers in one library?
Quote
Quote
The code base is too huge to be maintainable.
I don't think so, the TILP code base is far from being unmaintainable. It's in a reasonably usable state, and most of the code evolves pretty little, if at all. TIEmu is an unmaintainable code base, however, due to the fragile integration of outdated versions of a patched GDB, Tk, Insight, all of that mixed in the same event loop and sticked together by a fragile build system.
When I made the strip_tilp_nspire experiment, I didn't expect TI to come up with a new crappy, totally non-innovative TI-Z80 model, aimed at milking customers and expanding the lifespan of the TI-Z80 series by years...

Quote
A complete rewrite would take years, though.
A partial rewrite of <35K RLOC (some of the code could be copied with little in the way of changes) doesn't take years full-time, but it's still too lengthy a task for me to take on. There are other, more fun and more productive tasks to work on...
Especially this project here

• Editor
• LV10 31337 u53r (Next: 2000)
• Posts: 1708
• Rating: +229/-17
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #33 on: August 09, 2013, 01:47:24 pm »
Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)
I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.

With the big advantage of not having a 42th abstraction over the real communication.
Tilp itself isn't the problem, in fact, it's the filter driver for windows.... The number of people willing to install new software (especially drivers, in fact, with some manual configuration...) for this would be very low...
The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too). But then, no Linux indeed. To be good, the backend thing about communication should be separate, so that on Mac and Windows, users could use the nRemote layer (well, the java thing, that is, not the whole nRemote obviously), and on Linux, Tilp.

Quote
And, also, let's not forget that if such App-Store project comes to life, it'll have to be for all .tns of course (there are tons of TI activities that could use this, but also Lua scripts, and duh, the ndless programs (especially those with external resources), so if it ever gets popular (who knows ), the majority of users will be PC, then Mac, then Linux (and the order of file type will be TI BASIC things, then the Lua stuff, then the ndless stuff...)

For a real package manager (like pacspire  ) every file is just a file, nothing special (except the metadata, of course).
Yep, good enough

Quote
Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)
Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?
Quote
Yeah, a single repo is less of a maintenance problem.
That's perfectly true.... but what repo is going to be used ?
ticalc.org and tiplanet.org are the two websites with most nspire-related files (I dont know which has more, honestly, but I know tiplanet has a lot ...)
We (tiplanet) probably wouldn't have a problem making some php layer/web-service ( / API) to get the correct files in a wanted format over our archives system as it is right now, IDK about ticalc.org

Having a user-exposed file to edit repos and rules to get files from it (if not "standard" from the software POV, or something, IDK), would be cool.
« Last Edit: August 09, 2013, 01:50:01 pm by adriweb »
My calculator programs
TI-Nspire Lua programming : Tutorials  |  API Documentation

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #34 on: August 09, 2013, 02:03:23 pm »
Yes sure, but at least it will function directly and more quickly (no install time, I mean) for those on windows (and mac) with TINC[L]S installed, with no need of filter driver and such because of that crappy windows roadblock...
For Linux obviously libti* is the choice as it's easy to use there (and, well, is the only one).
Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great)
I think the requirement to have tilp installed is as easy for the average windows user as having the TI software.

With the big advantage of not having a 42th abstraction over the real communication.
Tilp itself isn't the problem, in fact, it's the filter driver for windows.... The number of people willing to install new software (especially drivers, in fact, with some manual configuration...) for this would be very low...
The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too)
Yes, but Tilp uses libti*, which means it works if it's installed.
Quote
Quote
Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)
Oh, that wouldn't be a good idea. I prefer having a single repo. Fetching packages and metadata would get horribly slow and what is with different version (but same version number!) of the same app in two repos?
Quote
Yeah, a single repo is less of a maintenance problem.
That's perfectly true.... but what repo is going to be used ?
ticalc.org and tiplanet.org are the two websites with most nspire-related files (I dont know which has more, honestly, but I know tiplanet has a lot ...)
We (tiplanet) probably wouldn't have a problem making some php layer/web-service ( / API) to get the correct files in a wanted format over our archives system as it is right now, IDK about ticalc.org
Importing them manually or automatic, and maybe displaying a message that new apps shouldn't be uploaded there.
But what if a developer disagrees (I doubt that)?
Quote
Quote
Having a user-exposed file to edit repos and rules to get files from it (if not "standard" from the software POV, or something, IDK), would be cool.
MySQL Database with all apps and AUTO_INCREMENTed ID + Subdirectories.
Communication over XML, e.g:
http://apps.tiplanet.org/list (a php file):
Code: [Select]
<XML STUFF><repository version="0.1" name="TI-Planet main repo"><app name="Tile World" version="1.3.0" id="1" cx="true" classic="true"><screenshot>1/screenshot.png</screenshot><description>First app available here</description><author>ajorians</author><package version="0.1">1/tworld.pcs.tns</package></app></repository>On http://apps.tiplanet.org/index.php you would get a nice login and registration form (or the forum accounts)
and you can submit new apps and update your own. And most important: Download the App Store!

#### Lionel Debroux

• LV11 Super Veteran (Next: 3000)
• Posts: 2135
• Rating: +290/-45
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #35 on: August 09, 2013, 02:50:34 pm »
Quote
Quote
So libticalcs doesn't support remote execution for the Nspire (while it does for most other models), but I don't know for sure whether the Nspire's OS itself does (the teacher software probably has features like that).
I doubt it. What do you want to execute without ndless?
Forcing a whole classroom of calculators to open an activity when starting a lesson ?

Quote
Quote
Sending files over the wire, and creating the bytes to be sent over the wire, are two strongly different concerns, even though the latter depends on the former.
Why not both layers in one library?
I can only speculate about it, as the organization of the libraries was made before my time as the maintainer, but at least, having libticables separate from libticalcs makes it possible to depend on libticables without depending on libticalcs, if one wants to implement completely different protocols

Quote
Communication over XML, e.g:
JSON is more lightweight.
« Last Edit: August 09, 2013, 02:51:47 pm by Lionel Debroux »
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.

#### compu

• LV5 Advanced (Next: 300)
• Posts: 275
• Rating: +63/-3
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #36 on: August 09, 2013, 03:42:15 pm »
Maybe we should agree on some things now?

My original idea was to install all packages into a central directory (e.g. /pacspire/) and to create a shortcut to the program in the documents folder (shouldn't be hard if ndless's ploader was exposed to pacspire).
Pacspire itself would get a simple GUI to list and remove packages.
Adriweb said pacspire should be able to install everything, including TI-BASIC and Lua stuff, but they 1. would have to be in the documents folder and 2. mostly are a single file (aren't they? I use TI-BASIC/Lua rarely), so I'm not sure how pacspire should keep track of that or if it is overkill to use a package manager for this (unless you are packing a bunch of scripts into a single package, or a lua script has dependencies like a luax extension, btw random thought: dynamic linking with ndless would be nice )

On the PC side, a small tool to generate packages and sending packages to the calc using nRemote/libti* would be nice.

So, what information has to be stored in a package?
Currently, there is a simple file called pkginfo.txt.tns with the following format:
name=Package name
version=Version string
timestamp=UNIX Timestamp (e.g. 1375988987)

and optional:
ext_name=txt
ext_prog=editor

The parser for this file is really crappy at the moment, it could be replaced by a real .ini-parser or something.

The next question is, should all packages be unzipped by default? Or should they be unzipped at runtime into a temporary folder? Or should pacspire pass an unzip-handle to the program so it can unzip its resources directly into RAM?
There could probably be an option for this in the pkginfo file.

Of course a central repository would be nice, but is it feasible and worth the effort?

#### Lionel Debroux

• LV11 Super Veteran (Next: 3000)
• Posts: 2135
• Rating: +290/-45
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #37 on: August 09, 2013, 03:52:22 pm »
Oh, I forgot...

The reason why I proposed nRemote is because it works "directly" as long as you have TINC[L]S (and well, it's Java, so at least it's mac+windows directly, too). But then, no Linux indeed. To be good, the backend thing about communication should be separate, so that on Mac and Windows, users could use the nRemote layer (well, the java thing, that is, not the whole nRemote obviously), and on Linux, Tilp.
It's not desirable for a portable community software to depend on TI's proprietary software. The fact that Ndless 1.0/1.1 do it is not a good reason for doing the same thing
Licensing issues are probably not much of a concern here, as they should be mitigated by the usage of dynamic linking (upon both TI's software and libti*), but they should be checked nevertheless. At least, statically combining the GPL'ed libti* and TI's proprietary software is impossible.
Member of the TI-Chess Team.
Co-maintainer of GCC4TI (GCC4TI online documentation), TILP and TIEmu.

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #38 on: August 09, 2013, 04:04:25 pm »
My original idea was to install all packages into a central directory (e.g. /pacspire/) and to create a shortcut to the program in the documents folder (shouldn't be hard if ndless's ploader was exposed to pacspire).
Jup, I agree with that. It should be fairly easy to integrate that into ndless or even call the hook manually.
Quote
Pacspire itself would get a simple GUI to list and remove packages.
Adriweb said pacspire should be able to install everything, including TI-BASIC and Lua stuff, but they 1. would have to be in the documents folder and 2. mostly are a single file (aren't they? I use TI-BASIC/Lua rarely), so I'm not sure how pacspire should keep track of that or if it is overkill to use a package manager for this (unless you are packing a bunch of scripts into a single package, or a lua script has dependencies like a luax extension, btw random thought: dynamic linking with ndless would be nice )
Dynamic linking? That's even slower than loading elfs on the nspire. And you'll get many dependency problems and so on..
Quote
On the PC side, a small tool to generate packages and sending packages to the calc using nRemote/libti* would be nice.

So, what information has to be stored in a package?
Currently, there is a simple file called pkginfo.txt.tns with the following format:
name=Package name
version=Version string
timestamp=UNIX Timestamp (e.g. 1375988987)

and optional:
ext_name=txt
ext_prog=editor

The parser for this file is really crappy at the moment, it could be replaced by a real .ini-parser or something.
If you want shortcuts in /documents/ you should add something like link_prog=tworld.tns and optionally autostart_prog=tworld.tns
Quote
The next question is, should all packages be unzipped by default? Or should they be unzipped at runtime into a temporary folder? Or should pacspire pass an unzip-handle to the program so it can unzip its resources directly into RAM?
That means modifying the programs and the programs wouldn't have full control over the files anymore (as they're only "virtual"). So I vote for the first option.
Quote
There could probably be an option for this in the pkginfo file.
Of course a central repository would be nice, but is it feasible and worth the effort?
I think so! At least I want to be reminded of a new ndless version if my nspire is plugged in. For apps it would be very practical.
It's annoying to find the correct thread, the newest post with attachment and then I have to download it into a temporary folder, start tilp, navigate to that folder, dragging the file and last, confirm overwriting.

#### hoffa

• LV6 Super Member (Next: 500)
• Posts: 322
• Rating: +131/-13
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #39 on: August 09, 2013, 04:07:23 pm »
Very good idea, I had never thought of a package manager before.

My attention span is too short to read the whole thread, but here are my two cents:

A package manager is a great idea, especially with projects that have tons of files. I find it crucial that such a program should focus on being:
- extremely simple to use: a whole bunch of settings and commands might be cool for some but it's a turn off for most
- extremely lightweight: it's still a calculator we're talking about, and as such I think a "TI-Nspire AppStore" is overkill and any computer-to-calculator package installing and such is way too hacky and too big of a maintenance mess, plus my user experience instinct tells me it's fun and technically nice but nobody is going to use it
I'm not using the word "extremely" lightly here, by the way.

The whole installing/uninstalling process should be well-defined and elegant. There should only be the bare minimum of metadata (name, version, maybe a short description). All installed files (except from the main executable) could also be placed in some hidden directory somehow (no .tns extension or something?) or everything could be nicely organized in a single main folder. Uninstall scripts (shouldn't be visible directly) could be just a text file with every line being a path to the file to delete. I have to stress on how important "elegant simplicity" is (and by simplicity I don't mean that it should be simple to install nTileWorld from your Android phone connected by serial cable to your fax machine using a single click, but it should be tiny yet in every single level simple while keeping in mind it's still a calculator) unless you (I'm not pointing anyone here) want to blow it and turn it into a dead toy for nerds. This is the kind of stuff that could play a central role with ndless and could be somewhat adopted by those using Nspires.

Quote
Of course a central repository would be nice, but is it feasible and worth the effort?
lolno
« Last Edit: August 09, 2013, 04:12:00 pm by hoffa »

#### Vogtinator

• LV9 Veteran (Next: 1337)
• Posts: 1192
• Rating: +108/-5
• Instruction counter
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #40 on: August 09, 2013, 04:18:28 pm »
Compare smartphones and handys. On a smartphone you get apps, on a handy you have to download .jars yourself.
But as the nspire isn't powerful enough to manage a centralized repo itself, we let the PC handle it.
If we have enough apps, a central source to get them would be very useful, how many are there approximately?

#### compu

• LV5 Advanced (Next: 300)
• Posts: 275
• Rating: +63/-3
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #41 on: August 09, 2013, 04:26:16 pm »
Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?

If we have enough apps, a central source to get them would be very useful, how many are there approximately?
More than 100 (many of them are outdated though)
« Last Edit: August 09, 2013, 04:27:36 pm by compu »

#### hoffa

• LV6 Super Member (Next: 500)
• Posts: 322
• Rating: +131/-13
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #42 on: August 09, 2013, 04:39:52 pm »
Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?
This so much, I'd be happy to contribute.

Let's first make a simple, lightweight package manager for calculators. We'll take over the world later.

Oh and for the central repository I'm not entirely against it; I guess a website made exclusively for TI-Nspire PCS packages could (could) be pretty nice.
« Last Edit: August 09, 2013, 04:47:34 pm by hoffa »

#### compu

• LV5 Advanced (Next: 300)
• Posts: 275
• Rating: +63/-3
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #43 on: August 09, 2013, 04:53:10 pm »
Well, I think we should start small (installing/removing/listing packages, autostart support, shortcuts, everything in a central folder outside of /documents/ hidden from the user -> no .tns extension needed) and then decice what to do next?
This so much, I'd be happy to contribute.
Nice

Oh, and while we're at central repositories and stuff:
Spoiler For Spoiler:

#### ExtendeD

• CoT Emeritus
• LV8 Addict (Next: 1000)
• Posts: 825
• Rating: +167/-2
##### Re: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP)
« Reply #44 on: August 09, 2013, 07:53:14 pm »
Nice to see that this app store idea is supported, this will help promoting community programs. I have actually been thinking of building one with the Chrome Web Store look and feel (there's strangely no open source clone of it at the moment that could be forked).

Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?

I have just added nl_exec() to Ndless/Ndless SDK r877. I haven't been able to test it extensively yet, tell me if everything works for you.
Implementing shortcuts should be straightforward, storing the target path in a plain text file with a .lnk extension should do.
« Last Edit: August 09, 2013, 07:54:29 pm by ExtendeD »
Ndless.me with the finest TI-Nspire programs