Greetings and about outlet, input & general stuff

[Alberto Gomez-Casado]

Hi Massimo and nice to 'meet' you Marco (where you the guy that was
with Massimo in Linz?).

Just today I uploaded couple of patches for libinput that should make
its usage clearer (I admit old calls were everything but nice-
looking), so before I have to refresh my memory I can just give you
two a brief overview of what I did recently.

LIBINPUT
Is just a collection of wrappers for raw_input(), I noticed using
hooke that unexpected answers from the user often triggered a nasty
crash, so what they do is provide some basic check of inputs to avoid
'voids', letters where numbers are expected, etc

The basic call there is safeinput(message,[list])
Message is a string that is shown to the user ('Enter filename:')
[list] can be present or not.
- If not present safeinput is just a raw_input shielded against void
inputs (it will keep asking until it gets some answer)
- If a list of only one element is provided, it is interpreted as a
default value (in case a void input that value will be returned)
- If a list of two or more 'string' elements is provided, user input
must match one of them to be valid
- If a list of two integer elements [a, b] is provided, user input
is required to be in the interval [a,b]

More info about the underlying calls can be found in the code. However
I am still not very satisfied with them, That's why I made safeinput()
to wrap all so I can improve them without further fiddling with other
module's code.


OUTLET
I though of this as just a centralized collector of command output.
Other option would have been making each command save results, but I
think that would have led to a lot of code duplication and probably
huge user hassle (do you want to save this? and this? and this
one?). So there's this object 'outlet' and the only thing each command
has to know about it is the method outlet.push(line) and the format of
that line, that so far is

type filename [list]

- type identifies which command produced that line
- filename is the curve from which the command produced the output
(this allows to know for example if a curve had more than one peak,
but user is left responsible of their ordering!). It's also useful to
keep track of where were you last time (if you follow natural order
when looking at curves).
- list can have pretty much anything, depending on the particular
command

From the point of view of the commands there is nothing else about
outlet. Apart from that I made a couple of commands to delete lines in
case you had a twitch when click and don what that measurement to be
saved and to have a look at current contents of outlet.


VIEWER
So far outlet is useless. That's where viewers (well, only one now)
do the job. They query outlet for data of some type, process it and
give some elaborated output. Again the only thing they have to know
about outlet is how to call it and the 'line' format.

I put in the viewer plugin a list to keep them so it is possible to
create many. The basic operations in viewer.py
- vwnew: adds a new viewer to the list, and sets it so it defines
what type of data it will be interested in
- vwaction: tells the viewer to 'do stuff', that is, retrieve data
and process it. Just a wrapper call for the specific one of each
viewer.

Names are not pretty by the way. I know.

In libviewer.py there is the structure of viewer object and a sample
viewer, a simple ascii dump of a user selected data type.

Plan is to use this structure to make more complicated viewers, like
having quick statistics in the program about the measurements you did
so far, or even making graphs with them without leaving hooke. This is
why I didn't merge outlet+viewer in the same object, this way I have a
'decoupling' system to make things (I think) easier.

Finally I put in outlet an attribute, relations, that could be used in
the future by the viewers to register themselves so outlet can
trigger their actions when new data arrives (allowing automatic
refreshes). But so far that's probably overdesigning.

Hope I made it finally clear.

See you guys.

[massimo s.]

Hi Alberto,

I answer in charge of Marco now (we currently have an internet outage in
the laboratory and now I'm at home, so I guess Marco will read it
tomorrow or Monday...)

Alberto Gomez-Casado ha scritto:

> Hi Massimo and nice to 'meet' you Marco (where you the guy that was
> with Massimo in Linz?).

Yes he is - we're the Linz conspiracy.

As for your explanations, to me they are *much* helpful -most of it I
had somewhat understood, but now it's clear. That will help us use that
in our code. I hope to add them to some reference/tutorial when the
function calls will somehow solidify.

Thanks & nice weekend (well, nice...here in Bologna it's going insanely hot)

m.

[MarcoB]

Hi Alberto!

Yes, I'm the unfortunate soul that suffered the excruciating
experience of going to Linz with Massimo. But look, I blame the Linz
conference, not Massimo. No, really.

On the serious side,thanks for the explanations: now it all makes
sense to me. I'm going to further modify the force clamp module very
soon (there are a couple further commands I need), and I'll take the
opportunity to experiment a bit with the .push stuff.

I notice, as I'm typing, that I wiped out your additions to the clamp
module somehow!
Bear with me, today's was my first SVN commit of my entire life...
I'll put the lines back ASAP.

,'``.._ ,'``.
:,--._:)\,:,._,.: All Glory to
:`--,'' :`...';\ the HYPNO TOAD!
`,' `---' `.
/ :
/ \
,' :\.___,-.
`...,---'``````-..._ |: \
( ) ;: ) \ _,-.
`. ( // `' \
: `.// ) ) , ;
,-|`. _,'/ ) ) ,' ,'
( :`.`-..____..=:.-': . _,' ,'
`,'\ ``--....-)=' `._, \ ,') _ '``._
_.-/ _ `. (_) / )' ; / \ \`-.'
`--( `-:`. `' ___..' _,-' |/ `.)
`-. `.`.``-----``--, .'
|/`.\`' ,','); SSt
` (/ (/