Les pieds dans le code

Après quelques release candidate, voici venu la nouvelle version de JRuby . On y retrouve:

• compatibilité ruby 1.8.7
• Amélioration du support ruby 1.9 (d’ailleurs, l’équipe demande à tous ceux qui le peuvent de tester et faire des retours sur les fonctionnalités implémenté dans cette nouvelle mouture de ruby)
• Une installation windows native (pas encore essayé, mais ça facilitera certainement l’utilisation de jruby sur ces plateforme)
• Un nouveau parseur YaML fait sont entré (un petit article Ola Bini: new yaml support for jruby: yecht
• Amélioration du support Java (vitesse, nouvelles méthodes)
• et 307 bugs corrigé…

Du bon, on voit que l’équipe et la communauté autour de cette implémentation est très active ! Et je pense que c’est un bon moyen de faire entrer Ruby dans le monde de l’entreprise. J’en suis témoin, et j’espère pouvoir vous en parler bientôt.

Je viens de tomber sur quelque chose d’étrange dans l’utilisation de l’objet IO de Ruby : La gestion des verrous sur les fichiers. Alors j’ai surement du rater quelque chose, mais voici mon histoire…

require 'test/unit'

DUCK="duck"
ELEPHANT="elephant"
SNAKE="snake"
FILE="test_file"

class TestFileConcurrencyAccess < Test::Unit::TestCase
  def test_concurrency_access
    t1 = Thread.start do
      File.open(FILE, "w") do |file|
        file.puts SNAKE
        file.flush
        sleep 8
        file.puts DUCK
      end
    end
    File.open(FILE,"r") do |f1|
      assert SNAKE, f1.read
    end
    t2 = Thread.start do
      File.open(FILE,"w") do |f|
        sleep 2
        f.puts ELEPHANT
      end
    end
    t2.join
    File.open(FILE,"r") do |f2|
      assert ELEPHANT, f2.read
    end

    t1.join
    File.open(FILE,"r") do |f3|
      assert SNAKE, f3.readline
      assert DUCK, f3.readline
    end

  end
end

fichier source

Le resultat d’execution de ce test donne une erreur sur la dernière lecture:

Loaded suite test_file_concurrency_access

Started

E

Finished in 8.003509 seconds.

1) Error:
test_concurrency_access(TestFileConcurrencyAccess):

EOFError: end of file reached

    test_file_concurrency_access.rb:38:in `readline’

    test_file_concurrency_access.rb:38:in `test_concurrency_access’

    test_file_concurrency_access.rb:36:in `open’

    test_file_concurrency_access.rb:36:in `test_concurrency_access’
1 tests, 3 assertions, 0 failures, 1 errors

Mais ce qui me gène (et qui ne ressort pas dans mon test, je l’avoue) c’est que j’aurais pensé que le deuxième File.open ne puisse pas s’executé, et me renvoie une Error du type: “Le fichier est déjà ouvert en écriture par quelqu’un d’autres”… Mais non, et du coup, j’ai un fichier assez moche qui ne ressemble à rien:

elephduck

Alors qu’on pourrait penser obtenir un truc dans le genre:

snake
duck

Avec éventuellement une erreur sur l’écriture d’éléphant dans le fichier.

J’ai également fait un essai en utilisant le code contenu dans chaque thread pour les executer dans deux console différentes, j’arrive au même résultat (c’est du coup dans test/unit, mais au niveau du contenu de FILE à la fin, j’ai là même chose…)
Fichier write_quickly.rb pour l’écriture d’ELEPHANT
Fichier write_slowly.rb pour l’écriture de SNAKE et DUCK

Bref, je suis perplexe. J’avoue ne pas avoir envie d’envoyer cela sur la mailing-liste Ruby-talk, ni sur celle de JRuby d’ailleurs (car j’ai vérifier, j’ai le même problème en JRuby). Du moins tant que je n’ai pas creusé un peu plus.

J’ai sûrement du faire une erreur quelque part, oublier quelque chose, ou faire quelque chose de travers. Si quelqu’un lit cela et à une idée, merci d’en m’en parler, je suis preneur !.

