[TxMt] tm_interactive_input question

[Hans-Joerg Bibiko]

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