compilation à la volée

On 5 sep, 12:23, zwim <zwim@f_ree.fr> wrote:

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant

"utiliser du code C écrit par l'utilisateur"

En principe, las réponse est sans appel. C'est non. Un 'utilisateur'
ne connait pas le C !

l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qu i
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

Ca veut dire que l'utilisateur doit maitriser le C et qu'il a un
compilateur / linker sur sa machine pour produire une application à
partir de la formule... Il va falloir gérer les erreurs de syntaxe de
l'utilisateur... De plus, il va falloir écrire un mécanisme assez
compliqué pour passer les paramètres à l'application externe et
récupérer les résultats...

Je ne sais pas si ça vaut le coup...

Un parseur d'expression mathématique n'est pas si complexe que ça.
L'usage d'outils comme Lex et Yacc (ou Flex et Bison en version GNU),
peut aider...

Le Sun, 6 Sep 2009 00:24:54 -0700 (PDT)
-ed- a écrit

On 5 sep, 12:23, zwim <zwim@f_ree.fr> wrote:

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant

"utiliser du code C écrit par l'utilisateur"

En principe, las réponse est sans appel. C'est non. Un 'utilisateur'
ne connait pas le C !

dans mon cas ça n'a pas d'importance, les utilisateurs sont +/- des
ingés.

l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

Ca veut dire que l'utilisateur doit maitriser le C et qu'il a un
compilateur / linker sur sa machine pour produire une application à
partir de la formule... Il va falloir gérer les erreurs de syntaxe de
l'utilisateur... De plus, il va falloir écrire un mécanisme assez
compliqué pour passer les paramètres à l'application externe et
récupérer les résultats...

les erreurs pas de soucis, si ça compile pas msg d'erreur, et si
l'utilisateur écrit un roman, un virus, un gestionnaire de DB, au lieu
d'une fonction, c'est son pb.

d'où l'idée de faire appel à tcc qui est un compilo très petit, sur
linux le pb ne se poserait pas, j'appelle gcc et le tour est joué,
mais sous windows...

c'est pourquoi aussi un appel à libtcc qui ne fait pas intervenir
d'appli externe a ma préférence.

Un parseur d'expression mathématique n'est pas si complexe que ça.
L'usage d'outils comme Lex et Yacc (ou Flex et Bison en version GNU),
peut aider...

le soucis n'est pas là, écrire un parseur je l'ai déjà fait fût un
temps, mais il y a trop d'inconvénients et c'est largement plus lourd
à écrire qu'un appel de command line...

pas de possibilité d'écrire une fonction par morceaux par exemple,
alors qu'en C, un simple if ( ) et ça roule, on peut aussi faire des
calculs intermédiaires facilement, et aussi faire des sommes dans des
boucles for.

si on veut accorder les mêmes possibilités pour un langage
utilisateur, ça devient vite une usine à gaz, donc autant écrire du
code C directement. L'effort pour l'utilisateur est minime à mon point
de vue.

enfin ces fonctions servent à des calculs intensifs derrière, c'est
pourquoi, évaluer ensuite la valeur de l'arbre est très lent, donc
pénalisant par rapport à une fonction compilée !

Je ne sais pas si ça vaut le coup...

Bref, on a discuté de mon usecase ici, mais moins de la question
initiale, la mise en oeuvre pratique...




--
zwim.
Rien n'est impossible que la mesure de la volonté humaine...

In article <32e4a55tqsatonffrkh27ti0ap921ls9a4@4ax.com>,
zwim <zwim@f_ree.fr> wrote:

Bonjour,

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant
l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

Bof, c'est tres relatif. A part pour des programmes jouets, le plus
souvent, ca marche mieux avec un parseur d'expressions. Deja, c'est bien
plus rapide cote interactions (la compilation est quand meme vachement
lente, donc il faut que tu utilises plein de fois la fonction pour que
ca batte un interpreteur). Ensuite, ca vaut souvent le coup d'avoir un
interpreteur legerement different du C pour quelque chose que tu montres
a ton utilisateur.

Le mieux a faire, c'est bien sur d'essayer les deux solutions, de voir
laquelle est la plus pratique et la plus efficace.

Comme mentionne dans un message cousin, refabriquer un parseur d'expressions
arithmetiques n'a rien de bine complique si on utilise les bons outils...

On 05/09/2009 12:23, zwim wrote:

