There seems to be a problem with how TextMate deals with processes run from a document. If you want your TextMate to become irresponsive, just do the following
1. Open a new document 2. Type "yes" 3. Press ^R 4. Voilá!
Of course what you do is to run into an endless loop here. But the problem is that the whole application becomes irresponsive. It really should not be as prone to errors in external programs, since this creates the risk of data losses.
On 28. Oct 2006, at 20:47, Nicolas Schmidt wrote:
There seems to be a problem with how TextMate deals with processes run from a document. If you want your TextMate to become irresponsive, just do the following
- Open a new document
- Type "yes"
- Press ^R
- Voilá!
Of course what you do is to run into an endless loop here. But the problem is that the whole application becomes irresponsive. It really should not be as prone to errors in external programs, since this creates the risk of data losses.
So what do you suggest? I remove the ability for you to run shell commands (and scripts) from TextMate?
Btw: you can always press ⌃C or ⌘. to kill the currently running sub process.
Am 29.10.2006 um 02:30 schrieb Allan Odgaard:
So what do you suggest? I remove the ability for you to run shell commands (and scripts) from TextMate?
Btw: you can always press ⌃C or ⌘. to kill the currently running sub process.
The proper behaviour would be that only the window from which the command is run (multi-tasking ?) is affected. I suppose that the subprocess spawned is synchronous (?!?).
P.S.: I tried to kill the process with ^C , but TextMate didn't seem to be able to terminate it. Instead it now became totally unresponsive, so that I had to bring down TextMate itself.
On 29. Oct 2006, at 12:12, Nicolas Schmidt wrote:
The proper behaviour would be that only the window from which the command is run (multi-tasking ?) is affected.
Unfortunately it is not easy to block just a single window w/o bringing up a sheet (I did take an initial shot at this some time ago). It also doesn’t make a lot of difference for people who work with projects (since the other tabs will still be unavailable).
Ideally only the buffer should be “busy” and a progress indicator should appear after 5 seconds or so with an explicit “abort” button -- but that is also problematic for a few reasons (e.g. we do not want the progress indicator for commands which opens a UI, but TM can’t always spot it) and it’s a lot of work for something which until your letter hadn’t been described as “a problem with how TextMate deals with processes” nor that “It really should not be as prone to errors in external programs” -- most people know what being able to run shell commands from the buffer means, and the ⌃C / ⌘. is generally enough to keep people from totally shooting themselves in the foot with this feature.
I suppose that the subprocess spawned is synchronous (?!?).
I don’t know what “synchronous” refers to here. Since the result from the command is inserted into the document, the process is serial, yes, in that it needs to wait for the command to finish, before letting the user continue his work, just as if you ran a macro, inserted a snippet, etc.
P.S.: I tried to kill the process with ^C , but TextMate didn't seem to be able to terminate it. Instead it now became totally unresponsive, so that I had to bring down TextMate itself.
The ‘yes’ command outputs around 20 MB/s on my machine, so if you had this running for just a few seconds before you killed it, you are in for a wait.
On Oct 29, 2006, at 10:59 AM, Allan Odgaard wrote:
The ‘yes’ command outputs around 20 MB/s on my machine, so if you had this running for just a few seconds before you killed it, you are in for a wait.
Perhaps what would make this particular user happy is a hidden preference where TextMate terminates the process after a configurable limit (based on amount of data) has been reached. I'm guessing most folks don't intend to insert megabytes of data into their buffer.
j.
The ‘yes’ command outputs around 20 MB/s on my machine, so if you had this running for just a few seconds before you killed it, you are in for a wait.
Well waiting may be an intended behaviour, but I think crashing silently isn't.
CONSOLE OUTPUT START
TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug terminate called after throwing an instance of 'std::bad_alloc' TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug TextMate(221,0xa000ed88) malloc: *** vm_allocate(size=8421376) failed (error code=3) TextMate(221,0xa000ed88) malloc: *** error: can't allocate region TextMate(221,0xa000ed88) malloc: *** set a breakpoint in szone_error to debug what(): St9bad_alloc
CONSOLE OUTPUT END
So what do you suggest? I remove the ability for you to run shell commands (and scripts) from TextMate?
I just checked Xcode's behaviour regarding this "feature". Instead of waiting until termination and then pasting the output in the current window, it pastes program output instantaneously. I think this is favourable over TM's behaviour (and the fact that it doesn't crash).
On 30 Oct 2006, at 23:39, Nicolas Schmidt wrote:
I just checked Xcode's behaviour regarding this "feature". Instead of waiting until termination and then pasting the output in the current window, it pastes program output instantaneously. I think this is favourable over TM's behaviour (and the fact that it doesn't crash).
The actual problem is not the insertion of text -- it's TextMate's reparsing of the whole file afterwards. Its scoping system needs to do it, whereas Xcode's syntax highlighting (which is also a few orders of magnitude less complex/powerful) can often get away with only reparsing what's on the screen right now.
TM is slow when processing very large files. It's a known problem (although not that important if you ask me).
-- Max
On Oct 30, 2006, at 3:09 PM, Max Noel wrote:
The actual problem is not the insertion of text -- it's TextMate's reparsing of the whole file afterwards. Its scoping system needs to do it, whereas Xcode's syntax highlighting (which is also a few orders of magnitude less complex/powerful) can often get away with only reparsing what's on the screen right now.
TM is slow when processing very large files. It's a known problem (although not that important if you ask me).
That isn't entirely true. The Cocoa text subsystem is not terribly efficient at rendering HUGE chunks of text, either from the layout or loading perspective.
b.bum
On Oct 30, 2006, at 2:39 PM, Nicolas Schmidt wrote:
So what do you suggest? I remove the ability for you to run shell commands (and scripts) from TextMate?
I just checked Xcode's behaviour regarding this "feature". Instead of waiting until termination and then pasting the output in the current window, it pastes program output instantaneously. I think this is favourable over TM's behaviour (and the fact that it doesn't crash).
Sure... though not throttling tons of output when that situation occurs is still a potentially catastrophic failure. TextMate's text window simply isn't going to deal with 20MB/sec of text being pushed into it.
Now, one might argue that a tail -f feature would be cool. However, this is pretty far afield of "editing a buffer of text", which seems to be TextMate's core charter.
Interestingly, the TermMate bundle may have the solution under the assumption that iTerm.framework actually does terminal like things such as dealing with the output of tail -f, efficiently rendering a buffer full o' text where the size of the text may be 10s or 100s of MB, and automatically throwing away all lines prior to the last, say, 10,000 (buffer limit).
TM, itself, should likely solve the problem thusly:
- launch the process and start emitting output into buffer as it is produced
- start buffer-n-spew mode after ##K worth of output
- suspend the inferior and bring up a "continue/continue-for-1MB-more/ quit" after, say, a megabyte of output produced
That would solve the problem without trying to turn the TextMate editing environment into a log monitor.
b.bum
TM, itself, should likely solve the problem thusly:
- launch the process and start emitting output into buffer as it is
produced
start buffer-n-spew mode after ##K worth of output
suspend the inferior and bring up a "continue/continue-for-1MB-
more/quit" after, say, a megabyte of output produced
That would solve the problem without trying to turn the TextMate editing environment into a log monitor.
Considering that probably TextMate never will be able to handle such big amounts of data as quick as Xcode for the mentioned reason, I conclude that this proposal is reasonable.
But besides the question of proper policy regarding sub processes and big amounts of data, there's still the problem that TextMate in fact quits ungracefully (that means without asking whether so save any data) when running "yes" from a document, aborting the process and waiting until this to happen.
On 31. Oct 2006, at 18:53, Nicolas Schmidt wrote:
But besides the question of proper policy regarding sub processes and big amounts of data, there's still the problem that TextMate in fact quits ungracefully (that means without asking whether so save any data) when running "yes" from a document, aborting the process and waiting until this to happen.
It does that because it simply runs out of memory and can’t do much more.
I agree that these things are not at all ideal, and long-term I certainly hope to have much better handling of it, but it is not what gets top priority, as for 99.9% of users, these things really never come up.
Nicolas Schmidt wrote:
There seems to be a problem with how TextMate deals with processes run from a document. If you want your TextMate to become irresponsive, just do the following
- Open a new document
- Type "yes"
- Press ^R
- Voilá!
Of course what you do is to run into an endless loop here. But the problem is that the whole application becomes irresponsive. It really should not be as prone to errors in external programs, since this creates the risk of data losses.
You could always kill the bash process to bring TM back to life…
-
Allan Odgaard -
Bill Bumgarner -
Jacob Rus -
Jay Soffian -
Max Noel -
Nicolas Schmidt