Thanks.. I think I fixed the old-build-system make install (now updating git repo). Could you send me the patch that's giving you the tcl errors? It's turing out to be complicated getting everything to work at once!

cheers Miller

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

hello, using the old build systempd did not start (a tcl file is missing)

with the new one, it work (and fix the old build system missing file btw) but pd~ did not work. pd~: can't stat /usr/local/lib/pd/pd would it be possible for the make install to create an alias from "where pd is installed" to "where pd is used by pd~"?

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

Cyrille

Le 24/12/2011 03:53, Miller Puckette a écrit :

...

Hi all,

Test 6 was a dud (Hans reported trouble within a couple of hours!) Heeeere's test 7...

http://crca.ucsd.edu/~msp/software.htm git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data

---

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

---

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

Hello,

thanks for the quick fix.

about the error, after digging around, i found that it's not related to vanilla, but to gcanvas from ggee, that was compiled for 0.42. btw, none of ggee gui external compile for 0.43

cheers Cyrille

Le 25/12/2011 03:32, Miller Puckette a écrit :

Thanks.. I think I fixed the old-build-system make install (now updating git repo). Could you send me the patch that's giving you the tcl errors? It's turing out to be complicated getting everything to work at once!

cheers Miller

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

hello, using the old build systempd did not start (a tcl file is missing)

with the new one, it work (and fix the old build system missing file btw) but pd~ did not work. pd~: can't stat /usr/local/lib/pd/pd would it be possible for the make install to create an alias from "where pd is installed" to "where pd is used by pd~"?

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

Cyrille

Le 24/12/2011 03:53, Miller Puckette a écrit :

...

Hi all,

Test 6 was a dud (Hans reported trouble within a couple of hours!) Heeeere's test 7...

http://crca.ucsd.edu/~msp/software.htm git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data

---

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

---

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

Sorry i made “reply all“ i guess this was addressed more to miller than to cyrille On Dec 26, 2011 12:36 PM, "matteo sisti sette" matteosistisette@gmail.com wrote:

Did you fix the bug that made all gui objects of a given kind (soetimes all toggles sometimes all sliders sometimes all numberboxes) suddenly freeze and stop working at apparently random times? On Dec 25, 2011 11:18 AM, "cyrille henry" ch@chnry.net wrote:

...

Hello,

thanks for the quick fix.

about the error, after digging around, i found that it's not related to vanilla, but to gcanvas from ggee, that was compiled for 0.42. btw, none of ggee gui external compile for 0.43

cheers Cyrille

Le 25/12/2011 03:32, Miller Puckette a écrit :

...

Thanks.. I think I fixed the old-build-system make install (now updating git repo). Could you send me the patch that's giving you the tcl errors? It's turing out to be complicated getting everything to work at once!

cheers Miller

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

hello, using the old build systempd did not start (a tcl file is missing)

with the new one, it work (and fix the old build system missing file btw) but pd~ did not work. pd~: can't stat /usr/local/lib/pd/pd would it be possible for the make install to create an alias from "where pd is installed" to "where pd is used by pd~"?

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

Cyrille

Le 24/12/2011 03:53, Miller Puckette a écrit :

...

Hi all,

Test 6 was a dud (Hans reported trouble within a couple of hours!) Heeeere's test 7...

http://crca.ucsd.edu/~msp/**software.htmhttp://crca.ucsd.edu/~msp/software.htm git clone git://pure-data.git.**sourceforge.net/gitroot/pure-** data/pure-datahttp://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data

______________________________**_________________ Pd-announce mailing list Pd-announce@iem.at http://lists.puredata.info/**listinfo/pd-announcehttp://lists.puredata.info/listinfo/pd-announce

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

