Pd-dev January 2008

pd-dev@lists.iem.at

27 participants
93 discussions

snprintf vs. sprintf_s?
by Miller Puckette 19 Jan '08

19 Jan '08

Hi Devs, I found out that .Net apparently doesn't use "snprintf" but has a similar function named "sprintf_s". (A couple of recent patches change "sprintfs" to "snprintfs" leading to compile errors in .Net). I'm thinking of just putting the following in s_main.c and s_file.c: #ifdef MSW #define snprinf sprintf_s #endif My question: will this break cygwin or some other non-microsoft compiler for Windows? thanks Miller

7 13

"declare" strangeness in abstractions (0.41 test10)
by Frank Barknecht 18 Jan '08

18 Jan '08

Hi, I checked out the behaviour of [declare] in the latest test version, which supposedly should have some fixes according to the release notes: Fixed "declare" which wasn't working properly yet in 0.40-0, and made more objects (notably "soundfiler") respect "declared" paths. Path entries are relative to the parent patch. Declares inside abstractions are ignored. Now I'm not sure, if simply ignoring declares in abstractions is the right thing (tm) to do. Using the declare-bug.tgz examples from Bug #1714473 I now cannot make abstractions evaluate declares anymore. This seems to be intended, but why? The example uses an abstraction, "myabs/test-patch-with-deep-declare" that includes an instance of [abuse-me], which by [declare -path ./sub] inside "myabs/test-patch-with-deep-declare.pd" should be taken from "myabs/sub/abuse-me.pd". But, alas, this isn't found and thus "myabs/test-patch-with-deep-declare" is broken. Opening "myabs/test-patch-with-deep-declare.pd" directly will make it find the correct abuse-me.pd in myabs/sub/abuse-me.pd I believe, the correct behaviour would be to not ignore the declares in abstractions, but make them act relative to the abstraction's path. Otherwise abstractions would behave differently when opened directly compared to when used as abstractions, which I think is very confusing. Ciao -- Frank Barknecht _ ______footils.org__

4 11

[ pure-data-Bugs-1874767 ] hostname from hcs crashes
by SourceForge.net 18 Jan '08

18 Jan '08

Bugs item #1874767, was opened at 2008-01-18 15:42 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1874767&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: externals Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: oli44 (oli44) Assigned to: Nobody/Anonymous (nobody) Summary: hostname from hcs crashes Initial Comment: hello, following message when banging the hostname object from hcs lib Patch: [bang( | [hostname] | [print] Debian Etch pd extended stable 20071224 olivier@puredell:~/puredata$ pd tk scaling is 1.33333333333 *** glibc detected *** malloc(): memory corruption: 0x082cc980 *** Pd: signal 6 I can repeat the bug anytime after an update to pd-e stable 20080112 olivier@puredell:~/puredata$ pd tk scaling is 1.33333333333 *** glibc detected *** malloc(): memory corruption: 0x08284f28 *** Pd: signal 6 olivier@puredell:~/puredata$ pd tk scaling is 1.33333333333 *** glibc detected *** malloc(): memory corruption: 0x08287ee8 *** Pd: signal 6 ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1874767&group_…

1 0

o profiling PD
by B. Bogart 18 Jan '08

18 Jan '08

Hey all, I'm trying to track down a strange baseline CPU usage in a patch of mine. Basically I load the patch and it will show a certain baseline CPU amount, even with audio off, no rendering, and no control messages flowing (except for those initially set off by the loadbangs). loading with -noloadbang does not show the baseline CPU. The amount of CPU seems proportional to the number of abstractions in the patch (about 800 kills the machine at 90%+, 400 uses about 40%) So I'd like to see what PD functions are using up all the CPU. I've compiled a PD with ./configure --enable-debug and I do see the -g in the makefile, but oprofile still only shows "pd" as a blackbox. For Gem I needed to do something with the "strip" stuff, but I don't see any corresponding features in the PD makefile. Any suggestions? Thanks all, B. Bogart

2 2

[ pure-data-Patches-1858772 ] Add a new Pd command line option, -autoload
by SourceForge.net 17 Jan '08

17 Jan '08

Patches item #1858772, was opened at 2007-12-26 21:41 Message generated for change (Comment added) made by russellbryant You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1858772&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: None Priority: 5 Private: No Submitted By: Russell Bryant (russellbryant) Assigned to: Nobody/Anonymous (nobody) Summary: Add a new Pd command line option, -autoload Initial Comment: I got tired of using the "-lib" option over and over, so I wrote a new option, "-autoload". This option allows you to specify a directory of externals. All externals found in this directory, and any sub-directories, will be automatically loaded. So, you can run pd using something like ... $ pd -autoload /usr/lib/pd/extra or a non-default location of externals where some have just been compiled, for example ... $ pd -autoload ~/src/pure-data/pd/extra So far, the patch has only been tested on Linux. ---------------------------------------------------------------------- >Comment By: Russell Bryant (russellbryant) Date: 2008-01-16 17:39 Message: Logged In: YES user_id=1942915 Originator: YES I'm closing this out for now after a discussion on the pd-dev list. It's not clear whether this patch really makes sense, so I'm going to sit on it for a while. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1858772&group_…

1 0

marking 'taken' patches as closed?
by Miller Puckette 16 Jan '08

16 Jan '08

Hi all, Any reason I shouldn't just go ahead and mark patches as 'closed' when I apply them? It's less clear what to do about bugs when I think I've fixed them, since a fair percentage of the time they cmoe back later in another form. I'm guessing that if I claim one is fixed and if nobody else comments for a few weeks, it's OK for me to close it. BTW, at the moment I'm just trying to fix bugs and document changes for 0.41 so it should come out in a week or so. cheers Miller

3 3

[ pure-data-Patches-1835093 ] Corrected help patch for [swap]
by SourceForge.net 16 Jan '08

16 Jan '08

Patches item #1835093, was opened at 2007-11-20 12:42 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1835093&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: documentation >Status: Pending >Resolution: Accepted Priority: 5 Private: No Submitted By: Frank Barknecht (fbar) Assigned to: Miller Puckette (millerpuckette) Summary: Corrected help patch for [swap] Initial Comment: As Chuckk Hubbard noted, the help file for[swap] has left and right swapped in some places. Attached is a corrected help patch ready to be dropped in as a replacement with an added example use for swap. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 19:44 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1835093&group_…

1 0

[ pure-data-Bugs-1841758 ] setitimer invalid timeval
by SourceForge.net 16 Jan '08

16 Jan '08

Bugs item #1841758, was opened at 2007-11-30 15:49 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&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: ClaudiusMaximus (claudiusmaximus) Assigned to: Nobody/Anonymous (nobody) Summary: setitimer invalid timeval Initial Comment: Pd's scheduler seems to have a bug regarding setitimer, which leads to messages in the system log: setitimer: pd (pid = 3401) provided invalid timeval it_value: tv_sec = 0 tv_usec = 1000000 (with a clock delaytime of 1000ms) man setitimer says: ----8<---- POSIX.1-2001 says that setitimer() should fail if a tv_usec value is specified that is outside of the range 0 to 999999. However, Linux does not give an error, but instead silently adjusts the corresponding seconds value for the timer. In the future (scheduled for March 2007), this non-conformance will be repaired: existing applications should be fixed now to ensure that they supply a properly formed tv_usec value. ----8<---- This is with pd-0.40-3 from Miller's site, on GNU/Linux Debian Etch, but I've noticed this issue on various other Linux distros. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 19:30 Message: Logged In: YES user_id=313747 Originator: NO taken ---------------------------------------------------------------------- Comment By: IOhannes m zmölnig (zmoelnig) Date: 2008-01-02 13:43 Message: Logged In: YES user_id=564396 Originator: NO i have submitted a fix for this as patch#1862148 https://sourceforge.net/tracker/index.php?func=detail&aid=1862148&group_id=… ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1841758&group_…

1 0

[ pure-data-Patches-1862148 ] [bugfix] setitimer invalid timeval
by SourceForge.net 16 Jan '08

16 Jan '08

Patches item #1862148, was opened at 2008-01-02 13:41 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&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: Pending Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] setitimer invalid timeval Initial Comment: as described by claude in bug#1841758 (https://sourceforge.net/tracker/index.php?func=detail&aid=1841758&group_id=…) there is a small bug in the use of setitimer() in sys_setalarm(). the problem is, that the setitimer() API has changed in order to be POSIX-conformant and Pd has not yet adapated to this change. the attached patch fixes the problem, by splitting the given "microsec" value into seconds and microseconds. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 19:37 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&group_…

1 0

[ pure-data-Patches-1862148 ] [bugfix] setitimer invalid timeval
by SourceForge.net 16 Jan '08

16 Jan '08

Patches item #1862148, was opened at 2008-01-02 13:41 Message generated for change (Settings changed) made by zmoelnig You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&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: Open Resolution: Accepted Priority: 5 Private: No Submitted By: IOhannes m zmölnig (zmoelnig) Assigned to: Miller Puckette (millerpuckette) Summary: [bugfix] setitimer invalid timeval Initial Comment: as described by claude in bug#1841758 (https://sourceforge.net/tracker/index.php?func=detail&aid=1841758&group_id=…) there is a small bug in the use of setitimer() in sys_setalarm(). the problem is, that the setitimer() API has changed in order to be POSIX-conformant and Pd has not yet adapated to this change. the attached patch fixes the problem, by splitting the given "microsec" value into seconds and microseconds. ---------------------------------------------------------------------- Comment By: Miller Puckette (millerpuckette) Date: 2008-01-14 19:37 Message: Logged In: YES user_id=313747 Originator: NO taken. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862148&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 January 2008