Magma

magma@lists.squeakfoundation.org

722 discussions

test suite cleaned up
by Chris Muller 06 Jan '13

06 Jan '13

Over the last few days I have made new versions of several packages which majorly clean up the way the tests are run. A more-standard SUnit way of launching the test suite can now be employed. Old way: MagmaTestCase fullSuite maDebug New way: MagmaTestCase suite debug (1.4) still uses the old way -- these latest packages can be merged simply by installing the (head) release from SqueakMap.

1 0

[ANN] Magma 1.4
by Chris Muller 01 Jan '13

01 Jan '13

cc: Magma list ---------- Forwarded message ---------- From: Chris Muller <ma.chris.m(a)gmail.com> Date: Fri, Dec 28, 2012 at 3:53 PM Subject: [squeak-dev] [ANN] Magma 1.4 To: squeak dev <squeak-dev(a)lists.squeakfoundation.org> I am pleased to announce the release of Magma 1.4 for Squeak 4.4. Magma is a database for Squeak that allows complex domain models to be developed with virtually no regard for persistence issues. Said models can run entirely in memory without Magma even loaded in the image or, by loading Magma, the size of the domain model can exceed the size of RAM and be simultaneously accessed and updated by multiple clients over a network with ACID properties. Further, by copying the database files to another machine on same network and starting a server on them, uninterrupted 24x7 service is gained automatically -- either server can go down at any time and will be automatically sync'd from the other when restarted. Magma regards data-integrity as a top priority. My oldest critical database still running today was "born" in 2004 and has survived major domain refactorings, 8 years of Magma upgrades, two hard-drive crashes and several power-outages. By hashing the contents of every commit, and writing them atomically to disk (among other security measures), Magma is an ultra-safe place to develop and store mission-critical objects. Correct mcz versions of domain code can be co-located in the same repository as the model it runs, ensuring full application recoverability even in the worst circumstances. I've learned that transparent persistence is a complex problem that, IMO, only a mature framework can deliver in a mature way. Magma 1.4 brings heightened levels of stability, robustness and performance over its predecessor. Applications just run better, faster, with better memory management, usability and performance. The change-log has all of the gory details. This, combined with the recent release of Cog 2640, IMO, makes Squeak+Magma a fantastic platform. PS - Even if you don't use Magma for persistence in your own applications, simply starting an empty database and copying all of your mcz's to it allows the Squeak IDE to show all "mc versions" and the "mc origin" of any method as options on the methods menu, very nice for general development.

6 9

Dealing with a Magma index that's out of step
by Nick Brown 13 Nov '12

13 Nov '12

Hi Chris and all, I have Magma in a small Seaside application, used internally at my workplace. It's running on Pharo 1.3 using the 1.3 patch and load script from the Squeak wiki. Primarily we keep domain objects inside a MagmaCollection, with various indexes, and occasionally a commit will cause an indexed value to change, and of course we use #noteOldKeysFor: to ensure the indexes get updated when this happens. A couple of days ago we had an incident where a runaway process on a server cause it to become largely unresponsive. This server also holds the Magma repository. It appears that as a result of Magma operating through this incident, a commit on a domain object succeeded, but the index update failed, so the index continued to reflect the old state of the object. (I can't prove this is the cause, but it seems to me likely.) Hitting Google for advice on fixing the Magma index, I found a thread on this list [1] where the given solution to this sort of index problem is to remove and re-add the object to the collection. However, when I remove the object from the collection, it doesn't get removed from the index (presumably because the index entry removal depends upon the state of the object being correspondent, which of course in this case, it isn't.) On re-adding the object to the collection, it gets indexed with its correct state, but this is in *addition* to the old index entry. So that didn't fix my problem. I did subsequently fix it by reverting the state of the domain object to match the index, then progressing the object forward through its normal process, successfully updating the index as it went. So, the questions are: 1 - Is there another way of fixing the problem, that I missed? 2 - Ought there to be clearly defined interfaces for forcing in & out particular index entries, or forcing entire index rebuilds? Thanks, Nick [1] http://thread.gmane.org/gmane.comp.lang.smalltalk.squeak.magma/914/focus=914

2 2

Re: [Vm-dev] [Pharo-project] Plan/discussion/communication around new object format
by Chris Muller 15 Jun '12

15 Jun '12

(discussion branch moved to Magma list). Well, I doubt it's faster than just using Avi's regular WriteBarrier. Understand the overrides are only compiled once per class, not once per object. In the real world compilation is not a significant factor on performance. The overridden methods follow the pattern: someMethod | t1 t2 newT1 newT2 returnValue | t1 := self instVarAt: 1. t2 := self instVarAt: 2. returnValue := super someMethod. newT1==t1 ifFalse: [ self modified. ^ returnValue ]. newT2==t2 ifFalse: [ self modified. ^ returnValue ]. ^ returnValue which is probably even faster than unwinding stack all the way to the Immutable handler every time an attribute is set. Not sure, but the above is fast enough to accomplish the overall goal and substantially improve app performance. > Ok, what if we call it a "fast write-barrier provided by the VM". > Would that change your view? Igor?

3 5

