Re: [MacRuby-devel] Exception backtraces in instance_eval

2010-11-14 Thread Martijn Walraven
Hi,

I've looked into the issue some more, and it turns out the backtraces created 
by MacRuby nightly are much more similar to the 1.9.2 ones. The backtrace still 
misses the line referring to the actual execution of the spec though, so the 
problem hasn't been completely solved yet.

It seems this might be related to a lack of file and line information in the 
example Proc. While Procs in Ruby 1.9.2 know their source location, it seems 
MacRuby Procs don't.

Ruby 1.9.2:
#
MacRuby nightly:
#

Is this a known limitation?

Thanks,

Martijn

RSpec output from MacRuby nightly:

1) A new HelloWorld object should return the appropriate greeting
   Failure/Error: Unable to find matching line from backtrace
   expected: "Hello World!",
got: "Hello Earth!" (using ==)
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/expectations/fail_with.rb:29:in
 `fail_with:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:48:in
 `fail_with_message:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:70:in
 `__delegate_operator:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:60:in
 `eval_match:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:29:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:42:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:81:in
 `with_around_hooks'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:39:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:75:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:74:in
 `with_pending_capture'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:38:in
 `run:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:261:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:257:in
 `run_examples:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:231:in
 `run:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
 `block'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/reporter.rb:12:in
 `report:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:24:in
 `run:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:55:in
 `run_in_process:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:46:in
 `run:'
   # 
/usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:10:in
 `block'
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Exception backtraces in instance_eval

2010-11-14 Thread Matt Aimonetti
I believe this is a known issue that needs to be addressed. Can you please 
check if there is already an open ticket, if not, please open one.

Thx

- Matt

Sent from my iPhone

On Nov 14, 2010, at 3:05, Martijn Walraven  wrote:

> Hi,
> 
> I've looked into the issue some more, and it turns out the backtraces created 
> by MacRuby nightly are much more similar to the 1.9.2 ones. The backtrace 
> still misses the line referring to the actual execution of the spec though, 
> so the problem hasn't been completely solved yet.
> 
> It seems this might be related to a lack of file and line information in the 
> example Proc. While Procs in Ruby 1.9.2 know their source location, it seems 
> MacRuby Procs don't.
> 
> Ruby 1.9.2:
> #
> MacRuby nightly:
> #
> 
> Is this a known limitation?
> 
> Thanks,
> 
> Martijn
> 
> RSpec output from MacRuby nightly:
> 
> 1) A new HelloWorld object should return the appropriate greeting
>   Failure/Error: Unable to find matching line from backtrace
>   expected: "Hello World!",
>got: "Hello Earth!" (using ==)
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/expectations/fail_with.rb:29:in
>  `fail_with:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:48:in
>  `fail_with_message:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:70:in
>  `__delegate_operator:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:60:in
>  `eval_match:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:29:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:42:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:81:in
>  `with_around_hooks'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:39:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:75:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:74:in
>  `with_pending_capture'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:38:in
>  `run:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:261:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:257:in
>  `run_examples:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:231:in
>  `run:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>  `block'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/reporter.rb:12:in
>  `report:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:24:in
>  `run:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:55:in
>  `run_in_process:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:46:in
>  `run:'
>   # 
> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:10:in
>  `block'
> ___
> 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] Exception backtraces in instance_eval

2010-11-14 Thread Martijn Walraven
I've added a ticket (#996) describing the issue. I wish I could do more to help 
fix it, but I'm afraid I don't know enough about the implementation of the VM.

On Nov 14, 2010, at 15:22 , Matt Aimonetti wrote:

> I believe this is a known issue that needs to be addressed. Can you please 
> check if there is already an open ticket, if not, please open one.
> 
> Thx
> 
> - Matt
> 
> Sent from my iPhone
> 
> On Nov 14, 2010, at 3:05, Martijn Walraven  
> wrote:
> 
>> Hi,
>> 
>> I've looked into the issue some more, and it turns out the backtraces 
>> created by MacRuby nightly are much more similar to the 1.9.2 ones. The 
>> backtrace still misses the line referring to the actual execution of the 
>> spec though, so the problem hasn't been completely solved yet.
>> 
>> It seems this might be related to a lack of file and line information in the 
>> example Proc. While Procs in Ruby 1.9.2 know their source location, it seems 
>> MacRuby Procs don't.
>> 
>> Ruby 1.9.2:
>> #
>> MacRuby nightly:
>> #
>> 
>> Is this a known limitation?
>> 
>> Thanks,
>> 
>> Martijn
>> 
>> RSpec output from MacRuby nightly:
>> 
>> 1) A new HelloWorld object should return the appropriate greeting
>>  Failure/Error: Unable to find matching line from backtrace
>>  expected: "Hello World!",
>>   got: "Hello Earth!" (using ==)
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/expectations/fail_with.rb:29:in
>>  `fail_with:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:48:in
>>  `fail_with_message:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:70:in
>>  `__delegate_operator:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:60:in
>>  `eval_match:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:29:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:42:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:81:in
>>  `with_around_hooks'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:39:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:75:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:74:in
>>  `with_pending_capture'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:38:in
>>  `run:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:261:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:257:in
>>  `run_examples:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:231:in
>>  `run:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>>  `block'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/reporter.rb:12:in
>>  `report:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:24:in
>>  `run:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:55:in
>>  `run_in_process:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:46:in
>>  `run:'
>>  # 
>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:10:in
>>  `block'
>> ___
>> 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] Exception backtraces in instance_eval

2010-11-14 Thread Matt Aimonetti
Thx for reporting the problem you encountered.

- Matt

Sent from my iPhone

On Nov 14, 2010, at 9:27, Martijn Walraven  wrote:

> I've added a ticket (#996) describing the issue. I wish I could do more to 
> help fix it, but I'm afraid I don't know enough about the implementation of 
> the VM.
> 
> On Nov 14, 2010, at 15:22 , Matt Aimonetti wrote:
> 
>> I believe this is a known issue that needs to be addressed. Can you please 
>> check if there is already an open ticket, if not, please open one.
>> 
>> Thx
>> 
>> - Matt
>> 
>> Sent from my iPhone
>> 
>> On Nov 14, 2010, at 3:05, Martijn Walraven  
>> wrote:
>> 
>>> Hi,
>>> 
>>> I've looked into the issue some more, and it turns out the backtraces 
>>> created by MacRuby nightly are much more similar to the 1.9.2 ones. The 
>>> backtrace still misses the line referring to the actual execution of the 
>>> spec though, so the problem hasn't been completely solved yet.
>>> 
>>> It seems this might be related to a lack of file and line information in 
>>> the example Proc. While Procs in Ruby 1.9.2 know their source location, it 
>>> seems MacRuby Procs don't.
>>> 
>>> Ruby 1.9.2:
>>> #
>>> MacRuby nightly:
>>> #
>>> 
>>> Is this a known limitation?
>>> 
>>> Thanks,
>>> 
>>> Martijn
>>> 
>>> RSpec output from MacRuby nightly:
>>> 
>>> 1) A new HelloWorld object should return the appropriate greeting
>>> Failure/Error: Unable to find matching line from backtrace
>>> expected: "Hello World!",
>>>  got: "Hello Earth!" (using ==)
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/expectations/fail_with.rb:29:in
>>>  `fail_with:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:48:in
>>>  `fail_with_message:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:70:in
>>>  `__delegate_operator:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:60:in
>>>  `eval_match:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-expectations-2.1.0/lib/rspec/matchers/operator_matcher.rb:29:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:42:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:81:in
>>>  `with_around_hooks'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:39:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:75:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:74:in
>>>  `with_pending_capture'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example.rb:38:in
>>>  `run:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:261:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:257:in
>>>  `run_examples:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/example_group.rb:231:in
>>>  `run:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:27:in
>>>  `block'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/reporter.rb:12:in
>>>  `report:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/command_line.rb:24:in
>>>  `run:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:55:in
>>>  `run_in_process:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:46:in
>>>  `run:'
>>> # 
>>> /usr/local/rvm/gems/macruby-nigh...@test/gems/rspec-core-2.1.0/lib/rspec/core/runner.rb:10:in
>>>  `block'
>>> ___
>>> 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] Future MacRuby support for "name-mangling" ?

2010-11-14 Thread Scott Lowe
Hello,

Both JRuby and IronRuby support translation from 'native' CamelCase method
names to the
lowercase_with_underscores naming convention in idiomatic Ruby.

