2009-12-29 5 views

Répondre

2

Pas avec l'interpréteur IRM, non.

Certaines machines virtuelles plus récentes sont en cours d'utilisation là où elles sont sur la table, mais elles ne sont pas largement utilisées (ou même prêtes à être utilisées) à ce stade.

3

Bien que la machine virtuelle 1.9 YARV de Ruby soit un compilateur de code octet, je ne crois pas qu'elle puisse vider le code octet sur le disque. Vous pourriez vouloir regarder le compilateur alternatif, Rubinius, je crois qu'il a cette capacité. Vous devriez noter cependant que les fichiers pyc de byte-code (et j'imagine l'équivalent de ruby) peuvent être assez facilement "décompilés".

38

J'ai écrit un much more detailed answer to this question dans la question "Can Ruby, PHP, or Perl create a pre-compiled file for the code like Python?"

La réponse est: cela dépend. Le Ruby Le langage ne prévoit pas de compilation en bytecode et/ou en exécution de bytecode. Il n'a également aucune spécification d'un format de bytecode. La raison en est simple: il serait beaucoup trop restrictif pour les implémenteurs de langage s'ils étaient forcés d'utiliser un format de bytecode spécifique, voire même des bytecodes. Par exemple, XRuby et JRuby compilent au bytecode JVM, Ruby.NET et IronRuby compilent au bytecode CIL, Cardinal compile au PAST, SmallRuby compile au bytecode de Smalltalk/X, MagLev compile au bytecode de GemStone/S. Pour toutes ces implémentations, il serait stupide d'utiliser un autre format de bytecode que celui utilisé actuellement, car tout leur point est interopérable avec d'autres implémentations de langage qui utilisent le même format de bytecode. Simlar pour MacRuby: il compile en code natif et non en code-bytecode. Encore une fois, utiliser bytecode serait stupide, puisque l'un des objectifs est de lancer Ruby sur l'iPhone, ce qui nécessite à peu près du code natif.

Et bien sûr, il y a l'IRM, qui est un interpréteur de script AST-walking pur et qui n'a donc pas de format bytecode.

Cela étant dit, il sont quelques Ruby Implémentations qui permettent le chargement et compilant à partir bytecode. Rubinius le permet, par exemple. (En effet, il a d'avoir cette fonctionnalité depuis son compilateur Ruby est écrit en Ruby, et donc le compilateur doit être compilé pour Rubinius bytecode en premier lieu, afin de résoudre le Catch-22.)

YARV peut également enregistrer et charge le bytecode, bien que la fonctionnalité de chargement soit actuellement désactivée jusqu'à ce qu'un vérificateur de bytecode soit implémenté qui empêche les utilisateurs de charger le bytecode manipulé qui pourrait planter ou autrement subvertir l'interpréteur. Mais, bien sûr, ces deux formats ont leurs propres formats de bytecode et ne se comprennent pas (ni ceux de tinyrb ou de RubyGoLightly ou ...) De plus, aucun de ces formats n'est compris par une JVM ou un CLR et vice versa. versa. Cependant, comme Mark le fait remarquer, vous pouvez toujours désosser le code byte, surtout dans des cas comme CPython, PyPy, Rubinius, YARV, tinyrb, RubyGoLightly, où le format bytecode était spécifiquement conçu pour être très proche de la langue source.

En général, il est simplement impossible de protéger le code de cette façon. La raison est simple: vous voulez que la machine puisse exécuter le code. (Sinon, à quoi cela sert-il de l'écrire en premier lieu?) Cependant, afin d'exécuter le code, la machine doit comprendre le code. Puisque les machines sont beaucoup plus stupides que les humains, il s'ensuit que tout code qui peut être compris par une machine peut tout aussi bien être compris par un humain, peu importe que ce code soit sous forme source, bytecode, assembly, code natif ou jeu de cartes perforées.

Il n'y a qu'une seule solution technique réalisable: si vous contrôlez le pipeline d'exécution toute , à savoir construire votre propre CPU, votre ordinateur, votre propre système d'exploitation, votre propre compilateur, votre propre interprète, et ainsi de suite et l'utilisation cryptographie forte pour protéger tous ceux, puis et seulement puis pourrait vous pouvez protéger votre code. Cependant, comme par exemple Microsoft a découvert à la dure avec la XBox 360, même en faisant tout cela et en embauchant certains des cryptographes et mathématiciens les plus intelligents de la planète, ne garantit pas le succès.

La seule vraie solution est pas une technique mais social: dès que vous avez écrit votre code, il est automatiquement entièrement protégé par droit d'auteur, sans que vous ayez à faire une seule chose. C'est tout. Votre code est protégé.

+0

Y at-il un impact performace/coût associé à aucun octet génération de code? –

+0

@ Myth17: Théoriquement oui, mais en pratique, c'est presque complètement négligeable. –

+0

Running Ruby sur l'iPhone n'est pas l'un des objectifs de MacRuby - D'où le nom ** Mac ** Ruby. Pour le développement d'iOS, il y a [RubyMotion] (http://www.rubymotion.com/), qui est développé par plusieurs des mêmes personnes. – anthropomorphic

0

Si vous utilisez JRuby, vous pouvez compiler votre code Ruby dans les fichiers de Java (y compris vos trucs Rails) pour les exécuter avec (ouvert) JDK hors de la boîte!

Vous pouvez même compilez vos trucs complète dans un fichier .war pour le déployer sur Apache Tomcat ou Jboss avec un outil appelé « fauvette »

https://rubygems.org/gems/warbler/