Re: Файловые системы, файлы, приложения - устаревшие концепц - Философия программирования

Привет Всем!

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

ИМХО лучше быть может.

Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.

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

В ОС основанной на ОБД можно сделать по другому. При создании экземпляра класса он существует всегда пока его не собрал сборщик мусора. Не зависимо от того, включен комп или выключен, используется ли этот экземпляр в данное время пользователем или нет — экземпляр существует. Вопрос в каком виде? Он может быть вытеснен в хранилище объектов на HD или быть загружен в RAM — по аналогии со swap fail современных ОС. Важное отличие в том, что экземпляры не уничтожаются при перегрузки ОС. Все приложения всегда находятся в запущеном состоянии. Если пользователь не использует текстовый процессор — то процессор находится в hibernate сотоянии. Так же нет понятия открыть-закрыть текстовый документ. Все текстовые документы этого процессора всегда загружены в виртуальное адресное пространство этого текстового процессора. Те которые не используются вытеснены на HD, те которые пользователь редактирует в данный момент находятся в RAM. Мало того — граница между приложениями стерта. Есть не приложения а компоненты. И эти компоненты используются совместно. Компонент "текстовый файл" совместно с компонентом "текстовый процессор" позволяет редактировать собственное содержание но как в OLE контейнере находится в ячейке электронной таблицы — которая тоже некоторый экземпляр хранимый в этой ОС-ООСУБД...

Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

С уважением, Дмитрий.

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

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

1. Производительность
2. Updates, patches и новые версии
3. Перенос данных, многопользовательская работа
4. Разработка

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

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

S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

M>1. Производительность
M>2. Updates, patches и новые версии
M>3. Перенос данных, многопользовательская работа
M>4. Разработка

J2EE EJB соответствует этой модели. Заморочки с производительностью только у Stateful Bean's.

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

S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

Все решаемо:

M>1. Производительность
Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.

M>2. Updates, patches и новые версии
В ОБД для этого применяют версионнинг объектов.

M>3. Перенос данных, многопользовательская работа
Еще лучше чем сейчас. качественная реализация СУБД поддерживает многопользовательскую работу. В режиме клиент-сервер можно будет шарить не только данные но и приложения. Какая перспектива для MS по сдаче в аренду компилятора C# крутящегося на TeamServer )))

M>4. Разработка
Аналогично современным методам разработки на C# но без заботы о старте-шатдоуне приложений. Экземпляр будучи создан не умирает пока не будет собран сборщиком мусора не зависимо от состояния ОС. В некотором смысле даже проще.

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

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

S>>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

S>Все решаемо:

M>>1. Производительность
S>Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.

Нет. Объектная персистентность — дорогое удовольствие. Чтобы поднять объект из хранилища, нужно заново его инстанцировать (сконструировать) из класса, считать сохранённое состояние (поля) из долговременного хранилища (с диска и/или из БД) и присвоить эти сохранённые (старые) значения, восстановив тем самым прежнее состояние объекта. Но это чертовски медленно по сравнению с бинарным hibernate в существующих реализациях операционных систем.

M>>2. Updates, patches и новые версии
S>В ОБД для этого применяют версионнинг объектов.

M>>3. Перенос данных, многопользовательская работа
S>Еще лучше чем сейчас. качественная реализация СУБД поддерживает многопользовательскую работу. В режиме клиент-сервер можно будет шарить не только данные но и приложения. Какая перспектива для MS по сдаче в аренду компилятора C# крутящегося на TeamServer )))

Это уже есть и работает. Технология JINI.

M>>4. Разработка
S>Аналогично современным методам разработки на C# но без заботы о старте-шатдоуне приложений. Экземпляр будучи создан не умирает пока не будет собран сборщиком мусора не зависимо от состояния ОС. В некотором смысле даже проще.

Уже есть и работает под управлением распределённого GC.

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

M>>>1. Производительность
S>>Будет такая же или выше по сравнению с текущей ОС. Пример. Запустить Эксель и Ворд. Переключаться между окнами (при условии что оба выгружены в swapfile). Это и будет скорость старта приложения — оно будет подниматься из ОБД так же как поднимается сейчас из swapfile.

ZEN>Нет. Объектная персистентность — дорогое удовольствие. Чтобы поднять объект из хранилища, нужно заново его инстанцировать (сконструировать) из класса, считать сохранённое состояние (поля) из долговременного хранилища (с диска и/или из БД) и присвоить эти сохранённые (старые) значения, восстановив тем самым прежнее состояние объекта. Но это чертовски медленно по сравнению с бинарным hibernate в существующих реализациях операционных систем.

А кто мешает сделать восстановление объектов в ОБД бинарной?
Надо всего лишь встроить ОБД в ядро ОС а не пользоваться промежуточными слоями в виде RDB & ORM.

M>>>3. Перенос данных, многопользовательская работа
ZEN>Это уже есть и работает. Технология JINI.
M>>>4. Разработка
ZEN>Уже есть и работает под управлением распределённого GC.

именно. уже есть и работает. осталась интеграция в ядро ОС.

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

S>Привет Всем!

S>...

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

, так сказать с чистого листа

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

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

Некоторые характеристики предполагаемой "ОС будущего" роднят ее с созданной еще в 80-х ОС Оберон, например:
1) система состоит из компонентов, а не изолированных приложений;
2) динамическая загрузка по требованию;
3) сборка мусора;
4) постоянные (persistent) объекты;
5) свободное внедрение объектов в документы.

Поэтому, возможно, предшествующий опыт может быть интересен.
Дизайн ОС Оберон подробно описан в книге "Project Oberon":
http://www.oberon2005.ru/book/ponw2005e.pdf

Есть и различия.
Вы исходите из того, что "приложение это набор экземпляров классов".
Поэтому у Вас нет файлов, а есть объектная база данных.
ОС Оберон строится из модулей (которые, конечно, могут определять классы), поэтому файлы там есть.

"Оберонщики" обосновывают необходимость модулей как отдельного строительного элемента системы, не совпадающего с классом. Например, Шиперски в своей статье "Import is Not Inheritance. Why We Need Both: Modules and Classes":
http://www.oberon2005.ru/paper/p_modcla.pdf

Большое значение в Обероне придается безопасности типов, в т.ч. межмодульной, основанной на понятии раздельной (не независимой) компиляции. Изобретены интересные механизмы, позволяющие сохранять одновременно целостность и гибкость системы. Например, в статье Crelier "Separate Compilation and Module Extension":
http://www.oberon2005.ru/paper/eth10650.pdf

Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля.
В принципе, это решаемая проблема.
За основу решения можно взять хотя сборки, как в .NET.

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

AVC>Поэтому, возможно, предшествующий опыт может быть интересен.
AVC>Дизайн ОС Оберон подробно описан в книге "Project Oberon":
AVC>http://www.oberon2005.ru/book/ponw2005e.pdf

Огромное спасибо за ссылку. Обязательно воспользуюсь в разработке собственной .NET ООСУБД

AVC>Есть и различия.
AVC>Вы исходите из того, что "приложение это набор экземпляров классов".
AVC>Поэтому у Вас нет файлов, а есть объектная база данных.

Да. в ОБД нет понятия файлов и RAM. по new выделяется объект. А где он расположен физически, на HD или в RAM — дело СУБД-ОС а не программиста. Пока на объект есть ссылки — он существует. Если он не используется в данное время — то объект занимает место на HD. Если используется — его копия загужается в RAM пока место в RAM не потребуется другому более свежему объекту. Полная аналогия с swapfile.

AVC>ОС Оберон строится из модулей (которые, конечно, могут определять классы), поэтому файлы там есть.

AVC>"Оберонщики" обосновывают необходимость модулей как отдельного строительного элемента системы, не совпадающего с классом. Например, Шиперски в своей статье "Import is Not Inheritance. Why We Need Both: Modules and Classes":
AVC>http://www.oberon2005.ru/paper/p_modcla.pdf

С этим согласен. namespaces, assemblies нужны. Но они тоже могут быть объектами ОБД а вовсе не файлами. По аналогии с тем же .NET сборка может быть System.Reflection.Assmbly а вовсе не файлом. И иметь методы Emit для генерации кода прямо внутрь объекта.

AVC>Большое значение в Обероне придается безопасности типов, в т.ч. межмодульной, основанной на понятии раздельной (не независимой) компиляции. Изобретены интересные механизмы, позволяющие сохранять одновременно целостность и гибкость системы. Например, в статье Crelier "Separate Compilation and Module Extension":
AVC>http://www.oberon2005.ru/paper/eth10650.pdf

AVC>Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля.
AVC>В принципе, это решаемая проблема.
AVC>За основу решения можно взять хотя сборки, как в .NET.

Да. сложностей с просто выгрузкой не будет, так как не будет понятия файла и выгружать просто нечего и некуда. А объекты они и так в связаном графе и друг друга блокируют, но не от выгрузки а от удаления сборщиком мусора.

А вот что очень сложно — так это поддержка версионности объектов при необходимости updates но и это решаемо. В промышленных ОБД для этого применяют метаниформацию, по аналогии с сборщиками мусора Java/.NET которые по живому исправляют содержимое регистров процессора — в ОБД по живому исправляют лайоут экземпляров на основании изменившихся методанных классов. Сложно но реализуемо.

Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.

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

ZEN>J2EE EJB соответствует этой модели. Заморочки с производительностью только у Stateful Bean's.

В J2EE EJB нет такого понятия как файл?

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

Ryf>идея нравится, но как приятно иногда начать работу после того как комп перезагружен

, так сказать с чистого листа

Так или иначе но потихоньку это просто обязано становиться прошлым.
Приложения должны конструироваться чтобы все время работать как чистый лист.
Управляемые среды это как раз большой шаг в эту сторону.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

Мне кажется, что подводный камень это то, что работать в некоторых вопросах станет труднее.
Я уже тут веду как раз обсуждения на тему этого с разработчиком другой ООБД.

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

Почему? Потому что эта грань несет кроме сложностей еще и пользу. Как то — контроль производительности (все-же простите меня но доступ в ОЗУ всегда будет существенно быстрее чем в более медленное, но более емкое хранилище), возможность контроллировать доступ — делать объекты публичными или работать локально, возможность иметь бесплатную систему откатов изменений, возможность контролировать транзакции и т.п.

Ну а в вашей реализации подводные камни это:
1. Сложность задачи — не справиться гораздо проще, чем кажется по дороге
2. Технические возможности — вы все таки не можете писать свою ОС и тягаться в производительности со своп файлом трудно
3. Как результат производительность
4. Сложные схемы работы для программиста — они не захотят разбираться или многим это будет неудобно

Вот так я думаю.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Mystic wrote:
> ZEN>J2EE EJB соответствует этой модели. Заморочки с производительностью
> только у Stateful Bean's.
> В J2EE EJB нет такого понятия как файл?
Нет. В чистой J2EE даже синглтонов нет

Posted via RSDN NNTP Server 2.0

Забыл сказать. На мой взгляд, ключевая необходимость в хранилище еще и в том, что хранилище должно позволять вам легко находить нужные объекты среди миллиардов других. Иначе вы будете иметь массу проблем в сколько-нибудь сложных системах.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>namespaces, assemblies нужны. Но они тоже могут быть объектами ОБД а вовсе не файлами. По аналогии с тем же .NET сборка может быть System.Reflection.Assmbly а вовсе не файлом. И иметь методы Emit для генерации кода прямо внутрь объекта.

Наверное, да.
По крайней мере, пока не вижу причин, делающих это невозможным.

AVC>>Я вижу единственную серьезную проблему у такой системы: т.к. она основана не на процессах (отдельных приложениях), то модули и объекты могут "сбиться" в один связный граф, что может затруднить выгрузку модуля.
AVC>>В принципе, это решаемая проблема.
AVC>>За основу решения можно взять хотя сборки, как в .NET.

S>Да. сложностей с просто выгрузкой не будет, так как не будет понятия файла и выгружать просто нечего и некуда. А объекты они и так в связаном графе и друг друга блокируют, но не от выгрузки а от удаления сборщиком мусора.

В Обероне проблем с уничтожением ненужных объектов ( =сборкой мусора ) тоже нет.
А вот с выгрузкой модулей — есть.
Дело в том, что модуль (кроме прочего) — хранилище кода. Объект ссылается на хранимые в модуле методы, что, IMHO, и создает проблему.
Получается, что на модуль существуют как явные ссылки (через отношение импорта), так и неявные (через объекты).
Пока что я не придумал лучшего варианта, чем использовать механизм сборок.
Не снабжать же каждый объект своей копией кода.

S>А вот что очень сложно — так это поддержка версионности объектов при необходимости updates но и это решаемо. В промышленных ОБД для этого применяют метаниформацию, по аналогии с сборщиками мусора Java/.NET которые по живому исправляют содержимое регистров процессора — в ОБД по живому исправляют лайоут экземпляров на основании изменившихся методанных классов. Сложно но реализуемо.

Интересно, хотя и правда сложно.

S>Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.

А методов?

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

iZEN>>J2EE EJB соответствует этой модели. Заморочки с производительностью только у Stateful Bean's.
M>В J2EE EJB нет такого понятия как файл?
Нет. Система выполнения EJB и непосредственно Bean's имеют понятие только об источнике данных, неважно каком. Конкретный источник данных (файл, байтовый поток, БД и т.д.) определяются в дескрипторе развёртывания. EJB работает только с интерфейсом доступа к источнику, не зная его физической реализации.

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

S>ИМХО лучше быть может.

Всё это здорово. Тольно аппаратное и программное обеспечение целиком состоят из устаревших концепций. Идеи, которые ты предлагаешь, витали и 10 лет назад. Но движение вперёд происходит не за счёт движения к лучшему, а за счёт движения от неприемлимого.

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

K>Всё это здорово. Тольно аппаратное и программное обеспечение целиком состоят из устаревших концепций. Идеи, которые ты предлагаешь, витали и 10 лет назад. Но движение вперёд происходит не за счёт движения к лучшему, а за счёт движения от неприемлимого.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

MS>В целом это правда. Но если что-то в наших руках — написать лучше ПО и оно будет востребовано, то почему не писать?

Вот вот, писать стараются так, чтоб было востребовано. И желательно, как можно быстрее.

MS>А то бы мы так с ДОС и сидели бы и говорили бы, а что, меня все устраивает и редактор отличный и вот хочешь — на BBS позвоню, спишу что угодно... Так что на практике это не совсем так. Конечно, когда неприемлимо, то прогресс идет пошустрее...

Знаете такой текстовый редактор vi? Тех, кто им пользуется, невозможно убедить перейти на что-то другое. И Windows нужен был не тем, кто сидел в ДОС, а тем, для кого это было неприемлимо.

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

K>Знаете такой текстовый редактор vi? Тех, кто им пользуется, невозможно убедить перейти на что-то другое.

+1
vi!

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

K>Знаете такой текстовый редактор vi? Тех, кто им пользуется, невозможно убедить перейти на что-то другое. И Windows нужен был не тем, кто сидел в ДОС, а тем, для кого это было неприемлимо.

Ага. Я пользовался им. Людей которых невозможно переубедить с него перейти сегодня переубеждать поздно вообще в чем либо.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AVC>+1
AVC>vi!

Пока я не научился нажимать :q и :q!, дело обычно доходило до

или