______________________________**_________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/** listinfo/pd-list 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 12/26/2011 07:26 PM, Miller Puckette wrote:

Hmm - I've never seen that one... do you know how to reproduce it (or is it up on the bug tracker)?

Hi,

It is issue 3298989 on the bug tracker but I don't know how to reproduce it. It happens with practically all of my old big patches that use quite a bit of GUI and GOP. I just run them and after a while it always happens.

I've never been able to isolate it.

If you are interested and if you don't mind I can send you "privately" a huge patch that exhibits the issue, though I don't know a sequence of steps to reproduce it, it's a matter of waiting for it to happen, it usually doesn't take a very long time......

On 2011-12-26 17:33, Miller Puckette wrote:

... Unless someone knows how to make a tcl interpreter ignore errors when executing scripts I don't know how to return to the more fail-soft 0.42 way.

What about calling the script as first argument to 'catch' and then handling any errors?

Martin

Le 2011-12-26 à 15:31:00, Miller Puckette a écrit :

Doesn't seem to work -- 'catch' grabs control Ok but there's no way to get control to go back to the script. Also no way to figure out how far down the script the interpreter got. There's gotta be a way to do this but I can't find it.

What's wrong with using $errorInfo ? Pd 43 already looks at that variable at least once.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC

I believe the difference between 0.42 and 0.43 is that the C code in 0.42 actually spat each 'line' of TCL, separately, to the interpreter, whereas in 0.43 entire batches of TCL script get fed to the interpreter as a block.

The 0.42 code wasn't airtight (checked for newlines at which {'s were balanced with }'s - this happened to work for all the TCL that Pd generated, but one could construct valid tcl code that gave false positives.) So I'm not in favor of 'fixing' 0.43 to work like 0.42 in this aspect. But I sure would like to be able to tell the interpreter to bull through if any individual statement failed - it won't fix any bugs but could make it less catastrophic when they manifest themselves.

cheers Miller

The 'catch' is already in place in Pd 0.43 in pd_connect::pd_readsocket, and that is indeed what is printing out the Tcl error dump that started this discussion.

As for whether pd-gui stops working after an error or not, I think this is a behavior of the Tcl interpreter, not Pd 0.43 or Pd 0.42. In both Pd 0.42 and 0.43, fatal errors stop the Tcl interpreter. Try sending a message with "{" in it. In both Pd 0.42 and 0.43, the Tcl interpreter will print an error message for non-fatal errors and then continue to execute the next commands.

About the bug report, that particular bug report shows a bug where Tcl commands are being split in the middle of the line, causing incomplete commands to be executed. The Tcl error dump that Cyrille posted in this thread is not the same error at all. Cyrille's error shows a complete Tcl command, but the ".x235b3d0.c "canvas does not exist. So Cyrille's error is like the errors that are triggered by the christchurch GOP that were fixed for 0.43-1test7.

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

.hc

---

Access to computers should be unlimited and total. - the hacker ethic

That is definitely true. It is possible to make pd-gui execute line-by-line by setting the buffering on the socket to be per-newline, then reintroducing the logic that used to be in the C code. But I think its faster to have Tcl parse, compile, and execute the code in larger blocks, but I don't have any data to back that up.

.hc

On Dec 27, 2011, at 1:37 PM, Miller Puckette wrote:

I believe the difference between 0.42 and 0.43 is that the C code in 0.42 actually spat each 'line' of TCL, separately, to the interpreter, whereas in 0.43 entire batches of TCL script get fed to the interpreter as a block.

The 0.42 code wasn't airtight (checked for newlines at which {'s were balanced with }'s - this happened to work for all the TCL that Pd generated, but one could construct valid tcl code that gave false positives.) So I'm not in favor of 'fixing' 0.43 to work like 0.42 in this aspect. But I sure would like to be able to tell the interpreter to bull through if any individual statement failed - it won't fix any bugs but could make it less catastrophic when they manifest themselves.

cheers Miller

...

The 'catch' is already in place in Pd 0.43 in pd_connect::pd_readsocket, and that is indeed what is printing out the Tcl error dump that started this discussion.

As for whether pd-gui stops working after an error or not, I think this is a behavior of the Tcl interpreter, not Pd 0.43 or Pd 0.42. In both Pd 0.42 and 0.43, fatal errors stop the Tcl interpreter. Try sending a message with "{" in it. In both Pd 0.42 and 0.43, the Tcl interpreter will print an error message for non-fatal errors and then continue to execute the next commands.

About the bug report, that particular bug report shows a bug where Tcl commands are being split in the middle of the line, causing incomplete commands to be executed. The Tcl error dump that Cyrille posted in this thread is not the same error at all. Cyrille's error shows a complete Tcl command, but the ".x235b3d0.c "canvas does not exist. So Cyrille's error is like the errors that are triggered by the christchurch GOP that were fixed for 0.43-1test7.

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

.hc

---

Access to computers should be unlimited and total. - the hacker ethic

Computer science is no more related to the computer than astronomy is related to the telescope. -Edsger Dykstra

The "paragraph mode" is not the cause of the freezes as far as I have seen, it just highlights the situation when there are bugs. I think we should first discuss fixing the bugs before changing the current mode of operation.

As for the fixes in pd-l2ork, it would be great to have them in vanilla. Could you refactor them against vanilla and submit them to the bug tracker? Then they can be reviewed and included.

.hc

On Thu, Dec 29, 2011, at 10:51, ico@vt.edu wrote:

The challenge remains, though, regardless of the approach. If a
particular call was called and it shouldn't have, parsing it out as
part of a paragraph or a line makes no difference performance-wise,
but it sure does make a world of a difference in terms of gui (or
parts of it) becoming unresponsive, since when the parser is in the
"paragraph mode" one will lose up to entire paragraph instead of a
single line (which in this case would not have any effect since the
line should've never been called). This is the part I was originally
referring to in terms of porting forward. If you look at the pd-l2ork,
it has much more detailed sanity checks for individual calls inside C
to make sure those calls are needed at all in the first place. Once
they are identified, you can wrap them in their own catch inside tcl
code (it that is indeed where they are being called)...

As for sanity checks, I don't think that really makes anything better
per se beyond whatever user enters manually via message to pd since
the 0.42 code already checks for sanity of those messages in its syntax.

The only time I encountered tcl breaking in core code of the 0.42
branch was as part of the network code (please note I mention here
vanilla as I haven't checked all the externals for proper behavior).
And if you ever tried debugging that you probably noticed just how the
tcl breaks. Namely, you could clearly see how one message inside
buffer was asynchronously overwritten midstream by another ending up
in a garbled output. Now, I know from our previous correspondence that
socket data incoming from a netreceive object apparently should output
in sync with the main loop, yet this problem was persistent until I
changed how the netreceive object behaves. In pd-l2ork all netreceive
sockets schedule received output as part of the guiqueue rather than
directly pushing the message out of an outlet no matter when it
receives it (or whenever suggested scheduler tells it to read from the
socket). This problem network-wise was much more apparent when there
was a heavier network traffic, while it almost never happened in low
throughput situations.

Long story short, I have not had gui freeze in pd-l2ork for over a
year now and so far I see no benefit in switching into a "paragraph
mode" as even if there is a huge performance benefit, the potential
penalty is the return of the gui freeze which renders any such
performance gains useless.

Quoting Hans-Christoph Steiner hans@at.or.at:

...

That is definitely true. It is possible to make pd-gui execute
line-by-line by setting the buffering on the socket to be
per-newline, then reintroducing the logic that used to be in the C
code. But I think its faster to have Tcl parse, compile, and
execute the code in larger blocks, but I don't have any data to back
that up.

.hc

On Dec 27, 2011, at 1:37 PM, Miller Puckette wrote:

...

I believe the difference between 0.42 and 0.43 is that the C code in 0.42 actually spat each 'line' of TCL, separately, to the interpreter, whereas in 0.43 entire batches of TCL script get fed to the interpreter as a block.

The 0.42 code wasn't airtight (checked for newlines at which {'s were balanced with }'s - this happened to work for all the TCL that Pd generated, but one could construct valid tcl code that gave false positives.) So I'm not in favor of 'fixing' 0.43 to work like 0.42 in this aspect. But I sure would like to be able to tell the interpreter to bull through if
any individual statement failed - it won't fix any bugs but could make it less catastrophic when they manifest themselves.

cheers Miller

...

The 'catch' is already in place in Pd 0.43 in
pd_connect::pd_readsocket, and that is indeed what is printing out
the Tcl error dump that started this discussion.

As for whether pd-gui stops working after an error or not, I think
this is a behavior of the Tcl interpreter, not Pd 0.43 or Pd 0.42.
In both Pd 0.42 and 0.43, fatal errors stop the Tcl interpreter.
Try sending a message with "{" in it. In both Pd 0.42 and 0.43,
the Tcl interpreter will print an error message for non-fatal
errors and then continue to execute the next commands.

About the bug report, that particular bug report shows a bug where
Tcl commands are being split in the middle of the line, causing
incomplete commands to be executed. The Tcl error dump that
Cyrille posted in this thread is not the same error at all.
Cyrille's error shows a complete Tcl command, but the ".x235b3d0.c
"canvas does not exist. So Cyrille's error is like the errors
that are triggered by the christchurch GOP that were fixed for
0.43-1test7.

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215
-tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

.hc

---

Access to computers should be unlimited and total. - the hacker ethic

---

Computer science is no more related to the computer than astronomy
is related to the telescope. -Edsger Dykstra

---

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

On Jan 4, 2012, at 11:30 AM, Mathieu Bouchard wrote:

Le 2011-12-27 à 22:08:00, Hans-Christoph Steiner a écrit :

...

It is possible to make pd-gui execute line-by-line by setting the buffering on the socket to be per-newline, then reintroducing the logic that used to be in the C code. But I think its faster to have Tcl parse, compile, and execute the code in larger blocks, but I don't have any data to back that up.

What makes you believe such a thing ?

Making computation in larger chunks may be a good idea for precompiled or preparsed code, it doesn't necessarily make sense for source code that has yet to be parsed.

If you want to know which one is faster, you can benchmark both ways so that running times get printed in a log.

The big blocks of code tend to be very similar instructions in a sequence, so that would hit caches well. That's one thing that makes me think this.

.hc

Terrorism is not an enemy. It cannot be defeated. It's a tactic. It's about as sensible to say we declare war on night attacks and expect we're going to win that war. We're not going to win the war on terrorism. - retired U.S. Army general, William Odom

Miller,

If you look through the pd-l2ork C code, which is by and large near identical (at least in its core) to pd vanilla (except for comments I added while studying the code) you will find a few places where mainly due to the way pd handles GOP it is easier to simply catch a tcl/tk command than go through all the trouble of making sure the call is sane. The rest of the code contains a series of sanity checks I added and as such spews no tcl/tk warnings or errors. I suspect this would be trivial to merge with your code base.

Best wishes,

Ico

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

Mathieu Bouchard matju@artengine.ca wrote:

Le 2011-12-26 à 14:33:00, Miller Puckette a écrit :

I read the thread on the bug tracker. It looks like this is an old bug that manifests itself worse in 0.43 because its error recovery for TCL commands coming from Pd isn't as good as 0.42 was.

What you need is not as much error recovery as error reporting. Do whatever is necessary so that future bug reports are easier to make. For example, when a Tcl command fails, print the command that directly caused that error, even when -d is set to 0.

Unless someone knows how to make a tcl interpreter ignore errors when executing scripts I don't know how to return to the more fail-soft 0.42 way.

Isn't that what the [catch] command already does ?

But if anything prevents an item from being created, this will necessarily cause more errors later, for any tcl command that assumes that the creation command worked.

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC_____________________________________________

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

For the few catches I do use, I don't do any follow-up simply because those have been proven (at least so far) not to cause any problems down the line so like I mentioned they were the few cases where it was easier to catch than to hunt for a way to check for their sanity.

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

Jonathan Wilkes jancsika@yahoo.com wrote:

Do you throw an error if catch catches something?

-Jonathan

From: Ivica Ico Bukvic ico@vt.edu To: Mathieu Bouchard matju@artengine.ca; Miller Puckette msp@ucsd.edu Cc: pd-list@iem.at Sent: Tuesday, December 27, 2011 12:45 AM Subject: Re: [PD] [PD-announce] pd 0.43-1 test7 (!) available

Miller,

If you look through the pd-l2ork C code, which is by and large near identical (at least in its core) to pd vanilla (except for comments I added while studying the code) you will find a few places where mainly due to the way pd handles GOP it is easier to simply catch a tcl/tk command than go through all the trouble of making sure the call is sane. The rest of the code contains a series of sanity checks I added and as such spews no tcl/tk warnings or errors. I suspect this would be trivial to merge with your code base.

Best wishes,

Ico

Ivica Ico Bukvic, D.M.A Composition, Music Technology Director, DISIS Interactive Sound & Intermedia Studio Director, L2Ork Linux Laptop Orchestra Assistant Director, CCTAD Virginia Tech Department of Music Blacksburg, VA 24061-0240 (540) 231-6139 (540) 231-5034 (fax) disis.music.vt.edu l2ork.music.vt.edu ico.bukvic.net

Mathieu Bouchard matju@artengine.ca wrote: Le 2011-12-26 à 14:33:00, Miller Puckette a écrit :

...

...

I read the thread on the bug tracker. It looks like this is an old bug that manifests itself worse in 0.43 because its error recovery for TCL commands coming from Pd isn't as good as 0.42 was.

What you need is not as much error recovery as error reporting. Do whatever is necessary so that future bug reports are easier to make. For example, when a Tcl command fails, print the command that directly caused that error, even when -d is set to 0.

...

Unless someone knows how to make a tcl interpreter ignore errors when executing scripts I don't know how to return to the more fail-soft 0.42 way.

Isn't that what the [catch] command already does ?

But if anything prevents an item from being created, this will necessarily cause

more errors later, for any tcl command that assumes that the

...

creation command worked.

...

...

---

...

| Mathieu BOUCHARD ----- téléphone : +1.514.383.3801 ----- Montréal, QC _____________________________________________

...

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

hello,

yes, you're right, my problem have noting to do with pd version. it was only the makefile that did not find g_canvas.h

cheers Cyrille

Le 27/12/2011 21:10, Hans-Christoph Steiner a écrit :

The 'ggee' externals are compiled against Pd-double and Pd-extended 0.43 every night and work for me.

.hc

On Dec 25, 2011, at 2:11 AM, cyrille henry wrote:

...

Hello,

thanks for the quick fix.

about the error, after digging around, i found that it's not related to vanilla, but to gcanvas from ggee, that was compiled for 0.42. btw, none of ggee gui external compile for 0.43

cheers Cyrille

Le 25/12/2011 03:32, Miller Puckette a écrit :

...

Thanks.. I think I fixed the old-build-system make install (now updating git repo). Could you send me the patch that's giving you the tcl errors? It's turing out to be complicated getting everything to work at once!

cheers Miller

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

hello, using the old build systempd did not start (a tcl file is missing)

with the new one, it work (and fix the old build system missing file btw) but pd~ did not work. pd~: can't stat /usr/local/lib/pd/pd would it be possible for the make install to create an alias from "where pd is installed" to "where pd is used by pd~"?

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

Cyrille

Le 24/12/2011 03:53, Miller Puckette a écrit :

...

Hi all,

Test 6 was a dud (Hans reported trouble within a couple of hours!) Heeeere's test 7...

http://crca.ucsd.edu/~msp/software.htm git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data

---

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

---

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

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

---

News is what people want to keep hidden and everything else is publicity. - Bill Moyers

Le 28/12/2011 06:33, Hans-Christoph Steiner a écrit :

apt-get install puredata-dev

when compiling pd from source? cheers C

.hc

On Dec 27, 2011, at 1:58 PM, cyrille henry wrote:

...

hello,

yes, you're right, my problem have noting to do with pd version. it was only the makefile that did not find g_canvas.h

cheers Cyrille

Le 27/12/2011 21:10, Hans-Christoph Steiner a écrit :

...

The 'ggee' externals are compiled against Pd-double and Pd-extended 0.43 every night and work for me.

.hc

On Dec 25, 2011, at 2:11 AM, cyrille henry wrote:

...

Hello,

thanks for the quick fix.

about the error, after digging around, i found that it's not related to vanilla, but to gcanvas from ggee, that was compiled for 0.42. btw, none of ggee gui external compile for 0.43

cheers Cyrille

Le 25/12/2011 03:32, Miller Puckette a écrit :

...

Thanks.. I think I fixed the old-build-system make install (now updating git repo). Could you send me the patch that's giving you the tcl errors? It's turing out to be complicated getting everything to work at once!

cheers Miller

On Sat, Dec 24, 2011 at 11:08:54PM +0100, cyrille henry wrote:

...

hello, using the old build systempd did not start (a tcl file is missing)

with the new one, it work (and fix the old build system missing file btw) but pd~ did not work. pd~: can't stat /usr/local/lib/pd/pd would it be possible for the make install to create an alias from "where pd is installed" to "where pd is used by pd~"?

when starting a patch using few GOP, i've got : (Tcl) INVALID COMMAND NAME: invalid command name ".x235b3d0.c" while executing ".x235b3d0.c create rectangle 610 115 710 215 -tags 234f0601 -fill grey" ("uplevel" body line 1) invoked from within "uplevel #0 $cmd_from_pd"

Cyrille

Le 24/12/2011 03:53, Miller Puckette a écrit : > Hi all, > > Test 6 was a dud (Hans reported trouble within a couple of hours!) Heeeere's > test 7... > > http://crca.ucsd.edu/~msp/software.htm > git clone git://pure-data.git.sourceforge.net/gitroot/pure-data/pure-data > > _______________________________________________ > Pd-announce mailing list > Pd-announce@iem.at > http://lists.puredata.info/listinfo/pd-announce > > _______________________________________________ > 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

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

---

News is what people want to keep hidden and everything else is publicity. - Bill Moyers

---

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