Magma April 2009

magma@lists.squeakfoundation.org

6 participants
6 discussions

Refreshing a MaReadResult instead of a MaRefreshViewResult
by Hernán Morales Durand 22 Apr '09

22 Apr '09

Hi, I was rebuilding indexes much as the same way Göran explained in a previous thread recently and apparently #submit: answered a MaReadResult resulting in a MNU (see attachement). I should note I'm using the branch from Magma tester-cmm.282 / Magma server-cmm.274, i.e. not the latest version. Is this something that can be solved upgrading to latest Magma? There is an easier or "live" solution? Image is Squeak 3.9 with VM Squeak 3.9.2 Thanks in advance Hernan

1 0

Question: How to rebuild indexes?
by Göran Krampe 21 Apr '09

21 Apr '09

Hi! Just wanted to get the "truth" from Chris on this. I would like to rebuild selected indexes from scratch, saw some code but... well, is there an official API for this? regards, Göran

2 3

r42Gamma1
by Chris Muller 12 Apr '09

12 Apr '09

I have just posted Magma r42Gamma1 to SqueakMap and SqueakSource. gamma1 over beta3: - The RepositoryDefinition now maintains a canonicalized Set of MagmaForwardingProxy 'links' to objects in other repositories, including their canonicalized MagmaId's. This allows easier deployment / movement of repositories in multi-repository federations. - Don't antagonize a proxy during preSerialization, nor when obtaining the objectCountByClass of a Session. - More strict error-check for sharing objects across sessions. - Fix not-caching lastKnownSize of an empty MagmaCollectionReader. - The commits.log file is being written during a fullBackupTo:. Don't copy it. - Minor fixes to MagmaFileTraverser.

1 0

[BUG]UndefinedObject(Object)>>doesNotUnderstand: #secondaryLocationsDo:
by Hernán Morales Durand 09 Apr '09

09 Apr '09

Hello, I'm updating to release 42 beta 3 but after trying to connect with this script I get a DNU. | path | path := String streamContents: [: s | s nextPutAll: FileDirectory default pathName; nextPutAll: FileDirectory slash; nextPutAll: 'Magma' ]. MagmaServerConsole new open: path; processOn: 51969. It worked fine with a previous release. I don't know what is that pervious release number because I didn't found a way to get the release version from Magma, I suppose my previous release is r42b1 or r41b3.... this is the bug report, any hint would be appreciated. 7 April 2009 3:09:56 am VM: Win32 - a SmalltalkImage Image: Squeak3.10.2 [latest update: #7179] SecurityManager state: Restricted: false FileAccess: true SocketAccess: true UndefinedObject(Object)>>doesNotUnderstand: #secondaryLocationsDo: Receiver: nil Arguments and temporary variables: aMessage: secondaryLocationsDo: [] in MagmaServerConsole>>checkIfAmPrimaryOvert...etc... Receiver's instance variables: nil MagmaServerConsole>>checkIfAmPrimaryOvertaken: Receiver: a MagmaServerConsole Arguments and temporary variables: portInteger: 51969 thisLocation: 52246990800e4fa:51969 each: nil sess: nil err: nil Receiver's instance variables: statistics: a MagmaServerStatistics lastRequestStart: nil lastRequestFinish: nil server: a MaNetworkRequestServer controller: a MagmaRepositoryController [] in MagmaServerConsole>>preIgnitionSequence: {[self checkIfAmPrimaryOvertaken: portInteger]} Arguments and temporary variables: portInteger: 51969 nodeUpdates: an OrderedCollection() update: nil each: nil BlockContext>>on:do: Receiver: [] in MagmaServerConsole>>preIgnitionSequence: {[self checkIfAmPrimaryOvertaken: portInteg...etc... Arguments and temporary variables: exception: MagmaNodeUpdate handlerAction: [] in MagmaServerConsole>>preIgnitionSequence: {[:update | node...etc... handlerActive: true Receiver's instance variables: sender: BlockContext>>on:do: pc: 80 stackp: 0 nargs: 0 startpc: 77 home: MagmaServerConsole>>preIgnitionSequence: --- The full stack --- UndefinedObject(Object)>>doesNotUnderstand: #secondaryLocationsDo: MagmaServerConsole>>checkIfAmPrimaryOvertaken: [] in MagmaServerConsole>>preIgnitionSequence: {[self checkIfAmPrimaryOvertaken: portInteger]} BlockContext>>on:do: - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - MagmaServerConsole>>preIgnitionSequence: MagmaServerConsole>>noteAboutToStart MaNetworkRequestServer(MaServer)>>noteAboutToStart MaServerSocket>>listen MaServerSocket>>processOn: MaNetworkRequestServer>>processOn: MaNetworkRequestServer>>processOn:using: MagmaServerConsole>>processOn: UndefinedObject>>DoIt Compiler>>evaluate:in:to:notifying:ifFail:logged: [] in TextMorphEditor(ParagraphEditor)>>evaluateSelection {[rcvr class evaluatorClass new evaluate: self selectionAsStream in: ctxt...]} BlockContext>>on:do: TextMorphEditor(ParagraphEditor)>>evaluateSelection TextMorphEditor(ParagraphEditor)>>inspectIt TextMorphEditor>>inspectIt: TextMorphEditor(ParagraphEditor)>>dispatchOnCharacter:with: TextMorphEditor>>dispatchOnCharacter:with: TextMorphEditor(ParagraphEditor)>>readKeyboard TextMorphEditor>>readKeyboard [] in TextMorphForEditView(TextMorph)>>keyStroke: {[editor readKeyboard]} TextMorphForEditView(TextMorph)>>handleInteraction:fromEvent: TextMorphForEditView>>handleInteraction:fromEvent: TextMorphForEditView(TextMorph)>>keyStroke: TextMorphForEditView>>keyStroke: TextMorphForEditView(TextMorph)>>handleKeystroke: KeyboardEvent>>sentTo: TextMorphForEditView(Morph)>>handleEvent: TextMorphForEditView(Morph)>>handleFocusEvent: [] in HandMorph>>sendFocusEvent:to:clear: {[ActiveHand := self. ActiveEvent := anEvent. result := focusHolder han...]} [] in PasteUpMorph>>becomeActiveDuring: {[aBlock value]} BlockContext>>on:do: PasteUpMorph>>becomeActiveDuring: HandMorph>>sendFocusEvent:to:clear: HandMorph>>sendEvent:focus:clear: HandMorph>>sendKeyboardEvent: HandMorph>>handleEvent: HandMorph>>processEvents [] in WorldState>>doOneCycleNowFor: {[:h | ActiveHand := h. h processEvents. capturingGesture := capturingGest...]} Array(SequenceableCollection)>>do: WorldState>>handsDo: WorldState>>doOneCycleNowFor: WorldState>>doOneCycleFor: PasteUpMorph>>doOneCycle [] in Project class>>spawnNewProcess {[[World doOneCycle. Processor yield. false] whileFalse. nil]} [] in BlockContext>>newProcess {[self value. Processor terminateActive]}

