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

[Daniel J S. <dan...@ie...>]

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.


>> I've managed to move enhanced_recursion() into the emitter code (i.e.,
>> same thread as gnuplot core) and that works.  Inelegant, but it works.
>
> Here I'm really lost. enhanced_recursion() is part of the gnuplot core.
> It is shared by all terminals.  What does this have to do with qt
> in particular?

It has to do with the fact I've placed the bulk of the qt terminal in a 
separate thread (which has an execution loop to ensure proper Qt 
behavior...that's the theory anyway).


>> 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.


>> 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.

Dan