Magma June 2009

magma@lists.squeakfoundation.org

7 participants
10 discussions

Clarification on what to load for the scenario:
by Timothy James Ziebart 06 Jul '09

06 Jul '09

I have a separate image running a Magma Server. I want to build a seaside app that will access the database remotely. Where I am building the app do I need to load the following packages? Magma client Seaside28Jetsam-Helpers Magma SeasideHelpers Or what should i be loading? Thank you.

3 2

r42Gamma4 - MessageNotUnderstood: MagmaRemoteLocation>>host:
by Timothy James Ziebart 25 Jun '09

25 Jun '09

Hi all, must have a mismatch in packages somewhere. Occurs as soon as I put in the host and port for a remoteMagmaLocation and save the configuration. I loaded the r42Gamma followed by Seaside Jetsam and finally Seaside helper via monticello. Any ideas?. Tim

1 0

r42Gamma4 woes
by Brian Mason 24 Jun '09

24 Jun '09

Greetings, I am trying to load Magma into Seaside 2.8.4. I get a load error: MaObjectSerializer>>setUpClassDefinitionProcessing preferences beforeSerializingAny: #MaClassReference do: [ : aMaClassReference | aMaClassReference id: (classIdManager idForClass: aMaClassReference classObject ifAbsent: [ (classIdManager addNewClass: aMaClassReference classObject theNonMetaClass) id ]). Cannot store into ->aMaClassReference := nil ] ; afterMaterializingAny: #MaClassDefinition do: (MessageSend receiver: classIdManager selector: #addClassDefinition:) I tried simply commenting out the obvious error but then the create never completes. MagmaRepositoryController Create: 'c:\first' root: Dictionaty new I am working under Vista. I would appreciate guidance. Brian "You can have everything you want if you just help enough other people get what they want." - Zig Zigglar

3 3

MagmaInvalidOid situation
by Hernán Morales Durand 19 Jun '09

19 Jun '09

