Magma September 2007

magma@lists.squeakfoundation.org

12 participants
20 discussions

concurrent processes (was: Re: [ANN] Magma 1.0r40)
by Chris Muller 28 Sep '07

28 Sep '07

Hi Sig! > I found code, which uses MagmaOidManager in two different processes. I > placed a check instead of Mutex in it, which throws error, if some > other process instead of one, which was first who accessed it tries to > deal with oids. > > After running update, i found, that the only process, which accessing > oid manager except one, which running update is running by magma > itself: > > See fork in MaObjectRepository>>flushCacheSoon. > > After changing this method to: > > flushCacheSoon > self flushCritical: > [ self commitCritical: > [ self flushCache. > applyProcess _ nil ] ] > > there's no other processes who attempt to use oid manager from except > one, which runs update. > > So, the conclusion is obvious: flush causing problems. Thanks for digging in and talking with code, this really helps us have a productive discussion. Thankfully, I don't see evidence of any Magma bug in what you've submitted. Your #checkProcess does not account for the fact that flushCacheSoon is forked repeatedly. Your ifFalse: condition is being satisfied against a dead process that already finished out. To serve its intended purpose, you should check that the 'process' inst-var is not terminated, as in: checkProcess process ifNil: [ process := Processor activeProcess ] ifNotNil: [ (process ~= Processor activeProcess and: [ process isTerminated not ] ]) ifTrue: [ self error: 'Multiple processes using id manager' ]. ] I'd be surprised if you hit your error with this change. > Cris, please check the #flushCritical: code. I think it should not run > inside a commit or parallel to commits if we want it to run it in > standalone process. > Otherwise magma disregards own rule which says that following is not allowed: > session commit: [ > [ some code ] fork > ] #flushCache does not run parallel with commits. See in #flushCacheSoon, the #flushCache is layered inside commitCritical:. > Also, i'm glad to note, that with changes in #flushCacheSoon, Florian > able to run own update without errors regardless using my dictionaries > or using stock classes. You probably fixed it by something else.. flushCache does not even use MagmaOidManager, it just uses a standard OidManager. > But timing are different: > - out of the box magma: 18 minutes > - using my dictionaries: 8 minutes. > > quite impressive for real world application isn't? :) Indeed, I'd like the next release (r41) should be a performance release that includes improved Dictionary's if possible.. > Cris, in attachment i placed the MagmaOidManager code, which checks > the process. Just for case, if you want to see it yourself. To make the test effective w.r.t. the flushCache code, you should move your 'process' variable, and #checkProcess up to MaOidManager and call it from that level rather than the Magma-specific subclass. Regards, Chris

1 0

[ANN] Magma 1.0r40
by Igor Stasenko 27 Sep '07

27 Sep '07

---------- Forwarded message ---------- From: Igor Stasenko <siguctua(a)gmail.com> Date: 25 Sep 2007 19:29 Subject: Re: [ANN] Magma 1.0r40 To: florian.minjat(a)emn.fr I'm placed a line in removeGarbageCollectedObjectEntries Transcript show: 'Oids count: ' , self oidCount asString; cr. And during running Florian's update it shows (between other lines): Oids count: 29923 Oids count: 45449 Oids count: 49919 Oids count: 66399 Oids count: 76492 So its growing and growing.. And only way to get rid of dead keys, is to call MaOidManager>>finalizeOids. But i can't find any places, leading to call of this method. Is this designed to be managed by user directly, using MagmaSession>>finalizeOids ? I think it should call finalizeValues to dicts in removeGarbageCollectedObjectEntries, so both dicts with object>id and id>object associations will be cleaned and rehashed. Or, maybe, since magma uses own version(s) of weakIdentityKey dicts, implementation of #at:put: in weakIdentityKey dict can be changed to silently reuse entries with key=nil. So there will be much less need for rehashing. And it seems i was wrong saying that weak finalization process can interfere with oid manager weak dicts. Since oid manager never register own dicts to finalization registry it should not because of it. But then i wonder, why with big pauses putted in #reject: (or not using #reject: , as in new case) helped to avoid errors? The only way how oid can be lost, its, for instance, i adding new oid to dict and then using it somewhere, while at same time in other (background) process dict is being rehashing and/or manipulating in other ways, and after rehashing new entries is lost because they putted into place, which was already scanned by copying loop which moves associations from old array to new one. Interesting, how well magma handles following code: session commit: [ [ big long huge loop ] fork. [ big long huge loop 2 ] fork. ... ]. Is it allows to spawn different processes in commit? I think, Florian you should check if your code does not contain such things, or maybe you using code, which leads to them.. I now trying to run update with all methods in MagmaOidManager enclosed by mutex. -- Best regards, Igor Stasenko AKA sig.

