[Pipet Devel] IRC about TextViewers

Brad Chapman chapmanb at arches.uga.edu
Sat Aug 26 16:47:38 EDT 2000

Hey all;
	I was doing some thinking about plugging things together more and
how we would be returning output back to the user interface components. I
wrote to Jean-Marc with the idea of having a TextViewer node that would
return the text back to the user interface as follows:

1. UIDocument::run() would be called initially, to get the process

2. During the processing, the TextViewer node would do something like
store the info that is to be displayed so that the BL can get it (this
idea migrated into having callbacks during the IRC discussion).

3. The BL could then return the info back to the dl, which would place a
callback to the user interface to let it know it had some values to

This way we could keep the UI completely separate, and still return
values back. Anyways, Jean-Marc and I had an IRC discussion about this,
so here it is below, for your reading pleasure. As always, comments are
very welcome. Enjoy! I'm off to start coding some of this...


<jm> Actually, I wanted to tell you that your last ideas (for text
output) do make sense, and were something I was planning in the (near)
<brad> So my last e-mail made some sense? Really?
<jm> I'm happy that some of my ideas did get accepted into Piper. I think
so far we managed to take the best from each project...
<brad> I think so too. Now we just have to work on moving forward and
adding more!
<jm> Tell me what you think about this: instead of having a new system
for the text output, why not use the Save node and create a special C++
stream that sends the data to a viewer instead of a file (or stdout)
<brad> That sounds good, although I would like to pipe the steam through
the bl (eventually) and then trhough the dl, instead of directly to the
user interface.
<brad> This way we can kind of keep the separation between user interface
and everything else intact. Although I'm not so sure how well this will
work in practice...
<jm> Sure, you keep the same "Save" node and you can write any kind of
stream. We can write one that sends that to the BL.
<brad> That would be really great -- what do you think it would take to
implement that?
<jm> Well, you need to define a class that derives from iostream (or
stream, I don't know) and that implements the standard stream operators
(read, write, ..), but differenly that the file streams. For the rest,
Jarl (and you?) know more about how to talk to the BL.
<jm> I've been thinking, though. what do we do with the probes? Those are
not like a viewer, they're interactive.
<brad> Well, I don't know much about the BL... but how about if we wrote
directly to the DL right now...Would I just need to wrap and store the
info generated by the write operation?
<brad> probes <- I'm not sure... (especially since I've never seen them
in action :-). What do you use them for?
<jm> a Probe is the Overflow equivalent of a debugger. You can see the
data that passes through them for every iteration and you can control the
flow with a set of next/stop/continue buttons.
<jm> Take a look at
http://freespeech.on.openprojects.net/08-03-00_023434_screenshot.jpg to
see probes in action.
<brad> Hmm, well I think we could use the same kind of thing for viewing
them. Everytime you wrote to the "Save" stream, this would call an update
in the user interface.
<brad> But I'm not sure about controlling the flow...what are the
functions that control the run() process right now?
<jm> The problem is the flow control. As in a debugger, you tell the
probes to stop the stream until you press next. The way a probe stops the
flow is by not returning from getOutput() until the user presses next.
<jm> This was the part where I changed semaphores for mutexes
<brad> Okay, well how about if we had something like this:
<brad> 1. The Probe has an internal variable, say 'info,' that gets set
after every iteration.
<brad> 2. The Probe also has a function has_info() which only returns
TRUE when the info is set.
<brad> 3. The BL or DL retrieves the info with a get_info() function
every time has_info() is TRUE, and then displays this info by a callback
to the User interface.
<brad> 4. The User interface then has a "next" button like in your
probes, that the DL or BL will call to advance the debugger to the next
<brad> 5. The Probe then clears its info and runs again, and so on...
<brad> Does this make sense or no?
<jm> Let me think......
<jm> makes sense... but I think it would be better for the probe to send
the info to the BL instead of waiting for the BL to read it. The result
of this idea is to simply replace the GUI calls in the probes by BL
calls, right?
<jm> (Of course, the simple solution is to limit the probes to local
<brad> info to the BL <- This make better sense, you are right. 
<brad> simple solution <- Right, but I guess we will have a similar
problem with the "Viewer" function I was talking about. The probe is just
a harder superclass of this same type of thing, right?
<jm> This way, your text viewer will end up as being a modified TextProbe
<brad> Yeah, that is what I was thinking! Does that seem like the right
thing to do?
<jm> For now it does look to me... we'll have to wait until Jarl comes up
with a version of the BL that works with the DL. I've learned from
developing Overflow that the line between a very clever idea and a stupid
idea is often very thin!
<brad> Definately true :-)
--> katie (lizzy at cn-380.ccisp.net) has joined #piper
<jm> For now, I suggest you try to work with the actual probes and we'll
modify them when the BL starts getting stable.
<brad> Also, what about a TextViewer that is at the end of a work path,
like in my example. How is that handled?
<jm> What do you mean by "at the end of a work path"?
<-- katie (lizzy at cn-380.ccisp.net) has left #piper
<brad> actual probes <- How about if I write a TextViewer.cc node that is
similar to TextProbe, that does this sort of thing?
<jm> (I think katie wasn't much interested in Piper!)
<jm> I'm now sure I understand...
<brad> end of work path <- I mean that then end of a set of connected
nodes. Like in my diagram, the TextViewer kind of ends the connection
<brad> understand <- Do you mean you do understand or don't?
<jm> oops that should have read I'm NOT sure I understand... sort of
changes the meaning!
<jm> well, you just put the netOutput at the output of the probe?
<brad> netOutput <- How would this be done exactly? In Overflow you
explicitly set the output to point somewhere (like the less_print box),
but in Piper this isn't necessarily true (like in the screenshot I sent
<jm> Also, if you don't want the result to be sent out of the network,
you send it do a Discard node (returns NIL regardless of the input)
<brad> Oh, okay, a discard node! But doesn't that still have an output
<brad> understand <- So you don't understand the TextViewer thing? I was
just thinking maybe I could implement this type of viewer to do what I
was trying to do, and then we can kind of see if it works. Maybe I'll
just have it do callbacks to the DL for now or something.
<jm> Well, regardless of the text viewer issue, all Overflow networks
need to have an output. That ouput is printed with on stdout in batchflow
or in a window in vflow. You do not have to print it in Piper, or you can
use the Discard node, but you still need to have an output, since
Overflow uses a "pull".
<brad> But I thought Overflow would pull from the end of the path. I
guess I'm confused -- where does the pull start from?
<jm> The pull starts from the netOutput of the toplevel network.
<jm> If you have more than one netOutput, Overflow will pull from all of
<brad> Oooooh, netOutput! Right. Okay, I'll have to think of a way to
make this jive with how things look in Piper...
<jm> From what I understand, Piper (Loci) used to consider any
unconnected terminal as a netOutput (or netInput). That's maybe where the
confusion comes from.
<brad> Okay, I think this makes some sense. I'm not sure if I understand
the entire process of making a node, so I might go ahead and try to make
a TextViewer node and see how it goes. 
<jm> I still don't understand how the TextViewer you want is different
from the TextProbe
<brad> unconnected terminals <- Yeah, this is definately the point of my
<brad> TextViewer <- Well, I think it would be different in the following
<brad> 1. No "stopping" of process flow, like with your Probe nodes.
<brad> 2. Try and implement some of this "callback" thing we were just
talking about, so that the node wouldn't have to talk directly to the
user interface.
<brad> Does that make sense?
<jm> Sure, go ahead... and tell me if you need help.
<brad> I'm sure I will :-)
<brad> It will be good for me to dig further into the whole node process
anyways. I understand the UI layer okay now, but not the data-flow/node
stuff, so I need to work on this anyways!
<brad> Oh yeah, I've got another smaller question for you -- what case
does Overflow expect the types of node parameters (and inputs and
outputs) to be in?
<jm> In this case, I suggest you start from the NOP node. NOP is the "no
op" node and simply retuns its input, without any processing.
<brad> For instance does it want INT or int or Int?
<brad> NOP <- Sounds nice and easy -- a good place for me to start :-)
<jm> Its lowercase (int, float), although the actual classes in the code
are called Int, Float, so it doesn't cause problem with the real int,
float types.
<brad> Thanks. That is what I was thinking, but I wanted to be sure. I
have everything as ALLCAPS now, and run doesn't like it :-)
<brad> I'll work on changing it over to lowercase...
<jm> For the rest (input/output name, parameter name, ...), you can use
what you want for the node you build, but the convention (so far) is to
use all caps for the input/output/parameter names and mixed for node
names (like the ConstantVector node)
<brad> Okay, I think I had been "sort of" sticking by this, but I'll keep
an eye out to make sure everything is the same.
<jm> Well, my girlfriend just arrived, and it seems like we're leaving
for ice cream... (D'OH!)
<brad> Sounds fun :-)
<jm> So ttyl...
<brad> Thanks for talking this stuff over with me, ttyl!
<-- jm has quit ([x]chat)

More information about the Pipet-Devel mailing list