Code Reloading

[Steven R. Baker]

Heya,

I'm having some issues with code reloading. When I run my tests in persistent mode (this is closer to what I want than transient mode), and make a change to a class, the changes are not reflected.

I'm assuming there's some kind of shortcut built in to require? How do I force a code reload? (I understand there are related issues, and I'll deal with those later).

Currently I'm simply reloading my stone when I change code, and it's annoying.

Thanks!

-Steven

[Jesse Cooke]

-Mcommit will commit from the command line, which should do what you want it to do (essentially wraps your script in a persistent_do block & commits just after)

What changes are you making to your classes? Adding, changing, or removing methods/attrs?

--------------------------------------------
Jesse Cooke :: N-tier Engineer
jc00ke.com / @jc00ke

-Steven

--
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.

[Steven R. Baker]

On Tuesday, 15 January, 2013 at 4:12 PM, Jesse Cooke wrote:

-Mcommit will commit from the command line, which should do what you want it to do (essentially wraps your script in a persistent_do block & commits just after)

I'll look at this. Thanks!

What changes are you making to your classes? Adding, changing, or removing methods/attrs?

Yes. I know there are likely other issues with this; I'm going to have to work out some small, repeatable examples of the things I'm running into.

-Steven

[Tim Felgentreff]

Thanks for telling us about this. We're working on something akin to Rails migrations, but for classes and all persistent objects that you have in MagLev. It's still in planning, but we'll definitely get to it.

---

From: Steven R. Baker
Sent: 15/01/2013 21:20
To: maglev-d...@googlegroups.com
Subject: Re: [maglev-discussion] Code Reloading

[Monty Williams]

Examples will definitely help come up with solutions. 

Persistence is like _really_ persistent -- by reachability. Getting rid of an object so it can be garbage collected means eliminating all persistent references. It's also possible for objects to hold on to old class references. At least it's easy to figure that out programmatically since objects have an actual identity.

I was curious about your need for multiple stones. Was it for multiple apps that don't share any data? Isolation? Would logging in as a different user possibly help? Or performance/scalability?  Note that multiple VMs should consume multiple cores. 

-- Monty

[Steven R. Baker]

Examples will definitely help come up with solutions. 

Persistence is like _really_ persistent -- by reachability. Getting rid of an object so it can be garbage collected means eliminating all persistent references. It's also possible for objects to hold on to old class references. At least it's easy to figure that out programmatically since objects have an actual identity.

This is what we want. We are going to have to come up with a way to get old instances of objects migrated to their new definitions, though… But we'll burn that bridge when we get to it, I guess.

I was curious about your need for multiple stones. Was it for multiple apps that don't share any data? Isolation? Would logging in as a different user possibly help? Or performance/scalability?  Note that multiple VMs should consume multiple cores. 

The short answer is isolation. What I had in mind was one per "environment" in the Rails sense of the term. So when I'm running my tests, it doesn't mess with data that I need for other purposes.

-Steven

[Nicco Kunzmann]

Hello,

I am from the bachelor's project team at HPI, Germany. We are working on MaglevRecord. MaglevRecord is supposed to replace ActiveRecord with a persistance layer powered by Maglev. One part of this is thinking about how migrations could work.

Have you written any migration code yet? Any code that keeps your classes up to date with your source code? It would be great if you could share it with us, if possible. Just mail to niccok...@gmail.com or paste a link or code in our issue at MigrationExample.

Currently we think about what migrations could look like, strongly influenced by Rails. [implementation]
Also about how migrations may work in MagLev. [implementation]

We would like to use your knowledge to improve MaglevRecord.

Nicco


Links:

��� MaglevRecord
��� MaglevRecord Wiki
��� Tracker for your ideas and code
��� For questions feel free to respond to me or on the mailing list.

On 01/16/2013 03:15 AM, Steven R. Baker wrote:

Examples will definitely help come up with solutions.�

Persistence is like _really_ persistent -- by reachability. Getting rid of an object so it can be garbage collected means eliminating all persistent references. It's also possible for objects to hold on to old class references. At least it's easy to figure that out programmatically since objects have an actual identity.

This is what we want. We are going to have to come up with a way to get old instances of objects migrated to their new definitions, though� But we'll burn that bridge when we get to it, I guess.

I was curious about your need for multiple stones. Was it for multiple apps that don't share any data? Isolation?�Would logging in as a different user possibly help?�Or performance/scalability?��Note that multiple VMs should consume multiple cores.�

The short answer is isolation. What I had in mind was one per "environment" in the Rails sense of the term. So when I'm running my tests, it doesn't mess with data that I need for other purposes.

-Steven

-- Monty

On Jan 15, 2013, at 12:20 PM, "Steven R. Baker" <ste...@stevenrbaker.com> wrote:

On Tuesday, 15 January, 2013 at 4:12 PM, Jesse Cooke wrote:

-Mcommit will commit from the command line, which should do what you want it to do (essentially wraps your script in a persistent_do block & commits just after)

I'll look at this. Thanks!

What changes are you making to your classes? Adding, changing, or removing methods/attrs?

Yes. I know there are likely other issues with this; I'm going to have to work out some small, repeatable examples of the things I'm running into.

-Steven

�

--------------------------------------------
Jesse Cooke ::�N-tier Engineer
jc00ke.com�/ @jc00ke

[Monty Williams]

Steven,

We had a good discussion with the HPI team on migrations this morning. They're interested in your use case and any problems you hit.

There are some GS/S methods that may be of use in the section "Finding Instances and References" starting on page 214 of the GS/S-64 3.1 Programming Guide available at http://community.gemstone.com/display/GSS64/GemStoneS+64+Documentation

but we haven't really developed best practices for MagLev applications.

I'd expect you'd see some interesting startup times if you persisted an entire Rails app -- but that could expose other tough problems, though.

Multiple stones sounds like a good way to prevent test results from polluting real data. "maglev force-reload" is a shortcut to disposing of $STONENAME - read the bin/maglev script to make sure it's not overkill.

-- Monty

[Jesse Cooke]

I talked with Peter about persisting an entire Rails app & he said Rails maintains some open file descriptors that would prevent it from being persisted.

Sinatra, on the other hand... not sure.

[Monty Williams]

That's one of the problems persisting apps that weren't designed for it. Sockets too. Maybe MagLev  could be made to simply ignore those. 

-- Monty

Sent from my iPhone

[Dale Henrichs]

In Seaside we had a similar problem with Semaphores, so I created a TransientSemaphore class to wrap the semaphore instances. In a TransientSemaphore class, the instance can be persisted (so the reference is maintained) but none of the instance variables are persisted so the semaphore itself was never shared ...

I did have to arrange for the transient instance to be recreated in a new session, but for semaphores there was no additional state needed ... For sockets, you may need some additional logic to recreate correctly in the new session ...

Dale

----- Original Message -----
| From: "Monty Williams" <monty.w...@gmail.com>
| To: maglev-d...@googlegroups.com
| Sent: Thursday, January 17, 2013 9:01:29 PM
| Subject: Re: [maglev-discussion] Code Reloading
|
|