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 [email protected] http://lists.gnu.org/mailman/listinfo/texmacs-dev
