Kolhoz wrote:
> C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
> C>секунды по незагруженной 100Мбит-сети).
> Очень смешно. Все 5000x5000 надо одновременно отобразить? :-O
На принтере — вполне себе нормально.

Для отображения на экране модель упрощается, но вынести его на сервер
нельзя. Так как при приближении модели упрощенные детали должны проявляться.

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

> C>У меня идет обработка данных с измерительных устройств.
> И у меня идёт. И что?
И ничего. Я объяснил откуда у меня трехмерные данные.

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

Кстати, трехмерный отображатель, обработчик данных и измеритель у меня —
разные подсистемы (сделанные на COM). Причем конфигурация всего может
управляться из любого COM-клиента, а в само приложение встроен VBA (как
в Word/Excel).

eao197 wrote:
> C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
> C>секунды по незагруженной 100Мбит-сети).
> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в
> C>них).
> А на какой технике и сколько времени это дело обсчитывается? Если не секрет.
Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто
переполняется адресное пространство.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>>>Извините, .NET — это международный стандарт, который с Windows никак не связан.
Точка-нет алеко ещё не то что до международного стандарта, но и до отраслевого тянуться и тянуться нужно.

POSIX — семейство международных стандартов на Си API, утилиты и средсва функционирования UNIX-подобных систем. Это уже действительно международный стандарт, подтверждённый ISO и IEC.

А что там точка-нэт? Да через пять лет о ней никто и вспоминать не будет. Ну было, что-то вроде переносимого OLE.

iZEN>>Шарашка под названием ECMA, которую спонсируют Intel, Apple и Microsoft, не такая уж и иеждународная организация по стандартизации.
АХ>Ага, конечно . см. здесь.
АХ>Цитата:
АХ>

АХ>ECMA was founded in 1961 to standardise computer systems in Europe.

АХ>В 1961 ни Intel, ни Apple, ни Microsoft, ни Sun не существовало. Только IBM был.

И что? Сейчас три вышеперечисленные мною компании в открытую спонсируют ECMA, не говоря уже о мелких конторках. Но почему-то IBM и Sun не спешат присоединяться.

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

В ответ обычно примерно такое:

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

Kolhoz wrote:
> C>Мальчик, файл и VFS в юниксах — это классический пример объектного
> C>дизайна. VFS — так это вообще textbook example для полиморфизма.
> Дедушка, эта ваша фраза — типичный пример так называемого
> передёргивания, каковое является частным случаем так называемой демагогии.
А по сути ответить нет ничего?

У меня сейчас в другой программе (построитель сценариев измерения)
используется самодельный VFS, например. На нем даже grep уже есть. То
есть я банально могу построить аналог юниксовой системы с помощью ООП, а
вот наоборот — не получится.

> C>Нет. Реализован он может быть как угодно. Лично делал IStream поверх
> C>DB-блоба.
> Вы специально тормозите? Так это уже не смешно. Какая на фиг разница,
> файл, блоб, хреноб — главное, что под это нужно физическое пространство.
Его не нужно на локальном компьютере. Блоб себе лежит где-то в базе, а
на мой компьютер приходят страницы по требованию.

А вот вам пришлось бы создавать временные файлы. Кстати, можно и
вычисляемый IStream сделать.

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

M>

M>ISDKSendPtr send;

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

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

M>send -> Send();
M>

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

А чем это лучше, например, вот такого:

system( "faxsend --to '123 45 56' --company 'My Company' --subject 'My Fax'" );

?

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

>> C>Размер входной сетки — 5000х5000. Это примерно 20Мб данных (примерно 3
>> C>секунды по незагруженной 100Мбит-сети).
>> C>На выходе примерно 500Мб информации (данные о треугольниках и индексы в
>> C>них).
>> А на какой технике и сколько времени это дело обсчитывается? Если не секрет.
C>Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто
C>переполняется адресное пространство.

Ну а все-таки сколько времени занимает расчет. Подозреваю, что расчет и запись 0.5Gb данных в ОП будет занимать не меньше нескольких секунд.

eao197 wrote:
> C>Обычные современные PC. Хотя 32-бит уже хватает с трудом — часто
> C>переполняется адресное пространство.
> Ну а все-таки сколько времени занимает расчет. Подозреваю, что расчет и
> запись 0.5Gb данных в ОП будет занимать не меньше нескольких секунд.
Изначальный рассчет может занимать достаточно долго, до минут на очень
сложных примерах. На реальных примерах — порядка десяти секунд.

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

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

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

Вот вот, я и имел ввиду, точнее я этого еще не говорил Просто хотелось узнать, есть ли такое в линуксе нечто подобное. Просто в данный момент работаю над крупным проектом и тут все завязано под КОМ технологию, и стало интересно, а можно ли в линуксе как то тоже применить компонентную модель. Т.к. дома стоит Сюся и я в свободное от работы время пытаюсь писать под линукс (честно говоря плохо получается ), но дальше хелоу ворлдов не доходило.

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

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

