Tu peux compiler du Python.
Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).
Mais on s'en fout. Ce que dis patrick_g c'est qu'utiliser un binaire issue de ses langages serait infinement meilleur que passé par un bytecode lourdingue.
Sans parler de l'embarqué.
En effet, les distributions dans l'embarqué sont uniquement fait en source pour n'utiliser que les fonctions utilisé (cf la compilation de busybox). Utiliser un VM pour un petit système... Tu auras eu le mérite de me faire rire.
Un truc qui exécute du code directement depuis une représentation intermédiaire ? Perl fait ça depuis le début mais je pense qu'il ne voulait ça pour simplifier le portage.
Les compilos fonctionnent aussi comme ça avec génération de code au lieu de l'exécution direct.
Une VM au sens de C#, JVM c'est un environnement d'exécution dynamique qui relit du bytecode pré-compilé. On en est loin dans le cas de Perl, ou de python.
Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
Ah, et sinon, tu ne réponds pas à toutes ces interrogations.
En effet, je n'ai pris qu'un exemple puisque la réponse est toujours la même : La VM n'apporte rien la dessus. C'est pas le programme qui décide du layout mémoire, fichier ou réseau mais les spec, et tout cela peut se simplifier par une bonne gestion par lib.
Concernant les autre point comme le 64 bits, cela se règle par recompilation.
Oui, c'est un problème.
il faudrait lire les liens que tu donnes...
Why is endianness so important? Suppose you are storing integer values to a file, and you send the file to a machine that uses the opposite endianness as it reads in the value. This causes problems because of endianness; you'll read in reversed values that won't make sense.
Donc, 1) cela se règle en lib 2) si tu décides d'écrire du big endian et que relis en little tu aura des soucis VM ou pas VM.
Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.
Et en quoi une lib ne fournit pas d''abstraction ?
Une VM facilite aussi la création de nouveaux langages en proposant de base tous ces outils.
Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
endian/big endian ne pose problème qu'avec les layout de fichier. Il suffit d'utiliser la bonne class de gestion du soucis dans le langage en question, ce n'est pas la VM qui fournis ça !
C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
A chaque fois que j'ai du le faire (ok, cela remonte à qq temps), c'était totalement incomplet (par exemple pas de description des paramètres d'une fonction)
La France a très peu de PME par rapport à l'Allemagne.
Croire que virer en France est complexe est faux, c'est juste long pour virer beaucoup de monde, mais pour virer moins de 9 personnes, cela peut être très rapide.
De plus, il y a aujourd'hui le principe de séparation à l'amiable si il y a accord des 2 parties (avec chômage, donc).
Tu peux pas virer quelqu'un juste parce qu'il est mauvais.
'fin si, tu peux.
Ca va te prendre 1 an, des tonnes de paperasses, des eventuelles suites au prud'hommes etc.
Tu as un exemple ? 1 an pour virer quelqu'un ayant une _vrai_ faute ?
Et au lieu d'autoriser tous les ordres possible, cela n'est pas possible de trouver le "bon" ordre, cela doit limiter la taille des recherches pour le linker.
Non, c'est pas automatique. Si tu refuses la reconduction, le truc normal c'est le CDI. Eux ont le choix de mettre fin à ta période d'essais ou te garder.
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Tu peux interpréter du C# ou du Java (ce dernier a d'ailleur été conçu dans cet optique initialement).
Mais on s'en fout. Ce que dis patrick_g c'est qu'utiliser un binaire issue de ses langages serait infinement meilleur que passé par un bytecode lourdingue.
Sans parler de l'embarqué.
En effet, les distributions dans l'embarqué sont uniquement fait en source pour n'utiliser que les fonctions utilisé (cf la compilation de busybox). Utiliser un VM pour un petit système... Tu auras eu le mérite de me faire rire.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
Un truc qui exécute du code directement depuis une représentation intermédiaire ? Perl fait ça depuis le début mais je pense qu'il ne voulait ça pour simplifier le portage.
Les compilos fonctionnent aussi comme ça avec génération de code au lieu de l'exécution direct.
Une VM au sens de C#, JVM c'est un environnement d'exécution dynamique qui relit du bytecode pré-compilé. On en est loin dans le cas de Perl, ou de python.
Cela dis il reste cette énorme lourdeur de traduction à la volé des instructions intermédiaires.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 3.
Le reste n'est que technique différente d'interprétation.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 0.
Tu fais le singe qui préfère la voiture rouge...
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
En effet, je n'ai pris qu'un exemple puisque la réponse est toujours la même : La VM n'apporte rien la dessus. C'est pas le programme qui décide du layout mémoire, fichier ou réseau mais les spec, et tout cela peut se simplifier par une bonne gestion par lib.
Concernant les autre point comme le 64 bits, cela se règle par recompilation.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 1.
il faudrait lire les liens que tu donnes...
Why is endianness so important? Suppose you are storing integer values to a file, and you send the file to a machine that uses the opposite endianness as it reads in the value. This causes problems because of endianness; you'll read in reversed values that won't make sense.
Donc, 1) cela se règle en lib 2) si tu décides d'écrire du big endian et que relis en little tu aura des soucis VM ou pas VM.
Et ? Je parle d'abstraction, dessous y'a du code natif et les threads de l'OS, c'est bien le but.
Et en quoi une lib ne fournit pas d''abstraction ?
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 5.
Pas plus qu'un backend de compilateur avec un langage inteermédiaire (llvm ?)
C'est aussi faire abstraction des incompatibilités de la machine qui peut casser mon soft en C recompilé : 32 vs 64 bits, litle-big endian, etc.
endian/big endian ne pose problème qu'avec les layout de fichier. Il suffit d'utiliser la bonne class de gestion du soucis dans le langage en question, ce n'est pas la VM qui fournis ça !
C'est aussi faire abstraction des incompatibilités de l'OS : gestion des threads notamment.
Si tes threads n'étaient géré que par la VM tu aurais de gros soucis de perf....
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à -1.
mmh je serais curieux de voir ça.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 8.
"La première sécurité est la liberté"
[^] # Re: Merci à tous pour toutes les informations
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 3.
je pense que c'est celui-ci qui augmente les perfs.
D'après mes derniers essais, -pipe ne sert à rien du tout (surtout si cela provoque un swap) car les buffers disques prennent le relais.
"La première sécurité est la liberté"
[^] # Re: Pourquoi Mono ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Utiliser Mono sans peur. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: Ils font déjà pas mal de coup de pute
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chomage partiel, Syntec et SSII. Évalué à 5.
Croire que virer en France est complexe est faux, c'est juste long pour virer beaucoup de monde, mais pour virer moins de 9 personnes, cela peut être très rapide.
De plus, il y a aujourd'hui le principe de séparation à l'amiable si il y a accord des 2 parties (avec chômage, donc).
Tu peux pas virer quelqu'un juste parce qu'il est mauvais.
'fin si, tu peux.
Ca va te prendre 1 an, des tonnes de paperasses, des eventuelles suites au prud'hommes etc.
Tu as un exemple ? 1 an pour virer quelqu'un ayant une _vrai_ faute ?
"La première sécurité est la liberté"
[^] # Re: Bibliothèques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 2.
Les outils pour jouer avec les symboles sont souvent nm et objdump, je crois que cela fait parti des binutils.
"La première sécurité est la liberté"
[^] # Re: Bibliothèques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Tuyaux et compilation parallèle ?
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: ...
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 2.
"La première sécurité est la liberté"
[^] # Re: Bibliothèques
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 6.
"La première sécurité est la liberté"
[^] # Re: .
Posté par Nicolas Boulay (site web personnel) . En réponse au journal GCC lent. Évalué à 3.
"La première sécurité est la liberté"
# Vaste
Posté par Nicolas Boulay (site web personnel) . En réponse au message cherche informaticien qui aime la photo!. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Ils font déjà pas mal de coup de pute
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chomage partiel, Syntec et SSII. Évalué à 4.
"La première sécurité est la liberté"
[^] # Re: Ils font déjà pas mal de coup de pute
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chomage partiel, Syntec et SSII. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Ils font déjà pas mal de coup de pute
Posté par Nicolas Boulay (site web personnel) . En réponse au journal Chomage partiel, Syntec et SSII. Évalué à 3.
"La première sécurité est la liberté"
[^] # Re: Super un nouveau langage
Posté par Nicolas Boulay (site web personnel) . En réponse à la dépêche Le language de programmation ooc sorti en version 0.2. Évalué à 2.
"La première sécurité est la liberté"