concurrent input from GUI *and * from irb

  • Thread starter Joachim (München)
  • Start date
J

Joachim (München)

I am currently redesigning a program that shall accept input
from both a GUI and from a terminal window that runs irb.

In reaction to the input, some output will be written to the
terminal or/and some controls in the GUI will change.

I need help on the basic architecture of such a system.
I have two rather vague ideas:

(1) Somehow run the irb terminal within the GUI's event loop?

(2) One thread runs the GUI, one thread runs the terminal?

Any comment will be appreciated, Joachim
 
K

Kero

I am currently redesigning a program that shall accept input
from both a GUI and from a terminal window that runs irb.

In reaction to the input, some output will be written to the
terminal or/and some controls in the GUI will change.

I need help on the basic architecture of such a system.
I have two rather vague ideas:

(1) Somehow run the irb terminal within the GUI's event loop?

Some toolkits provide for actions-when-idle ("idle" is the keyword for at
least one of them) or perform-this-action-after-that-delay.

*nix only (I don't know how M$ and Mac/cocoa behave in this regard):

The main PITA with GUI threads is that they think that they are the main
program. From that "design", it follows that those threads tend to block
natively when waiting for input, thus blocking all other Ruby threads. It
results in crazy constructions to embed one in the other, even without Ruby
in between, including an X11 extension that shouldn't have been (passing
focus from one toolkit to another).

irb uses readline; readline has a similar problem.
(2) One thread runs the GUI, one thread runs the terminal?

(3) One program irb, one GUI, both talk with drb to the real program (which,
coincidentally, has a nice mutex somewhere to protect it from race conditions).

(4) Use a multi-line text widget to emulate irb
 
B

benjohn

I am currently redesigning a program that shall accept input
from both a GUI and from a terminal window that runs irb.

In reaction to the input, some output will be written to the
terminal or/and some controls in the GUI will change.

I need help on the basic architecture of such a system.

Do you know the model view controller design pattern? Also look at
tiered designs where persistence is at the bottom, business logic is on
top of this, and "presentation" is on top of the "business logic".

If you factor out your models and the kinds of changes that it's
possible to make to your system, you should be able to quite cleanly
place a GUI and a command line "presentation" of the underlying system
in to a seperate module. In fact, you should be able to bolt on
arbitrary presentations (web based too, say) without too much trouble :)

You'll probably want some kind of concept of transactions and
synchronisation in the model to allow for different active parties to
make concurrent changes.

Cheers,
Benjohn
 
J

Joachim (München)

Thank you, Kero and Paul, for your comments.

I see that I have to supply more specific information about my
application.

It's for scientific data analysis. The expert user will do most work
through
a dialog interface which I want to re-implement by extending irb.
Commands
entered through the irb terminal will result in changes in diagrams or
tables that run in separate GUI windows; mouse clicks in these windows
shall have the same effect as specific terminal commands. I also need a
log file which keeps track of all activities.

In conclusion, GUI activity should produce a command string which is to
be
executed by irb, and some irb commands will result in GUI changes.

Your comments indicate that threads are no good idea.

Is there no simpler solution than running irb and GUI as separate
processes,
with lots of interprocess communication?

Thanks again, Joachim
 
J

Joachim (München)

my user should be able to define variables, to define functions, to
include scripts, to hack for-loops, to iterate over arrays &c: the full
functionality of irb. Is that really possible with Kernel::eval ?
Joachim
 
L

Logan Capaldo

my user should be able to define variables, to define functions, to
include scripts, to hack for-loops, to iterate over arrays &c: the =20
full
functionality of irb. Is that really possible with Kernel::eval ?
Joachim

Of course it is. irb is built on top of eval. (irb is AFAIK, pure =20
ruby. Without eval it wouldn't work at all.)
 
K

Ken Bloom

my user should be able to define variables, to define functions, to
include scripts, to hack for-loops, to iterate over arrays &c: the full
functionality of irb. Is that really possible with Kernel::eval ?
Joachim

Yes, just like some of the examples that float around here of people
defining whole methods in class_eval (sometimes several methods, in fact)
you can indeed do that. (And I just tested and you can load/require files
too)

Be aware though that by using Kernel::eval on user input, your user can
also sleuth around and hack his way into the program you have written, so
you should be very careful about using this anywhere were security is
critical.

You should also be very careful about running eval in a context where
there are exposed functions that could interfere with your user's intended
meaning for his code.

I'd suggest looking at how IRB works, and then replicate its guts to
provide a relatively safe and clean execution environment. (Or use parts
of the IRB setup, but not the front command shell.) In particular, I think
the tricks are in irb/workspace.rb

--Ken Bloom
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,743
Messages
2,569,478
Members
44,899
Latest member
RodneyMcAu

Latest Threads

Top