OSX console doesn't hook stdout

[ccoupe]

Shoes.app do
  Shoes::show_console
  button "quit" do quit end
  $stdout.puts "stdout printing"
  $stderr.puts "stderr printing"
end

only the $stderr.puts is displayed. Also, why can't button accept { quit } and requires do end.

[passenger94]

regarding

can't button accept { quit } and requires do end.

i think you 're talking about
button("quit") { quit }

When you write it that way parenthesis are mandatory, same for slots and probably some others
flow( some_attributes ) { }, i'm guessing, without parenthesis, ruby is confused about block being eventually a hash ?
EDIT in fact : { } has higher precedence then do/end
button "quit" { ...block here is called against "quit" string... } it's like button("quit" { ... })
do/end is like (button "quit") do ... end

[ccoupe]

Here's another approach for OSX http://stackoverflow.com/questions/16391279/how-to-redirect-stdout-to-a-nstextview?rq=1 instead of the tesi.c . I also see commented code in cocoa-term.m that suggests I tried something like that (but not well enough). There is something very odd going on with OSX and standard out. At the end of shoe_native_console I do a

printf("Mak\010c\t console \t\tcreated\n"); //test \b \t in string` 

That shows on the screen after going thru the pty/tesi. (it's there to to test tabs and bs). It works!. A newer test:

Shoes.app do
  Shoes::show_console
  button "quit" do quit end
  $stdout.puts "stdout printing"
  $stderr.puts "stderr printing"
  if $stdout != $stderr
    $stdout = $stderr
    puts "Now on stdout?"
  end
end

does switch and output "Now on stdout" which suggests Ruby (on osx) is not using fd[1] for stdout which makes no sense at all.

[passenger94]

don't know how to help here ... i have "Now on stdout" also on linux
(and both"stdout printing", "stderr printing" before)

[ccoupe]

Some success on this issue._ Here's the individual video tests. https://gist.github.com/ccoupe/a6e77b37e3edcbff3559 from OSX. The run all test doesn't work - hangs Shoes after test 2. Of course the question arises about one of the test failures? Is it even fixable?

[passenger94]

Now this is funky ! the test failure in the gist is strange : it does get a height but 474 instead 480 is non sense ... (do test pass if you check for height != 0 instead of a concrete dimension ?, some codec dimension accommodating ? (i know some codec have restriction on size, must be multiple of 16 for example) - let's hope it's not a fiddle/mac peculiar behaviour, in test4 that's where the dimensions comes from -
Anyway, this might suggest, as well as hangs on test 2, that the hook on the video surface (NSView) is dysfunctional ... probably too early ... (again isn't there a proper signal, like "realize" in gtk, to hook to ? i might be wrong but ... worth a try, no ?)
But here we are dealing with stress tests, it's nice to know Shoes/Vlc team can handle that, but it's not a realistic scenario ... (allowed me to surround a nasty bug, in any case)
All this chattering is valid assuming drawing are asynchronous in cocoa, are they ?

Also does the scrolling works ? in gtk the rendering must happen in a visible part of the ui :
https://github.com/Shoes3/shoes3/blob/master/Tests/test_video_vlc.rb#L57
(Worth noting that fortunately this is only pertinent in the context of those test, in a real app as soon as another drawing is triggered, all is ok)
I knew it was totally heretical (part of the fun) ..., it might also suggest that testing that way (testing part of shoes in shoes gui) is simply a bad idea :-D

[ccoupe]

Cocoa uses a run_loop of events, where events can be generated by program code so it is essentially asynchronous as well as timers, and many external activities. There's an odd bug on the mailing list about video on OSX - where the widget doesn't show the video, just the black screen but the audio plays. But only on the older osx 10.9. On My unauthorized 10.9 VM, both shoes and VLC app do that (don't work) but that's not a confirmation or way to test it since VLC.app works for him. It does suggest some race condition.

I think I have to subclass NSView for the Video widget in order to specify the callbacks. There are a couple that might work viewDidMoveToWindow is my first choice. I could also disable mouse and key events for that View (rectangle of pixels that vlc draws to).

Going through the tests in order did draw one big black bar so I think that code is OK now that start{} is working. For what it's worth, testing native control sizes/dimensions would fail on different platforms. You may need some fuzzy measure of success +/- 10% of requested?

[passenger94]

Going through the tests in order did draw one big black

only for test4, right ?, others must be small !
I'm not sure that the fact you can see that bar is good news ... on gtk you don"t have the time to see it it's erased as soon as test is finished, but could be an osx thing though

beware, though the black screen is not a guaranty of success, it could be only the NSView being drawn, it tells nothing about the success of Vlc's hook on that surface
on gtk when the hook fail you see a second independent "display" created by Vlc, is it the same on cocoa/osx ? (maybe the hook fails but also no secondary displays, for some reason)

[ccoupe]

The latest commit uses a new cocoa subclass and does the realized settting in a separate method (and time?) Doesn't hurt. Doesn't help. Videos are fine for users. Same behaviour for tests. Except I added a few log messages. If you look at the commit you might notice shoes_native_surface_remove is a no-op and if you saw the test log with the new NSLog messages in it one might think that is a real problem I should fix. ;-)

If we ever get to #144, tests like you've done for would be very valuable. That idea needs an opaque Shoes class "Insertion_Point" (very different native implementations) and methods to move it, append here, delete from here to there, Since that opaque class is completely undefined at this time, tests would be very good to add as we (if) we work on that.

[passenger94]

shoes_native_surface_remove is a no-op

oh wait, ... this is coherent with problem at hand ... (on tests at least)
I do_ remember old vlc implementation was entirely a no-op on osx,
Looks like we probably need to implement that stub too, like we implemented shoes_native_surface_new()
There are a few methods, in shoes, like those one (stubs) in order to simplify calls to native code in non native code, so for example, in canvas.c you just call whatever_native_dosomething then if needed in cocoa, it's implemented, if not needed in gtk, just create a stub that does nothing and fine we are (or the other way around)

Might be wrong by i think you nailed it !
Edit: OOooops ! looks like that method really really needs some love ! 🙀 :-D

[ccoupe]

I should surrender my Unix Programmer Card because I forgot that some nix syscalls set the global variable 'errorno' and it can be used to get a string error message. Here's what I get when trying to dup2(newfd, (fileno(stdout)):

About C stdout before
fd: 1, isatty: 0, name: |(null)|, pipefd: 23
About C stdout after
fd: 1, isatty: 0, name: |(null)|, pipefd: 23
dup2 rtn 1, errorno: 25, Inappropriate ioctl for device
STDERR OK

Finally a clue! I wonder what would happen if I close(stdout) before the dup2?

About C stdout after
fd: 1, isatty: 0, name: |(null)|, pipefd: 23
dup2 rtn 1, errorno: 9, Bad file descriptor

That makes sense. Why or when OSX became so difficult to deal with stdout will be discovered.

[ccoupe]

OR test code bugs are the problem being reported by the test code. I hate that! Number 25 (0r 26 or 23) is the fd of the pipe, not the error code. sigh

[ccoupe]

I think I mo`-betta understand the problem after many man days of huh? Most folks would launch Shoes with a double click on the icon in /Applications which actually calls the bash script 'shoes-launch' which tries to decide if it should call 'open Shoes.app --args' or 'ugly/path/to/shoes-bin args'. Only the latter has stdout pointing to a terminal (the launching terminal). This is similar to what Windows does, i.e. shoes.exe vs cshoes.exe

When OSX shoes spins up from a non terminal launch stdout points to the equivalent to /deb/null. The ./cshoes script for OSX can go either way depending on args parsed by shoes-launch. So, when shoe_terminal gets called, C, Obj->C/Cocoa ,and Ruby already have references to stdout as as an fd, File * or FileHandle * or all three. Which one does osx/ruby hold in $stdout ? It's big deal for Shoes/OSX and it's not simple because it affects a lot of Shoes launch code

[ccoupe]

I managed to get a stdout working almost well enough(I think). C write(), C printf, and Obj-C [NSFileHandle write: data] works for #236. Ruby however, seems to use the old /dev/null stdout that existed at startup and I haven't found the magic Ruby calls to re-init stdout. Some of the code really should be run at Shoes startup - before initializing Ruby if it can detect that it doesn't have a stdout. Important IF. OSX uses the cocoa notification center - observer stuff for file events - dataAvailble for Filehandle. I like it.

I vaguely remember that gio/gtk can do something similar, @passenger94 - is that true? If so, that would allow us to get rid of the pty for Linux and possibly do something nice for Windows. . Another Big IF.

[ccoupe]

I figured out how to reset stdout at the Ruby level so I don't have to deal with fixing world.c (yet) to handle terminal/no-terminal situations. It requires a monkey patch to IO.puts if Shoes.terminal is called. @passenger94 , @backorder please look at the monkey patch in bugs/bug224 before I move it into rb_eval_string() (but only for OSX)

[passenger94]

can't tell what's going on on OSX, all i know is that i can do $stdout = STDOUT if i need to reset $stdout to original.

Hello, busy at the moment, sorry fo not being around too much lately.

[ccoupe]

I'm closing this one. There's rough edges if your cocoa savvy and some unused code could be deleted but it's done.