10 Sep
2009
10 Sep
'09
5:35 a.m.
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_input.dylib
" -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.
10 Sep
10 Sep
6:36 a.m.
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?
--
View this message in context:
http://www.nabble.com/-FIXED--Interactive-Input-on-Snow-Leopard.-tp25377566…
Sent from the textmate users mailing list archive at Nabble.com.
6:41 a.m.
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!
1:55 p.m.
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?
5:21 p.m.
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/1504bb2b4edc970f1f339d9…
11 Sep
11 Sep
2 a.m.
On 10/09/2009, at 11:55 PM, Adam R. Maxwell wrote:
On Sep 9, 2009, at 10:35 PM, Luke Daley wrote:
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.
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?
Absolutely no idea.
How would I make it async-signal safe and why would I do this?
2:52 a.m.
On Sep 10, 2009, at 7:00 PM, Luke Daley wrote:
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.
On 10/09/2009, at 11:55 PM, Adam R. Maxwell wrote:
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...
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?
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 :).
3:16 a.m.
On 11/09/2009, at 12:52 PM, Adam R. Maxwell wrote:
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.
I am guessing this has something to do the $NOCANCEL symbol variant.
The document
http://developer.apple.com/mac/library/releasenotes/Darwin/SymbolVariantsRe…
just notes that it is for internal use.
I'll do some more research 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?
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 :).
4236
days inactive
4237
days old
7 comments
5 participants
participants (5)
-
Adam R. Maxwell -
Alex Ross -
Luke Daley -
Michael Sheets -
Steve Copley