J'aimerais bien qu'on m'explique?

[polo974]

l'informatique, le but est le moindre effort de l'utilisateur, pas de la machine...

sinon, poussé à l'extrême, on ne lui demande plus rien, et elle le fait à la perfection : le rien...

si j'ai une formule genre ((a * b + c*c ) - (a*c/b))/(c * c /(a+b))
j'ai 2 choix:

écriture C:
je jette la formule dans le code et basta:
y = ((a * b + c*c ) - (a*c/b))/(c * c /(a+b)); // le compilo se depatouille
(ensuite, on peut optimiser, développer, regrouper, mais ça reste lisible pour le commun des mortels)

en polonaise inversée:
heu... je laisse ça à d'autres ...
(c'est une sorte de flemme, mais un automatisme est fait pour les flemmards, j'en suis donc fier)
-----

[Forthman]

((a * b + c*c ) - (a*c/b))/(c * c /(a+b)
a b * c c * a c * b / - c c * a b + / /
c'est pas bien compliqué quand-même
ok, je sors

[ansset]

l'informatique, le but est le moindre effort de l'utilisateur, pas de la machine...

sinon, poussé à l'extrême, on ne lui demande plus rien, et elle le fait à la perfection : le rien...

si j'ai une formule genre ((a * b + c*c ) - (a*c/b))/(c * c /(a+b))
j'ai 2 choix:

écriture C:
je jette la formule dans le code et basta:
y = ((a * b + c*c ) - (a*c/b))/(c * c /(a+b)); // le compilo se depatouille
(ensuite, on peut optimiser, développer, regrouper, mais ça reste lisible pour le commun des mortels)

je plussoie, avec un argument non développé ici : tout dépend de ce qu'on programme.
je me demande bien si on utilise du Forth pour de la programmation de simulation numérique poussée, avec beaucoup d'équations complexes.
ps: je connais très bien ( et depuis le début ) tout ce qui concerne les images de synthèse, et franchement, la problématique était essentiellement la modélisation des phénomènes physiques, dont principalement un rendu réaliste, et dans ce cadre, une des difficultés était dans les équations ( peu simples et avec beaucoup de paramètres ajustables )
ensuite , il fallait du CPU puissant pour avaler tout cela.
je n'ai jamais entendu parler du Forth pour tout ça !
l'autre difficulté était le travail avec 10 ingés en parallèle, et donc une lisibilité commune ( à l'instant T ) et évolutive dans le temps.

j'ai donc une question :
dans quels domaines , le Forth est-il majoritairement utilisé ?

[inviteb9f49292]

j'ai donc une question :
dans quels domaines , le Forth est-il majoritairement utilisé ?

Précise bien de nos jours...

[ansset]

salut à toi:
c'était sous-entendu, enfin je le pensais.

[polo974]

((a * b + c*c ) - (a*c/b))/(c * c /(a+b)
a b * c c * a c * b / - c c * a b + / /
c'est pas bien compliqué quand-même
ok, je sors

il manque un +...

[CM63]

il manque un +...

Je ne pense pas.

[Ludwig1]

Salut

Précise bien de nos jours...

Une liste non exhaustive c'est en Allemand (En Allemagne c'est bien plus connu qu'en France)
je peux te traduire si tu veux.

https://www.forth-ev.de/staticpages/...p/applications

Pour résumer, le système de développement Forth est utilisé dans bien des domaines, mais indéniablement c'est l'automatique et le pilotage de machines qui est son terrain de prédilection, il existe une VM Forth pour une large gamme de microcontrôleurs. On implante des VM Forth spécifique dans des FPGA.
Le Spatial, Pilotage de satellites,
Armement, Pilotage de Missiles etc...
C.a.d. des domaines auquel la majorité d'entre vous n'est probablement pas confrontée. Raison pour laquelle vous ne connaissez pas.
Je me verrais mal programmer un régulateur à réponse pile autrement qu'en Forth.
Le fait est que vos PC et autres sont aussi des machines, il n'est donc pas stupide d'appliquer
la science de l'automatique pour faire fonctionner une machine destinée à " usiner des informations de façon automatisée".
Quand Chuck à fait Forth il avait deux PB à résoudre:

1) Piloter le télescope
2) Ramasser une quantité industrielle de données puis les traiter.

