Здравствуйте, eao197, Вы писали:
GZ>>Немного не понял зачем тебе там Б+. Ты хочешь получать по UID другой UID?
E>Не совсем. Мне нужно будет сохранить объект, описателем которого будет является сериализованный двоичный образ его идентификатора транзакции (поскольку я не знаю, что в этом идентификаторе содержится, а вот образ однозначно уникален). И затем по идентификатору транзакции поднимать этот объект.
E>В принципе, в качестве ключа можно будет использовать хеш двоичного образа. Но на хешах нельзя строить упорядоченные множества и коллизии как-то разрешать нужно. Хотя нужно ли в этом случае упорядочение -- еще большой вопрос. E>Я просто еще не выбрал окончательного решения и обдумываю разные варианты.
По моему тут как раз и есть лучшее решения именно хеширование. Притом замесить можно даже с помощью простейшей функции типа a|=((*i)<<1). Распределение будет достаточно приличное. Вопрос только в размерах таблицы. И доступ к таблице достаточно оптимальный. В сети решений для хешей до фига.
Хотя вопрос о том, не является ли это слишком избыточным решением остается. Просто, насколько большое кол-во данных тут присутствует. Может можно обойтись stl
E>Ба! Прочитал с открытым ртом E>Если серьезно, то я не большой спец в алгоритмах.
Удивлен. Хорошо знать ООБД и не знать алгоритмы как они работают.
E>>> E>>>Вообще-то я сейчас курю по поводу libgist (GiST). Ее в PostgreSQL используют. Смущает то, что в GiST применяются непереносимые (платформно-зависимые) файлы для хранения индексов. И не понятно, как мне к своей транзакционности изменение этих индексных файлов пристегнуть. GZ>>Это мои любимые велосипеды. Для меня такое сделать самый цимес.
E>Любимые велосипеды -- это libgist что-ли?
Нет, алгоритмы. Иногда очень чудные вещи получаются. Только в коммерции за это не платят. Только когда работал на государство.
Здравствуйте, GlebZ, Вы писали:
E>>Я просто еще не выбрал окончательного решения и обдумываю разные варианты. GZ>По моему тут как раз и есть лучшее решения именно хеширование. Притом замесить можно даже с помощью простейшей функции типа a|=((*i)<<1). Распределение будет достаточно приличное. Вопрос только в размерах таблицы. И доступ к таблице достаточно оптимальный. В сети решений для хешей до фига.
Да, для данного конкретного случая я тоже так думаю. Но вот если добавлять в ObjESSty функциональность по поддержке индексов, то хотелось бы сразу сделать максимально универсальное решение.
Объемы данных, я думаю будут порядка 1M-3M значений и хранить их нужно будет в течении двух-трех дней, после чего переодически удалять устаревшие объекты (для чего еще нужен будет индекс по timestamp-у).
E>>Ба! Прочитал с открытым ртом E>>Если серьезно, то я не большой спец в алгоритмах. GZ>Удивлен. Хорошо знать ООБД и не знать алгоритмы как они работают.
Открою секрет -- я знаю мало, просто поверхам но из разных областей. Именно это, имхо, и позволило сделать ObjESSty, т.к. там есть совершенно разные задачи -- начиная от парсинга DDL и заканчавая поддержкой восстанавливаемости. Если бы я был спецом в алгоритмах, то я бы, вероятно, занимался оптимизацией работы с кешем, но до релиза бы так и не добрался
E>>>> E>>>>Вообще-то я сейчас курю по поводу libgist (GiST). Ее в PostgreSQL используют. Смущает то, что в GiST применяются непереносимые (платформно-зависимые) файлы для хранения индексов. И не понятно, как мне к своей транзакционности изменение этих индексных файлов пристегнуть. GZ>>>Это мои любимые велосипеды. Для меня такое сделать самый цимес.
E>>Любимые велосипеды -- это libgist что-ли? GZ>Нет, алгоритмы. Иногда очень чудные вещи получаются. Только в коммерции за это не платят. Только когда работал на государство.
Ну прям как я
Только я бы хотел дойти и до того, чтобы и в коммерции мне за изобретение велосипедов платили... Вот тут: Re[7]: Методология дворника.
Гигантская работа вами проделана. Почти написана объектная СУБД.
Одного я не пойму. Зачем? Чем плохи существующие ООСУБД? Почему пришлось писать свою?
Ваш продукт мне кажется очень похожим на Versant FastObjects t7. Кстати, рекомендую посмотреть на то, как там реализованы B+ tree индексы.
Здравствуйте, eao197, Вы писали:
E>Да, для данного конкретного случая я тоже так думаю. Но вот если добавлять в ObjESSty функциональность по поддержке индексов, то хотелось бы сразу сделать максимально универсальное решение. E>Объемы данных, я думаю будут порядка 1M-3M значений и хранить их нужно будет в течении двух-трех дней, после чего переодически удалять устаревшие объекты (для чего еще нужен будет индекс по timestamp-у).
Делаешь хеши допустим по 8 байт. При нормальном распределении получится вероятность конфликта — 2**64/2**20. Тут можно даже и 4 байтами обойтись. При поиске формируешь хеш, ищешь хеш, дойдя до листовых проверяешь исходные значения. Так как при конфликте все значения находятся рядом, проверяешь следующее. В результате и овцы сыты и волки целы. Работы на день с бумагой(по незнанию) и час кодирования.
E>Открою секрет -- я знаю мало, просто поверхам но из разных областей. Именно это, имхо, и позволило сделать ObjESSty, т.к. там есть совершенно разные задачи -- начиная от парсинга DDL и заканчавая поддержкой восстанавливаемости. Если бы я был спецом в алгоритмах, то я бы, вероятно, занимался оптимизацией работы с кешем, но до релиза бы так и не добрался
Открою секрет. Знание алгоритмов позволяет просто оценивать эффективность на бумажке и до реализации.
E>Ну прям как я E>Только я бы хотел дойти и до того, чтобы и в коммерции мне за изобретение велосипедов платили... Вот тут: Re[7]: Методология дворника.
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Гигантская работа вами проделана. Почти написана объектная СУБД.
Я бы сказал, на четверть написанная объектная СУБД. Нет индексов, многопользовательского режима, клиент-серверной работы.
А языка запросов так и вообще не будет (вероятно).
AR>Одного я не пойму. Зачем? Чем плохи существующие ООСУБД? Почему пришлось писать свою?
Хороший вопрос. Сам на него ответа не знаю.
Началось все еще на пятом курсе университета. Я тогда уже работал в КБ системного программирования и мы там хотели замутить супер-пупер объектно-ориентированную SCADA-систему. А поскольку SCADA предполагает интерфейс пользователя в виде мнемосхем + сохранение где-то описанных пользователем источников данных и другой мути, то решили попробовать сохранить все это (т.е. описание объектов и их графическое представление и расположение на мнемосхемах) в объектной БД. А в 1994-1995 годах ситуация с ООСУБД была достаточно интересная -- все только начиналось, казалось, что можно сделать все своими руками Плюс к тому, с Интернетом у нас в Гомеле тогда были большие проблемы и информацию о ООСУБД приходилось добывать по крупицам (спасибо журналу СУБД (который сейчас только в рамках Открытых Систем существует)), не говоря уж про сами системы. А поскольку был молодой, да ранний, то и склепал со страху почти готовую СУБД, на которой мы свою SCADA все же сделали. И даже в одном реальном проекте применили. А затем все это направление по экономическим причинам сдохло, а вскоре и я из КБ ушел.
Кроме того, первую свою СУБД Dss я делал еще и в качестве своей кандидатской дисертации. Даже сам диссер написал, только приткнуть его не куда было. Так уж сложилась моя учеба в аспирантуре -- всяко ведь бывает. Хотя работа была сделана намного бОльшая, чем сейчас. Один набор различных утилит чего стоил!
Но оглядываясь назад, думаю, что главным двигателем было желание доказать всему миру, что я могу делать подобные вещи. Типа: сделал, показал, получил приглашение в IBM
Так уж получилось, что после увольнения из КБ я не мог заниматься Dss дальше и эта разработка сама по себе зачахла. Кроме того, в техническом плане она была, как бы это сказать, написана дилетантом. Например, я использовал TCP/IP для взаимодействия между клиентом и сервером, но толком TCP/IP канал не контролировал. Но и таких плюх, думаю, там много было
А затем получил приглашение в компанию, где уже работал мой коллега по разработке SCADA. Вот мы и решили реинкарнировать нашу систему. Получилось. Но к ней захотелось еще приделать восстанавливаемость после сбоев. Для чего нужно было объектные данные переодически на диск записывать. А тогда мы как раз делали проектик, в котором по условиям заказчика, на нашей стороне не должно было быть никакой РСУБД, хотя на собственные велосипеды ограничений не было. Вот меня, как рецедивиста, на старое и потянуло
Собственно тогда (имхо, как и сейчас) выбор был между покупкой коммерческой ООСУБД, либо использованием Goods Кости Книжника, либо в создании своего хранилища. Будучи паталогическим изобретателем велосипедов, я выбрал самый трудный путь По которому ковыляю по мере сил
Я отказался от развития предыдущего проекта Dss из-за того, что Dss была жестко ориентированна на объекты фиксированного размера. А нам нужно было именно эффективно обрабатывать объекты разных размеров. Еще одним минусом Dss было то, что там были явные операции Load и Free (я вообще больше интересуюсь явной стабильностью, чем неявной, как в большинстве ООСУБД). Да и техническая часть Dss так же меня уже не устраивала.
Вот так, наверное.
Если в кратце, то основная причина -- шило в одном месте. Плюс стоимость коммерческих аналогов. Плюс, хотя это не очень этично, пока мой велосипед используется, я не очень волнуюсь о своем рабочем месте
AR>Ваш продукт мне кажется очень похожим на Versant FastObjects t7. Кстати, рекомендую посмотреть на то, как там реализованы B+ tree индексы.
С интересом посмотрю, а где можно исходники глянуть?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
AR>>Ваш продукт мне кажется очень похожим на Versant FastObjects t7. Кстати, рекомендую посмотреть на то, как там реализованы B+ tree индексы.
E>С интересом посмотрю, а где можно исходники глянуть?
Ну исходники — вряд ли. Но в документации описанию механизма индексации посвящено страниц 20 (см. Collected Technical Documentation — C++, главу 8, стр 639-...) (для доступа к документу может потребоваться регистрация на сайте).
Здравствуйте, eao197, Вы писали:
E>Началось все еще на пятом курсе университета...
Ну что тут скажешь? Внушает!
И хотя лично я являюсь ярым противником изобретения велосипедов, такой труд критиковть не решусь. Впрочем мне все равно трудно представить будущее ващей СУБД именно в связи с наличием более совершенных продуктов (разве только военные и ФАПСИшные нужды, аналогично Линтеру). А вот ваш SObjectizer мне понравился. Понравился именно своей новизной и относительной уникальностью. Возможно у него и есть сильные конкуренты, но это явно не велосипед. Впрочем, я затрудняюсь судить насколько сильна и перспективна данная технология в техническом плане. Во всяком случае любопытно, а там, глядишь, окажется, что и полезно ...
Здравствуйте, Alexey Rovdo, Вы писали:
AR>Здравствуйте, eao197, Вы писали:
E>>Началось все еще на пятом курсе университета...
AR>Ну что тут скажешь? Внушает! AR>И хотя лично я являюсь ярым противником изобретения велосипедов, такой труд критиковть не решусь. Впрочем мне все равно трудно представить будущее ващей СУБД именно в связи с наличием более совершенных продуктов (разве только военные и ФАПСИшные нужды, аналогично Линтеру).
Ну я бы хотел сделать объектно-ориентированный аналог BerkeleyDB (это в идеале, конечно). Ну и в дополнение там будет платформенно-независимый формат самой БД, чего нет в BerkeleyDB.
К тому же, главное -- это иметь готовый продукт, а уже его успешное приложение -- это сдело случая.
AR> А вот ваш SObjectizer мне понравился. Понравился именно своей новизной и относительной уникальностью. Возможно у него и есть сильные конкуренты, но это явно не велосипед. Впрочем, я затрудняюсь судить насколько сильна и перспективна данная технология в техническом плане. Во всяком случае любопытно, а там, глядишь, окажется, что и полезно ...
Спасибо за добрые слова.
У нас на SObjectizer-е все C++ продукты сделаны. Хотя из состояния велосипеда, я считаю, мы еще не вышли.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Здравствуйте, eao197, Вы писали:
E>Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
Небольшое замечание: в рахиве все файлы с x-битом установленным. ИМХО не очень удобно find напускать . Можно с чегонить
не того бит снять.
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Буду признателен за любые конструктивные предложения и замечания, в том числе и за разгромную (но объективную) критику.
A>Небольшое замечание: в рахиве все файлы с x-битом установленным. ИМХО не очень удобно find напускать . Можно с чегонить A>не того бит снять.
Здравствуйте, eao197, Вы писали:
E>Спасибо! Исправил: http://eao197.narod.ru/objessty/oess.1.4.0-b2.tar.bz2 E>Впредь постараюсь дистрибутивы под Linux-ом собирать, а то потрированные под Win утилиты вот такие фокусы откалывают.
хмм... может архив не закачал? (без прокси сливал, все равно тоже самое)
В сам код еще не смотрел, да врядли я чего-то такого скажу . Тут и без меня наговорят .
При сборке ругалось вот так:
$gcc -v
Reading specs from /usr/lib/gcc-lib/i486-linux/3.3.6/specs
Configured with: ../src/configure -v --enable-languages=c,c++,java,f77,pascal,objc,ada,treelang
--prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-gxx-include-dir=/usr/include/c++/3.3
--enable-shared --enable-__cxa_atexit --with-system-zlib --enable-nls --without-included-gettext --enable-clocale=gnu
--enable-debug --enable-java-gc=boehm --enable-java-awt=xlib --enable-objc-gc i486-linux
Thread model: posix
gcc version 3.3.6 (Debian 1:3.3.6-5)
$ ./build.rb
ar: creating lib/libcls.2.7.0.a
ar: creating lib/libsmart_ref.3.1.0.a
oess_1/util_cpp_serializer/main.cpp:136:2: warning: no newline at end of file
running unit test: ./test.reenterability...
error_count: 0
running unit test: ./test.stdsn.shptr...
launching './test.stdsn.shptr ./test.stdsn.shptr > test/stdsn/shptr/result.test'...
comparing 'test/stdsn/shptr/result.test' and 'test/stdsn/shptr/result.ok'
running unit test: ./test.stdsn.shptr.cloneable...
launching './test.stdsn.shptr.cloneable ./test.stdsn.shptr > test/stdsn/shptr.cloneable/result.test'...
comparing 'test/stdsn/shptr.cloneable/result.test' and 'test/stdsn/shptr.cloneable/result.ok'
In file included from oess_1/file/file.cpp:50:
oess_1/defs/log/h/err.hpp:40:1: warning: "LOG_ERR" redefined
In file included from /usr/include/syslog.h:1,
from ace/os_include/os_syslog.h:28,
from ace/OS.h:329,
from oess_1/file/file.cpp:48:
/usr/include/sys/syslog.h:54:1: warning: this is the location of the previous definition
ar: creating lib/liboess_zlib.1.4.0.a
ar: creating lib/libpcre.4.5.a
ar: creating lib/libpcre++.0.9.5.a
running unit test: ./test.storage.is_exists...
running unit test: ./test.storage.create...
running unit test: ./test.storage.snapshot_collection...
running unit test: ./test.stream_storage.create...
running unit test: ./test.stream_storage.entity...
running unit test: ./test.oess_db.create...
running unit test: ./test.oess_db.ent_raw...
ar: creating lib/libargs.4.3.a
In file included from test/bench/chain_storage/create_update/main.cpp:72:
test/bench/chain_storage/create_update/10000_create.cpp:1250:55: warning: no newline at end of file
In file included from test/bench/chain_storage/create_update/main.cpp:89:
test/bench/chain_storage/create_update/10000_create_half.cpp:625:56: warning: no newline at end of file
In file included from test/bench/chain_storage/create_update/main.cpp:107:
test/bench/chain_storage/create_update/10000_load.cpp:1250:46: warning: no newline at end of file
In file included from test/bench/chain_storage/create_update/main.cpp:125:
test/bench/chain_storage/create_update/10000_update_index.cpp:1250:45: warning: no newline at end of file
In file included from test/bench/chain_storage/create_update/main.cpp:151:
test/bench/chain_storage/create_update/10000_update_size.cpp:1250:56: warning: no newline at end of file
In file included from test/bench/chain_storage/create_update/main.cpp:168:
test/bench/chain_storage/create_update/10000_destroy_half.cpp:625:46: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:70:
test/bench/stream_storage/create_update/1000_create.cpp:125:55: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:87:
test/bench/stream_storage/create_update/1000_create_half.cpp:63:25: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:105:
test/bench/stream_storage/create_update/1000_load.cpp:125:38: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:123:
test/bench/stream_storage/create_update/1000_update_index.cpp:125:39: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:149:
test/bench/stream_storage/create_update/1000_update_size.cpp:125:55: warning: no newline at end of file
In file included from test/bench/stream_storage/create_update/main.cpp:166:
test/bench/stream_storage/create_update/1000_destroy_half.cpp:63:19: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:124:
test/bench/oess_db/create_update/10000_create.cpp:1250:55: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:143:
test/bench/oess_db/create_update/10000_create_half.cpp:625:56: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:163:
test/bench/oess_db/create_update/10000_load.cpp:1250:46: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:183:
test/bench/oess_db/create_update/10000_update_index.cpp:1250:45: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:211:
test/bench/oess_db/create_update/10000_update_size.cpp:1250:56: warning: no newline at end of file
In file included from test/bench/oess_db/create_update/main.cpp:230:
test/bench/oess_db/create_update/10000_destroy_half.cpp:625:46: warning: no newline at end of file
running unit test: ./sample_subextension...
running unit test: ./sample_subextension.auto_ptr...
Ну и по build системе. Почему все-таки mxx, а не какой-нить scons. Ну или может даже CMake?
C чем столкнулся:
1. Ставил ruby (не самый распространенный язык, и так в системе зоопарк: python,perl,clisp вот еще ruby)
2. Распаковывал mxx_ru в каталог с проектом, все распаковалось туда, где стоял (был в <project_root>/dev).
При этом в build.rb ссылки на mxx_ru/cpp и т.д. Неплохо былоб чтобы их архива все распаковывалось сразу в mxx_ru .
3. Поправил скрипт (ибо не везде /usr/local/bin/ruby, в дебиане например просто в /usr/bin)
4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
Неплохо было бы сделать что-то вроде .settings или чего-то похожего чтобы не править скрипт. Сценарий:
$ pwd
~/src/oess/dev
$ mkdir build-debug
$ cd build-debug
$ cp ../settings.default ./settings
$ vi settings
// правим, ставим что это DEBUG, файлы класть сюда
$ ../build.rb
...
// далее
$ mkdir build-release
// аналогично, но для release
Re[4]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, aka50, Вы писали:
A>Здравствуйте, eao197, Вы писали:
E>>Спасибо! Исправил: http://eao197.narod.ru/objessty/oess.1.4.0-b2.tar.bz2 E>>Впредь постараюсь дистрибутивы под Linux-ом собирать, а то потрированные под Win утилиты вот такие фокусы откалывают.
A>хмм... может архив не закачал? (без прокси сливал, все равно тоже самое)
С LOG_ERR поправлю. Предупреждения пострараюсь то же, но т.к. я больше работаю по Windows, но это совешенно несмертельное предупреждение и имеет тендецию появляться вновь
A>Ну и по build системе. Почему все-таки mxx, а не какой-нить scons. Ну или может даже CMake?
CMake когда-то смотрел, мне не понравилось.
Для scons-а мне бы пришлось доделывать поддержку платформы NonStop да и выбранную структуру проекта, вероятно, пришлось бы менять. А программировать на python-е мне не хотелось. Ruby больше понравился.
A>2. Распаковывал mxx_ru в каталог с проектом, все распаковалось туда, где стоял (был в <project_root>/dev). A> При этом в build.rb ссылки на mxx_ru/cpp и т.д. Неплохо былоб чтобы их архива все распаковывалось сразу в mxx_ru .
Поправлю обязательно.
A>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
Для того, чтобы скомпилировать в Debug нужно было просто указать в командной строке --mxx-cpp-debug. Аналогично для Release: --mxx-cpp-release.
A> Неплохо было бы сделать что-то вроде .settings или чего-то похожего чтобы не править скрипт. Сценарий:
Ok. На эту тему покурю. Сложного, вроде, ничего нет.
Постараюсь в ближайшее время сделать все это.
Андрей, а какую информацию о тебе в THANKS включить?
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[5]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, eao197, Вы писали:
E>>>Спасибо! Исправил: http://eao197.narod.ru/objessty/oess.1.4.0-b2.tar.bz2 E>>>Впредь постараюсь дистрибутивы под Linux-ом собирать, а то потрированные под Win утилиты вот такие фокусы откалывают.
A>>хмм... может архив не закачал? (без прокси сливал, все равно тоже самое)
E>Закачал, а в форум не ту ссылку дал: http://eao197.narod.ru/objessty/oess.1.4.0-b2-20050704.tar.bz2
Исправилось.
E>CMake когда-то смотрел, мне не понравилось. E>Для scons-а мне бы пришлось доделывать поддержку платформы NonStop да и выбранную структуру проекта, вероятно, пришлось бы менять. А программировать на python-е мне не хотелось. Ruby больше понравился.
Понятно. Если соберусь использовать посмотрю, может можно будет поверх еще CMake прикрутить. Удобнее в проекты
будет включать. К тому же у меня уже ACE+TAO есть под CMake. В общем, если че, кину патчик. Чтоб было
A>>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
E>Для того, чтобы скомпилировать в Debug нужно было просто указать в командной строке --mxx-cpp-debug. Аналогично для Release: --mxx-cpp-release.
Хмм... но тогда былоб неполохо build.rb --help чтоб работал.
Re[6]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, aka50, Вы писали:
E>>CMake когда-то смотрел, мне не понравилось. E>>Для scons-а мне бы пришлось доделывать поддержку платформы NonStop да и выбранную структуру проекта, вероятно, пришлось бы менять. А программировать на python-е мне не хотелось. Ruby больше понравился. A>Понятно. Если соберусь использовать посмотрю, может можно будет поверх еще CMake прикрутить. Удобнее в проекты A>будет включать. К тому же у меня уже ACE+TAO есть под CMake. В общем, если че, кину патчик. Чтоб было
Ok.
А почему ты MPC из ACE не используешь?
A>>>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
E>>Для того, чтобы скомпилировать в Debug нужно было просто указать в командной строке --mxx-cpp-debug. Аналогично для Release: --mxx-cpp-release. A>Хмм... но тогда былоб неполохо build.rb --help чтоб работал.
Это в документации было написано
А вот в "build.rb --help" такую штуку сделать не просто. Ведь mxx_ru как бы не только на C++ расчитан. Код по обработке C++ проектов в mxx_ru можно рассматривать как plug-in. А каждый plug-in ищет в командной строке те аргументы, которые понимает, это не сложно. А вот заставить plug-in-ы выдавать help по ключу... Чтож, можно и над этим покурить. Спасибо за идею, правда не знаю, когда до этого руки дойдут.
... << RSDN@Home 1.1.4 beta 7 rev. 447>>
SObjectizer: <микро>Агентно-ориентированное программирование на C++.
Re[7]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
A>>Понятно. Если соберусь использовать посмотрю, может можно будет поверх еще CMake прикрутить. Удобнее в проекты A>>будет включать. К тому же у меня уже ACE+TAO есть под CMake. В общем, если че, кину патчик. Чтоб было
E>Ok. E>А почему ты MPC из ACE не используешь?
Причина одна:
1. Perl.
A>>>>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
E>>>Для того, чтобы скомпилировать в Debug нужно было просто указать в командной строке --mxx-cpp-debug. Аналогично для Release: --mxx-cpp-release. A>>Хмм... но тогда былоб неполохо build.rb --help чтоб работал.
E>Это в документации было написано
Не в документации, а в target.rb еще и в cp1251
Re[8]: [ANN] ObjESSty - еще один проект сериализации
Здравствуйте, aka50, Вы писали:
E>>А почему ты MPC из ACE не используешь? A>Причина одна: A>1. Perl.
Понятно. Почти как моя причина не использовать SCons
A>>>>>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path.
E>>>>Для того, чтобы скомпилировать в Debug нужно было просто указать в командной строке --mxx-cpp-debug. Аналогично для Release: --mxx-cpp-release. A>>>Хмм... но тогда былоб неполохо build.rb --help чтоб работал.
E>>Это в документации было написано A>Не в документации, а в target.rb еще и в cp1251
Здравствуйте, eao197, Вы писали:
E>Здравствуйте, aka50, Вы писали:
E>>>А почему ты MPC из ACE не используешь? A>>Причина одна: A>>1. Perl.
E>Понятно. Почти как моя причина не использовать SCons
E>Андрей, это ты со зла E>http://eao197.narod.ru/mxx_ru/sm_html/mxx_ru_smch5.html#x11-370005.1.5
честно на сайте не глядел. Искал в архиве.
Здравствуйте, aka50, Вы писали:
A>При сборке ругалось вот так:
A>
A>oess_1/defs/log/h/err.hpp:40:1: warning: "LOG_ERR" redefined
A>
FIXED
A>2. Распаковывал mxx_ru в каталог с проектом, все распаковалось туда, где стоял (был в <project_root>/dev). A> При этом в build.rb ссылки на mxx_ru/cpp и т.д. Неплохо былоб чтобы их архива все распаковывалось сразу в mxx_ru .
FIXED
A>3. Поправил скрипт (ибо не везде /usr/local/bin/ruby, в дебиане например просто в /usr/bin)
FIXED. Теперь нужно запускать просто ruby build.rb
A>4. Увидел, что править настройки проекта надобно в самом build.rb (например Debug/не Debug) при чем вместе с output path. A> Неплохо было бы сделать что-то вроде .settings или чего-то похожего чтобы не править скрипт. Сценарий:
Для меня такое сделать самый цимес. 