То, что вы описали, крайне напоминает то, как устроена Smalltalk-среда ( например, http://www.smalltalk.ru ). Если интересно — могу рассказать поподробнее своими словами

. Сейчас, кстати, есть и более интересные концепции и проекты, например OpenCroquet ( http://OpenCroquet.org ) — рапределённая динамическая среда.

Но мне кажется, что такие ОС мы уже вряд ли увидим. Почему — сказать сложно, но эта идея очень старая (тот же Smalltalk начали создавать в начале 70-х), рождалась она неоднократно у разных людей, были даже концепт-версии — но мейнстрим эту идею так и не принял.

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

MS>Ага. Я пользовался им. Людей которых невозможно переубедить с него перейти сегодня переубеждать поздно вообще в чем либо.

Это вы зря. Я сам то люблю неторопясь мышью повозить. А эти ребята текст набивают 10-ю пвльцами, раза в 2 быстрее.

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь

Такие картинки "будущих ОС" рисовали еще в 1994 году, во времена IBM OpenDoc и Novell AppWare.

А воз и ныне там.

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

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

K>Это вы зря. Я сам то люблю неторопясь мышью повозить. А эти ребята текст набивают 10-ю пвльцами, раза в 2 быстрее.

Нет я не зря. я тоже 10 пальцами набиваю и мышью возиться не люблю. Но как уже правильно сказали :q! это просто умереть не встать юзабилити.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

K>Пока я не научился нажимать :q и :q!, дело обычно доходило до

или

это да.

Зато потом...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Вывод: понятие файла и приложения — прошло проверку временем, и, скорее всего, навсегда. Над ним могут быть разные абстракции, но оно само — навсегда.

Кроме того, понятие файла фундаментально для UNIX. ("Все есть файл.")
Но когда-нибудь и UNIX устареет...

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Вывод: понятие файла и приложения — прошло проверку временем, и, скорее всего, навсегда. Над ним могут быть разные абстракции, но оно само — навсегда.

Не знаю. Просто это так сразу не поменяешь. Но WinFS же не зря делают...

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

MS>Нет я не зря. я тоже 10 пальцами набиваю и мышью возиться не люблю. Но как уже правильно сказали :q! это просто умереть не встать юзабилити.

Тут недавно вышел у меня короткий диалог со Зверьком Харьковским.
Он мне — юзабилити!
А я ему — функциональность!!
Вот то же и с vi.

Вот самый простой пример.
Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.
И что?

А в vi все просто: yy999p

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

идея разумная, я тоже над этим немало задумывался. С некоторыми ограничениями она даже реализуема

(например, не все объекты имеет смысл сохранять персистентно — немалая часть из них являются временными, и живет крайне недолго)
Проблема в том, что в мэйнстриме мы этого не увидим еще лет 10, если не 20. Причина очень проста — инерция разработчиков и большая база унаследованного кода. М$ даже перейти на управляемый код толком не может, а тут такие радикальные изменения

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

AVC>Кроме того, понятие файла фундаментально для UNIX. ("Все есть файл.")
AVC>Но когда-нибудь и UNIX устареет...

Для виндов тоже.

MS>Не знаю. Просто это так сразу не поменяешь. Но WinFS же не зря делают...

Ага, как широко известно, это надстройка над NTFS.

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

AVC>Вот самый простой пример.
AVC>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.
AVC>И что?

AVC>А в vi все просто: yy999p

Ну это знаете у меня и ФАР умеет...
И не надо помнить эти бестолковые сочетания...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Ага, как широко известно, это надстройка над NTFS.

Как широко известно пока да. Но вообще NTFS это тоже некая база данных. Бинарные деревья, метаданные и т.п.
Так что развитие файловой системы очевидно пойдет как раз в сторону просто лучшей скорости, большей функцинальности и т.п.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Как вы себе представляете копирование объекта, живущего абы где абы как и реализованного абы в каком коде?

А компрессию объекта, живущего абы где, с целью уменьшить расходы на передачу объекта по сети?

А саму по себе передачу такового вот объекта-документа по сети? В виндах вон пробовали ОЛЕшные документы так передавать, потребовало дополнительного сервиса в системе.

А бэкап? С объектами у нас останется по сути только image backup. А если объект размазан по нескольким томам?

Кроме того. Несколько объектов бывают связаны слабой логической ассоциативной связью, которую не получится реализовать технически в виле ОЛЕшного линкинга или типа того — там слишком все кондово и streamlined. Это требует, например, возможности их копировать и передавать по сети все сразу и вместе. Нужно понятие "контейнер этих объектов".

Как это сделать опять же для объекта, представленного абы как и реализованного в абы каком коде?

А вот файл — он полиморфен, все эти операции работают над файлами вообще, независимо от их содержимого. Контейнер для файлов в виде ZIP — это семечки, как и их компрессия. И к мейлу мы аттачим файлы, а не вордовые документы. И с сети качаем файлы, а не мультики.

Эти базовые операции над файлом могут быть совершены даже при отсутствии на этой машине кода, умеющего с ними работать. Даже операция "просмотр в виде текста" и то худо-бедно реализована.

Более того. Файлы могут быть даже многоплатформенны, например, JPG.

Этот полиморфизм великая сила концепции файла как последовательности байт, возникшей в старом первоначальном юниксе, а потом попавшей практически во все ОС.

Именно потому попытки уйти от него потерпели поражение. Например, в NTFS уже 12 лет как есть альтернативные стримы (собственно, WinFS есть развитие этого дела как раз). А кто ими пользуется, если они не ZIPуются, и если нет простого пути передать файл по сети вместе со стримами?

Конечно, приятно, когда в файл-менеджере кроме тупых и стандартных свойств файла есть еще и юзер-дефайнед, и если есть версионность файлов, есть индексированный поиск по юзер-дефайнед атрибутам и прочие WinFSовские обещания. Но это не повод выкидывать на помойку старую добрую файловую систему.

Это делается над ней. Например, такой продукт, как Docs Open/Hummingbird, был еще в 95 году, делал именно это (а заодно еще и размазанное по куче физических серверов хранилище, и втыкал хуками свои диалоги Open/Save в Ворд и немеряну кучу других программ).

Как я понял, WinFS будет тем же самым, но раздаваемым на халяву с виндой, и с SDK для приложений, чтобы умели делать Open/Save в WinFS.

Опять же — старая добрая файловая система все же живет там внизу.

MS>Как широко известно пока да. Но вообще NTFS это тоже некая база данных. Бинарные деревья, метаданные и т.п.

Любая файловая система — база данных, и имеет метаданные.

NTFS не более чем использует в организации метаданных классический в мире баз данных подход в виде бинарных деревьев. Возможны и иные подходы.

Ну да, еще альтернативные стримы есть, и потуги на создание юзер-дефайнед атрибутов — которые так и остались потугами, хотя место под них в дизайне оставлено.

Как я понял, WinFS — это и будут эти атрибуты, плюс индексы по ним, а не только по имени.

Но для базовых операций над документами в системе — "скопировать", "скачать", "передать по сети", "передать по мейлу", "сгруппировать в контейнер" — это лишнее усложнение. Это потребует либо разработки всех этих тулов в Микрософте — и прощай, скажем, мейлеры третьих фирм, а то и HTTP-серверы, с которых будет невозможно скачать документ со стримами и кастом-атрибутами — либо же стандартизации этого дела — а она провалилась из-за обилия попыток реализации на коленке.

На самом деле очень многое в ИТ провалилось именно из-за невозможности внятной стандартизации.

Т.е. RFC-то написать можно, и можно даже создать комитет, который его проштампует — но нет никакой гарантии, что все вендоры будут следовать стандарту, и — особенно важно! — что будет единое развитие стандарта, а не "версия 1.0 + проприетарная фичка от Микрософта + такая же проприетарная фичка от Мозиллы + такая же фичка от Оперы".

Собрать обратно технологию, которая вот так расползлась, дело великого труда, и кое-где так и не удалось на 100% — ни с юниксами, ни с HTML. Ибо на обратной чаше весов — огромный коммерческий интерес. С какой радости Микрософту советоваться с Оперой по поводу новых фич ИЕ? чтоб все единообразно было? так Микрософту это не нужно, ему все равно, будет ли это решение проприетарным или нет.

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

Ну или взять спам. Огромная проблема в современном мире, решается простым и тупым образом — криптографическим доказательством поля From. Реализация — на неделю работы.

Но это надо а) отпатчить стандарт SMTP под это дело и б) чтобы все вендоры всей кучи емейлового софта поддержали именно это, а не свою проприетарную фичу, которая будет работать только Exchange-Exchange.

До сих пор не сделано.

Вообще, в ИТ много а) вещей, сделанных один раз криво и тяп-ляп, а потом ставших классикой, и не замененных ни на что лучшее десятилетиями, потому что стандарт де-факто б) расползшихся стандартов.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Как я понял, WinFS — это и будут эти атрибуты, плюс индексы по ним, а не только по имени.

Я пока не в курсе подробностей. Спорить не могу.

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

Не поддерживаю такую позицию. Если бы вместо файлов были объекты иерархической структуры — было бы куда проще очень много что.

MSS>Это потребует либо разработки всех этих тулов в Микрософте — и прощай, скажем, мейлеры третьих фирм, а то и HTTP-серверы, с которых будет невозможно скачать документ со стримами и кастом-атрибутами — либо же стандартизации этого дела — а она провалилась из-за обилия попыток реализации на коленке.

Стандартизация конечно нужна от M$. Базовые классы и библиотеки на все случаи жизни. Будет это на .NET я думаю. Чего и нет. Просто не сразу. Не завтра. Все это нельзя так сразу делать. Тут организационных вопросов тьма

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>На самом деле очень многое в ИТ провалилось именно из-за невозможности внятной стандартизации.

MSS>Т.е. RFC-то написать можно, и можно даже создать комитет, который его проштампует — но нет никакой гарантии, что все вендоры будут следовать стандарту, и — особенно важно! — что будет единое развитие стандарта, а не "версия 1.0 + проприетарная фичка от Микрософта + такая же проприетарная фичка от Мозиллы + такая же фичка от Оперы".

Ну на самом деле фичка от Майкрософта при надлежащей поддержке оного становится стандартом на виндах в добровольно-принудительном характере...

MSS>Собрать обратно технологию, которая вот так расползлась, дело великого труда, и кое-где так и не удалось на 100% — ни с юниксами, ни с HTML. Ибо на обратной чаше весов — огромный коммерческий интерес. С какой радости Микрософту советоваться с Оперой по поводу новых фич ИЕ? чтоб все единообразно было? так Микрософту это не нужно, ему все равно, будет ли это решение проприетарным или нет.

Ну не совсем. Раньше было да. Потому что раньше IE был лучшим браузером с большим отрывом. Сейчас уже так вот явно не скажешь...

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

Наверное...

MSS>Ну или взять спам. Огромная проблема в современном мире, решается простым и тупым образом — криптографическим доказательством поля From. Реализация — на неделю работы.

И что? Ну докажете вы From и что дальше?

MSS>Но это надо а) отпатчить стандарт SMTP под это дело и б) чтобы все вендоры всей кучи емейлового софта поддержали именно это, а не свою проприетарную фичу, которая будет работать только Exchange-Exchange.
MSS>До сих пор не сделано.

MSS>Вообще, в ИТ много а) вещей, сделанных один раз криво и тяп-ляп, а потом ставших классикой, и не замененных ни на что лучшее десятилетиями, потому что стандарт де-факто б) расползшихся стандартов.

В целом согласен. Но WinFS то назрело потихоньку. Все будет...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

AVC>>А в vi все просто: yy999p

MS>Ну это знаете у меня и ФАР умеет...

А у меня не умеет...

Или, по крайней мере, я не знаю, как это сделать в FAR.
Разве что нажать Ctrl-C, а затем до конца жизни не отпускать Ctrl-V.

Я уж не говорю о том, чтобы 1000 раз повторить последнюю команду редактирования или выполнить какой-нибудь макрос.

MS>И не надо помнить эти бестолковые сочетания...

Да их и не надо много помнить. Достаточно знать с десяток основных команд. Уже будет польза.

Кроме того, Vim доступен и в "гуевом варианте", с менюшками, можно почти ничего и не помнить.

А собственно о чем спор-то?

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

Вся эта тема, конечно, оффтоп, но резюме, IMHO, такое: не все старое и "негуевое" плохо.

MS>Ну на самом деле фичка от Майкрософта при надлежащей поддержке оного становится стандартом на виндах в добровольно-принудительном характере...

Не всегда. Микрософт монополист только в самих виндах и Офисе. Он даже в браузерах уже не монополист.

А если фичка сначала появится у Мозиллы, и только потом появится ее аналог у Микрософта?

MS>И что? Ну докажете вы From и что дальше?

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

MS>Стандартизация конечно нужна от M$. Базовые классы и библиотеки на все случаи жизни. Будет это на .NET я думаю. Чего и нет. Просто не сразу. Не завтра. Все это нельзя так сразу делать. Тут организационных вопросов тьма

Кастом-атрибуты есть уже 12 лет. Воз и ныне там. Значит — не прижились.

.NET тут вообще не при чем, он пока что нуль в мире коробочного софта.

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

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС.
Ага. Почти-что КПК, только там с памятью трабла. Поэтому он не предназначен для работы с гигабайтами информации.
S>Какие здесь подводные камни?

Да до фигищи.

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

Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на

<commandir>
   <mycommandir1/>
   <commandir>
      <mycommandir2/>
      <hendehoh/>
      <commandir/>
   </commandir>
</commandir>

Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.

Когда-то Microsoft весьма живо рекламировала Ole Storage. Обещала всемерную поддержку. И где это все сейчас? Даже Office на нее не перевели полностью. А проблема банальна, структура файла была сделана уникально эффективной под каждое приложение.

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

AVC>А у меня не умеет...

Plugins...

AVC>Или, по крайней мере, я не знаю, как это сделать в FAR.

Plugins...

AVC>Разве что нажать Ctrl-C, а затем до конца жизни не отпускать Ctrl-V.

Plugins...

AVC>Я уж не говорю о том, чтобы 1000 раз повторить последнюю команду редактирования или выполнить какой-нибудь макрос.

Plugins...

AVC>Да их и не надо много помнить. Достаточно знать с десяток основных команд. Уже будет польза.

AVC>Кроме того, Vim доступен и в "гуевом варианте", с менюшками, можно почти ничего и не помнить.

А я не про VIM

AVC>А собственно о чем спор-то?

Не знаю.

AVC>Просто когда мне нужно быстро выполнить большой объем редактирования, я использую Vim, потому что это заметно быстрее.

Верю. А я фар использую...

AVC>Поэтому я в таких случаях не собираюсь отказываться от использования vi.

Ну. Ок.

AVC>Вся эта тема, конечно, оффтоп, но резюме, IMHO, такое: не все старое и "негуевое" плохо.

Согласен! Фар тоже негуевый.

P.S. Но vi это конечно жуткое угребище по юзабилити....

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

MS>>Ну на самом деле фичка от Майкрософта при надлежащей поддержке оного становится стандартом на виндах в добровольно-принудительном характере...
MSS>Не всегда. Микрософт монополист только в самих виндах и Офисе.

Ну да. Прямо звучит как в "узком семейном кругу" он монополист

MSS>Он даже в браузерах уже не монополист.

Ну. Скажем есть альтернативы уже неплохие, все же шестерка подзатянулась. Посмотрим что там будет с IE7 финальным...

MSS>А если фичка сначала появится у Мозиллы, и только потом появится ее аналог у Микрософта?

Значит кто-то в Майкрософте согласился, что она полезная посмотрев на опыт Мозиллы.
Это ничего не значит. Если кто-то первый придумал колесо, не значит что Мерседес спер идею, верно?

MS>>И что? Ну докажете вы From и что дальше?

MSS>В таких условиях спамить никто не захочет. Потому как спамера сразу вычислит его провайдер, и отключит. Весь спам основан на безнаказанности этого дела ввиду анонимности.

Да никакой там анонимности часто нет. Просто есть сети, которые закрыть трудно и наказать нельзя... Вот и все...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

MS>>Стандартизация конечно нужна от M$. Базовые классы и библиотеки на все случаи жизни. Будет это на .NET я думаю. Чего и нет. Просто не сразу. Не завтра. Все это нельзя так сразу делать. Тут организационных вопросов тьма

MSS>Кастом-атрибуты есть уже 12 лет. Воз и ныне там. Значит — не прижились.

Да их как-то особо и не проталкивали. Ну есть и есть. Кто-то использует, кто-то нет... Это как бы не показатель...

MSS>.NET тут вообще не при чем, он пока что нуль в мире коробочного софта.

Он даже не один нуль, а уже много нулей с другими цифрами впереди. Что конечно считать коробкой....

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>........

Ну короче резюме. В суть предложения вы не въехали толком.

Кто вам мешает, чтобы за всеми документами был базовый класс файл с теми же самыми методами, свойствами и т.п., что и сейчас? Кто вам сказал забудем про файлы вообще? Вы как-то не очень понимаете, что просто сейчас есть только 1 класс — файл. Ну есть еще какие-то доступные разные методы через что-то. Но мало, вяло и несерьезно. А надо чтобы было хорошо, много и прямо. И .NET для этого лучший кандидат. И такая идея у M$ и есть. Вот и все дела.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

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

А про наследование классов вы ведь наверняка знаете...

GZ>Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на
GZ>

GZ><commandir>
GZ>   <mycommandir1/>
GZ>   <commandir>
GZ>      <mycommandir2/>
GZ>      <hendehoh/>
GZ>      <commandir/>
GZ>   </commandir>
GZ></commandir>
GZ>

GZ>Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

Да не надо вообще задумываться о данных... Я что-то не вник.

GZ>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.

Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...

GZ>Когда-то Microsoft весьма живо рекламировала Ole Storage. Обещала всемерную поддержку. И где это все сейчас? Даже Office на нее не перевели полностью. А проблема банальна, структура файла была сделана уникально эффективной под каждое приложение.

Опыт сын ошибок трудных...

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Всё СЛИШКО сложно, это будет весьма глючная и негибкая система, скорее нужно делать наооборот -- всё это файлы (смотри Plan9) а c пользовательской инфой нужно работать потипу Beagle или Google Desktop.

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

CP>Всё СЛИШКО сложно, это будет весьма глючная и негибкая система,
Сошласен.
CP>скорее нужно делать наооборот -- всё это файлы (смотри Plan9) а c пользовательской инфой нужно работать потипу Beagle или Google Desktop.
Это другая крайность. ИМХО Singularity очень близко к золотой середине.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

MS>Plugins...
MS>Plugins...
MS>Plugins...
MS>Plugins...

Да, плагины — сила.

Но пока что это выглядит как "волшебная палочка".
Что-то вроде:

Волшебная палочка...
Волшебная палочка...
Волшебная палочка...

Хотелось бы знать, как именно задаются в этих плагинах
— число повторений операций,
— макросы,
— регулярные выражения для поиска и замены.
Если все через менюшку, то это — заметная потеря времени (конечно, при большом числе операций).
А синтаксис регулярных выражений не напрягает?

Или для него тоже нашли "гуевый" и "юзабильный" аналог? (Я такого не знаю, но рад бы узнать.)

MS>P.S. Но vi это конечно жуткое угребище по юзабилити....

Вот здесь, видимо, мы и расходимся во мнениях.
Важны функциональность и простота. Это, IMHO, и есть "юзабилити".
Ни в коем случае не утверждаю, что есть только один "правильный" способ достижения функциональности.
Например, мне нравятся и UNIX, и Оберон, хотя они и основаны на несколько разных принципах (впрочем, в Inferno была сделана попытка синтеза).
И в случае UNIX, и в случае Оберона функциональность (и => юзабильность) достигается за счет простоты конструктивных принципов, что позволяет постоянно наращивать возможности системы в нужном направлении.
Тот же vi может использовать при редактировании все возможности системы.
Ему даже не нужны отдельные "плагины", потому что в UNIX (как и в Обероне) все "плагин".

А Вы — "юзабилити, юзабилити..."

AVC>А в vi все просто: yy999p

А что, часто требуется такое сделать? (какое-нибудь индийское программирование

)

Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

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

R_X>А что, часто требуется такое сделать? (какое-нибудь индийское программирование

)

Просто это реальный случай, имевший место пару недель назад.

R_X>Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

Вы же программист.
У меня "алгоритм" O(1).
А у Вас O(ln n).
И Вам не стыдно?

(шутка, конечно

)

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

AVC>Вы же программист.
AVC>У меня "алгоритм" O(1).
AVC>А у Вас O(ln n).
AVC>И Вам не стыдно?

(шутка, конечно

)

Важна не скорость одной операции, а скорость выполнения задачи в целом

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

R_X>Важна не скорость одной операции, а скорость выполнения задачи в целом

OK.
Поговорим чуть подробнее.
(Мне сначала казалось, что внезапно всплывшая тема о vi явный оффтоп, а сейчас мне видится что-то общее с темой топика.
Общее, возможно, в том, как воспринимается непривычное.

)

Поговорим об эффективности в целом.

Что делает программист ежедневно?
Редактирует, компилирует, тестирует, отлаживает, сохраняет версии. (Можно этот список дополнить.)
В остальное время общается и думает. Тем больше, чем меньше потратил времени на указанные "технические" шаги.
Возьмем, к примеру, (1) редактирование.
Редактирование в vi эффективнее.
Меньше нажатий клавиш, мышь и меню (зачастую — растратчики времени) практически не используются.
Но это далеко не все.
Любые операции редактирования с регулярными выражениями, любые макросы и т.д.
И это не все.
Я могу использовать любую внешнюю программу-фильтр для редактирования как любого блока текста, так и файла целиком.
Написать программу-фильтр, согласитесь, гораздо проще, чем любой иной плагин.
И т.д. и т.п.
А теперь немного о (2-4) компиляции, тестировании и отладке.
Подойдем с точки зрения языка.
Сколько мелких и порой трудноуловимых багов проникает в программы на Си/C++?
(Не хочу "плевать в колодец", сам пишу в основном на Си/C++.)
Сколько иногда тратится времени на их поиски?
В то же время, для программиста на Обероне такие проблемы практически незнакомы.
Почему?
Потому что Вирт сумел "замкнуть" систему типов, в ней больше нет слабых мест, какие есть в Си/C++.
(Решающий шаг — избавление от вариантных записей, теперь для используется только расширение типа.)
Со времен Паскаля (как минимум) Вирт совершенствовал систему типов в своих языках и, IMHO, добился своей цели.
(Также в нем нет типичной "сишной" путаницы между оператором и выражением.)
В том же Обероне есть все главное, что сейчас считается "прогрессивным" в императивных языках.
Оберон — type-safe, расширяем, изначально поддерживает компонентное программирование и сборку мусора (и это в 80-е годы).
Кроме того, очень прост, эффективен. неприхотлив (работает по голому железу — на нем пишут ОС; а также на JVM, на .NET).
Я знаю людей, чья личная производительность многократно выросла при переходе на Оберон.
Так, стоп! Слишком много про Оберон (как и про vi)!
В данном случае главное — не сам Оберон, а принцип: использовать type-safe языки.
И т.д. и т.п.
Вот вопрос:
Все ли ресурсы мы используем для повышения своей производительности труда?
Я думаю, что и к теме топика надо подходить с этой точки зрения.
Эта "будущая ОС" повысит нашу производительность или нет?
Технические вопросы здесь вторичны. Сначала нало выяснить, а хороша ли основная идея?

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

GZ>>Данные могут из себя представлять некую амебную массу, которую просто невозможно типизировать. Только интерпретировать и то, в каждом состоянии по свойму.
А при чем тут наследование. Возьмем к примеру DVD фильм. Если мы хотим его посмотреть, то это всего лишь stream который надо проинтерпретировать. В случае редактирования, на нужно больше информации о том, что и как в ней лежит.
Или возьмем к примеру bmp. Что такое пиксель? В зависимости от заголовка мы можем понять что пиксель это может быть один бит для черно-белых изображений, может быть набором битов разбитых по слоям, или может быть вообще 4 байтным словом.

MS>А про наследование классов вы ведь наверняка знаете...
Знаю. Только для данных это палка о двух концах. С одной стороны оно нам дает многомерность. С другой стороны, ну например такой запрос(насколько я помню, вы Net знаете):
select * from object where object.GetHashCode()=5
В данном случае у нас минимум 3 выстрела в ногу. Найдите их(справшиваю потому, что может быть некоторые выстрелы не заметил сам).

MS>Да не надо вообще задумываться о данных... Я что-то не вник.
Надо. Когда я только начинал, объем в 1 Гигабайт для меня казался чем то огромным, в котором можно сохранить все. Но с развитием техники, увеличилось количество обрабатываемой информацией, и сейчас 1 Гиг является обычным делом. Не думаю что что-то изменится и объем обрабатываемой информации не будет увеличиваться.
Одно из достоинств реляционной модели то, что ее можно легко трансформировать. То есть, разложить информацию таким образом, чтобы эти миллионы строк обрабатывались со сложностью не превышающей O(logN). Для реляционки модель хранения и предоставления данных независимы. И эта трансформация пока недоступна для OODB.

GZ>>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.
MS>Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...
Объекты обладают множеством недостатков, но я не знаю лучше. Поищите по форуму Философии. Объектная модель не столь однозначна. Это обсасывалось множество раз.

... << RSDN@Home 1.2.0 alpha rev. 0>>

)

R_X>Я обычно копирую строчку 10 раз, потом выделяю блок из 10 строчек, копирую его еще 10 раз, потом повторяю операцию еще раз — не намного дольше, чем вспомнить yy999p

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

AVC>В Обероне проблем с уничтожением ненужных объектов ( =сборкой мусора ) тоже нет.
AVC>А вот с выгрузкой модулей — есть.

У меня эта проблема решена лишь частично. Выгрузить assembly саму по себе невозможно. Тут даже не моя причина а .NET так работает. Реализация классов у меня хранится во внешнешних assebly. Со всеми вытикающими. А вот выгрузить экземпляр — никаких проблем. Даже если он используется его все равно можно насильно вытиснить. Впрочем в большинстве случаев это не нужно. Всегда в RAM найдется кто нибудь, кто уже не выполняется. Вот его и вытесняю. Очень важной особенностью моей СУБД является возможность закружать граф связанных объектов по частям. Тоесть если А ссылается на Б, Б ссылается на С, а С ссылается на А — загружать их можно в любом порядке и в любой комплектности не зависимо друг от друга. Далее незагруженные объекты загружаются ondemand и вытисняются по мере исчерпания RAM.

S>>Я в своей ОБД сделал по другому. У меня любой экземпляр может иметь переменное число аттрибутов изначально. Тоесть добавить/удалить field в классе это не задача версионирования а просто штатная операция ОБД. При этом разные экземпляры одного и того же класса могут иметь различный набор аттрибутов.

AVC>А методов?

Методы реализованны во внешних DLL. После старта приложения заменить их нельзя. Чтоб заменить DLL на новую версию надо остановить приложение. При остановке данные в объектах не теряются — объекты даже не заметят что их останавливали.

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

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

S>>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

MS>Мне кажется, что подводный камень это то, что работать в некоторых вопросах станет труднее.

Ну я и писал, что аналогия — грубая. И ясно, что за все придется платить. Однако имхо пользы в совокупности может быть гораздо больше.

MS>Мне кажется, что нельзя отказываться от понятия хранилище. Т.е. нельзя бесповоротно стирать грань между персистивными и транзиентными объектами.

А это и не обязательно. В моей ОБД все контролируемо.

MS>Почему? Потому что эта грань несет кроме сложностей еще и пользу. Как то — контроль производительности (все-же простите меня но доступ в ОЗУ всегда будет существенно быстрее чем в более медленное, но более емкое хранилище),
Здесь возможен компромис. В текущей версии моей ОБД доступ в хранилище производится только при первом обращении к объекту.
Хранилище написано не очень оптимально и обеспечивает около 1000 инстанциирований в секунду. Затем следующие обращения по ИД идут в RAM. Индекс в RAM обеспечивает 50000 — 80000 разадресаций в секунду (для AMD 1.7).

MS>Ну а в вашей реализации подводные камни это:
MS>1. Сложность задачи — не справиться гораздо проще, чем кажется по дороге
Эт есть. Однако справился. Уже не первую версию опубликовал. И еще на подходе.

MS>2. Технические возможности — вы все таки не можете писать свою ОС и тягаться в производительности со своп файлом трудно
Да. Свою ОС я и не пишу. Я пишу свою ООСУБД.

MS>3. Как результат производительность
По сравнению с РБД+ОРМ имхо можно выиграть весьма.

MS>4. Сложные схемы работы для программиста — они не захотят разбираться или многим это будет неудобно
Не для всех задач. Для интереса портировал небольшую программу с MS-SQL на свое изделие. Исходный код работы с персистент объектами в моей БД оказался проще. Нет никаких SqlCommand постоянный ExecuteQuery и пересылки данных из датасетов в объекты и обратно. Вот уш по этому пункту ОБД точно в переди, даже если отстает по скорострельности.

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

EB>Но мне кажется, что такие ОС мы уже вряд ли увидим. Почему — сказать сложно, но эта идея очень старая (тот же Smalltalk начали создавать в начале 70-х), рождалась она неоднократно у разных людей, были даже концепт-версии — но мейнстрим эту идею так и не принял.

Наверное самая изветная тупиковая попытка — ODMG ИМХО она провалилась из за "проблем" с идентичностью объектов. В отличие от ODMG в моей СУБД один и тот же экземпляр может иметь несколько разных ИД, и так же несколько разных экземпляров могут иметь один и тот же ИД. Это сближает мою СУБД с реляционными, так как позволяет мне проводить операции OBJECT JOIN когда из нескольких различных экземпляров возникает новый — композитный — по аналогии с VIEW / SELECT ... FROM ... OUTER JOIN ...

Здравствуйте, GlebZ, Вы писали:
GZ>>>Кто сказал что в будущем останется ООП. ООП обладает рядом недостатков, собственно поэтому его и влепили в рамки КОП. И вообще на ООП не кончается все программирование.
MS>>Конечно, и не начинается. И что? Типа объекты долой? Нет такого понятия? Мы против объектов... Не знаем таких...
GZ>Объекты обладают множеством недостатков, но я не знаю лучше. Поищите по форуму Философии. Объектная модель не столь однозначна. Это обсасывалось множество раз.

К теме объектности. Ссылки старые, но хорошие.

http://www.softcraft.ru/paradigm/process/index.shtml

http://www.softcraft.ru/paradigm/dhp/index.shtml

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

S>Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.

Задача более фундаментальна. Выкиньте слова: "ОС" и "объектная система управления БД" — они лишние.

Более фундаментальная задача: реализация модели бесконечной персистентной памяти. Нужно реализовать среду времени исполнения, которая работает в рамках этой модели. ОС и всякие БД пусть работают поверх этой среды времени исполнения.

ОС, БД, пользовательские модули
            |
            |
           \|/
 среда времени исполнения
            |
            |
           \|/
         железо

Что вообще означает модель бесконечной персистентной памяти? А то и означает, что записав по адресу A данные X сегодня, и обратившись через сто-тыщ-мильёнов лет по адресу A мы сможем считать данные X.

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

Д>идея разумная, я тоже над этим немало задумывался. С некоторыми ограничениями она даже реализуема

Д>(например, не все объекты имеет смысл сохранять персистентно — немалая часть из них являются временными, и живет крайне недолго)
Д>Проблема в том, что в мэйнстриме мы этого не увидим еще лет 10, если не 20. Причина очень проста — инерция разработчиков и большая база унаследованного кода. М$ даже перейти на управляемый код толком не может, а тут такие радикальные изменения

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

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

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

GZ>Данные могут быть слаботипизированны, тогда накладные расходы на типизацию в ООDB могут превысить все мыслимые пределы. Представь себе какие расходы будут на
GZ>

GZ><commandir>
GZ>   <mycommandir1/>
GZ>   <commandir>
GZ>      <mycommandir2/>
GZ>      <hendehoh/>
GZ>      <commandir/>
GZ>   </commandir>
GZ></commandir>
GZ>

GZ>Здесь 3 commandir и все разного типа. Здесь всего 6 разных типов, которые на которые надо иметь типизацию и уметь хранить 6 разными способами. Для реляционки такое не проблема, потому как она ее можно подвернуть так, чтобы она меньше задумывалась о типе, а больше задумывалась именно о данных.

А знаете, для ОБД это еще меньшая проблема чем для РБД. С "радостью" EAV надеюсь знакомы? Так под моей ОБД такой проблемы нет. Любой экземпляр любого класса может иметь любые аттрибуты. И приведенное здесь дерево — это просто тривиальность. ну чтоб было по интереснее, можно сделать mycommandir1 вторым парентом для mycommandir2, а mycommandir2 сделать парентом для внешнего commandir. Это все штатные средства работы с аттрибутами объектов в СУБЗ Cerebrum

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

GZ>Одно из достоинств реляционной модели то, что ее можно легко трансформировать. То есть, разложить информацию таким образом, чтобы эти миллионы строк обрабатывались со сложностью не превышающей O(logN). Для реляционки модель хранения и предоставления данных независимы. И эта трансформация пока недоступна для OODB.

В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Здравствуйте, shuklin, Вы писали:

S>>Если рассмотреть ОС как единую среду выполнения некоторых модулей совмещенную с объектной системой управления БД — то ни файлы ни приложения не нужны.

СГ>Задача более фундаментальна. Выкиньте слова: "ОС" и "объектная система управления БД" — они лишние.

СГ>Что вообще означает модель бесконечной персистентной памяти? А то и означает, что записав по адресу A данные X сегодня, и обратившись через сто-тыщ-мильёнов лет по адресу A мы сможем считать данные X.
Задача еще более фундаментальна. В моей, уже разработанной ОБД экземпляры могут иметь много различных адресов, и один и тот же адрес в зависимости от контекста может указывать на разные данные. И без этого никак.

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

S>Несколько версий своей ОБД я уже даже опубликовал. Там есть более подробные описания архитектуры, которую я бы хотел видеть в будущей ОС — ну разумеется в том виде в котором у меня получилось это все дело реализовать на сегодняшний момент.

а маппинг на какие языки у нее есть? Как вообще осуществляется доступ, в общих чертах?
ОБД — это конечно хорошо, но попыток было уже много, и практически все не особо удачные

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>>Несколько версий своей ОБД я уже даже опубликовал. Там есть более подробные описания архитектуры, которую я бы хотел видеть в будущей ОС — ну разумеется в том виде в котором у меня получилось это все дело реализовать на сегодняшний момент.

Можно скачать последнюю версию под .NET 1.1 по адресу http://www.shuklin.com/ai/ht/ru/cerebrum Там же есть и описание.

Д>а маппинг на какие языки у нее есть?

.NET 1.1 языки. Это в первую очередь C# & VB