Hi all, I'm looking for more information concerning this error. Maybe a course of remedy? (I've not tried to isolate yet in the hope of a better understanding of the problem). Context: I did this process over two MagmaCollection's before succesfully. The process re-index an entire MagmaCollection, using a temporary magma collection for that purpose. The error happened when committing indexes to the new (temporary) magma collection. All the process uses a MagmaSession locally connected. The code looks like this: | collection | self session begin. collection:= self root at: self tempKey put: MagmaCollection new. self indexes do:[:each | collection addIndex: each ]. self session commit And the stack obtained with the trick of my previous e-mail: 16 June 2009 2:51:36 am VM: Win32 - a SmalltalkImage Image: Squeak3.9 [latest update: #7067] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir D:\OpusApp Trusted Dir D:\OpusApp\compu Untrusted Dir C:\Documents and Settings\compu\Mis documentos\My Squeak MagmaSession>>signalExceptionLike: Receiver: a MagmaSession D:\OpusApp\Magma Arguments and temporary variables: anException: MagmaInvalidOid: 1623575456 is not a valid oid. signalableError: MagmaInvalidOid: 1623575456 is not a valid oid. Receiver's instance variables: id: an UUID('2caca4db-5f85-a546-a057-f7978a775e9c') user: a MagmaUser id = Opus serializer: a MaObjectSerializer transaction: a MaTransaction readStrategy: a MaReadStrategy definition: a MagmaRepositoryDefinition preferences: a MagmaPreferences anchor: nil transactionLevel: 1 strongReferences: an OrderedCollection() cache: a Dictionary() guard: a Mutex statistics: a MagmaSessionStatistics primaryLink: a MaLocalServerLink secondaryLink: a MaLocalServerLink allowFailover: true oidCount: 12879073 lastClean: 26265480 requiredProgress: 0 [] in MagmaSession>>submit:to: {[aMagmaRepositoryRequest requiresConnection ifTrue: [self ensureConnected]...]} Arguments and temporary variables: aMagmaRepositoryRequest: a MaReadRequest aMaServerLink: a MaLocalServerLink didTry: false link: a MaLocalServerLink result: MagmaInvalidOid: 1623575456 is not a valid oid. err: nil node: nil [] in BlockContext>>maOn:do:on:do: {[self value]} Arguments and temporary variables: exc1: MagmaSessionLost block1: [] in MagmaSession>>submit:to: {[:err | MagmaNotification signal: 'Mag...etc... exc2: NetworkError block2: [] in MagmaSession>>submit:to: {[:err | aMagmaRepositoryRequest isConn...etc... BlockContext>>on:do: Receiver: [] in BlockContext>>maOn:do:on:do: {[self value]} Arguments and temporary variables: exception: MagmaSessionLost handlerAction: [] in MagmaSession>>submit:to: {[:err | MagmaNotification signa...etc... handlerActive: true Receiver's instance variables: sender: BlockContext>>on:do: pc: 29 stackp: 0 nargs: 0 startpc: 27 home: BlockContext>>maOn:do:on:do: --- The full stack --- MagmaSession>>signalExceptionLike: [] in MagmaSession>>submit:to: {[aMagmaRepositoryRequest requiresConnection ifTrue: [self ensureConnected]...]} [] in BlockContext>>maOn:do:on:do: {[self value]} BlockContext>>on:do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - [] in BlockContext>>maOn:do:on:do: {[[self value] on: exc1 do: block1]} BlockContext>>on:do: BlockContext>>maOn:do:on:do: [] in MagmaSession>>submit:to: {[didTry := false. link := aMaServerLink. [aMagmaRepositoryRequest requires...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: [] in MagmaSession>>submit:to: {[aMagmaRepositoryRequest waitCursor showWhile: [didTry := false. link :...]} Mutex>>critical: MagmaSession>>submit:to: [] in MagmaSession>>secondarySubmit: {[self submit: aMagmaRepositoryRequest to: secondaryLink]} [] in BlockContext>>maOn:do:on:do: {[self value]} BlockContext>>on:do: [] in BlockContext>>maOn:do:on:do: {[[self value] on: exc1 do: block1]} BlockContext>>on:do: BlockContext>>maOn:do:on:do: MagmaSession>>secondarySubmit: MagmaSession>>read: [] in MagmaSession>>realObjectFor: {[result := self read: oid. self statistics clientSideProxyMaterializationTi...]} Mutex>>critical: MagmaSession>>realObjectFor: MagmaMutatingProxy>>mutant MagmaMutatingProxy(MaMutatingProxy)>>mutateAndSend: [] in MagmaMutatingProxy(MaMutatingProxy)>>doesNotUnderstand: #select: {[self maIsMutatingProxy ifTrue: [self mutateAndSend: aMessage] ifFalse: ...]} BlockContext>>on:do: MagmaMutatingProxy(MaMutatingProxy)>>doesNotUnderstand: #select: RecordEventManager>>recordEventsOfKind: SerialManifestation>>issnInternationalRecord SerialManifestation>>issnInternationalRecordDateString MaSearchStringIndex(MagmaCollectionIndex)>>indexObjectFor: MaSearchStringIndex>>canIndex: MaSearchStringIndex(MagmaCollectionIndex)>>validateCanIndex: MaSearchStringIndex(MagmaCollectionIndex)>>indexHashesFor: [] in MagmaCollection>>buildIndexes:ignoring: {[:eachIndex | changes add: oid at: (eachIndex indexHashesFor: eachObject...]} ...etc... Best regards Hernan

2 2

r42Gamma4
by Chris Muller 17 Jun '09

17 Jun '09

Thanks to everyone who reported issues with r42 gamma. I have just posted a yet another gamma version with additional fixes, function, and performance. - Fix for MaServerLocation>>#=, when comparing to unreachable hosts! - Removed MaServerSocket>>'timeoutSeconds' since it is ambiguous with the MaClientServerPreferences>>'timeoutSeconds'. - Changed temporary holding area utilized by #noteOldKeysFor: to a strong reference, avoiding any chance a GC would cause such an operation to be lost. A similar fix for accessing / changing objects directly from a MagmaCollection (instead of a MagmaCollectionReader, the normal case). - Statistics improvement: Real-world wants statistics for specific Timespans. Now the DBA can select statistics just for particular time-periods in the past. - Discovered that changing the Form of the mouse pointer for every read and commit can have a significant impact on performance! It's now turned OFF by default. To get this back, set the new MagmaPreferences showStatusViaCursor: true, otherwise, enjoy the improved performance! - Chris

1 0

Semaphore>>critical:
by Hernán Morales Durand 17 Jun '09

17 Jun '09

Hi Chris and others, I'm using Squeak 3.11.2 (alpha) 27/3/2009 VM, Squeak 3.9-7067 and Magma r42Gamma3. With the latest release of Magma, whenever a Debugger with a Magma exception is raised, control is not returned, and is necessary to press Alt + . to quit this situation. Doing this you will get a "User Interrupt" debugger window. But although control is returned, possibly there is still a deadlock preventing other operations too, like mail out a bug report. Actually to mail out the report below I've implemented a #semaphore getter in Mutex and (inside the debugger) from Mutex>>critical: select the owner instance variable and signal the semaphore. 16 June 2009 2:30:06 am VM: Win32 - a SmalltalkImage Image: Squeak3.9 [latest update: #7067] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true Working Dir D:\OpusApp Trusted Dir D:\OpusApp\compu Untrusted Dir C:\Documents and Settings\compu\Mis documentos\My Squeak Semaphore>>critical: Receiver: a Semaphore() Arguments and temporary variables: mutuallyExcludedBlock: [] in Mutex>>critical: {[owner := activeProcess. aBlock...etc... blockValue: nil Receiver's instance variables: firstLink: nil lastLink: nil excessSignals: 1 Mutex>>critical: Receiver: a Mutex Arguments and temporary variables: aBlock: [] in MagmaSession>>submit:to: {[aMagmaRepositoryRequest waitCursor s...etc... activeProcess: a Process in Semaphore>>critical: Receiver's instance variables: semaphore: a Semaphore() owner: a Process in Process>>suspend MagmaSession>>submit:to: Receiver: a MagmaSession D:\OpusApp\Magma Arguments and temporary variables: aMagmaRepositoryRequest: a MagmaPathNameRequest aMaServerLink: a MaLocalServerLink didTry: nil link: nil result: nil err: nil node: nil Receiver's instance variables: id: an UUID('2caca4db-5f85-a546-a057-f7978a775e9c') user: a MagmaUser id = Opus serializer: a MaObjectSerializer transaction: a MaTransaction readStrategy: a MaReadStrategy definition: a MagmaRepositoryDefinition preferences: a MagmaPreferences anchor: nil transactionLevel: 1 strongReferences: an OrderedCollection() cache: a Dictionary() guard: a Mutex statistics: a MagmaSessionStatistics primaryLink: a MaLocalServerLink secondaryLink: a MaLocalServerLink allowFailover: true oidCount: 12879073 lastClean: 26265480 requiredProgress: 0 MagmaSession>>pathNamePrimary Receiver: a MagmaSession D:\OpusApp\Magma Arguments and temporary variables: Receiver's instance variables: id: an UUID('2caca4db-5f85-a546-a057-f7978a775e9c') user: a MagmaUser id = Opus serializer: a MaObjectSerializer transaction: a MaTransaction readStrategy: a MaReadStrategy definition: a MagmaRepositoryDefinition preferences: a MagmaPreferences anchor: nil transactionLevel: 1 strongReferences: an OrderedCollection() cache: a Dictionary() guard: a Mutex statistics: a MagmaSessionStatistics primaryLink: a MaLocalServerLink secondaryLink: a MaLocalServerLink allowFailover: true oidCount: 12879073 lastClean: 26265480 requiredProgress: 0 --- The full stack --- Semaphore>>critical: Mutex>>critical: MagmaSession>>submit:to: MagmaSession>>pathNamePrimary - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MagmaSession>>maPrintAbbreviatedOn: MagmaSession(MaObject)>>printOn: [] in MagmaSession(Object)>>printStringLimitedTo: {[:s | self printOn: s]} String class(SequenceableCollection class)>>streamContents:limitedTo: MagmaSession(Object)>>printStringLimitedTo: [] in MethodContext>>printDetails: {[receiver printStringLimitedTo: 90]} BlockContext>>on:do: BlockContext>>ifError: MethodContext>>printDetails: MethodContext(ContextPart)>>errorReportOn: [] in Debugger>>mailOutBugReport {[messageStrm := WriteStream on: (String new: 1500). messageStrm nextPut...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: Debugger>>mailOutBugReport Debugger(StringHolder)>>perform:orSendTo: Debugger>>perform:orSendTo: [] in MenuItemMorph>>invokeWithEvent: {[(selArgCount := selector numArgs) = 0 ifTrue: [target perform: selector] ...]} BlockContext>>ensure: CursorWithMask(Cursor)>>showWhile: MenuItemMorph>>invokeWithEvent: MenuItemMorph>>mouseUp: MenuItemMorph>>handleMouseUp: MouseButtonEvent>>sentTo: MenuItemMorph(Morph)>>handleEvent: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuItemMorph(Morph)>>processEvent:using: MorphicEventDispatcher>>dispatchDefault:with: MorphicEventDispatcher>>dispatchEvent:with: MenuMorph(Morph)>>processEvent:using: MenuMorph(Morph)>>processEvent: MenuMorph>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: ...etc... Cheers, Hernan

2 1

Issue with self defined indexes
by Hilaire Fernandes 11 Jun '09

11 Jun '09

I have an issue with index I defined of my own. It is not working properly, I don't see why. I have created a simple index for attributes taking values in a pre-set list, it looks like: MaVocabularyIndex>>keySize ^ 8 MaVocabularyIndex>>vocabulary: aCollection vocabulary := aCollection asOrderedCollection add: 'inconnu'; yourself MaVocabularyIndex>>indexHashForIndexObject: anObject ^ vocabulary indexOf: anObject ifAbsent: [MagmaInvalidIndexObject signal: 'Unvalid index value'] To use it: aMagmaCollection addIndex: ((MaVocabularyIndex attribute: #status) vocabulary: LomStatus frenchVocabularies); where LomStatus frenchVocabularies returns #('brouillon' 'final' 'r?vis?' 'indisponible') Is there anythings wrong in such implementation of an index? After committing a lot of data I see strange result when doing queries: (resources where: [:e | e status in: #('final' )]) size -> 146 (resources where: [:e | e status in: #('indisponible' )]) size 0 (resources where: [:e | e status in: #('final' 'indisponible')]) size -> 250 Definitely it is not consistent, any tips where to look at? Btw, all the indexed attributes accessors (ie #status) return an OrderedCollection containing one or more terms from the vocabulary reference lists. When committing my data, I pay attention to commit only when all attributes are set. If I add a noteForOldKey in the commit block I get at some point of the importing data process a MaSoftwareError. The error is not fixed to a particular imported data, but it looks like from a certain level of imported data. Hilaire

1 2

Timeout
by Hilaire Fernandes 10 Jun '09

10 Jun '09

In MaServerSocket there are both a timeoutSecond instV and and a #timeoutSecond instM defined as: timeoutSeconds "The number of seconds to wait for responses from network requests before assuming they are lost." ^ preferences timeoutSeconds is it normal?

2 1

r42Gamma3 was: What to do with a MagmaCommitError
by Chris Muller 09 Jun '09

09 Jun '09

> Thanks for the explanations Chris. I tried to restart but the commitNumber > of the session in the debugger was nil, and when the session wanted to > reconnect and validate in #validateCommitNumber another MNU was raised. This > is expected for this kind of situation? Thanks for the report Hernán, you certainly know how to find the bugs! Indeed, the recent addition of the commitNumber to the CommitResult did not get included in a FailedCommitResult, causing a session which then disconnected before crossing another transaction boundary, without its commitNumber, resulting in the error you saw upon attempting to reconnect that session. Good catch! I have fixed this and release it as r42Gamma3. While I was in there, I decided to include a nice improvement to commit-conflict resolution. Recall when you get a commit-conflict, you have access to #conflictingObjects. Before, in r42Gamma2 and earlier, it just answered the conflicting objects but now it answers a collection of Associations whose keys are the original persistent object in conflict, and whose values are a shallowCopy of the local sessions version of that object before it was updated due to crossing the transaction boundary (the commit attempt). This would allow a general commit-error handling user-interface that can present the conflicting objects side-by-side, maximizing reconciliation productivity. Very likely, not many applications even take advantage of #conflictingObjects, so no code changes will be necessary for most applications. But applications which were making use of #conflictingObjects in r42Gamma2 or earlier will need to account for the richer model now in r42Gamma3. - Chris On Thu, Jun 4, 2009 at 1:42 AM, Hernán Morales Durand <hernan.morales(a)gmail.com> wrote: > > > 2009/6/3 Chris Muller <asqueaker(a)gmail.com> >> >> Thanks for the great questions. >> >> > Now I have a Debugger with a MagmaCommitError. As you can see from the >> > attachement, the User2 session still has a transaction, >> >> The attachment shows the "transactionLevel" as 0, meaning the session >> is not in a transaction. The 'transaction' instance variable always >> has a MaTransaction instance which is just a single per session to >> manage the readSet (for changed-detection). It is completely private. >> >> so I have some >> > questions: >> > >> > -Is this transaction invalid in some way? I've observed some possibly >> > relevant protocol here (#restore? #changedObjects?) >> >> MaTransaction is completely private. Access with caution. >> >> > -Supposing that it's appropiate to reapply User2 changes, do I have the >> > chance to do it from the Debugger? >> >> Magma guards its internal state, you may restart at the point your >> application issued the #commit, but be sure to check the session >> transactionLevel, you may need to manually send #begin to the session >> first if the application code doesn't.. >> >> Likewise, if your application issued #commit: [ ... ] and your >> session is at transactionLevel 0, then of course you can just restart >> from there.. > > Thanks for the explanations Chris. I tried to restart but the commitNumber > of the session in the debugger was nil, and when the session wanted to > reconnect and validate in #validateCommitNumber another MNU was raised. This > is expected for this kind of situation? > >> >> > -If the Debugger isn't useful at this stage, how to apply the User2 >> > changes? >> >> A session that experiences a commit-conflict is no longer in a >> transaction, but the local changes can still be committed. However, >> the state of the local model is now "merged" with updates from other >> users. The MagmaCommitConflictError (Exception) has a >> MaFailedCommitResult, which has a collection of the objects that, in >> particular, the application may wish to review, they are the ones >> User2 changes now overlay the local changes. >> >> If the application wishes to continue committing the local changes, it >> may issue a #begin followed by a commit. I must admit, it seems >> unnecessary to require the application to do this.. I don't think >> that would be difficult, hmm.. >> >> Or, the application may issue an #abort to cancel all local changes, >> refresh all contents from the repository and start over. >> >> - Chris > > > Hernan > > _______________________________________________ > Magma mailing list > Magma(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/magma > >

2 1

What to do with a MagmaCommitError
by Hernán Morales Durand 04 Jun '09

04 Jun '09

The page http://wiki.squeak.org/squeak/2636 says: "Thankfully, Magma will detect this conflict and signal a MagmaCommitError back to user 2. This is because she tried to change an object that was changed by User 1 since she began her transaction, invalidating her changes. The failed result object has the challenging objects that were in conflict (Object A) and the name of each user who changed them (User 1). Additionally, User 2 can now see the new Object A, as changed by User 1, because her commit attempt caused a crossing of a transaction boundary. At this point, User 2 no longer has a transaction. She must reapply her changes under a new transaction, if appropriate. " Now I have a Debugger with a MagmaCommitError. As you can see from the attachement, the User2 session still has a transaction, so I have some questions: -Is this transaction invalid in some way? I've observed some possibly relevant protocol here (#restore? #changedObjects?) -Supposing that it's appropiate to reapply User2 changes, do I have the chance to do it from the Debugger? -If the Debugger isn't useful at this stage, how to apply the User2 changes? Cheers, Hernan

2 4

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma June 2009