Bugs item #2062558, was opened at 2008-08-20 08:12
Message generated for change (Comment added) made by millerpuckette
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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.41.0
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4 mac binary doesn't accept arguments
Initial Comment:
The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes.
Please bring back this useful feature!
----------------------------------------------------------------------
>Comment By: Miller Puckette (millerpuckette)
Date: 2008-08-21 11:48
Message:
Logged In: YES
user_id=313747
Originator: NO
Wierd... I get this too. As a temporary workaround, instead of working
inside the
"App", just untar the source, ./configure and make -- then the args work,
I think.
I'll try to figure out why they don't when it's an App...
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 00:35
Message:
Logged In: YES
user_id=564396
Originator: NO
funnily enough we decided yesterday to file a bug-report about this very
issue, but thomas was faster :-)
it is _really_ annoying when doing development/debugging.
interestingly enough, the only argument i found that actually was accepted
is "-help", which gives you all the arguments that are unfortunately
ignored...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&group_…
Bugs item #1996275, was opened at 2008-06-17 18:38
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&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: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: floats show as 6 digits, but implemented at higher precision
Initial Comment:
Sometimes some duplicates get through [change] since it is doing a != for the comparison. Instead it should do a comparison with a set precision, something like this:
http://howto.wikia.com/wiki/Howto_compare_float_numbers_in_the_C_programmin…
//compares if the float f1 is equal with f2 and returns 1 if true and 0 if false
int compare_float(float f1, float f2)
{
float precision = 0.00001;
if (((f1 - precision) < f2) &&
((f1 + precision) > f2))
{
return 1;
}
else
{
return 0;
}
}
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 10:16
Message:
Logged In: YES
user_id=564396
Originator: NO
i just had a look at your "long_floats.pd" and noticed that it works as i
would have expected it: the numbers are kept internally at the precision
you entered in emacs.
i attached a patch "long_floats2.pd" that actually does something more
than just showing an object [f 0.123457] but actually tries to display what
is going on behind the scenes.
in short
if you have a float
#X 100 100 obj f 0.123456789;
and another float
#X 200 100 obj f 0.123457;
both will show up as [f 0.123457] but you can subtract them and get a
non-0 result (which is ok, as 0.123456789-0.123457 IS non-0);
the actual result is _wrong_ (which would be a good bug to report!)
all the problem stems from the fact the the graphical environment Pd is 2
things at the same time:
- a program editor
- a runtime environment
and the focus is on runtime environment.
in a runtime-environment you probably don't want to be dizzied by
nitpicking problems of the floating-point precision and its representation;
in an editor you just want to save your intention rather than what the
program thinks your intentions are.
and yes, you are right that the actual "culprit" is the binbuf->text
conversion; this is used for saving to patch as well as displaying in the
GUI, so both of them lack the full precision.
loading is unaffected!
File Added: long_floats2.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-25 16:09
Message:
Logged In: YES
user_id=27104
Originator: YES
I updated float-precision-misrepresentation.pd to make it clear that the
width of the object box is not causing the rounding.
File Added: float-precision-misrepresentation.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-25 16:07
Message:
Logged In: YES
user_id=27104
Originator: YES
So this doesn't just happen on saving, but also on loading. I attached
long_floats.pd which I edited with emacs to have 9 digit floats. They get
rounded to 6 digits upon load.
Also, just typing a number with more than 6 digits into an object box
rounds it once the object is created. So my guess is that this problem is
caused by conversion to binbufs rather than saving the file as was
previously mentioned.
File Added: long_floats.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-25 05:37
Message:
Logged In: YES
user_id=27104
Originator: YES
"floats show as 6 digits, but implemented at higher precision" outlines
the inconsistency, which is the bug in question. Feel free to rewrite the
title if you think you can make a clearer description. (But please don't
do it out of spite, like switching the bug to Invalid.)
This is the key to this problem:
[float 0.100000001490116119384765625] gets rounded to 6 digits. I don't
know the exact source of the problem. If you do, please tell us.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-24 17:21
Message:
Logged In: YES
user_id=564396
Originator: NO
my patch 10percent.pd illustrated exactly the problem you initially
reported and which is still described in the summary line.
i don't know what bug you want to report exactly, but what you say in the
subject ("floats show as 6 digits, but implemented at higher precision") is
imho invalid as a bug-report (and thus a waste of time; we agree here). so
i closed it (but of course i will now leave it open)
if you want a binary patch-format with full precision, you should file a
feature request (preferrably a new one).
if you think that the text patch-format should is buggy as it discards
precision, you should say so in the bug-report.
your analogy to C's printf is invalid insofar, as you can do the same with
Pd, either as shown in my 10percent.pd patch or by using [makefilename]'s
formatting.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-24 17:05
Message:
Logged In: YES
user_id=27104
Originator: YES
Why would you close the bug if you agree that there is a problem? "The
only valid issue i can see is, that precision gets lost when saving and
re-loading a patch". As for the 10percent.pd patch, that is just wasting
our time, since that is demonstrating the manual control of display
precision, not the bug that we are talking about.
No other programming language that I use has this problem. With C, you
have the power to control the precision that is displayed with printf(),
for example. And if you set a variable in C, the editor doesn't
automatically round it off to 6 digits when you save it.
float myNumber = 0.100000001490116119384765625;
versus:
[float 0.100000001490116119384765625]
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-24 10:26
Message:
Logged In: YES
user_id=564396
Originator: NO
imho, this bug-report "floats show as 6 digits, but implemented at higher
precision" is invalid.
first of all, i don't see how loat-precision-misrepresentation.pd is any
more helpful than my patch.
it only illustrates that Pd is working correctly (0.999999+9e-7 is
0.9999999 which IS smaller than 1 and therefore correctly outputs the value
to the left outlet of [moses]).
the rest is just a matter of representation (see attached 10percent.pd
patch)
you are surely aware that "all that is gold does not glitter" and a visual
representation is not necessary the thing per se.
showing a 32bit floating point value is always problematic: either you
sacrifice precision (in the display!) or you sacrifice readability.
this get's worse by the fact that floating point numbers do a bad job in
representing numbers whose nominators are not power-of-2.
e.g. "0.1" really cannot be expressed with a floating point number; the
closest you can get is about "0.100000001490116119384765625".
this is the reason why Pd does not try to display the _exact_ value of a
number but rather accepts a little rounding:
i guess you would file a bug-report if the result of 1/10 would show up as
"0.100000001490116119384765625"
see
http://en.wikipedia.org/wiki/Floating_point#Representable_numbers.2C_conver…
for more information on this dilemma.
a less sophisticated way would be to display the floating-point numbers as
4byte binaries (display "0x3DCCCCCD" instead of "0.1")
it needs some time to get used to it, but once you are there...
another way to make Pd represent all numbers exactly, is to limit Pd's
valid numbers, e.g. to just integers.
the only valid issue i can see is, that precision gets lost when saving
and re-loading a patch; the obvious fix for this is to use a binary
format.
you could file a feature-request for such a thing if you really need it.
File Added: 10percent.pd
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-23 22:56
Message:
Logged In: YES
user_id=27104
Originator: YES
This is a more fundamental bug then. It is not just [print] that is
limited to 6 digits. You can't represent more than six digits in anything
that gets saved. Yet things in the C implementation are working at higher
precision. That's a pretty serious disconnect between what's happening in
the implementation and how it is represented in Pd.
For example, anytime you have you any number with more than 6 digits in an
object or message box, and you save the patch, it'll be automatically
rounded to 6 digits. Also, consider the attached patch, it shows that
using [moses] can be similarly misrepresented. I don't think that the
pd_precision.pd patch represents this issue very well.
Yes, this is a known issue, but this is just another illustration of where
it's a problem. I have forgotten what is the source of this disconnect.
File Added: float-precision-misrepresentation.pd
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-23 16:33
Message:
Logged In: YES
user_id=564396
Originator: NO
attached is a patch that simulates what you experienced.
btw, it is rather simple to quantize your numbers with an abstraction, if
you don't need full precision.
also it might be a nice feature to [change] to allow a certain fuzziness.
i guess you could submit a feature-request for this instead of this
bug-report.
File Added: pd_precision.pd
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-23 16:23
Message:
Logged In: YES
user_id=564396
Originator: NO
ah i see, but this is a misunderstanding on your side.
Pd uses _full_ precision of floats. however it will only display (and
save) a number with a limited precision.
i don't think we should change [change] just because [print] is unable to
show enough precision.
if you use [tgl] instead of [print] you will notice that even more values
look the same :-)
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-07-23 16:08
Message:
Logged In: YES
user_id=27104
Originator: YES
Since this comparison is happening in C space, it is done using the full
precision of the float. But Pd only uses 6 digits of precision, so the
comparison should match that, not what is happening in C space.
Basically, I hooked up a [change]-[print] to some sensor data, and it was
quite common to see the exact same number printed out one after the other.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-07-23 09:26
Message:
Logged In: YES
user_id=564396
Originator: NO
do you have a practical example that exposes the bug?
in theory you are of course right, but in practice i wonder how this can
be applied to [change].
e.g. if i send "1" and the result of "2/2" to change, i might consider
these two as different enough :-)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1996275&group_…
Bugs item #1984672, was opened at 2008-06-04 19:21
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&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: stffn (stffn)
Assigned to: Nobody/Anonymous (nobody)
>Summary: numbers in comments are not kept as literals
Initial Comment:
...but only if it's followed by a number unless it's 0's then one 0 is kept. Try to open this patch (also attached):
#N canvas 50 50 200 370 missing_0s.pd 10;
#X text 50 10 011;
#X text 50 40 foo;
#X text 50 70 0ff;
#X text 50 100 0 ff;
#X text 50 130 0;
#X text 50 160 01;
#X text 50 190 0 1;
#X text 50 220 0 ;
#X text 50 250 00;
#X text 50 280 02;
#X text 50 310 000;
#X text 50 340 0000;
It's in Pd-0.41-4 and Pd-extended-0.40.3-RC1 on Intel powered Mac OS X
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 09:49
Message:
Logged In: YES
user_id=564396
Originator: NO
the problem is,that numbers in comments are not kept as literals (strings,
symbols) but are really interpreted as numbers, thus "019" is equivalent to
"19".
the same problem occurs if you have large numbers 8000000001 which will be
stripped to 8e09 (like everywhere else in Pd)
the workaround for this is to make sure that these numbers are really read
as symbols, e.g. by adding quotes (or other non-numerical characters):
#X text 50 310 "000";
i changed the name from "0 in start of comment gets stripped off..."
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1984672&group_…
Bugs item #1964787, was opened at 2008-05-15 21:09
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&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: Dan Wilcox (danomatika)
Assigned to: Nobody/Anonymous (nobody)
>Summary: alsamidi startup flag broken
Initial Comment:
In any of the autobuilds of 0.40.3, the "-alsamidi" startup flag selects the checkbox for Alsamidi in the media menu, but the actual midi I/O ports are not created aka aconnect -io does not show them. Upon selecting Alsamidi in the media menu, the proper connections appear.
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 09:40
Message:
Logged In: YES
user_id=564396
Originator: NO
i can reproduce on Pd-0.41;
a workaround is to specify the mididev;
e.g. use "-alsamidi -mididev 1" to get a single (autoconnected)
alsamidi-port
or use "-alsamidi -mididev 2" to get two (unconnected) alsamidi-ports
----------------------------------------------------------------------
Comment By: Dan Wilcox (danomatika)
Date: 2008-07-26 06:22
Message:
Logged In: YES
user_id=2032867
Originator: YES
Still a problem for me as I need pd to open its midi ports automatically.
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-18 20:50
Message:
Logged In: YES
user_id=27104
Originator: NO
have you tried this on Pd-vanilla 0.41? I wonder if there is different
behavior there?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1964787&group_…
Bugs item #2062558, was opened at 2008-08-20 17:12
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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.41.0
Status: Open
Resolution: None
Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4 mac binary doesn't accept arguments
Initial Comment:
The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes.
Please bring back this useful feature!
----------------------------------------------------------------------
>Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2008-08-21 09:35
Message:
Logged In: YES
user_id=564396
Originator: NO
funnily enough we decided yesterday to file a bug-report about this very
issue, but thomas was faster :-)
it is _really_ annoying when doing development/debugging.
interestingly enough, the only argument i found that actually was accepted
is "-help", which gives you all the arguments that are unfortunately
ignored...
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&group_…
Bugs item #2062558, was opened at 2008-08-20 15:12
Message generated for change (Settings changed) made by xovo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&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.41.0
Status: Open
Resolution: None
>Priority: 7
Private: No
Submitted By: Thomas Grill (xovo)
>Assigned to: Miller Puckette (millerpuckette)
Summary: 0.41-4 mac binary doesn't accept arguments
Initial Comment:
The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes.
Please bring back this useful feature!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&group_…
Bugs item #2062558, was opened at 2008-08-20 15:12
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=2062558&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.41.0
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Thomas Grill (xovo)
Assigned to: Nobody/Anonymous (nobody)
Summary: 0.41-4 mac binary doesn't accept arguments
Initial Comment:
The MacOS build version 0.41-4 doesn't accept command line arguments when e.g. run as "/Applications/Pd-0.41-4/Contents/Resources/bin/pd -noprefs - lib my_lib". This worked in 0.40-2 and is very handy for debugging purposes.
Please bring back this useful feature!
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2062558&group_…
Bugs item #1955701, was opened at 2008-05-01 21:18
Message generated for change (Comment added) made by xovo
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1955701&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: abstractions
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: vasp abstractions missing
Initial Comment:
there are vasp abstractions missing in the distribution. they can be found at http://grrrr.org/ext/vasp/vasp-0.1.3-pd.zip in the subfolder vasp/pd.
----------------------------------------------------------------------
Comment By: Thomas Grill (xovo)
Date: 2008-08-20 15:08
Message:
Logged In: YES
user_id=350252
Originator: NO
It seems that pd-extended is meant here.
Up-to-date abstractions can be found in the svn at
https://svn.grrrr.org/ext/trunk/vasp/pd/ , help files at
https://svn.grrrr.org/ext/trunk/vasp/pd-help/
----------------------------------------------------------------------
Comment By: Fabian (fabbb)
Date: 2008-05-01 21:24
Message:
Logged In: YES
user_id=2077082
Originator: NO
i'm on pd-ext 0.39.3 win i forgot to say
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1955701&group_…
Bugs item #1655662, was opened at 2007-02-09 00:54
Message generated for change (Comment added) made by sf-robot
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655662&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: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Matteo Sisti Sette (sistisette)
Assigned to: Nobody/Anonymous (nobody)
Summary: .xa10120: no such object
Initial Comment:
Hi,
This seems to happen under "random" circumstances. It happened to me with every kind of patches (simple and complex) and usually NOT in a sistematic manner (that is, the same patch which once triggers the bug, after restarting PD never does again...)
However, this patch that I attach does sistematically make this happen, at least to me under Windows XP.
The following error message appears in the output window:
>> .xa10120: no such object
This particular patch uses "scripting", i.e. it creates and deletes an object in a subpatch iteratively; however, I saw this same bug happen a lot of times with patches which didn't make any use of scripting at all. I attach this just because it is the only one I have that is sure to trigger the bug.
Sorry I can't "isolate" it further.
Matteo Sisti Sette
----------------------------------------------------------------------
>Comment By: SourceForge Robot (sf-robot)
Date: 2008-08-19 02:20
Message:
Logged In: YES
user_id=1312539
Originator: NO
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 zmlnig (zmoelnig)
Date: 2008-08-04 16:25
Message:
Logged In: YES
user_id=564396
Originator: NO
shall we close this and re-open it whenever the bug occurs again?
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-05-09 19:59
Message:
Logged In: YES
user_id=27104
Originator: NO
I couldn't reproduce this on Windows XP SP2 with Pd-extended
0.40.3-20080504
----------------------------------------------------------------------
Comment By: Matteo Sisti Sette (sistisette)
Date: 2007-04-23 11:42
Message:
Logged In: YES
user_id=1709568
Originator: YES
I guess it may be windows-specific.
I am reproducing it right now with 0.40-2 vanilla on Windows XP.
Can anyone else reproduce it in windows?
(does anyone else use windows?)
Please note that it is NOT in ANY WAY specific to dinamically creating
patches or objects in patches. It happens to me a lot every day working
with patches that never do anything dynamically and that don't use dyn (nor
any external for what it's worth).
However, here is a typical situation which triggers the bug in my everyday
life:
-work with some rather "big" patch which uses a lot of abstractions (which
I did myself), including a some of them used more than once i.e. a few
instances of the same abstraction; and abstractions contain other
abstractions and so on (no weird infinite loop or anything, just a bit
complex)
-open (with file/open) separately the file of an abstraction which is
being used in the main patch (or inside some other abstraction used in the
main patch etc), edit and save it.
This will for some reason automatically open and close all patch windows
which contain occurences of the saved abstraction (which is quite slow and
quite annoying but is better than older versions which used to open them
without closing), AND produce the mentioned error message.
When this happen, I'm not sure whether the stability and correct behaviour
of PD is compromised, so I usually restart it.
Note however that this is a lot different from the situation exemplified
by the attached patch, and both trigger the bug.
----------------------------------------------------------------------
Comment By: Nobody/Anonymous (nobody)
Date: 2007-04-23 09:47
Message:
Logged In: NO
I haven't been able to reproduce the problem on win32 pd vanilla 0.40-2,
but,
I've had this problem a lot of time on win32, it always happen when I
create patches dynamically, after an amount of created(/destroyed) patches,
the object maker isn't able to make any new object and send these tk path
names error messages.
Sometimes the tk binding become erroneous within this problem, yesterday
when the bug occured, the Font Bomb windows was opened with clicking on
'FileMenu' button, Media Settings on 'Cancel' button, and SavePanel on 'Ok'
button
But I haven't been able to determine if this is caused by an external or
not.
The problem also occur when the patches are created with the [dyn~]
external.
----------------------------------------------------------------------
Comment By: stffn (stffn)
Date: 2007-04-23 09:18
Message:
Logged In: YES
user_id=1658640
Originator: NO
I can not reproduce it either on OS X using vanilla 0.40-2 and extended
0.39.2 test7 and RC1. Increaseing the number in the msg does noet seam to
provoke the error either.
----------------------------------------------------------------------
Comment By: IOhannes m zmlnig (zmoelnig)
Date: 2007-04-23 09:04
Message:
Logged In: YES
user_id=564396
Originator: NO
unfortunately i cannot reproduce this with your patch on linux with
pd-0.39-2 (vanilla) and pd-0.40-1 (vanilla).
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1655662&group_…
Bugs item #2053509, was opened at 2008-08-15 13:42
Message generated for change (Settings changed) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2053509&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: pd-extended
Group: None
>Status: Deleted
>Resolution: Invalid
Priority: 5
Private: No
Submitted By: oli44 (oli44)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: missing depency libtcl on Hardy
Initial Comment:
When installing the Hardy package of Pd-e http://autobuild.puredata.info/auto-build/2008-08-14/Pd-0.42.0-extended-200…
on a fresh Uubuntu Studio Hardy install, there is message about a missign dependency namely libtcl
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-08-18 19:19
Message:
Logged In: YES
user_id=27104
Originator: NO
You need to install tcllib
(http://packages.ubuntu.com/hardy/interpreters/tcllib), it is in the
'universe' repository:
apt-get install tcllib
I am closing the bug. Reopen it if there is a problem.
----------------------------------------------------------------------
Comment By: oli44 (oli44)
Date: 2008-08-16 04:19
Message:
Logged In: YES
user_id=1473188
Originator: YES
Here is a snapshot of aptitude trying to solve the installation of Pd-e
0.42
File Added: aptitude_libtcl_snapshot.png
----------------------------------------------------------------------
Comment By: oli44 (oli44)
Date: 2008-08-16 04:11
Message:
Logged In: YES
user_id=1473188
Originator: YES
Here is the error msg, sorry the locale is set to French
sudo dpkg -i Pd-0.42.0-extended-20080814-ubuntu-hardy-i386.deb
[sudo] password for olivier:
(Lecture de la base de donnes... 181343 fichiers et rpertoires dj
installs.)
Prparation du remplacement de pd-extended 0.40.3extended-1 (en utilisant
Pd-0.42.0-extended-20080814-ubuntu-hardy-i386.deb) ...
Dpaquetage de la mise jour de pd-extended ...
dpkg: des problmes de dpendances empchent la configuration de
pd-extended: (rougly: dependency problems prevent setting up pd-e)
pd-extended dpend de tcllib; cependant: (pd-e depends from tcllib)
Le paquet tcllib n'est pas install. (the package tcllib is not
installed).
dpkg: erreur de traitement de pd-extended (--install):
problmes de dpendances - laiss non configur
Des erreurs ont t rencontres pendant l'excution:
pd-extended
Hope this helps
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2008-08-15 19:51
Message:
Logged In: YES
user_id=27104
Originator: NO
I don't quite understand the problem, there isn't a package called
'libtcl' and the dependencies are automatically generated based on the
installed packages.
Could you copy-n-paste the original error message?
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2053509&group_…