Je ne sais pas comment vous les uns et les autres vous travaillez avec votre machine.
En ce qui me concerne, je démarre la machine virtuelle, puis au clavier je lui dis ce que je veux. Il n'y a pas de syntaxe, il n'y pas de " compilateur" au sens commun du terme.
Je passe les infos et ensuite je dis ce qu'il faut faire avec.
Si la machine ne sais pas faire ce que je souhaite elle me le dit, alors je dois le lui apprendre.

Le seul travail de " programmation" consistera alors à faire apprendre un mot nouveau à la machine et à enregistrer celui-ci
dans un des dictionnaires de la machine.

Il est bien plus facile de mettre au point un seul mot à la fois puis de tester son bon fonctionnement en dehors de tous contexte d'une quelconque application. (Développement interactif)

Cordialement

Ludwig

[albanxiii]

((a * b + c*c ) - (a*c/b))/(c * c /(a+b)
a b * c c * a c * b / - c c * a b + / /
c'est pas bien compliqué quand-même
ok, je sors

J'aurais dit :

a b * c c * a c * b / c c * a b + / / -

[pm42]

Il est bien plus facile de mettre au point un seul mot à la fois puis de tester son bon fonctionnement en dehors de tous contexte d'une quelconque application. (Développement interactif)

Il y a de nombreux langages et environnements qui permettent de travailler de cette façon : Lisp, PHP, Python, Scala, pas mal d'environnements Web (Play et autres).
Et comme toute logique itérative, elle est adaptée à un certain type et une certaine taille de projets.

Tout ce que tu décris se ramène à 1 seul programmeur travaillant sur une base de code de taille raisonnable. C'est un tout petit sous-ensemble de ce qu'on a à faire en développement et il est dommage d'avoir une visions aussi limitée.

[Forthman]

J'aurais dit :

a b * c c * a c * b / c c * a b + / / -

il aurait fallu que l'équation d'origine soit : (a * b + c*c ) - (a*c/b)/(c * c /(a+b)

[Ludwig1]

Salut,

Tout ce que tu décris se ramène à 1 seul programmeur travaillant sur une base de code de taille raisonnable. C'est un tout petit sous-ensemble de ce qu'on a à faire en développement et il est dommage d'avoir une visions aussi limitée.

On peut travailler tout seul sur un projet ou par équipe. Dans le travail par équipe, on fixe le cahier des charges pour chaque
programmeur. Il reçoit les spécifications des méthodes qu'il doit développer en gros ça se présente de la façon suivante:

1) Structure des données sur la pile avant appel de la méthode
2) Ce que la méthode est supposée faire
3) Structure des données restituée par la méthode sur la pile de donnée.

Il se trouve que j'ai eu à conduire des projets de ce type, en un temps record, nous avions toute une panoplie de composants
informatiques prêt à l'emploi pour piloter les machines.
Je ne sais pas si tu connais l'histoire de l'aéroport de Riad, l'équipe qui à sauvé la situation a procédé de cette façon.
L'expérience a montrée que le développement basé sur la VM Forth se prête à merveille au travail en équipe.



Cordialement

Ludwig

[Forthman]

Ce que tu expliques là fonctionne avec tous les langages, sauf qu'on parlera de procédures et non pas de mots,
et qu'il faut donner des noms et types de variables en entrées/sorties.
(enfin je pense puisque je ne programme qu'en Forth et assembleur)

Mais bon !... Imaginons un instant que ça y est tu as convaincu tous les participants de se mettre au Forth
On fait quoi ? Parce que...
Il n'y a que très peu de doc (des trucs exploitables en 2016, pas des veux machins des années 80)
Il y a très peu de forums (actifs) (je ne parle même pas de forums en français)

Hier encore, je me suis penché sur SwiftForth, mais comme je suis sous Linux, je n'ai qu'un vilain terminal tout moche
(avec wine j'ai vu que l'interface était un peu mieux sous win$)
Je voulais voir comment fonctionnait les objets de la pile, mais je n'ai pas vu de différence.
La pile Forth (de la version démo de swiftforth tournant sous linux, je précise) est une simple pile 32 bits.
quand je tape une chaine genre :

S" Bonjour"

un TYPE m'affiche Bonjour
Mais un . (point) m'affiche la longueur de la chaîne soit 7
et un autre . (point) m'affiche l'adresse de cette chaîne
Donc un fonctionnement "classique"

J'ai également cherché des exemples en Forth de programmes utilisant l'opengl (le minimum syndical quand-même) et je n'ai rien trouvé

Par contre ce n'est pas la peine de me dire que la première chose à faire est de claquer 399$ dans swift car déjà comme dit plus haut sous Linux
c'est moche, et que même si j'étais sous windows, je ne mettrai pas une telle somme dans un langage (sauf utilisation pro, et encore)

gforth (qui est quand-même LA référence sous Linux) n'a pas bougé depuis juillet 2014

donc voilà quoi ...

[pm42]

On peut travailler tout seul sur un projet ou par équipe. Dans le travail par équipe, on fixe le cahier des charges pour chaque
programmeur. Il reçoit les spécifications des méthodes qu'il doit développer en gros ça se présente de la façon suivante:

1) Structure des données sur la pile avant appel de la méthode
2) Ce que la méthode est supposée faire
3) Structure des données restituée par la méthode sur la pile de donnée.