Д>Как вообще осуществляется доступ, в общих чертах?
Желательно, но не обязательно унаследовать ваш класс от моего базового. Крайне желательно, но не обязательно — реализовать интерфпйс IComponent. Вобщем и все. Однако, ОБД не станет сама сериализовать поля твоего класса. Если ты хочешь, чтобы у класса были персистент поля можно сделать
— определить эти поля как аттрибуты в метаданных самой ОБД.
— реализовать ISerializable и сериализовать нужные данные самостоятельно.

Разадресация ИД происходит в пределах контекта. Каждый объект обладает собственным контекстом. Он задается объекту через метод SetConnector интерфейса IComponent — собственно для этого и нужно реализовать этот интерфей — чтоб иметь доступ к собственному контексту.

через контекс можно получить доступ к дочерним аттрибутам.
container = this.GetChildComponents();

через коллекцию дочерних аттрибутов можно получать доступ к их контекстам

connector = container.AttachConnector(someHandle);

через коннектор можно получить
— доступ собственно к экземпляру
connector.Component

— доступ к коллекции дочерних аттрибутов дочернего аттрибута
container2 = connecor.GetContainer() as IContainer;

Д>ОБД — это конечно хорошо, но попыток было уже много, и практически все не особо удачные

Я думаю, что создатели заужали свои амбиции. Я не только делаю ОБД, но еще и БЗ и нейронные сети — такой суржик привел к весьма значительным отступлениям от стандартов ODMG.

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

S>В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...
Да она может и 10000 обрабатывать. Но если в алгоритме заложено O(logN) вместо O(N), то он все равно будет быстрее. Их разница обычно измеряется не в разы, а на порядки.

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

S>>В моем изделии сложность обработки каждого экземпляра, не зависимо от объема БД — O(C). 80000 экземпляров в секунду на AMD 1.7 и это сделано одним человеком ...
GZ>Да она может и 10000 обрабатывать. Но если в алгоритме заложено O(logN) вместо O(N), то он все равно будет быстрее. Их разница обычно измеряется не в разы, а на порядки.

разницу между O(N), O(logN) и O(C) просто не заметили?

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

S>А знаете, для ОБД это еще меньшая проблема чем для РБД. С "радостью" EAV надеюсь знакомы? Так под моей ОБД такой проблемы нет. Любой экземпляр любого класса может иметь любые аттрибуты. И приведенное здесь дерево — это просто тривиальность. ну чтоб было по интереснее, можно сделать mycommandir1 вторым парентом для mycommandir2, а mycommandir2 сделать парентом для внешнего commandir. Это все штатные средства работы с аттрибутами объектов в СУБЗ Cerebrum
То есть нету типизированности, нету идентификации, и это называется ООДБ?

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

GZ>То есть нету типизированности, нету идентификации, и это называется ООДБ?

Есть. Но ее можно считать мягкой, так как при любой необходимости она нарушается без доп затрат.
Точнее — типизация и прочее вводится как дополнительные рестрикшены. А вот с идентификацией вопрос сложнее.
Она у меня есть, но координально отличается от ODMG. уже писал здесь же. Один объект имеет разные ИД. Одно и тоже ИД адресует разные объекты.

ООДБ означает что в БД храняться экземпляры объектов с поведением. А вот модель данных в ООБД может быть иерархической, сетевой, реляционной, может еще какую придумают ... У меня — сетевая модель.

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

S>разницу между O(N), O(logN) и O(C) просто не заметили?
Нет не заметил, и не понял что значит сложность обработки одного экземпляра.

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

AVC>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.

Только не говори, что это — типичная задача при программировании.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>>разницу между O(N), O(logN) и O(C) просто не заметили?
GZ>Нет не заметил, и не понял что значит сложность обработки одного экземпляра.

O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.

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

S>O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.
O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

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

S>>O(C) — в данном случае означает, что время обработки/доступа/поиска одного экземпляра не зависит от колличества экземпляров, находящихся в хранилище БД.
WH>O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).

Не люблю 1, С всетаки показывает весьма существенные затраты на каждый объект. Совсем ведь без затрат никак (((

Текущие характеристики моей СУБД на AMD 1.7

Инстанциирование объекта — хранилище <-> RAM 1000 C# в секунду.
Поиск в кэш — 50000 — 80000 C# в секунду.

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

shuklin wrote:

> WH>O(C) это что-то не стандартное. Обычно в таких случаях пишут O(1).
>
> Не люблю 1, С всетаки показывает весьма существенные затраты на каждый
> объект. Совсем ведь без затрат никак (((
Любишь/не любишь, но O(C)=O(1) при любом C>0
Или у тебя C=N^N^100?

> Текущие характеристики моей СУБД на AMD 1.7
>
> Инстанциирование объекта — хранилище <-> RAM 1000 C# в секунду.
> Поиск в кэш — 50000 — 80000 C# в секунду.

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

Т.е. вообще от кол-ва объектов никак не зависит? Что 1 объект в хранилище, что 1000000?
А от чего зависит? А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?

Posted via RSDN NNTP Server 2.0

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

_>Т.е. вообще от кол-ва объектов никак не зависит? Что 1 объект в хранилище, что 1000000?
_>А от чего зависит? А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?

Практически вообще не зависит. Конешно есть косвенные факторы. Если БД поместится вся в RAM целиком, мы будем иметь одну C, Если не поместиться — будем иметь другую C. На границе, при которой размер БД вот вот выйдет за границы RAM конечно возникнет нелинейность. Ну так как без этого? И это доли процентов от общего размера С. Тоесть С в зависимости от размера БД меняется скачком в случае выхода БД за пределы RAM, но все еще остается С(тоесть я могу ориентируясь на худший случай говорить о С) — остальное — очень незначительные ее изменения.

СУБД 32 битная. Максимально теоретически возможное колличество объектов в ней — 2млрд (один бит не используется для адресации).

_>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в нем объектов близко к

p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С учетом накладных расходов, в текущей версии это до 80000 завершенных операций поиска в секунду на машине с которой я это ща пишу. Тоесть от запроса объекта по его ID до получения ссылки на c# экземпляр.

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

AVC>>Товарищу надо вставить 1000 одинаковых строк в навороченном "гуевом" редакторе.

Д>Только не говори, что это — типичная задача при программировании.

Это просто недавний случай, вот он сразу и вспомнился.
А вообще "типичная задача" — понятие относительное.
Например, т.к. я переодически "пишу компиляторы"

, мне может срочно понадобиться сделать md-файл для нового backend-а.
Но ассемблеры "капризны": у одних destination register слева, у других справа.

И что, мне несколько сотен шаблонов ручками править?

А в vi это не проблема: найти и переставить подстроки по шаблону. Раз — и все!

Потом использование abbr.
Например, тут высказывались в том духе, что в Обероне набирать ключевые слова заглавными буквами "рука устанет".

Мол, Shift держать трудно, надо обладать большой физической силой...
А оно надо?
Настраиваю abbr, у меня вместо while не только WHILE напечатается, но и WHILE DO END, и курсор встанет в нужную позицию.

Конечно, многие "фичи" могут быть и в других редакторах.
Но, как правило, не все.
К тому же, они везде реализованы по разному...
А vi (или vim) практически везде одинаков (и везде доступен).

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

AVC>А вообще "типичная задача" — понятие относительное.

вполне даже абсолютное... хочешь, опрос проведем?

я не думаю, что найдется хотя бы 0.1% людей, для которых возможность вставки заданного количества одинаковых строк в код является определяющей при выборе IDE

AVC>Но ассемблеры "капризны": у одних destination register слева, у других справа.

AVC>И что, мне несколько сотен шаблонов ручками править?

AVC>А в vi это не проблема: найти и переставить подстроки по шаблону. Раз — и все!

поиск и замена по регэксу есть практически в любой современной IDE

AVC>Потом использование abbr.
AVC>Например, тут высказывались в том духе, что в Обероне набирать ключевые слова заглавными буквами "рука устанет".

AVC>Мол, Shift держать трудно, надо обладать большой физической силой...
AVC>А оно надо?
AVC>Настраиваю abbr, у меня вместо while не только WHILE напечатается, но и WHILE DO END, и курсор встанет в нужную позицию.

а может, надо просто проектировать языки таким образом, чтобы хотя бы простые вещи не требовали средств автоматизации работы?

AVC>А vi (или vim) практически везде одинаков (и везде доступен).

Только пользоваться этим допотопным чудом мало кто хочет.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

_>>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
S>Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в нем объектов близко к

S>p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С учетом накладных расходов, в текущей версии это до 80000 завершенных операций поиска в секунду на машине с которой я это ща пишу. Тоесть от запроса объекта по его ID до получения ссылки на c# экземпляр.

В любой Windows используются точно такие же алгоритмы для сокрытия реального адреса объекта и выдачей пользователю некоторого handle.
Вопрос сколько времени требуется для поиска объекта по какому-то primary key, например по имени.

shuklin wrote:

> _>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
> Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве
> всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в
> нем объектов близко к
>
> p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С
> учетом накладных расходов, в текущей версии это до 80000 завершенных
> операций поиска в секунду на машине с которой я это ща пишу. Тоесть от
> запроса объекта по его ID до получения ссылки на c# экземпляр.

Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за константное время, значит у тебя известные ограничения
этого подхода — вставка/удаление работает линейное время, либо объекты должны быть фиксированного размера, при этом
иногда нужно делать дефрагментацию (точнее упаковку). А вообще говоря 10000 _вставок_ в секунду не слишком далеко от
некоторых промышленных бд, выборка по индексу (но не за линейное время, а за логарифмическое) быстрее (без хранения всей
базы в памяти, из кэша ещё быстрее).

Posted via RSDN NNTP Server 2.0

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

_>>>А как объекты создаются/удаляются (добавляются в хранилище, уничтожаются)?
S>>Интересует API или идея? Индекс является деревом 10-10-12 бит. В дереве всегда 3 уровня. Когда дерево находится целиком в RAM то время поиска в нем объектов близко к

S>>p[(h>>22) & 0x3FF][(h>>12)&0x3FF][h&0xFFF] — тоесть такты процессора. С учетом накладных расходов, в текущей версии это до 80000 завершенных операций поиска в секунду на машине с которой я это ща пишу. Тоесть от запроса объекта по его ID до получения ссылки на c# экземпляр.

MS>В любой Windows используются точно такие же алгоритмы для сокрытия реального адреса объекта и выдачей пользователю некоторого handle.
Это алгоритм не столько для скрытия, сколько для обеспечения "мягкости" handle — независимости логического адреса объекта от способа его хранения диск/память и независимости от сессии работы ОБД и возможности дефрагментации — перемещения блоков с данными.

MS>Вопрос сколько времени требуется для поиска объекта по какому-то primary key, например по имени.

уточнение. в ОБД primary key объекта это его ID. В ОБД используются только суррогатные primary key == object ID.

Поиск объектов по вторичным ключам действительно требует времени. Требует построения дополнительных индексов и всего прочего.
В этом моменте ОБД настолько же эффективны либо хуже РБД. ИМХО. Ну совсем все сразу не получишь. За все остальные достоинства приходится расплачиваться. В том числе этим. Еще в ОБД есть трудности с VIEW. не то чтоб VIEW в ОБД небыло вовсе, но они не столь "красивы" концептуально. Вплоть до того что ODMG вообще согласился с тем, что поддержка VIEW в ОБД есть фича необязательная. ИМХО проблемы VIEW в ОБД гораздо важнее этих едениц процентов по скорости. При наличии прямой навигации как целостная система, приложение на ОБД в 90% будет все равно уделывать приложение на РБД по скорости. А вот VIEW — это вопрос не оптимизации а функциональности.

В ОБД моей разработке для решения трудностей с VIEW применяются объектные JOIN и агрегаты. Индексы для поиска объектов по вторичным ключам в моей ОБД не реализованы. При их необходимости программеру придется реализовать персистент хэш таблицы. В будущем поддержку индексов планирую. В других ОБД поддержка вторичных индексов есть.

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

_>Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за константное время, значит у тебя известные ограничения
_>этого подхода — вставка/удаление работает линейное время,
Да. Причем для вставки/удаления С гораздо хуже чем для выборок. Сейчас это еще связанно с ограниченостью моих рессурсов как разработчика. Что и как оптимизировать ясно. А время на это нет

_>либо объекты должны быть фиксированного размера, при этом
_>иногда нужно делать дефрагментацию (точнее упаковку).
Этого нет. Объекты могут иметь любой размер и дефрагментация не предусмотрена. В будущем возможно, но не в ближайшем. Да, доп потери. Опять же я не про вымышленную систему говорю, а про рельную, доступную для свободного довнлоада.

_> А вообще говоря 10000 _вставок_ в секунду не слишком далеко от
_>некоторых промышленных бд, выборка по индексу (но не за линейное время, а за логарифмическое) быстрее (без хранения всей
_>базы в памяти, из кэша ещё быстрее).

Ну Рим не за один день строился

shuklin wrote:

> _>Идея, конечно, интересует. Если у тебя идёт выбор по индексу, за
> константное время, значит у тебя известные ограничения
> _>этого подхода — вставка/удаление работает линейное время,
> Да. Причем для вставки/удаления С гораздо хуже чем для выборок. Сейчас
> это еще связанно с ограниченостью моих рессурсов как разработчика. Что и
> как оптимизировать ясно. А время на это нет
Что-то такое ощущение, что для тебя все алгоритмы имеют сложность С, где это С может быть каким угодно.

> _>либо объекты должны быть фиксированного размера, при этом
> _>иногда нужно делать дефрагментацию (точнее упаковку).
> Этого нет. Объекты могут иметь любой размер и дефрагментация не
> предусмотрена. В будущем возможно, но не в ближайшем. Да, доп потери.
Если из 5-и гигового файла удалить объекты, которые находятся в 1-м гигабайте — тебе как-то придётся сдвигать оставшиеся
4 гига, меняя положение/индексы (а не дай бог если они идентификаторы) объектов.

> Опять же я не про вымышленную систему говорю, а про рельную, доступную
> для свободного довнлоада.
Да я понимаю, просто отношусь скептически. Не понимаю, за счёт чего (а не чем) эта система "лучше всех существующих"?

Posted via RSDN NNTP Server 2.0

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

S>В моей, уже разработанной ОБД экземпляры могут иметь много различных адресов, и один и тот же адрес в зависимости от контекста может указывать на разные данные.

Это как?

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

AVC>Здравствуйте, Ranger_XL, Вы писали:
R_X>>Важна не скорость одной операции, а скорость выполнения задачи в целом

[...]

AVC>Все ли ресурсы мы используем для повышения своей производительности труда?
AVC>Я думаю, что и к теме топика надо подходить с этой точки зрения.
AVC>Эта "будущая ОС" повысит нашу производительность или нет?
AVC>Технические вопросы здесь вторичны. Сначала нало выяснить, а хороша ли основная идея?

С тех пор как появилась задача о программировании автоматически появилась и вторая задача об оптимизации программирования.

Всё, что мы тут обсуждаем это задача об оптимизации программирования.
Нас ждут такие технологии, которые позволят сварганить операционку за час, среду разработки за пол дня.
Дадим каждому пользователю по операционке и рабочей среде под заказ!
Эта мечта о могуществе на кончиках пальцев.

Всё это незримо начинается с установления обратных связей. Где появляется обратная связь — жди повышения эффективности.

Тут возник спор. Одни говорят (утрирую): — файл это всё. Другие говорят: — всё это объект.
1) если нет ничего проще файла. Однако у файла есть свойства и атрибуты. Методы файла — это приложения которые "понимают" такой файл. Тогда коммунизм наступит при достаточном количестве приложений.
2) если нет ничего проще объекта (Sysyem::Object). Тогда нас ждут братья servlet, plugin и addin.

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

А серьёзный скачёк будет тогда, когда компьютер в свободное от пользователя время начнёт заниматься поиском и установлением новых обратных связей. Но пока что, это задача слишком нетривиальная.
По-этому, я бы поставил вопрос по другому: "При какой архитектуре ОС проще искать и устанавливать обратные связи?". Вот где собака не рылась!

СГ>ОС, БД, пользовательские модули
СГ>            |
СГ>            |
СГ>           \|/
СГ> среда времени исполнения
СГ>            |
СГ>            |
СГ>           \|/
СГ>         железо
СГ>

СГ>Что вообще означает модель бесконечной персистентной памяти? А то и означает, что записав по адресу A данные X сегодня, и обратившись через сто-тыщ-мильёнов лет по адресу A мы сможем считать данные X.

Согласен. Весь вопрос упирается в создании надёжного и эффективного ассоциативного хранилища мгновенного доступа.

WoldemaR wrote:

> Всё, что мы тут обсуждаем это задача об оптимизации программирования.
> Нас ждут такие технологии, которые позволят сварганить операционку за
> час, среду разработки за пол дня.
> Дадим каждому пользователю по операционке и рабочей среде под заказ!
> Эта мечта о могуществе на кончиках пальцев.
Как в старом анекдоте:

Как выглядит программа на языке высокого уровня 10 поколения?
"Хочу программу с БД и красивым интерфейсом".
Как выглядит отладка программы на языке высокого уровня 10 поколения?
"Хочу программу с БД и красивым интерфесом. И чтоб работало!!!"

Posted via RSDN NNTP Server 2.0

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

_>Если из 5-и гигового файла удалить объекты, которые находятся в 1-м гигабайте — тебе как-то придётся сдвигать оставшиеся
_>4 гига, меняя положение/индексы (а не дай бог если они идентификаторы) объектов.

В текущей версии: Нет, не придется. В начале файла образуется дыра с мусором. Этот мусор будет заполнятся по мере создания новых объектов. Если такого создания не будет — дыра в файле так и останется на всегда дырой.

shuklin wrote:
> В текущей версии: Нет, не придется. В начале файла образуется дыра с
> мусором. Этот мусор будет заполнятся по мере создания новых объектов.
> Если такого создания не будет — дыра в файле так и останется на всегда
> дырой.
То есть имеем классическую схему с каталогом страниц?

Posted via RSDN NNTP Server 2.0

Здравствуйте, Сергей Губанов, Вы писали:

S>>В моей, уже разработанной ОБД экземпляры могут иметь много различных адресов, и один и тот же адрес в зависимости от контекста может указывать на разные данные.

СГ>Это как?

Ага, это одно из отличительных свойств моей СУБД — в ODMG вовсе не так.

если коротко

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

shuklin wrote:
> один и тот же персистент экземпляр класса может в разных контекстах
> идентифицироваться разными Handle.
И что? Ну добавили level of indirection? Что это фундаментально меняет?

Posted via RSDN NNTP Server 2.0

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

C>То есть имеем классическую схему с каталогом страниц?

На уровне хранилища — гдето так. Скорее ближе к старому досовкому FAT.

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

>> один и тот же персистент экземпляр класса может в разных контекстах
>> идентифицироваться разными Handle.
C>И что? Ну добавили level of indirection? Что это фундаментально меняет?

Появляетс возможность строить объектные JOINs & aggregates.

типа WHERE ИД_ОБЪЕКТА(объект1)==ИД_СВЯЗИ(связь3)

shuklin wrote:
>> > один и тот же персистент экземпляр класса может в разных контекстах
>> > идентифицироваться разными Handle.
> C>И что? Ну добавили level of indirection? Что это фундаментально меняет?
> Появляетс возможность строить объектные JOINs & aggregates.
> типа WHERE ИД_ОБЪЕКТА(объект1)==ИД_СВЯЗИ(связь3)
Тогда теряем возможность O(1) изменений объектов и скатываемся к случаю
с РБД

Рукомендую почитать про CODASYL — там на это все уже в 70-х годах
натыкались.

Posted via RSDN NNTP Server 2.0

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

C>Тогда теряем возможность O(1) изменений объектов и скатываемся к случаю
C>с РБД

Я не вижу зла в откате к техническим характеристикам и возможностям РБД в сложных для ОБД случаях. Так мы получим БД которая сочетает в себе лучшее из ОБД и РБД. На данный момент я вижу такую БД только на основе сетевой модели. для компоненты О в названии БД, компонента Р в модели — имхо зло немерянное.

AVC>А в vi все просто: yy999p

Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
А в достаточно популярном донельзя гуевом MS Word достаточно: ALT-F11, двойной клик на This Document и выполнить (F5) следующее:

Sub test()

    For i = 0 To 1000
       Call ActiveDocument.Range.InsertParagraphBefore
       Call ActiveDocument.Range.InsertBefore("Этот текст появится очень много раз")
    Next
  
End Sub

Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.

З.Ы. По роду занятий я не VB программист и никогда им не был

Я тут http://www.rsdn.ru/Forum/Message.aspx?mid=1862408&only=1
прикинул что и как да почём, кому интересно — заходите.

Кстати, может какие ообд так уже работают? Никто не в курсе.

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

L>Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
L>А в достаточно популярном донельзя гуевом MS Word достаточно: ALT-F11, двойной клик на This Document и выполнить (F5) следующее:
В студии тоже можно макросы писать... через все тотже Alt+F11... Болие того студия умеет записывать и воспроизводить действия пользователя. Ctrl+Shift+R, записываем действия, Ctrl+Shift+R далие при помощи Ctrl+Shift+P воспроизводим действия нужное колличество раз.
Кстати вот такой макрос

    Sub TemporaryMacro()
        DTE.ActiveDocument.Selection.WordLeft(True)
        Dim s = DTE.ActiveDocument.Selection.Text
        DTE.ActiveDocument.Selection.Text = ""
        For i = 1 To Integer.Parse(s)
            DTE.ActiveDocument.Selection.Paste()
        Next
    End Sub

позволяет скопировать текст в буфер обмена после чего примо в редакторе написать число которое будет обозначать сколько раз нужно вставить этот текст. Далие запускаем макрос и все...
При жилании можно сделать макрос который будет выполнять и болие сложнве комманды.

А вот такой макрос

    Sub TemporaryMacroN()
        DTE.ActiveDocument.Selection.WordLeft(True)
        Dim s As String = DTE.ActiveDocument.Selection.Text
        DTE.ActiveDocument.Selection.Text = ""
        Dim i As Integer
        For i = 1 To Integer.Parse(s)
            RecordingModule.TemporaryMacro()
        Next
    End Sub

позволяет выполнять записанные действия N раз.

... << RSDN@Home 1.1.4 beta 6a rev. 436>>

MS>Кто вам мешает, чтобы за всеми документами был базовый класс файл с теми же самыми методами, свойствами и т.п., что и сейчас? Кто вам сказал забудем про файлы вообще? Вы как-то не очень понимаете, что просто сейчас есть только 1 класс — файл. Ну есть еще какие-то доступные разные методы через что-то. Но мало, вяло и несерьезно. А надо чтобы было хорошо, много и прямо.

Все я прекрасно понимаю. Сейчас есть суперкласс "файл", от которого унаследованы подклассы типа "MS Word Document", типа "бинарь" (имеет закладку Version в шелле), и прочие подобные.

Вы предлагаете сделать все это более развитым. Пожалуйста. Но "файл" как базовая сущность — дата-время, флажки, имя и содержимое, которое в самом классе "файл" не интерпретируется — он останется. Низкий уровень файловых систем трогать не нужно.

Все эти классы могут быть сделаны на уровне интерпретации содержимого файла и понятия "формат файла". Так это успешно и делается уже многие годы.

WinFS даже скорее не об этом, а скорее о расширении понятия "директория". Т.е. там будут "директории" не по имени файла, а по какому-то кастом-атрибуту — например, "второе имя" файла, или мало ли что там еще.

Такие вещи можно сделать, либо тронув низ файловой системы (и, насколько я знаю, в Ntfs таки подымут в полный рост экспериментальную подсистему NtOfs, которая именно это и делает), либо создав метаданные, скажем, в MDB файле (как Thumbs.db) сбоку от файловой системы. Там будут храниться значения кастом-атрибутов для всех файлов на томе, и индексы по ним.

>на что-то другое. И Windows нужен был не тем, кто сидел в ДОС, а тем, для кого это было неприемлимо.

Я ж помню, как Windows захватывал рынок. Через 3rd party developers в основном, а не через юзеров.

Windows решал для девелопера 2 проблемы а) использование всей памяти машины и б) совместимость сразу с любыми принтерами. Под Windows было удобнее девелопить, чем под ДОС, потому под нее сразу появилось много приложений, некоторые из них Windows-only.

А юзеры туда пошли только тогда, когда уже все эти приложения там были. Многие юзеры у нас в России так и сидели в ДОС до появления Windows 95 (в которой основной key point с точки зрения рынка был — сеть).

Именно из-за приложений (и еще многозадачности — не надо выходить из старой программы, чтобы открыть новую, причем многозадачность была еще и для ДОС задач) юзера туда и пошли, а не из-за UI. Под ДОСом был тот же ТурбоВижн — прекрасный UI, для неграфических задач типа финансов ничем не хуже Windows. Собственно, турбовижновскую 1С-Бухгалтерию я видел у людей еще в начале 2000ных годов.

Видел и такую картину — в виндах стоят Ворд, Эксел, и на DOS VM бегает сразу 2 рабочих места "Паруса".

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

S>У меня эта проблема решена лишь частично. Выгрузить assembly саму по себе невозможно. Тут даже не моя причина а .NET так работает.

Можно. Грузишь её в отдельный домен, потом домен прибиваешь и сборка выгружается.

... << RSDN@Home 1.2.0 alpha rev. 0>>

Здравствуйте, shuklin, Вы писали:
S>Наверное самая изветная тупиковая попытка — ODMG ИМХО она провалилась из за "проблем" с идентичностью объектов.
Неа. Она провалилась из-за того, что в
— в OQL встроили слищком могучий type inference. Ни один ЯП общего назначения на тот момент не был способен с этим справиться; в итоге, значительная часть OQL — запросов просто не позволяла представить свои результаты в языке "клиента".
— в OQL отказались от описания семантики методов, возложив эту задачу на внешний язык.
Таким образом, вместо того, чтобы стереть грань между DB и OO, эти орлы возвели непреодолимую стену. Даже просто реализовать этот мусор оказалось невозможным; построить приемлемо эффективную реализацию — тем более.
Мне неизвестны какие-либо проблемы с identity, присущие ODMG OQL. Возможно, я просто не смотрел в нужную сторону. Ты не мог бы рассказать, какие именно проблемы сулит ODMG-подход к identity?

Заодно поясни, зачем ты отказался от основы ООП в своей СУБД — ведь identity это базовая концепция?
Ну вот я могу себе представить алгоритм, который полагается на то, что из identity(a) == identity(b) следует, что a и b — это один и тот же объект. И модифицируя состояние объекта через ссылку а, мы гарантированно получим тот же результат, что и через ссылку b.
Опять же я могу представить себе алгоритм, зависящий от того, что из identity(a) != identity(b) однозначно следует различность этих двух объектов.
Нарушение этих предположений может привести к достаточно тяжким проблемам с семантикой.

1.1.4 stable rev. 510

Здравствуйте, Сергей Губанов, Вы писали:

СГ>Более фундаментальная задача: реализация модели бесконечной персистентной памяти. Нужно реализовать среду времени исполнения, которая работает в рамках этой модели. ОС и всякие БД пусть работают поверх этой среды времени исполнения.
Это как раз не штука. Интригу в эту "более-менее фундаментальную задачу" можно добавить, к примеру, так: реализовать эффективный механизм выполнения запросов в этой модели.
Что понимается под запросом? Поиск множества объектов, удовлетворяющих заданному предикату.
Что понимается под "эффективным"? Тут немного сложнее. Во-первых, есть полное количество экземпляров в модели — пусть это будет N.
Во-вторых, есть количество объектов, которые фактически удовлетворяют заданному предикату. Пусть это будет R<p>.
Предположим, что сам предикат p позволяет вычислить его на произвольном экземпляре с затратами, не зависящими ни от N, ни от R<p>.
В случае, если модель позволяет перечислить все объекты за время порядка O(N), мы можем выполнить запрос с такой же асимптотикой.
Задача состоит в том, чтобы улучшить эту асимптотику; в идеале — до O(R<p>) на достаточно широком классе предикатов.

1.1.4 stable rev. 510

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

MSS>>Вывод: понятие файла и приложения — прошло проверку временем, и, скорее всего, навсегда. Над ним могут быть разные абстракции, но оно само — навсегда.
AVC>Кроме того, понятие файла фундаментально для UNIX. ("Все есть файл.")

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

AVC>Но когда-нибудь и UNIX устареет...

Угу. Вместе с компьютерами.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Windows решал для девелопера 2 проблемы а) использование всей памяти машины и б) совместимость сразу с любыми принтерами. Под Windows было удобнее девелопить, чем под ДОС, потому под нее сразу появилось много приложений, некоторые из них Windows-only.
Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.

