Stepping through with GLORP Proxies
Does anybody else have issues while stepping through GLORP Proxy objects (collections in this case)? I simply can't use this feature unless the proxied collection was already materialized. I can't reproduce it right now, but it bites me everytime is step through blocks, because stepping into is really annoying :) Does anybody else have the same issue? This is Pharo 2. Esteban A. Maringolo
Does the Pharo debugger use the mirror primitives yet? Unless InstructionStream and ContextPart have been updated to use objectClass: and objectInstVarAt: et al then the debugger will be fooled by proxies. I really need to push this code through to Squeak trunk. Once I've done that (Monday? it's thanksgiving here and its party time :-) ) Pharo can perhaps adopt the code too. David, does the Interpreter support the mirror primitives yet? i.e. do the MirrorPrimitiveTests pass on the Interpreter now? On Fri, Nov 29, 2013 at 6:03 AM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Does anybody else have issues while stepping through GLORP Proxy objects (collections in this case)?
I simply can't use this feature unless the proxied collection was already materialized.
I can't reproduce it right now, but it bites me everytime is step through blocks, because stepping into is really annoying :)
Does anybody else have the same issue?
This is Pharo 2.
Esteban A. Maringolo
-- best, Eliot
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet?
No. I think the methods are not even in the image.
Unless InstructionStream and ContextPart have been updated to use objectClass: and objectInstVarAt: et al then the debugger will be fooled by proxies. I really need to push this code through to Squeak trunk. Once I've done that (Monday? it's thanksgiving here and its party time :-) ) Pharo can perhaps adopt the code too.
Yes. but I wonder who will do that. It will for sure be faster to get that into Pharo if someone (who is not me) submits it. Marcus
On Fri, Nov 29, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr>wrote:
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet?
No. I think the methods are not even in the image.
Unless InstructionStream and ContextPart have been updated to use objectClass: and objectInstVarAt: et al then the debugger will be fooled by proxies. I really need to push this code through to Squeak trunk. Once I've done that (Monday? it's thanksgiving here and its party time :-) ) Pharo can perhaps adopt the code too.
Yes. but I wonder who will do that. It will for sure be faster to get that into Pharo if someone (who is not me) submits it.
I'll either prepare a change set or submit. It'll get done. -- best, Eliot
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet? No. I think the methods are not even in the image.
I'll either prepare a change set or submit. It'll get done.
Thank you Eliot. I can continue stepping into until the change is ready. Please make it compatible with Pharo 2 (whatever that means in term of code) :) Best regards,
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet? No. I think the methods are not even in the image.
I'll either prepare a change set or submit. It'll get done.
Thank you Eliot.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term of
code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
Best regards,
-- best, Eliot
Hello, 2013/11/30 Eliot Miranda <eliot.miranda@gmail.com>
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet? No. I think the methods are not even in the image.
I'll either prepare a change set or submit. It'll get done.
Thank you Eliot.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term of
code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
http://files.pharo.org/image/20/ then the file named: Pharo-Image-2.0-latest.zip
Best regards,
-- best, Eliot
Hi eliot why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha. Stef On Nov 30, 2013, at 10:30 PM, Eliot Miranda <eliot.miranda@gmail.com> wrote:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote: 2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 1:06 PM, Marcus Denker <marcus.denker@inria.fr> wrote:
On 29 Nov 2013, at 22:03, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet? No. I think the methods are not even in the image.
I'll either prepare a change set or submit. It'll get done.
Thank you Eliot.
I can continue stepping into until the change is ready. Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
Best regards,
-- best, Eliot
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi eliot
why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha.
In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?). So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system. Regards, Esteban A. Maringolo
On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi eliot
why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha.
In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?).
Excellent news! Will you be able to tell us more because Pharo needs more visibility.
So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system.
I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect.
Regards,
Esteban A. Maringolo
One thing with Pharo 3.0 is that the debugger is quite different than it used to be. It is now split into a model (DebugSession + DebugContext) and the view, SpecDebugger. I don't know what Eliot does have to change but the new code may require some extra work due to the debugger being different. Now the new debugger is so much easier to understand and to edit that it shouldn't be an issue... 2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi eliot
why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha.
In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?).
Excellent news! Will you be able to tell us more because Pharo needs more visibility.
So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system.
I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect.
Regards,
Esteban A. Maringolo
On Sun, Dec 1, 2013 at 11:44 AM, Clément Bera <bera.clement@gmail.com>wrote:
One thing with Pharo 3.0 is that the debugger is quite different than it used to be.
It is now split into a model (DebugSession + DebugContext) and the view, SpecDebugger. I don't know what Eliot does have to change but the new code may require some extra work due to the debugger being different.
The code is all down at the level of ContextPart so I hope it won't affect the debugger changes at all.
Now the new debugger is so much easier to understand and to edit that it shouldn't be an issue...
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi eliot
why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha.
In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?).
Excellent news! Will you be able to tell us more because Pharo needs more visibility.
So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system.
I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect.
Regards,
Esteban A. Maringolo
-- best, Eliot
Ok then the latest Pharo 3 that you can find here: https://ci.inria.fr/pharo/job/Pharo-3.0-Update-Step-4-Publish/ is the best image for this fix. However being the bleeding edge this image is stable but might have some issues. 2013/12/2 Eliot Miranda <eliot.miranda@gmail.com>
On Sun, Dec 1, 2013 at 11:44 AM, Clément Bera <bera.clement@gmail.com>wrote:
One thing with Pharo 3.0 is that the debugger is quite different than it used to be.
It is now split into a model (DebugSession + DebugContext) and the view, SpecDebugger. I don't know what Eliot does have to change but the new code may require some extra work due to the debugger being different.
The code is all down at the level of ContextPart so I hope it won't affect the debugger changes at all.
Now the new debugger is so much easier to understand and to edit that it shouldn't be an issue...
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>
On Dec 1, 2013, at 6:11 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/12/1 Stéphane Ducasse <stephane.ducasse@inria.fr>:
Hi eliot
why in pharo 2.0? Do you have some specific scenario? Because it would be better to have it in Pharo 30 alpha.
In ten days I'll put a system into production (cross your fingers). It is built with Pharo 2 (what else?).
Excellent news! Will you be able to tell us more because Pharo needs more visibility.
So having this... will certainly help those who, like me, don't live in the bleeding edge. And will need to support (hence debug) a running system.
I tend not to rely on just introduced features even in 2.0 and also introducing something new can always have side effect.
Regards,
Esteban A. Maringolo
-- best, Eliot
Hi Eliot, 2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
I'm coming back late to this. Because the change wasn't integrated in Pharo 2. Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address? Thank you! Esteban A. Maringolo
Hi Esteban, find attached. Let me know of any problems. On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
Eliot, I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart. Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex' Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod' Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?). Esteban A. Maringolo 2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
find attached. Let me know of any problems.
On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
Hi Esteban, On Mon, Jun 23, 2014 at 11:45 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
Eliot,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod'
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
I'm sorry Esteban, but that is work for the Pharo consortium to do. My time is limited and I use Squeak. Esteban A. Maringolo
2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
find attached. Let me know of any problems.
On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term
of
code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
-- best, Eliot
2014-06-23 16:28 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
I'm sorry Esteban, but that is work for the Pharo consortium to do. My time is limited and I use Squeak.
That's totally understandable. I hope somebody from Pharo with enough internals knowledge will pick this up. GLORP is the only ORM we have in Pharo 3, and debugging objects being mapped can get really nasty. Regards! Esteban A. Maringolo
On 23 Jun 2014, at 16:49, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-06-23 16:28 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
I'm sorry Esteban, but that is work for the Pharo consortium to do. My time is limited and I use Squeak.
That's totally understandable.
sad, but understandable. in any case, it is a work for the pharo *community*, not for the consortium. things that would help: - an entry in the issue tracker - an explanation of the use case needed to solve - a pointer to Eliot modifications in squeak so the one who will do the job can take a look
I hope somebody from Pharo with enough internals knowledge will pick this up.
GLORP is the only ORM we have in Pharo 3, and debugging objects being mapped can get really nasty.
any other ORM you would do would use also proxies, so you would have the same problem :) is not a problem of GLORP but a problem in our support for proxies. Esteban
Regards!
Esteban A. Maringolo
2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
sad, but understandable. in any case, it is a work for the pharo *community*, not for the consortium. things that would help: - an entry in the issue tracker - an explanation of the use case needed to solve - a pointer to Eliot modifications in squeak so the one who will do the job can take a look
I added an entry to the issue tracker: https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger Which also refers back to this post, possibly causing an infinite recursion :)
I hope somebody from Pharo with enough internals knowledge will pick this up.
GLORP is the only ORM we have in Pharo 3, and debugging objects being mapped can get really nasty.
any other ORM you would do would use also proxies, so you would have the same problem :)
I know, but that doesn't make my statement false. :)
is not a problem of GLORP but a problem in our support for proxies.
What else uses this kind of proxies? Regards! Esteban A. Maringolo
What specific problem are you having debugging? Stepping Through a block which about to send message to a Proxy? It seems like I should be having the same problem with Magma proxies.. I know sometimes I would get a "Simulation" error while stepping Through (which would blow up a debugging session) but that may have been caused by something else because I don't remember seeing even that in a while.. I may be doing something different in my Proxy-reification process than Glorp which lets it work even without using mirror primitives (unless I'm using them without knowing it -- I'm not sure how they work or even what they are)..? On Mon, Jun 23, 2014 at 3:16 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
sad, but understandable. in any case, it is a work for the pharo *community*, not for the consortium. things that would help: - an entry in the issue tracker - an explanation of the use case needed to solve - a pointer to Eliot modifications in squeak so the one who will do the job can take a look
I added an entry to the issue tracker: https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger
Which also refers back to this post, possibly causing an infinite recursion :)
I hope somebody from Pharo with enough internals knowledge will pick this up.
GLORP is the only ORM we have in Pharo 3, and debugging objects being mapped can get really nasty.
any other ORM you would do would use also proxies, so you would have the same problem :)
I know, but that doesn't make my statement false. :)
is not a problem of GLORP but a problem in our support for proxies.
What else uses this kind of proxies?
Regards!
Esteban A. Maringolo
Hi Chris, On Jun 23, 2014, at 2:05 PM, Chris Muller <asqueaker@gmail.com> wrote:
What specific problem are you having debugging? Stepping Through a block which about to send message to a Proxy? It seems like I should be having the same problem with Magma proxies.. I know sometimes I would get a "Simulation" error while stepping Through (which would blow up a debugging session) but that may have been caused by something else because I don't remember seeing even that in a while..
I may be doing something different in my Proxy-reification process than Glorp which lets it work even without using mirror primitives (unless I'm using them without knowing it -- I'm not sure how they work or even what they are)..?
If you're using squeak 4.4 ish or later you're already using them. They're simply access to objects without sending messages and are used by the debugger to make sure eg inst vars are accessed without sending messages which will have weird effects if debugging proxy code.
On Mon, Jun 23, 2014 at 3:16 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-06-23 16:59 GMT-03:00 Esteban Lorenzano <estebanlm@gmail.com>:
sad, but understandable. in any case, it is a work for the pharo *community*, not for the consortium. things that would help: - an entry in the issue tracker - an explanation of the use case needed to solve - a pointer to Eliot modifications in squeak so the one who will do the job can take a look
I added an entry to the issue tracker: https://pharo.fogbugz.com/f/cases/13377/Mirror-primitives-in-Debugger
Which also refers back to this post, possibly causing an infinite recursion :)
I hope somebody from Pharo with enough internals knowledge will pick this up.
GLORP is the only ORM we have in Pharo 3, and debugging objects being mapped can get really nasty.
any other ORM you would do would use also proxies, so you would have the same problem :)
I know, but that doesn't make my statement false. :)
is not a problem of GLORP but a problem in our support for proxies.
What else uses this kind of proxies?
Regards!
Esteban A. Maringolo
Esteban I would like to know how different are the Glorp proxies from the ones of Mariano. Because we are thinking about to get by default a nice proxy system. Proxies in the sense of object representing one that is not in the system (and not proxies as metaobject or representing an object that is around as in the JS literature). Ideally I would like to unify both. Stef On 23/6/14 20:45, Esteban A. Maringolo wrote:
Eliot,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod'
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
Esteban A. Maringolo
2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
find attached. Let me know of any problems.
On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done. I can continue stepping into until the change is ready. Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please... I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
On 24/6/14 08:18, stepharo wrote:
Esteban
I would like to know how different are the Glorp proxies from the ones of Mariano. Because we are thinking about to get by default a nice proxy system. Proxies in the sense of object representing one that is not in the system (and not proxies as metaobject or representing an object that is around as in the JS literature). Ideally I would like to unify both.
Stef
On 23/6/14 20:45, Esteban A. Maringolo wrote:
Eliot,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod'
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
Esteban A. Maringolo
2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
find attached. Let me know of any problems.
On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done. I can continue stepping into until the change is ready. Please make it compatible with Pharo 2 (whatever that means in term of code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please... I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
Hi Stef, 2014-06-24 3:18 GMT-03:00 stepharo <stepharo@free.fr>:
Esteban
I would like to know how different are the Glorp proxies from the ones of Mariano. Because we are thinking about to get by default a nice proxy system. Proxies in the sense of object representing one that is not in the system (and not proxies as metaobject or representing an object that is around as in the JS literature). Ideally I would like to unify both.
There's nothing much special about GLORP proxies, and maybe Mariano knows better. They have a common superclass named "AbstractProxy" (no NS), and they work more like "remote references" than anything else. They are true proxies, it is, they hold a reference to the realobject, but no #become is involved in the process. Also proxies can "release" the referenced object and materialize it back when needed (according to the proxy strategy). Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns whether the referenced class is aClass (it is, aProxy isKindOf: Proxy "false"), #= and #hash causes materialization of the referenced object. Other than that I couldn't find anything else, it's a classical proxy, with some ORM related stuff. Regards!
On 24 Jun 2014, at 09:58, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Hi Stef,
2014-06-24 3:18 GMT-03:00 stepharo <stepharo@free.fr>:
Esteban
I would like to know how different are the Glorp proxies from the ones of Mariano. Because we are thinking about to get by default a nice proxy system. Proxies in the sense of object representing one that is not in the system (and not proxies as metaobject or representing an object that is around as in the JS literature). Ideally I would like to unify both.
There's nothing much special about GLORP proxies, and maybe Mariano knows better. They have a common superclass named "AbstractProxy" (no NS), and they work more like "remote references" than anything else.
They are true proxies, it is, they hold a reference to the realobject, but no #become is involved in the process. Also proxies can "release" the referenced object and materialize it back when needed (according to the proxy strategy).
Proxy>>#class returns Proxy, but Proxy>>#isKindOf: aClass returns whether the referenced class is aClass (it is, aProxy isKindOf: Proxy "false"), #= and #hash causes materialization of the referenced object.
Other than that I couldn't find anything else, it's a classical proxy, with some ORM related stuff.
yeah, thatâs why I said is not a problem of GLORP proxies but about our treatment of proxies in general :) Esteban
Regards!
On Mon, Jun 23, 2014 at 11:45 AM, Esteban A. Maringolo <emaringolo@gmail.com
wrote:
Eliot,
I never installed your proposed changes in a Pharo 3 image because there is a significant change in ContextPart. Your proposed changeset changes classVars of ContextPart.
Your proposal: classVariableNames: 'MaxLengthForASingleDebugLogReport MaxStackDepthForASingleDebugLogReport PrimitiveFailToken QuickStep ValueIndex'
Current vars: classVariableNames: 'PrimitiveFailToken QuickStep SpecialPrimitiveSimulators TryNamedPrimitiveTemplateMethod'
Obviously my change set was for Squeak, and the def above is for Pharo. So the two definitions need to be merged. Did you try the union of the class variable names?
Would you mind adapting your mirror methods changes to work also in Pharo 3 (and maybe in Pharo 4 too?).
Esteban A. Maringolo
2014-02-26 14:40 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
Hi Esteban,
find attached. Let me know of any problems.
On Wed, Feb 26, 2014 at 8:32 AM, Esteban A. Maringolo < emaringolo@gmail.com> wrote:
Hi Eliot,
2013-11-30 18:30 GMT-03:00 Eliot Miranda <eliot.miranda@gmail.com>:
On Fri, Nov 29, 2013 at 2:22 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2013/11/29 Eliot Miranda <eliot.miranda@gmail.com>:
I'll either prepare a change set or submit. It'll get done.
I can continue stepping into until the change is ready.
Please make it compatible with Pharo 2 (whatever that means in term
of
code) :)
OK, the code is now in Squeak trunk. What image should I use to integrate into Pharo 2? A url please...
I'm coming back late to this. Because the change wasn't integrated in Pharo 2.
Do you have the changeset applied to Squeak Trunk? I'd like to reapply it in my Pharo 2 image (at my own risk). Can you send it to may email address?
Thank you!
Esteban A. Maringolo
-- best, Eliot
-- best, Eliot
On 29 November 2013 21:02, Eliot Miranda <eliot.miranda@gmail.com> wrote:
Does the Pharo debugger use the mirror primitives yet? Unless InstructionStream and ContextPart have been updated to use objectClass: and objectInstVarAt: et al then the debugger will be fooled by proxies. I really need to push this code through to Squeak trunk. Once I've done that (Monday? it's thanksgiving here and its party time :-) ) Pharo can perhaps adopt the code too.
David, does the Interpreter support the mirror primitives yet? i.e. do the MirrorPrimitiveTests pass on the Interpreter now?
Obviously I'm not David, but http://build.squeak.org/job/SqueakTrunkOnInterpreter/329/testReport/Tests.Co... tells me that yes, they are passing on the Interpreter VM. frank
On Fri, Nov 29, 2013 at 6:03 AM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
Does anybody else have issues while stepping through GLORP Proxy objects (collections in this case)?
I simply can't use this feature unless the proxied collection was already materialized.
I can't reproduce it right now, but it bites me everytime is step through blocks, because stepping into is really annoying :)
Does anybody else have the same issue?
This is Pharo 2.
Esteban A. Maringolo
-- best, Eliot
On Fri, Nov 29, 2013 at 01:02:53PM -0800, Eliot Miranda wrote:
Does the Pharo debugger use the mirror primitives yet? Unless InstructionStream and ContextPart have been updated to use objectClass: and objectInstVarAt: et al then the debugger will be fooled by proxies. I really need to push this code through to Squeak trunk. Once I've done that (Monday? it's thanksgiving here and its party time :-) ) Pharo can perhaps adopt the code too.
David, does the Interpreter support the mirror primitives yet? i.e. do the MirrorPrimitiveTests pass on the Interpreter now?
Hi Eliot, Happy Thankgiving. Sorry I missed your question, but yes the mirror primitives are implemented in the interpreter VM: Name: VMMaker-dtl.262 Author: dtl Time: 5 January 2012, 12:41:29.745 am VMMaker 4.7.19 Reference Mantis 7429: Add Mirror Primitives to the VM Update primitivePerformInSuperclass to support ContextPart>>object:perform:withArguments:inClass: Implementation differs from that of oscog in that the original primitivePerformAt: is retained unmodified, and the necessary stack adjustments are done in primitivePerformInSuperclass for the special case of argumentCount 4 (mirror primitive call) rather than 3. The oscog approach may be prefered (not least for its clearer method naming), but making the change in primitivePerformInSuperclass is low risk and more easily implemented by a Sunday Squeaker. All MirrorPrimitiveTests pass. So it theory it should work ... Dave
On Fri, Nov 29, 2013 at 6:03 AM, Esteban A. Maringolo <emaringolo@gmail.com>wrote:
Does anybody else have issues while stepping through GLORP Proxy objects (collections in this case)?
I simply can't use this feature unless the proxied collection was already materialized.
I can't reproduce it right now, but it bites me everytime is step through blocks, because stepping into is really annoying :)
Does anybody else have the same issue?
This is Pharo 2.
Esteban A. Maringolo
-- best, Eliot
participants (7)
-
Chris Muller -
Clément Bera -
David T. Lewis -
Eliot Miranda -
Esteban A. Maringolo -
Esteban Lorenzano -
Frank Shearar -
Marcus Denker -
stepharo -
Stéphane Ducasse