RealBasic, ca compile???
- Créateur du sujet SuperCed
- Date de début
Avec RealBasic tu peux créer des applications directement pour OS 9.x, OS X et Windows. Cela génére un executable...si je ne fais pas d'erreur mais cela fait un ptit bout de temps que je n'ai pas utilisé la chose...
Je sais que ca genere un executable, mais il peut tres bien y avoir un runtime dedant... Donc ca ne m'aide pas a savoir si RealBasic compile ou pas.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
Je sais que ca genere un executable, mais il peut tres bien y avoir un runtime dedant... Donc ca ne m'aide pas a savoir si RealBasic compile ou pas.<HR></BLOCKQUOTE>
Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence...
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows.
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.
Je sais que ca genere un executable, mais il peut tres bien y avoir un runtime dedant... Donc ca ne m'aide pas a savoir si RealBasic compile ou pas.<HR></BLOCKQUOTE>
Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence...
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows.
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par HURRICAN:
Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence...
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows.
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.<HR></BLOCKQUOTE>
Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. Ce qui le rend plus lent.
Le code compile, s'est de l'assembleur. Director ne genere pas de l'assembleur mais un fichier binaire que le runtime interprete comme il veut. C'est comme si c'etait du Java, sauf que la machine virtuelle est inclue dans l'executable.
Tu vois la difference?
Si c'est un éxécutable (et RB en génére ...), c'est que le code est compilé. Le runtime n'a rien à voir avec çà.
Ta question est donc plutôt, RealBasic génére t'il un code libre, ou est t-il lié à une licence...
La réponse est simple, il n'existe quasiment plus de langages imposant l'achat d'une licence pour l'éxécution du code. RB n'échappe pas à la règle.
En revanche, et comme la plupart des autres Basic, C, Java ..., il est nécessaire de joindre à l'éxécutable, les bibliothèques de fonctions qui permettent l'éxécution correcte du code, surtout si tu désires que le code tourne également sur plate-forme Windows.
Résumé : Les programmes écrits en RealBasic sont libres de droits, et leur distribution est donc libre. Seul l'auteur a des droits sur ce code généré.<HR></BLOCKQUOTE>
Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. Ce qui le rend plus lent.
Le code compile, s'est de l'assembleur. Director ne genere pas de l'assembleur mais un fichier binaire que le runtime interprete comme il veut. C'est comme si c'etait du Java, sauf que la machine virtuelle est inclue dans l'executable.
Tu vois la difference?
et qu'en est il de Java sous os X ?
est il compilé ou interpreté, ...ou bien un peu des deux ?
et si java est toujours interprete,
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?
est il compilé ou interpreté, ...ou bien un peu des deux ?
et si java est toujours interprete,
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. <HR></BLOCKQUOTE>
Tu ne connais pas la définition d'un exécutable ... Il s'agit forcément d'un programme compilé (C, Basic, Java, Cobol, ...) ou assemblé (assembleur ...). A ne pas confondre avec un 'script éxécutable' (Director ...) par exemple. Quand le mot 'éxécutable' est indiqué seul, il veut dire 'programme objet'.
Non, un executable ne veut pas forcement dire que le code est compilé. Je te donne un exemple, Director cree des executable, mais pourtant, le code n'est pas compile, il est interprete. <HR></BLOCKQUOTE>
Tu ne connais pas la définition d'un exécutable ... Il s'agit forcément d'un programme compilé (C, Basic, Java, Cobol, ...) ou assemblé (assembleur ...). A ne pas confondre avec un 'script éxécutable' (Director ...) par exemple. Quand le mot 'éxécutable' est indiqué seul, il veut dire 'programme objet'.
ok, j'avais alors une mauvaise definition du mot executable. Je vais verifier ce que tu me dis quand meme... on sait jamais...
Je pensais qu'un executable etait seulement un programme qui se lancait quand on double cliquait dessus.
Je pensais qu'un executable etait seulement un programme qui se lancait quand on double cliquait dessus.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par jduffas:
et qu'en est il de Java sous os X ?
est il compilé ou interpreté, ...ou bien un peu des deux ?
et si java est toujours interprete,
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?<HR></BLOCKQUOTE>
Java, c'est toujours du code interprete, a part sur quelques prototypes de Sun... Je ne sais pas si objective C est compile ou interprete, mais je pense qu'il est compile. C'est a verifie. Si je suis dans le vrai, il y a des fortes chances pour que le code Java soit plus lent que le code ObjectiveC, a moins que le compilateur Objective C soit tres mauvais...
et qu'en est il de Java sous os X ?
est il compilé ou interpreté, ...ou bien un peu des deux ?
et si java est toujours interprete,
son integration dans les couches basses du systeme, permet elle une rapidité equivalente entre un programme ecrit en objective C et un programme ecrit en java ?<HR></BLOCKQUOTE>
Java, c'est toujours du code interprete, a part sur quelques prototypes de Sun... Je ne sais pas si objective C est compile ou interprete, mais je pense qu'il est compile. C'est a verifie. Si je suis dans le vrai, il y a des fortes chances pour que le code Java soit plus lent que le code ObjectiveC, a moins que le compilateur Objective C soit tres mauvais...
Pour l'éxécutable tu peux me faire confiance, je suis ingénieur/chef de projet, et je développe depuis 1985 ...
Tu as tort également de croire que Java est toujours interprêté. Java se compile également. Il existe plusieurs types de compilateurs d'ailleurs. Les JIT (Just In Time) compilent à la volée, au moment de l'éxécution. Mais il existe aussi des compilateurs, qui crée des éxécutables au sens propre du terme. Il ne reste plus alors qu'à livrer l'objet, ses classes, ses beans, ... pour pouvoir l'éxécuter.
En revanche tu as raison sur la vitesse. Java n'est pas un foudre de guerre, même s'il a fait des progrès notables. En mode interprêté ou en JIT, il n'a vraiment aucune chance de toute façon ...
Tu as tort également de croire que Java est toujours interprêté. Java se compile également. Il existe plusieurs types de compilateurs d'ailleurs. Les JIT (Just In Time) compilent à la volée, au moment de l'éxécution. Mais il existe aussi des compilateurs, qui crée des éxécutables au sens propre du terme. Il ne reste plus alors qu'à livrer l'objet, ses classes, ses beans, ... pour pouvoir l'éxécuter.
En revanche tu as raison sur la vitesse. Java n'est pas un foudre de guerre, même s'il a fait des progrès notables. En mode interprêté ou en JIT, il n'a vraiment aucune chance de toute façon ...
Oui, c'est vrai, Java peut etre compile a la vole, j'avais oublie cela. Par contre, je savais pas qu'il pouvait etre compile totalement, comme du C.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
Oui, c'est vrai, Java peut etre compile a la vole, j'avais oublie cela. Par contre, je savais pas qu'il pouvait etre compile totalement, comme du C.<HR></BLOCKQUOTE>
Faux. Java n'est pas et ne sera pas compilé totalement comme du C. Cela voudrait dire que l'executable qui résulterait de la compilation serait du code machine donc directement comprehensible par le processeur. Ce n'est pas le cas puisque Java necessite une JVM.
Pour ce qui est de RealBasic. Je suis quasiment certain que l'executable qui resulte de la compilation de ton projet est en fait un "run-time" qui compile ton code à son execution. 90 % certain.
Oui, c'est vrai, Java peut etre compile a la vole, j'avais oublie cela. Par contre, je savais pas qu'il pouvait etre compile totalement, comme du C.<HR></BLOCKQUOTE>
Faux. Java n'est pas et ne sera pas compilé totalement comme du C. Cela voudrait dire que l'executable qui résulterait de la compilation serait du code machine donc directement comprehensible par le processeur. Ce n'est pas le cas puisque Java necessite une JVM.
Pour ce qui est de RealBasic. Je suis quasiment certain que l'executable qui resulte de la compilation de ton projet est en fait un "run-time" qui compile ton code à son execution. 90 % certain.
Pour Java, si, il existe justement des compilo qui transforme ton code Java en assembleur, et la, pas besoin de VM.
Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?
Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
Pour Java, si, il existe justement des compilo qui transforme ton code Java en assembleur, et la, pas besoin de VM.<HR></BLOCKQUOTE>
Désolé, mais j'ai du louper un épisode là !
La seule façon de faire de que tu dis, constituerait à implanter une "puce" java dans la machine (ce qui a été envisagé par Sun, mais jamais mis en oeuvre).
Sinon point de salut. La particularité INTRINSEQUE de Java est d'etre un langage interprété, c'est donc necessairement la JVM qui se charge de ça....Si tu doutes, tu as le site de sun
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?[/QB]<HR></BLOCKQUOTE>
C'est un runtime, c'est certain. Sinon le langage utilisé n'est pas du basic.
Pour Java, si, il existe justement des compilo qui transforme ton code Java en assembleur, et la, pas besoin de VM.<HR></BLOCKQUOTE>
Désolé, mais j'ai du louper un épisode là !
La seule façon de faire de que tu dis, constituerait à implanter une "puce" java dans la machine (ce qui a été envisagé par Sun, mais jamais mis en oeuvre).
Sinon point de salut. La particularité INTRINSEQUE de Java est d'etre un langage interprété, c'est donc necessairement la JVM qui se charge de ça....Si tu doutes, tu as le site de sun
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Pour RealBasic, tu crois vraiment qu'il s'agit d'un compilateur a la vole??? Moi j'aurais pas pense a ca, j'aurais pense que soit, c'etait compile, soit le runtime interpretait les commandes du script RealBasic. Ca me semble bizare qu'ils aient fait un compilateur a la vole vu la difficulte de realisation de ce genre de programme. Pourquoi se seraient-ils embetes a faire ca?[/QB]<HR></BLOCKQUOTE>
C'est un runtime, c'est certain. Sinon le langage utilisé n'est pas du basic.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Cocoa:
Alors si cela existe vraiment du java non-interpreté, cela retire d'une part sa capacité de portabilité, et d'autre part, ce n'est surement pas Sun qui supporte ça. Pour ce qui est de la puce, elle est effectivement operationnelle, mais n'est absolument pas distribuée sur des stations grand-public...Pour des raisons évidentes de stratégies de la part de Microsoft par exemple.....
Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.<HR></BLOCKQUOTE>
En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.
C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)
Alors si cela existe vraiment du java non-interpreté, cela retire d'une part sa capacité de portabilité, et d'autre part, ce n'est surement pas Sun qui supporte ça. Pour ce qui est de la puce, elle est effectivement operationnelle, mais n'est absolument pas distribuée sur des stations grand-public...Pour des raisons évidentes de stratégies de la part de Microsoft par exemple.....
Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.<HR></BLOCKQUOTE>
En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.
C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par Cocoa:
Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.<HR></BLOCKQUOTE>
J'ai été visité le site de RealBasic...J'y avais pas mis le pied depuis des lustres...Il semble qu'officiellement sur la version 3.5, ils affirment que l'application resultant de la compilation soit integralement compilée sans "run-time". Cela me semble louche, car je ne vois pas techniquement comment ils peuvent faire.
Un runtime est fait pour compiler du code à la volée lors de son execution. En clair, la partie executable de ton application "realbasic" est en fait simplement composée du runtime (et eventuellement des composants compilés de l'interface, mais je n'en suis pas certain). Le code Basic lui sera inévitablement compilé seulement et imperativement lors de l'execution du run-time.<HR></BLOCKQUOTE>
J'ai été visité le site de RealBasic...J'y avais pas mis le pied depuis des lustres...Il semble qu'officiellement sur la version 3.5, ils affirment que l'application resultant de la compilation soit integralement compilée sans "run-time". Cela me semble louche, car je ne vois pas techniquement comment ils peuvent faire.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>Posté à l'origine par SuperCed:
En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.<HR></BLOCKQUOTE>
Je récapitule sur ce débat interessant
La JVM, inclue un JIT (Just In Time compiler). Le JIT est chargé de traduire le code JVM d'un classe directement en code natif, et ce dès la première utilisation d'une classe du programme.
Cette phase de "traduction" prend certes un peu de temps, mais une fois celle-ci effectuée, et ce jusqu'à la fin de l'exécution du programme, plus aucune traduction de code (sur la classe considéré) ne sera refaite (ce sont tes fichiers .class que tu retrouves apres un javac sous le terminal). Cette technique améliore considérablement la rapidité d'exécution des programmes, bien qu'une phase de traduction persiste.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)<HR></BLOCKQUOTE>
J'ai pas bien compris le rapport entre un émulateur et une compilation de code
En effet, ca retire une part des capacites de portabilite. Il n'y a pas trop d'interet.
D'autre part, un runtime ne fait pas de compilation a la volee, il ne fait qu'interpreter. Renseigne toi la dessus, et reviens me voir sur le forum.
Certaines machines virtuelles Java interpretent le code, d'autres font une compilation a la volee ce qui les rendent plus rapide.<HR></BLOCKQUOTE>
Je récapitule sur ce débat interessant
La JVM, inclue un JIT (Just In Time compiler). Le JIT est chargé de traduire le code JVM d'un classe directement en code natif, et ce dès la première utilisation d'une classe du programme.
Cette phase de "traduction" prend certes un peu de temps, mais une fois celle-ci effectuée, et ce jusqu'à la fin de l'exécution du programme, plus aucune traduction de code (sur la classe considéré) ne sera refaite (ce sont tes fichiers .class que tu retrouves apres un javac sous le terminal). Cette technique améliore considérablement la rapidité d'exécution des programmes, bien qu'une phase de traduction persiste.
<BLOCKQUOTE><font size="1" face="Verdana, Geneva">quote:</font><HR>C'est comme un emulateur, il y en a 3 types :
ceux qui compilent directement, ceux qui interpretent, et ceux qui font une compilation a la volee. Ces derniers sont souvent les plus rapides, mais par contre, c'est beaucoup plus chaud a programmer.
Renseigne toi un peu la dessus, et fais moi un rapport detaille a ton retour. ;-)<HR></BLOCKQUOTE>
J'ai pas bien compris le rapport entre un émulateur et une compilation de code
eh bien, un emulateur lit un langage. Un compilateur et un interpreteur aussi, ca marche de la meme facon. Tu as deja etudie la theorie du langage?