... << RSDN@Home 1.2.0 alpha rev. 0>>

GZ>Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.

Имели право. Они же не продавали их в одной коробке.

Антимонопольным властям не нравился стиль MSных OEM контрактов, когда оплата была не от количества установленных виндов, а... от количества проданных OEMщиком машин. Т.е. на уровне бизнеса просто блокировался интерес к преинсталляции любой ОС, кроме виндов, ибо за винду платить все равно.

Итог — в 93-94 годы все брэнды, кроме IBM, были с преинсталлированными виндами, и только виндами — другая ОС в преинсталле не встречалась. Только у IBM не было преинсталлированных виндов, а была либо ДОС, либо полуось.

Судья Споркин открыл процесс. По ходу процесса MS договорился с министерством торговли (или как оно там), что MS это дело прекращает. Министерство отозвало иск из суда, а Споркин сказал — "вы не сделаете из меня дурачка, который подписывает все, что ему суют" — и стал продолжать дело. Итог — дисквалификация Споркина.

Потом был еще Джексон, но это уж потом.

Здравствуйте, Maxim S. Shatskih, Вы писали:

GZ>>Третья немаловажная причина в том, что Microsoft предлагал практически готовое рабочее место Windows+Office. Что не сильно потом нравилось антимонопольным властям.
MSS>Имели право. Они же не продавали их в одной коробке.
Просто когда стало ясно, что и офис и Windows стали монополистами, шли упорные слухи что решением суда и антимонопольного комитета будет разделение корпорации на две части: которая занимается OS, и которая занимается офисом. Но Microsoft постоянно с кем то договаривается.

... << RSDN@Home 1.2.0 alpha rev. 0>>

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

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

Не хочется мешать основной теме.

AVC>>А вообще "типичная задача" — понятие относительное.

Д>вполне даже абсолютное... хочешь, опрос проведем?

Д>я не думаю, что найдется хотя бы 0.1% людей, для которых возможность вставки заданного количества одинаковых строк в код является определяющей при выборе IDE

Хм... и после такого голосования мои типичные задачи изменятся?
А вообще мне нравится здешняя манера передергивания.
Только за руками следи.

Вот я как-то сказал, что в Обероне можно в программный текст вставлять самые разные объекты — от рисунков, иллюстрирующих идею алгоритма, до соответствующих отрывков из книг или документации.
Тут же стали говорить, что это не нужно (кстати, почему?), и представлять дело так, что это главная фича Оберона.
Не в этой отдельной фиче дело, а в том, что я получаю ее бесплатно.
Так уж устроены документы в Обероне, что в них можно вставлять произвольные объекты.
Так и здесь.
Разве дело только в том, чтобы вставить 1000 одинаковых строк?

Д>а может, надо просто проектировать языки таким образом, чтобы хотя бы простые вещи не требовали средств автоматизации работы?

Так-так. Шутить изволите.

Вот, небось, сидишь сейчас в навороченной среде.
Редактор, конечно, с синтаксической подсветкой.
И хочешь поговорить о Простых Вещах.

OK.
Вот Простой Вопрос.

Как ты думаешь, что проще автоматизировать: проверку на завершение ввода ключевого слова или синтаксическую подсветку?
Что же касается собственно дизайна ЯП, то хорошо спроектирован тот язык, что не требует многочасовых сидений в отладчике.

AVC>>А vi (или vim) практически везде одинаков (и везде доступен).

Д>Только пользоваться этим допотопным чудом мало кто хочет.

Так я никого и не заставляю...

AVC wrote:
> Не в этой отдельной фиче дело, а в том, что я получаю ее бесплатно.
> Так уж устроены документы в Обероне, что в них можно вставлять
> произвольные объекты.
Ну в Виндовом OLE точно так же можно делать. И что?

Posted via RSDN NNTP Server 2.0

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

>> Не в этой отдельной фиче дело, а в том, что я получаю ее бесплатно.
>> Так уж устроены документы в Обероне, что в них можно вставлять
>> произвольные объекты.
C>Ну в Виндовом OLE точно так же можно делать. И что?

Разница в простоте.
При том, что Оберон возник раньше.
При несоизмеримости вложенных человеко-лет.

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

AVC>Наверное, если у народа будет желание, лучше обсудить "войну редакторов" в специальном топике.

AVC>Не хочется мешать основной теме.

ну давай проголосуем, чтобы ее отделили...

AVC>Хм... и после такого голосования мои типичные задачи изменятся?

а с чего ты взял, что меня интересуют твои типичные задачи?

Меня интересуют типичные задачи типичного программиста... тем более, что уж возможности текстового редактора всем нужны примерно одни и те же.

AVC>Разве дело только в том, чтобы вставить 1000 одинаковых строк?