Re: selective commit
by Milan Mimica 12 Jun '12

12 Jun '12

Suppose my root is anArray. Now I load two elements from that array: a := session root at: 1. b := session root at: 2. Then I mutate both of them. Now I want to commit changes I made to 'a', but not 'b'. On 11 June 2012 22:26, Chris Muller <asqueaker(a)gmail.com> wrote: > Hi Milan, I don't understand -- ...you have a (Magma?) database and > you want to commit changes to some of the objects in the database but > not all of them? That obviously works so I guess you are asking about > something different -- could you please clarify? > > > > On Mon, Jun 11, 2012 at 1:42 PM, Milan Mimica <milan.mimica(a)gmail.com> > wrote: > > Hi > > > > Do I understand correctly that Magma doesn't support commit on per > instance > > basis? I want to commit only some of the some instances I have loaded > from > > database. > > > > > > -- > > Milan Mimica > > http://sparklet.sf.net > > > > _______________________________________________ > > Magma mailing list > > Magma(a)lists.squeakfoundation.org > > http://lists.squeakfoundation.org/mailman/listinfo/magma > > > -- Milan Mimica http://sparklet.sf.net

2 2

selective commit
by Milan Mimica 11 Jun '12

11 Jun '12

Hi Do I understand correctly that Magma doesn't support commit on per instance basis? I want to commit only some of the some instances I have loaded from database. -- Milan Mimica http://sparklet.sf.net

1 0

Re: [Pharo-users] Magma benchmarks and stability
by Igor Stasenko 15 Mar '12

15 Mar '12

On 15 March 2012 18:20, Bernat Romagosa <tibabenfortlapalanca(a)gmail.com> wrote: > Hi, > > Just how slow is Magma? And how stable? > > Is it a good choice for an application that will be used by around 200 users > every day? The application wouldn't need to support a big workload, > substantially many more queries than insertions. > i think you'd better ask it on magma mailing list: <magma(a)lists.squeakfoundation.org> so people who know things better can see your questions. -- Best regards, Igor Stasenko.

2 1

MagmaUpgrader missing methods?
by Hernán Morales Durand 08 Mar '12

08 Mar '12

I've installed Magma in Pharo 1.3 OneClick following instructions here: http://wiki.squeak.org/squeak/2657, i.e. applied patch Pharo-1.3-patches-for-Magma.cs.gz<http://wiki.squeak.org/squeak/uploads/2657/Pharo-1.3-patches-for-Magma.cs.gz>and doIt to the script Pharo1.3-load-magma1.st<http://wiki.squeak.org/squeak/uploads/2657/Pharo1.3-load-magma1.st> I tried to upgrade my databases from version 12 to 16, but there is no MagmaUpdater #compressTo: or #source: methods as described in a previous mail in this list. Instead I've found this way: ( MagmaUpgrader location: 'd:\Smalltalk\Projects\Browsers\MagmaBrowser\MBTest7\') upgrade but it is failing again MagmaUpgrader(Object)>>subclassResponsibility Receiver: a MagmaUpgrader Arguments and temporary variables: Receiver's instance variables: location: 'd:\Smalltalk\Projects\Browsers\MagmaBrowser\MBTest7\' definition: nil session: nil MagmaUpgrader>>legacyVersion Receiver: a MagmaUpgrader Arguments and temporary variables: ... do I need to install an additional package or there is an alternative way to upgrade? Cheers, Hernán

1 0

Root object migration
by Brian Tabone 28 Feb '12

28 Feb '12

I originally set up my Magma repository to use the MagmaPreAllocatedDictionary and now I want to switch to the MagmaDictionary (I'm on Magma 1.3). I want to do this primarily so I can iterate easily over the keys. Is there a tried and true way to migrate your objects from one root to another? Should I set up another repository with a MagmaDictionary as root and iterate over known keys from the old repository and insert and commit them against the new repository? Thanks in advance, Brian Tabone

2 1

Re: [Pharo-project] garbage collection
by Chris Muller 20 Feb '12

20 Feb '12

> Very strange. Shortly after I read your post I opened a unresponsive image > myself. In the process stack I saw that magma was the culprit (didn't remember > I have it installed in that image). However the problem was that I moved my > directory and magma was looking for the old path. I didn't investigate further but > it seems that the MagmaRepositoryController>>#open (called on startUp) is > able to block the UI thread. In the same image I could use seaside still although > the UI was frozen. Hi. Based on your description, it sounds like Magma hit its warning condition check that it found a file named "_open" in the repository directory, indicating it thinks another process has it open. This can occur if the server image did not shut down properly last time. Before starting the image, see if there is a file called "_open" and, if there is, delete it. The image should start normally now. This is something that has annoyed me at least a couple of times as well. I'm not sure what the UI process was doing in your case, but Alt+. should allow you to interrupt it and see the stacks.. My suspicion is that something in the image wanted a MagmaSession to do something, but since the server was waiting for you to respond to the Warning about "_open" it wouldn't return... The confusing part for me is, the image startup code runs in the UI process doesn't it? So why were there two Processes to possibly get into a deadlock? - Chris

2 1

← Newer
1
2
3
4
5
6
7
...
73
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma