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 -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080612/5fd69219/attachment.html>
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 Lam (IRONRUBY) <jflam at
microsoft.com>
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
> Ironruby-core at rubyforge.org
> http://rubyforge.org/mailman/listinfo/ironruby-core
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080613/de6939e8/attachment.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Thursday, June 12, 2008 8:08 PM
To: ironruby-core at rubyforge.org
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 Lam (IRONRUBY) <jflam at
microsoft.com<mailto:jflam at microsoft.com>> 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
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080612/ead5e24b/attachment-0001.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Dino Viehland
Sent: Thursday, June 12, 2008 8:21 PM
To: ironruby-core at rubyforge.org
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Thursday, June 12, 2008 8:08 PM
To: ironruby-core at rubyforge.org
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 Lam (IRONRUBY) <jflam at
microsoft.com<mailto:jflam at microsoft.com>> 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
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080612/f574c5d3/attachment.html>
Cool passing it a bool makes it work :) I stole the function of Andrew Peters 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 Hagenlocher <curth at microsoft.com> 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:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Dino Viehland > *Sent:* Thursday, June 12, 2008 8:21 PM > > *To:* ironruby-core at rubyforge.org > *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:* ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] *On Behalf Of *Ivan Porto Carrero > *Sent:* Thursday, June 12, 2008 8:08 PM > *To:* ironruby-core at rubyforge.org > *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 Lam (IRONRUBY) <jflam at microsoft.com> > 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 > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080613/1de9c9e5/attachment-0001.html>
Except there is a bug... o.dispose if o :-) On Fri, Jun 13, 2008 at 3:45 PM, Ivan Porto Carrero <ivan at flanders.co.nz> wrote:> Cool passing it a bool makes it work :) > > I stole the function of Andrew Peters 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 Hagenlocher <curth at microsoft.com> > 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:* ironruby-core-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Dino Viehland >> *Sent:* Thursday, June 12, 2008 8:21 PM >> >> *To:* ironruby-core at rubyforge.org >> *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:* ironruby-core-bounces at rubyforge.org [mailto: >> ironruby-core-bounces at rubyforge.org] *On Behalf Of *Ivan Porto Carrero >> *Sent:* Thursday, June 12, 2008 8:08 PM >> *To:* ironruby-core at rubyforge.org >> *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 Lam (IRONRUBY) <jflam at microsoft.com> >> 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 >> 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 >> >> > > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080613/8d0c7056/attachment.html>
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: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Ivan Porto Carrero
Sent: Thursday, June 12, 2008 8:46 PM
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] SVN r114 is out
Cool passing it a bool makes it work :)
I stole the function of Andrew Peters 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 Hagenlocher <curth at
microsoft.com<mailto:curth at microsoft.com>> 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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Dino Viehland
Sent: Thursday, June 12, 2008 8:21 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
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: ironruby-core-bounces at rubyforge.org<mailto:ironruby-core-bounces at
rubyforge.org> [mailto:ironruby-core-bounces at
rubyforge.org<mailto:ironruby-core-bounces at rubyforge.org>] On Behalf Of
Ivan Porto Carrero
Sent: Thursday, June 12, 2008 8:08 PM
To: ironruby-core at rubyforge.org<mailto:ironruby-core at rubyforge.org>
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 Lam (IRONRUBY) <jflam at
microsoft.com<mailto:jflam at microsoft.com>> 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
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org<mailto:Ironruby-core at rubyforge.org>
http://rubyforge.org/mailman/listinfo/ironruby-core
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://rubyforge.org/pipermail/ironruby-core/attachments/20080612/8d250b05/attachment-0001.html>