[MacRuby-devel] Looking for info on MacRuby's JIT

2009-12-07 Thread ravenex 
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___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] [MacRuby] #486: macri exits with fatal error

2009-12-07 Thread MacRuby 
#486: macri exits with fatal error
+---
 Reporter:  stephen.banna...@…  |   Owner:  lsansone...@…
 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: [email protected] 
 Date:   Mon Dec 7 03:32:54 2009 +

 potentially fix 10.5 build

 git-svn-id:
 http://svn.macosforge.org/repository/ruby/MacRuby/tr...@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: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #486: macri exits with fatal error

2009-12-07 Thread MacRuby 
#486: macri exits with fatal error
+---
 Reporter:  stephen.banna...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:   
Component:  MacRuby |Keywords:  macri
+---

Comment(by stephen.banna...@…):

 Also: Mac OS X 10.5.8.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #486: macri exits with fatal error

2009-12-07 Thread MacRuby 
#486: macri exits with fatal error
+---
 Reporter:  stephen.banna...@…  |   Owner:  lsansone...@…
 Type:  defect  |  Status:  new  
 Priority:  major   |   Milestone:   
Component:  MacRuby |Keywords:  macri
+---

Comment(by stephen.banna...@…):

 resolved: operator error! use macirb NOTmacri

 I'd close it myself but that option isn't available to me.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #486: macri exits with fatal error

2009-12-07 Thread MacRuby 
#486: macri exits with fatal error
+---
 Reporter:  stephen.banna...@…  |Owner:  lsansone...@…
 Type:  defect  |   Status:  closed   
 Priority:  major   |Milestone:   
Component:  MacRuby |   Resolution:  invalid  
 Keywords:  macri   |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => invalid


Comment:

 Errare humanum est :)

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] info on MacRuby's JIT (Roxor compiler for LLVM)

2009-12-07 Thread Ernest N. Prabhakar, Ph.D. 
Hi Ravenex,

On Dec 7, 2009, at 8:36 AM, ravenex wrote:
>  
> 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.

I don't have any answers either, but let me try to collect the relevant 
information, if only to improve my own understanding.

>  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?
>  
> Any pointers to documents, blog posts or mails would be truely appreciated.


As I understand it, the MacRuby compiler is known as Roxor and is defined in:

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/compiler.h

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/compiler.cpp

Roxor depends on some language facilities, e.g.:

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/llvm.h

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/objc.h

But mostly on the VM (which is essential for breaking the Global Interpreter 
Lock):

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/vm.h

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/vm.cpp

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/vm_eval.c

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/vm_method.c

> 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.


In terms of front-ends, there is both an AOT and JIT compiler.  It looks like 
both are called from:

http://svn.macosforge.org/repository/ruby/MacRuby/trunk/main.cpp

With the AOT compiler called via: rb_vm_aot_compile -> 
RoxorAOTCompiler::compile_main_function
and the JIT invoked from: ruby_run_node -> RoxorCompiler::compile_main_function

If I understand your question, it is what method explicitly does the 
compilation during JIT?  That would seem to be: compile_node

* http://svn.macosforge.org/repository/ruby/MacRuby/trunk/compiler.cpp

> Function *
> RoxorCompiler::compile_main_function(NODE *node)
> {
> current_instance_method = true;
> 
> Value *val = compile_node(node);

If so, then the question becomes "Where is implemented, compile_node and does 
it cache pre-compiled methods"?

I don't know, but hopefully this gives you somewhere to look; or will inspire 
someone who knows more to provide a better answer

-- Ernie P.
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #475: GCD Queues should print their label as their "to_s" method

2009-12-07 Thread MacRuby 
#475: GCD Queues should print their label as their "to_s" method
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by ernest.prabha...@…):

 Labels should be strings, and should be unique

 PROPOSAL alias to_s to label

 Modify inspect to add label as well as the pointer description

 Should not crash on null label

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by ernest.prabha...@…):

 NOTE: group dispatch is ALWAYS aysnc; my bad

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] A path to linking rbo files into one executable in Xcode

2009-12-07 Thread Dylan Bruzenak 
Thanks for the detailed response. I'll have to take a stab at one of these
methods, probably the scripting one for starters. nm... things I should have
known yesterday :)

- Dylan

On Fri, Nov 27, 2009 at 2:11 PM, Laurent Sansonetti
wrote:

