Magma August 2008

magma@lists.squeakfoundation.org

3 participants
4 discussions

r41beta10
by Chris Muller 01 Sep '08

01 Sep '08

I have just posted r41Beta10 release to the "MagmaTester" project of squeaksource. The crux of this release was to add the "commitNumber" to every object buffer, which logically associates every object in the repository to its set of commit-log records, granting the potential for associated meta-information stored in the log (such as "timestamp") for "free", and brings the potential for "long transactions" that span session disconnect / reconnects. This release also (hopefully) finalizes Magma's buffer format for future releases. In beta9, there were just 4-bits of available space on each MaObjectBuffer. To accomodate the new commitNumber, these 4-bits were used to specify an "attribute-map" for the buffer (a number between 0 and 15). Legacy maps are map index 0. The new Magma-specific map is 1, which contains a larger header to accomodate the commitNumber as well as some additional filler for possible future fields (without having to jump another map index). A total of 12 bytes per object have been added, so repository sizes will be larger on disk. The implementation allows old buffer formats to be read without having to convert the entire repository at once. When opening a beta9 repository with this beta10 a MagmaWarning will be signaled, indicating that the repository is version 9 and will be updated to version 10, therefore the version 10 code will need to be used going forward. The udpate is instantaneous, the old version 9 *buffers* are left as-is, but any commits will replace them with version 10 buffers. I also fixed a problem with using #commitAndBegin: in conjunction with nested transactions. - Chris

1 0

r41beta9
by Chris Muller 22 Aug '08

22 Aug '08

I've just posted r41Beta9 to the "MagmaTester" project of squeaksource. Earlier in release 41, a new feature / fix was applied that ensured all objects in an old session are updated when the session is reconnected. The way this was implemented slowed down connection times, significantly when a large footprint is cached. This has now been optimized so that connection times are back to normal for not-so-old sessions. Very old sessions may still take some time to bring forward, but everyday images are as fast as they once were. - Chris

1 0

r41Beta8 (was: Changing the class of a v.i.)
by Chris Muller 05 Aug '08

05 Aug '08

Hi Norberto, thank you very much for the test code. I was able to reproduce and fix the problem. You may install "r41Beta8" from the "MagmaTester" project of squeaksource. Now, for as long as you have been using Magma, I know you are aware your classes can evolve with new and different inst vars without having to change the class of your legacy instances. So you are doing something different and unusual here, changing the class of existing instances. Out of curiousity, why are you interested in doing that? - Chris Full details about r41Beta8: - Save TTCFonts similarly to StrikeFonts! - Now detecting objects that have *only* had their class changed in a transaction. - Handling higher-level Error to ensure a sessions transaction-level is decremented. - Fix for excited clients when server coming up problem. - Extra guards for MagmaForwardingProxy's, so they can be used seamlessly as non-persistent objects (i.e., for in-memory domain testing). - MagmaSessionRequest similarly, can now be used non-persistently. - Wait a user-specified timeoutSeconds instead of default timeout, when connecting the initial socket. Don't retry. r41Beta8 consists of the following packages: Ma exception handling-cmm.25 Ma base additions-cmm.105 Ma proxy support-cmm.34 Ma traverse object graphs-cmm.24 MaFixedWidthReport-cmm.4 Ma Statistics-cmm.9 Ma object serialization-cmm.178 Collections-BTree-lr.68 Ma special collections-cmm.91 Ma client server-cmm.157 WriteBarrier-pmm.26 Magma client-cmm.306 Magma server-cmm.267 Ma Armored Code-cmm.120 Ma Squeak domain-cmm.5 Ma special collections tester-cmm.11 Ma object serialization tester-cmm.16 Magma tester-cmm.279 On Mon, Aug 4, 2008 at 11:29 AM, Norberto Manzanos <nmanzanos(a)gmail.com> wrote: > Hi. > > I'm trying to change the class of one instance variable of an object > persistend in a MagmaCollection. > Schematically, what I'm doing is > > open a session > retrive the object > begin transaction > change the classs (using #primitiveChangeClassTo: > commit transaction > close session > > open session > retrieve the object > check the class . FAILS!. > > I tried removing the object from the collection, and readding it, but it > failed too. > Could anybody tell me is there is a special thing I must do to achieve this > need? > > I'm sending a test with an example and some sample classes. > > Thanks in advance. > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

1 0

Changing the class of a v.i.
by Norberto Manzanos 04 Aug '08

04 Aug '08

Hi. I'm trying to change the class of one instance variable of an object persistend in a MagmaCollection. Schematically, what I'm doing is open a session retrive the object begin transaction change the classs (using #primitiveChangeClassTo: commit transaction close session open session retrieve the object check the class . FAILS!. I tried removing the object from the collection, and readding it, but it failed too. Could anybody tell me is there is a special thing I must do to achieve this need? I'm sending a test with an example and some sample classes. Thanks in advance.

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma August 2008