Тогда уж давай ссылку и на Windows-way.

неа. связи какие-то больно черезжопные. юниксвей - это конвеер.

> неа. связи какие-то больно черезжопные. юниксвей - это конвеер.

это просто одмын попался криворукий.

// wbr

Пайпы слишком неуниверсальные.

>это просто одмын попался криворукий.

<тут я отвечаю офигенно талантливым стишком-пародией "Дом, который построил Одмин">

Именно на это и похоже, когда в 2009 году люди обрабатывают данные парсингом plaintext-а.

блин!
я в такую игрушку в детстве гамался.
Как называется, помнит кто-нибудь? так, просто ради развития памяти.

> Как называется, помнит кто-нибудь? так, просто ради развития памяти.

Incredible Machines вестимо. есть ещё продолжение, для винды. но оно уже как-то не попёрло.

// wbr

О прогрессфаны пришли.

The Incredible Machine, сокращённо TIM. Отличная игра, да.

windoze way

http://www.tretyakovgallery.ru/pictures/c/c8/c84d0c6b56f7f95ebafd38f405103489...

>> Именно на это и похоже, когда в 2009 году люди обрабатывают данные парсингом plaintext-а.

+1

> Именно на это и похоже, когда в 2009 году люди обрабатывают данные парсингом plaintext-а.

При администрировании Windows тоже очень часто парсят plaintext в командной строке (просто потому что это удобно), получается нет систем для 2009-го года?

>> При администрировании Windows тоже очень часто парсят plaintext в командной строке (просто потому что это удобно), получается нет систем для 2009-го года?

Для небольших админских (и просто служебных) сриптов это какраз применимо. Но когда такой подход пихают везде куда только можно, не задумываясь про оверхед, создаваемый многократным перегоном данных в текст и обратно, а так же постоянным запуском кучи процессов, то это уже unix-маразм.

> Для небольших админских (и просто служебных) сриптов это какраз применимо. Но когда такой подход пихают везде куда только можно, не задумываясь про оверхед, создаваемый многократным перегоном данных в текст и обратно, а так же постоянным запуском кучи процессов, то это уже unix-маразм.

Согласен. Просто в сообщении, на которое я отвечал был намек на то, что в современных условиях парсинг вообще должен быть не у дел, без уточнений.

Кстати, а можно конкретный пример такой перегруженной реализации?

>> Кстати, а можно конкретный пример такой перегруженной реализации?

Разные "системы учёта трафика" в которых логи squid'а парсятся sarg'ом, потом выхлоп sarg'а парсится perl-криптом и данные записываются в какую-нибудь базу данных.

Ещё в качестве примера как НЕ НАДО делать я бы привёл сразу все многочисленные морды к mplayer'у и морды к CLI-программам вообще. Кроме случаев когда эти программы имеют чётко специфицированный текстовый интерфейс (вроде Universal Chess Interface).

P.S. Это всё было мо ИМХО.

> Ещё в качестве примера как НЕ НАДО делать я бы привёл сразу все многочисленные морды к mplayer'у и морды к CLI-программам вообще. Кроме случаев когда эти программы имеют чётко специфицированный текстовый интерфейс (вроде Universal Chess Interface).

Ну у mplayer есть slave mode, не знаю как это подходит под определение специализированного текстового интерфейса.

>> Ну у mplayer есть slave mode, не знаю как это подходит под определение специализированного текстового интерфейса.

Подходит, но только на половину. Там чётко описаны только команды которые понимает mplayer. А вот с обратной связбю - жопа. Единственный выход - это заготавливать кучу регекспов с учётом разных локализаций. Но это просто убермегакостыль. Переводчик (или разработчик) исправил опечатку в тексте - и всё, парсинг выхлопа mplayer'а в лучшем случае перестаёт работать. В худшем - выдаёт неправильную иформацию.

О, даже вещества есть!

> О, даже вещества есть!

Где? Помимо тротила и сыра.

> Как называется, помнит кто-нибудь? так, просто ради развития памяти.