> Hi Dylan,
>
> Sorry for the late response.
>
>
> On Nov 25, 2009, at 10:21 AM, Dylan Bruzenak wrote:
>
>  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.
>>
>
> You can use the nm(1) tool against every .o file to locate the MREP_ symbol
> name.
>
>
>  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 :)
>>
>
> You're not nuts :) Having the ability to compile all the source code of an
> application into the same executable is something we definitely want to
> feature. Your approach should work but I would like to offer a solution that
> doesn't require any change in MacRuby or the application code. I also want a
> solution that works on non-Xcode projects (command-line tools).
>
> Basically, my plan is to add a global table in MacRuby core that would be
> filled by macrubyc once you produce an executable based on .o Ruby files.
> The table would be a simple "Ruby file path" to "MREP_ function name"
> mapping. Then, at runtime, #require would look into that table and
> appropriately run the initializers.
>
> I haven't had the time to implement this idea yet. I may do it for the
> final 0.5. Hopefully this can be done in macruby_deploy. Any help would be
> greatly appreciated :)
>
> Laurent
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by ernest.prabha...@…):

 PROPOSAL::

 q.apply
 q.sync()
 q.async()
 q.async(group)

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by ernest.prabha...@…):

 PROPOSAL: queue.dispatch and group.dispatch

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by ernest.prabha...@…):

 PROPOSAL: delete queue.dispatch and group.dispatch

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #482: Dispatch::Queue#dispatch should take a hash instead of a bool

2009-12-07 Thread MacRuby 
#482: Dispatch::Queue#dispatch should take a hash instead of a bool
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by ernest.prabha...@…):

 Obsoleted by proposal

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #477: Need GCD wrapper for dispatch_once

2009-12-07 Thread MacRuby 
#477: Need GCD wrapper for dispatch_once
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  minor   |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:   
+---

Comment(by ernest.prabha...@…):

 Needs a (pseudo-static) variable managed by RoxorCore

 Dispatch.once { DB.connect(@db_file) }

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by conra...@…):

 After reading through the specification, I would like to see the following
 more explicit API:

 {{{
 queue = Dispatch::Queue.new( "comp.lang.MyCustomerQueue", attribute = nil
 )
 queue.dispatch_async( &block )
 queue.dispatch_sync( &block )
 queue.dispatch_apply( iterations, &block )

 group = Dispatch::Group.new
 group.dispatch_async( queue, &block )
 group.dispatch_wait( Dispatch::TIME_FOREVER )
 group.dispatch_release
 }}}

 These are just some of my thoughts because I was looking for something
 that was inline with the C API.  Also, the explicit API eliminates the
 need for 'if' constructs within
 the function definition within 'gcd.c'.  Next, we can namespace this by
 adding both the Group and Queue classes within the module Dispatch.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |   Owner:  lsansone...@…
 Type:  enhancement |  Status:  new  
 Priority:  blocker |   Milestone:  MacRuby 0.5  
Component:  MacRuby |Keywords:  gcd  
+---

Comment(by conra...@…):

 Here's a better representation and it's associated usage:

 API:
 {{{

 module Dispatch

   # constants...
   TIME_FOREVER = 1

   class Queue

  def initialize( label, attribute = nil )
@label = label
@attribute = attribute
  end

  def dispatch_async( &block )
  end

  def dispatch_sync( &block )
  end

  def dispatch_apply( iterations, &block )
  end

   end

   class Group

 def dispatch_async( queue, &block )
 end

 def dispatch_wait( timeout )
 end

 def dispatch_release
 end

   end

 end

 }}}

 USAGE:
 {{{
 block = lambda { do_some_work }

 queue = Dispatch::Queue.new( "comp.lang.MyCustomerQueue" )
 queue.dispatch_async( &block )
 queue.dispatch_sync( &block )
 queue.dispatch_apply( 5, &block )

 group = Dispatch::Group.new
 group.dispatch_async( queue, &block )
 group.dispatch_wait( Dispatch::TIME_FOREVER )
 group.dispatch_release

 }}}

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Looking for info on MacRuby's JIT

2009-12-07 Thread Vincent Isambart 
> 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.

There's currently no documentation on the inner workings of MacRuby.
Any help is welcome ;-)
Most knowledge is in the code or Laurent's head (and a bit in other
commiters' head ;-)). Feel free to ask questions on the ML, though
answers may take some time.

> 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.

Yes I added it to be sure that LLVM does not use its lazy compilation
mechanism (that is know not to work correctly in multiple threads).
It's not needed in MacRuby because we do it our own way.

> I must have
> missed something...but if Roxor JIT compiles a method upon first invocation,
> where is this behavior implemented.

In JIT mode, the conversion of Ruby code to LLVM code (or more
strictly speaking LLVM C++ objects) is done as soon as a Ruby script
is loaded. But LLVM's optimization phase and native code generation of
a function is only done when this function is called.

The place where it's done is hard to find though: it's done using a
functionality of the Objective-C runtime: we define the
"resolveClassMethod:" and "resolveInstanceMethod:" on NSObject (in
vm.cpp, in Init_PreVM)
http://developer.apple.com/mac/library/documentation/cocoa/reference/Foundation/Classes/NSObject_Class/Reference/Reference.html#//apple_ref/occ/clm/NSObject/resolveClassMethod:
There are also a few other cases where we compile a method even if
it's not called, for instance when a method is aliased or a module
included.

