Magma

magma@lists.squeakfoundation.org

722 discussions

Start a nNew thread

Test
by Chris Muller 15 Aug '16

15 Aug '16

Please ignore

1 0

Re: Magma 1.5
by Chris Muller 17 Aug '15

17 Aug '15

Hi, Magma 1.3 runs on Pharo 1.3 (http://wiki.squeak.org/squeak/2657 and scroll down to "Pharo"), and a "Magma for Pharo" project was set up at http://ss3.gemtalksystems.com/ss/MagmaPharo.html/ a few years ago. Although I am not currently planning to port Magma to Pharo, I would welcome and support anyone who wanted to do that. Best, Chris On Mon, Aug 17, 2015 at 11:46 AM, Torsten Bergmann <astares(a)gmx.de> wrote: > Hi Chris, > > I blogged about the new release at: http://astares.blogspot.de/2015/08/magma-15.html > > One question: > > Is Magma still Squeak only? Or are there ports available/planned > to other ST dialects? Especially a Magma for Pharo would be nice as Pharo > is more interesting for commercial development and still open source > like Squeak. > > Thanks > T.

1 0

Fwd: [ANN] Magma 1.5
by Chris Muller 13 Aug '15

13 Aug '15

I am pleased to announce version 1.5 of Magma for Squeak 5, now available on SqueakMap. Magma allows multiple Squeak images to collaborate on a single, large object model, with the robustness and control expected from a database. It offers the most transparent db access possible for Smalltalk, affording the user the ability to develop complex, performant designs, iteratively, on-the-fly. It has been designed for "continuous flow" development, the way Smalltalkers like and expect to work. For example, I could have connections open to 3 separate databases, open transactions in any of them, and having restructured a class hierarchy in the model, and stepping through the debugger when that "final boarding call" for my flight is announced. Thanks to the image, this scenario has never been a problem for Smalltalkers and Magma is deliberate to ensure this flow is maintained. Once at 10K feet, I can resume stepping through that same debugger within 5 seconds of restarting the image, DB connections intact, commit my transactions when I'm ready, done. Magma handles every aspect of that use-case correctly even in multi-user environments, and has so many safety and integrity features, it is the safest way to develop and keep a model in Squeak. This release coincides with the release of Squeak 5, and has many improvements and fixes over Magma 1.4. Detailed notes about these improvements are available at http://wiki.squeak.org/squeak/6209. - Chris

2 1

question: "Root" explanation
by magmaodb dslextreme.com 29 Jul '15

29 Jul '15

Hello, I am interested to convert my existing application from Oracle to Magma simply due to simplicity to manage and get away from converting from data to object and back, plus other issues involving relational database management. Anyway I do code in Smalltalk, but new to Squeak and definitely have no experience in Object databases. I read the literature and reviewed the Magma-Tester... classes to help me to understand the concept and the usage. One of the recommendations remains unclear, that is - NOT to use the Dictionary class as the ROOT, but instead use some other class to avoid the depth of "1", which is common for Collection classes retrieval. Could you please elaborate, what would you use for the superclass of the root class and would it have any subclasses (if any, please provide example). The point of confusion is that the method at:put: would be implemented in the root class and it is implemented in some of the collection classes. The Object class (which is one of of implementers) expecting integers only and I would like to have literals such as "person". The collection classes would allow for literals, but the recommendation (my assumption) would be other than the collection class. Obviously, I am missing something, please provide some examples (or correct me) so it would help me to move forward in the way that you have intended. Ian

2 2

Hi everybody
by Luis Sánchez Peña 28 Apr '15

28 Apr '15

Hello, I am Luis Sánchez from Barcelona, Spain. I have been a hobby software developer in Smalltalk since 7 years. I make software only for me and my job and only in Smalltalk. I learnt C and Java, but I didn't like them. When I started, I discovered Magma and Seaside. I liked both of them and used them for programming in Pharo. Now Magma doesn't work anymore in Pharo and I miss it. I would like to come back to Squeak because Magma still runs in Squeak. I come to this list because I want to learn about this wonderful project and help with my Smalltalk knowledge. Thanks, Luis Sánchez Peña

2 1

Re: [Seaside] Migrations - Object Database
by Chris Muller 27 Apr '14

27 Apr '14

I use Magma, but yes, Data-quality management applies to any persistent model, and is a little more involved than at first it seems, because it's tempting to just spank-out a workspace script which enumerates appropriate objects in your DB and fixes/upgrades them. But doing only that is loaded with caveats. After running a repair script, can one _really_ feel comfortable the model is "all fixed" and ready for production? Did the script really work? Did it catch all cases or was there possibly a bug in it? To address these concerns, Magma employs a first-class DataRepair which is used to perform data repairs/migrations on Magma models in a controlled and reliable fashion. It is based on the repair process we used at Florida Power and Light for patching/upgrading the models in its GemStone databases. The requirements of a data-repair are: - Enumerate all objects needing repair. - Of the enumerated objects, #check, #count or #identify the ones that are in need of repair. - Of the enumerated objects, #improve or #repair the ones that are in need of repair. - Before committing #repair, _verify_ whether the repaired objects are, in fact, repaired by using the same check as for #check, #count and #identify. If they are, commit, if not, abort. - Connect a brand-new session, run a final #check and report whether the repair was successful or failed. - (Optional) If successful, you might wish to persist the DataRepair object itself somewhere in your database, so it has a history of what was done to it. - Output report of for each of the above actions. Here is an example of Magma's DataRepair constructor: (MagmaDataRepair at: (MagmaRemoteLocation host: 'prod1' port: 51199) enumerate: [ : session : repair | session root accountsDo: [ : eachAccount | repair check: eachAccount ] ] check: [ : eachAccount : repair | eachAccount importFilters anySatisfy: [ : each | each class = MaxImportFilter ] ]) repair: [ : eachAccount : repair | eachAccount importFilters withIndexDo: [ : eachFilter : index | eachAccount importFilters at: index put: eachFilter asKeywordFilter ] ] To this object, I can send any of the 5 actions: #check, #count, #identify, #improve or #repair. The first three are read-only operations. The 4th will commit the repairs as-it-goes, the last one only commits after a successful pre-verification. Although you the user must specify the enumerate:, check: and repair: blocks, the DataRepair object encapsulates the _process_ of repairing models in a controlled and reliable fashion, by using those user-specified, model-specific blocks. - Chris On Sat, Apr 26, 2014 at 11:55 AM, Aaron Rosenzweig <aaron(a)chatnbike.com>wrote: > Hi, > > We’ve been experimenting with GOODS as an object database persistency > mechanism for a couple of weeks. We plan to use Dali with it too. We’re > really excited about this but have a burning question. > > *Question: * > How do we handle changes to the “model” layer? > > *Example: * > Suppose that last week we had a “Person” and “Profession” object. Each > “Person” could only have one “Profession.” We’ve been saving some data to > our Object Database and have 500 people and 25 professions currently saved > and used with our app. > > This week we realize that our world view is wrong. Some people are both a > “Chef” and a “Computer Scientist.” They have 2 or more professions. We must > change our “model.” The class “Person” must change. > > How do we fix our object database now? > > *Background:* > This isn’t really a GOODS specific question is it? I imagine it is the > same issue with Magma, GemStone, etc. But in all the examples I’ve found > nobody seems to talk about “migrations” or maybe I’ve overlooked it. Can > someone point me in the right direction? > > In NeXT / Apple WebObjects I would write a “migration” to do the necessary > steps to change SQL tables, make new DB constraints, etc. as an executable > script. I would commit this migration to the repository. Any of the other > developers on our team would automatically get it when they pulled from the > repository. They don’t need to think about it. As soon as the WebObjects > app launches the migrations would be run and they could see the new > functionality and make “Marcus” both a “Chef and a Computer Scientist." > When we deploy the new code in production, the migration will automatically > run there too. This is all explained in detail here: > > > https://github.com/wocommunity/wonder/blob/master/Frameworks/Core/ERExtensi… > > Any helpful pointers are appreciated. > > Thank you, > *Aaron Rosenzweig* / Chat 'n Bike <http://www.chatnbike.com> > *e:* aaron(a)chatnbike.com *t:* (301) 956-2319 [image: Chat 'n Bike] [image: > Chat 'n Bike] > > > _______________________________________________ > seaside mailing list > seaside(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside > >

3 4

Re: [Newbies] Re: Is Squeak/Pharo an appropriate language choice?
by Chris Muller 02 Nov '13

02 Nov '13

Hi Charles, when I saw the description of what you were looking for -- - an object model that larger than the size of available RAM - transparent access - keyword access - multi-core access and updates I wanted to let you know Magma fits that problem domain like a glove. Whether it can meet your performance requirements -- only you can decide, but maybe I can at least clarify some of your questions. > Long answer (excuse the rambling, I was thinking it through as I wrote it): > If I'm understanding http://wiki.squeak.org/squeak/2639 correctly, which I > may not be, I'd still need to recode the entire graph structure to be > designed in terms of id#s (keys) rather than direct references. > I.e., I'd need to code it in terms of two collections one of which would > contain keys that, when interpreted, referenced itself. This does appear to > move the plan into the area of the possible, but at the cost of the > advantage that I'd hoped Smalltalk would provide of a large persistent > image. I thought at first when it was talking about transparency that this > wouldn't be necessary, but: No. There is no inherent requirement for any object to have id's. You can, of course, but ODBMS's, whether GemStone or Magma, access their objects transparently via direct pointer. > Magma can maintain and quickly "search" large, flat structures, but the > normal Smalltalk collections such as Bag or OrderedCollection are not > suitable for this. The contiguous ByteArray records Magma uses to store and > transport Smalltalk objects would be impractical for a large Smalltalk > Collection > > Seems to mean that the Graph couldn't be stored as something that Magma > would recognize as a graph. I'm not sure what you mean by "recognize as a graph" but I don't think that's correct. MagmaCollections are treated the same as regular collections, except that they can be very large and with increased concurrency between sessions. > So does "Objects are persisted by > reachability", though that has other possible interpretations. But since > the graph would contain a very large number of cycles in multiple > "dimensions"... OTOH http://wiki.squeak.org/squeak/2638 on Read Strategies > appears to mean that it wouldn't automatically (or rather could be set to > not automatically) pull in items that are references within the object being > read. ReadStrategies are a performance optimization only. You should never use them except in very special cases after observing and diagnosing slowness. > Again, http://wiki.squeak.org/squeak/5722 , may mean that a class with named > variables holding 4 arrays of arrays of length 3 (reference float float) and > a few other variables containing things like bools and strings and ints, > would be handled without problem. But note that each of those references is > to an item of the same type, and it could include cycles. So I can't decide > WHAT it means. Do I need to recode the references as id#s? Does that even > suffice? (If it does, then it's still a good deal. But if I must name each > entry separately, it's not a good deal at all, as the number of entries in > each of the 4 outer level arrays is highly variable, and though I intend to > apply an upper limit, only experiment can determine what a reasonable upper > limit is.) Sorry if I'm having trouble understanding your question here. Why would you need to "recode the references as id's?" ODBMS's preserve the graph in the exact shape it was committed, including cycles. > And yet again (if I'm understanding correctly) I'm going to need to violate > just about every one of the hints on performance in > http://wiki.squeak.org/squeak/2985 . I'm not sure how much MagmaArray keeps > in RAM of things that aren't currently in use. At one point it sounded like > 6 bytes. This is actually a lot of overhead in this kind of a system. MagmaArray's keep just one "page" of objects in memory at a time. The default page is 125, meaning 125 objects it references. But you can change that to anything you want as long as its > 0. > Additionally, it appears that Magma doesn't have anyway to detect that a > reference is "stale" (i.e., hasn't been referenced in a long time), an use > that to decide to roll it out. It looks as if this needs to be done by the > program...but that time-stamp (and a few other items mustn't (well, > needn't...but I sure would need to overwrite it when I read it in) itself be > included in the items rolled out. So I need to solve THAT problem. When you said, "hasn't been referenced in a long time" I assume you meant "hasn't been ACCESSED in a long time". When you say "roll it out" I assume you mean remove it from memory so RAM can be recovered? If so, you should know that Magma only references retrieved objects via Weak collections. If your app is no longer referencing them, they'll get "rolled out" automatically. If your app is, obviously they won't. > Magma seems to be a good object database, but I can't see that it makes > Smalltalk a desirable choice for this project (It may, this could be a > documentation problem...either my not understanding it or the information > not being clear.) If I'm going to recode the references into id#s, then > either Ruby or Python make it trivial to turn the object into a string (and > to reconstitute it later), and they also make it trivial to leave out any > volatile variables. Perhaps Magma does the latter, but this wasn't clear. > > Definitely a part of my problem is that I don't have a clear image of how I > would proceed. The only examples given were small fragments, extremely > useful in clarifying points, but insufficient to yield a larger idea of how > to use things. (E.g., I have no idea how to do Ma Object Serialization, but > I may need to implement it anyway.) You could install and experiment with it..? That's the Smalltalk way. > Perhaps this is all because I don't really know Smalltalk well...which I > assuredly don't. I was hoping to use Smalltalk to avoid the database > problem, trading RAM (including virtual RAM) consumption for capacity, but > it looks as if I end up at a database anyway. And in that case I should use > a language that I'm already familiar with. (I'd really been hoping that the > persistent image would be the answer.) If I do a decomposition I could even > get away with using a key-value store. The only problem is that the id# > requires lookup via an indirect reference. (Is it in the Directory? If > not, get it from the database, if not, it's a new value.) Once I do the > recoding of references to id#s, the database portion is "trivial, but > annoying". But now I've added thousands of additional indirections/second. > However, IIUC, Magma would be doing that under the hood anyway (as opposed > to the image, which would be handled in hardware memory translation), and If > I code it, I can put in things like automatically rolling out when it's > stale. (By the way, does "stub" mean remove from memory, or remove from the > database? From context I decided it probably meant remove from memory, but > I couldn't decide whether dirty data would be written before being removed > from memory, and I couldn't be really sure it wasn't just being deleted. > That needs rephrasing by someone who knows what it's supposed to mean.) #stubOut: is something I, myself, have rarely ever used. It means convert the object back to a Proxy. If there's a chance it has been changed, then it should only be used right after a commit because it does NOT imply any writes to the DB. > To me this appears to be, again, not the project that justifies > implementation in Smalltalk. Perhaps if I were already experienced in > Smalltalk I wouldn't see things that way, as Magma clearly means that > Smalltalk *can* handle doing the project. Ok, good luck. > Thank you for your suggestion. > > -- > Charles Hixson > > > _______________________________________________ > Beginners mailing list > Beginners(a)lists.squeakfoundation.org > http://lists.squeakfoundation.org/mailman/listinfo/beginners >

1 0

all Subspaces
by Fima Bahari 05 Feb '13

05 Feb '13

Dear All How can I have all Subspaces of a VectorSpace in a List?

1 0

Magma 1.4 test failure
by Stuart Herring 09 Jan '13

09 Jan '13

Hi Chris, I'm trying to run the tests for 1.4 in Squeak and I'm getting a failure in tryChangingIndex50 I'm using Squeak 4.4 with a recent Cog VM on Linux, and I loaded Magma 1.4 from Squeak Map. The actual failure is Assertion Failed in the final assertion of tryChangingIndex50: self should: [ err result commitConflicts first conflictingObjects anySatisfy: [ : each | each key = ma yourself ] ]. I'm assuming the tests pass for you? What VM and OS combination have you tried? Regards, Stuart

3 6

Magma 1.4 on Pharo 1.4 and beyond
by Chris Muller 07 Jan '13

07 Jan '13

Hi Pharoers, below is a script which will load Magma 1.4 into Pharo 1.4. Proceed past the Warnings. After loading, you can run the tests by opening a Transcript and then executing: MagmaTestCase fullSuite maDebug Right now the tests immediately hit a snag due to an API factoring in Pharo 1.4 which moved some "vm" accessors out of "Smalltalk" and into "Smalltalk vm" but removing the "vm" prefix.. (sigh). There are also a couple of extension methods needed in Pharo so that MethodContexts can be serialized.. So, given that folks are already moving to 2.0 and there's already talk about Pharo 3.0 alpha, I think we've reached the point where the entire codebase should simply be forked for Pharo so that the code doesn't get too squirrely and with a proliferation of "-Squeak" and "-Pharo" packages. I'm looking for someone with experience with cross-dialect issues interested in getting Magma ported to Pharo. I would help from the Magma side, of course. - Chris | gofer | (Smalltalk hasClassNamed: #MaObject) ifFalse: [ "MaBase layer with tests" gofer := Gofer new squeaksource3: 'MaBase'. #('Collections-BTree-lr.73' 'BrpExtensions-cmm.11' 'Ma-Core-cmm.232' 'Ma-Collections-cmm.141' 'Ma-Ascii-Report-cmm.9' 'Ma-Statistics-cmm.28' 'Ma-Search-cmm.42' 'Ma-Serializer-Core-cmm.290' 'Ma-Serializer-Pharo-Core-cmm.1' 'Ma-Serializer-Tests-cmm.40') do: [ : each | gofer version: each ]. gofer load ]. "Load the Ma client server package" (Smalltalk hasClassNamed: #MaClientSocket) ifFalse: [ Gofer new squeaksource3: 'Ma-Client-Server' ; version: 'Ma-Client-Server-Core-cmm.225' ; version: 'Ma-Client-Server-Tester-cmm.157' ; load. "Include OSProcess to support tester launching of images." Gofer new squeaksource: 'OSProcess' ; version: 'OSProcess-dtl.66' ; load ]. "Magma client" (Smalltalk hasClassNamed: #MagmaSession) ifFalse: [ Gofer new squeaksource3: 'Magma' ; version: 'WriteBarrier-cmm.44' ; version: 'SOLHashTables-cmm.16' ; version: 'Magma-Client-cmm.642' ; load ]. "Magma server" (Smalltalk hasClassNamed: #MagmaServerConsole) ifFalse: [ Gofer new squeaksource3: 'Magma' ; version: 'Magma-Server-cmm.455' ; version: 'Magma-Tools-cmm.68' ; load ]. "Magma tester" (Smalltalk hasClassNamed: #MagmaTestCase) ifFalse: [Gofer new squeaksource3: 'Magma' ; version: 'Magma-Tester-cmm.406' ; version: 'Magma-Pharo-Tester-cmm.1' ; load]

4 6

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

Magma