I scanned that file and it seems like it collects the output at the end of the process, which isn't quite what I need. Thanks for the pointer though.
I also tried closing the ports, but that didn't help. I've been trying to reduce my code to a minimum working/non-working example, and it hasn't helped much. Basically I found out that every other command I tried worked fine, but the instruments one doesn't work with the copy-port stuff (it works when run by itself). For instance, I tried "raco test" on some personal code with the copy-port stuff and it logged in real-time just fine. I also tried "brew upgrade" and it logged the results in real time. But for some reason the command I'm using doesn't seem to work. I think I'm just going to use the tee workaround for now. Thanks for the time and pointers. I definitely learned a few things, so it wasn't a complete waste for me at least. If there are any perfectionists that still want to figure this out, I'm just running iOS UI Automation tests as described here: http://stackoverflow.com/questions/4191945/can-the-ui-automation-instrument-be-run-from-the-command-line Although I doubt there are many people who've been enlightened by Racket yet still stoop to writing Objective-C code... On Thu, May 16, 2013 at 9:09 PM, Jay McCarthy <[email protected]>wrote: > I'm showing up late to this party, but... > > DrDr has to do this in a very reliable way and it is abstracted into a > fairly nice function called run/collect/wait > > > https://github.com/plt/racket/blob/master/collects/meta/drdr/run-collect.rkt > > You may want to look at it a little. > > Jay > > On Thu, May 16, 2013 at 6:43 PM, Robby Findler > <[email protected]> wrote: > > Oh, I meant to say that I think that process*/ports can make things > easier > > than system for this kind of thing. read-string-evt is more for if you > want > > to get good performance for high-throughput streams, which it seems like > > isn't an issue here. This different seems unlikely to help with whatever > is > > going wrong. > > > > I don't see that you're closing the ports anywhere, so maybe there is > > something like that happening in your real script. Make sure that you > close > > everything as soon as you know there is no more data. Otherwise, I'm just > > not sure what's going wrong. > > > > As for process* and system*: they will work, I think, unless the strings > you > > put in the "~a"s are multiple arguments and you can't do that parsing > > yourself. You'd do something like > > > > (system* "/usr/bin/instruments" "-t" (path->string instruments-path) > > (path->string app-path) "-e" "UIASCRIPT" (path->string script-path)) > > > > roughly. > > > > Robby > > > > > > On Thu, May 16, 2013 at 7:27 PM, Nick Shelley <[email protected]> > > wrote: > >> > >> I tried "file-stream-buffer-mode" on the stdout port and that didn't > help. > >> That seems to be the only port that will work with that method. > >> > >> I also realize I misled you when I put "<script-that-logs-to-console>" > as > >> a placeholder in the code. Really it is a command of the form (format > >> "instruments -t ~a \"~a\" -e UIASCRIPT ~a" ...) where two of the three > ~a > >> arguments are passed to Racket through the command-line. If I understand > >> correctly, process* and system* won't work with this form. > >> > >> After experimenting a bunch unsuccessfully, I tried putting the system > >> call before I created the ports and without a parameterized > >> current-output-port. The results I see are that for the first system > call I > >> get real-time logs to the console, then with the next one the tests > repeat, > >> but the logs don't come until the end. > >> > >> I even tried Neil's suggested approach in case that made a difference. > >> Aside from the fact that it has the same buffering problem, I never get > the > >> eof event, so I don't know when to terminate the sync loop. Here's the > code: > >> > >> (define-values (in out) (make-pipe)) > >> (define stdout (current-output-port)) > >> (define string-port (open-output-string)) > >> (process/ports out #f #f (format "instruments -t ~a \"~a\" -e > UIASCRIPT > >> ~a" instruments-path app-path script-path)) > >> (let loop ([data (sync (read-string-evt 1 in))]) > >> (unless (eof-object? data) > >> (display (format "data: [~a]" data) stdout) > >> (display data string-port) > >> (loop (sync (read-string-evt 1 in))))) > >> (printf "~n~nresults: ~a~n" (get-output-string string-port)) > >> > >> With this I get the delayed logs (each letter in brackets per sync > event) > >> and then the program hangs waiting for an eof that never comes. Out of > >> curiosity, why did both of you recommend this approach over the system > >> approach? Either I'm doing it completely wrong or I just can't see the > >> advantage. > >> > >> > >> On Thu, May 16, 2013 at 5:08 PM, Neil Van Dyke <[email protected]> > >> wrote: > >>> > >>> You can try "file-stream-buffer-mode" on the port. > >>> > >>> Neil V. > >>> > >> > >> > >> ____________________ > >> Racket Users list: > >> http://lists.racket-lang.org/users > >> > > > > > > ____________________ > > Racket Users list: > > http://lists.racket-lang.org/users > > > > > > -- > Jay McCarthy <[email protected]> > Assistant Professor / Brigham Young University > http://faculty.cs.byu.edu/~jay > > "The glory of God is Intelligence" - D&C 93 >
____________________ Racket Users list: http://lists.racket-lang.org/users
