Re: [Texmacs-dev] continuations

[Joris van der Hoeven]

Dear Max,

Yes, I am aware of the fact that our support for continuations is fragile.
By the way, the copy-stack-based implementation in Guile is quite inefficient.
They will induce another problem if we ever want to replace Guile by
another Scheme dialogue with potentially different conventions or
no support of continuations. I have the plan of completely removing
our dependency on continuations and simply use closures instead.
But this will take some time, of course. What should be easier and
also beneficial would be to replace the existing code for interactive
footer commands by a closure-based implementation. If you have some time,
then you may try. Otherwise, I will do it, when I will have time...

Best, --Joris


Unrelated P.S.: one of the last annoying remaining bugs in the Qt version
is the often erroneous behaviour of images. If someone has some time to
take a careful look at this problem; cf. an earlier post on
this list to Norbert.


On Wed, Dec 22, 2010 at 04:00:39PM +0100, Gubinelli Massimiliano wrote:
> Dear Joris,
>  I just realized that the allowing the scheme code to use continuations puts 
> some restrictions on the coding style in the C++ side. Each time  we call a 
> scheme closure we are not sure to come back (maybe the closure invoke a 
> continuation and we jump in a another stack status and in a different point 
> of the program). Thus if we are modifiyng internal structures of the program 
> we must be sure that they are in the correct state at each of these "cut" 
> points. I didn't realized this before. I wonder if you take care of this in 
> the texmacs code when you invoke scheme command (essentially in interactive 
> input stuff). I like very much the idea of having continuations availables in 
> the scheme part. On the other side I have a very nasty bug which is probably 
> generated by the bad interaction of the continuation jumps with the state of 
> Qt/Cocoa internal structures. The bug does not happen in Linux or Windows. I 
> do not know if it happens with Carbon. I still do not have found a way to 
> circumvent it by modifying the Qt plugin code. 
> I'm trying to fix parts of my code where I didn't take into account the 
> possibility of longjmps generated by scheme continuations. But I do not think 
> this particular bug is due to a problem in my code. Seems more an 
> incompatibility of the Qt framework with this programming style. I have to 
> investigate further.
> 
> 
> The bug I'm referring to is the following: open a new buffer and another one, 
> modify the second  and try to close it. After confirming at the footer prompt 
> you get a EXC_BAD_ACCESS exception in the Qt/Cocoa internals.  
> 
> best
> max
> 
> ps: I post to the list to allow other people partecipate to the discussion if 
> the want.
> 
> 
> 
> 
> 
> _______________________________________________
> Texmacs-dev mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/texmacs-dev