Patches item #2838176, was opened at 2009-08-15 14:56
Message generated for change (Tracker Item Submitted) made by nobody
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: Tooltips patch for 0.42-5
Initial Comment:
This is GG/tim's tooltip patch ported forward to 0.42-5
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=2838176&group_…
Bugs item #2838114, was opened at 2009-08-15 10:33
Message generated for change (Tracker Item Submitted) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&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: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: zexy fwriteln buffer overflow
Initial Comment:
The buffer for the prefix is too small.
gcc -I. -DHAVE_CONFIG_H -DZEXY_LIBRARY -DPD -I/usr/src/pd/src -g -O2 -g -Wall -O2 -mms-bitfields -fPIC -mfpmath=sse -msse -g -O2 -g -Wall -O2 -c -o fwriteln.o fwriteln.c
In file included from /usr/include/string.h:640,
from fwriteln.c:26:
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:233:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
In function 'strcpy',
inlined from 'fwriteln_new' at fwriteln.c:236:
/usr/include/bits/string3.h:106: warning: call to __builtin___strcpy_chk will always overflow destination buffer
Line 195: char prefix[2]="%";
Line 233: strcpy(prefix,"%-");
Line 236: strcpy(prefix,"%+");
The strcpy will copy an additional '\0' byte which will overflow the buffer.
Suggested fix: increase the prefix buffer size
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2838114&group_…
Bugs item #2827011, was opened at 2009-07-25 09:49
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2827011&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: Closed
>Resolution: Duplicate
Priority: 5
Private: No
Submitted By: boonier (boonier)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: 'View List" button in Array properties not working
Initial Comment:
When clicked throws error window:
wrong # args: should be array
and has 3 btn options [OK] [Skip message] [Details]
this is on latest Pd extended 0.41.4, osx 10.4.11
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-14 11:49
Message:
This was fixed in Pd-extended 0.42, here's the bug report:
https://sourceforge.net/tracker/index.php?func=detail&aid=2807222&group_id=…
If you want, you could probably easily apply the fix to pd.tk in 0.41.4
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2827011&group_…
Bugs item #2836261, was opened at 2009-08-12 10:36
Message generated for change (Comment added) made by eighthave
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&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: v0.42
>Status: Pending
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Hans-Christoph Steiner (eighthave)
Summary: "Find" Application Error - PD 0.42.5-extended-20090803 (XP)
Initial Comment:
using "find" from the menu or typing "ctrl+f" in PD 0.42.5-extended-20090803 (Windows XP) results in this error:
Application Error
Error: invalid command name "x"
Details:
invalid command name "x"
invalid command name "x"
while executing "x"
(procedure "find_ok" line 1)
invoked from within
"find_ok .find1"
invoked from within
".find1.button invoke"
("uplevel" body line 1)
invoked from within
"uplevel #0 [list $w invoke]"
(procedure "tk::ButtonUp" line 24)
invoked from within
"tk::ButtonUp .find1.button"
(command bound to event)
----------------------------------------------------------------------
>Comment By: Hans-Christoph Steiner (eighthave)
Date: 2009-08-14 11:34
Message:
doh, it was a stupid typo. Fixed with this commit:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=119…
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2836261&group_…
We have to sort this out!
The denormals bug in freeverb~ _seems_ to have been fixed by following Julius' advice. I made a makefile with
-fno-trapping-math
as a flag and so far so good. I haven't had a problem with the freeverb~ object pegging the CPU. May I advise that this is implemented in PD-extended, since it causes my patch to NOT WORK AT GIGS! I simply cannot take any more embarrassment. I want to play live, otherwise there's simply no point doing anything!
The second one I have discovered is in bsaylor/svf~ and there's no makefile for this in the subversion repository. I notice in the source code there is a FLUSH_TO_ZERO definition. Interestingly, when I try to compile this external using a bog-standard makefile on Ubuntu 8.10, it causes an error:
cc1: warnings being treated as errors
svf~.c: In function ‘run_svf’:
svf~.c:59: error: dereferencing type-punned pointer will break strict-aliasing rules
svf~.c:60: error: dereferencing type-punned pointer will break strict-aliasing rules
Now, I'm trying to unpick the statement:
#define FLUSH_TO_ZERO(fv) (((*(unsigned int*)&(fv))&0x7f800000)==0)?0.0f:(fv)
which is being called on lines 59 and 60 of bsaylor/svf~.c, causing the compiler to choke, and (perhaps) causing my drumsynths to break!
And by the way, where is the source code for the _other_ svf~ external?
Ed
--- On Wed, 1/7/09, Julius Smith <jos(a)ccrma.stanford.edu> wrote:
> From: Julius Smith <jos(a)ccrma.stanford.edu>
> Subject: Re: [PD] bug in freeverb???
> To: "Matt Barber" <brbrofsvl(a)gmail.com>
> Cc: pd-list(a)iem.at
> Date: Wednesday, 1 July, 2009, 8:22 PM
> Hmmm, this sounds like underflow
> traps ("denormals"). You should
> also be able to add a small constant to the input signal.
>
> I notice gcc has the option
>
> -fno-trapping-math
>
> which may make the problem disappear if my theory is
> correct. (I
> hope the FPU simply sets underflows quietly to zero when no
> trap can
> be generated.)
> There is also
>
> -ffast-math
>
> which is more aggressive.
>
> - jos
>
> At 11:30 AM 7/1/2009, Matt Barber wrote:
> >We have also had this problem, and have found that
> normally one can
> >avoid it by salting the [freeverb~] object with a
> minuscule amount of
> >noise at all times.
> >
> >Matt
> >
> >
> >
> > > Message: 5
> > > Date: Wed, 1 Jul 2009 09:57:43 -0700 (PDT)
> > > From: Andres Ferrari <anfex(a)yahoo.com>
> > > Subject: [PD] bug in freeverb???
> > > To: pd-list(a)iem.at
> > > Message-ID: <166347.29167.qm(a)web111408.mail.gq1.yahoo.com>
> > > Content-Type: text/plain; charset=iso-8859-1
> > >
> > >
> > > when is connected into freeverb any signal
> multiplied by zero
> > > the CPU usage begin to up and up to the limit,
> and if the patch
> > is heavy by far exceeds the 100%....sound and
> everything becomes a mess.
> > >
> > > This happens to me only in leopard.
> > >
> > > In osx 10.4 (ppc) and windows I've never had that
> problem.
> > > Andr?s Ferrari G.
> > >
> > > http://www.myspace.com/anfex
> > >
> >
> >_______________________________________________
> >Pd-list(a)iem.at
> mailing list
> >UNSUBSCRIBE and account-management ->
> >http://lists.puredata.info/listinfo/pd-list
>
>
> Julius O. Smith III <jos(a)ccrma.stanford.edu>
> Prof. of Music and Assoc. Prof. (by courtesy) of Electrical
> Engineering
> CCRMA, Stanford University
> http://ccrma.stanford.edu/~jos/Â
>
>
> _______________________________________________
> Pd-list(a)iem.at
> mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list
>
Send instant messages to your online friends http://uk.messenger.yahoo.com
Bugs item #2837519, was opened at 2009-08-14 09:26
Message generated for change (Tracker Item Submitted) made by claudiusmaximus
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2837519&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: ClaudiusMaximus (claudiusmaximus)
Assigned to: Nobody/Anonymous (nobody)
Summary: pdp mmx problems on amd64
Initial Comment:
pdp's "./configure --enable-mmx" leads to build failure on amd64:
make -C mmx
make[3]: Entering directory `/build/buildd/pd-pdp-0.12.svn20090813/system/mmx'
as -o pixel_pack_s16u8.o pixel_pack_s16u8.s
pixel_pack_s16u8.s: Assembler messages:
pixel_pack_s16u8.s:25: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:27: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:28: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:73: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:74: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:82: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:84: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:85: Error: suffix or operands invalid for `push'
pixel_pack_s16u8.s:122: Error: suffix or operands invalid for `pop'
pixel_pack_s16u8.s:123: Error: suffix or operands invalid for `pop'
make[3]: *** [pixel_pack_s16u8.o] Error 1
it compiles fine on i386.
problem:
./configure doesn't automatically enable MMX if it is available, or disable it if requested but the CPU doesn't support it.
suggested fix:
add a test for build target CPU type in pdp/configure.ac and autoenable MMX if it is supported
suggested fix 2:
port the i386/mmx code to amd64/mmx, autoselect at compile time and/or run time
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=2837519&group_…
I found a solution to the GNOME/metacity blocking the raising of
windows. It turns out to be not too bad. Basically, you just have to
'group' each window with the toplevel '.' (i.e. the Pd window), then
you can raise windows. Here's the commit for Pd-extended:
http://pure-data.svn.sourceforge.net/viewvc/pure-data?view=rev&revision=118…
I am going to try adding this on pd-devel now...
.hc
----------------------------------------------------------------------------
"It is convenient to imagine a power beyond us because that means we
don't have to examine our own lives.", from "The Idols of
Environmentalism", by Curtis White
Each branch has its own goals and tracks trunk accordingly. Pd-
extended tracks trunk with a merge before each release. The pd-devel
0.41.4 branch is currently only for the GUI rewrite effort and is
frozen on 0.41.4. Previous pd-devel branches were for other things.
Donno about desiredata or other branches.
.hc
On Aug 13, 2009, at 1:40 PM, Tim Jones wrote:
> Ok. And all "core versions" are still derivatives of the SVN trunk,
> right? Is pd-devel just supposed to be a more stable version of what's
> in trunk?
>
> On Thu, Aug 13, 2009 at 8:45 AM, Hans-Christoph
> Steiner<hans(a)at.or.at> wrote:
>>
>> There are different core versions of pd: vanilla (miller's), devel,
>> extended, desiredata. Then there are all of the externals, docs,
>> etc.
>> Pd-extended includes all this stuff as part of each release so
>> everything
>> is then added to the pd-extended release branch. The externals,
>> docs, etc.
>> in the Pd-extended release branch then gets tweaks to make sure it
>> all works
>> well together as a package.
>> So if you want the whole tested, integrated Pd-extended package,
>> you should
>> use everything from the Pd-extended release branches.
>> .hc
>> On Aug 12, 2009, at 8:04 PM, Tim Jones wrote:
>>
>> As the Gentoo pd-overlay is a little moldy, I was planning on
>> fixing some up
>> some of the ebuilds. I was a little bit confused by all the overlap
>> in svn,
>> though. What's the difference between the trunk and the pd-devel
>> branch?
>> pd-overlay also seemingly offers two choices: build pd-extended
>> (with all
>> its externals) in one process, or build pd-devel (or a numbered
>> version of
>> pd, src from M. Puckette's site) and then build the plugins
>> seperately, one
>> by one. Would there be any significant difference between these two
>> approaches? I like the modularity of the latter, having seperate
>> ebuilds for
>> each plugin. Also, what would be the best place in svn to get src
>> for the
>> externals themselves? /trunk/externals?
>>
>> _______________________________________________
>> Pd-dev mailing list
>> Pd-dev(a)iem.at
>> http://lists.puredata.info/listinfo/pd-dev
>>
>>
>>
>>
>>
>> ----------------------------------------------------------------------------
>> Programs should be written for people to read, and only
>> incidentally for
>> machines to execute.
>> - from Structure and Interpretation of Computer Programs
>>
----------------------------------------------------------------------------
'You people have such restrictive dress for women,’ she said, hobbling
away in three inch heels and panty hose to finish out another pink-
collar temp pool day. - “Hijab Scene #2", by Mohja Kahf