[PD-dev] compiling pd-extended for ubuntu 9.10

2009-10-31 Thread patrick

hi,

i have this error when compiling pd-extended for ubuntu 9.10:

make -C /home/psc/src/pd/externals/gem2pdp
make[3]: Entering directory `/home/psc/src/pd/externals/gem2pdp'
g++ -fPIC -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math -Wall 
-W -Wno-unused -Wno-parentheses -Wno-switch -DGEM2PDP_VERSION=\0.7\ -g 
-g -O2 -I/home/psc/src/pd/pd/src -I. 
-I/home/psc/src/pd/externals/pdp/include -I/home/psc/src/pd/Gem/src -o 
gem2pdp.o -c gem2pdp.cpp

In file included from /home/psc/src/pd/Gem/src/Base/CPPExtern.h:20,
from /home/psc/src/pd/Gem/src/Base/GemBase.h:20,
from gem2pdp.h:13,
from gem2pdp.cpp:11:
/home/psc/src/pd/Gem/src/Base/GemVersion.h:13: warning: type qualifiers 
ignored on function return type

In file included from /home/psc/src/pd/externals/pdp/include/pdp.h:41,
from gem2pdp.h:15,
from gem2pdp.cpp:11:
/home/psc/src/pd/externals/pdp/include/pdp_types.h:50: error: 
redeclaration of C++ built-in type ‘bool’

make[3]: *** [gem2pdp.o] Error 1
make[3]: Leaving directory `/home/psc/src/pd/externals/gem2pdp'
make[2]: *** [gem2pdp] Error 2
make[2]: Leaving directory `/home/psc/src/pd/externals'
make[1]: *** [externals_install] Error 2
make[1]: Leaving directory `/home/psc/src/pd/packages'
make: *** [install] Error 2

also i had to modified:

char * extension = strrchr(filename, '.');

for
char * extension = strrchr(const_castchar*(filename), '.');

as reported by ClaudiusMaximus
http://www.mail-archive.com/gem-...@iem.at/msg00236.html

pat

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] compiling pd-extended for ubuntu 9.10

2009-10-31 Thread Hans-Christoph Steiner


My fault, 'bool' is typedef'ed not #define'ed so you can't test it  
with a #ifndef.  I just discovered all this stuff is in the standard  
C99 header stdbool.h anyhow.  'svn up' externals/pdp/include' and try  
again.


.hc

On Oct 31, 2009, at 5:46 AM, patrick wrote:


hi,

i have this error when compiling pd-extended for ubuntu 9.10:

make -C /home/psc/src/pd/externals/gem2pdp
make[3]: Entering directory `/home/psc/src/pd/externals/gem2pdp'
g++ -fPIC -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math - 
Wall -W -Wno-unused -Wno-parentheses -Wno-switch -DGEM2PDP_VERSION= 
\0.7\ -g -g -O2 -I/home/psc/src/pd/pd/src -I. -I/home/psc/src/pd/ 
externals/pdp/include -I/home/psc/src/pd/Gem/src -o gem2pdp.o -c  
gem2pdp.cpp

In file included from /home/psc/src/pd/Gem/src/Base/CPPExtern.h:20,
from /home/psc/src/pd/Gem/src/Base/GemBase.h:20,
from gem2pdp.h:13,
from gem2pdp.cpp:11:
/home/psc/src/pd/Gem/src/Base/GemVersion.h:13: warning: type  
qualifiers ignored on function return type

In file included from /home/psc/src/pd/externals/pdp/include/pdp.h:41,
from gem2pdp.h:15,
from gem2pdp.cpp:11:
/home/psc/src/pd/externals/pdp/include/pdp_types.h:50: error:  
redeclaration of C++ built-in type ‘bool’

make[3]: *** [gem2pdp.o] Error 1
make[3]: Leaving directory `/home/psc/src/pd/externals/gem2pdp'
make[2]: *** [gem2pdp] Error 2
make[2]: Leaving directory `/home/psc/src/pd/externals'
make[1]: *** [externals_install] Error 2
make[1]: Leaving directory `/home/psc/src/pd/packages'
make: *** [install] Error 2

also i had to modified:

char * extension = strrchr(filename, '.');

for
char * extension = strrchr(const_castchar*(filename), '.');

as reported by ClaudiusMaximus
http://www.mail-archive.com/gem-...@iem.at/msg00236.html

pat

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev






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




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


[PD-dev] two patches for pd vanilla and pd-extended 0.42.5

2009-10-31 Thread Ivica Ico Bukvic
Here are two patches for g_editor.c that fix following issues in 0.42.5:

1) undo recreates patch cords with wrong color (I posted this one
earlier by mistake on the pd-list)

2) graph on parent (GOP) enable and then immediately disable crashes
patches that haven't been closed prior to disabling GOP (to reproduce,
open new patch-right-click-properties-enable gop-apply-disable
gop-apply-crash). This one may also affect pd vanilla (haven't
checked)

