Menu
▾
▴
pyfltk-user — Mailing list for the discussion of pyFLTK related issues.
You can subscribe to this list here.
| 2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(16) |
Jul
(5) |
Aug
(9) |
Sep
(22) |
Oct
(14) |
Nov
(20) |
Dec
(1) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2004 |
Jan
(7) |
Feb
(2) |
Mar
(18) |
Apr
(15) |
May
(8) |
Jun
(2) |
Jul
(15) |
Aug
(2) |
Sep
|
Oct
(1) |
Nov
(5) |
Dec
(5) |
| 2005 |
Jan
(8) |
Feb
(3) |
Mar
(1) |
Apr
(2) |
May
(1) |
Jun
(2) |
Jul
|
Aug
(14) |
Sep
(6) |
Oct
(42) |
Nov
(6) |
Dec
(1) |
| 2006 |
Jan
(12) |
Feb
(6) |
Mar
(1) |
Apr
(16) |
May
|
Jun
(4) |
Jul
(26) |
Aug
(4) |
Sep
(2) |
Oct
(9) |
Nov
(8) |
Dec
(10) |
| 2007 |
Jan
(4) |
Feb
(21) |
Mar
(12) |
Apr
(1) |
May
(13) |
Jun
(7) |
Jul
(1) |
Aug
(6) |
Sep
(10) |
Oct
(10) |
Nov
(8) |
Dec
|
| 2008 |
Jan
|
Feb
(8) |
Mar
(1) |
Apr
(7) |
May
(2) |
Jun
|
Jul
(2) |
Aug
|
Sep
|
Oct
(4) |
Nov
|
Dec
|
| 2009 |
Jan
|
Feb
(6) |
Mar
(14) |
Apr
(3) |
May
(18) |
Jun
(8) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(2) |
Dec
(2) |
| 2010 |
Jan
(1) |
Feb
(9) |
Mar
(21) |
Apr
|
May
|
Jun
(4) |
Jul
(10) |
Aug
(6) |
Sep
|
Oct
(5) |
Nov
|
Dec
|
| 2011 |
Jan
(3) |
Feb
(1) |
Mar
|
Apr
|
May
(3) |
Jun
(2) |
Jul
(1) |
Aug
(10) |
Sep
(3) |
Oct
(1) |
Nov
|
Dec
(1) |
| 2012 |
Jan
(4) |
Feb
(2) |
Mar
(2) |
Apr
|
May
(2) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2013 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2014 |
Jan
(5) |
Feb
|
Mar
(3) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
(2) |
Nov
|
Dec
|
| 2015 |
Jan
(3) |
Feb
(3) |
Mar
(4) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
(1) |
Oct
|
Nov
(2) |
Dec
(2) |
| 2016 |
Jan
(6) |
Feb
|
Mar
|
Apr
|
May
(5) |
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(5) |
Dec
|
| 2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2018 |
Jan
(4) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2020 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(12) |
Dec
|
| 2021 |
Jan
(1) |
Feb
|
Mar
(12) |
Apr
|
May
|
Jun
(17) |
Jul
(17) |
Aug
(11) |
Sep
(1) |
Oct
(2) |
Nov
(4) |
Dec
(2) |
| 2022 |
Jan
(12) |
Feb
(12) |
Mar
(12) |
Apr
(5) |
May
(1) |
Jun
|
Jul
|
Aug
(29) |
Sep
(6) |
Oct
|
Nov
(4) |
Dec
|
| 2023 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
(6) |
Aug
(16) |
Sep
|
Oct
(13) |
Nov
|
Dec
|
| 2024 |
Jan
(4) |
Feb
(21) |
Mar
(12) |
Apr
(22) |
May
|
Jun
(17) |
Jul
(16) |
Aug
(13) |
Sep
(5) |
Oct
(1) |
Nov
|
Dec
(15) |
| 2025 |
Jan
(3) |
Feb
(1) |
Mar
(11) |
Apr
(4) |
May
(1) |
Jun
(10) |
Jul
(8) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Robert A. <ro...@gm...> - 2024-12-14 17:44:07
|
On Sat, Dec 14, 2024 at 7:42 AM <and...@bl...> wrote: > > Hi Robert > > At least the warning for Fl_Valuator we cannot fix, as we need to create a director class here in order to be able to inherit the format method in derived classes. I assume that we are facing a similar problem with Fl_Display_Device. For the last one we could probably ask the fltk team whether they would consider adding a virtual destructor, but this is probably not so important. In short I would suggest to ignore these warnings for the time being. > By the way, it seems fltk-1.4.1 has now been released: https://www.fltk.org/articles.php?L1959 > Shall we follow suit and also release what we have? I belive that our code base should be quite stable already and that we have been covering most features of fltk-1.4 Yes I saw they released 1.4.1. :) I will start building wheel packages. |
|
From: <and...@bl...> - 2024-12-14 15:57:39
|
Hi Robert At least the warning for Fl_Valuator we cannot fix, as we need to create a director class here in order to be able to inherit the format method in derived classes. I assume that we are facing a similar problem with Fl_Display_Device. For the last one we could probably ask the fltk team whether they would consider adding a virtual destructor, but this is probably not so important. In short I would suggest to ignore these warnings for the time being. By the way, it seems fltk-1.4.1 has now been released: https://www.fltk.org/articles.php?L1959 Shall we follow suit and also release what we have? I belive that our code base should be quite stable already and that we have been covering most features of fltk-1.4 Best regards Andreas Best regards Andreas > Robert Arkiletian <ro...@gm...> hat am 11.12.2024 00:18 CET geschrieben: > > > Building with latest FLTK 1.4.0-1 release and latest r648 pyFltk > > OS: Debian 12 x86_64 > > command: > python3 setup.py swig > > /usr/local/include/FL/Fl_Device.H:118: Warning 314: 'print' is a > python keyword, renaming to '_print' > ./swig/Fl_Valuator.i:25: Warning 517: Director class 'Fl_Valuator' > can't be constructed > /usr/local/include/FL/Fl_Device.H:95: Warning 517: Director class > 'Fl_Display_Device' can't be constructed > /usr/local/include/FL/Fl_Device.H:108: Warning 514: Director base > class Fl_Device_Plugin has no virtual destructor. > > Should we ignore these warnings? Or do they need to be addressed > before we release 1.4? > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
|
From: Robert A. <ro...@gm...> - 2024-12-10 23:19:05
|
Building with latest FLTK 1.4.0-1 release and latest r648 pyFltk OS: Debian 12 x86_64 command: python3 setup.py swig /usr/local/include/FL/Fl_Device.H:118: Warning 314: 'print' is a python keyword, renaming to '_print' ./swig/Fl_Valuator.i:25: Warning 517: Director class 'Fl_Valuator' can't be constructed /usr/local/include/FL/Fl_Device.H:95: Warning 517: Director class 'Fl_Display_Device' can't be constructed /usr/local/include/FL/Fl_Device.H:108: Warning 514: Director base class Fl_Device_Plugin has no virtual destructor. Should we ignore these warnings? Or do they need to be addressed before we release 1.4? |
|
From: Robert A. <ro...@gm...> - 2024-10-22 22:23:44
|
Hello everyone, I am excited to share that the FLTK team has released 1.4.0 rc1. https://www.fltk.org/articles.php?L1947 This release comes with significant new features, including native Wayland support. Congrats and kudos to all the FLTK devs. They have put a lot of work into this release. Hopefully, pyFltk 1.4.0 will follow soon after the official release. cheers |
|
From: Andreas H. <and...@bl...> - 2024-09-28 07:20:23
|
<div dir='auto'><div>Hi Gonzalo</div><div dir="auto"><br></div><div dir="auto">I have given you now developer access to the project. If you want to work on pyFltk14, then please bar your work on the existing branch for V1.4.</div><div><br></div><div data-smartmail="gmail_signature">Best regards</div><div data-smartmail="gmail_signature" dir="auto"><br></div><div data-smartmail="gmail_signature" dir="auto">Andreas</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 26 Sept 2024 14:22, Gonzalo Garramuño <gga...@gm...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I am starting to work on the wrapping of pyFLTK for 1.4, and would like <br> to get permissions to commit on the svn repository.</p> <p dir="ltr">My username on sourceforge is ggarra13.</p> <p dir="ltr">Not sure if you need anything else.</p> <p dir="ltr">-- <br> Gonzalo Garramuño<br> gga...@gm...<br><br></p> <p dir="ltr">_______________________________________________<br> Pyfltk-user mailing list<br> Pyf...@li...<br> https://lists.sourceforge.net/lists/listinfo/pyfltk-user<br> </p> </blockquote></div><br></div> |
|
From: Gonzalo G. <gga...@gm...> - 2024-09-26 12:22:27
|
I am starting to work on the wrapping of pyFLTK for 1.4, and would like to get permissions to commit on the svn repository. My username on sourceforge is ggarra13. Not sure if you need anything else. -- Gonzalo Garramuño gga...@gm... |
|
From: Robert A. <ro...@gm...> - 2024-09-11 22:53:06
|
On Wed, Sep 11, 2024 at 1:51 PM Andreas Held <and...@bl...> wrote: > > Hi Robert > > This is strange and cannot really work. Probably you should report that to the fltk mailing list. Including mac.H can only work off the headers are taken from the source location and not from the install location. > You can avoid this problem by setting the environment variable FLTK_HOME to the directory where your fltk sources tree resides. > Hi Andreas, Thanks for the reply. So it's the FLTK package in homebrew (brew.sh) which is missing the src files. It's similar to Debian having both libfltk1.3 and libfltk1.3-dev. It seems Homebrew has no dev package for FLTK. So my next step forward is to build the FLTK source tree manually instead of relying on homebrew. |
|
From: Andreas H. <and...@bl...> - 2024-09-11 20:51:11
|
<div dir='auto'><div>Hi Robert</div><div dir="auto"><br></div><div dir="auto">This is strange and cannot really work. Probably you should report that to the fltk mailing list. Including mac.H can only work off the headers are taken from the source location and not from the install location. </div><div dir="auto">You can avoid this problem by setting the environment variable FLTK_HOME to the directory where your fltk sources tree resides. </div><div dir="auto"><br></div><div dir="auto">Best regards</div><div dir="auto"><br></div><div dir="auto">Andreas</div><div><br></div><div data-smartmail="gmail_signature">Sent from Android device</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 10 Sept 2024 22:08, Robert Arkiletian <ro...@gm...> wrote:<br type="attribution" /><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><p dir="ltr">I'm getting the following error on both intel macs and arm macs <br> <br> Using <br> pyfltk svn 631 <br> python 3.9 <br> FLTK 1.3.9 from brew.sh <br> swig 4.2.1 <br> <br> python3 setup.py swig <br> completes with a warning <br> ./swig/Fl_Valuator.i:25 Warning 517: Director class 'Fl_Valuator' <br> can't be constructed <br> <br> However, <br> python3 setup.py build <br> fails with the following error <br> ... <br> running build_ext <br> building 'fltk._fltk' extension <br> creating build/temp.macosx-10.9-universal2-cpython-39 <br> creating build/temp.macosx-10.9-universal2-cpython-39/contrib <br> creating build/temp.macosx-10.9-universal2-cpython-39/fltk <br> g++ -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common <br> -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -g -DUNIX=1 -DFL_INTERNALS=1 <br> -I/usr/local/Cellar/fltk/1.3.9/include -I./src -I./contrib <br> -I/usr/include -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 <br> -c ./contrib/ListSelect.cpp -o <br> build/temp.macosx-10.9-universal2-cpython-39/./contrib/ListSelect.o <br> -arch x86_64 <br> g++ -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common <br> -dynamic -DNDEBUG -g -fwrapv -O3 -Wall -g -DUNIX=1 -DFL_INTERNALS=1 <br> -I/usr/local/Cellar/fltk/1.3.9/include -I./src -I./contrib <br> -I/usr/include -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9 <br> -c ./fltk/fltk_wrap.cpp -o <br> build/temp.macosx-10.9-universal2-cpython-39/./fltk/fltk_wrap.o -arch <br> x86_64 <br> In file included from ./fltk/fltk_wrap.cpp:6360: <br> In file included from /usr/local/Cellar/fltk/1.3.9/include/FL/fl_draw.H:27: <br> In file included from /usr/local/Cellar/fltk/1.3.9/include/FL/x.H:30: <br> /usr/local/Cellar/fltk/1.3.9/include/FL/mac.H:136:12: fatal error: <br> '../src/Fl_Font.H' file not found <br> # include "../src/Fl_Font.H" <br> ^~~~~~~~~~~~~~~~~~ <br> 1 error generated. <br> error: command '/usr/bin/g++' failed with exit code 1 <br> <br> <br> Andreas, I noticed you ignored Fl_XFont_On_Demand in swig/x.i svn 630. <br> I was hoping this fixed the above issue but it has not. Also, noticed <br> that FLTK 1.4 does not use this include in mac.H. Any ideas on how to <br> avoid this error? <br> <br> <br> _______________________________________________ <br> Pyfltk-user mailing list <br> Pyf...@li... <br> https://lists.sourceforge.net/lists/listinfo/pyfltk-user <br> </p> </blockquote></div><br></div> |
|
From: Robert A. <ro...@gm...> - 2024-09-10 20:08:59
|
I'm getting the following error on both intel macs and arm macs
Using
pyfltk svn 631
python 3.9
FLTK 1.3.9 from brew.sh
swig 4.2.1
python3 setup.py swig
completes with a warning
./swig/Fl_Valuator.i:25 Warning 517: Director class 'Fl_Valuator'
can't be constructed
However,
python3 setup.py build
fails with the following error
...
running build_ext
building 'fltk._fltk' extension
creating build/temp.macosx-10.9-universal2-cpython-39
creating build/temp.macosx-10.9-universal2-cpython-39/contrib
creating build/temp.macosx-10.9-universal2-cpython-39/fltk
g++ -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common
-dynamic -DNDEBUG -g -fwrapv -O3 -Wall -g -DUNIX=1 -DFL_INTERNALS=1
-I/usr/local/Cellar/fltk/1.3.9/include -I./src -I./contrib
-I/usr/include -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9
-c ./contrib/ListSelect.cpp -o
build/temp.macosx-10.9-universal2-cpython-39/./contrib/ListSelect.o
-arch x86_64
g++ -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common
-dynamic -DNDEBUG -g -fwrapv -O3 -Wall -g -DUNIX=1 -DFL_INTERNALS=1
-I/usr/local/Cellar/fltk/1.3.9/include -I./src -I./contrib
-I/usr/include -I/Library/Frameworks/Python.framework/Versions/3.9/include/python3.9
-c ./fltk/fltk_wrap.cpp -o
build/temp.macosx-10.9-universal2-cpython-39/./fltk/fltk_wrap.o -arch
x86_64
In file included from ./fltk/fltk_wrap.cpp:6360:
In file included from /usr/local/Cellar/fltk/1.3.9/include/FL/fl_draw.H:27:
In file included from /usr/local/Cellar/fltk/1.3.9/include/FL/x.H:30:
/usr/local/Cellar/fltk/1.3.9/include/FL/mac.H:136:12: fatal error:
'../src/Fl_Font.H' file not found
# include "../src/Fl_Font.H"
^~~~~~~~~~~~~~~~~~
1 error generated.
error: command '/usr/bin/g++' failed with exit code 1
Andreas, I noticed you ignored Fl_XFont_On_Demand in swig/x.i svn 630.
I was hoping this fixed the above issue but it has not. Also, noticed
that FLTK 1.4 does not use this include in mac.H. Any ideas on how to
avoid this error?
|
|
From: <fel...@we...> - 2024-08-31 08:31:56
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello Andreas and Robert.</div> <div> </div> <div>I'm using now fltk1.3.9 but facing the same build problem with pyfltk.</div> <div>So i will search for missing files.</div> <div>Thank you for your help.</div> <div> </div> <div>Felix</div> <div> <div> <div name="quote" style="margin:10px 5px 5px 10px; padding: 10px 0 10px 10px; border-left:2px solid #C3D9E5; word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;"> <div style="margin:0 0 10px 0;"><b>Gesendet:</b> Freitag, 30. August 2024 um 20:39 Uhr<br/> <b>Von:</b> "Robert Arkiletian" <ro...@gm...><br/> <b>An:</b> "pyFltk User Exchange" <pyf...@li...><br/> <b>Betreff:</b> Re: [Pyfltk-user] compiling pyfltk under buildroot-2024.05 fails</div> <div name="quoted-content">On Fri, Aug 30, 2024 at 2:20 AM felix.doe--- via Pyfltk-user<br/> <pyf...@li...> wrote:<br/> ><br/> > Hello<br/> ><br/> > I'm building a slim Linux OS with buildroot for an embedded system.<br/> > To control the touch display i'd like to use pyFLTK building from source.<br/> > Python version = 3.11<br/> ><br/> > FLTK_VERSION = 1.3.7 -> compiles successful and installs:<br/> > libfltk.so, libfltk.so.1.3, libfltk_forms.so, libfltk_forms.so.1.3, libfltk_images.so, libfltk_images.so.1.3<br/> > PYTHON_PYFLTK_VERSION = 1.3.9 -> fails<br/> ><br/> > I fetch the pyFLTK package from pypi using: utils/scanpypi pyFltk -o package<br/> > This produces the messages:<br/> > buildroot package name for pyFltk: python-pyfltk<br/> > Package: python-pyfltk<br/> > Fetching package pyFltk<br/> > Downloading package pyFltk from <a href="https://files.pythonhosted.org/packages/b1/30/812dc908880ee24523ba79882eeb74232418d7fea40bcce9b636443b832a/pyFltk-1.3.9.tar.gz" target="_blank">https://files.pythonhosted.org/packages/b1/30/812dc908880ee24523ba79882eeb74232418d7fea40bcce9b636443b832a/pyFltk-1.3.9.tar.gz</a>...<br/> > Building for Linux<br/> > ['./src', './contrib', '/usr/include']<br/> > Checking FLTK configuration ...<br/> > Checking fltk-config using FLTK_HOME<br/> > Checking fltk-config using default installation<br/> > /bin/sh: 1: fltk-config: not found<br/> > No version information for FLTK found!<br/> > /bin/sh: 1: fltk-config: not found<br/> > No compile flags found!<br/> > /bin/sh: 1: fltk-config: not found<br/> > No link flags found!<br/> <br/> Hi Felix,<br/> I suspect you are not installing all the necessary files for FLTK as<br/> fltk-config is not found. Either that or those files are not in your<br/> path. Take a look at the files which are installed from libfltk1.3-dev<br/> on a Debian system.<br/> <a href="https://packages.debian.org/sid/amd64/libfltk1.3-dev/filelist" target="_blank">https://packages.debian.org/sid/amd64/libfltk1.3-dev/filelist</a><br/> <br/> Also, you may want to look at the build process from source here<br/> <a href="https://pyfltk.sourceforge.io/install.php#source" target="_blank">https://pyfltk.sourceforge.io/install.php#source</a><br/> it shows the build dependencies. Although you don't need subversion as<br/> you already have the source. However, the other packages may pull in<br/> other dependencies not listed.<br/> <br/> ...<br/> > This looks like missing files or build dependencies.<br/> > Please advise<br/> <br/> <br/> _______________________________________________<br/> Pyfltk-user mailing list<br/> Pyf...@li...<br/> <a href="https://lists.sourceforge.net/lists/listinfo/pyfltk-user" target="_blank">https://lists.sourceforge.net/lists/listinfo/pyfltk-user</a></div> </div> </div> </div></div></body></html> |
|
From: Robert A. <ro...@gm...> - 2024-08-30 18:39:22
|
On Fri, Aug 30, 2024 at 2:20 AM felix.doe--- via Pyfltk-user <pyf...@li...> wrote: > > Hello > > I'm building a slim Linux OS with buildroot for an embedded system. > To control the touch display i'd like to use pyFLTK building from source. > Python version = 3.11 > > FLTK_VERSION = 1.3.7 -> compiles successful and installs: > libfltk.so, libfltk.so.1.3, libfltk_forms.so, libfltk_forms.so.1.3, libfltk_images.so, libfltk_images.so.1.3 > PYTHON_PYFLTK_VERSION = 1.3.9 -> fails > > I fetch the pyFLTK package from pypi using: utils/scanpypi pyFltk -o package > This produces the messages: > buildroot package name for pyFltk: python-pyfltk > Package: python-pyfltk > Fetching package pyFltk > Downloading package pyFltk from https://files.pythonhosted.org/packages/b1/30/812dc908880ee24523ba79882eeb74232418d7fea40bcce9b636443b832a/pyFltk-1.3.9.tar.gz... > Building for Linux > ['./src', './contrib', '/usr/include'] > Checking FLTK configuration ... > Checking fltk-config using FLTK_HOME > Checking fltk-config using default installation > /bin/sh: 1: fltk-config: not found > No version information for FLTK found! > /bin/sh: 1: fltk-config: not found > No compile flags found! > /bin/sh: 1: fltk-config: not found > No link flags found! Hi Felix, I suspect you are not installing all the necessary files for FLTK as fltk-config is not found. Either that or those files are not in your path. Take a look at the files which are installed from libfltk1.3-dev on a Debian system. https://packages.debian.org/sid/amd64/libfltk1.3-dev/filelist Also, you may want to look at the build process from source here https://pyfltk.sourceforge.io/install.php#source it shows the build dependencies. Although you don't need subversion as you already have the source. However, the other packages may pull in other dependencies not listed. ... > This looks like missing files or build dependencies. > Please advise |
|
From: <fel...@we...> - 2024-08-30 09:20:33
|
<html><head></head><body><div style="font-family: Verdana;font-size: 12.0px;"><div>Hello</div> <div> </div> <div>I'm building a slim Linux OS with buildroot for an embedded system.</div> <div>To control the touch display i'd like to use pyFLTK building from source.</div> <div>Python version = 3.11</div> <div> </div> <div>FLTK_VERSION = 1.3.7 -> compiles successful and installs:<br/> libfltk.so, libfltk.so.1.3, libfltk_forms.so, libfltk_forms.so.1.3, libfltk_images.so, libfltk_images.so.1.3<br/> PYTHON_PYFLTK_VERSION = 1.3.9 -> fails</div> <div> </div> <div>I fetch the pyFLTK package from pypi using: utils/scanpypi pyFltk -o package</div> <div>This produces the messages:</div> <div> <div> <em>buildroot package name for pyFltk: python-pyfltk<br/> Package: python-pyfltk<br/> Fetching package pyFltk<br/> Downloading package pyFltk from https://files.pythonhosted.org/packages/b1/30/812dc908880ee24523ba79882eeb74232418d7fea40bcce9b636443b832a/pyFltk-1.3.9.tar.gz...<br/> Building for Linux<br/> ['./src', './contrib', '/usr/include']<br/> Checking FLTK configuration ...<br/> Checking fltk-config using FLTK_HOME<br/> Checking fltk-config using default installation<br/> /bin/sh: 1: fltk-config: not found<br/> No version information for FLTK found!<br/> /bin/sh: 1: fltk-config: not found<br/> No compile flags found!<br/> /bin/sh: 1: fltk-config: not found<br/> No link flags found!<br/> FLTK was configured without multi-threading support!<br/> FLTK was configured without OpenGL support!<br/> FLTK was configured without Forms support!<br/> done<br/> Checking if package package/python-pyfltk already exists...</em></div> <div> </div> <div> <div>The first build attempt with original distutils delivers</div> <div><em> maestro@boss-gt:~/buildroot-2024.05$ make all | tee log.txt<br/> package/python-pyfltk/python-pyfltk.mk:15: *** "Invalid PYTHON_PYFLTK_SETUP_TYPE. Valid options are 'maturin', 'setuptools', 'setuptools-rust', 'pep517' or 'flit'.". Schluss.<br/> make: *** [Makefile:82: _all] Fehler 2</em></div> </div> <div> </div> <div>The second build attempt with setuptools produces</div> <div> </div> <div> <div> <em>maestro@boss-gt:~/buildroot-2024.05$ make all | tee log.txt<br/> >>> python-pyfltk 1.3.9 Building<br/> (cd /home/maestro/buildroot-2024.05/output/build/python-pyfltk-1.3.9//; _PYTHON_HOST_PLATFORM="linux-arm" _PYTHON_PROJECT_BASE="/home/maestro/buildroot-2024.05/output/build/python3-3.11.8" _PYTHON_SYSCONFIGDATA_NAME="`{ [ -e /home/maestro/buildroot-2024.05/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/python3.11//_sysconfigdata__linux_*.py ] && basename /home/maestro/buildroot-2024.05/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/python3.11//_sysconfigdata__linux_*.py .py; } || true`" PATH="/home/maestro/buildroot-2024.05/output/host/bin:/home/maestro/buildroot-2024.05/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin" GIT_DIR=. PATH="/home/maestro/buildroot-2024.05/output/host/bin:/home/maestro/buildroot-2024.05/output/host/sbin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin:/snap/bin" AR="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc-ar" AS="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-as" LD="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-ld" NM="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc-nm" CC="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc" GCC="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc" CPP="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-cpp" CXX="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-g++" FC="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gfortran" F77="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gfortran" RANLIB="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc-ranlib" READELF="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-readelf" STRIP="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-strip" OBJCOPY="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-objcopy" OBJDUMP="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-objdump" AR_FOR_BUILD="/usr/bin/ar" AS_FOR_BUILD="/usr/bin/as" CC_FOR_BUILD="/home/maestro/buildroot-2024.05/output/host/bin/ccache /usr/bin/gcc" GCC_FOR_BUILD="/home/maestro/buildroot-2024.05/output/host/bin/ccache /usr/bin/gcc" CXX_FOR_BUILD="/home/maestro/buildroot-2024.05/output/host/bin/ccache /usr/bin/g++" LD_FOR_BUILD="/usr/bin/ld" CPPFLAGS_FOR_BUILD="-I/home/maestro/buildroot-2024.05/output/host/include" CFLAGS_FOR_BUILD="-O2 -I/home/maestro/buildroot-2024.05/output/host/include" CXXFLAGS_FOR_BUILD="-O2 -I/home/maestro/buildroot-2024.05/output/host/include" LDFLAGS_FOR_BUILD="-L/home/maestro/buildroot-2024.05/output/host/lib -Wl,-rpath,/home/maestro/buildroot-2024.05/output/host/lib" FCFLAGS_FOR_BUILD="" DEFAULT_ASSEMBLER="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-as" DEFAULT_LINKER="/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-ld" CPPFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64" CFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1" CXXFLAGS="-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -O2 -g0 -D_FORTIFY_SOURCE=1" LDFLAGS="" FCFLAGS=" -O2 -g0" FFLAGS=" -O2 -g0" PKG_CONFIG="/home/maestro/buildroot-2024.05/output/host/bin/pkg-config" STAGING_DIR="/home/maestro/buildroot-2024.05/output/host/arm-buildroot-linux-gnueabihf/sysroot" INTLTOOL_PERL=/usr/bin/perl PYTHONPATH="/home/maestro/buildroot-2024.05/output/host/arm-buildroot-linux-gnueabihf/sysroot/usr/lib/python3.11/" PYTHONNOUSERSITE=1 /home/maestro/buildroot-2024.05/output/host/bin/python3 -m build -n -w )<br/> * Getting build dependencies for wheel...<br/> /bin/sh: 1: fltk-config: not found<br/> /bin/sh: 1: fltk-config: not found<br/> /bin/sh: 1: fltk-config: not found<br/> ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any<br/> Building for Linux<br/> ['./src', './contrib', '/usr/include']<br/> Checking FLTK configuration ...<br/> Checking fltk-config using FLTK_HOME<br/> Checking fltk-config using default installation<br/> No version information for FLTK found!<br/> No compile flags found!<br/> No link flags found!<br/> FLTK was configured without multi-threading support!<br/> FLTK was configured without OpenGL support!<br/> FLTK was configured without Forms support!<br/> done<br/> * Building wheel...<br/> /bin/sh: 1: fltk-config: not found<br/> /bin/sh: 1: fltk-config: not found<br/> /bin/sh: 1: fltk-config: not found<br/> ERROR setuptools_scm._file_finders.git listing git files failed - pretending there aren't any<br/> arm-buildroot-linux-gnueabihf-gcc: ERROR: unsafe header/library path used in cross-compilation: '-I/usr/include'<br/> error: command '/home/maestro/buildroot-2024.05/output/host/bin/arm-buildroot-linux-gnueabihf-gcc' failed with exit code 1<br/> Building for Linux<br/> ['./src', './contrib', '/usr/include']<br/> Checking FLTK configuration ...<br/> Checking fltk-config using FLTK_HOME<br/> Checking fltk-config using default installation<br/> No version information for FLTK found!<br/> No compile flags found!<br/> No link flags found!<br/> FLTK was configured without multi-threading support!<br/> FLTK was configured without OpenGL support!<br/> FLTK was configured without Forms support!<br/> done</em></div> <div><em> ERROR Backend subprocess exited when trying to invoke build_wheel<br/> make[1]: *** [package/pkg-generic.mk:283: /home/maestro/buildroot-2024.05/output/build/python-pyfltk-1.3.9/.stamp_built] Fehler 1<br/> make: *** [Makefile:82: _all] Fehler 2</em></div> </div> <div> </div> <div>The config and make files are:</div> <div> </div> <div> <div><em>file: Config.in</em></div> <div><em>config BR2_PACKAGE_PYTHON_PYFLTK<br/> bool "python-pyfltk"<br/> help<br/> This is a Python wrapper for the FLTK.</em></div> <div><em> http://pyfltk.sourceforge.net</em></div> <div><br/> <em>file: python-pyfltk.mk</em></div> <div><em>################################################################################<br/> #<br/> # python-pyfltk<br/> #<br/> ################################################################################</em></div> <div><em>PYTHON_PYFLTK_VERSION = 1.3.9<br/> PYTHON_PYFLTK_SOURCE = pyFltk-$(PYTHON_PYFLTK_VERSION).tar.gz<br/> PYTHON_PYFLTK_SITE = https://files.pythonhosted.org/packages/b1/30/812dc908880ee24523ba79882eeb74232418d7fea40bcce9b636443b832a<br/> #PYTHON_PYFLTK_SETUP_TYPE = distutils<br/> PYTHON_PYFLTK_SETUP_TYPE = setuptools<br/> PYTHON_PYFLTK_LICENSE = GNU Lesser General Public License v2 (LGPLv2)<br/> PYTHON_PYFLTK_LICENSE_FILES = COPYING</em></div> <div><em>$(eval $(python-package))</em></div> <div> </div> <div> </div> <div>This looks like missing files or build dependencies.</div> <div>Please advise</div> </div> </div></div></body></html> |
|
From: Matthias M. <mm...@ma...> - 2024-08-28 17:05:03
|
> On 27. Aug 2024, at 21:04, and...@bl... wrote: > > However, the real culprit causing the infinite recuirsion is line 14 in fltk.1. Namely, Fl_Valuator is marked as "No Director", hence it cannot be derived from. Why I added this line is not completely clear to me anymore. I had to read up on the documentation myself. My first thought was, teh string must be some fprint style formatting text like "%d". The docs only reveal the intention of using a virtual method when reading all the way to the end. It's not surprising that, when porting hundereds of methods, this is not too obvious. Especially with a function that is used so rarely. - Matthias |
|
From: <and...@bl...> - 2024-08-27 19:04:35
|
Hi there Thank you Matthias for pointing this out. Following your explanation, I have now replaced the line %cstring_bounded_mutbale(char* format_string, 128); by %cstring_bounded_output(char* format_string, 128); However, the real culprit causing the infinite recuirsion is line 14 in fltk.1. Namely, Fl_Valuator is marked as "No Director", hence it cannot be derived from. Why I added this line is not completely clear to me anymore. There is some warning message while compiling, probably Fl_Valuator cannot be used on its own, but probably this was never the idea anyway. In any case, when I uncomment line 14 then your example works. Best regards Andreas > Matthias Melcher <mm...@ma...> hat am 27.08.2024 10:38 CEST geschrieben: > > > The idea behind Fl_Valuator::format() is to giv the user a chance to override how the text output of the current value is formatted. > > By overriding this method, the user can return any string of up to 128 bytes length. So both parameters are actually return values. IMHO the Python signature should simply take no argument and return the formatted number as a string. The interface can then calculate the length of the string and clip it to 128 bytes. > > - Matthias > > > > On 25. Aug 2024, at 20:25, and...@bl... wrote: > > > > Hi Dima > > > > You are definitely right that the length parameter is incorrect, that should be 128 in this case. About how to actually wrap this so as not to cause a stack overflow seems not so easy. I will also try to dive into that a little bit to see whether I can support you here. > > > > Best regards > > > > Andreas > > > >> Dima Kogan <di...@se...> hat am 25.08.2024 03:54 CEST geschrieben: > >> > >> > >> To answer the main question: this cannot work at all with today's > >> implementation in pyfltk. cstring_bounded_mutable() is meant for callers > >> of the function, NOT director overriders. The docs here: > >> > >> https://www.swig.org/Doc1.3/Library.html#Library_nn8 > >> > >> clearly say: > >> > >> It is important to emphasize that this function does not mutate the > >> string value passed---instead it makes a copy of the input value, > >> mutates it, and returns it as a result. > >> > >> I haven't figured out how to tell swig to do what I want. If somebody > >> knows how, please chime in |
|
From: Matthias M. <mm...@ma...> - 2024-08-27 08:51:41
|
The idea behind Fl_Valuator::format() is to giv the user a chance to override how the text output of the current value is formatted. By overriding this method, the user can return any string of up to 128 bytes length. So both parameters are actually return values. IMHO the Python signature should simply take no argument and return the formatted number as a string. The interface can then calculate the length of the string and clip it to 128 bytes. - Matthias > On 25. Aug 2024, at 20:25, and...@bl... wrote: > > Hi Dima > > You are definitely right that the length parameter is incorrect, that should be 128 in this case. About how to actually wrap this so as not to cause a stack overflow seems not so easy. I will also try to dive into that a little bit to see whether I can support you here. > > Best regards > > Andreas > >> Dima Kogan <di...@se...> hat am 25.08.2024 03:54 CEST geschrieben: >> >> >> To answer the main question: this cannot work at all with today's >> implementation in pyfltk. cstring_bounded_mutable() is meant for callers >> of the function, NOT director overriders. The docs here: >> >> https://www.swig.org/Doc1.3/Library.html#Library_nn8 >> >> clearly say: >> >> It is important to emphasize that this function does not mutate the >> string value passed---instead it makes a copy of the input value, >> mutates it, and returns it as a result. >> >> I haven't figured out how to tell swig to do what I want. If somebody >> knows how, please chime in |
|
From: Dima K. <di...@se...> - 2024-08-26 00:37:40
|
I'm asking the question on the swig mailing list: https://sourceforge.net/p/swig/mailman/swig-user/thread/87frqtid3x.fsf%40secretsauce.net/#msg58809771 It's not obvious this is possible. It might be, but I haven't figured out how to do it. |
|
From: <and...@bl...> - 2024-08-25 18:40:03
|
Hi Dima You are definitely right that the length parameter is incorrect, that should be 128 in this case. About how to actually wrap this so as not to cause a stack overflow seems not so easy. I will also try to dive into that a little bit to see whether I can support you here. Best regards Andreas > Dima Kogan <di...@se...> hat am 25.08.2024 03:54 CEST geschrieben: > > > To answer the main question: this cannot work at all with today's > implementation in pyfltk. cstring_bounded_mutable() is meant for callers > of the function, NOT director overriders. The docs here: > > https://www.swig.org/Doc1.3/Library.html#Library_nn8 > > clearly say: > > It is important to emphasize that this function does not mutate the > string value passed---instead it makes a copy of the input value, > mutates it, and returns it as a result. > > I haven't figured out how to tell swig to do what I want. If somebody > knows how, please chime in > > > _______________________________________________ > Pyfltk-user mailing list > Pyf...@li... > https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
|
From: Dima K. <di...@se...> - 2024-08-25 01:53:24
|
To answer the main question: this cannot work at all with today's implementation in pyfltk. cstring_bounded_mutable() is meant for callers of the function, NOT director overriders. The docs here: https://www.swig.org/Doc1.3/Library.html#Library_nn8 clearly say: It is important to emphasize that this function does not mutate the string value passed---instead it makes a copy of the input value, mutates it, and returns it as a result. I haven't figured out how to tell swig to do what I want. If somebody knows how, please chime in |
|
From: Dima K. <di...@se...> - 2024-08-24 22:43:20
|
Hello. Fl_Valuator has this questionable-looking method declaration: virtual int format(char*); The char* argument is assumed to be a buffer that's 128 bytes long: https://github.com/fltk/fltk/blob/9e35b0216f384f815284d6e8ee4ee9fcce3af01a/src/Fl_Valuator.cxx#L168 This isn't good code, but that's what we're stuck with. I want to override this in Python. This has several potential problems: 1. Even starting to think about this in pyfltk doesn't work. I have this code: import sys from fltk import * class Fl_Value_Slider_Derived(Fl_Value_Slider): def __init__(self, *args, **kwargs): return super().__init__(*args, **kwargs) window = Fl_Window(800, 600, "window") slider = Fl_Value_Slider_Derived(0,300, 800, 300, "slider") window.end() window.show() Fl.run() It does this: dima@shorty:~$ python3 /tmp/tst2.py Traceback (most recent call last): File "/tmp/tst2.py", line 16, in <module> Fl.run() File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 2839, in run return _fltk.Fl_run(*args) ^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 7932, in draw return _fltk.Fl_Value_Slider_draw(self, *args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 3604, in format return _fltk.Fl_Valuator_format(self, *args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 3604, in format return _fltk.Fl_Valuator_format(self, *args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/usr/lib/python3/dist-packages/fltk/fltk.py", line 3604, in format return _fltk.Fl_Valuator_format(self, *args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ [Previous line repeated 994 more times] RecursionError: maximum recursion depth exceeded 2. The corresponding thing in pyfltk is in swig/Fl_Valuator.i: %cstring_bounded_mutable(char* format_string, 1024); This "1024" should be "128", no? I'm not yet clear on this. The relevant docs: https://www.swig.org/Doc1.3/Library.html#Library_nn12 3. Strings are immutable in Python, so we'd need special code to make this overridable and functional. I think this code doesn't exist. Yes? I'm going to look at this for a little bit today. Hopefully this is easy |
|
From: Robert A. <ro...@gm...> - 2024-08-22 06:21:28
|
On Tue, Aug 20, 2024 at 11:20 PM Robert Arkiletian <ro...@gm...> wrote: > > On Tue, Aug 20, 2024 at 5:36 PM Dima Kogan <di...@se...> wrote: > > > > Hello. > > > > I just hit a trivial crash. Possily related to the various issues we've > > been seeing recently, and I'd like to record this here. Recipe: > > > > #!/usr/bin/python3 > > > > import sys > > from fltk import * > > > > class Fl_Button_Derived(Fl_Button): > > def __init__(self, > > *args, > > **kwargs): > > return super().__init__(*args, **kwargs) > > > > window = Fl_Window(800, 600, "window") > > button1 = Fl_Button_Derived(0, 0, 800, 300, "button1") > > button1 = Fl_Button( 0, 300, 800, 300, "button2") > > > > window.end() > > window.show() > > Fl.run() > > > > sys.exit(0) > > > > This crashes. Here I accidentally put both buttons into the "button1" > > object. So the first one (the derived class) is destroyed in some > > incorrect way, and we crash. > > Did some digging into the SWIG documentation. Specifically, https://www.swig.org/Doc4.0/SWIGDocumentation.html#Python_directors ------ 32.5.3 Ownership and object destruction Memory management issues are slightly more complicated with directors than for proxy classes alone. Python instances hold a pointer to the associated C++ director object, and the director in turn holds a pointer back to the Python object. By default, proxy classes own their C++ director object and take care of deleting it when they are garbage collected. This relationship can be reversed by calling the special __disown__() method of the proxy class. After calling this method, the .thisown flag is set to zero, and the director class increments the reference count of the Python object. When the director class is deleted it decrements the reference count. Assuming no outstanding references to the Python object remain, the Python object will be destroyed at the same time. This is a good thing, since directors and proxies refer to each other and so must be created and destroyed together. Destroying one without destroying the other will likely cause your program to segfault. ------- So if I add the disown line as per below there is no more segfault from fltk import * class Fl_Button_Derived(Fl_Button): def __init__(self, *args, **kwargs): return super().__init__(*args, **kwargs) window = Fl_Window(800, 600, "window") button1 = Fl_Button_Derived(0, 0, 800, 300, "button1") button1 = button1.__disown__() button1 = Fl_Button( 0, 300, 800, 300, "button2") window.end() window.show() Fl.run() Looking at the interface files in the swig dir, the only file that contains disown is macros.i. ----- // macro to delegate the ownership of a class to C++ %define CHANGE_OWNERSHIP(name) #include "CallbackStruct.h" %pythonappend name##::##name %{ if len(args) == 5: # retain reference to label self.my_label = args[-1] if self.parent() != None: # delegate ownership to C++ self.this.disown() self.init_type("name") #print("Adding type: ", name) %} %extend name { void init_type(char* name) { CallbackStruct *cb = new CallbackStruct( 0, 0, 0, 0 ); memcpy(cb->type_name, name, strlen(name)); self->user_data(cb); } } %enddef // macro to revert the ownership %define REVERT_OWNERSHIP(name) %pythonappend name %{ #self = args[0] if self.parent() != None: #delegate ownership to C++ self.this.disown() else: #give ownership back to Python self.this.own() %} %enddef ----- but in the Fl_Button.i interface file we are calling CHANGE_OWNERSHIP(Fl_Button) So one would assume disown is already being set as the parent of the button is the window (which is not None). I'll look into this further in the next few days as I feel like I'm getting closer to the root cause of this bug. Any insight from others is welcome. |
|
From: Robert A. <ro...@gm...> - 2024-08-21 06:21:11
|
On Tue, Aug 20, 2024 at 5:36 PM Dima Kogan <di...@se...> wrote:
>
> Hello.
>
> I just hit a trivial crash. Possily related to the various issues we've
> been seeing recently, and I'd like to record this here. Recipe:
>
> #!/usr/bin/python3
>
> import sys
> from fltk import *
>
> class Fl_Button_Derived(Fl_Button):
> def __init__(self,
> *args,
> **kwargs):
> return super().__init__(*args, **kwargs)
>
> window = Fl_Window(800, 600, "window")
> button1 = Fl_Button_Derived(0, 0, 800, 300, "button1")
> button1 = Fl_Button( 0, 300, 800, 300, "button2")
>
> window.end()
> window.show()
> Fl.run()
>
> sys.exit(0)
>
> This crashes. Here I accidentally put both buttons into the "button1"
> object. So the first one (the derived class) is destroyed in some
> incorrect way, and we crash.
>
> Thanks.
>
Dima
Nice and simple recipe. Doing some testing to see if I can pinpoint
the issue. Also, will try and see if this was a regression by testing
it with some previous releases. My gut says this is an ownership
issue. As an additional observation if I add a callback to the first
instance of button1, then it does not segfault. I suspect adding a
callback keeps a ref alive so the widget is not deleted by the GC. See
below
from fltk import *
def foo(wid):
pass
class Fl_Button_Derived(Fl_Button):
def __init__(self,
*args,
**kwargs):
return super().__init__(*args, **kwargs)
window = Fl_Window(800, 600, "window")
button1 = Fl_Button_Derived(0, 0, 800, 300, "button1")
button1.callback(foo)
button1 = Fl_Button( 0, 300, 800, 300, "button2")
window.end()
window.show()
Fl.run()
Also here is the gdb backtrace for the seg fault
#0 0x000000000052340b in _PyObject_GetMethod ()
#1 0x0000000000583bb0 in PyObject_CallMethodObjArgs ()
#2 0x00007ffff71b201b in SwigDirector_Fl_Button::handle
(this=0xbeebf0, arg0=<optimized out>)
at ./fltk/fltk_wrap.cpp:3295
#3 0x00007ffff6f289b4 in Fl_Group::handle(int) () from
/lib/x86_64-linux-gnu/libfltk.so.1.3
#4 0x00007ffff6f74a75 in Fl_X::make_xid(Fl_Window*, XVisualInfo*,
unsigned long) ()
from /lib/x86_64-linux-gnu/libfltk.so.1.3
#5 0x00007ffff71031db in Fl_Window_show (data=0x0, count=0x0,
self=0xbf32b0) at ./fltk/fltk_wrap.cpp:6040
#6 _wrap_Fl_Window_show (self=<optimized out>, args=<optimized out>)
at ./fltk/fltk_wrap.cpp:17098
#7 0x0000000000548828 in ?? ()
#8 0x000000000056b114 in PyObject_Call ()
#9 0x00000000005359d7 in _PyEval_EvalFrameDefault ()
#10 0x000000000052436b in PyEval_EvalCode ()
#11 0x000000000064a627 in ?? ()
#12 0x0000000000647eef in ?? ()
#13 0x0000000000654070 in ?? ()
#14 0x0000000000653dbb in _PyRun_SimpleFileObject ()
#15 0x0000000000653be4 in _PyRun_AnyFileObject ()
#16 0x000000000065297f in Py_RunMain ()
#17 0x000000000062a547 in Py_BytesMain ()
#18 0x00007ffff7cc924a in ?? () from /lib/x86_64-linux-gnu/libc.so.6
#19 0x00007ffff7cc9305 in __libc_start_main () from
/lib/x86_64-linux-gnu/libc.so.6
#20 0x000000000062a3e1 in _start ()
(gdb)
|
|
From: Dima K. <di...@se...> - 2024-08-21 00:36:26
|
Hello.
I just hit a trivial crash. Possily related to the various issues we've
been seeing recently, and I'd like to record this here. Recipe:
#!/usr/bin/python3
import sys
from fltk import *
class Fl_Button_Derived(Fl_Button):
def __init__(self,
*args,
**kwargs):
return super().__init__(*args, **kwargs)
window = Fl_Window(800, 600, "window")
button1 = Fl_Button_Derived(0, 0, 800, 300, "button1")
button1 = Fl_Button( 0, 300, 800, 300, "button2")
window.end()
window.show()
Fl.run()
sys.exit(0)
This crashes. Here I accidentally put both buttons into the "button1"
object. So the first one (the derived class) is destroyed in some
incorrect way, and we crash.
Thanks.
|
|
From: Matthias M. <mm...@ma...> - 2024-07-22 10:00:11
|
> On 21. Jul 2024, at 20:17, and...@bl... wrote: > > Hi Matthias > > Thank you very much for this insight into fltk. I will try to have a dive into that to see how we could utilize it. In general, I don't think that the problem is so big though. It just happens that fltk and Python do have quite different systems of keeping track of widgets and memory. These two systems do not always go very well together but that's mostly for special and border cases. All in all, I don't think that we have had many problems over these years. > On a related note, do you have any idea when we can expect the first official release of fltk1.4? > > Best regards > > Andreas Hi Andreas, it's probably fine as long as the user only created widgets, but never deletes them. As soon as a group is deleted the C++ structure is pulled out under the Pythin wrapper, and the app will crash. I hope that my extension will help to fix this. I really love that there are multiple language wrappers for FLTK. Just let me know if you need anything else. As for the release data, I'll have to ask Albrecht again. I think we are ready now, but he likes to do some extended testing first. Matthias |
|
From: <and...@bl...> - 2024-07-21 18:31:51
|
Hi Matthias Thank you very much for this insight into fltk. I will try to have a dive into that to see how we could utilize it. In general, I don't think that the problem is so big though. It just happens that fltk and Python do have quite different systems of keeping track of widgets and memory. These two systems do not always go very well together but that's mostly for special and border cases. All in all, I don't think that we have had many problems over these years. On a related note, do you have any idea when we can expect the first official release of fltk1.4? Best regards Andreas ----Ursprüngliche Nachricht---- Von : mm...@ma... Datum : 21/07/2024 - 13:53 (CEST) An : pyf...@li... Betreff : Re: [Pyfltk-user] There's something funky going on with pyFLTK's reference counting Hi guys, Matthias here, one of the FLTK core devs. I am following the PyFLTK mailing list every once in a while, and I am afraid that most if not all of your issues still come from reference counting. And it's FLTK's fault. This is in reply to https://sourceforge.net/p/pyfltk/mailman/message/58788137/ . The sourceforge mailing list interface is a pest. I am not a Python or SWIG expert by any means, but I do understand the logic behind reference counting. I tried to fix your issues writing a SWIG-less Pythin wrapper by hand. However, FLTK ruins reference counts by deleting widgets in Fl_Group::clear(), and there is no way to avoid that. I tried to alleviate the issue by adding the virtual methods Fl_Group::on_insert, on_move, and on_remove, but they ended up watered down. Originally, retuning on_remove was supposed to return a value that forbade deleting, but that was watered down because we would have had to change Fl_Group::remove(). Anyway, the latest version of FLTK 1.4 no sends an FL_AUTO_DELETE_EVENT, and returning 1 from that event will suppress calling the destructor. PyFLTK can use this to keep the actual widget around and decremet the reference count in the wrapper. Maybe this finally fixes your issues, I don't know. Either way, I'd be happy to help in finding all little traps in FLTK where widgets are automatically referenced and dereferenced, so PyFLTK can be as stable as possible. Matthias _______________________________________________ Pyfltk-user mailing list Pyf...@li... https://lists.sourceforge.net/lists/listinfo/pyfltk-user |
|
From: RJ A. <rj....@gm...> - 2024-07-21 13:47:31
|
On Sun, Jul 21, 2024, 2:07 p.m. Matthias Melcher <mm...@ma...> wrote: > Hi guys, > > Matthias here, one of the FLTK core devs. I am following the PyFLTK > mailing list every once in a while, and I am afraid that most if not all of > your issues still come from reference counting. And it's FLTK's fault. > > This is in reply to > https://sourceforge.net/p/pyfltk/mailman/message/58788137/ . The > sourceforge mailing list interface is a pest. > > I am not a Python or SWIG expert by any means, but I do understand the > logic behind reference counting. I tried to fix your issues writing a > SWIG-less Pythin wrapper by hand. However, FLTK ruins reference counts by > deleting widgets in Fl_Group::clear(), and there is no way to avoid that. > > I tried to alleviate the issue by adding the virtual methods > Fl_Group::on_insert, on_move, and on_remove, but they ended up watered > down. Originally, retuning on_remove was supposed to return a value that > forbade deleting, but that was watered down because we would have had to > change Fl_Group::remove(). > > Anyway, the latest version of FLTK 1.4 no sends an FL_AUTO_DELETE_EVENT, > and returning 1 from that event will suppress calling the destructor. > PyFLTK can use this to keep the actual widget around and decremet the > reference count in the wrapper. > > Maybe this finally fixes your issues, I don't know. Either way, I'd be > happy to help in finding all little traps in FLTK where widgets are > automatically referenced and dereferenced, so PyFLTK can be as stable > Hi Matthias, This is Robert. I am on vacation in Munich. I would welcome your contribution to help us stabilize pyFltk 1.4. BTW I sent you an email off list. > |
14 messages has been excluded from this view by a project administrator.
