I am running 2.0-alpha.9507 on OS X 10.9.1.
I first noticed this problem in the rails bundle whenever it requests to create a new file.
I can recreate the issue with the following code:
require '/Users/curt/Library/Application Support/TextMate/Managed/Bundles/Bundle Support.tmbundle/Support/shared/lib/ui.rb'
TextMate::UI.request_confirmation( :button1 => "Create", :button2 => "Cancel", :title => "Missing foo.rb", :prompt => "Create missing foo.rb?" )
Pressing Cmd-R results in: ArgumentError: An object in the argument tree could not be converted
Here is the stack trace: /Users/curt/Library/Application Support/TextMate/Managed/Bundles/Bundle Support.tmbundle/Support/shared/lib/ui.rb:54:in `to_plist': An object in the argument tree could not be converted (ArgumentError) from /Users/curt/Library/Application Support/TextMate/Managed/Bundles/Bundle Support.tmbundle/Support/shared/lib/ui.rb:54:in `alert' from /Users/curt/Library/Application Support/TextMate/Managed/Bundles/Bundle Support.tmbundle/Support/shared/lib/ui.rb:277:in `request_confirmation'
It is runing ruby version: 2.0.0-p247
Is this a known problem. Or perhaps a problem using Ruby 2.0?
On 8 Feb 2014, at 0:13, Curt Sellmer wrote:
[…] TextMate::UI.request_confirmation […] ArgumentError: An object in the argument tree could not be converted […] It is runing ruby version: 2.0.0-p247
Is this a known problem. Or perhaps a problem using Ruby 2.0?
It is a problem with ruby 2.0 and the (binary) plist extension we use. Since the extension is built with the ruby SDK (so to speak) I don’t think it can really be made to work with arbitrary versions of ruby (that have SDK incompatibilities).
Though I see there now is a property list reader in 100% ruby: https://github.com/ckruse/CFPropertyList
We could switch to that, though some of the library code would likely also need updating.
[…] go_to_alternate_file.rb […] The first line of the this file is #!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby […] Am I missing something?
The commands which call this script do so by using "${TM_RUBY:-ruby}" (effectively ignoring the script’s shebang).
The reason they do that is (as I understand it) intentional, as the Rails bundle may load stuff from the user’s project (for member file queries etc.), and therefor should use the version of ruby that the user normally uses.
Unfortunately this means that all code referenced by the Rails bundle must be compatible with all versions of ruby.
I’m not sure what to do about this… we can start by trying out the source version of the plist loader and take it from there.
On Feb 8, 2014, at 2:28 AM, Allan Odgaard mailinglist@textmate.org wrote:
[…] go_to_alternate_file.rb […] The first line of the this file is #!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby […] Am I missing something?
The commands which call this script do so by using "${TM_RUBY:-ruby}" (effectively ignoring the script’s shebang).
The reason they do that is (as I understand it) intentional, as the Rails bundle may load stuff from the user’s project (for member file queries etc.), and therefor should use the version of ruby that the user normally uses.
I’ve just deployed a change where we now use Ruby 1.8 for all bundle commands that don’t load rails itself. This should solve many of the issues. The commands that do load rails still use TM_RUBY so there are still the problems described by Allan there.
Thanks for the quick response. The new version works beautifully.
On Sat, Feb 8, 2014 at 3:47 AM, Michael Sheets mummer@whitefalls.orgwrote:
On Feb 8, 2014, at 2:28 AM, Allan Odgaard mailinglist@textmate.org wrote:
[…] go_to_alternate_file.rb […] The first line of the this file is #!/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby […] Am I missing something?
The commands which call this script do so by using "${TM_RUBY:-ruby}"
(effectively ignoring the script’s shebang).
The reason they do that is (as I understand it) intentional, as the
Rails bundle may load stuff from the user’s project (for member file queries etc.), and therefor should use the version of ruby that the user normally uses.
I’ve just deployed a change where we now use Ruby 1.8 for all bundle commands that don’t load rails itself. This should solve many of the issues. The commands that do load rails still use TM_RUBY so there are still the problems described by Allan there.
textmate mailing list textmate@lists.macromates.com http://lists.macromates.com/listinfo/textmate