Darrell, Slavek, E, All,
I have spent the past few days attempting to work out a version neutral port
of superkaramba so that it will build on both python2 and python 3.3.3 systems.
I have done it -- I think... The patch is:
tdeutils-superkaramba-python2_004.diff
The easy version neutral changes needed are the following:
PyString_CheckExact -> PyBytes_CheckExact
PyString_FromString -> PyBytes_FromString
PyString_FromStringAndSize -> PyBytes_FromStringAndSize
PyInt_FromLong -> PyLong_FromLong
However, help to get the "karamba" module initialized properly in
karamba_python.cpp at 359 the new python 3 module initialization routine must be
used.
I have tried to followed: http://docs.python.org/3/howto/cporting.html under
the heading of "Module initialization and state" to include preprocessor checks
needed to accommodate python2 and python. Essentially for python 3, you must
define the karamba module with 'static struct PyModuleDef karambadef = {foo' and
then call 'PyModule_Create(&karambadef);' instead of calling
'Py_InitModule((char*)"karamba", karamba_methods);' To work with both python2
and python, preprocessor checks are included as follows:
New code:
struct module_state {
PyObject *error;
};
#if PY_MAJOR_VERSION >= 3
#define GETSTATE(m) ((struct module_state*)PyModule_GetState(m))
#else
#define GETSTATE(m) (&_state)
static struct module_state _state;
#endif
static PyObject *
error_out(PyObject *m) {
struct module_state *st = GETSTATE(m);
PyErr_SetString(st->error, "something bad happened in karamba_python.cpp");
return NULL;
}
<snip>
#if PY_MAJOR_VERSION >= 3
static int karamba_traverse(PyObject *m, visitproc visit, void *arg) {
Py_VISIT(GETSTATE(m)->error);
return 0;
}
static int karamba_clear(PyObject *m) {
Py_CLEAR(GETSTATE(m)->error);
return 0;
}
static struct PyModuleDef karambadef = {
PyModuleDef_HEAD_INIT,
"karamba",
NULL,
sizeof(struct module_state),
karamba_methods,
NULL,
karamba_traverse,
karamba_clear,
NULL
};
#define INITERROR return NULL
#else
#define INITERROR return
#endif
PyThreadState* KarambaPython::mainThreadState = 0;
KarambaPython::KarambaPython(const ThemeFile& theme, bool reloading):
pythonThemeExtensionLoaded(false), pName(0), pModule(0), pDict(0)
{
PyThreadState* myThreadState;
char pypath[1024];
getLock(&myThreadState);
// load the .py file for this .theme
PyRun_SimpleString((char*)"import sys");
//Add theme path to python path so that we can find the python file
snprintf(pypath, 1023, "sys.path.insert(0, '%s')", theme.path().ascii());
PyRun_SimpleString(pypath);
PyRun_SimpleString((char*)"sys.path.insert(0, '')");
PyImport_AddModule((char*)"karamba");
#if PY_MAJOR_VERSION >= 3
PyModule_Create(&karambadef);
#else
Py_InitModule((char*)"karamba", karamba_methods);
#endif
That's it. Then it builds on bleeding-edge arch without issue. Darrell, will
you try this patch and confirm that it works fine with python2. Then let's get a
few more eyes on it and if no objections, push it.
The patch is included below.
--
David C. Rankin, J.D.,P.E.
All,
We are working on a new web site design. Work is in progress. At
the moment I will share only that the new design looks great.
We would like some new Trinity screen shots.
Limitations:
* Must be from git (R14).
* No personal information exposed --- keep everything generic.
* No strange or unsual color combinations, no black or dark
backgrounds and wallpapers.
* Trinity apps only for these images. Certain free/libre non-
Trinity exceptions are acceptable, but only in the panel or desktop
icons.
* Screen shots from virtual machines must be full screen to appear
as a full desktop.
* Please remember we are advertising Trinity and not your desktop,
your 82 inch Jumbotron monitor, your conky talents, etc. :)
Requests:
* We need one primary classic desktop shot. This particular shot
must be a default desktop, such that all of the device icons appear
as well as the default wallpaper. Add one Trinity app, but do not
cover the default desktop elements. I am thinking the default
screen with the release notes (help handbook) and tooltips dialog.
* A couple more classic desktop shots that are not default.
* At least one traditional, "Look everybody, I have a dozen apps
open!" image.
Other screen shots are open to your liking within the previous
limitations.
Send all files to me through the list or directly.
More news about the new web site design soon to come.
Please forward this request to the user list. (Yeah, I know, I
should subscribe....)
Thank you!
Darrell
> What scope should it be declared in? When building with
>autotools, I do not experience this failure.
One idea is you are using a bleeding edge Python. Those Python
developers are like grocery store managers: they have to keep
changing the location of things to appear like they actually do
something constructive.
The tdeutils/superkaramba/src/meter_python.cpp file is the only
place I find the function PyString_CheckExact being used. The
meter_python.cpp has the following include:
#include <Python.h>
I have Python 2.7 installed. The Python.h header file has a bunch
of other header file includes, one of which PyString_CheckExact is
defined.
Perhaps look into where PyString_CheckExact is defined in your
version of Python. My guess is your version of Python.h no longer
contains an include where PyString_CheckExact is defined or perhaps
PyString_CheckExact has been replaced by a different function.
Just guessing.
The only thing certain in free/libre software is tomorrow somebody
upstream will break something that works today.
Darrell
>> Anybody else notice the following output spew when starting
>Amarok?
>> I traced the introduction of the bug to the first few days of
>Sept. 2013.
>No, all ok on my system. Just this:
>
>Amarok: [Loader] Starting amarokapp..
>Amarok: [Loader] Don't run gdb, valgrind, etc. against this
>binary! Use amarokapp.
>tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel
>= 0x93fa30 ): TDEAccel object already contains an action name
>"play_pause"
>tdecore (TDEAction): WARNING: TDEAction::insertTDEAccel( tdeaccel
>= 0x93fa30 ): TDEAccel object already contains an action name
>"play_pause"
Are you compiling with cmake or autotools? I am unable to build
with cmake.
Darrell
> I thought the kate sort plugin made it into the code. It isn't
>in kate in R14.
When all is said and done, more often than not more is said than
done. What you see is as far as the request developed.
Would be a nice addition.
Darrell
Slavek,
kaffeine is partially fixed to deal with the new paranoia/cdda.h and
paranoia/paranoia.h header locations. The fix to kaffeine/configure.in.in seems
OK. However, without a patch to 'kaffeine/kaffeine/configure.in.in' ./configure
fails to find the new headers and fails with:
checking cdio/cdda.h usability... no
checking cdio/cdda.h presence... no
checking for cdio/cdda.h... no
-----------------------------------------
ERROR: Could not find cdparanoia headers.
-----------------------------------------
configure: error: could not find cdparanoia headers
This check in 'kaffeine/kaffeine/configure.in.in is causing the failure:
dnl --------------------
dnl check for cdparanoia
dnl --------------------
KDE_CHECK_HEADER([cdio/cdda.h], [with_cdparanoia=yes], [with_cdparanoia=no])
if test "$with_cdparanoia" != "yes" ; then
echo ""
echo "-----------------------------------------"
echo "ERROR: Could not find cdparanoia headers."
echo "-----------------------------------------"
echo ""
AC_MSG_ERROR([could not find cdparanoia headers])
fi
This must be consitnt with the new 'kaffeine/configure.in.in' check of:
KDE_CHECK_HEADER(cdio/paranoia/cdda.h, [have_libcdio_090="yes"],
[have_libcdio_090="no"])
if test "x$have_libcdio_090" = "xyes"; then
AC_DEFINE(HAVE_LIBCDIO_090, 1, [have libcdio >= 0.90])
fi
Since that check fails I have to patch configure.in.in. Next, you (or
somebody) added preprocessor checks to
kaffeine/kaffeine/src/input/disc/paranoia.h at line 35 - line 36 is MISSING a
'/' after paranoia:
extern "C"
{
#ifdef HAVE_LIBCDIO_090
#include <cdio/paranoiacdda.h>
#include <cdio/paranoia/paranoia.h>
#else // HAVE_LIBCDIO_090
#include <cdio/cdda.h>
#include <cdio/paranoia.h>
#endif // HAVE_LIBCDIO_090
}
Should be:
extern "C"
{
#ifdef HAVE_LIBCDIO_090
#include <cdio/paranoia/cdda.h>
^^^^
Further, since configure.in.in is not fixed, the preprocessor checks do not
work after I patch configure.in.in... I still get build failures:
In file included from disc.h:39:0,
from disc.cpp:42,
from libkaffeinedisc_la.all_cpp.cpp:2:
paranoia.h:39:23: fatal error: cdio/cdda.h: No such file or directory
#include <cdio/cdda.h>
I've tried fixing each of the autofoo checks and defines, but I still get:
l_cpp.Tpo -c libkaffeinedisc_la.all_cpp.cpp -fPIC -DPIC -o
.libs/libkaffeinedisc_la.all_cpp.o
In file included from disc.h:39:0,
from disc.cpp:42,
from libkaffeinedisc_la.all_cpp.cpp:2:
paranoia.h:39:23: fatal error: cdio/cdda.h: No such file or directory
#include <cdio/cdda.h>
^
compilation terminated.
I've attached the latest patch I tried. I need help fixing it :(
--
David C. Rankin, J.D.,P.E.
Darrell, Calvin, Slavek,
I thought the kate sort plugin made it into the code. It isn't in kate in R14.
I thought Calvin made a plugin for TDE for it? Anybody recall anything about it?
--
David C. Rankin, J.D.,P.E.
>Although I foresee the counterarguments that will be provided in
>this regard, I want to make the following comment.
>
>The general response of any non-English-speaking low/medium level
>user, but usually unwelcome in English-speaking dev lists, is that
>translations should be in the main package or be a one of its
>dependences or at least a "recommend" (in the Debian package
>system jargon), because non-English-speaking novices find very
>frustrating to want to install a software (p. eg. k3b or
>kaffeine), find and install the package, and find it only in
>English - however much we may seem very normal to have to look for
>a additional package xxx-i18n or xxx-l10n or xxx-i18n-es or xxx-
>l10n-es (as Spanish example).
>
>As I comment and report as many bugs, should be given much more
>importance to translations in TDE. The 1232 bug is an example of
>how the lack of translation can make a desktop environment as
>unusable for non-English-speaking users.
>
>Cheer and thanks for all
I think i18n will receive attention after R14.0.0. At that time,
please be vocal to help ensure that happens. :)
Darrell
Slavek, Darrell,
tdeutils fails when built with cmake:
[ 96%] Building CXX object
superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o
cd /build/tde-tdeutils/src/build/superkaramba/src && /usr/bin/c++
-DHAVE_CONFIG_H -march=i686 -mtune=generic -O2 -pipe -fstack-protector
--param=ssp-buffer-size=4 -DQT_NO_ASCII_CAST -DQT_CLEAN_NAMESPACE -DQT_NO_STL
-DQT_NO_COMPAT -DQT_NO_TRANSLATION -DQT_THREAD_SUPPORT -D_REENTRANT -include
tqt.h -I/opt/tqt3/include -I/usr/include/tqt -DQT_NO_ASCII_CAST
-DQT_CLEAN_NAMESPACE -DQT_NO_STL -DQT_NO_COMPAT -DQT_NO_TRANSLATION
-DQT_THREAD_SUPPORT -D_REENTRANT -include tqt.h -I/build/tde-tdeutils/src/build
-I/build/tde-tdeutils/src/build/superkaramba/src
-I/build/tde-tdeutils/src/tdeutils/superkaramba/src -I/usr/include/python3.3m
-I/opt/trinity/include -I/opt/tqt3/include -I/usr/include/tqt -o
CMakeFiles/superkaramba.dir/meter_python.cpp.o -c
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp
In file included from
/build/tde-tdeutils/src/tdeutils/superkaramba/src/karamba.h:73:0,
from
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:17:
/build/tde-tdeutils/src/tdeutils/superkaramba/src/imagelabel.h:41:14: warning:
declaration 'class TDEIO::CopyJob' does not declare anything [enabled by default]
class TDEIO::CopyJob;
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function
'TQString PyString2TQString(PyObject*)':
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:96:33: error:
'PyString_CheckExact' was not declared in this scope
if (PyString_CheckExact(text))
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:98:41: error:
'PyString_AsString' was not declared in this scope
char* t = PyString_AsString(text);
^
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp: In function
'PyObject* TQString2PyString(TQString)':
/build/tde-tdeutils/src/tdeutils/superkaramba/src/meter_python.cpp:151:38:
error: 'PyString_FromString' was not declared in this scope
pyString = PyString_FromString("");
^
superkaramba/src/CMakeFiles/superkaramba.dir/build.make:973: recipe for target
'superkaramba/src/CMakeFiles/superkaramba.dir/meter_python.cpp.o' failed
What scope should it be declared in? When building with autotools, I do not
experience this failure.
--
David C. Rankin, J.D.,P.E.
>On my system i can use the right window key to do that.
>The very first time it seems to take a while. Can you confirm
>that? Perhaps a bug similar to the Alt+F1 one. New bug report?
I had to re-enable the keys on my laptop but the response is
immediate.
Now to find a way to replace that function without those keys. :(
Darrell