| Milestone:
Component: MacRuby |Keywords:
--+-
macruby-0.6 > require 'rack/request'
/Users/aman/.rvm/gems/macruby-0.6/gems/rack-1.2.1/lib/rack/r
:
Component: MacRuby |Keywords:
--+-
{{{
macruby-0.6 > require 'sinatra'
TypeError: compared with non class/module
}}}
--
Ticket URL: <http://www.macruby.org
|Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes (by joshua.balla...@…):
* status: new => closed
* resolut
:
Component: MacRuby |Keywords:
--+-
Comment(by joshua.balla...@…):
This is due to Sinatra's use of Rack#release.
--
Ticket URL: <http://www.macruby.org/trac/ticket/808
:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
Same as .
--
Ticket URL: <http://www.macruby.org/trac/ticket/808#comment:2>
MacRuby <http://ma
: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by watson1...@…):
In dispatcher.cpp:
When removed flag of VM_BLOCK_THREAD from b
| Milestone: MacRuby 0.7
Component: MacRuby|Keywords:
---+
Using the nightly build dated July 21 on Mac OS X 10.6.4, when I try to
apply a cipher encryption to a string, I
: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by lsansone...@…):
Thanks for the detective work & patch! It seems clearer now.
Priority: major | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
I tried bundler on trunk, it fails inside the "thor&quo
|Milestone: MacRuby 0.7
Component: MacRuby| Resolution: fixed
Keywords: |
---+
Changes (by lsansone...@…):
* status: new => closed
* resolut
Priority: major | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
Working around the #caller bug, it seems to load properly, at
:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
The #release problem has been fixed in r4374, however, sinatra fails a bit
later in what seems to be the same
: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by watson1...@…):
With your patch,in the following conditions, I think that assertion
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by kyossi...@…):
Hi, I tried with trunk(rev4372) but rake failed again
#810: MacRuby can't install the nokogiri of rubygems.
--+-
Reporter: watson1...@… | Owner: lsansone...@…
Type: defect| Status: new
Priority: bl
#810: MacRuby can't install the nokogiri of rubygems.
--+-
Reporter: watson1...@… |Owner: lsansone...@…
Type: defect| Status: closed
Priority: bl
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by lsansone...@…):
Can you try a `rake clean' then a `rake' agai
: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Changes (by lsansone...@…):
* status: new => clo
| Milestone: MacRuby 0.7
Component: MacRuby|Keywords:
---+
I've verified that Trac 809 fixes an OpenSSL bug I ran into, but I'm
running into additional failures la
#810: MacRuby can't install the nokogiri of rubygems.
--+-
Reporter: watson1...@… |Owner: lsansone...@…
Type: defect| Status: reopened
Priority: bl
#810: MacRuby can't install the nokogiri of rubygems.
--+-
Reporter: watson1...@… |Owner: lsansone...@…
Type: defect| Status: closed
Priority: bl
#810: MacRuby can't install the nokogiri of rubygems.
--+-
Reporter: watson1...@… |Owner: lsansone...@…
Type: defect| Status: closed
Priority: bl
:
Component: MacRuby |Keywords:
--+-
Comment(by macr...@…):
Thanks. Is there a reason why this exception provides no backtrace?
{{{
$ macruby -rubygems -e' begin; re
:
Component: MacRuby |Keywords:
--+-
Comment(by macr...@…):
Using sinatra master (for caller fix) and yesterday's nightly (for
Rack.release fix), I am still unable to
:
Component: MacRuby |Keywords:
--+-
Comment(by macr...@…):
Looks like the assertion that's failing was part of the r4374 commit.
r4374 is also causing the following erro
:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
There is no backtrace because the exception comes from rubygems which has
been AOT compiled. In trunk we do
#808: sinatra does not load
--+-
Reporter: macr...@… |Owner: lsansone...@…
Type: defect| Status: closed
Priority: critical |Milestone: MacRuby
: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Comment(by watson1...@…):
Thank you for fixing this
ority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by watson1...@…):
This issue did not reproduce with r4379. Thank you! :)
--
T
ority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes (by lsansone...@…):
* status: new =>
Priority: blocker | Milestone:
Component: MacRuby |Keywords: irb
-+--
{{{
$ cat t.rb
toplevel = :ok
p local_variables
p eval('local_vari
Priority: blocker | Milestone:
Component: MacRuby |Keywords: irb
-+--
Comment(by eloy.de.en...@…):
FYI: There are specs inthe MacRuby repo in
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by kyossi...@…):
Hi thanks for your reply.
I attached output for rev
nsone...@…
Type: defect| Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
'
nsone...@…
Type: defect| Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comme
nsone...@…
Type: defect| Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comme
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by lsansone...@…):
I suspect our de-reclaration of the __cxa routines in v
nsone...@…
Type: defect| Status: closed
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Key
nsone...@…
Type: defect| Status: closed
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Key
|Milestone: MacRuby 0.7
Component: MacRuby| Resolution: fixed
Keywords: |
---+
Changes (by martinlagarde...@…):
* status: new => closed
* resolut
| Milestone: MacRuby 0.7
Component: MacRuby|Keywords:
---+
With latest MacRuby nightly (July 27), the following code causes a seg
fault if run directly from the command line
| Milestone: MacRuby 0.7
Component: MacRuby|Keywords:
---+
Old description:
> With latest MacRuby nightly (July 27), the following code causes a seg
> fault if run di
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by watson1...@…):
An error of "Couldn't create the encoder for macR
| Milestone: MacRuby 0.7
Component: MacRuby|Keywords:
---+
Running macrake without any argument results in a segmentation fault.
Macrake also fails on trivial rake files with the same
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by lsansone...@…):
I think it is probably better at this point to simply
ority: blocker | Milestone:
Component: MacRuby |Keywords: build Leopard
-+--
Comment(by kyossi...@…):
Thanks much for guys. I'll upgrade to SnowLeopard or us
ority: blocker |Milestone:
Component: MacRuby | Resolution: wontfix
Keywords: build Leopard|
-+--
Changes (by lsansone...@…):
* status:
| Milestone:
Component: MacRuby |Keywords:
--+-
I tried the following simple multi-threaded code snippet on MacRuby 0.6
(release build, obtained from http://www.macruby.org
|Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes (by lsansone...@…):
* status: new => closed
* resolution: =>
| Milestone:
Component: MacRuby|Keywords:
---+
Trying to use the "next" method of an external iterator showed the
following problem:
iMac:~ kenn
|Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Comment(by moo...@…):
I tried it with the latest nightly build and found it works fine
Priority: major| Milestone:
Component: MacRuby |Keywords: bitmap,NSBitmapImageRep,
@nsBitmapImageRepObj.bitmapData
Priority: major| Milestone:
Component: MacRuby |Keywords: bitmap,NSBitmapImageRep,
@nsBitmapImageRepObj.bitmapData
#281: Bundles pointing to local MacRuby installation instead of embedded
---+
Reporter: reb...@… |Owner:
lsansone...@…
Type: defect
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
As discussed with Laurent, it was hard to reduce the problem. Hence, here
are
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by lsansone...@…):
Just curious, does it still crash if you disable
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by martinlagarde...@…):
Replying to [comment:1 lsansone...@…]:
> J
| Milestone:
Component: MacRuby|Keywords:
---+
Comment(by watson1...@…):
It seems that the external iterator is not yet implemented.[[BR]]
The external
Priority: major | Milestone: MacRuby 0.6
Component: MacRuby |Keywords:
+---
When raise an Exception object in rescue block, the rescued object is
raised.
{{{
def
Priority: major | Milestone: MacRuby 0.6
Component: MacRuby |Keywords:
+---
Comment(by cheke...@…):
Before run the test, I changed the message in rescue block from
#281: Bundles pointing to local MacRuby installation instead of embedded
---+
Reporter: reb...@… |Owner:
lsansone...@…
Type: defect
#281: Bundles pointing to local MacRuby installation instead of embedded
---+
Reporter: reb...@… |Owner:
lsansone...@…
Type: defect
Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by watson1...@…):
An error occurs when pthread_mutex_
Priority: major |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
+---
Changes (by martinlagarde...@…):
* status: new
| Milestone:
Component: MacRuby|Keywords:
---+
Changes (by lsansone...@…):
* milestone: MacRuby 0.7 =>
Comment:
It crashes differently here.
{{{
(
| Milestone:
Component: MacRuby|Keywords:
---+
Comment(by lsansone...@…):
Nevermind, my copy of macruby was corrupted. I now get the real crash :-)
--
Ticket
| Milestone:
Component: MacRuby|Keywords:
---+
Comment(by lsansone...@…):
Reduction:
{{{
./miniruby -e "p readlines"
}}}
--
Ticket
|Milestone: MacRuby 0.7
Component: MacRuby| Resolution: fixed
Keywords: |
---+
Changes (by lsansone...@…):
* status: new => closed
* resolut
Priority: critical| Milestone:
Component: MacRuby |Keywords:
+---
Comment(by lsansone...@…):
I believe this problem only
s: closed
Priority: minor |Milestone:
Component: MacRuby | Resolution: wontfix
Keywords: |
+-
| Milestone:
Component: MacRuby |Keywords:
+---
Changes (by lsansone...@…):
* milestone: MacRuby 0.7 =>
Comment:
Well, I tried
| Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
MacRuby doesn't really honor the script encoding setting. It uses UTF-8 by
defaul
:
Component: MacRuby |Keywords:
+---
Comment(by lsansone...@…):
The header is indeed small and could be emulated. However, apparently we
already do ship an empty re.h file
: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
+---
Changes (by lsansone...@…):
* status: new => closed
* resolution: => fixed
* mil
losed
Priority: blocker |Milestone:
Component: MacRuby | Resolution: wontfix
Keywords:|
--+-
Changes (by lsansone...@…):
* s
|Milestone:
Component: MacRuby | Resolution: wontfix
Keywords:|
--+-
Changes (by lsansone...@…):
* status: new => clo
| Milestone:
Component: MacRuby|Keywords:
---+
Comment(by lsansone...@…):
Renamed summary accordingly.
--
Ticket URL: <http://www.macruby.org/trac/tic
#676: MacRuby 0.6 requires g++ 4.2 in Leopard
+---
Reporter: came...@… |Owner: lsansone...@…
Type: defect | Status: closed
Priority: critical
: major |Milestone: MacRuby 0.6
Component: MacRuby | Resolution: fixed
Keywords: |
+---
Changes (by lsansone...@…):
* status: new
Priority: major| Milestone:
Component: MacRuby |Keywords: bitmap,NSBitmapImageRep,
@nsBitmapImageRepObj.bitmapData
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Comment(by lsansone...@…):
Looks like Method#== is broken when used on Method
| Milestone:
Component: MacRuby |Keywords:
+---
Comment(by martinlagarde...@…):
Yep, still regexp1 and regexp2 both still crash
| Milestone:
Component: MacRuby |Keywords:
+---
Comment(by lsansone...@…):
Looks like it crashes during finalization.
Could you reduce
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Changes (by lsansone
:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
Array#hash is actually NSArray#hash which is... quite naive, it returns
the number of elements
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes (by
Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
When writing MacRuby we prefer to che
|Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Changes (by lsansone...@…):
* status: new => clo
Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by watson1...@…):
It is necessary for "t->stat
Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by watson1...@…):
Please forget the change o
|Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Comment(by martinlagarde...@…):
This looks fixed indeed
tus: closed
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes
Priority: major | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by lsansone...@…):
I wrote a simple gemfile
{{{
source "http://rubygem
: major |Milestone:
Component: MacRuby| Resolution: invalid
Keywords: |
---+
Changes (by lsansone...@…):
* status: new
#586: "macgem build" fails.
-+--
Reporter: r...@…|Owner: lsansone...@…
Type: defect | Status: closed
Priority: major|Milestone
|Milestone:
Component: MacRuby | Resolution: wontfix
Keywords: |
+---
Changes (by lsansone...@…):
* status: new => closed
* resolut
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
--+-
Comment(by watson1...@…):
With the following patch, it would be fixed. :D
Priority: blocker |Milestone: MacRuby 0.7
Component: MacRuby | Resolution: fixed
Keywords:|
--+-
Changes (by lsansone
#821: uncached ObjC stub - Abort trap
+---
Reporter: jazz...@… | Owner: lsansone...@…
Type: defect | Status: new
Priority: major | Milestone: MacRuby
#786: MacRuby does not finish when more exceptions is generated on same Thread
almost at the same time.
--+-
Reporter: watson1...@… | Owner: lsansone...@…
Type: defect
2301 - 2400 of 2454 matches
Mail list logo