Best wishes,

ico
--- g_editor_old.c	2009-10-30 22:13:16.0 -0400
+++ g_editor.c	2009-10-31 13:34:00.0 -0400
@@ -909,11 +909,15 @@ void canvas_destroy_editor(t_glist *x)
 t_object *ob;
 if (x-gl_editor)
 {
-for (y = x-gl_list; y; y = y-g_next)
-if (ob = pd_checkobject(y-g_pd))
-rtext_free(glist_findrtext(x, ob));
-editor_free(x-gl_editor, x);
-x-gl_editor = 0;
+		if (x-gl_list) {
+	for (y = x-gl_list; y; y = y-g_next)
+	if (ob = pd_checkobject(y-g_pd))
+	rtext_free(glist_findrtext(x, ob));
+			if (x-gl_editor) {
+editor_free(x-gl_editor, x);
+x-gl_editor = 0;
+			}
+		}
 }
 }

--- g_editor_old.c	2009-10-30 22:13:16.0 -0400
+++ g_editor.c	2009-10-30 22:13:40.0 -0400
@@ -2472,9 +2472,9 @@ void canvas_connect(t_canvas *x, t_float
 if (!(oc = obj_connect(objsrc, outno, objsink, inno))) goto bad;
 if (glist_isvisible(x))
 {
-sys_vgui(.x%lx.c create line %d %d %d %d -width %d -tags l%lx\n,
+sys_vgui(.x%lx.c create line %d %d %d %d -width %d -fill %s -tags l%lx\n,
 glist_getcanvas(x), 0, 0, 0, 0,
-(obj_issignaloutlet(objsrc, outno) ? 2 : 1),oc);
+(obj_issignaloutlet(objsrc, outno) ? 2 : 1), (obj_issignaloutlet(objsrc, outno) ? $signal_cord : $msg_cord), oc);
 canvas_fixlinesfor(x, objsrc);
 }
 return;
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] pd.tk question

2009-10-31 Thread Hans-Christoph Steiner


On Oct 30, 2009, at 10:24 PM, Ivica Ico Bukvic wrote:


Hey Ivica,

Just make it a global, that's the easiest.  Or use namespaces and
namespace variables.

.hc


I am not all that good with tk. Only learned what I had to to hack
together better version of pd.tk. Any examples would be most
appreciated. How do namespaces work?

Also, after opening tons of windows that generate global variables,
doesn't this effectively produce a minor but nonetheless present  
memory

leak as the global variables will be hard to trace when deallocating
those windows (see my other email re: improvements)?

Ico


Look at the new pd-gui-rewrite branch, it uses namespaces a fair  
amount.  They are a bit overcomplicated in Tcl, but you don't have to  
use the complicated parts.


.hc






kill your television



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] two patches for pd vanilla and pd-extended 0.42.5

2009-10-31 Thread Ivica Ico Bukvic
On Sat, 2009-10-31 at 13:39 -0400, Ivica Ico Bukvic wrote:
 Here are two patches for g_editor.c that fix following issues in 0.42.5:
 
 1) undo recreates patch cords with wrong color (I posted this one
 earlier by mistake on the pd-list)
 
 2) graph on parent (GOP) enable and then immediately disable crashes
 patches that haven't been closed prior to disabling GOP (to reproduce,
 open new patch-right-click-properties-enable gop-apply-disable
 gop-apply-crash). This one may also affect pd vanilla (haven't
 checked)

Oops, discovered another bug:

New patcher-create [pd something]-inside new patcher create any object
(e.g. symbol) and leave it selected-right-click on
canvas-properties-enable gop-apply-disable gop-apply-crash

New patch should supersede the previous patch for the second point
fixing this problem as well.