M>>

M>>ISDKSendPtr send;

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

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

M>>send -> Send();
M>>

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

E>А чем это лучше, например, вот такого:
E>

E>system( "faxsend --to '123 45 56' --company 'My Company' --subject 'My Fax'" );
E>

Всем Ну, вернее, отсылка самого факса, конечно, практически равнозначна. А вот уже считывание факсовых событий, пробег по папкам в винфаксе и вытягивание из них сообщений может оказаться для Unix-way геморроем (пишу по памяти):

ISDKLogPtr log;
log.CreateInstance();

bstr_t folderID = log -> GetFolderFirst(FAX_FOLDER_STANDARD, L"");
if(folderID.Length() > 0)
{
    folderID = log -> GetFolderFirst(FAX_FOLDER_NONE, folderID);
    while(folderID.Length() > 0)
    {
        bstr_t messageID = log -> GetMessageFirst(folderID);
        while(messageID.Length() > 0)
        {
            bstr_t messageTo = log -> GetMessageTo(messageID);
            bstr_t messageCompany = log -> GetMessageCompany(messageID);
            bstr_t messageFax = log -> GetMessageFax(messageID);
            /* ... и так далее. Там штук 20 параметров, */
            /* включая даты, время, количество попыток, ошибки и т.д. */
            
            messageID = log -> GetMessageNext(folderID, messageID);
        }
        
        folderID = log -> getFolderNext();
    }
}

Unix-way подразумевает вызов faxsend для получения некоторого структурированного списка папок и сообщений. Этот список еще надо будет ручками распарсить и прийти, в общем, к такому же коду, что я привел, но с бОльшим геморроем (парсер-то придется писать).

Тут есть еще один грабель — пути к исполняемым фалам. В *nix же тоже есть переменная окружения PATH (это если я не ошибаюсь) То есть, faxsend на самом деле придется запускать как-то так:

/usr/local/faxsend/bin/faxsend --faxlist

А faxsend не обязательно в той папке находится В случае с COM'ом нам достаточно, чтобы WinFax был просто установлен в системе.

Но, опять же, я не против Unix-way. Он имеет право на существование и порой весьма и весьма полезен. Но он не единственный путь.

ЗЫ. WinFax'овые объекты тоже весьма Unix-way. Во-первых, возвращают только BSTR. Во вторых, функции GetMessageTime и GetMessageDate возвращают строки locale-aware. То есть, на US locale они возвращают, соответственно, "06/22/2006" и "08:01 РМ". А на RU locale — "22.06.2006" и "20:01"

Kolhoz wrote:
> C>И? Это означает, что если что-то не делать, чтобы оно работало совместно
> C>- то оно совместно работать не будет.
> Нет. Это означает — сначала сделай хороший двигатель, а потом думай,
> какой кожей обивать кресла и какого цвета будет стрелка на спидометре.
Ага, сначала сделать крутой двигатель, а потом обнаружить, что ему нужен
бензин Аи-99.

> C>OLE на интерфейс вааще пофиг. Он работает с прямоугольниками рисования и
> C>объектами данных. Как их интерпретирует приложение — личное дело самого
> C>приложения.
> Вот вот. Это и есть — ущербный и ограниченный подход, который не
> позволяет делать даже самые простейшие вещи (см. пример задачи несколько
> ранее).
Пайпы могут наливать мне кофе? Отсойная вещь! Они даже не могут код на
С++ компилировать!

OLE — это способ связывания разных компонентов и их визуального
отображения. Что делают эти компоненты внутри — OLE не волнует.
Называется это умным словом — "инкапсюляция".

Kolhoz wrote:
> K> Очень хорошим чистым и наглядным примером компонентно ориентированной
> технологии является на мой взгляд .NET.
> ?!?
Ага.

> В .NET из компонентностей есть только довольно примитивные формы RPC и
> сериализации и интерфейс ко всё тому же OLE. Ничего чистого и тем более
> наглядного не прослеживается — нет даже общей идеологии.
Назовите НЕпримитивные формы RPC.

Ну и OLE к .NET не имеет никакого отношения. Может не стоит показывать
своего незнания в обоих предметах?

> K> да даже кто то предложил увольнять все кто пользуется вордом (таких
> наверное процентов 90 от всех АйТи специалистов "которым не место в АйТи")
> А 90% и надо бы уволить. Тогда софт станет лучше и безглючнее.
Ага, конечно.

