Hi,
Many of my Textmate commands are slow and take up to 15 seconds. My problem seems to be the same than the one described in this thread: http://lists.macromates.com/textmate/2006-January/007647.html. The top command shows that the bash seems to be taking up all available CPU cycles while TextMate is loading. This is really annoying, since this happens with even very basic bundle commands like bolding in LaTeX, which renders the commands in LaTeX bundle virtually unusable.
I tried the solution provided in this post: http://lists.macromates.com/textmate/2006-January/007705.html. However, I don't have fink or any other suspicious lines in my .bash_profile, .bash_login or .profile files. Does anyone have any idea on what might possibly cause the problem?
Regards, Juho
On Jun 3, 2009, at 12:09 PM, Juho Makkonen wrote:
Hi,
Many of my Textmate commands are slow and take up to 15 seconds. My problem seems to be the same than the one described in this thread: http://lists.macromates.com/textmate/2006-January/007647.html. The top command shows that the bash seems to be taking up all available CPU cycles while TextMate is loading. This is really annoying, since this happens with even very basic bundle commands like bolding in LaTeX, which renders the commands in LaTeX bundle virtually unusable.
I tried the solution provided in this post: http://lists.macromates.com/textmate/2006-January/007705.html. However, I don't have fink or any other suspicious lines in my .bash_profile, .bash_login or .profile files. Does anyone have any idea on what might possibly cause the problem?
Any chance you could paste your .bash_profile / .profile ?
Alex Ross wrote:
On Jun 3, 2009, at 12:09 PM, Juho Makkonen wrote:
Hi,
Many of my Textmate commands are slow and take up to 15 seconds. My problem seems to be the same than the one described in this thread: http://lists.macromates.com/textmate/2006-January/007647.html. The top command shows that the bash seems to be taking up all available CPU cycles while TextMate is loading. This is really annoying, since this happens with even very basic bundle commands like bolding in LaTeX, which renders the commands in LaTeX bundle virtually unusable.
I tried the solution provided in this post: http://lists.macromates.com/textmate/2006-January/007705.html. However, I don't have fink or any other suspicious lines in my .bash_profile, .bash_login or .profile files. Does anyone have any idea on what might possibly cause the problem?
Any chance you could paste your .bash_profile / .profile ?
Sure. Actually neither of those files contains anything at the moment, but /etc/profile contains these lines (they are there by default after the installation, i believe):
# System-wide .profile for sh(1)
if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
if [ "${BASH-no}" != "no" ]; then [ -r /etc/bashrc ] && . /etc/bashrc fi
-juho
Allan Odgaard wrote:
On 3 Jun 2009, at 22:07, Juho Makkonen wrote:
[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.
This solved the problem, thanks! What is the point in those lines anyway, does commenting them cause any problems?
-juho
On 04.06.2009, at 10:05, Juho Makkonen wrote:
Allan Odgaard wrote:
On 3 Jun 2009, at 22:07, Juho Makkonen wrote:
[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.
This solved the problem, thanks! What is the point in those lines anyway, does commenting them cause any problems?
Those lines add the components defined in /etc/paths and /etc/paths.d/ * to your PATH, making executables there available to your shell processes. The downside of disabling them is that for executables found in one of those directories you need to either add their component to PATH manually or type their full path when you want to run them.
FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.
Martin
FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.
Interesting. I didn't know that one. But why do I receive an egrep not found each time I start a bash after having applied this patch?
enas
On 04.06.2009, at 19:27, enas wrote:
FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.
Interesting. I didn't know that one. But why do I receive an egrep not found each time I start a bash after having applied this patch?
I’d guess that your PATH isn’t set up correctly :-D egrep(1) should be in `/usr/bin', so you should replace the egrep call with `/usr/bin/egrep' (without the quotes).
(I thought /usr/bin was part of the default PATH bash defines on startup when it’s empty…)
Martin
On 4 Jun 2009, at 18:51, Martin Kühl wrote:
On 04.06.2009, at 19:27, enas wrote:
FWIW, I’ve applied the patch at http://gist.github.com/123525 to my system, which takes care of the slowdowns for me. Of course you should backup the path_helper script beforehand, patching system scripts is generally not a good idea, use at your own risk and so on.
Interesting. I didn't know that one. But why do I receive an egrep not found each time I start a bash after having applied this patch?
I’d guess that your PATH isn’t set up correctly :-D
Surely :)
(I thought /usr/bin was part of the default PATH bash defines on startup when it’s empty…)
I thought too, that's why I find it strange that this patch doesn't work on my system, which is by any means standard (and I had already come upon this problem), while it works for you (at the author of the patch too I guess). Anyway, that's out of the scope of this discussion (and I did replace egrep by /usr/bin/egrep); I just find it annoying not to understand why things don't work as I thought they should.
enas
On Jun 3, 2009, at 11:42 PM, Allan Odgaard wrote:
On 3 Jun 2009, at 22:07, Juho Makkonen wrote:
[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.
Where is this code, in which bundle?
On 4 Jun 2009, at 21:39, Scott Haneda wrote:
On Jun 3, 2009, at 11:42 PM, Allan Odgaard wrote:
On 3 Jun 2009, at 22:07, Juho Makkonen wrote:
[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.
Where is this code, in which bundle?
This is in /etc/profile — a standard system file.
This seems to be a principle problem with TextMate. Maybe it should not start a new bash process for every command but keep one running in the background and reuse it!? To prevent interferences, there could also be one process per bundle.
Best regards Daniel
Am 24.06.2009 um 11:45 schrieb Allan Odgaard:
On 4 Jun 2009, at 21:39, Scott Haneda wrote:
On Jun 3, 2009, at 11:42 PM, Allan Odgaard wrote:
On 3 Jun 2009, at 22:07, Juho Makkonen wrote:
[...] if [ -x /usr/libexec/path_helper ]; then eval `/usr/libexec/path_helper -s` fi
With a long PATH this one can take a _loooong_ time to execute (I filed a performance bug against it), try disable/comment it.
Where is this code, in which bundle?
This is in /etc/profile — a standard system file.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate
On 9 Jul 2009, at 17:56, Daniel Sadilek wrote:
This seems to be a principle problem with TextMate. Maybe it should not start a new bash process for every command but keep one running in the background and reuse it!? To prevent interferences, there could also be one process per bundle.
We setup stdin/out and the environment before we launch the interpreter (which is different for each invocation), and we use the return code from the interpreter, changing to a long-living interpreter would be rather problematic/challenging (and one command could easily pollute the environment).
This is clearly an OS problem that can easily be addressed either by the user or Apple.
-
Alex Ross -
Allan Odgaard -
Daniel Sadilek -
enas -
Juho Makkonen -
Martin Kühl -
Scott Haneda