Magma December 2011

magma@lists.squeakfoundation.org

8 participants
9 discussions

transactions
by Milan Mimica 25 Dec '11

25 Dec '11

I have spent some time trying to use Magma properly, hoping that some things that weren't clear at the beginning will eventually come clear. But one thing I still don't get: transactions. I understand transaction semantics in RDMS, but what does it mean in magma? What is the difference between modifying an object inside and outside transaction? This two code snippets don't show any difference. session := ... model := session root model. model firstName: 'foo'. session begin. model lastName: 'bar'. session commit. session := ... model := session root model. session begin. model firstName: 'foo'. model lastName: 'bar'. session commit. They both commit both firstName and lastName properties, so I don't see any use of opening and ending a transaction. Couldn't there just be a commit message, so that you are always in a transaction, as that is how it apparently works? -- Milan Mimica http://sparklet.sf.net

2 3

Fwd: two, hopefully, small issues
by Milan Mimica 13 Dec '11

13 Dec '11

---------- Forwarded message ---------- From: Milan Mimica <milan.mimica(a)gmail.com> Date: 13 December 2011 19:44 Subject: Re: two, hopefully, small issues To: Chris Muller <ma.chris.m(a)gmail.com> On 12 December 2011 21:37, Chris Muller <ma.chris.m(a)gmail.com> wrote: > > > You would just > not use WriteBarrier in development if the problem affects you.. > Running one setup in development and another in production is not an option. I am not going to do that. > I dug up my old correspondence with Avi and forwarded it to this list. > Please have a look and if it is no longer a problem or you have a > solution, please post it to Magma Inbox and I'd be happy to integrate > it. > I can't seem to reproduce the problem. There is a snipped you posted and you claim it raises a primitive failure, but it doesn't for me. That's good news. It doesn't surprise me though. The problem showed up more that 6 years ago, it was a different VM and everything. I am just going to use the WB feature and I'll let you know if something horrible happens. -- Milan Mimica http://sparklet.sf.net -- Milan Mimica http://sparklet.sf.net

1 0

Fwd: Significant WriteBarrier bug, assistance needed
by Chris Muller 12 Dec '11

12 Dec '11

----- Forwarded Message ----- From: Chris Muller <chris(a)funkyobjects.org> To: avi(a)beta4.com Sent: Monday, April 11, 2005 10:21 AM Subject: Re: Significant WriteBarrier bug, assistance needed Hi Avi, I did spend some more time with it, but I wasn't able to find a solution. The main challenge is in updating existing instances of the * classes (e.g., the anonymous subclasses). My initial statement that we should need to do nothing when WbTestA is modified was wrong, the * classes do indeed have a different format, that's why we are unable to remove them from the WriteBarrier. But I have not been successful in using any existing system methods (i.e., "ClassBuilder new mutate: oldClass to: class") because they are not equipped to migrate instances with different instSizes. And that's the odd thing; when it comes into #migrateFromTarget: oldSuperclass to: newSuperclass the oldClass' instSize is still 1, even though it has two instVars in its superclasses (I changed the test script I sent you to start-out WbTestA with one variable instead of none). So, in the back of my mind, I've been thinking about potential "backup" ideas such as writing a custom migration method that can handle this odd situation. OR, try to find some kind of "pre-notification" from the SystemChangeNotifier of the class-change (if even available!) and remove all and then add them back in on the post.. I dunno, I actually hope this will be a piece of cake for you so I don't have to resort to this. I just posted a new Magma on SqueakSource last night that supports WriteBarrier but leaves it off by default due to this problem. With WriteBarrier turned on, the peak commit rate jumped from about 20 per second to 114 per second! The bottom line is, WriteBarrier is way too cool to stop now. And I love how this could not be done in Java.. :) Please let me know if I can help in any way. Thanks, Chris --- Avi Bryant <avi.bryant(a)gmail.com> wrote: > On Apr 5, 2005 10:35 PM, Chris Muller <chris(a)funkyobjects.org> wrote: > > Hi, I know you just helped me with one bug but now I've run into a tougher > one. > > I thought I had it nailed, I think my fix is close but there is still one > > problem which I can't seem to fix. > > Hi Chris, > > Did you ever make any progress on this? > > Avi > >

1 0

Fwd: Significant WriteBarrier bug, assistance needed
by Chris Muller 12 Dec '11

12 Dec '11

