Ruby 2.0 state/port?

I'm wondering if Ruby 2.0 is supported or is going to be supported, and when.

Thank you :)

PS: You're doing a great job!

I believe 2.0 is backward compatible so there should be no issues.

But yes, i will soon install 2.0 and start testing. If someone who has 2.0 installed runs the examples, and reports errors that will certainly push me to install and start work on it sooner. I haven't got a plan for 2.0 yet, most likely start work on it in a month or so.

Ok, I'm on Arch Linux x64 + Ruby 2.0 and I'm running some examples. What I noticed so far is that, for example, in the tabular example, the clock doesn't refresh automatically. I mean, if I run the example, the clock stays at the same HH:MM:SS, and it updates only after I press a key (trigger an action). As soon as I stop triggering actions, the clock stops updating.

That's also valid for a small Thread example. I just wrote something like

Thread.new {
    i = 0
    while i<10
        tab = @form.by_name["tab"]
        tab.append ["1", "2", "3", "4"]
        i=i+1
        sleep(1)
    end
}

and the array doesn't get appended until I trigger an action. Also, if I wait 5s and then I trigger an action, only 1 row gets appended (so it's not because of refresh but because the thread isn't running)

It this supposed to be that way or I found a bug?

1. In the examples, the sample status line only updates dates when the form refreshes which happens on a movement or key. Typically i assume that a clock will be on the screen or something. I would not want to be running a clock if the user really does not want it. e.g. in calcurse notice that the clock actually keeps updatign every second but that steals the cursor away and the calcurse application (IMO) changed its UI to deal with this.

If the user really wants the object to refresh at some point when a key has not been pressed then a form.repaint is required. This happens in things like statusbars. In most objects the object's repaint_required will also have to be called or set to true so that form.repaint has an effect.

1. The same is true of your thread example. When modifying tab, you will have to do a tab.repaint_all() and then @form.repaint(). The idea is that only an object that has been modified is repainted. This keeps repainting to the minimum.

Indeed, the repaint-only-what-changed strategy is just fine :) Anyways, I tried what you suggest and the tabular example still doesn't update. Have a look: http://pastebin.com/uguTtRGH

This is the code from tabular.rb (from the examples folder) as-is with the thread added at the end. I'd expect new rows to be added (and shown) automatically, but nothing happens actually. Even more, they don't even get added if I don't trigger actions constantly.

To make it clear:

What I'd like: The thread to add one new row each second, and repaint autoatically.

What could happen if the auto-repaint is disabled: Launch the example, wait 10s, then hit a key to trigger a repaint; observ 10 rows added.

What actually happens: Launch the exaple, wait 10s, then hit a key to trigger a repaint;. Only 1 new row is added.

Why is that happening?

I tried out your sample, it worked the first time then stopped working. Then I put an alert in the loop. it worked the first time in the loop, but again on subsequent executions of the program did not work. I am not sure if the threads are working consistenemtly.

I then removed the thread.new and only kept a loop and it works fine. So it is something with threads. Or rather updating the screen within a thread.

In your case, since you are adding at the end of the list,and the end is not visible therefore you need to make it visible using tab.goto_end. You do not require to call tab.repaint_all since using tab.append will automatically set the flag for tab to be repainted on the next keypress. However, form.repaint is required since there is no keypress happening inside the loop.

I have used threads earlier (as in one gmail sample) in order to periodically fetch unread mails and display count, however i will check the code and see. I have not used that for a long time since the gmail gem changed a lot and could not handle concurrent fetches. IIRC, even there the unread count was updated only on a keypress, not from within the thread (but i cannot really remember).

In some cases, if @form.repaint does not work, then one can add @window.wrefresh and check again. This did not work from inside the thread.

The issues I see are:

1. update of form/window not happening from within thread
2. thread not working consistently, it works once and then does not work for next few executions.

I will look and see if i can find other thread examples and get back to you.

Ok, thank you :) I'll keep trying to get it working or debug it to see where it fails.

I did find some code that was using threads and ncurses (for gmail), and there are comments saying that the thread stops working if you press a key two times, or if you press a key in the other list several times, and it swallows exceptions etc.

Not sure if this is a threads bug or ffi-ncurses or rbcurse or ruby bug? Let me think and try some things out.

hello gentle men. how did thus turn out?