superkaramba: fixed SEGV when loading python scripts. #44
Merged
MicheleC
merged 2 commits from fix/issue/43/superkaramba-segv
into master
1 year ago
Loading…
Reference in new issue
There is no content yet.
Delete Branch 'fix/issue/43/superkaramba-segv'
Deleting a branch is permanent. It CANNOT be undone. Continue?
Needs testing with python < 3.7 due to changes in API from version 3.7.
This resolves issue #43.
76bfc28b3f
toc465f60e58
1 year agoI tried to build on Debian 9.x (Stretch) – that's Python 3.5.x and it leads to FTBFS:
c465f60e58
tof61073a409
1 year agoI pushed an updated version.
Py_FinalizeEx
is not available prior to 3.6, so I reverted to the originalPy_Finalize
form.Great, now build is successful also on Python 3.5.x.
Comparing with KDE 3.5.10 on Lenny with python 2, it looks like this fix is not enough. Back to the workboard ;-)
superkaramba: fixed SEGV when loading python scripts.to WIP: superkaramba: fixed SEGV when loading python scripts. 1 year agoMicheleC referenced this pull request 1 year agof61073a409
to5dab6232ef
1 year agoI have pushed an updated commit that seems to solve the issues with superkaramba and python3. Python scripts in examples will need to be modified from python 2 to python 3, but I will work on those in coming days. In the meantime it would be good to test this in other older distros to see if there is any issue with it.
Uploaded first batch of converted examples to help testing.
9cd8533e12
to3ac0a96fbb
1 year agoWIP: superkaramba: fixed SEGV when loading python scripts.to superkaramba: fixed SEGV when loading python scripts. 1 year agoExamples converted to python3.
PR ready for review and merge.
Below are some notes for checking and decisions.
In addition, in the
examples/autoHide/main.py
file is the occurrence ofprint "Loaded my python extension!"
that needs adjustment for compatibility with Python3. The same would be good to do also inexamples/template.py
.Next to this here is the idea of adding a build of
xcursor.so
to CMake rules to ensure that it will be ready for the current system.pass
#This gets called everytime our widget is clicked.
#Notes
Is there any reason that this comment is reduced? I know that in this particular example of values are not essential, but I assume that the comment here fulfills the educational purpose.
That comment was wrong, it referred to the
mouseClick
event which is above this comment. You can see at line 22 that there is the same comment.Instead at line 36 there is the
mouseMove
event, so I have updated the comment to refer to the right event.Oh, I understand, I didn't look at it in detail. So your adjustment makes sense.
#print xp, yp
xp = xp - rp_width // 2
yp = yp - rp_height // 2
#print xp, yp
Although these occurrences are in the note, it would be good for the code to be updated for compatibility with Python3. Here are more such cases in this file.
Good point, those were not converted automatically by the 2to3 script. I have checked also the other examples.
for image in taskPanels:
karamba.hideImage(widget, image)
#for image in taskPanels:
# karamba.hideImage(widget, image)
I didn't do a test, but I am surprised that this code is postponed?
ah, I forgot to uncomment this. My bad.
3ac0a96fbb
toda9cd0c056
1 year agoLatest commit addresses the points above. Still to look into the cmake target, will do that later in the afternoon
Looking at the cmake code, it seems the example files are not even part of the building process. In debian they are simply included in a package thanks to the packaging rules.
I propose we merge this PR first, then we modify the cmake files to include installation of examples from cmake. At the same time we can add a target to build xcursor.so at build time. What do you think?
Yes, definitely, creating a CMake rules I assumed that it could be solved as a separate part.
It looks good and ready for merge.
da9cd0c056
into master 1 year agoMicheleC referenced this pull request from TDE/tde 10 months agoReviewers
da9cd0c056
.