On Apr 9, 2009, at 12:01 PM, Mathieu Godart wrote:

Le 9 avr. 09 à 19:36, siemsen@ucar.edu a écrit :

...

I have two Macs running TextMate 1.5.8. I have some personal bundles that I want to keep in sync between the two machines. I tried this:

On machine A, modify a bundle and quit the Bundle Editor to save the bundle.

Have you tried to quit TM, here?

Yes, it doesn't make a difference.

...

On machine A, reopen the Bundle Editor and drag the bundle to my Desktop. On machine A, scp -r the bundle directory from my Desktop to machine B, into my Desktop. On machine B, double-click the bundle. TextMate says "do you want to update?". On machine B, I click "yes". It seems to work.

Yet the bundle on machine B doesn't have the changes that I made while I was on machine A.

Any suggestions appreciated. Note that I have MobileMe, and would love to cut down on the manual work that the above (unsuccessful) approach requires.

Why don't you do the scp from the ~/Library/Application\ Support/ TextMate/Bundles/YourBundle.tm to the other machine and ask TM to update the bundles? You could even create a TM command for that. ;-)

I thought about that, and it certainly makes better sense, but my bundle doesn't show up in that directory, on either machine. I don't understand why. The bundle appears in the Bundle Editor, along with the standard bundles. It shows up in ~/Library/Application\ Support/ TextMate/Pristine\ Copy/Bundle, but I'm fairly sure that's an old copy - the modification date isn't "today", and when I look inside the Syntaxes/<bundlename>.tmLanguage file, it doesn't show the changes that I made today.

I don't know where TextMate is storing the bundle, yet I can modify it and use it in TextMate.

-- Pete

Hello,

I'm growing increasingly annoyed with an issue I could not find a solution for: the output to stderr and stdout getting out of sync in the default TextMate output window.

I am currently developping for Perl, but I quickly checked that the issue is there for Ruby as well.

If you run this little Perl program:

print "line 1\n"; warn "line 2\n"; print "line 3\n"; warn "line 4\n"; print "line 5\n";

You get this output:

line 2 line 4 line 1 line 3 line 5

This is the wrong behaviour because STDOUT is supposed to be line- buffered ("hot" in Perl lingo) when going to a terminal. So OK, the TM output Window is incorrectly *not* considered as a terminal. This should be fixable by any of the following three standard idioms:

# fix 1 my $previous = select STDOUT; $|=1; select $previous;

# fix 2 binmode(STDOUT, ":unix");

# fix 3 STDOUT->autoflush(1);

But none of them work.

This Ruby program exhibits the same problem:

$stdout.puts "line 1\n"; $stderr.puts "line 2\n" $stdout.puts "line 3\n"; $stderr.puts "line 4\n" $stdout.puts "line 5\n";

Has anybody been able to find a solution for this? This is a PITA.

Many thanks.

Jean-Denis

Of course, no need to suggest to flush STDOUT each time by wrapping the write command?

Mathieu

Le 10 avr. 09 à 10:01, Chris Rebert a écrit :

On Fri, Apr 10, 2009 at 12:43 AM, Jean-Denis Muys jdmuys@free.fr wrote:

...

Hello,

I'm growing increasingly annoyed with an issue I could not find a solution for: the output to stderr and stdout getting out of sync in the default TextMate output window.

I am currently developping for Perl, but I quickly checked that the issue is there for Ruby as well.

Apparently Python too:

#program: from sys import stderr as e, stdout as o e.write("debug1\n") o.write("hi\n") e.write("bug2\n") o.write("bye\n") e.write("buggy3\n")

#textmate output window: hi bye debug1 bug2 buggy3

Cheers, Chris

-- I have a blog: http://blog.rebertia.com

---

textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate

On Fri, Apr 10, 2009 at 12:33 PM, Jenny Berry yolospat@gmail.com wrote:

Same goes for Ruby

Python, Perl, Ruby, all use TextMate::Executor to handle cmd-R. It appears to batch the stdout and stderr, instead of properly interleaving them as they are produced.

