[#15359] Timeout::Error — Jeremy Thurgood <jerith@...>

Good day,

41 messages 2008/02/05
[#15366] Re: Timeout::Error — Eric Hodel <drbrain@...7.net> 2008/02/06

On Feb 5, 2008, at 06:20 AM, Jeremy Thurgood wrote:

[#15370] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Eric Hodel wrote:

[#15373] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15374] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/06

Nobuyoshi Nakada wrote:

[#15412] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15413] Re: Timeout::Error — Jeremy Thurgood <jerith@...> 2008/02/07

Nobuyoshi Nakada wrote:

[#15414] Re: Timeout::Error — Nobuyoshi Nakada <nobu@...> 2008/02/07

Hi,

[#15360] reopen: can't change access mode from "w+" to "w"? — Sam Ruby <rubys@...>

I ran 'rake test' on test/spec [1], using

16 messages 2008/02/05
[#15369] Re: reopen: can't change access mode from "w+" to "w"? — Nobuyoshi Nakada <nobu@...> 2008/02/06

Hi,

[#15389] STDIN encoding differs from default source file encoding — Dave Thomas <dave@...>

This seems strange:

21 messages 2008/02/06
[#15392] Re: STDIN encoding differs from default source file encoding — Yukihiro Matsumoto <matz@...> 2008/02/06

Hi,

[#15481] very bad character performance on ruby1.9 — "Eric Mahurin" <eric.mahurin@...>

I'd like to bring up the issue of how characters are represented in

16 messages 2008/02/10

[#15528] Test::Unit maintainer — Kouhei Sutou <kou@...>

Hi Nathaniel, Ryan,

22 messages 2008/02/13

[#15551] Proc#curry — ts <decoux@...>

21 messages 2008/02/14
[#15557] Re: [1.9] Proc#curry — David Flanagan <david@...> 2008/02/15

ts wrote:

[#15558] Re: [1.9] Proc#curry — Yukihiro Matsumoto <matz@...> 2008/02/15

Hi,

[#15560] Re: Proc#curry — Trans <transfire@...> 2008/02/15

[#15585] Ruby M17N meeting summary — Martin Duerst <duerst@...>

This is a rough translation of the Japanese meeting summary

19 messages 2008/02/18

[#15596] possible bug in regexp lexing — Ryan Davis <ryand-ruby@...>

current:

17 messages 2008/02/19

[#15678] Re: [ANN] MacRuby — "Rick DeNatale" <rick.denatale@...>

On 2/27/08, Laurent Sansonetti <laurent.sansonetti@gmail.com> wrote:

18 messages 2008/02/28
[#15679] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 6:33 AM, Rick DeNatale <rick.denatale@gmail.com> wrote:

[#15680] Re: [ANN] MacRuby — Yukihiro Matsumoto <matz@...> 2008/02/28

Hi,

[#15683] Re: [ANN] MacRuby — "Laurent Sansonetti" <laurent.sansonetti@...> 2008/02/28

On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org> wrote:

Re: [ANN] MacRuby

From: "Laurent Sansonetti" <laurent.sansonetti@...>
Date: 2008-02-29 01:46:42 UTC
List: ruby-core #15689
On Thu, Feb 28, 2008 at 4:44 PM, Evan Phoenix <evan@fallingsnow.net> wrote:
>
>  On Feb 28, 2008, at 3:04 PM, Laurent Sansonetti wrote:
>
>  > On Thu, Feb 28, 2008 at 1:51 PM, Yukihiro Matsumoto <matz@ruby-lang.org
>  > > wrote:
>  >> Hi,
>  >>
>  >> In message "Re: [ANN] MacRuby"
>  >>
>  >>    on Fri, 29 Feb 2008 05:56:41 +0900, "Laurent Sansonetti" <laurent.sansonetti@gmail.com
>  >> > writes:
>  >>
>  >> |>     duck.foo(1, bar: 2)      #  mapped to foo:bar: what does an
>  >> |>  instance of C do with this?
>  >> |
>  >> |Here, MacRuby will check if duck responds to foo:bar:. If true, this
>  >> |message is sent with 1 and 2 as arguments. If not true, the foo
>  >> |message is sent instead with 1 and {:bar => 2} as arguments.
>  >> |
>  >> |If you're working with pure Ruby objects, the second code path
>  >> should
>  >> |always be taken. Unless you define foo:bar: in your Ruby class.
>  >> |
>  >> |Note that the key:value syntax to describe a hash pair is
>  >> available in
>  >> |vanilla 1.9.
>  >>
>  >> I still think having dedicated syntax for Objective-C call is better
>  >> than overriding normal call.
>  >>
>  >>
>  >>  duck.foo: 1 bar: 2
>  >>
>  >> or
>  >>
>  >>
>  >>  duck.foo: 1, bar: 2
>  >>
>  >> maybe?  I am not sure if the parser allows this or not yet.
>  >>
>  >
>
>  I thought about working up for Objective-C calling support via this
>  syntax:
>
>  O[duck :foo => 1, :bar => 2]
>
>  At one point, I had a small parser change that allowed this to be
>  written as:
>
>  O[duck foo: 1, bar: 2]
>
>  The idea was that the rubinius compiler would detect this special form
>  and emit the 'right thing'.
>

Your idea is surprising, but how would you do to override an Objective-C method?

>  I think a bit part of this is whether you expect users (and other
>  code) to know they're calling out to Objective-C, or if you want tight
>  integration. This is essential what matz says.
>

Yes I do agree with that.

>  By making special Objective-C syntax, then you can't pass in an
>  Objective-C object and expect it to be duck-typed like normal ruby
>  objects. But the trade off is that the syntax is less elegant. I think
>  it's a trade off, and my 2 cents is you should opt for the more
>  elegant syntax. This is because there are only a few tiny edge cases
>  where the Objective-C selector matches the ruby selector, where you'd
>  want to allow the ObjC object to be duck typed as something else.
> [...]
>
>  Something else that has not been brought up (that I saw) is whether
>  ruby methods are available as Objective-C methods. Can ruby methods be
>  called directly via the ObjC runtime?
>

In MacRuby, Ruby methods are in fact Objective-C methods, by default.
Everything is registered to the Objective-C runtime.

Calling them from Objective-C might be tricky sometimes, because Ruby
allows some characters in method names that Objective-C doesn't. But
using the runtime API (ex. objc_msgSend) should just work.

My point is, there should not be any special syntax to call
Objective-C methods because all methods are Objective-C methods. Or at
least, no extremely special syntax.

I do like the current implemented one, as many people so far.

  duck.foo 1, bar:2

A few people also like Matz's first suggestion, which is to specify
the ':' in the first part of the method call, because it's more
consistent with the selector that will be sent.

  duck.foo:1, bar:2

But so far, most of these people are Objective-C developers and not
Ruby developers.

Laurent

In This Thread