22 Apr
2020
22 Apr
'20
7:20 a.m.
Hi, I just updated to 2.0.8, and there are a few bugs:
• Running a Python script with ⌘R hangs, producing no output in the HTML
output window – the spinny thing continues to spin throughout
– the Ruby stacktrace you get when closing the window with ⌘W – which
comes up in a modal window alert – specifies an exception in a “kill”
method, which is not an evidently obvious visible part of the bundle
command text to which the window alert offers to take you
• Starting up immediately after updating from TextMate 2.0.6 reset the
theme of every open code window to plain black-and-white (this was easily
remedied and wasn’t a showstopper in any way, though)
• There have been a number of odd hard-crashes – the “Submit Crash Log”
dialog would come up, saying that TextMate crashed, but the TextMate UI
would still appear to be up and running; in some cases a part of the UI
would prove to have been rendered unresponsive; in any case a force-quit
was always necessary.
Here are logs from two of these hard-crash events:
• https://gist.github.com/fish2000/2b6957a0f722d006b5673b7440767a9a
Let me know if I can be of further assistance w/r/t this. 2.0.8 looks like
it’ll be awesome, once some of these kinks are ironed out. Yes!
-fish (née Alexander Böhn)
22 Apr
22 Apr
3:56 p.m.
On 22 Apr 2020, at 14:20, Alexander Bohn wrote:
Hi, I just updated to 2.0.8, and there are a few
bugs:
• Running a Python script with ⌘R hangs, producing no output in
the HTML
output window […]
• Starting up immediately after updating from TextMate 2.0.6 reset
the
theme of every open code window to plain black-and-white […]
I think both of these issues could be caused by a corrupted bundle
index.
Try quit TextMate, delete this file, and see if ⌘R works again:
~/Library/Caches/com.macromates.TextMate/BundlesIndex.binary
• There have been a number of odd hard-crashes – the
“Submit
Crash Log”
dialog would come up, saying that TextMate crashed
The crash points to `__CFSocketManager` (system code), I have received a
similar crash from another client, although that one I have seen before
(but it’s rare).
Nonetheless, as it appears there might be an issue related to using
`CFSocket`, I have switched to using a dispatch source instead, as
that’s anyway a more modern (and thus nicer) API.
Please try 2.0.9 available by holding down option (⌥) when selecting
TextMate → Check for Update.
[…] in some cases a part of the UI
would prove to have been rendered unresponsive; in any case a
force-quit
was always necessary.
I have run into this myself, since upgrading to 10.15, it’s when Apple
throws up dialogs during startup, it can end in a “nested run-loop”
state where the outer run-loop gets no events, but is blocking the UI
(waiting for the user to respond to the dialog.
It’s a little tricky to work around with the current code, but I’m
working on a major overhaul of this and more.
9:22 p.m.
On 23 Apr 2020, at 3:56, Allan Odgaard wrote:
I just had a very unfortunate experience with 2.0.9. I noted it was
available as a test build in this thread, and thought I'd try it as I've
seen all manner of weird stuff with file content not refreshing etc.
when files on disc change in 2.0.6 and wondered if there were
improvements. I've not reported bugs about this because so far, I can
never replicate anything.
2.0.9 launched and reloaded all my many windows - several temporary text
files (unsaved, I've just relied on application state restore for so
many years now that I don't even think about it) and and about 20
different projects in different windows across multiple desktops (I'm a
very busy developer, heh). As ever, it didn't put anything back in the
correct desktop spaces so I moved all the windows in Mission Control
manually but then noticed one I wanted to close - but couldn't. TextMate
didn't respond.
At this point I realised that while I could move windows and they'd gain
focus, there was no way to interact. Typing and mouse clicks were
totally ignored.
Then it got stranger. Quitting TextMate from the menu worked,
surprisingly, but it immediately self-restarted! I force-quit it, and it
restarted once more. I tried to shut down the computer, but TextMate
cancelled the restart. Even "pkill -9 TextMate", which did seem to kill
it off, didn't let the computer restart and I had to force-reboot.
A tedious Disk Utility check later, with TextMate automatically
relaunched after the reboot and all its windows restored - nope, no
good; can't click in anything. Quit it; restarts itself. I could't
delete it even after "pkill -9" as the Finder insisted that the
application was open and sure enough a moment later it reappeared. So
this time I used "pkill -9 TextMate; sudo rm -rf ..." to forcibly remove
the application before it had a chance to restart.
I then reinstalled 2.0.6 and - no windows. Nothing. Absolutely all my
state, and all my temporary files including project notes, have
disappeared. Wut?! Surely those are all in Library/Application Support,
*not* stored in the application bundle?
Is there any way I can get any of that back? And what on earth is going
on with TextMate 2.0.9's self-restart behaviour - it's practically a
virus at that point, unkillable and crippling machine functions - is
that a known bug, or a misfiring intended feature of some kind, or just
yet another problem in Catalina at work (10.15.4)?
Thanks in advance for any insights.
--
TTFN, Andrew Hodgkinson
Find photos, software, music and more at my home site, Bandcamp and
GitHub:
https://pond.org.uk / https://pondnz.bandcamp.com /
https://github.com/pond
[…] in some
cases a part of the UI
would prove to have been rendered unresponsive; in any case a
force-quit
was always necessary.
I have run into this myself, since upgrading to 10.15, it’s when
Apple throws up dialogs during startup, it can end in a “nested
run-loop” state where the outer run-loop gets no events, but is
blocking the UI (waiting for the user to respond to the dialog.
23 Apr
23 Apr
12:42 a.m.
On 23 Apr 2020, at 4:22, Andrew Hodgkinson wrote:
I just had a very unfortunate experience with 2.0.9. I
noted it was
available as a test build in this thread, and thought I'd try it as
I've seen all manner of weird stuff with file content not refreshing
etc. when files on disc change in 2.0.6 and wondered if there were
improvements. I've not reported bugs about this because so far, I can
never replicate anything.
Regarding file changes: The code for this has been rewritten using a
simpler API (provided by macOS) and it now watches parent folders.
Previously if a parent folder was changed (renamed or deleted), TextMate
would not notice it, so the open document would become “detached”
from the file on disk (either not using the new path, or if the file got
re-created, it would not notice changes made to the new re-created
file).
This could possibly happen after running a git rebase or similar
operation that would delete and recreate *folders* (with open documents)
in your project.
2.0.9 launched and reloaded all my many windows -
several temporary
text files (unsaved, I've just relied on application state restore for
so many years now that I don't even think about it) and and about 20
different projects in different windows across multiple desktops (I'm
a very busy developer, heh). As ever, it didn't put anything back in
the correct desktop spaces so I moved all the windows in Mission
Control manually but then noticed one I wanted to close - but
couldn't. TextMate didn't respond.
For placing them on the appropriate desktop: There is currently no API
to open a window on a specific desktop.
Apple’s own session restore support is able to do this, it’s not a
drop-in replacement, but I am working on migrating to Apple’s system.
At this point I realised that while I could move
windows and they'd
gain focus, there was no way to interact. Typing and mouse clicks were
totally ignored.
I’ve seen this issue before, both with TextMate and other
applications. But new for macOS 10.15 (I think) is that it used to be,
that one could switch to another application and back, to fix the issue,
but this is not always the case with macOS 10.15.
[…] with TextMate automatically relaunched after the
reboot and all
its windows restored - nope, no good; can't click in anything. Quit
it; restarts itself. I could't delete it even after "pkill -9" as the
Finder insisted that the application was open and sure enough a moment
later it reappeared. So this time I used "pkill -9 TextMate; sudo rm
-rf ..." to forcibly remove the application before it had a chance to
restart.
That is pretty damn weird. So even after a reboot, TextMate kept
relaunching? And still in a state where it didn’t get “proper”
activation (no keyboard input)?
Apple does offer to relaunch applications if they terminate
unexpectedly, but that is offered as an option, not automatic.
I then reinstalled 2.0.6 and - no windows. Nothing.
Absolutely all my
state, and all my temporary files including project notes, have
disappeared. Wut?! Surely those are all in Library/Application
Support, *not* stored in the application bundle?
You should be able to find “untitled” (or unsaved) documents in
`~/Library/Application Support/TextMate/Session`.
Metadata about the files are stored using extended attributes, to view
this, run e.g.:
% xattr -l ~/Library/Application\ Support/TextMate/Session/untitled.txt
com.macromates.backup.file-type: text.plain
com.macromates.backup.identifier: C0498FF4-97E3-4E07-B020-9AF3AF4727D8
com.macromates.backup.modified: YES
com.macromates.backup.tab-size: 4
com.macromates.backup.untitled-count: 1
Is there any way I can get any of that back? And what
on earth is
going on with TextMate 2.0.9's self-restart behaviour - it's
practically a virus at that point, unkillable and crippling machine
functions - is that a known bug, or a misfiring intended feature of
some kind, or just yet another problem in Catalina at work (10.15.4)?
I can assure you that TextMate does not do anything to try and make
itself be relaunched repeatedly (which would require a helper process).
And it is not obvious to me how such a situation can even arise. There
is “keep alive” support in their launch daemon system, but that is
not for GUI applications, and I think their launch daemon support even
stops keeping a process alive (relaunching) if it terminates too
quickly.
1:27 a.m.
On 23 Apr 2020, at 12:42, Allan Odgaard wrote:
Yes, this was very odd; not quite the same thing. In some previous
examples of "doesn't respond", the window doesn't even look like it has
focus even though it's sort-of-active, and switch-away-switch-back does
indeed resolve it. In this case, it looked entirely active and normal,
but just didn't respond to any input.
This could possibly happen after running a git rebase
or similar
operation that would delete and recreate _folders_ (with open
documents) in your project.
Ah yeah, that kinda matches some of the weird stuff. Thanks for putting
in the API migration effort to try and resolve it; will be nice to not
have those issues arise in some future iteration.
Apple’s own session restore support is able to do
this, it’s not a
drop-in replacement, but I am working on migrating to Apple’s
system.
OK - I figured it probably wouldn't be a simple fix, else it'd have
happened ages ago.
At this point
I realised that while I could move windows and they'd
gain focus, there was no way to interact. Typing and mouse clicks
were totally ignored.
I’ve seen this issue before, both with TextMate and other
applications. But new for macOS 10.15 (I think) is that it used to be,
that one could switch to another application and back, to fix the
issue, but this is not always the case with macOS 10.15. That is pretty damn weird. So even after a reboot,
TextMate kept
relaunching? And still in a state where it didn’t get “proper”
activation (no keyboard input)?
That's right - every bit as strange as it sounds. I've no explanation.
In the end, it seems session restore data may have been corrupted
somehow too, since when I finally got 2.0.6 installed back, it'd
complain about having crashed at shutdown previously, and ask me if I
wanted to restore windows. Saying 'yes' would lead to no windows at all,
while saying 'no' would lead to one default empty document... And it did
this *on every launch*. I had to delete it with an app cleaner to fully
remove all related data before it settled down and started behaving
normally.
As you say, this seems almost impossible without some kind of launcher.
If there's nothing in the OS via e.g. flags/other API to say "relaunch
me if I die" then the only explanation I can think of is some horrible
problem in the Catalina window and/or desktop process manager (if
they're separate things, who knows) which just kept relaunching it over
and over, even after a reboot.
You should be able to find “untitled” (or unsaved)
documents
in `~/Library/Application Support/TextMate/Session`.
Thanks - yeah, I dug those out before deleting everything to get 2.0.6
working properly again.
Metadata about the files are stored using extended
attributes, to view
this [...]
Useful! Thanks.
And it is not obvious to me how such a situation can
even arise. There
is “keep alive” support in their launch daemon system, but that is
not for GUI applications, and I think their launch daemon support even
stops keeping a process alive (relaunching) if it terminates too
quickly.
Totally agree. It seems we've no choice but to chalk it up to even more
super-lousy engineering in Catalina; yet another weird rotting-code bug
that'll probably never be fixed. If I do ever manage to get anything
replicable or diagnosed, I'll let you know.
Thanks for the detailed reply,
--
TTFN, Andrew Hodgkinson
Find photos, software, music and more at my home site, Bandcamp and
GitHub:
https://pond.org.uk / https://pondnz.bandcamp.com /
https://github.com/pond
12:14 p.m.
On 22 Apr 2020, at 20:42, Allan Odgaard wrote:
That is pretty damn weird. So even after a reboot,
TextMate kept
relaunching? And still in a state where it didn’t get “proper”
activation (no keyboard input)?
Apple does offer to relaunch applications if they terminate
unexpectedly, but that is offered as an option, not automatic.
I just saw the same behavior on 10.14.6. (Keyboard and mouse input
appear to do nothing, and TextMate immediately relaunches when
quit/killed.)
An easy fix, in case anyone else runs into this: Restore 2.0.8 or older
from a backup and replace 2.0.9 with it in your Applications folder.
After that, quitting 2.0.9 will actually quit and you can launch the
older version.
--
Rob McBroom
4:28 p.m.
On 23 Apr 2020, at 19:14, Rob McBroom wrote:
On 22 Apr 2020, at 20:42, Allan Odgaard wrote:
Interestingly today I had two instances of this myself, both after
rebooting (although on second run, TextMate was responsive).
I was able to study the stack trace of TextMate and I *think* 2.0.10
should avoid getting TextMate into this state.
That is pretty damn weird. So even after a
reboot, TextMate kept
relaunching? And still in a state where it didn’t get “proper”
activation (no keyboard input)?
Apple does offer to relaunch applications if they terminate
unexpectedly, but that is offered as an option, not automatic.
I just saw the same behavior on 10.14.6. (Keyboard and mouse input
appear to do nothing, and TextMate immediately relaunches when
quit/killed.)
361
days inactive
362
days old
6 comments
4 participants
participants (4)
-
Alexander Bohn -
Allan Odgaard -
Andrew Hodgkinson -
Rob McBroom