> [Switching to process 1982]
> Running…
> 2009-10-05 22:29:51.141 IStockCocoa[1982:80f] Error loading
> /Library/InputManagers/GearsEnabler.old/GearsEnabler.bundle/Contents/MacOS/GearsEnabler:
> dlopen(/Library/InputManagers/GearsEnabler.old/GearsEnabler.bundle/Contents/MacOS/GearsEnabler,
> 265):
It's way better, but I'm getting this:
[Switching to process 1982]
Running…
2009-10-05 22:29:51.141 IStockCocoa[1982:80f] Error loading /Library/
InputManagers/GearsEnabler.old/GearsEnabler.bundle/Contents/MacOS/
GearsEnabler: dlopen(/Library/InputManagers/GearsEnabler.old/
GearsEnabler.bundl
On Oct 5, 2009, at 8:01 PM, Conrad Taylor wrote:
What should be the exact output? In Ruby 1.9.1, I see the following
output:
$ ruby test.rb
"A"
"B"
"C"
"D"
[snip]
#init is actually a NSObject thing. MacRuby's default initializer
calls it.
The mainstream Ruby doesn't, which explains you
What should be the exact output? In Ruby 1.9.1, I see the following output:
$ ruby test.rb
"A"
"B"
"C"
"D"
Note: When .new is called allocate method is called. Then the
object's initialize method is called and the
instance is returned to the caller.
$ macruby test.rb
"HasInit"
"A"
"H
Hi,
I fixed several 32-bit bugs, so it should be better. However, the
specs don't pass at 100% yet (a notable thing is that ruby exceptions
cannot be intercepted by objc).
Feel free to give it a try and let us know if it's better now :)
Laurent
On Oct 5, 2009, at 7:32 PM, s.ross wrote:
G
Thanks for the report, I added your snippet in our test suite.
At a glance it looks like an infinite loop in the dispatcher.
Definitely a bug :)
Laurent
On Oct 5, 2009, at 6:37 PM, Michael Shapiro wrote:
Hi all,
I searched a few months of the list archives and trac, but wasn't
able to fi
> Great progress. I'm pretty sure you would have mentioned it in the release
> notes if it were stable, but has there been any progress making MacRuby work
> properly on Snow Leopard 32-bit architectures like the Core Duo? (nag, nag
> :)
Yes, 32-bit mode should work better (Laurent fixed the asser
Great progress. I'm pretty sure you would have mentioned it in the
release notes if it were stable, but has there been any progress
making MacRuby work properly on Snow Leopard 32-bit architectures like
the Core Duo? (nag, nag :)
Thx
On Oct 5, 2009, at 2:34 PM, Laurent Sansonetti wrote:
Hi all,
I searched a few months of the list archives and trac, but wasn't able
to find reference to this.
Calling `super` inside of an overridden #init function where no ruby
ancestors define #init causes a segmentation fault. If I'm not
mistaken, shouldn't the init: message be passed to N
> Supporting Enumerable::Enumerator might be harder than planned. I think we
> will have to implement coroutines first. I wonder if we want to do that for
> 0.5.
I think it can wait after 0.5. There's already enough things to do for 0.5 ;-)
___
MacRuby-d
Somehow I always pick dead ends.
I guess I am out of my league with this project.
Thanks,
-Gp
On 2009-10-05, at 8:19 PM, Laurent Sansonetti wrote:
Hi Giampiero,
I think it works because the specs are tagged :) Check out spec/
frozen/tags/macruby/core/enumerator.
Supporting Enumerable::Enu
Hi Giampiero,
I think it works because the specs are tagged :) Check out spec/frozen/
tags/macruby/core/enumerator.
Supporting Enumerable::Enumerator might be harder than planned. I
think we will have to implement coroutines first. I wonder if we want
to do that for 0.5.
Laurent
On Oct
I wanted to contribute to the project and I am not sure what I am
seeing. I ran the following specs:
./mspec/bin/mspec ci -B ./spec/macruby.mspec ./spec/frozen/core/
enumerator
and
./mspec/bin/mspec ci -B ./spec/macruby.mspec ./spec/frozen/core/
enumerable
Both of these groups of specs
That's a quick response. I'll look into the codes. Thanks!
On 6 Oct 2009, at 01:05, Laurent Sansonetti wrote:
Hi Linan,
Actually, we do use SELs to unify symbols (if you look at parse.y).
The Symbol class just inherits from NSString for convenience purposes.
The current code is far to be pe
Hi Linan,
Actually, we do use SELs to unify symbols (if you look at parse.y).
The Symbol class just inherits from NSString for convenience purposes.
The current code is far to be perfect but so far it works okay.
Laurent
On Oct 5, 2009, at 4:55 PM, Linan Wang wrote:
Hi,
I read a little bi
Hi,
I read a little bit source codes and found out that Symbol is
implemented on top of NSString. My question is if it's a better choice
to use SEL as the basis when objc is available? objc runtime takes
care of the registration and management. I guess using NSString class
is a decision wi
Another status update, covering about 2 weeks of development.
Highlights:
- Early backtracing support.
- Much better AOT compilation. Parts of the standard library are now
pre-compiled for testing.
- Migrated to LLVM top of tree.
- Dispatcher performance is now back to normal (we lost about 3
Hi Trevor,
Thanks for the report. It's very likely a bug in MacRuby 0.5. If you
are willing to create a test case that reproduces the problem we can
then investigate a fix.
Laurent
On Oct 3, 2009, at 4:52 AM, Trevor Hills wrote:
I have a small MacRuby/HotCocoa application that uses the
#362: Add Unit Testing and Embed MacRuby to Project Template
-+--
Reporter: dy...@… |Owner: eloy.de.en...@…
Type: enhancement | Status: closed
Priority: t
19 matches
Mail list logo
