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 <ast at atownley.org>
http://atownley.org
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)> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Andrew S. Townley > Sent: Tuesday, April 21, 2009 10:08 AM > To: ironruby-core at 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 <ast at atownley.org> > http://atownley.org > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
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''>>> exitC:\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> -----Original Message----- > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > bounces at rubyforge.org] On Behalf Of Andrew S. Townley > Sent: Tuesday, April 21, 2009 10:08 AM > To: ironruby-core at 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 <ast at atownley.org> > http://atownley.org > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
Hi Jimmy,> 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)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> > -----Original Message----- > > From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core- > > bounces at rubyforge.org] On Behalf Of Andrew S. Townley > > Sent: Tuesday, April 21, 2009 10:08 AM > > To: ironruby-core at 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 <ast at atownley.org> > > http://atownley.org > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-- Andrew S. Townley <ast at atownley.org> http://atownley.org
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-bounces at rubyforge.org [mailto:ironruby-core- > > bounces at rubyforge.org] On Behalf Of Andrew S. Townley > > Sent: Tuesday, April 21, 2009 10:08 AM > > To: ironruby-core at 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 <ast at atownley.org> > > http://atownley.org > > > > _______________________________________________ > > Ironruby-core mailing list > > Ironruby-core at rubyforge.org > > http://rubyforge.org/mailman/listinfo/ironruby-core > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core-- Andrew S. Townley <ast at atownley.org> http://atownley.org
thibaut.barrere at gmail.com
2009-Apr-22 11:00 UTC
[Ironruby-core] WinForms event handling
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" <ast at 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-bounces at rubyforge.org [mailto:ironruby-core- >>> bounces at rubyforge.org] On Behalf Of Andrew S. Townley >>> Sent: Tuesday, April 21, 2009 10:08 AM >>> To: ironruby-core at 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 <ast at atownley.org> >>> http://atownley.org >>> >>> _______________________________________________ >>> Ironruby-core mailing list >>> Ironruby-core at rubyforge.org >>> http://rubyforge.org/mailman/listinfo/ironruby-core >> >> _______________________________________________ >> Ironruby-core mailing list >> Ironruby-core at rubyforge.org >> http://rubyforge.org/mailman/listinfo/ironruby-core > > > -- > Andrew S. Townley <ast at atownley.org> > http://atownley.org > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core
On Wed, 2009-04-22 at 13:00 +0200, thibaut.barrere at gmail.com wrote:> 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" <ast at atownley.org> a > ?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 <ast at atownley.org> http://atownley.org