[MacRuby-devel] Hot Cocoa disappearing window behaviour
It seams like the default behaviour of windows generated in Hot Cocoa is to allow their content height to be shrunk to zero (by dragging the lower right corner). At which time you are left with just the title bar and no way to recover once you have released the mouse button (AFAIK). A minimum width is already provided. layout_view demonstrates this behaviour. It is probably a good idea to set a minimum height value by default. Dave. ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
Hi,
If this is a problem with the Objective-C Hash implementation, I would
be inclined to say that the test case should go in test-macruby/cases/
rubyspec/hash_test.rb.
Because we might need to move this into the rubyspec project, if it's
not already in there, once we start on integrating rubyspec.
If so, please take a look at, for instance, this test case as an
example: http://www.macruby.org/trac/browser/MacRuby/trunk/test-macruby/cases/hotcocoa/mapper_test.rb
- Eloy
On 12 feb 2009, at 04:21, 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
On Feb 11, 2009, at 12:11 PM, M. Scott Ford wrote:
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 not sure how to fix it. Here
are some test cases. These all pass in ruby 1.9.1. The first one
fails in MacRuby trunk, but the other two pass.
h = Hash.new do |h, k|
12
end
h = h.merge({1 => 2})
assert_equal(h[1], 2)
assert_equal(h[:random], 12)
h = Hash.new do |h, k|
12
end
h.merge!({1 => 2})
assert_equal(h[1], 2)
assert_equal(h[:random], 12)
h = Hash.new do |h, k|
12
end
h.merge({1 => 2})
assert_equal(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 condensed
this down to a much smaller example[BLOCK 2]. In ruby 1.9.1 the
second block results in 'yellow,bold', but in macruby the second
block results in nil.
My guess is that there is a bug in the merge implementation or
the constructor implementation. I am not familiar enough with
ruby to know which, so I will take a look at both. I feel this
should be added as a test case, but I am not sure where to put
that, since I am new to the project. Any tips?
-Scott
- BLOCK 1 --
ALIASES = Hash.new do |h,k|
if k.to_s =~ /(.*)_param/
h[$1] + ',bold'
end
end.merge({
'missing' => 'yellow',
'pending' => 'yellow',
'failed' => 'red',
'passed' => 'green',
'outline' => 'cyan',
'skipped' => 'cyan',
'comment' => 'grey',
'tag' => 'blue'
})
if ENV['CUCUMBER_COLORS'] # Example: export
CUCUMBER_COLORS="passed=red:failed=yellow"
ENV['CUCUMBER_COLORS'].split(':').each do |pair|
a = pair.split('=')
ALIASES[a[0]] = a[1]
end
end
ALIASES.each do |method, color|
unless method =~ /.*_param/
code = <<-EOF
def #{method}(string=nil, &proc)
#{ALIASES[method].split(",").join("(") + "(string, &proc"
+ ")" * ALIASES[method].split(",").length}
end
# This resets the colour to the non-param colour
def #{method}_param(string=nil, &proc)
#{ALIASES[method+'_param'].split(",").join("(") +
"(string, &proc" + ")" * ALIASES[method
+'_param'].split(",").length} +
#{ALIASES[method].split(",").join(' + ')}
end
EOF
eval(code)
end
end
-- END BLOCK 1 --
--- BLOCK 2 --
ALIASES = Hash.new do |h,k|
if k.to_s =~ /(.*)_param/
h[$1] + ',bold'
end
end.merge({
'missing' => 'yellow'
})
puts ALIASES['missing_param']
- END BLOCK 2 -
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
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 ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
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, Eloy Duran wrote: Hi, If this is a problem with the Objective-C Hash implementation, I would be inclined to say that the test case should go in test- macruby/cases/rubyspec/hash_test.rb. Because we might need to move this into the rubyspec project, if it's not already in there, once we start on integrating rubyspec. If so, please take a look at, for instance, this test case as an example: http://www.macruby.org/trac/browser/MacRuby/trunk/test-macruby/cases/hotcocoa/mapper_test.rb - Eloy ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
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 easily migrate it to rubyspec later on. Thanks, - Eloy On 12 feb 2009, at 15:09, M. Scott Ford wrote: 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, Eloy Duran wrote: Hi, If this is a problem with the Objective-C Hash implementation, I would be inclined to say that the test case should go in test- macruby/cases/rubyspec/hash_test.rb. Because we might need to move this into the rubyspec project, if it's not already in there, once we start on integrating rubyspec. If so, please take a look at, for instance, this test case as an example: http://www.macruby.org/trac/browser/MacRuby/trunk/test-macruby/cases/hotcocoa/mapper_test.rb - Eloy ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Bug: NSValueTransformer receivers NSCFNumber, not fixnum
Is this a bug? I don't see anything quite like it in Trac.
I have a binding to a button's state property. Here's the binding:
@comboBox.bind 'enabled',
toObject: @button,
withKeyPath: 'state',
options: {
NSValueTransformerBindingOption =>
OffStateMeansTrueTransformer.alloc.init
}
At the point the binding is made, the state of the button is a fixnum 0.
The value transformer is immediately called to set the starting value.
Here's the transformedValue code:
def transformedValue(state)
puts "state -> bool transforming #{state.inspect}"
# prints #
# state.intValue is 0
Because of this, I have to cast the state before making comparisons:
case state.intValue
when NSOffState then true
when NSOnState then false
else
raise "The value to transform should be either NSOffState or
NSOnState."
end
If this is a bug, I'll write a testcase.
-
Brian Marick, independent consultant
Mostly on agile methods with a testing slant
www.exampler.com, www.exampler.com/blog, www.twitter.com/marick
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
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 easily migrate it to rubyspec later on. Thanks, - Eloy ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
[MacRuby-devel] Another Cucumber Related Bug
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 would be nice. Especially since I have no idea where to start. :) Any tips? require 'optparse' args = [] args.extend(OptionParser::Arguable) args.clear -Scott ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Another Cucumber Related Bug
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 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 would be nice. Especially since I have no idea where to start. :) Any tips? require 'optparse' args = [] args.extend(OptionParser::Arguable) args.clear -Scott ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
Hi Scott, As you can see in this commit: http://github.com/masterkain/macruby/commit/0cb18321229b35a61e9af46e068b3d55a3678bd6 I have fixed the problem in a different way. Because if I understood your intention right, then the problem was in #dup. Please let me know if this fixes your issue, or that I might have missed another part of your tests. - Eloy On 12 feb 2009, at 16:29, M. Scott Ford wrote: Eloy, Here is an updated patch that uses spec style tests. -Scott 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 easily migrate it to rubyspec later on. Thanks, - Eloy ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Help with bug from Cucumber codebase
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 have fixed the problem in a different way. Because if I understood your intention right, then the problem was in #dup. Please let me know if this fixes your issue, or that I might have missed another part of your tests. - Eloy ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
Re: [MacRuby-devel] Another Cucumber Related Bug
Even more data. The following code block also segfaults. It looks like the issue is the cast of ary to a CFMutableArrayRef. But that is where I am stumped, because I am not sure what alternatives there are. Any help? fred = Module.new args = ['a'] args.extend(fred) args.replace(['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 ___ MacRuby-devel mailing list [email protected] http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel
