Preos 0.58 : Runc est mort ! - Page 2

mdr, tu es nostalgik du tps où t'étais newbie, squale92?

pas vraiment, non
mais je n'ai pas pu m'empécher de tester sans envoyer shrnklib... (même si j'avais vu dans le readme qu'il allait absolument shrnkilb) => juste pr voir ce que ça donnait...
Je sais que pas mal de newbies liront pas le readme... et qu'ils vont dire "c de la merde, ça marche pas, ça plante"...

sinon, pkoi est-ce que tu met shrnklib dans stdlib, alors que, de toute façon, il faut qd même l'avoir ailleurs ?

Squale,29>Encore un message du genre librairies are not executable ?

shrnklib est dans stdlib. Oups. Erreur.
Sinon, oué faut que je debuggue a donf. tous les cas de figure possibles.

oué, shrnkilb est dans stdlib (enfin, d'après ce que j'ai maté à l'éditeur hexa, il me semble que c le cas...)
Sinon, c vrai que c une bonne diée (du moins, pr moi, qui n'utilise que rarement des programmes avec librairies, et qui n'ai donc pas trop souvent à subire les temps de décompression... quoique, vu que je compresse déjà quasiment tout en PPG (sauf les outils de développement..))

Link> ben, un message un peu plus explicite serait le bienvenu...


PpHd> sinon, petite suggestion pr shrnklib (je sens que ça peut être la mort à implémenter )
est-ce que ce ne serait pas possible de mettre shrkklib dans stdlib, mais sans compresser shrnklib ?
=> il n'y aurait pas besoin de shrnklib en dehors de stdlib... vu qu'elle ne serai pas compressée dedans... et ça ferai un seul fichier...

C'est vrai que ce serait le mieux, je pense...

mais dur à implémenter

Le mieux, ça serait d'utiliser ttpack à la place de shrnklib pour compresser, et de mettre les fonctions ttunpack directement dans PreOs.

ça serait pas une mauvaise idée
et ça permettrai de supprimer ttstart
tous les programmes en PPG, directement launchés par PreOS !
JE SUIS POUR ! (totalement)

Kevin:Ben il me semble que j'ia dit que c'etait possible de le faire avec ttpack, mais que je ne ferait pas <= Tn, qui est pour les libs statiques, ne verrait pas d'un bon oeil une lib dynamique contenant ttunpack. Et puis shrnklib est plus rapide que ttunpack
Ensuite je ne les mettrais pas dans preos, C'ést mieux dans une lib externe : une fois decompresse, la librarie est automatiquement desalloue (Bref meme si la lib de decomporession fait 40 K vous ne la verrez pas a l'execution du programme).

squale: Nan, pas les ppg. Les pack archivevs seulement sont lances par preos. Les packs archives sont auto-extractibles, pas les ppg.
Tu pourrais compresser les outils de developement en pack archive. Les nostub sont parfaitements supportes en pack archive.
Et non squale, shrnklib, n'est pas dans stdlib. stdlib continet le nom de la librarie a utiliser pour se decompresser. On peut donc utiliser pk92lib, ziplib, shrnklib, unpack dans une pack archive.

Et nan c pas possible de mettre des parties non-compresses au milieu d'autre compresses. Quoique Je vais voir si c'est possible en moins de 20 octets.

erf. bon, ben, dsl pr shrnklib : j'avais vu le nom dans la stdlib, c pr ça

j'ai dit que je ne compressais pas les outils de développement
(pour éviter de perdre du temps avec les progs que j'utilise le plus)

PpHd
a écrit : Kevin:Ben il me semble que j'ia dit que c'etait possible de le faire avec ttpack, mais que je ne ferait pas <= Tn, qui est pour les libs statiques, ne verrait pas d'un bon oeil une lib dynamique contenant ttunpack.

Tu ne le mets pas en librairie dynamique, tu l'intègres dans le kernel! Comme ça, le système de librairies compressées devient beaucoup moins compliqué: au lieu d'aller chercher une librairie pour la décompression, qu'on doit toujours garder décompressée, tu décompresses directement avec les routines intégrées. C'est bien plus pratique pour l'utilisateur: il n'a besoin que du pack de librairies et pas d'une librairie de décompression externe. Et ttunpack ne fait qu'1 KO! Ce n'est pas un gros problème de l'avoir en RAM: on est toujours loin des 12 KO de Universal OS.

Tu pourrais compresser les outils de developement en pack archive. Les nostub sont parfaitements supportes en pack archive.

Un programme _nostub qui nécessite un kernel...

Mais il est vrai que ce n'est pas facilement implémentable de lancer directement un PPG. À la limite, on pourrait essayer d'intercepter l'erreur "Name is not a function or program" et faire qqch. avec ça. Ou alors on joue avec la ligne d'entrée comme AutoStart.

>Squale: Bug corrige. En fait, ce bug survenait des qu'il trouvait pas une librarie.

Kevin Kofler a écrit :
Tu ne le mets pas en librairie dynamique, tu l'intègres dans le kernel! Comme ça, le système de librairies compressées devient beaucoup moins compliqué: au lieu d'aller chercher une librairie pour la décompression, qu'on doit toujours garder décompressée, tu décompresses directement avec les routines intégrées. C'est bien plus pratique pour l'utilisateur: il n'a besoin que du pack de librairies et pas d'une librairie de décompression externe. Et ttunpack ne fait qu'1 KO! Ce n'est pas un gros problème de l'avoir en RAM: on est toujours loin des 12 KO de Universal OS.

Certes, certes, mais si on peut s'en passer se sera mieux, non.
Et on perd la possibilite de compresser on-calc avec ziplib.
Ou la possibilite d'utiliser de nouvelles routines de decompression.
Remarque je peux toujours falsifier le header de preos pour en faire une lib
dynamique qui exporte une fonction de decompression de ttunpack.
Non ?
Ce qui m'enerve, c'es que je devrais le faire a la main et pas en mistub car
tigcc le supporte pas...

Un programme _nostub qui nécessite un kernel...

Pour un utilisateur qui possede deja un kernel, pkoi pas ?
Sinon, c vrai que ce n'est pas tres utile.

Mais il est vrai que ce n'est pas facilement implémentable de lancer directement un PPG. À la limite, on pourrait essayer d'intercepter l'erreur "Name is not a function or program" et faire qqch. avec ça. Ou alors on joue avec la ligne d'entrée comme AutoStart.

Oui. Mais je prefere mon systeme.
Meme si le shell ne supporte pas le pack archive, ca va se decompresser tout seul.

Et que penses tu du fait de sauver les auto-int dans des vecteurs ?

J'arrive toujours pas a corriger tous les leaks de memoire lors du hot reset (je libere l'estack et l'historique maintenant). Mais qu'est-ce qui peut bien prendre tant de place... Rechercher les handles du PrgmIO / Graph peut etre ?

Question: Pkoi AMS alloue toujours 4 handles de taille 4 au debut et qui ne serve a rien ?

cool pr la correction du bug.
j'avais pas testé sans autres librairies.
(pas newbie à ce point )

je trouve que garder le système actuel serait pas mal, mais en rajoutant en plus le PPG

J'ai deja dit que je ne pouvais pas gerer le PPG. Utilisez autostart si vous le souhaitez.

moué...
au pire, je peux l'intégrer dans mon TSR...
(je l'avais fait, pour certains cas)

mais bon.
tant pis

Arg, j'en ai marre. Je rajoute une option de compilation :
NostubIncompatibilty
Pour faire planter tous les progs nostub
Na
PS: J'ai craque.

erg

PpHd : j'ai trouvé comment corriger une partie des pertes de mémoire après un hot reset.
La plus grosse perte provient de deux appels de WinOpen avec WF_DUP_SCR comme flag. Il suffit de supprimer les anciens blocs mémoires nécessaires aux duplicate screens. On peut trouver leur handle dans la structure WINDOW associée. Pour une des 2 fenêtres, le pointeur sur cette structure est très facile à trouver, mais pour l'autre, le pointeur est constant mais n'a pas l'air d'avoir été exporté.
Alors le plus simple c'est de parcourir toute la liste des fenêtres, et de supprimer tous les blocs mémoires des duplicate screens. Ce bout de code fonctionne, si on le rajoute juste avant AMS_HiddenFunc.

	move.l		($c8).w,a2
	move.l		(a2),a3			;FirstWindow
	move.l		(a3),a3
DelDupScreens:
	move.w		$20(a3),-(a7)		;handle du DupScr
	beq.s		NoDupScr
	move.l		HeapFree*4(a2),a0
	jsr		(a0)
	addq.l		#4,a7
NoDupScr:
	move.l		34(a3),a3		;NextWindow	
	move.l		a3,d0

Les autres pertes de mémoire proviennent de la création de la barre d'entrée de l'Home, et d'un MenuBegin. Pour la barre d'entrée, il suffit de supprimer l'handle dans la structure TEXT_EDIT associée à l'ancienne barre. Mais ici aussi, le pointeur vers la structure est constant, mais il n'est pas exporté...
Pour le MenuBegin, je sais plus exactement, mais ça a pas l'air facile non plus.
Et il y a encore quelques autres handles créés qui proviennent d'un Plotinit et de 2 CreateEmptyList, mais ça ne mange qu'environ 10 octets.

Avec uniquement la correction pour les duplicate screens, on ne perd plus que 200 octets au hot reset.

Merci beaucoup. J'ai aussi ameliore de mon cote en faisant un HeapFree(top_estack) et un nettoyage de l'historique.
Mais faut que j'implemente un systeme de protection (Au cas ou la liberation planterait).

joli

ExtendeD a écrit :
Les autres pertes de mémoire proviennent de la création de la barre d'entrée de l'Home, et d'un MenuBegin. Pour la barre d'entrée, il suffit de supprimer l'handle dans la structure TEXT_EDIT associée à l'ancienne barre. Mais ici aussi, le pointeur vers la structure est constant, mais il n'est pas exporté...

Il est facile à trouver (merci à Samuel Stearley, la version ici est adaptée à partir des sources de XtraKeys):

;Detect the address of the home screen entry line parameters
;Thanks to Samuel Stearley for this one!
 move.l $c8,a0
 move.l TE_select*4(a0),d0 ;get the address of TE_select
 move.l HomeExecute*4(a0),a0 ;get the address of HomeExecute
;The code for HomeExecute contains a jsr to TE_select preceded by a pea of the
;required address.
search_loop:
 addq.l	#2,a0 ;code is word-aligned, so no need to check every byte
 cmp.l (a0),d0 ;compare with the address of TE_select
 bne search_loop
 movea.w -4(a0),a0 ;get address of the home screen entry line

arg tout ca a implante et a teste
Merci beaucoup.

Bon j'ai implante le truc d'Extended. On ne perd plus que 198 octets lors d'un Hot reset.
La j'ai la flemme d'ameliorer le truc pour en perdre moins

PREOS contiendra combien de librairie intégrées au kernel ??

aucune, je crois

PpHd a écrit :
Bon j'ai implante le truc d'Extended. On ne perd plus que 198 octets lors d'un Hot reset.
La j'ai la flemme d'ameliorer le truc pour en perdre moins

Allez, implante aussi mon code (enfin, celui de Samuel Stearley ), ça fera encore moins de perdu. Il y a juste:

 move.w 34(a0),-(a7)
 ROM_THROW HeapFree

à rajouter à la fin pour effectivement libérer le bloc.

Je vais faire un effort.

PpHd> Oui, oui, c'est genial, ca d'avoir une extracion automatique des runc )

Squale92> Pour les ppg, tu peut le decompresser et les recompresser avec runc

Il n'y a pas de ttunppggen.