Magma

magma@lists.squeakfoundation.org

722 discussions

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

Traits and Magma in Pharo 1.3
by Panu Suominen 02 Nov '11

02 Nov '11

Hi, I have a little problem using Magma, Pharo 1.3 & co. Magma seems to load fine to empty 1.3 image. Tests does not seem to work but data can be stored and loaded. However after loading more code to the image debuger pops up saying that Trait does not understand typeOfClass. This is raised from MaClassDefinition >> initializeForm:. This problem makes impossible to load a trait to the image. Method naming suggest that traits should not end up there anyways? I hacked my self around this problem by adding a guarding line in the begining of MaClassIdManage>>refreshInImageDefinition:. It goes like this: aClass isTrait ifTrue:[^self]. It enables me to load codes to the image, but I have no idea about the possible side effects of this change. Maybe someone more knowledgeable should investigate the issue? :) -- Panu

1 0

security
by Milan Mimica 25 Oct '11

25 Oct '11

Hello! I know magma deliberately omits any client authentication code, but then, how do I prevent anyone to connect and modify my database? Do rely on the firewall to not allow any connections from the outside to magma server port? Do I rely on magma being an obscure database? -- Milan Mimica http://sparklet.sf.net

2 1

Long form of keyword queries
by Udo Schneider 16 Aug '11

16 Aug '11

All, I'm currently searching for the long form of keyword queries. A short form of aMagmaCollection where: [ :reader | reader keywords includesAnyOf: #('test') ]. works fine. This relies on a #doesNotUndestand: call because of #keywords. Thus I'm searching for a long form for it. E.g. something like aMagmaCollection where: [ :reader | reader read: #keywords includesAnyOf: #('test') ]. Any hints? Best Regards, Udo

2 2

[ANN] Magma 1.3alpha1
by Chris Muller 16 Aug '11

16 Aug '11

The first alpha release for Magma 1.3 is available on SqueakMap. The following detail the major improvements since the 1.2 stable release. -- Introducing MagmaSolHashTable. A special kind of collection based on Tom Rushworth's SOLHashTable, which maps Integer keys to an object with O(1) access. Duplicate keys are allowed and can be enumerated in key order. -- New MagmaDictionary implementation. Built atop MagmaSolHashTable is a complete replacement of the MagmaDictionary implementation. The original MagmaDictionary was based on an indexed MagmaCollection, which worked but not efficiently because MagmaCollections incur too-high a query overhead for access to a single object (via #at:). This new implementation puts MagmaDictionary much closer to a MagmaPreallocatedDictionary, but without the large pre-allocation on disk required. -- Introducing MagmaHashTable. Since it was so easy to implement atop the new MagmaSolHashTable, yet another new kind of collection, MagmaHashTable, is also introduced. A MagmaHashTable is similar to a MagmaCollection except: - It can only query a range of one indexed attribute using #from:to:do:. - It can't randomly access via #at: like a regular indexed MagmaCollectionReader. - Access is much faster. -- Improved Monticello Integration. In addition to a persistent domain model, each Magma repository also contains a persistent code model, allowing packages to be browsed, loaded and saved into the repository via the Monticello user-interface. For Squeak, if a Magma-based Monticello repository is part of Monitcello's repository list, two new menu options in each of the class and method-panes of Squeak browsers will be visible: "browse mc versions" and "browse mc origin". The first lists all versions of that method or class-def throughout all version history. The second opens the version-comments box of the version in which that version of the method or class originated, which can be useful for revealing why it was changed. For details, see: http://wiki.squeak.org/squeak/5603 -- Encapsulation of Application State + Behavhiors Employing the Monticello integration, when a #fullBackup is executed, all currently-loaded package versions (which are operating on the model) of the client-image invoking the backup are committed into the Magma repository's built-in Monticello repository model before invoking the actual backup. All packages are saved, including Kernel, System, Monticello, Morphic, etc. which can result in the first #fullBackup taking a long time. If this is unacceptable, then a #modelBackup can be used to back up only the domain model as before. -- Better releasing code ensures all objects which should get GC'd, do. -- Renamed Packages The "Magma client" package has been renamed to "Magma-Client". "Magma server" has been renamed to "Magma-Server". -- Includes utility to upgrade legacy repositories to the next version of Magma.

1 0

depoyment
by Milan Mimica 14 Aug '11

14 Aug '11

Hello List! I'm developing a small website in Seaside and using Magma for persistence. Now it's time to deploy the project to a server where development would continue in a more real environment. I'm not sure how to do it, since I've never deployed a smalltalk image. I was going to run the Magma server in a separate VM, containing not a lot more than needed by Magma. Let's say a plain Pharo image with Magma installed. Seems reasonable to me, but is it a good idea to have it separated from the WEB server and the only client? The other thing I'm concerned about is stopping the server. How do I shut it down gracefully when running in headless mode? -- Milan Mimica http://sparklet.sf.net

5 13

Be careful, problem with WeakOrderedCollection in Pharo (there is a fix)
by Mariano Martinez Peck 08 Aug '11

08 Aug '11

Hi Chris. We found a problem with WeakOrderedCollection in Pharo which may cause problems in Magma users in Pharo. Basically, once a WeakOrderedCollection needed to #grew, it stops being weak because the internal array was replaced by a Array instead of a WeakArray. (WeakOrderedCollection new instVarNamed: 'array') class ->>>> WeakArray (WeakOrderedCollection new grow instVarNamed: 'array') class ->>>> Array So....I can imagine that some applications running magma may grow a lot due to this bug. Just to check whether someone is having this bug or not, you may want to execute: WeakOrderedCollection allInstances select: [:each | (each instVarNamed: 'array') class = Array ] if you have instances, then that's a problem ;) To fix it, you can fileine the changes of the issue tracker: http://code.google.com/p/pharo/issues/detail?id=4596 and then you should fix the already created instances. cheers ps: I have no idea how much Magma uses WeakOrderedCollection, but I thought it was just worth it to raise a warning. -- Mariano http://marianopeck.wordpress.com

2 1

Re: [Vm-dev] A trick to speedup #become: (but not becomeForward:)
by Chris Muller 02 Aug '11

02 Aug '11

I'm not sure how easy it would be to get the physical size of the objects which weren't retrieved. As you said, encoding it in the referencing oid might be the only way - which would require rewriting of the OidMap and upgrade of legacy repositories. :( I understand why it won't work with becomeForward: - because that would be creating two copies of the object. But Magma needs to becomeForward:, rather than become:, its proxies... (pause to remember for sure why...). I think because of proxies to Symbol selectors - you can't become: any object to a Symbol selector or else their CompiledMethod literals would refer to the Proxy... So that would be another hurdle to overcome to succeed with your idea. Just so you know, I _did_ implement your other workaround idea - where reified proxies are "saved up" into a OrderedCollection which is then bulk-becomed only once every 30 seconds. I didn't know if you saw it in the last release (Magma 1.2) - it was a great performance improvement! Your creative ideas are really helping Magma. Thanks, Chris On Sat, Jul 30, 2011 at 8:12 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > An interesting observation: > > if two oops which we need to swap: oop1 and oop2 taking exactly same > space in memory, > then all we need to do is to swap their memory contents, instead of > scanning heap and updating pointers! > > This makes a become operation extremely cheap for such pairs! > As for objects of different sizes, we could still use slow algorithm. > > But knowing that if two objects with same size will be swapped much > faster, a developers could adapt their algorithms to exploit this > feature > (use fixed-size objects instead of variable-sized ones etc). > > Magma using proxies, which then #becomeForward: to real objects when reified. > This is very costly operation and main reason why it so slow on > loading objects from server. > To speed thing up, a special trick can be used: > - each time server sends an object ID (instead of real object) it > could also send its size in bytes (or even more clever - you can > encode object size in its ID ;) ). > Then a client will create a proxy for given object and will try to > match the size, if its possible. (nobody said that proxy can't be > variable-sized, right?) > > Then once client requesting to reify given proxy with real object from > database, VM will just overwrite a proxy's memory contents with real > object. > > -- > Best regards, > Igor Stasenko AKA sig. >

2 3

Magma tests failed on Windows XP
by Toedter, Hartwig 15 Jul '11

15 Jul '11

Hello, I loaded Magma into my Pharo 1.2.1 image using the script "Pharo1.1.2-load-magma.st" (on the web site named Pharo1.2-load-magma.st<http://wiki.squeak.org/squeak/uploads/2657/Pharo1.1.2-load-magma.st>) on Windows XP. After running the script I tried to verify the installation with running "MagmaTestCase fullSuite maDebug" from a Workspace. This ended with an error (se the attached debug log). My short analysis was, that the class ExternalWindowsOSProcess is not suitable for the tests. Which means the tests won't run under Windows XP. Does that further mean Magma won't run under Windows XP? Best regards, Hartwig Tödter iks Gesellschaft für Informations- und Kommunikationssysteme mbH Siemensstraße 27 40721 Hilden Tel.: +(49)2103 5872 16 Mobile: +(49)151 12118408 Fax: +(49)2103 5872 58 E-Mail: mailto:H.Toedter@iks-gmbh.com Internet: http://www.iks-gmbh.com ________________________________________________________________________ iks Gesellschaft für Informations- und Kommunikationssysteme mbH Siemensstrasse 27, 40721 Hilden, Amtsgericht Düsseldorf, HRB 45519 Geschäftsführerin: Dipl.-Inf. Monika Stoll Prokuristen: Dipl.-Ing. (FH) Thomas Kondring & Hartwig Tödter ________________________________________________________________________

3 2

Magma object serializer
by Martin Dias 10 Jun '11

10 Jun '11

Hi, I want to run some benchmarks with the Magma object serializer... Am I using it in the right way? Thanks!! Martin | serializer graphBuffer anObject classDefinitionsByteArray graphBufferByteArray loadedObject | anObject := Array with: 1 with: 'string'. serializer := MaObjectSerializer new. graphBuffer := serializer serializeGraph: anObject. classDefinitionsByteArray := serializer classDefinitionsByteArray. graphBufferByteArray := graphBuffer byteArray. "put these two bytearrays into a stream, and reload them..." loadedObject := MaObjectSerializer new classDefinitionsByteArray: classDefinitionsByteArray; materializeGraph: graphBufferByteArray

5 10

← Newer
1
2
3
4
5
6
7
8
9
...
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