🚀 go-pugleaf

Libero 2.11 is available for free downloading!

Point your browser to http://www.imatix.com for info.

Libero is a Programmer's Tool and Code Generator.  You define the
high-level logic of a problem as a diagram: Libero generates the code
to implement this logic.  Your applications are easier to write, more
robust, easier to understand.  Libero uses a finite-state machine as
underlying model.

Libero is multi-language, multi-platform, multi-purpose.  It uses
a programmable code-generator engine and supports a wide range of
languages:

    - C/C++
    - Perl
    - COBOL 74, COBOL 85
    - Visual Basic, MS Test Basic 1.0
    - UNIX C Shell, Korn Shell, Bourne Shell, Bash Shell
    - 80x86 assembler
    - Awk

Libero runs on these platforms:

    - UNIX (tested on Linux, HP/UX, SunOS, Irix 5.2, AIX 3.2.5, Solaris)
    - MS-DOS
    - MS-Windows
    - Digital VAX/VMS and Open-VMS
    - any (in principle) any platform with an ANSI C compiler.

Libero is free software following the GNU general public license.  This
is an extract from the documentation:

---------------------------------------------------------------------------

                                   Introduction

       "Laziness

          The quality  that makes  you go to great effort to reduce overall
          energy expenditure.   It  makes you  write labour-saving programs
          that other  people will  find useful, and document what you wrote
          so you  don't have  to answer  so many questions about it.  Hence
          the first great virtue of a programmer."

          - Larry Wall, Programming Perl.


     How It All Started

       In 1982,  as a student, I got into games programming as a way of making
     some money.  I skipped the build-it-yourself-from-an-old-TV-screen-and-a-
     hex-keypad phase  of personal  computers, and  jumped straight  into  the
     world of  ready-to-go colour  and sound.   My first PC had 5K of RAM, and
     25x22 colour  video.   It could  beep in  three-part harmony.   My  first
     published work  was an  article that  explained how  to tweak  the  video
     output to  30x33 (hi  resolution!).   Soon I was writing sprite painters,
     assembly libraries  for sound and graphics, even languages to replace the
     built-in Basic.   Anything  to let  me write  my games faster and better.
     Before I  knew what  had hit  me, I  was hooked into the cycle of writing
     tools to improve the world I lived in.

       I haven't  written a  game for  a long time, but I've continued writing
     tools.  Libero is one of the best - it's simple, clean, portable, and has
     hit the mark so often that I feel it's unfair to keep it for myself.

       The ideas behind Libero evolved in Brussels, Belgium during the 1980's.
     I worked with Leif Svalgaard, on what we would now call a CASE tool - ETK
     - that  let COBOL programmers produce clean, portable code instead of the
     mess we  generally saw.   One  of  the  key  techniques  we  used  was  a
     programming method based on finite state machines.

       Historically, the  first real  programs that used finite state machines
     were compilers.   Finite  state machines are also called Turing machines.
     In 1967,  Peter Naur  describes a  new way  of using Turing machines in a
     compiler, and shows how they simplify error checking.  He goes on to say:

       "The above  description has  stressed the checking aspect of the Turing
     machine approach.   However, an equally important aspect is the ease with
     which arbitrary  actions may  be specified.  (...) By using this approach
     it is  usually possible  to  avoid  tests  in  individual  actions  to  a
     surprisingly high degree.  This in our experience is a very effective way
     of reducing the bulk and execution time of the translator algorithm."

       ETK provides  an interactive  editor that you use to describe the logic
     of the  program as  a finite state machine.  This approach encourages you
     to think  about the  complete problem.   You describe everything that can
     happen, and  how the program should react.  The end-result looks a little
     like a  flow-chart, but  has more  arrows, and  fewer different  kinds of
     boxes.

       Now, in  a conventional  state machine,  these boxes are given numbers,
     and the  programmer build  some tables  that encode  the arrows.  To make
     such a  table by hand - or, just as bad, encode the table directly in the
     logic of  the program,  using GOTOs - is a Bad Thing, since the result is
     near to  impossible to  maintain.  The neat part of our solution was that
     we took  the textual  description (called  a 'dialog'), and generated the
     mystical tables  directly as COBOL code.  This is a Good Thing, since the
     original dialog  is easy  to change,  and suddenly becomes excellent (and
     always accurate) documentation.

       In 1992 I began working as a consultant, and found that I wanted to use
     these techniques  in my  work.  I was writing in C, so I threw together a
     code generator that could output C code using the same dialog methodology
     I was used to.  I called this tool 'Libero' after the guy who runs around
     the sidelines  at the football/soccer pitch doing all the dirty work.  My
     first serious job was a bunch of TCP/IP clients and servers.  It was nice
     to come  back to  the place  three years  later and  find  that  the  guy
     maintaining my  work had only found one bug, and was happy to go into the
     programs.   He said  that the  dialogs made  them easy  to understand and
     modify.

       This kind  of experience convinced me that there was real value in this
     tool.   I've written  lots of cute programs that are really useful for my
     own needs,  but that  just don't  hack it  in the  real world.  Libero is
     different.

       The first  release of  Libero generated C code using an external model,
     called a  'schema'.   I had a couple of schemas; one for ANSI C code, and
     one for multithreaded DEC/VMS code.

       I released  version 2.0  onto the  Net after  adding schemas  for  UNIX
     scripts.  This release gave me a lot of feedback, and I rewrote the code-
     generator again  to make it much more generic.  The current version has a
     lot more  language schemas and a lot fewer bugs, plus a front-end for MS-
     Windows.

       I hope  to continue in both these directions.  Libero has become a tool
     that lets  you switch  between languages  at ease.   The first step is to
     accept the state-machine as a valid method for program development.  This
     takes a  little effort,  but I  hope that  the examples which follow will
     help convince  you.   The second  step is  to see  that  this  method  is
     language-independent.   You can write a program in Awk, then recode it in
     C or Perl or assembler without changing its design.


     Some Examples

       I've not  found a  quick way to convey the true nature of state machine
     programming.   In my  experience, it  invariably  takes  a  few  days  of
     practice.   After three  or four  days' exposure  to the  idea there is a
     near-audible 'click!'  and something in the brain connects all the pieces
     together and  you go  'Oh, it's  like THAT!'.   Maybe  people cultured on
     event-driven programming will get it faster.

       In this  section  I'll  describe  some  everyday  situations  as  state
     machines, in the hope that this will help the process.


     Example 1: A Coke Machine

       The coke  machine (once  awake and  gently humming1)  sits against  the
     wall, waiting.  Like all coke machines, it's very good at waiting, due to
     Natural Selection.    All  the  impatient  proto-coke  machines  ran  off
     screaming 'I  can't take  it anymore'  and  were  crunched  underfoot  by
     brontosaurii back  in the  mists of  prehistory.  (I noted the part about
     the mists  specifically to  explain why  the dinosaur trampled the proto-
     coke machine  instead  of  extracting  something  cool  to  drink.    The
     prevailing mists  also explain  the later  demise of the dinosaurs due to
     extreme thirst.   The  surviving proto-coke machines moved patiently back
     against the proto-walls, out of danger.)

     ____________________
     1   There is  a theory  about  this,  notably  that  coke  machines  have
     terrible memories,  and can't  remember the  words.   A second  school of
     thought says  that the coke machines are humming because they're thinking
     about all  the terrible  things they're  going to  do to humans with crow
     bars.   A third  school of  thought reckons  that the  coke machines have
     already done  something, and  are humming  because they  thought  it  was
     really funny.

       A punter  arrives with  a handful  of loose  change.   The coke-machine
     (covered by  the modern  and tasteful  metal grid  that serves  both as a
     defensive covering and as an attraction for coke machines of the opposite
     sex) moves into 'attention' mode.  When it hears the clink of tasty cash,
     rather that the ominous clunk of a heavy crow-bar, it relaxes into 'ready
     mode'.  The machine is now ready to handle any eventuality, so long as it
     includes coinage.

       As the  last coin  falls and  the punter  presses the  button  labelled
     'healthie  waye  sparkling  spring  water',  the  machine  considers  the
     possibilities.   Should it  play dead,  and just take the punter's money?
     Or maybe it can substitute a can of 30% sucrose 'sweeto-sap'?  Finally it
     rumbles once,  then again for added effect, then excretes a can of water.
     It munches the coins, then settles back against the wall, quietly humming
     again.

       Just to  prove that  you can  describe any  sequence of events, however
     improbable, with  a state  machine,  here  goes.   Act 1, scene 1 has our
     protagonist against  the wall,  trying to remember the words of the song.
     Our hero  is normally  OK; if  something went  terribly  wrong  with  the
     rehearsals (e.g.  a dinosaur got sucked through a five-dimensional space-
     time vortex  stretched between  the middle  terrasic to five minutes into
     rehersals; the dinosaur a little off balance after the trip puts down its
     left foot,  and 'crunch'...),  it might be Dead, in which case we have to
     call the  whole thing  off.   We'll call  this scene  'Should  Be  Gently
     Humming'...

       Should-Be-Gently-Humming:
           (--) Ok                                 -> Something-Happened
                 + Wait-For-A-Punter
           (--) Dead                               ->
                 + Stop-The-Programme

       The coke  machine has  been waiting,  perhaps for days, for a punter to
     come along.   When  the footprints  fade in  from the  distance  (a  coke
     machine's ears  are always  against the  ground, which  explains why  you
     rarely find  coke machines  on wet  or dirty surfaces), the machine hears
     either a cashy 'clink' or a more sinister 'clunk':

       Something-Happened:
           (--) Clink                              -> Before-Cooperating
                 + Accept-Punter's-Cash
                 + Wait-For-Punter's-Choice
                 + Shall-We-Cooperate?
           (--) Clunk                              ->
                 + Exit-Stage-Left-Running
                 + Stop-The-Programme

       The advent  of a  'Clunk' tells  the machine to beat it, smartly.  If a
     'Clink' happened,  the machine goes on to think about a game plan for the
     coming few  minutes.   It accepts whatever spare change the punter has to
     spare, then pounces, metaphorically:

       Before-Cooperating:
           (--) Ok                                 -> Cooperate
                 + Consider-Punter's-Choice
           (--) Nasty                              -> Let's-Be-Nasty
                 + Consider-Punter's-Choice
           (--) Play-Dead                          -> Something-Happened
                 + Switch-Off-All-Lights
                 + Wait-Until-Punter-Has-Left
                 + Switch-On-The-Lights
                 + Wait-For-A-Punter

       If it's  in a good mood, the machine ejects more or less the drink that
     the punter chose:

       Cooperate:
           (--) Coke                               -> Something-Happened
                 + Eject-Can-Of-Coke
                 + Wait-For-A-Punter
           (--) Spring-Water                       -> Something-Happened
                 + Eject-Can-Of-Spring-Water
                 + Wait-For-A-Punter
           (--) Juice                              -> Something-Happened
                 + Eject-Can-Of-Juice
                 + Wait-For-A-Punter
           (--) Sweeto-Sap                         -> Something-Happened
                 + Eject-Can-Of-Sweeto-Sap
                 + Wait-For-A-Punter
           (--) Empty                              ->
                 + Switch-Off-All-Lights
                 + Stop-The-Programme

       If the  coke machine's  pretty weak  internal moral  system failed,  it
     supplies the opposite of whatever the punter wanted:

       Let's-Be-Nasty:
           (--) Coke                               -> Something-Happened
                 + Eject-Can-Of-Juice
                 + Wait-For-A-Punter
           (--) Spring-Water                       -> Something-Happened
                 + Eject-Can-Of-Sweeto-Sap
                 + Wait-For-A-Punter
           (--) Juice                              -> Something-Happened
                 + Eject-Can-Of-Coke
                 + Wait-For-A-Punter
           (--) Sweeto-Sap                         -> Something-Happened
                 + Eject-Can-Of-Spring-Water
                 + Wait-For-A-Punter
           (--) Empty                              ->
                 + Switch-Off-All-Lights
                 + Stop-The-Programme

       This diagram  is a  little complex  for  a  first  example.    Remember
     however, that we are modelling a rich behaviour pattern that took several
     hundreds of  millions of  years to  evolve.   Real  software  is  usually
     developed much  faster, and  should therefore  be much  simpler, only  it
     isn't.

--
Pieter A. Hintjens