А теперь о Ruby и Redmine
Я таки нашел, в чем причина вот этого бага:
no method error [] for class nil
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/949011
Вкратце: недавно в большинстве реализаций хэш таблиц была найдена имманентная уязвимость к потенциальным DDOS атакам на веб-приложения, связанная с тем что атакующий мог посылать запросы такого вида, что внутри приложения они приводили к обращению к хэш-таблице всегда к одному bucket. Т.е. передавать ключи, которые после обработки hash-функцией всегда давали одно и то же значение, убивая эту таблицу из O(1) в O(N) и съедая тем самым процессор.
В руби это дело исправили:
https://launchpad.net/ubuntu/+source/ruby1.8/1.8.7.249-2ubuntu0.1
http://launchpadlibrarian.net/94639065/ruby1.8_1.8.7.249-2_1.8.7.249-2ubuntu0.1.diff.gz
конкретно эти строки:
++extern unsigned long rb_genrand_int32(void);
++
++void
++Init_st(void)
++{
++ hash_seed = rb_genrand_int32();
++}
+- register int key = 0;
++ register unsigned long key = hash_seed;
Формально, в норме бы ничего не поменялось, после этого.
НО: в редмайне оказалось место, где работа зависит от порядка элементов в хэше:
/usr/share/redmine/app/models/setting.rb,166
setting ||= new(:name => name, :value => @@available_settings[name]['default'])
тут происходит примерно такое: создается новый объект Setting и ему устанавливаются атрибуты name и value. И, это ключевой момент, установка атрибута value ЗАВИСИТ от наличия уже установленного атрибута name:
т.е. оно использует name чтобы получить значение по умолчанию из @@available_settings и далее пытается из него получить значение атрибута 'serialized'
Раньше это работало, а после секьюрити-фикса - работает в зависимости от rb_genrand_int32.
Так что ошибка, вообще говоря, в редмайне. Надеятся на порядок в хэш-таблице, это бред.
PS: а вот и фикс, месяц назад: http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb
no method error [] for class nil
https://bugs.launchpad.net/ubuntu/+source/ruby1.8/+bug/949011
Вкратце: недавно в большинстве реализаций хэш таблиц была найдена имманентная уязвимость к потенциальным DDOS атакам на веб-приложения, связанная с тем что атакующий мог посылать запросы такого вида, что внутри приложения они приводили к обращению к хэш-таблице всегда к одному bucket. Т.е. передавать ключи, которые после обработки hash-функцией всегда давали одно и то же значение, убивая эту таблицу из O(1) в O(N) и съедая тем самым процессор.
В руби это дело исправили:
https://launchpad.net/ubuntu/+source/ruby1.8/1.8.7.249-2ubuntu0.1
http://launchpadlibrarian.net/94639065/ruby1.8_1.8.7.249-2_1.8.7.249-2ubuntu0.1.diff.gz
конкретно эти строки:
++extern unsigned long rb_genrand_int32(void);
++
++void
++Init_st(void)
++{
++ hash_seed = rb_genrand_int32();
++}
+- register int key = 0;
++ register unsigned long key = hash_seed;
Формально, в норме бы ничего не поменялось, после этого.
НО: в редмайне оказалось место, где работа зависит от порядка элементов в хэше:
/usr/share/redmine/app/models/setting.rb,166
setting ||= new(:name => name, :value => @@available_settings[name]['default'])
тут происходит примерно такое: создается новый объект Setting и ему устанавливаются атрибуты name и value. И, это ключевой момент, установка атрибута value ЗАВИСИТ от наличия уже установленного атрибута name:
def value=(v)
v = v.to_yaml if v && @@available_settings[name]['serialized']
write_attribute(:value, v.to_s)
endт.е. оно использует name чтобы получить значение по умолчанию из @@available_settings и далее пытается из него получить значение атрибута 'serialized'
Раньше это работало, а после секьюрити-фикса - работает в зависимости от rb_genrand_int32.
Так что ошибка, вообще говоря, в редмайне. Надеятся на порядок в хэш-таблице, это бред.
PS: а вот и фикс, месяц назад: http://www.redmine.org/projects/redmine/repository/revisions/8909/diff/trunk/app/models/setting.rb
no subject
PS Пока что из языков только питон предсказуем до тошноты, может луа еще (хотя там в стандартных библиотеках undefined поведение местами)
no subject
lua да, весьма стабилен, хотя тут ещё все зависит от конкретной реализации
no subject
У луа проблемы изменно в совместимости между реализациями. И на все что не описано в programming lua закрывают глаза, и делают вид что его нет (и я кстати именно про таймзоны)
PS А что у питона не так с таймзонами?
PPS С таймзонами все не так -- надо всем жить по гринвичу
no subject
no subject
no subject
Вы в сях где-нибудь поставье лишнюю скобочку - будет ровно то же самое.
И там и там - один символ.
no subject
везде проблеы и один табик, очень ок.
no subject
no subject
no subject
no subject
no subject
Зачем приводить ссылки на редакторы, существенного опыта работы с которыми не имеется? Хотя, в емаксе такое тоже было, ЕМНИП.
no subject
Уже никто их не ставит, никогда.
У меня они запрещены -- в редакторе -- раз, прекоммит-хуком два.
no subject
no subject
(reindent -- скрипт из стандартной поставки петона,
Я пару раз импортил ветки от таких умельцев ;)
PS du -sh ./eggs -- 37mb, табов нету.
no subject
(Anonymous) 2012-03-26 11:03 am (UTC)(link)руби бы сильно выиграл от табовой разметки.
c:wicked ayerrow
no subject
no subject
С синтаксисом питона как раз плохо, пока не заучишь N странных конструкций (оптимизированных для интерпретатора, а не человека) не взлетишь.
no subject
Там только декораторы выглядят марсианскими (но все равно к ним быстро привыкаешь) -- но они как я понимаю тянуты из джавы целиком
no subject
https://plus.google.com/111512356605658929685/posts/Ry4Kpdd9cfx
Плавно с около-руби тем свернули на питон.
Влом повторяться.