Hi!
As Chris knows we need sequence numbers in Gjallar. Chris implemented #serverPerform:withArguments: but I admit being slightly stumped with it.
I think the idea is that you add methods to MagmaRepositoryController like for example:
q2CounterInitialize: anId | sess counter | counter := 0. sess := self session. sess cacheAt: anId put: counter. ^sess commit: [ sess root environment at: anId put: counter ]
q2CounterNext: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId put: (sess root environment at: anId) + 1]
q2CounterValue: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId ]
...and then we call them, right? Soo... today I ended up getting errors about serialization:
"MaMalformedRequestError: No createProxyBlock specified. See MaObjectSerializer>>toCreateProxies:"
Aha... I think I realized this now - the id above is a UUID but we are sending a MaMutatingProxy instead. So I added just a little call like "{id yourself}" to make sure it gets faulted - and then it seems to work.
regards, Göran
Thanks for the report Göran. Good debugging, another option would be to employ a ReadStrategy to ensure the UUID is dereferenced in the original server call.
This never came up because serverPerform: was added solely for this purpose (sequence # generators), and a proxy would never be part of any of the other requests. Still, you've piqued my curiousity whether Magma could make this invisible for you.
Regards, Chris
On Tue, Nov 18, 2008 at 4:26 PM, Göran Krampe goran@krampe.se wrote:
Hi!
As Chris knows we need sequence numbers in Gjallar. Chris implemented #serverPerform:withArguments: but I admit being slightly stumped with it.
I think the idea is that you add methods to MagmaRepositoryController like for example:
q2CounterInitialize: anId | sess counter | counter := 0. sess := self session. sess cacheAt: anId put: counter. ^sess commit: [ sess root environment at: anId put: counter ]
q2CounterNext: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId put: (sess root environment at: anId) + 1]
q2CounterValue: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId ]
...and then we call them, right? Soo... today I ended up getting errors about serialization:
"MaMalformedRequestError: No createProxyBlock specified. See MaObjectSerializer>>toCreateProxies:"
Aha... I think I realized this now - the id above is a UUID but we are sending a MaMutatingProxy instead. So I added just a little call like "{id yourself}" to make sure it gets faulted - and then it seems to work.
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
2008/11/22 Chris Muller asqueaker@gmail.com:
Thanks for the report Göran. Good debugging, another option would be to employ a ReadStrategy to ensure the UUID is dereferenced in the original server call.
This never came up because serverPerform: was added solely for this purpose (sequence # generators), and a proxy would never be part of any of the other requests. Still, you've piqued my curiousity whether Magma could make this invisible for you.
I think its quite possible, since you anyways need to serialize requests to server - if you discover a proxy, you can reify it , or maybe just serialize its ID without need in reifying it on client side, which is much faster.
Regards, Chris
On Tue, Nov 18, 2008 at 4:26 PM, Göran Krampe goran@krampe.se wrote:
Hi!
As Chris knows we need sequence numbers in Gjallar. Chris implemented #serverPerform:withArguments: but I admit being slightly stumped with it.
I think the idea is that you add methods to MagmaRepositoryController like for example:
q2CounterInitialize: anId | sess counter | counter := 0. sess := self session. sess cacheAt: anId put: counter. ^sess commit: [ sess root environment at: anId put: counter ]
q2CounterNext: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId put: (sess root environment at: anId) + 1]
q2CounterValue: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId ]
...and then we call them, right? Soo... today I ended up getting errors about serialization:
"MaMalformedRequestError: No createProxyBlock specified. See MaObjectSerializer>>toCreateProxies:"
Aha... I think I realized this now - the id above is a UUID but we are sending a MaMutatingProxy instead. So I added just a little call like "{id yourself}" to make sure it gets faulted - and then it seems to work.
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi sig,
I think its quite possible, since you anyways need to serialize requests to server - if you discover a proxy, you can reify it , or maybe just serialize its ID without need in reifying it on client side, which is much faster.
Just to clarify, there are two sets of serializers on each of the client and server. One serializer converts buffers in the repository to and from buffers and objects, the other converts *requests and responses* to and from buffers and objects. Never the two should cross, which reminds me, Göran, that, although not explicitly necessary, it would be good form to *copy* the UUID you pass in the request, just so it is its own object. This would, in fact, have the beneficial side-effect of reifying it and avoiding the problem you had in the first place.
So requests and responses are fully serialized object trees, never expected to have any proxies whatsoever. If there is a proxy in a request I consider it a bug. This is also the reason you cannot simply reference the proxy by oid in the referencing buffer, the TcpRequestServer is generic, it does not know anything about Magma, and will not go looking into any repository for what object it is.
- Chris
On Fri, Nov 21, 2008 at 8:00 PM, Igor Stasenko siguctua@gmail.com wrote:
2008/11/22 Chris Muller asqueaker@gmail.com:
Thanks for the report Göran. Good debugging, another option would be to employ a ReadStrategy to ensure the UUID is dereferenced in the original server call.
This never came up because serverPerform: was added solely for this purpose (sequence # generators), and a proxy would never be part of any of the other requests. Still, you've piqued my curiousity whether Magma could make this invisible for you.
I think its quite possible, since you anyways need to serialize requests to server - if you discover a proxy, you can reify it , or maybe just serialize its ID without need in reifying it on client side, which is much faster.
Regards, Chris
On Tue, Nov 18, 2008 at 4:26 PM, Göran Krampe goran@krampe.se wrote:
Hi!
As Chris knows we need sequence numbers in Gjallar. Chris implemented #serverPerform:withArguments: but I admit being slightly stumped with it.
I think the idea is that you add methods to MagmaRepositoryController like for example:
q2CounterInitialize: anId | sess counter | counter := 0. sess := self session. sess cacheAt: anId put: counter. ^sess commit: [ sess root environment at: anId put: counter ]
q2CounterNext: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId put: (sess root environment at: anId) + 1]
q2CounterValue: anId | sess | sess := self session. ^sess commit: [ sess root environment at: anId ]
...and then we call them, right? Soo... today I ended up getting errors about serialization:
"MaMalformedRequestError: No createProxyBlock specified. See MaObjectSerializer>>toCreateProxies:"
Aha... I think I realized this now - the id above is a UUID but we are sending a MaMutatingProxy instead. So I added just a little call like "{id yourself}" to make sure it gets faulted - and then it seems to work.
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
-- Best regards, Igor Stasenko AKA sig.
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
Hi again!
Chris Muller wrote:
Thanks for the report Göran. Good debugging, another option would be to employ a ReadStrategy to ensure the UUID is dereferenced in the original server call.
Right, I need to look into readstrategies again - it seems we have ours disabled right now.
This never came up because serverPerform: was added solely for this purpose (sequence # generators), and a proxy would never be part of any of the other requests. Still, you've piqued my curiousity whether Magma could make this invisible for you.
I was also going nuts trying to debug another (turned out very similar) issue where we send #respondsTo: to a proxy. We got false but then I realized we only got false *the first time* (restarting in debugger made it answer true and thus I immediately started suspecting proxies) but I was still totally confused because the Magma DNU code looked perfectly fine.
Then I realized the problem was not the *receiver* - it was (probably) the argument - the symbol. I think it happens to be a proxy... I haven't finished this little adventure yet - I am fairly sure it is because the argument is a proxy and the method dict lookup fails somehow because of that. I will try to establish this.
regards, Göran
There are two rules for proxies:
- avoid sending an inlined message to proxies (i.e., #==) - avoid sending a proxy as an argument to a primitive
ReadStrategies are the main tool provided to abide these rules.
There is an option, #debugProxies, which can help in that it won't allow the printString to reify the proxy.
Keith Hodges also did some work, now included in the base Magma package that, when this is turned on, when you explore a tree of objects it will initially show them as proxies (just the first time).
I see that MaMutatingProxy reponds to #respondsTo:. This may be from Keith, make sure this isn't the one causing your pain..
Regards, Chris
On Sat, Nov 22, 2008 at 3:32 AM, Göran Krampe goran@krampe.se wrote:
Hi again!
Chris Muller wrote:
Thanks for the report Göran. Good debugging, another option would be to employ a ReadStrategy to ensure the UUID is dereferenced in the original server call.
Right, I need to look into readstrategies again - it seems we have ours disabled right now.
This never came up because serverPerform: was added solely for this purpose (sequence # generators), and a proxy would never be part of any of the other requests. Still, you've piqued my curiousity whether Magma could make this invisible for you.
I was also going nuts trying to debug another (turned out very similar) issue where we send #respondsTo: to a proxy. We got false but then I realized we only got false *the first time* (restarting in debugger made it answer true and thus I immediately started suspecting proxies) but I was still totally confused because the Magma DNU code looked perfectly fine.
Then I realized the problem was not the *receiver* - it was (probably) the argument - the symbol. I think it happens to be a proxy... I haven't finished this little adventure yet - I am fairly sure it is because the argument is a proxy and the method dict lookup fails somehow because of that. I will try to establish this.
regards, Göran
Magma mailing list Magma@lists.squeakfoundation.org http://lists.squeakfoundation.org/mailman/listinfo/magma
magma@lists.squeakfoundation.org