 |
| Red alpha 1 | |
| DocKimbel | 28-Oct-2012/17:09:05+1:00 |
Red est maintenant disponible en alpha 1, c'est la première version "utilisable", bien que les E/S soient limitées à PRINT pour l'instant.  http://www.red-lang.org/2012/10/red-alpha-release.html | |
| DocKimbel | 28-Oct-2012/17:10:19+1:00 |
| Pour avoir une idée de ce que Red peut déjà faire: https://github.com/dockimbel/Red/blob/master/red/tests/demo.red | |
| trigram | 28-Oct-2012/20:33:06+1:00 |
| Cool ! Félicitation pour la ténacité et le travail accompli DocKimbel ! | |
| JJV | 28-Oct-2012/21:49:12+1:00 |
| OUI félicitation DocKimbel. JJV | |
| deglingo | 28-Oct-2012/22:51:31+1:00 |
| Chapeau bas pour tout ce qui a été accompli en si peu de temps ! C'est captivant de suivre l'évolution de Red... Doc, sinon au niveau de la roadmap, as-tu une idée même approximative de l'échéance à laquelle tu vas introduire l'évaluation différée dans Red (les fonctions reduce, rejoin, compose, compose/deep, etc...) et également le fameux "parse" ? C'est pas du tout pour mettre une quelconque pression, loin de là, juste pour avoir une vision à plus long terme sur quelques fonctionnalités clés du langage. Encore bravo et merci beaucoup. | |
| jocko | 28-Oct-2012/23:42:37+1:00 |
| Bravo, Doc | |
| DocKimbel | 29-Oct-2012/0:20:37+1:00 |
@Deglingo: merci ! Les fonctions évaluant du code durant l'exécution (type DO, REDUCE, COMPOSE) seront bientôt supportées, mais dans un premier temps uniquement avec un block litéral en argument. Pour un support complet, il faudra attendre que le compilateur JIT soit ajouté (en 2013)...mais il y a une autre option possible pour palier à ce manque et rendre ces fonctions pleinement utilisable bien avant (je n'en dis pas plus pour l'instant, vous en saurez plus d'ici un mois  ).Pour ce qui est de PARSE, Gabriele s'est proposé pour l'implementer, s'il ne le fait pas, je le prendrai en charge d'ici la fin de l'année, ce n'est de tout façon pas un gros travail, une semaine tout au plus pour l'implémenter et le débugguer, c'est juste un mini-interpréteur de commandes. @tous: merci pour ces encouragements !! | |
| Laurent | 29-Oct-2012/2:36:54+1:00 |
| Super! Bravo! | |
| rosanoff | 29-Oct-2012/6:19:14+1:00 |
| Super, bravo et bon dev. | |
| DideC | 29-Oct-2012/11:20:55+1:00 |
| Ca va trop vite, on est pas habitué !! Bravo Nenad. | |
| shadwolf | 29-Oct-2012/13:06:43+1:00 |
| Felicitations Doc! Continu sur ta lancée! Je pense que Carl est entrain de crammer sa derniere cartouche. Si l'ouverture de rebol en opensource est un fiasco, plus personne ne le prendra au serrieux. Et a Nice cet été il risque d'etre bien seul! Pour ce qui est de parse. Si gabriele a dit qu'il le fera, c'est qu'il le fera! Parcontre se sera sa vision de parse il se peut que ca ne cadre pas avec ta vision de parse. Parse est compliqué et crucial et mon avis Carl l'a trop abandonné. Ce serait bien que Gabriele arrive a faire un groupe de reflexion qui face continuellement évoluer parse de red. | |
| ldci | 29-Oct-2012/19:00:44+1:00 |
| Bravo Nenad J'ai testé avec osx: parfait! En revanche quelques problèmes avec l'intégration des libs red/system.Affaire à suivre. | |
| DocKimbel | 29-Oct-2012/21:44:55+1:00 |
| @Didec: Quand je pense que je suis toujours en train de pester parce que je trouve que ça avance trop lentement... @shadwolf: Non, PARSE n'est pas compliqué du tout à implémenter et il n'ajoute rien que le language ne permette de faire déjà de base, en utilisant simplement les actions sur les "series". Le dialecte PARSE est un simple DSL permettant de faciliter le parsing, rien de plus, c'est un "sucre syntaxique". PARSE pourrait être facilement recodé avec les fonctions de base de REBOL ou Red, et c'est d'ailleurs ce que Gabriele compte faire. @ldci: merci pour les tests ! Pour les libs Red/System, si tu utilises les bindings de Kaj, il a fait qq changements très récemment qui ont induit des régressions sur les plateformes avec CPU Intel. Si tu as des erreurs de type "float exception" ou "float invalid op", c'est lié à ce pb que Kaj va rapidemment corriger (il a retiré le code permettant d'initialiser le FPU de manière compatible avec les libs écrites en C). Si ton problème est différent, tu peux le poster ici, ou mieux dans le bugtracker: https://github.com/dockimbel/Red/issues | |
| deglingo | 1-Nov-2012/15:16:55+1:00 |
| Merci pour les infos. Excellent ! La question a peut-être été déjà posée : une fois que le code source de Rebol2 et Rebol3 sera publié et les questions de licence réglées, est-ce que cela peut encore accélérer le développement de Red ? En gros, malgré que Rebol soit un langage interprété et Red un langage compilé, est-il possible de reprendre des parties importantes du code de Rebol pour développer Red ? | |
| DocKimbel | 2-Nov-2012/1:48:54+1:00 |
| Carl n'a jamais parlé de mettre REBOL2 en open source, mais uniquement REBOL3. est-il possible de reprendre des parties importantes du code de Rebol pour développer Red ? Etant donné que REBOL est codé en C et Red en Red/System, non, il n'est pas possible de "copier/coller" du code. Néanmoins, il est possible pour Red de s'inspirer de solutions déjà implementées dans R3 pour éventuellement fabriquer certaines parties plus rapidement, mais je n'y crois pas trop. Le gain le plus important est sans doute la couche graphique que l'on pourrait directement porter vers Red, même si Red proposera de toute façon des alternatives. Globalement, je doute que l'accès aux sources de R3 permette d'accélérer le developpement de Red de manière significative. En revanche, on pourra étendre la librairie standard plus facilement en reprenant les solutions éprouvées dans R3 (je pense à la partie crypto et SSL en particulier). A l'inverse R3 va pouvoir bénéficier de plusieures avancées que Red va apporter dans les mois qui viennent (notamment les ponts Java, Objective-C et .Net). | |
| deglingo | 2-Nov-2012/19:35:05+1:00 |
| Excellent, cette sorte de complĂ©mentaritĂ© entre Red et Rebol3 ! Inattendu, non ? C'est Ă quel horizon les ponts Java, Objective-C, et .Net ? Ca va ĂȘtre un sacrĂ© boulot, non ? Tu vas tout prendre en charge ? Chapeau si c'est le cas ! Dans quelques temps, il faudrait convaincre les fabricants de "devices" mobiles d'y mettre Red en natif !!! Ca serait possible techniquement ? Autre question : sur le blog de Red, il y a une liste de points Ă implĂ©menter dont "I/O support (including networking)", "Concurrency support". C'est pour la fin d'annĂ©e ou j'ai mal compris ? Ca paraĂźt super rapide ! Il y aura dĂ©jĂ des protocoles rĂ©seau implĂ©mentĂ©s ? Concurrency support , ça inclut quoi exactement ? Une partie du multi-threading ? Je m'arrĂȘte lĂ . DĂ©solĂ©, ça fait beaucoup de questions ! C'est que ça suscite des envies tout ça !! Merci en tout cas. | |
| DocKimbel | 3-Nov-2012/19:29:22+1:00 |
| Le pont Java pour les prochaines semaines, fin d'année au plus tard, les deux autres (Objective-C et .Net) ne sont pas plannifiés pour l'instant. Par défaut, je prends en charge tout. Pour le pont Java, Kaj s'est proposé pour réaliser l'interfaçage JNI. Mettre Red en natif dans les OS mobiles, pas de limitation technique particulière, par contre, convaincre les fabricants de le faire...peut-être quand on aura franchit le cap du million de devs Red dans le monde. ) I/O et "Concurrency": oui, pour la fin d'année. La gestion de la concurrence sera sans doute au stade du prototype utilisable, donc plutôt alpha sans doute. Protocole réseaux: oui, pour le bas-niveau, on aura TCP, UDP, DNS et si j'ai le temps, ICMP et Raw (accès direct à l'interface réseau). Pour ceux de plus haut niveau, au moins HTTP et HTTPS, peut-être SMTP. Pour les autres, on verra au fur et à mesure des besoins et des contributions. Si personne ne contribue, je trouverai le temps en 2013 d'ajouter POP3, IMAP4 et SSH. FTP me parait obsolète, je n'utilise plus que SFTP depuis dix ans, donc je ne passerai pas de temps dessus. Concurrency support (voir mes slides de présentations sur red-lang.org) C'est la possibilité d'exécuter simultanément plusieurs bouts de code Red (sur le même coeur ou répartis sur plusieurs coeurs). Donc, tu peux voir ça comme des "threads lights" qui s'appuyeront sur des "threads OS" au nombre très limité (1 par coeur). Pour la synchro, le plan est d'ajouter une couche "acteurs" (à la Scala/Haskell), mais je lorgne de plus en plus vers les goroutines de Go...à voir en décembre ce qui me paraitra le plus adapté. | |
| deglingo | 4-Nov-2012/14:07:04+1:00 |
| Sacré rythme de développement ! Ca décoiffe ! Le pont JAVA, ça consiste à transformer le code Red ou Red/System en bytecode interprétable par la JVM, c'est bien ça ? Quelle version de JAVA sera utilisée ? Le langage JAVA bouge pas mal en ce moment avec l'introduction des "lambda" expressions (pour java 8 normalement / http://www.jcp.org/en/jsr/detail?id=335 ) J'ai jeté un oeil aux "goroutines" (http://fr.wikibooks.org/wiki/Programmation_en_Go/Goroutines ). Ca a l'air super intéressant, léger et performant ! Que de choses passionnantes (protocoles réseau, la concurrence, les ponts avec les autres langages, la partie "interfaces graphiques", etc...). Je rêve du jour où l'on pourra avoir des serveurs d'applications en Red ultra-performants, multi-protocoles, utilisables en entreprises !! J'espère pouvoir en faire la promotion autour de moi... Merci. | |
| DocKimbel | 4-Nov-2012/15:30:20+1:00 |
| Pont Java: non, ça consiste à interfacer au runtime une appli Red en code natif avec la JVM en passant par JNI. Tu pourras invoquer les méthodes Java depuis Red comme si tu étais dans la JVM et inversement, appeler le code Red depuis la JVM. Les deux langages restent dans leur propre "monde", mais peuvent dialoguer dans les deux sens. Faire un backend JVM est également prévu (compilation Red générant du bytecode), mais pas à court terme, sans doute courant 2013, suivant les besoins/priorités. Serveur d'applis Red: c'est prévu pour l'été 2013 en alpha. Je compte créer un nouveau framework web en Red, beaucoup plus moderne que les simples RSP, plutôt du type GWT voire Opa (http://opalang.org). Et si tout se passe comme prévu, il y aura également une offre commerciale d'hébergement scalable pour ce serveur d'appli, type Heroku ! | |
| deglingo | 4-Nov-2012/20:21:51+1:00 |
| OK, cĂŽtĂ© JAVA, c'est plus clair pour moi. Au fur et Ă mesure de la maturation de Red, certains vont s'intĂ©resser au dĂ©veloppement d'interfaces graphiques, d'autres aux protocoles rĂ©seau, d'autres encore aux serveurs d'applications, au dĂ©veloppement d'application mobiles, etc, etc...C'est comme ça que naĂźt l'"Ă©cosystĂšme" autour d'un langage... Pour ma part, j'espĂšre vraiment qu'Ă l'inverse de Rebol, Red aura la chance de pĂ©nĂ©trer le monde de l'entreprise, des systĂšmes d'informations, notamment par l'utilisation de serveurs d'applications Red au lieu de Java (serveurs dominants Ă l'heure actuelle), et peut-ĂȘtre par le dĂ©veloppement de frameworks et progiciels dĂ©veloppĂ©s en Red. Pour cela, il faut qu'il y ait plus de ponts entre Red et les technos existantes du marchĂ©, qu'il n'y en a eu avec Rebol, l'inter-opĂ©rabilitĂ© ! Le futur nous le dira... | |
| jocko | 5-Nov-2012/12:25:47+1:00 |
| OK sous linux (ubuntu) Problème avec certaines langues sous windows (XP, Seven). Est-ce une question de polices disponibles sur la machine ? | |
| DocKimbel | 5-Nov-2012/13:58:02+1:00 |
| Jocko: tu parles de l'affichage des caractères Unicode du script %hello.red ? Sous Windows, il faut dans la console sélectionner la police "consolas", mais il te manquera quand même les caractères chinois (je crois que des polices pour Seven sont téléchargeable mais je n'ai pas essayé). Il n'y a que sous Linux que j'arrive à afficher tous les caractères, les polices pré-installées prenant en charge le CJK. | |
| jocko | 5-Nov-2012/15:42:13+1:00 |
| Oui, il s'agit du script %hello.red. Avec la police consolas, les messages s'affichent correctement, sauf le message chinois. Merci, je ne connaissais pas cette police. | |
| rosanoff | 11-Nov-2012/14:50:45+1:00 |
| Bonjour, encore bravo pour l'avancement de projet. J'ai hâte de pouvoir remplacer : rebol +cheyenne + postgresql + sqlite par red framework + postgresql + sqlite ainsi que la gestion des dates. bonne continuation. | |
| deglingo | 11-Nov-2012/18:38:46+1:00 |
| Bonjour Doc, J'ai testé l'utilisation du type path! avec Red. Je définis le bloc suivant : personnes: [ paul [ age 34 ville "Toulouse" ] jean [ age 41 ville "Nantes" ] ] J'ajoute la ligne suivante : j'arrive à compiler, à lancer l'exécutable et à obtenir le bon résultat : print personnes/4/2 ; => résultat = 41 Par-contre, si j'utilise la notation suivante, j'obtiens une erreur de compilation (voir ci-dessous) : print personnes/jean/age
>> do/args %red.r "test_path.red"
-= Red Compiler =-
Compiling test_path.red ...
...compilation time: 171 ms
Compiling to native code...
*** Compilation Error: undefined symbol: _select
*** in file: %test_path.red
*** at line: 113
*** near: [_select
stack/mark _select
word/get _personnes
word/get _jean
actions/pick*
]Est-ce que j'utilise mal la notation, ou tout simplement ce n'est peut-ĂȘtre pas encore complĂštement implĂ©mentĂ© ? Merci d'avance. | |
| DocKimbel | 12-Nov-2012/0:13:44+1:00 |
| Ton code est correct, c'est juste que SELECT n'est pas implémenté encore. Quand tu utilises un word! dans un path! (à partir de la 2ième position), celà déclenche une action SELECT implicitement. SELECT étant simplement un PICK FIND 2, il faut attendre en fait que FIND soit implémenté. Je pense que ce sera fait dans le courant de la semaine, sans doute pas avec toutes les options immédiatement, mais ça sera suffisant pour un simple SELECT. Pour info, j'attaque le support des fonctions demain ou après-demain...ça va devenir intéressant. | |
| deglingo | 12-Nov-2012/11:32:05+1:00 |
| OK, super ! Ca sera excellent quand on aura le support des fonctions, et des objets, on pourra utiliser la notation "path" aussi bien sur les block!, les objets que sur les raffinements de fonctions. Est-ce qu'il aura un type map! ? La notation "path" s'applique aussi sur ce type. Merci et bon dév. ! | |
| Philippe | 12-Nov-2012/14:04:03+1:00 |
| Salut, Excellent, toutes ces perspectives ! Pour les protocoles réseau bas niveau : SCTP ? Bravo Doc ! ===Philippe | |
| DocKimbel | 12-Nov-2012/15:53:28+1:00 |
| Est-ce qu'il aura un type map! ? Oui, mais il est basse priorité pour l'instant (il fait partie des optimisations, il ne fournit pas de fonctionnalité nouvelle). Hash! sera également de la partie, je regrette fortement son absence dans R3... Pour les protocoles réseau bas niveau : SCTP ? Ce n'est pas dans ma roadmap, donc sans doute pas pour la v1. J'avoue que je n'ai jamais utilisé ce protocole, tu as un cas d'usage ? Est-ce intégré par défaut dans les trois principaux OS ? | |
| Philippe | 13-Nov-2012/9:36:45+1:00 |
| Hello, SCTP est le protocole qui sera utilisé majoritairement sur les réseaux IP, car plus sécurisé et puissant que TCP. Réseaux IP = 4G/LTE, M2M donc d'ici 2-3 ans quelques millions d'objets connectés, plus de 110 réseaux commerciaux existants, et le double l'an prochain dans plus de 73 pays. Il existe des implémentations kernel dans la plupart des OS. http://stackoverflow.com/questions/1171555/why-is-sctp-not-much-used-known te fait un condensé de divers points de vues et liens. ===Philippe | |
| shadwolf | 13-Nov-2012/15:58:55+1:00 |
| Philippe, sans vouloir te froisser, je me mefie des grandes annonces concernant de nouveaux standards... exemple en 2012 internet passera totallement en ip v6 ... bon ben fin 2012 c'est toujours pas le cas et le test a grande echelle qui a ete il y a quelques mois a ete catastrophique. Ou flash est mort nous le remplaçon par html5, et au final adbobe et google s'assosie et font que pour plateforme mobile android et linux en general le plugin navigateur flash player disparaisse au profit d'une integration "infine" de l'api flash dans chrome et dirivatifs...(PPAPI) Ou encore gnome 3 est laid il doit etre abandonné. Ce qui conduira Microsoft a "s'en inspirer" pour son windows phone 7 puis pour son windows8 UI (ex interface metro..) Ou encore X11R6 est mort vive Wayland ... Bon parcontre rebol community a eu un fretillement mais apparement ils sont reparti en mode sieste... | |
| ldci | 13-Nov-2012/19:31:51+1:00 |
| On cause de red sur haïku os http://www.haiku-os.org/community/forum/red_programming_language_haiku Qui serait intéréssé? | |
| DocKimbel | 13-Nov-2012/23:12:53+1:00 |
| La bonne volonté seule ne suffit pas pour porter Red sur Haiku. L'API Haiku est entièrement en C++, donc non directement appelable depuis un autre langage que C/C++. Il est possible de créer des bindings pour chaque kit (groupe d'API) à l'aide d'une générateur, mais ça reste un travail long et fastidieux. Peut-être qu'un pont peut être construit comme pour la JVM ou obj-c, mais je ne me souviens plus si C++ permet l'instanciation de classes et l'invocation de méthodes dynamiquement... | |
| Philippe | 14-Nov-2012/9:52:31+1:00 |
| @shad: chacun pense ce qu'il veut, donc je ne me froisse pas, je ne suis pas dans des élucubrations comme on en lit tant, mais je fais référence à mon contexte pro. ===Philippe | |
| shadwolf | 14-Nov-2012/16:49:14+1:00 |
| @philippe: Hum les autres annonces aussi etaient faites par des gens parlant de leur contexte professionnel. Ceci dit c'est bien de commencer des maintenant ca te laisse un an et plus pour dev ou creer un groupe de dev pour gerer ce protocol reseaux. dockimble c'est ennorme que la communauté haiku envisage Red... Haiku est fait par un francais. Par certain coté les debut de haiku os me rappellaient ceux de rebol mais a la difference de RT notre ami auteur de haiku OS a su deleguer et s'entourer de gens actifs et desireux de faire avancer le projet. Haiku est tres suivi outre atlantique donc oui ca donne de la visibilité a Red. La visibilité n'est jamais une mauvaise chose. En suite le gros probleme que je vois c'est l'absence de VM rebol 2.X.XX.X pour cet OS. Je ne sais pas dans quelle mesure cela impacterai Red. Mais il clair que si l'on doit attendre une vm rebol 2.etc pour haiku venant de RT on va attendre longtemps. Pour ce que j'en sais la communauté Haiku est petite mais assez motivée et débrouillarde, ils ne ce contente pas de parler inlassablement de projets ou de problemes ils agissent. et en cela il se peut qu'il te propose de faire un moteur de compilation en C++ pour ton red. Lequel remplacerait rebol et a terme te permettrai de te separer de rebol en faisant un extrem mini rebol juste adapter aux besoins de compilations de red... A suivre donc... pour les classes dynamiques en C++ normalement c'est nom mais bon y a toujours moyen de "tricher" reste a savoir si les gens en charge du portage sont motivés ou pas. La motivation est a mon avis la fondation de tout acte de création. | |
| shadwolf | 14-Nov-2012/16:55:36+1:00 |
| Petit rappel pour les gens ne le savant pas. Haiku est un OS temps réel herité de BeOS mais entierement réécrit. Fort simpatique au demeurant. ultra rapide car ne faisant pas grand chose comme dirait shadwolf. Mais ultra rapide quand meme, sans SSD un haiku boot en 9 secondes avec interface graphique... sur un netbook... oui je sais c'est pas juste..."comment ca tu aimes plus ton windows 8? hey! oh! c'est bon arrete un peu de raler!" | |
| ldci | 14-Nov-2012/17:27:52+1:00 |
| Pour info 1 La version core de rebol pour Beos fonctionne sous Haiku (alpha 3 pas eu le temps de tester sous alpha 4). C'est la version rebol view qui pose problème Pour info 2: notre Doc national a été (comme moi) un "happy developer" sous BeOS. Dans mon souvenir il avait même acheté la machine BeBox produite par J.L. Gassé. | |
| DocKimbel | 14-Nov-2012/17:47:20+1:00 |
| Effectivement, on doit pouvoir faire tourner le compilateur Red sous Haiku. La dernière version de /Core pour BeOS est 2.5.0, il y aura donc sans doute quelques modifications à faire dans le compilateur pour qu'il puisse tourner sur cette ancienne version. Oui, j'avais acheté en 1996, une BeBox Dual-133, je n'avais que des Amigas et je ne pouvais pas me résoudre à passer sur PC/Windows 3.0. Une machine vraiment incroyable pour l'époque !Haiku alpha4 est vraiment bien, incroyable rapide et identique à BeOS. L'API C++ est un frein au portage et l'utilisation de langages de scripts sur BeOS, si Red peut y faire un percée, je pense que ça peut être vraiment rentable en terme de notoriété et extension de la communauté Red. | |
| shadwolf | 15-Nov-2012/14:00:48+1:00 |
| (at)Dockimble: tres, tres, bien tout ca! Pour le moment si rebol/core fonctionne on s'en contentera mais, tu me connais, je vois a plus long terme vu que de toute façon Red est voué a devenir independant de rebol pour sa compilation. Il serait peut etre judicieux de creer un groupe de travail chez les developpeurs Haiku pour leur faire ecrire un super compilateur temps réel qui en suite serait adaptable par le bas vers les autres machines. Je pense que c'est plus judicieux comme tactique a moyen terme que d'attendre que la communauté rebol se remette enfin au travail et que Carl arrete de disparaitre inopinément. Et que le futur de rebol soit organisé et stable. A mon avis si tu veut que Red compte se developpe il faut surtout surveillé deux axes fondamentaux la documentation. Qui doit permettre une prise en main rapide de red mais aussi permettre de s'epanouir en tant que developpeur. Un vieux reve qu'on a tous eu ici et qui n'a jamais ete concretisé: Transformé les tickets d'entre aide du forum en documentation de haut niveau" Si pour red un corpus de redacteurs se cré ca pourrait vraiment etre ennorme! (les espaces de styockage de wiki gratos sont pletores de nos jours sur le net et docu-wiki-rebolfr existe encore profitons en!) L'autre point fondemental c'est de se séparé le plus possible de la communauté rebol et de rebol/core ou du moins de bien leur faire comprendre que red est fait pour duré et avancé et que ce n'est possible qu'en se bougeant concretement les arpions! On a bien compris que rebol3 va etre soumis a la dictature de louis XVI et n'avancera pas et que rebol2.0 n'avancera plus. | |
| shadwolf | 15-Nov-2012/14:03:07+1:00 |
| Dockimble quand tu penses que haiku a commencé juste avec la passion d'un seul homme qui a tout reecrit sur son temps libre c'est digne d'interret et d'eloge. A lépoque 1998 deux systemes d'exploitation m'interressait vraiment plus que les autres QNX et BeOS. | |
| ldci | 18-Nov-2012/21:21:19+1:00 |
| @ tous rebol core 2.5.0 tourne bien sous Haiku alpha 4.1 mais pas red. pas encore eu le temps de regarder le compilateur A + | |
| shadwolf | 20-Nov-2012/15:07:33+1:00 |
| @ldci: super! masi bon on le sait rebol 2.5.0 evoluera plus... et sera pas tout de suite opensource. On a bien vu que l'important c'etait de relancer rebol3. Rebol2 est consideré comme mort... Je ne sais pas ... il a fallut 10 ans de baston avec Carl pour qu'il accepte le principe de lacher dans la nature son code source pour assurer la survie de son projet. A moins d'un mouvement massif pour que rebol 2 soit opensource aussi il n'evoluera plus. A la limite c'est meme pas evoluer c'est juste que rebol 2/core soit au meme niveau sur tout les OS. rebol 2.5.0 avait un packet de bug assez violent... (cf rambo si c'est encore possible) La version la plus avancé et la plus debugée est la rebol 2.7.8... qui evidement existe pour windows linux et mac os et c'est tout. Ca peut jouer. Je rappellerait que l'effort de debug a surtout porter sur rebol/core ce qui prouve bien qu'il y a une ennorme difference entre 2.5 et 2.7.8 | |
|
Login required to Post. | |