C'est amusant parce que c'est exactement ce qui ne marche pas pour un gros projet.
C'est du pur cycle en V et avec l'illusion qu'on peut spécifier complètement et précisément au niveau de la méthode.

L'autre chose amusante est que c'est contradictoire avec le développement interactif décrit plus haut : si on travaille de cette façon, pas besoin d'ajouter des méthodes à la volée comme tu e décrivais puisqu'on a des specs complètes dès le début.

Il se trouve que j'ai eu à conduire des projets de ce type, en un temps record, nous avions toute une panoplie de composants
informatiques prêt à l'emploi pour piloter les machines.

Affirmation gratuite comme d'hab.

Je ne sais pas si tu connais l'histoire de l'aéroport de Riad, l'équipe qui à sauvé la situation a procédé de cette façon.

Ca remonte à plus de 20 ans...
Le monde a changé, l'informatique aussi. Pas toi.

L'expérience a montrée que le développement basé sur la VM Forth se prête à merveille au travail en équipe.

Tu viens de démontrer le contraire en expliquant qu'on pouvait utiliser le "specs formelles/cycle en V" qui est la méthode "loin d'être merveilleuse".

Encore et encore et encore, ton ignorance, obsolesence et ton prosélytisme autour du forth sont plus que ridicules. On a vraiment l'impression que la dite limite de consommation est dépassée (ou qu'au delà de cette limite, le ticket n'est plus valable pour faire une allusion plus du ton temps).

[polo974]

il manque un +...

Je ne pense pas.

si, si...

