[prev in list] [next in list] [prev in thread] [next in thread] 

List:       koffice-devel
Subject:    Re: compiling trunk - KoView/QPointer, Kross/Python
From:       Raphael Langerhorst <raphael.langerhorst () kdemail ! net>
Date:       2006-12-19 17:44:01
Message-ID: 200612191844.02062.raphael.langerhorst () kdemail ! net
[Download RAW message or body]

Am Dienstag, 19. Dezember 2006 13:33 schrieb Sebastian Sauer:
> Raphael Langerhorst wrote:
> > There is also another error related to python and kross in the way that
> > at least Py::AttributeError() and Py::TypeError() are not understood by
> > the compiler. I don't know python, but trying to fix it I came to the
> > impression that the parameter should name a type as a string literal, not
> > the error message text(??):
> >
> > [100%] Building CXX object
> > libs/kross/python/CMakeFiles/krosspython.dir/pythonextension.o
> > /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.c
> >pp: In
> >    member function `virtual Py::Object
> >    Kross::PythonExtension::getattr(const char*)':
> > /home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.c
> >pp:203: error: parse
> >    error before `.' token
> >
> > This is with NetBSD 3 (GCC 3.3.3) and Python 2.3.5 as well as latest
> > qt-copy, kdelibs, etc. - on amd64
> >
> > Any ideas how this can be fixed?
> >
> >
> > Attached patch is a suggestion for KoView and a question for the python
> > bindings. It is not meant to be committed the way it is (python bindings
> > need to be properly fixed first).
>
> Regarding;
>
> if(! property.isReadable()) {
> -            Py::AttributeError( QString("Attribute \"%1\" is not
> readable.").arg(n).toLatin1().constData() );
> +            QString tstr("Attribute \"");
> +            tstr.append(n);
> +            tstr.append(" is not readable.");
> +            QByteArray ba = tstr.toLatin1();
> +            char* string_data = ba.data();
> +            Py::AttributeError( string_data /* "Attribute is not
> readable." /* QString("Attribute \"%1\" is not
> readable.").arg(QString::number(n)).toLatin1().constData() */ );
>              return Py::None();
>          }
>
> That looks interessting. So, it is not possible to do something like
> QString().arg(n) where n is a char* ?

I think you can. Qt would make a QString of the given char and use this as 
parameter to arg() (AFAICS) - char* is an acceptable parameter to the QString 
constructor so its internally constructing one and passes that to arg().

The above verbosity was meant to track down the actual call that doesn't work 
(in gcc error+line output), but in fact everything up there worked fine 
except that "string_data" was an unknown type (whatever). So my assumption is 
that the argument to Py::AttributeError is not a normal argument.

If I use above code, I get the following output:

/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.cpp:208: 
error: conflicting
   types for `Py::AttributeError string_data'
/home/raphael/devel/KDE/trunk/koffice/libs/kross/python/pythonextension.cpp:207: 
error: previous
   declaration as `char*string_data'


line 207 is: char* string_data = ba.data();
line 208 is: Py::AttributeError( string_data );

so.... hmm... thinking about it I'm concluding that the parameter to 
Py::AttributeError is meant to be the variable name of the created 
AttributeError python object. Is this possible?

In which case it is nonsense to put the error description there, right? What 
role has the variable name of such a python object? Ultimately: what should 
be the parameter to Py::AttributeError and similar things ?

Does no one else have this compile error?

Regards,
Raphael

_______________________________________________
koffice-devel mailing list
koffice-devel@kde.org
https://mail.kde.org/mailman/listinfo/koffice-devel

[prev in list] [next in list] [prev in thread] [next in thread]