Ico
--- g_editor_old.c	2009-10-30 22:13:16.0 -0400
+++ g_editor.c	2009-10-31 14:01:29.0 -0400
@@ -907,13 +907,18 @@ void canvas_destroy_editor(t_glist *x)
 {
 t_gobj *y;
 t_object *ob;
+	glist_noselect(x);
 if (x-gl_editor)
 {
-for (y = x-gl_list; y; y = y-g_next)
-if (ob = pd_checkobject(y-g_pd))
-rtext_free(glist_findrtext(x, ob));
-editor_free(x-gl_editor, x);
-x-gl_editor = 0;
+		if (x-gl_list) {
+	for (y = x-gl_list; y; y = y-g_next)
+	if (ob = pd_checkobject(y-g_pd))
+	rtext_free(glist_findrtext(x, ob));
+			if (x-gl_editor) {
+editor_free(x-gl_editor, x);
+x-gl_editor = 0;
+			}
+		}
 }
 }
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread András Murányi
On Sat, Oct 31, 2009 at 5:13 PM, olsen sesselastron...@googlemail.comwrote:

 buenas
 ydego...@gmail.com wrote:

 ola,


 /usr/lib/pd/extra/pidip/pidip.pd_linux:
 /usr/lib/pd/extra/pidip/pidip.pd_linux: undefined symbol:
 quicktime_has_video
 pidip: can't load library


  it's been a long time i haven't seen this one
 this means that you load pidip before loading pdp,
 or you don't load pdp at all

 i guess this was because my brain was building this trunken package as hans
 indicated.
 so now i'm trying to follow the instructions on build  whoop:

 gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses
 -Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math
 -DPDP_VERSION=\0.12.5-darcs\ -I. -I/usr/X11R6/include  -I../include
 -I../../include -I/home/olsen/pd/pd-extended_2/pd-extended/pd/src   -o
 pdp_bitmap.o -c pdp_bitmap.c
 pdp_bitmap.c:41: error: conflicting types for ‘pdp_packet_bitmap_isvalid’
 ../../include/pdp_bitmap.h:90: note: previous declaration of
 ‘pdp_packet_bitmap_isvalid’ was here
 make[5]: *** [pdp_bitmap.o] Error 1

 any bughunter knows this one?
 salutis
 ø



I'm standing at the same one (on amd64).

Andras
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] pd.tk question

2009-10-31 Thread András Murányi
On Sat, Oct 31, 2009 at 7:00 PM, Hans-Christoph Steiner h...@at.or.atwrote:


 On Oct 30, 2009, at 10:24 PM, Ivica Ico Bukvic wrote:

  Hey Ivica,

 Just make it a global, that's the easiest.  Or use namespaces and
 namespace variables.

 .hc


 I am not all that good with tk. Only learned what I had to to hack
 together better version of pd.tk. Any examples would be most
 appreciated. How do namespaces work?

 Also, after opening tons of windows that generate global variables,
 doesn't this effectively produce a minor but nonetheless present memory
 leak as the global variables will be hard to trace when deallocating
 those windows (see my other email re: improvements)?

 Ico


 Look at the new pd-gui-rewrite branch, it uses namespaces a fair amount.
  They are a bit overcomplicated in Tcl, but you don't have to use the
 complicated parts.

 .hc


Hans, when you have a few minutes can you just sum up quickly how does it go
with namespaces? I've familiarized easy with everything else in the sources,
but i couldn't get namespaces do anything (thus my tabbed-console plugin
doesn't see the popupmode setting).

Btw, i would be happy to clean up pdtk_post as suggested by the comments,
but i have questions:
- this should be switchable between Pd window and stderr: how do you
imagine this; a command line switch or from preferences...?
- you mentioned you would shift popupmode to a plugin, is it ok if i give it
a shot?

Andras
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


[PD-dev] s_audio_jack.c patch

2009-10-31 Thread Ivica Ico Bukvic
The following patch fixes jack auto-connect problem encountered on
Ubuntu 9.04.

Best wishes,

Ico


--- s_audio_jack.c	2009-10-29 19:57:33.0 -0400
+++ ../../../../pd-extended-svn/pd-extended/pd/src/s_audio_jack.c	2009-05-28 21:14:05.0 -0400
@@ -153,7 +153,7 @@ static char** jack_get_clients(void)
  * it in spot 0 put it in spot 0 and move whatever
  * was already in spot 0 to the end. */
 
-if( strcmp( alsa_pcm, tmp_client_name ) == 0  num_clients  0 )
+if( strcmp( system, tmp_client_name ) == 0  num_clients  0 )
 {
   char* tmp;
 /* alsa_pcm goes in spot 0 */
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] pd.tk question

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 3:12 PM, András Murányi wrote:




On Sat, Oct 31, 2009 at 7:00 PM, Hans-Christoph Steiner  
h...@at.or.at wrote:


On Oct 30, 2009, at 10:24 PM, Ivica Ico Bukvic wrote:

Hey Ivica,

Just make it a global, that's the easiest.  Or use namespaces and
namespace variables.

.hc

I am not all that good with tk. Only learned what I had to to hack
together better version of pd.tk. Any examples would be most
appreciated. How do namespaces work?

Also, after opening tons of windows that generate global variables,
doesn't this effectively produce a minor but nonetheless present  
memory

leak as the global variables will be hard to trace when deallocating
those windows (see my other email re: improvements)?

Ico

Look at the new pd-gui-rewrite branch, it uses namespaces a fair  
amount.  They are a bit overcomplicated in Tcl, but you don't have  
to use the complicated parts.


.hc


Hans, when you have a few minutes can you just sum up quickly how  
does it go with namespaces? I've familiarized easy with everything  
else in the sources, but i couldn't get namespaces do anything (thus  
my tabbed-console plugin doesn't see the popupmode setting).


Here are the basics:

Create a namespace 'pdwindow' with the variable 'printout_buffer' in it:
namespace eval pdwindow {
variable printout_buffer
...
}

