WinForms event handling

Ruby IronRuby
1

Hi,

I was doing a bit of experimenting with ironruby today to see if it
might be useful for some prototyping work that I’m doing. I noticed
that any of the strings returned from the CLR don’t automatically
include the ruby string methods. I would’ve expected that these would
be mapped directly so that you could call @textfield.text.strip instead
of @textfield.text.trim.

Probably low on the priority list, but was just curious what the plan
was. Assignment to locally created string references doesn’t help
either. I know it’s early days yet, but this sort of thing will make it
difficult for people to remember which API applies where–especially if
CLR strings “escape” a particular method context.

Interesting things seem to also happen if you try and create a CLR type
directly:

C:>ir -v
IronRuby 0.3 0.3.0.0 on .NET 2.0.0.0

C:>iirb
irb(main):001:0> require ‘mscorlib’
=> true
irb(main):002:0> s = System::String.new “fubar”
TypeError: can’t convert String into System::Char*
from (irb):0
from :0:in eval' from workspace.rb:80:in evaluate’
from context.rb:217:in evaluate' from irb.rb:147:in eval_input’
from irb.rb:253:in signal_status' from irb.rb:146:in eval_input’
from ruby-lex.rb:230:in each_top_level_statement' from :0:in loop’
from ruby-lex.rb:229:in each_top_level_statement' from :0:in catch’
from ruby-lex.rb:227:in each_top_level_statement' from irb.rb:102:in eval_input’
from irb.rb:69:in start' from :0:in catch’
from irb.rb:51:in `start’
from iirb:0irb(main):003:0>

The only way that I’ve found to ensure that it’s really a Ruby string is
to do something like this

s = “” << clrstring

Has anyone else hit this yet?

Cheers,

ast

Andrew S. Townley [email protected]
http://atownley.org

2

In the latest builds this will work:

s = System::String.new ‘fubar’
=> ‘fubar’

s.class
=> System::String

Note that the result is single-quoted; that’s a little hint that it’s a
System::String rather than a Ruby String. The reason they are different
is mutability; Ruby strings are mutable, while the CLR’s are not.
Unfortunately this means that not all the methods on a Ruby string can
work on a CLR string (like sub!, slice!, etc), but we have added any
non-mutable methods to CLR strings:

s.upcase
=> “FUBAR”

And any mutable methods will throw:

s.upcase!
:0: Mutating method `upcase!’ called for an immutable string
(System::String) (TypeError)

3

Hi Jimmy,

=> “FUBAR”

And any mutable methods will throw:

s.upcase!
:0: Mutating method `upcase!’ called for an immutable string (System::String) (TypeError)

I’d forgotten that CLR strings were immutable. It’s been a while since
I was doing anything on the CLR.

Cheers for the feedback.

ast

might be useful for some prototyping work that I’m doing. I noticed
CLR strings “escape” a particular method context.
irb(main):002:0> s = System::String.new “fubar”
from ruby-lex.rb:229:in `each_top_level_statement’
to do something like this
http://atownley.org

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Andrew S. Townley [email protected]
http://atownley.org

4

I’m assuming this is the 0.3 release from Rubyforge, is that correct?

In the newest build of IronRuby, @textfield.text.strip and
@textfield.text.trim both work. It also appears we have fixed the String
creation bug you mention (note that ‘’ is a ClrString and “” is a Ruby
String):

[11] > rbd
IronRuby 0.3.0.0 on .NET 2.0.50727.4913
Copyright (c) Microsoft Corporation. All rights reserved.

require ‘temp.dll’
=> true
Foo.bar
=> ‘hello world’
r = Foo.bar
=> ‘hello world’
r.trim
=> ‘hello world’
r.strip
=> “hello world”
s = System::String.new “fubar”
=> ‘fubar’
exit
C:\temp
[12] > gc temp.cs
public static class Foo {
public static string bar() {
return “hello world”;
}
}
C:\temp

This build can be built from sources at
http://github.com/ironruby/ironruby.git, or we should have a release in
the next week or so.

JD

5

Quick message from phone: if windows forms or wpf is an option for
you, have a look here:

Cheers

– Thibaut

Le 22 avr. 09 Ã 11:45, “Andrew S. Townley” [email protected] a
écrit :

6

Hi Jim

I’m assuming this is the 0.3 release from Rubyforge, is that correct?

Yes. That’s correct.

r = Foo.bar
public static class Foo {
public static string bar() {
return “hello world”;
}
}
C:\temp

This build can be built from sources at http://github.com/ironruby/ironruby.git, or we should have a release in the next week or so.

All sounds good. I hit another problem with the core library that I was
trying to bring to the CLR which will keep the IronRuby use on hold for
a while. It works with JRuby on both Windows and Linux, but one of the
gems I need, uuid, uses flock which chokes in the 0.3.0 build.

One of the other things I noticed trying to pull in code that works in
MRE and JRuby is that IronRuby asked me for gems that I’d never heard of
before on the other environments. It must be much more aggressive about
pre-compiling the dependencies than the other implementations. Perhaps
that’s part of the start-up time issue.

There’s ~12K lines of code in the library I’m experimenting with (not
counting the gems it uses–of which there are a few), and it takes
ages for the main import to return from iirb. This is probably better
in the next release too, so I’ll try again to see how it goes.

I’m looking forward to seeing this mature rapidly, because it looks like
the best option for building native Windows GUI applications with Ruby.
In fairness, that’s really the only reason that I’m interested in it.
The other options all seem to be not quite as polished as I’d like or
are too close to the Win32 API. I had my fill of that back in the days
when I was forced into MFC, so I don’t want to go there again if I don’t
have to.

In the near term, it’s looking like I’m going to have to go down the
JRuby route to get my application working on Windows. At the moment,
it’s using MRE and the Ruby/GNOME2 bindings under Linux, but I need it
on Windows for some things.

Hopefully, the main thrust of IronRuby really isn’t to deal with testing
or Silverlight, as it would seem to appear from most of the Google
search results. I think there’s a very real need for a complete Ruby
implementation that’s tightly integrated with the CLR for building
“real” applications for Windows in much the same way that Apple is
integrating YARV with the Cocoa APIs to make building apps for the Mac
much more straightforward.

I’ve used MFC/C++, WinForms/C#, JFC/Java, GTK+/Python & Ruby,
NEXTSTEP/AppKit/ObjC and a few other minor environments, and I’d prefer
never to go back to building UIs with compiled languages again. :slight_smile:

Thanks again for the help and the quick response. Keep up the good
work!

Cheers,

ast

Hi,
either. I know it’s early days yet, but this sort of thing will make
C:>iirb
from irb.rb:146:in `eval_input’

ast
Ironruby-core mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core

–
Andrew S. Townley [email protected]
http://atownley.org

7

On Wed, 2009-04-22 at 13:00 +0200, [email protected] wrote:

écrit :
Hi Thilbaut,

Thanks for the pointer. That might certainly work for the UI part.
However, I’m not sure that IronRuby’s quite ready for the rest of my
codebase.

It looks cool, though.

Cheers,

ast

Andrew S. Townley [email protected]
http://atownley.org