But of course!
Unfortunately, the “with-bool†version won’t work for classes that don’t
follow that convention. And it looks like “arity†isn’t working for CLR
methods, so there’s no way to tell the difference.
From: [email protected]
[mailto:[email protected]] On Behalf Of Ivan Porto
Carrero
Sent: Thursday, June 12, 2008 8:46 PM
To: [email protected]
Subject: Re: [Ironruby-core] SVN r114 is out
Cool passing it a bool makes it work 
I stole the function of Andrew P. when I saw it I thought the same
thing
Do I submit a bug report for this?
On Fri, Jun 13, 2008 at 3:29 PM, Curt H.
<[email protected]mailto:[email protected]> wrote:
What’s changed since the last release is that we’re now exposing
protected members on CLR types as protected members on the Ruby class
that’s generated to represent the type. And in doing so, we’re
apparently hiding the (public) no-arg method on the base class. And
what’s more, it looks like the protected one-arg overload is also being
exposed as though it were public, and it shouldn’t be.
Improved CLR interop is very high on our priority list.
Nice function, btw, and an excellent example of the power of Ruby. If
only the language didn’t make life so hard on implementers…
From:
[email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]]
On Behalf Of Dino Viehland
Sent: Thursday, June 12, 2008 8:21 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] SVN r114 is out
StringReader defines dispose(bool disposing) and inherits dispose() from
TextReader. So it’s either that dispose(bool) is completely hiding the
inherited dispose or the overload resolution is completely broken –
probably the former. It’s probably related to exposing protected
members to everyone or just some bug in filtering protected members out.
From:
[email protected]mailto:[email protected]
[mailto:[email protected]mailto:[email protected]]
On Behalf Of Ivan Porto C.
Sent: Thursday, June 12, 2008 8:08 PM
To: [email protected]mailto:[email protected]
Subject: Re: [Ironruby-core] SVN r114 is out
What could be wrong here?
def using(o)
begin
yield if block_given?
ensure
o.dispose
end
end
This code worked until rev.113 but now it tells me :
$sr = StringReader.new(‘Hello, world’)
=> #System::IO::StringReader:0x0000060
$sr.dispose
:0:in Initialize': wrong number or type of arguments for dispose’
(ArgumentError)
Thanks
Ivan
On Fri, Jun 13, 2008 at 2:49 PM, John L. (IRONRUBY)
<[email protected]mailto:[email protected]> wrote:
This update contains the code we demo’d at RailsConf, and a few
improvements that we’ve made since then.
If you rake compile this build, it will generate an ir.cmd file for you
in the build\debug directory. The rakefile now looks for your MRI
install (by searching your PATH for ruby.exe). If you have your
build\debug directory on your path, this file will run correctly.
You will see a bunch of warnings when compiling. We know about these,
and will fix them soon (it’s the DLR folks deprecating a bunch of old
APIs).
I’ve also added a RubyTestKey.snk file which contains a public key. Our
assemblies are delay-signed using this key, and you must enable skip
verification to run the assemblies on your dev machine. You’ll need to
run the runfirst.cmd file in svn\trunk to turn on skip verification for
assemblies signed using our public key.
This should simplify some of the SIGN flag problems, although it
introduces a new set of problems around signing if you want to
distribute the signed assemblies. Unfortunately, we had to enable
signing on external builds because there’s some bug that only occurs
when running an unsigned build. We’re investigating this now.
Thanks,
-John
Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core
Ironruby-core mailing list
[email protected]mailto:[email protected]
http://rubyforge.org/mailman/listinfo/ironruby-core