use the 'printout_buffer' variable anywhere with the namespace prefix:
puts $::pdwindow::printout_buffer


Create a proc in the 'pdwindow' namespace and use 'printout_buffer'  
without the prefix:

proc ::pdwindow::pdtk_post {message} {
variable printout_buffer
puts $printout_buffer
...
}

Call the pdtk_post proc from anywhere:

::pdwindow::pdtk_post blah blah

All the pdtk_post proc to be used outside of the 'pdwindow' namespace:
namespace eval pdwindow {
...
namespace export pdtk_post
...
}

Use the 'pdtk_post' proc from the pdwindow namespace globally without  
the prefix

namespace import ::pdwindow::pdtk_post
pdtk_post blah blah


Btw, i would be happy to clean up pdtk_post as suggested by the  
comments, but i have questions:
- this should be switchable between Pd window and stderr: how do  
you imagine this; a command line switch or from preferences...?
- you mentioned you would shift popupmode to a plugin, is it ok if i  
give it a shot?


Sure, but I recently fixed those two, thanks to mescalinum's  
opt_parser code. :)  I suppose I should remove the TODO...


.hc





kill your television


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] two patches for pd vanilla and pd-extended 0.42.5

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 1:39 PM, Ivica Ico Bukvic wrote:

Here are two patches for g_editor.c that fix following issues in  
0.42.5:


1) undo recreates patch cords with wrong color (I posted this one
earlier by mistake on the pd-list)


Accepted and committed.


2) graph on parent (GOP) enable and then immediately disable crashes
patches that haven't been closed prior to disabling GOP (to reproduce,
open new patch-right-click-properties-enable gop-apply-disable
gop-apply-crash). This one may also affect pd vanilla (haven't
checked)


Looks good to me.   Is it still present in 0.43?  Submit this to the  
patch tracker and assign it to Miller.  Then I can accept it in Pd- 
extended.  One change, I'd do this patch like this, I think its cleaner:


Index: g_editor.c
===
--- g_editor.c  (revision 12704)
+++ g_editor.c  (working copy)
@@ -907,13 +907,15 @@
 {
 t_gobj *y;
 t_object *ob;
-if (x-gl_editor)
+if (x-gl_editor  x-gl_list)
 {
 for (y = x-gl_list; y; y = y-g_next)
 if (ob = pd_checkobject(y-g_pd))
 rtext_free(glist_findrtext(x, ob));
-editor_free(x-gl_editor, x);
-x-gl_editor = 0;
+if (x-gl_editor) {
+editor_free(x-gl_editor, x);
+x-gl_editor = 0;
+}
 }
 }


.hc




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.




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 3:03 PM, András Murányi wrote:




On Sat, Oct 31, 2009 at 5:13 PM, olsen  
sesselastron...@googlemail.com wrote:

buenas
ydego...@gmail.com wrote:
ola,

/usr/lib/pd/extra/pidip/pidip.pd_linux: /usr/lib/pd/extra/pidip/ 
pidip.pd_linux: undefined symbol: quicktime_has_video

pidip: can't load library


it's been a long time i haven't seen this one
this means that you load pidip before loading pdp,
or you don't load pdp at all
i guess this was because my brain was building this trunken package  
as hans indicated.

so now i'm trying to follow the instructions on build  whoop:

gcc -DPD -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses - 
Wno-switch -fPIC -O2 -funroll-loops -fomit-frame-pointer -ffast-math  
-DPDP_VERSION=\0.12.5-darcs\ -I. -I/usr/X11R6/include  -I../ 
include -I../../include -I/home/olsen/pd/pd-extended_2/pd-extended/ 
pd/src   -o pdp_bitmap.o -c pdp_bitmap.c
pdp_bitmap.c:41: error: conflicting types for  
‘pdp_packet_bitmap_isvalid’
../../include/pdp_bitmap.h:90: note: previous declaration of  
‘pdp_packet_bitmap_isvalid’ was here

make[5]: *** [pdp_bitmap.o] Error 1

any bughunter knows this one?
salutis
ø



I'm standing at the same one (on amd64).

Andras


There was a mismatch between the header declaration, which used a  
'bool' return type and the actual functions themselves, which used an  
'int' return type.  Previously this didn't matter since there was a  
#define bool int, which means that all the 'bool's where converted to  
'int's before compilation.


Now, its the way it should be.  'svn up' and try again.

.hc





Free software means you control what your computer does. Non-free  
software means someone else controls that, and to some extent controls  
you. - Richard M. Stallman



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)

2009-10-31 Thread Hans-Christoph Steiner


Hey Ivica,

I rewrote the scrollbar logic in 0.43 and its working well, as far as  
I can tell.  Have you tried it out?  I think its a similar approach,  
but the difference is that my code tries to keep things at 0,0 since  
Pd has a historical preference for patches having 0,0 as the upper left.


