in reply to Handling asynchronous events with Perl

In addition to using POE or threads, I would ask what is your "long-term-vision" for the monitoring program? Wouldn't you ultimately want a GUI to watch these things. The reason I say this, is that Tk, Gtk2, or Wx have "built-in event loops" to make this job easy, plus you can have a GUI to display "when and where" an AUV has surfaced, assign mouse menus to the icons you use, so you can adjust things like resurfacing times. Depending on how the files come in, you can setup individual "fileevents" to watch for changes to the filehandles which each AUV prints to, or you could just monitor a single file, and regex the input to detect which AUV it comes from.

You could setup HoH (a hash of hashes) to track the AUV's, and with a menuing system, you could save changes to each AUV configuration, to be sent when a surface-event is detected.

The only drawback to using a GUI, is that you need to run it on a machine running an X server, or Windows.

I'm not really a human, but I play one on earth. flash japh
  • Comment on Re: Handling asynchronous events with Perl

Replies are listed 'Best First'.
Re^2: Handling asynchronous events with Perl
by njcodewarrior (Pilgrim) on Jul 11, 2005 at 12:20 UTC
    Yes, this is exactly what I would like to be able to do. Currently, I'm using Matlab for data visualization and have created a GUI that tracks the progress of the AUV once deployed; however, it is limited to tracking the AUV using available data.

    My 'long-term-vision' is to have an application capable of visualizing position information and data from the vehicle as well as doing the things you describe.

    Where's a good place to start for building GUIs using Perl?

    Thanks.
[reply]
      I would use Tk. You can read "perldoc Tk" then "perldoc Tk::UserGuide". You can ask questions here, google for sample code at groups.google.com, and ask questions in the friendly newsgroup, comp.lang.perl.tk

      I was thinking about your problem, and thought how nice it would be to actually make each AUV an object, then just make a big Tk canvas, put an gridded ocean map on it, and have little icons for each AUV object. You could have a little red indicator to blink when they are surfaced, and when submerged, plot their approximate position based on last readings, etc. You could work out a "coordinate translation" between GPS coordinates and your "gridded-ocean map". It sounds like a doable and fun project.

      Of course, as always, the devil is in the details, like error handling, restarting crashed servers, etc. You will probably need to store your AUV object data in a simple database, with backup, in case your monitoring computer crashes and needs to be rebuilt and restarted.

      I have posted a few examples which may "stimulate" ideas for you. Like this is a possible way to setup grid patterns -> Tk ImageMap-color-zones.

      And here is a nice little intro to how to make independent objects and display them on the screen. I call them bubbles. Anyways, don't get confused by the all the effects. My main purpose was to find a way to make alot of objects, and reuse them so as not ot get memory increases in a long running program. I also used Zinc, because it makes rotations and translations alot easier than the plain Canvas. But this could all be done on a plain Tk::Canvas.....you don't need fancy rotations, just translations, and the plain Canvas does them just fine. Also the package bubble, could be put into it's own .pm, I just make this monolithic for ease of testing the script. This is mostly to show how to make objects which "update their own display". So............

      Read more... (10 kB)
      I'm not really a human, but I play one on earth. flash japh
[reply]
[d/l]
Re^2: Handling asynchronous events with Perl
by fmerges (Chaplain) on Jul 11, 2005 at 17:50 UTC

    Hi,

    I would make a Tier based Perl solution.

    I mean, having a Polling System (cron, POE, threads, maybe...), a Data Backend (some DBMS could be PostgreSQL) and a Consumer GUI which gets the info from the DB.

    This way the entire program acquisition, which is the very important thing is something small and stable which doesn't depend in any way with the user interaction, or gui libs or X server. And the GUI is only a consumer from the data stored in the DB. Why a DB? Because that way you have all the data in one place, and can get the data out in some different way, more flexibility to use other custom app that would use the data for further displaying or calculations.

    This schema ilustrate it:

    ----------------------
|  data adquisition  |        Something small and robust.
----------------------
          |
          /
----------------------
| db storage of data |        DB backend, later you can use
----------------------        any software/language to
          /                   retrieve data, analisys, etc.
          |                   This way you're solution is
----------------------        very flexible.
| GUI, consumer, etc |        
----------------------

    [download]

    Of course only a idea... ;-)

    Regards,

    |fire| at irc.freenode.net

    I like merlyn's disclaimer

[reply]
[d/l]
      Sounds like a good plan. I have noticed that big projects like the one described go through different "growth phases". First is the "proof of concept", just showing it CAN be done. Then comes the "error and exception handling" which is usually discovered during testing of the "proof-of-concept" code. It sure does pay to sit down and think a bit, before making big coding descisions.
      I'm not really a human, but I play one on earth. flash japh
[reply]

        Hi,

        I'm really inspired by KISS and UNIX, modular programming, small units, etc.

        I recommend books like The Art of Unix Programming and Extreme Programming, the last one has much in common with the Unix Programming Philosophy.

        Once you start thinking about all in small pieces all at the same time seems more simple that it would be in programming bulky programs and also more robust and flexible.

        Regards,

        |fire| at irc.freenode.net I like merlyn's disclaimer
[reply]

In Section Seekers of Perl Wisdom