Hi Jim
> I'm assuming this is the 0.3 release from Rubyforge, is that correct?
Yes. That's 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.
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. :)
Thanks again for the help and the quick response. Keep up the good work!
Cheers,
ast
>
> JD
>
> > -----Original Message-----
> > From: ironruby-core-boun...@rubyforge.org [mailto:ironruby-core-
> > boun...@rubyforge.org] On Behalf Of Andrew S. Townley
> > Sent: Tuesday, April 21, 2009 10:08 AM
> > To: ironruby-core@rubyforge.org
> > Subject: [Ironruby-core] WinForms event handling
> >
> > 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 <a...@atownley.org>
> > http://atownley.org
> >
> > _______________________________________________
> > Ironruby-core mailing list
> > Ironruby-core@rubyforge.org
> > http://rubyforge.org/mailman/listinfo/ironruby-core
>
> _______________________________________________
> Ironruby-core mailing list
> Ironruby-core@rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
--
Andrew S. Townley <a...@atownley.org>
http://atownley.org
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
