On 01/24/2014 05:36 PM, Miller Puckette wrote:

Delete these lines in g_text.c:

     /* for comments, just draw a bar on RHS if unlocked; when a visible
     canvas is unlocked we have to call this anew on all comments, and when
     locked we erase them all via the annoying "commentbar" tag. */
 else if (x->te_type == T_TEXT && glist->gl_edit)
 {
     if (firsttime)
         sys_vgui(".x%lx.c create line\

%d %d %d %d -tags [list %sR commentbar]\n", glist_getcanvas(glist), x2, y1, x2, y2, tag); else sys_vgui(".x%lx.c coords %sR %d %d %d %d\n", glist_getcanvas(glist), tag, x2, y1, x2, y2); }

(however, that won't disable the functionality; just the ugly marks.)

I'm still trying to think of something less ugly - tell me if you have any ideas...

Just to give a concrete example, something like:

else if (x->te_type == T_TEXT && glist->gl_edit) { if (firsttime) sys_vgui(".x%lx.c create rect %d %d %d %d " "-dash {1 3} " "-tags [list %sR commentbar]\n", glist_getcanvas(glist), x1, y1, x2, y2, tag); else sys_vgui(".x%lx.c coords %sR %d %d %d %d\n", glist_getcanvas(glist), tag, x1, y1, x2, y2); }

Then you have a visual clue that the user is in editmode, with no ambiguity between the drawing and the text.

You can play with the dash values-- I chose those because it gives a clear contrast to broken boxes. Use a larger 2nd integer to make the dashed box stand out less.

Btw-- I haven't tested this. I'd be a lot more likely to try out code on Pd Vanilla 0.45 if someone could explain to me how to do incremental builds. If I change a single line in g_text.c in 0.43 it only requires a single "make" that takes about 3 seconds. Doing the same in 0.45 requires "make clean && make", unnecessarily rebuilding all of Pd.
Doing "make" in the src directory of 0.45 only rebuilds the things that need to recompile, but it doesn't update the binary, which makes it useless.

-Jonathan

re: "something less ugly" http://rosettacode.org/wiki/String_concatenation#LabVIEW :)

why in the world have I not thought to make an external that you can script with assembly language? I mean most modern audio devices have at least 64 programmable 'oscillators' or wave channels if you will. Even Don Buchla uses digital oscillators in his modulars nowdays. It's not like we are stuck with ay-3-8910a drum 3 channel drums. *twitch

On Fri, Jan 31, 2014 at 4:00 PM, Miller Puckette msp@ucsd.edu wrote:

On Fri, Jan 31, 2014 at 03:47:46PM -0500, Jonathan Wilkes wrote:

...

On 01/24/2014 05:36 PM, Miller Puckette wrote:

...

Delete these lines in g_text.c:

    /* for comments, just draw a bar on RHS if unlocked; when a

visible

...

...

    canvas is unlocked we have to call this anew on all comments,

and when

...

...

    locked we erase them all via the annoying "commentbar" tag. */
else if (x->te_type == T_TEXT && glist->gl_edit)
{
    if (firsttime)
        sys_vgui(".x%lx.c create line\

%d %d %d %d -tags [list %sR commentbar]\n", glist_getcanvas(glist), x2, y1, x2, y2, tag); else sys_vgui(".x%lx.c coords %sR %d %d %d %d\n", glist_getcanvas(glist), tag, x2, y1, x2, y2); }

(however, that won't disable the functionality; just the ugly marks.)

I'm still trying to think of something less ugly - tell me if you have

any

...

...

ideas...

Just to give a concrete example, something like:

else if (x->te_type == T_TEXT && glist->gl_edit) { if (firsttime) sys_vgui(".x%lx.c create rect %d %d %d %d " "-dash {1 3} " "-tags [list %sR commentbar]\n", glist_getcanvas(glist), x1, y1, x2, y2, tag); else sys_vgui(".x%lx.c coords %sR %d %d %d %d\n", glist_getcanvas(glist), tag, x1, y1, x2, y2); }

Then you have a visual clue that the user is in editmode, with no ambiguity between the drawing and the text.

You can play with the dash values-- I chose those because it gives a clear contrast to broken boxes. Use a larger 2nd integer to make the dashed box stand out less.

Btw-- I haven't tested this. I'd be a lot more likely to try out code on Pd Vanilla 0.45 if someone could explain to me how to do incremental builds. If I change a single line in g_text.c in 0.43 it only requires a single "make" that takes about 3 seconds. Doing the same in 0.45 requires "make clean && make", unnecessarily rebuilding all of Pd. Doing "make" in the src directory of 0.45 only rebuilds the things that need to recompile, but it doesn't update the binary, which makes it useless.

-Jonathan

cd pd/src; make -f makefile.gnu always works for me :)

M

...

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management ->

http://lists.puredata.info/listinfo/pd-list

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 08/03/2014 02:23 PM, Miller Puckette wrote:

Belatedly - I'm not sure what's wrong here:

What OS are you on?

Debian Wheezy.

On linux, I go to src and "make -f makefile.gnu" and on Mac, "make -f makefile.mac". Seems to do incremental rebuilds just fine for me.

Yes, I think you suggested that before and it solved the problem for me. It's just that I always did "./configure && make" to build, then "make" to do incremental builds. The "auto" system didn't allow me to continue doing that (at least not in a way that is trivial to figure out), and I wasn't sure whether that was a bug or not.

(I advise anyone but professional software packagers to stay away from the "auto" build system - lots of folks (including me) have trouble getting it to work.)

It's orders of magnitude more complex than what you describe above, but on the bright side it doesn't work very well. What is it doing there?

-Jonathan

cheers Miller

...

Btw-- I haven't tested this. I'd be a lot more likely to try out code on Pd Vanilla 0.45 if someone could explain to me how to do incremental builds. If I change a single line in g_text.c in 0.43 it only requires a single "make" that takes about 3 seconds. Doing the same in 0.45 requires "make clean && make", unnecessarily rebuilding all of Pd. Doing "make" in the src directory of 0.45 only rebuilds the things that need to recompile, but it doesn't update the binary, which makes it useless.

-Jonathan

---

Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 01/31/2014 09:47 PM, Jonathan Wilkes wrote:

Btw-- I haven't tested this. I'd be a lot more likely to try out code on Pd Vanilla 0.45 if someone could explain to me how to do incremental builds. If I change a single line in g_text.c in 0.43 it only requires a single "make" that takes about 3 seconds. Doing the same in 0.45 requires "make clean && make", unnecessarily rebuilding all of Pd.

why?

Doing "make" in the src directory of 0.45 only rebuilds the things that need to recompile, but it doesn't update the binary, which makes it useless.

how come?

it works fine here, and the binary is updated immediately.

but, then i don't know which "binary" you are talking about. the actual "pd" binary produced by the autotools, will live in ".../src/pd" (as opposed to .../bin/pd produced by the "traditional" makefile), maybe you just checked the wrong one?

i'm very much in favour of the autotools, as they make the build-system standards conformant. e.g. it's simple to inject *additional* FLAGS (e.g. for security builds). that's whey it is used for the Debian packages.

gfmdsar IOhannes

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

thanks for the detailed description.

On 2014-08-07 00:24, Jonathan Wilkes via Pd-list wrote:

4. ./src/pd

Oops... Error in startup script: couldn't read file "/home/pd-0.45-5/src/tcl//pd-gui.tcl": no such file or directory

this would be trivial to fix in Pd. i haven't done this because i considered the problem an edge case (the idea being, that we shouldn't add too much cruft to the source base to cater for the needs of very few people, esp. as there are simple workarounds).

my usual workaround for this is: $ cd src $ ln -s ../tcl .

Which-- as I already stated in an old thread-- requires me to do this from the main pd directory: cp src/pd .

Then run ./pd

Now it runs. Great!

[...]

So I don't get an updated binary in the src/ directory with "make", and I do get an updated binary when doing "make && make clean".

actually no, the last part is not quite correct (though the effect is the same).

it seems that all the problems come from compiling Pd with the included "portaudio", which enables a number of hacks to properly load the included library (rather than one provided by the system). this boils down to ./src/pd *not* being a binary at all, but instead being a wrapper script, that launches the actual binary that is hidden in ./src/.libs. now when you copy the script ./src/pd to ./ and call it, it will

• • try to launch ./.libs/pd

and if that fails it will

• • (magically) find the correct binary in ./src/.libs/ and create a

local copy in ./.libs/; and then launch it.

now when you do your changes to clip_float() and recompile, that binary in ./src/.libs/ gets updated nicely, but when you call ./pd it will still use it's outdated copy of the binary. when running "make clean" the ./.libs/ folder (containing the outdated copy) is deleted and later re-popuplated with the now-current binary.

i understand that this is a quite convoluted process, and that not everyone wants to pile up the knowledge to understand and debug this (and probably not even read my above explanation).

i can offer 3 possible "solutions":

• • disable "portaudio" when building Pd. this basically disables the

wrapper-script trickery and gives you a "src/pd" *binary* that can be run without any hacks. obviously this is not very practical if you *want* portaudio.

• • use symlinks from ./src/tcl to ./tcl, and call ./src/pd;

(rather than copying ./src/pd to ./ and then call ./pd) add this information to the documentation

• • add code to Pd that searches for the tcl-files in the correct place,

even when called from the wrapper script.

gfsd IOhannes

On 08/07/2014 11:17 AM, Miller Puckette wrote:

Or better yet, without changing any files at all - invoke Pd with the full pathname, ../src/pd (or even ../src/pd!) instead of ./pd and I think all the filename bashing will work.

That doesn't work.

But this is an academic conversation at this point. I no longer have a need to do incremental builds, I could use makefile.gnu if I needed to, and the autogen.sh works fine for IOhannes' needs.

-Jonathan

cheers M

On Thu, Aug 07, 2014 at 12:14:16PM +0200, IOhannes m zmoelnig wrote:

...

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

thanks for the detailed description.

On 2014-08-07 00:24, Jonathan Wilkes via Pd-list wrote:

...

4. ./src/pd

Oops... Error in startup script: couldn't read file "/home/pd-0.45-5/src/tcl//pd-gui.tcl": no such file or directory

this would be trivial to fix in Pd. i haven't done this because i considered the problem an edge case (the idea being, that we shouldn't add too much cruft to the source base to cater for the needs of very few people, esp. as there are simple workarounds).

my usual workaround for this is: $ cd src $ ln -s ../tcl .

...

Which-- as I already stated in an old thread-- requires me to do this from the main pd directory: cp src/pd .

Then run ./pd

Now it runs. Great!

[...]

...

So I don't get an updated binary in the src/ directory with "make", and I do get an updated binary when doing "make && make clean".

actually no, the last part is not quite correct (though the effect is the same).

it seems that all the problems come from compiling Pd with the included "portaudio", which enables a number of hacks to properly load the included library (rather than one provided by the system). this boils down to ./src/pd *not* being a binary at all, but instead being a wrapper script, that launches the actual binary that is hidden in ./src/.libs. now when you copy the script ./src/pd to ./ and call it, it will

• • try to launch ./.libs/pd

and if that fails it will

• • (magically) find the correct binary in ./src/.libs/ and create a

local copy in ./.libs/; and then launch it.

now when you do your changes to clip_float() and recompile, that binary in ./src/.libs/ gets updated nicely, but when you call ./pd it will still use it's outdated copy of the binary. when running "make clean" the ./.libs/ folder (containing the outdated copy) is deleted and later re-popuplated with the now-current binary.

i understand that this is a quite convoluted process, and that not everyone wants to pile up the knowledge to understand and debug this (and probably not even read my above explanation).

i can offer 3 possible "solutions":

• • disable "portaudio" when building Pd. this basically disables the

wrapper-script trickery and gives you a "src/pd" *binary* that can be run without any hacks. obviously this is not very practical if you *want* portaudio.

• • use symlinks from ./src/tcl to ./tcl, and call ./src/pd;
  (rather than copying ./src/pd to ./ and then call ./pd)

add this information to the documentation

• • add code to Pd that searches for the tcl-files in the correct place,

even when called from the wrapper script.

gfsd IOhannes

-----BEGIN PGP SIGNATURE----- Version: GnuPG v1 Comment: Using GnuPG with Icedove - http://www.enigmail.net/

iQIcBAEBCAAGBQJT41F1AAoJELZQGcR/ejb43K8P+wZzYCPoN5J6g1CPC3K69Wrj 3nsyDm3ugJaGVSi/CJ7Gr+CVM/gkpckbSLvmCtABDRW0etFOVrdvaF42xlA/smT9 2bD4AzCzlXc/PWerEdjaKCoP/FiVZj5a99r2moJttMMlj5WU6PS1Q1+pPxEUh98r FPMj+J069u1cArn57oTRFlKthW5yPNBdGBD7AVrvhkHC0kENmdQxqzQiioDHUsOQ xTA62K0t4HU70s85gDSbEiGI8qIda4k50sDsAPNrYnGqiyi+AXN9C2BeKEVD/Nx3 /Fmg0YDlzkMMrdjlY1YKwIHohC1S0ynrHs2zuCkzPCzeU0gAo1u5PHpNwExMy5Mq h98yBWAdSuhLBGlyZAindGopHiES9julDO3NghQyVDSXFQmoGnQig+bVwuS938P6 +l+BTk49kSoltiC9rYP+zusSQ0rFS5ytkyQPJXdegA93hvnroamTNEb0IL80V0dK PCtUX2ngjMweBhJBbUrvD/MHzTaX6mIEgd1TX0xMk5wkeDwJNhFrlpnGWasAulhk YX6ti0mZ9WnDBE4wlXZ4yVulx6eWa896J+aIL4/GcCf0XnKGETdh92DSBWGvLZjN dwsXDAM5IxKhI95F6xU6MJ4y8y8W8U1iPe6rL2DxOKylhr8em8X0+R4CVyXg2QoQ GLLBbHlrYH2TvQP3b5oB =BURL -----END PGP SIGNATURE-----

---

Pd-list@lists.iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

On 08/25/2014 05:29 AM, IOhannes m zmoelnig wrote:

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256

On 2014-08-07 17:56, Jonathan Wilkes via Pd-list wrote:

...

On 08/07/2014 11:17 AM, Miller Puckette wrote:

...

Or better yet, without changing any files at all - invoke Pd with the full pathname, ../src/pd (or even ../src/pd!) instead of ./pd and I think all the filename bashing will work.

That doesn't work.

indeed that doesn't work.

...

But this is an academic conversation at this point. I no longer have a need to do incremental builds,

aha. i guess it is not correct that just because the problem is no longer relevant for *you* it has disappeared.

I'm not trying to magically absolve you of the responsibility to fix the problem you apparently created. All I'm saying is that I no longer do regular, incremental builds on Vanilla (and that when I need to do that I can use the method Miller gave me). *For me*, that means cost of threads turning unpleasant on a dime like this outweighs the potential benefits of continuing a conversation with you.

-Jonathan