TI-Nspire Dev Day - Page 1

geogeo, brandonw et moi-même apportons la petite pierre à l'édifice qui a commencé à prendre de l'allure ces derniers mois :

-> release synchronisée de Ndless et Nspire8x

---

Ndless v1.0 : http://www.ticalc.org/archives/files/fileinfo/426/42626.html
Trunk Subversion (code source des développements en cours) : https://www.unsads.com/scm/svn/nsptools/Ndless/trunk/ , guest/guest (le certificat peut être accepté)
Configurer un environnement de développement pour Ndless v1.0 : http://www.unitedti.org/forum/index.php?s=&showtopic=9284&view=findpost&p=140674

Félicitations !

Voilà c'est le début d'une grande logithèque qui s'ouvre sur Nspire.

(Rah c'est beau l'asm ARM )

Félicitations J'espère que ça permettra de créer une communauté qui tient la route !
Excellent boulot en tout cas !

Félicitations publiques

C'est une bonne nouvelle. En particulier, c'est bien d'avoir choisi une licence libre! Mais y a-t'il une raison technique pour laquelle vous utilisez les composants propriétaires de TI plutôt que les libs portables CalcForge ou LPG? Et serait-il éventuellement possible d'avoir une licence duale MPL/GPL, ce qui permettrait un portage vers ces libs sans problèmes légaux (ces libs sont sous GPL)? (GPL 2 ou 3, peu importe, les libs CalcForge et LPG sont sous GPLv2+.)

Voilà les principales raisons :
- Computer Link est installé chez tout possesseur de TI-Nspire -> pas de libs supplémentaires à distribuer
- Je ne connais pas le niveau de stabilité des libs CalcForge en ce qui concerne la TI-Nspire. Je connais celles de Computer Link pour avoir joué avec depuis plusieurs années.
- Le seul intérêt des libs propriétaires que je vois est la compatibilité Linux, ça ne faisait pas partie de mes priorités.

<< Et serait-il éventuellement possible d'avoir une licence duale MPL/GPL >>
Je n'avais vu ces problèmes de compatibilité de licence, mais on pourrait ajouter ça.

A mon avis, ça n'est pas un hasard s'ils ont choisi la MPL

Pour la licence duale, ce serait vraiment top si c'était possible.

Lionel Debroux (./9) :
A mon avis, ça n'est pas un hasard s'ils ont choisi la MPL

Ils ont probablement choisi la MPL parce qu'elle permet l'utilisation de composants propriétaires, n'est-ce pas?

Félicitations les gars

Kevin Kofler (./11) :

Lionel Debroux (./9) :
A mon avis, ça n'est pas un hasard s'ils ont choisi la MPL

Ils ont probablement choisi la MPL parce qu'elle permet l'utilisation de composants propriétaires, n'est-ce pas?

Oui, le but est d'être moins restrictif que la GPL sur ce sujet, mais d'exiger la distribution de sources modifiées.

Toutes mes ficelles de calçon!

Bien joué les gars!!

Sinon, pour la n-spire, vous travailler sur quoi en ce moment ??

La classe !

Sinon, pour la n-spire, vous travailler sur quoi en ce moment ??

La news ticalc, et le repo SVN, indiquent qu'ils travaillent en tout premier lieu sur l'environnement de développement: des instructions plus détaillées sur la façon de le mettre en place. Il y a plusieurs toolchains ARM génériques qui sont très bien.

Bravo !!



Beau travail !

Les fonctions suivantes ont déjà un équivalent dans les libs CalcForge:
pxConnectApp.connectedDevice().getDeviceInfo
pxConnectApp.setConnectAPI (fonction interne, l'API des libs CalcForge est différente sur ce point)
pxConnectApp.enumerateConnectedDevices
pxConnectApp.connect
pxConnectApp.installOS
pxConnectApp.getDeviceInfo
conApi.shutdown
conApi.sendFile
conApi.getFile
conApi.enumDirectory("/") ("/" étant codé en dur, cf. get_dirlist dans calc_nsp.c, c'est une énumération récursive, mais je ne pense pas que ça ait une importance)

En revanche, il faudra rajouter ça aux libs CalcForge pour faire marcher Injector:
conApi.getFileAttributes (fonction bas niveau présente: cmd_r_dir_attributes) (On pourrait éventuellement s'en passer et utiliser un receive à la place.)
conApi.mkDir (indispensable, il me semble)
conApi.copyFile (vraie copie locale, indispensable, une copie à travers le PC ne marchera pas, ExtendeD sait sans doute pourquoi)
conApi.delete (probablement dispensable, mais on voudrait éviter de faire du travail de porc; del_var est prévu par l'API, mais pas implémentée pour la Nspire)

Ca valait le coup d'attendre

Toutes mes félicitations à la team

Toutes mes félicitations ! Vous faites vraiment un excellent travail !
Bon courage pour la suite et le développement de softs futurs !

sam22 (./15) :
Bien joué les gars!!

Sinon, pour la n-spire, vous travailler sur quoi en ce moment ??

Un loader ELF me semble être une nouvelle étape importante à franchir.

Un "" de plus à tout l'équipe du projet

(je me demande bien quelle tête ils font chez TI en ce moment )

Pareil, doit y avoir quelques remontages de bretelles sévères pour les responsables sécurité

(je me demande bien quelle tête ils font chez TI en ce moment )

Peut-être qu'il faut attendre lundi pour ça...


Mais grâce à Ndless, la Nspire va peut-être enfin commencer à se vendre "vraiment"...
Donc faudrait savoir ce qu'ils veulent...

Ils ont enfin sabré le champagne chez TI!

Mes félicitations!
Dommage que ca ne fonctionne que sous Windows, je ne pourrai rien faire.
Et encore mes félicitations !

Bah, tu peux aider avec le portage vers les libs CalcForge ou LPG/TiLP. Cf. par exemple ./19.

A noter que je travails à 100% sur un Mac et que je n'utilise pas Windows ni même Cygwin pour compiler Ndless.

J'ai posté une news trilingue:
http://mobifiles.bytefox.de/viewtopic.php?t=3933&f=37 (allemand)
http://www.tigen.org/index.php?module=news&action=comment&id=309 (français, anglais)