I'm developing an external based on someone else's code, and there's a spot that causes a crash when freeing some memory, so I disabled that temporarily to check some output. I also added a t_atom pointer which I allocate before I call the function I mention here with getbytes(), and after I set some values to it and output it as a list from the first outlet of the object, I free the memory of the t_atom with freebytes().
At first it worked find and I got a list out the outlet, but when I tried to launch Pd again with this patch, Pd launches but the patch won't open. I tried to open the patch manually but again it doesn't open. Other patches open and work fine. I don't think the patch is at some place beyond my monitor, because I don't see any tab on the top part of my screen. When I open any other patch, a new tab appears there, next to the tab of Pd's console.
I'm on UbuntuStudio 22.04, with Pd-0.52.2. Any ideas?
Hello,
Could you post a link to your code or attach a zip file with sources and patch file?
Le 9 nov. 2022 à 21:30, Alexandros adrcki@gmail.com a écrit :
I'm developing an external based on someone else's code, and there's a spot that causes a crash when freeing some memory, so I disabled that temporarily to check some output. I also added a t_atom pointer which I allocate before I call the function I mention here with getbytes(), and after I set some values to it and output it as a list from the first outlet of the object, I free the memory of the t_atom with freebytes().
At first it worked find and I got a list out the outlet, but when I tried to launch Pd again with this patch, Pd launches but the patch won't open. I tried to open the patch manually but again it doesn't open. Other patches open and work fine. I don't think the patch is at some place beyond my monitor, because I don't see any tab on the top part of my screen. When I open any other patch, a new tab appears there, next to the tab of Pd's console.
I'm on UbuntuStudio 22.04, with Pd-0.52.2. Any ideas?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
did you started Pd from a terminal?
if so does it prints something to it?
or put the Pd's console to log to 4. does it prints something?
--
Mensaje telepatico asistido por maquinas.
On 09/11/2022 17:30, Alexandros wrote:
I'm developing an external based on someone else's code, and there's a spot that causes a crash when freeing some memory, so I disabled that temporarily to check some output. I also added a t_atom pointer which I allocate before I call the function I mention here with getbytes(), and after I set some values to it and output it as a list from the first outlet of the object, I free the memory of the t_atom with freebytes().
At first it worked find and I got a list out the outlet, but when I tried to launch Pd again with this patch, Pd launches but the patch won't open. I tried to open the patch manually but again it doesn't open. Other patches open and work fine. I don't think the patch is at some place beyond my monitor, because I don't see any tab on the top part of my screen. When I open any other patch, a new tab appears there, next to the tab of Pd's console.
I'm on UbuntuStudio 22.04, with Pd-0.52.2. Any ideas?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
I remade the patch and now it opens. I've no idea why. I did set log to 4, but nothing concerning this patch was being printed. Also, I did launch Pd from a terminal and there was nothing there either. Pretty mysterious. Anyway, now the patch opens again. I'll come back here if I encounter this strange issue again.
On 9/11/22 23:36, Lucas Cordiviola wrote:
did you started Pd from a terminal?
if so does it prints something to it?
or put the Pd's console to log to 4. does it prints something?
--
Mensaje telepatico asistido por maquinas.
On 09/11/2022 17:30, Alexandros wrote:
I'm developing an external based on someone else's code, and there's a spot that causes a crash when freeing some memory, so I disabled that temporarily to check some output. I also added a t_atom pointer which I allocate before I call the function I mention here with getbytes(), and after I set some values to it and output it as a list from the first outlet of the object, I free the memory of the t_atom with freebytes().
At first it worked find and I got a list out the outlet, but when I tried to launch Pd again with this patch, Pd launches but the patch won't open. I tried to open the patch manually but again it doesn't open. Other patches open and work fine. I don't think the patch is at some place beyond my monitor, because I don't see any tab on the top part of my screen. When I open any other patch, a new tab appears there, next to the tab of Pd's console.
I'm on UbuntuStudio 22.04, with Pd-0.52.2. Any ideas?
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
On 11/10/22 16:04, Alexandros wrote:
I remade the patch and now it opens. I've no idea why. I did set log to 4, but nothing concerning this patch was being printed. Also, I did launch Pd from a terminal and there was nothing there either. Pretty mysterious. Anyway, now the patch opens again. I'll come back here if I encounter this strange issue again.
i just had something similar. the reason why the patch would not open was, that the patch file was empty.
this happened, because Pd crashed while saving the file (right between clearing the original contents and writing the new content).
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui (courtesy of yours sincerely).
gasmdr IOhannes
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 16:21]:
[...]
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui
Do you mean the now vanilla GUI objects once introduced by IEM, or the iemgui external library?
best, P
On 11/10/22 17:35, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 16:21]:
[...]
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui
Do you mean the now vanilla GUI objects once introduced by IEM, or the iemgui external library?
with "Pd-0.53's iemgui" i mean the built-in iemgui objects (like [tgl]).
but to keep the confusion going, i stumbled upon the issue while updating the iemgui external library.
gmasdr IOhannes
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 18:20]:
On 11/10/22 17:35, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 16:21]:
[...]
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui
Do you mean the now vanilla GUI objects once introduced by IEM, or the iemgui external library?
with "Pd-0.53's iemgui" i mean the built-in iemgui objects (like [tgl]).
but to keep the confusion going, i stumbled upon the issue while updating the iemgui external library.
Thanks! Should I be worried as Pd user and refrain from using 0.53.0 for now to not lose patches?
On 11/10/22 23:09, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 18:20]:
On 11/10/22 17:35, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 16:21]:
[...]
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui
Do you mean the now vanilla GUI objects once introduced by IEM, or the iemgui external library?
with "Pd-0.53's iemgui" i mean the built-in iemgui objects (like [tgl]).
but to keep the confusion going, i stumbled upon the issue while updating the iemgui external library.
Thanks! Should I be worried as Pd user and refrain from using 0.53.0 for now to not lose patches?
hmm, fair enough. luckily not all is bad.
TL;DR with the built-in iemguis, you should be fine. there is no (known) reason to worry that your patches might be lost when saving.
you should be on the watch, if you are using GUI-externals that use the iemgui infrastructure (the "iemgui" external, "moonlib",... probably others)
long story:
so what was i trying to say? (hard to tell, i might have been too confused the other day, i'll try again): Pd-0.53 overhauled the (built-in) iemguis and changed a bit of their interface (ABI). in general, Pd has a super stable API/ABI, which makes externals that were compiled 20 years ago still work with current Pds (at least: if you still have your trusty PowerPC around).
so why did the iemgui ABI break: honestly, because I think that the iemgui interface should not be part of the public interface of Pd *at all* (it's a complicated and ugly interface; it does a bad job of centralizing common functionality (just look at the same-same boilerplate code in each and every (old-style) iemgui object); and it adds computational overhead). i probably should have gone the full length of it, and remove the g_all_canvas.h file from Pd's public headers.
anyhow. because of the subtle ABI-change introduced by Pd-0.53, GUI-externals that use this ABI started to crash on various ends.
yesterday, i started fixing these issues for the "iemgui" external library. some of the crashes would appear when saving the patch, taking down the patchfile with them. some of the crashes originate from internal regressions of the iemgui API (as provided by Pd). luckily (and: iirc :-)) the two sets of crashes do not overlap.
i was possibly confusing myself (and you), because i spent the day dealing with a couple of serious bugs (crashes), and some of them needed fixing on the "external" side, and some fixing on the Pd-core (internal) side.
so sorry for all that.
gmards IOhannes
PS: originally i wanted to start this reply with a snide remark along the lines of "but you do have recent backups, don't you?", but thought better of it. nevertheless, you always *should* have proper backups of your patches (e.g. track them with something like git)
Thank you IOhannes, amazing explanation, as always! best, P
On 11/10/22 23:09, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 18:20]:
On 11/10/22 17:35, Peter P. wrote:
- IOhannes m zmoelnig zmoelnig@iem.at [2022-11-10 16:21]:
[...]
this in turn was triggered by a gruesome regression in Pd-0.53's iemgui
Do you mean the now vanilla GUI objects once introduced by IEM, or the iemgui external library?
with "Pd-0.53's iemgui" i mean the built-in iemgui objects (like [tgl]).
but to keep the confusion going, i stumbled upon the issue while updating the iemgui external library.
Thanks! Should I be worried as Pd user and refrain from using 0.53.0 for now to not lose patches?
hmm, fair enough. luckily not all is bad.
TL;DR with the built-in iemguis, you should be fine. there is no (known) reason to worry that your patches might be lost when saving.
you should be on the watch, if you are using GUI-externals that use the iemgui infrastructure (the "iemgui" external, "moonlib",... probably others)
long story:
so what was i trying to say? (hard to tell, i might have been too confused the other day, i'll try again): Pd-0.53 overhauled the (built-in) iemguis and changed a bit of their interface (ABI). in general, Pd has a super stable API/ABI, which makes externals that were compiled 20 years ago still work with current Pds (at least: if you still have your trusty PowerPC around).
so why did the iemgui ABI break: honestly, because I think that the iemgui interface should not be part of the public interface of Pd *at all* (it's a complicated and ugly interface; it does a bad job of centralizing common functionality (just look at the same-same boilerplate code in each and every (old-style) iemgui object); and it adds computational overhead). i probably should have gone the full length of it, and remove the g_all_canvas.h file from Pd's public headers.
anyhow. because of the subtle ABI-change introduced by Pd-0.53, GUI-externals that use this ABI started to crash on various ends.
yesterday, i started fixing these issues for the "iemgui" external library. some of the crashes would appear when saving the patch, taking down the patchfile with them. some of the crashes originate from internal regressions of the iemgui API (as provided by Pd). luckily (and: iirc :-)) the two sets of crashes do not overlap.
i was possibly confusing myself (and you), because i spent the day dealing with a couple of serious bugs (crashes), and some of them needed fixing on the "external" side, and some fixing on the Pd-core (internal) side.
so sorry for all that.
gmards IOhannes
PS: originally i wanted to start this reply with a snide remark along the lines of "but you do have recent backups, don't you?", but thought better of it. nevertheless, you always *should* have proper backups of your patches (e.g. track them with something like git)
Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> https://lists.puredata.info/listinfo/pd-list
-
Alexandros -
IOhannes m zmoelnig -
IOhannes m zmölnig
-
Lucas Cordiviola -
Patco -
Peter P.