[MacRuby-devel] Can't build the MacRuby latest.
Hi, Now, I'm rebuilding all of MacRuby latest. But, it seems that does not finish forever with following build log. snip ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C "ext/ripper/lib/ripper/filter.rb" -o "ext/ripper/lib/ripper/filter.rbo" ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C "ext/ripper/lib/ripper/lexer.rb" -o "ext/ripper/lib/ripper/lexer.rbo" ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C "ext/ripper/lib/ripper/sexp.rb" -o "ext/ripper/lib/ripper/sexp.rbo" ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C "ext/ripper/lib/ripper.rb" -o "ext/ripper/lib/ripper.rbo" cd ext/bigdecimal && ../../miniruby -I../.. -I../../lib -r rbconfig -e "RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'" checking for labs() in stdlib.h... yes checking for llabs() in stdlib.h... yes creating Makefile - Does it occur only in my environment? Thank you. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Can't build the MacRuby latest.
Hi, I just rebuild everything and got the same problem. On Jan 28, 2011, at 6:43 PM, Watson wrote: > Hi, > > Now, I'm rebuilding all of MacRuby latest. > But, it seems that does not finish forever with following build log. > > snip > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/filter.rb" -o > "ext/ripper/lib/ripper/filter.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/lexer.rb" -o "ext/ripper/lib/ripper/lexer.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/sexp.rb" -o "ext/ripper/lib/ripper/sexp.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper.rb" -o "ext/ripper/lib/ripper.rbo" > cd ext/bigdecimal && ../../miniruby -I../.. -I../../lib -r rbconfig -e > "RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'" > checking for labs() in stdlib.h... yes > checking for llabs() in stdlib.h... yes > creating Makefile > > - > > Does it occur only in my environment? > > Thank you. > ___ > 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] Can't build the MacRuby latest.
Hi, I suspect the cause of the bug is the change Laurent did today for next/ensure. Last time I played with the exception handling code I remember it took me quite a while to get something working in all cases. I did a reduction of the code that does not work: def foo(dummy) 1.times do next end ensure puts end foo(nil) I'll create a ticket for that. On Jan 28, 2011, at 6:43 PM, Watson wrote: > Hi, > > Now, I'm rebuilding all of MacRuby latest. > But, it seems that does not finish forever with following build log. > > snip > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/filter.rb" -o > "ext/ripper/lib/ripper/filter.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/lexer.rb" -o "ext/ripper/lib/ripper/lexer.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper/sexp.rb" -o "ext/ripper/lib/ripper/sexp.rbo" > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > "ext/ripper/lib/ripper.rb" -o "ext/ripper/lib/ripper.rbo" > cd ext/bigdecimal && ../../miniruby -I../.. -I../../lib -r rbconfig -e > "RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'" > checking for labs() in stdlib.h... yes > checking for llabs() in stdlib.h... yes > creating Makefile > > - > > Does it occur only in my environment? > > Thank you. > ___ > 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
[MacRuby-devel] Strange NSDate behavior building 32 bit v 64 bit
I am seeing some strange behavior with NSDate, here is my basic code in a new
MacRuby project.
I am running on a MacBook 2009 model, Mac OSX 10.6.6
I am using the latest XCode and the MacRuby Framework 0.7 in XCode
in rbmain.rb:
NSLog("In rb_main.rb")
puts "NSDate = " + NSDate.date.to_s
NSLog( "NSDate = " + NSDate.date.to_s)
CCode.printNSDate
in CCode.m:
@implementation CCode
+ (void) printNSDate
{
NSLog(@"In printNSDate, NSDate = %@", NSDate.date);
}
@end
When compiled: 64-bit Universal, the output is
2011-01-28 05:54:16.972 TestRuby[90066:a0f] In rb_main.rb
NSDate = 2011-01-28 05:54:16 -0600
2011-01-28 05:54:16.976 TestRuby[90066:a0f] NSDate = 2011-01-28 05:54:16 -0600
2011-01-28 05:54:16.979 TestRuby[90066:a0f] In printNSDate, NSDate = 2011-01-28
05:54:16 -0600
When compiled: 32-bit Universal, the output is
2011-01-28 05:51:23.941 TestRuby[89998:a0f] In rb_main.rb
NSDate = 2011-01-28 05:44:00 -0600
2011-01-28 05:51:23.958 TestRuby[89998:a0f] NSDate = 2011-01-28 05:44:00 -0600
2011-01-28 05:51:23.961 TestRuby[89998:a0f] In printNSDate, NSDate = 2011-01-28
05:51:23 -0600
2011-01-28 05:51:24.565 TestRuby[89998:a0f] Error loading
/Library/InputManagers/Smart Crash Reports/Smart Crash
Reports.bundle/Contents/MacOS/Smart Crash Reports:
dlopen(/Library/InputManagers/Smart Crash Reports/Smart Crash
Reports.bundle/Contents/MacOS/Smart Crash Reports, 265): no suitable image
found. Did find:
/Library/InputManagers/Smart Crash Reports/Smart Crash
Reports.bundle/Contents/MacOS/Smart Crash Reports: GC capability mismatch
2011-01-28 05:51:25.409 TestRuby[89998:a0f] Error loading
/Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL:
dlopen(/Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL, 265): no
suitable image found. Did find:
/Library/InputManagers/SIMBL/SIMBL.bundle/Contents/MacOS/SIMBL: GC
capability mismatch
The Obj-C routine prints the correct time. 5:51:23 in both cases.
For 32 bit, the Ruby code prints some time in the past that never changes.
For 64 bit, the Ruby code prints the correct time.
Any idea's what could be going on?
Thanks!
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Gems again; signing records
I know this has been asked before but his is driving me nuts.It' s been a frustrating day; I've been trying to use the UUID gem and have still not been able to 'require' it successfully. I have installed uuid using macgem and have unpacked it to a vendor directory, so I now have : vendor -- macaddr-1.0.0 -- lib -- macaddr.rb -- uuid-2.3.1 -- lib -- uuid.rb Obviously, there's more, but those are important bits. I have tried the following, after googling, with no success, on the basis that the files are 'require'd and once loaded, can be 'require'd again by simple reference: In rb_main.rb $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ lib') require 'macaddr' require 'uuid' However, when I try to require 'macaddr' or 'uuid' from another class definition file, I get 'no such file to load'. I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/ PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference. I've tried using the full path: require '/Users/martin/work/macruby/onWeb/xx/Vendor/macaddr-1.0.0/ lib/macaddr' require '/Users/martin/work/macruby/onWeb/xx/Vendor/uuid-2.3.1/lib/ uuid' and this produces a 'no such file to load -- fileutils' - neither gem depends on fileutils ! But hey, I tried it and it refused to build - 'checking for Magick- config... no' So I have two questions: 1. What is the *proper* way of incorporating gems into a MacRuby project using XCode to build and run; and 2. All I want to do is sign records for later comparison. Can anybody suggest an alternative method, other than using UUID? thanks ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
On Fri, Jan 28, 2011 at 12:41 PM, Martin Hawkins wrote: > In rb_main.rb > > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ > lib') > > require 'macaddr' > require 'uuid' > > However, when I try to require 'macaddr' or 'uuid' from another class > definition file, I get 'no such file to load'. > Two things: -- You should only have to require these files once, unless you expect the other class definitions to be used independently of your main project. Putting these in rb_main.rb is typically a good idea. -- This might be obvious, but just in case: the "File.join(File.dirname..." patern will only work in rb_main.rb or any other file in the same directory. If you've put your class definition files in lib/ then you'll need to change the relative path. > 1. What is the *proper* way of incorporating gems into a MacRuby > project using XCode to build and run; and > Typically, when you unpack a gem it will have a structure like: /foo_gem-1.0/lib /foo_gem-1.0/lib/foo_gem.rb /foo_gem-1.0/lib/foo_gem/library_files.rb In other words, usually the "lib" directory is already partitioned by gem name inside the gem. So, what I do is to just collect all the contents of the "lib" directories for all the gems and put them together (either directly in my own lib/ or in vendor/lib/). There's no reason for the extra directories...just adds complexity. > 2. All I want to do is sign records for later comparison. Can anybody > suggest an alternative method, other than using UUID? > In MacRuby you can use the CFUUID utilities: http://developer.apple.com/library/mac/#documentation/CoreFoundation/Reference/CFUUIDRef/Reference/reference.html > macirb irb(main):001:0> framework 'Foundation' => true irb(main):002:0> cfuuid = CFUUIDCreate(nil) => #<__NSCFType:0x200f6dd60> irb(main):003:0> id = CFUUIDCreateString(nil, cfuuid) => "689369A5-5CCD-41D0-BF83-1759BFD4F3EA" irb(main):004:0> CFRelease(cfuuid) => nil ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
Well, I've just realised that get the fileutils message was in fact a sign of some success, as the UUID gem does indeed require it. I'll play around a little more with gem loading - I've got to get it right for other projects. I was doing what you suggested but without apparent success. wrt CFUUID, that's helpful and I'll look at that. I was just looking at NSProcessInfo, which has a globallyUniqueString method. On Jan 28, 6:25 pm, Joshua Ballanco wrote: > On Fri, Jan 28, 2011 at 12:41 PM, Martin Hawkins > wrote: > > > In rb_main.rb > > > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') > > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ > > lib') > > > require 'macaddr' > > require 'uuid' > > > However, when I try to require 'macaddr' or 'uuid' from another class > > definition file, I get 'no such file to load'. > > Two things: > > -- You should only have to require these files once, unless you expect the > other class definitions to be used independently of your main project. > Putting these in rb_main.rb is typically a good idea. > -- This might be obvious, but just in case: the "File.join(File.dirname..." > patern will only work in rb_main.rb or any other file in the same directory. > If you've put your class definition files in lib/ then you'll need to change > the relative path. > > > 1. What is the *proper* way of incorporating gems into a MacRuby > > project using XCode to build and run; and > > Typically, when you unpack a gem it will have a structure like: > > /foo_gem-1.0/lib > /foo_gem-1.0/lib/foo_gem.rb > /foo_gem-1.0/lib/foo_gem/library_files.rb > > In other words, usually the "lib" directory is already partitioned by gem > name inside the gem. So, what I do is to just collect all the contents of > the "lib" directories for all the gems and put them together (either > directly in my own lib/ or in vendor/lib/). There's no reason for the extra > directories...just adds complexity. > > > 2. All I want to do is sign records for later comparison. Can anybody > > suggest an alternative method, other than using UUID? > > In MacRuby you can use the CFUUID > utilities:http://developer.apple.com/library/mac/#documentation/CoreFoundation/... > > > macirb > > irb(main):001:0> framework 'Foundation' > => true > irb(main):002:0> cfuuid = CFUUIDCreate(nil) > => #<__NSCFType:0x200f6dd60> > irb(main):003:0> id = CFUUIDCreateString(nil, cfuuid) > => "689369A5-5CCD-41D0-BF83-1759BFD4F3EA" > irb(main):004:0> CFRelease(cfuuid) > => nil > > ___ > MacRuby-devel mailing list > [email protected]://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] Can't build the MacRuby latest.
Fixed in r5207. Sorry for the inconvenience, I did not try a full build before committing. Laurent On Jan 28, 2011, at 3:28 AM, Vincent Isambart wrote: > Hi, > > I suspect the cause of the bug is the change Laurent did today for > next/ensure. Last time I played with the exception handling code I remember > it took me quite a while to get something working in all cases. > > I did a reduction of the code that does not work: > def foo(dummy) > 1.times do > next > end > ensure > puts > end > foo(nil) > > I'll create a ticket for that. > > On Jan 28, 2011, at 6:43 PM, Watson wrote: > >> Hi, >> >> Now, I'm rebuilding all of MacRuby latest. >> But, it seems that does not finish forever with following build log. >> >> snip >> ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C >> "ext/ripper/lib/ripper/filter.rb" -o >> "ext/ripper/lib/ripper/filter.rbo" >> ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C >> "ext/ripper/lib/ripper/lexer.rb" -o "ext/ripper/lib/ripper/lexer.rbo" >> ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C >> "ext/ripper/lib/ripper/sexp.rb" -o "ext/ripper/lib/ripper/sexp.rbo" >> ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C >> "ext/ripper/lib/ripper.rb" -o "ext/ripper/lib/ripper.rbo" >> cd ext/bigdecimal && ../../miniruby -I../.. -I../../lib -r rbconfig -e >> "RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'" >> checking for labs() in stdlib.h... yes >> checking for llabs() in stdlib.h... yes >> creating Makefile >> >> - >> >> Does it occur only in my environment? >> >> Thank you. >> ___ >> 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 ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Can't build the MacRuby latest.
Thank you!! I was able to rebuild with r5207 :) 2011/1/29 Laurent Sansonetti : > Fixed in r5207. Sorry for the inconvenience, I did not try a full build > before committing. > Laurent > On Jan 28, 2011, at 3:28 AM, Vincent Isambart wrote: > > Hi, > > I suspect the cause of the bug is the change Laurent did today for > next/ensure. Last time I played with the exception handling code I remember > it took me quite a while to get something working in all cases. > > I did a reduction of the code that does not work: > def foo(dummy) > 1.times do > next > end > ensure > puts > end > foo(nil) > > I'll create a ticket for that. > > On Jan 28, 2011, at 6:43 PM, Watson wrote: > > Hi, > > Now, I'm rebuilding all of MacRuby latest. > > But, it seems that does not finish forever with following build log. > > snip > > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > > "ext/ripper/lib/ripper/filter.rb" -o > > "ext/ripper/lib/ripper/filter.rbo" > > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > > "ext/ripper/lib/ripper/lexer.rb" -o "ext/ripper/lib/ripper/lexer.rbo" > > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > > "ext/ripper/lib/ripper/sexp.rb" -o "ext/ripper/lib/ripper/sexp.rbo" > > ./miniruby -I. -I./lib bin/rubyc --internal --arch x86_64 -C > > "ext/ripper/lib/ripper.rb" -o "ext/ripper/lib/ripper.rbo" > > cd ext/bigdecimal && ../../miniruby -I../.. -I../../lib -r rbconfig -e > > "RbConfig::CONFIG['libdir'] = '../..'; require './extconf.rb'" > > checking for labs() in stdlib.h... yes > > checking for llabs() in stdlib.h... yes > > creating Makefile > > - > > Does it occur only in my environment? > > Thank you. > > ___ > > 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 > > > ___ > 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] Gems again; signing records
Hi Martin, I think we now get the "how to embed gems in a MacRuby Xcode project?" question every week. I think it's time that we provide a way to automate that and properly document it on the website. As I suggested on IRC yesterday, I think we should add a --gem argument to macruby_deploy, which would make sure the given gems and their dependencies are unpacked inside the application bundle. I created the following ticket to track this change, and I believe it should be done for 0.9. https://www.macruby.org/trac/ticket/1137 Laurent On Jan 28, 2011, at 9:41 AM, Martin Hawkins wrote: > I know this has been asked before but his is driving me nuts.It' s > been a frustrating day; I've been trying to use the UUID gem and have > still not been able to 'require' it successfully. > > I have installed uuid using macgem and have unpacked it to a vendor > directory, so I now have : > vendor -- macaddr-1.0.0 -- lib -- macaddr.rb > -- uuid-2.3.1 -- lib -- uuid.rb > > Obviously, there's more, but those are important bits. > > I have tried the following, after googling, with no success, on the > basis that the files are 'require'd and once loaded, can be 'require'd > again by simple reference: > In rb_main.rb > > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/uuid-2.3.1/lib') > $:.unshift File.join(File.dirname(__FILE__), 'Vendor/macaddr-1.0.0/ > lib') > > require 'macaddr' > require 'uuid' > > However, when I try to require 'macaddr' or 'uuid' from another class > definition file, I get 'no such file to load'. > > I've tried setting ENV['GEM_HOME']='/Users/martin/work/macruby/onWeb/ > PeepOpen/Vendor' in rb_main.rb; that seemed to make no difference. > > I've tried using the full path: > require '/Users/martin/work/macruby/onWeb/xx/Vendor/macaddr-1.0.0/ > lib/macaddr' > require '/Users/martin/work/macruby/onWeb/xx/Vendor/uuid-2.3.1/lib/ > uuid' > and this produces a 'no such file to load -- fileutils' - neither gem > depends on fileutils ! > > But hey, I tried it and it refused to build - 'checking for Magick- > config... no' > > So I have two questions: > > 1. What is the *proper* way of incorporating gems into a MacRuby > project using XCode to build and run; and > 2. All I want to do is sign records for later comparison. Can anybody > suggest an alternative method, other than using UUID? > > thanks > ___ > 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] Gems again; signing records
On 2011-01-28, at 20:30 , Laurent Sansonetti wrote: > > As I suggested on IRC yesterday, I think we should add a --gem argument to > macruby_deploy, which would make sure the given gems and their dependencies > are unpacked inside the application bundle. It could be great if this involved a bit of magic, so you only specify the gems you need in a single place. Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned devotee. It really helps keep a tight grip on a project's gem dependencies, locking versions and all. With the added benefit to pull gems from custom paths and git repos. I suppose such support could be built on top of a simpler --gem argument in a rake task, though. Anyway, food for thought. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
Hi Caio, On Jan 28, 2011, at 2:39 PM, Caio Chassot wrote: > On 2011-01-28, at 20:30 , Laurent Sansonetti wrote: >> >> As I suggested on IRC yesterday, I think we should add a --gem argument to >> macruby_deploy, which would make sure the given gems and their dependencies >> are unpacked inside the application bundle. > > It could be great if this involved a bit of magic, so you only specify the > gems you need in a single place. > > Maybe it's overkill, but we could rely on Bundler. I'm a Bundler hater turned > devotee. It really helps keep a tight grip on a project's gem dependencies, > locking versions and all. With the added benefit to pull gems from custom > paths and git repos. > > I suppose such support could be built on top of a simpler --gem argument in a > rake task, though. I would rather avoid any dependency. I agree that keeping track of the gems you need in a single place is a good idea, though. Maybe we should refactor the Xcode templates to do so, eventually. Another possibility would be to scan the application's source code and auto-detect the list of gems, but I prefer to avoid that. Laurent___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
On 2011-01-28, at 21:36 , Laurent Sansonetti wrote: > > I would rather avoid any dependency. I agree that keeping track of the gems > you need in a single place is a good idea, though. > > Maybe we should refactor the Xcode templates to do so, eventually. I'd classify Xcode as a dependency. Simple plain text files are nice and tidy. And that's what a Gemfile is. We can skip Bundler and just steal the Gemfile format, or a subset of it. It's rather well specified: http://gembundler.com/man/gemfile.5.html > Another possibility would be to scan the application's source code and > auto-detect the list of gems, but I prefer to avoid that. Indeed. So many ways this could go wrong. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Thread safety in apply example?
On Wed, Jan 26, 2011 at 4:45 PM, Laurent Sansonetti wrote: > Hi Charles! > Sorry for the late response. > As others have noted, in this snippet, #apply is called on a sequential > queue (queues created by Queue.new are always sequential), therefore there > shouldn't be any problem here. If the queue was concurrent, however, there > would be a thread safety issue. > I think this rdoc snippet should be rewritten to avoid confusion. Yup, I understand now. Thank you! > I see that you're wrapping a GCD-like interface in JRuby, it's very cool! I > assume you want your interface to be cross platform, but in the case of > JRuby running on Mac OS X, maybe we can extract our code as a C extension, > this way JRuby would use the "system" GCD. Maybe we can also work together > on creating a good test/spec suite for the GCD interface, because it's > currently lacking. To be honest I'm more and more downbeat about C extensions. On JRuby, we have opted to disallow C extensions from running concurrently, since there's just too many extensions that mutate global state. They also make it impossible to spin up multiple JRuby instances in the same JVM, since ALL C extensions hold references to a specific JRuby runtime or classes it contains in global state (i.e. no extensions out there are MVM-safe). So there are certainly other possiblities: 1. FFI. The libdispatch APIs are all C-based and seem to be pretty consistent. A single FFI binding might work for everyone including MRI. 2. Attempt to build off Java/Cocoa integration, as seen in this attempt: http://pixel.recoil.org/code/rococoa/index.html. I don't know how reliable that integration is though, or if Apple is going to continue maintaining it. A C extension would probably be a "last resort" since it has many limitations. re: testing: Yes! Are there many tests for this yet? I have not looked for them, so I have no idea. I'd love to see a complete suite (or at least complete for the highest-level surface area of functionality) that we could all try to meet. - Charlie ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Gems again; signing records
IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler code is overly complicated and tries to do way too much. Trying to resolve the dependency tree is not something you should do in prod or on a client machine. This belongs to the dev environment. We could potentially look at isolate but it doesn't support 'frozen' gems. The way I see it, we just need macdeploy to unpack the gems you need & their dependencies as well as modify the loadpath. By doing that our prod apps don't even have the need to load or rely on rubygems. What do you think? - Matt Sent from my iPhone On Jan 28, 2011, at 16:09, Caio Chassot wrote: > On 2011-01-28, at 21:36 , Laurent Sansonetti wrote: >> >> I would rather avoid any dependency. I agree that keeping track of the gems >> you need in a single place is a good idea, though. >> >> Maybe we should refactor the Xcode templates to do so, eventually. > > I'd classify Xcode as a dependency. Simple plain text files are nice and tidy. > > And that's what a Gemfile is. We can skip Bundler and just steal the Gemfile > format, or a subset of it. It's rather well specified: > http://gembundler.com/man/gemfile.5.html > > >> Another possibility would be to scan the application's source code and >> auto-detect the list of gems, but I prefer to avoid that. > > Indeed. So many ways this could go wrong. > ___ > 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] Gems again; signing records
On 2011-01-29, at 02:11 , Matt Aimonetti wrote: > > IMHO adding Bundler as a dependency would be a huge mistake. First, Bundler > code is overly complicated and tries to do way too much. (You forgot to mention slow.) I think I agree here. I just like the Gemfile format. Don't think we need to reinvent the wheel. > Trying to resolve the dependency tree is not something you should do in prod > or on a client machine. This belongs to the dev environment. Maybe your argument backfires here, because resolving the dependency tree at compile time to decide which gems to bundle in the final app is actually quite useful. In fact, it's what you suggest right after: > The way I see it, we just need macdeploy to unpack the gems you need & their > dependencies as well as modify the loadpath. By doing that our prod apps > don't even have the need to load or rely on rubygems. Yes. In fact not loading rubygems on bundled/compiled apps is probably something to strive for. I can see things getting messy with unforeseen conflicts between app gems and user gems. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] is_a? method
On Wed, Jan 19, 2011 at 5:15 PM, Caio Chassot wrote: > On 2011-01-19, at 20:50 , Robert Rice wrote: >> >> You instantiated AnArray. Try this: >> >> class AnArray < Array; end >> >> AnArray.kind_of?( Array ) will return false > > Is this what you're looking for? > > $ macirb > irb(main):001:0> class AnArray < Array; end > => nil > irb(main):002:0> AnArray <= Array > => true Or: AnArray.ancestors.include? Array ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
