Je teste de suite
PureBasic 4.20 Beta 5
PureBasic 4.20 Beta 5
pb 5.31
Re: PureBasic 4.20 Beta 5
Moi qui ai installé a b4 cet aprem...didier69 a écrit :Sortie de la beta 5 avec pas mal d'explications de la part de Fred.
Je teste de suite
Oui oui, mais là maintenant je n'ai pas le courage de m'y mettrebernard13 a écrit :ça serait bien que que le message de fred soit traduit en Français
.Pour info, la documentation est en français mais le fichier Purebasic.chm semble ne pas se copier lors de l'update. Le fichier français est dans l'archive zip dans le répertoire "Languages\Francais". Je l'ai simplement recopié dans le répertoire où Purebasic est installé après la mise à jour.
pb 5.31
Bonjour,
Voici lela 5ème beta de PB 4.20. ça a été plus long que prévu, et je voudrais passer un peu de temps à expliquer pourquoi. N'ayez pas peur, ce sera probablement la dernière beta, si tout va bien . Voici l'histoire :
Au début, 4.20 devait juste ajouter de nouvelles commandes.Pas de problèmes prévu, car nous ne travaillerons pas sur le compilateur ou de débogeur. Mieux, la plupart des nouvelles bibliothèques ont été déjà écrites, comme nous en écrivons souvent lorsque quand la correction des bogues devient trop ennuyeuse (nous n'incluons pas la nouvelle bibliothèque dans le planning, donc elle veut évoluer doucement). si bien que 2 mois après la version 4.10 une nouvele beta était prête. Et maintenant, les choses se compliquent.
Nous rencontrons encore des bogues/limitations dues à LccWin32, nous avons donc décidé qu'il était temps de passer à Visual C++ 2005. Ce choix a été fait pour les raisons suivantes :
1) c'est le compilateur « officiel » de C/C++ sur Windows
2) il est libre (nous employons l'excellente edition « Express » )
3) il produit un ttrès bon code (bien mieux que le lcc - quelques bibliothèques ont gagné 50-100% juste en changeant le compilateur)
4) il a une version 64bits, ainsi le port en 64 bits est direct (au moins pour les bibliothèques)
5) exempt d'erreurs (au moins du côté de compilateur)
Ainsi nous avons commencé la migration de toutes les bibliothèques et des bibliothèques du compilateur (SystemBase, StringManager, etc…). Certaines étaient codées avec l'ASM intégré à Lcc, il a donc fallu les retravailler. VC++ est également plus rigoureux et beaucoup d'avertissements sont apparus et on eu besoin d'une correction. D'ailleurs nous avons activé le mode de contrôle de probabilité 64 bits et notre console a débordé. Pensez que quand nous migrons toutes les commandes, ça affecte des centaines de fichiers, tous les makefile doivent être adaptés etc. Mais comme vous pouvez le comprendre, c'est pour avoir un meilleur résultat. Plusieurs semaines plus tard, tout compilait correctement et vous pouvez le deviner, la version 64 bits compilant (presque) aussi bien. C'était la base pour commencer le travail pour le compilateur 64bits.
Nous avions donc bien avancé, mais une optimisation VC8 étrange provoquait des bugs avec l'appel de fonctions (PureBasic supposait que les arguments passés à la pile pour les fonctions ne seraient jamais modifiés par fonction en C. (ce qui est le cas avec lcc et GCC). Mais il y a aucune information correcte sur ceci, et le VC8 utilise les paramètres de la pile comme tampon si besoin). Ainsi une modification du compilateur était nécessaire pour résoudre cela, après beaucoup de recheches (nous avons obtenu des bugs aléatoires sur quelques fonctions).
Entre temps, nous avons fait face à quelques régressions ainsi nous avons fait des essais beaucoup plus restreints pour rendre les commandes plus robuste aux changements. Ceux-ci grâce à l'outil « PureUnit » développé par Timo (Fr34k) qui devrait arriver bientôt avec PB, car c'est vraiment d'un grand secours pour s'assurer un module se comporte comme prévu, sur chaque plateforme.
Une fois que toutes les bibliothèques et aides ont été compilées avec VC8, nous ne pouvions pas laisser le compilateur utiliser Lcc. Ainsi nous avons commencé la migration de celui-ci. bons gains en vitesse de compilation (10-30%) mais nous avons dû duper un peu VC8 pour employer une vieille DLL VC (MSVCRT.dll) au lieu du nouveau VC8, car il ne fonctionnerait pas directement sans installer VC8. Google nous a beaucoup aidé
En parallèle, CVS meurt et remplacé partout par SVN. Nous avons migré le dépôt de bibliothèques il y a quelque temps, mais le compilateur et les outils internes employaient toujours le vieux CVS. La migration n'était pas tout lisse car le dépôt de CVS était sur un ordinateur basé sur NT tandis que le script requis pour faire la migration étaient sur le Linux. Après quelques problèmes, cela a fonctionné. Donc SVN partout. Et honnêtement c'est mieux comme ça.
Timo a voulu ajouter un profileur à l'ide, ainsi il a fait. Et il l'a bien fait. Ainsi il m'a fait remarqué me que je n'ai pas profilé le compilateur depuis un moment et ce pourrait être tout à fait amusement à faire. J'ai essayé de trouver un bon profileur sur Windows (n'importe qui ?) mais j'ai seulement trouvé le coûteux 'Quantify' pour les mesures (et la démo a montré seulement l'appel d'api avec VC8 exécutable, je ne savais pas si elles provenaient de bugs ou d'appels normaux). Ainsi je suis passé sur Linux et ai employé le gprof et le compilateur de Linux. J'ai employé le code source d'ide comme repère (60 000 lignes). Et ici, le désastre : 23 millions d'appels à stricmp () - appelé en recherchant (a token) (comme une constante, structure, procedure, fonctions, macro etc.). Il semble que mes vieilles"lookup tables" souffrent ici. À coup sûr, les résidants ont presque 8000 constantes et la table de consultation était trop petite. J'ai décidé de changer cela avec la vraie table de hash. Le gain était impressionnant, maintenant seulement 500 000 appels à stricmp () sont faits. Sur mon ordinateur, le temps de compilation est passé de 3500ms à 500ms. Cette optimisation est disponible dans la betas 5, donc si vous avez un grand projet, vous allez sentir la différence.
Nous avons également voulu aborder la plupart des bogues importants restant depuis dernière version 4.10 (et même avant), ainsi nous passons un certain temps pour les fixer (sur les 3 OS). Ceci m'a amené à retoucher le « QuadUnit », qui est employé pour manoeuvrer et compiler sur les quatre OS. Celui développé pour PB 4.00 était bon mais parfois trop compliqué à utiliser. Ainsi j'ai totalement simplifié la conception et ai recodé plusieurs parties fondamentales. Ce changement est également dans la beta 5, ainsi n'hésitez pas à rapporter les bogues si il en reste. Au moins, tout le "QuadUnit" a rapporté que des bogues sont maintenant corrigés.
En fait, nous avons ajouté trop commande pour une seule version, mais hé, nous sommes des mégalomanes. Ainsi nous avons obtenu beaucoup de rapports de bogues sur ces derniers (logique car ces nouvelles bibliothèques n'étaient pas triviales). Merci à vous tous pour les rapports et la patience.
Comme nous ne pouvons pas nous arrêter, nous devons travailler à quelques nouvelles idées, nous avons commencé la version 64 bits de PureBasic et la version X86 (intel) pour MacOS. On pourrait penser que la version X86 sur MacOS est juste une recompilation, mais c'est ce tromper. L'OS X le x86 ABI est horrible et est très stirck sur l'utilisation de la pile (on 16 bytes boundaries) que les versions Windows/Linux ne requierent pas. Si la pile est mal utilisé, ça fonctionne parfois, pas d'autres fois : c'est très dur pour débugger. Ainsi, le compilateur a été retouché pour manipuler correctement l'utilisation de la pile. De plus, FASM n'est pas disponible sur OS x x86, ainsi nous avons décidé de migrer toutes les bibliothèques d'assemblage (liste chaînée, misc..) sur NASM. En effet le compilateur a été modifié pour produire le code compatible avec NASM au lieu de FASM. Du côté x64, le travail a été encore tout plus dur car "the assembly" (l'asembleur ?) lui même n'est pas le même. Mais, tous les deux arivent, et l'essai public viendra bientôt.
Le dernier point mais pas le moindre, beaucoup de nouvelles commandes signifient beaucoup de Doc. à écrire. Ceci prend beaucoup de temps, car nous le faisons dans 3 langues. La beta 5 vient avec la Doc. dans 3 langages, pour toutes les nouvelles commandes.
Voilà, ainsi vous pouvez télécharger la beta 5 sur votre compte et l'essayer. Les bêtas pour Linux et OS X sont prêts aussi, mais nous attendrons un peu avant leur distribution(pour voir s'il n'y a aucun problème important. Et si vous utilisez la beta 4, regardez le répertoire temporaire car un bug empêche parfois de supprimer des fichiers temporaires et ça prend de la place
Have fun !
L'équipe de Fantaisie Software
Voici lela 5ème beta de PB 4.20. ça a été plus long que prévu, et je voudrais passer un peu de temps à expliquer pourquoi. N'ayez pas peur, ce sera probablement la dernière beta, si tout va bien . Voici l'histoire :
Au début, 4.20 devait juste ajouter de nouvelles commandes.Pas de problèmes prévu, car nous ne travaillerons pas sur le compilateur ou de débogeur. Mieux, la plupart des nouvelles bibliothèques ont été déjà écrites, comme nous en écrivons souvent lorsque quand la correction des bogues devient trop ennuyeuse (nous n'incluons pas la nouvelle bibliothèque dans le planning, donc elle veut évoluer doucement). si bien que 2 mois après la version 4.10 une nouvele beta était prête. Et maintenant, les choses se compliquent.
Nous rencontrons encore des bogues/limitations dues à LccWin32, nous avons donc décidé qu'il était temps de passer à Visual C++ 2005. Ce choix a été fait pour les raisons suivantes :
1) c'est le compilateur « officiel » de C/C++ sur Windows
2) il est libre (nous employons l'excellente edition « Express » )
3) il produit un ttrès bon code (bien mieux que le lcc - quelques bibliothèques ont gagné 50-100% juste en changeant le compilateur)
4) il a une version 64bits, ainsi le port en 64 bits est direct (au moins pour les bibliothèques)
5) exempt d'erreurs (au moins du côté de compilateur)
Ainsi nous avons commencé la migration de toutes les bibliothèques et des bibliothèques du compilateur (SystemBase, StringManager, etc…). Certaines étaient codées avec l'ASM intégré à Lcc, il a donc fallu les retravailler. VC++ est également plus rigoureux et beaucoup d'avertissements sont apparus et on eu besoin d'une correction. D'ailleurs nous avons activé le mode de contrôle de probabilité 64 bits et notre console a débordé. Pensez que quand nous migrons toutes les commandes, ça affecte des centaines de fichiers, tous les makefile doivent être adaptés etc. Mais comme vous pouvez le comprendre, c'est pour avoir un meilleur résultat. Plusieurs semaines plus tard, tout compilait correctement et vous pouvez le deviner, la version 64 bits compilant (presque) aussi bien. C'était la base pour commencer le travail pour le compilateur 64bits.
Nous avions donc bien avancé, mais une optimisation VC8 étrange provoquait des bugs avec l'appel de fonctions (PureBasic supposait que les arguments passés à la pile pour les fonctions ne seraient jamais modifiés par fonction en C. (ce qui est le cas avec lcc et GCC). Mais il y a aucune information correcte sur ceci, et le VC8 utilise les paramètres de la pile comme tampon si besoin). Ainsi une modification du compilateur était nécessaire pour résoudre cela, après beaucoup de recheches (nous avons obtenu des bugs aléatoires sur quelques fonctions).
Entre temps, nous avons fait face à quelques régressions ainsi nous avons fait des essais beaucoup plus restreints pour rendre les commandes plus robuste aux changements. Ceux-ci grâce à l'outil « PureUnit » développé par Timo (Fr34k) qui devrait arriver bientôt avec PB, car c'est vraiment d'un grand secours pour s'assurer un module se comporte comme prévu, sur chaque plateforme.
Une fois que toutes les bibliothèques et aides ont été compilées avec VC8, nous ne pouvions pas laisser le compilateur utiliser Lcc. Ainsi nous avons commencé la migration de celui-ci. bons gains en vitesse de compilation (10-30%) mais nous avons dû duper un peu VC8 pour employer une vieille DLL VC (MSVCRT.dll) au lieu du nouveau VC8, car il ne fonctionnerait pas directement sans installer VC8. Google nous a beaucoup aidé
En parallèle, CVS meurt et remplacé partout par SVN. Nous avons migré le dépôt de bibliothèques il y a quelque temps, mais le compilateur et les outils internes employaient toujours le vieux CVS. La migration n'était pas tout lisse car le dépôt de CVS était sur un ordinateur basé sur NT tandis que le script requis pour faire la migration étaient sur le Linux. Après quelques problèmes, cela a fonctionné. Donc SVN partout. Et honnêtement c'est mieux comme ça.
Timo a voulu ajouter un profileur à l'ide, ainsi il a fait. Et il l'a bien fait. Ainsi il m'a fait remarqué me que je n'ai pas profilé le compilateur depuis un moment et ce pourrait être tout à fait amusement à faire. J'ai essayé de trouver un bon profileur sur Windows (n'importe qui ?) mais j'ai seulement trouvé le coûteux 'Quantify' pour les mesures (et la démo a montré seulement l'appel d'api avec VC8 exécutable, je ne savais pas si elles provenaient de bugs ou d'appels normaux). Ainsi je suis passé sur Linux et ai employé le gprof et le compilateur de Linux. J'ai employé le code source d'ide comme repère (60 000 lignes). Et ici, le désastre : 23 millions d'appels à stricmp () - appelé en recherchant (a token) (comme une constante, structure, procedure, fonctions, macro etc.). Il semble que mes vieilles"lookup tables" souffrent ici. À coup sûr, les résidants ont presque 8000 constantes et la table de consultation était trop petite. J'ai décidé de changer cela avec la vraie table de hash. Le gain était impressionnant, maintenant seulement 500 000 appels à stricmp () sont faits. Sur mon ordinateur, le temps de compilation est passé de 3500ms à 500ms. Cette optimisation est disponible dans la betas 5, donc si vous avez un grand projet, vous allez sentir la différence.
Nous avons également voulu aborder la plupart des bogues importants restant depuis dernière version 4.10 (et même avant), ainsi nous passons un certain temps pour les fixer (sur les 3 OS). Ceci m'a amené à retoucher le « QuadUnit », qui est employé pour manoeuvrer et compiler sur les quatre OS. Celui développé pour PB 4.00 était bon mais parfois trop compliqué à utiliser. Ainsi j'ai totalement simplifié la conception et ai recodé plusieurs parties fondamentales. Ce changement est également dans la beta 5, ainsi n'hésitez pas à rapporter les bogues si il en reste. Au moins, tout le "QuadUnit" a rapporté que des bogues sont maintenant corrigés.
En fait, nous avons ajouté trop commande pour une seule version, mais hé, nous sommes des mégalomanes. Ainsi nous avons obtenu beaucoup de rapports de bogues sur ces derniers (logique car ces nouvelles bibliothèques n'étaient pas triviales). Merci à vous tous pour les rapports et la patience.
Comme nous ne pouvons pas nous arrêter, nous devons travailler à quelques nouvelles idées, nous avons commencé la version 64 bits de PureBasic et la version X86 (intel) pour MacOS. On pourrait penser que la version X86 sur MacOS est juste une recompilation, mais c'est ce tromper. L'OS X le x86 ABI est horrible et est très stirck sur l'utilisation de la pile (on 16 bytes boundaries) que les versions Windows/Linux ne requierent pas. Si la pile est mal utilisé, ça fonctionne parfois, pas d'autres fois : c'est très dur pour débugger. Ainsi, le compilateur a été retouché pour manipuler correctement l'utilisation de la pile. De plus, FASM n'est pas disponible sur OS x x86, ainsi nous avons décidé de migrer toutes les bibliothèques d'assemblage (liste chaînée, misc..) sur NASM. En effet le compilateur a été modifié pour produire le code compatible avec NASM au lieu de FASM. Du côté x64, le travail a été encore tout plus dur car "the assembly" (l'asembleur ?) lui même n'est pas le même. Mais, tous les deux arivent, et l'essai public viendra bientôt.
Le dernier point mais pas le moindre, beaucoup de nouvelles commandes signifient beaucoup de Doc. à écrire. Ceci prend beaucoup de temps, car nous le faisons dans 3 langues. La beta 5 vient avec la Doc. dans 3 langages, pour toutes les nouvelles commandes.
Voilà, ainsi vous pouvez télécharger la beta 5 sur votre compte et l'essayer. Les bêtas pour Linux et OS X sont prêts aussi, mais nous attendrons un peu avant leur distribution(pour voir s'il n'y a aucun problème important. Et si vous utilisez la beta 4, regardez le répertoire temporaire car un bug empêche parfois de supprimer des fichiers temporaires et ça prend de la place
Have fun !
L'équipe de Fantaisie Software
Je ne garantis pas du tout la qualitée de la traduction car pour aller plus vite j'ai utilisé un traducteur automatique que j'ai ramené en Français 
Surtout sur la fin concernant MacOS, "stack alignement" que j'ai traduit en "utilisation de la pile" je suppose qu'il y a beaucoup mieux mais je ne connais pas assez la gestion de la pile. En tout cas bravo Fred, surtout pour la version X86 de MacOS
Par contre ça aurait été bien de venir s'exprimer aussi ici
Surtout sur la fin concernant MacOS, "stack alignement" que j'ai traduit en "utilisation de la pile" je suppose qu'il y a beaucoup mieux mais je ne connais pas assez la gestion de la pile. En tout cas bravo Fred, surtout pour la version X86 de MacOS
Par contre ça aurait été bien de venir s'exprimer aussi ici
Merci pour la traduction. C'est compréhensible quand même, c'est l'essentiel.Oliv a écrit :Je ne garantis pas du tout la qualitée de la traduction car pour aller plus vite j'ai utilisé un traducteur automatique que j'ai ramené en Français
Surtout sur la fin concernant MacOS, "stack alignement" que j'ai traduit en "utilisation de la pile" je suppose qu'il y a beaucoup mieux mais je ne connais pas assez la gestion de la pile. En tout cas bravo Fred, surtout pour la version X86 de MacOS
Bah on a pris l'habitude, maintenant. Tu sais bien qu'on est la cinquième roue du carrosse, nous. (Et encore, quand je dis "carrosse", je devrais dire "char à boeufs")Par contre ça aurait été bien de venir s'exprimer aussi ici
Wow , il y a eu de sacrés changements !
Fr3ak a ajouté une petite note pour dire qu'il était très occupé ces derniers temps , mais qu'il promettait de corriger les bugs relatifs à l'IDE pour la version finale.
Fred a traduit les nouvelles commandes de la biblio cipher (dispo dans le fichier chm), je vais mettre cette version en ligne bientôt, quand j'aurai fait quelques corrections et quelques ajouts.
Fr3ak a ajouté une petite note pour dire qu'il était très occupé ces derniers temps , mais qu'il promettait de corriger les bugs relatifs à l'IDE pour la version finale.
Fred a traduit les nouvelles commandes de la biblio cipher (dispo dans le fichier chm), je vais mettre cette version en ligne bientôt, quand j'aurai fait quelques corrections et quelques ajouts.
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Comtois si tu as besoin d'aide pour la traduction (correcte cette fois ) dis le.
Dobro : La cross compilation....ça m'étonnerai beaucoup car il faut porter toute l'API d'un OS sur l'autre : Sur ce lien, il prennent un paquet "win32" et de mémoire quand on utilise CygWin il faut aussi telecharger toutes les bibliothèques de Linux.
) dis le.Dobro : La cross compilation....ça m'étonnerai beaucoup car il faut porter toute l'API d'un OS sur l'autre : Sur ce lien, il prennent un paquet "win32" et de mémoire quand on utilise CygWin il faut aussi telecharger toutes les bibliothèques de Linux.
Oui j'aimerais bien de l'aide pour la traduction de la doc, pour les ajouts dans l'IDEOliv a écrit :Comtois si tu as besoin d'aide pour la traduction (correcte cette fois
Je ferai un post pour montrer les passages à traduire, dès que j'aurai un peu de courage.
J'imagine que tu parlais du texte plus haut ? Mais j'en profite pour recruter
http://purebasic.developpez.com/
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Je ne réponds à aucune question technique en PV, utilisez le forum, il est fait pour ça, et la réponse peut profiter à tous.
Non je parlais bien de la doccomtois a écrit :Oui j'aimerais bien de l'aide pour la traduction de la doc, pour les ajouts dans l'IDEOliv a écrit :Comtois si tu as besoin d'aide pour la traduction (correcte cette fois
Je ferai un post pour montrer les passages à traduire, dès que j'aurai un peu de courage.
J'imagine que tu parlais du texte plus haut ? Mais j'en profite pour recruter
Sauf pour le "correcte cette fois" bien sur où je parlais de celle de Fred
-
beauregard
- Messages : 1307
- Inscription : dim. 08/juil./2007 18:32
- Localisation : Toulouse