[clam-devel] ipyclam: trouble with ProcessingConfigs
Xavier Serra Román
xvr.serra at gmail.com
Fri May 27 03:27:13 PDT 2011
On May 27, 2011, at 11:47 AM, David García Garzón wrote:
> 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
I'll keep the conflicting tests commented untill we figure out more.
> .
>
> 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;
> }
Yes, I know. That is going to be the next step. First was setting attributes trusting
that the user passes the correct value, then making a test passing the incorrect
type and expecting an exception.
>
> 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