4 6

Re: [ANN] Magma 1.0r40
by Florian Minjat 24 Sep '07

24 Sep '07

I installed the whole new thing and tested it right away with my 'big update' and got an error each time (I tested three times to be sure) : I didn't do anything to use a special collection or anything. EXCEPTION : MagmaInvalidOid: 3298536245786 is not a valid oid. (13:49:09) MagmaSession>>signalExceptionLike: self <- a MagmaSession temps anException <- MagmaInvalidOid: 3298536245786 is not a valid oid. signalableError <- MagmaInvalidOid: 3298536245786 is not a valid oid. inst vars id <- 2 user <- a MagmaUser id = update serializer <- a MaObjectSerializer transaction <- a MaTransaction readStrategy <- a WAMagmaReadStrategyDefault definition <- a MagmaRepositoryDefinition preferences <- a MagmaPreferences anchor <- a MaRootAnchor transactionLevel <- 1 link <- a MaLocalServerLink strongReferences <- an OrderedCollection() MagmaSession>>submit: self <- a MagmaSession temps aMagmaRepositoryRequest <- a MaRefreshSegmentRequest result <- MagmaInvalidOid: 3298536245786 is not a valid oid. inst vars id <- 2 user <- a MagmaUser id = update serializer <- a MaObjectSerializer transaction <- a MaTransaction readStrategy <- a WAMagmaReadStrategyDefault definition <- a MagmaRepositoryDefinition preferences <- a MagmaPreferences anchor <- a MaRootAnchor transactionLevel <- 1 link <- a MaLocalServerLink strongReferences <- an OrderedCollection() MagmaSession>>refreshSegment:of:where:pageSize:using:loadObjects: self <- a MagmaSession temps aMagmaCollectionReaderSegment <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 aMagmaCollection <- a MagmaCollection aMaTerm <- a MaClause (login 55581004787803423704017422417120985088..55581004787803423704017422417120985088) anInteger <- 125 aMaReadStrategy <- nil aBoolean <- true segment <- nil inst vars id <- 2 user <- a MagmaUser id = update serializer <- a MaObjectSerializer transaction <- a MaTransaction readStrategy <- a WAMagmaReadStrategyDefault definition <- a MagmaRepositoryDefinition preferences <- a MagmaPreferences anchor <- a MaRootAnchor transactionLevel <- 1 link <- a MaLocalServerLink strongReferences <- an OrderedCollection() MagmaCollection>>refreshSegment:where:pageSize:using:loadObjects: self <- a MagmaCollection temps aMagmaCollectionReaderSegment <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 aMaTerm <- a MaClause (login 55581004787803423704017422417120985088..55581004787803423704017422417120985088) anInteger <- 125 aMaReadStrategy <- nil aBoolean <- true inst vars session <- a MagmaSession changes <- a MagmaCollectionChanges indexes <- an OrderedCollection(a MaSearchStringIndex login a MaIntegerIndex rank a MaIntegerIndex worldId) descriptions <- an OrderedCollection(a MagmaIndexDescription a MagmaIndexDescription a MagmaIndexDescription ) MagmaCollectionReader>>refreshSegment:loadObjects: self <- a MagmaCollectionReader temps aMagmaCollectionReaderSegment <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 aBoolean <- true sortIndex <- nil inst vars collection <- a MagmaCollection expression <- a MaClause (login 55581004787803423704017422417120985088..55581004787803423704017422417120985088) readStrategy <- nil trunk <- a MaQueryTrunk segment <- nil segments <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) pageSize <- 125 reversed <- false localAdditionsSegment <- nil [] in MagmaCollectionReader>>segmentContaining: {[:foundSegment | self refreshSegment: foundSegment loadObjects: true. foun...]} self <- a MagmaCollectionReader temps anInteger <- 1 desiredSegment <- nil each <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 foundSegment <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 inst vars collection <- a MagmaCollection expression <- a MaClause (login 55581004787803423704017422417120985088..55581004787803423704017422417120985088) readStrategy <- nil trunk <- a MaQueryTrunk segment <- nil segments <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) pageSize <- 125 reversed <- false localAdditionsSegment <- nil [] in OrderedCollection(Collection)>>maDetect:ifFound:ifNone: {[:element | (aBlock value: element) ifTrue: [^ foundBlock value: element]...]} self <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) temps aBlock <- [] in MagmaCollectionReader>>segmentContaining: {[:each | each includesIndex: anInteger]} foundBlock <- [] in MagmaCollectionReader>>segmentContaining: {[:foundSegment | self refreshSegment: foundSegment...etc... exceptionBlock <- [] in MagmaCollectionReader>>segmentContaining: {[[desiredSegment := self getNextSegmentAndLoad: tru...etc... element <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 inst vars array <- an Array(nil nil a MagmaCollectionReaderSegment 1..1 of 1 | 0 nil nil nil nil nil nil nil) firstIndex <- 3 lastIndex <- 3 OrderedCollection>>do: self <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) temps aBlock <- [] in OrderedCollection(Collection)>>maDetect:ifFound:ifNone: {[:element | (aBlock value: element) ...etc... index <- 3 inst vars array <- an Array(nil nil a MagmaCollectionReaderSegment 1..1 of 1 | 0 nil nil nil nil nil nil nil) firstIndex <- 3 lastIndex <- 3 OrderedCollection(Collection)>>maDetect:ifFound:ifNone: self <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) temps aBlock <- [] in MagmaCollectionReader>>segmentContaining: {[:each | each includesIndex: anInteger]} foundBlock <- [] in MagmaCollectionReader>>segmentContaining: {[:foundSegment | self refreshSegment: foundSegment...etc... exceptionBlock <- [] in MagmaCollectionReader>>segmentContaining: {[[desiredSegment := self getNextSegmentAndLoad: tru...etc... element <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 inst vars array <- an Array(nil nil a MagmaCollectionReaderSegment 1..1 of 1 | 0 nil nil nil nil nil nil nil) firstIndex <- 3 lastIndex <- 3 MagmaCollectionReader>>segmentContaining: self <- a MagmaCollectionReader temps anInteger <- 1 desiredSegment <- nil each <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 foundSegment <- a MagmaCollectionReaderSegment 1..1 of 1 | 0 inst vars collection <- a MagmaCollection expression <- a MaClause (login 55581004787803423704017422417120985088..55581004787803423704017422417120985088) readStrategy <- nil trunk <- a MaQueryTrunk segment <- nil segments <- an OrderedCollection(a MagmaCollectionReaderSegment 1..1 of 1 | 0) pageSize <- 125 reversed <- false localAdditionsSegment <- nil Igor Stasenko wrote: > On 23/09/2007, Chris Muller <asqueaker(a)gmail.com> wrote: >> Sig contributed a simple change that lets you plug whatever dictionary >> you want. This is included in this release, so you can set it up as >> part of your application-initialization. >> >> But sig's new Dictionary's themselves arrived too late to incorporate >> as the default into this release. There is much testing and measuring >> and comparing with other Dictionary solutions (such as those from >> Martin Loewis) needed before making a switch to a new default Weak >> Dictionary. > > I don't know, maybe better was to keep my dictionaries as separate > package. Previously, i had a package with 'B' single prefix in class > names. But then, since i implemented them mainly for use with magma i > decided to rename them with Ma prefix and replace existing ones > directly in magma. > > And please, let me remind you, that magma uses two kinds of weak dictionaries: > WeakIdentityKeyDictionary > and > WeakValueDictionary > Previously i added a way to choose only one of them in > MagmaPreferences class (for WeakIdentityKeyDictionary). > > Now, i added snapshot, which fills the gap, and also makes use of it in > MaOidManager and MagmaOidManager code. > > Now, there's no direct references to any weak dictionary classes > within magma client code, they are rely on those, which set in > MagmaPreferences. > > see Magma client-sig.258 in magma-tester repo. It based on Magma > client-cmmr50.256. > >> - Chris >> >> On 9/23/07, Florian Minjat <florian.minjat(a)emn.fr> wrote: >>> Great I'll test it with my app right away ! >>> Does it include collection optimisation from sig or others ? >>> >>> Florian >>> >>> Chris Muller wrote: >>>> I am pleased to announce release 40 of the Magma object database for >>>> Squeak, offering a significant boost in robustness from the previous >>>> version: >>>> >>>> - No longer constrained by Squeaks 2GB file-addressability, Magma can >>>> now support unlimited file sizes (configured out of the box for up to >>>> 281 Terabyte sized files). >>>> - Full backups are now truly "live", with no pause in service. >>>> - There is now support for a "warm backup," for rapid failover capability.. >>>> - ..and server load distribution for clients that can tolerate a >>>> slightly-behind, read-only repository (i.e., for reporting, archive >>>> retrieval, etc.). >>>> - The MagmaCollectionIndex hierarchy is no longer required on the server. >>>> - The server correctly ignores garbage bytes sent by hackers to its >>>> listening port. >>>> - Other enhancements and some important bug fixes. >>>> >>>> Nearly every feature and fix has originated at the request of members >>>> of the Squeak community. This is your database. I plan to continue >>>> supporting, improving, and ensuring you have a good experience using >>>> Magma. Please tell me what you need on the Magma mailing list. >>>> >>>> This one single code-base has been installed and tested successfully >>>> in the 3.7, 3.8, 3.9, Tweak, Croquet 1.0SDK and sq3.9-7067dev07.07.1 >>>> images. Other images may work, I just haven't tested them, you can >>>> use the "Magma tester" to find out. In images without >>>> MethodProperties (3.7 and 3.8), Monticello will provide a friendly >>>> pink warning that a few extension methods will not load. This is ok, >>>> just press Proceed. It's better than maintaining different code bases >>>> for each version of Squeak. >>>> >>>> Since its earliest days, Magma has been a "one-click" install and this >>>> version is no different. There are three configurations available on >>>> SqueakMap and SqueakSource; "client", "server" and "tester". The >>>> former simply exclude certain packages that are not needed for that >>>> function. >>>> >>>> - Chris >>>> >>>> >>> >> > >

