Hi Allan,

On 09.04.2008, at 23:28, Allan Odgaard wrote:

On 9 Apr 2008, at 11:46, Hans-Joerg Bibiko wrote:

...

[...] I see the dialog and the prompt but I cannot enter something and I cannot close the dialog (only APPLE+. works). What I'm doing wrong?

The problem is that the dialog was non-modal, i.e. relying on the global event loop of TM, but that isn’t running during the execution of commands. I have fixed it to make the dialog modal and should work now.

Thanks a lot! I will try it out tomorrow.

...

BTW: How can I change the button's titles?

You can set TM_I_WANT_PINK_BUTTONS=YES :p

Why not. My daughter would love it ;P

Nah… presently there is no way to change button titles AFAIK, but Luke did initially have environment variables for them. Question is, does it make sense to change them? The “Send EOF” should probably stay hardcoded, but an environment variable can be made available to change the other one. Would that be enough?

Well, if one thinks in terms of a running script asking the user for whatever, it would be fine. But I did play with an elder version (tm_read) and Rdaemon. 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. 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 . ;) [or a third button which kills the running process]

But back to the reality, I mean to be able to label the 'Send' button would be fine for now.

Thanks and mange tak,

--Hans

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

On 11/04/2008, at 12:50 AM, Hans-Joerg Bibiko wrote:

OK. I changed the code of tm_interactive_input for it and in principal it works perfectly ;) It was really quite simple caused by the clean structured source code!

Thank Allan for that, he wouldn't let me stop if it was anything less :P

Now I have an other problem.

I call R spawned by using this R < in_pipe > out.txt

Fine. But if R outputs a huge text chunk tm_interactive_input gives me a signal that R wants to read something, but there're still data in the pipe to out.txt. It takes time to flush the pipe out.txt to disk.

Is there a way to ask the pipe whether it finished writing?

My guess is here that the output is too big for one call to write(). If this is the case then that is a problem, because the logic of when an outputting session stops is external to anything that we control. If this is indeed the case, you are better off trying to pursue it on the R side.

LD.