Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - compu

Pages: 1 2 [3] 4 5 ... 19
Could you add an option "savefile=" or something similiar where you can list a file as savefile in the package metadata?
On uninstallation, the user will (if the program has savefiles and they exist) be prompted whether they should be removed.
It's hard to remove files in /pacspire..
Sure, but maybe something like savefolder would be better? :P

Would it be possible to hook the deletion of the lnk file (if any) to trigger pacspire so that it can properly uninstall everything, as you say ?
Possible: Yes, but probably not for me. Maybe someone who is better at reverse engineering could do it ;)
I'll make a GUI where it will be possible to remove packages.

If some program relies on specific files and the program binary being in a specific location in /documents, is it possible to disable linking?
This shouldn't be necessary, because every Ndless program can easily be adapted to use relative paths (with enable_relative_paths()).

Is is possible to associate a file extension to a hidden program?
Yup, as ndless's ploader scans the whole filesystem (except /phoenix) for executables AFAIK.

I have added shortcut support now. (in the gif pacspire is configured to install packages to /pacspire -> only the shortcut is visible to the user, packages installed to /pacspire can't be removed at the moment :P)

First of all, thanks ExtendeD for adding nl_exec :)

As for the Ndless/no-ndless question, I'm not sure how you would manage packages on a non-ndlessed calc. It would definitely require a lot more work on the computer side, which is at least not what I originally planned.
I still think we should focus on Ndless first, because it makes the most sense in my opinion.

But as said, before, whatever the type, lua, basic, or ndless, it should not have to matter to the program (both computer and calc side)
I'm pretty sure it will matter, because Ndless programs will have to be installed differently from the basic/lua stuff (outside from /documents/, with shortcuts, file extensions, etc.)

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:

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 :P (many of them are outdated though)

Maybe we should agree on some things now? ;D

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 :P)

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:

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?

Thanks Jim for the code :)

Oh, I don't think sending keys is a good solution. What if the user presses a key manually or disconnects the calc?
Well, we could... disable bus access to the keypad while receiving stuff? ;D

The problem is more the other direction.. How do you get feedback from the calc(whether the installation has finished successfully, the ndless version..)?
Reading a logfile (after executing pacspire) would -again- be slow as hell.
True. How does nRemote receive data from a calc?

Thanks for the explanation :)

get_event() will be helpful. ( )
It receives keystrokes AND you can receive files while waiting for an event to happen. Pretty awesome and it should solve many problems :D

Test attached. It waits for an event and prints the event data (through serial). If you send a file while waiting, it will be received successfully. (Press ESC to close)

Sorry, I may have used too much parentheses or used a not understandable enough English, so there is a part of my request that you didn't see.
-I was indeed asking for a "folder selection menu" or something.
-But also a way for developers to force the "unpacking folder", so that a program that must be put in "startup" will always be put in startup (doesn't ask the user where to unpack), or so that a program that is still in-dev and that must be ran from the Ndless folder (and nowhere else) will be unpacked in the Ndless folder.
forcing an installation folder is easy as well and could be added to the pkginfo.txt, but I'd like to have another solution:
Putting all resources/executables in one central folder with subdirectories for each package (that could be outside of the /documents/ folder) and put something like shortcuts into the Documents folder.
The same could be done with the startup folder: just put a shortcut in there and it wouldn't matter where the program is actually located.
Since r820 Ndless has the function enable_relative_paths() so programs shouldn't care about the location of their resources (as long as programs are adapted to use this function, which is pretty easy).
Well, let me know what you think. But I think this would be easier when we are turning pacspire into a fully-fledged package manager.

I just tried to read the libticalcs2 HTML-documentation and it seems so outdated, that "nspire" isn't mentioned one singe time.
But as tilp runs fine and some files in src begin with nsp_*, I think it's the right library in the right version.
So is tilp the only reliable source for documentation?
And I wonder why there are four libti* librarys. In my opinion it would have made more sense to combine them into one libticalcs..
Yup, I only found outdated documentations as well. Maybe, Lionel, if you are reading this... :P

I'll try setting up a small application which sends a file to the calculator and maybe even executes it.
Nice :)

Even with WINE it doesn't. It needs the navnet device driver installed. TINCL shows a splash screen and then it exits with "Connectivity Library is missing".

How should the calculator and the App Store play together? Should the store extract the archive and send all the files or should the appstore send the package to the calculator and start pacspire to install it? The latter sounds better in my opinion, but I think it'll get close to impossible, as pacspire can't communicate with the appstore in any ways except screenshots and files (and that only if no ndless app is running!)  :banghead:
I'd let pacspire do the work. Some posts ago Lionel said libticalcs has support to send keystrokes, maybe that would work somehow? ;D

