Page 1 of 1

Read from process broken LC7.0DP5?

Posted: Sat May 24, 2014 5:22 pm
by PaulDaMacMan
Just got some time to try some stacks on LC 7.0DP5
I have a card that loops sends read & write from process that was opened for an interactive (non-blocking) session with:
open process tProcess for update

Seems like the read part in an infinite loop waiting for input in LC 7.0 (works in 6.6.2 rc4 , 6.7 not tested)
"Command period yields:
Message execution error:
Error description: read: aborted
Hint: "
-- hint is blank??? <-- this is because of the Command+period stopping of the script

my read loop command:

Code: Select all

global tRunning,tProcess
command readLoop tProcess
   if tRunning then
      read from process tProcess until empty
      if it is not empty then
         put it after field "outField"
         set the vscroll of field "outField" to the formattedheight of field "outField"
      end if
      send readLoop to me in  100 milliseconds -- 100 milliseconds
   end if
end readLoop
however the write part is working because I can hear it firing (running a shell app that makes sound, tProcess is fuildSynth (CLI))

Re: Read from process broken LC7.0DP5?

Posted: Sat May 24, 2014 10:06 pm
by FourthWorld
PaulDaMacMan wrote:"Command period yields:
...
-- hint is blank???
The hint field contains a reference to the portion of the statement that coudn't be executed, if the interrupt occurred as a result of a script error. In this case, the script is fine, it appears to have been interrupted by the user typing Cmd-.

It's more difficult to read code that's not indented, so here I've re-posted it using the "Code" tag from the options at the top of the post editing view:

Code: Select all

global tRunning,tProcess
command readLoop tProcess
   if tRunning then
      read from process tProcess until empty
      if it is not empty then
         put it after field "outField"
         set the vscroll of field "outField" to the formattedheight of field "outField"
      end if
      send readLoop to me in  100 milliseconds -- 100 milliseconds
   end if
end readLoop
Indented like this is seems that the send command is being invoked even if the data is empty, which would account for the infinite loop since all states from the read will always call that handler.
however the write part is working because I can hear it firing (running a shell app that makes sound, tProcess is fuildSynth (CLI))
Where does the write occur? It doesn't seem to be part of the posted code.

Re: Read from process broken LC7.0DP5?

Posted: Sat May 24, 2014 10:40 pm
by DarScott
I'm not sure why a command-period is needed to stop this. You can have a button that does a final read, close the process and turn off tRunning. (Did you intend to name that gRunning?) Do you have something like this?

If you had to use command-period, then perhaps there is a confusion in the implementation of reading until the other end closes and reading everything in the buffer. I think read until empty should do the latter. In the past read until EOF did the same, but there might be changes. Those changes might have conflated the two.

I have a vague notion of a shift in this semantics or some confusion related to it. If this is the issue, we should track it down.

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 1:34 am
by PaulDaMacMan
I have various scripts that write to

Code: Select all

global tProcess,gChannel,gNote,gVelo

on mouseDown
   write "noteon " & the label of  btn chan && the short name of me &" 127"  & crlf to process tProcess 
end mouseDown
   
on mouseUp
   write "noteoff " & the label of  btn chan && the short name of me & crlf to process tProcess 
end mouseUp
and other messages like load soundfont, pass file paths of midi files, Quit the CLI, etc.
then I read from the buffer every 100 to see if there is any feedback from the CLI

This all works for me in 6.6.2.

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 2:22 am
by DarScott
I suspect there is something wrong with 'until empty' in 7.0. I think that problem shows up with other I/O.

A quick check is to see if this works:

Code: Select all

    read from process tProcess for 10 chars in 0.01 seconds 
(That's off the top of my head; I hope that is right.)

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 4:51 pm
by PaulDaMacMan
Yes that works it looks like 'empty' is broken
Here is my new read command until it's fixed:

Code: Select all

command readLoop
   if tRunning then
      --      read from process tProcess until empty
      -- read from process tProcess for 100 
      read from process tProcess for 10 chars in 0.01 seconds
      if the number of chars in it >1 then
         put it after field "outField"
         -- set the vscroll of field "outField" to the formattedheight of field "outField"
         send readLoop to me in  100 milliseconds -- 100 milliseconds
      else
         send readLoop to me in  100 milliseconds -- 100 milliseconds
         exit readLoop
      end if
   end if
end readLoop

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 4:53 pm
by PaulDaMacMan
@DarScott you filed this already, correct?
Also, Thanks for the heads up on this.
It's really a bad one for me because I use 'is empty' all the time!
And also,yes tProcess should have a name indicative of a global variable. I got the beginnings of the script from some example code that was probably more of a 'blocking' method of reading from a shell app. Will rename it something like theLiveFSProcess (the stack sometimes has multiple instances of FluidSynth running simultaneously).

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 6:04 pm
by DarScott
I have not filed this for 'process' but I'm looking at it on Monday for 'driver'. I'll try to look at it for process, socket and stdin/stdout, but I don't know if I'll get to those. I might have filled this for 'driver', and if so it is reasonable to add to that. Or separate if you are not sure. (Write was only recently fixed for 'driver' and it makes testing read a lot easier.)

At one time the 'in 0.01 seconds' did not work right, so we needed to do what you are doing, that is, 'until empty'. I use it everywhere as the idiom of "read until the buffer is empty" or "give me all you have".

However, one might also have the need for something that means "read until the other end closes". This doesn't apply to 'driver', that is, serial I/O, unless one interprets DSR that way. But it might apply to 'process'.

I'm guessing somebody "fixed" EOF to mean the latter, but kept the notion of 'until empty' meaning the same as 'until EOF'. So we lost 'give me all you have" in the process (if I might be allowed a minor pun).

I'm just guessing based on a something I saw the past month and haven't had a chance to look closer at.

If you haven't filed the bug by the time I get to this, I'll do it.

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 6:13 pm
by PaulDaMacMan
Also didn't LC use to report "User canceled script" or something similar when a loop was stopped via Command+period in the Dev mode?

Re: Read from process broken LC7.0DP5?

Posted: Sun May 25, 2014 6:22 pm
by DarScott
I think even being able to command-period in the middle of I/O is new. The message is generated by separate code, I imagine. I don't mind the separate message, but I like the notion of their being the same. And this should apply to all blocking I/O.

(I hope to get my feet wet in doing some LiveCode enhancements this summer and if that works well, I'll look at callbacks for 'process' I/O after that.)

Re: Read from process broken LC7.0DP5?

Posted: Mon May 26, 2014 4:03 pm
by PaulDaMacMan
DarScott wrote:I think even being able to command-period in the middle of I/O is new.
I think you're correct, I remember having to force-quit the engine (and then use Activity Monitor to kill my tProcess) when I had bad scripts in early experiments for this stack. Still, some feedback from the engine would be nice here.

Re: Read from process broken LC7.0DP5?

Posted: Mon May 26, 2014 4:38 pm
by PaulDaMacMan
finally got a chance to file this http://quality.runrev.com/show_bug.cgi?id=12538
Very busy BBQin', getting my yard/pool ready for summer and of course drinking beer!
Maybe the next global jam should be scheduled to avoid national holidays.