Да, provider'ов пока что писать намного сложнее.
Дело в том, что мы сначала написали набор плагинов под нашу ситуацию, которая заточена под большие кластера, грубо говоря. А нам удобнее конфигурировать все per-host и per-cluster, то есть в наших программах вообще нет ни слова о том, где лежит конфиг, все сконфигурировано заранее.
Тем не менее я понимаю, что такой подход не всех устроит (и поэтому же документация многих сбивает с толку). Надеюсь в ближайшие недели написать синтаксический сахар и туториал для биндингов конфигов в рантайме.
Хотя и сейчас уже можно забиндить в конфигурационное дерево что угодно, просто нигде это явно не сказано: BEGIN {
our $config = ...; # загрузить конфиг откуда угодно с помощью чего угодно
}
use Morpheus -defaults => { '/foo/bar' => $config };
# либо еще проще, без BEGIN {}:
use Morpheus
$config = ...;
Morpheus->import(-defaults => { '/foo/bar' => $config });
Ага, это один из двух реальных вариантов. В статье ни одного реального нет — не успеет ни один из этих концов света случиться.
Я лично верю, что либо серая слизь, либо Seed AI (который не обязательно конец света, но после которого человечество никогда не будет прежним), причем в ближайшие 20-30 лет. При этом серая слизь мне пока кажется вероятнее.
> Т.е. к нему надо выполнять http-connect.
Не http-connect, а tcp
> Кеширование в файл будет быстрее.
Кеширование в файл не будет быстрее, потому что или у вас будет много-много файлов, или вам придется этот файл блокировать на каждое сохранение, и думать о хешировании внутри файла, и в итоге переписать memcached с нуля.
tcp-сокет, кстати, вполне быть и на localhost.
> Но memcached не нужно использовать, если у вас только один сайт.
А если у меня один сайт на FastCGI? :)
Ну как, если запретить в coding style одну часть перлового синтаксиса — получится C. Другую часть — получится Java :-)
Если серьезно, благодаря разнообразию выразительных средств в perl'е развита и обратная сторона медали. Я не зря сказал о pre-commit хуках, если натравить на весь код Perl:: Critic и заставить всех соблюдать его рекомендации (это, правда, очень жестоко) — то получится результат получится куда как синтаксически чище, чем даже на python'е.
А еще бывают такие одаренные разработчики, мыслительный процесс которых позволяет им писать нечитаемый код на любом языке. Тут уж ничего не поделаешь.
Корпорации, которые хотят контролировать стиль кода и заставить всех писать на Perl исключительно в C (или C++, кому как нравится) стиле, могут задокументировать свой coding style в виде а) донесенного до каждого документа, б) pre-commit hook'ов в системе контроля версий.
Чтобы разработчики быстрее могли разобраться в архитектуре, можно использовать фреймворки, Catalyst, или что-то еще. Для Perl их немало.
Тут ситуация уже не отличается от других языков, у Python есть Zope/Django/TurboGears, для Java тоже есть много слов, которых я не знаю, но которые по функциональности друг друга перекрывают.
На десктопе Athlon64 3200+ у меня тоже тормозит отрисовка при скролле, но на нем и gmail тормозит, и любые страницы с большим количеством маленьких картинок.
А на MacbookPro все летает (под тем же FF3).
Как устроен движок изнутри, я не знаю, хотя не представляю, что может мешать ему рендерить вектор в картинку и отрисовывать ее быстро. В конце концов, html тоже рендерится в некую картинку из векторных объектов-букв.
И flash тоже шустро работает, и тоже не потому, что flash бинарный, а svg — xml. Потому что все равно все они проходят через какое-то внутреннее представление сначала.
Ну, это вечный круг — никто не использует SVG в браузерах => мозилла не развивает свой svg-движок => никто не использует SVG в браузерах.
Хотя какой-то запас по оптимизации там есть, не грузить все треки в один общий DOM (там есть js при переключении между треками, но нет ajax'а), кешировать xslt-трансформацию на сервере, и тому подобное.
С png, впрочем, тоже хочется попробовать, но мне хотелось бы, наоборот, интерактива добавить.
PS. Вы, похоже, первый человек, загрузивший gtp на сайт, поздравляю :)
Спасибо!
Честно признаться, я расстроился, когда количество отзывов не оправдало мои ожидания, и проект немного подзабросил.
Но все еще хочу продолжить. Хотя без пользователей грустно :)
Ой. Это я зря сделал, да.
Но ссылка ничего не объясняет, кроме слова «доказано», там нет никакой аргументации.
Хотя подумав немного и вспомнив всякие удивительные явления из основ квантовой физики, я готов рассмотреть такую возможность. Может, там в самом деле можно понять, передалось что-то или нет, только связавшись между двумя точками, где проводится эксперимент, по «медленной» связи.
Ага, а на 1650 на 1080, наоборот, пока что скролл появляется.
Вместо gzip-компрессии полезнее будет начать отдавать клиенту готовый SVG, а еще начать кешировать результат преобразования gtp => xml (на моем VPS оно занимает пару секунд для среднего размера файлов), это у меня есть в планах.
Спасибо за отзыв :)
Все просто.
Табулатуры в интернете доступны давно и в огромном количестве.
Исторически они там есть в двух форматах — обычные txt, которые прочитать с листа сложно, если не знаешь мелодии (длины очень невнятно написаны), и guitar pro.
У GuitarPro для чтения табов из инета есть два недостатка — во-первых, он платный (хотя я купил), во-вторых, нельзя быстро посмотреть файл прямо в браузере (ну согласитесь, неудобно читать сайт, состоящий из сотен тысяч ссылок на .doc-файлы).
Никакой перегонки мегабайт звука в моем варианте нет, потому что вообще нет звука.
Во-первых, потому что я не придумал, как его сделать без flash'а, во-вторых, потому что это не главный use case для меня самого. Я обычно просто сижу с гитарой перед браузером и пытаюсь сыграть все подряд, что понравится (играть почти не умею, правда =) ).
Кстати, если те же ultimate-guitar.com позаимствуют мой код и сделают вместо кнопки «скачать» кнопку «посмотреть», я наверное буду рад и сочту свою миссию законченной :) А пока у меня есть мечта написать greasemonkey-скрипт, который эту кнопку у них на сайте подменит.
> инициаторы соревнования выставили в правилах необходимость отсылки им кода, который должен компилироваться и работать в условиях распространяемого Live-CD
Дело в том, что мы сначала написали набор плагинов под нашу ситуацию, которая заточена под большие кластера, грубо говоря. А нам удобнее конфигурировать все per-host и per-cluster, то есть в наших программах вообще нет ни слова о том, где лежит конфиг, все сконфигурировано заранее.
Тем не менее я понимаю, что такой подход не всех устроит (и поэтому же документация многих сбивает с толку). Надеюсь в ближайшие недели написать синтаксический сахар и туториал для биндингов конфигов в рантайме.
Хотя и сейчас уже можно забиндить в конфигурационное дерево что угодно, просто нигде это явно не сказано:
BEGIN {
our $config = ...; # загрузить конфиг откуда угодно с помощью чего угодно
}
use Morpheus -defaults => { '/foo/bar' => $config };
# либо еще проще, без BEGIN {}:
use Morpheus
$config = ...;
Morpheus->import(-defaults => { '/foo/bar' => $config });
Мы работаем над этим :)
Я лично верю, что либо серая слизь, либо Seed AI (который не обязательно конец света, но после которого человечество никогда не будет прежним), причем в ближайшие 20-30 лет. При этом серая слизь мне пока кажется вероятнее.
(код автора не читал)
(автоматическая типографика — зло! там сверху минус, а не тире.)
Не http-connect, а tcp
> Кеширование в файл будет быстрее.
Кеширование в файл не будет быстрее, потому что или у вас будет много-много файлов, или вам придется этот файл блокировать на каждое сохранение, и думать о хешировании внутри файла, и в итоге переписать memcached с нуля.
tcp-сокет, кстати, вполне быть и на localhost.
> Но memcached не нужно использовать, если у вас только один сайт.
А если у меня один сайт на FastCGI? :)
Если серьезно, благодаря разнообразию выразительных средств в perl'е развита и обратная сторона медали. Я не зря сказал о pre-commit хуках, если натравить на весь код Perl:: Critic и заставить всех соблюдать его рекомендации (это, правда, очень жестоко) — то получится результат получится куда как синтаксически чище, чем даже на python'е.
А еще бывают такие одаренные разработчики, мыслительный процесс которых позволяет им писать нечитаемый код на любом языке. Тут уж ничего не поделаешь.
Чтобы разработчики быстрее могли разобраться в архитектуре, можно использовать фреймворки, Catalyst, или что-то еще. Для Perl их немало.
Тут ситуация уже не отличается от других языков, у Python есть Zope/Django/TurboGears, для Java тоже есть много слов, которых я не знаю, но которые по функциональности друг друга перекрывают.
А на MacbookPro все летает (под тем же FF3).
Как устроен движок изнутри, я не знаю, хотя не представляю, что может мешать ему рендерить вектор в картинку и отрисовывать ее быстро. В конце концов, html тоже рендерится в некую картинку из векторных объектов-букв.
И flash тоже шустро работает, и тоже не потому, что flash бинарный, а svg — xml. Потому что все равно все они проходят через какое-то внутреннее представление сначала.
Хотя какой-то запас по оптимизации там есть, не грузить все треки в один общий DOM (там есть js при переключении между треками, но нет ajax'а), кешировать xslt-трансформацию на сервере, и тому подобное.
С png, впрочем, тоже хочется попробовать, но мне хотелось бы, наоборот, интерактива добавить.
PS. Вы, похоже, первый человек, загрузивший gtp на сайт, поздравляю :)
Честно признаться, я расстроился, когда количество отзывов не оправдало мои ожидания, и проект немного подзабросил.
Но все еще хочу продолжить. Хотя без пользователей грустно :)
Но ссылка ничего не объясняет, кроме слова «доказано», там нет никакой аргументации.
Хотя подумав немного и вспомнив всякие удивительные явления из основ квантовой физики, я готов рассмотреть такую возможность. Может, там в самом деле можно понять, передалось что-то или нет, только связавшись между двумя точками, где проводится эксперимент, по «медленной» связи.
Вместо gzip-компрессии полезнее будет начать отдавать клиенту готовый SVG, а еще начать кешировать результат преобразования gtp => xml (на моем VPS оно занимает пару секунд для среднего размера файлов), это у меня есть в планах.
Спасибо за отзыв :)
Табулатуры в интернете доступны давно и в огромном количестве.
Исторически они там есть в двух форматах — обычные txt, которые прочитать с листа сложно, если не знаешь мелодии (длины очень невнятно написаны), и guitar pro.
У GuitarPro для чтения табов из инета есть два недостатка — во-первых, он платный (хотя я купил), во-вторых, нельзя быстро посмотреть файл прямо в браузере (ну согласитесь, неудобно читать сайт, состоящий из сотен тысяч ссылок на .doc-файлы).
Никакой перегонки мегабайт звука в моем варианте нет, потому что вообще нет звука.
Во-первых, потому что я не придумал, как его сделать без flash'а, во-вторых, потому что это не главный use case для меня самого. Я обычно просто сижу с гитарой перед браузером и пытаюсь сыграть все подряд, что понравится (играть почти не умею, правда =) ).
Кстати, если те же ultimate-guitar.com позаимствуют мой код и сделают вместо кнопки «скачать» кнопку «посмотреть», я наверное буду рад и сочту свою миссию законченной :) А пока у меня есть мечта написать greasemonkey-скрипт, который эту кнопку у них на сайте подменит.
Неправда, If a team wishes to use a language or compiler that is not supported, they may submit an executable, as long as it runs in the LiveCD environment.