The Incredible Machine, много где есть для скачки, с DOSBOX-ом в комплекте :) Идет даже на маке :)

>> Где? Помимо тротила и сыра.

Две пробирки с в-вами.

Mac-way

http://img177.imageshack.us/img177/951/macgoodweirduglybn0.jpg

http://img301.imageshack.us/my.php?image=wrongholelh8.jpg

http://img150.imageshack.us/my.php?image=linuksmb0.jpg

> Где? Помимо тротила и сыра.

Человечка вверху справа видишь? Это Орлангурыч, а рядом - они.

Ну и ещё одна в противоположном конце картинки, что символизирует.

>Подходит, но только на половину. Там чётко описаны только команды которые понимает mplayer. А вот с обратной связбю - жопа. Единственный выход - это заготавливать кучу регекспов с учётом разных локализаций. Но это просто убермегакостыль. Переводчик (или разработчик) исправил опечатку в тексте - и всё, парсинг выхлопа mplayer'а в лучшем случае перестаёт работать. В худшем - выдаёт неправильную иформацию.

LANG=C - вот тебе и свобода от криворуких переводчиков. а локализацию к морде всеравно свою собственную прикручивать придется.

> Две пробирки с в-вами.

Понятно, спасибо. А что они делают?

> LANG=C - вот тебе и свобода от криворуких переводчиков. а локализацию к морде всеравно свою собственную прикручивать придется.

Сам-то пробовал, что пишешь? mplayer игнорирует LANG=C.

действительно, однако и какой-либо локализации мплеера я не вижу - все одно на добром ингрише пишет %)

> однако и какой-либо локализации мплеера я не вижу - все одно на добром ингрише пишет %)

Имхо, задаётся при компиляции и потом не сменишь.

>> LANG=C - вот тебе и свобода от криворуких переводчиков.

1) Проблема никак не зависит от криворукости переводчиков.

2) Разработчики точно так же могут изменить оригинальный английский текст. Имеют полное право.

>Именно на это и похоже, когда в 2009 году люди обрабатывают данные парсингом plaintext-а.

О, великий! Научи, как правильно? Мышкойтыц?

>> О, великий! Научи, как правильно? Мышкойтыц?

Быдлоанонизмусы не знают ничего кроме мышкойтыц и былокодинга на пёрле?

>Быдлоанонизмусы не знают ничего кроме мышкойтыц и былокодинга на пёрле?

Применительно к быдло-plaintext-у? Нет. Быдлоанонизмусы не знают ничего кроме мышкойтыц и былокодинга на [пёрле,sed,awk,etc]

Может быть, быдлонеймофаг решительно снизойдет и научит?

>> Может быть, быдлонеймофаг решительно снизойдет и научит?

К сожалению анонизмусов уже ничего не спасёт. Такова их горькая участь.

>К сожалению анонизмусов уже ничего не спасёт. Такова их горькая участь.

да, +1

а по делу есть что ответить столь же четко и определенно?

>> а по делу есть что ответить столь же четко и определенно?

Отказаться отплейнтекста? Для всего уже есть нормальные библиотеки и API под тот же perl и python. Я уже не говорю про C.

>Отказаться отплейнтекста? Для всего уже есть нормальные библиотеки и API под тот же perl и python. Я уже не говорю про C.

Феерично! Ты, надеюсь, пошутить хотел? У тебя почти получилось.

/me не верит в существование столь совершенного долбоёба, решившегося заявить такое на полнос серьёзе.

с: plaens

> Единственный выход - это заготавливать кучу регекспов с учётом разных локализаций. Но это просто убермегакостыль. Переводчик (или разработчик) исправил опечатку в тексте - и всё, парсинг выхлопа mplayer'а в лучшем случае перестаёт работать. В худшем - выдаёт неправильную иформацию.

другой выход -- сделать что-то вроде plumbing в Plan 9.

> Быдлоанонизмусы не знают ничего кроме мышкойтыц и былокодинга на пёрле?

