Re: [PD-dev] [PD] pd-extended build on 9.10
thank you very much Hans, everything is working (only Bitstream Vera is missing). pat ___ 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
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
Re: [PD-dev] [PD] pd-extended build on 9.10
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 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] much better scrolling algorithm (pd-extended 0.42.5)
> 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] much better scrolling algorithm (pd-extended 0.42.5)
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] two patches for pd vanilla and pd-extended 0.42.5
> > 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] [PD] pd-extended build on 9.10
On Sun, Nov 1, 2009 at 12:51 AM, Hans-Christoph Steiner 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 ___ 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
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] compiling pd-extended for ubuntu 9.10
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
> >> 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] [PD] pd-extended build on 9.10
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] compiling pd-extended for ubuntu 9.10
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] much better scrolling algorithm (pd-extended 0.42.5)
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 [$par
Re: [PD-dev] [PD] pd-extended build on 9.10
On Oct 31, 2009, at 3:03 PM, András Murányi wrote: On Sat, Oct 31, 2009 at 5:13 PM, olsen 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] two patches for pd vanilla and pd-extended 0.42.5
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.tk question
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
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
[PD-dev] s_audio_jack.c patch
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] compiling pd-extended for ubuntu 9.10
another one: make[3]: Entering directory `/home/psc/src/pd/externals/pdp/opengl' make -C system make[4]: Entering directory `/home/psc/src/pd/externals/pdp/opengl/system' cc -DPD -O2 -funroll-loops -fomit-frame-pointer -ffast-math -Wall -W -Wstrict-prototypes -Wno-unused -Wno-parentheses -Wno-switch -g -I../../../../pd/src -fPIC -I../../include -I../include -I/usr/X11R6/include -DPDP_VERSION=\"0.12.5-darcs\" -o pdp_texture.o -c pdp_texture.c pdp_texture.c:219: error: conflicting types for ‘pdp_packet_texture_isvalid’ ../include/pdp_texture.h:59: note: previous declaration of ‘pdp_packet_texture_isvalid’ was here make[4]: *** [pdp_texture.o] Error 1 make[4]: Leaving directory `/home/psc/src/pd/externals/pdp/opengl/system' make[3]: *** [subdirs] Error 2 make[3]: Leaving directory `/home/psc/src/pd/externals/pdp/opengl' make[2]: *** [/home/psc/src/pd/externals/pdp/opengl/pdp_opengl.pd_linux] 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 ___ Pd-dev mailing list Pd-dev@iem.at http://lists.puredata.info/listinfo/pd-dev
Re: [PD-dev] pd.tk question
On Sat, Oct 31, 2009 at 7:00 PM, Hans-Christoph Steiner 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). 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
Re: [PD-dev] [PD] pd-extended build on 9.10
On Sat, Oct 31, 2009 at 5:13 PM, olsen 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 ___ 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
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.tk question
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
[PD-dev] two patches for pd vanilla and pd-extended 0.42.5
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] compiling pd-extended for ubuntu 9.10
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_cast(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] compiling pd-extended for ubuntu 9.10
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_cast(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