1 1

Re: [ANN] Magma 1.0r40
by Chris Muller 22 Sep '07

22 Sep '07

Heh, ok I guess missed that (announcement?). Still, breaking the repository up into multiple smaller chunked files is a good idea, which is what Magma now does instead of appending endlessly to the same files. - Chris On 9/22/07, Andreas Raab <andreas.raab(a)gmx.de> wrote: > What "2GB file-addressability" limit are you referring to? There is no > such thing. Files have been 64 bit for a couple of years now so unless > you run some really, really old VMs that limit doesn't exists. > > Cheers, > - Andreas > > Chris Muller wrote: > > I am pleased to announce release 40 of the Magma object database for > > Squeak, offering a significant boost in robustness from the previous > > version: > > > > - No longer constrained by Squeaks 2GB file-addressability, Magma can > > now support unlimited file sizes (configured out of the box for up to > > 281 Terabyte sized files). > > - Full backups are now truly "live", with no pause in service. > > - There is now support for a "warm backup," for rapid failover capability.. > > - ..and server load distribution for clients that can tolerate a > > slightly-behind, read-only repository (i.e., for reporting, archive > > retrieval, etc.). > > - The MagmaCollectionIndex hierarchy is no longer required on the server. > > - The server correctly ignores garbage bytes sent by hackers to its > > listening port. > > - Other enhancements and some important bug fixes. > > > > Nearly every feature and fix has originated at the request of members > > of the Squeak community. This is your database. I plan to continue > > supporting, improving, and ensuring you have a good experience using > > Magma. Please tell me what you need on the Magma mailing list. > > > > This one single code-base has been installed and tested successfully > > in the 3.7, 3.8, 3.9, Tweak, Croquet 1.0SDK and sq3.9-7067dev07.07.1 > > images. Other images may work, I just haven't tested them, you can > > use the "Magma tester" to find out. In images without > > MethodProperties (3.7 and 3.8), Monticello will provide a friendly > > pink warning that a few extension methods will not load. This is ok, > > just press Proceed. It's better than maintaining different code bases > > for each version of Squeak. > > > > Since its earliest days, Magma has been a "one-click" install and this > > version is no different. There are three configurations available on > > SqueakMap and SqueakSource; "client", "server" and "tester". The > > former simply exclude certain packages that are not needed for that > > function. > > > > - Chris > > > > > > >

