Здравствуйте, Cyberax, Вы писали:

C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
C>случае в юниксах эта задача не решается).

Читайте про VFS (виртуальная файловая система) и про интерфейс vnone/vfs, который чётко специфицирует организацию и функционирование любой произвольной файловой системы в UNIX. Это позволяет компонентным подходом решить задачу создания и поддержки собственной файловой системы. Этот интерфейс позволяет работать с любой файловой системой удалённо, по сети, прозрачно для пользователей и их процессов.

Через неё, кстати, "включили" "файловую" систему /proc, описывающую системные процессы, работающие в системе. Через неё приложения могут читать и писать в адресное пространство процессов. Это не pipe и не сокеты, это гораздо быстрее!

Kolhoz wrote:
> C>Или с кузова были сделаны под размер двигателя.
> Во! Начинаете понимать!
И? Это означает, что если что-то не делать, чтобы оно работало совместно
— то оно совместно работать не будет.

>> > C>Ну так покажите эти GUI. И их пользователей. Какие проблемы?
>> > Зачем? Я уже приводил пример того, что ещё лучше и что общеизвестно.
> C>Какой пример? wxMaxima? Я о нем и не слышал, хотя с учеными часто работаю.
> Wolfram Mathematica. Чистейший unix way в лучших его проявлениях. И с
> прозрачным интерфейсом к OLE2 при этом, только вот, не хватает силёнок у
> OLE для такой мощщи.
OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и
объектами данных. Как их интерпретирует приложение — личное дело самого
приложения.

iZEN wrote:
> C>Ну и иногда еще ОЧЕНЬ мешает невозможность сделать свою реализацию
> C>файлов (я знаю, что можно использовать FUSE на Линуксе, но в общем
> C>случае в юниксах эта задача не решается).
> Читайте про VFS (виртуальная файловая система) и про интерфейс
> vnone/vfs, который чётко специфицирует организацию и функционирование
> любой произвольной файловой системы в UNIX.
Еще раз. Вопрос был как мне добавить СВОЮ реализацию файла. И причем не
как драйвер в ядро.

Kisloid wrote:
> Вот исходя из того что это есть файл у меня возникает такое смутное
> сомнение что оно будет медленным. Самому их пока не приходилось
> юзать, поэтому и спрашиваю
Смотря для чего. Из моей практики — файлы в tmpfs (файловая система,
оптимизированная под временные файлы) на Linux 2.6 работали гораздо
быстрее, чем pipe'ы для передачи 10-20Кб информации.

Однако pipe'ы очень удобно использовать, если нужно обработать большой
объем информации, так как при этом не нужна временная копия.

Здравствуйте, Cyberax, Вы писали:

>> Во! Начинаете понимать!
C>И? Это означает, что если что-то не делать, чтобы оно работало совместно
C>- то оно совместно работать не будет.

Нет. Это означает — сначала сделай хороший двигатель, а потом думай, какой кожей обивать кресла и какого цвета будет стрелка на спидометре.

C>OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и
C>объектами данных. Как их интерпретирует приложение — личное дело самого
C>приложения.

Вот вот. Это и есть — ущербный и ограниченный подход, который не позволяет делать даже самые простейшие вещи (см. пример задачи несколько ранее).

dmz wrote:
> C>Как через один пайп передать два потока одновременно? Только named
> pipe'ами.
> А оно точно надо? В один поток — точно нельзя? Точно-точно?
В том случае было нельзя. Пришлось писать скрипт, который обрабатывал
эту ситуацию хитрым образом с помощью сигналов.

>> > И? Где трудности? Вставить в пайплайн xslt кто запретил?
> C>А как мне из xslt вызвать файловые операции со сторонними файлами?
> А это уже не поток. Работайте с файлами — но это уже другая история.
> XML вообще формат, не рассчитанный на работу в потоковом стиле.
> Вот хоть что делайте.
Именно. Но тем не менее, с XML замечательно можно работать компонентно:
получаем документ через SOAP, парсим MSXMLем, отдаем DOM-дерево скрипту
и т.п.

Просто это уже другая (неюниксовая) компонентность. Часто намного
более мощная, так как оперирует более мощными примитивами.

То что она более мощная не значит, что она лучше юниксовой модели —
просто у нее область применения другая.

Вот только тут некоторые товарищи считают, что все можно заключить в
прокрустово ложе пайпов и файлов в FS.

> C>COM ведь используется.
> Я так понимаю, COM что бы MSXML дергать? Ну возьмите libxml которая есть в
> питоне — и никакого кома.
Не было под рукой (я бы взял — мне MSXML не нравится). Просто это пример
как могут работать компоненты.

> C>Это я к тому, что Unix-pipes — это далеко не идеал.
> Ничто — не идеал. Гвозди — молотком, шурупы — отверткой. Ы?
Ага.

