[txmt-dev] Re: Yosemite breaks some bundles
On 21 Oct 2014, at 1:30, phuibonhoa wrote: A lot of my normal workflows are broken in Yosemite. Ensure you do not have old versions of the bundles eclipsing the updated ones: https://github.com/textmate/textmate/wiki/Reverting-To-Defaults If you have done that then please be specific about what things does not work for you: https://github.com/textmate/textmate/wiki/Writing-Bug-Reports ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
Is there an update to this now that Yosemite is officially out? A lot of my normal workflows are broken in Yosemite. -- View this message in context: http://textmate.1073791.n5.nabble.com/txmt-dev-Yosemite-breaks-some-bundles-tp27935p28421.html Sent from the textmate-dev mailing list archive at Nabble.com. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
Well, as workaround TextMate can either: (1) be bundled with its own Ruby 1.8 framework, about 1.8MB, so not s big (2) migrate to 2.0, then offer installation of Ruby 2.0 on older (supported) platforms (3) migrate to 2.0 and cut anything below 10.9 WDYT? -- Adam ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
On 17 Jun 2014, at 18:08, Attila Györffy wrote: Having said that, I’d like to know what’s stopping us from using that Ruby interpreter (let it be 1.8 or 2.0 or anything further) in Bundles? […] There is probably a lot of string/character handling in bundle commands, which is one of the main major changes from 1.8 → 1.9/2.0. For example 1.8 represent characters as integers, e.g. ?A and "a"[0] both evaluate to 65. In ruby 2.0 those two things evaluate to "a" (a string). There is no jcode/jlength in 2.0 but the native string’s length method return number of code point. There are a few other minor things, for example fork/exec will close file descriptors by default in 2.0 but not 1.8, and the “opt out” argument is 2.0 only. But I’ll welcome patches that can make the code run on both versions of ruby. It’s just easier (for me) with the suggested migration plan (which includes bundling ruby for users which only have one version on their system), and it should minimize the chance of anything breaking. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
Thanks for the reply Allan. I think you are right and the ‘Current’ symlink is indeed there on previous versions of Mac OS X. (Just checked it on Lion). Having said that, I’d like to know what’s stopping us from using that Ruby interpreter (let it be 1.8 or 2.0 or anything further) in Bundles? I’m a little bit unsure about the benefits of bundling an old and retired version of Ruby (EOL last year) with TextMate itself in case we can write the bundles in such ways that they will work on both interpreters. Assuming that the migration work to update the code to work on 2.0 (as well as 1.8) is relatively seamless, what’s stopping us from relying on the Bundled system Ruby? Cheers, — Attila -- Attila Györffy Sent with Airmail From: Allan Odgaard mailingl...@textmate.org Reply: TextMate developers textmate-dev@lists.macromates.com Date: 14 Jun 2014 at 13:13:25 To: TextMate developers textmate-dev@lists.macromates.com Subject: [txmt-dev] Re: Yosemite breaks some bundles On 4 Jun 2014, at 23:18, Attila Györffy wrote: Sorry about the late reply. I know this is a little bit early to start talking about the new OS X but I’m an early adopter and try to fix issues that arise prior to the final release so the time most people upgrade, tools that mean a lot to me (like TextMate itself) can be used without having to worry a lot. Appreciated — Not yet on 10.10 myself. […] 1.8 is gone and has been replaced with a ‘Current’ symlink that (as of writing) points to version 2.0 (I guess this could be Apple’s move to support new default Rubies later on in a consistent manner.) I believe the Current symlink has always existed. So we have these options: Include our own ruby 1.8 (for 10.10 users) and update all shebangs to find that. Include our own ruby 2.0 (for 10.7 & 10.8) and update all shebangs plus code to run on 2.0. Use Current and ensure all code works on both 1.8 and 2.0. For a quick fix I am leaning toward option #1. Long-term we should do #2. I think option #3 is a little painful and will require testing against RUBY_VERSION for some code. Allan, how can I start working on this? Step One We need to create a new bundle and package ruby 1.8 into that bundle’s Support folder. The binary should be named ruby18 (or similiar distinctive name). The bundle should then include a setting that sets PATH to $PATH:$TM_BUNDLE_SUPPORT/ruby18/bin. All ruby shebangs then need to be updated to use #!/usr/bin/env ruby18. Step Two Add ruby 2.0 to the same bundle and to the PATH as well. Step Three Update ruby code in the bundle-support bundle to work on both 1.8 and 2.0. This will be required unless we migrate all commands at once. Step Four Update other ruby code to work on 2.0 and update the shebang to #!/usr/bin/env ruby20. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
On 14 Jun 2014, at 13:32, Stefan Daschek wrote: So we have these options: […] Would this also solve the problems with bundles that require specific gems to be installed? I.e. would those gems then be installed “locally” for TextMate’s Ruby only, without affecting the system-wide gems? That would indeed be a very cool side-effect of this change :) Not per se. I think this would be a bundle-by-bundle policy. I.e. if the bundle requires a gem because of its own code, then that gem should be included in the bundle, e.g. we include a plist ruby extension and a mysql driver. If the bundle requires the gem because the bundle is basically about the gem, then it makes more sense to have the bundle use the user’s gem (and possibly ruby), for example the Ruby bundle itself uses the user’s ruby for running and validating code. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
So we have these options: 1. Include our own ruby 1.8 (for 10.10 users) and update all shebangs to find that. 2. Include our own ruby 2.0 (for 10.7 & 10.8) and update all shebangs plus code to run on 2.0. 3. Use |Current| and ensure all code works on both 1.8 and 2.0. Would this also solve the problems with bundles that require specific gems to be installed? I.e. would those gems then be installed “locally” for TextMate’s Ruby only, without affecting the system-wide gems? That would indeed be a very cool side-effect of this change :) Stefan. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
[txmt-dev] Re: Yosemite breaks some bundles
On 4 Jun 2014, at 23:18, Attila Györffy wrote: Sorry about the late reply. I know this is a little bit early to start talking about the new OS X but I’m an early adopter and try to fix issues that arise prior to the final release so the time most people upgrade, tools that mean a lot to me (like TextMate itself) can be used without having to worry a lot. Appreciated — Not yet on 10.10 myself. […] 1.8 is gone and has been replaced with a ‘Current’ symlink that (as of writing) points to version 2.0 (I guess this could be Apple’s move to support new default Rubies later on in a consistent manner.) I believe the `Current` symlink has always existed. So we have these options: 1. Include our own ruby 1.8 (for 10.10 users) and update all shebangs to find that. 2. Include our own ruby 2.0 (for 10.7 & 10.8) and update all shebangs plus code to run on 2.0. 3. Use `Current` and ensure all code works on both 1.8 and 2.0. For a quick fix I am leaning toward option #1. Long-term we should do #2. I think option #3 is a little painful and will require testing against `RUBY_VERSION` for some code. Allan, how can I start working on this? # Step One We need to create a new bundle and package ruby 1.8 into that bundle’s Support folder. The binary should be named `ruby18` (or similiar distinctive name). The bundle should then include a setting that sets `PATH` to `$PATH:$TM_BUNDLE_SUPPORT/ruby18/bin`. All ruby shebangs then need to be updated to use `#!/usr/bin/env ruby18`. # Step Two Add ruby 2.0 to the same bundle and to the `PATH` as well. # Step Three Update ruby code in the bundle-support bundle to work on both 1.8 and 2.0. This will be required unless we migrate all commands at once. # Step Four Update other ruby code to work on 2.0 and update the shebang to `#!/usr/bin/env ruby20`. ___ textmate-dev mailing list textmate-dev@lists.macromates.com http://lists.macromates.com/listinfo/textmate-dev
