DideC et si on Rebolait?
shadwolf23-Oct-2017/14:49:47+2:00
Dans un precedent post DideC me demandait pourquoi je reprennait pas l'IDE viva-rebol?

J'ai repondu un truc du genre "BuHarg! je deteste les Glob! tant que r2 est pas dispo pour ameliorations je ferrait rien du tout... Quand j ai demander des correctifs de bug dans VID R2, Buarhg On m avait claqué la porte a la gueule en me disant que r3 aurait nativement la widget ritch text donc arrete de faire chier shadwolf..."


Puis bon le site qui hostait le projet viva-rebol est parciellement mort. Du coup dificil de continuer a avoir acces a viva-rebol.

Maintenant plus je vois le monde de l informatique evolué et plus je le vois ressemblé au monde REBOL. Si on prend le monde python aujourd'hui ou le monde java ou le monde javascript (si il y a un monde de dev javascript c est pas une blague) il s'articulent tous autour du un package and project manager... ce que rebol avait preques en 2003 avec view/desktop et rebol.org sauf que bon c etait pas un outil pour aider a la creation rapide de projet il manquait cette dimension.
Je parle des maven, npm, apm, gradle, etc ... ses outils en ligne de commande lié a un site et qui permette "rapidement" de poser la structure d un projet que ce soit un moteur backend style python/Django ou que se soit un web angular ou react ou une application mobile cordova phonegap ionic etc...

Je suis encore une fois devant le dileme suivant:" Rebol en 2003 faisait deja ca avec en plus une jolie interface graphique et on doit etre genre 100 dans le monde a le savoir".

Qu'est ce qu il manque a rebol pour que l on puisse faire un clone rebol de Django.

1) une structure centralisé permettant d installer des script /librairies (appelons ca des plugins) pour etendre rebol.

2) un site fiable et actif ou une comunauté de revision assurte que les puglins publié ne vont pas exploser ni rebol ni notre computer.

3) Accepté que rebol doit avoir ce qu il faut pour etre portable en gros rebol-core me semble etre le point fondementale. Mais qu'est ce que rebol-core selon moi ?

4) Prendre LINUX comme os de developpement et porter vers le reste de l univers car c'est sous linux que sont les sites WEB.

5) Orientons REBOL pour faire des sites web. PHP et python sont un bon milliard de fois plus connus que rebol et pourquoi ? parce qu ils servent le web.

6) Offrir une solution qui evolue dans le temps qui s adapte facilement au nouveau defis du futur.
shadwolf23-Oct-2017/15:05:19+2:00
Okay shadwolf mais c est quoi rebol-core pour toi ?

commencons la liste et ensemble afinons.

- parse
- network
- help
- console
- outil de gestion package/projet-starter
- function mathematique et logique.
- sisteme centralise pour les plugins
- compresion/decompression
shadwolf23-Oct-2017/15:10:57+2:00
- Un truc que j'aime bien dans python et que je verai bien dans rebol-core c'est la possibilité a la volée d avoir un fichier binaire contenant le script deja interpreté en langage machine.
shadwolf23-Oct-2017/15:23:08+2:00
- executer un sous programme et interpreter le resultat.

- Pouvoir controller l execution d un sous programme. kill le procesus s'il a rien produit dans un certain lapse de temps donc connaitre le PID connaitre stdErr et stdOut. voir simuler une saisie utilisateur (tcl/tk).

- Que l execution du sous programme soit async.
shadwolf23-Oct-2017/15:39:18+2:00
Par exemple pour la gestion des processus PHP considere que les scripts php vont etre auto gerez par le serveur web (apache ou autres) en gros un fichier php a un debut un milieu une fin et une courte durée de vie. il a pour but de genere une page web avec des données qu il a ete chercher dans une base de données. Si un script a un probleme ca ne met pas en cause le reste des scripts du site (sauf si c est une librairie qui a un probleme).