.hc

On Oct 31, 2009, at 3:34 PM, Ivica Ico Bukvic wrote:

Below is relevant excerpt that IMHO is much better scrolling  
algorithm.

It has been tested only on Linux so far but there is no reason why it
should not work on other platforms. Basically, now the whole canvas
translates as necessary. Therefore,

1) dragging a single object away from 0 0 coordinates will never  
spawn a

scrollbar (since we don't care how far someone goes away from
center--theoretically their whole patch could be at -3 to -29800  
(x1

x2). That said, I am not sure if the thing will crash if you go beyond
1.0e30 either direction but I suspect it will take a long while before
you get there :-)
2) scrollbars appear/disappear logically, (e.g. only when two or more
objects are far enough from each other not to fit on the visible  
portion

of the canvas)
3) and perhaps most importantly since text (particularly larger text
commonly used for iemlib gui elements) generates incorrect reports  
from

the bbox all call (e.g. try creating a number2 with a height 80 and
notice how you are never able to drag it all the way to the top of the
canvas without invoking the Y-axis scrollbar even though your text  
might
be font 10; larger font sizes make things even worse). So now  
finally I

can create compact windows without scrollbars using iemlib objects.

Optionally, if you wish to use hacked pd.tk version (made for
pd-extended 0.42.5). You will also have an option to disable  
scrollbars,

menu, alter background color, toggle ontop, and disable resize, *per
patcher*. I found this to be also rather useful for GUI creation.
Attached with the new pd.tk are supporting abstractions.

Below is relevant code for points 1-3 from the current pd.tk in hope  
it

will find its way into 0.43 gui rewrite.

