ООDB на основе Pharo

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

А можно мне, а можно мне?

Я не понимаю, о чём вообще речь, в чём прелесть и вообще.

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

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

3 декабря 2014 г., 9:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Для Фаро, как я думаю, хорошо было бы добавить возможность сверхбольших образов, причем только небольшая часть находится в ОЗУ, в идеале размер ОЗУ можно редактировать. Активные объекты подгружаются в память из диска. Даже сохранять всю систему теряет смысл. При таком подходе проблема объектной базы самоустраняется.

3 декабря 2014 г., 14:26 пользователь Nikolay Kleptsov <[hidden email]> написал:

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Вопрос не в том, как объект сохранить (взять и сохранить, в чем пролема?), а как сделать это все надежно и прозрачно.

Не уверен, что можно все это хорошо реализовать, оставаясь в рамках Cog-а — это один из под-вопросов.

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 12:26 пользователь Nikolay Kleptsov <[hidden email]> написал:

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

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

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 12:49 пользователь Nikolay Kleptsov <[hidden email]> написал:

Для Фаро, как я думаю, хорошо было бы добавить возможность сверхбольших образов, причем только небольшая часть находится в ОЗУ, в идеале размер ОЗУ можно редактировать. Активные объекты подгружаются в память из диска. Даже сохранять всю систему теряет смысл. При таком подходе проблема объектной базы самоустраняется.

3 декабря 2014 г., 14:26 пользователь Nikolay Kleptsov <[hidden email]> написал:

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
Я имею ввиду прикладное значение много образности. Скажем имеем некий
image(образ) root(0), который представляет собой дерево из обьектов
ABC где B cодержит пустую коллекцию, а в С имеет место под некую
переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
машины называются Gems, которые читают исходный образ (дерево
обьектов). За чтение образа, его версии, синхронизацию отвечает
посредник, так называемый Stone. Таким образом имеем схему
Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
Каждaя виртуальная машина, видит один и только один образ, читает,
модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
Вот так можно представить жизненный цикл этих двух образов.

