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 - Vogtinator
Pages: 1 ... 48 49 [50] 51 52 ... 83
736
« on: August 09, 2013, 08:07:33 pm »
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.
A program associated to .lnk isn't needed?
737
« 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?
738
« 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. 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.. 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 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. 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.
739
« 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. 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?
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)? 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): <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!
740
« on: August 09, 2013, 01:39:36 pm »
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
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? 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. 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? 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...
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? 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...
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 
741
« on: August 09, 2013, 12:49:54 pm »
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.
Same here. libti* supports this functionality though as Lionel stated a few posts up.
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. 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).
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? So is tilp the only reliable source for documentation? The documentation of libti* was already incomplete / partially outdated when I became the maintainer, and (with the help of contributors) I have focused more on the code (which needs bugfixes, feature expansion and hardening) than on the documentation (all the more libti* have relatively few users, and documentation of the API has pretty little user-visible effect, eh ?), so yeah, the source code of the libraries and testcases is your best bet. You're coders as well, after all
Oh, the usual fear of documentation
Have a look at libticalcs (calc_xx -> calc_nsp -> nsp_cmd -> nsp_vpkt -> nsp_rpkt) and the testcase, libticables (link_xxx -> link_usb) and the testcase, TILP (especially tilp_calcs.c), titools. The testcases and titools are about as bare-bones as you can get.
That's good, although some things like #define TRYF(x) { int aaa_; if((aaa_ = (x))) return aaa_; }can already be called obfuscation Does "ticalcs_calc_execute" still work for nspires? That would be perfect, escpecially if you can pass arguments!
One of the NavNet JARs (don't remember which one) contains the 3-byte key code definitions. Adriweb, remind us which one
It's c:/Program Files (x86)/TI Education/TI-Nspire Computer Link/lib/commproxy/commproxy.jar /com/ti/et/education/commproxy/NspireVirtualKeyStroke.java
BTW, libticalcs contained support for Nspire remote control before nRemote was released, though I used a beta version of nRemote in a Windows VM to debug and fix my implementation of the feature through sniffing USB packets.
Oh, I don't think sending keys is a good solution. What if the user presses a key manually or disconnects the calc?
And I wonder why there are four libti* libraries. Actually, for the combination of TI-Z80, TI-68k and Nspire, four libraries is not enough
There's a clear need for a fifth library on top of the four current ones, so as to consolidate some code currently duplicated, with variations, across clients (TILP, TIEmu, TilEm, titools). I started creating it locally, though it contains pretty little.
The whole libti* framework looks complex and seems to have deep nesting of functions, but after a while maintaining the code base, I realized that for the purposes of presenting a single, mildly abstracted API to clients (instead of at least three sets of APIs with significant overlap, due to TI-Z80/TI-68k/Nspire, DBUS/DUSB/NSP, and some commonalities between TI-Z80 and TI-68k), it's not easy to do simpler. Just follow the call chains I outlined above - there's a use for each file, in the complete framework
In my opinion it would have made more sense to combine them into one libticalcs. It's equally clear that for the narrower purposes of interacting with the sole Nspire series, four libraries are far too much, and you're completely right about a single library making sense:
* libticonv deals with character conversion, which is necessary on TI-Z80 and TI-68k models, but the Nspire uses Unicode (and conversions can be handled more directly by other frameworks);
* libtifiles deals with file types... but the Nspire has very few of them, unlike the TI-Z80 and TI-68k series;
Why seperate conversion from file types? * libticables deals with multiple cables... most of which don't work on modern computers due to lack of the physical interfaces, and the Nspire uses a single cable type;
* libticalcs deals with the raw DBUS, DUSB and NSP protocols and transport protocols built on top of them.
Why seperate libticables from libticalcs? Calcs without cables don't work
On my Github, you'll find a one-off experiment of a few hours, where I fused libticonv, libtifiles, libticables, libticalcs and tilp into a single code base (I probably should have let libti* on the one side and tilp on the other side, but oh well), shaved most code related to TI-Z80 and TI-68k calculators. Doing so slashed the size of the code base by more than half (~78K RLOC -> <35K RLOC). I didn't bother thoroughly purging the code base, there remain some bits directly aimed at TI-Z80 or TI-68k series and some APIs which are not necessary for dealing with the Nspire series.
I didn't merge developments from mainline since I created that one-off experiment. With several months of full-time paid work, it would be possible to make a fresh API, simplified from the current one while keeping the good bits, tailored to Nspire interaction, replacing Glib with C++11/STL, making a whole new Qt UI on top of it (GTK+ is falling out of favor), making a solid up-to-date documentation, etc... but who can afford that kind of luxury, all the more it's for the benefit of relatively few users ? At least, I cannot
The code base is too huge too be maintainable.. A complete rewrite would take years, though. Even with WINE it doesn't. USB support in Wine is in the "TODO" group, anyway.
What means: It's finished in two years but every second application will crash horribly. At least it's my current wine experience.. Remember the main point here, whatever the choice : it has to be extremely simple for the user (no installation would be great) Well, the "no installation" part is not going to happen, especially on Windows, due to the "everything USB needs a driver, which in turns requires admin privileges for installing" behaviour. On the day the two main FLOSS Web browsers (Firefox and Chrome) start providing an interface to USB peripherals on the host (notwithstanding the severe security problems), maybe...
Browsers having USB support? Why not integrate firefox in the linux kernel and booting firefox directly?  Vogtinator:
get_event() will be helpful. (http://hackspire.unsads.com/wiki/index.php/Libndls#Keyboard )
It receives keystrokes AND you can receive files while waiting for an event to happen. Pretty awesome and it should solve many problems 
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)
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.
742
« on: August 09, 2013, 10:54:03 am »
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*?).
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.. Great! If you want to, I could help
Sure, why not
I'll try setting up a small application which sends a file to the calculator and maybe even executes it. 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
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.
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!) 
743
« on: August 09, 2013, 09:30:18 am »
But doesn't nRemote use the mysterious NavNet.jar to interface with the Nspire windows driver?
That would make it completely useless to me, as I'm using Linux.
744
« on: August 09, 2013, 09:09:07 am »
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? 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 
Great! If you want to, I could help 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.
Wow, not too bad for a calculator.. 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
745
« on: August 08, 2013, 07:55:27 pm »
So I would have to download the .pcs package manually, transfer it to my calculator and then install it?  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. 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.. However, this tool is already waaaaaaayyy more awsome to use than dragging and dropping dozens of files in tilp Edit: pacspire uses .zip format for the files? What is the installation speed like?
746
« on: July 18, 2013, 02:37:37 pm »
well as you may looked inside the spoiler: How the heck is yours like that 
it's on my school and school's are like mine always have super fast internet, because all big schools have.
Now I'm jealous.. I'm at a big school (1600 students) and we can't even get DSL 16000. Fiber is 100m away and the telephone cable goes around the entire building once to reach the second floor. (~500m). Downloading 200MB takes 1 hour.
747
« on: July 09, 2013, 12:54:47 pm »
This is the easiest and best I found so far: http://simplemachines.it/doc/arm_inst.pdf. It explains the most important things of the arm instruction set. For more in-depth features and instructions for e.g. the FPU (which the nspire doesn't have), you should also read the "ARMv5 Architecture Reference Manual.pdf" which you can find somewhere in the internet.
748
« on: June 17, 2013, 04:51:17 pm »
I don't think hard- and softlinks are supported under windows.
Also the file permissions might be a problem
Edit: You can switch ttys with Alt-Right and Alt-Left as well, but there has to be a shell running.
749
« on: June 17, 2013, 03:42:30 pm »
For both of these I doubt the kernels will support it. But if you want to use them, go for it and compile your own kernel
750
« on: June 17, 2013, 03:39:10 pm »
You have to use Linux for that. Windows doesn't support it.
Pages: 1 ... 48 49 [50] 51 52 ... 83
|
Show Posts