ну хорошо. Любая задача, которая требует повторить операцию строго n раз. Я с трудом могу представить, кому и при каких обстоятельствах это может понадобиться

А это, тем не менее, преподносится как одна из крутейших фич vim.

AVC>Так-так. Шутить изволите.

AVC>Вот, небось, сидишь сейчас в навороченной среде.
AVC>Редактор, конечно, с синтаксической подсветкой.
AVC>И хочешь поговорить о Простых Вещах.

да, сижу. Только она делает не постые вещи, а вполне даже сложные. Авто-комплит по именам классов и методов, переименование, resolve namespae — это наверно самое полезные фичи... но помощь писать ключевые слова без выворачивания пальцев в число таких фич точно не входит

AVC>OK.
AVC>Вот Простой Вопрос.

AVC>Как ты думаешь, что проще автоматизировать: проверку на завершение ввода ключевого слова или синтаксическую подсветку?

зависит от языка, но обычно пункт 1 проще

AVC>Что же касается собственно дизайна ЯП, то хорошо спроектирован тот язык, что не требует многочасовых сидений в отладчике.

перпендикулярно

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

S>Ты не мог бы рассказать, какие именно проблемы сулит ODMG-подход к identity?

Очень трудно создать VIEW в такой ОБД. Допустим у нас есть объект город и справочник города. И есть объект компания у которой указатель на город. Далее нам нужен производный объект Компания у которой вместо указателя на город находится его имя — аналогично РБД шному JOIN. Итак сделали такой объект. Теперь вопрос, а какой ИД у этого производного объекта? В РБД — тот же что и у исходной компании. А в ОБД какой? Новый? Новый нельзя. И без VIEW тоже нельзя — надо ведь сохранять совместимость с legacy.

S>Заодно поясни, зачем ты отказался от основы ООП в своей СУБД — ведь identity это базовая концепция?

В первую очередь из за игр с семантическими сетями. Там с ODMG трактовкой OID делать нечего. Ну например, нужно мне добавить в объект на рантайм новую именованную связь, а связи дать дополнительные аттрибуты. Связь логично окрасить тем же ОИД. Тогда из текущено объекта связанный объект должен быть разадресован не по ид этого объекта а по ид связи с ним. В итоге смысл уникального ОИД полностью теряется на уровне пользователя. Ну много причин. А главная, моя концепция включает ODMG как частный случай. Ведь можно не значит необходимо. Если в какомто случае синонимию/омонимию OID не нужна — то можно ей не пользоваться, назначая во всех контекстах одинаковым объектам одинаковые OID.

Я в своей ОБД широко использую этот механизм для адресации аттрибутов объектов. Есть список аттрибутов. Каждый аттрибут имеет свой описатель — тоже объект с некоторым ИД. Однако любой другой объект по этому ИД получает не описатель, а значение этого аттрибута. Так например Аттрибут имя имеет аттрибут с собственным ИД и со значением "Имя". Подробнее это описано здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx

Здравствуйте, shuklin, Вы писали:
S>Очень трудно создать VIEW в такой ОБД. Допустим у нас есть объект город и справочник города. И есть объект компания у которой указатель на город. Далее нам нужен производный объект Компания у которой вместо указателя на город находится его имя — аналогично РБД шному JOIN. Итак сделали такой объект. Теперь вопрос, а какой ИД у этого производного объекта?
Никакого, потому что это не объект. Я же говорю — проблема OQL как раз в том, что легким манием руки порождаются новые типы. К счастью, конструировать объектные типы нельзя, потому и вопрос об OID лишен смысла. После операторов проекции или join получается неидентифицируемый кортеж.
S>В РБД — тот же что и у исходной компании.
И в РБД у него никакого PK нету. Ровно по той же причине.
S>А в ОБД какой? Новый? Новый нельзя. И без VIEW тоже нельзя — надо ведь сохранять совместимость с legacy.

S>В первую очередь из за игр с семантическими сетями. Там с ODMG трактовкой OID делать нечего. Ну например, нужно мне добавить в объект на рантайм новую именованную связь, а связи дать дополнительные аттрибуты. Связь логично окрасить тем же ОИД. Тогда из текущено объекта связанный объект должен быть разадресован не по ид этого объекта а по ид связи с ним. В итоге смысл уникального ОИД полностью теряется на уровне пользователя. Ну много причин. А главная, моя концепция включает ODMG как частный случай. Ведь можно не значит необходимо. Если в какомто случае синонимию/омонимию OID не нужна — то можно ей не пользоваться, назначая во всех контекстах одинаковым объектам одинаковые OID.

S>Я в своей ОБД широко использую этот механизм для адресации аттрибутов объектов. Есть список аттрибутов. Каждый аттрибут имеет свой описатель — тоже объект с некоторым ИД. Однако любой другой объект по этому ИД получает не описатель, а значение этого аттрибута. Так например Аттрибут имя имеет аттрибут с собственным ИД и со значением "Имя". Подробнее это описано здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx
Надо бы почитать. Пока что звучит как ересь

1.1.4 stable rev. 510

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

S>Никакого, потому что это не объект. ... После операторов проекции или join получается неидентифицируемый кортеж.

Вспомним тот же пример — компания и город. Пусть у компании было текстовое поле — "город". Ввели систему в эксплуатацию. Она проработала с год. Появились реализации тулзов третьей стороны. Теперь надо текстовое поле "город" в объекте компании заменить на указатель. Без нарушения совместимости с уже существующим кодом. В РБД для этого можно использовать VIEW. В данном простом примере можно выкрутится за счет проперти. Но а если у нас структура БД поплыла? Надо делать вьюшки, причем такие, чтоб они выглядели для старых клиентов полноценными экземплярами объектов старого формата.

S>Надо бы почитать. Пока что звучит как ересь

Вот благодаря этой ереси эта проблема решаема и в ОБД.

Здравствуйте, shuklin, Вы писали:
S>Вспомним тот же пример — компания и город. Пусть у компании было текстовое поле — "город". Ввели систему в эксплуатацию. Она проработала с год. Появились реализации тулзов третьей стороны. Теперь надо текстовое поле "город" в объекте компании заменить на указатель. Без нарушения совместимости с уже существующим кодом.
Это невозможно. Как ты себе представляешь этот гипотетический существующий код? С учетом того, что теперь нельзя делать

update company set city = 'Новосибирск' where companyId = @companyId

Тебе придется искать такие вызовы по коду, вводить отдельный справочник городов, UI к нему и прочее и прочее.
Пойми, что структура данных сама по себе никогда не меняется. Меняются требования. И возможность адаптироваться к изменившимся требованиям одной лишь структурой БД — это миф.
Впрочем, есть одна ситуация, когда то, о чем ты говоришь, теоретически возможно. Это оптимизация по результатам эксплуатации. Всякая денормализация и прочее. Теоретически, в таких случаях (если клиенское приложение написано исключительно через хранимые процедуры и view) можно воспользоваться этой замечательной инкапсуляцией.
Но беда в том, что на практике потребность оттюнить перформанс при помощи изменений структуры (а не подстройкой индексов) возникает намного реже, чем изменения в требованиях.

S>Вот благодаря этой ереси эта проблема решаема и в ОБД.
То, что ты сделал, нельзя называть ОБД. Потому что основных черт ОБД у этого нету.
Ну вот придумал ты способ называть результат join объектом. Ок, вот мы заджойнили кошечку со шкафом. А методы у этого чуда от кого будут?

1.1.4 stable rev. 510

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

S>Это невозможно. Как ты себе представляешь этот гипотетический существующий код?

Я это уже сделал. Объекты FieldDescriptor притворяются объектами AttributeDesctiptor именно на основе одной из возможностей моей СУБЗ. На самом деле FieldDescriptor не идеальное решение и для Cerebrum. Там используется полиморфизм поведения ядра. Тоже самое можно сделать на основе полиморфизма структуры. Вот только сущесвующая реализация экспорта/импорта полиморфизм структуры еще не поддерживает. Поэтому FieldDescriptor работают по старинке.

S>Ну вот придумал ты способ называть результат join объектом. Ок, вот мы заджойнили кошечку со шкафом. А методы у этого чуда от кого будут?

Паттерн Wrapper|Bridge

Здравствуйте, shuklin, Вы писали:
S>Я это уже сделал.
Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях. Если клиентское приложение ничего не знает о городах, то сколько там дескрипторов ни наверни, работать лучше оно не станет.

1.1.4 stable rev. 510

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

S>Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях. Если клиентское приложение ничего не знает о городах, то сколько там дескрипторов ни наверни, работать лучше оно не станет.

Главное, чтобы старая версия клиентского приложения не взорвалась при переходе на новую версию БД и так же не взорвала саму БД. А самомодификация клиентского кода при изменении схемы данных — направление перспективное, тоже планирую этим заняться, и наработки есть, но еще не в том состоянии чтоб предлагать их в качестве готового решения.

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

S>>Я это уже сделал.
S>Ты ничего пока не сделал. Проблема не в дескрипторах, а в клиентских приложениях.

И еще, похоже я плохо объяснил свою мысль. Не дескриптор решает эту проблему, а дескриптор иллюстрирует на своем примере использование одного из механизмов моей СУБД (использование IContainerEvents интерфейса) который может быть использован для построения объектного VIEW. Собственно FieldDescriptor является таким объектным VIEW/JOIN. FieldDescriptor JOINит собственные данные с данными AttributeDescriptor. Цели для которых это сделано никакого отношения к рассматриваемой проблеме не имеют. Это просто указание, какой кусок исходников смотреть, если интересно понять, о чем я говорю.

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

S>Я считаю, что это очень грубая но весьма правдоподобная картина будущих ОС. Какие здесь подводные камни?

Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой, построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется непосильной задачей.

Мне кажется, стоит пробовать обкатывать те или иные идеи в этой области с малого.

AVC>>А в vi все просто: yy999p :)

L>Разработчики студии, видимо, справедливо решили что такая возможность программисту не нужна.
Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.

L>Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.
Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.

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

dmz>Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.
"просто скопировать несколько строк" гораздо проще с помощью мыши.

L>>Ничего сложного, правда? Поверте, это достаточно быстро — секунд 15 и нагляднее, по-моему, чем yy999p.
dmz>Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.
О да, а знание команд vim наверное инсталлируется прямо в мозг при первом запуске. Этот VBA к тому же обладает интеллисенсом и подсказывает, что можно сделать, имена объектов и методов выбраны так, чтобы типичный американец сразу знал, что куда вставлять, а кроме всего прочего, можно включить запись макроса. Поэтому типичная штука — это включить запись, вбить параграф, выключить запись, пойти в редактор макросов и обложить две строчки циклом. Я так в свое время выполнял подбор параметра в Excel для 2000 начальных условий.

1.1.4 stable rev. 510

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

Y>Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой, построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется непосильной задачей.

Y>Мне кажется, стоит пробовать обкатывать те или иные идеи в этой области с малого.

Полностью согласен. Что ты понимаешь под метафреймами? На какой стадии находится твоя работа? Я уже где то год обкатываю свои идеи на изготовленном движке ООБД. Уже опубликовал несколько версий. Если заинтересуешся — можешь посмотреть. Буду рад любому сотрудничеству.

Дмитрий.

shuklin wrote:
>
> Y>Мне близка Ваша тема, я сейчас думаю над языковой-хранилище средой,
> построенной на принципах метафреймов. Копать же вплоть до ОС мне кажется
> непосильной задачей.
>
> Y>Мне кажется, стоит пробовать обкатывать те или иные идеи в этой
> области с малого.
>
> Полностью согласен. Что ты понимаешь под метафреймами? На какой стадии
> находится твоя работа? Я уже где то год обкатываю свои идеи на
> изготовленном движке ООБД. Уже опубликовал несколько версий. Если
> заинтересуешся — можешь посмотреть. Буду рад любому сотрудничеству.

Под метафреймом я понимаю такую модель:

— Ссылка на метаобъект данного объекта; Значение
-- Ссылка на метаобъект слота 1; Значение
-- Ссылка на метаобъект слота 2; Значение
---- Ссылка на метаобъект слота 2.1; Значение

(если рассматривать упрощенно)

У меня моя работа находится в фазе перманетного обдумывания, с
некоторыми отворотами-исследованиями в сторону (типа http://verb.org.ua/om/)

Сейчас же я пытаюсь начать набрасывать рантайм (http://verb.org.ua/xi/,
исходников пока, увы, нет)

Основная мысль заключается в том, что на базе метафреймов описывается
ВСЁ, включая и конструкции для вычислений, и необходимые данные.
Соответственно, мы можем сделать метафреймовый язык с persistent store.
Такое вот.

С уважением,
Юрий.

Posted via RSDN NNTP Server 2.0

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

Y>Под метафреймом я понимаю такую модель:

Y>- Ссылка на метаобъект данного объекта; Значение
Y>-- Ссылка на метаобъект слота 1; Значение
Y>-- Ссылка на метаобъект слота 2; Значение
Y>---- Ссылка на метаобъект слота 2.1; Значение

Если под ссылкой на метаобъект ты понимаешь ссылку на некоторый экземпляр, описывающий семантику данного экземпляра, причем в отношении много значений к одному описателю — то именно такую архитектуру я в своей ООБД уже реализовал.

Если под метаобъектом ты понимаешь нечто отличное от описателя — тогда я не понял идеи, опиши пожалуйста подробнее.

Дмитрий.

Здравствуйте, shuklin, Вы писали:
Y>>Под метафреймом я понимаю такую модель:

Y>>- Ссылка на метаобъект данного объекта; Значение
Y>>-- Ссылка на метаобъект слота 1; Значение
Y>>-- Ссылка на метаобъект слота 2; Значение
Y>>---- Ссылка на метаобъект слота 2.1; Значение

S>Если под ссылкой на метаобъект ты понимаешь ссылку на некоторый экземпляр, описывающий семантику данного экземпляра, причем в отношении много значений к одному описателю — то именно такую архитектуру я в своей ООБД уже реализовал.

S>Если под метаобъектом ты понимаешь нечто отличное от описателя — тогда я не понял идеи, опиши пожалуйста подробнее.

Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.
У объекта Number может быть, для примера, слоты
— (мета=SymbolicName) "Number"
в свою очередь, SymbolicName может иметь метой Symbol или Object.
Это, в целом, уже вопрос устаканивания набора базовых фреймов. Например, я хочу чтобы мета-отношения были также предметом отношения фрейм-слот, т.е. нужен объект META, на который также ссылаются, и т.п.

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

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Y>Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Y>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.

Ориентировочно понял. Да очень похоже на то что и я сделал. Можешь посмотреть на детали моего творчества по этому поводу здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx там с серидины статьи идет описание AttributeDescriptor и TableDescriptor Мне очень интересно обсудить различия в наших подходах.

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

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

Y>>Если я правильно тебя понимаю, то приблизительно это я и имею в виду. Для уточнения
Y>>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.

S>Ориентировочно понял. Да очень похоже на то что и я сделал. Можешь посмотреть на детали моего творчества по этому поводу здесь http://www.shuklin.com/ai/ht/ru/cerebrum/lessons/Cerebrum.Samples.Streams-01.aspx там с серидины статьи идет описание AttributeDescriptor и TableDescriptor Мне очень интересно обсудить различия в наших подходах.

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

1. Я пытаюсь идти путём полной последовательности в формировании объектов.
У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.
2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот
3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.
4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

Вот пока такие различия усмотрел.

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Y>У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.

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

Y>2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот

У меня таблицы могут быть аттрибутами, к примеру. Тоже нет ограничений. Просто совсем без конкретики не удобно. Ее придется вводить. Вот рекомендуемое разделение аттрибутов и таблиц есть одно из таких решений. Это уже модель внутри модели. Причем служебная модель для обслуги собственных целей ООБД. Там все сделано так как было удобнее для самой ОБД. А вот пользователи могут творить все что захотят, делать объекты собственными аттрибутами, или парентами, назначать одному и тому же экземпляру различные ID, либо одному и тому же ID назначать различные объекты (в различных контекстах разадресации) Модель данных моей ООБД сетевая — никаких таблиц. Только граф и однонаправленные связи. Узлы можно рассматривать как фреймы, а связи — как слоты. На основе примененной модели данных легко реализуются иерархические семантические сети, иерархические сети фреймов, модель близкая к реляционной (используется для конфигурации ядра), нейронные сети.

Y>3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.

У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.

Y>4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

Ага, это наверное основное. Я свое изделие под *nix не планирую портировать никогда, хотя потенциальную возможность такого порта заложил. Это технически возможно. Я — win разработчик и целевая аудитория *nix для моей ООБД мне не интересна.

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

Y>>У меня нету специальных Name/DisplayName/Description. Это все должно быть описано в форме отношений фрейм-слот, и мета-отношений. Мне кажется, этот подход позволяет не ограничивать себя так или иначе и создавать более гибкую модель.

S>У меня эти свойства тоже не являются специальными, но без них будет совсем неудобно. Поэтому я их создаю зарание про запас.

Я пришёл к выводу, что мне никто не мешает добавить слоты с метами Name/DisplayName/Description к тому объекту, которому я хочу, и тогда, когда я этого хочу.

Y>>2. У меня фактически нет разделения типа Attribute/Table. У меня все является объектом, а "вложенность" описывается посредством отношений фрейм-слот

S>У меня таблицы могут быть аттрибутами, к примеру. Тоже нет ограничений. Просто совсем без конкретики не удобно. Ее придется вводить. Вот рекомендуемое разделение аттрибутов и таблиц есть одно из таких решений. Это уже модель внутри модели. Причем служебная модель для обслуги собственных целей ООБД. Там все сделано так как было удобнее для самой ОБД. А вот пользователи могут творить все что захотят, делать объекты собственными аттрибутами, или парентами, назначать одному и тому же экземпляру различные ID, либо одному и тому же ID назначать различные объекты (в различных контекстах разадресации) Модель данных моей ООБД сетевая — никаких таблиц. Только граф и однонаправленные связи. Узлы можно рассматривать как фреймы, а связи — как слоты. На основе примененной модели данных легко реализуются иерархические семантические сети, иерархические сети фреймов, модель близкая к реляционной (используется для конфигурации ядра), нейронные сети.

То есть в приниципе можно рассатривать Attribute/Table как предмет описания фрейм-слот отношений?

Y>>3. Так как я планирую гибрид языка и базы данных, меня интересует собственный memory allocation manager в своих участках памяти (маппленых). Т.е. я не хочу базироваться на какой-то low level (bdb, например) или high level (*sql) базе данных.

S>У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.

А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

Есть ли что-то в этом направлении?

Y>>4. Я в основном *nix-разработчик, и практически не использую (да и не знаю особо) .NET. Только ради пробы какие-то hello world на mono писал.

S>Ага, это наверное основное. Я свое изделие под *nix не планирую портировать никогда, хотя потенциальную возможность такого порта заложил. Это технически возможно. Я — win разработчик и целевая аудитория *nix для моей ООБД мне не интересна.

Мне лично это не кажется основным различием, по крайней мере идеологическим.

С уважением,
Юрий

... << RSDN@Home 1.1.4 stable SR1 rev. 568>>

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

Y>Я пришёл к выводу, что мне никто не мешает добавить слоты с метами Name/DisplayName/Description к тому объекту, которому я хочу, и тогда, когда я этого хочу.

Правильно. В моей ОБД любой слот можно добавлять к любому объекту в любое удобное время. Можно сказать, что потенциально все объекты обладают всеми аттрибутами + все объекты являются аттрибутами и все аттрибуты являются объектами. Но это потенциально. В какой то конкретной БД только определенные экземпляры являются аттрибутами у определенных экземпляров. Любой экземпляр объекта можно сделать аттрибутом какого то экземпляра объекта. Учитывая всеже необходимость минимального порядка, все равно будут существовать ограничения, но они накладываются не БД а задачей. Что делает с одной стороны такой инструмент мощным, а с другой, утяжеляет поиск ошибок, т.к. можно сделать всю таблицу значением аттрибута "Name" и при попытке привести ее к типу String получить толи экзепшин толи результат Table.ToString() — это уш как повезет, но по любому результат без смысла )) Т.к. БД позволяет максимальную свободу — ответственность разработчика избегать нарушений такого характера. В мои интересы именно такая свобода и входит как первоочередной приоритет. constraints можно накрутить уже потом, по мере необходимости.