Session 1 ....commit ..(верс 1)...........................abort
(хватаем последнюю версию (2)
A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
|                   |                                                   |
C(0)              C(0)                                              C($10000)

Stone
версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
(0).............выбрасываем верс(1)

Session 2..................commit....................(версия 2).....
A->B->{}                    A->B->{}                    A->B->{D. D . D}
|                                |                               |
C($0)                          C($10000)                 C($10000)

Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
несколько обьектов в коллекцию и дает комманду commit на сохранение
изменений. Stone получает список изменений. И создает новую мастер
версию обьектного дерева (root 1). Одна из задач для Stone - это
помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
ему теперь приходится помнить обе версии, на случай если Сессия №2
захочет подгрузить обьект B, то она получит пустую коллекцию,
соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
Весь образ в память виртуалки не грузится, а только некие его части. В
реальной базе С и B могут быть сильно удалены, а образ очень большой.
Тем временем Сессия №2 одновременно, или последовательно (не суть
важно по времени) обновляет обьект С и издает комманду commit. Stone
обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
версию №2 обьектного дерева. Эта версия становится исходным образом
для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
не издается команда abort, на обновление образа, после чего Stone
вручает ей версию №2. Теперь обе сессии видят синхронизированный,
одинаковый образ. Stone отправляет версию №1 в мусор.

Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
очень живым и интересным. Естественно могут быть конфликты если две
сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
опоздал, первый commit выигрывает (optimistic locking).

2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
> написал:
>>
>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>> силу того, что концепция и принцип работы конечного продукта в
>> известной степени меняется в условиях много-образности и унитарности
>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>> существует некий оптимальный обьем транзакции для записи.
>
>
> Не очень понял, что вы имеете в виду.
> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
> получится.
>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
> на одной из презентаций, его разработчики как раз демонстрировали
> подключение нативных нитей: они модифицировали управление памятью и работу
> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
> также, по идее, может быть реализована виртуальная мультитранзакционная
> память.
>
>
>

> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

Как работает жемстоун мне известно. Вопрос же Дениса о том, возможно ли в фаре подобное реализовать на самом смолтолке, не выходя за рамки виртуальной машины. Мой ответ - нельзя. Такое возможно только в системе типа BeeSmalltalk, если, конечно, это вообще возможно. Но лет десять назад, вероятно, никто и подумать не мог, что можно создать смолтолк, в котором и GC, и JIT является частью имиджа, а не виртуальной машины.

3 декабря 2014 г., 2:18 пользователь Alexander Kogan <[hidden email]> написал:

нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
Я имею ввиду прикладное значение много образности. Скажем имеем некий
image(образ) root(0), который представляет собой дерево из обьектов
ABC где B cодержит пустую коллекцию, а в С имеет место под некую
переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
машины называются Gems, которые читают исходный образ (дерево
обьектов). За чтение образа, его версии, синхронизацию отвечает
посредник, так называемый Stone. Таким образом имеем схему
Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
Каждaя виртуальная машина, видит один и только один образ, читает,
модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
Вот так можно представить жизненный цикл этих двух образов.

Session 1 ....commit ..(верс 1)...........................abort
(хватаем последнюю версию (2)
A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
|                   |                                                   |
C(0)              C(0)                                              C($10000)

Stone
версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
(0).............выбрасываем верс(1)

Session 2..................commit....................(версия 2).....
A->B->{}                    A->B->{}                    A->B->{D. D . D}
|                                |                               |
C($0)                          C($10000)                 C($10000)

Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
несколько обьектов в коллекцию и дает комманду commit на сохранение
изменений. Stone получает список изменений. И создает новую мастер
версию обьектного дерева (root 1). Одна из задач для Stone - это
помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
ему теперь приходится помнить обе версии, на случай если Сессия №2
захочет подгрузить обьект B, то она получит пустую коллекцию,
соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
Весь образ в память виртуалки не грузится, а только некие его части. В
реальной базе С и B могут быть сильно удалены, а образ очень большой.
Тем временем Сессия №2 одновременно, или последовательно (не суть
важно по времени) обновляет обьект С и издает комманду commit. Stone
обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
версию №2 обьектного дерева. Эта версия становится исходным образом
для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
не издается команда abort, на обновление образа, после чего Stone
вручает ей версию №2. Теперь обе сессии видят синхронизированный,
одинаковый образ. Stone отправляет версию №1 в мусор.

Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
очень живым и интересным. Естественно могут быть конфликты если две
сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
опоздал, первый commit выигрывает (optimistic locking).

2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
> написал:
>>
>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>> силу того, что концепция и принцип работы конечного продукта в
>> известной степени меняется в условиях много-образности и унитарности
>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>> существует некий оптимальный обьем транзакции для записи.
>
>
> Не очень понял, что вы имеете в виду.
> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
> получится.
>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
> на одной из презентаций, его разработчики как раз демонстрировали
> подключение нативных нитей: они модифицировали управление памятью и работу
> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
> также, по идее, может быть реализована виртуальная мультитранзакционная
> память.
>
>
>

> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Как работает жемстоун мне известно. Вопрос же Дениса о том, возможно ли в фаре подобное реализовать на самом смолтолке, не выходя за рамки виртуальной машины. Мой ответ - нельзя. Такое возможно только в системе типа BeeSmalltalk, если, конечно, это вообще возможно. Но лет десять назад, вероятно, никто и подумать не мог, что можно создать смолтолк, в котором и GC, и JIT является частью имиджа, а не виртуальной машины.

3 декабря 2014 г., 2:18 пользователь Alexander Kogan <[hidden email]> написал:

нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
Я имею ввиду прикладное значение много образности. Скажем имеем некий
image(образ) root(0), который представляет собой дерево из обьектов
ABC где B cодержит пустую коллекцию, а в С имеет место под некую
переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
машины называются Gems, которые читают исходный образ (дерево
обьектов). За чтение образа, его версии, синхронизацию отвечает
посредник, так называемый Stone. Таким образом имеем схему
Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
Каждaя виртуальная машина, видит один и только один образ, читает,
модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
Вот так можно представить жизненный цикл этих двух образов.

Session 1 ....commit ..(верс 1)...........................abort
(хватаем последнюю версию (2)
A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
|                   |                                                   |
C(0)              C(0)                                              C($10000)

Stone
версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
(0).............выбрасываем верс(1)

Session 2..................commit....................(версия 2).....
A->B->{}                    A->B->{}                    A->B->{D. D . D}
|                                |                               |
C($0)                          C($10000)                 C($10000)

Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
несколько обьектов в коллекцию и дает комманду commit на сохранение
изменений. Stone получает список изменений. И создает новую мастер
версию обьектного дерева (root 1). Одна из задач для Stone - это
помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
ему теперь приходится помнить обе версии, на случай если Сессия №2
захочет подгрузить обьект B, то она получит пустую коллекцию,
соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
Весь образ в память виртуалки не грузится, а только некие его части. В
реальной базе С и B могут быть сильно удалены, а образ очень большой.
Тем временем Сессия №2 одновременно, или последовательно (не суть
важно по времени) обновляет обьект С и издает комманду commit. Stone
обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
версию №2 обьектного дерева. Эта версия становится исходным образом
для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
не издается команда abort, на обновление образа, после чего Stone
вручает ей версию №2. Теперь обе сессии видят синхронизированный,
одинаковый образ. Stone отправляет версию №1 в мусор.

Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
очень живым и интересным. Естественно могут быть конфликты если две
сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
опоздал, первый commit выигрывает (optimistic locking).

2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:

>
> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
> написал:
>>
>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>> силу того, что концепция и принцип работы конечного продукта в
>> известной степени меняется в условиях много-образности и унитарности
>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>> существует некий оптимальный обьем транзакции для записи.
>
>
> Не очень понял, что вы имеете в виду.
> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
> получится.
>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
> на одной из презентаций, его разработчики как раз демонстрировали
> подключение нативных нитей: они модифицировали управление памятью и работу
> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
> также, по идее, может быть реализована виртуальная мультитранзакционная
> память.
>
>
>

> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Вопрос чем  лучше ООБД немного  из разряда. Чем Smaltalk лучше С,
Java(нужное вставить). Зависит от поставленых задач наверно. Частично
ответ был озвучен, думать меньше надо,  не надо озадачиваться
поддержкой и совместимостью двух или более продуктов. Из последнего
вытекает более важный момент. Если код имеет потенциал мутировать, то
скажем добавить переменную и еще одно поле в базу это куда ни шло, а
вот добавить subclass да еще с дополнительными связями на комплексный
обьект(ы) может уже стать существенным препоном. Начинают вылезать
дополнительные таблицы, ключи, нормализация. А в OOБД,ну добавил и
добавил. Set все стерпит.

2014-12-03 1:32 GMT-08:00 Nikolay Kleptsov <[hidden email]>:

> А я считаю что можно, если слепо не копировать GemStone. В качестве внешнего
> хранилища данных использовать либо БД либо файловую систему. Дополнительный
> образ контроллер будет определять кто, где хранит части базы и откуда
> загружать данные. Контроль сессии, прав пользователей, конкуренция
> процессов. Контроллер управляет несколькими образами кешами, отдельные
> образы могут иметь свое хранилище, другие разделять.
>
> 3 декабря 2014 г., 15:20 пользователь Denis Kudriashov
> <[hidden email]> написал:
>
>> Как работает жемстоун мне известно. Вопрос же Дениса о том, возможно ли в
>> фаре подобное реализовать на самом смолтолке, не выходя за рамки виртуальной
>> машины. Мой ответ - нельзя. Такое возможно только в системе типа
>> BeeSmalltalk, если, конечно, это вообще возможно. Но лет десять назад,
>> вероятно, никто и подумать не мог, что можно создать смолтолк, в котором и
>> GC, и JIT является частью имиджа, а не виртуальной машины.
>>
>> 3 декабря 2014 г., 2:18 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>
>>> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
>>> Я имею ввиду прикладное значение много образности. Скажем имеем некий
>>> image(образ) root(0), который представляет собой дерево из обьектов
>>> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
>>> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
>>> машины называются Gems, которые читают исходный образ (дерево
>>> обьектов). За чтение образа, его версии, синхронизацию отвечает
>>> посредник, так называемый Stone. Таким образом имеем схему
>>> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
>>> Каждaя виртуальная машина, видит один и только один образ, читает,
>>> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
>>> Вот так можно представить жизненный цикл этих двух образов.
>>>
>>> Session 1 ....commit ..(верс 1)...........................abort
>>> (хватаем последнюю версию (2)
>>> A->B->{}       A->B->{D. D . D}                            A->B->{D. D .
>>> D}
>>> |                   |                                                   |
>>> C(0)              C(0)
>>> C($10000)
>>>
>>> Stone
>>> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
>>> (0).............выбрасываем верс(1)
>>>
>>> Session 2..................commit....................(версия 2).....
>>> A->B->{}                    A->B->{}                    A->B->{D. D . D}
>>> |                                |                               |
>>> C($0)                          C($10000)                 C($10000)
>>>
>>> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
>>> несколько обьектов в коллекцию и дает комманду commit на сохранение
>>> изменений. Stone получает список изменений. И создает новую мастер
>>> версию обьектного дерева (root 1). Одна из задач для Stone - это
>>> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
>>> ему теперь приходится помнить обе версии, на случай если Сессия №2
>>> захочет подгрузить обьект B, то она получит пустую коллекцию,
>>> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
>>> Весь образ в память виртуалки не грузится, а только некие его части. В
>>> реальной базе С и B могут быть сильно удалены, а образ очень большой.
>>> Тем временем Сессия №2 одновременно, или последовательно (не суть
>>> важно по времени) обновляет обьект С и издает комманду commit. Stone
>>> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
>>> версию №2 обьектного дерева. Эта версия становится исходным образом
>>> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
>>> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
>>> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
>>> не издается команда abort, на обновление образа, после чего Stone
>>> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
>>> одинаковый образ. Stone отправляет версию №1 в мусор.
>>>
>>> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
>>> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
>>> очень живым и интересным. Естественно могут быть конфликты если две
>>> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
>>> опоздал, первый commit выигрывает (optimistic locking).
>>>
>>> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>> >
>>> > 2 декабря 2014 г., 22:19 пользователь Alexander Kogan
>>> > <[hidden email]>
>>> > написал:
>>> >>
>>> >> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> >> силу того, что концепция и принцип работы конечного продукта в
>>> >> известной степени меняется в условиях много-образности и унитарности
>>> >> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> >> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> >> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> >> существует некий оптимальный обьем транзакции для записи.
>>> >
>>> >
>>> > Не очень понял, что вы имеете в виду.
>>> > В традиционном смолтолке со статичной и отделенной виртуальной машиной
>>> > не
>>> > возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>>> > поддерживает нативные потоки, то, находясь внутри имиджа, реализовать
>>> > их не
>>> > получится.
>>> >  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины
>>> > как
>>> > таковой не существует, есть только исполняемый и самомодифицируемый
>>> > образ. И
>>> > на одной из презентаций, его разработчики как раз демонстрировали
>>> > подключение нативных нитей: они модифицировали управление памятью и
>>> > работу
>>> > планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>>> > также, по идее, может быть реализована виртуальная мультитранзакционная
>>> > память.
>>> >
>>> >
>>> >
>>> > --
>>> > --
>>> > http://groups.google.ru/group/sugr
>>> > ---
>>> > Вы получили это сообщение, поскольку подписаны на группу "Russian
>>> > Smalltalk
>>> > User Group".
>>> > Чтобы отменить подписку на эту группу и больше не получать от нее
>>> > сообщения,
>>> > отправьте письмо на электронный адрес
>>> > [hidden email].
>>> > Чтобы настроить другие параметры, перейдите по ссылке
>>> > https://groups.google.com/d/optout.
>>>
>>> --
>>> --
>>> http://groups.google.ru/group/sugr
>>> ---
>>> Вы получили это сообщение, поскольку подписаны на группу Russian
>>> Smalltalk User Group.
>>>
>>> Чтобы отменить подписку на эту группу и больше не получать от нее
>>> сообщения, отправьте письмо на электронный адрес
>>> [hidden email].
>>> Настройки подписки и доставки писем: https://groups.google.com/d/optout.
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian
>> Smalltalk User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее
>> сообщения, отправьте письмо на электронный адрес
>> [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.
>
>
> --
> --
> http://groups.google.ru/group/sugr
> ---
> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
> User Group".
> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
> отправьте письмо на электронный адрес [hidden email].
> Чтобы настроить другие параметры, перейдите по ссылке
> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

3 декабря 2014 г., 12:29 пользователь Dennis Schetinin <[hidden email]> написал:

Денис, а чего не хватает для этого? И, если необходимо допиливать виртуалку, то насколько сильно?

На этот вопрос я ответить не могу

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Сохранять объект не так легко как покажется. В Pharo да и в других Smalltalk системах есть специальные объекты (процесс, блок). Процесс жестко связан с ОС. У процесса есть контекст, стек команд и т.д.. Блок являющийся объектом, на самом деле располагается в каком-нибудь методе. Одновременно является объектом со ссылкой, и частью метода. Далее индексированные объекты тоже различные, начиная с байтовых и заканчивая двойным словом (4 байта). В одних содержатся ссылки, в других просто байты данных. Еще добавить индексированные переменные и именованные. А ведь еще есть PoolVariables, переменные класса

3 декабря 2014 г., 14:48 пользователь Dennis Schetinin <[hidden email]> написал:

Вопрос не в том, как объект сохранить (взять и сохранить, в чем пролема?), а как сделать это все надежно и прозрачно.

Не уверен, что можно все это хорошо реализовать, оставаясь в рамках Cog-а — это один из под-вопросов.

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 12:26 пользователь Nikolay Kleptsov <[hidden email]> написал:

Денис, я понял вашу мысль. Создать объектную базу оставаясь в рамках Фаро и Ког ВМ и без использования какой-нибудь БД.

На мой вопрос как сохранять отдельные объекты оставаясь в пределах Фаро, ответа не получил.

Магма сохраняет в файлы в специальную директорию. Но последней версией Фаро не поддерживается.

3 декабря 2014 г., 12:51 пользователь Dennis Schetinin <[hidden email]> написал:

Я спрашиваю в разрезе

Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
силу того, что концепция и принцип работы конечного продукта в
известной степени меняется в условиях много-образности и унитарности
транзакций.

Ведь то, что вы описали не обязательно должно быть "вшито" на самом нижнем уровне?

Денис, в Pharo же тоже ведутся работы в направлении большей свободы изменения Smalltalk-а из самого Smalltalk-а. Это совсем не то, что нужно для обсуждаемой задачи? Или этого просто мало? Насколько необходима именно новая динамическая ВМ, чего не хватает в "аксиоматике" существующих? 

Моя мысль: сформировать список необходимых изменений, которые позволят менять способ управления памятью: дать возможность рассматривать ее лишь как кэш, то есть не загружать/сохранять все объекты разом), согласовывать работу нескольких образов примерно так, как описал Александр… ну, и всего, что для этого надо. Мы в состоянии это сделать? Ходя бы в каком-то общем виде для начала? Или, может быть, это действительно никому не надо?

Николай, вы действительно не понимаете, чего я хочу и зачем это надо? 

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 10:39 пользователь Dennis Schetinin <[hidden email]> написал:

Александр, спасибо!

А что нужно сделать/переделать в Pharo чтобы что-то подобное можно было реализовать?

--

Best regards,

Dennis Schetinin

3 декабря 2014 г., 3:28 пользователь Alexander Kogan <[hidden email]> написал:

Stone, Gem №1 и Gem № 2 могут находиться на одной и той же машине, а
могут на разных концах планеты

2014-12-02 15:18 GMT-08:00 Alexander Kogan <[hidden email]>:

> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
> Я имею ввиду прикладное значение много образности. Скажем имеем некий
> image(образ) root(0), который представляет собой дерево из обьектов
> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
> машины называются Gems, которые читают исходный образ (дерево
> обьектов). За чтение образа, его версии, синхронизацию отвечает
> посредник, так называемый Stone. Таким образом имеем схему
> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
> Каждaя виртуальная машина, видит один и только один образ, читает,
> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
> Вот так можно представить жизненный цикл этих двух образов.
>
> Session 1 ....commit ..(верс 1)...........................abort
> (хватаем последнюю версию (2)
> A->B->{}       A->B->{D. D . D}                            A->B->{D. D . D}
> |                   |                                                   |
> C(0)              C(0)                                              C($10000)
>
> Stone
> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
> (0).............выбрасываем верс(1)
>
> Session 2..................commit....................(версия 2).....
> A->B->{}                    A->B->{}                    A->B->{D. D . D}
> |                                |                               |
> C($0)                          C($10000)                 C($10000)
>
> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
> несколько обьектов в коллекцию и дает комманду commit на сохранение
> изменений. Stone получает список изменений. И создает новую мастер
> версию обьектного дерева (root 1). Одна из задач для Stone - это
> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
> ему теперь приходится помнить обе версии, на случай если Сессия №2
> захочет подгрузить обьект B, то она получит пустую коллекцию,
> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
> Весь образ в память виртуалки не грузится, а только некие его части. В
> реальной базе С и B могут быть сильно удалены, а образ очень большой.
> Тем временем Сессия №2 одновременно, или последовательно (не суть
> важно по времени) обновляет обьект С и издает комманду commit. Stone
> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
> версию №2 обьектного дерева. Эта версия становится исходным образом
> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
> не издается команда abort, на обновление образа, после чего Stone
> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
> одинаковый образ. Stone отправляет версию №1 в мусор.
>
> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
> очень живым и интересным. Естественно могут быть конфликты если две
> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
> опоздал, первый commit выигрывает (optimistic locking).
>
> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>
>> 2 декабря 2014 г., 22:19 пользователь Alexander Kogan <[hidden email]>
>> написал:
>>>
>>> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>> силу того, что концепция и принцип работы конечного продукта в
>>> известной степени меняется в условиях много-образности и унитарности
>>> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>> существует некий оптимальный обьем транзакции для записи.
>>
>>
>> Не очень понял, что вы имеете в виду.
>> В традиционном смолтолке со статичной и отделенной виртуальной машиной не
>> возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>> поддерживает нативные потоки, то, находясь внутри имиджа, реализовать их не
>> получится.
>>  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины как
>> таковой не существует, есть только исполняемый и самомодифицируемый образ. И
>> на одной из презентаций, его разработчики как раз демонстрировали
>> подключение нативных нитей: они модифицировали управление памятью и работу
>> планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>> также, по идее, может быть реализована виртуальная мультитранзакционная
>> память.
>>
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---

Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

сделать можно все. Не боги горшки обжигают.
 Магма казалось бы на самом деле не плохая стартовая точка. но
ньюансов  много. Большие проблемы начинаются скажем c GC очень
большого образа, большая часть которого на диске, а не в памяти. или
вещи типа allInstances

2014-12-03 2:03 GMT-08:00 Alexander Kogan <[hidden email]>:

> Вопрос чем  лучше ООБД немного  из разряда. Чем Smaltalk лучше С,
> Java(нужное вставить). Зависит от поставленых задач наверно. Частично
> ответ был озвучен, думать меньше надо,  не надо озадачиваться
> поддержкой и совместимостью двух или более продуктов. Из последнего
> вытекает более важный момент. Если код имеет потенциал мутировать, то
> скажем добавить переменную и еще одно поле в базу это куда ни шло, а
> вот добавить subclass да еще с дополнительными связями на комплексный
> обьект(ы) может уже стать существенным препоном. Начинают вылезать
> дополнительные таблицы, ключи, нормализация. А в OOБД,ну добавил и
> добавил. Set все стерпит.
>
> 2014-12-03 1:32 GMT-08:00 Nikolay Kleptsov <[hidden email]>:
>> А я считаю что можно, если слепо не копировать GemStone. В качестве внешнего
>> хранилища данных использовать либо БД либо файловую систему. Дополнительный
>> образ контроллер будет определять кто, где хранит части базы и откуда
>> загружать данные. Контроль сессии, прав пользователей, конкуренция
>> процессов. Контроллер управляет несколькими образами кешами, отдельные
>> образы могут иметь свое хранилище, другие разделять.
>>
>> 3 декабря 2014 г., 15:20 пользователь Denis Kudriashov
>> <[hidden email]> написал:
>>
>>> Как работает жемстоун мне известно. Вопрос же Дениса о том, возможно ли в
>>> фаре подобное реализовать на самом смолтолке, не выходя за рамки виртуальной
>>> машины. Мой ответ - нельзя. Такое возможно только в системе типа
>>> BeeSmalltalk, если, конечно, это вообще возможно. Но лет десять назад,
>>> вероятно, никто и подумать не мог, что можно создать смолтолк, в котором и
>>> GC, и JIT является частью имиджа, а не виртуальной машины.
>>>
>>> 3 декабря 2014 г., 2:18 пользователь Alexander Kogan <[hidden email]>
>>> написал:
>>>
>>>> нативные нити и планировщик на мой взгляд не совсем то о чем я говорю.
>>>> Я имею ввиду прикладное значение много образности. Скажем имеем некий
>>>> image(образ) root(0), который представляет собой дерево из обьектов
>>>> ABC где B cодержит пустую коллекцию, а в С имеет место под некую
>>>> переменную. Стартуем две виртуальные машины, в GEMSTONE виртуальные
>>>> машины называются Gems, которые читают исходный образ (дерево
>>>> обьектов). За чтение образа, его версии, синхронизацию отвечает
>>>> посредник, так называемый Stone. Таким образом имеем схему
>>>> Gem (Session 1) -------------->Stone<--------------Gem(Session 2).
>>>> Каждaя виртуальная машина, видит один и только один образ, читает,
>>>> модифицирует обьекты в нем. Понятия по большому с чету о других Gems.
>>>> Вот так можно представить жизненный цикл этих двух образов.
>>>>
>>>> Session 1 ....commit ..(верс 1)...........................abort
>>>> (хватаем последнюю версию (2)
>>>> A->B->{}       A->B->{D. D . D}                            A->B->{D. D .
>>>> D}
>>>> |                   |                                                   |
>>>> C(0)              C(0)
>>>> C($10000)
>>>>
>>>> Stone
>>>> версия(0)..->..версия(1)..синхр . ->   версия (2) выбр верс
>>>> (0).............выбрасываем верс(1)
>>>>
>>>> Session 2..................commit....................(версия 2).....
>>>> A->B->{}                    A->B->{}                    A->B->{D. D . D}
>>>> |                                |                               |
>>>> C($0)                          C($10000)                 C($10000)
>>>>
>>>> Изначально обе сессии видят нулевую версию образа. Сессия №1 добавляет
>>>> несколько обьектов в коллекцию и дает комманду commit на сохранение
>>>> изменений. Stone получает список изменений. И создает новую мастер
>>>> версию обьектного дерева (root 1). Одна из задач для Stone - это
>>>> помнить, что Сессия №2 все еще работает с исходной версией №0, поэтому
>>>> ему теперь приходится помнить обе версии, на случай если Сессия №2
>>>> захочет подгрузить обьект B, то она получит пустую коллекцию,
>>>> соответсвующую версии (0) ассоциируемой с данной виртуальной машиной.
>>>> Весь образ в память виртуалки не грузится, а только некие его части. В
>>>> реальной базе С и B могут быть сильно удалены, а образ очень большой.
>>>> Тем временем Сессия №2 одновременно, или последовательно (не суть
>>>> важно по времени) обновляет обьект С и издает комманду commit. Stone
>>>> обьединяет версию (1) и изменения исходящие от Сессии 2 и создает
>>>> версию №2 обьектного дерева. Эта версия становится исходным образом
>>>> для Сессии №2. Одновременно выбрасывается в мусор версия №0, поскольку
>>>> ни одна из сессий на больше  в ней не нуждается. Сессия №1 продолжает
>>>> наблюдать версию №1 (т.е читая обьект С, получает $0) до тех пор, пока
>>>> не издается команда abort, на обновление образа, после чего Stone
>>>> вручает ей версию №2. Теперь обе сессии видят синхронизированный,
>>>> одинаковый образ. Stone отправляет версию №1 в мусор.
>>>>
>>>> Таким образом 2 сессии могут иметь 1 или 2 образа одновременно, 3 - 3
>>>> и т.д. Сессий может быть и сто, и тысяча и десять. Все становиться
>>>> очень живым и интересным. Естественно могут быть конфликты если две
>>>> сессии модифицировали один и тот же обьект.  Тогда кто не успел тот
>>>> опоздал, первый commit выигрывает (optimistic locking).
>>>>
>>>> 2014-12-02 12:40 GMT-08:00 Denis Kudriashov <[hidden email]>:
>>>> >
>>>> > 2 декабря 2014 г., 22:19 пользователь Alexander Kogan
>>>> > <[hidden email]>
>>>> > написал:
>>>> >>
>>>> >> Концепция подгрузить Gemstone, немного бессмысленна сама по себе в
>>>> >> силу того, что концепция и принцип работы конечного продукта в
>>>> >> известной степени меняется в условиях много-образности и унитарности
>>>> >> транзакций. Приходится решать вопрос как часто сохранять/обновлять
>>>> >> образ(ы). В случае с Gemstone можно это делать хоть после каждого
>>>> >> изменения обьекта, без каких-то принципиальных потерь, хотя несомненно
>>>> >> существует некий оптимальный обьем транзакции для записи.
>>>> >
>>>> >
>>>> > Не очень понял, что вы имеете в виду.
>>>> > В традиционном смолтолке со статичной и отделенной виртуальной машиной
>>>> > не
>>>> > возможно уйти за рамки ее "аксиоматики". Например, если виртуалка не
>>>> > поддерживает нативные потоки, то, находясь внутри имиджа, реализовать
>>>> > их не
>>>> > получится.
>>>> >  В BeeSmalltalk (Mist, Pinochio и другие аналоги) виртуальной машины
>>>> > как
>>>> > таковой не существует, есть только исполняемый и самомодифицируемый
>>>> > образ. И
>>>> > на одной из презентаций, его разработчики как раз демонстрировали
>>>> > подключение нативных нитей: они модифицировали управление памятью и
>>>> > работу
>>>> > планировщика. Все было сделано вживую, находясь внутри смолтолка, Точно
>>>> > также, по идее, может быть реализована виртуальная мультитранзакционная
>>>> > память.
>>>> >
>>>> >
>>>> >
>>>> > --
>>>> > --
>>>> > http://groups.google.ru/group/sugr
>>>> > ---
>>>> > Вы получили это сообщение, поскольку подписаны на группу "Russian
>>>> > Smalltalk
>>>> > User Group".
>>>> > Чтобы отменить подписку на эту группу и больше не получать от нее
>>>> > сообщения,
>>>> > отправьте письмо на электронный адрес
>>>> > [hidden email].
>>>> > Чтобы настроить другие параметры, перейдите по ссылке
>>>> > https://groups.google.com/d/optout.
>>>>
>>>> --
>>>> --
>>>> http://groups.google.ru/group/sugr
>>>> ---
>>>> Вы получили это сообщение, поскольку подписаны на группу Russian
>>>> Smalltalk User Group.
>>>>
>>>> Чтобы отменить подписку на эту группу и больше не получать от нее
>>>> сообщения, отправьте письмо на электронный адрес
>>>> [hidden email].
>>>> Настройки подписки и доставки писем: https://groups.google.com/d/optout.
>>>
>>>
>>> --
>>> --
>>> http://groups.google.ru/group/sugr
>>> ---
>>> Вы получили это сообщение, поскольку подписаны на группу "Russian
>>> Smalltalk User Group".
>>> Чтобы отменить подписку на эту группу и больше не получать от нее
>>> сообщения, отправьте письмо на электронный адрес
>>> [hidden email].
>>> Чтобы настроить другие параметры, перейдите по ссылке
>>> https://groups.google.com/d/optout.
>>
>>
>> --
>> --
>> http://groups.google.ru/group/sugr
>> ---
>> Вы получили это сообщение, поскольку подписаны на группу "Russian Smalltalk
>> User Group".
>> Чтобы отменить подписку на эту группу и больше не получать от нее сообщения,
>> отправьте письмо на электронный адрес [hidden email].
>> Чтобы настроить другие параметры, перейдите по ссылке
>> https://groups.google.com/d/optout.

--
--
http://groups.google.ru/group/sugr
---
Вы получили это сообщение, поскольку подписаны на группу Russian Smalltalk User Group.

Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес [hidden email].
Настройки подписки и доставки писем: https://groups.google.com/d/optout.