Right, but the thing is that we have to support these kinds of documents since it's exactly the purpose of pacspire : easier multi-file projects installation

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)

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.)

Quote from: adriweb on August 10, 2013, 10:57:12 am

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.)

In my opinion, the transfer itself shouldn't have to be different : what should change, is the behaviour of the calc program upon receiving the files :
 - if the metadata says it's an ndless file or [whatever user option forcing the destination not to /documents], then move that wheever it's good.
 - if [there is no metadata file ?] or it's an official .tns (easy to detect), then, don't move it (expect if user option blablba), but watch out that if there are several files, then, look at the metadata to know which ones have to be put in MyLib.

Quote from: adriweb on August 10, 2013, 10:57:12 am

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)

As said by other people earlier, there is no interest in making pacspire support Lua nor Basic program, since they are only one-file-made.

You don't seem to have read :

Oh, BTW, you're wrong when saying "neither BASIC, nor Lua, can read and write files" : there are (and not just a handful) Lua and Basic projects that come with multiple files that have to be put inside of MyLib, to function, so they are reading/writing to external things, just not very freely.

nor :

Of course, but not so many if you're combining the conditions : getting aware of the project && getting convinced it is a good idea && resticting (with no other motive than pissing the management off) to ndless files[/b].
I'm just trying to help growing the targeted people ("catchment area" / "zone de chalandise" Tongue)

But I have to say it's difficult to keep up for new posts in this topic while writing

Quote from: adriweb on August 10, 2013, 11:21:03 am

You don't seem to have read : [...] nor [...]
But I have to say it's difficult to keep up for new posts in this topic while writing

Yeah, I skipped an entire page ... damn me.
Then, yes, for MyLib Basic/Lua programs, there is an interest, but how many are they exept Make3D demo and FormulaPro ?

Some programs of critor, too
And some "big" basic (and rarer, Lua, like your Make3d, yes) projects by other community members or even TI sometimes.

On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?
I mean what will be the differences between TI-Planet hosting and the pretty concept posted earlier ?

Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.

Quote

Quote from: Levak on August 10, 2013, 11:38:42 am

On another topic, talking about web hosting, what should differ from the existing if there is no PC-side client ?
I mean what will be the differences between TI-Planet hosting and the pretty concept posted earlier ?

Hmm.. the computer side is to have a unified repo-browsing and transferring experience that also makes the whole package-with-metadata thing easier (not made by hand by the user).
Concerning TI-Planet, since we'd already talked about having some API to get archive-info and whatnot (-in JSON, I believe, but that's not much the point), this would be the chance to get it done for a good/well-defined purpose.

And, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).

I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)

*Cough* Just thought I would mention that TILP would not be usable for me (and I'm sure) other windows users. I have never successfully gotten it to run properly on this PC (running windows 7). In fact, the last time I tried to install it (a few months ago) it rendered both TI connect and itself unusable. This was following the instructions to a T.

Althogh Java is absolute crap to develop a graphical application in, it might be the best option.
Using JNI to interface Qt with NavNet might be too complex.

Yeah, I had Java that in mind because it's at the same time directly cross-platform (no need for external QT and such) and could be linked to both libti* (JNI I guess, loading .dlls or .so or .dylib) and navnet (itself is using JNI but that's the deep navnet part which we won't use, only the high-level stuff are necessary. You can pretty much see what here.)
But I indeed know it's not the preferred language for many of us here (I myself didn't write much Java except nRemote ^^)

*Cough* Just thought I would mention that TILP would not be usable for me (and I'm sure) other windows users. I have never successfully gotten it to run properly on this PC (running windows 7). In fact, the last time I tried to install it (a few months ago) it rendered both TI connect and itself unusable. This was following the instructions to a T.

Same here (the filter driver thing is what blocked me, all the rest was fine) And of course, it went flawlessly on Ubuntu... Ah, Micro$oft....

Quote

Quote from: hoffa on August 10, 2013, 01:41:36 pm

And, the two things above are the exact same thing, just with a different layout. We would need a native client, which also handles transferring the files (libticalcs + Qt?).

I'd very much like to insist that to get as many people attracted to this project as possible, something without any external install would be better, and thus it's why I'd be thinking of a Java program which :
- if running on Linux, uses libti*
- if Mac or Windows, detect if TINC[L]S is installed, then use navnet, otherwise fallback on libti* if installed.
On both cases, if no transfer "driver" is detected (unlikely...), well, tell the user to get either one. (But the rest of the program could still work)

You really think that would make people want to use it? Most people pretty much never hook up their calculator to their computer, it's hacky, requires to download tools and has minimal benefits (compared to the work required to implement it nicely). [rant]Plus, who uses a joke like Java anyway?[/rant]

I used to send my buddies games just by cable during classes (oh boy the hours spent during mathematics class playing Pokemon), and that's up to where the majority of people bother to go just to put some stuff on a calculator (and with the package manager at the very most two files would be required to be sent, one if it was integrated into ndless)

I believe this is way more true for z80 platforms than Nspires (and 68k at a lesser extent, though). That's probably because students would get a z80 "by default" whereas a 68k or an Nspire would actually be a choice.

And that is a good point for making the software (especially the computer one, since the calc one, once installed, means the user trusts the whole thing anyway) as intuitive/portable/easy-to-use as possible. Which is again why feature detection on Mac/Windows is important : if the user has TINC[L]S installed, the program needs to install nothing : it justs sits there (no install needed to launch a .jar or an exe/app where it's embedded into), using what's already available and not installing complementary libs (which is, also, not possible all the time, especially for a driver, if the user is not an administrator).

PS : I was/am also the calc-guy in class