(d'ailleurs à la fin du calcul, il reste 2 éléments sur la pile)

comme quoi, c'est vachement lisible...

[Forthman]

a b * c c * + a c * b / - c c * a b + / /

oupssseuuuu !!!

edit: oui, la lisibilité est pourrie, mais l'écriture est simple, faut juste pas se tromper à la première écriture

[pm42]

edit: oui, la lisibilité est pourrie, mais l'écriture est simple, faut juste pas se tromper à la première écriture

On appelle ça des "write only languages" comme APL et d'autres

[Ludwig1]

Salut,

Ce que tu expliques là fonctionne avec tous les langages, sauf qu'on parlera de procédures et non pas de mots,
et qu'il faut donner des noms et types de variables en entrées/sorties.
(enfin je pense puisque je ne programme qu'en Forth et assembleur)

Tous d'abord je souhaite faire remarquer que nous parlons de machine informatique virtuelle, pas de langage de programmation.
Cela signifie qu'on ne peut pas se baser sur les caractéristiques de l'un pour décrire l'autre.
Classiquement, avec la méthode de développement à l'aide d'un langage on commence par édit, puis compil, puis debugg puis à la fin, au bout d'un temps long long long, on fait un exécutable.

Dans le cadre de la VM ici décrite, le développement d'une application consiste à rajouter des " Mots " nouveaux dans un dictionnaire particulier.

Comme tu es actif dans le domaine de l'usinage semblerait 'il je vais utiliser des analogie de ce domaine pour décrire la VM.
Les analogies:
On peut considérer que la VM est l'équivalent d'un centre d'usinage l'un usine des pièces (Objets), l'autre aussi (Données)
De ce fait, il apparaît que la notion d'objet s'applique essentiellement aux données.
Sur un centre d'usinage, on dispose d'un endroit ou sont fixés les objets (étau, gabarit de montage etc...)
Sur la VM on trouve un endroit ou sont " fixées les objets" la pile de données.
Sur un centre d'usinage, on dispose d'un magasin d'outils ou sont rangés les outils spécifiques liés aux opérations d'usinage.
Sur la VM on trouve un dictionnaire particulier contenant les " outils" spécifiques liés aux opération de traitement.
On peut continuer la liste des analogies,
Disque dur = Magasin central
Dictionnaire principal = Magasin central d'outillage
Internet = système de transport
etc... etc...
Comme déjà dit à plusieurs reprises, les ordinateurs et autres ne sont rien d'autres que des machines à traiter
les informations de façons automatisé.
En conséquence de quoi j'essai d'appliquer les préceptes d'une science nommée Automatique pour faire fonctionner ma machine.
Le reste c'est direction poubelle.

Mais bon !... Imaginons un instant que ça y est tu as convaincu tous les participants de se mettre au Forth

D'abord je souhaite faire remarquer que je ne cherche pas à convaincre qui que ce soit de quoi que ce soit. J'essai juste d'exposer une méthodologie de développement autre que celle classiquement utilisée.
Les questions posées sur le Forum, ne font que confirmer la lourdeur de la méthode de développement édit, compil, debugg,

On fait quoi ? Parce que...
Il n'y a que très peu de doc (des trucs exploitables en 2016, pas des veux machins des années 80)
Il y a très peu de forums (actifs) (je ne parle même pas de forums en français)

Pour autant que je sache, les nez de broche ISO 40 existaient déjà il y a 50 ans, ça s'est un peu adapté à la CNC pour faire
le changement d'outil. Un filetage ISO M10 d'il y a 50 ans était probablement le même que celui d'aujourd'hui.
Les mots " SWAP DUP DROP etc..." sont des outils qui permettent de réaliser une certaine opération sur un objet.
Ceci étant, pour ce qui me concerne, je développe sous Windows 10 des applications orientés composants pour le CLOUD
avec des outils d'il y a " presque 50 ans".
C'est bien là ou est le PB, faire le distingo entre les outils et les objets à " usiner".
Les outils sont normalisés et invariant (presque), les objets que l'on fabrique avec, eux évoluent avec le temps.

Hier encore, je me suis penché sur SwiftForth, mais comme je suis sous Linux, je n'ai qu'un vilain terminal tout moche
(avec wine j'ai vu que l'interface était un peu mieux sous win$)

Comme déjà dit, je suis sous Windows 10, je ne connais pas la structure de la VM qui tourne sur Linux.

Je voulais voir comment fonctionnait les objets de la pile, mais je n'ai pas vu de différence.
La pile Forth (de la version démo de swiftforth tournant sous linux, je précise) est une simple pile 32 bits.
quand je tape une chaine genre :

S" Bonjour"

un TYPE m'affiche Bonjour

Essaye ça

: STRING$        ( n < nom$ > --- ) \ Déclaration d'une chaine de caractères de
                 \ longueur n et de nom nom$.
                 \ USAGE:  255    STRING$  Message$  
                 \ construit une chaine de caractères vide de nom Message$
                 \ et d'une taille max de 255 caractères



        CREATE
                DUP  c, 0 c, H +!
        DOES>
                DUP 1+ c@ >R
                2+ R>
 ;



: LEN$          ( adr,n, --- adr,n,nmax ) \ Retourne la taille max d'une chaine de
                   \ caractères

   OVER 2- C@

 ;


 : ERASE$        ( adr,len --- ) \ Purge une chaine de caractères et rempli celle-ci
                       \ avec des 0. La taille courante est ramenée a 0


        Len$ NIP OVER >R
        ERASE 0 R>
        1- C!


 ;


: BLANK$        ( adr,len --- ) \ Purge une chaine de caractères et rempli celle-ci
                     \ avec des espaces. La taille courante est ramenée a 0


        Len$ NIP OVER >R
        BLANK 0 R>
        1- C!

 ;      



: $!            ( adr1,n1,adr2,n2 --- ) \ Transfert de la chaine source adr1,n1
                \ vers la chaine destination adr2,n2, la chaine destination est d'abord purgée de son contenu 
                \ précédent

        OVER 4 Pick <>
        IF
           2DUP ERASE$
        THEN
           DROP 1- DUP 1-
           C@ ROT MIN SWAP PLACE

 ;



64    STRING$  InputMessage$

 S" Nombre rentré:  "  	       InputMessage$   $!

128   STRING$  OutputMessage$

  S" Valeur du carré de ce nombre:  "  OutputMessage$ $!


: N_Au_Carré		( n --- n*n )
  
   Dup * ;


: AFFICHE_TEST        ( n --- ) \ test d'affichage du carré d'un nombre Integer

  

   CR  20  10 AT-XY InputMessage$  TYPE  DUP         51  10 AT-XY (.) Type
   CR  20  11 AT-XY OutputMessage$ TYPE  N_Au_Carré  50  11 AT-XY (.) TYPE


;



\ USAGE:
 
25 AFFICHE_TEST

Mais un . (point) m'affiche la longueur de la chaîne soit 7
et un autre . (point) m'affiche l'adresse de cette chaîne
Donc un fonctionnement "classique"

Quelqu'un dit autre chose ?

J'ai également cherché des exemples en Forth de programmes utilisant l'opengl (le minimum syndical quand-même) et je n'ai rien trouvé

Je n'utilise pas OpenGL mais Fastgraph ( Ted Gruber jeux vidéos Las Vegas )qui est bien plus rapide
En général pour implémenter une API
voir les mots

LIBRARY
Function:
IMPORT:

Cordialement
Ludwig

[polo974]

a b * c c * + a c * b / - c c * a b + / /

oupssseuuuu !!!

edit: oui, la lisibilité est pourrie, mais l'écriture est simple, faut juste pas se tromper à la première écriture

bah, pas tant que ça, vu que je l'ai vu juste en lisant (ensuite, j'ai testé pour vérifier quand cm63 a émis un doute (et j'ai un peu révisé, mais ça s’arrêtera là (c'est ici qu'on voit que je suis accro aux parenthèses ))).

[polo974]

On appelle ça des "write only languages" comme APL et d'autres

Et on met tout ça dans des WOM (Write Only Memory) ...


(bref, on oublie...)

[inviteb9f49292]

Je n'utilise pas OpenGL mais Fastgraph ( Ted Gruber jeux vidéos Las Vegas )qui est bien plus rapide

Il est vraiment surpuissant ce forth pour pouvoir faire pédaler une bibliothèque graphique plus rapidement que l'OpenGL... qui est l'accès direct au matériel...
Bref encore une énormité annoncée de manière péremptoire...

[Ludwig1]

Re salut,

a b * c c * + a c * b / - c c * a b + / /

oupssseuuuu !!!

edit: oui, la lisibilité est pourrie, mais l'écriture est simple, faut juste pas se tromper à la première écriture

Si on applique de façon claire la séparation entre objets (données) et les opérations à réaliser sur ces données, la lisibilité
n'est pas trop " pourrie"

Objets          Opérations
------------||--------------
a  a                   *
c  c                    *
a  c                   *
b                       /
                         -
c  c                   *
a  b                   +
                        /
                        /

Si on applique la convention d'écriture classique, qui consiste à représenter l'évolution dynamique de la pile de données,
les choses deviennent limpides au point qu'il n'est pas nécessaire de faire appel à un débugger.
La recherche d'erreur est grandement simplifiée.

Exemple:

: EraseZl           ( zadr0, --- ) \ Initialise tous les pointeurs d'une Zliste et efface le contenu de la liste.
                                   \ USAGE:   ListeFichiers  Erasezl
                                   \ Efface le contenu de la Zliste de nom ListeFichiers et
                                   \ initialise les pointeurs de cette liste.


	>R 		( zadr0 ----  )
        R@ 		( -------zadr0 )		
        R@ 		( zadr0 --- zadr0 zadr0 )
        Zmaxtaille@     ( zadr0 zadr0 --- zadr0 maxtaille ) 
        Erase		( zadr0 maxtaille ---- )
        0		( --- 0 )
	R@ 		( 0 --- 0 zadr0 )
        Zcounter 	( 0 zadr0 --- 0 adrZcount )
        !		( 0 adrZcount --- )
	R@ 		( --- zadr0 )
        Ztaille         ( zadr0 ---adrZtaille ) 
        OFF		( adrZtaille --- )
	R@ 		( --- zadr0 )
        R>              ( zadr0, --- zadr0,zadr0 )
        FreeZadr        ( zadr0,zadr0 --- zadr0,FreeZadr )
        !		( zadr0, FreeZadr --- )
        

;

Une simple lecture de l'évolution de la pile de données suffit pour voir si les outils utilisés sont compatibles avec
les données présentes et vis versa.

Cordialement

Ludwig

[Ludwig1]

Salut,

Il est vraiment surpuissant ce forth pour pouvoir faire pédaler une bibliothèque graphique plus rapidement que l'OpenGL... qui est l'accès direct au matériel...
Bref encore une énormité annoncée de manière péremptoire...

Mis à par qu'on utilise les fonctions de Fastgraf, ça n'a rien à voir avec Forth, tu peux utiliser avec n'importe quel langage.
A ton avis, Fastgraf c'est fait comment ? tu peux lire ici

http://www.fastgraph.com/


Cordialement

Ludwig

[albanxiii]

a b * c c * + a c * b / - c c * a b + / /

oupssseuuuu !!!

edit: oui, la lisibilité est pourrie, mais l'écriture est simple, faut juste pas se tromper à la première écriture

D'accord avec ça. Ce qui est pourri c'est qu'il manque une parenthèse dans l'expression de départ, et qui m'a foutu dedans.

For fun : http://www.mathblog.dk/tools/infix-postfix-converter/

[Forthman]

Tous d'abord je souhaite faire remarquer que nous parlons de machine informatique virtuelle, pas de langage de programmation.

Pas si virtuelle que ça puisqu'il faut utiliser :
- un PC
- sous Windows
- avec Fastgraph (qui coutait 299$ mais visiblement plus en vente)

Comme tu es actif dans le domaine de l'usinage semblerait 'il je vais utiliser des analogie de ce domaine pour décrire la VM.

Je n'ai pas bien compris, pourrais tu me le réexpliquer avec plus de condescendance

C'est bien là ou est le PB, faire le distingo entre les outils et les objets à " usiner".
Les outils sont normalisés et invariant (presque), les objets que l'on fabrique avec, eux évoluent avec le temps.

Il y a 50 ans on usinait avec des outils en acier rapide, aujourd'hui on utilise des plaquettes en carbure
et Il y a 50 ans il n'y avait pas de commande numérique mais ça doit pas être des "outils"

Comme déjà dit, je suis sous Windows 10, je ne connais pas la structure de la VM qui tourne sur Linux.

Comment peux-tu donner un avis objectif sur la portabilité alors ?

Essaye ça
....

Euhh.. faudrait m'expliquer ce que tu veux expliquer parce que là je ne vois pas
(à part démontrer que la VM en question n'a même pas de fonctions simples pour le traitement de chaînes de caractères )

Quelqu'un dit autre chose ?

Comme tu parles toujours d' "objets", je pensais que swiftforth traitait une pile d'objets alors que ce ne sont que des valeurs
32 bits.
J'ai mémoire d'avoir utilisé un forth qui faisait ça, et du coup le mot . (point) servait à afficher aussi bien une valeur qu'une
chaine de caractères. tout comme le mot + permettait d'additionner les deux derniers éléments et si ces derniers étaient
des chaines de caractères, et bien il les concaténait (comme le RPL sur les machines HP en fait)

Je n'utilise pas OpenGL mais Fastgraph ( Ted Gruber jeux vidéos Las Vegas )qui est bien plus rapide
En général pour implémenter une API

cette phase sous entant que c'est par choix, alors qu'en fait non

Mis à par qu'on utilise les fonctions de Fastgraf, ça n'a rien à voir avec Forth, tu peux utiliser avec n'importe quel langage.
A ton avis, Fastgraf c'est fait comment ? tu peux lire ici

Bien vu que fastgraph date au mieux de 2003 (c'est pas moi qui le dit, c'est la date des fichiers) ça m'étonnerait qu'il exploite les accélérations
graphiques d'aujourd'hui ...

Pour le dernier exemple EraseZl, si je remplace le derniers R> par une R@ la description reste valide, mais le mot plantera
car la pile de retour n'aura pas été remise à son état initial.
donc dire qu'il n'y a pas besoin de débugger c'est prendre le problème à l'envers.
C'est parce qu'il n'y a pas de débugger qu'il faut faire sans

[Ludwig1]

Pas si virtuelle que ça puisqu'il faut utiliser :
- un PC
- sous Windows
- avec Fastgraph (qui coutait 299$ mais visiblement plus en vente)

Ben tu interfaces DirectX, ça marche aussi

Comment peux-tu donner un avis objectif sur la portabilité alors ?

Ben ça tourne sur n CPU différentes, et sous n systèmes d'exploitations. Je voulais dire que ne connaissant pas Linux, je ne sais pas comment la VM s'interface avec Linux. puisqu'il faut bien interfacer avec un système d'exploitation. Je n'ai pas de
penchant particulier pour MS, mais il faut admettre que la doc concernant les API et leurs mise en Oeuvre est assez bien faite.
Bien que ce soit majoritairement prévu pour C++, c'est directement exploitable par la VM.

Euhh.. faudrait m'expliquer ce que tu veux expliquer parce que là je ne vois pas
(à part démontrer que la VM en question n'a même pas de fonctions simples pour le traitement de chaînes de caractères )

Ben tu re regardes.
Manipulation de chaines de caractères? au moins 300 " Méthodes, procédures etc... "

Chaine1$ [CHAR] U Scan
BL WORD COUNT BL SKIP -TRAILING etc... donne toi la peine de regarder.

Comme tu parles toujours d' "objets", je pensais que swiftforth traitait une pile d'objets alors que ce ne sont que des valeurs
32 bits.

qui sont des pointeurs sur les objets tu connais? La manipulation d'objet se fais au travers de leurs pointeurs respectifs,
c,à,d, une adresse.

Bien vu que fastgraph date au mieux de 2003 (c'est pas moi qui le dit, c'est la date des fichiers) ça m'étonnerait qu'il exploite les accélérations graphiques d'aujourd'hui ...

Ben tu regardes

Pour le dernier exemple EraseZl, si je remplace le derniers R> par une R@ la description reste valide, mais le mot plantera
car la pile de retour n'aura pas été remise à son état initial.
donc dire qu'il n'y a pas besoin de débugger c'est prendre le problème à l'envers.
C'est parce qu'il n'y a pas de débugger qu'il faut faire sans

bien sur qu'il y a un débugger, il est même en multifenêtrage. Ben oui le mot plantera avec un joli message qui t'informes de
l'erreur afin que tu puisse y remédier.

Comme déjà répété souvent, t'es pas obligé de quoi que ce soit, tu travailles avec les instruments de ton choix
et moi je travailles avec les instruments de mon choix.
Si t'as une question technique je veux bien te répondre.


Cordialement

Ludwig

[Ludwig1]

Par contre ce n'est pas la peine de me dire que la première chose à faire est de claquer 399$ dans swift car déjà comme dit plus haut sous Linux
c'est moche, et que même si j'étais sous windows, je ne mettrai pas une telle somme dans un langage (sauf utilisation pro, et encore)

gforth (qui est quand-même LA référence sous Linux) n'a pas bougé depuis juillet 2014
donc voilà quoi ...

J'allais presque oublier,
La prochaine fois que je verrais Bernd Paysan je lui transmettrai le bonjour de ta part et lui dirai
à quel point tu chantes les louanges de gForth, il sera ravi.

Cordialement

Ludwig

[Forthman]

J'ai re regardé, mais je ne vois pas...
ton code ne fait rien de plus que ce que j'avais écrit vite fait (j'ai changé les noms de mes mots avec les tiens, mais j'ai utilisé ma présentation) :

: N_Au_Carre ( n --- n*n )
\ ----------
\ transforme le sommet de la pile par son carre
  Dup * ;

: AFFICHE_TEST ( n --- )
\ ------------
\ affiche le sommet de la pile et son carre avec un petit texte explicatif
  CR
  ."  Nombre rentré : " DUP . CR
  ." Valeur du carré de ce nombre : " N_Au_Carre . CR ;

Alors bien sûr, on peut avoir envie de définir comme tu l'as fait des mots qui vont contenir le texte à afficher, de mon point de vue, ça sera pratique en cas de traduction
dans une autre langue (tous les textes seraient regroupés dans le fichier, donc plus facile à éditer)
Dans ce cas je serais parti sur un truc plutôt comme ça :

CREATE InputMessage$ ," Nombre rentré : " \ message affiché pour indiquer la valeur entrée sur la pile
CREATE OutputMessage$ ," Valeur du carré de ce nombre : " \ message affiché lors de l'opération

: N_Au_Carre ( n --- n*n )
\ ----------
\ transforme le sommet de la pile par son carre
  Dup * ;

: AFFICHE_TEST ( n --- )
\ ------------
\ affiche le sommet de la pile et son carre avec un petit texte explicatif
  CR
  InputMessage$ COUNT TYPE DUP . CR
  OutputMessage$ COUNT TYPE N_Au_Carre . CR ;

Voire, à vouloir modifier pendant l'utilisation du code on pourrait aussi faire ça :
( Mais ça devient vraiment tordu là )

DEFER InputMessage$ \ message affiché pour indiquer la valeur entrée sur la pile
DEFER OutputMessage$  \ message affiché lors de l'opération

CREATE message1$ ," Nombre rentré : "
CREATE message2$ ," Valeur du carré de ce nombre : "

' message1$ IS InputMessage$
' message2$ IS OutputMessage$

: N_Au_Carre ( n --- n*n )
\ ----------
\ transforme le sommet de la pile par son carre
  Dup * ;

: AFFICHE_TEST ( n --- )
\ ------------
\ affiche le sommet de la pile et son carre avec un petit texte explicatif
  CR
  InputMessage$ COUNT TYPE DUP . CR
  OutputMessage$ COUNT TYPE N_Au_Carre . CR ;

La prochaine fois que je verrais Bernd Paysan je lui transmettrai le bonjour de ta part et lui dirai
à quel point tu chantes les louanges de gForth, il sera ravi.

Si ça t'amuse, mais je n'ai jamais chanté (je n'ai même jamais utilisé gforth) mais il est en tête de liste des forth que l'on trouve sous Linux

[Ludwig1]

Salut,

J'ai re regardé, mais je ne vois pas...
ton code ne fait rien de plus que ce que j'avais écrit vite fait (j'ai changé les noms de mes mots avec les tiens, mais j'ai utilisé ma présentation) :
Alors bien sûr, on peut avoir envie de définir comme tu l'as fait des mots qui vont contenir le texte à afficher, de mon point de vue, ça sera pratique en cas de traduction
dans une autre langue (tous les textes seraient regroupés dans le fichier, donc plus facile à éditer)
Dans ce cas je serais parti sur un truc plutôt comme ça :

Ce que j'ai essayé de te montrer c'est la POO par prototype. Ici le mot String$ est un constructeur

: STRING$        ( n < nom$ > --- ) \ Déclaration d'une chaine de caractères de
                 \ longueur n et de nom nom$.
                 \ USAGE:  255    STRING$  Message$  
                 \ construit une chaine de caractères vide de nom Message$
                 \ et d'une taille max de 255 caractères



        CREATE
                DUP  c, 0 c, H +!
        DOES>
                DUP 1+ c@ >R
                2+ R>
 ;

la séquence comprise entre CREATE et DOES> est ce que l'on appelle le Compile Time c.a.d. ce qui est exécuté lors de la création (enregistrement) dans le dictionnaire.
la séquence comprise entre DOES> et point virgule est ce que l'on appelle le Run Time. Chaque objet (ici chaines de caractères) crée avec le Constructeur STRING$ va hériter de ce Run Time.

Nous pouvons maintenant ( si elles n'existaient pas encore) développer n + 1 Méthodes permettant de faire du traitement
sur les chaines de caractères.
On peut évidement appliquer cette façon de faire à n'importe quelle structure de données y compris les bases de données.


Cordialement

Ludwig

[polo974]

D'accord avec ça. Ce qui est pourri c'est qu'il manque une parenthèse dans l'expression de départ, et qui m'a foutu dedans.
...

taratata (comme dirait scarlette)...
au départ, il y avait toutes les parenthèses.
c'est dans le fil qu'il y a la dernière qui est tombée...

mais au départ, je pensais à une écriture avec a, b et c sur la pile et sans emploi de variables...