Bugs item #1609736, was opened at 2006-12-06 02:31
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1609736&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: v0.39.2
Status: Closed
Resolution: None
Priority: 5
Private: No
Submitted By: Hans-Christoph Steiner (eighthave)
Assigned to: Nobody/Anonymous (nobody)
Summary: [pix_movie] and [pix_film] only play solid colors
Initial Comment:
On Intel-based machines with ATI cards both Mac OS X and Ubuntu, using Gem checked out from CVS on 2006-12-05, playing movies with both [pix_film] and [pix_movie] just plays solid colors that somehow seem related to the actual movie being played.
This happened on a Dell Dimension 8400 with ATI card:
0000:01:00.0 VGA compatible controller: ATI Technologies Inc RV370 5B60 [Radeon X300 (PCIE)]
0000:01:00.1 Display controller: ATI Technologies Inc RV370 [Radeon X300SE]
And on a Mac Pro with Quad Processors and an ATI Radeon X1900 XT.
And on a MacBook Pro with a ATI Mobility Radeon X1600
----------------------------------------------------------------------
Comment By: SourceForge Robot (sf-robot)
Date: 2007-10-23 04: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 zmölnig (zmoelnig)
Date: 2007-09-04 12:18
Message:
Logged In: YES
user_id=564396
Originator: NO
has this been fixed by the recent changes to use non-rectangle textures by
default??
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-12-06 19:44
Message:
Logged In: YES
user_id=27104
Originator: YES
File Added: 05.film.pd-smoothing.png
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-12-06 19:43
Message:
Logged In: YES
user_id=27104
Originator: YES
Ok, a follow up on the Mac Pro (using build 2006-12-06):
05.movie.pd:
1 movie plays all one color
2 sending [mode 0( to [pix_movie] causes error:
error: pix_movie: no method for 'mode'
05.film.pd:
1 the movie plays fine
2 [pix_convolve] causes strange banding (see attached images)
3 turn off [pix_convolve] and the video is fine.
And on the Ubuntu/Dell Dimension:
05.movie.pd:
1 plays solid colors by default
2 sending [mode 0( to [pix_movie] makes it work
3 now toggling mode 1/0 works, and reports the change to the Pd console
05.film.pd:
1 plays solid colors by default
2 sending [mode 0( to [pix_texture] makes it work
3 now toggling mode 1/0 works, and reports the change to the Pd console
File Added: 05.film.pd-default.png
----------------------------------------------------------------------
Comment By: Hans-Christoph Steiner (eighthave)
Date: 2006-12-06 04:17
Message:
Logged In: YES
user_id=27104
Originator: YES
This also happens on Ubuntu, so its not OS-specific. I guess I forgot to
mention that. The above Dell Dimension is running Ubuntu Dapper.
Is there a certain set of ./configure options to try?
----------------------------------------------------------------------
Comment By: christopher clepper (cclepper)
Date: 2006-12-06 03:45
Message:
Logged In: YES
user_id=663212
Originator: NO
This most likely is a problem with the autobuild building pix_film/movie
files which are not the right ones on OSX. I use the same hardware daily
without problems so the code is certainly fine. Some #ifdef bludgeoning
might make the autobuild do the right thing.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1609736&group_…
Bugs item #1825741, was opened at 2007-11-04 23:36
Message generated for change (Comment added) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1825741&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: Closed
>Resolution: Fixed
Priority: 7
Private: No
Submitted By: marius schebella (mariusschebella)
Assigned to: Nobody/Anonymous (nobody)
Summary: gem focus with leopard
Initial Comment:
hi,
gemwindow stays in the background and ignores mouse click. with apple click I can shift the window (should be possible without the apple...) and window stays in background.
this is with os x 10.5 (leopard). gem cvs from oct 26.
marius.
----------------------------------------------------------------------
>Comment By: IOhannes m zmölnig (zmoelnig)
Date: 2008-01-10 10:30
Message:
Logged In: YES
user_id=564396
Originator: NO
to my knowledge ths should be resolved now in CVS.
if the problem still persists, please open another bug, but in the pd-gem
project (i am trying to eliminate all the "Gem"-bugs from the "pure-data"
project.
thanks
----------------------------------------------------------------------
Comment By: marius schebella (mariusschebella)
Date: 2007-11-11 22:00
Message:
Logged In: YES
user_id=1856112
Originator: YES
Hi,
if this is related to Rez, did someone already try to fix it? what else
could it be? gem is basically broken without the possibility to bring the
window to the front, also, gemmouse does not recognize mouseclicks.
marius.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1825741&group_…
Patches item #1868117, was opened at 2008-01-09 21:29
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=1868117&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: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Improve libm checks using configure script
Initial Comment:
This commit adds configure script checking for a number of functions in libm:
- sinf, cosf, atanf, atan2f, ...
Previously, in x_arithmetic.c, these functions were redefined for MSW / Apple. Now, they will only be redefined if the configure script does not find them.
The results of the checks for these functions are placed in the config.h header file. The config.h.in file was generated using autoheader.
(Note that this patch requires the inclusion of acinclude.m4, submitted in a different issue. Also, after including acinclude.m4, you must run aclocal before running autoconf to generate the configure script.)
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1868117&group_…
Patches item #1868092, was opened at 2008-01-09 21:12
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=1868092&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: Russell Bryant (russellbryant)
Assigned to: Nobody/Anonymous (nobody)
Summary: Add m4 macros used for configure script improvements
Initial Comment:
This patch will add a new file, acinclude.m4, which is a small library of m4 macros used to make adding certain things to the configure script much easier. It is a raw copy from the file's source (Asterisk). All of the macro prefixes are AST, but they have been left intact, to ease keeping this file up to date with the original one.
This is required before any of the other configure script related patches can be applied.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1868092&group_…
Patches item #1862168, was opened at 2008-01-02 14:22
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862168&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: 6
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
>Summary: [bugfix] makefilename ignores "%c"
Initial Comment:
the bugfix-#1688540 introduced argument-checking in [makefilename].
unfortunately, the author forgot about the "%c", which is currently the only way to get "weird" characters (like space,...).
this breaks quite some patches which depend on that workaround.
since there is still no "clean" way to produce symbols with special characters, i'd suggest to include "%c" into the formatting in [makefilename].
attached is a fix, that adds "%c" to the types that request an integer.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862168&group_…
Patches item #1862178, was opened at 2008-01-02 14:40
Message generated for change (Settings changed) made by zmoelnig
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862178&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: 1
Private: No
Submitted By: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
>Summary: [feature] make makefilename accept floats in %s
Initial Comment:
while fiddling with the bug-fix for the missing "%c" in [makefilename] (see #1862168), i found that
[makefilename %s] will safely ignore any number that it receives.
in theory this is nice and consistent behaviour.
in practice i find it weird that
[32(
|
[makefilename %s]
outputs nothing(!).
and
[32(
|
[makefilename _%s+]
outputs "_+"
the attached patch uses "%g" to convert a number into a string which is then inserted as %s.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1862178&group_…
Patches item #1867738, was opened at 2008-01-09 16:25
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=1867738&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: IOhannes m zmölnig (zmoelnig)
Assigned to: Miller Puckette (millerpuckette)
Summary: [FIX] gensym() should use "const char*"
Initial Comment:
gensym is currently defined as "t_symbol *gensym(char *s);"
this leads to numerous warnings when compiling C++-externals, since C++ treats literals (strings) as "const char*".
e.g.
gensym("hello");
yields and a warning "warning: deprecated conversion from string constant to 'char*'"
the fix for this is simple and makes total sense, since gensym() does not need to modify the passed string. just use:
t_symbol *gensym(const char *s);
the attached patch does this (it additionally applies the same to the dogensym() function in m_class.c
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1867738&group_…
This error should have been fixed yesterday in the autobuild scripts. The
builders just need to be updated now, it seems ...
Pd user wrote:
> checking for snd_pcm_info in -lasound... yes
> checking for shm_open in -lrt... yes
> checking for jack_set_xrun_callback in -ljack... yes
> checking for jack_set_error_function in -ljack... yes
> MORECFLAGS --------------- -O6 -funroll-loops -fomit-frame-pointer
> checking for special C compiler options needed for large files... no
> checking for _FILE_OFFSET_BITS value needed for large files... 64
> ./configure: line 8297: syntax error near unexpected token `SINF,'
> ./configure: line 8297: `AST_EXT_LIB_CHECK(SINF, m, sinf)'
> make[1]: [pd] Error 2 (ignored)
> make -C /home/pd/auto-build/pd-extended/pd/src BUILDLAYOUT_DIR=/home/pd/auto-build/pd-extended/packages cvs_root_dir=/home/pd/auto-build/pd-extended DESTDIR=/home/pd/auto-build/pd-extended/packages/linux_make/build/ prefix=/usr/local libpddir=/home/pd/auto-build/pd-extended/packages/linux_make/build//usr/local/lib/pd OPT_CFLAGS="-O2 -mcpu=i686 -march=i386 -ftree-vectorize -ftree-vectorizer-verbose=3" UNAME=Linux install
> make[2]: Entering directory `/home/pd/auto-build/pd-extended/pd/src'
> make[2]: *** No rule to make target `install'. Stop.
> make[2]: Leaving directory `/home/pd/auto-build/pd-extended/pd/src'
> make[1]: *** [pd_install] Error 2
> make[1]: Leaving directory `/home/pd/auto-build/pd-extended/packages'
> make: *** [install] Error 2
> upload specs linux_make . deb
> Uploading /home/pd/auto-build/pd-extended/packages/linux_make/./Pd*.deb
> ls: /home/pd/auto-build/pd-extended/packages/linux_make/./Pd*.deb: No such file or directory
>
> _______________________________________________
> PD-cvs mailing list
> PD-cvs(a)iem.at
> http://lists.puredata.info/listinfo/pd-cvs
>
Patches item #1852385, was opened at 2007-12-17 09:07
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1852385&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: Russell Bryant (russellbryant)
Assigned to: Miller Puckette (millerpuckette)
Summary: Improve strtokcpy() efficiency, prevent stack overflow
Initial Comment:
This patch provides a revised implementation of the strtokcpy() function in s_path.c. It provides the following benefits:
1) Prevent potential overflow of a stack buffer. This function did nothing to ensure that it didn't write past the end of the destination buffer.
It is possible to cause this to happen by providing certain command line arguments that are longer than MAXPDSTRING. Also, there may be other ways to trigger this bug if namelist_append_files() is used anywhere beyond the uses I reviewed, which are the ones in pd/*.c.
2) Copy bytes from the string in the same loop that looks for the delimiter. This is simply for efficiency in that the string only has to be traversed once, instead of twice (one to find the delimiter, and the second to copy up to it).
3) Document the function using doxygen style tags.
----------------------------------------------------------------------
>Comment By: Russell Bryant (russellbryant)
Date: 2008-01-06 08:39
Message:
Logged In: YES
user_id=1942915
Originator: YES
Checked in to branch-v0-40-extended
----------------------------------------------------------------------
Comment By: Russell Bryant (russellbryant)
Date: 2007-12-17 09:07
Message:
Logged In: YES
user_id=1942915
Originator: YES
File Added: strokcpy.txt
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1852385&group_…
Patches item #1848356, was opened at 2007-12-10 21:29
Message generated for change (Comment added) made by russellbryant
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848356&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: bugfix
>Status: Closed
>Resolution: Accepted
Priority: 5
Private: Yes
Submitted By: Russell Bryant (russellbryant)
Assigned to: Guenter Geiger (ggeiger)
Summary: streamin/streamout doc updates, bugs, and a security issue
Initial Comment:
This issue has been marked private as it includes details on a remotely exploitable buffer overflow vulnerability in the code for [streamin~].
A while ago, I was looking around at different options for streaming audio in and out of Pd. I spent a short time looking at the code for [streamin~] and [streamout~]. I ended up not using them for my project. However, I made this set of changes while looking at the code.
Since I moved on to something else, these changes aren't exactly complete, but point out some important things, so I think they may be worth putting in as is.
Here is a summary of the changes that are included.
stream.h changes:
1) doxygen style documentation updates
2) added an ifdef to protect against multiple or recursive inclusion of the header
3) Documentation of some of the fields in the data structures
4) Fixed potential alignment bugs by adding the packed attribute for the structure that defines frame headers. This attribute should always be used when it is used to directly interpret data from the network or when used to prepare data to send directly over the network. This section of the gcc manual has a tidbit about the attribute:
http://gcc.gnu.org/onlinedocs/gcc-4.2.2/gcc/Variable-Attributes.html#Variab…
5) Point out the fact that the code is not endianness-safe. The code should eventually be updated to respect network byte order.
6) Point out that the version field of the frame header is ignored when parsing incoming frames. It should eventually be checked, but doesn't matter much until the format gets changed such that the version number gets bumped.
7) Change a list of #defines to an enum, for the sake of better coding practice.
8) Change the use of "int" in the frame header structure to explicitly list that the field is 32-bits by using the int32_t type.
streamin~.c changes:
1) Fix a remotely exploitable buffer overflow that would allow remote execution of arbitrary code. The frame header includes 4 bytes to specify the frame length. However, the code only allocates enough space for the frame header and 256 bytes of payload data. The size portion of the frame header was not checked to ensure that its value was valid. This little hack should fix it.
----------------------------------------------------------------------
>Comment By: Russell Bryant (russellbryant)
Date: 2008-01-06 08:31
Message:
Logged In: YES
user_id=1942915
Originator: YES
I have merged these patches into the externals repository.
----------------------------------------------------------------------
You can respond by visiting:
https://sourceforge.net/tracker/?func=detail&atid=478072&aid=1848356&group_…