Bonjour,

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant
l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Votre opinion/retour d'expérience sur ce sujet ?
Est-ce que tcc est la bonne méthode, en connaissez vous d'autres ?
Quid de lib dynamique -vs- code relocatable en mémoire (i.e. tcc -o
-shared versus libtcc api) ?

inutile de faire coder du C ou rajouter une couche de langage de plus.
IL faut générer le code exécutable à la volée tout en en permettant
éventuellement la sauvegarde pour réutilisation ultérieuse.

Pour cela, il existe quatre façons de procéder. La première, c'est de
générer le code d'une machine virtuelle quelconque qui produit ensuite
du code exécutable, l'avantage est que l'appli est indépendante de la
plateforme d'exploitation. La deuxième est d'utiliser un générateur de
code à la volée tel que
http://www.gnu.org/software/lightning/manual/html_node/Overview.html.

La troisième façon, la plus sophistiquée consiste à utiliser un
générateur de code piloté par les spécification de la machine-cible tel
que celui-ci http://www.cs.tufts.edu/~nr/toolkit/

La quatrième façon, la plus simple est d'utiliser un interpréteur forth
embarqué muni d'un vocabulaire assembleur.

Pour ma part, après avoir essayé quasiment tout, j'ai utilisé un
générateur de code piloté avec insertion du code à la volée.

On 05/09/2009 12:23, zwim wrote:

Bonjour,

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant
l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Votre opinion/retour d'expérience sur ce sujet ?
Est-ce que tcc est la bonne méthode, en connaissez vous d'autres ?
Quid de lib dynamique -vs- code relocatable en mémoire (i.e. tcc -o
-shared versus libtcc api) ?

> J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant
> l'execution d'un programme, pour permettre par exemple la définition
> de fonctions sans avoir recours à "yet another user language"...
>
> Prenons un usecase basique genre gnuplot.
> L'utilisateur entre une fonction math, et le programme trace son
> graphe.
>
> Au lieu de faire appel à un langage utilisateur qui va conduire à
> parser une chaine, et interpréter un arbre binaire arithmétique ce qui
> peut être assez lent, la solution d'écrire la fonction directement en
> C et de la compiler à la volée me semble plus pratique.
>
> J'ai pour l'instant lu des examples avec TCC qui permet de générer une
> lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
> récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
> en plus c'est sous LGPL.
>
> Votre opinion/retour d'expérience sur ce sujet ?
> Est-ce que tcc est la bonne méthode, en connaissez vous d'autres ?
> Quid de lib dynamique -vs- code relocatable en mémoire (i.e. tcc -o
> -shared versus libtcc api) ?
>


inutile de faire coder du C ou rajouter une couche de langage de plus.
IL faut générer le code exécutable à la volée tout en en permettant
éventuellement la sauvegarde pour réutilisation ultérieuse.

Pour cela, il existe quatre façons de procéder. La première, c'est de
générer le code d'une machine virtuelle quelconque qui produit ensuite
du code exécutable, l'avantage est que l'appli est indépendante de la
plateforme d'exploitation. La deuxième est d'utiliser un générateur de
code à la volée tel que
http://www.gnu.org/software/lightning/manual/html_node/Overview.html.

La troisième façon, la plus sophistiquée consiste à utiliser un
générateur de code piloté par les spécification de la machine-cible tel
que celui-ci http://www.cs.tufts.edu/~nr/toolkit/

La quatrième façon, la plus simple est d'utiliser un interpréteur forth
embarqué muni d'un vocabulaire assembleur.

Pour ma part, après avoir essayé quasiment tout, j'ai utilisé un
générateur de code piloté

Le 05-09-2009, zwim <zwim@f_ree.fr> a écrit :

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Ne peux tu pas sinon opter pour un modèle client/serveur
avec communication socket ? C'est moins sexy, mais ça marche bien
aussi.
L'utilisateur écrits toujours son code C, il se le compile,
il ajoute de #include qui lance le serveur, et voilà.
Aucune techno évoluée, mais pas long à faire.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0

Le Mon, 07 Sep 2009 09:58:09 +0200
achour a écrit

On 05/09/2009 12:23, zwim wrote:

Bonjour,

J'aimerais pouvoir utiliser du code C écrit par l'utilisateur pendant
l'execution d'un programme, pour permettre par exemple la définition
de fonctions sans avoir recours à "yet another user language"...

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Votre opinion/retour d'expérience sur ce sujet ?
Est-ce que tcc est la bonne méthode, en connaissez vous d'autres ?
Quid de lib dynamique -vs- code relocatable en mémoire (i.e. tcc -o
-shared versus libtcc api) ?

