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 started. 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 display. 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... Brad <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) future. <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 step. <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 processing...) <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 path... <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 you..) <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 connector? <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 them. <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 confusion. <brad> TextViewer <- Well, I think it would be different in the following ways: <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)