0 Members and 1 Guest are viewing this topic.
QuoteAlso, 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.
Also, it'd be good to have such a program linked to the major community repos (ticalc, omni, tiplanet, cemetech...)
That's good, although some things likeCode: [Select]#define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }can already be called obfuscation
#define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }
Does "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!
static int execute (CalcHandle* handle, VarEntry *ve, const char *args){ return 0;}
Oh, I don't think sending keys is a good solution.
What if the user presses a key manually or disconnects the calc?
Why separate conversion from file types?
Why seperate libticables from libticalcs? Calcs without cables don't work
The code base is too huge to be maintainable.
A complete rewrite would take years, though.
Browsers having USB support? Why not integrate firefox in the linux kernel and booting firefox directly?
QuoteDoes "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 isCode: [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).
QuoteOh, 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
QuoteWhat if the user presses a key manually or disconnects the calc?PEBKAC is not much of our concern ^^
QuoteWhy 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...QuoteWhy 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.
QuoteThe 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...QuoteA 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 from: adriweb on August 09, 2013, 11:22:44 amYes 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.
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)
QuoteAnd, 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).
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...)
QuoteAlso, 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?
Yeah, a single repo is less of a maintenance problem.
Quote from: Vogtinator on August 09, 2013, 12:49:54 pmQuote from: adriweb on August 09, 2013, 11:22:44 amYes 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)
Quote from: Vogtinator on August 09, 2013, 12:49:54 pmQuoteAlso, 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?QuoteYeah, 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
QuoteHaving 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.
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.
<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>
QuoteSo 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?
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).
QuoteSending 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?
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.
Communication over XML, e.g:
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.
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 nameversion=Version stringtimestamp=UNIX Timestamp (e.g. 1375988987)and optional:ext_name=txtext_prog=editorThe 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?
Of course a central repository would be nice, but is it feasible and worth the effort?
If we have enough apps, a central source to get them would be very useful, how many are there approximately?
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?
Quote from: compu on August 09, 2013, 04:26:16 pmWell, 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.
Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?
Author
Topic: pacspire - A simple package manager for the TI-Nspire/Ndless (WIP) (Read 59148 times)