proc pdtk_canvas_getscroll {name} {
   global pdtk_canvas_mouseup_name
   global pdtk_canvas_mouseup_xminval
   global pdtk_canvas_mouseup_xmaxval
   global pdtk_canvas_mouseup_yminval
   global pdtk_canvas_mouseup_ymaxval

#bbox all is not accurate enough
#particularly when using large iemlib objects
#so we calculate canvas size manually
   #set size [$name bbox all]

#borrowed from http://wiki.tcl.tk/4844
set x1 1.0e30; set x2 -1.0e30 ;
set y1 1.0e30; set y2 -1.0e30 ;
foreach item [$name find all] {
switch -exact [$name type $item] {
arc -
line -
oval -
polygon -
rectangle {
set coords [$name coords $item]
foreach {x y} $coords {
if { $x  $x1 } {set x1 $x}
if { $x  $x2 } {set x2 $x}
if { $y  $y1 } {set y1 $y}
if { $y  $y2 } {set y2 $y}
}
}
}
}

if {$x1 != 1.0e30} {

set xminval 0
set yminval 0
set xmaxval 100
set ymaxval 20
#set x1 [lindex $size 0]
#set x2 [lindex $size 2]
#set y1 [lindex $size 1]
#set y2 [lindex $size 3]

#pdtk_post bbox all: $x1 $x2 $y1 $y2\n
#pdtk_post new bbox all: $xbox1 $xbox2 $ybox1 $ybox2\n

#these work much better than the ones below
#they allow for intelligent translation of the canvas
#rather than introducing redundant scrollbars
set xminval $x1
set yminval $y1

set xmaxval [expr $x1+($x2-$x1)]
set ymaxval [expr $y1+($y2-$y1)]

#if {$x1  $xminval} {set xminval $x1}
#if {$y1  $yminval} {set yminval $y1}

#if {$x2  $xmaxval} {set xmaxval $x2}
#if {$y2  $ymaxval} {set ymaxval $y2}

#pdtk_post $xminval $xmaxval $yminval $ymaxval\n

set parentname [winfo parent $name]
set winwidth [winfo width $parentname]
set winheight [winfo height $parentname]

set canvaswidth [ expr {abs($xmaxval-$xminval)} ]
set canvasheight [ expr {abs($ymaxval-$yminval)} ]
#set canvaswidth [ expr {abs($xminval)+$xmaxval} ]
#set canvasheight [ expr {abs($yminval)+$ymaxval} ]

#pdtk_post $canvaswidth $canvasheight\n

#pdtk_post $parentname [$parentname.scroll cget 

Re: [PD-dev] compiling pd-extended for ubuntu 9.10

2009-10-31 Thread patrick

oups, sorry (same report as olsen)...

fixed with:

pd/externals/pdp/opengl/include/pdp_texture.h

- bool pdp_packet_texture_isvalid(int packet);
+ int pdp_packet_texture_isvalid(int packet);


pat

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread patrick

using svn, then rm -rf pd and:
svn co 
https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.42/pd


i am getting this error:
fakeroot dpkg-deb --build /home/psc/src/pd/packages/linux_make/build/ 
/home/psc/src/pd/packages/linux_make/Pd-0.42.5-extended.deb

dpkg-deb - error: Debian revision (`extended') doesn't contain any digits
dpkg-deb: 1 errors in control file
make: *** [deb] Error 2

pat

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread András Murányi

 pdp_bitmap.c:41: error: conflicting types for ‘pdp_packet_bitmap_isvalid’
 ../../include/pdp_bitmap.h:90: note: previous declaration of
 ‘pdp_packet_bitmap_isvalid’ was here
 make[5]: *** [pdp_bitmap.o] Error 1

 any bughunter knows this one?
 salutis
 ø


 I'm standing at the same one (on amd64).


 There was a mismatch between the header declaration, which used a 'bool'
 return type and the actual functions themselves, which used an 'int' return
 type.  Previously this didn't matter since there was a #define bool int,
 which means that all the 'bool's where converted to 'int's before
 compilation.

 Now, its the way it should be.  'svn up' and try again.


No luck... svn pulled the new files but i'm still getting the error

Andras
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] compiling pd-extended for ubuntu 9.10

2009-10-31 Thread Hans-Christoph Steiner


Thanks.  Fixed in svn, commit 12709.

.hc

On Oct 31, 2009, at 5:15 PM, patrick wrote:


oups, sorry (same report as olsen)...

fixed with:

pd/externals/pdp/opengl/include/pdp_texture.h

- bool pdp_packet_texture_isvalid(int packet);
+ int pdp_packet_texture_isvalid(int packet);


pat

___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev






  ¡El pueblo unido jamás será vencido!



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 5:30 PM, patrick wrote:


using svn, then rm -rf pd and:
svn co 
https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.42/pd

i am getting this error:
fakeroot dpkg-deb --build /home/psc/src/pd/packages/linux_make/ 
build/ /home/psc/src/pd/packages/linux_make/Pd-0.42.5-extended.deb
dpkg-deb - error: Debian revision (`extended') doesn't contain any  
digits

dpkg-deb: 1 errors in control file
make: *** [deb] Error 2


cd packages
svn up Makefile

That should fix that bug.

.hc



The arc of history bends towards justice. - Dr. Martin Luther  
King, Jr.




___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread András Murányi
On Sun, Nov 1, 2009 at 12:51 AM, Hans-Christoph Steiner h...@at.or.atwrote:


 On Oct 31, 2009, at 5:30 PM, patrick wrote:

  using svn, then rm -rf pd and:
 svn co
 https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.42/pd

 i am getting this error:
 fakeroot dpkg-deb --build /home/psc/src/pd/packages/linux_make/build/
 /home/psc/src/pd/packages/linux_make/Pd-0.42.5-extended.deb
 dpkg-deb - error: Debian revision (`extended') doesn't contain any digits
 dpkg-deb: 1 errors in control file
 make: *** [deb] Error 2


 cd packages
 svn up Makefile

 That should fix that bug.


yes, i just committed a bit too early.
and now (with all the externals)...:

linux_make install succeeded!


and i'm back to this:

fakeroot dpkg-deb --build
 /home/muranyia/Download/pure-data/packages/linux_make/build/
 /home/muranyia/Download/pure-data/packages/linux_make/Pd-0.42.5-extended.deb
 dpkg-deb - error: Debian revision (`extended') doesn't contain any digits
 dpkg-deb: 1 errors in control file


Andras
___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] two patches for pd vanilla and pd-extended 0.42.5

2009-10-31 Thread Ivica Ico Bukvic

  2) graph on parent (GOP) enable and then immediately disable crashes
  patches that haven't been closed prior to disabling GOP (to reproduce,
  open new patch-right-click-properties-enable gop-apply-disable
  gop-apply-crash). This one may also affect pd vanilla (haven't
  checked)
 
 Looks good to me.   Is it still present in 0.43?  Submit this to the

Just tested it and yes it is present in 0.43 (pd-gui-rewrite version I
checked out less than a week ago from svn).

   
 patch tracker and assign it to Miller.  Then I can accept it in Pd- 
 extended.  One change, I'd do this patch like this, I think its cleaner:
 
 Index: g_editor.c
 ===
 --- g_editor.c(revision 12704)
 +++ g_editor.c(working copy)
 @@ -907,13 +907,15 @@
   {
   t_gobj *y;
   t_object *ob;
 -if (x-gl_editor)
 +if (x-gl_editor  x-gl_list) -HERE
   {
   for (y = x-gl_list; y; y = y-g_next)
   if (ob = pd_checkobject(y-g_pd))
   rtext_free(glist_findrtext(x, ob));
 -editor_free(x-gl_editor, x);
 -x-gl_editor = 0;
 +if (x-gl_editor) {

I think this is superfluous, the code is already checking that in the
previous if statement (see ASCII arrow above). The code in between the
arrow and this if statement TTBOMK does not touch gl_editor. So, my vote
would be to leave the patch as-is.

However, please note another more important omission which deals with
the other bug I reported in the follow-up email:

--- g_editor_old.c  2009-10-30 22:13:16.0 -0400
+++ g_editor.c  2009-10-31 14:01:29.0 -0400
@@ -907,13 +907,18 @@ void canvas_destroy_editor(t_glist *x)
 {
 t_gobj *y;
 t_object *ob;
+   glist_noselect(x);
 if (x-gl_editor)

It appears if noselect is not called prior to running the rest of the
code, it crashes in deselect part. This simply deselects selected
objects when disabling GOP. To reproduce this problem do the following:

New patcher-create [pd something]-inside new patcher create any object
(e.g. symbol) *and leave the object selected*-right-click on
canvas-properties-enable gop-apply-disable gop-apply-crash

 +editor_free(x-gl_editor, x);
 +x-gl_editor = 0;
 +}

Obviously I would also remove the last line if you agree to remove the
if statement in question.

Best wishes,

Ico


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)

2009-10-31 Thread Ivica Ico Bukvic
On Sat, 2009-10-31 at 17:18 -0400, Hans-Christoph Steiner wrote:
 Hey Ivica,
 
 I rewrote the scrollbar logic in 0.43 and its working well, as far as  
 I can tell.  Have you tried it out?  I think its a similar approach,  
 but the difference is that my code tries to keep things at 0,0 since  
 Pd has a historical preference for patches having 0,0 as the upper left.
 
 .hc

I see. After I've played with the 0.43 and here are a couple reasons why
I feel this implementation is still (IMHO) better:

1) it seems does that the canvas does not create scrollbars until you
let go of an object. So if you do go off-canvas, the scrollbar does not
appear until you do mouse-up. I personally find this distracting as the
canvas does not update dynamically. This is not the case with the
submitted patch.

2) more importantly, pd-gui-rewrite still suffers from miscalculated
bbox all size which this patch also addresses. e.g. try creating a
number2 object and adjust its height to 80 (top-right value on the
properties window). Now drag it all the way up and it can never reach
the edge of the top side of the canvas (or any other side for that
matter, depending upon the width parameter) due to miscalculated size
(bbox accounts for text as well and text through this process scales
incorrectly according to this tk post: http://wiki.tcl.tk/4844). Of
course, not everyone needs size 80 number2 box but this discrepancy is
present at all sizes--it is just less noticeable at smaller ones as in
those cases rectangle around the text is much closer to the text size if
not greater. In other words, with greater size value, the text size
grows faster than the size of graphical elements (rectangles, lines,
etc.).

3) 0 0 coordinate-centric design IMHO does not make sense. From
historical perspective, old patches should still TTBOMK open just fine.
Yet, if 0 0 approach is still imposed, it results in unintuitive
behavior of scrollbars. e.g. try the following on 0.43 (or previous
versions without the suggested patch):

create an object-create another object and slide it to the right until
it goes outside the canvas area-a horizontal scrollbar will indicate
there is more stuff to the right-scroll to the right and at this point
you may find both of your objects (effectively your whole patch) within
the canvas, yet the scrollbar will suggest there is something to the
left when there isn't.

This has in my opinion been rather distracting while building patches,
particularly when dealing with patch GUI design, so much so that I
resorted to creating disable scrollbars option (see my other email).
But even this does not guarantee proper behavior. OTOH, my
implementation does tend to pack everything to the top left corner, but
at least this way you have an option of putting a canvas object (or some
other more functional and less GUI-oriented object) in the top left
corner and you will always meet expected results upon reopening your
patch.

On a side-note, the new gtk look on the 0.43 is too large for netbook
screens (1024x600). e.g. iem object properties do not fit. The proposed
version of the older pd.tk takes care of this without sacrificing
(obviously IMHO) readability/usability.

Many thanks for all your feedback and support! Keep up the great work!

Best wishes,

Ico


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] much better scrolling algorithm (pd-extended 0.42.5)