Y>То есть в приниципе можно рассатривать Attribute/Table как предмет описания фрейм-слот отношений?

Да, можно, Attribute/Table является частным случаем применения фрейм-слот отношений. При реализации Attribute/Table были задействованы более низкоуровневые возможности модели данных (графа).

Y>А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

В .NET куча интересных возможностей. Меня прежде всего заинтересовал MC++ он позволяет в одном коде перемешивать IL и старый добрый ASM (не на прямую, а как результат компиляции C++ — управляемо через pragma какой кусочек сырца куда скомпилится) Память на прямую можно использовать и из C# — там есть понятие указатель, хотя оно включается специальной опцией компилятора, и с такой сборокой будут проблемы при попытке ее запуска из под IE к примеру. Но для собственной ООБД это не принципиально, по любому сервайсу придется отдавать почти все права. Еще я очень активно использую "mixed" классы. Тоесть обычные структуры в памяти, методы к которым частично реализованы на IL и частично на unmanaged code При этом virtual методы overrided тоже в mixed режиме. В базовом классе метод может быть реализован на unmanaged code и перекрыт managed у наследника, и далее опять unmanaged. Ну это все внутренности. Наружу торчит только C# интерфейс.

Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

Y>Мне лично это не кажется основным различием, по крайней мере идеологическим.

Да, это различие исключительно политическое )) Можем сотрудничать на идеологической основе, она у нас очень близкая. Сможем обогатить системы друг друга полезными идеями. Я свою делаю в первую очередь для моделирования нейронных сетей, хотя и стандартные бизнес сценарии мне тоже интересны. А ты для чего свою?

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

Y>>А вот тут хотелось бы подробнее, мне интересно. Возможно ли в .NET взять кусок памяти некоего размера, и самостоятельно с ним работать? А взять его не просто из свободной памяти, а из файла (т.е. Memory Mapped File)? Т.е. как вот в *nix я делаю mmap() и дальше танцую оттуда.

S>Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap()

и работы с этим всем.

У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

Y>>Мне лично это не кажется основным различием, по крайней мере идеологическим.

S>Да, это различие исключительно политическое )) Можем сотрудничать на идеологической основе, она у нас очень близкая. Сможем обогатить системы друг друга полезными идеями. Я свою делаю в первую очередь для моделирования нейронных сетей, хотя и стандартные бизнес сценарии мне тоже интересны. А ты для чего свою?

Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

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

... С уважением, Юрий

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

S>Прямое отображение файла в память я решил не использовать, несмотря на возможный выигрыш в производительности. Пытался, но пришел к тому, что потеряю больше чем получу. Если твоя БД требует прямого отображения, то в Win32 есть соответсвующее API а что C# что MC++ может им воспользоваться. Хотя удобно это не будет. Мало того, есть интересные результаты тестов. В некоторых сценариях C# опережает по скорости C++. Это связано со стековым выделением памяти в .NET и heap в С++. Есть ли аналог MC++ для Mono я не знаю. И какое АПИ доступно из Mono — тоже не знаю. В самом .NET на сколько мне известно memory mapped files не поддерживаются — только как внешнее OSAPI.

В Mono есть класс Mono.Unix.Native.Syscall, в котором есть и mmap

... С уважением, Юрий

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

Y>Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap()

и работы с этим всем.

Да, всего интересного много есть в природе. Приходится оптимизировать затраты на собственное обучение чтоб не превратить этот процесс в китайский университет. И поэтому тоже я не смотрю в сторону *nix — просто не хватит рессурсов поддерживать две платформы.

Y>У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

Хм. Учитывая, что я потенциально тоже собираюсь прикрутить к своей системе "некий "язык программирования" с полной и прозрачной персистентностью" то отказался от отображения и поэтому тоже. В первую очередь по следующим причинам
— необходимо транслировать мягкие ссылки при сериализации объектов. Если этого не делать, то на дсик уйдет много откровенного мусора и пустышек требуемых только на рантайм.
— очень много аттрибутов объектов сохранять нет необходимости. при отображении они будут забивать диски.

если начать избавляться от этих моментов — то в итоге классическая сериализация окажется и эффективнее и проще по сравнению с отображением в котором сортируются поля, динамически подменяются мягкие ссылки и пр.

Я решил, в файле буду хранить данные максимально компактно чтоб уменьшить трафик, а в озу — как будет быстрее их обработать.

Y>Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

Мне тоже пришлось в бизнес сценариях поработать с ОРМ и SQL-XML связками для business logic teirs ИМХО ОБД может быть весьма полезна во многих областях бизнеса. Поэтому я обращаю на возможность такого применения своей ОБД первоочередное внимание. Уже в собственных планах выпуск на ее основе совершенно обычных продуктов без ИИ+ИНС.

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

Y>>Надо бы почитать документацию по Mono, интереса ради. В том числе и по поводу OS API, вызовов mmap()

и работы с этим всем.

S>Да, всего интересного много есть в природе. Приходится оптимизировать затраты на собственное обучение чтоб не превратить этот процесс в китайский университет. И поэтому тоже я не смотрю в сторону *nix — просто не хватит рессурсов поддерживать две платформы.

А у меня вряд ли хватит ресурсов на поддержку развития в сторону Windows. Я последний раз под него писал году эдак в 96-97.

Y>>У меня же требуется прямое отображение по тому соображению (но не только), что у меня не совсем БД, а некий "язык программирования" с полной и прозрачной персистентностью.

S>Хм. Учитывая, что я потенциально тоже собираюсь прикрутить к своей системе "некий "язык программирования" с полной и прозрачной персистентностью" то отказался от отображения и поэтому тоже. В первую очередь по следующим причинам
S>- необходимо транслировать мягкие ссылки при сериализации объектов. Если этого не делать, то на дсик уйдет много откровенного мусора и пустышек требуемых только на рантайм.

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

S>- очень много аттрибутов объектов сохранять нет необходимости. при отображении они будут забивать диски.

А можно пример, когда неоторые аттрибуты сохранять нет необходимости?

Кстати, в моей модели планируется такая штука, как объекты, которые не записываются, в рамках всё той же метафреймовой модели. В метафрейме объекта должно быть просто указание необходимости записи "обратно" в файл, или что-то вроде этого.

S>Я решил, в файле буду хранить данные максимально компактно чтоб уменьшить трафик, а в озу — как будет быстрее их обработать.

Кстати. Является ли твое решение transactionable? А то я после просмотра материала не понял этого.

А насчет отображений -- знаешь ли ты такие модели как images (во многих реализациях Lisp, Smalltalk, etc.)? Я в некотором роде оттуда наследую модель отображения, так как некоторым боком любитель Lisp/Smalltalk/etc.

Y>>Ближе к "бизнес-сценариям", я нейронками не занимаюсь в данный момент. Хотя всё возможно, есть некие выходы на интересные работы в этом направлении.

S>Мне тоже пришлось в бизнес сценариях поработать с ОРМ и SQL-XML связками для business logic teirs ИМХО ОБД может быть весьма полезна во многих областях бизнеса. Поэтому я обращаю на возможность такого применения своей ОБД первоочередное внимание. Уже в собственных планах выпуск на ее основе совершенно обычных продуктов без ИИ+ИНС.

Замечательно!

... С уважением, Юрий

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

Y>Что имеется в виду под мягкими ссылками? weak pointers? Что именно ты считаешь мусором, которому не стоит уходить на диск?

на сколько я знаю, soft pointers общепринятое название в противовес слабым ссылкам (weak pointers)
Ну допустим у нас есть циклический двусвязный список из пользовательских экземпляров объектов. И пусть в этом списке будет миллион инстансов. В какой то момент нужно обратится к 10000 объекту и отшагать в перед до 11000. Пусть у нас уже есть какой то способ попасть в 10000 напрямую. Итак мы вытянули 10000 в память. он указывает на 9999 и на 10001. Должны ли мы вытягивать и их тоже? Если да — то в итоге мы вытяним весь миллион. он забъет своб ОС и перформанс будет мизерный (это еще если все не рухнет). Если мы не будем вытягивать 9999 и 10001 до тех пор пока они нам не понядобятся, возникнет вопрос, а куда указывают ссылки prev, next из 10000? Для решения этого дело делают или объекты плайсхолдеры, которые заменяются при обращении к ним на настоящие, или мягкие указатели, которые указывают на область диска где расположен объект до того как произойдет инстанциация, после чего они будут указывать уже на область памяти. Как минимум в таком указателе в ram нужно 2 поля — указатель в память и на диск. А вот на диск сбрасывать указатели на объекты в рам смысла нет ни какого. На диске это просто мусор. Я использую мягкие ссылки.

Y>А можно пример, когда неоторые аттрибуты сохранять нет необходимости?

какие нибудь временные объекты. К примеру в моей ОБД не сохраняются TableView (аналог System.Data.DataView но для моих табличек)

Y>Кстати, в моей модели планируется такая штука, как объекты, которые не записываются, в рамках всё той же метафреймовой модели. В метафрейме объекта должно быть просто указание необходимости записи "обратно" в файл, или что-то вроде этого.

Да. Это важно.

Y>Кстати. Является ли твое решение transactionable? А то я после просмотра материала не понял этого.

Ну это интересный вопрос. В текущей версии формально — да. Тот же пример Streams-01 если его запустить позволяет сделать commit|rollback. Но фактически простых commit|rollback в реальной жизни (по крайней мере мне) в том виде в котором я это реализовал на данный момент (in memory snapshot) совершенно недостаточно. Поэтому я продолжаю работу в этом направлении. В будущих версиях поддержка транзакций будет по интереснее. Какая — расскажу после выпуска.

Y>А насчет отображений -- знаешь ли ты такие модели как images (во многих реализациях Lisp, Smalltalk, etc.)? Я в некотором роде оттуда наследую модель отображения, так как некоторым боком любитель Lisp/Smalltalk/etc.