Dans mon souvenir avec Cheyenne! si je me souviens bien comme le serveur web reposait sur rebol si un sous script avait un probleme et faisait planté rebol le site disparaissait... pas glop du tout... donc un aspect a resoudre.
shadwolf23-Oct-2017/17:27:57+2:00
pourquoi Les outils telque django, react, nodejs se demarque de comment on faisait des sites web avant.

Principals outils mis en oeuvre de nos jours docker, et git.

Apache postgres ou mysql ou oracle ont une approche monolitique dans leur fonctionnement. En gros les fichiers de config sont dans /etc le fichiers binaires dans /usr/bin les librairies dans /usr/lib et le fichier de donnees sont dans /var/lib/mysql /var/www etc... bref suivant les distros linux ca varie.

Avec django, nodejs, et leur derrive tout ce passe dans le dossier qu on leu a choisi...


Dans les grandes ligne creer un siteweb django/react ca marhe comme ca

1) django
-creer un dossier backend entrer dans le dossier backend
-creer les fichier pour Docker
- lancer un docker-compose run <serviceDjango> python3 manage.py startproject api
- lancer un docker-compose run <serviceDjango> python3 manage.py startapp app

(api contient la conf du serveur django les librairie qu il charge le port d ecoute le type de base de donnee utilisé par defaut sqlite etc... backend/app contiendra notre MVC)

Partager le tout avec git init puis le monter dans le serveur de partage de sources de son choix. De sorte que pour le recuperer le collegue qui bosse aussi sur le backend il aura juste a faire :
- git clone url
- docker-compose up & et youpla le backend est ready to dev.

Si on a besoin de transporter notre django vers notre host genre digital ocean. on se prepare une version OS minimaliste genre archlinux-docker.iso on creer une machine virtuelle en lui donnant notre iso. on se log ssh a notre nouvelle machine virtuelle et on fait
- git clone url
- docker-compose up& et youpla c est deployé.

Et pour le front-end ben c est un peu la meme..
- On install npm et nodejs
- On install avec npm create-react-app
- On fait un create-react-app <mon-front>
- On fait rendtre dans le dossier mon-front et on est pres a dev l interface avec le backend.

Publication/partage du front end avec git-hub.

Deployment avec une iso minimal qui a nodejs +webpack ou nginx git clone url et c est parti ca marche.

pas besoin d etre super user. pas besoin de se casser les pieds a deplace des dossiers dans ses sous dossier du systeme d exploitation.

et En java avec un framework auto config comme Spring-boot-camp c est limite encore plus facil en un sens ... On recupere le fichier XML pour le projet a utilise avec maven ou gradle ou autre... on un maven insta
shadwolf23-Oct-2017/17:34:57+2:00
idealement rebol devrait etre le seul outil que l on ai besoin d installer.

dans un dossier on invoquerait rebol create-backend monbackend puis rebol create-frontend mon-web ca crerait la structure que lon veut utiliset puis on entrerait dans
monbackend on remplirait le MVC et on ferait rebol start-backend et hop le backend serait inicialiser les librairies auto installee si besoin est la base de donnees créée etc...

pour le front end pareil on irait dans le dossier mon-web et on ferrait rebol web start et pof on aurait rebol qui s executerai en mode serveur web.

evidement pourquoi on aurrait pas tout dans le meme outils?

ben si on a une application monolitique tout en un pas de scalabilité sauf en utilisant des subterfuges comme docker/swarm... Si on partie plante elle entraine tout le reste avec elle...
shadwolf23-Oct-2017/17:42:44+2:00
maintenant rebol doit etre le plus simple et extensible possible... par exemple le serveur web je vois pas du tout l interret de l avoir en natif dans la wm ca peut tres bien etre un script placé dans le dossier de librairie de rebol.

de sorte que rebol web start.. Je ne me souvient plus trop si les mezzanine de rebol2 etaient des scripts intégré dans rebol pour augmenter des fonctions de fond de panier ... ce serait la meme idee mais en dehors de la VM rebol.