Si c’est un comportement souhaité, j’aimerais comprendre pourquoi, et si c’est un oubli ou une erreur, j’aimerais bien aider à trouver une solution.

ps: Retour au thème Scribbish que je trouve plus lisible, en attendant que je refasse quelque chose…

Après avoir déménagé le gestionnaire de projet de CodeHaus à Kenai (la forge selon Sun), JRuby change de gestionnaire de version pour passer de Subversion à Git

L’annonce de Headius: JRuby moves to Git

ça va forker !

Charles Nutter, dit Headius l’a annoncé par un twit : le projet JRuby déménage:

I’m so excited to move everything to kenai.com + git + github. We’ll really be dogfooding JRuby on Rails then (kenai is JRoR-based).

source: "https://twitter.com/headius/status/1378984561":https://twitter.com/headius/status/1378984561

Le projet JRuby est donc en train de déménagé de la plateforme Codehaus à Kenai. Ce gestionnaire de projet est, comme l’indique Charles, basé sur JRuby (je vous donne la nouvelle adresse ;-)). C’est très bon tout cela.

Ce site héberge déjà le projet ActiveRecord-JDBC qui est maintenant traité comme un projet enfant de JRuby.

Et pour reprendre encore une fois Charles, ils ont besoin d’aide pour transferer le wiki:

Help JRuby move to http://kenai.com Copy wiki pages from http://wiki.jruby.org/wiki/Main_Page to http://kenai.com/projects/jruby/pages/Home, then tell me so I can lock the original.

source: "https://twitter.com/headius/status/1374505769":https://twitter.com/headius/status/1374505769

N’hésitez pas ;-)

C’est pas tout frais, mais Jruby vient de sortir en version 1.2.

Au menu:

• Un bon support des fonctionnalité de Ruby 1.9
• Le compilateur marche (cela permet de compiler des classes Ruby en byteCode Java)
• Amélioration des performances (un classique) sur le parseur, et le runtime
• Un début de support pour Android (le projet est nomé Ruboto)
• Un gros paquet de bugs sont fixés (un peu trop long pour être listé ici :-))

Ce projet avance vite et bien. Je ne sais pas à quel niveau de compatibilité sont arrivé les autres VM aujourd’hui,je pense à Rubinius et IronRuby surtout (vous en connaissez d’autres ?), mais certainement aussi bien. Je fais parti de ces gens qui pense que c’est une bonne chose, et vous ?

J’ai raté ça, mais le 17 décembre, Thomas E Enebo annonçait la sorti de JRuby 1.1.6.

Cette version corrige pas mal de bug, notemment sur l’objet IO (qui ces dernier mois a été l’objet de pas mal de remonté de bug). Cette version prépare également le support de la version 1.9 de Ruby: le parseur est complet, la pluspart des objets du core, des standard lib sont supporté.

Le projet est toujours aussi actif. C’est bon pour Ruby et c’est bon pour les développeurs. J’espère que les entreprises frileuses qui ont déjà adopté Java accepterons plus facilement l’utilisation de Ruby par ce biais.

La nouvelle version de JRuby viens de sortir: Jruby 1.1.4 .

Au programme, pas mal de chose dont

• Un gros refactoring de la couche d’intégratiohn java.
• de 2 à 20 fois plus rapide sur la plus part des fonctionnalitées
• Les exceptions java peuvent être maintenant récupérer directement dans Ruby
• Amélioration de la gestion mémoire
• Début du support de Ruby 1.9 (vivement les fibres dans jruby ! je veux voir ça)
• Amélioration des performances
• Pool de Thread amélioré
• Accès concurent sur les tableaux amélioré
• Et 72 bug résolu depuis la version 1.1.3

Dans les prochain mois, l’équipe va travailler pour essayer de sortir des release plus fréquement (quelque chose comme une fois par mois). Le but étant de corriger au plus vite les divers problème, et apporté les évolutions plus rapidement aux utilisateurs.

Un bon projet toujours sur un bon rythme :)