inutile de faire coder du C ou rajouter une couche de langage de plus.
IL faut générer le code exécutable à la volée tout en en permettant
éventuellement la sauvegarde pour réutilisation ultérieuse.

Pour cela, il existe quatre façons de procéder. La première, c'est de
générer le code d'une machine virtuelle quelconque qui produit ensuite
du code exécutable, l'avantage est que l'appli est indépendante de la
plateforme d'exploitation. La deuxième est d'utiliser un générateur de
code à la volée tel que
http://www.gnu.org/software/lightning/manual/html_node/Overview.html.

La troisième façon, la plus sophistiquée consiste à utiliser un
générateur de code piloté par les spécification de la machine-cible tel
que celui-ci http://www.cs.tufts.edu/~nr/toolkit/

La quatrième façon, la plus simple est d'utiliser un interpréteur forth
embarqué muni d'un vocabulaire assembleur.

Pour ma part, après avoir essayé quasiment tout, j'ai utilisé un
générateur de code piloté avec insertion du code à la volée.

Ah, me voilà avec de la lecture en perspective.

Pour le moment je vais commencer avec libtcc et voir ce que ça donne,
ça m'a l'air facile à faire, les liens présentés ci-dessus sont
interessants, mais semblent bigrement difficiles à mettre en branle
d'un claquement de doigts.

Néanmoins, je garde cela sous le coude, pour amélioration ultérieure
(tout est question de temps dispo...)


--
zwim.
Rien n'est impossible que la mesure de la volonté humaine...

Le Mon, 7 Sep 2009 09:19:21 +0000 (UTC)
Marc Boyer a écrit

Le 05-09-2009, zwim <zwim@f_ree.fr> a écrit :

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Ne peux tu pas sinon opter pour un modèle client/serveur
avec communication socket ? C'est moins sexy, mais ça marche bien
aussi.
L'utilisateur écrits toujours son code C, il se le compile,
il ajoute de #include qui lance le serveur, et voilà.
Aucune techno évoluée, mais pas long à faire.

yep, mais je voulais justement cacher cet aspect compilation à
l'utilisateur.
si l'utilisateur est capable de compiler facilement, autant qu'il
recompile directement l'appli finale avec ses modifs...


--
zwim.
Rien n'est impossible que la mesure de la volonté humaine...

Le 07-09-2009, zwim <zwim@f_ree.fr> a écrit :

Le Mon, 7 Sep 2009 09:19:21 +0000 (UTC)
Marc Boyer a écrit

Le 05-09-2009, zwim <zwim@f_ree.fr> a écrit :

Prenons un usecase basique genre gnuplot.
L'utilisateur entre une fonction math, et le programme trace son
graphe.

Au lieu de faire appel à un langage utilisateur qui va conduire à
parser une chaine, et interpréter un arbre binaire arithmétique ce qui
peut être assez lent, la solution d'écrire la fonction directement en
C et de la compiler à la volée me semble plus pratique.

J'ai pour l'instant lu des examples avec TCC qui permet de générer une
lib dynamique, ou même LIBTCC qui permet de le faire en mémoire et de
récupérer les symboles via tcc_get_symbol( ), ça à l'air prometteur et
en plus c'est sous LGPL.

Ne peux tu pas sinon opter pour un modèle client/serveur
avec communication socket ? C'est moins sexy, mais ça marche bien
aussi.
L'utilisateur écrits toujours son code C, il se le compile,
il ajoute de #include qui lance le serveur, et voilà.
Aucune techno évoluée, mais pas long à faire.

yep, mais je voulais justement cacher cet aspect compilation à
l'utilisateur.

Ben, un utilisateur capable de coder en C, je le supposais
capable d'accepter la compilation.
D'autant qu'avec tcc, il faudra aussi compiler, non ?

si l'utilisateur est capable de compiler facilement, autant qu'il
recompile directement l'appli finale avec ses modifs...

Ben, ça dépend du contexte. Tu parlais de gnuplot non ? Je ne me
vois pas recompiler tout gnuplot à chaque définition de courbe.

Marc Boyer
--
En prenant aux 10% des francais les plus riches 12% de leurs revenus,
on pourrait doubler les revenus des 10% les plus pauvres.
http://www.inegalites.fr/spip.php?article1&id_mot0