 |
| Lib graphique pour R3 | |
| ldci | 9-Nov-2015/9:32:57+1:00 |
| Bonjour à tous En mettant à jour le binding pour la lib GLFW je suis tombé sur cette bibliothèque https://github.com/wjakob/nanogui C'est en C++, mais je pense qu'on devrait pouvoir faire un lien pour R3 sans trop de problème. Je n'ai malheureusement pour faire ça en ce moment, mais si quelqu'un avait quelques minutes pour regarder ce serait super. Affaire à suivre Amicalement | |
| ldci | 9-Nov-2015/11:37:35+1:00 |
| Bien plus simple encore car en pur C https://github.com/memononen/NanoVG Interessant... | |
| GreG | 9-Nov-2015/22:09:48+1:00 |
| Hello! Bien moi ca me fait surtout penser a l'extension SDL2 sur R3 qui marche bien sur MacOSX aussi! Je pense qu'il faudrait 'simplement' adapter r3-gui dessus, je n'en etais pas loin mais il reste encore quelques heures de travail pour ca. | |
| ldci | 10-Nov-2015/8:56:02+1:00 |
| Salut Greg Content d'avoir des nouvelles et de voir qu'il ya encore quelques irréductibles gaulois à croire en Rebol! Amicalement | |
| GreG | 10-Nov-2015/21:40:04+1:00 |
Heureux de te voir passer sur le forum egalement  Pour moi en ce moment, c'est surtout un probleme de temps libre, mais j'espere bien m'organiser pour refaire une petite place a Rebol! | |
| jjv | 12-Nov-2015/10:32:40+1:00 |
| "quelques irréductibles gaulois à croire en Rebol!" +1 JJV | |
| PierreCh | 16-Nov-2015/0:15:21+1:00 |
| +1 aussi! | |
| Dr-logic | 9-Dec-2015/8:22:41+1:00 |
| Salut aux gaulois (et aux autres), bon, je viens de m'inscrire sur ce forum, avant je croyais être le seul french à adorer REBOL  J'ai un peu lu les commentaires, c'est vrai que R, REBOL, BORON ressemblent à des mutans en perpétuelle mutation. Pour autant, on sent qu'il y a des chevaux sous le capot. Mais si j'avais des reproches à faire, c'est avant tout un cruel manque de specifications. Je ne parle pas de doc ou d'index de fonctions, mais d'un réel état des lieux des types de données, de leurs limites. Un peu à la façon UML. Par exemple, dans REBOL 2, j'avais découvert une erreur dans la somme de nombres ! Ce n'est pas le genre de chose que j'aime rencontrer en phase de débogage ! Pour ce qui est de la GUI, je trouve que c'est inutile puisqu'une page web peut lancer une ligne de commande. Bon, la critique est aisée, mais l'art est difficile. Mon problème est que je n'aime pas le C/C++ alors, pour être constructif, je vous propose une action concrète: Je serai ravi de réaliser un inventaire des types de données et fonctions (de REBOL dans un premier temps), façon UML. puis je vous propose de mutualiser nos tests unitaires. Je sais lister les plages de valeurs des formats de base du C, (int, double, etc...) j'ai un peu plus de mal à suivre les surcharges de classes et à définir le format de sortie d'une fonction. Mais le blocage vient des lib, des pipes et du parseur. Qui appelle qui et dans quel fichier source ? Le récursif n'arrange rien ... A cela vient s'ajouter les surprises du genre [a: sort b] qui trie aussi le contenu de b ? Je suis convaincu que ces petites bizarreries masquent le potentiel de ces langages. | |
| DideC | 9-Dec-2015/17:48:08+1:00 |
| Bienvenue à toi Dr-logic. Manque de spécifs... ou difficultés à les trouver ? Faire des spécifs, l'idée est intéressante, mais précise un peu ce que tu pense être manquant (avec quelques exemples). Rebol n'étant pas un langage purement objet, il n'y a pas de surcharges de classe, puisqu'il n'y a pas de classe ! Il n'y a que des objets, que l'on duplique en modifiant éventuellement la copie (make...). Quand au "format de sortie d'une fonction" et bien une fonction retourne une valeur (d'un datatype! donné) ou même différentes valeurs de différents types selon son résultat. lib, pipes et parseur : tu parles de source en C ou je ne comprends pas bien le sujet ? Quand aux surprises comme 'sort, il y en a assez peu. Je pense à 'trim, 'uppercase et 'lowercase, pour les plus utilisés !? Après avoir utilisé Rebol quasiment depuis ces débuts, je dois avouer que le Core/Manual reste pour moi plutôt bien fait, même s'il n'est pas parfait. On y trouve souvent les réponses recherchées. Maintenant, documenter les manques, reste une bonne idée. | |
| Dr-logic | 10-Dec-2015/8:21:50+1:00 |
| Merci DideC, lorsque je parle de C, d'objet et de surcharge de classes, je fais référence au code source de ROBOL (et BORON). C'est tout ce qui reste en dehors de la doc... Par exemple, lorsque tu cherche à générer du code REBOL dans ton script REBOL, tu as plusieurs moyens d'y pervenir, mais tous ne vont pas donner le même résultat. do & reduce associés aux différents moyens de composer les expressions à évaluer vont générer des différences de syntaxe, de type de donnée en réponse, etc... à cela vient s'ajouter le format des mots ex: word word: :word 'word Pour moi, REBOL est un emboitement de commandes (pipe) dont les valeurs en retour sont typées dynamiquement. C'est donc la syntaxe qui va différencier les résultats obtenus. mais , par exemple quelle taille maxi peut avoir un format monétaire, ou une somme d'heures? un format email doit contenir @, et les points, la longueur maxi de l'email ? Un opérateur comme le + réagit comment selon les formats des variables ? Oui, la doc est bien faite (et je remercie M. LE GOFF pour sa traduction, c'est tellement plus agréable en français...) mais j'éprouve juste le besoin de pouvoir prédire le comportement de mon script lors de sa conception et non lors de son test. En fait, avec REBOL, le plus gros du travail consiste à trouver LA commande qui réalise simplement ce que j'ai tenté de coder à l'aide d'une usine à gaz. Donc à optimiser le code, encore et encore. Et cela oblige à tâtonner... En terme de tâtonnement, la palme revient au parser! Tellement puissant que chacun de mes tests débouchent sur un code intéressant, hors sujet et inattendu ! A chaque fois que je cherche à réaliser une opération, j'en découvre d'autres tout aussi passionnantes. Bien entendu, je ne m'attends pas à trouver toutes les réponses dans la doc, mais au final, cela laisse un sentiment répulsif, de complexité du langage alors que c'est justement ce qui fait sa force. pour a: sort b une fois que je le sais, je commence par dupliquer b, puis je fais le tri. La fonction reste puissante et utile, il suffit de savoir comment la manipuler. (je me suis fait ma fonction tri et puis voilà) voici un exemple de questions pour lesquelles je ne trouve pas de réponse (et le test est impossible, car REBOL est trop puissant) : combien de make peut-on lancer dans un script REBOL? quelle est la taille maxi d'un script? comment générer des "objets" REBOL de type indexé ex: objet(1)/fonction param ? Pour revenir sur "la surcharge de classe", je suis obligé de me créer ma fonction addition, de tester les datatypes des variables en entrée puis rediriger le traitement en fonction du but recherché et ainsi prendre en charge les commandes de type: addition entier & string => string je me suis même créé ma fonction euro pour additionner des entiers =100*la valeur et retourner le résultat soit en string "10,04€" ou en décimal 10.04 cela pour conserver le format à 2 décimales et pour éviter l'addition de nombre décimal de REBOL 2, suite à des résultats faux. Au final, pour maîtriser la bête, je me recrée mes fonctions après tatonnements et test unitaire, pour savoir précisément à l'avance quel sera le résultat produit. Considérant que les combinaisons de fonctions de base non vérifiées sont à bannir. tu imagines la lourdeur de l'opération ! Alors je me dis que si je savais ce que retournent les fonctions internes de REBOL et de quelle manière elles interagissent, je pourrais plus facilement deviner le résultat produit ? C'est quand-même malheureux d'en arriver à tester une fonction d'addition d'entiers pour s'assurer du résultat obtenu... | |
| GreG | 10-Dec-2015/20:53:52+1:00 |
| Bienvenu Dr-logic, A l’école on apprend la programmation procédurale, puis la programmation par objet. De ce fait, nos esprits sont formates et certains ont du mal a appréhender Rebol pour cette raison. Tous le design de Rebol est justement d'aborder les choses de façon plus naturel et de se rapprocher du langage des humains. Les tâtonnements dont tu parles sont typiques pour un débutant, ce n'est qu'avec un peu de pratique que tu seras a l'aise sans imaginer aller voir le code source en C de l’interpréteur! | |
| Dr-logic | 11-Dec-2015/6:25:54+1:00 |
| Salut GreG, ravi d'être un petit scarabé ... Pour moi le gros avantage d'un interpréteur open source comme BORON et maintenant REBOL, c'est justement d'aller voir ce que fait précisément une fonction, quelle plage de valeur elle accepte en entrée et quelle plage de valeur elle retourne en sortie. Cela se valide lors de tests unitaires pour chaque fonction codée. Et les erreurs deviennent compréhensibles. Il ne suffit pas de dire dans la doc que SORT sert à faire un tri, si tu ne sais pas à l'avance quel ordre ton tri va retourner. Autre exemple: si je sais comment l'interpréteur gère les "objets" instanciés, je peux envisager un appel par référence si les paramètres passés à l'interpréteur le permettent. Comment veux-tu savoir ça autrement que dans le code ou par tâtonnement ? | |
| GreG | 11-Dec-2015/13:45:23+1:00 |
| Désolé pour le scarabé! Je ne sais pas, autant j'ai souvent une console Rebol pour vérifier un comportement lorsque je code, autant je n'ai jamais eu besoin d'aller voir le code de l'interpreteur pour comprendre davantage. Biensur, aller voir ce code source permet d'acquerir une maitrise complète. Pour moi, quelques tests unitaires Rebol suffises. Je ne me suis jamais demandé combien de make je pouvais faire, je n'ai jamais été confronté à une limite en particulier. Voilà. Sinon, faudrait peut-etre ouvrir un nouveau thread? On s'éloigne de la lib graphique de François | |
|
Login required to Post. | |