Magma January 2007

magma@lists.squeakfoundation.org

11 participants
13 discussions

[ANN] MagmaServerLoader-cmm.25
by Chris Muller 08 Mar '07

08 Mar '07

I am pleased to announce the latest Magma upgrade! The main thrust of this release are bug fixes but, primarily, one particular bug which required a significant amount of work; complete transparency of "pseudo-persistent" MagmaCollectionReaders. By pseudo-persistent I mean Readers that are the result-sets of a query on a new, automatically created MagmaCollection borned from using one of the "luxury" query features (either distinctness or sorting by other than the most-optimal attribute) on another MagmaCollection. Although these new Reader/Collection pairs, are not (initially, at least) truly persistent because they are not referenced by the persistent object model, they do, like persistent collections, require support by back-end (hash-index) files and managed by a server object. Until now, attempting to further query these "result set" Readers or attach them to the persistent graph did not work. Now it does. Further, thanks to Hilaire's great suggestion, further querying of Readers is fully symmetrical with MagmaCollections, i.e., you can use #where: and friends on a Reader. I don't think Brent will like this but.. along with this is the notion that the back-end files for "result sets" are no longer deleted simply because the creator session disconnects. They can't be. Just because a session disconnects doesn't mean its done with the MagmaCollectionReader in its image. For example, the disconnect could just be a side-effect of saving the image. So how are back-end files ever removed? Via MagmaCompressor. So, applications that allow users to run many hundreds of "luxury" queries, will accumulate quite a few result-set support files. This would pose a problem for the Magma server, up until now, because the server would open all known MagmaCollection and index files upon starting, and any queries would create (and open) files that would remain open until the server was shut down. No longer. Now, all files are now opened lazily! The Magma server should start more quickly now. Further, to mitigate the sheer number of open file handles for query result sets, Magma now employs a "file pool" to limit the number of simultaneously-open files. The user may set the maximum number of open files via #filePoolSize: (the default is 60), and oldest-accessed files are closed. Not only does this allow a good approach to dealing with many query result sets, it is more ISP-friendly (some ISP's restrict the number of simultaneously-open files you may have). For those familiar with Magma's meta-model (MagmaRepositoryDefinition), it no longer includes 'allLargeCollections'. This turned out to be significant addition-by-subtraction. There is a reduction in the model, code (including some special-case code) and number of byte-code instructions the computer must execute. A win win win all-around. Caveats: Ah, of course. Besides the aforementioned potential file explosion, it is now important to let Magma have the entire directory. __Do not keep any of your own important files in any Magma repository directory__ because MagmaRepositoryController>>#delete: now simply deletes all files in the directory. Upgrading: Guess what?! All existing databases are completely compatible with the new code. Why? Because, in spite of the change in Magma's meta model, the class mapping permits "dynamic evolution" of the class model, and removal of an instance variable is actually the simplest case. Other fixes: - Fixed bug with MagmaCollection>>#asArray:. Thanks to Göran's team! - Fixed at:ifOutOfBounds: sometimes giving error instead of valuing the outOfBoundsBlock reported by Göran. - Added Form and BitMap to default ReadStrategy, 99999 depth, thanks Hilaire for reporting. - ensure MaTransactionalFileStreams are always binary, this fixes the "Outage occurred" message in 3.9. I spent a lot of time on this and believe it to be a quality release. It is, therefore, the new Magma baseline which I've posted to both the "Magma" project as well as the "MagmaTester" project. Enjoy!

3 2

Magma Seaside package?
by Thierry Thelliez 09 Feb '07

09 Feb '07

Exploring how Seaside and Magma could work together, I am trying to install Magma in a 3.9 image. According to http://wiki.squeak.org/squeak/5817 the 'Magma seaside' package is needed. I cannot find it... In the SqueakMap browser I see Magma server, client and tester. But no Magma seaside. I did find the MagmaServerLoader through Montecillo. I guess that the following code is a little bit out of date (from the Pier install script): magma := squeaksource project: 'MagmaTester'. magma install: 'MagmaServerLoader'; install: 'Magma server'; install: 'Magma client'; install: 'Magma seaside'; install: 'Magma sunit'. How can I try Seaside+Magma in a 3.9 image? Thank, Thierry

5 8

[Fwd: Re: Magma Seaside package?]
by Jens Pall 31 Jan '07

31 Jan '07

This didn't make it to the list, so ... -------- Original Message -------- Subject: Re: Magma Seaside package? Date: Tue, 30 Jan 2007 22:31:05 -0300 From: Ramiro Diaz Trepat <ramirodt(a)gmail.com> To: Jens Pall <jens(a)axonspace.com> Yes Göran, it would be really great to have a stripped down version of your Gjallar to look at. On 1/30/07, Jens Pall <jens(a)axonspace.com> wrote: > Göran Krampe wrote: > > > Btw, I have the intention of sitting down and "strip" Gjallar down to a > > very small example app which only does login/logut and has a trivial > > domain model. This way it could be used as a neat starting point for > > building an app. > > I would be very much interested in such an example since I am trying to > work my way towards using Magma along with Seaside. I installed Gjallar > and found it a bit intimidating for a Smalltalk novice like me (besides > having some trouble logging in at first :) > > JP > > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma >

3 4

Magma logo
by Giuseppe Luigi Punzi 30 Jan '07

30 Jan '07

Hi. I'm putting on my web the logo of all the resources I use. I would like to know if magma has his own logo to use on my resources page. Cheers.- -- Giuseppe Luigi Punzi - Consultor :: ZYO Consulting :: email: glpunzi(a)zyoconsulting.com tlfno: +34 675 145 912 web: http://www.zyoconsulting.com

2 1

Seaside and Magma: first steps into Gjallar
by Thierry Thelliez 29 Jan '07

29 Jan '07

(disclaimer: I am new to Squeak/Seaside/Magma/) I am trying to understand how to use Seaside and Magma. In another thread someone mentioned Gjallar. I downloaded gjallar-0.3. Out of the box it works (I get the login screen but I have not yet found the username/password). My main issue is the upgrading. On the bottom right of the opened image there are instructions: "To upgrade Gjallar, use the http://mc.gjallar.se repository opened up to the left." Maybe I do not understand Montecillo but I clicked on the top right window, on the Q2v0.3 link, then on the refresh button. This shown two new versions: Q2v0.3-gk.229.mcz and Q2v0.3-gk.228.mcz. Apprently I have 227. I clicked on 229 and pressed the Load button. Gjallar would not work after that. Errors on the web pages about Magma. How does one update to the latest/greatest? Thanks, Thierry

2 2

No MagmaCommitError with two local sessions
by Giovanni Corriga 26 Jan '07

26 Jan '07

Hi all, the following snippet session1 begin. session1 root at: #foo put: #bar. session2 commit: [session2 root at: #foo put: #baz]. session1 commit. results in a MagmaCommitError, as it should, when the sessions are remote and created with #hostAddress:port: , but runs successfully when the two sessions are created using #openLocal: . Is this expected, or is it a bug? Ciao, Giovanni

3 6

Re: How to optimise memory consumption
by Chris Muller 26 Jan '07

26 Jan '07

Hi Martin, its hard to say why your image might be growing. So that we may try to work on the problem from a common perspective, I created three test scripts that attempt to recreate the problem. "Create script" | path | path _ 'c:\temp\memLeakCheck'. mc _ MagmaCollection new addIndex: (MaUUIDIndex attribute: #key); yourself. MagmaRepositoryController create: path root: (Dictionary new at: 'mc' put: mc; yourself) "start server in one image" | path | path _ 'c:\temp\memLeakCheck'. MagmaServerConsole new open: path ; processOn: 1010 ; inspect "load from client in another image" | mc session | session _ MagmaSession hostAddress: #(127 0 0 1) asByteArray port: 1010. session connectAs: 'loader'. mc _ session root at: 'mc'. session begin. 1 to: 25000 do: [ : n | mc add: UUID new -> nil. n \\ 1000 = 0 ifTrue: [ | timeToRun | Transcript cr; show: 'committing ', n printString, '... '. timeToRun _ [session commitAndBegin] durationToRun. Transcript show: timeToRun printString ] ]. session commitAndBegin ; disconnect Running both images on my laptop, here is the output from the client: committing 1000... 0:00:00:12.616 committing 2000... 0:00:00:17.148 committing 3000... 0:00:00:14.84 committing 4000... 0:00:00:16.814 committing 5000... 0:00:00:15.773 committing 6000... 0:00:00:13.942 committing 7000... 0:00:00:17.519 committing 8000... 0:00:00:15.909 committing 9000... 0:00:00:14.148 committing 10000... 0:00:00:19.148 committing 11000... 0:00:00:13.307 committing 12000... 0:00:00:17.941 committing 13000... 0:00:00:15.093 committing 14000... 0:00:00:15.174 committing 15000... 0:00:00:19.248 committing 16000... 0:00:00:14.536 committing 17000... 0:00:00:17.181 committing 18000... 0:00:00:16.068 committing 19000... 0:00:00:14.807 committing 20000... 0:00:00:20.409 committing 21000... 0:00:00:14.279 committing 22000... 0:00:00:20.054 committing 23000... 0:00:00:16.961 committing 24000... 0:00:00:14.754 committing 25000... 0:00:00:17.994 I also observed the memory consumption of both images. It remained within about 1MB of their original starting allocatioon through the entire test. I, too, am running on Windows XP, albeit with just 768MB RAM. Do the above scripts work for you too? Or, can you modify the scripts in some way that exposes the apparent memory leak? I will be happy to fix whatever bugs we can find through this process. Or, if you have more detailed information about your tests I will do my best to interpret what the problem may be. Regards, Chris PS - On the server, you may also run this script to see what "Ma" classes may be staying referenced and therefore causing image growth. ((MaObject allSubclasses collect: [ : each | each -> each instanceCount ]) asSortedCollection: [ : a : b | a value > b value ]) Also, there is a Swiki page about memory utilization.. ----- Original Message ---- From: Martin Beck <martin.beck(a)hpi.uni-potsdam.de> To: magma(a)lists.squeakfoundation.org Sent: Friday, January 19, 2007 6:19:19 AM Subject: How to optimise memory consumption Hey, we're running around 100 tests which work with the database (e.g. create the whole database for testing, etc.). Even if we don't use our session pooling and clean up all magmasessions on the client afterwards, the server image consumes around 250mb while it started with 30mb.... Any hints to keep memory consumption down? Running on WindowsXP with 2gb ram... Regards, Martin _______________________________________________ Magma mailing list Magma(a)lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma

3 2

Magma in production
by Giuseppe Luigi 24 Jan '07

24 Jan '07

Hi all, Probably, I will start a project soon, and I would like do it on Smalltalk and an ODBMS What I need is to know if Magma is fully stable for a production app. This app (surely with Seaside UI) will be a multiuser Sales Management (sorry, I don't know how to translate from spanish "Software de Gestión") and this project will be my first project on squeak and ODBMS's. Cheers.

2 1

[ANN] Magma 1.0r39
by Chris Muller 24 Jan '07

24 Jan '07

I have just posted a new version of Magma with Keith Hodges' relative-path support enhancement. Now that they are officially included, I hope Keith will update his Seaside-Magma-Pier (wiki out of the box) image. There are number of other minor enhancements, fixes and performance improvements: - Ability to reference a MagmaSession in the domain. Any reference will always materialize to whatever session did the materialization. - Some enhancements to MagmaMutatingProxy to better support PointerFinder and Object Explorer tools. - After adding a new MagmaCollection with indexes in one commit, don't enumerate the collection again to build its indexes (omitting the ones it already added). This is strictly a performance improvement for a specific scenario. - Corrected reference to Morph class to just its name, #Morph. - Serialization optimization - No longer opening repository just to determine files, because a Magma repository now owns the entire directory. Magma continues to be fully-supported, questions or issues are addressed promptly. - Chris

2 1

WASession subclasses + Magma
by Ramiro Diaz Trepat 22 Jan '07

22 Jan '07

Another question regarding sessions. I was looking at the modified Sushi Store example to use Magma. I see there, that the WAStore class>>#initialize has changed to this: initialize | application | application := self registerAsApplication: 'store'. application configuration addAncestor: WAMagmaConfiguration new. ^ application My questions are: 1. Conceptually, what is an "ancestor" in the application configuration? 2. Why the initialization of the class is returning something, particularly the application? 3. If I subclass a WAMagmaSession to add some extra information, for instance the current user, in a MySession, what should be done in my root component's #initialize method? Should I still call the: "application addAncestor: WAMagmaConfiguration new." and then call "application preferenceAt: #sessionClass put: MySession" ? I believe the WAMagmaConfiguration sets the session type to be WAMagmaSession, so how should I use my own kind of session?

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma January 2007