Forum TI-Planet.org

TGV 9896 pour 9h56.

De toutes façons j'en avais fait l'expérience pour avoir pris un hôtel la veille les années précédentes, c'est très limite pour les ateliers du dimanche matin 8h30 vu que hors saison et en prime un dimanche, les heures de petit-déjeuner sont souvent plus tardives.

Je prendrais le temps de prendre un petit dej, je ne vais pas co-animer un atelier le ventre vide! Disons qu'en general les ateliers du dimanche matin commencent un peu en retard...

J'avais oublié l'atelier fx-92+ Spéciale Collège, et je m'étais trompé d'horaire pour l'atelier NumWorks.
Voir plus haut : viewtopic.php?t=23019&p=246110#p246313

critor a écrit:L1-10 : Atelier de formation Python avec la calculatrice NumWorks
Niveau : Lycée
Animation : Louise WATTINNE, Léo SOLE

Existe t'il en enregistrement vidéo (rêvons) ou une trace écrite de cet atelier ?

Un des trolls suivant a-t'il été lancé, au choix dans la liste suivante :

- Comment fait-on pour exécuter un script python dont la taille dépasse 4ko ?
- Pourquoi n'y a t-il que 16ko pour l’exécution des scripts ?
- Pourquoi les couleurs du clavier sont gris clair /gris foncé / jaune peu lisible ? (et si on mettait un peu de bleu / vert pour utiliser la palette RGB ...)

Je n'étais pas à cet atelier, donc j'ignore si il a été filmé.

Par contre, je suis passé devant (car en retard pour mon propre atelier ) et j'ai pu constater que la salle était TRÈS bien remplie.
Ce n'était pas le cas pour l'atelier Python de Casio la veille, bizarrement, alors que la Graph 35+E II reste pourtant à ma connaissance la référence au lycée.

Je suis allé à l'atelier projets SNT de TI.
La salle était bien remplie, mais c'était une petite salle à la différence.

J'aurais bien aimé pouvoir me dédoubler, mais malheureusement...
C'est bien dommage que tous les ateliers qui m'intéressent aient lieu en même temps.

Un petit bilan des journées APMEP sur Planète Casio :
https://www.planet-casio.com/Fr/forums/ ... 939&page=1

https://www.planet-casio.com/Fr/forums/lecture_sujet.php?id=15939&page=1
Concernant la NumWorks
J'ai appris que la RAM de la Numworks, qui fait 256 ko, est partitionnée avec une zone par application. Ça signifie que chaque programme doit avoir une zone allouée à l'avance et de taille suffisante, que personne d'autre ne pourra utiliser. Comme ils se gardent un peu de place ça fait parfois des petites zones... le plus impacté reste Python, comme vous l'avez vu avec le concours de rentrée. On espère que ça s'améliorera avec le temps

Je dois vraiment être une buse mais d'une je ne comprend pas quelles avantages présente cette méthode de gestion de la mémoire (rapidité des temps d'accès ?), de deux qu'est ce qui empêche l'équipe NumWorks de libérer des blocs entiers de mémoire pour les affecter à python, au hasard lorsque l'utilisateurs rentre dans l'application python ?

Copier la mémoire RAM dans la ROM doit être super rapide il me semble, on ne parle pas ici de Go, ni même de de Mo mais juste de quelques Ko... Copier la ROM dans la RAM (l'opération réciproque donc) doit être encore plus rapide je pense.

Il n'y a pas de système de fichiers en Flash, ou de sauvegarde temporaire en Flash d'un sous-ensemble du contenu de la RAM en vue d'une restauration ultérieure.

L'allocation statique de la mémoire simplifie une partie du code, mais a d'autres défauts, clairement...

L'avantage c'est clairement que c'est plus simple. Mais ça montre plusieurs défauts à mon avis ; un système d'exploitation complet ne fonctionnerait pas comme ça. Déjà ça révèle que l'OS n'est pas du tout pensé pour ajouter des applications tierces (il faudrait leur réserver de la RAM aussi ?). Ensuite c'est très limitant parce que ça divise la quantité de RAM par le nombre d'applications. Ça peut se justifier si les applications sont susceptibles de toutes tourner en même temps... mais même là ça ne vaut pas un vrai gestionnaire de mémoire.

J'aime beaucoup le développement noyau, et j'ai l'impression qu'ils ont sauté l'une des parties les plus importantes... je sais pas trop pourquoi.

Au fait, une partie de la mémoire statiquement allouée (il y a d'autres blocs, par exemple le TreePool) l'est avec une union plutôt qu'une struct. Cette partie-là est donc une zone partagée entre toutes les applis, et non une zone par application. C'est pour ça que https://github.com/numworks/epsilon/pull/1064 peut augmenter la taille du tas Python à 32 KB sans changer la taille du tas.