> This is the last experimental branch status update, we accomplished I
> think all the goals required to merge the branch into trunk. There
> will be more status updates after, but they will focus on trunk and
> the 0.5 release objectives :)
To be clear, this means that the trunk is going to be b
> I'm on a MacBook Pro with a 2.16GHz Core Duo running 10.5.7.
Core Duo is 32 bit. If I had to guess, that would be the source of the issue.
___
MacRuby-devel mailing list
MacRuby-devel@lists.macosforge.org
http://lists.macosforge.org/mailman/listinfo.
Hello,
The breaking change was introduced in r829.
-Scott
On Mar 2, 2009, at 10:00 PM, M. Scott Ford wrote:
Hello,
I just grabbed the latest from trunk (r831), and the following
section from my rakefile causes the macruby process to hang. It
seems to be the gem call that is causing the
Hello,
I just grabbed the latest from trunk (r831), and the following section
from my rakefile causes the macruby process to hang. It seems to be
the gem call that is causing the problem. Commenting that line out
allows execution to proceed. I will keep investigating, but wanted to
repor
e(['a', 'b'])
On Feb 12, 2009, at 2:01 PM, M. Scott Ford wrote:
One more piece of data. The module that is being extended does not
matter. The following block dies the same way.
fred = Module.new
args = []
args.extend(fred)
args.clear
___
Eloy,
I applied your change to dup, rolled out my change, and then the tests
that I wrote still pass.
-Scott
On Feb 12, 2009, at 2:02 PM, Eloy Duran wrote:
Hi Scott,
As you can see in this commit:
http://github.com/masterkain/macruby/commit/0cb18321229b35a61e9af46e068b3d55a3678bd6
I hav
One more piece of data. The module that is being extended does not
matter. The following block dies the same way.
fred = Module.new
args = []
args.extend(fred)
args.clear
On Feb 12, 2009, at 1:56 PM, M. Scott Ford wrote:
Hello,
The following block of code generates a segmentation fault. I
Hello,
The following block of code generates a segmentation fault. I am going
to try to track down where it is coming from. Commenting out the
args.extend line will prevent the failure.
I am going to digg in and try to figure out what is wrong, but I
thought that an extra pair of eyes wou
Eloy,
Here is an updated patch that uses spec style tests.
-Scott
hash_merge.patch
Description: Binary data
On Feb 12, 2009, at 9:16 AM, Eloy Duran wrote:
Hi Scott,
If you would like to re write your patch in a more spec style as the
one I pointed to that would be great!
We can then e
Eloy,
I did not see your email before I submitted the patch.
I glanced at the hash tests in the RubySpec project and there is not
much there, so moving this test into RubySpec sounds like a good idea.
Is that something that I should take care of now?
-Scott
On Feb 12, 2009, at 8:53 AM, El
Laurent,
The patch is attached.
-Scott
hash_merge.patch
Description: Binary data
On Feb 11, 2009, at 10:21 PM, Laurent Sansonetti wrote:
Thanks for the detective work Scott! Could you create a test case in
test/ruby/test_hash.rb and send us a patch? I would then merge it.
Laurent
___
And the fix.
Change rb_hash_merge to use rb_obj_dup instead of rb_hash_dup.
On Feb 11, 2009, at 2:48 PM, M. Scott Ford wrote:
Sorry to reply to my own post but I have been playing with this all
day to figure out what is wrong. I have narrowed the problem down to
the merge method, but I am
(h[1], 12)
assert_equal(h[:random], 12)
On Feb 11, 2009, at 11:53 AM, M. Scott Ford wrote:
Hello,
I have been trying to get cucumber working with MacRuby, and I have
run into a bug. I have tracked the source of it down to a block of
code in cucumber's code base[BLOCK 1]. I have condense
Hello,
I have been trying to get cucumber working with MacRuby, and I have
run into a bug. I have tracked the source of it down to a block of
code in cucumber's code base[BLOCK 1]. I have condensed this down to a
much smaller example[BLOCK 2]. In ruby 1.9.1 the second block results
in 'ye
14 matches
Mail list logo
