[clam-devel] ipyclam: trouble with ProcessingConfigs

David García Garzón david.garcia at upf.edu
Fri May 27 02:47:11 PDT 2011


Xavi, Pau, you didn't notice but you were sending catalan bable to the list 
;-) I am not able to reproduce the error neither. It looks like typeid does 
not work as it should. Maybe a dangling library in testfarm. Who knows.

Xavi, i took a look to the setAttribute implementation and i see some flaws.
In order to choose the type you rely on the type of the new value. But if that 
value is not the correct one for the attribute you force the assignement which 
could lead to memory corruption.

The proper solution is to check first the attribute type, then check the value 
is of a compatible type, raising an exception if not, then setting the 
attribute.

if ( config.attributeType(index) == typeid(bool) )
{
	if (not PyBool_Check(value) )
		raise TypeError // Translate to C
	bool boolvalue = value==Py_True;
	config.setAttributeValue<bool>(index, boolvalue);
	return;
}

Code is starting to be quite repetitive for plain value types. We should 
consider to build a type plugin system like the one we have for configurators.
If you see that clear, just proceed. If not, no problem, proceed with 
remaining todos (keys(), type errors, key error at setter...).

Next, in order to check what attributes put in code() we should check whether 
they differ from the default. That's something we don't have in Dummy world so 
let's add it. The idea is that Configuration should be able to ask the 
(Clam/Dummy) ConfigurationProxy whether a value differs or not from the default 
value and, if it does, add the "net.proc.Param = Value" string to code().

In dummy, is quite straigh forward to implement as we have a reference to the 
default configuration. So building the code() part on top of that is quite 
simple. Then the clam implementation we just have to obtain a default 
constructed configuration of the same kind and compare. A crappy working 
implementation is good for start, we can latter optimize and clean things.



A Dijous 26 Maig 2011 23:50:24, Xavier Serra Román va escriure:
> No sé que se'm deu haver colat. Ara n'hi ha 3 més dels que diu al log i són
> tots en verd. M'esperaré a que faci el següent testeig a veure si continua
> fallant
> 
> Sorry
> 
> On May 26, 2011, at 11:46 PM, Pau Arumi wrote:
> > Ei Xavi, tenim testfarm en vermell per culpa de pyclam. Li faras una
> > ullada please?
> > 
> > > On May 26, 2011, at 10:52 PM, David García Garzón wrote:
> > > 
> > > Xavi, note that attributeValue is a const getter so you cannot use the
> > > returned reference to assign it. I suggest you add a new method:
> > > void setAttributeValue(unsigned i, const value_type & value)
> > > value_type & attribute =
> > > *(value_type *)_processingConfig->GetAttributeAsVoidPtr( i )
> > > attribute = value;
> > > so you can call:
> > > config.setAttributeValue<std::string>(unsigned i, value)
> > > 
> > > Worked like a charm. I didn't realize that attributeValue was a const
> > > method. Thanks!
> > > 
> > > 
> > > 
> > > A Dijous 26 Maig 2011 20:36:41, Xavier Serra Román va escriure:
> > > Hi guys..
> > > I have another issue. How do you set new values to a dynamictype
> > > attribute? I've seen clam code such as:
> > > ConcreteString & value = *(ConcreteString
> > > *)object.GetAttributeAsVoidPtr(attribute); value =
> > > input->toPlainText().toLocal8Bit().constData();
> > > 
> > > but in my code I do:
> > > std::string old = config.attributeValue<std::string>(i);
> > > old = value;
> > > with value being passed as const std::string& and attributeValue<type>
> > > being: *(type *)_processingConfig->GetAttributeAsVoidPtr( i )
> > > and nothing changes. What am I doing wrong?
> > > 
> > > Thanks!
> > > 
> > > PS: I hate pointers
> > > 
> > > On May 25, 2011, at 8:39 PM, Pau Arumi wrote:
> > > Check the Component interface. Maybe it is called Clone() or
> > > DeepCopy(). P
> > > 
> > > On May 25, 2011, at 7:48 PM, David García Garzón wrote:
> > > On Wednesday 25 May 2011 19:09:23 Xavier Serra Román wrote:
> > > Hi guys,
> > > I'm now at the part of ipyclam dealing with configurations and I've
> > > run into some trouble, I defined a c++ class to wrap into python
> > > with boost.python that holds a processingconfig.
> > > 
> > > I need to create the processingconfig in the class from a copy of
> > > another one so I've defined: ConfigurationProxy(const
> > > CLAM::ProcessingConfig & prototype)
> > > 
> > >      {
> > >      
> > >              _processingConfig = new CLAM::ProcessingConfig(prototype);
> > >      
> > >      }
> > > 
> > > this, obviously. doesn't work because abstract classes cannot be
> > > allocated but I don't know what else to do.
> > > 
> > > Use the Component::Species() virtual method. It is redefined in
> > > subclasses  (including ProcessinConfig's derivatives) in a way that
> > > it returns an object  of the same class than the receiver. Not a
> > > copy, just the default constructed  one.
> > > 
> > > How do you call it? I don't seem to be able to make it work, I've tried
> > > from prototype.Species() to
> > > CLAM::ProcessingConfig::Species(prototype)..
> > > 
> > > Be carefull on the code below, if you ned the default constructor (do
> > > you need  it?) initialize all the members.
> > > 
> > > Be also carefull with the copy constructor (generated by default).
> > > The default  copy constructor copies all members, in this case will
> > > copy the pointer and  you will double delete it on the destructor.
> > > This might happen not just in  assignments but also when passing it
> > > as parameter or returning not as  reference,  and it may not be you
> > > but maybe boost::python. So my suggestiong  is to implement it
> > > private and assert false inside, so, at least if  boost::python uses
> > > it you will be notified at compilation or runtime.
> > > 
> > > The complete code of the class is:
> > > class ConfigurationProxy
> > > {
> > > 
> > > public:
> > >      CLAM::ProcessingConfig * _processingConfig;
> > >      ConfigurationProxy() {}
> > >      ConfigurationProxy(const CLAM::ProcessingConfig & prototype)
> > >      {
> > >      
> > >              _processingConfig = new CLAM::ProcessingConfig(prototype);
> > >      
> > >      }
> > >      ~ConfigurationProxy()
> > >      {
> > >      
> > >              delete _processingConfig;
> > >      
> > >      }
> > > 
> > > };
> > > 
> > > Thanks!
> > > _______________________________________________
> > > clam-devel mailing list
> > > clam-devel at lists.clam-project.org<mailto:clam-devel at lists.clam-project.
> > > org>
> > > http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.
> > > org
> > > 
> > > _______________________________________________
> > > clam-devel mailing list
> > > clam-devel at lists.clam-project.org<mailto:clam-devel at lists.clam-project.
> > > org>
> > > http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org
> > 
> > <Archivo adjunto>  ATT00001.txt
> > 
> > 
> > _______________________________________________
> > clam-devel mailing list
> > clam-devel at lists.clam-project.org
> > http://lists.clam-project.org/listinfo.cgi/clam-devel-clam-project.org

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



More information about the clam-devel mailing list