[MacRuby-devel] [MacRuby] #149: String concatenation loses encoding
#149: String concatenation loses encoding
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: critical| Milestone:
Component: MacRuby |Keywords:
+---
Concatening strings loses the encoding:[[BR]]
a = 'あ'[[BR]]
a.encoding # => #[[BR]]
(a+a).encoding # => #[[BR]]
('a'+a).encoding # => #[[BR]]
The encoding should be the same for all 3 (UTF-16).
--
Ticket URL: <http://www.macruby.org/trac/ticket/149>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #150: invalid strings with IO.pipe and readline
#150: invalid strings with IO.pipe and readline
--+-
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect| Status: new
Priority: major | Milestone:
Component: MacRuby |Keywords:
--+-
Test case:
{{{
#!/usr/local/bin/macruby
r, w = IO.pipe
w.write("test\r\n")
l = r.readline("\r\n")
puts l.chomp("\r\n").inspect # ruby1.9: "test", macruby: "test\r\n"
puts l.match("e")[0].inspect # ruby1.9: "e", macruby: " "
}}}
Calling readline on an IO.pipe stream with a delimiter causes really odd
strings to be returned, they don't behave correctly in a number of cases
including the two shown. Possibly an encoding issue?
--
Ticket URL: <http://www.macruby.org/trac/ticket/150>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application
#151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby|Keywords: ---+ This obviously happens because the code to be evaluated contains an error - local variable '''a''' is undefined - but as I see in objc.m, '''evaluateString''' should throw an exception, not crash the app. GBD cannot catch this bug somehow, this is all I get: Cannot access memory at address 0x2444c75f -- Ticket URL: <http://www.macruby.org/trac/ticket/151> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
An argument isn’t being marshalled properly to mutable array KVC
accessors.
{{{
class KVCTest
def initialize; @a = []; end
def countOfThings; @a.size; end
def objectInThingsAtIndex(i); @a[i]; end
end
KVCTest.new.valueForKey 'things'
irb(main):015:0> KVCTest.new.valueForKey 'things'
TypeError: no implicit conversion from nil to integer
from (irb):11:in `[]'
from (irb):11:in `objectInThingsAtIndex'
from bin/irb:12:in `'
}}}
Not sure why objectInThingsAtIndex: is getting a nil arg here.
--
Ticket URL: <http://www.macruby.org/trac/ticket/152>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: Component: MacRuby | Resolution: Keywords: | -+-- Comment(by [EMAIL PROTECTED]): This is really a method signature issue. -- Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:2> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker |Milestone:
Component: MacRuby | Resolution:
Keywords: |
-+--
Comment(by [EMAIL PROTECTED]):
Here’s the proposal from Rich:
{{{
kvo do
def countOfThings; 42; end
def objectInThingsAtIndex(i); "The Answer"; end
end
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:3>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #153: TypeError not raised for 'String + nil'
#153: TypeError not raised for 'String + nil' -+-- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor| Milestone: Component: MacRuby |Keywords: -+-- This is fairly minor since it's something that ought not to happen, except that both macirb and macruby lock up when it happens. This works (well, you get the expected error): >> "stuff" << nil TypeError: can't convert nil into String This does not: >> "stuff" + nil I end up having to kill it. I've tried it with both 0.3 and the latest testing branch. -- Ticket URL: <http://www.macruby.org/trac/ticket/153> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #153: TypeError not raised for 'String + nil'
#153: TypeError not raised for 'String + nil' -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: minor|Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: Fixed in #711/trunk. -- Ticket URL: <http://www.macruby.org/trac/ticket/153#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #154: Odd behavior with NSTableView
#154: Odd behavior with NSTableView
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: minor| Milestone:
Component: MacRuby |Keywords:
-+--
I'm trying to learn some Mac programming via MacRuby & Xcode, so I built
the project in the tutorial here:
http://developer.apple.com/mac/articles/scriptingautomation/cocoaappswithmacruby.html
(It's a good tutorial; perhaps it should be added to the examples unless
that's already been done.)
Just playing around I tried extending it by adding a 'phone number' field.
That worked fine until I attempted to do some formatting on the input.
If you're unfamiliar with the project, it builds a simpls NSTableView with
a few fields, a Controller class, and then a Friend class to store the
data (first name, last name, etc). Aside from adding a few lines to the
Controller class, I added a setter function to the Friend class.
Here's the setter function (comments stripped):
def setphone_no (p_no)
@phone_no=p_no.gsub(/[^\d]/,'')
if @phone_no.length > 10 # || p_no[0] == '+'
@phone_no = '+' << @phone_no
end
end
This mostly works, except in the following case. If a string is entered
into a field that is only digits, and longer than the limit (10), all that
gets displayed in the table is the "+". The field works okay if you
change the number after that. In fact, the number seems to be stored
okay; it's only being displayed properly that is the problem.
Adding the second test condition has no effect. However, strings which
fail the first test and pass the second are okay. It's only the ones that
are 'too long' that end up missing.
Strings that work:
The default string that gets passed from the Controller class :
"0123456789012" (but this does NOT work if typed in)
"+012345" (any string with a leading + (regardless of length if the second
condition is turned on))
"01234567890 12" (any long string with a non-numeric in it)
"0123456789" (any string of 10 or fewer digits)
Other things tried:
Using either attr_reader or a custom getter makes no difference.
I tried using a different attached marker ('INT' instead of '+') -
whatever the marker is is all that gets displayed for 'bad' strings.
No difference using ' vs. " or + vs. << to add the marker.
Changing the length limit affects the length of strings that will not get
displayed, but otherwise shows the same problem.
Changing the test condition order has no effect.
Looking at the console output using 'debugging' puts lines, the Friend
object always shows the entered value correctly (e.g. when updating the
table after another entry is changed). The class (when setting or
getting) shows up as NSMutableString.
This problem doesn't seem to show up when doing this without a GUI. I
pulled out what just the Friend class and made a simplified Controller
class, and it tested fine in macirb.
Project is attached.
--
Ticket URL: <http://www.macruby.org/trac/ticket/154>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed Comment: Fixed in r720 and r721. -- Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #127: implement Set using NSSet
#127: implement Set using NSSet -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: assigned Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * owner: [EMAIL PROTECTED] => [EMAIL PROTECTED] * status: new => assigned -- Ticket URL: <http://www.macruby.org/trac/ticket/127#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * milestone: => MacRuby 0.4 -- Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:5> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #155: arrays can'e be changed while being enumerated
#155: arrays can'e be changed while being enumerated ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: critical | Milestone: Component: MacRuby|Keywords: ---+ collections in ruby can be modified in place, but this is not allowed with NSMutableArray. rb_main.rb:22:in `NSApplicationMain': NSGenericException: *** Collection was mutated while being enumerated. (RuntimeError) -- Ticket URL: <http://www.macruby.org/trac/ticket/155> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application
#151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): I cannot reproduce this problem with the EmbeddedMacRuby example. Could you share your code, or give a full threaded backtrace from GDB? -- Ticket URL: <http://www.macruby.org/trac/ticket/151#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #145: PagePacker example locks up on exit if file is un-saved
#145: PagePacker example locks up on exit if file is un-saved -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: Component: MacRuby | Resolution: Keywords: | -+-- Comment(by [EMAIL PROTECTED]): I cannot reproduce your problem with MacRuby trunk. Maybe something changed in the meantime which fixed your bug? Could you retry to reproduce the problem with MacRuby trunk? -- Ticket URL: <http://www.macruby.org/trac/ticket/145#comment:1> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #147: HotCocoa failed to run on OSX 1.0.5.4 PPC arch
#147: HotCocoa failed to run on OSX 1.0.5.4 PPC arch --+- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect| Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords:| --+- Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.3 => MacRuby 0.4 -- Ticket URL: <http://www.macruby.org/trac/ticket/147#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #147: HotCocoa failed to run on OSX 1.0.5.4 PPC arch
#147: HotCocoa failed to run on OSX 1.0.5.4 PPC arch --+- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect| Status: new Priority: major |Milestone: MacRuby 1.0 Component: MacRuby | Resolution: Keywords:| --+- Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.4 => MacRuby 1.0 Comment: The PPC support is not very stable, which could explain why you're experiencing such problems. -- Ticket URL: <http://www.macruby.org/trac/ticket/147#comment:2> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object
---+
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major |Milestone: MacRuby 0.3
Component: MacRuby| Resolution:
Keywords: |
---+
Comment(by [EMAIL PROTECTED]):
This can actually be duplicated easily with something like the following:
{{{
module A
def initialize
super
end
end
class B
include A
end
B.new
}}}
I ran into this when trying to get Capistrano to run under MacRuby (since
Capistrano depends on Net::SSH, which depends on Ruby's Logger, which
depends on Monitor, etc.). I've tried digging through MacRuby to figure
out where the error is coming from, but my ruby-internals-fu is yet weak.
I'll keep digging, but hopefully someone smarter than me can figure this
out more quickly. :)
--
Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:2>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #156: macirb fails using Japanese locales
#156: macirb fails using Japanese locales
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major | Milestone: MacRuby 0.4
Component: MacRuby |Keywords:
+---
Using trunk(r721), macirb fails to start when LANG is ja_JP. including
ja_JP.UTF-8, ja_JP.SJIS, ja_JP.EUC.
{{{
[EMAIL PROTECTED](10033)$ export LANG=ja_JP.UTF-8
[EMAIL PROTECTED](10034)$ macirb
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/locale.rb:43:in
`String': wrong argument type NSObject (expected Data) (TypeError)
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/locale.rb:129:in
`real_load'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/locale.rb:120:in
`block in load'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/locale.rb:118:in
`each'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/locale.rb:118:in
`load'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/init.rb:120:in
`init_error'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb/init.rb:17:in
`setup'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/irb.rb:53:in
`start'
from /usr/local/bin/macirb:12:in `'
}}}
macirb has no apparent problems with other locales, such as zh_TW.UTF-8,
ko.UTF-8, en_US.UTF-8, etc.
--
Ticket URL: <http://www.macruby.org/trac/ticket/156>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #156: macirb fails using Japanese locales
#156: macirb fails using Japanese locales +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: | +--- Comment(by [EMAIL PROTECTED]): Probably related to a Ruby 1.9 issue * http://redmine.ruby-lang.org/issues/show/711 * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-core/19702 * http://blade.nagaokaut.ac.jp/cgi-bin/scat.rb/ruby/ruby-dev/37027 -- Ticket URL: <http://www.macruby.org/trac/ticket/156#comment:1> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #85: NKF doesn't work
#85: NKF doesn't work
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: minor|Milestone: MacRuby 0.4
Component: MacRuby | Resolution:
Keywords: |
-+--
Comment(by [EMAIL PROTECTED]):
Also true for
{{{
require 'kconv'
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/85#comment:2>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.3 Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): Just ran into the same issue when trying to use the xmlrpc std-lib, the parser instantiation causes an infinite loop on a super call from a mixin. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:3> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #75: 64-bit Support
#75: 64-bit Support ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker|Milestone: MacRuby 0.4 Component: MacRuby| Resolution: fixed Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed Comment: This is done in trunk since a few days now, closing. -- Ticket URL: <http://www.macruby.org/trac/ticket/75#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #74: DTrace / Instruments.app Support
#74: DTrace / Instruments.app Support ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker|Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): DTrace probes have been added in trunk since a few days, we still miss a usdt file to describe them for Instruments.app. -- Ticket URL: <http://www.macruby.org/trac/ticket/74#comment:2> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.3 => MacRuby 0.4 -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #144: require of hotcocoa fails on case sensitive file system
#144: require of hotcocoa fails on case sensitive file system ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: trivial|Milestone: Component: MacRuby| Resolution: Keywords: hotcocoa | ---+ Changes (by [EMAIL PROTECTED]): * owner: [EMAIL PROTECTED] => [EMAIL PROTECTED] -- Ticket URL: <http://www.macruby.org/trac/ticket/144#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #157: MacRuby/miniruby segfaults while building
#157: MacRuby/miniruby segfaults while building
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
While trying to build the latest MacRuby (r721) from a fresh checkout,
MacRuby segfaults with the following output:
{{{
$ rake
(in /Users/cypher/Projects/MacRuby)
mkdir -p .ext/include/universal-darwin9.0/ruby
cp include/ruby/config.h .ext/include/universal-darwin9.0/ruby
mv new_dtrace.h dtrace.h
mv miniprelude.c.new miniprelude.c
touch prelude.c
mv parse.c.new parse.c
rm -f parse.o
cp lex.c.blt lex.c
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0
/universal-darwin9.0/strscan.bundle: [BUG] Segmentation fault
MacRuby version 0.4 (ruby 1.9.0 2008-06-03) [universal-darwin9.0, x86_64]
-- stack frame
(0xc08120060): 0004
0001 (0xc08120068):
0002 (0xc08120070): 0004
0003 (0xc08120078):
0004 (0xc08120080): 800094180
0005 (0xc08120088): 8000a6920
0006 (0xc08120090): 8000906e0
0007 (0xc08120098): 800321840
0008 (0xc081200a0): 800092720
0009 (0xc081200a8): 800092660
0010 (0xc081200b0): 8000e0400
0011 (0xc081200b8): 0004
0012 (0xc081200c0): 8000907a0
0013 (0xc081200c8):
0014 (0xc081200d0): 0004
0015 (0xc081200d8): 80031e940
0016 (0xc081200e0): 0004
0017 (0xc081200e8):
0018 (0xc081200f0): 0004
0019 (0xc081200f8):
0020 (0xc08120100): 0004
0021 (0xc08120108):
0022 (0xc08120110): 0004
0023 (0xc08120118): c0812010a (= 21)
0024 (0xc08120120): 0004
0025 (0xc08120128): c0812011a (= 23)
0026 (0xc08120130): 0004
0027 (0xc08120138): 8000a92e0
0028 (0xc08120140): 0004
0029 (0xc08120148):
0030 (0xc08120150): 0004
0031 (0xc08120158): <- lfp <- dfp
-- control frame --
c:0010 p:-61284 s:0032 b:0032 l:31 d:31 TOP
c:0009 p: s:0030 b:0030 l:29 d:29 CFUNC :require
c:0008 p:0094 s:0026 b:0026 l:25 d:25 CLASS
/Users/cypher/Projects/MacRuby/lib/erb.rb:407
c:0007 p:0006 s:0024 b:0024 l:23 d:23 CLASS
/Users/cypher/Projects/MacRuby/lib/erb.rb:250
c:0006 p:0013 s:0022 b:0022 l:21 d:21 TOP
/Users/cypher/Projects/MacRuby/lib/erb.rb:249
c:0005 p: s:0020 b:0020 l:19 d:19 FINISH :set_encoding:
c:0004 p: s:0018 b:0018 l:17 d:17 CFUNC :require
c:0003 p:0165 s:0014 b:0014 l:13 d:13 TOP
tool/compile_prelude.rb:60
c:0002 p: s:0004 b:0004 l:03 d:03 FINISH :inherited:
c:0001 p: s:0002 b:0002 l:01 d:01 TOP
---
}}}
'ps -u' then show a miniruby instance ("./miniruby -I. -I./lib -rrbconfig
tool/compile_prelude.rb prelude.rb gem_prelude.rb prelude.c.new") just
hanging there, which has to be SIGKILLed (normal SIGTERM doesn't do
anything). Killing miniruby produces following additional output:
{{{
rake aborted!
Command failed with status (): [./miniruby -I. -I./lib -rrbconfig
tool/com...]
/Users/cypher/Projects/MacRuby/rakefile:509
(See full trace by running task with --trace)
}}}
The problem seems to have been introduced in the last two weeks, as
building worked fine before.
Running {{{rake --trace}}} produces the following output:
{{{
/usr/bin/ruby tool/compile_prelude.rb prelude.rb miniprelude.c.new
(in /Users/cypher/Projects/MacRuby)
** Invoke default (first_time)
** Invoke all (first_time)
** Invoke macruby (first_time)
** Invoke macruby:build (first_time)
** Invoke macruby:dylib (first_time)
** Invoke rbconfig (first_time)
** Invoke miniruby (first_time)
** Invoke objects (first_time)
** Invoke config_h (first_time)
** Execute config_h
** Invoke dtrace_h (first_time)
** Execute dtrace_h
** Execute objects
rm miniprelude.c.new
/usr/bin/bison -o y.tab.c parse.y
/usr/bin/sed -f ./tool/ytab.sed -e "/^#/s!y.tab.c!parse.c!" y.tab.c >
parse.c.new
mv parse.c.new parse.c
rm -f parse.o
cp lex.c.blt lex.c
/usr/bin/ruby -Ks tool/insns2vm.rb opt_sc.inc optinsn.inc optunifs.inc
insns.inc insns_info.inc vmtc.inc vm.inc
/usr/bin/ruby -n tool/node_name.rb include/ruby/node.h > node_name.inc
/usr/bin/gcc -I. -I./include -I/usr/include/libxml2 -arch i386 -arch
x86_64 -fno-common -pipe -O2 -g -Wall -Wno-parentheses -Wno-deprecated-
declarations -Werror -c array.c -o array.o
/usr/bin/gcc -I. -I./include -I/usr/include/libxml2 -arch i386 -arch
x86_64 -fno-common -pipe -O2 -g -Wall -Wno-parentheses -Wno-deprecated-
declarations -Werror -c bignum.c -o bignum.o
/usr/bin/gcc -I. -I./include -I/usr/include/libxml2 -arch i386 -arch
x86_64 -fno-common -pip
Re: [MacRuby-devel] [MacRuby] #157: MacRuby/miniruby segfaults while building
#157: MacRuby/miniruby segfaults while building
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker |Milestone:
Component: MacRuby | Resolution:
Keywords: |
-+--
Comment(by [EMAIL PROTECTED]):
As from the mailing list:
{{{
Rich and I got this problem a while ago, I was unable to find the root of
it and removing /Library/Frameworks/MacRuby.framework fixed it.
The problem was miniruby crashing when loading the strscan.bundle C
extension inside the dyld. I initially thought that it was a local issue
when copying the file but it looks like it is not.
I will try to reproduce it here. In the meantime I suspect that removing
/Library/Frameworks/MacRuby.framework should make it disappear.
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/157#comment:2>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #158: MacRuby tutorial comments
#158: MacRuby tutorial comments ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.3 Component: MacRuby|Keywords: tutorial ---+ Not sure if this is the right place, I noticed a couple things about the MacRuby tutorial, it says: >> "foo".class => NSCFString >> "foo".class.ancestors => [NSCFString, NSMutableString, NSString, Comparable, Object, NSObject, Kernel] With 0.3 it should be >> "foo".class => NSMutableString >> "foo".class.ancestors => [NSMutableString, NSMutableString, NSString, Comparable, NSObject, Kernel] Though, in 0.3, I'm not sure why NSMutableString is reported twice? Jim -- Ticket URL: <http://www.macruby.org/trac/ticket/158> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #158: MacRuby tutorial comments
#158: MacRuby tutorial comments
---+
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: minor |Milestone: MacRuby 0.4
Component: MacRuby| Resolution: fixed
Keywords: tutorial |
---+
Changes (by [EMAIL PROTECTED]):
* status: new => closed
* resolution: => fixed
* milestone: MacRuby 0.3 => MacRuby 0.4
Comment:
You're right, this was a bug in 0.3, which has been fixed in trunk since.
{{{
$ macirb
>> MACRUBY_VERSION
=> 0.4
>> 'foo'.class
=> NSMutableString
>> 'foo'.class.ancestors
=> [NSMutableString, NSString, Comparable, NSObject, Kernel]
>>
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/158#comment:1>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error
#159: "%d" with large integer argument gives conversion error
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major| Milestone:
Component: MacRuby |Keywords:
-+--
The following script reproduces the error easily:
{{{
N = 34363859232
p N
p N.class
puts "%d" % N
}}}
This results in the following exception:
{{{
01.rb:5:in `%': integer 34363859232 too big to convert to `int'
(RangeError)
}}}
When run in ruby 1.9, the output shows that N is a Bignum. When run in
macruby, the output shows that N is a fixnum. This appears to be due to
bignum.c line 523:
{{{
if (len <= (sizeof(long)*CHAR_BIT)) {
}}}
Apparently, in macruby, sizeof(long) is 8, which means bignums are only
instantiated for integers larger than 64 bits or so, and in the above
example, the integer is only 44 bits.
Even though the bignums are only created based on sizeof(long), the
rb_str_format function in sprintf.c uses FIX2LONG for converting the VALUE
to a long int, and FIX2LONG uses INT_MIN and INT_MAX to check the bounds
of the integer.
I'm not sure what the safest way to fix this is. Should check_int (and
others?) in numeric.c be comparing against larger boundary numbers,
instead of INT_MIN/MAX?
--
Ticket URL: <http://www.macruby.org/trac/ticket/159>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): The patch I just uploaded fixes the problem for me, but the implementation is...messy. I'll be happy to clean it up, but I wanted to get sign-off on whether this was even an appropriate way to approach the solution. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:5> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #157: MacRuby/miniruby segfaults while building
#157: MacRuby/miniruby segfaults while building -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: Component: MacRuby | Resolution: Keywords: | -+-- Comment(by [EMAIL PROTECTED]): Thanks, that fixed it. -- Ticket URL: <http://www.macruby.org/trac/ticket/157#comment:3> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): Thanks for the patch Jamis, it clearly demonstrates that the current mixin implementation suffers from problems. I have an idea to rewrite it by duplicating the module class and interposing it into the ancestors chain during include, I think it should fix this problem and also eliminate some of the dirty code paths in the VM. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:6> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Comment(by [EMAIL PROTECTED]): Sounds good. I was thinking something along those lines would be cleanest, but I'm not up to speed enough to tackle that. I'll keep hacking. Still trying to get Net::SSH to run under MacRuby. :) -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:7> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #160: Opening a TCPSocket causes GC exception
#160: Opening a TCPSocket causes GC exception
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major| Milestone:
Component: MacRuby |Keywords: ext socket
-+--
TCPSocket (perhaps other sockets, too, but TCPSocket for sure) apparently
doesn't like MacRuby (or vice-versa):
{{{
require 'socket'
TCPSocket.open('localhost', 22)
}}}
Results in an nasty exception:
{{{
y.rb:2: [BUG] destination 0x7fff5fbfe810 isn't in the auto zone
MacRuby version 0.4 (ruby 1.9.0 2008-06-03) [universal-darwin9.0, x86_64]
-- stack frame
(0xc08120060): 0004
0001 (0xc08120068):
0002 (0xc08120070): 0004
0003 (0xc08120078):
0004 (0xc08120080): 0004
0005 (0xc08120088):
0006 (0xc08120090): 100396320
0007 (0xc08120098): 800088a20
0008 (0xc081200a0): 002d
0009 (0xc081200a8): 0004
0010 (0xc081200b0):
0011 (0xc081200b8): 0004
0012 (0xc081200c0): <- lfp <- dfp
-- control frame --
c:0005 p: s:0013 b:0013 l:12 d:12 CFUNC :initialize:
c:0004 p: s:0011 b:0011 l:10 d:10 CFUNC :open
c:0003 p:0027 s:0006 b:0006 l:05 d:05 TOPy.rb:2
c:0002 p: s:0004 b:0004 l:03 d:03 FINISH :inherited:
c:0001 p: s:0002 b:0002 l:01 d:01 TOP
---
DBG> : "y.rb:2:in `initialize:'"
DBG> : "y.rb:2:in `open'"
DBG> : "y.rb:2:in `'"
-- backtrace of native function call (Use addr2line) --
0x1001095d1
0x100028c14
0x100028cf8
0x10003b735
0x10010a756
0x1046051e7
0x1046053b1
0x10460569e
0x10002cd9f
0x1046057a8
0x10460581b
0x1000ffc3f
0x1001000da
0x10010390e
0x100061da1
0x10004569e
0x1001048a7
0x1000f973b
0x1000fe622
0x1000fe8ac
0x10002c632
0x10002f9e7
0x10f1f
0x10ea4
0x2
-------
Abort trap
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/160>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #160: Opening a TCPSocket causes GC exception
#160: Opening a TCPSocket causes GC exception -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major|Milestone: Component: MacRuby | Resolution: Keywords: ext socket | -+-- Comment(by [EMAIL PROTECTED]): I managed to track it down to rb_fd_init in thread.c, the call to GC_WB, when rb_fd_init is called via wait_connectable in socket.c, called via ruby_connect (also in socket.c). I'm afraid I don't know the auto_zone API at all, so I'm unsure of how to proceed, but maybe this will save someone a little time investigating. -- Ticket URL: <http://www.macruby.org/trac/ticket/160#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #160: Opening a TCPSocket causes GC exception
#160: Opening a TCPSocket causes GC exception -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: major|Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: ext socket | -+-- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: Good catch, the problem is in socket.c:1072, which should pass a pointer to the auto zone. I fixed it in r737/trunk. But this will anyway be addressed once we rewrite the IO system. Currently there are too many problems with IO due to the way we handle byte strings. Thanks for harnessing MacRuby :-) -- Ticket URL: <http://www.macruby.org/trac/ticket/160#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #159: "%d" with large integer argument gives conversion error
#159: "%d" with large integer argument gives conversion error
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major|Milestone:
Component: MacRuby | Resolution:
Keywords: |
-+--
Comment(by [EMAIL PROTECTED]):
At a glance it looks like the problem is in the way we convert the
argument to a C_INT type, to pass to the CFStringCreateWithFormat
function, in the objc.m file - rb_str_format().
Instead of trying to convert big fixnums or bignums to C_INT we should
instead take a different code path and print every digit out of the
numeric type.
This easily reproduces when trying to print a bignum:
{{{
$ ./miniruby -e "p '%d' % (42**12)"
-e:1:in `%': bignum too big to convert into `long' (RangeError)
from -e:1:in `'
$
}}}
(sprintf.c is mostly unused in MacRuby, because we rely on CF for this.)
--
Ticket URL: <http://www.macruby.org/trac/ticket/159#comment:1>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #134: require 'rexml/document' fails
#134: require 'rexml/document' fails
+---
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major |Milestone:
Component: MacRuby | Resolution:
Keywords: |
+---
Comment(by [EMAIL PROTECTED]):
Here is a reduction of the bug causing the failure:
{{{
module A
module B
CONST1 = "cool"
end
module C
include B
end
class D
include C
CONST2 = CONST1
end
end
}}}
Hope it'll help.
--
Ticket URL: <http://www.macruby.org/trac/ticket/134#comment:2>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #161: `macgem install` fails for the "wirble" gem
#161: `macgem install` fails for the "wirble" gem
--+-
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect| Status: new
Priority: minor | Milestone:
Component: MacRuby |Keywords:
--+-
Not sure what the state of macgem is, and what is necessary to make a gem
compatible with macruby as opposed to normal Ruby, but I was trying to get
my normal irb working environment compatible with macirb, and I ran across
this problem:
{{{
[Thu Nov 13 - 02:18:58] [elliottcable @ Geoffrey] [~/Code/] [ - ]
-- sudo macgem install wirble
Password:
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/net/http.rb:576:
[BUG] destination 0x7fff5fbfdaa0 isn't in the auto zone
MacRuby version 0.4 (ruby 1.9.0 2008-06-03) [universal-darwin9.0, x86_64]
-- stack frame
(0xc08120060): 0004
0001 (0xc08120068):
0002 (0xc08120070): 0004
0003 (0xc08120078):
0004 (0xc08120080): 80040a280
0005 (0xc08120088): 8003508a0
0006 (0xc08120090): 0004
0007 (0xc08120098): 0004
0008 (0xc081200a0):
0009 (0xc081200a8): 8003a02e0
0010 (0xc081200b0): 8003508a0
0011 (0xc081200b8): 80034f060
0012 (0xc081200c0): 8004359c0
0013 (0xc081200c8): 0004
0014 (0xc081200d0): 0004
0015 (0xc081200d8):
0016 (0xc081200e0): 8004359c0
0017 (0xc081200e8): 800087c40
0018 (0xc081200f0): 0004
0019 (0xc081200f8): 0004
0020 (0xc08120100):
0021 (0xc08120108): 0004
0022 (0xc08120110): 800087c40
0023 (0xc08120118): 80007b3c0
0024 (0xc08120120): 8007bf160
0025 (0xc08120128): 80007b600
0026 (0xc08120130):
0027 (0xc08120138): 8007bf160
0028 (0xc08120140): 800973400
0029 (0xc08120148): 0004
0030 (0xc08120150):
0031 (0xc08120158): 0004
0032 (0xc08120160): 8003cd480
0033 (0xc08120168): 80092a400
0034 (0xc08120170): 0001
0035 (0xc08120178): 0004
0036 (0xc08120180): 0004
0037 (0xc08120188):
0038 (0xc08120190): 8003c9800
0039 (0xc08120198): 0004
0040 (0xc081201a0): c0821fd08
0041 (0xc081201a8): 8000aaca0
0042 (0xc081201b0): 800499d60
0043 (0xc081201b8): 0004
0044 (0xc081201c0): 0004
0045 (0xc081201c8): c08120188 (= 37)
0046 (0xc081201d0): 800499d60
0047 (0xc081201d8): 8000aaca0
0048 (0xc081201e0): 80078ba40
0049 (0xc081201e8): 0004
0050 (0xc081201f0): 0004
0051 (0xc081201f8): 0004
0052 (0xc08120200):
0053 (0xc08120208): 0004
0054 (0xc08120210): 8000aaca0
0055 (0xc08120218): 80078ba40
0056 (0xc08120220): 0004
0057 (0xc08120228): 8000aaca0
0058 (0xc08120230): 8003bdec0
0059 (0xc08120238): 800496860
0060 (0xc08120240): 0004
0061 (0xc08120248): 0004
0062 (0xc08120250):
0063 (0xc08120258): 0004
0064 (0xc08120260): 800496860
0065 (0xc08120268): 8003bbe00
0066 (0xc08120270): 8003ae820
0067 (0xc08120278):
0068 (0xc08120280): 0004
0069 (0xc08120288): 0004
0070 (0xc08120290): 0004
0071 (0xc08120298):
0072 (0xc081202a0): 104ddefd0
0073 (0xc081202a8): 8003aa3e0
0074 (0xc081202b0): 0004
0075 (0xc081202b8):
0076 (0xc081202c0): 0004
0077 (0xc081202c8):
0078 (0xc081202d0): 0004
0079 (0xc081202d8):
0080 (0xc081202e0): 800488aa0
0081 (0xc081202e8):
0082 (0xc081202f0): 0004
0083 (0xc081202f8):
0084 (0xc08120300): 800088060
0085 (0xc08120308): 0004
0086 (0xc08120310): c0821f918
0087 (0xc08120318): 80032d9a0
0088 (0xc08120320): 80046ecc0
0089 (0xc08120328): 0004
0090 (0xc08120330): c081202f8 (= 83)
0091 (0xc08120338): 80046ecc0
0092 (0xc08120340): 80032d9a0
0093 (0xc08120348):
0094 (0xc08120350): 8b3c0
0095 (0xc08120358): 0004
0096 (0xc08120360): 0004
0097 (0xc08120368): 0004
0098 (0xc08120370): 0004
0099 (0xc08120378):
0100 (0xc08120380): 800457c40
0101 (0xc08120388): 8b3c0
0102 (0xc08120390): 80049e920
0103 (0xc08120398): 8004e8140
0104 (0xc081203a0): 0004
0105 (0xc081203a8): 0004
0106 (0xc081203b0): 0004
0107 (0xc081203b8):
0108 (0xc081203c0): 80049e920
0109 (0xc081203c8): 8004e8140
0110 (0xc081203d0): 0004
0111 (0xc081203d8): 0004
0112 (0xc081203e0): 0004
0113 (0xc081203e8): 0004
0114 (0xc081203f0):
0115 (0xc081203f8): 0004
0116 (0xc08120400): 0004
0117 (0xc08120408): c0821f678
0118 (0xc08120410): 0004
0119 (0xc08120418): 0004
0120 (0xc08120420):
0121 (0xc08120428): 0004
0122 (0xc08120430): 0004
0123 (0xc08120438): 0004
0124 (0xc08120440): 0004
0125 (0xc08120448): 0004
0126 (0xc08120450):
Re: [MacRuby-devel] [MacRuby] #127: implement Set using NSSet
#127: implement Set using NSSet -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: assigned => closed * resolution: => fixed Comment: Let’s call this done, in r722, r723, r738 and r741. Still some tests to pass, but this is pretty close. As per my discussion w/Laurent, there are some methods still left in set.rb, at least for now. -- Ticket URL: <http://www.macruby.org/trac/ticket/127#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: reopened Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: closed => reopened * resolution: fixed => Comment: Fixed key names in r743. -- Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:6> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #152: KVC arguments not properly marshalled
#152: KVC arguments not properly marshalled
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: blocker |Milestone: MacRuby 0.4
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Changes (by [EMAIL PROTECTED]):
* status: reopened => closed
* resolution: => fixed
Comment:
For posterity, the final syntax is:
{{{
class MathFacts
kvo_array :firstTenSquares do
def size; 10; end
def [](i); (i+1)*(i+1); end
end
end
>> MathFacts.new.valueForKey 'firstTenSquares'
=> [1, 4, 9, 16, 25, 36, 49, 64, 81, 100]
}}}
and similar for kvo_set.
--
Ticket URL: <http://www.macruby.org/trac/ticket/152#comment:7>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #162: Lack of support of selectors in BridgeSupport
#162: Lack of support of selectors in BridgeSupport +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- When I run http://pastie.org/315934 and I press a button the application crashes: http://pastie.org/315935 Laurent told it was because selectors are not yet supported in BridgeSupport. There is a work around specifying the signature of the callback with method_signature but we should not have to do it. -- Ticket URL: <http://www.macruby.org/trac/ticket/162> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #163: macruby_main forces a relative path
#163: macruby_main forces a relative path --+- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: enhancement | Status: new Priority: minor | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: --+- Sometimes it makes sense to load a script from a path external to the main bundle (say, inside an input manager or something), but macruby_main automatically prepends the main bundle's resource path, making the use of absolute paths (via ../../ etc) extremely hackish. My proposed solution is also hackish, but it works. Simply check to see if the path starts with a "/" and don't prepend the resource folder path if that's the case. '''objc.m:2819''' s/&p1[2]/(path[0] != '/') ? &p1[2] : "" -- Ticket URL: <http://www.macruby.org/trac/ticket/163> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: crash,cfequal +--- Cocoa application built using MacRuby r746 on OS 10.5.5 with a Core 2 Duo MBP with 4GB of RAM. I am invoking a ruby proc using performRubySelector as follows: callSelector = @selector(call:); proc = [[MacRuby sharedRuntime] evaluateString:[NSString stringWithFormat:@"proc %@", source]]; return [proc performRubySelector:callSelector withArguments:_arg1_,_arg2_,nil]; in this case I am passing two Objective-C objects, part of my application data model, into the proc. The source of the proc is: do |generateTool,player| if rand < 0.5 generateTool.directionKnob.value = 1 else generateTool.directionKnob.value = 5 end end At some point the application crashes with the following stack trace: (gdb) thread apply all bt Thread 6 (process 59831 thread 0x6f17): #0 0x9063c68e in __semwait_signal () #1 0x90667986 in _pthread_cond_wait () #2 0x9066736d in pthread_cond_wait$UNIX2003 () #3 0x900db692 in -[NSCondition wait] () #4 0x9009402a in -[NSObject(NSThreadPerformAdditions) performSelector:onThread:withObject:waitUntilDone:modes:] () #5 0x900e7648 in -[NSObject(NSThreadPerformAdditions) performSelectorOnMainThread:withObject:waitUntilDone:] () #6 0x0001cf7e in -[ELTool run:] (self=0x22afa80, _cmd=0x96884ee0, _playhead_=0x0) at /Users/matt/Projects/LucidMac/Elysium/src/tools/ELTool.m:83 #7 0x87bc in -[ELLayer pulse] (self=0x2246630, _cmd=0x2b27f) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:245 #8 0x7f9f in -[ELLayer run] (self=0x2246630, _cmd=0x96884a24) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:155 #9 0x81ca in -[ELLayer runLayer] (self=0x2246630, _cmd=0x2b203) at /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:177 #10 0x90093bad in -[NSThread main] () #11 0x90093754 in __NSThread__main__ () #12 0x90f5 in _pthread_start () #13 0x906665b2 in thread_start () Thread 5 (process 59831 thread 0x5403): #0 0x9063c68e in __semwait_signal () #1 0x9063c50f in nanosleep$UNIX2003 () #2 0x002ec71e in thread_timer (dummy=0x0) at thread_pthread.c:571 #3 0x90f5 in _pthread_start () #4 0x906665b2 in thread_start () Thread 4 (process 59831 thread 0x4d03): #0 0x906354a6 in mach_msg_trap () #1 0x9063cc9c in mach_msg () #2 0x00098f0f in XServerMachPort::ReceiveMessage () #3 0x0008b477 in MIDIInPortThread::Run () #4 0x0008f07d in XThread::RunHelper () #5 0x000999ee in CAPThread::Entry () #6 0x90f5 in _pthread_start () #7 0x906665b2 in thread_start () Thread 3 (process 59831 thread 0x3d03): #0 0x906354a6 in mach_msg_trap () #1 0x9063cc9c in mach_msg () #2 0x011a7c39 in __ape_agent () #3 0x90f5 in _pthread_start () #4 0x906665b2 in thread_start () Thread 2 (process 59831 thread 0x2a03): #0 0x9063c68e in __semwait_signal () #1 0x90667986 in _pthread_cond_wait () #2 0x9066736d in pthread_cond_wait$UNIX2003 () #3 0x93f36bcf in auto_collection_thread () #4 0x90f5 in _pthread_start () #5 0x906665b2 in thread_start () Thread 1 (process 59831 thread 0x10b): #0 0x92fce036 in CFEqual () #1 0x900b917f in -[NSKeyValueUnnestedProperty _keyPathIfAffectedByValueForKey:exactMatch:] () #2 0x900b9015 in -[NSKeyValueUnnestedProperty keyPathIfAffectedByValueForKey:exactMatch:] () #3 0x9008fe81 in -[NSObject(NSKeyValueObserverNotification) willChangeValueForKey:] () #4 0x9016c96d in _NSSetIntValueAndNotify () #5 0x903dc1dd in .LCFI1 () #6 0x903dc771 in ffi_call () #7 0x002fd3e0 in rb_objc_call2 (recv=36326752, klass=501521904, sel=0x1283530, imp=0x9016c8f0 <_NSSetIntValueAndNotify>, sig=0x202e630, bs_method=0x0, argc=1, argv=0x14e0058) at objc.m:1296 #8 0x002e64d3 in vm_call_method (th=0x203b6b0, cfp=0x155ff50, num=1, blockptr=0x0, flag=97, id=, recv=36326752, klass=501521904, mcache=0x202e620) at vm_insnhelper.c:662 #9 0x002d6759 in vm_eval (th=0x203b6b0, initial=) at insns.def:1067 #10 0x002e0f6b in vm_eval_body (th=0x203b6b0) at vm.c:1033 #11 0x002e14db in vm_invoke_proc (th=0x203b6b0, proc=0x22a3530, self=3376, argc=1, argv=0xbfffe5b0, blockptr=0x0) at vm.c:449 #12 0x0020ab6f in proc_call (argc=1, argv=0x1, procval=1) at proc.c:506 #13 0x002cf035 in call_cfunc (func=0x20ab10 , recv=36301072, len=, argc=1, argv=0xbfffe5b0) at vm_insnhelper.c:289 #14 0x002e2539 in vm_call0 (th=0x203b6b0, klass=19322032, recv=36301072, id=128335, oid=4, argc=1, argv=0xbfffe5b0, body=0x2069c40, nosuper=0) at vm_eval.c:75
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: crash,cfequal | +--- Comment(by [EMAIL PROTECTED]): Well that mangled the formatting quite nicely. For a clean version check [http://gist.github.com/26119 here]. -- Ticket URL: <http://www.macruby.org/trac/ticket/164#comment:1> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: crash,cfequal | +--- Old description: > Cocoa application built using MacRuby r746 on OS 10.5.5 with a Core 2 Duo > MBP with 4GB of RAM. > > I am invoking a ruby proc using performRubySelector as follows: > > callSelector = @selector(call:); > proc = [[MacRuby sharedRuntime] evaluateString:[NSString > stringWithFormat:@"proc %@", source]]; > return [proc performRubySelector:callSelector > withArguments:_arg1_,_arg2_,nil]; > > in this case I am passing two Objective-C objects, part of my application > data model, into the proc. The source of the proc is: > > do |generateTool,player| > if rand < 0.5 > generateTool.directionKnob.value = 1 > else > generateTool.directionKnob.value = 5 > end > end > > At some point the application crashes with the following stack trace: > > (gdb) thread apply all bt > > Thread 6 (process 59831 thread 0x6f17): > #0 0x9063c68e in __semwait_signal () > #1 0x90667986 in _pthread_cond_wait () > #2 0x9066736d in pthread_cond_wait$UNIX2003 () > #3 0x900db692 in -[NSCondition wait] () > #4 0x9009402a in -[NSObject(NSThreadPerformAdditions) > performSelector:onThread:withObject:waitUntilDone:modes:] () > #5 0x900e7648 in -[NSObject(NSThreadPerformAdditions) > performSelectorOnMainThread:withObject:waitUntilDone:] () > #6 0x0001cf7e in -[ELTool run:] (self=0x22afa80, _cmd=0x96884ee0, > _playhead_=0x0) at > /Users/matt/Projects/LucidMac/Elysium/src/tools/ELTool.m:83 > #7 0x87bc in -[ELLayer pulse] (self=0x2246630, _cmd=0x2b27f) at > /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:245 > #8 0x7f9f in -[ELLayer run] (self=0x2246630, _cmd=0x96884a24) at > /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:155 > #9 0x81ca in -[ELLayer runLayer] (self=0x2246630, _cmd=0x2b203) at > /Users/matt/Projects/LucidMac/Elysium/src/datamodel/ELLayer.m:177 > #10 0x90093bad in -[NSThread main] () > #11 0x90093754 in __NSThread__main__ () > #12 0x90f5 in _pthread_start () > #13 0x906665b2 in thread_start () > > Thread 5 (process 59831 thread 0x5403): > #0 0x9063c68e in __semwait_signal () > #1 0x9063c50f in nanosleep$UNIX2003 () > #2 0x002ec71e in thread_timer (dummy=0x0) at thread_pthread.c:571 > #3 0x90f5 in _pthread_start () > #4 0x906665b2 in thread_start () > > Thread 4 (process 59831 thread 0x4d03): > #0 0x906354a6 in mach_msg_trap () > #1 0x9063cc9c in mach_msg () > #2 0x00098f0f in XServerMachPort::ReceiveMessage () > #3 0x0008b477 in MIDIInPortThread::Run () > #4 0x0008f07d in XThread::RunHelper () > #5 0x000999ee in CAPThread::Entry () > #6 0x90f5 in _pthread_start () > #7 0x906665b2 in thread_start () > > Thread 3 (process 59831 thread 0x3d03): > #0 0x906354a6 in mach_msg_trap () > #1 0x9063cc9c in mach_msg () > #2 0x011a7c39 in __ape_agent () > #3 0x90f5 in _pthread_start () > #4 0x906665b2 in thread_start () > > Thread 2 (process 59831 thread 0x2a03): > #0 0x9063c68e in __semwait_signal () > #1 0x90667986 in _pthread_cond_wait () > #2 0x9066736d in pthread_cond_wait$UNIX2003 () > #3 0x93f36bcf in auto_collection_thread () > #4 0x90f5 in _pthread_start () > #5 0x906665b2 in thread_start () > > Thread 1 (process 59831 thread 0x10b): > #0 0x92fce036 in CFEqual () > #1 0x900b917f in -[NSKeyValueUnnestedProperty > _keyPathIfAffectedByValueForKey:exactMatch:] () > #2 0x900b9015 in -[NSKeyValueUnnestedProperty > keyPathIfAffectedByValueForKey:exactMatch:] () > #3 0x9008fe81 in -[NSObject(NSKeyValueObserverNotification) > willChangeValueForKey:] () > #4 0x9016c96d in _NSSetIntValueAndNotify () > #5 0x903dc1dd in .LCFI1 () > #6 0x903dc771 in ffi_call () > #7 0x002fd3e0 in rb_objc_call2 (recv=36326752, klass=501521904, > sel=0x1283530, imp=0x9016c8f0 <_NSSetIntValueAndNotify>, sig=0x202e630, > bs_method=0x0, argc=1, argv=0x14e0058) at objc.m:1296 > #8 0x002e64d3 in vm_call_method (th=0x203b6b0, cfp=0x155ff50, num=1, > blockptr=0x0, flag=97, id= optimizations>, recv=36326752, klass=501521904, mcache=0x202e620) at > vm_insnhelper.c:662 > #9 0x002d6759 in vm_eval (th=0x203b6b0, initial= unavailable, due to optimizations>) at insns.def:1067 > #10 0x002e0f6b in vm_eval_b
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: crash,cfequal | +--- Comment(by [EMAIL PROTECTED]): So the problem is related to KVO. When I add KVO notifications to the object being manipulated by the Ruby code it explodes, remove the addObserver call and everything is fine. Unfortunately in my real-life case the KVO is essential for that property so I can't work around it. -- Ticket URL: <http://www.macruby.org/trac/ticket/164#comment:3> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #165: MacRuby broken on 10.5
#165: MacRuby broken on 10.5
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone: MacRuby 0.4
Component: MacRuby |Keywords: crash,bridge support,gc
+---
I just got a bug report from a tester about Elysium (which embed MacRuby
r746) and he has a new crash:
{{{
Process: Elysium [7269]
Path:/Users/stu/Downloads/Elysium.app/Contents/MacOS/Elysium
Identifier: com.lucidmac.Elysium
Version: ??? (0.7.9.9)
Code Type: X86 (Native)
Parent Process: launchd [109]
Date/Time: 2008-11-19 12:26:03.366 +
OS Version: Mac OS X 10.5.5 (9F33)
Report Version: 6
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Exception Codes: 0x0002, 0x
Crashed Thread: 0
Application Specific Information:
objc[7269]: garbage collection is ON
*** Terminating app due to uncaught exception 'RuntimeError', reason:
'dlopen(/System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib,
1): no suitable image found. Did find:
/System/Library/Frameworks/CoreFoundation.framework/Resources/BridgeSupport/CoreFoundation.dylib:
GC capability mismatch'
Thread 0 Crashed:
0 com.apple.CoreFoundation0x9278bff4
___TERMINATING_DUE_TO_UNCAUGHT_EXCEPTION___ + 4
1 libobjc.A.dylib 0x92afee3b objc_exception_throw +
40
2 com.apple.CoreFoundation0x9278bc71 -[NSException raise] +
17
3 libmacruby.1.9.0.dylib 0x002f4978
rb_raise_ruby_exc_in_objc + 344
4 libmacruby.1.9.0.dylib 0x002f4aa0 evaluateString_rescue +
16
5 libmacruby.1.9.0.dylib 0x002053a3 rb_rescue2 + 435
6 libmacruby.1.9.0.dylib 0x002f4af8 -[MacRuby
evaluateString:] + 72
7 com.lucidmac.Elysium0x00016467 -[ElysiumController
initMacRuby] + 292
8 com.lucidmac.Elysium0x0001633d -[ElysiumController
awakeFromNib] + 72
9 com.apple.CoreFoundation0x9279a955 -[NSSet
makeObjectsPerformSelector:] + 181
10 com.apple.AppKit0x94c7caca -[NSIBObjectData
nibInstantiateWithOwner:topLevelObjects:] + 1533
11 com.apple.AppKit0x94c72cf6 loadNib + 264
12 com.apple.AppKit0x94c72658
+[NSBundle(NSNibLoading)
_loadNibFile:nameTable:withZone:ownerBundle:] + 946
13 com.apple.AppKit0x94c7229b
+[NSBundle(NSNibLoading)
loadNibFile:externalNameTable:withZone:] + 171
14 com.apple.AppKit0x94c721d9
+[NSBundle(NSNibLoading)
loadNibNamed:owner:] + 391
15 com.apple.AppKit0x94c71e88 NSApplicationMain + 434
16 com.lucidmac.Elysium0x2670 main + 30
17 com.lucidmac.Elysium0x2626 start + 54
}}}
Talking with Alloy we think the difference is that on my machine I have
built and installed MacRuby which means that the rake task for fixing the
bridge support dylibs has been run, whereas on his machine (since he just
gems my embedded MacRuby) it has not.
This would appear to mean that any application embedding MacRuby will be
broken on 10.5
--
Ticket URL: <http://www.macruby.org/trac/ticket/165>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: MacRuby broken on 10.5
#165: MacRuby broken on 10.5 -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: Keywords: crash,bridge support,gc | -+-- Comment(by [EMAIL PROTECTED]): Typo: I meant "(since he just gets my embedded MacRuby)" above. -- Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files (was: MacRuby broken on 10.5)
#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: crash,bridge support,gc +--- Comment(by [EMAIL PROTECTED]): Indeed, that's a serious problem, good catch! I guess the solution will be to embed these .dylib files inside the framework (MacRuby.framework/Resources/BridgeSupport/*.dylib) and modify MacRuby core to look there in priority. -- Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #166: Bus error when installing gem
#166: Bus error when installing gem --+- Reporter: [EMAIL PROTECTED]| Owner: [EMAIL PROTECTED] Type: defect| Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: --+- Whenever I try to install a Gem macruby crashes with a bus error. I attached a strack trace for when I tried to install the Amazon S3 gem. -- Ticket URL: <http://www.macruby.org/trac/ticket/166> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: crash,cfequal +--- Changes (by [EMAIL PROTECTED]): * owner: [EMAIL PROTECTED] => [EMAIL PROTECTED] Comment: My bet is that this is caused by the automagic subclasses that KVO inserts. -- Ticket URL: <http://www.macruby.org/trac/ticket/164#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #142: Infinite loop creating new Monitor object
#142: Infinite loop creating new Monitor object ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: fixed Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed Comment: So I have been investigating different solutions to re-implement the mixin feature, but I was unsuccessful. My first attempt was to create intermediate classes and interpose them inside the ancestor chain, but this causes some problem with the 64-bit libobjc runtime (which does not authorize you to change the superclass of NSObject), it requires to allocate a complete class-pair (both the class and its metaclass) every time, and it does not work if you extend a singleton class. My second attempt was to monkey-patch the libobjc method lookup functionality to also look inside mixed modules at runtime. This was working but I could not make it stable (and also it's really evil). This was just to experiment a potential change that I would submit to the libobjc guys. My third attempt was the successful one, I basically used a solution very similar to Jamis' patch and removed the unnecessary code paths. When dispatching the super message we no longer forward it to the real superclass but use the Ruby ancestors chain. The problem should be fixed in r750. -- Ticket URL: <http://www.macruby.org/trac/ticket/142#comment:8> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #167: Autoload throws an exception at the second call
#167: Autoload throws an exception at the second call
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: critical| Milestone:
Component: MacRuby |Keywords:
+---
The second call to autoload always throws an exception:
{{{
./miniruby -e 'autoload :A, "a";autoload :B, "b"'
-e:1:in `autoload': wrong argument type NSObject (expected Data)
(TypeError)
from -e:1:in `'
}}}
The first call to rb_autoload creates and saves an autoload_table, but it
seems the type of the table (NSObject) is not what the second call to
rb_autoload is waiting for (it wants a Data). The check is on the first
line of check_autoload_table (all of those functions are in variable.c).
--
Ticket URL: <http://www.macruby.org/trac/ticket/167>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #162: Lack of support of selectors in BridgeSupport
#162: Lack of support of selectors in BridgeSupport +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: major |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | +--- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: A fix has been committed as part of r753. -- Ticket URL: <http://www.macruby.org/trac/ticket/162#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #168: NSNotFound is different from returned values
#168: NSNotFound is different from returned values
-+--
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
-+--
Code:
{{{
s = 'test'
r = s.rangeOfString 'abc'
puts r.location
puts NSNotFound
}}}
Output:
{{{
9223372036854775807
2147483647
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/168>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #167: Autoload throws an exception at the second call
#167: Autoload throws an exception at the second call +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: critical|Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | +--- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: Fixed in r755/trunk. -- Ticket URL: <http://www.macruby.org/trac/ticket/167#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #168: NSNotFound is different from returned values
#168: NSNotFound is different from returned values -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: There were 2 problems: 1) the BS parser does not take into account the value64 field in 64-bit mode 2) the value64 field for NSNotFound is incorrect in Foundation.bridgesupport. 1) was fixed and 2) was temporarily work-around'ed (it will be fixed in a future Mac OS X release) in r756/trunk. -- Ticket URL: <http://www.macruby.org/trac/ticket/168#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: crash,cfequal +--- Changes (by [EMAIL PROTECTED]): * owner: [EMAIL PROTECTED] => [EMAIL PROTECTED] Comment: A temporary fix has been committed as r758. I will improve this fix later. Let me know if it fixes your problem. -- Ticket URL: <http://www.macruby.org/trac/ticket/164#comment:5> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #164: MacRuby crashes Cocoa app with exception in CFEqual
#164: MacRuby crashes Cocoa app with exception in CFEqual +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: crash,cfequal | +--- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed Comment: Finally I don't think the fix should be improved. Currently we cache the original implementation so that at the very next call we will be direct. I considered the creation of a convenience method on the Ruby side that would simply call the objc original implementation, but it sounded too much overkill. Matt confirmed that r758 fixes the problem, so I'm closing this bug! -- Ticket URL: <http://www.macruby.org/trac/ticket/164#comment:6> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #163: macruby_main forces a relative path
#163: macruby_main forces a relative path --+- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: enhancement | Status: closed Priority: minor |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords:| --+- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed Comment: Thanks for the patch. I agree that the solution is hackish but we can probably live with it for now. I will make sure this will be correctly documented. I committed it as r760, thanks! -- Ticket URL: <http://www.macruby.org/trac/ticket/163#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #169: [HotCocoa] status_item mapping doesn't appear to work
#169: [HotCocoa] status_item mapping doesn't appear to work
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: minor | Milestone:
Component: MacRuby |Keywords:
+---
I'm porting a little single file rubycocoa app to check out hotcocoa but
ran into a little problem with the code below:
{{{
require 'hotcocoa'
class Application
include HotCocoa
def start
application :name => "MacMenu" do |app|
app.delegate = self
@item = status_item
[EMAIL PROTECTED] = status_bar.statusItemWithLength
NSVariableStatusItemLength
@item.title = "MacMenu"
end
end
end
Application.new.start
}}}
The @item = status_item call causes the following error:
{{{
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/hotcocoa/mappings/status_item.rb:6:in
`alloc_with_options': undefined local variable or method `status_bar' for
# (NameError)
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/hotcocoa/mapper.rb:48:in
`block in map_method'
from hotcocoa_menu_test.rb:9:in `block in start'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/hotcocoa/mappings/application.rb:9:in
`call'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/hotcocoa/mappings/application.rb:9:in
`handle_block'
from
/Library/Frameworks/MacRuby.framework/Versions/0.4/usr/lib/ruby/1.9.0/hotcocoa/mapper.rb:67:in
`block in map_method'
from hotcocoa_menu_test.rb:7:in `start'
from hotcocoa_menu_test.rb:16:in `'
}}}
Using the commented out line instead everything is fine.
--
Ticket URL: <http://www.macruby.org/trac/ticket/169>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #169: [HotCocoa] status_item mapping doesn't appear to work
#169: [HotCocoa] status_item mapping doesn't appear to work +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): Should have mentioned, MacRuby is svn r758 -- Ticket URL: <http://www.macruby.org/trac/ticket/169#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #169: [HotCocoa] status_item mapping doesn't appear to work
#169: [HotCocoa] status_item mapping doesn't appear to work +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby |Keywords: +--- Changes (by [EMAIL PROTECTED]): * owner: [EMAIL PROTECTED] => [EMAIL PROTECTED] Comment: Rich, can you look at this? -- Ticket URL: <http://www.macruby.org/trac/ticket/169#comment:3> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #170: rake clean target does not delete miniruby
#170: rake clean target does not delete miniruby ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor | Milestone: MacRuby 0.4 Component: MacRuby|Keywords: ---+ See subject line. One frequent problem for people following -trunk is that internal changes to MacRuby can cause older versions of the objects or miniruby itself to cause heisenbugs in the build process. This leads to frequent "rake clean" and even "rm -rf /Library/Frameworks/MacRuby.framework" phases, to keep cross-contamination to a minimum, so "rake clean" should do its job better by also cleaning the miniruby binary -- Ticket URL: <http://www.macruby.org/trac/ticket/170> MacRuby <http://macruby.org/> ___________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #169: [HotCocoa] status_item mapping doesn't appear to work
#169: [HotCocoa] status_item mapping doesn't appear to work +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: minor | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): The code works if either: * "include HotCocoa" is done not in a class, but at the top level (it's probably why this was not seen earlier). It works because then all the HotCocoa methods become available to '''all''' objects * you add "include HotCocoa" in HotCocoa::Mappings::Mapper as alloc_with_options is run on an instance of HotCocoa::Mappings::Mapper -- Ticket URL: <http://www.macruby.org/trac/ticket/169#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #155: arrays can'e be changed while being enumerated
#155: arrays can'e be changed while being enumerated ---+ Reporter: [EMAIL PROTECTED]| Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: critical | Milestone: MacRuby 1.0 Component: MacRuby|Keywords: ---+ Changes (by [EMAIL PROTECTED]): * milestone: => MacRuby 1.0 Comment: This is indeed a restriction of the current implementation. Since I have no idea on how to fix this quickly, let's have a look for 1.0. -- Ticket URL: <http://www.macruby.org/trac/ticket/155#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone: MacRuby 0.4
Component: MacRuby |Keywords: crash,bridge support,gc
+---
Comment(by [EMAIL PROTECTED]):
I committed the necessary infrastructure changes as part of r762. Now
MacRuby will load any BridgeSupport file/dylib that is inside the
executable bundle, in Resources/BridgeSupport, prior to any other
location.
This means you can copy all the .dylib files inside your .app bundle and
(in theory) your app should run on a vanilla Leopard install.
The following should work (untested though)
{{{
$ mkdir /Path/To/MyApp.app/Contents/Resources/BridgeSupport
$ find /System/Library/Frameworks -regex ".*/BridgeSupport/.*dylib" -exec
cp {} /Path/To/MyApp.app/Contents/Resources/BridgeSupport \;
}}}
This will be automatized as part of the hotcocoa deploy task and be also
available as an Xcode target.
--
Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:3>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #136: NSProgressIndicator freezes application
#136: NSProgressIndicator freezes application --+- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect| Status: new Priority: blocker | Milestone: Component: MacRuby |Keywords: --+- Comment(by [EMAIL PROTECTED]): I couldn't reproduce this. I'm using the most recent revision (r736). -- Ticket URL: <http://www.macruby.org/trac/ticket/136#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #171: [trunk/#762] build fails in ripper extension
#171: [trunk/#762] build fails in ripper extension -+-- Reporter: [EMAIL PROTECTED]| Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: bison, ripper -+-- Trunk at both #760 and #762 fails the same way inside the ripper extension: I have bison 2.4 from macports, running on 10.5.5. compiling ripper bison -t -v -oy.tab.c ripper.y ripper.y:2920.25-26: $$ for the midrule at $6 of `primary' has no declared type make: *** [ripper.c] Error 1 rake aborted! Command failed with status (1): [./miniruby -I./lib -I.ext/common -I./- -r] /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:971:in `sh' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `call' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `sh' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `sh' /Users/roberto/Build/SVN/MacRuby/rakefile:549 /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `execute' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `each' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:612:in `execute' /opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:578:in `invoke_with_call_chain' /opt/local/lib/ruby/1.8/monitor.rb:242:in `synchronize' [...] -- Ticket URL: <http://www.macruby.org/trac/ticket/171> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #171: [trunk/#762] build fails in ripper extension
#171: [trunk/#762] build fails in ripper extension
-+--
Reporter: [EMAIL PROTECTED]| Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone: MacRuby 0.4
Component: MacRuby |Keywords: bison, ripper
-+--
Comment(by [EMAIL PROTECTED]):
Sorry, formatting is messed up...
{{{
compiling ripper
bison -t -v -oy.tab.c ripper.y
ripper.y:2920.25-26: $$ for the midrule at $6 of `primary' has no declared
type
make: *** [ripper.c] Error 1
rake aborted!
Command failed with status (1): [./miniruby -I./lib -I.ext/common -I./-
-r]
/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:971:in `sh'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `call'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:984:in `sh'
/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:1072:in `sh'
/Users/roberto/Build/SVN/MacRuby/rakefile:549
/opt/local/lib/ruby/gems/1.8/gems/rake-0.8.3/lib/rake.rb:617:in `call'
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/171#comment:1>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #172: resurrection error
#172: resurrection error --+- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect| Status: new Priority: minor | Milestone: MacRuby 0.4 Component: MacRuby |Keywords: --+- I am trying to use some existing ruby code in my core data document based app. After switching the application over to MacRuby I get a resurrection error upon closing the document's main window and opening a new document. The error is similar to the following: malloc: *** resurrection error for object 0x10f77a0: auto_zone_write_barrier: _NSThreadPerformInfo.argument[32](0x10b04a0)[12] = NSTrackingArea[48](0x10f77a0) I have been able to recreate this problem in a very simple application based on the core data document based application template. The project is attached. I have tested with the 0.3 release and revision 762 in the testing branch. I am not 100% sure if this is a defect in MacRuby or an error in my project. -- Ticket URL: <http://www.macruby.org/trac/ticket/172> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #70: Need a RubyCocoa compatible layer
#70: Need a RubyCocoa compatible layer ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker| Milestone: MacRuby 1.0 Component: MacRuby|Keywords: ---+ Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.4 => MacRuby 1.0 -- Ticket URL: <http://www.macruby.org/trac/ticket/70#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #157: MacRuby/miniruby segfaults while building
#157: MacRuby/miniruby segfaults while building -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: MacRuby 0.4 Component: MacRuby | Resolution: fixed Keywords: | -+-- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 -- Ticket URL: <http://www.macruby.org/trac/ticket/157#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #89: [RubyCocoa Layer] Need to implement some of the RubyCocoa C API
#89: [RubyCocoa Layer] Need to implement some of the RubyCocoa C API ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker| Milestone: MacRuby 1.0 Component: MacRuby|Keywords: ---+ Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.4 => MacRuby 1.0 -- Ticket URL: <http://www.macruby.org/trac/ticket/89#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #69: [RubyCocoa Layer] method_missing like behaviour for pure Objective-C objects that try to send messages to pure Ruby objects.
#69: [RubyCocoa Layer] method_missing like behaviour for pure Objective-C objects that try to send messages to pure Ruby objects. -+-- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: enhancement | Status: new Priority: trivial | Milestone: MacRuby 1.0 Component: MacRuby |Keywords: rubycocoa layer -+-- Changes (by [EMAIL PROTECTED]): * milestone: MacRuby 0.4 => MacRuby 1.0 -- Ticket URL: <http://www.macruby.org/trac/ticket/69#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant
#173: Need to expose the SVN revision number as a constant
---+
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker| Milestone: MacRuby 1.0
Component: MacRuby|Keywords:
---+
It would be great for debugging purposes to expose the SVN revision number
as a constant in !MacRuby. Maybe {{{MACRUBY_REVISION}}}.
--
Ticket URL: <http://www.macruby.org/trac/ticket/173>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #131: Dictionary arg not accepted
#131: Dictionary arg not accepted
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: major|Milestone: MacRuby 0.4
Component: MacRuby | Resolution: fixed
Keywords: |
-+--
Changes (by [EMAIL PROTECTED]):
* status: new => closed
* resolution: => fixed
Comment:
The Pointer class was introduced in MacRuby trunk to specifically address
these problems.
{{{
pattributes = Pointer.new_with_type('@')
perror = Pointer.new_with_type('@')
o = NSAttributedString.alloc.initWithData(data,
options:NSCharacterEncodingDocumentOption, documentAttributes:pattributes,
error:perror);
unless o
p perror[0]
else
p pattributes[0]
end
}}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/131#comment:4>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL
PROTECTED]
Type: defect | Status: closed
Priority: blocker |Milestone: MacRuby 0.4
Component: MacRuby | Resolution: fixed
Keywords: crash,bridge support,gc |
-+--
Changes (by [EMAIL PROTECTED]):
* status: new => closed
* resolution: => fixed
Comment:
I committed the remaining changes as part of r765.
For HotCocoa projects, {{{macrake deploy}}} will copy the .dylib files.
For Xcode projects, a {{{Embed MacRuby}}} target is now installed as part
of MacRuby. You can add the target to your project and building the target
should embed MacRuby.framework inside the application bundle, change the
linker install name and copy the .dylib files.
The 'build_as_embeddable' Rakefile configuration variable has been
removed, since it's no longer necessary.
I will make sure this 'feature' will be appropriately documented in our
future cookbook.
--
Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:4>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL
PROTECTED]
Type: defect | Status: closed
Priority: blocker |Milestone: MacRuby 0.4
Component: MacRuby | Resolution: fixed
Keywords: crash,bridge support,gc |
-+--
Comment(by [EMAIL PROTECTED]):
Replying to [comment:4 [EMAIL PROTECTED]:
> For Xcode projects, a {{{Embed MacRuby}}} target is now installed as
part of MacRuby. You can add the target to your project and building the
target should embed MacRuby.framework inside the application bundle,
change the linker install name and copy the .dylib files.
>
> The 'build_as_embeddable' Rakefile configuration variable has been
removed, since it's no longer necessary.
>
Reading this I can't be sure but it seems to imply I can only embed the
version of MacRuby I have installed. How would I embed trunk if I have 0.4
or 0.5 installed?
M.
--
Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:5>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
#165: Embeddable MacRuby.framework misses the BridgeSupport dylib files
-+--
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL
PROTECTED]
Type: defect | Status: closed
Priority: blocker |Milestone: MacRuby 0.4
Component: MacRuby | Resolution: fixed
Keywords: crash,bridge support,gc |
-+--
Comment(by [EMAIL PROTECTED]):
Good point, currently it will embed the {{{Current}}} version of the
framework (which may be trunk). We should specify options to
HotCocoa::ApplicationBuilder.deploy. Could you file another ticket for
this?
--
Ticket URL: <http://www.macruby.org/trac/ticket/165#comment:6>
MacRuby <http://macruby.org/>
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- However the new embedding approach for MacRuby should work it should not be dependent upon the version of MacRuby that is installed on the system (ideally it should not even be dependent upon there *being* a version of MacRuby installed). The primary use case is anticipating needing 0.4, 0.5, or 1.0 installed for apps that I am running that depend upon MacRuby (e.g. LimeChat when it moves across) and wanting to deploy other versions (e.g. trunk) in my own application. I'm also not keen on the removal of the build_as_embeddable option and a new dependency upon Xcode. I would rather this problem were solved by keeping the build_as_embeddable rask task and having that task patch the dylibs and and embed them into MR itself (rather than into my application). The way things are going MacRuby is forcing its dependencies into my project. I want to treat it just like any other framework I link to. -- Ticket URL: <http://www.macruby.org/trac/ticket/174> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): Re-reading I wish I hadn't written "The way things are going" it sounds too ominous, it was just the first phrase that came into my head. The basis of what I am trying to articulate is a clean separation of concerns between MacRuby and my application. Regards, Matt -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: major | Milestone:
Component: MacRuby |Keywords:
+---
Comment(by [EMAIL PROTECTED]):
JFYI, {{{build_as_embeddable}}} was removed because it's really not
necessary anymore.
You can still embed a given version of MacRuby in your app by doing:
{{{
$ rake
$ DESTDIR=/tmp/foo rake install
$ mkdir -p /path/to/MyApp.app/Contents/Frameworks
$ cp -r /tmp/foo/Library/Frameworks/MacRuby.framework
/path/to/MyApp.app/Contents/Frameworks
}}}
Then use the Xcode target, or:
{{{
$ macruby -r hotcocoa/application_builder -e
"HotCocoa::ApplicationBuilder.deploy(ARGV[0])" /path/to/MyApp.app
}}}
Now, this is quite painful to do. We should introduce a way to deploy a
specific version of the framework.
--
Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:2>
MacRuby <http://macruby.org/>
_______
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant
#173: Need to expose the SVN revision number as a constant ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker| Milestone: MacRuby 1.0 Component: MacRuby|Keywords: ---+ Comment(by [EMAIL PROTECTED]): One thing to keep in mind is that if you ever move to a VCS like Git (although this issue is not exclusive to Git) you lose the concept of a "revision number". For example Git commits are identified by a hash. -- Ticket URL: <http://www.macruby.org/trac/ticket/173#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #54: build on Leopard fails on readline
#54: build on Leopard fails on readline -+-- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: reopened Priority: blocker |Milestone: Component: MacRuby | Resolution: Keywords: readline | -+-- Comment(by [EMAIL PROTECTED]): Wow, hadn't noticed so much new comments :-). @Laurent: This really isn't a real problem with MacRuby, it's just that the stuff people have installed/compiled is not correct for MacRuby is trying to build. Maybe we should provide a rake task like: build:native / build:universal ? This way it's easier for people to at least get to a working solution. @edarocket I'm fairly certain that that's not the way readline should be configure to get a UB… Maybe check how macports would build it. -- Ticket URL: <http://www.macruby.org/trac/ticket/54#comment:8> MacRuby <http://macruby.org/> ___________ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application
#151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application ---+ Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby|Keywords: ---+ Comment(by [EMAIL PROTECTED]): I've checked EmbeddedMacRuby example and our code only differs in that you catch the exception yourself, while I expected that MacRuby framework would do that. No matter - it's great as it is, so please close this ticket, and thanks for those examples. -- Ticket URL: <http://www.macruby.org/trac/ticket/151#comment:2> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application
#151: [[MacRuby sharedRuntime] evaluateString:@"a"] crashes the application ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: major |Milestone: MacRuby 0.4 Component: MacRuby| Resolution: fixed Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => fixed * milestone: => MacRuby 0.4 Comment: Excellent - closing. -- Ticket URL: <http://www.macruby.org/trac/ticket/151#comment:3> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant
#173: Need to expose the SVN revision number as a constant
---+
Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED]
Type: defect | Status: closed
Priority: blocker|Milestone: MacRuby 0.4
Component: MacRuby| Resolution: fixed
Keywords: |
---+
Changes (by [EMAIL PROTECTED]):
* status: new => closed
* resolution: => fixed
* milestone: MacRuby 1.0 => MacRuby 0.4
Comment:
A patch was contributed by Vincent Isambart that implements this feature.
It works for both SVN and Git.
{{{
$ ./miniruby -e "p MACRUBY_REVISION"
"svn revision 745 from
http://svn.macosforge.org/repository/ruby/MacRuby/trunk";
}}}
It has been committed as r766.
--
Ticket URL: <http://www.macruby.org/trac/ticket/173#comment:2>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant
#173: Need to expose the SVN revision number as a constant ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: reopened Priority: blocker|Milestone: MacRuby 0.4 Component: MacRuby| Resolution: Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * status: closed => reopened * resolution: fixed => Comment: Looking more carefully, looks like the revision number is not the latest one. I pinged Vincent. Re-opening the ticket. -- Ticket URL: <http://www.macruby.org/trac/ticket/173#comment:3> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #173: Need to expose the SVN revision number as a constant
#173: Need to expose the SVN revision number as a constant ---+ Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker|Milestone: MacRuby 0.4 Component: MacRuby| Resolution: fixed Keywords: | ---+ Changes (by [EMAIL PROTECTED]): * status: reopened => closed * resolution: => fixed Comment: Forgot to do "svn update", mea culpa :-) -- Ticket URL: <http://www.macruby.org/trac/ticket/173#comment:4> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] [MacRuby] #175: Problem with r766 rakefile?
#175: Problem with r766 rakefile?
+---
Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED]
Type: defect | Status: new
Priority: blocker | Milestone:
Component: MacRuby |Keywords:
+---
I just tried to update to r766 and got the following:
{{
Siona:~/Projects/ruby/MacRuby-Trunk matt$ svn up
CRakefile
Amisc/xcode-templates/Target Templates
Amisc/xcode-templates/Target Templates/Ruby
Amisc/xcode-templates/Target Templates/Ruby/Embed MacRuby.trgttmpl
Ulib/hotcocoa/application_builder.rb
Uversion.c
Updated to revision 766.
Siona:~/Projects/ruby/MacRuby-Trunk matt$ rake clean
(in /Users/matt/Projects/ruby/MacRuby-Trunk)
rake aborted!
/Users/matt/Projects/ruby/MacRuby-Trunk/rakefile:31: syntax error,
unexpected tLSHFT, expecting $end
<<<<<<< .mine
^
/Library/Ruby/Gems/1.8/gems/rake-0.8.3/lib/rake.rb:2349:in
`raw_load_rakefile'
(See full trace by running task with --trace)
Siona:~/Projects/ruby/MacRuby-Trunk matt$
}}
--
Ticket URL: <http://www.macruby.org/trac/ticket/175>
MacRuby <http://macruby.org/>
___________
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #175: Problem with r766 rakefile?
#175: Problem with r766 rakefile? +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: blocker | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): Problem was local. I had a change to the Rakefile which svn kindly turned into a merge conflict when I updated. I didn't notice the 'C' on the update status. -- Ticket URL: <http://www.macruby.org/trac/ticket/175#comment:1> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): I've been having a lot of problems with this. I can't make the Xcode target work at all and, because of a confusion, I managed to release a version update without the bridge support metadata and am getting crash reports. I think this process is brittle and introduces unnecessary dependencies into my project not to mention adding several seconds to each build cycle (whether needed or not and they do add up). I would like, instead, to see the MacRuby build process (perhaps governed by some kind of flag) embed the bridge support metadata into the MacRuby.framework bundle itself and look for them there first. This would eliminate any dependency in my application project and allow me to treat MacRuby.framework as I would any other framework (which is a very good thing). It would also considerably reduce the change that I will ever again release a binary without the patched metadata. I took a look at bs.c but, although the relevant area is obvious enough to spot, I would not be confident to make this change myself. The "Ruby C" coding style is not for the faint hearted. Matt -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:3> MacRuby <http://macruby.org/> ___ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): I have been using the Xcode target for quite some time here, what kind of problems did you really experience? The idea behind the target is to not build it during development, but only to release a deployment version for release. If the target does not satisfy you, you can still use the command line exactly as before (see my reply above). There are really more than one way to do it (even if the Xcode target is IMHO the easiest way). I don't think that modifying the BridgeSupport parser to look for BridgeSupport files inside the framework is a good idea, because it violates the BridgeSupport load path that we discussed a year ago with the PyObjC guys. This dylib problem is also very temporary as I said, it is the plan to address this in an future software update for Leopard. -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:4> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #175: Problem with r766 rakefile?
#175: Problem with r766 rakefile? +--- Reporter: [EMAIL PROTECTED] |Owner: [EMAIL PROTECTED] Type: defect | Status: closed Priority: blocker |Milestone: Component: MacRuby | Resolution: invalid Keywords: | +--- Changes (by [EMAIL PROTECTED]): * status: new => closed * resolution: => invalid -- Ticket URL: <http://www.macruby.org/trac/ticket/175#comment:2> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] [MacRuby] #174: Allow embedding of arbitrary versions of MacRuby
#174: Allow embedding of arbitrary versions of MacRuby +--- Reporter: [EMAIL PROTECTED] | Owner: [EMAIL PROTECTED] Type: defect | Status: new Priority: major | Milestone: Component: MacRuby |Keywords: +--- Comment(by [EMAIL PROTECTED]): For me the Xcode target has never embedded the metadata. By default it seems to add itself to the list of targets, there it does nothing I can observe. If I try and drag it under the Application target itself the script generates an error because it won't go after the compile sources build phase. >I don't think that modifying the BridgeSupport parser to look for BridgeSupport files inside the framework is a good idea, because it violates the BridgeSupport load path that we discussed a year ago with the PyObjC guys. And then in the very next sentence you say the problem is temporary. So, given that, why not adopt this approach temporarily? It may not be what you discussed with the PyObjC folks but it's the best solution for your users. How are PyObjC even going to know if you add MR itself at the front of the load path? Why do they care? m/ -- Ticket URL: <http://www.macruby.org/trac/ticket/174#comment:5> MacRuby <http://macruby.org/> _______ MacRuby-devel mailing list MacRuby-devel@lists.macosforge.org http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
