Hello,

Same problem here, with last release of [pyext]

py/pyext 0.2.1pre - python script objects

(C)2002-2008 Thomas Grill - http://grrrr.org/ext

using Python 2.6.4 (r264:75708, Oct 26 2009, 08:23:19) [MSC v.1500 32 bit (Intel)]

Fortunately I've keeped a working release, but it works with python24 only:

py/pyext 0.2.1pre - python script objects

(C)2002-2005 Thomas Grill - http://grrrr.org/ext

using Python 2.4.4 (#71, Oct 18 2006, 08:34:43) [MSC v.1310 32 bit (Intel)]

maybe you should use another solution, or come back to the old python24, unless someone provide a working dll for Vista machines.

The create folder feature could be implemented in pd, or rather tcl command lines could be used through pd messaging system without an external since it already uses tcl for the client side

Selon Matteo Sisti Sette matteosistisette@gmail.com:

patrick escribió:

...

maybe it's because of numpy... install it: http://www.scipy.org/Installing_SciPy/Windows

The ImportError message disappeared, but pyext still crashes.

Is there anybody using [pyext] on Windows Vista successfully?

-- Matteo Sisti Sette matteosistisette@gmail.com http://www.matteosistisette.com

---

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

Selon Matteo Sisti Sette matteosistisette@gmail.com:

I guess you're using windows too, right?

yes

...

Fortunately I've keeped a working release, but it works with python24 only:

Oh, would you please send it to me? (or is it online somewhere?)

it's attached

...

The create folder feature could be implemented in pd, or rather tcl

command

...

lines could be used through pd messaging system without an external since

it

...

already uses tcl for the client side

That sounds very interesting. Is it possible with the current stable pd release or you mean with the new pdGuiRewrite thing?

well, it's just an idea that sometimes comes in the top of my fingers, this doesn't seem to be implemented yet, maybe there is a good reason for that.

Can you point me to some resource to learn how to do that?

PureData code has a function for doing nasty things like this with tcl called sys_vgui() and could be one beginning point, the purpose of one idea would be about sending tcl commands through pd messaging sytem, but pd doesn't like some usefull characters in tcl like "{","}", "[",..., so another idea is about having an internal for loading tcl script 'à la ' [pyext], for the moment it's possible to use the great job of Federico Ferri called pdtcl, but at this point, any other external for script language would be a method like another

in fact the topic seems to be pending still...

http://www.mail-archive.com/pd-dev@iem.at/msg02391.html

Hans-Christoph Steiner escribió:

I wrote an external called [sys_gui] that allows you to send Tcl to the GUI from Pd. While you can't (yet?) use {} you can use "" and [] and that gets you a long way.

GREAT! I think that solves all my "problems" :)

hi

removed all those who receive this mail anyhow, because they are subscribed to the list.

Matteo Sisti Sette wrote:

Matteo Sisti Sette escribió:

...

Hans-Christoph Steiner escribió:

...

I wrote an external called [sys_gui] that allows you to send Tcl to the GUI from Pd. While you can't (yet?) use {} you can use "" and [] and that gets you a long way.

GREAT! I think that solves all my "problems" :)

Oh no!!!! Almost!

