Re: enhanced_recursion() and do_event(), can they be redesigned?

[sfeam <sf...@us...>]

On Sunday, 23 February 2014 10:04:42 PM Daniel J Sebald wrote:
> On 02/23/2014 09:43 PM, sfeam wrote:
> > On Sunday, 23 February 2014 09:26:26 PM Daniel J Sebald wrote:
> >> In attempting to modify the qt_term.cpp Qt terminal, I ran into some
> >> annoying problems with recursive calls, namely enhanced_recursion() and
> >> do_event().
> >>
> >> First, let me summarize a few things:
> >>
> >> 1) There are a few uses of the global pointer term->.  My preference
> >> would be to remove those, but I understand there needs to be a way to
> >> get some information back to gnuplot core.  It seems to me that putting
> >> non-const pointers in the API is the best way to do that.  But yes, it
> >> is sort of the same difference.
> >
> > I'm afraid I'm not following you.
> > A few uses for term->   in what piece of code, exactly?
> 
> There aren't many cases, but here is one example in qt_term.cpp:
> 
> // Called just before a plot is going to be displayed.
> void QtTerminalInterface::qt_graphics(unsigned int v_char)
> {
> 	ensureOptionsCreated();
> 	out << GEDesactivate;
> 	qt_flushOutBuffer();
> 	connectToServer();
> 
> 	// Set text encoding
> 	if (!(codec = qt_encodingToCodec(encoding)))
> 		codec = QTextCodec::codecForLocale();
> 
> 	// Set font
> 	currentFontSize = qt_optionFontSize;
> 	currentFontName = qt_option->FontName;
> 
> 	// Set plot size
> 	if (qt_setSize)
> 	{
> 		term->xmax = qt_oversampling*qt_setWidth;
> 		term->ymax = qt_oversampling*qt_setHeight;
> 		qt_setSize = false;
> 	}
> 
> In a separate thread, the "term->xmax =" will be done asynchronously. 
> Hence a mutex/wait is needed to make sure the code in the separate 
> thread has updated term->xmax and term->max before the core thread can 
> continue onward.

Ah. Now I'm with you.
Yeah, this is the piece of code that has changed the most in qt
because nothing seems to work properly on both linux and OSX.
You are quite correct that term->foo should not be referenced in 
this part of the terminal driver.  It is supposed to return the revised
font information via an event GP_fontprops.  And it _was_ doing that
at one point.  I've now lost track of all the work-arounds and what
exactly they fixed, but certainly it would be good if you can get
back to the original intent.  You can look at other terminal
drivers as a model if needed.

> >> So, with that, I'll ask if there is some way of redesigning
> >> enhanced_recursion() and do_event().
> >
> > These have nothing to do with each other, so I don't understand the
> > question.  Both are part of the core, and are shared by all terminals.
> 
> What they share is the fact that they go back to the core code and can 
> recursively issue further API calls before the active API returns.
> 
> 
> >> What is the role of enhanced_recursion()?
> >
> > This is the routine that interprets enhanced text markup strings.
> > It's part of the core text processing.  It is called whenever the
> > core routines want to output a string in enhanced text mode.
> 
> What you described sounds more like enhanced_writec(), whereas 
> enhanced_recursion() is issued by the terminal, at least it is for the 
> Qt terminal.

All of those enhanced_foo() routines are part of the text output layer.
enhanced_recursion() in particular is shared by all terminals and 
lives in term.c.   It is called whenever an enhanced text string is
output, and then calls itself recursively as the name suggests to
handle embedded fragments of the text markup.   E.g.
   "{top_{sub1_{sub2_{sub3}}}}"
Each left curly bracket triggers a new level of recursion.
Please leave it alone.

 
> >> What is the role of do_event()?
> >
> > do_event() is an asynchronous entry point in the core.
> > Interactive terminals use it to request some action, e.g.
> > replot, update mouse coords, zoom, respond to hot-key.
> >
> >> Is there some way a result can be sent back via the API that indicates
> >> to repeat the last event?
> >
> > Sent from whom to whom?  What sort of event?
> 
> Add a second variable to waitforinput, say:
> 
>      qt_waitforinput(int options, gp_event_t* event)
>
> and the gnuplot core does something like:
> 
>      gp_event_t *event_request = 0;
>      term->waitforinput(options, &event_request);
>      if (event_request)
> 	do_event(event_request);
> 
> That way there are no recursions...I'm assuming (hoping) that there 
> isn't recursions inside of recursions.

Sorry, I'm not following this at all.
You can't change waitforinput() for just qt;
it's an API shared by all the interactive terminals.

Anyhow, what's wrong with recursion?
I posted an example before of a hot key definition that
necessarily triggers recursion and works correctly on 
all the terminals I tried.  If there is a piece of the qt
event code that is not re-entry safe, let's fix that first
and then worry about whether something else is also problematic.

	Ethan