On zondag, mei 26, 2002, at 11:49 , Christian Tismer wrote: > >> However, and more importantly, there is a good chance that Tcl itself >> also allocates memory on the stack for use in called functions. In a >> Python -> Tcl -> Python -> Tcl scenario, this may cause problems for >> stackless Python; one would have to inspect the entire Tcl source >> base, or analyse the specific problem in more detail to be sure. > > Incredibly bad! Bad style, even worse, bad for me. > I change my question to: > What patterns beyond the > Python -> Tcl -> Python -> Tcl > scenario are thinkable? > I already spent 14 hours on this. I'm happy > to work around it if there is a finite > number of cases. But if this leads to major > changes to Tcl, I'd prefer to declare Stackless > incompatible with Tcl. It works great with PythonWin > and wxPython, which is a plus for design. Does your assertion "it works great with PythonWin and wxPython" mean that neither of those can have the situation where you go from Python -> Windows -> Python -> Windows (or replace Windows with wx) while you have a reference to the first Python stack passed to the first Windows call, which is then subsequently used by the second Windows call? Or does it mean something "lighter"? Because if you indeed mean what I guess here then I can't be sure that the Mac toolbox modules are safe either, at least not without serious inspection. A lot of structures are allocated on the stack in the glue routines, and a lot of toolbox modules may do callbacks. Or does your "works great" merely mean that you haven't run into any problems yet? -- - Jack Jansen <Jack.Jansen@oratrix.com> http://www.cwi.nl/~jack - - If I can't dance I don't want to be part of your revolution -- Emma Goldman -
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4