Jruby vous connaissez ? C’est l’implémentation Java du langage de programmation Ruby. Une implémentation qui à mon avis séduit ou séduira la plus part des entreprise ayant déjà une infrastructure basé sur la technologie Java.

Et bien cette semaine, c’est la dernière ligne droite, Tom a déclenché les hostilitées en annonçant la sortie d’ici la fin de semaine de la nouvelle version 1.1.3 de cette implémentation, et du coup propose à tous de signaler ce qu’ils souhaitent voir dans cette version (archives de l’annonce: JRuby 1.1.3 by end of week…Nominate problems here…. Charles Oliver Nutter a surenchéri en faisant suivre le message sur la mailing list User (The reason we’re pushing 1.1.3 now is so we can finally branch 1.1 into
full maintenance mode and start hitting Java integration hard.

Les demandes pleuvent, je vous prévient un peu tard peut-être pour participer, mais essayé toujours. Au pire on fera les tests sur cette nouvelle mouture.

Pour certain c’est une évidence, mais un vieux mail sur la liste de diffusion de ruby_core ma donné envie de me pencher sur la question.

Venant du monde Java (enfin je n’en suis pas encore sorti), je suis un habitué du:

MacLasse monObjet = MacLasse.new();

pour Ruby ça devient:

mon_objet = Mac_lasse.new

Bon à part le typage dur de java versus le typage dynamique de ruby, pas de gros changement sur l’interprétation de la façon d’instancier un objet entre ces deux langages.

Par contre c’est sur la classe elle même que ça change pas mal.

En java MacLasse ressemble à ça:

public class MacLasse {
  public MacLasse(){
    // code a executer lors de l'instanciation de l'objet
  }
}

et en ruby on se retrouve avec ça:

class Mac_lasse
  def initialize
    // code a executer lors de l'instanciation de l'objet
  end
end

Cette methode en java s’appel un constructeur (ça c’est pour ceux du fond qui suivent pas hein ! ). On l’obtient en définissant une methode portant le même nom que la classe.

Pour ruby, peut importe le nom de la classe, on utilise une methode initialize.

Alors initialize est-elle une methode de type constructeur ?

Non. et en Java non plus finalement. Ces deux methode ne construisent pas l’instance, elle l’initialise. Elles permettent de préparer l’instance avant de la rendre. En java comme en Ruby, on peut très bien ce passer de ces methodes.

Maintenant on va s’éloigner de Java…

En Ruby on pourrais définir une methode new en lieu et place d’@initialize@. Non mais qu’est-ce que je raconte, heureusement y’en a au premier rang qui suivent. Merci.

Je reprend. En ruby on peut surcharger la methode new (Object#new) en plus de la methode initialize. Le seul hic, c’est qu’il faut faire attention. Cette methode new est censé créer l’instance de la class. Il faut donc penser à renvoyer la bonne instance en fin de methode (new pour les voisins du radiateur).

Voyons plutôt un petit bout de code:

class Test_initialize
    def initialize
        "test_initialiaze"
    end
end

class Test_new
    def self.new(*args)
        "test_new"
    end
end

class Test_new_2
    def self.new(*args)
        "test_new_2"
        Object.new
    end
end

test = Test_initialize.new
puts test.class   # Test_initialize

test = Test_new.new("args")
puts test.class   # String

test = Test_new_2.new("args")
puts test.class   # Object

On le voit assez bien je pense: Surcharger new ne doit pas se faire à la légère. Utilisé initialize pour initialiser l’instance semble bien plus logique.

Là dessus Ruby montre bien un de ces principe de base qui veux que le langage soit simple et logique. Contrairement a Java ou l’on parle de constructeur en lieu et place de methode d’initialisation.

C’est de la sémantique c’est sur, mais le principe est là. J’aime ruby et j’aime bien java quand même :-)

Et voilà, l’implémentation Java de Ruby vient de sortir. Alors forcement tout n’est pas implémenté, tout n’est pas compatible. Mais c’est sûrement à essayer !

Je suis sur que c’est un bon moyen de faire entrer Ruby dans l’entreprise !

L’annonce surle blog de Charles Nutter

Le site officiel de JRuby

il faut que je code !