August 2010 - MacRuby-devel - lists.macosforge.org

[MacRuby] #742: Encoding is always UTF-8 (?)
by MacRuby 03 Aug '10

03 Aug '10

#742: Encoding is always UTF-8 (?) ----------------------------------+----------------------------------------- Reporter: watson1978@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: ----------------------------------+----------------------------------------- Test code: {{{ $ cat a.rb # coding: us-ascii p __ENCODING__ #=> #<Encoding:US-ASCII> p "abc".encoding #=> #<Encoding:US-ASCII> p "\x80".encoding #=> #<Encoding:ASCII-8BIT> }}} Result on Ruby 1.9.2 preview3: {{{ $ ruby -v a.rb ruby 1.9.2dev (2010-05-31 revision 28117) [x86_64-darwin10.3.0] #<Encoding:US-ASCII> #<Encoding:US-ASCII> #<Encoding:ASCII-8BIT> }}} Result on MacRuby: {{{ $ macruby a.rb #<Encoding:US-ASCII> #<Encoding:UTF-8> #<Encoding:UTF-8> }}} When script encoding is "us-ascii", I think that literal encoding should return "ASCII-8BIT". -- Ticket URL: <http://www.macruby.org/trac/ticket/742> MacRuby <http://macruby.org/>

1 1

[MacRuby] #788: "rake clean" should ensure no cruft in MacRuby.framework search path
by MacRuby 03 Aug '10

03 Aug '10

#788: "rake clean" should ensure no cruft in MacRuby.framework search path ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- Because of the way the MacRuby search path is setup up, it appears possible for older/crufty versions of some libraries to end up hiding newer versions, even after a "rake clean" has been one. $ find /Library/Frameworks/MacRuby.framework -name "*ripper*" /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/site_ruby/1.9.0/ripper /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/site_ruby/1.9.0/ripper.rb /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/site_ruby/1.9.0 /universal-darwin10.0/ripper.bundle /Library/Frameworks/MacRuby.framework/Versions/0.5/usr/lib/ruby/site_ruby/1.9.0 /universal-darwin11.0/ripper.bundle /Library/Frameworks/MacRuby.framework/Versions/0.6/usr/lib/ruby/site_ruby/1.9.0/ripper /Library/Frameworks/MacRuby.framework/Versions/0.6/usr/lib/ruby/site_ruby/1.9.0/ripper.rb /Library/Frameworks/MacRuby.framework/Versions/0.6/usr/lib/ruby/site_ruby/1.9.0 /universal-darwin10.0/ripper.bundle /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/site_ruby/1.9.2/ripper /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/site_ruby/1.9.2/ripper.rb /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/site_ruby/1.9.2/ripper.rbo /Library/Frameworks/MacRuby.framework/Versions/0.7/usr/lib/ruby/site_ruby/1.9.2 /universal-darwin10.0/ripper.bundle -- Ticket URL: <http://www.macruby.org/trac/ticket/788> MacRuby <http://macruby.org/>

1 1

[MacRuby] #795: GCD inconsistently copies local variables inside blocks
by MacRuby 03 Aug '10

03 Aug '10

#795: GCD inconsistently copies local variables inside blocks ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- The expectation is that Ruby blocks will have their local variables copied before being passed to GCD, to avoid errors from accessing them after they are destroyed. However, that does not seem to always happen. For example: $ macruby -e 'i=0; Dispatch::Queue.new("i").sync {i = 42}; puts i' returns '0' as expected. However, this does not: $ macirb irb(main):001:0> i=0; Dispatch::Queue.new("i").sync {i = 42}; puts i 42 => nil It appears to be copied properly in the block_spec.rb test: it "should create const copies of dynamic (local) variables" do i = 42 @q.sync {i = 1} i.should == 42 end But not in the README.rdoc for the dispatch module (aka dispatch_methods.rb sample): n = 0 job = Dispatch::Job.new { n = 21 } job.join puts "n (after): #{n} => 0?!?" # [returns 21, not 0] Any suggestions? -- Ticket URL: <http://www.macruby.org/trac/ticket/795> MacRuby <http://macruby.org/>