An app store would indeed be nice, but who will do the work of setting it up, maintaining it in the long-term, and sifting through old programs for re-packaging them ?
Maybe Linux style repos ? This way devs maintain their stuff themselves and it's pretty easy to set up (you just need an HTTP server and there are plenty of free hosts). ;)
Why not a simple Web UI for submitting and updating apps?
That's what I was thinking of + a command-line client that downloads packages and sends them to the calc (I guess that would be possible with libti*?).

Great! If you want to, I could help :D
Sure, why not :)

But if I click on tworld.pcs.tns again, it says 1.3.0 would be newer than my installed version 1.3.0, but in the log file it states otherwise xD
Quote from: dialog
The installed version of tworld (1.3.0) is newer than the one you are trying to install (1.3.0). Continue?
Quote from: logfile
checking if the package is newer than the installed version... no
It actually says the same, but "installed version" and "package" are interchanged... I should probably change that :D

The [great, in my option] idea of an Nspire App-Store has been in mind of several people for quite some time, yet nothing has been done on that path :P
It could be coupled with some remote control software to automatically extract/isntall/launch whatever. nRemote for example can do that quite easily with its "script" support.
Thanks, I will take a look at nRemote, but if it doesn't work on Linux as Vogtinator says, it probably won't be an option.

Damn, I was ninja'd 4 times writing this post...

Anyways, great work Compu, that will surely help people installing their programs. I think there should be (if not already present) a way to decide if the installation is done in a specified folder (for in-dev programs that still don't support to be in any folder or don't support their dependencies to be in random folders, or for programs that must be in startup) or in a folder that the user would choose (for programs that can be run from any folder and that the user would like to put in the Game folder for example).
Selecting a folder should be pretty easy to add.

Here is a small gif to show the installation process.

So I would have to download the .pcs package manually, transfer it to my calculator and then install it?  :-\
At the moment, yes.

Sure, it's easier to install and you won't make any mistakes, but I think a pc-based version (using tilp's libs) would be better, but also harder to code and maintain.
A PC-based version is at least on my wishlist ;D

Imagine a public omnimaga and ti-planet repository with almost every app available as "one-click-install".
Something like an "Nspire-App-Store", maybe even with automated ndless installation?
Maybe even an "One-Click-Update" which updates all applications installed on the calculator..
Maybe my brain is already dreaming at 2:00 am while I'm still awake typing this post..
Well, I'll see what I can do. :P

Edit: pacspire uses .zip format for the files? What is the installation speed like?
I'm at school now and can't give you exact times, but it is not too slow. Try installing the tworld package (~1,8MB uncompressed, ~400KB compressed) and you'll see.

compu: nice :)
Would being able to temporary unpack/run/remove temporary files be an interesting option, to avoid cluttering the OS file manager at the expense of launch time?
Sure. And by the way, would it be possible to make the program loader of ndless available to launched programs?

Also how does pacspire conflicts with Ndless's zlib definitions?
Everything zlib-related in os.h is commented out at the moment.

I'm trying to make some kind of package manager for the TI-Nspire.
The goal is to make installing/removing programs on an Nspire very easy, e.g. for games that need a large amount of other files/resources.
In its current state pacspire can install zip files and register file extensions on installation time.

For testing purposes I made a package of Tile World which can be installed with one click ;)

To do this, you have to send pacspire.tns and tworld.pcs.tns to your calc and start pacspire once. Now you can click on tworld.pcs.tns to install it.
Source code and more information is available on github.
This is an early version so please let me know if you have suggestions, find bugs, etc.

Other / Re: Germany being spied on
« on: June 27, 2013, 12:14:21 pm »
YouTube refuses to pay money to the GEMA, so they are not allowed to play songs of members of the GEMA (all major music labels). YouTube says the prices are too high, the GEMA says YouTubes offers are too low. They can't agree on something (probably because the GEMA is too greedy). The GEMA does not block the songs, YouTube does so they don't have to pay.
And yes, this really sucks...

On a semi related note, has Germany started its own version of the Great Firewall of China like United Kingdom is trying to do? (censoring certain sites, such as one very popular torrent site and its affiliated music promotion service, now requiring a proxy to access them) I don't think Canada did, although in Canada we have weird copyright laws that prevents services like Spotify from launching here and others such as Netflix from offering a selection as good as in USA.
In 2010, a law was made to block child pornography ("Zugangserschwerungsgesetz") which was supposed to show a STOP-sign on CP websites, but it was never used and reversed in 2011.
Other than that, we don't have anything similar to the TPB blockades in the UK AFAIK, but some lobby organisations actively fight copyright infringements and took down the largest German movie streaming portal in 2011.

You switched to Git? Nice. Feel free to give me access to your repo, my GitHub username is juju2143 and I'll check it out as soon as I'll get my hands on my Prizm (my bro have it atm).
Done ;)

catastropher: That sounds really awesome :)

Pages: 1 2 [3] 4 5 ... 19