I think TextMate::Executor is Alex Ross's baby.

j.

On Apr 13, 2009, at 6:23 PM, Alex Ross wrote:

On Apr 13, 2009, at 7:10 AM, Jay Soffian wrote:

...

Python, Perl, Ruby, all use TextMate::Executor to handle cmd-R. It appears to batch the stdout and stderr, instead of properly interleaving them as they are produced.

I think TextMate::Executor is Alex Ross's baby.

The only way to get proper line-buffering from these is to run them attached to a TTY. I tried “faking” it, but it's not really possible unless somebody writes a dylib that we inject into the process to force line buffering. I don't really know how to do that, so it never got done…

—alex

*** workaround for this problem below ***

It's true that by default, stdout is fully buffered unless attached to a TTY. However, it is usually possible to change its buffering mode from whatever language you are using. For example, from Perl, there are (at least) 3 different idioms to do that:

# idiom 1 my $previous = select STDOUT; $|=1; select $previous;

# idiom 2 binmode(STDOUT, ":unix");

# idiom 3 STDOUT->autoflush(1);

However, non of those work within TextMate.

I don't mind the default buffering to be fully buffered.

I do mind however, not being able to change the buffering mode.

For example, save and run the following perl program in the terminal, and in TM to see the difference:

# ------------ snip ------------- warn "\ndefault buffering\n"; print "stdout line 1\n"; warn "stderr line 2\n"; print "stdout line 3\n"; warn "stderr line 4\n"; print "stdout line 5\n";

my $previous = select STDOUT; $|=1; select $previous;

warn "\nline buffering\n"; print "stdout line 6\n"; warn "stderr line 7\n"; print "stdout line 8\n"; warn "stderr line 9\n"; print "stdout line 10\n"; # ------------ snip -------------

Note: executing the above program in the terminal with the usual command will have stdout and stderr attached to a TTY:

perl bufferingTest.pl

To execute it with stdout and stderr NOT attached to a TTY, one way is to pipe both output streams to the cat command:

perl bufferingTest.pl 2>&1 | cat

This gave me the following idea for a workaround for this problem: copy the line above into another file, called bufferingTest.sh (a shell "program"), and instead of running the original Perl program, run the .sh file.

This workaround works as expected, with only one minor issue: the output to stderr is not printed in red any more. Maybe someone can imagine a more subtle way to go?

One possible acceptable behaviour for me would be to have stderr and stdout printed in *different* windows. Would that be possible?

best regards,

JD

Just a quick question: when using the Dropbox, you can modify the bundle only from one machine, right?

Mathieu

Le 10 avr. 09 à 01:16, Scott Haneda a écrit :

Agreed. I posted a question here a few weeks back, and did not get any bites to it, so I just went with it. I looked at the bundles and found there were no resource forks, so I symblinked it all up with Dropbox.

I have full syn now, with backup and the ability to restore and do everything else Dropbox does. It's also nice it is free. I take it a step further, and sync prefs to a lot of other apps as well.

I can not recommend Dropbox enough. I wish it were a little faster at the upload, but it works.

On Apr 9, 2009, at 1:28 PM, Daniel Stockman wrote:

...

This becomes quite a bit easier when you use symbolic links combined with a WebDAV-like resource (Dropbox, MobileMe's iDisk). Updating the bundles is then simply a process of navigating to the "Bundles > Bundle Editor > Reload Bundles" menu item in TM (with the WebDAV-like resource set to automatically sync, of course).

-- Scott * If you contact me off list replace talklists@ with scott@ *

---

textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate

On 2009-Apr-10, at 5:24 AM, Mathieu Godart wrote:

Just a quick question: when using the Dropbox, you can modify the bundle only from one machine, right?

I haven't used it, but based on what I see in the demos, it should be safe to modify bundles from anywhere. You might not want to do it with TextMate running in multiple locations, but you probably can.

If something is modified from two places and there's a conflict, I think drop-box lets you know by changing the file's icon. So, if you're going to manage bundles willy nilly from all over the place, you might want to periodically look at the folder in DropBox to make sure there are no conflicts.