Bugs item #1573656, was opened at 2006-10-09 13:06
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&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.1
Status: Open
Resolution: None
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: $arg-expansion gives error with old patches
Initial Comment:
with the advent of the new and better $arg-expansion
(namely: expansion of $args _within_ an argument, like
bla-$2-blu), old patches (<0.40) that used dollars
within symbols are somewhat broken.
example1: iemlib provides an object [parentdollarnull]
with an alias [parent$0]; the latter gets expanded
(e.g. to [parent1003]) and cannot be created.
THIS IS NO BUG (imho)
however, $0 is not only expanded on a logic level, but
also on a visible level (i really see [parent1003]);
this i believe IS a bug.
example2 (more important!): in the olde times, if a
symbol contained dollars within, it was saved (in the
.pd file) like "bla-$2-blu".
in pd=0.40.0, the same symbol gets saved as
"bla-\$2-blu" (note the backslash).
loading an old abstraction yields an error ("argument
out of range"), even if enough arguments (in this case:
2) are supplied.
the expansion works correctly though!
imho, either the warning should be supressed or the old
behaviour (no expansion) should be preserved.
(it would be good if the pd-version at the time of
saving would be stored in the .pd-fileformat in order
to allow such things)
this little script should replace all "$<n>" with a
missing backslash at the beginning with "\$<n>"
find . -name "*.pd" | while read f
do
sed -i -e 's|\([^\\]\)\$|\1\\$|g' $f
done
note on the script: i haven't done excessive testing,
but it seems to work; make backups before you apply it,
since it will change all affected files without asking)
note: it seems like old versions (tested with
pd-0.39-2) seem to be able to correctly read files
saved with pd-0.40-0
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-10-09 13:11
Message:
Logged In: YES
user_id=564396
also confirmed with 0.40.1
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&group_…
Bugs item #1573656, was opened at 2006-10-09 13:06
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=1573656&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.0
Status: Open
Resolution: None
Priority: 5
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: $arg-expansion gives error with old patches
Initial Comment:
with the advent of the new and better $arg-expansion
(namely: expansion of $args _within_ an argument, like
bla-$2-blu), old patches (<0.40) that used dollars
within symbols are somewhat broken.
example1: iemlib provides an object [parentdollarnull]
with an alias [parent$0]; the latter gets expanded
(e.g. to [parent1003]) and cannot be created.
THIS IS NO BUG (imho)
however, $0 is not only expanded on a logic level, but
also on a visible level (i really see [parent1003]);
this i believe IS a bug.
example2 (more important!): in the olde times, if a
symbol contained dollars within, it was saved (in the
.pd file) like "bla-$2-blu".
in pd=0.40.0, the same symbol gets saved as
"bla-\$2-blu" (note the backslash).
loading an old abstraction yields an error ("argument
out of range"), even if enough arguments (in this case:
2) are supplied.
the expansion works correctly though!
imho, either the warning should be supressed or the old
behaviour (no expansion) should be preserved.
(it would be good if the pd-version at the time of
saving would be stored in the .pd-fileformat in order
to allow such things)
this little script should replace all "$<n>" with a
missing backslash at the beginning with "\$<n>"
find . -name "*.pd" | while read f
do
sed -i -e 's|\([^\\]\)\$|\1\\$|g' $f
done
note on the script: i haven't done excessive testing,
but it seems to work; make backups before you apply it,
since it will change all affected files without asking)
note: it seems like old versions (tested with
pd-0.39-2) seem to be able to correctly read files
saved with pd-0.40-0
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1573656&group_…
Bugs item #1572310, was opened at 2006-10-06 14:20
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572310&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.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: after Save As..., the path remains at the location
Initial Comment:
If you open an instance of an abstraction, then Save
As... to somewhere else, the path of that abstraction
stays at the original location, even though the file
was saved to the new location. Clicking File->Save
will then save to the original location rather than the
new location.
Tested on Mac OS X with Pd-0.39.2,
Pd-0.39.2-extended-test5, and Pd-0.40-0.
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-10-07 17:49
Message:
Logged In: YES
user_id=27104
"Save As..." means write out a new file. A new file means a
new class. The instance that started this process remains
the old class, therefore is no longer related to this new class.
This means its inconsistent to have this instance remain as
the original class.
Also, from a usability perspective, it makes things much
more coherent. In every other app that I use, when I do
"Save As...", that current view changes to the new file. It
does not remain on the old file.
----------------------------------------------------------------------
Comment By: Frank Barknecht (fbar)
Date: 2006-10-07 07:53
Message:
Logged In: YES
user_id=569446
I'm note sure if that's a bug, though I agree, that it's
confusing. But if you open an instance of an abstraction and
save that under a different name, this action doesn't affect
the name of the abstraction's instance as it is used in the
parent patch: This one will stay the same. If you want to
use your newly saved abstraction you need to rename the
instance to the new name as well first.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572310&group_…
Bugs item #1572310, was opened at 2006-10-06 20:20
Message generated for change (Comment added) made by fbar
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572310&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.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: after Save As..., the path remains at the location
Initial Comment:
If you open an instance of an abstraction, then Save
As... to somewhere else, the path of that abstraction
stays at the original location, even though the file
was saved to the new location. Clicking File->Save
will then save to the original location rather than the
new location.
Tested on Mac OS X with Pd-0.39.2,
Pd-0.39.2-extended-test5, and Pd-0.40-0.
----------------------------------------------------------------------
>Comment By: Frank Barknecht (fbar)
Date: 2006-10-07 13:53
Message:
Logged In: YES
user_id=569446
I'm note sure if that's a bug, though I agree, that it's
confusing. But if you open an instance of an abstraction and
save that under a different name, this action doesn't affect
the name of the abstraction's instance as it is used in the
parent patch: This one will stay the same. If you want to
use your newly saved abstraction you need to rename the
instance to the new name as well first.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572310&group_…
Bugs item #1572310, was opened at 2006-10-06 14:20
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=1572310&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.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: after Save As..., the path remains at the location
Initial Comment:
If you open an instance of an abstraction, then Save
As... to somewhere else, the path of that abstraction
stays at the original location, even though the file
was saved to the new location. Clicking File->Save
will then save to the original location rather than the
new location.
Tested on Mac OS X with Pd-0.39.2,
Pd-0.39.2-extended-test5, and Pd-0.40-0.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572310&group_…
Bugs item #1572290, was opened at 2006-10-06 13:48
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=1572290&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.0
Status: Open
Resolution: None
Priority: 5
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: serious troubles with folders with non-ASCII chars on WinXP
Initial Comment:
On Windows XP, you cannot save a new file to any
directory that has non-ASCII characters in it. For
example, if someone has an accented E in their
username, then their home folder will be in
C:\Documents and Settings\USERNAME, where USERNAME is
the name with the accented E.
The work around is to save to the root of C:\, then
move the file to the directory with the non-ASCII
chars. After that, it is possible to save changes.
But the only way to open the file is to double-click it
and let it open via file associations. File->Open
crashes Pd-0.40-2 and nothing happens on
Pd-0.39.2-extended-test5.
This has been confirmed on Pd-0.39.2-extended-test5 and
Pd-0.40-0, on Windows XP US and Spanish editions.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1572290&group_…
This is a quick howto on how to build Mac OS X Universal binaries
with autoconf-based build systems:
http://developer.apple.com/documentation/Porting/Conceptual/
PortingUnix/compiling/chapter_4_section_3.html
.hc
------------------------------------------------------------------------
Looking at things from a more basic level, you can come up with a
more direct solution... It may sound small in theory, but it in
practice, it can change entire economies. - Amy Smith
Bugs item #1378911, was opened at 2005-12-12 10:10
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1378911&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.38.4
>Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: B. Bogart (bbogart)
Assigned to: Nobody/Anonymous (nobody)
Summary: pd filename extension not added on OSX port
Initial Comment:
On linux when you do "file" -> "save" and type the
filename "mypatch" then PD will save a file called
"mypatch.pd" if you do the same on OSX, you end up with
a file called "mypatch" without the extension. One must
manually add the extension to open the file.
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-04 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-09-20 08:46
Message:
Logged In: YES
user_id=27104
I confirmed that both of these bugs existed in Pd-extended
0.38.4 on Mac OS X. I also confirmed that neither of these
bugs exist in Pd-0.39.2-extended-test5.
----------------------------------------------------------------------
Comment By: B. Bogart (bbogart)
Date: 2005-12-12 10:14
Message:
Logged In: YES
user_id=117349
Frank Barknecht adds that the filename extension on linux
ONLY gets added "only if the name doesn't contain any dots.
This has bitten me several times when trying to save a
rrad.osc~ file, which wouldn't get an appended .pd, too."
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1378911&group_…
Patches item #1368474, was opened at 2005-11-28 10:24
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1368474&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: None
Group: None
>Status: Closed
Resolution: None
Priority: 5
Submitted By: Mathieu Bouchard (matju)
Assigned to: Nobody/Anonymous (nobody)
Summary: expr~ unused vars
Initial Comment:
removed unused vars in expr~ that cause pagefuls of
warnings when compiling with -Wall
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2006-10-03 19:20
Message:
Logged In: YES
user_id=1312539
This Tracker item was closed automatically by the system. It was
previously set to a Pending status, and the original submitter
did not respond within 14 days (the time period specified by
the administrator of this Tracker).
----------------------------------------------------------------------
Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2006-09-19 00:06
Message:
Logged In: YES
user_id=564396
no patch enclosed
might be duplicated by patch #1561099
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1561099&group_…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1368474&group_…