Magma September 2006

magma@lists.squeakfoundation.org

9 participants
42 discussions

Read Strategies
by Keith Hodges 18 Sep '06

18 Sep '06

Chris, is it possible to set the read strategy subtractively. I.e to a deep level with the exception of one attribute. (MaReadStrategy new) forAny: Page readToDepth: 4; forVariableNamed: 'uselessStuff' readToDepth: 0. many thanks in advance Keith ___________________________________________________________ The all-new Yahoo! Mail goes wherever you go - free your email address from your Internet provider. http://uk.docs.yahoo.com/nowyoucan.html

1 0

Magma seaside updated
by Keith Hodges 18 Sep '06

18 Sep '06

The 'Magma seaside' package has been updated in the www.squeaksource.com/MagmaTester repository, and it contains some useful new features. Experimental WAMagmaSharedSession - shares one magmaSession over many seaside sessions. WAMagmaControlPanel - now a WADispatcherEditor plugin, provides UI for creating, deleting and initialising repositories. Application specific control panels (e.g. PRMagmaControlPanel for pier) ReadStrategies - admin-user can now select a ReadStrategyClass from /seaside/config group #magma. - default read strategy class, builds read strategy via the repository root object. For those using Magma with seaside I would be interested to have any feedback since this is very much a work in progress, and collaboration is invited wherever possible. I would like to compare notes with others that may have done similar work in the past, such as incorporating ReadStrategies into a Magma Seaside application. many thanks in advance Keith ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

[Ann] Magma-seaside ReadStrategy support
by Keith Hodges 17 Sep '06

17 Sep '06

Experimental attempt to add read strategy support to the base Magma seaside package. Magma seaside-kph.31 Added support for read strategy selection in seaside/config and default read strategy may be supplied/modified by the repository root object. Read strategy is updated for every new seaside session (even if the magmaSession is shared) Keith ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html

1 0

Read Strategising
by Keith Hodges 17 Sep '06

17 Sep '06

I am adding a Read Strategy configuration mechanism to the Magma-Seaside package. I am wondering whether to ask the session root object to contribute to the read strategy would be considered bad form? Keith ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

1 0

Questions
by Keith Hodges 17 Sep '06

17 Sep '06

Chris, I am trying to explain to myself how this all works in order to get my head around it. Would you be able to offer any insights on the following: I have a repository which consists of one large fairly fully connected (i.e. many nodes have parent child bi-directional relationships) tree of objects, about 90000 at last count. My web application begins by starting a seaside session, it then decides it needs some data from the repository, so it finds a MagmaSession on the repository and looks in magmaSession root for the start of its data. At this point I assume that Magma rematerialises the root, and every object as it is needed by the application. For a single web page hit I expect to rematerialise 100 to 1000 objects, which seems like a good case for a ReadStrategy (another topic for another day). Now this web application session hangs around in the web server referencing a bunch of these rematerialised objects. So I guess no clearing up happens yet. And if another user hits the web application, starting a new session, sharing the same MagmaSession, more objects will be loaded, and none cleared away. However I notice that no one explicitly holds a reference to the root object, except for the MagmaSession itself, they are referencing other objects in the tree. Does this mean that if the model-tree was not fully connected, the root could be gc'd while the user continues to browse around the leaves? If so would a new user asking the same MagmaSession for its root, would get a fresh instance. If this new user browsed down to the same leaf as the first user, I would hope that they would both be looking at the same object within the one session. If another user goes to the same leaf in a fresh second non-shared magma session then his root-tree and leaf objects are a different rematerialisation of the repository, they are not the same objects as the first two users are looking at. Is this the case? So the first user changes the data in the leaf, the second user sharing the session with the first will see the exact same objects as the first so has no need to 'abort' to see the changes, in fact aborting is a bad idea because the first user may be in the middle of a commit:[] and that would ruin things for him. The third user in his own magmaSession needs to #abort in order for the leaf object changes to be passed to his session. To see the changes I guess he has to let go of his own references to his view on the leaf objects, to back off to some safe unchanged place such as the branch, and then from there re-view the leaf objects which will have been updated. Is this correct? Eventually the webserver is left alone for a while and sessions are discarded, I am assuming that the fact that the MagmaSession has a reference to its root will not stop it from being garbage collected. I also get the idea that it is not a good idea to store a reference to these persisted objects anywhere such as in a Class instance variable since this will simply result in the whole tree remaining memory resident. .. to next email best regards Keith ___________________________________________________________ Yahoo! Messenger - NEW crystal clear PC to PC calling worldwide with voicemail http://uk.messenger.yahoo.com

2 1

Scalability Testing
by Keith Hodges 17 Sep '06

17 Sep '06

So.... as I am scalability testing, I see that my magmaSession cachedObjectCount is now 90000, i.e the whole database is in memory, and still growing. Isn't smalltalk great I can rewrite the code while the test is running. So I figure if I can hunt down who is holding references to the datamodel and get them to let go, the cached object count and my memory usage will fall. I track down one instance of something permanently referencing the root and re-code that. I also notice that due to the design of my Scalability testing framework it is holding at least one reference to the model in an instance var, even when it is paused and not doing anything. So I recoded it while it is running. Still 90000 object count. Where can it be? How does one track down the offending item? Keith ___________________________________________________________ All New Yahoo! Mail Tired of Vi@gr@! come-ons? Let our SpamGuard protect you. http://uk.docs.yahoo.com/nowyoucan.html

3 2

Indexing fix posted to "Magma"
by Chris Muller 16 Sep '06

16 Sep '06

My laptop completed the excruciating #testHeavyAddsAndRemoves on Wednesday, so I'm not expecting any more indexing problems. MagmaServerLoader-cmm.23, and its client and tester counterparts, are now saved to the "Magma" project. Once again, the fix required a file-format enhancement. If you need help converting irreplacable legacy repositories, please let me know.

1 0

Testing pier-magma
by Keith Hodges 16 Sep '06

16 Sep '06

Findings so far. I have persisted 248 pages so far (a far cry from the promised 5000!) but I am doing so slowly. Magma reports 84818 objects from aRepositoryController objectCount. That is an average of 342 objects per page. Although Pier pages do contain a lot of objects to describe what most wiki's store in a single string. 342 seems to be quite a lot. Disk usage is 3Mb for 250 pages which is 12k per page, i.e. 60Mb for a site of 5000 pages with one page generated per Squeak class. So I opened an explorer on the repository and took a look at a simple page. The page generated for Squeak class 'Password' seemed to be quite typical, not too large. (I didn't even know squeak had a class called Password). The page consists of headings, the class comment, a list of subclasses (Password has none) an unordered list of instance methods each being a [broken] link (i.e. pages for individual methods have not been filled in) and a similar unordered list of class methods. Counting objects in the repository explorer I get approximately 102 unique Objects, 50 nil's, and 8 object references. Just for one page! 160 Objects that I can explicitly count, I am not sure what Magma is doing behind the scenes in terms of overhead. The only thing that I can see that could be optimised is the appearance of 9 empty arrays ( #decoration and #children ) which could be lazily initialialized. I doubt if it is worth doing what is the overhead of storing an empty array, as opposed to nil? Keith ___________________________________________________________ Try the all-new Yahoo! Mail. "The New Version is radically easier to use" The Wall Street Journal http://uk.docs.yahoo.com/nowyoucan.html

1 0

[ANN] Pier-ScriptingAPI
by Keith Hodges 15 Sep '06

15 Sep '06

I have uploaded a first release of a scriptingAPI for pier. The aim at this stage is to provide a platform for importing data and hence some scalability testing with pier-magma. There are three classes which implement the same API. a) PRModelScripter - direct operations on the model b) PRCommandScripter - operations via the command interface (logging optional) c) PRCommandAppScripter - as b) but run in the context of the registered application including logging (optional) and persistency. For Data importing PRPierifyToPage provides an abstract class for loading data from a target object into a pier page. Example of use: (PRPierifySmalltalkClass target: Object into: (PRCommandAppScripter onKernelNamed:'pier') So to create a persisted Pier kernel with 5000+ pages, one every 10 seconds. Create a persisted kernel named 'Squeak' using the Magma Control Panel GUI. Then run. PRPierifySmalltalkClass pace: 10. PRPierifySmalltalkClass exampleProtoObject. [ PRPierifySmalltalkClass exampleAllClasses ] forkAt: 15. feedback welcome Keith ___________________________________________________________ All new Yahoo! Mail "The new Interface is stunning in its simplicity and ease of use." - PC Magazine http://uk.docs.yahoo.com/nowyoucan.html

1 0

MagmaCollection API
by goran＠krampe.se 15 Sep '06

15 Sep '06

Howdy all, and Chris of course! Ok, let me show you a method in Gjallar: findObjectById: id "Find any object by id. Return nil if not found." | reader | reader _ cases where: [:each | each read: #id at: id ]. reader size > 1 ifTrue: [self error: 'Multiple objects with the same UUID!']. ^reader size = 1 ifTrue: [reader at: 1] ifFalse: [nil] So "cases" is a MagmaCollection with an index #id. Now... what is the preferred simplest way of doing the #read:at: ? Nowadays this method is not on MagmaCollection but on the reader. So.... the above looks needlessly complex IMHO - or is there a point I am missing? regards, Göran PS. I am now experimenting with a shared magma session in combination with one per user - I drowned in too much materialization otherwise.

3 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma September 2006