concurrent input from GUI *and * from irb

Discussion in 'Ruby' started by Joachim (München), Sep 4, 2006.

  1. 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
    Joachim (München), Sep 4, 2006
    #1
    1. Advertising

  2. Joachim (München)

    Kero Guest

    > 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
    Kero, Sep 4, 2006
    #2
    1. Advertising

  3. Joachim (München)

    Guest

    > 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
    , Sep 4, 2006
    #3
  4. 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
    Joachim (München), Sep 5, 2006
    #4
  5. 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
    Joachim (München), Sep 5, 2006
    #5
  6. On Sep 5, 2006, at 10:10 AM, Joachim (M=FCnchen) wrote:

    > 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.)
    Logan Capaldo, Sep 5, 2006
    #6
  7. Joachim (München)

    Ken Bloom Guest

    On Tue, 05 Sep 2006 07:09:55 -0700, Joachim (München)
    wrote:

    > 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

    --
    Ken Bloom. PhD candidate. Linguistic Cognition Laboratory.
    Department of Computer Science. Illinois Institute of Technology.
    http://www.iit.edu/~kbloom1/
    Ken Bloom, Sep 6, 2006
    #7
    1. Advertising

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

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. Pep
    Replies:
    6
    Views:
    810
  2. Martin DeMello
    Replies:
    21
    Views:
    322
    Martin DeMello
    Mar 7, 2005
  3. Sam Stephenson
    Replies:
    1
    Views:
    214
    Andrew Walrond
    Jun 18, 2005
  4. Replies:
    1
    Views:
    150
    Florian Groß
    Oct 26, 2005
  5. anne001
    Replies:
    1
    Views:
    255
    anne001
    Jun 27, 2006
Loading...

Share This Page