> Вы поработайте для сравнения в команде, где весь документооборот на вордах,
> и в команде, где с одной стороны docbook, а с другой —
> bugzilla+cvszilla. Поймёте, почему вторая команда будет свысока смотреть
> на первую.
Пробовал. После $#TY$OIU# с docbook в итоге перешли на Word.

И уж системы багтрекинга и SCM к формату документов не имеют никакого
отношения.

> Ламер — не тот, кто пользуется виндовсом (я вот почти только под виндовс
> и писал всегда), а тот, кто не желает думать своей головой и ведётся на
> дешевый appeal to authority.
Ага. Всякой чепухе про Unix way, например.

> Я всячески пытаюсь свести данную дискуссию к обсуждению исключительно
> объекивных технических свойств разных компонентных моделей — но
> оппоненты постоянно скатываются на ту или иную гуманитарно-религиозную
> fallacy.
Ну-ну. От вас технических возражений по сути и не было.

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

DK>>Дело в том, что распростанённость этого чуда весьма низка...
K> Ваша заява никак не вписывается в логику предыдущего вашего же утверждения.
K> Знаете, есть такой пренеприятнейший тип людей, кто не способен признавать свои ошибки и всячески старается их замазать и заболтать. Так, к сведению.
Ну, что ж вы так агрессивно настроены?
Я про гегемонию МС говорил, за которой обывателю не видны ни линУксы, ни цыгВины, ни прочие проблески разума среди пошлой коммерции.

DK>>Отсюда мораль, выживает тот, кто выживает (кого-то). (тобишь мелкомягкие)
K> А что, с X-Window что-то случилось? Вроде бы очень даже неплохо выживает. Что бы там всякие малограмотные не вещали.
У простого юзера винды НЕТ X-Window, в отличие от WinAPI, что бы там офигевшие и зазнавшиеся линуксоиды не говорили
Все мы там будем

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

M>Unix-way подразумевает вызов faxsend для получения некоторого структурированного списка папок и сообщений. Этот список еще надо будет ручками распарсить и прийти, в общем, к такому же коду, что я привел, но с бОльшим геморроем (парсер-то придется писать).

Вот насчет распарсить ручками -- это еще вопрос
Если бы faxsend был восстребованн именно в виде автономного приложения, то для парсинга его результатов уже давно были бы готовые библиотеки (вроде C++ оберток над PCRE или zlib). Возможно, даже созданные с помощью yacc/lex или antlr.

M>Тут есть еще один грабель — пути к исполняемым фалам. В *nix же тоже есть переменная окружения PATH (это если я не ошибаюсь) То есть, faxsend на самом деле придется запускать как-то так:
M>

M>/usr/local/faxsend/bin/faxsend --faxlist
M>

Вот это спорное утверждение, имхо (на счет полного пути к faxsend).

M>А faxsend не обязательно в той папке находится В случае с COM'ом нам достаточно, чтобы WinFax был просто установлен в системе.

"Просто установлен"
Помнится довелось с HTTP работать через WinInet. Так приложение сильно зависело от того, какая версия IE была на машине установлена.

В случае с внешним приложением его можно таскать с собой и запускать из собственного подкаталога. Причем именно ту версию, которую нужно. Например, я так Ruby с собой таскал, когда нужно было у заказчиков контрольную компиляцию делать.

---

На самом деле интересен подход в стиле Unix way в TIB/Rendezvous. Там демоны-router-ы работают как отдельные приложения на каждой из машин. А локальные приложения, нуждающие в TIB/Rendezvous, подключаются к локальному демону. Причем протокол там собственный, двоичный, но, тем не менее, явное разделение на компоненты, отвечающие только за одну задачу. А общение между компонентами происходит посредством библиотеки, поддерживающей протокол общения с локальным демоном. Поскольку общение с демоном идет через TCP/IP, то вместо локального демона можно легко подключится к удаленному (например, на ноутбуке пользователя может не быть локального демона, зато на его рабочей станции -- будет).

Так что Unix way можно рассматривать как стремление разнести разные задачи по разным процессам и избежать работы через общее адресное пространство и RPC механизмы. Поскольку такой подход дает надежность, масштабируемость и расширямость. Но ценой некоторых издержек. В том числе и по объему первоначального кодирования.

Просто примеры удобнее всего приводить с использованием стандартных утилит вроде tar, bzip, find, xarg, grep. Их использование в сочетании с конвейерами является наглядной, но далеко не полной иллюстрацией Unix way.

Но лично я не пытаюсь доказать, что Unix way лучше, чем COM или какая-то другая компонентная модель. Только хочу показать, что, имхо, компонентные технологии стремяться к монолитным приложениям, в которых компоненты взаимодействуют через вызовы процедур (будь то локальный вызов, или обращение к удаленному объекту посредством RPC). В то время как Unix way явно рекомендует вместо монолитных приложений создавать раздробленные на небольшие части приложения и организовывать взаимодействие между ними через другие формы IPC (а RPC следует избегать). Но без фанатизма.

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