3 6

[MacRuby] #814: SegFault running CGI script from command line
by MacRuby 03 Aug '10

03 Aug '10

#814: SegFault running CGI script from command line -------------------------------+-------------------------------------------- Reporter: pwilson@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.7 Component: MacRuby | Keywords: -------------------------------+-------------------------------------------- With latest MacRuby nightly (July 27), the following code causes a seg fault if run directly from the command line: {{{ require 'cgi' c = CGI.new }}} It works OK when run through the web server. When ruby 1.9 runs this from the command line it asks for data from stdin to serve as query parameters. Under MacRuby I get this crash: {{{ (offline mode: enter name=value pairs on standard input) Segmentation fault }}} and this stack trace: {{{ Program received signal EXC_BAD_ACCESS, Could not access memory. Reason: 13 at address: 0x0000000000000000 0x000000010005818a in rb_f_open () (gdb) bt #0 0x000000010005818a in rb_f_open () #1 0x000000010005b7cd in rb_io_gets () #2 0x0000000100140a39 in rb_vm_dispatch () #3 0x0000000102f004d0 in ?? () #4 0x0000000102f0c32c in ?? () #5 0x0000000100140996 in rb_vm_dispatch () #6 0x0000000102f004d0 in ?? () #7 0x0000000102f0d319 in ?? () #8 0x0000000100140996 in rb_vm_dispatch () #9 0x0000000102f004d0 in ?? () #10 0x0000000102f0e43f in ?? () #11 0x000000010014097b in rb_vm_dispatch () #12 0x000000010006e342 in rb_class_new_instance_imp () #13 0x0000000100140a39 in rb_vm_dispatch () #14 0x0000000102f004d0 in ?? () #15 0x0000000102f000bd in ?? () #16 0x000000010014d708 in rb_vm_run () #17 0x000000010003fef0 in ruby_run_node () #18 0x0000000100000d28 in main () }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/814> MacRuby <http://macruby.org/>

1 5

[MacRuby] #820: raising alternative Exception object in rescue block does not work.
by MacRuby 02 Aug '10

02 Aug '10

#820: raising alternative Exception object in rescue block does not work. --------------------------------+------------------------------------------- Reporter: chekenan@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.6 Component: MacRuby | Keywords: --------------------------------+------------------------------------------- When raise an Exception object in rescue block, the rescued object is raised. {{{ def mm raise RuntimeError, "original" end def m begin mm rescue RuntimeError puts "reached here" raise TypeError, "re-raise" end end m }}} Executed in both 1.9.2-rc2 and macruby-0.6, {{{ $ rvm 1.9.2,macruby test.rb info: 1.9.2 (ruby-1.9.2-rc2): ruby 1.9.2dev (2010-07-11 revision 28618) [x86_64-darwin10.4.0] does catched. a.rb:10:in `rescue in m': re-raise (TypeError) from a.rb:6:in `m' from a.rb:14:in `<main>' info: macruby (macruby-0.6): MacRuby version 0.6 (ruby 1.9.0) [universal- darwin10.0, x86_64] does catched. /Users/dche/Desktop/a.rb:2:in `mm': original (RuntimeError) from /Users/dche/Desktop/a.rb:7:in `m' from /Users/dche/Desktop/a.rb:14:in `<main>' }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/820> MacRuby <http://macruby.org/>

1 2

MacRuby on Leopard (10.5)
by Michal 02 Aug '10

02 Aug '10

Hi guys, as I mentioned in my last email I've just started development of the new Mac OS X app and I'd love to use MacRuby(0.6) instead of objective-c. We must support Leopard (10.5) users, so my question is: Will my app run without any problems on macs with Mac OS X 10.5-Leopard(Intel)?? I plan to embed MacRuby within an application package so users can just double-click to run. Thanks in advance for answer. Cheers, Michal

2 1

HotCocoa app doesn't run on Macs without installation of macruby
by Michal 01 Aug '10

01 Aug '10

