Pyremote Python remote control is now in CVS!

Developers
2003-09-24
2012-09-14
1 2 > >> (Page 1 of 2)
  • Stefan Schroeder

    Hello,

    the plugin for remote control of Gxsm with Python is now
    in the CVS. DO a fresh checkout and try it.
    Documenetation is already available: See Appendix in the Manual.
    I am specifically interested if the cross library detection works well,
    I only have Python 2.1 and it should run with 2.2. Could use some help to write the appropriate automake/autoconf lines for correct inclusion of header and library-files.
    BTW: This Plugin was developed with Gxsm 1! There is no
    port to Gxsm2 yet, I will do it when this version stuff I mentioned is sorted out.
    PZ, can you announce the PI on the News please!?
    It resides in Tools-Menu PI lies in plug-ins/common.

     
    • Percy Zahl

      Percy Zahl - 2003-10-07

      Great job Stefan!

      I just checked out the pyremote (GXSM2) and it works on my PPC!
      Just one issue according to the current documentation, I needed to set the PYTHONPATH explicitly, otherwise my script was not found, even in the current working directory.

      PZ

       
    • Stefan Schroeder

      True. Perhaps I lost track of my environment variables,
      because on my development computer I never logout.

      I will upgrade the documentation with respect to this issue.
      In the future, there could be a console message when the script
      is not found about this.

       
    • Stefan Schroeder

      Update:
      pyremote now automagically sets PYTHONPATH to your
      cwd if PYTHONPATH is not set. So you dont need to set it
      explicitly.
      The PI is ported to Gxsm2 as noted above. When the cout's
      are replaced with PI_DEBUG macros the PI will be final
      for now.
      If ound the adding arguments to the call of a plugin is rather complicated, because the MathOp Functions do not allow more
      args than Src and Dest.

       
    • Percy Zahl

      Percy Zahl - 2003-10-16

      GXSM compiles OK even without python-libs installed, but calling the pyremote plugin crashes GXSM. There need to be some precautions in configure.in...

      If all is installed OK it works fine.

       
    • Percy Zahl

      Percy Zahl - 2003-10-24

      a few remarks:

      I figured out the RH9/pyremote crash problem, was due to a bad rpm post install, the symlink to the libpython2.2.so was just missing.... Grrrr RH sucks -- but works now OK.

      Hi Stefan!
      Is there any possibility to canel a (lengthy) running pyremote job -- that'll be nice. Example: A pythone loop runs a set of several scans with different params... OK, then the user figures out he want's to stop the job inbetween for some reason (tip crash etc...). The only way I found was to kill it all:-(

      And here the GXSM hack of the day:
      To help the python remote programmer to figure out the correct 
      set ("Names", ..) of all remote enabled entry fields I added a nifty option to the GXSM->Help menu to show tooltips with the correct "remote set name" if the mouse is over the entry!

      -PZ

       
      • Stefan Schroeder

        You should add a check for this symlink in the configure-script.

        I will think about a cancel option. No idea yet.
        Might be script-sided (simple) or application-sided (difficult!? Gxsm blocks while script runs, so no input possible. So must be in an own thread, eieiei, can cause sync problems again.)
        No hacking this weekend, ill look at the 'cool option' on monday.

        I compiled Gxsm with gcc3.3 on
        triangular.fkp.uni-hannover.de. No problems
        except the annoying upgrade of netcdf libs.

        I think doing a apt-get repository on sf is not possible (never seen yet), but think I can donate some webspace from cluster.fkp. The deb-package is highly expermental. Should be checked first.

         
    • Stefan Schroeder

      There still is the problem when the Python-libs are  there at compiletime, but not at runtime.
      I have no idea yet, how to catch this.

       
    • Stefan Schroeder

      Brainstorming:

      PZ asked me about how to cancel a running pyremote-job.
      This is not builtin, because non-interactivity is the point in having
      a script. But I see the point.

      In remote.C of the old remote-control you include
      pthread.h. Do you have experience with programming
      threads? We could implement the running python interpreter in
      a new thread. But what would happen, if during execution of the script presses some strange buttons. Perhaps there should be a sort of cancel-button, which does not interrupt immediatly, but before the next script-command is executed.

       
      • Percy Zahl

        Percy Zahl - 2003-10-27

        Yes, both is true:

        I'm using a gthread to read from the SRanger FIFO buffer in background in GXSM-2. (sranger-dev.C) Works nice and easy!

        And it's true, GXSM is not blocked while running a scan via remote, cos I'm calling the gtk_mail_iteration() via gapp->check_events ():

        "inline void check_events(){ while(gtk_events_pending()) gtk_main_iteration(); };"

        while the scanning process is waiting for data, thus GXSM is not blocked and runs in a quasi threaded mode even without any extra threads! (The only real thread is the one used to read the sranger FIFO I mentione above, but non is used for PCI32/PC31/etc.!)

        And It's also true, while the remote script is running or waiting to strat the next scan I actually can press "stop" to cancel the current scan and then the remote immediately starts the next scan... -- but this is what I wanted to shortpass, just imaging having a remote script running 100scans....

        -PZ

         
    • Stefan Schroeder

      Hey, after trying it myself I found that Gxsm does not freeze
      during execution of a script. This simplifies everything a lot.
      When can open a simple dialog when pyremote is started along the lines of 'Script started: press button to interrupt'.
      When this button is pressed, we issue a message like this:
      'Script will be interrupted on next occasion, Please wait.'
      The PI Checks a flag before executing the next command,
      which the cancel button sets and there we are.

       
    • Stefan Schroeder

      After some googling I still have no idea how to elegantly
      interrupt the Python script. Problem is, that the script is
      executed 'en bloc', with no 'line-by-line' ahndling which
      would offer opportunity to interfere.
      As workaround I would be possible to add a cancel
      flag which would suppress the execution of Gxsms
      internal functions. So if you have a script, doing 100 scans,
      and then interrupt, the current scan would be finished
      (or can be canceled pressing Stop) and the next startscan()
      would allow to not execute it. But this would not stop
      a lengthy script that does some other calculation with Pythons
      built in functions, like

      emb.startscan()
      for i in 1000:
         time_consuming_calculation

       
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Is there a way inside of python itself to setup an "signal-handler"  "kill or terminate" to catch any event form GXSM so that the script exits then like pressing "CTRL-C" in a console?

      -PZ

       
    • Stefan Schroeder

      Yes, signal handlers can be installed, but I have no idea how to
      fire up the signal to Python.

      http://www.python.org/doc/current/lib/module-signal.html

       
    • Stefan Schroeder

      OK workaround with signal handlers:
      This program wnats to scan 10 times.
      If you go to the conolse and send signal
      SIGCHLD to the app (kill -17 PID), after
      next scan the script will interrupt

      import emb
      import os
      import time 
      import sys

      print "Welcome to Python."

      import signal

      i=0

      def signal_handler(signal, frame):
              print 'You sent signal CHLD'
              i=1

      signal.signal(signal.SIGCHLD, signal_handler)

      print 'Send signal chld to stop'

      for i in range(10):
              emb.startscan()
              if i==1:
                      break

       
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Looks good! I think that's the way to go and you can simply execute the kill command from GXSM (see surface.C / load the stuff where bunzip2 is called...)

      PZ

       
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Ahhh -- BTW I could imagine to add the import emb... and signal ... "header" lines to the script automaticaly before running it! What do you think?

      -PZ

       
    • Stefan Schroeder

      I just thought the same. But dont know yet, where to
      store the intermediate data. One could surely create
      a temporary file, but I'd like to avoid that.
      BTW. If we do this, the module should not be called
      emb, to avoid nameclashes. gxsmemb or the like
      would be more concise. If I do this, I will
      announce it.

       
    • Stefan Schroeder

      PS: Using signal SIGUSR1 would be better style than SIGCHLD.
      I dont know what SIGCHLD is reserved for. Something with
      child-processes.

       
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Can't the interpreter run a script just out of memory instead of a file?

       
    • Stefan Schroeder

      True.
      The parser has several methods to assemble the code
      from strings, files and codeobjects. But at some
      place, the user still hat to allow entrance to the signal
      handler. THis means: the line
      if i==1: break
      still has to written by the user.
      The documentation/C-API reference is not so extensive like
      other parts of the docs. There are dozens of ways to import python-code and Im not sure yet about the way to go.

      Perhaps a header is a good idea, but how to exit gracefully
      from the script at any line? calling sys.exit will quit
      Gxsm not only the interpreter. There is no goto.
      THat would be a solution.

       
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Why do you need the "i==1: break" ??
      The execption handler should be able to exit the script like

      def signal_handler(signal, frame):
        exit

      I guess there is a kind of "exit" and that's it!

      -PZ

       
      • Percy Zahl

        Percy Zahl - 2003-10-27

        I just had a look at the python signal handling (7.1), looks perfect:

        - the signal will not interfere the C-implementaion, i.e. it will interrupt only inbetween python code -- that's perfect

        - I would suggest to use the SIGINT (overrides the default) to cancel or maybe you could add also an pause/unpause feature!
        This one seems to be well suited for this purpose!

        And there is an pause signal/command in python - exactly what you need to pause/unpause any script via signalling:
        pause()
            Cause the process to sleep until a signal is received; the appropriate handler will then be called. Returns nothing. Not on Windows. (See the Unix man page signal(2).)

        - And at GXSM level all you need to know: "man signal"

        I guess there is a pythonlib call to get the PID of the process.

        -- all looks very promising to me and I could already imagine a tiny py-controllbar anywhere attached to the GXSM main window statusbar... if a python job is executing... and... as a bonus to the users comfort I guess the pylib has a function to be set as handler if an script error occurs, so that the "bad-line" can be shown highlighted in a window using the powerful text-widget...  also this will allow editing just be no extra costs:-)

        -PZ

         
    • Percy Zahl

      Percy Zahl - 2003-10-27

      Hey, this works already even without any extra line in your python script, try this:

      import emb
      emb.set('PointsX', '500')
      emb.set('RangeX', '500')
      for i in range(1000):
          emb.startscan()

      start it... and then on your console just type this:

      kill -SIGINT 15042   << replace this by the gxsm2 PID

      (gxsm2 doese nothing with it by default)

      -- this just came into my mind as I was thinking what to the hell the "default" keybord interrupt in python only could be...

      -PZ

       
    • Stefan Schroeder

      OK, the last hint is it. We can open a dialog box when pyremote
      is started. It says 'Cancel script?'. Then we get
      the pid with getpid. But why does this not interrupt Gxsm
      itself? WHen I put sys.exit() into the signal handler,
      gxsm was stopped.

      About pausing: Why should you need this? if you pause your
      scan, it will be corrupted anyway. If you send pause to gxsm
      wont it pause gxsm? There is no child PID to send the kill
      to.

      Another idea:
      It should be (not quite) easy to add a sort of macro recorder:
      When you work with Gxsm, everything you do is recorded
      in python to a file. E.g. when you set the rangex, then
      to this file is written emb.set("rangex", ...
      Thus you could exactly see what you did and rewind and replay.

       
1 2 > >> (Page 1 of 2)

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

JavaScript is required for this form.





No, thanks