December 2009 - MacRuby-devel - lists.macosforge.org

[MacRuby] #467: macrubyc generate binary that does not work using File.dirname
by MacRuby 09 Dec '09

09 Dec '09

#467: macrubyc generate binary that does not work using File.dirname -------------------------------------+-------------------------------------- Reporter: jordan.breeding@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- During the investigation for #424 I decide to try compiling my main script using macrubyc, unfortunately it didn't work at all. I narrowed the initial failure to compiler (since I don't know if there will be other problems later) to: {{{ #!/usr/bin/env macruby $:.unshift(File.dirname($0)) }}} It results in this error: {{{ 154 jordan@thetourist ~/Tests/priority_queue_bug > ./test core:in `dirname:': can't convert false into String (TypeError) }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/467> MacRuby <http://macruby.org/>

1 1

[MacRuby] #368: AOT compilation failing on this example
by MacRuby 09 Dec '09

09 Dec '09

#368: AOT compilation failing on this example -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- -- Ticket URL: <http://www.macruby.org/trac/ticket/368> MacRuby <http://macruby.org/>

1 2

[MacRuby] #481: macrubyc doesn't let you use ruby's stdlibs
by MacRuby 09 Dec '09

09 Dec '09

#481: macrubyc doesn't let you use ruby's stdlibs -------------------------------------+-------------------------------------- Reporter: mattaimonetti@… | Owner: lsansonetti@… Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: -------------------------------------+-------------------------------------- {{{ macrubyc search_to_pdf.rb -o converter --arch i386 --arch x86_64 $ ./converter no such file to load -- net/http (LoadError) }}} I tried using --static without better results. -- Ticket URL: <http://www.macruby.org/trac/ticket/481> MacRuby <http://macruby.org/>

1 2

Has the team given up on continuous integration?
by Giampiero De Ciantis 09 Dec '09

09 Dec '09

rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to the suite of specs? Lost cause? Cheers, -Gp

4 7

[MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style
by MacRuby 08 Dec '09

08 Dec '09

#476: GCD Groups should be a wrapper around dispatch, not its own invocation style ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: gcd ----------------------------------------+----------------------------------- Right now, GCD Groups are treated almost like a Queue, so developers call dispatch on them -- except that: - you need to specify a queue as a parameter -- or use (atypically) have it invisibly invoke the default queue - there's no way to specify synchronous dispatch This works well if you really just want async concurrency, but becomes awkward (and IMHO confusing) for anything else. g = Dispatch::Group.new g.dispatch {work_function(i)}} g.dispatch(q_a) {work_function(i)}} g.dispatch(q_b, false) {work_function(i)}} g.wait I don't know if it is possible, but what I'd prefer is for Groups to take a block *containing* multiple dispatch invocations, and auto-magically associate them with a group. So for example, you could do: g = Dispatch::Group.new g.wait do q_a.dispatch(true) {work_function(i)} q_b.dispatch(false) {work_function(i)} end In this case, the "group" is synchronous so it automatically does a wait until the "child" dispatches complete. For async behavior, simply do: g.on_completion { puts "I'm all done" } g.notify do q_a.dispatch {work_function(i)} q_b.dispatch {work_function(i)} end If you want to add some invocations to the group but neither wait or notify yet, use a "shovel" to add them: g << { q_c.dispatch {work_function(i)} } As a bonus, one could provide a convenience class method for the synchronous case that avoids the need for any variable at all: Dispatch::Group.wait do q_a.dispatch(true) {work_function(i)} q_b.dispatch(false) {work_function(i)} end While this does require you to be more explicit in the concurrency async case, I think this API better reflects the full semantics of GCD groups. Of course, this presumes that queue dispatches would need to check if they're executing inside a group; I'm sure that must be possible, but I don't know what the performance implications might be. Still, I wanted to raise it now before 0.5 is final and people start relying on the current API. -- Ticket URL: <http://www.macruby.org/trac/ticket/476> MacRuby <http://macruby.org/>

1 10

[MacRuby] #482: Dispatch::Queue#dispatch should take a hash instead of a bool
by MacRuby 08 Dec '09

08 Dec '09

#482: Dispatch::Queue#dispatch should take a hash instead of a bool ----------------------------------------+----------------------------------- Reporter: ernest.prabhakar@… | Owner: lsansonetti@… Type: enhancement | Status: new Priority: blocker | Milestone: MacRuby 0.5 Component: MacRuby | Keywords: ----------------------------------------+----------------------------------- I like the way MacRuby unifies GCD's 'sync' and 'async' call into a single "dispatch" method. However, I always need to remind myself which way is 'true' and which is 'false'. In addition, it may create ordering issues when we add other parameters. I think it would be better if dispatch just took an explicit hash; then we could say: q.dispatch(sync:true) which is much easier to figure out. This would also simplify groups: q.dispatch(sync:true, group: g) -- Ticket URL: <http://www.macruby.org/trac/ticket/482> MacRuby <http://macruby.org/>

1 2

mac & ruby question
by Tim Rand 08 Dec '09

08 Dec '09

Hi Conrad, You are totally right--if I make 1.8.7 the default ruby version I can install and run rsruby gem without a hitch. Same install on 1.9.1 doesn't work. I investigated and as suspected the 1.8.7 gem install provides both the i386 binary and the x86_64 binary files while the 1.9.1 gem install only creates the x86_64 binary (see below). I'm still puzzled by what is influencing which type of file is generated--it doesn't seem to listen to the command line as sudo ARCHFLAGS="-arch i386" gem install rsruby -- --with-R-dir=$R_HOME wouldn't force the i386 binary to be produced. Don't you think this behavior is weird? Is it the placement within the file system that makes the OS decide whether this or that type of binary should be generated? And how do I force 1.9.1 gem install to do what 1.8.7 gem install does? Tim:~/.gem/ruby/1.8/gems/rsruby-0.5.1.1/lib> ls rsruby rsruby.rb rsruby_c.bundle Tim:~/.gem/ruby/1.8/gems/rsruby-0.5.1.1/lib> file rsruby_c.bundle rsruby_c.bundle: Mach-O universal binary with 2 architectures rsruby_c.bundle (for architecture i386): Mach-O bundle i386 rsruby_c.bundle (for architecture x86_64): Mach-O 64-bit bundle x86_64 Tim:~/.gem/ruby/1.8/gems/rsruby-0.5.1.1/lib> gem19 which rsruby (checking gem rsruby-0.5.1.1 for rsruby) /usr/local/lib/ruby19/gems/1.9.1/gems/rsruby-0.5.1.1/lib/rsruby.rb Tim:~/.gem/ruby/1.8/gems/rsruby-0.5.1.1/lib> cd /usr/local/lib/ruby19/gems/1.9.1/gems/rsruby-0.5.1.1/lib Tim:/usr/local/lib/ruby19/gems/1.9.1/gems/rsruby-0.5.1.1/lib> ls rsruby rsruby.rb rsruby_c.bundle Tim:/usr/local/lib/ruby19/gems/1.9.1/gems/rsruby-0.5.1.1/lib> file rsruby_c.bundle rsruby_c.bundle: Mach-O 64-bit bundle x86_64 On Mon, Dec 7, 2009 at 7:00 AM, <macruby-devel-request(a)lists.macosforge.org>wrote: > Send MacRuby-devel mailing list submissions to > macruby-devel(a)lists.macosforge.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel > or, via email, send a message with subject or body 'help' to > macruby-devel-request(a)lists.macosforge.org > > You can reach the person managing the list at > macruby-devel-owner(a)lists.macosforge.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of MacRuby-devel digest..." > > > Today's Topics: > > 1. Re: mac & ruby question (Conrad Taylor) > 2. Re: UTF8 Strings [resolved] (s.ross) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sun, 6 Dec 2009 21:22:46 -0800 > From: Conrad Taylor <conradwt(a)gmail.com> > To: "MacRuby development discussions." > <macruby-devel(a)lists.macosforge.org> > Subject: Re: [MacRuby-devel] mac & ruby question > Message-ID: <4697C26B-EC61-4CDE-9EC4-9040C7F5CF95(a)gmail.com> > Content-Type: text/plain; charset="us-ascii"; Format="flowed"; > DelSp="yes" > > TIm, does gems install correctly with Ruby 1.8.7 which is the default > in Snow Leopard? This should be the case. Next, x86_64 is the > default under Snow Leopard and your bundles are being correctly. > Thus, I would recommend sticking with default compilation settings. > For example, the following is all you need: > > gem install hpricot > > Thus, I would recommend going through the process again of reinstalling. > > Good luck, > > -Conrad > > Sent from my iPhone > > On Dec 6, 2009, at 8:43 PM, Tim Rand <timrandg(a)gmail.com> wrote: > > > I am sorry. This is not a macruby question per se, just a question > > about plain old ruby on mac (specifically snow leopard) question. > > But you guys for sure will know the answer, so I must ask. Why is it > > that after upgrading to snow leopard (10.6.2) a long list of gems no > > longer run on ruby 1.9.1? > > > > Using Matt Aimonetti's sl_gems_update.rb file, I get: > > Please reinstall: > > eventmachine versions: 0.12.0, 0.12.0 > > fastthread versions: 1.0.1, 1.0.1 > > hpricot versions: 0.6.161, 0.6.161, 0.8.2, 0.8.2, 0.8.2, 0.8.2 > > hpricot-0.6.161/lib/universal versions: darwin9.0, darwin9.0 > > mongrel versions: 1.1.5, 1.1.5 > > rb-appscript versions: 0.5.1, 0.5.1 > > rmagick versions: 2.2.0, 2.2.0 > > rsruby versions: 0.4.5, 0.4.5 > > ruby-debug-base versions: 0.10.3, 0.10.3 > > sqlite3-ruby versions: 1.2.1, 1.2.1 > > tioga versions: 1.8, 1.8, 1.8, 1.8, 1.8, 1.8, 1.8, 1.8, 1.8, 1.8 > > tmail versions: 1.2.3.1, 1.2.3.1 > > > > Indeed, I had noticed already that hpricot, rsruby, and sqlite3 were > > no longer working. > > Reinstalling eventmachine and fastthread worked. > > But many of the others appear to install, but don't function: > > > > Tim:~/Desktop/RubyClub> sudo env ARCHFLAGS="-arch i386" gem install > > why-hpricot --source http://gems.github.com > > Building native extensions. This could take a while... > > Successfully installed why-hpricot-0.7.229 > > 1 gem installed > > Installing ri documentation for why-hpricot-0.7.229... > > Installing RDoc documentation for why-hpricot-0.7.229... > > Tim:~/Desktop/RubyClub> gem which hpricot > > (checking gem why-hpricot-0.7.229 for hpricot) > > /usr/local/lib/ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/ > > hpricot.rb > > Tim:~/Desktop/RubyClub> ruby -e 'require "hpricot"' > > /usr/local/lib/ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/ > > hpricot.rb:20:in `require': dlopen(/usr/local/lib/ruby19/gems/1.9.1/ > > gems/why-hpricot-0.7.229/lib/hpricot_scan.bundle, 9): no suitable > > image found. Did find: (LoadError) > > /usr/local/lib/ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/ > > hpricot_scan.bundle: mach-o, but wrong architecture - /usr/local/lib/ > > ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/hpricot_scan.bundle > > from /usr/local/lib/ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/ > > hpricot.rb:20:in `<top (required)>' > > from -e:1:in `require' > > from -e:1:in `<main>' > > > > And file on that path gives: > > file /usr/local/lib/ruby19/gems/1.9.1/gems/why-hpricot-0.7.229/lib/ > > hpricot_scan.bundle > > Mach-O 64-bit bundle x86_64 > > > > I am pretty sure that the problem is with .bundle files being > > compiled for x86_64 architecture, but I explicitly told the os to use > > env ARCHFLAGS="-arch i386" > > and it ignored it and put the bundle files in the x86_64 > > architecture anyhow. > > > > I am stuck. Why am I getting the mach-o but wrong architecture error? > > > > It seems to be a problem with gems that have .bundle files. > > If anyone can explain how I should be installing gems in snow > > leopard so that they actually work, I would really like that person. > > Seriously. > > Tim > > _______________________________________________ > > MacRuby-devel mailing list > > MacRuby-devel(a)lists.macosforge.org > > http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel >

1 0

Looking for info on MacRuby's JIT
by ravenex 08 Dec '09

08 Dec '09

Hi all, Greetings. New to this list, and to MacRuby. I was just skimming over the source code from trunk, but wasn't able to find a document that describes the current design of Roxor. I only found requirements, build instructions, coding styles and the like. The thing I find very confusing is that in vm.cpp, RoxorCore::RoxorCore(), there's a call to ee->DisableLazyCompilation(). This disables LLVM JIT's lazy compilation. Is it the case that Roxor compiles every method called by the toplevel script? Or how is Roxor feeding stuff into the JIT? It seems to me that in main.cpp, main() calls ruby_options(), where the whole source file gets parsed into MRI's Ruby AST. That AST is supposed to go into RoxorCompiler::compile_main_method(), and out comes LLVM IR. And then after optimizations passes, GETCORE()->compile() puts the JIT in action, turns LLVM IR into native code, and then invoke the IMP. I must have missed something...but if Roxor JIT compiles a method upon first invocation, where is this behavior implemented. Any pointers to documents, blog posts or mails would be truely appreciated. Thanks in advance, Raven

3 2

A path to linking rbo files into one executable in Xcode
by Dylan Bruzenak 07 Dec '09

07 Dec '09

Hi all, First, great work with the 0.5b2 release. I'm starting to use this for more serious development and it does most of the things I need very well. After a brief struggle last night I managed to get the code for one of my projects compiling using the new macruby_deploy method and it works like a charm. However, I would like to include the .rbo files in the same executable inside the .app bundle as my objc files, rather than as separate files in the resources directory. To that end I defined a build rule that picks up .rb files and uses macrubyc to compile them. I moved the .rb files into the 'compile sources' build step, which causes the output .o files to be included in the excutable. I then ran into an obvious snag: the ruby environment isn't intialized and the classes are not being pulled in. After some investigation of the rubyc file I can see that you're creating a custom .mm file that calls a number of set up methods for the runtime and an MREP_UUID function for each class. A few questions: 1.) Is there a way that I can find these MREP function names and call them dynamically ? I was considering modifying the generator to output a .m file with a class that just has an init method that calls these, but it isn't compatible with the build rule approach above. 2.) Is there an easier way to set up this environment than the code below ? ruby_sysinit(&argc, &argv); if (argc > 0) { argc--; argv++; } ruby_init(); ruby_set_argv(argc, argv); rb_vm_init_compiler(); try { void *self = rb_vm_top_self(); //MREP FUNCTION CALLS GO HERE :) } catch (...) { rb_vm_print_current_exception(); rb_exit(1); } rb_exit(0); 3.) Am I nuts ? If there's a much easier way to do this, please let me know :) thanks! - Dylan

2 2

[MacRuby] #486: macri exits with fatal error
by MacRuby 07 Dec '09

07 Dec '09

#486: macri exits with fatal error ----------------------------------------+----------------------------------- Reporter: stephen.bannasch@… | Owner: lsansonetti@… Type: defect | Status: new Priority: major | Milestone: Component: MacRuby | Keywords: macri ----------------------------------------+----------------------------------- Iust compiled and installed the latest macruby: I'm at this commit: {{{ commit 209109d0e826d43b0be924c863cb31121cde8af0 Author: lsansonetti(a)apple.com <lsansonetti@apple.com@23306eb0-4c56-4727 -a40e-e92c0eb68959> Date: Mon Dec 7 03:32:54 2009 +0000 potentially fix 10.5 build git-svn-id: http://svn.macosforge.org/repository/ruby/MacRuby/trunk@3080 23306eb0-4c56-4727-a40e-e92c0eb68959 }}} Built and installed as follows: {{{ rake macruby sudo rake install }}} When I start macri I get a long list of "Known classes and modules" on the console which ends with the string "fatal" and quits. {{{ [macruby-git (master)]$ macri ---------------------------------------------- Known classes and modules ACL, ACL::ACLEntry, ACL::ACLList, Abbrev, Acceptables, AmbiguousArgument, AmbiguousOption, Arguable, ArgumentError, Array, Base64, BasicSocket, Benchmark, Benchmark::Job, Benchmark::Report, ... snip about 600 lines ... Zlib::NeedDict, Zlib::StreamEnd, Zlib::StreamError, Zlib::VersionError, Zlib::ZStream, __Finalizer, __Parser, cASN1ObjectId, cDigest, fatal }}} -- Ticket URL: <http://www.macruby.org/trac/ticket/486> MacRuby <http://macruby.org/>

1 3