For blocks it's done in dispatcher.cpp, in rb_vm_prepare_block. That's
a function called just before any block is given to a function.

In AOT mode, of course, we always compile and optimize everything
(blocks and methods) beforehand.
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

[MacRuby-devel] mac & ruby question

2009-12-07 Thread Tim Rand 
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,
wrote:

> Send MacRuby-devel mailing list submissions to
>[email protected]
>
> 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
>[email protected]
>
> You can reach the person managing the list at
>[email protected]
>
> 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 
> To: "MacRuby development discussions."
>
> Subject: Re: [MacRuby-devel] mac & ruby question
> Message-ID: <[email protected]>
> 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  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

[MacRuby-devel] Has the team given up on continuous integration?

2009-12-07 Thread Giampiero De Ciantis 
rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to the 
suite of specs? Lost cause?

Cheers,

-Gp
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] Has the team given up on continuous integration?

2009-12-07 Thread Matt Aimonetti 
Hi Gp,

 I'm not sure why you seem so upset. Here are the results of the CI:

Library:
  files: 1043
  examples: 1987
  skipped examples: 748
  expectations: 7548
  failures: 0

  errors: 0
  pass rate: 72.65%

Core:
  files: 1365
  examples: 6635
  skipped examples: 1438
  expectations: 18752
  failures: 2
  errors: 0
  pass rate: 82.19%

Language:
  files: 61

  examples: 1013
  skipped examples: 96
  expectations: 2635
  failures: 0
  errors: 0
  pass rate: 91.34%

Summary:
  files: 2469
  examples: 9635
  skipped examples: 2282
  expectations: 28935

  failures: 2
  errors: 0
  pass rate: 80.85%

Exceptions:


1)
Process.groups gets an Array of the gids of groups in the supplemental
group access list FAILED
Expected [12, 20, 62, 80, 98, 100, 204, 251, 253, 254, 257, 402, 404,
500, 501, 1025]

to equal [12, 20, 62, 80, 98, 100, 204, 250, 251, 252, 253, 254, 255,
256, 257, 401, 402, 403, 404, 405, 406, 407, 500, 501, 502, 503, 504,
1025, 1027, 1028, 19000, 19002]
core:in `raise:'
core:in `each'

core:in `all?'
core:in `each'

2)
String#dump includes .force_encoding(name) if the encoding isn't ASCII
compatiable FAILED
Expected "\"v\"" to equal "\"\\bv\".force_encoding(\"UTF-16BE\")"

core:in `raise:'
core:in `each'
core:in `all?'
core:in `each'
rake aborted!
Command failed with status (1): [./mspec/bin/mspec ci -B ./spec/macruby.msp...]



The first failure is bogus. So it lefts us with one failing spec related to
the encodings that we currently don't fully support.

Unless I'm missing something, this isn't bad at all. Maybe you're having
other results on your system and is willing to try to help us finding out
what's going on?

- Matt

On Mon, Dec 7, 2009 at 7:49 PM, Giampiero De Ciantis
wrote:

> rake spec:ci hasn't passed in 3 months, maybe more. Is there any point to
> the suite of specs? Lost cause?
>
> Cheers,
>
> -Gp
> ___
> MacRuby-devel mailing list
> [email protected]
> http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
>
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #482: Dispatch::Queue#dispatch should take a hash instead of a bool

2009-12-07 Thread MacRuby 
#482: Dispatch::Queue#dispatch should take a hash instead of a bool
+---
 Reporter:  ernest.prabha...@…  |Owner:  lsansone...@…
 Type:  enhancement |   Status:  closed   
 Priority:  blocker |Milestone:  MacRuby 0.5  
Component:  MacRuby |   Resolution:  duplicate
 Keywords:  |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => duplicate


Comment:

 Closing because of #476.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel

Re: [MacRuby-devel] [MacRuby] #476: GCD Groups should be a wrapper around dispatch, not its own invocation style

2009-12-07 Thread MacRuby 
#476: GCD Groups should be a wrapper around dispatch, not its own invocation
style
+---
 Reporter:  ernest.prabha...@…  |Owner:  lsansone...@…
 Type:  enhancement |   Status:  closed   
 Priority:  blocker |Milestone:  MacRuby 0.5  
Component:  MacRuby |   Resolution:  fixed
 Keywords:  gcd |  
+---
Changes (by lsansone...@…):

  * status:  new => closed
  * resolution:  => fixed


Comment:

 Proposal implemented as r3086.

 Conrad: we opted for a similar design. You now have the following methods
 on Queue: #sync, #async (which can accept an optional Group argument),
 #apply.

-- 
Ticket URL: 
MacRuby 

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel