[clam-devel] --SPAM--:: Re: ConfigurationProxy: següent passa

[David García Garzón]

A Divendres 27 Maig 2011 16:37:09, Xavier Serra Román va escriure:
> On May 27, 2011, at 2:21 PM, David García Garzón wrote:
> > On Thursday 26 May 2011 22:33:34 Xavier Serra Román wrote:
> >> On May 26, 2011, at 10:13 PM, David García Garzón wrote:
> >>> Forwarded to the list, sorry, the original message from Xavi was in
> >>> catalan.
> >>> 
> >>> A Dijous 26 Maig 2011 18:22:17, Xavier Serra Román va escriure:
> >>>> Ei David!
> >>>> l'altre dia vam parlar del camí a seguir amb el configuration i vas
> >>>> dir Add, Removes... Amb això vols dir per exemple:
> >>>> proxy["new_attribute"] = 'newvalue' ?
> >>>> Fins ara sempre consideravem això com a AttributeError. I en cas
> >>>> afirmatiu, com es fa? He vist el AddAttr_ de la interfície de
> >>>> DynamicType però pren dos valors enters i és protected
> >>>> 
> >>>> Bye!
> >>> 
> >>> We should concentrate first in being able to do the same things that we
> >>> support right now with dummy: Plain type checked attributes but no
> >>> optionality (the add/remove thing you asked) and no composite
> >>> attributes. Looking at the source i still miss some features for the
> >>> clam config proxy:
> >>> - Errors on accessing wrong attribs should match the ones raised by
> >>> dummy - implement __setitem__ to set the config value.
> >>> - Error on type missmatch al __setitem__
> >>> - keys()
> >>> 
> >>> Once this is done, comparing dummy and clam tests they should be quite
> >>> uniform. We can postpone optional and composite attributes
> >>> implementation while going forward to something that it is usable yet,
> >>> that is, being able to inspect the configuration of an actual
> >>> processing inside a network and reconfiguring it. So lets consider how
> >>> to implement Clam_NetworkProxy::processingConfig, first to get the
> >>> actual
> >>> configuration, then to modify it (how to apply the configuration which
> >>> was a tricky issue).
> >> 
> >> Been thinking about that. What do you think of creating a function
> >> inside Clam_NetworkProxy that returns a ConfigurationProxy (something
> >> like the factory method we have inside Clam_ConfigurationProxy) and
> >> then pass that method to the Configuration python object? It should
> >> look something like
> >> 
> >> this (in the Processing.py __init__):
> >> 	self.__dict__["_config"] = Configuration.Configuration(
> >> 
> >> proxy.processingConfigProxy(processingType) )
> > 
> > It is not about the type, it is about the processing itself. you want the
> > processingConfigProxy to have access to the actual configuration values.
> > So the current interface should work. Just that what
> > proxy.processingConfig(name) should return is now a proxy (either dummy
> > or clam), not a dict.
> 
> I have some questions then. In clam proxy processingConfig should ask the
> processing for its config object and get the values from there right? How
> can I do that? I found no GetConfig() method in <CLAM/Network.hxx> or
> <CLAM/Processing.hxx>

Look twice. Processing::GetConfig() really exists. It returns a const reference 
to the base class you can then DeepCopy. Not sure how to get a default 
constructed one. I thought we had an Species() like method like we have for 
enums. We might need to add it.

> And the other question, how can I make processingConfig (clam proxy again)
> return a Clam_ConfigurationProxy? So far in all my attempts all I got was
> a class named Clam_ConfigurationProxy but without any of its methods
> implemented (just an empty Clam_ConfigurationProxy)

Not sure if i understood. What code did you tried?
Try with:

    const CLAM::ProcessingConfig & config = 
network.GetProcessing(processingName).GetConfig();
    return py::object(py::ptr(new ConfigurationProxy(config)));

Because the c++->python mapping for ConfigurationProxy definition should be 
loaded when doing that in Clam_NetworkProxy, you should call:
	import("Clam_ConfigurationProxy");
within the BOOST_PYTHON_MODULE(Clam_NetworkProxy) brakets.

This should work, but notice that there are some flaws to solve:
First, memory handling, we are doing a 'new' and i dont know whether it is 
deleted somewhere. Some traces to see how proxies are created and distroyed 
would be nice. Notice that every time you run net.myprocessing, a different 
processing wrapper is created, including the modification

Then there is the problem of setters besides not applying the configuration to 
the processing there seems to be some aliasing problems. That is, it seems 
that setting the configuration does not even affect the configuration object we 
create to manipulate. At this point i am not sure how to solve that.

Maybe the solution is keeping a reference to the processing inside the 
wrapper. Which also would allow to implement all the read only operations 
directly on the object returned by processing->GetConfig(), and creating the 
copy to implement the set applying the copy and deleting it within the same 
method. I see three use cases:
- A config that is not bound to a processing. (created by clone() or other 
means) It just holds the config. Modifications are applied just to the config 
object. (the one we are implementing now, but should be not the case when we 
get it from a processing)
- A config bound to a processing, modifications are directly applied to the 
processing configuring it every time we change an attribute.
- A config bound to a processing and a temporary config, which holds the 
modifications until explicitly applied.

I guess we need to discuss that further or take one implementation which 
works, and consider later other scenarios.


-- 
David García Garzón
(Work) david dot garcia at upf anotherdot edu
http://www.iua.upf.edu/~dgarcia