Pd-dev October 2012

pd-dev@lists.iem.at

12 participants
92 discussions

[ pure-data-Patches-3303222 ] make sure patches get written to disk
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3303222, was opened at 2011-05-17 03:34 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3303222&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Closed Resolution: Accepted Priority: 6 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: make sure patches get written to disk Initial Comment: there is a very long standing (reported for pd-0.36cvs!) bug-report in debian (debian-bug#203288), claiming: <snip> pd: no error given when saving to a filesystem that is full When trying to save to a filesystem that is full, a 0 byte file is written and no error is given. </snip> with Pd-0.43, i get an error when saving too big patches on the filsystem in most cases (great), but some (e.g. creating a new empty patch, save that on the full fileystem) still reports everything as correct, even though only a 0 byte file gets written. a simple solution (attached) is to call fflush() at the end of binbuf_write() and check it's return value for success. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3303222&group_…

1 0

[ pure-data-Patches-3307503 ] segfault in DSP-loop detection
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3307503, was opened at 2011-05-25 06:32 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307503&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed Resolution: Accepted Priority: 8 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: segfault in DSP-loop detection Initial Comment: given a patch that contains a DSP-loop _and_ an [inlet~] _and_ and [outlet~] (see attached patch). if this file is opened as a toplevel patch (via File->Open) and you then turn on DSP, Pd will segfault. if [outlet~] is missing, Pd will give an error about "DSP-loop detected" and refuses to calculate (which is ok and expected). however, a segfault is not ok. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2011-07-30 12:50 Message: applied ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2011-05-25 06:36 Message: hunting down the bug i found that it crashes in the "fill borrowed outputs" loop around d_ugen.c:1064. the crash happens because dc_iosigs==NULL (due to the patch being run as toplevel ) and dc_noutlets==dc_ninlets==1 (because there is inlet~ and outlet~). this combination leads to an access of (*dc_iosigs)->s_borrowedFrom which is invalid (dc_iosigs==NULL) the attached patch tries to fix the underlying problem, by forcing dc_noutlets=dc_ninlets=0 if the toplevel flag is set. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3307503&group_…

1 0

[ pure-data-Patches-3438752 ] "pd -rt" crashes if pd-watchdog cannot be found
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3438752, was opened at 2011-11-16 04:37 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438752&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed Resolution: Accepted Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: "pd -rt" crashes if pd-watchdog cannot be found Initial Comment: i'm using Pd-0.43 (today's git) on linux (debian wheezy/sid which comes with gcc-4.6.1) if i start Pd in "realtime" mode (which is the default on linux) and it cannot find the "pd-watchdog" binary, Pd quits. i stumbled upon this bug, since i had no link from Pd/src/ to Pd/bin/, and started Pd from it's source directory. while i agree that my setup was somewhat broken as the pd-watchdog should have been in place, i strongly believe that Pd must not crash in these circumstances. it probably should drop realtime execution if it cannot find pd-watchdog, rather than crash. zmoelnig@ferrari:~/src/git/pure-data$ ls bin/pd-watchdog ls: cannot access bin/pd-watchdog: No such file or directory zmoelnig@ferrari:~/src/git/pure-data$ ./src/pd priority 6 scheduling enabled. priority 8 scheduling enabled. sh: ./bin/pd-watchdog: No such file or directory pd: watchdog process died zmoelnig@ferrari:~/src/git/pure-data$ pdsend errorname: >>error writing "sock8": broken pipe<< zmoelnig@ferrari:~/src/git/pure-data$ ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-06-30 14:17 Message: There should be some way to get git to check for trailing whitespace which I seem always to get warned of when applying your patches... ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-03-07 05:11 Message: i attached a small patch, that checks whether Pd can find a file named "pd-watchdog", and if not, disabled real-time mode. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3438752&group_…

1 0

