FFI – это рубишный гем, который позволяет вызывать функции С.
В данном случае я имел в виду, что вызов блока с аргументами требует знания ABI (бинарного интерфейса). Так же как компилятор RM делает трамплины для Objective-C методов – надо делать их и для блоков. Но во время компиляции этой информации еще нет.
invoke. Можно вызывать на любых «блоковых объектах». В том числе и со стороны руби. У него типичная сигнатура «v@:», для которой гарантированно есть трамплин :)
Weak – это больная тема. Я помню пару лет назад ее мусолили в MacRuby, и тогда Лаурент писал что-то вроде того, что «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения».
Как в RM обстоят дела со сборкой мусора, я, если честно, не имею ни малейшего понятия. Это, собственно, основная коммерческая информация RM. Насколько я помню, указатели в RM как раз таки со слабой связанностью, и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained». Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.
А вообще тема интересная, я даже захотел ее покопать (странно, что раньше оно мне не попадало в голову).
1. Ну почему, на крайний случай всегда есть NSInvocation :-)
2. Нет, синтаксис попроще
3. Машинный код с кучей вызовов в RoxorVM. В целом – еще одна обертка вокруг Objective-C Runtime. Простые операции а ля 2 + 2 компилятся как есть.
И да, мне кажется корректнее, если «типизацию» значения (например приведение значения токена в int) должен делать лексер. Фактически, я еще ни разу не использовал свойство *Token#type в парсере.
> что для свертывания нетерминала задается только один блок, несмотря на наличие в правилах choise
можно просто сделать несколько правил.
Я недавно выкатил 0.2.3, там несколько «хелперов» для типичных задач свертки + альтернативный вариант блоков (в аргументах – value, результат присваивается в lhs.value).
Парсер условно стабилен. В том плане, что он делает то что мне нужно на тех грамматиках, на которых я его гоняю (c, tablegen). Естественно, это 0.2.3, так что баги там, вероятно, есть. Так что багрепорты (особенно с патчами) принимаются на ура.
Синтаксис Racc несколько «не рубишен». Я как-то сел портировать питоновский Ply (который очень хорош по читабельности) на Ruby. Результат можно посмотреть тут: github.com/farcaller/rly
В целом, я старался оптимизировать код, но лексер несколько медленный, так как на регулярках (хотя в ruby2.0 он заметно шустрее). Если интересно – я могу детальнее описать механизм работы и подводные камни LALR(1)-генераторов на руби.
Да, каюсь. Невнимательно читал и пропустил «Идея состоит в следующем: поднять на этом же пользователе gitolite».
Но если подумать – то origin url все равно меняется, так как надо указывать порт. Почему бы тогда не поменять ssh пользователя, а репы не закинуть ему симлинками?
В данном случае я имел в виду, что вызов блока с аргументами требует знания ABI (бинарного интерфейса). Так же как компилятор RM делает трамплины для Objective-C методов – надо делать их и для блоков. Но во время компиляции этой информации еще нет.
invoke. Можно вызывать на любых «блоковых объектах». В том числе и со стороны руби. У него типичная сигнатура «v@:», для которой гарантированно есть трамплин :)
Weak – это больная тема. Я помню пару лет назад ее мусолили в MacRuby, и тогда Лаурент писал что-то вроде того, что «или GC сам все сделает как надо, или это архитектурная проблема вашего приложения».
Как в RM обстоят дела со сборкой мусора, я, если честно, не имею ни малейшего понятия. Это, собственно, основная коммерческая информация RM. Насколько я помню, указатели в RM как раз таки со слабой связанностью, и если закинуть ссылку на объект в указатель – то это будет некий «unsafe_unretained». Плюс, всегда можно написать свой класс WeakRef, благо Objective-C в данный момент позволяет.
А вообще тема интересная, я даже захотел ее покопать (странно, что раньше оно мне не попадало в голову).
2. Нет, синтаксис попроще
3. Машинный код с кучей вызовов в RoxorVM. В целом – еще одна обертка вокруг Objective-C Runtime. Простые операции а ля 2 + 2 компилятся как есть.
Но вообще frame pointer в руби выключать не стоит в принципе. Минимальный оверхед на грани заметности, а дебажить скучнее становится в разы.
можно просто сделать несколько правил.
Я недавно выкатил 0.2.3, там несколько «хелперов» для типичных задач свертки + альтернативный вариант блоков (в аргументах – value, результат присваивается в lhs.value).
Парсер условно стабилен. В том плане, что он делает то что мне нужно на тех грамматиках, на которых я его гоняю (c, tablegen). Естественно, это 0.2.3, так что баги там, вероятно, есть. Так что багрепорты (особенно с патчами) принимаются на ура.
В целом, я старался оптимизировать код, но лексер несколько медленный, так как на регулярках (хотя в ruby2.0 он заметно шустрее). Если интересно – я могу детальнее описать механизм работы и подводные камни LALR(1)-генераторов на руби.
А вообще – отличное расследование, но я так и не уловил конец. Кто таки вызывал -resizeToContents неправильно?
Но если подумать – то origin url все равно меняется, так как надо указывать порт. Почему бы тогда не поменять ssh пользователя, а репы не закинуть ему симлинками?
Можно поподробнее? Почему? Насколько я помню, никаких изменений именно в конфигурацию sshd нет.