"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
Nan mais je connais le pb c'est assez complexe, c'est peut etre pas grand chose par example il cherche Datas et il est dans le contexte Commands::Runners::Runner et il s'arrete sur Commands::Runners::Runner::Datas ce qui est faut, il doit continuer et tester Commands::Runners::Datas puis Commands::Datas qui est correcte. Mais la j'ai mon rapport sur le feu et je n'ai pas le temps de voir.
Reminder. ;)
On 2006-07-07, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
Nan mais je connais le pb c'est assez complexe, c'est peut etre pas grand chose par example il cherche Datas et il est dans le contexte Commands::Runners::Runner et il s'arrete sur Commands::Runners::Runner::Datas ce qui est faut, il doit continuer et tester Commands::Runners::Datas puis Commands::Datas qui est correcte. Mais la j'ai mon rapport sur le feu et je n'ai pas le temps de voir.
Reminder. ;)
Workaround temporaire:
dpkg -i /mnt/goinfre/libruby1.8_1.8.4-2_i386.deb
/!\ Ceci va casser toutes les packets qui dépendent de Ruby. Par exemple pour installer libmagick++9-dev:
The following packages have unmet dependencies. libmagick++9-dev: Depends: libmagick9-dev (= 7:6.2.4.5-0.8) but it is not going to be installed rdoc1.8: Depends: libruby1.8 (>= 1.8.4-5) but 1.8.4-2 is to be installed ruby1.8-dev: Depends: libruby1.8 (= 1.8.4-5) but 1.8.4-2 is to be installed
Astuce: Faites apt-get install -f pour régler les problèmes de dépendances. Ceci va remettre la dernière version de libruby1.8 Faites votre apt-get install normal Re-faite un dpkg -i /mnt/goinfre/libruby1.8_1.8.4-2_i386.deb
On 7/7/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
Nan mais je connais le pb c'est assez complexe, c'est peut etre pas grand chose par example il cherche Datas et il est dans le contexte Commands::Runners::Runner et il s'arrete sur Commands::Runners::Runner::Datas ce qui est faut, il doit continuer et tester Commands::Runners::Datas puis Commands::Datas qui est correcte. Mais la j'ai mon rapport sur le feu et je n'ai pas le temps de voir.
Reminder. ;)
Oui, je vais essayer d'y faire qq chose ce weekend.
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/7/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
Nan mais je connais le pb c'est assez complexe, c'est peut etre pas grand chose par example il cherche Datas et il est dans le contexte Commands::Runners::Runner et il s'arrete sur Commands::Runners::Runner::Datas ce qui est faut, il doit continuer et tester Commands::Runners::Datas puis Commands::Datas qui est correcte. Mais la j'ai mon rapport sur le feu et je n'ai pas le temps de voir.
Reminder. ;)
Oui, je vais essayer d'y faire qq chose ce weekend.
Merci.
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ?
Oui, c'est assez grave en fin de compte :(
Un changement dans ruby, que je n'ai pas encore cerné à complètement détruit lazy loading.
Lazy loading est utilisé dans CoreEx (le paquet commun à tous nos projets vcs, uttk...) pour se passer des "require"s. Il utilise une technique assez compliqué qui ne marche pour l'instant plus dans ruby 1.8.5. En attendant que le problème soit résolu, j'ai contourné le problème en ajoutant un fil chier chargant tous les modules dans l'ordre manuellement.
Ici http://gallium.inria.fr/~pouillar/gems sont disponibles les nouveaux gems pour utiliser vcs. Cette version corrige entre autre le problème rencontré par Akim au sujet des destinataires multiples dans les mails.
Faites moi signe si il y a un problème.
Amicalement,
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ?
Oui, c'est assez grave en fin de compte :(
Un changement dans ruby, que je n'ai pas encore cerné à complètement détruit lazy loading.
Lazy loading est utilisé dans CoreEx (le paquet commun à tous nos projets vcs, uttk...) pour se passer des "require"s. Il utilise une technique assez compliqué qui ne marche pour l'instant plus dans ruby 1.8.5. En attendant que le problème soit résolu, j'ai contourné le problème en ajoutant un fil chier chargant tous les modules dans l'ordre manuellement.
Ici http://gallium.inria.fr/~pouillar/gems sont disponibles les nouveaux gems pour utiliser vcs. Cette version corrige entre autre le problème rencontré par Akim au sujet des destinataires multiples dans les mails.
Faites moi signe si il y a un problème.
Amicalement,
Hum... Ça ne marche pas chez moi (le message d'erreur est différent d'avant) :
brasilia ~ % vcs-svn help 18:24 #201 vcs: error: No Vcs instanciated vcs: error: undefined method `each' for false:FalseClass
Par ailleurs, il doit manquer une dépendance sur sur le paquet objective_command-0.1.1.0.gem dans le paquet vcs-0.5.2.5.gem ; voici ce que vcs m'a dit avant que je n'installe objective_command :
brasilia ~/download/software/ruby/vcs % vcs /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': no such file to load -- objective_command (MissingSourceFile) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /usr/lib/ruby/gems/1.8/gems/core_ex-0.6.1.0/lib/core_ex.rb:108:in `core_ex_require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb:22 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:17 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/vcs:7 from /usr/bin/vcs:18
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ?
Oui, c'est assez grave en fin de compte :(
Un changement dans ruby, que je n'ai pas encore cerné à complètement détruit lazy loading.
Lazy loading est utilisé dans CoreEx (le paquet commun à tous nos projets vcs, uttk...) pour se passer des "require"s. Il utilise une technique assez compliqué qui ne marche pour l'instant plus dans ruby 1.8.5. En attendant que le problème soit résolu, j'ai contourné le problème en ajoutant un fil chier chargant tous les modules dans l'ordre manuellement.
Ici http://gallium.inria.fr/~pouillar/gems sont disponibles les nouveaux gems pour utiliser vcs. Cette version corrige entre autre le problème rencontré par Akim au sujet des destinataires multiples dans les mails.
Faites moi signe si il y a un problème.
Amicalement,
Hum... Ça ne marche pas chez moi (le message d'erreur est différent d'avant) :
brasilia ~ % vcs-svn help 18:24 #201 vcs: error: No Vcs instanciated vcs: error: undefined method `each' for false:FalseClass
Arg tu peux essayer :
$ VCS_SEVERITY=debug vcs-svn help
Par ailleurs, il doit manquer une dépendance sur sur le paquet objective_command-0.1.1.0.gem dans le paquet vcs-0.5.2.5.gem ; voici ce que vcs m'a dit avant que je n'installe objective_command :
Oui en effet.
brasilia ~/download/software/ruby/vcs % vcs /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require__': no such file to load -- objective_command (MissingSourceFile) from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/activesupport-1.3.1/lib/active_support/dependencies.rb:147:in `require' from /usr/lib/ruby/gems/1.8/gems/core_ex-0.6.1.0/lib/core_ex.rb:108:in `core_ex_require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb:22 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:17 from /usr/local/lib/site_ruby/1.8/rubygems/custom_require.rb:21:in `require' from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/vcs:7 from /usr/bin/vcs:18
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ?
Oui, c'est assez grave en fin de compte :(
Un changement dans ruby, que je n'ai pas encore cerné à complètement détruit lazy loading.
Lazy loading est utilisé dans CoreEx (le paquet commun à tous nos projets vcs, uttk...) pour se passer des "require"s. Il utilise une technique assez compliqué qui ne marche pour l'instant plus dans ruby 1.8.5. En attendant que le problème soit résolu, j'ai contourné le problème en ajoutant un fil chier chargant tous les modules dans l'ordre manuellement.
Ici http://gallium.inria.fr/~pouillar/gems sont disponibles les nouveaux gems pour utiliser vcs. Cette version corrige entre autre le problème rencontré par Akim au sujet des destinataires multiples dans les mails.
Faites moi signe si il y a un problème.
Amicalement,
Hum... Ça ne marche pas chez moi (le message d'erreur est différent d'avant) :
brasilia ~ % vcs-svn help 18:24 #201 vcs: error: No Vcs instanciated vcs: error: undefined method `each' for false:FalseClass
Arg tu peux essayer :
$ VCS_SEVERITY=debug vcs-svn help
Ça donne ça :
brasilia ~ % VCS_SEVERITY=debug vcs-svn help Err 1 #202 vcs: debug: revision.rb vcs: debug: diff.rb vcs: debug: conflict.rb vcs: debug: message.rb vcs: debug: common_commit.rb vcs: debug: junk.rb vcs: debug: edit.rb vcs: debug: list.rb vcs: debug: mail.rb vcs: debug: add.rb vcs: debug: cvs.rb vcs: debug: form.rb vcs: debug: news.rb vcs: debug: delete.rb vcs: debug: svk.rb vcs: debug: url.rb vcs: debug: back.rb vcs: debug: environment.rb vcs: debug: status.rb vcs: debug: changelog.rb vcs: debug: last_changed_date.rb vcs: debug: script.rb vcs: debug: prcs.rb vcs: debug: diffstat.rb vcs: debug: ignore.rb vcs: error: No Vcs instanciated vcs: debug: Backtrace enabled: vcs: error: /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb:708:in `merge_user_conf': undefined method `each' for false:FalseClass (NoMethodError) vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:89:in `user_configuration_setup' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:88:in `user_configuration_setup' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:96:in `run' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/vcs-svn:9 vcs: error: from /usr/bin/vcs-svn:18
et j'ai compris d'où venait le problème en regardant /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb
[...]
def merge_user_conf ( conf ) conf = YAML.load(conf.read) if conf.is_a? Pathname conf.each do |k, v| v = v.to_sym if v.is_a? String user_conf.send("#{k}=", (v.is_a? Array)? ((user_conf.send(k) || []) + v) : v) end end
[...]
Cette méthode ne vérifie pas que `conf' est peut-être vide (= false:falseClass), ce qui était mon cas car j'avais désactivé toutes les options de mon fichier ~/.vcs.
En réactivant une option de ce fichier, vcs remarche (youpi !).
On 7/11/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
"Nicolas Pouillard" nicolas.pouillard@gmail.com writes:
On 7/10/06, Roland Levillain roland@lrde.epita.fr wrote:
C'est peut-être une mise à jour de Ruby (dans Debian unstable) qui a cassé Vcs. C'est grave docteur ?
Oui, c'est assez grave en fin de compte :(
Un changement dans ruby, que je n'ai pas encore cerné à complètement détruit lazy loading.
Lazy loading est utilisé dans CoreEx (le paquet commun à tous nos projets vcs, uttk...) pour se passer des "require"s. Il utilise une technique assez compliqué qui ne marche pour l'instant plus dans ruby 1.8.5. En attendant que le problème soit résolu, j'ai contourné le problème en ajoutant un fil chier chargant tous les modules dans l'ordre manuellement.
Ici http://gallium.inria.fr/~pouillar/gems sont disponibles les nouveaux gems pour utiliser vcs. Cette version corrige entre autre le problème rencontré par Akim au sujet des destinataires multiples dans les mails.
Faites moi signe si il y a un problème.
Amicalement,
Hum... Ça ne marche pas chez moi (le message d'erreur est différent d'avant) :
brasilia ~ % vcs-svn help 18:24 #201 vcs: error: No Vcs instanciated vcs: error: undefined method `each' for false:FalseClass
Arg tu peux essayer :
$ VCS_SEVERITY=debug vcs-svn help
Ça donne ça :
brasilia ~ % VCS_SEVERITY=debug vcs-svn help Err 1 #202 vcs: debug: revision.rb vcs: debug: diff.rb vcs: debug: conflict.rb vcs: debug: message.rb vcs: debug: common_commit.rb vcs: debug: junk.rb vcs: debug: edit.rb vcs: debug: list.rb vcs: debug: mail.rb vcs: debug: add.rb vcs: debug: cvs.rb vcs: debug: form.rb vcs: debug: news.rb vcs: debug: delete.rb vcs: debug: svk.rb vcs: debug: url.rb vcs: debug: back.rb vcs: debug: environment.rb vcs: debug: status.rb vcs: debug: changelog.rb vcs: debug: last_changed_date.rb vcs: debug: script.rb vcs: debug: prcs.rb vcs: debug: diffstat.rb vcs: debug: ignore.rb vcs: error: No Vcs instanciated vcs: debug: Backtrace enabled: vcs: error: /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb:708:in `merge_user_conf': undefined method `each' for false:FalseClass (NoMethodError) vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:89:in `user_configuration_setup' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:88:in `user_configuration_setup' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/../lib/vcs/app.rb:96:in `run' vcs: error: from /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/bin/vcs-svn:9 vcs: error: from /usr/bin/vcs-svn:18
et j'ai compris d'où venait le problème en regardant /usr/lib/ruby/gems/1.8/gems/vcs-0.5.2.5/lib/vcs/vcs.rb
[...]
def merge_user_conf ( conf ) conf = YAML.load(conf.read) if conf.is_a? Pathname conf.each do |k, v| v = v.to_sym if v.is_a? String user_conf.send("#{k}=", (v.is_a? Array)? ((user_conf.send(k) || []) + v) : v) end end
[...]
Cette méthode ne vérifie pas que `conf' est peut-être vide (= false:falseClass), ce qui était mon cas car j'avais désactivé toutes les options de mon fichier ~/.vcs.
A ok, merci c'est corrigé maintenant.
En réactivant une option de ce fichier, vcs remarche (youpi !).
Tant mieux !