2009-10-31 Thread Ivica Ico Bukvic

 3) 0 0 coordinate-centric design IMHO does not make sense. From
 historical perspective, old patches should still TTBOMK open just fine.
 Yet, if 0 0 approach is still imposed, it results in unintuitive
 behavior of scrollbars. e.g. try the following on 0.43 (or previous
 versions without the suggested patch):
 
 create an object-create another object and slide it to the right until
 it goes outside the canvas area-a horizontal scrollbar will indicate
 there is more stuff to the right-scroll to the right and at this point
 you may find both of your objects (effectively your whole patch) within
 the canvas, yet the scrollbar will suggest there is something to the
 left when there isn't.

After testing this a bit more, here's a small correction. My
implementation does pack everything to the right or the left depending
upon where the whole canvas is located in respect to the 0 0 coord. This
does not however affect older patches. That said, I still feel this is
more desirable and ultimately can be further adjusted as necessary.

Best wishes,

Ico


___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] [PD] pd-extended build on 9.10

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 8:09 PM, András Murányi wrote:




On Sun, Nov 1, 2009 at 12:51 AM, Hans-Christoph Steiner  
h...@at.or.at wrote:


On Oct 31, 2009, at 5:30 PM, patrick wrote:

using svn, then rm -rf pd and:
svn co 
https://pure-data.svn.sourceforge.net/svnroot/pure-data/branches/pd-extended/0.42/pd

