On 10 Apr 2008, at 01:36, Luke Daley wrote:
On 10/04/2008, at 8:20 AM, Hans-Jörg Bibiko wrote:
It seems that R (R running as daemon via spawn in an hidden pty) distinguishes between a 'read' coming from pipe as 'keyboard input' and the R command 'readline' which reads something from the keyboard. This led me to the assumption to use tm_interactive_input to solve a tiny problem - meaning whenever R executes the command readline, tm_interactive_input pops up a dialog to enter something.
Are you saying that you get false positives here? i.e. the dialog is opening when you don't want it to? If so I will need to understand what you are doing more before I can work out how to fix.
No. I experimented with the 'old' tm_read, and I found out by accident that a normal R 'read' didn't pop up the dialog whereas R's command 'readline' did. This was actually my desired workaround. "But unfortunately ;) " the new tm_interactive_input works like a charm meaning the dialog shows up with 'read' and 'readline'.
If there is a way to get rid of it - and there're a very few not only theoretical indications - then it would be nice not only to label the buttons but also to show only one button or even a NIB . ;)
I get the feeling that your particular usage here will be a bit niche. To that end, you might be better off ripping the tm_interactive_input code and modifying it to suit your needs. I'll certainly help you out if you go that path.
Thanks. You're right, it's really marginal. (BTW to remote a process running in a PTY by itself is marginal in TM terms. Maybe in the future not ;) And if I have a bit time I'll have a look at the code. Maybe I/we can find a way.
I'll be interested to see what Allan thinks, but we may need to give some thought to making this mechanism more generic. Essentially providing a skeletal lib which provides the common stuff (and the majority of the work) and allow people with customised needs to use a different auxillary lib which provides the behaviour. How you would even do that in C is not really evident to me but I think we could make it work.
This would be great. As I mentioned, I would need a tiny modification: Instead of showing a dialog it would be nice to have only a trigger/file/signal indicating whether the process wants to read something. Then, e.g., I could simplify the synchronization between Rdaemon and TM. If the process (Rdaemon) wants to read something tm_interactive_input will write a file let's say 'read.status'. In TM I could run a while loop checking the existence of that file. If it exists TM knows that the process finished its task. Then TM could delete that file and do other things. While writing this it seems to me that this could be implemented actually quite easy.
@Allan: With your modification to handle the modal status tm_interactive_input works perfectly ;)
Again, thanks a lot
--Hans