ZEN>POSIX — семейство международных стандартов на Си API, утилиты и средсва функционирования UNIX-подобных систем. Это уже действительно международный стандарт, подтверждённый ISO и IEC.
И при чем тут компонентный подход?
Это вообще offtopic.

Windows, кстати, поддерживает POSIX.1 и пресловутые pipes:
здесь.

ZEN>А что там точка-нэт? Да через пять лет о ней никто и вспоминать не будет. Ну было, что-то вроде переносимого OLE.
Мне кажется, что ты глубоко заблуждаешься .
Еще посмотрим, когда Mono доделают как он на Unix системах развернется .

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


M>ЗЫ. WinFax'овые объекты тоже весьма Unix-way. Во-первых, возвращают только BSTR. Во вторых, функции GetMessageTime и GetMessageDate возвращают строки locale-aware. То есть, на US locale они возвращают, соответственно, "06/22/2006" и "08:01 РМ". А на RU locale — "22.06.2006" и "20:01"
Ха, так мы тут на ту же штуку напоролись, только с другой стороны в .NET.
В файле значения с плавающей точкой записаны как обычно через '.', а "умные" функции .NET использующие местную локаль, которая у меня русская, решили что они должны быть через ','.
В результате в процессе парсинга строки System.Convert.ToDouble вываливался с exception.

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


K> Опять 5*5... Эта компонентность не более мощная. Она более частная. Она реализуется тривиально поверх примитивов unix way, а вот unix way поверх объектной компонентной модели — нет. Не сравнивайте даже общее решение с частным!
Да все в точности наоборот!
Передайте от одного компонента другому имя файла и будет вам полнейший Unix way.
Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

Здравствуйте, Андрей Хропов, Вы писали:

АХ> Весь этот Unix way сводится просто к сериализации/десериализации в/из потоков (они же файлы).
АХ> Это конечно было замечательно в 70-е (и даже в 80-е) годы, но сейчас уже придумали кой-чего получше.

Что?

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

C>По странному совпадению, МСОффис безглючнее своих конкурентов.

(плотоядно потирая кулаки) Ага, щасс...
Буквально вот на днях. Есть .doc файл с вот такой растровой картинкой (откуда она взялась — не важно, скажам дали):


Элементарная задача. Требуется отредактировать картинку и заменить все надписи типа "Style=1,2,3..." на "Style=A,B,C...". Как это делается? В первую очередь пробуем банально замазать встроенным редактором и сделать новые надписи (точное соблюдение шпифта не требуется). И тут же обнаруживаем, что при выборе цвета отсутствует простейшая функция "Pick Color" и выставить в точности цвет очень непросто. Хорошо. Берем другой способ — copy/paste плюс MS Paint. Копируем изображение, вставляем его в Paint и получаем следующую порноту:


Ну вот какой кретин решил, что при копировании надо портить картинку и приводить ее к стандартным 256 цветам поносного цвета?! И это Это Office 2003! Они наверное думают, что 256 цветов — это неимоверно круто.

---

И так во всем. Другой пример. Есть некая презентация в PowerPoint. Фрагмент выгдядит так (градиентный фон не важен):

---

Селектируем его и копируем в Word. Результат:

Куда линия подевалась? Куда текст отъехал?

---

В Exel:

Та же беда, формально чуть лучше.

---

В MS Paint:

Самый адекватный результат, но опять-же, 1) цвета "отъехали" 2) пропало сглаживание шрифтов.

---

Пробуем сгруппировать выделеные элементы и снова скопировать всю группу в Word:

Прогресс! Линия появилась! Отдельная благодарность за оригинальную трактовку наклонного текста. Очень смешно — "упал пац стол"...

---

Так каков правильный способ copy-paste? Вот именно — сделать screenshot, после чего с помощью Paint вырезать нужный фрагмент и вставить его как битмап. Собственно на этом так называемые "безграничные возможности" буфера обмена и заканчиваются.

Может я чего-то не понимаю, но меня от подобной халтуры тошнит. Как вся эта помойка может нравиться, я тем более не понимаю. Ребята! Брынза не бывает зеленого цвета — это вас кто-то обманул.

Здравствуйте, Андрей Хропов, Вы писали:

АХ>Мне кажется, что ты глубоко заблуждаешься .
АХ>Еще посмотрим, когда Mono доделают как он на Unix системах развернется .
Не доделают его — это нереально.
Он обречён на отставание.
Посмотри с какой скоростью плодятся всякие C# 3.0, LINQ, ADO.NET 3, WCF, WPF и прочие buzzwords.