If I create a directory and then, _immediately_ after (in the same message tree, after 0 logical time), I send a [write ...( message to a [textfile] to save a file into the newly created folder, it fails because (I guess) the creation of the folder is "non-blocking" (so to say) that is it takes a small time to create it but the action is considered finished (and the following branch of messages is generated) as soon as the "command has been sent".

it's not about non-blocking. but [sys_gui] sends a request over the internet to your local computer to create a directory. since the internet can take some time, so will your folder creation. even though the connection to your local computer should be pretty fast, it is still asynchronous to your main patch.

Any suggestions on how to check for the existence of a directory?

well, write a textfile into the folder with some content and try to retrieve the content. if it succeeded, then the folder is there. (and writeable; in order to don't create any locks because you try to wirte to a non-writeable folder, make sure to do some timeout)

fgmasdr IOhannes

colet.patrice@free.fr wrote:

Selon Matteo Sisti Sette matteosistisette@gmail.com:

...

Any suggestions on how to check for the existence of a directory?

it would be childish if [sys_gui] or another object would retrieve tcl console output, then [puts [glob -type d My-Dir]< would do the trick, or just a bang when tcl command is done.

as said before: we are dealing with asyncrhonous messages over the internet here. i don't think there is a way to do what you request (as option b) generically. otoh, you can do option a with [sys_gui] something like "pd_send myrecname [ glob -type d My-Dir ]" should send the output of the glob command back to Pd where it will magically appear on the "myrecname" receiver.

sidenote: pd_send is what i remember; could be called slightly differently or take more args; for details see pd.tk

mdyr IOhannes

On Jan 14, 2010, at 11:45 AM, colet.patrice@free.fr wrote:

Selon IOhannes m zmoelnig zmoelnig@iem.at:

...

as said before: we are dealing with asyncrhonous messages over the internet here.

yes just seen this...

...

something like "pd_send myrecname [ glob -type d My-Dir ]" should
send the output of the glob command back to Pd where it will magically
appear on the "myrecname" receiver.

pretty magics!

[pdsend "tcl-rcv [file isdirectory My-Dir<--[sys_gui]

[r tcl-rcv]--[sel 1]--[write My-Dir/My-File.txt cr<--[textfile]

this trick could reside in an abs, I've attached something like that.

so now all this stuff is possible inside PureData:

http://tmml.sourceforge.net/doc/tcl/

unless the commands that need {}

I like the idea of an outlet on sys_gui a lot. It should probably
just output a bang once the command you entered into sys_gui is
finished. Or perhaps it needs to output a copy of the message that
was just sent. Otherwise, if you send a lot of messages, it might be
hard to tell which bang goes with which message.

Then for getting messages from the pdwindow and/or console, I think
those should probably be separate objects, like [console].

Patco, if you want to try making it work, the code is in externals/hcs/ sys_gui.c. That code is pretty simple. I think you could do it by
appending something like "; pdsend "#sys_gui-receiver bang" to every
command sent, then bind to the receiver name "#sys_gui-receiver" to
get that bang.

.hc

I have always wished for my computer to be as easy to use as my
telephone; my wish has come true because I can no longer figure out
how to use my telephone." --Bjarne Stroustrup (creator of C++)

On Jan 14, 2010, at 2:58 PM, colet.patrice@free.fr wrote:

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

...

Patco, if you want to try making it work, the code is in externals/ hcs/ sys_gui.c. That code is pretty simple. I think you could do it by

my msys build system is broken:

$ make hcs/sys_gui cc -DPD -I/home/patko/pd-extended/pd/src -Wall -W -ggdb -I/home/patko/pd-extended/Gem/src -mms-bitfields -DMSW -DNT - D'O_NONBLOCK=1' -D'srand48(n)=srand((n))' -D'drand48()=((double)rand()/RAND_MAX)' -D'bzero(p,n)=memset(p,0,n)' -s -shared hcs/sys_gui.c -o hcs/ sys_gui make: cc: Command not found make: *** [hcs/sys_gui] Error 127

make CC=gcc

or even better export CC=gcc

.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

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

sys_gui.c. That code is pretty simple. I think you could do it by appending something like "; pdsend "#sys_gui-receiver bang" to every command sent, then bind to the receiver name "#sys_gui-receiver" to get that bang.

attached diff should be this binding method but it doesn't work, the bang is sent before tcl is done; why attached patch works? (it bangs after tcl command is done), the only difference is that the send command is trigged.

pc

On Jan 18, 2010, at 12:44 PM, colet.patrice@free.fr wrote:

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

...

sys_gui.c. That code is pretty simple. I think you could do it by appending something like "; pdsend "#sys_gui-receiver bang" to every command sent, then bind to the receiver name "#sys_gui-receiver" to get that bang.

attached diff should be this binding method but it doesn't work, the
bang is sent before tcl is done; why attached patch works? (it bangs after tcl
command is done), the only difference is that the send command is trigged.

pc

<sys_gui-send-bang.diff><createDir.pd>

Ah, the error came from [textfile] not wanting to write an empty
file. This works for me with your unchanged C code:

For the outlet, I would bind to a unique receive symbol generated from
the pointer to the instance of the sys_gui object, then use that
receive to send the bang in Tcl, receive it in C, then output it out
the outlet:

sprintf(buf,"#%lx", (long unsigned int)x);

.hc

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

Maybe not nice, but it should work. ++

Jack

Le jeudi 14 janvier 2010 à 18:52 +0100, Matteo Sisti Sette a écrit :

colet.patrice@free.fr escribió:

...

Selon Matteo Sisti Sette matteosistisette@gmail.com:

...

Any suggestions on how to check for the existence of a directory?

it would be childish if [sys_gui] or another object would retrieve tcl console output, then [puts [glob -type d My-Dir]< would do the trick, or just a bang when tcl command is done.

I tried the attached patch without success. I know it's not an example of best practice, but I expected it to work.

the strategy consists of 3-steps in a single trigger:

[t a a a] 1 2 3

1. send the [file mkdir...( message with [sys_gui]

2. keep pd busy in an [until] loop which, at each iteration, checks

whether the folder exists and, if so, exits the [until] loop. I do this with [folder_list], reading the list of files contained in the directory where the new subdirectory is to be created and checking whether one of the symbols it outputs matches the complete path name of the to-be-created directory

3. I create the file with [textfile]

This doesn't work. I've put a maximum of 1000 iterations to avoid hanging pd forever. However, even if I change it to 10000, 100000 or even infinite (a bang), it never works.

Note that the [until] loop thingie does work if isolated and used to check the existence of a directory.

It seems like the actual creation of the directory (possibly even the act of sending the message to the gui process??) is "deferred" untill the completion of the whole message-tree. Is that so?

pièce jointe document texte brut (test_blocking_create_dir - copia.pd) #N canvas 681 23 450 711 10; #X obj 247 332 sys_gui; #X obj 188 99 dirpanel; #X obj 192 57 bng 15 250 50 0 empty empty empty 17 7 0 10 -262144 -1 -1; #X msg 263 174 symbol $1/newdir; #X obj 33 332 textfile; #X msg 40 283 set , add cis boom bash , write $1/newfile.txt; #X msg 218 245 file mkdir $1; #X obj 117 560 folder_list; #X obj 114 403 until; #X obj 137 334 t b a a; #X obj 130 479 symbol; #X obj 163 145 t a a a a; #X msg 58 223 symbol $1/newdir; #X obj 116 589 t a a; #X obj 126 505 t a b; #X msg 209 635 ====; #X obj 14 306 t b a; #X obj 265 204 t a a a; #X obj 125 619 select -; #X msg 105 533 symbol $1/*; #X obj 112 650 t b b; #X obj 116 439 t b b; #X msg 96 371 1000; #X connect 1 0 11 0; #X connect 2 0 1 0; #X connect 3 0 17 0; #X connect 5 0 16 0; #X connect 6 0 0 0; #X connect 7 0 13 0; #X connect 8 0 21 0; #X connect 9 0 22 0; #X connect 9 1 10 1; #X connect 10 0 14 0; #X connect 11 0 12 0; #X connect 11 1 9 0; #X connect 11 3 3 0; #X connect 12 0 5 0; #X connect 13 0 18 0; #X connect 14 0 19 0; #X connect 14 1 15 0; #X connect 16 1 4 0; #X connect 17 0 6 0; #X connect 17 2 18 1; #X connect 18 0 20 0; #X connect 19 0 7 0; #X connect 20 0 8 1; #X connect 21 0 10 0; #X connect 22 0 8 0; _______________________________________________ Pd-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

Matteo Sisti Sette wrote:

Jack escribió:

...

Maybe not nice, but it should work.

Thank you very much, that's great. It does work, and I think it is as nice as it can be.

However, unfortunately, it is "unsafe" for my purposes because of the [delay 0]. Well I guess it's more correct to say it is incompatible with my patch.

if you use [sys_gui] then yuo will _always_ have to live with a delay. i can only repeat myself, that the pd-gui (which executes the [sys_gui] commands) and the pd-core are asynchronous applications. this is by design.

fgmar IOhannes

(i go on with this thread for "scientific interest", having already solved the practical problem, thanks btw to the help of a few of you)

Roman Haefeli wrote:

I don't see, how a [delay 0] can help here. The result is still zero logical time.

I didn't expect it to make any difference either. However, compare my patch (without delay 0) and Jack's one (with delay 0) and you'll see his one works and mine doesn't.

Both do the same sequence of operations, in the same order, in 0 logical time:

• send the message to gui to create folder
• loop: check whether folder exists
• if not, go to loop
• write file

the only difference being the presence or not of a zero delay after each iteration of the loop (an important difference)

This means the following message trees (pardon me if I arrange them horizontally rather than vertically but I'm not very good at ascii 'art'):

--- A: NO DELAY ---

-+- send message to create folder | +-+- loop iteration 1 (check dir exsistence) | | | +- loop iteration 2 | | .. | +- loop iteration N (dir is found or maximum # of cicles is hit) | +- write file

--- B: WITH ZERO DELAY ---

-+- send message to create folder | +-+- loop iteration 1 (check dir existence) | +- bang to [delay 0]

-+- loop iteration 2 | +- bang to [delay 0]

...

-+- loop iteration N (dir is found) | +- write file

(possibly with minor errors, I hope not any major ones)

Though in both cases it all happens it 0 time, in the first case it is all in one message tree while in the second case it's several detached message trees.

It seems like, for some reason, the directory cannot _actually_ be created untill the whole message tree (one of whose branches has provoked the sending of the message) is completed.

I can only try 2 guesses:

A) it is because of how the operating system manages processes (i.e. the "delay 0" has a similar role to a "sleep 0") - but then, I would expect an amount of unpredictability

B) because of the way PD is implemented, maybe the message is not even actually sent to the gui process until the whole message tree is completed?? or the gui is somehow aware of the fact that the message tree is not complete and won't process the messages it has received until it is????

Does this make sense?

thanks m.

IOhannes zmölnig escribió:

if you use [sys_gui] then yuo will _always_ have to live with a delay. i can only repeat myself, that the pd-gui (which executes the [sys_gui] commands) and the pd-core are asynchronous applications. this is by design.

Yes of course, it can't be any other way.

I was just looking for a "synchronous" solution; however at the end I opted for simply pre-generating the folders.

It would be cool however to have a set of externals (or an external with a set of methods) to perform basic filesystem tasks, such as creating and deleting folders and deleting files, in a "synchronous" way, to have that possibility, just like [textfile] writes and reads in a synchronous way. Even in Vanilla, why not. This is just for the wishlist.

One idea would be to modify [textfile]'s behaviour so that, when it receives a [write( message, and the path where the file is to be written does not exist, it will (attempt to) create the folder, or all the directory tree down to the complete path. Wouldn't that be fine?

thanks m.