2 3

MagmaCollectionReader behavior
by Miguel Enrique Cobá Martínez 01 Apr '09

01 Apr '09

It is not clear from the magmaseaside tutorial, but the code from http://wiki.squeak.org/squeak/6021: initialize | users | users := MagmaCollection new. users addIndex: (MaSearchStringIndex attribute: #email) beAscii. self at: #users put: users findUserByEmail: anEmail ^ (self users where: [ :each | each email equals: anEmail ] ) firstOrNil without any doubt suggests that the where: method and the each email equals: anEmail gives a *exact* or *equal* match, but that is not the case. In fact, the where: send returns a MagmaCollectionReader that stands for the *set* or *collection* of objects that matched the equals: method in direct relation with the index created for the MagmaCollection. In this example, the index is created with the default (no keySize: especified) of 32 bits that merely gives you 4 meaningful characters when searching for a string, i.e. if you have users with emails like: user email 1 'miguel(a)domain1.com' 2 'miguel(a)domain2.com' 3 'miguel.coba(a)domain3.com' a message send like: findUserByEmail: 'miguel(a)domain1.com' will give you a MagmaReader that represents the 3 users in the database, because they all share the same 4 initial characters. After that, the firstOrNil message, ensure that the user # 1 will *always* be returned, no matter what argument you are passing to findUserByEmail. So, the answer from findUserByEmail: 'miguel(a)domain1.com' findUserByEmail: 'miguel(a)domain2.com' findUserByEmail: 'miguel.coba(a)domain3.com' will be always user #1. In summary, the method doesn't has a right behavior, because it can't be used for finding a specific user, that is the intended action. After reading the Index documentation from the magma site, it was clear that this MagmaCollectionReader can't give accurate and exact results and by itself it can't be used for finding objects. You *always* have to apply some kind of searching over the already reduced collection represented by MagmaCollectionReader in order to find the *exact* match you are trying to locate. So the code should be something like: findUserByEmail: anEmail | user | "Here you are working over the entire magma repo" user := (self users where: [:each | each email equals: anEmail]) "Here you are working over the reduced set returned by the where and represented by a MagmaCollectionReader" detect: [:each | "Here you are working on a plain Collection" each email = anEmail ] ifNone: [nil]. " ^ user After changing the code this way, the example correctly can find the users with emails 'miguel(a)domain1.com', 'miguel(a)domain2.com' and 'miguel.coba(a)domain3.com'. Can someone confirm that this is the correct way to use a MagmaCollectionReader? P.D. I tried with a larger keySize: at index creation (I even try 400 bits) but this only postponed the point where the string matching stop working. Also, it is not efficient and with 400, squeak throws an error. So that was not the way to go. Thank for your comments, Miguel Cobá

5 6

Re: MagmaCollectionReader behavior
by Miguel Cobá 01 Apr '09

01 Apr '09

2009/4/1 Keith Hodges <keith_hodges(a)yahoo.co.uk>: > >> >> I think that this is a point where the requirements for the developers >> can be a little too much. See it this way, we are only indexing a >> string. It shouldn't be necessary to implement a hash code for >> converting them to numbers. Besides, most of us, or at least me, are >> not experts in the hashing techniques and for sure we can't be certain >> that the hash is correct or that don't clash. >> >>> >>> If you want to use a big, fat, e-mail address as a "unique >>> identifier", you will be better served to use most of a 64 or 128-bit >>> key-space than a small percentage of a 400-bit key-space. Using only >>> the alpha range: >>> >>> (MaSearchStringIndex attribute: #email) keySize: 128; beAlpha; >>> yourself >> >> This line it is perfect for the wiki page, instead of the current one, >> because it will give the expected results most of the time. Of course >> the note about the limit cases should be present. > My Bad, > > I threw that code together in a rushed weekend a long time ago and > thought no more of it, it worked, but then I only had 3 records! > > Please do feel free to update the wiki page with improvements Done, Miguel Cobá > > Keith > >

1 0

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma April 2009