> Боюсь все эти суровые нереализуемые требования в реале сведутся к требованию
> воткнуть эхельную таблицу в ворд и там ее редактировать. Что в реальной
> жизни и под виндовс умеет крайне мало приложений — например, эхельная таблица в
> Лотус вставляется как картинка. Даже в html или rtf-не конвертируется.
Просто OLE2 — не очень простой для реализации интерфейс (MS, однако).
Его сами оффисные приложения, в основном, и поддерживают.

> С другой стороны, внутри офисных пакетов — и OO и вроде KOffice так умеют.
Умеют, но стабильно стали совсем недавно работать. А вот
inter-оффисность плохо работает

> С третьей стороны и телевизор (kmplayer) у меня вполне встраивается в
> бровзер.
> KParts — и не говорите что не стандарт. В рамках KDE такой-же стандарт,
> как ActiveX в Win.
Да, но этих стандартов много. И друг с другом они не интероперируют
нормально.

> по моему, вам просто хочется разрушить мозг оппонента, уж извините.
"That will just be a completely unintentional side effect" (c) Linus
Torvalds

> Я таки не понял, если рару нужно random access то почему бы ему просто
> не скормить файл? Из какого-то принципа? И чем в данном случае его поведение
> отличается от его поведения под win?
В Win я могу создать IStream (поток с поддержкой seek'а) над своими
данными, и отдать его rar'у (а лучше 7-zip'у).

> Была где-то ссылка на статью, где убедително доказывалось, что KDE — это
> Unix Way в полный рост. Стало быть, не провалились.
Я в KDE постоянно работаю. Не заметно Unix-way

> На самом деле, Unix way это не что иное, как принцип K.I.S.S. И ничего
> более.
Э! Нет. Unix way — это Unix way.

eao197 wrote:
> C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
> C>текущего проекта предлагаете на сервер вынести?
> Это зависит от расчета и от того, что является результатом расчета.
> Может быть его нужно не то что на один сервер, а на отдельный high
> perfomance кластер выносить.
Проблема в том, что результат рассчета часто будет передаваться по сети
дольше, чем считаться.

Здравствуйте, Cyberax, Вы писали:

C>Просто это уже другая (неюниксовая) компонентность. Часто намного
C>более мощная, так как оперирует более мощными примитивами.

Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!

C>Вот только тут некоторые товарищи считают, что все можно заключить в
C>прокрустово ложе пайпов и файлов в FS.

А сокеты как же?

C>В Win я могу создать IStream (поток с поддержкой seek'а) над своими
C>данными, и отдать его rar'у (а лучше 7-zip'у).

И реализован он будет через временный файл. Оно нам надо?

Здравствуйте, Cyberax, Вы писали:

C>Проблема в том, что результат рассчета часто будет передаваться по сети
C>дольше, чем считаться.

А подробнее?
По какой сети?
Какие объемы данных?

Здравствуйте, Cyberax, Вы писали:

C>Проблема в том, что результат рассчета часто будет передаваться по сети
C>дольше, чем считаться.

Он не может передаваться сильно дольше чем потребуется на его отображение.
Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики уровня 3D-стрелялок ничего представить не могу, что требовало бы связывать в один контекст логику и отображение. А если таки потребуется — я всё равно unix way применю. Только внутри одного контекста. Не знаете, как? А вот я — знаю. Производительность будет неотличима от производительности прямого вызова API. Завидуете?

eao197 wrote:
> C>Проблема в том, что результат рассчета часто будет передаваться по сети
> C>дольше, чем считаться.
> А подробнее?
> По какой сети?
100Mbit. Да даже и гигабит не поможет.

> Какие объемы данных?
На входе массив точек — двумерная карта высот. На выходе — треугольная
сетка с индексами для некоторых операций.

Kolhoz wrote:
> C>Проблема в том, что результат рассчета часто будет передаваться по сети
> C>дольше, чем считаться.
> Он не может передаваться сильно дольше чем потребуется на его отображение.
Ага.

Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
секунды по незагруженной 100Мбит-сети).

На выходе примерно 500Мб информации (данные о треугольниках и индексы в
них).

> Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики
> уровня 3D-стрелялок ничего представить не могу, что требовало бы
> связывать в один контекст логику и отображение.
У меня идет обработка данных с измерительных устройств.

> А если таки потребуется — я всё равно unix way применю.
Ага. И изображать данные будете через пайпы. А управлять вращениями
частей — задавая координаты кватернионов из командной строки.

> Только внутри одного контекста. Не знаете, как?
Через пайпы? Так это много ума не надо.