1 0

[ANN] Magma 1.0r40
by Chris Muller 22 Sep '07

22 Sep '07

I am pleased to announce release 40 of the Magma object database for Squeak, offering a significant boost in robustness from the previous version: - No longer constrained by Squeaks 2GB file-addressability, Magma can now support unlimited file sizes (configured out of the box for up to 281 Terabyte sized files). - Full backups are now truly "live", with no pause in service. - There is now support for a "warm backup," for rapid failover capability.. - ..and server load distribution for clients that can tolerate a slightly-behind, read-only repository (i.e., for reporting, archive retrieval, etc.). - The MagmaCollectionIndex hierarchy is no longer required on the server. - The server correctly ignores garbage bytes sent by hackers to its listening port. - Other enhancements and some important bug fixes. Nearly every feature and fix has originated at the request of members of the Squeak community. This is your database. I plan to continue supporting, improving, and ensuring you have a good experience using Magma. Please tell me what you need on the Magma mailing list. This one single code-base has been installed and tested successfully in the 3.7, 3.8, 3.9, Tweak, Croquet 1.0SDK and sq3.9-7067dev07.07.1 images. Other images may work, I just haven't tested them, you can use the "Magma tester" to find out. In images without MethodProperties (3.7 and 3.8), Monticello will provide a friendly pink warning that a few extension methods will not load. This is ok, just press Proceed. It's better than maintaining different code bases for each version of Squeak. Since its earliest days, Magma has been a "one-click" install and this version is no different. There are three configurations available on SqueakMap and SqueakSource; "client", "server" and "tester". The former simply exclude certain packages that are not needed for that function. - Chris