----- Forwarded Message ----- From: Chris Muller <chris(a)funkyobjects.org> To: Avi Bryant <avi(a)beta4.com> Sent: Tuesday, April 5, 2005 3:35 PM Subject: Significant WriteBarrier bug, assistance needed Hi, I know you just helped me with one bug but now I've run into a tougher one. I thought I had it nailed, I think my fix is close but there is still one problem which I can't seem to fix. Here's the problem. Given this class-hierarchy: Object WbTestA WbTestB and instances of WbTestB are behind write-barrier, if then inst-vars are added to WbTestA, the current implementation tries to migrate (e.g., in WBClassBuider>>migrateFromTarget:to:) based on what comes in from the SystemChangeEvent, which is the WbTestA changes. It ends up creating a new write-barrier subclass for WbTestA and assigning that to the 'class' variable of the builder for WbTestB. A primitive failure soon results. Based on my research, it seems, under this case, no migration of old WbTestB instances should be necessary because class WbTestB will, by the time it gets to WBClassBuider>>migrateFromTarget:to:, already be pointing to the new WbTestA superclass, not the old one. So my fix so far involves changing that method to: migrateFromTarget: oldSuperclass to: newSuperclass | oldClass | oldClass _ class. "Was the immediate WriteBarrier superclass modified (or was it a superclass of that)?" (oldClass superclass == newSuperclass) ifTrue: [ oldClass superclass: oldSuperclass. class _ self createSubclassOf: newSuperclass. class updateInstancesFrom: oldClass ] To test this, I created these two test scripts. The first as a regression-test for changing the immediate superclass, the second to handle the new scenario I stumbled on. "Immediate superclass change test." | a wb domain | a _ Object subclass: #WbTestA instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized'. b _ (Smalltalk at: #WbTestA) subclass: #WbTestB instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized'. wb _ WriteBarrier new. domain _ (Smalltalk at: #WbTestB) new. wb add: domain. [ a subclass: #WbTestB instanceVariableNames: 'newBvar' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized' ] ensure: [ wb remove: domain. b removeFromSystem. a removeFromSystem ] "Super superclass change test." | a b wb domain | a _ Object subclass: #WbTestA instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized'. b _ (Smalltalk at: #WbTestA) subclass: #WbTestB instanceVariableNames: '' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized'. wb _ WriteBarrier new. domain _ (Smalltalk at: #WbTestB) new. wb halt add: domain. [ Object subclass: #WbTestA instanceVariableNames: 'newAvar' classVariableNames: '' poolDictionaries: '' category: 'as yet uncategorized' ] ensure: [ wb remove: domain. b removeFromSystem. a removeFromSystem ] So, what's the problem now? The first test still works, the second "works" until it tries to clean up. The line in the ensure block: wb remove: domain gets a primitive failure in primitiveChangeClassTo: and I can't figure out why. The commment is very detailed about the possible reasons but I still think we're not violating any of those reasons, it should work.. I stared at it until 1am, but I'm just not seeing it.. Can you give me a hand? Thanks, Chris

1 0

two, hopefully, small issues
by Milan Mimica 12 Dec '11

12 Dec '11

MagmaWbClassBuilder >> migrateFromTarget:to: starts with a "self halt". I assume that is just some debug leftover. Am I right? In MagmaSession class >> cleanUp occurence of "(PointerFinder pointersTo: each)" should be replaced with "each pointersTo", since PointerFinder is deprecated (I'm talking Pharo 1.3 here). I made a patch. -- Milan Mimica http://sparklet.sf.net

3 3

about WriteBarrier
by Chris Muller 11 Dec '11

11 Dec '11

> I would like to take a look to this. In which primitives you need to send > #yourself for example? This is because otherwise the VM will fail / crash > because it expects the parameters of a primitive to be of a certain type > rather than a proxy ? Right, this is the problem that has been solved with the new extension. > Which are those subclases you mention that override the primitive methods? The ones that WriteBarrier dynamically instantiates for each class of object added to the WB. Please look at the WriteBarrier package (it's a small, standalone package) and it will become crystal clear. > Thanks and congrats for the release. Thanks, Chris

3 3

[ANN] Magma 1.3
by Chris Muller 09 Dec '11

09 Dec '11

I am very pleased to announce the immediate availability of Magma 1.3. The following detail the major improvements to 1.3 over 1.2: Serializer Upgrade ==== BlockClosures (Contexts and CompiledMethods too, of course), can now be stored in the database, even with references to inst-vars, self, temps or globals. Split-Ordered Lists ==== Tom Rushworth developed a fantastic Split-Ordered list implementation for Squeak. Working closely with Tom, this package has been extended in Magma to support very large SOL collections, implemented as a MagmaSolHashTable. Thank you Tom! The MagmaSolHashTable is actually a fairly primitive collection, and was used as the basis for two new collections: A MagmaHashTable and a completely new implementation of MagmaDictionary which is much faster than the old one (almost as fast as a preallocated dictionary). Full Monticello Model ==== When using Magma as a Monticello repository the package versions are not zipped but stored directly in the repository as native instances of MCVersions, MCPackages, MCInfos, MCDefinitions, etc. All of these original MC object instances are canonicalized so there is only ONE copy of that MCMethodDefinition from 2002 which is shared rather than copied in every version since. MCPackages are also canonicalized, as is all ancestry! For packages stored in a Magma repository, two new menu options appear on the methods menu and classes menu: browse mc versions browse mc origin The first shows all versions of a particular method or class-definition across all MC versions saved to that repository, in chronological order (no latency). The second opens the MC-Version Inspector in which that version of the method was saved, to see the version notes. This is very useful for quickly knowing WHY changes were made. Note: Currently only Squeak has its IDE tools updated to support this. WriteBarrier Resurrection ==== After two years dormancy, Avi Bryant's original WriteBarrier has been resurrected for use in closure/Cog images. Its original dependency on NewCompiler has been removed. With both the WriteBarrier and Cog, the MagmaBenchmarker reports a new record maximum commit rate -- 456 commits per second !! The WriteBarrier is now on by default, so nothing needs to be done to enjoy the speed up. Proxy Transparency ==== A new extension to the WriteBarrier should now alleviate the need to send #yourself to primitive arguments! Primitives which require arguments are now overridden in the anonymous subclass so that the arguments will automatically be ensured to be fully-reified for the super call. Immutability ==== For performance, TimeSpans, Durations, DateAndTimes, Points, Intervals, Colors are now immutable. Strings are also immutable by default, but now a custom ImmutabilityStrategy may be specified, providing fine control over immutability in case mutable Strings are needed (or if other objects can be made immutable). Platform Independence ==== Magma 1.3 runs on Squeak 4.3 and Pharo 1.3. All of the packages have been renamed in accordance with contemporary package naming conventions employed by most other active Squeak and Pharo projects. Platform-specific behaviors are now in platform-specific packages (named with "-Squeak" or "-Pharo"). The package hierarchy is documented at http://wiki.squeak.org/squeak/6178. More ==== Many minor cleanups, fixes, and usability improvements. This is, by far, the best Magma ever. Please enjoy the new version. - Chris

5 4

Fulltext searches
by Benoit St-Jean 08 Dec '11

08 Dec '11

Quick question! Let's suppose I want to design a message board and store posts from users (and topics, and users, and discussion threads, etc) and that I also want to allow user to search the message posts contents for some strings... I couln't find it but is there anything similar to fulltext indexes in Magma? ----------------- Benoit St-Jean Yahoo! Messenger: bstjean A standpoint is an intellectual horizon of radius zero. (Albert Einstein)

1 0

Re: [Pharo-users] [pharo-users] Can't Load Magma in Pharo 1.3
by Mariano Martinez Peck 05 Dec '11

05 Dec '11

Hi. It looks like OSProcess (a dependency of Magma) is registering a class in the startUp list explicitly before ImageSegment (which was removed). This was already fixed in new version of OSProcess. Hence, ConfigurationOfMagma should be updated to use the new version of OSProcess. Cheers On Mon, Oct 24, 2011 at 4:54 PM, Ankur Sethi <get.me.ankur(a)gmail.com> wrote: > Hi, > > I'm new to Pharo and Smalltalk in general. I'm trying to build a small > blogging application using Pharo and Seaside. I've decided to use > Magma for persistence, but I'm having some issues loading it in Pharo > 1.3. > > I loaded Magma the usual way: > > Gofer new > squeaksource: 'MetacelloRepository'; > package: 'ConfigurationOfMagma'; > load. > > (Smalltalk at:#ConfigurationOfMagma) > project latestVersion > load: 'Server'; > load: 'Client'. > > ... and I was presented with a backtrace. Since didn't know how to get > a full backtrace out of Pharo in plain text, I took a screenshot: > http://imagebin.org/180559 > > I know this is not adequate, but I'm hoping someone can help me get > Pharo to give me information about this issue in a more convenient > format. > > When I told Pharo to abandon loading the package and then re-evaluated > this: > > (Smalltalk at:#ConfigurationOfMagma) > project latestVersion > load: 'Server'; > load: 'Client'. > > ... then everything went just fine. I even tried creating a Magma > repository, which worked. However, some things were totally borked in > my Pharo image. I couldn't get the System Browser to do syntax > highlighting, for one. > > I'm using Pharo1.3 + CogVM 13307 on Mac OS X Lion. > > I hope I made sense. > > Thanks. > > -- > Ankur Sethi > (GeneralMaximus on IRC and elsewhere) > > -- Mariano http://marianopeck.wordpress.com

2 7

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma December 2011