Some of you may have noticed that Pharo has removed or renamed "EventSensor" to "InputEventSensor". This causes a Warning to appear when installing Magma, that the extension methods applied to EventSensor will not be loaded.
These methods exist for transparency, so that *if* someone commits an object that refers to the Sensor global, it will not materialize a new Sensor instance in other clients, but rather refer directly to the existing global.
It's the same behavior as when a reference to Smalltalk, Processor, World, ActiveHand, Transcript or Compiler is committed / materialized.
Sigh. So, what to do about it?
a) let it be. Pharo users, press "Proceed" and be happy. b) remove this serialization behavior for Sensor. Most apps probably don't try to serialize it anyway.. But if they do... breakage! c) create a new branch of Magma for this and all future Pharo divergences. (Someone please volunteer!)
Suggestions?
- Chris
2009/11/10 Chris Muller asqueaker@gmail.com:
Some of you may have noticed that Pharo has removed or renamed "EventSensor" to "InputEventSensor". This causes a Warning to appear when installing Magma, that the extension methods applied to EventSensor will not be loaded.
These methods exist for transparency, so that *if* someone commits an object that refers to the Sensor global, it will not materialize a new Sensor instance in other clients, but rather refer directly to the existing global.
It's the same behavior as when a reference to Smalltalk, Processor, World, ActiveHand, Transcript or Compiler is committed / materialized.
Sigh. So, what to do about it?
a) let it be. Pharo users, press "Proceed" and be happy. b) remove this serialization behavior for Sensor. Most apps probably don't try to serialize it anyway.. But if they do... breakage! c) create a new branch of Magma for this and all future Pharo divergences. (Someone please volunteer!)
Suggestions?
Chris, does Magma has facility, where i could tell: if you encounter some concrete object to be stored in DB, please throw an error?
I think that Magma should not care directly about special objects, like Processor or Sensor, but it would be cool to have an option to tell Magma that given reference should not be serialized, but instead use a specified message send (or something similar) for restoring reference back when deserializing an object from DB, which having such reference. So, for example, then i could tell that to reify a reference to Sensor global, magma should send 'Smalltalk at: #Sensor'.
Concerning branches, then you would need only a small platform-specific package, which registering a set of objects, during db initialization, to be (de)serialized in such way .
- Chris _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
m On 10 Nov 2009, at 20:02, Igor Stasenko wrote:
2009/11/10 Chris Muller asqueaker@gmail.com:
Some of you may have noticed that Pharo has removed or renamed "EventSensor" to "InputEventSensor". This causes a Warning to appear when installing Magma, that the extension methods applied to EventSensor will not be loaded.
These methods exist for transparency, so that *if* someone commits an object that refers to the Sensor global, it will not materialize a new Sensor instance in other clients, but rather refer directly to the existing global.
It's the same behavior as when a reference to Smalltalk, Processor, World, ActiveHand, Transcript or Compiler is committed / materialized.
Sigh. So, what to do about it?
a) let it be. Pharo users, press "Proceed" and be happy. b) remove this serialization behavior for Sensor. Most apps probably don't try to serialize it anyway.. But if they do... breakage! c) create a new branch of Magma for this and all future Pharo divergences. (Someone please volunteer!)
Suggestions?
Break out the extensions into pharo extensions and squeak extensions.
What I did plan to do was to start a pharo/squeak compatability project as part of LPF. If you use level playing field to load Magma, then LPF will have loaded the compatibility items in as needed.
regards
Keith
Hi Keith, I'm glad to see your presence again..!
Yes, I would be willing to have someone incorporate LPF or other "platform-packages" as Igor suggested into the mainline Magma, delegating to them appropriately, as long as they didn't get too big and/or confusing..
But here's the thing. I believe "energy to do something" comes out of this or any volunteer community only when a volunteer is motivated by their own agenda. Therefore, I hope this work will eventually be picked up by someone like Stuart, Miguel, yourself, or anyone else who is motivated enough by a Pharo project to do the work. I have a _mountain_ of other work besides Magma right now, and since my trajectory is along the Squeak path at this time, that's where I find my energy to be fully allocated at this time.
The other problem is "value for the effort". For now I think Squeak and Pharo are compatible-enough that Magma is able to maintain one single code-base that can be loaded and used in either..
Regards, Chris
On Tue, Nov 10, 2009 at 5:31 PM, keith keith_hodges@yahoo.co.uk wrote:
m On 10 Nov 2009, at 20:02, Igor Stasenko wrote:
2009/11/10 Chris Muller asqueaker@gmail.com:
Some of you may have noticed that Pharo has removed or renamed "EventSensor" to "InputEventSensor". This causes a Warning to appear when installing Magma, that the extension methods applied to EventSensor will not be loaded.
These methods exist for transparency, so that *if* someone commits an object that refers to the Sensor global, it will not materialize a new Sensor instance in other clients, but rather refer directly to the existing global.
It's the same behavior as when a reference to Smalltalk, Processor, World, ActiveHand, Transcript or Compiler is committed / materialized.
Sigh. So, what to do about it?
a) let it be. Pharo users, press "Proceed" and be happy. b) remove this serialization behavior for Sensor. Most apps probably don't try to serialize it anyway.. But if they do... breakage! c) create a new branch of Magma for this and all future Pharo divergences. (Someone please volunteer!)
Suggestions?
Break out the extensions into pharo extensions and squeak extensions.
What I did plan to do was to start a pharo/squeak compatability project as part of LPF. If you use level playing field to load Magma, then LPF will have loaded the compatibility items in as needed.
regards
Keith _______________________________________________ Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org