1 0

Gosts objects
by Norberto Manzanos 22 Sep '07

22 Sep '07

Hi Chris and people. Something really strange has just happened with Magma. I had a repository. One of its collections had about 11000 objects. I made a massive adding of about 600 objects. 10 objects per transaction, refreshPersistentObjects... seting to false, readStrategy with depth 0. When the process finished, the size of the collection was about 11600. I noticed the files of the repository hadn't change. When I closed the session the collection size was 11000 again. Where were the other? I tried sending an #abort (but the whole process was inside transactions,so, what for?), then I sent a #cleanUp to MagmaSession (I don't known why, magic perhaps). Surprisingly, when I reconnected the session and requested the size again, it was 600!. I swear I didn't drink nothing but coffee, but when I closed and reconnected the session one more time, the collection had the 11000 of the beginning. The objects file hadn't changed and the size of the squeak image was about 150 Mb. So, they were allways in memory ... but where exactly? There was only one instance of MagmaRepositoryController and two instances of MagmaSession, one my session, and a __system session. This is not the first time that many objects disapears in the air. What I really want to understand is what could be the reason that several #add: to the repository inside a transaction could not be actually saved in the files and keeps in memory. Thanks in advance. Norberto

2 3

Magma benchmarks with different MaDictionaries comparison
by Igor Stasenko 13 Sep '07

13 Sep '07