[ pure-data-Patches-3481846 ] [bugfix] on start, the Pd window doesn't always show msgs
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3481846, was opened at 2012-01-30 17:41 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Closed Resolution: Accepted Priority: 8 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] on start, the Pd window doesn't always show msgs Initial Comment: Sometimes, when Pd starts, it only writes a portion of the stored ::pdwindow::logbuffer to the Pd Window. This tiny patch fixes that by waiting for the event loop before printing the logbuffer to the Pd window. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-09-08 20:16 Message: OK, I checked again and the patch made sense this time, but it's already in the code, so closing this. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-02-19 17:57 Message: Hmm, the attached file doesn't look loke a patch file (some HTM trash instead)??? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3481846&group_…

1 0

[ pure-data-Patches-3497084 ] fix for open_via_path() declaration headfizz
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3497084, was opened at 2012-03-05 09:41 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata-dev Group: None >Status: Closed Resolution: Accepted Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: fix for open_via_path() declaration headfizz Initial Comment: m_pd.h says that the parameters for open_via_path() are: "open_via_path(name, ext, dir, ...)" otoh, s_path.c implements the function as "open_via_path(dir, name, ext,...)" also the function is used as (dir, name, ext,...) throughout the code. the attached cosmetic patch fixes the function declaration in m_pd.h, so i don't get headfizz whenever i try to find out why i'm using the function correctly. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:12 Message: done (by hand, not sure when) ---------------------------------------------------------------------- Comment By: Mathieu BOUCHARD (mathieubouchard) Date: 2012-03-06 07:34 Message: Just imagine that the ministry of transportation puts the wrong signs on the autobahn. When it's time to fix them, they call the change «cosmetic». So, of course, they ask a beautician to take care of it. Do any changes to the docs also count as «cosmetic» ? Because help-intro.pd always listed classes that never existed, such as [powtorms~] and [rmstopow~]. I suppose that it's cosmetic too ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3497084&group_…

1 0

[ pure-data-Patches-3505262 ] slightly increase buffers when dealing with UTF8
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3505262, was opened at 2012-03-15 07:33 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: slightly increase buffers when dealing with UTF8 Initial Comment: running Pd through valgrind [1] gives a number of "Invalid read" errors, as soon as you create an object and type a single letter (e.g. "f"). creating the object (by licking besides it), gives another number of "Invalid read" errors. those errors suggest that memory outside the allocated buffer is accessed. it seems that all these errors are related to the UTF-8 code (since with utf-8 we might have to check multiple bytes). the attached fix simply increases the allocated buffer slightly (more than what happens already), so the read can take place on safe grounds. [1] like with $ valgrind --tool=memcheck --leak-check=full ./src/pd -noprefs -nrt -noaudio -stderr ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-06-22 15:19 Message: applied to 0.43-3 test ---------------------------------------------------------------------- Comment By: Marvin Humphrey (creamygoodness) Date: 2012-03-15 08:22 Message: The existing UTF-8 processing code assumes that strings are NUL-terminated and feels free to access that NUL byte beyond the buffer. However, the strings PD uses are always paired with a length, so it is possible to perform UTF-8 processing without going past the end of the buffer. That other patch gets rid of the overruns, and applying it should indeed clear the Valgrind errors that inspired both patches. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-03-15 07:47 Message: seems like it is duplicate patches day for me: https://sourceforge.net/tracker/?func=detail&aid=3420484&group_id=55736&ati… i haven't really checked the other patch, but it seems like it addresses the same issues while curing the cause rather than the symptoms. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3505262&group_…

1 0

[ pure-data-Patches-3518188 ] support loading [classname] from classname/classname.pd
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3518188, was opened at 2012-04-15 08:23 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: feature >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: support loading [classname] from classname/classname.pd Initial Comment: This patch adds support for loading [classname] from classname/classname.pd to match classname/classname.pd_linux support, which has been around a long time and proven quite useful. The patch adds classname/classname.pd as the last thing to try in the whole loading sequence, so it should not break anything, unless it is relying on the failure of an object to create. One example this patch supports is the [arduino] object, which is implemented as an abstraction. With this patch, everything can be included in a folder called "arduino/" from the help patch, the meta file, and the abstraction itself. This makes installation trivial, just drop the arduino folder in the right place, and also makes the arduino folder show up in the Help Browser. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:18 Message: accepted 0.44 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3518188&group_…

1 0

[ pure-data-Patches-3534907 ] Pd crashes when deleting (used) array via GUI
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3534907, was opened at 2012-06-13 08:22 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed Resolution: None Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: Pd crashes when deleting (used) array via GUI Initial Comment: via the properties of an array you can delete the given array (this is useful if you have multiple arrays in one graph and want to get rid of one) unfortunately doing so can lead to a crash, if the thus-deleted array is used in a DSP-object. the reason for this is that dsp-arrays will usually only check for the existence of a table when the dsp-graph is compiled (dsp-method), but the GUI-deletion does not trigger a re-compilation of the dsp-graph. attached is a small example patch to trigger the problem ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-06-22 15:18 Message: applied to 0.43-3 test ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-06-13 08:34 Message: attached is a git-patch against current head (0.43-2) that calls canvas_update_dsp() if the deleted array is flagged as being used in dsp calculations. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3534907&group_…

1 0

[ pure-data-Patches-3536805 ] [tabread4~] crashes with illegal tablesizes
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3536805, was opened at 2012-06-21 00:10 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: None >Status: Closed Resolution: Fixed Priority: 7 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [tabread4~] crashes with illegal tablesizes Initial Comment: as reported for the debian-package of Pd [1], pd can crash when using [tabread4~] and loading an invalid (raw) file into the table using [soundfiler]. "invalid" file means, that a (raw) file is read with a "headersize" (to skip) that is actually larger than the entire file. [soundfiler] will attempt to resize the table to something negative (since filelength-headersize<0) which will fail safely, and leave the table at a size=1. however, a [tabread4~] that accesses this table might segfault, since it needs more than 1 sample to interpolate. for a patch that triggers the problem, see [1]. it seems that the problem only appears on x86_64, and not on i386. [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=678306 ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-06-22 15:18 Message: applied to 0.43-3test ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-06-21 00:22 Message: attached is a patch that fixes the problem. the patch does: - make [soundfiler] fail if lseek(CUR)>lseek(EOF) (which is the case if the specified header is larger than the soundfile); this is not strictly necessary, since the array-resize will not resize to negative lengths. - make [tabread4~] fallback to zeroes, if the table is smaller than 4 samples. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3536805&group_…

1 0

[ pure-data-Patches-3494768 ] verbose() leaves blank lines when filtered out in Pd window
by SourceForge.net 04 Oct '12

04 Oct '12

Patches item #3494768, was opened at 2012-02-26 08:10 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_… Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: puredata Group: bugfix >Status: Closed Resolution: Accepted Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: verbose() leaves blank lines when filtered out in Pd window Initial Comment: When lines are posted to the Pd window using verbose() and then the Pd window is set to display at a lower level than the verbose() posted at, the lines that were posted using verbose() will be filtered, but will leave a blank line in their place. lines posted with logpost() do not do this. For example, if I post three lines using verbose() like this: verbose(3, "three"); verbose(4, "four"); verbose(3, "three"); Setting the log level to four will show: three four three Setting the log level to 3 will show: three three When it should show: three three I'm assigning this to IOhannes because I think he wrote the current verbose() function. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2012-08-31 17:10 Message: applied (0.44) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2012-02-27 06:32 Message: That was quick. The solution makes sense to me. But I think its a bad idea to change to loglevel+4 to loglevel+3. Either leave verbose()'s custom level numbering the same, or make it the same as the Pd window, error(), logpost(), etc.. I still really think the +4 on the loglevel doesn't make sense. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:57 Message: attached is a fix for the problem (thus changing Tracker to 'Patches' and assigning to miller) it also closes the gap between verbose() and post() by applying a loglevel-offset of '3' rather than '4' (so now verbose(0) (loglevel=3) is following post() (loglevel=2) immediately. ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2012-02-27 04:52 Message: the problem comes from the use of endpost() to terminate the message. endpost() doesn't know anything about log-levels, so it tags all LFs as "normal". i can think of 2 ways to fix this: - don't use endpost() to terminate a message, but instead append the "\n" to the message itself (which get's tagged with the log-level) - make endpost() aware of the last used loglevel and terminate any message using this level i'd rather go for the 1st solution, as it doesn't require any global state... ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=3494768&group_…

1 0

← Newer
1
2
3
4
5
6
7
8
9
10
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

Pd-dev October 2012