i am getting this error:
fakeroot dpkg-deb --build /home/psc/src/pd/packages/linux_make/ 
build/ /home/psc/src/pd/packages/linux_make/Pd-0.42.5-extended.deb
dpkg-deb - error: Debian revision (`extended') doesn't contain any  
digits

dpkg-deb: 1 errors in control file
make: *** [deb] Error 2

cd packages
svn up Makefile

That should fix that bug.


yes, i just committed a bit too early.
and now (with all the externals)...:

linux_make install succeeded!

and i'm back to this:

fakeroot dpkg-deb --build /home/muranyia/Download/pure-data/packages/ 
linux_make/build/ /home/muranyia/Download/pure-data/packages/ 
linux_make/Pd-0.42.5-extended.deb
dpkg-deb - error: Debian revision (`extended') doesn't contain any  
digits

dpkg-deb: 1 errors in control file

Andras



Ok, I think I got it. Either:

cd packages
make set_version
cd linux_make
make install  make package

Or:

cd packages
svn up Makefile
cd linux_make
make install  make package


.hc




As we enjoy great advantages from inventions of others, we should be  
glad of an opportunity to serve others by any invention of ours; and  
this we should do freely and generously. - Benjamin Franklin



___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev


Re: [PD-dev] two patches for pd vanilla and pd-extended 0.42.5

2009-10-31 Thread Hans-Christoph Steiner


On Oct 31, 2009, at 9:12 PM, Ivica Ico Bukvic wrote:




2) graph on parent (GOP) enable and then immediately disable crashes
patches that haven't been closed prior to disabling GOP (to  
reproduce,

open new patch-right-click-properties-enable gop-apply-disable
gop-apply-crash). This one may also affect pd vanilla (haven't
checked)


Looks good to me.   Is it still present in 0.43?  Submit this to the


Just tested it and yes it is present in 0.43 (pd-gui-rewrite version I
checked out less than a week ago from svn).



patch tracker and assign it to Miller.  Then I can accept it in Pd-
extended.  One change, I'd do this patch like this, I think its  
cleaner:


Index: g_editor.c
===
--- g_editor.c  (revision 12704)
+++ g_editor.c  (working copy)
@@ -907,13 +907,15 @@
 {
 t_gobj *y;
 t_object *ob;
-if (x-gl_editor)
+if (x-gl_editor  x-gl_list) -HERE
 {
 for (y = x-gl_list; y; y = y-g_next)
 if (ob = pd_checkobject(y-g_pd))
 rtext_free(glist_findrtext(x, ob));
-editor_free(x-gl_editor, x);
-x-gl_editor = 0;
+if (x-gl_editor) {


I think this is superfluous, the code is already checking that in the
previous if statement (see ASCII arrow above). The code in between the
arrow and this if statement TTBOMK does not touch gl_editor. So, my  
vote

would be to leave the patch as-is.


Stylistically, the format of your patch doesn't fit in with most Pd  
code, the change I suggest makes the patch fit into the Pd style.   
They are both functionally the same.



However, please note another more important omission which deals with
the other bug I reported in the follow-up email:

--- g_editor_old.c  2009-10-30 22:13:16.0 -0400
+++ g_editor.c  2009-10-31 14:01:29.0 -0400
@@ -907,13 +907,18 @@ void canvas_destroy_editor(t_glist *x)
{
t_gobj *y;
t_object *ob;
+   glist_noselect(x);
if (x-gl_editor)

It appears if noselect is not called prior to running the rest of the
code, it crashes in deselect part. This simply deselects selected
objects when disabling GOP. To reproduce this problem do the  
following:


New patcher-create [pd something]-inside new patcher create any  
object

(e.g. symbol) *and leave the object selected*-right-click on
canvas-properties-enable gop-apply-disable gop-apply-crash


+editor_free(x-gl_editor, x);
+x-gl_editor = 0;
+}


Obviously I would also remove the last line if you agree to remove the
if statement in question.


I don't really know the ramifications of this patch, hence submitting  
it to the patch tracker.  But fixing crasher bugs is always good.


.hc



Best wishes,

Ico








You can't steal a gift. Bird gave the world his music, and if you can  
hear it, you can have it. - Dizzy Gillespie





___
Pd-dev mailing list
Pd-dev@iem.at
http://lists.puredata.info/listinfo/pd-dev