With "Ma special collections-sig.89.mcz" ---------------------------------------------------------- MagmaBenchmarker runLocalBaseline: false 'The date is 3 September 2007 4:00:28 pm Hardware Details: computer : noname cpu : athlon speed : 1.10GHz memory : 786Mb disk : WD800JB-00ETA0 80GB OS Details: osVersion : NT platformName : Win32 platformSubtype : IX86 vmVersion : Squeak3.10alpha of 30 March 2007 [latest update: #7091] imageName : D:\sig\florian image\sq3.9-7067dev07.08.1base-SeasideMagmaDOL-wIndVersion-specialCollection-sig.image Image Details: version : Squeak3.9 lastUpdate : 7067 Code Package Details (from Monticello): Name: Magma tester-cmm.258 Author: cmm Time: 3 August 2007, 11:07:10 am UUID: df68e32f-884e-9245-b8b1-d17e7af970c9 Ancestors: Magma tester-cmm.257 Magma server details: flushAggressively : false MagmaSession Details: isLocal : true allowWriteBarrier : false refreshPersistentObjectsEvenWhenChangedOnlyByMe : false Benchmarker Details: thousands : 1000 Benchmarks: --- connectionTests timeToDisconnect : 0:00:00:00.741 timeToConnect : 0:00:00:00.817 --- readTests peakRefreshRate : 4971.805638872225 per second. singleObjectRead : 2160.967806438712 per second. oneThousandElementArrayRead : 163.3020187887268 per second. oneThousandElementArrayOfObjectsRead : 4.327301337529504 per second. oneMillionObjectPointersRead : 7 seconds. oneThousandLevelsDeepRead : 3.300970873786408 per second. --- writeTests peakCommitRate : 16.44867221561633 per second. oneThousandElementArrayCommit : 11.72263063779058 per second. a1001BufferCommit : 5.96777402029043 per second. aOneMillionBufferCommit : 32 seconds. --- magmaArrayTests getMagmaArraySize : 5634.273145370926 per second. updateThousandsOfMagmaArrayElements : 0.1250781738586616 per second. --- magmaCollectionTests addThousandsOfObjectsTenAtATime : 12.481 seconds. addThousandsOfObjectsOneHundredAtATime : 5.917 seconds. addThousandsOfObjectsAtOnce : 5.877 seconds.' With "Ma special collections-cmm.83.mcz" --------------------------------- 'The date is 3 September 2007 4:17:15 pm Hardware Details: computer : noname cpu : athlon speed : 1.10GHz memory : 786Mb disk : WD800JB-00ETA0 80GB OS Details: osVersion : NT platformName : Win32 platformSubtype : IX86 vmVersion : Squeak3.10alpha of 30 March 2007 [latest update: #7091] imageName : D:\sig\florian image\sq3.9-7067dev07.08.1base-SeasideMagmaDOL-wIndVersion-specialCollection-sig.image Image Details: version : Squeak3.9 lastUpdate : 7067 Code Package Details (from Monticello): Name: Magma tester-cmm.258 Author: cmm Time: 3 August 2007, 11:07:10 am UUID: df68e32f-884e-9245-b8b1-d17e7af970c9 Ancestors: Magma tester-cmm.257 Magma server details: flushAggressively : false MagmaSession Details: isLocal : true allowWriteBarrier : false refreshPersistentObjectsEvenWhenChangedOnlyByMe : false Benchmarker Details: thousands : 1000 Benchmarks: --- connectionTests timeToDisconnect : 0:00:00:00.736 timeToConnect : 0:00:00:00.768 --- readTests peakRefreshRate : 3070.985802839432 per second. singleObjectRead : 1872.025594881024 per second. oneThousandElementArrayRead : 162.037962037962 per second. oneThousandElementArrayOfObjectsRead : 4.17578047325512 per second. oneMillionObjectPointersRead : 7 seconds. oneThousandLevelsDeepRead : 2.906976744186046 per second. --- writeTests peakCommitRate : 15.97444089456869 per second. oneThousandElementArrayCommit : 11.36137133745266 per second. a1001BufferCommit : 5.89622641509434 per second. aOneMillionBufferCommit : 32 seconds. --- magmaArrayTests getMagmaArraySize : 5681.06378724255 per second. updateThousandsOfMagmaArrayElements : 0.1270809505655102 per second. --- magmaCollectionTests addThousandsOfObjectsTenAtATime : 12.839 seconds. addThousandsOfObjectsOneHundredAtATime : 6.164 seconds. addThousandsOfObjectsAtOnce : 6.41 seconds.' -- Best regards, Igor Stasenko AKA sig.

5 7

r41Alpha2
by Chris Muller 11 Sep '07

11 Sep '07

r41Alpha2 is posted to the "Magma Tester" project of squeaksource.com. After being reminded that Gjaller is based in 3.8, I decided to withdraw the #executeInServer: aBlock function in lieu of performInServer:withArguments:. This allowed reverting the server #protocol to not require all the classes associated with Blocks, which was a bigger step into low-level dependencies than I want to commit to at this time. - Chris

1 0

r40Gamma4
by Chris Muller 10 Sep '07

10 Sep '07

I just noticed there were still references to some of my old "Ma time objects" classes in 1.0r40gamma3. I'm pretty surprised no one mentioned this! I thought Monticello would warn me if I tried to load code which had no defined class, but it doesn't. So I used Lint to find occurrences of "References an undeclared variable" and removed them. It also includes some improvements to make the network test cases more platform independent, so launching images on Linux works without needing to change code. Release is imminent, please let me know of any final issues asap. - Chris

1 0

WAMagmaSession question
by Florian Minjat 07 Sep '07

07 Sep '07

Hi there, A question about the WAMagmaSession shipped with magma seaside package. I use them with my own session object and I'd like to see the number of Magma proxy materializations during a page load. I saw a new option 'Signal Proxy Materializations' but I don't see any effect. I would like to display this number on the webpage at the end of the load. Any idea on how to do that ? Florian

2 1

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma September 2007