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 -
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
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
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
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 -- macadd
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 requir
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
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 co
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
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, wh
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
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
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. Sim
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 que
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
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
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>
17 matches
Mail list logo
