Hi all,
I believe I have fixed the issues with interactive input on Snow Leopard. However, this should be considered beta until it gets included in the TM distribution.
That said, if you are brave enough to test it it would be very much appreciated.
To install, open up a document in TextMate and enter the following one line:
curl "http://cloud.github.com/downloads/alkemist/interactive-input/tm_interactive_... " -o "$TM_SUPPORT_PATH/lib/tm_interactive_input.dylib"
With the caret on that line, press ⌃R to run the command. Interactive input will be reinstated and you don't need to restart TM.
Please raise any issues on this list.
LD.
I'm not on Snow Leopard, just 1.5.8
But... this fixes the interactive input issue for me
Many thanks!
Steve
P.S. Any idea what I have to do to get rid of the error "TERM environment variable not set."? It appears because I'm calling os.system("clear") to clear the terminal screen. I know this'll not work with the TM running window, but can I stop the error?
On Sep 9, 2009, at 11:36 PM, Steve Copley wrote:
I'm not on Snow Leopard, just 1.5.8
But... this fixes the interactive input issue for me
Many thanks!
Steve
P.S. Any idea what I have to do to get rid of the error "TERM environment variable not set."? It appears because I'm calling os.system ("clear") to clear the terminal screen. I know this'll not work with the TM running window, but can I stop the error?
You could check that TERM is set before you call os.system("clear"). You could also try setting a TERM variable in TextMate's preferences, but I have no idea what will happen then!
On Sep 9, 2009, at 10:35 PM, Luke Daley wrote:
I believe I have fixed the issues with interactive input on Snow Leopard. However, this should be considered beta until it gets included in the TM distribution.
ISTR the crash I saw on Snow Leopard looked like it was calling malloc (via strdup in mode.c) before the system's malloc zone was set up. Is that still the case? Also, for my own curiosity, is it a problem that your read override doesn't appear to be async-signal safe?
On Sep 10, 2009, at 8:55 AM, Adam R. Maxwell wrote:
ISTR the crash I saw on Snow Leopard looked like it was calling malloc (via strdup in mode.c) before the system's malloc zone was set up. Is that still the case? Also, for my own curiosity, is it a problem that your read override doesn't appear to be async-signal safe?
The fix is described at:
http://github.com/alkemist/interactive-input/commit/1504bb2b4edc970f1f339d98...
On 10/09/2009, at 11:55 PM, Adam R. Maxwell wrote:
On Sep 9, 2009, at 10:35 PM, Luke Daley wrote:
I believe I have fixed the issues with interactive input on Snow Leopard. However, this should be considered beta until it gets included in the TM distribution.
ISTR the crash I saw on Snow Leopard looked like it was calling malloc (via strdup in mode.c) before the system's malloc zone was set up. Is that still the case?
TBH, it was very difficult to determine exactly what was going on. I was operating under the assumption that the problem was due to something in our read() implementation calling something that in turn invoked read() causing a recursion. Your explanation makes more sense. I'll test this and let you know.
Also, for my own curiosity, is it a problem that your read override doesn't appear to be async-signal safe?
Absolutely no idea.
How would I make it async-signal safe and why would I do this?
On Sep 10, 2009, at 7:00 PM, Luke Daley wrote:
On 10/09/2009, at 11:55 PM, Adam R. Maxwell wrote:
ISTR the crash I saw on Snow Leopard looked like it was calling malloc (via strdup in mode.c) before the system's malloc zone was set up. Is that still the case?
TBH, it was very difficult to determine exactly what was going on. I was operating under the assumption that the problem was due to something in our read() implementation calling something that in turn invoked read() causing a recursion. Your explanation makes more sense. I'll test this and let you know.
That was just my guess based on the stack trace I saw, and a glance at the code confirmed that mode_contains calls strdup. If my guess is correct, that particular issue could likely worked around by using vm_allocate instead of strdup; I never got around to trying it myself, though. I have yet to look at the Darwin source to see why Apple is calling arc4random when creating the scalable zone now...
Also, for my own curiosity, is it a problem that your read override doesn't appear to be async-signal safe?
Absolutely no idea.
How would I make it async-signal safe
Well, my understanding is that you'd be limited to functions listed in the man page for sigaction(2). So strdup/getenv/etc would be off limits. Not much fun.
and why would I do this?
My guess is that it would matter if code using the library relies on calling read() from a signal handler. Signal handling is outside my area of expertise, so I was hoping someone else would have an answer :).
On 11/09/2009, at 12:52 PM, Adam R. Maxwell wrote:
Also, for my own curiosity, is it a problem that your read override doesn't appear to be async-signal safe?
Absolutely no idea.
How would I make it async-signal safe
Well, my understanding is that you'd be limited to functions listed in the man page for sigaction(2). So strdup/getenv/etc would be off limits. Not much fun.
Indeed. I very much doubt we could practically achieve what we need to with this limitation.
and why would I do this?
My guess is that it would matter if code using the library relies on calling read() from a signal handler. Signal handling is outside my area of expertise, so I was hoping someone else would have an answer :).
I am guessing this has something to do the $NOCANCEL symbol variant.
The document http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRel... just notes that it is for internal use.
I'll do some more research and let you know.
-
Adam R. Maxwell -
Alex Ross -
Luke Daley -
Michael Sheets -
Steve Copley