Quick message from phone: if windows forms or wpf is an option for
you, have a look here:
Http://www.github.com/thbar/magic
Cheers
-- Thibaut
Le 22 avr. 09 à 11:45, "Andrew S. Townley" <a...@atownley.org> a
écrit :
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
_______________________________________________
Ironruby-core mailing list
Ironruby-core@rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