Je suis pour que les gens etendent rebol en utilisant rebol ... donc un rebol minimaliste au possible un bon syssteme d extension qui demande un vrai investissement de matiere grise. Pourquoi je devrais ecrire un script de passerelle pour utiliser depuis mon script rebol la librairie SQLite.
C est pas possible de faire ca automatiquement ?
shadwolf23-Oct-2017/18:07:18+2:00
De sorte que rebol web start nous telecharge le plugin script web et librairies puis appelle la fonction start du module web.

premier lancement
monlinux$ rebol web start
Web plugin not found locally
Web plugin found on rebol plugin repository
Web plugon downloading [ === ]
Web Plugin ready to use
Web Plugin Loaded call start method.
Web plugin ready and listenning on:
loacalhost:8080

second et suivant lancement:

monlinux$ rebol web start
Web plugin locally found
Web Plugin Loaded call start method.
Web plugin ready and listenning on:
loacalhost:8080
shadwolf23-Oct-2017/18:29:52+2:00
pourquoi les mezzanine doivent etre externes a la vm rebol ?

Pour moi il est fondementale que rebol progresse... Hors progresser en rebol en passant son temps a faire du C je vois pas trop l interret... Idealement je veux que s'il y a un probleme dans le protocole mysql ou sqlite ou autre on puisse l ameliorer directement. sans avoir besoin de recompiler.
Je veux que si le changement s opere dans une mezzanine que ce soit informer ou mis a jour automatiquement.
PierreCh9-Nov-2017/18:30:21+1:00
Salut!

Quel intéressant monologue! C'est bien, au moins, il n'y a pas énormément de contradiction.

Intéressantes idées que voilà. As-tu essayé de voir ce qu'avait fait rgchris avec son Quartier-Maître?
https://github.com/rgchris/QuarterMaster

J'avais essayé, il y a longtemps, de le faire tourner, mais j'avais échoué, puis j'étais parti en Afrique, et comme d'hab, voilà, paf...
shadwolf10-Nov-2017/15:58:11+1:00
je suis forcé au monologue y a plus personne...
shadwolf10-Nov-2017/17:39:04+1:00
r3 etait pas si loin d avoir un systeme de package externe prenons GUI (que je prefere appeller VID) il repose sur a la fois des types natifs (gob! images!) des fonctions natives dont l implementation est laissé ouverte a travers de host pour de futurs remplissage.

Du coup c est bizarre car on a la necesité de faire un type natif un dialect natif mais on laisse ouverte et libre l implementation "physique" des mot du dialect.

VID se compose donc de 3 partie une partie interne au rebol/core une partie C extern passant par host mais qu on doit quand meme compiler avec le core et une partie externe le dialect (load-gui) qui est un script mis en place sur le site rebol.com. et la encore je sais pas trop en fait car on a pas tout les code de GUI on a pas AGG par exemple dans le code source de R3 actuel.

Alors oui j ai ete le premier a pester contre load/library mais au finale ca me semble être moins le bordel que le systeme actuel.
shadwolf10-Nov-2017/17:54:21+1:00
QuaterMaster est interessant. Maintenant faut un rebol v3 qui le serve bien.
PierreCh11-Nov-2017/22:27:41+1:00
Oui, en effet. Pour ma part, je me satisfais pour le moment d'un Rebol 2 qui a le grand avantage, à mon très humble avis, de fonctionner de manière stable et prédictible.

J'ai essayé le Rebol 3 il y a pas mal de temps, je n'avais guère été convaincu. J'en étais arrivé à porter tous mes espoirs du côté de Red. Et puis les évènements de la vie m'ont pas mal éloigné d'Internet... Je tente de raccrocher les wagons avec le monde Rebol aujourd'hui.
shadwolf11-Nov-2017/23:20:07+1:00
rebol2 a juste 200 fois plus de contenu que r3 au niveau du core ...

Login required to Post.


Powered by RebelBB and REBOL 2.7.8.4.2