Pd-dev May 2007

pd-dev@lists.iem.at

13 participants
67 discussions

[ pure-data-Bugs-1650752 ] Select Cursor does not Correspond to Text In New PD-Extended
by SourceForge.net 05 May '07

05 May '07

Bugs item #1650752, was opened at 2007-02-02 08:00 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1650752&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.39.2 >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Luke Iannini (lukeiannini) Assigned to: Hans-Christoph Steiner (eighthave) Summary: Select Cursor does not Correspond to Text In New PD-Extended Initial Comment: Basically the change to the new font(s) has caused the mouse cursor to be inaccurate when selecting text. It seems to be assuming the wider courier font is in use. This combined with the next bug I'm about to submit regarding backwards delete has made things a bit tedious. This is on i386 and PPC OS X (though I assume this is platform independent) with the lastest 392 autobuilds. A picture is included with a badly rendered OmniDazzle cursor in the position of the actual cursor (since the cursor is not included in OS X screengrabs), and the text cursor in the position that results from a click at that point. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-04 19: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: stffn (stffn) Date: 2007-04-20 00:30 Message: Logged In: YES user_id=1658640 Originator: NO I can confirm that i in that version can't reproduce it. :-) ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 21:12 Message: Logged In: YES user_id=27104 Originator: NO I think this is fixed in the released build of Pd-0.39.2-extended-RC1, as long as DejaVu Sans Mono is installed. Can anyone confirm? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2007-02-05 07:02 Message: Logged In: YES user_id=27104 Originator: NO This stuff is still a work in progress. Most importantly, you need to have DejaVu Sans Mono font currently. Otherwise, it picks a proportional font, and causes the misalignment. ---------------------------------------------------------------------- Comment By: stffn (stffn) Date: 2007-02-02 15:01 Message: Logged In: YES user_id=1658640 Originator: NO I can confirm this behavior, using the intel mac build. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1650752&group_…

1 0

[ pure-data-Bugs-1595028 ] cyclone's [gate] changes type on drag and on save
by SourceForge.net 05 May '07

05 May '07

Bugs item #1595028, was opened at 2006-11-12 04:03 Message generated for change (Comment added) made by sf-robot You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1595028&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: Fixed Priority: 5 Private: No Submitted By: Damian Stewart (damian_nz) Assigned to: Hans-Christoph Steiner (eighthave) Summary: cyclone's [gate] changes type on drag and on save Initial Comment: if i drag a [gate] object around the gui window, or save a patch containing a [gate], the [gate] object is saved as a different type depending on what the last message to its left inlet was. (0==text, 1==object, 2==msg, 3==numberbox, ...) i'm running pd-0.39.2-extended-2006-11-08-windowsxp attached is a patch that demonstrates the bug. bang, then drag aroud the gate object, or just save and reload the patch. ---------------------------------------------------------------------- >Comment By: SourceForge Robot (sf-robot) Date: 2007-05-04 19: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: Hans-Christoph Steiner (eighthave) Date: 2007-04-19 21:16 Message: Logged In: YES user_id=27104 Originator: NO I believe this is fixed for a while now. Can anyone confirm that this is still a problem anywhere? ---------------------------------------------------------------------- Comment By: Hans-Christoph Steiner (eighthave) Date: 2006-11-18 20:26 Message: Logged In: YES user_id=27104 Originator: NO Strange bug indeed, I confirmed it on Windows XP with Pd-0.39.2-extended-2006-11-16. And it does not exist on Mac OS X with the same build. cyclone seems to assume that -mms-bitfields was not set when building Pd, and that is likely related to the problem. Everything else in Pd is built using -mmsbitfields. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=478070&aid=1595028&group_…

1 0

Accessing canvas_list without including g_canvas.h
by Jamie Bullock 04 May '07

04 May '07

Hi, Does anyone know if there is a way to access the canvas_list pointer from an external without including g_canvas.h? I want to be able to create a canvas and add it to the list of root canvases, but ideally I only want to use the public API (m_pd.h). Jamie

2 3

Pd: signal 6
by chris clepper 01 May '07

01 May '07

I am getting a lot of console messages with Pd 0.40 IntelMac stating the following: Pd: signal 6 closing audio... closing MIDI... ... done. My reading of sys_bail() shows that the next call after those messages is exit() but neither the pd process or the Tk app exit. I don't really follow how sys_bail is triggered and why it would not exit - although I am happy to have the processes continue. What is going on? Chris

1 0

Re: [PD-dev] add_string_support.patch
by martin.peach＠sympatico.ca 01 May '07

01 May '07

Is there a correct way to use diff to make the paths properly in the first place? Do you have to run it from a particular location or specify a path? Also I agree that string should be blob (or puredata ;)) since string implies text and it's really able to manipulate any kind of byte data. Martin > From: Hans-Christoph Steiner <hans(a)eds.org> > On May 1, 2007, at 2:59 AM, zmoelnig(a)iem.at wrote: > > > Quoting Hans-Christoph Steiner <hans(a)eds.org>: > > > >>> > >>> try "-p 2" > >> > >> This is automated, so that would mean changing all the patches in > >> packages/patches. I think it would be much easier to change that one > >> patch to remove the path information. > > > > the last one was another mail where i clicked "send" before thinking. > > > > the "-p 2" would strip _at most_ the first 2 "path-elements" (see 'man > > patch' for a better explanation) of the filenames. so > > "pd/src/g_rtext.c" becomes "g_rtext.c", while "src/g_canvas.c" becomes > > "g_canvas.c" and "m_pd.h" stays the same. > > > > so all patches should apply just as fine as they do now, and the > > string-support patch would apply too. > > > > apart from that, i agree that all patches should be "normalized" in > > a way. > > (and that "string" really should be "blob") > > Feel free to add this stuff to the build system, as long as it works > on all platforms. an older sed is installed on everything in the > auto-build farm. But it might save more trouble in the long run to > keep a consistent format. Hard to say... > > .hc

2 1

add_string_support.patch
by Hans-Christoph Steiner 01 May '07

01 May '07

I just noticed this in the build logs. Looks like the patch isn't applied at all. I think the problem is that there is a relative path in the filenames, while the working ones just have the filename, i.e. this doesn't work: |--- pd/src/g_text.c 4 Oct 2006 19:35:06 -0000 1.15 |+++ pd/src/g_text.c 12 Feb 2007 03:45:43 -0000 This works: --- g_rtext.c 6 Sep 2004 20:20:34 -0000 1.4 +++ g_rtext.c 14 Dec 2005 03:59:31 -0000 .hc Applying /home/pd/auto-build/pd-extended/packages/patches/ add_string_support.patch can't find file to patch at input line 8 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/g_text.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/g_text.c,v |retrieving revision 1.15 |diff -u -w -r1.15 g_text.c |--- pd/src/g_text.c 4 Oct 2006 19:35:06 -0000 1.15 |+++ pd/src/g_text.c 12 Feb 2007 03:45:43 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 3 out of 3 hunks ignored can't find file to patch at input line 49 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_atom.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_atom.c,v |retrieving revision 1.4 |diff -u -w -r1.4 m_atom.c |--- pd/src/m_atom.c 11 Aug 2006 20:09:07 -0000 1.4 |+++ pd/src/m_atom.c 12 Feb 2007 03:45:43 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 71 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_binbuf.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_binbuf.c,v |retrieving revision 1.13 |diff -u -w -r1.13 m_binbuf.c |--- pd/src/m_binbuf.c 4 Oct 2006 19:35:06 -0000 1.13 |+++ pd/src/m_binbuf.c 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 89 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_class.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_class.c,v |retrieving revision 1.7 |diff -u -w -r1.7 m_class.c |--- pd/src/m_class.c 15 Aug 2006 04:54:15 -0000 1.7 |+++ pd/src/m_class.c 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 9 out of 9 hunks ignored can't find file to patch at input line 206 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_imp.h |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_imp.h,v |retrieving revision 1.4 |diff -u -w -r1.4 m_imp.h |--- pd/src/m_imp.h 19 Aug 2005 23:28:03 -0000 1.4 |+++ pd/src/m_imp.h 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 2 out of 2 hunks ignored can't find file to patch at input line 229 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_obj.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_obj.c,v |retrieving revision 1.4 |diff -u -w -r1.4 m_obj.c |--- pd/src/m_obj.c 18 May 2005 04:28:51 -0000 1.4 |+++ pd/src/m_obj.c 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 6 out of 6 hunks ignored can't find file to patch at input line 334 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_pd.c |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_pd.c,v |retrieving revision 1.4 |diff -u -w -r1.4 m_pd.c |--- pd/src/m_pd.c 28 Nov 2004 21:20:42 -0000 1.4 |+++ pd/src/m_pd.c 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 1 out of 1 hunk ignored can't find file to patch at input line 354 Perhaps you used the wrong -p or --strip option? The text leading up to this was: -------------------------- |Index: pd/src/m_pd.h |=================================================================== |RCS file: /cvsroot/pure-data/pd/src/m_pd.h,v |retrieving revision 1.17 |diff -u -w -r1.17 m_pd.h |--- pd/src/m_pd.h 22 Oct 2006 21:46:11 -0000 1.17 |+++ pd/src/m_pd.h 12 Feb 2007 03:45:44 -0000 -------------------------- File to patch: Skip this patch? [y] Skipping patch. 10 out of 10 hunks ignored ------------------------------------------------------------------------ ---- I have the audacity to believe that peoples everywhere can have three meals a day for their bodies, education and culture for their minds, and dignity, equality and freedom for their spirits. - Martin Luther King, Jr.

3 5

definitions in m_pd.h that aren't present in pd (and vice versa)
by Claude Heiland-Allen 01 May '07

01 May '07

Hi, I'm trying to use SWIG in my work on a Lua external for Pd, and had to comment out the following definitions in m_pd.h to get code generated by SWIG to load without "undefined symbol" errors: EXTERN t_symbol *pd_getfilename(void); EXTERN t_symbol *pd_getdirname(void); EXTERN void pd_anything(t_pd *x, t_symbol *s, int argc, t_atom *argv); EXTERN t_parentwidgetbehavior *class_parentwidget(t_class *c); EXTERN int sys_isreadablefile(const char *name); EXTERN float garray_get(t_garray *x, t_symbol *s, t_int indx); EXTERN void c_extern(t_externclass *cls, t_newmethod newroutine, t_method freeroutine, t_symbol *name, size_t size, int tiny, t_atomtype arg1, ...); EXTERN void c_addmess(t_method fn, t_symbol *sel, t_atomtype arg1, ...); I guess these have either been removed from pd, or aren't declared with the right visibility in the source. It would be great if this could be fixed. Also, the following are visible in pd, but undeclared in m_pd.h, meaning I have to declare them myself: typedef int (*loader_t)(t_canvas *, char *); void sys_register_loader(loader_t loader); Would be super if this could be fixed too. Tested with pd-0.40-2 from Miller's site. Claude -- http://claudiusmaximus.goto10.org

2 1

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