[maglev-discussion] Persisting Ruby Modules?
Conrad Taylor
Tim Felgentreff
you can do that once, you don't have to do it everytime another class
includes them. Other than that, I don't see anything immediately
wrong, what's the error you are getting?
> --
> You received this message because you are subscribed to the Google Groups
> "MagLev Discussion" group.
> To post to this group, send email to maglev-d...@googlegroups.com.
> To unsubscribe from this group, send email to
> maglev-discuss...@googlegroups.com.
> For more options, visit this group at
> http://groups.google.com/group/maglev-discussion?hl=en.
>
Peter McLain
--
Peter McLain
pmc...@vmware.com
Jesse Cooke
Conrad Taylor
On Tue, Nov 8, 2011 at 10:38 AM, Conrad Taylor <conr...@gmail.com> wrote:Hey ALL, what the proper way to persist a ruby module? I was thinking that something like the following would do the job but appears that I'm missing something:module SomeModulemodule ClassMethods...enddef self.included( klass )klass.extend ClassMethodsMaglev::PERSISTENT_ROOT[ klass ] = Hash.newklass.maglev_persistable # stage the class for persistenceself.maglev_persistable # stage the module for persistenceA while back I talked with Monty & Peter about this #maglev_persistable method & IIRC they didn't think it was the best idea to actually use it.As Peter said, wrapping your code in a persistent_do block is preferred.
Conrad Taylor
Classes and Modules need to be defined in persistent mode. Try wrapping your code in Maglev.persistent do ... end, or run maglev on the module definition file with the --commit option.
Conrad Taylor
You might want to make the ClassMethods module persistable, too, also,
you can do that once, you don't have to do it everytime another class
includes them. Other than that, I don't see anything immediately
wrong, what's the error you are getting?
Peter McLain
I guess there is a bit of confusion (to which, I contributed).
In your example, which module did not get persisted? My comment assumed that it was SomeModule that wasn't persisted. But your code also tries to persist any class the mixes in SomeModule, so I'm not sure which Module/Class is not getting persisted.
For the code below to work, you'll certainly first need to ensure SomeModule is persisted, and that is NOT being done by the code below. (more comments below).
> On Tue, Nov 8, 2011 at 11:08 AM, Jesse Cooke <je...@jc00ke.com> wrote:
> On Tue, Nov 8, 2011 at 10:38 AM, Conrad Taylor <conr...@gmail.com> wrote:
> Hey ALL, what the proper way to persist a ruby module? I was thinking that something like the following would do the job but appears that I'm missing something:
>
> module SomeModule
>
> module ClassMethods
>
> ...
>
> end
>
> def self.included( klass )
>
> klass.extend ClassMethods
>
> Maglev::PERSISTENT_ROOT[ klass ] = Hash.new
>
> klass.maglev_persistable # stage the class for persistence
>
> self.maglev_persistable # stage the module for persistence
> A while back I talked with Monty & Peter about this #maglev_persistable method & IIRC they didn't think it was the best idea to actually use it.
> As Peter said, wrapping your code in a persistent_do block is preferred.
>
> Jesse, I really like the maglev_persistable because it doesn't require me to wrap all my ruby code. Now, I guess the better method would be to follow Peter's recommendation to use the -Mcomment option:
This deceptively simple example is actually getting a bit complex. My comment about --commit would apply to making SomeModule persistent. That's ok. But SomeModule is doing a lot of tricky things, and I'm not sure there all in the correct order (yet)! I haven't had time to really think this one through or run any code, but here are a couple of concerns I have:
1. You are doing "klass.extend ClassMethods" *before* you make klass persistent.
2. The klass.extend probably needs to in the persistent block
3. There is no check to see if klass is *already* persistent
4. There is no guarantee that all of klass's ancestors are persistent.
5. Looks like the self.maglev_persistable will mark SomeModule persistable *each* time it gets mixed in
Something like the following totally un-parsed, un-run, un-tested code might work better:
def self.included(klass)
Maglev.persistent do
klass.maglev_persistable
klass.extend ClassMethods
# etc.
end
# at this point, the persistence is staged, but not committed.
end
Stepping back a bit, I'm wondering whether the whole endeavour is too clever by half. Smalltalk is easy: *everything* is persistent. In MagLev, for better or worse, we decided that you'd have to explicitly manage persistent classes (the idea being not all code *should* be persistent). Persistence is a powerful hammer, but the MagLev team, with advice from the Smalltalk GreyBeards, thought it would be wise for only carefully selected classes to be persistent in MagLev (basically, your domain model...the things that would have been candidates for ActiveRecord: see https://github.com/MagLev/maglev/blob/master/docs/persistence-api.rdoc). Doing a bunch of Metaprogramming with persistence is wielding two very powerful swords... I'm not trying to say you shouldn't try what your doing, just that we hand't envisioned such potentially un-restrained application of persistence to classes. But its good to see people playing with MagLev, and perhaps we can work out the kinks here and we'll find it's a great combination!
--
Peter McLain
pmc...@vmware.com
Charles Monteiro
--
You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
To post to this group, send email to maglev-d...@googlegroups.com.
To unsubscribe from this group, send email to maglev-discuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maglev-discussion?hl=en.
Jesse Cooke
Peter McLain
On Nov 8, 2011, at 12:17 PM, Jesse Cooke wrote:
> Yeah. One way to think of persisting is multiple VMs can access the same code without explicitly loading it.
> On Tue, Nov 8, 2011 at 12:07 PM, Charles Monteiro <cha...@nycsmalltalk.org> wrote:
> So , newbie question again, persisting classes / modules is done for the purposes of making said behavior available i.e. server based (MagLev based) ?
There are at least two big reasons to persist code:
1. As Jesse said, a reason to persist classes is to get code loaded and shared across VMs.
2. Another reason is to get your *data* saved (your domain model). E.g., instead of persisting rows in a Customer table in MySQL, you can create a persistent Customer class (a plain-old ruby class), and you persist Customer objects. Along with those objects, will be the class and the behavior. It's just all OO modeling and no ORM mapping pain. You'll want to collect your customers into some collection, and probably index them for faster search (MagLev supports indexing, just like an RDBMS would). See https://github.com/MagLev/maglev/blob/master/examples/persistence/indexing/Indexing-README.rdoc
--
Peter McLain
pmc...@vmware.com
Charles Monteiro
What I'm hoping is that my experiences with Gemstone / S will help me get past the learning curb of MagLev i.e. how much of the design , how things work in general is based on Gemstone/ S ? i.e. do we think of application partitioning things in the same way,. also are there concepts such as forwarders, replicationSpecs, stubbing etc
How about the admin of MagLev ? Is that like Gemstone/ S ?
Where are the docs ?
Honestly, I'm starting to get a bit excited. Granted I rather still do most things in Smalltalk and with Gemstone / S , but to have access to something that works the same way-ish, has the same scaling properties etc with a language that is not half bad, gives me hope. Although I still think that overall Seaside is a better web framework than Rails , then again MagLev is not limited in its use to a specific presentation framework. But I ramble ...
Adrian Madrid
Jesse Cooke
How does it work? Let's say I persist a new copy of a class Person. Do all running VMs start using the new code automagically or do I need to restart those VMs?
aemadrid
Peter McLain
On Nov 8, 2011, at 12:45 PM, Charles Monteiro wrote:
> What I'm hoping is that my experiences with Gemstone / S will help me get past the learning curb of MagLev i.e. how much of the design , how things work in general is based on Gemstone/ S ? i.e. do we think of application partitioning things in the same way,. also are there concepts such as forwarders, replicationSpecs, stubbing etc
The underlying processes (stone, vm etc.) and architecture (shared page cache) are the same. Some of the details you mention (e.g., forwarders and in general the way Smalltalk deals with migration) are Smalltalk specific. See the api persistence doc in $MAGLEV_HOME/docs for more details on the differences between ruby and smalltalk here. You also have access to all of the Smalltalk objects too! See https://github.com/MagLev/maglev/blob/master/docs/ruby_and_smalltalk.rdoc
> How about the admin of MagLev ? Is that like Gemstone/ S ?
In fact, we recommend reading the GemStone/S docs for details on admin of the stone, vm etc. (http://maglev.github.com/docs/further_reading.html).
> Where are the docs ?
$MAGLEV_HOME/docs and we are starting to fill out the documentation section of http://maglev.github.com/ The examples directory has good stuff as well.
--
Peter McLain
pmc...@vmware.com
Charles A. Monteiro
object instances under a prior object schema (set of instVars )
Jesse Cooke
but how is schema migration handled ? i.e. you may have persisted
object instances under a prior object schema (set of instVars )
On Nov 8, 4:21 pm, aemadrid <aemad...@gmail.com> wrote:
> That makes sense. I can plan then when/where I want to get new releases of
> my (running) code.
--
You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
Conrad Taylor
Sent from my iPhone
On Nov 8, 2011, at 11:49 AM, Peter McLain <pmc...@vmware.com> wrote:
> Hi Conrad,
>
> I guess there is a bit of confusion (to which, I contributed).
>
> In your example, which module did not get persisted? My comment assumed that it was SomeModule that wasn't persisted. But your code also tries to persist any class the mixes in SomeModule, so I'm not sure which Module/Class is not getting persisted.
Peter, the SomeModule is not being persisted.
>
> For the code below to work, you'll certainly first need to ensure SomeModule is persisted, and that is NOT being done by the code below. (more comments below).
>
>> On Tue, Nov 8, 2011 at 11:08 AM, Jesse Cooke <je...@jc00ke.com> wrote:
>> On Tue, Nov 8, 2011 at 10:38 AM, Conrad Taylor <conr...@gmail.com> wrote:
>> Hey ALL, what the proper way to persist a ruby module? I was thinking that something like the following would do the job but appears that I'm missing something:
>>
>> module SomeModule
>>
>> module ClassMethods
>>
>> ...
>>
>> end
>>
>> def self.included( klass )
>>
>> klass.extend ClassMethods
>>
>> Maglev::PERSISTENT_ROOT[ klass ] = Hash.new
>>
>> klass.maglev_persistable # stage the class for persistence
>>
>> self.maglev_persistable # stage the module for persistence
>
>> A while back I talked with Monty & Peter about this #maglev_persistable method & IIRC they didn't think it was the best idea to actually use it.
>> As Peter said, wrapping your code in a persistent_do block is preferred.
>>
>> Jesse, I really like the maglev_persistable because it doesn't require me to wrap all my ruby code. Now, I guess the better method would be to follow Peter's recommendation to use the -Mcomment option:
>
> This deceptively simple example is actually getting a bit complex. My comment about --commit would apply to making SomeModule persistent. That's ok. But SomeModule is doing a lot of tricky things, and I'm not sure there all in the correct order (yet)! I haven't had time to really think this one through or run any code, but here are a couple of concerns I have:
>
> 1. You are doing "klass.extend ClassMethods" *before* you make klass persistent.
I was thinking that
> 2. The klass.extend probably needs to in the persistent block
> 3. There is no check to see if klass is *already* persistent
There are two possible cases here I believe:
1) I want to update a persistent class
or module.
2) I want to mixin a module into
another class or module.
Given the above to cases, what's the best way to do this?
> 4. There is no guarantee that all of klass's ancestors are persistent.
How does one make this guarantee?
> 5. Looks like the self.maglev_persistable will mark SomeModule persistable *each* time it gets mixed in
>
> Something like the following totally un-parsed, un-run, un-tested code might work better:
>
> def self.included(klass)
> Maglev.persistent do
> klass.maglev_persistable
> klass.extend ClassMethods
> # etc.
> end
> # at this point, the persistence is staged, but not committed.
> end
>
> Stepping back a bit, I'm wondering whether the whole endeavour is too clever by half. Smalltalk is easy: *everything* is persistent. In MagLev, for better or worse, we decided that you'd have to explicitly manage persistent classes (the idea being not all code *should* be persistent). Persistence is a powerful hammer, but the MagLev team, with advice from the Smalltalk GreyBeards, thought it would be wise for only carefully selected classes to be persistent in MagLev (basically, your domain model...the things that would have been candidates for ActiveRecord: see https://github.com/MagLev/maglev/blob/master/docs/persistence-api.rdoc).
Yes, I agree with you a 100%. I would like to persist data access objects or objects that are used for my data access layer.
> Doing a bunch of Metaprogramming with persistence is wielding two very powerful swords... I'm not trying to say you shouldn't try what your doing, just that we hand't envisioned such potentially un-restrained application of persistence to classes. But its good to see people playing with MagLev, and perhaps we can work out the kinks here and we'll find it's a great combination!
I'm playing with the ability to easily mixin Maglev by isolating it from the class that it is being mixed into. Just playing around.
-Conrad
>
> --
> Peter McLain
> pmc...@vmware.com
Charles Monteiro
Sent from my iPhone
> áI guess there is a bit of confusion (to which, I contributed).
>
> áIn your example, which module did not get persisted? áMy comment assumed that it was SomeModule that wasn't persisted. áBut your code also tries to persist any class the mixes in SomeModule, so I'm not sure which Module/Class is not getting persisted.
Peter, the SomeModule is not being persisted.
>
> áFor the code below to work, you'll certainly first need to ensure SomeModule is persisted, and that is NOT being done by the code below. á(more comments below).
>
>> On Tue, Nov 8, 2011 at 11:08 AM, Jesse Cooke <je...@jc00ke.com> wrote:
>> On Tue, Nov 8, 2011 at 10:38 AM, Conrad Taylor <conr...@gmail.com> wrote:
>> Hey ALL, what the proper way to persist a ruby module? áI was thinking that something like the following would do the job but appears that I'm missing something:
>>
>> module SomeModule
>>
>> ámodule ClassMethods
>>
>> á á...
>>
>> áend
>>
>> ádef self.included( klass )
>>
>> á áklass.extend ClassMethods
>>
>> á áMaglev::PERSISTENT_ROOT[ klass ] = Hash.new
>>
>> á áklass.maglev_persistable á# stage the class for persistence
>>
>> á áself.maglev_persistable á# stage the module for persistence
>
>> A while back I talked with Monty & Peter about this #maglev_persistable method & IIRC they didn't think it was the best idea to actually use it.
>> As Peter said, wrapping your code in a persistent_do block is preferred.
>>
>> Jesse, I really like the maglev_persistable because it doesn't require me to wrap all my ruby code. áNow, I guess the better method would be to follow Peter's recommendation to use the -Mcomment option:I was thinking that
>
> áThis deceptively simple example is actually getting a bit complex. áMy comment about --commit would apply to making SomeModule persistent. áThat's ok. áBut SomeModule is doing a lot of tricky things, and I'm not sure there all in the correct order (yet)! áI haven't had time to really think this one through or run any code, but here are a couple of concerns I have:
>
> á1. You are doing "klass.extend ClassMethods" *before* you make klass persistent.
> á2. The klass.extend probably needs to in the persistent block
> á3. There is no check to see if klass is *already* persistent
There are two possible cases here I believe:
1) I want to update a persistent class
á á or module.
2) I want to mixin a module into
á á another class or module.
Given the above to cases, what's the best way to do this?
> á4. There is no guarantee that all of klass's ancestors are persistent.
How does one make this guarantee?
> á5. Looks like the self.maglev_persistable will mark SomeModule persistable *each* time it gets mixed in
>
> Something like the following totally un-parsed, un-run, un-tested code might work better:
>
> á ádef self.included(klass)Yes, I agree with you a 100%. áI would like to persist data access objects or objects that are used for my data access layer.
> á á áMaglev.persistent do
> á á á áklass.maglev_persistable
> á á á áklass.extend ClassMethods
> á á á á# etc.
> á á áend
> á á á# at this point, the persistence is staged, but not committed.
> á áend
>
> Stepping back a bit, I'm wondering whether the whole endeavour is too clever by half. áSmalltalk is easy: *everything* is persistent. áIn MagLev, for better or worse, we decided that you'd have to explicitly manage persistent classes (the idea being not all code *should* be persistent). áPersistence is a powerful hammer, but the MagLev team, with advice from the Smalltalk GreyBeards, thought it would be wise for only carefully selected classes to be persistent in MagLev (basically, your domain model...the things that would have been candidates for ActiveRecord: see https://github.com/MagLev/maglev/blob/master/docs/persistence-api.rdoc).
I'm playing with the ability to easily mixin Maglev by isolating it from the class that it is being mixed into. áJust playing around.
> Doing a bunch of Metaprogramming with persistence is wielding two very powerful swords... I'm not trying to say you shouldn't try what your doing, just that we hand't envisioned such potentially un-restrained application of persistence to classes. áBut its good to see people playing with MagLev, and perhaps we can work out the kinks here and we'll find it's a great combination!
-Conrad
>
> --
> Peter McLain
> pmc...@vmware.com
>
>
>
>
> --
> You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
> To post to this group, send email to maglev-d...@googlegroups.com.
> To unsubscribe from this group, send email to maglev-discuss...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/maglev-discussion?hl=en.
>
--
You received this message because you are subscribed to the Google Groups "MagLev Discussion" group.
To post to this group, send email to maglev-d...@googlegroups.com.
To unsubscribe from this group, send email to maglev-discuss...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/maglev-discussion?hl=en.
Michael Latta
Jesse Cooke
In maglev you can run entirely with VM resident classes if you choose. If you persist data the classes need to be persistent. Not all your classes need to be. In a Rails app only the Model equivalent classes need be persistent. the controller and view classes would stay VM resident in most cases. There may be a reason to persist them to speed up VM startup or such but that would be an optimization for performance. Since there are no instances that live past a request there would be no other point. On the other hand you could attach view/controller objects to the session and move from a stateless to a statefull application which would be an interesting use case. Of course the part of Rails that creates new controller instances would need to be patched to look for one on the session, but being Rails where monkey patching is possible, and given that Rails 3 is much better structured where it may not even go that far, there are many options to play with if you choose.