 |
| Fil | |
| ldci | 4-Jul-2013/9:45:46+2:00 |
| Bojour à tous le fil Rebol et Opencv a disparu! Dommage car je demandais vos conseils sur la gestion de la mémoire avec Rebol | |
| DideC | 4-Jul-2013/10:13:13+2:00 |
| Mince ! Ca commence à faire pas mal de pertes de ce genre, ça devient inquiétant !  D'autant qu'il y avait beaucoup d'informations techniques très intéressantes sur ce fil. Greg, au secours !! | |
| GreG | 4-Jul-2013/10:53:20+2:00 |
| Je ne comprends vraiment pas d'ou vient ce problème de perte de thread (et donc d'email). | |
| GreG | 4-Jul-2013/15:22:47+2:00 |
| Il existe encore un CGI beta de rebelBB, je vais le détruire au cas où il serait à l'origine de ces problèmes et afin d'être certain que seul le script rebelBB.cgi accéde au serveur IMAP. Après, si vous avez des suggestions, je suis preneurs. Je pense qu'il faut écarter l'hypothèse d'un serveur IMAP defectueux, c'est tout de même un serveur chez un hebergeur avec redondance etc. | |
| ldci | 4-Jul-2013/22:33:08+2:00 |
| @Didec: pas de panique j'ai gardé trace de mes tests du binding OPenCV @ tous: j'ai besoin d'aide pour un problème de gestion de la mémoire avec Rebol. Quand je fais des acquisitions vidéo, j'ai un beau "not enough memory" après 2 mn environ. Le coupable c'est la fonction de récupération des images "image: cvRetrieveFrame capture ". J'ai testé avec system/sats et j'ai bien une utilisation exponentielle de la mémoire avec cette routine. C'est spécifique à Rebol car je n'ai pas ce pb ni en C ni en Red. J'ai essayé plein de solutions sans succès et je suis preneur de toute suggestion. A + | |
| shadwolf | 6-Jul-2013/0:50:08+2:00 |
| gestion de memoire merdique sur rebol2 ... que c est etonnant..... je dirais a la louche que c est parce que cet imbe... perdon ... parce que rebol2 ne vide pas le contenu d une memoire vers le disque dur tant qu on ecrit dedans... Ou une chose dans le genre. Hum j ai trop peu d info pour savoir de quoi il s agit vraiment mais ton probleme me rappel un probleme qu on avait au debut de rebol2 ... et qui avait forcer Carl a faire une option speciale a write /direct - Opens the port without buffering. j imagine que le but c est d ecrire dans un ficher .... L autre probleme que vois c est que dans ta traduction tu utilise une variable "normale" de rebol et pas un tampon cycle comme ca doit etre le cas en C et en red ... en gros le tampon cycle a une taille fixe tu ecris dedans quand tu arrive au bout tu ecris son contenu sur le disque dans le cas d une ecriture puis tu repart au debut et et ainsi de suite. | |
| shadwolf | 6-Jul-2013/0:54:14+2:00 |
| pour les fils ... ton server greg avait eu des problemes disque a une epoque se serait pas a nouveau le cas? les mails qui disparaissent = des fichiers qui disparaissent = un disque qui oubli ou un mec qui volontairement efface ou un bug dans le serveur MAPI qui efface les fichiers en les fermant mal... moi je ferais courrir un crontab horaire pour copier le contenu du dossier de mail... mais bon c est sous linux ca ... | |
| ldci | 6-Jul-2013/1:40:05+2:00 |
| @ShadWolf Très intéressant commentaire: effectivement OpenCV bufferise les images qu'il renvoie (afin de pouvoir synchroniser n images) et précise même qu'il ne faut pas y toucher ! La variable Rebol "normale" comme tu dis, n'a aucune espèce d'importance. Une fois que la capture vidéo est créée on peut s'en même passer. Par contre comment faire pour vider le tampon cycle avec Rebol? Voici le code incriminé
; repeat until q keypress
while [foo <> 113] [
print ["avant " system/stats / (10 ** 6)]
cvGrabFrame capture
image: cvRetrieveFrame capture;
cvShowImage "Test Window" image ; show frame
image: none
recycle
print ["après " system/stats / (10 ** 6)]
foo: cvWaitKey 1
]
Bon courage à ceux qui veulent tester! A + | |
| gerardcote | 27-Jul-2013/21:37:04+2:00 |
| @ Ldci : Si cela peut aider, j'ai cru entendre, lors du dernier ReCode àMontréal, Maxim raconter comment il avait contourné des problèmes de gestion de mémoire que le GC lui imposait. Carl semblait intéressé par sa solution mais moi je n'y ai pas trop compris grand chose - le tout étant de plus discuté en anglais. Peut-être que tu pourrais le contacter pour échanger un peu avec lui sur le sujet. C'est quand il a présenté son logiciel Liquid qu'il a présenté sa solution je crois bien. Le nombre de noeuds associés à des objets devant être générés étant volumineux, il a plutôt résolu de créer des références - sans les instancier si je me rappelle bien - vers ces objets pas encore officiellement créés chaque fois... enfin quelque chose du genre. Ainsi il minimisait l'impact du GC en évitant des appels inutiles. Faut lui demander les détails. | |
| Jocko | 28-Jul-2013/9:07:39+2:00 |
| à propos de Liquid, Maxim a t'il annoncé une nouvelle version, une mise à jour du site ? | |
| gerardcote | 28-Jul-2013/18:00:42+2:00 |
| Oui il devrait nous fournir sa nouvelle mouture de Glass et de Liquid si je ne m'abuse, ainsi que ses codes exemples pour aller avec sa présentation d'ici une semaine ou deux - mais cela dit, ça fait déjà 14 jours que l'annonce a été faite. alors vaut mieux aller lui poser la question sur AltMe je crois ... Lui il en a pris vraiment large sur ses épaules cette fois et j'espère seulement que sa santé tiendra le coup... il semblait encore voler quand je l'ai rencontré avec sa conjointe à Montréal, mais sait-on jamais. Il a même réalisé sous Glass, un petit IDE appelé Glide qui me semblait assez puissant - malgré un manque de fini déjà peu apparent selon les auditeurs - mais Maxim est très exigeant envers lui-même et ses produits alors il nous a indiqué les faiblesses qu'il désire encore corriger avant de pouvoir le qualifier d'oeuvre achevée ... mais quand le sera-t-il et sera-t-il accessible à tous ensuite ? ... à suivre! | |
|
Login required to Post. | |