They IronRuby guys call this "name-mangling":
http://ironruby.net/Documentation/.NET/Names

I had an expectation that this would be the case with MacRuby, but I now
know that this is
not true. Are there any plans to implement this feature in the future? You
can probably guess
that I like this feature an awful lot.

Regards,

Scott
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Future MacRuby support for "name-mangling" ?

2010-11-14 Thread Joshua Ballanco
Hi Scott,

MacRuby's spiritual predecessor RubyCocoa did this sort of substitution of 
camelCase for under_case. However, I don't foresee this name-mangling being a 
part of MacRuby's near future for one very important reason: MacRuby methods 
*are* Objective-C methods.

I'm not aware of the particulars of the IronRuby or JRuby bridges, but in the 
case of RubyCocoa, there is a translation step to get from a Ruby method name 
to an Objective-C selector. In MacRuby, there is no transation step. MacRuby 
method names are Objective-C selectors and vice versa. So, we'd have to *add* a 
step in the method dispatch to do translation (since there isn't already one). 
It's not impossible, but I would guess it's pretty low on the priority list at 
the moment.

Cheers,

Josh


On Nov 14, 2010, at 11:51 AM, Scott Lowe wrote:

> Hello,
> 
> Both JRuby and IronRuby support translation from 'native' CamelCase method 
> names to the
> lowercase_with_underscores naming convention in idiomatic Ruby.
> 
> They IronRuby guys call this "name-mangling": 
> http://ironruby.net/Documentation/.NET/Names
> 
> I had an expectation that this would be the case with MacRuby, but I now know 
> that this is
> not true. Are there any plans to implement this feature in the future? You 
> can probably guess
> that I like this feature an awful lot.
> 
> Regards,
> 
> 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] Neat MacRuby app, HotCocoa, and more!

2010-11-14 Thread Joshua Ballanco
Hey Leigh,

I don't (currently) have much of an opinion about HotCocoa, but regarding the 
specific example you give, there has been some talk about implementing the Ruby 
net/* libraries on top of NSURLConnection and friends. In the past, the problem 
has been that NSURLConnection is inherently async and the net/* libraries 
attempt to do things a bit more synchronous. However, maybe we could use an 
alternative Ruby library (like HTTParty) as a starting point instead?

Cheers,

Josh


On Nov 13, 2010, at 10:08 PM, Leigh Caplan wrote:

> Hey everybody,
> 
> I wanted to say hi to the list and introduce myself - I've been lurking for 
> awhile and come by when I need help, but RubyConf has me all fired up, so I'd 
> like to start engaging more with the community. My name is Leigh Caplan, and 
> I'm a developer in Seattle, WA. I like long walks on the beach, dinner by 
> candlelight, and not having to write my Mac OS X apps in Objective C.
> 
> First, I wanted to tell everyone about a potentially useful menu extra that I 
> created called CobraMenu. It's meant to be a simple "traffic light" for CI 
> Joe (the super simple/awesome CI server written by the Github guys). You can 
> find more info at http://texel.github.com/CobraMenu/ or just clone/fork it 
> from https://github.com/texel/CobraMenu
> 
> Next, developing this got me thinking about HotCocoa, and how it could evolve 
> into a really useful project in the future. I had a chat w/ Matt Aimonetti 
> today, and he mentioned that Rich Kilmer, while still interested in the 
> project, both didn't have time to maintain it and also wasn't convinced that 
> its current goal as a DSL for creating UI elements was necessarily useful for 
> anything but trivial projects. Apparently there's also been some discussion 
> to this effect on this list, but I'm a bit late to the party, so I apologize.
> 
> Now, I *can* see a need for a ruby-like DSL for Cocoa, but in my opinion, it 
> would be much more exciting if we endeavored to wrap other Cocoa classes and 
> idioms in a loving Ruby-like embrace. Here's a rudimentary example (very much 
> like something I've done in CobraMenu): 
> 
> HotCocoa::URLConnection.get('http://google.com') do |c|
> 
>   c.success { success_callback }
> 
>   c.failure { failure_callback }
> 
>   c.error   { |e| error_handler.call_something e }
> 
> end
> 
> 
> I'd be interested to see if other people think this is a good idea. If so, I 
> can formulate a strategy, and get to work :)
> 
> Leigh
> ___
> 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] Future MacRuby support for "name-mangling" ?

2010-11-14 Thread Matt Aimonetti
It actually is also helpful to quickly see the difference between Obj-c/C 
methods/functions & Ruby methods.
It also helps with documentation.

I agree with Joshua, I don't see that change happening anytime soon either.

- Matt

Sent from my iPhone

On Nov 14, 2010, at 12:49, Joshua Ballanco  wrote:

> Hi Scott,
> 
> MacRuby's spiritual predecessor RubyCocoa did this sort of substitution of 
> camelCase for under_case. However, I don't foresee this name-mangling being a 
> part of MacRuby's near future for one very important reason: MacRuby methods 
> *are* Objective-C methods.
> 
> I'm not aware of the particulars of the IronRuby or JRuby bridges, but in the 
> case of RubyCocoa, there is a translation step to get from a Ruby method name 
> to an Objective-C selector. In MacRuby, there is no transation step. MacRuby 
> method names are Objective-C selectors and vice versa. So, we'd have to *add* 
> a step in the method dispatch to do translation (since there isn't already 
> one). It's not impossible, but I would guess it's pretty low on the priority 
> list at the moment.
> 
> Cheers,
> 
> Josh
> 
> 
> On Nov 14, 2010, at 11:51 AM, Scott Lowe wrote:
> 
>> Hello,
>> 
>> Both JRuby and IronRuby support translation from 'native' CamelCase method 
>> names to the
>> lowercase_with_underscores naming convention in idiomatic Ruby.
>> 
>> They IronRuby guys call this "name-mangling": 
>> http://ironruby.net/Documentation/.NET/Names
>> 
>> I had an expectation that this would be the case with MacRuby, but I now 
>> know that this is
>> not true. Are there any plans to implement this feature in the future? You 
>> can probably guess
>> that I like this feature an awful lot.
>> 
>> Regards,
>> 
>> 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
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Neat MacRuby app, HotCocoa, and more!

2010-11-14 Thread Matt Aimonetti
You can look at the wrapper I wrote and usually use in my apps:
https://github.com/mattetti/macruby-httpwrapper/blob/master/macruby_http.rb

It's not perfect but it might help you.

- Matt

Sent from my iPhone

On Nov 14, 2010, at 13:14, Joshua Ballanco  wrote:

> Hey Leigh,
> 
> I don't (currently) have much of an opinion about HotCocoa, but regarding the 
> specific example you give, there has been some talk about implementing the 
> Ruby net/* libraries on top of NSURLConnection and friends. In the past, the 
> problem has been that NSURLConnection is inherently async and the net/* 
> libraries attempt to do things a bit more synchronous. However, maybe we 
> could use an alternative Ruby library (like HTTParty) as a starting point 
> instead?
> 
> Cheers,
> 
> Josh
> 
> 
> On Nov 13, 2010, at 10:08 PM, Leigh Caplan wrote:
> 
>> Hey everybody,
>> 
>> I wanted to say hi to the list and introduce myself - I've been lurking for 
>> awhile and come by when I need help, but RubyConf has me all fired up, so 
>> I'd like to start engaging more with the community. My name is Leigh Caplan, 
>> and I'm a developer in Seattle, WA. I like long walks on the beach, dinner 
>> by candlelight, and not having to write my Mac OS X apps in Objective C.
>> 
>> First, I wanted to tell everyone about a potentially useful menu extra that 
>> I created called CobraMenu. It's meant to be a simple "traffic light" for CI 
>> Joe (the super simple/awesome CI server written by the Github guys). You can 
>> find more info at http://texel.github.com/CobraMenu/ or just clone/fork it 
>> from https://github.com/texel/CobraMenu
>> 
>> Next, developing this got me thinking about HotCocoa, and how it could 
>> evolve into a really useful project in the future. I had a chat w/ Matt 
>> Aimonetti today, and he mentioned that Rich Kilmer, while still interested 
>> in the project, both didn't have time to maintain it and also wasn't 
>> convinced that its current goal as a DSL for creating UI elements was 
>> necessarily useful for anything but trivial projects. Apparently there's 
>> also been some discussion to this effect on this list, but I'm a bit late to 
>> the party, so I apologize.
>> 
>> Now, I *can* see a need for a ruby-like DSL for Cocoa, but in my opinion, it 
>> would be much more exciting if we endeavored to wrap other Cocoa classes and 
>> idioms in a loving Ruby-like embrace. Here's a rudimentary example (very 
>> much like something I've done in CobraMenu): 
>> 
>> HotCocoa::URLConnection.get('http://google.com') do |c|
>> 
>>   c.success { success_callback }
>> 
>>   c.failure { failure_callback }
>> 
>>   c.error   { |e| error_handler.call_something e }
>> 
>> end
>> 
>> 
>> I'd be interested to see if other people think this is a good idea. If so, I 
>> can formulate a strategy, and get to work :)
>> 
>> Leigh
>> ___
>> 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] Future MacRuby support for "name-mangling" ?

2010-11-14 Thread Scott Lowe
>* I'm not aware of the particulars of the IronRuby or JRuby bridges, but in 
>the case of RubyCocoa, there is a translation step to get from a Ruby method 
>name to an Objective-Cselector. In MacRuby, there is no transation step. 
>MacRuby method names are Objective-C selectors and vice versa. So, we'd have 
>to *add* a step in the method dispatch to do translation (since there isn't 
>already one).*

I believe that IronRuby presents a "view" onto the CLR objects, so
yes, there is bound to be an intermediate step to facilitate this.

Thanks for your time and your answers, gentlemen.

Scott
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


[MacRuby-devel] Conforming to a protocol

2010-11-14 Thread Martijn Walraven
Hi,

I was wondering if there is any way to formally indicate a MacRuby class 
conforms to an Objective-C protocol. I encountered some code that uses 
conformsToProtocol: instead of respondsToSelector: as a check before invoking 
delegate methods, and the only way I could get a delegate written in MacRuby to 
work was to create an Objective-C class with the same name and specify the 
required protocols in the interface declaration there.

Thanks,

Martijn
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


[MacRuby-devel] Weird behaviour for a weird line of code

2010-11-14 Thread Mark Rada
Hey,

I wrote a line of code that I thought was correct (but maybe not so pretty) and 
in one case it was giving me a weird error. I was wondering if someone could 
explain to me what is wrong with it; I suspect there is some behaviour of 
MacRuby that I am not understanding. Here are a few examples that are close to 
what I had:

A working case: (Case #1)

require 'uri'
test = URI.parse url unless (url = nil).nil? # works, as I expected, 
url is nil and the left side is not evaluated


Ok, try again, but without a nil value for url: (Case #2)

require 'uri'
 test = URI.parse url unless (url = 'http://macruby.org/').nil?  # 
error about url not being defined


Now, when I try this out in macirb: (Case #3)

require 'uri'
 test = URI.parse url unless (url = 'http://macruby.org/').nil?  # 
error again

 test = URI.parse url unless (url = 'http://wikipedia.org/').nil? # 
works fine this time

puts test.to_s  # gives me the wikipedia value


If it doesn't work in the second case, why does it start working in the third 
case?

Thanks,
Mark

___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel


Re: [MacRuby-devel] Neat MacRuby app, HotCocoa, and more!

2010-11-14 Thread Leigh Caplan
I had digest mode turned on, so this reply might be orphaned. Sorry in advance 
if that's the case.

Thanks Matt for showing me your HTTP wrapper... there are some good ideas there.

In reply to Josh, what would be the advantages of using NSURLConnection as the 
transport for the net/* libraries? I can see that having access to two 
different built-in mechanisms for dealing with the network may be confusing; I 
used NSURLConnection as an example, but there are many facets of Cocoa which 
don't have corresponding support in Ruby, and that's where I see a great 
opportunity for a wrapper library. I just find it way easier to reason about my 
code if async callbacks are defined inline using procs and the like.

I can also see disadvantages to this approach, such as extra indirection whilst 
debugging, and potential for more memory usage if the implementers (read: me) 
aren't careful about making sure that stored procs eventually go out of scope.

Additionally, it probably wouldn't make sense to wrap everything in all the 
frameworks– we could probably identify logical groups of classes where having 
more Ruby-like conventions would be a good fit. I'll go over 
Foundation.framework in the next week and see if I can do just that.

Leigh
___
MacRuby-devel mailing list
[email protected]
http://lists.macosforge.org/mailman/listinfo.cgi/macruby-devel