Forum Programmation.ruby Mais ils sont fous

Posté par yellowiscool le 04 août 2010 à 02:04.

Étiquettes :

août

2010

Après une légère mise à jour sur une debian instable, une application ruby on rails ne fonctionnait plus du tout.

En effet, il manquait un fichier VERSION.yml du module memcache.

Ce qui est bien avec le ruby, c'est que c'est un langage interprété, donc lent, mais cela permet de le modifier en temps réel.

J'ai donc regardé à quoi servait ce fichier.

Ce fichier est un fichier yaml, qui contient un numéro de version. C'est tout.

J'ai passé la constantes du numéro de version à 42.42.42, et l'application rails est retombé en marche.

En gros, il est chargé un fichier, qui est ensuite parsé en yaml, et 3 concaténations plus tard, on obtient un numéro de version qui sert à rien…

J'espère que c'est pas partout pareil dans le ruby.

# …

Posté par yellowiscool le 04 août 2010 à 02:08. Évalué à 2.

Ça sert à rien, mais qu'est-ce que ça fait du bien de l'écrire.

En plus, l'application rails qui était en panne était mon blog. D'habitude, j'écris sur mon blog, mais c'était urgent…
Envoyé depuis mon lapin.
- [^] # Re: …
  
  Posté par bibitte le 04 août 2010 à 20:11. Évalué à 4.
  
  En même temps si tu utilise un debian instable pour ton blog c'est le genre de chose aux quels il faut s'attendre.
  
  L'instable n'est par forcement instable d'un point de vue bug c'est juste que les version de paquet ne sont pas du tout stables, c'est une version de dev (SID veux dire "still in development") donc t'as un truc assez à jour d'un point de vue fraicheur mais avec quelques ratés dans le packaging ...
  
  Dans le temps ou j'utilisai la SID ce qui m'arrivait souvent c'était des dépendances cassées, une mise à jour d'un paquet cassait un dépendance d'une autre ou alors le paquet d'un programme était mis à jour mais pas le paquet data qui va avec du coup il ne voulait plus s'installer, bref les joies de l'instable!!
  
  Bref pour un blog ou un truc qui doit tourner 24h24 vaux mieux pas mettre une sid ou alors c'est jouer a la roulette russe a chaque MAJ
  - [^] # Re: …
    
    Posté par yellowiscool le 04 août 2010 à 21:37. Évalué à 2.
    
    C'est une testing pour être précis, et les problèmes arrivent très rarement, et jusqu'à présent, seul postgresql et les trucs liés à ruby ont eu des problèmes.
    Envoyé depuis mon lapin.
# OpenSSL toussa ..

Posté par Jean B le 04 août 2010 à 02:40. Évalué à 3.

A vrai dire la faute incombe au mainteneur du paquet Debian
http://www.mail-archive.com/debian-bugs-rc@lists.debian.org/(...)
Si tu utilisait le "gem" officiel tu n'aurait pas ce bug.

Ensuite pour les prochaines versions ce fichier disparait:
http://github.com/mperham/memcache-client/commit/c8ec03928ea(...)

NB: je ne blâme pas particulièrement Debian je constate juste.
# Logique

Posté par Axioplase ıɥs∀ (site web personnel) le 04 août 2010 à 06:05. Évalué à 2.

>> Ce qui est bien avec le ruby, c'est que c'est un langage interprété, donc lent,

Non, c'est un langage avec des interprètes lents, donc lent.

Le fait qu'il soit interprété ne le rend pas lent pour autant. Tu as des interprètes très rapides pour différents langages…
- [^] # Re: Logique
  
  Posté par yellowiscool le 04 août 2010 à 11:33. Évalué à 2.
  
  Le fait qu'il y ait une phase d’interprétation fait que c'est lent.
  Envoyé depuis mon lapin.
  - [^] # Re: Logique
    
    Posté par Axioplase ıɥs∀ (site web personnel) le 04 août 2010 à 14:57. Évalué à 2.
    
    Le fait que beaucoup d'interprètes soient codés naïvement fait que c'est lent.
    T'as des techniques d'interprétation rapides (utilisées dans pas mal d'interprètes Scheme, par exemple).
- [^] # Re: Logique
  
  Posté par JoeltheLion (site web personnel) le 04 août 2010 à 12:01. Évalué à 3.
  
  Le fait qu'il soit interprété ne le rend pas lent pour autant. Tu as des interprètes très rapides pour différents langages…
  
  Ca dépend ce qu'on entend par lent... J'aimerais beaucoup que tu me cites un langage interprété qui donne des programmes aussi rapides qu'un programme en C raisonnablement optimisé?
  - [^] # Re: Logique
    
    Posté par Jean B le 04 août 2010 à 12:48. Évalué à -2.
    
    Ben Java: http://shootout.alioth.debian.org/u64/benchmark.php?test=all(...)
    
    Sur le premier bench il arrive devant C et sur les autres il est très loin d'être ridicule. Et encore tu parle de "raisonnablement optimisé", là les codes ont été retravaillées des tonnes de fois.
    - [^] # Re: Logique
      
      Posté par yellowiscool le 04 août 2010 à 14:55. Évalué à 3.
      
      Le java n'est pas interprété, mais compilé en bytecode pour une machine virtuelle.
      
      En plus, certaines machines virtuelles transcodent le bytecode en code natif pour la machine hôte.
      
      On est loin du petit langage interprété qui analyse un fichier texte et qui fait les opérations à la volée.
      Envoyé depuis mon lapin.
      - [^] # Re: Logique
        
        Posté par Jean B le 04 août 2010 à 23:34. Évalué à 0.
        
        Le résultat de la compilation n'est pas du code natif. Encore si la phase de "compilation" produisait un fichier executable natif avec un "runtime", je serait d'accord pour parler de language compilé. Mais dans le cas de Java le "bytecode" doit être interprété par une VM c'est donc un langage interprété.
        
        Python fait pareil, il compile les sources en bytecode (.pyc), et personne ne contredirait que c'est un langage interprété, bon certes il ne fait pas de JIT, et les primitives du bytecode sont de plus haut niveau, mais peu importe ce n'est pas du code natif.
        
        [^] # Re: Logique
        
        Posté par barmic le 08 août 2010 à 13:18. Évalué à 2.
        
        Quasiment tout les langages « interprétés » font de la compilation just in time. Je crois que ruby 2 le feras aussi.
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)
    - [^] # Re: Logique
      
      Posté par JoeltheLion (site web personnel) le 04 août 2010 à 15:35. Évalué à 5.
      
      D'une part, le benchmark que tu cites, malgré des conditions favorables pour java, montre que ce langage est à peu près deux fois plus lent que du C (le C est très optimisé, mais le java aussi, donc on peut dire que c'est équitable).
      
      D'autre part, comme le souligne yellowiscool, java n'est pas vraiment un langage interprété.
      
      En l'état actuel des technologies disponibles, les langages interprétés sont toujours plus lents que ceux qui ne le sont pas.
  - [^] # Re: Logique
    
    Posté par Axioplase ıɥs∀ (site web personnel) le 04 août 2010 à 14:54. Évalué à -2.
    
    Interprété versus "C raisonnablement optimisé" ?!
    Il est pas un peu biaisé ton benchmark ?
    - [^] # Re: Logique
      
      Posté par JoeltheLion (site web personnel) le 04 août 2010 à 15:38. Évalué à 0.
      
      Ben tu prétends que les langages interprétés, ne sont "pas plus lent", que le problème ce sont les "interprètes naïfs". J'aimerais donc bien que tu me donne un exemple d'interprète non naïf, je trouve ça légitime, pas toi?
      
      En fait, sur le fond, je suis un peu d'accord avec toi: en optimisant l'interpréteur, on peut s'approcher du code natif. Cependant même les meilleures implémentations actuelles sont toujours nettement plus lentes que le code produit par un bon compilateur de C, et je pense que c'est un fait qu'il ne faut pas oublier.
      - [^] # Re: Logique
        
        Posté par Hojo le 04 août 2010 à 23:55. Évalué à 1.
        
        Je crois me souvenir que Perl dans plusieurs benchmark était plus rapide que C pour pas mal d'opération de traitement de gros volume de texte.
        
        C'est qu'un vague souvenir, donc pas de référence, mais peut-être ça parlera à quelqu'un.
      - [^] # Re: Logique
        
        Posté par Axioplase ıɥs∀ (site web personnel) le 05 août 2010 à 06:03. Évalué à 4.
        
        >> Ben tu prétends que les langages interprétés, ne sont "pas plus lent"
        
        Non. Le code compilé est, comme on s'y attend souvent, plus efficace que le code interprété. Je dis que « interprété = lent » n'est pas vrai, ce qui est différent.
        Tu as énormément de variation au sein des langages interprétés…
        
        Un interprète qui ressemble à
        (define (ev e env) (cond ((symbol? e) (cdr (assoc e env))) ...)) (define (eval e) (ev e '()))
        sera bien plus lent qu'un interprète qui ressemble à
        (define (ev e) (cond ((symbol? e) (lambda (k env) (k (assoc e env)))) ...)) (define (eval e) ((ev e) (lambda (v) v) '()))
        
        (Ensuite, je persiste en disant que le bench est injuste : dès que tu optimises ton langage compilé, il est quasiment impossible pour une version (même pas forcément interprétée) non-optimisée de faire mieux !)
        
        [^] # Re: Logique
        
        Posté par barmic le 08 août 2010 à 13:23. Évalué à 2.
        
        Tu es la première personne que je vois faire du pseudo code en lisp :)
        
        Du coup je comprends pas grand chose à l'exemple mais c'est pas grave.
        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.