ну отчего же, можно что-нибудь сочинить эдакое. Сейчас пайпы служат для подключения одного выхлопа в std. формате во вход другого. Из std. текстового формата следует изотропия макр^W^W разбираемость read/write в REPL ^W^W^W^W^W^W возможность стыковки. Но отсутствует возможность описать конкретный "интерфейс": ВЕСЬ выхоп разбирается. Тогда как если бы можно было иметь не один stdout с сотней ключей, а по отдельному ключу иметь каждый раз новый отдельный поток (тоже текстовый, да). И стыковать вот эти потоки отдельных интерфейсов. Если не нравится текстовый вид и затраты на парсинг -- можно придумать схему кеширования текст-бинарник. То есть, строить тот же граф из разных программ в конвейере, но упор не на узлы в графе -- программы с выхлопом в одну кучу, а рёбра-интерфейсы. Можно что-то вроде plumbing придумать для интроспекции интерфейсов.
Это, а мы тут не d-bus изобретаем?

>Из std. текстового формата следует изотропия макр^W^W разбираемость read/write в REPL ^W^W^W^W^W^W возможность стыковки. Но отсутствует возможность описать конкретный "интерфейс": ВЕСЬ выхоп разбирается. Тогда как если бы можно было иметь не один stdout с сотней ключей, а по отдельному ключу иметь каждый раз новый отдельный поток (тоже текстовый, да). И стыковать вот эти потоки отдельных интерфейсов.

ну ты что-то совсем круто накрутил!

не так уж и часто требуется несколько потоков, и очень часто требуется разбирать именно весь выхлоп.

для остальных же случаев есть быдлокодинг в REPL

> не так уж и часто требуется несколько потоков

у Витуса Вагнера про True Unix GUI было что-то про разные потоки. Дескать, полезно было бы звук по одному потоку, картинку по другому, кнопки/логи по третьему. А plumbing по этим потокам это да, отсебятина.

> для остальных же случаев есть быдлокодинг в REPL

быдлокодинг в REPL всё равно 100% вызовется, а хочется лениво закешировать, и вызывать заново только если параметры среды изменились

Лучше сразу перейти к message-passing и dataflow-модели. Некоторые виды задач на нее отлично ложатся в самом что ни на есть unix-way'е.

>Дескать, полезно было бы звук по одному потоку, картинку по другому, кнопки/логи по третьему.

не, ну зачем нам звучащие картинки?

говно полезло с словами: " когда в 2009 году люди обрабатывают данные парсингом plaintext-а"

то, что речь шла именно о plaintext-данных, косвенно подтверждается предложением "отказаться от плайнтекста"

вот. а для такого дела, имхо, обычного конвеера вполне хватает. в основном.

>> Отказаться отплейнтекста? Для всего уже есть нормальные библиотеки и API под тот же perl и python. Я уже не говорю про C.

> Феерично! Ты, надеюсь, пошутить хотел? У тебя почти получилось.

Не выдерайте фразу из контекста.

> с: plaens

А ну в прочем всё с вами ясно...

>закешировать, и вызывать заново только если параметры среды изменились

ну, это уж совсем запредельная задача получается. В смысле, за пределами применимости [perl sed awk etc]

>> другой выход -- сделать что-то вроде plumbing в Plan 9.

Спасибо, прочитал про plumbing. Интересная штука...

>> Это, а мы тут не d-bus изобретаем?

Ага. DBus - это одно из возможных решений.

Забавно.

>Не выдерайте фразу из контекста.

не напомнишь, какие еще фразы были в том посте, из которого я выдрал?

> Отказаться отплейнтекста? Для всего уже есть нормальные библиотеки и API под тот же perl и python. Я уже не говорю про C.

похоже, кто-то решил отказаться от моска.

Кстати, как ты себе представляешь такой "отказ"? (Даже не спрошу, чем ты его предлагаешь заменить, допустим, это будет некий мегформат X3)

тогда получается такая цепочка:

текс => быдопарсерtxtна[perl,awk,sed,C] =>txt2X3 => быдлопарсерX3на[perl, python, C]

профит??