Hi guys, I've just started development of the new Mac OS X app and I'd like to use MacRuby + HotCocoa. I want the app to run on computers which do not have MacRuby installed so I need to embed MacRuby into app package. If I do not use HotCocoa and I build app using Xcode it works great and users without installed MacRuby can run the app. However if I create new app using hotcocoa <appname> and then I do macrake deploy users without installed MacRuby cannot run the app - it's crashing. I reopened issue http://www.macruby.org/trac/ticket/281because it looks like it's related. Anyhone encountered this problem? Any solutions, please? Thank you and have a great day! Michal

1 0

[MacRuby] #281: Bundles pointing to local MacRuby installation instead of embedded
by MacRuby 01 Aug '10

01 Aug '10

#281: Bundles pointing to local MacRuby installation instead of embedded -------------------------------+-------------------------------------------- Reporter: reborg@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: embedded,deploy,installation,distribution -------------------------------+-------------------------------------------- After embedding the MacRuby framework with 'macrake deploy' is not possible to distribute the application to computers without MacRuby installed if the application uses native bundles. Try this: - hotcocoa test; cd test - macrake deploy - otool -L Test.app/Contents/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /universal-darwin9.5/stringio.bundle The last command gives an absolute reference to libmacruby.dylib: Test.app/Contents/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /universal-darwin9.5/stringio.bundle: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/libmacruby.dylib (compatibility version 0.4.0, current version 0.4.0) /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.3) Another test: - open lib/application.rb and require 'stringio' at the top - save and close, macrake clean; macrake deploy - move the MacRuby installation dir in /Library/Frameworks to another name - run the app This is the output from the console: 6/7/09 5:08:47 PM [0x0-0xdb8db8].com.yourcompany.Test[54737] /Users/reborg/tmp/test/Test.app/Contents/Resources/lib/application.rb:1:in `require': dlopen(/Users/reborg/tmp/test/Test.app/Contents/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /universal-darwin9.5/stringio.bundle, 9): Library not loaded: /Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/libmacruby.dylib (LoadError) 6/7/09 5:08:47 PM [0x0-0xdb8db8].com.yourcompany.Test[54737] Referenced from: /Users/reborg/tmp/test/Test.app/Contents/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /universal-darwin9.5/stringio.bundle 6/7/09 5:08:47 PM [0x0-0xdb8db8].com.yourcompany.Test[54737] Reason: image not found - /Users/reborg/tmp/test/Test.app/Contents/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.1 /universal-darwin9.5/stringio.bundle 6/7/09 5:08:47 PM [0x0-0xdb8db8].com.yourcompany.Test[54737] from /Users/reborg/tmp/test/Test.app/Contents/Resources/lib/application.rb:1:in `<top (required)>' 6/7/09 5:08:47 PM [0x0-0xdb8db8].com.yourcompany.Test[54737] from /Users/reborg/tmp/test/Test.app/Contents/Resources/rb_main.rb:3:in `load' -- Ticket URL: <http://www.macruby.org/trac/ticket/281> MacRuby <http://macruby.org/>

1 6

[MacRuby] #817: External iterators returning nil
by MacRuby 01 Aug '10

01 Aug '10

#817: External iterators returning nil -----------------------------------+---------------------------------------- Reporter: kennylovrin@… | Owner: lsansonetti@… Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby | Keywords: -----------------------------------+---------------------------------------- Trying to use the "next" method of an external iterator showed the following problem: iMac:~ kenny$ macruby -v MacRuby 0.7 (ruby 1.9.2) [universal-darwin10.0, x86_64] iMac:~ kenny$ macirb irb(main):001:0> i = ["one", "two"].each => #<Enumerator:0x2000faa60> irb(main):002:0> i.next => nil irb(main):003:0> i.next => nil irb(main):004:0> iMac:~ kenny$ ruby -v ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0] iMac:~ kenny$ irb >> i = ["one", "two"].each => #<Enumerable::Enumerator:0x101270900> >> i.next => "one" >> i.next => "two" >> As I understand, this is a defect as I haven't found any indications that it shouldn't work? -- Ticket URL: <http://www.macruby.org/trac/ticket/817> MacRuby <http://macruby.org/>

1 1