Нет, этого я не знаю. ((( Какая там основная фишка?

Здравствуйте, yrashk, Вы писали:
Y>Предположим, у нас есть объект OneKilo (названия здесь и далее только лишь для удобства). Значение, предположим, (uint32_t)1024 (4 байта). У объекта OneKilo метаобъектом может быть объект Number, у которого собственный метаобъект, например, Object.
Y>У объекта Number может быть, для примера, слоты
Y>- (мета=SymbolicName) "Number"
Y>в свою очередь, SymbolicName может иметь метой Symbol или Object.
Ты случайно не JavaScript пытаешься изобрести

1.1.4 stable rev. 510

Здравствуйте, shuklin, Вы писали:
S>У меня сейчас работают 3 сборщика мусора. Из них один — MSовский из .NET и два собственного изготовления. Надо сказать МС овский для ОБД подходит плохо, с ним приходится бороться.
Кстати, ты не мог бы чуть подробнее рассказать об этом? Я в свое время, когда об этом размышлял, то так и не придумал, как все правильно делать.
Вижу две фундаментальных проблемы:
1. Взаимодействие встроенного сборщика мусора и кэша СУБД.
Обеспечение своевременной уборки объектов, инстанцированных в рамках навигации или выполнения запросов, и при этом все еще приемлемой эффективности.
2. Сборка персистентного мусора.
Тут вообще все сложно. С одной стороны, сам по себе ввод операции Delete для хранимых объектов приводит к тем же проблемам, которые стимулировали развитие управляемых систем с автоматическим управлением памятью:
— риск повисших указателей
— риск двойного удаления
— риск получения утечек — объектов, которые никто не использует, но которые все еще живут.

Вроде как идеалом является автоматический сборщик мусора. Но его реализация упирается в то, что:
— при наличии языка запросов все объекты являются потенциально достижимыми (эта проблема снимается при ограничении чисто навигационными запросами. В таком случае можно считать мусором все объекты, недостижимые из предопределенного root-объекта базы данных)
— честное сканирование графа достижимости для хранимых данных неприемлемо: каждый проход сборщика мусора будет поднимать в память всю базу. А типичные применения СУБД подразумевают объем обрабатываемых данных далеко за пределами емкости оперативной памяти. Существующие сборщики мусора в Java и .Net предполагают большое количество временных объектов, а в базе большинство объектов — долгоживущие.
— подсчет ссылок имеет один фатальный недостаток: неумение детектировать циклы.

Я имел дело с реализацией, где был выбран компромиссный подход: он был основан на счетчике ссылок, но при этом у всех "живых" объектов всегда была "лишняя" ссылка. Так что можно было создать объект, и он жил без того, чтобы на него хоть кто-то сослался. Операция "удаления" снимала эту лишнюю ссылку, и помечала объект специальным флагом. Этот флаг запрещал делать новые ссылки на этот объект. Таким образом, пользователь мог выразить свое желание удалить объект, но реально он удалялся только после того, как на него пропадали все ссылки. Я не помню сейчас, снимались ли ссылки с тех, на кого объект ссылался, при пометке на удаление или только при реальном удалении. В любом случае, этот подход был достаточно рискованным: на практике он работал, но потенциально разработчик мог написать систему, чреватую утечками. Гарантировалась только ссылочная целостность.

1.1.4 stable rev. 510

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

Складывается ощущение дежа вю.Это вы наверно Windows .Net2 описываете

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

Как только не найден готовый класс с соответствующей функциональностью,
все эти монстры мысли начинают изучать low-level API или нанимают C++ программиста
для разработки требуемого компонента

Изучение иерархии классов (1500 в Net framework) по сложности уже приближается
к толкованию Талмуда (и столь же спекулятивно, т.к.постоянная смена условий
порождает изменяющиеся требования = больше классов хороших и разных).
Рост количества классов сводит на нет преимущества быстрой разработки.
Критерием же на самом деле являются стоимость разработки и т.п.
реальные вещи.

Иначе происходит ситуация как с телом Лунного короля (из путешествиях Гулливера )
у которого оторвалась голова и принялась придумывать новый чудесный мир,
но когда ее тело поймало, плотские интересы победили

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

Y>>в свою очередь, SymbolicName может иметь метой Symbol или Object.
S>Ты случайно не JavaScript пытаешься изобрести

?
Я Вас порадую (или наоборот). Нет.

... С уважением, Юрий

Sinclair,

dmz>>Это не "такая возможность". Это просто несколько команд на языке vim-а. yy (скопировать) 999p — вставить 999 раз. Потом, что значит не нужна. 1000 раз может и не нужна, просто скопировать несколько строк — вполне обычное дело.
S>"просто скопировать несколько строк" гораздо проще с помощью мыши.

Мышь для текстового редактора — это очевидный минус. Для людей, которые владеют слепым методом, даже перемещение рук на клавиши управления курсором — это уже существенная задержка, поскольку ломает ритм. А необходимость использования мыши просто уничтожает эффективность.

Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.

Но однажды у меня появился ноут, который страдал неприятным эффектом — даже если выставить на максимум, скорость повтора всё равно была низкой и скорость навигации по файлу методом "нажать и давить" упала просто ниже плинтуса. Чтобы ускориться потребовался пересмотр привычек и понадобились команды "перейти ко второй открывающей скобке, перейти к началу первого идентификатора после знака присваивания, заменить все is_done на is_finished в текущем блоке, добавить закрывающую скобку в конце этого выражения" и так далее.
И разумеется, шорткаты в kate имелись лишь для небольшого числа таких команд, и поэтому было быстрее ткнуть мышой — а это уже неизчезающий оверхед. Переезд на vim позволил избавиться от таких задержек благодаря большому количеству разнообразных примитивных операций.

Волею судьбы я уже полгода работаю под виндой, но до сих пор "vim-way" является эталоном — ценой небольших умственных усилий можно намного уменьшить рутину при редактировании текстов. К сожалению, в царстве "Visual чего-то-там" всё совсем по-другому, прикрутить vim сюда требует существенных усилий, так что я покатился по наклонной (VS, Eclipse, FAR etc.)

dmz>>Это никак не 15 секунд — сначала пришлось бы изучать бейсик или что это было.
S>О да, а знание команд vim наверное инсталлируется прямо в мозг при первом запуске.
Интересная метафора

S>Этот VBA к тому же обладает интеллисенсом и подсказывает, что можно сделать, имена объектов и методов выбраны так, чтобы типичный американец сразу знал, что куда вставлять, а кроме всего прочего, можно включить запись макроса. Поэтому типичная штука — это включить запись, вбить параграф, выключить запись, пойти в редактор макросов и обложить две строчки циклом. Я так в свое время выполнял подбор параметра в Excel для 2000 начальных условий.
Правда, есть замечание: эффективность использования для опытных пользователей важнее чем эффективность обучения.

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

LCR>Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.
Ну что ж, приятно познакомиться

Я никогда не трогал эти настройки. Когда мне надо несколько срабатываний, я в 90% быстро стучу по клавиатуре. Потому, что минимальная задержка (в досе) была практичкски 0 — это умножение почти всех символов. И очень трудно угадать нужное время удерживания.

LCR>Но однажды у меня появился ноут, который страдал неприятным эффектом — даже если выставить на максимум, скорость повтора всё равно была низкой и скорость навигации по файлу методом "нажать и давить" упала просто ниже плинтуса. Чтобы ускориться потребовался пересмотр привычек и понадобились команды "перейти ко второй открывающей скобке, перейти к началу первого идентификатора после знака присваивания, заменить все is_done на is_finished в текущем блоке, добавить закрывающую скобку в конце этого выражения" и так далее.
LCR>И разумеется, шорткаты в kate имелись лишь для небольшого числа таких команд, и поэтому было быстрее ткнуть мышой — а это уже неизчезающий оверхед.
На практике я тоже никогда не копирую мышкой. Навигация с клавиатуры точнее и быстрее. Но я очень интенсивно использую Shift+Ctrl+Right и Shift+Ctrl+Left для выделения по словам (если не использую выделение по строкам).

1.1.4 stable rev. 510

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

S>Складывается ощущение дежа вю.Это вы наверно Windows .Net2 описываете

S>Только в мозгах пропитанных идеологией интерпретаторов могло возникнуть
S>что-либо подобное — любая Вавилонская башня состоит из более чем одного этажа.

Ващето мозги пропитаны нейронными сетями, семантическими сетями фреймов, экспертными системами и прочей ИИшной мутью )))

А за одно пришлось поучаствовать в весьма крупных промышленных проектах, в которых без этой мути ну просто никак (((

С тем, что при существующем объеме классов в FCL .NET стал чудищем страшнее MFC — согласен полностью. Ну законы природы таковы, что сложные проблемы действительно требуют сложных решений и сложных инструментов для их решения.

Вот мне такой инструмент понадобился, я решил сделать его сам, так как я умею делать такие штуки

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

S>Кстати, ты не мог бы чуть подробнее рассказать об этом? Я в свое время, когда об этом размышлял, то так и не придумал, как все правильно делать.

Пришлось натолкнуться на неприятность — правильно сделать нельзя, т.к. придется отказываться от .NET и делать ее заново — а это бред, даже для очень крупной компании. Поэтому я решил сделать чтоб работало. Хотя я вижу что многие вещи получились неудобными. Если кто то тут мне подскажет идею выхода — с удовольствием ей воспользуюсь.

S>Вижу две фундаментальных проблемы:
S>1. Взаимодействие встроенного сборщика мусора и кэша СУБД.
S>Обеспечение своевременной уборки объектов, инстанцированных в рамках навигации или выполнения запросов, и при этом все еще приемлемой эффективности.

Какое решение ИМХО было самым прямым, и какое я и применил. Отслеживать объекты, инстанциированные и на которые еще существуют указатели в рам. Остальные выстроить в список last recently used и выгружать начиная с самых старых. Вобщем так мой первый сборщик и работает. У меня есть класс-паразит над Win32 Heap Alloc который ведет список всех размещенных блоков памяти, следит за очередностью их использования и пытается выгрузить самые старые при превышении колличества размещенных блоков заданной константе или при превышении размера выделенной памяти заданной константе. Эта система размещения работает только для объектов, сопровождающих экземпляры пользовательских объектов. Остальные служебыне объекты размещаются своими собственными средсвами. Ну с виду тут все красиво, более менее. Однако граблей много.

взяли мы ИД объекта и разадресовали по нему указатель на .NET объект. Этот указатель кудато сунули, а потом через пару минут по нему ударили. Но учитывая мою собственную сборку мусора, этот объект уже давно задиспосен и все управляющие структуры выгружены. Возможно в рам есть его клон, но у него уже другой указатель, по любому GPF. Узнать, остались ли ссылки на какойто .NET экземпляр нельзя. Тоесть провести целевую выгрузку какого то конкретного объекта .NET нельзя. Можно ждать, пока сам .NET сборщик мусора начнет собирать объекты и вызовет Finalizer но тут тоже все плохо. Вызов пойдет в отдельном треде, вызов пойдет в совершенно непредсказуемый момент, может уже приложение остановлено БД потушена и сохраняться уже кудато позно. Потом в финализере нет гарантии, что связанные с данным объектом другие объекты еще существуют. + еще проблема — нужно перекрыть финализеры всех пользовательских экземпляров. Тоесть обязать наследовать пользовательские экземпляры от собственного класса => все value types сразу пролетают, и все системные classes тоже. Вобщем слишком много минусов у перекрытия финализера. Я от этого тоже отказался.
Еще один вариант, каждый раз при адресации объекта его блокировать, и затем в ручную unpin когда он не нужен. Так я и поступаю внутри ядра. Но обязать пользователей относится к этому моменту аккуратно во первых жестоко, во вторых нереально. Мне самому не нужна такая ОБД в которой я буду получить выстрел в голову каждый раз как забуду сделать unpin. В ядре, к отладке которого я подхожу осторожно это допустимо. Но не на пользовательском уровне.

В результате остановился на следующей схеме. Итак я возвращаю после разадресации не сам объект а оболочку IConnector. У этой оболочки есть свойство Component через которое доступен пользовательский экземпляр. Оставлять себе указатели на пользовательский экземпляр без сохранения указателя на Connector нельзя. В конструкторе коннектора идет пиннинг объекта. В деструкторе — unpin. В большинстве случаев паттерн работы с объектом выглядит следующим образом:
using(IConnector c = workspace.AttachConnector(h))
{
((MyClass)c.Component).MyMethod(c, ...);
}
Зачем желательно передать в метод c это отдельная тема связанная с паттерном FLYWEIGHT — но это не обязательно.
Итак при разадресации по идентификатору h объекта в методе workspace.AttachConnector возвращается его оболочка IConnector. После завершения работы с объектом эту оболочку необходимо Dispose что удобно с помощью конструкции usint () Если же по каким то причинам using не приемлем, и пользователь забыл или не смог провести Dispose то сам .NET вызовет Dispose в процессе сборки мусора и утечки памяти не будет. Побочный эффект — невозможность использовать экземпляр пользовательского объекта на прямую. На форуме по LINQ мне подсказали одну идею, но она сложна в реализации и всех деталей я еще не знаю. Решает это неудобство лишь частично. Поэтому я оставлю эту проблему как открытую для свободного обсуждения.

S>2. Сборка персистентного мусора.
S>Тут вообще все сложно. С одной стороны, сам по себе ввод операции Delete для хранимых объектов приводит к тем же проблемам, которые стимулировали развитие управляемых систем с автоматическим управлением памятью:
S>- риск повисших указателей
S>- риск двойного удаления
S>- риск получения утечек — объектов, которые никто не использует, но которые все еще живут.

Этим занимается вторая подсистема сборки мусора.

Есть такое дело на 100% ну я решил все очень прямо. У меня в персистент объектах есть счетчики входящих указателей. Когда на объект не указывает ни одного персистент указателя объект удаляется из системы по завершению транзакции или при сборке мусора если он вне транзакции.

S>- при наличии языка запросов все объекты являются потенциально достижимыми (эта проблема снимается при ограничении чисто навигационными запросами. В таком случае можно считать мусором все объекты, недостижимые из предопределенного root-объекта базы данных)

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

S>- честное сканирование графа достижимости для хранимых данных неприемлемо: каждый проход сборщика мусора будет поднимать в память всю базу. А типичные применения СУБД подразумевают объем обрабатываемых данных далеко за пределами емкости оперативной памяти. Существующие сборщики мусора в Java и .Net предполагают большое количество временных объектов, а в базе большинство объектов — долгоживущие.
Согласен полностью. Поэтому второй сборщик мусора работает на той же идее подсчета ссылок, что и COM. Для подсчета ссылок всю БД держать в рам вовсе не нужно. Те объекты, которые участвуют в операциях установки связей по указателям по любому инстанциированы для их апдейта, так что за одно еще и каунтер проинкрементить декрементить — оверхеад мизерный.

S>- подсчет ссылок имеет один фатальный недостаток: неумение детектировать циклы.

Увы да. Чтож, в COM от этого никто не умер пока, хотя неудобств много. И в перспективе можно сделать четвертую подсистему сборки мусора, которая будет работать честно и запускаться во время "сна" системы.

S>Я имел дело с реализацией, где был выбран компромиссный подход: он был основан на счетчике ссылок, но при этом у всех "живых" объектов всегда была "лишняя" ссылка. Так что можно было создать объект, и он жил без того, чтобы на него хоть кто-то сослался. Операция "удаления" снимала эту лишнюю ссылку, и помечала объект специальным флагом. Этот флаг запрещал делать новые ссылки на этот объект. Таким образом, пользователь мог выразить свое желание удалить объект, но реально он удалялся только после того, как на него пропадали все ссылки. Я не помню сейчас, снимались ли ссылки с тех, на кого объект ссылался, при пометке на удаление или только при реальном удалении. В любом случае, этот подход был достаточно рискованным: на практике он работал, но потенциально разработчик мог написать систему, чреватую утечками. Гарантировалась только ссылочная целостность.

Да, у меня похожая система 1 к 1. Даже флаг такой есть, только он действует в пределах рам. При выгрузке объекта из рам принимается окончательное на данное время решение, или он будет таки убит, или останется жив. После выгрузки флаг теряется. лишняя ссылка на объект появляется при включении объекта в лог транзакции. Пока жива транзакция в которой к этому объекту обращались он будет жив даже если его "удалят". Так как в Cerebrum нет принудительного удаления объекта, а есть только операция снятия с него ссылок, логических парадоксов не возникает. Если к концу транзакции ссылок не осталось — объекту хана. Если осталось хоть одна, еще поживет )))

Sinclair,

LCR>>Могу привести одно небольшое наблюдение. Все люди, которых я знаю (включая меня самого), в настройках клавиатуры ставят максимальную скорость повтора автонажатий и минимальную скорость задержки. Зачем? Эти люди очень часто используют действие "нажать и давить", хотя может быть не отдают даже себе в этом отчёт.
S>Ну что ж, приятно познакомиться

Итак, ты говоришь, что не трогаешь настройки, перемещаешься исключительно нажатиями.

Давай рассмотрим такой пример:
Функция полностью на экране, количество строк в функции где-то 60-70 строк. Мы где-то в середине экрана, тут становится понятным, что нужно в начало функции вставить инициализацию чего-нибудь. Для этого нужно перейти на строку чуть ниже заголовка:

CString simpleTest2(const char *url)
{
    error_td_t err;
    roi_proxy_t *ro;
    // надо вот сюда, чтобы вставить эти 2 строки ниже
    // WSADATA wsaData;
    // WSAStartup(MAKELONG(2,0), &wsaData);
    AfxMessageBox(_T("Before Login procedure invocation"));

    ... // далее идут 30 строк кода
    |   // а курсор здесь

PageUp делать нельзя, потому что функция уедет вниз, а хочется её сохранить на экране.

Посему я вижу три альтернативы:
1. Медленно, но верно "нажать и давить" клавишу "вверх".
2. Быстро-быстро нажимать клавишу "вверх".
3. Использовать умный keystroke чтобы сразу попасть в нужное место (vim-way).

Итак, позволь задать следующие вопросы:

1. Что ты делаешь, когда надо несколько десятков срабатываний, и соответствующего шортката (типа Ctrl+Right) нет, как в примере выше?
2. Можешь ли достигнуть "трели" в 10 нажатий в секунду (это скорость автоповтора, на глазок)?

S>На практике я тоже никогда не копирую мышкой. Навигация с клавиатуры точнее и быстрее. Но я очень интенсивно использую Shift+Ctrl+Right и Shift+Ctrl+Left для выделения по словам (если не использую выделение по строкам).
В данном случае нам повезло, ибо есть шорткат (хотя и неудобный:-P).

	От:	shuklin
	Дата:	19.04.06 10:56
	Оценка:	8 (4)

От:	Mystic	http://mystic2000.newmail.ru
Дата:	19.04.06 11:06
Оценка:

	От:	iZEN
	Дата:	19.04.06 11:17
	Оценка:

	От:	shuklin
	Дата:	19.04.06 11:19
	Оценка:

	От:	iZEN
	Дата:	19.04.06 11:31
	Оценка:

	От:	AVC
	Дата:	19.04.06 11:45
	Оценка:	12 (1) +1 -1

	От:	Max.Subpixel
	Дата:	19.04.06 13:47
	Оценка:	3 (1)

От:	Eugene Beschastnov	http://eugenius-nsk.livejournal.com/
Дата:	19.04.06 14:22
Оценка:	+1

	От:	Maxim S. Shatskih
	Дата:	19.04.06 14:32
	Оценка:	-1

От:	EXO	http://www.az.inural.ru
Дата:	20.04.06 11:13
Оценка:

От:	Сергей Губанов	http://sergey-gubanov.livejournal.com/
Дата:	20.04.06 11:21
Оценка:

От:	Ligen	http://zone-of-ambiguity.blogspot.com/
Дата:	21.04.06 20:16
Оценка:

От:	Sinclair	https://github.com/evilguest/
Дата:	23.04.06 13:21
Оценка:	+1

От:	Геннадий Васильев	http://www.livejournal.com/users/gesha_x
Дата:	23.04.06 16:32
Оценка:

От:	Lazy Cjow Rhrr	lj://_lcr_
Дата:	04.05.06 06:32
Оценка: