Pd-dev August 2007

pd-dev@lists.iem.at

21 participants
40 discussions

[ pure-data-Bugs-1776553 ] Message boxes seem to behave inconsistently
by SourceForge.net 18 Aug '07

18 Aug '07

Bugs item #1776553, was opened at 2007-08-17 22:02 Message generated for change (Comment added) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776553&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: Open Resolution: None Priority: 5 Private: No Submitted By: r jacobs (rnjacobs) Assigned to: Nobody/Anonymous (nobody) Summary: Message boxes seem to behave inconsistently Initial Comment: I don't know whether this is an actual bug, but it is a strange inconsistency. In using PD 0.40-2 in the Debian archive, the attached patch (three message boxes, containing a list "1 2 3", an anything "a b c", and "$1 $2") produces the output r: 1 2 3 p: 1 2 r: a b c p: b c I assume the reason the last line is "b c" instead of "a b" is because the message box sees that the input is an anything and interprets "a" as a type. But "a" isn't a type, so there is no way to get the first element of an anything using a message box (yes, i could use an unpack, so there's definitely workarounds). Is this a bug? Thank you! ---------------------------------------------------------------------- Comment By: Matteo Sisti Sette (sistisette) Date: 2007-08-18 16:14 Message: Logged In: YES user_id=1709568 Originator: NO No, the behaviour is correct (or at least, consistent). In the message [a b c(, "a" is the "message identifier" (not sure the terminology I'm using is correct)... that's what you call the "type", but it need not be a type (such as symbol float or list). So b and c are the first and second arguments. "a" is not an argument. If you want to get the first element (i.e. the identifier) you need to convert the anything message into a list, so that the identifier is converted into the first argument, i.e.: [a b c( | [list] <-- this outputs "list a b c" | [$1 $2( Hope this helped. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776553&group_…

1 0

[ pure-data-Bugs-1776891 ] [until] hangs if started with a negative number
by SourceForge.net 18 Aug '07

18 Aug '07

Bugs item #1776891, was opened at 2007-08-18 16:03 Message generated for change (Settings changed) made by sistisette You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776891&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: v0.40.2 Status: Open Resolution: None >Priority: 2 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: [until] hangs if started with a negative number Initial Comment: If you send a negative number to an [until] object, it behaves as if you sent it a bang: i.e., it iterates an infinite number of times (unless a bang is received in the right inlet stopping the iterations). Instead, it should either treat a negative number as zero, or generate an error message when it receive a negative number. The documentation (i.e. help patch) says: "If you start "until" with a number, it iterates at most that number of times". Though "iterating at most -21 times" means nothing strictly speaking, it would make much more sense if it didn't iterate at all. Also, it would be a warranty that sending it a number would never ever cause an infinite loop. You may argue that sending [until] a [-21( is like writing: for (int i=0; i<-21; i++) which produces an infinite loop. However, that's not the way [until] is described in the documentation. No initialization, testing condition and increment are mentioned. So it should rather be compared to languages where a for loop looks like: for i = M to N In such languages, using M>N *usually* produces either a decrementing i or no iteration at all. Finally, if one actually does want an infinite loop (obviously taking care of using the right inlet to stop it) s/he can do it with a [bang( message. Obviously this is a minor issue, as one can always put a [max 0] before [until] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776891&group_…

1 0

[ pure-data-Bugs-1776891 ] [until] hangs if started with a negative number
by SourceForge.net 18 Aug '07

18 Aug '07

Bugs item #1776891, was opened at 2007-08-18 16:03 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=1776891&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: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Matteo Sisti Sette (sistisette) Assigned to: Nobody/Anonymous (nobody) Summary: [until] hangs if started with a negative number Initial Comment: If you send a negative number to an [until] object, it behaves as if you sent it a bang: i.e., it iterates an infinite number of times (unless a bang is received in the right inlet stopping the iterations). Instead, it should either treat a negative number as zero, or generate an error message when it receive a negative number. The documentation (i.e. help patch) says: "If you start "until" with a number, it iterates at most that number of times". Though "iterating at most -21 times" means nothing strictly speaking, it would make much more sense if it didn't iterate at all. Also, it would be a warranty that sending it a number would never ever cause an infinite loop. You may argue that sending [until] a [-21( is like writing: for (int i=0; i<-21; i++) which produces an infinite loop. However, that's not the way [until] is described in the documentation. No initialization, testing condition and increment are mentioned. So it should rather be compared to languages where a for loop looks like: for i = M to N In such languages, using M>N *usually* produces either a decrementing i or no iteration at all. Finally, if one actually does want an infinite loop (obviously taking care of using the right inlet to stop it) s/he can do it with a [bang( message. Obviously this is a minor issue, as one can always put a [max 0] before [until] ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776891&group_…

1 0

strange canvas behaviour
by glerm soares 18 Aug '07

18 Aug '07

Hello, I found a strange behaviour in canvas object. I don't know if it it operational system related, but anyway It's happening here and could happen with others. The situation is: When I send a symbol # to a canvas label (with the intention of use this as a "panel") it's converted for the symbol $ ... someting like: C# | ; cnv_test label $1 / it results in canvas printing: C$ there's a patch attached with an example. my system is Linux (Ubuntu Feisty - Gnome Desktop) kernel 2.6.20-26-generic locale pt_BR thanks glerm

2 4

[ pure-data-Bugs-1776553 ] Message boxes seem to behave inconsistently
by SourceForge.net 17 Aug '07

17 Aug '07

Bugs item #1776553, was opened at 2007-08-17 16:02 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=1776553&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: Open Resolution: None Priority: 5 Private: No Submitted By: r jacobs (rnjacobs) Assigned to: Nobody/Anonymous (nobody) Summary: Message boxes seem to behave inconsistently Initial Comment: I don't know whether this is an actual bug, but it is a strange inconsistency. In using PD 0.40-2 in the Debian archive, the attached patch (three message boxes, containing a list "1 2 3", an anything "a b c", and "$1 $2") produces the output r: 1 2 3 p: 1 2 r: a b c p: b c I assume the reason the last line is "b c" instead of "a b" is because the message box sees that the input is an anything and interprets "a" as a type. But "a" isn't a type, so there is no way to get the first element of an anything using a message box (yes, i could use an unpack, so there's definitely workarounds). Is this a bug? Thank you! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1776553&group_…

1 0

[ pure-data-Bugs-1767751 ] shell portability fixes for configure.in
by SourceForge.net 17 Aug '07

17 Aug '07

Bugs item #1767751, was opened at 2007-08-04 17:19 Message generated for change (Settings changed) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1767751&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: v0.40.2 Status: Open Resolution: None Priority: 5 Private: No Submitted By: Klaus Heinz (kheinz) >Assigned to: Miller Puckette (millerpuckette) >Summary: shell portability fixes for configure.in Initial Comment: Hi, configure.in (and configure) contains unportable shell syntax. The declared shell for configure, /bin/sh, is not always a link to bash or ksh, which both support == in comparisons. The original syntax for /bin/sh only accepts = as comparison operator. The appended fix changes == to =. ciao Klaus Heinz ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1767751&group_…

1 0

[ pure-data-Bugs-1770553 ] image object does not like spaces
by SourceForge.net 16 Aug '07

16 Aug '07

Bugs item #1770553, was opened at 2007-08-08 21:51 Message generated for change (Comment added) made by eighthave You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1770553&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: Accepted Priority: 5 Private: No Submitted By: marius schebella (mariusschebella) Assigned to: Frank Barknecht (fbar) Summary: image object does not like spaces Initial Comment: when I create [image test.gif] and any of the folders in the path to test.gif contains a space then [image] will not find it. even if test.gif is in the same folder. intel mac. versions pd-extended-0.39.3-rc5 and also 0.40. marius. ---------------------------------------------------------------------- >Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-08-15 19:15 Message: Logged In: YES user_id=27104 Originator: NO I tried [file join] and {} instead of "" and neither handled using " in a filename. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-08-15 04:06 Message: Logged In: YES user_id=569446 Originator: NO Hi Hans, I've found some docs regarding platform independent filename handling in Tcl using "file join" and "file split" here: http://www.tcl.tk/man/tcl8.4/TclCmd/file.htm However I don't know how to add this to the code in image.c. Any ideas? Ciao -- Frank ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-08-14 16:03 Message: Logged In: YES user_id=27104 Originator: NO Since the line in question is a line of Tcl, I am sure Tcl has standard methods of handling file names that will deal with all this... ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-08-11 12:53 Message: Logged In: YES user_id=569446 Originator: NO Allow me to reopen this as a Bug, as 1) I didn't yet get any confirmation if the space problem is indeed fixed, but 2) more importantly a proper solution should not fail on other circumstances like the mentioned doublequotes. -- fbar ---------------------------------------------------------------------- Comment By: marius schebella (mariusschebella) Date: 2007-08-10 08:48 Message: Logged In: YES user_id=1856112 Originator: YES tested with autobuilds from /auto-build/2007-08-10 Pd-0.40.3-extended-20070810-macosx104-i386.dmg and Pd-0.39.3-extended-macosx104-i386.dmg. unfortunately no difference in behaviour, strange. m. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-10 08:21 Message: Logged In: NO it still breaks for filenames that contain doublequotes. ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-08-09 03:28 Message: Logged In: YES user_id=569446 Originator: NO sorry, wrong patch, please test this one. File Added: image-spaces-fixed.diff ---------------------------------------------------------------------- Comment By: Frank Barknecht (fbar) Date: 2007-08-09 03:25 Message: Logged In: YES user_id=569446 Originator: NO Can you check, if attached oneline change fixes it? File Added: image-spaces.diff ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1770553&group_…

1 0

[ pure-data-Patches-1775023 ] use Tcl's normalize to clean up pd_guidir on OSX and Win32
by SourceForge.net 16 Aug '07

16 Aug '07

Patches item #1775023, was opened at 2007-08-15 18:35 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1775023&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: None Priority: 5 Private: No Submitted By: Hans-Christoph Steiner (eighthave) Assigned to: Miller Puckette (millerpuckette) Summary: use Tcl's normalize to clean up pd_guidir on OSX and Win32 Initial Comment: A minor cleanup to simplify pd_guidir using Tcl's [file normalize] on Mac OS X and Win32. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1775023&group_…

1 0

gem ortho
by nosehair911＠bellsouth.net 15 Aug '07

15 Aug '07

I am trying to convert an opengl app to a gem object but I am still a bit confused as to the ortho thing. I have it pretty much converted but I can only see it using ortho and it looks very small. This app is made to be viewed using gluOrtho2D ( 0.0, 1.0, 0.0, 1.0 ); but I cant figure out how to see it right in gem. I have tried using perspect in conbination with view but I dont think I quite get what to do with it. Any help? Thanks, Alain

1 0

any time to look at Gem bugs?
by Hans-Christoph Steiner 15 Aug '07

15 Aug '07

Hey all, Right now, I am at the point where the only outstanding issues with Pd-extended are the ones I filed in the Gem bug tracker. I was wondering whether anyone will have any time in the near future to look at these. Otherwise, I'll make the release, and they can be addressed in the next release (which would be a bummer for a lot of GNU/Linux users). .hc ------------------------------------------------------------------------ ---- The arc of history bends towards justice. - Dr. Martin Luther King, Jr.

1 0

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 August 2007