FR wrote:
> C>Агащазблин. Рассчет 3D-поверхностей и работу с ними вы мне тоже из моего
> C>текущего проекта предлагаете на сервер вынести?
> Ну формально легко выносится, даже OpenGL именно на этой идеологии построен
Во-первых, отображение сгенерированных данных — это фигня. Залил display
list на сервер — и дальше просто меняешь ему преобразования.

Kolhoz wrote:
> C>Просто это уже *другая* (неюниксовая) компонентность. Часто намного
> C>более мощная, так как оперирует более мощными примитивами.
> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она
> реализуется тривиально поверх примитивов unix way, а вот unix way поверх
> объектной компонентной модели — нет. Не сравнивайте даже общее решение с
> частным!
Мальчик, файл и VFS в юниксах — это классический пример объектного
дизайна. VFS — так это вообще textbook example для полиморфизма.

> C>Вот только тут некоторые товарищи считают, что все можно заключить в
> C>прокрустово ложе пайпов и файлов в FS.
> А сокеты как же?
Ой, да я про сокеты забыл. Они ведь все проблемы Вселенной решают.

> C>В Win я могу создать IStream (поток с поддержкой seek'а) над своими
> C>данными, и отдать его rar'у (а лучше 7-zip'у).
> И реализован он будет через временный файл. Оно нам надо?
Нет. Реализован он может быть как угодно. Лично делал IStream поверх
DB-блоба.

C>>Создается компонент (написанный на С++) и прозрачно используется из
C>>совершенно другого языка (о котором создатель компонента мог и не
C>>догадываться).

K> Какое извращение. Интерфейсы какие-то выдумывать... Гораздо проще — на любом языке создаётся компонент, который знает только про текстовые потоки и аргументы коммандной строки.

Как представлю себе десериализацию из тестового потока в каком-нить С++

Куда как лучше (не без помощи форума COM/DCOM/ActiveX) написать такое (отсылка факса с помощью Symantec WinFax Pro):

ISDKSendPtr send;

send -> SetTo(L"123 45 56");
send -> SetCompany(L"My Company");
send -> SetSubject(L"My Fax");
send -> SetPrintFromApp(TRUE);

/* Печатаем на принтер WinFax*/

send -> Send();

Красота! Считывание пришедших сообщений — в таком же стиле. Ну, COM'овском.

Mamut wrote:
> Как представлю себе десериализацию из тестового потока в каком-нить С++
Сейчас вам скажут, что надо использовать S-выражения, которые еще и
выполняться сами могут

C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
C>секунды по незагруженной 100Мбит-сети).

Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O

C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в
C>них).

Значит это ещё не выход.

>> Так что не надо предрассудков. Проверьте сначала. Я вот кроме графики
>> уровня 3D-стрелялок ничего представить не могу, что требовало бы
>> связывать в один контекст логику и отображение.
C>У меня идет обработка данных с измерительных устройств.

И у меня идёт. И что?

>> А если таки потребуется — я всё равно unix way применю.
C>Ага. И изображать данные будете через пайпы. А управлять вращениями
C>частей — задавая координаты кватернионов из командной строки.

Никаких пайпов.

>> Только внутри одного контекста. Не знаете, как?
C>Через пайпы? Так это много ума не надо.

Я же сказал — Внутри. Одного. Контекста. Какие пайпы, блин! Это ОДИН ПРОЦЕСС. С общей памятью. Физически. А логически — две отдельные программы, обменивающиеся сообщениями.

Здравствуйте, Cyberax, Вы писали:

C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
C>секунды по незагруженной 100Мбит-сети).

C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в
C>них).

А на какой технике и сколько времени это дело обсчитывается? Если не секрет.

>> Как представлю себе десериализацию из тестового потока в каком-нить С++
C>Сейчас вам скажут, что надо использовать S-выражения, которые еще и
C>выполняться сами могут

Я, в принципе, не против Unix-way. Просто при росте сложности системы, имхо, что-то вроде COM'a начинает рулить намного сильнее, чем попытка связать воедино с десяток разрозненных программ. С другой стороны, десяток разрозненных программ удобны для автоматизации. Сбацал скрипт, их связывающий, повесил на cron и отдыхаешь.

Здравствуйте, Cyberax, Вы писали:

C>Мальчик, файл и VFS в юниксах — это классический пример объектного
C>дизайна. VFS — так это вообще textbook example для полиморфизма.

Дедушка, эта ваша фраза — типичный пример так называемого передёргивания, каковое является частным случаем так называемой демагогии.

>> И реализован он будет через временный файл. Оно нам надо?
C>Нет. Реализован он может быть как угодно. Лично делал IStream поверх
C>DB-блоба.

Вы специально тормозите? Так это уже не смешно. Какая на фиг разница, файл, блоб, хреноб — главное, что под это нужно физическое пространство. Следовательно — избегать надо подобных приколов, за исключением самых крайних случаев.