Like we talked about earlier, let''s give an update on what we are working on I''m working on hacking optparse to work so that we can update to the newest Rubinius spec''s. Then I''ll be closing out a whole slew of bugs. Jim Deville -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080502/13a6c57d/attachment.html>
I''m still working on the shelveset that I sent out for code review
earlier today (bugfixes9). We found a few more issues when we did the code
review. The most interesting case is this one:
We normally define methods that accept symbol using a signature that takes a
SymbolId, eg:
[RubyMethod("attr", RubyMethodAttributes.PrivateInstance)]
public static void Attr(CodeContext/*!*/ context, RubyModule/*!*/ self, SymbolId
name) {
DefineAccessor(context, self, name, true, false);
}
Methods like these will blow up if you pass it a ''string-like''
thing. We have a Protocol to convert these things - Protocols.CastToSymbol(),
which does the right thing, which is call to_str on the target.
We have an open question right now which is whether we should bake in object to
SymbolId conversions in the binder or whether we should handle them in a case by
case basis by defining an overload that accepts an Object, and calling
Protocols.CastToSymbol() on that object.
Once I get this shelveset past the troll, I''ll work next on getting
socket.cs and the ironi regex library into the tree.
Thanks,
-John
From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at
rubyforge.org] On Behalf Of Jim Deville
Sent: Friday, May 02, 2008 2:37 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Friday Status Update
Like we talked about earlier, let''s give an update on what we are
working on
I''m working on hacking optparse to work so that we can update to the
newest Rubinius spec''s. Then I''ll be closing out a whole slew
of bugs.
Jim Deville
I''ve been looking at what it would take to start using byte arrays rather then strings for the backing store for MutableString. It''s one heck of a rabbit hole, I can get it /almost/ working... either I fail one spec, or three... and they''re totally different. Anyway, if noone else is working on it I''ll continue to see what I can do, this is related to the zlib issue with binary files (or actually any file that contains bytes over 127 potentially) as data is passed around as strings and not byte arrays. Oh and I hope to implement actual compression sometime soon.. just need to block out some time. On Fri, May 2, 2008 at 6:24 PM, John Lam (IRONRUBY) <jflam at microsoft.com> wrote:> I''m still working on the shelveset that I sent out for code review earlier > today (bugfixes9). We found a few more issues when we did the code review. > The most interesting case is this one: > > We normally define methods that accept symbol using a signature that takes > a SymbolId, eg: > > > [RubyMethod("attr", RubyMethodAttributes.PrivateInstance)] > public static void Attr(CodeContext/*!*/ context, RubyModule/*!*/ self, > SymbolId name) { > DefineAccessor(context, self, name, true, false); > } > > > Methods like these will blow up if you pass it a ''string-like'' thing. We > have a Protocol to convert these things - Protocols.CastToSymbol(), which > does the right thing, which is call to_str on the target. > > We have an open question right now which is whether we should bake in > object to SymbolId conversions in the binder or whether we should handle > them in a case by case basis by defining an overload that accepts an Object, > and calling Protocols.CastToSymbol() on that object. > > Once I get this shelveset past the troll, I''ll work next on getting > socket.cs and the ironi regex library into the tree. > > Thanks, > -John > > From: ironruby-core-bounces at rubyforge.org [mailto: > ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville > Sent: Friday, May 02, 2008 2:37 PM > To: ironruby-core at rubyforge.org > Subject: [Ironruby-core] Friday Status Update > > Like we talked about earlier, let''s give an update on what we are working > on > > I''m working on hacking optparse to work so that we can update to the > newest Rubinius spec''s. Then I''ll be closing out a whole slew of bugs. > > Jim Deville > _______________________________________________ > Ironruby-core mailing list > Ironruby-core at rubyforge.org > http://rubyforge.org/mailman/listinfo/ironruby-core >-- Michael Letterle [Polymath Prokrammer] http://blog.prokrams.com -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080502/621eae55/attachment.html>
Michael Letterle:> I''ve been looking at what it would take to start using byte arrays > rather then strings for the backing store for MutableString. It''s one > heck of a rabbit hole, I can get it /almost/ working... either I fail > one spec, or three... and they''re totally different. Anyway, if noone > else is working on it I''ll continue to see what I can do, this is > related to the zlib issue with binary files (or actually any file that > contains bytes over 127 potentially) as data is passed around as > strings and not byte arrays. > > Oh and I hope to implement actual compression sometime soon.. just > need to block out some time.Tomas has spent quite some time looking at a dual byte-array + char-array MutableString implementation. It was sitting in his work queue to tackle after his current work on eval and blocks. Perhaps you could share some of your findings with him around the zlib integration effort so that we don''t duplicate our efforts? Thanks! -John
I might be right off track here and since I haven''t seen any of the
detailed
discussion about the question below I might be being completely naive.
The open question should really be targeting all standard conversion
protocols in Ruby.
In my mind it seems that the way Ruby works generally is to have a load of
these "protocols" for type conversion, but that it is not enforced by
the
language at all and that it is entirely up the library developer to follow
suit. While this allows ultimate freedom for the developer it obviously
does allow inconsistency to creep in.
I would feel uncomfortable baking these protocols into the binder, unless
there was some way of overriding them in library code, since this is
perfectly possible in MRI. For instance, it must be possible in at least
some cases to monkey patch code that by default uses the standard conversion
protocol so that it does something different (e.g. converts strings to
symbols in some other way???)
Clearly this is not a good thing to do in general but since Ruby allows it
as a language, it seems that it should be supported in IronRuby.
Happy to be completely wrong here.
Pete
-----Original Message-----
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of John Lam
(IRONRUBY)
Sent: Friday,02 May 02, 2008 23:25
To: ironruby-core at rubyforge.org
Subject: Re: [Ironruby-core] Friday Status Update
I''m still working on the shelveset that I sent out for code review
earlier
today (bugfixes9). We found a few more issues when we did the code review.
The most interesting case is this one:
We normally define methods that accept symbol using a signature that takes a
SymbolId, eg:
[RubyMethod("attr", RubyMethodAttributes.PrivateInstance)]
public static void Attr(CodeContext/*!*/ context, RubyModule/*!*/ self,
SymbolId name) {
DefineAccessor(context, self, name, true, false);
}
Methods like these will blow up if you pass it a ''string-like''
thing. We
have a Protocol to convert these things - Protocols.CastToSymbol(), which
does the right thing, which is call to_str on the target.
We have an open question right now which is whether we should bake in object
to SymbolId conversions in the binder or whether we should handle them in a
case by case basis by defining an overload that accepts an Object, and
calling Protocols.CastToSymbol() on that object.
Once I get this shelveset past the troll, I''ll work next on getting
socket.cs and the ironi regex library into the tree.
Thanks,
-John
From: ironruby-core-bounces at rubyforge.org
[mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Jim Deville
Sent: Friday, May 02, 2008 2:37 PM
To: ironruby-core at rubyforge.org
Subject: [Ironruby-core] Friday Status Update
Like we talked about earlier, let''s give an update on what we are
working on
I''m working on hacking optparse to work so that we can update to the
newest
Rubinius spec''s. Then I''ll be closing out a whole slew of
bugs.
Jim Deville
_______________________________________________
Ironruby-core mailing list
Ironruby-core at rubyforge.org
http://rubyforge.org/mailman/listinfo/ironruby-core
Peter Bacon Darwin wrote:> I might be right off track here and since I haven''t seen any of the detailed > discussion about the question below I might be being completely naive. > > The open question should really be targeting all standard conversion > protocols in Ruby. > > In my mind it seems that the way Ruby works generally is to have a load of > these "protocols" for type conversion, but that it is not enforced by the > language at all and that it is entirely up the library developer to follow > suit. While this allows ultimate freedom for the developer it obviously > does allow inconsistency to creep in. > I would feel uncomfortable baking these protocols into the binder, unless > there was some way of overriding them in library code, since this is > perfectly possible in MRI. For instance, it must be possible in at least > some cases to monkey patch code that by default uses the standard conversion > protocol so that it does something different (e.g. converts strings to > symbols in some other way???) > > Clearly this is not a good thing to do in general but since Ruby allows it > as a language, it seems that it should be supported in IronRuby.FYI, there are a few cases in the core classes that use e.g to_s or to_a instead of to_str or to_ary to coerce. I don''t remember them off the top of my head. - Charlie
Yes, we have Protocols class that implements various flavors of conversions that are used in libraries. The binder idea is that there would be an attribute you can apply on C# methods that would disable the default conversions implemented in binder. So if 90% of methods do the conversion one way their implementation could be simplified. The rest would be marked by the attribute. Tomas -----Original Message----- From: ironruby-core-bounces at rubyforge.org [mailto:ironruby-core-bounces at rubyforge.org] On Behalf Of Charles Oliver Nutter Sent: Saturday, May 03, 2008 1:05 AM To: ironruby-core at rubyforge.org Subject: Re: [Ironruby-core] Friday Status Update Peter Bacon Darwin wrote:> I might be right off track here and since I haven''t seen any of the detailed > discussion about the question below I might be being completely naive. > > The open question should really be targeting all standard conversion > protocols in Ruby. > > In my mind it seems that the way Ruby works generally is to have a load of > these "protocols" for type conversion, but that it is not enforced by the > language at all and that it is entirely up the library developer to follow > suit. While this allows ultimate freedom for the developer it obviously > does allow inconsistency to creep in. > I would feel uncomfortable baking these protocols into the binder, unless > there was some way of overriding them in library code, since this is > perfectly possible in MRI. For instance, it must be possible in at least > some cases to monkey patch code that by default uses the standard conversion > protocol so that it does something different (e.g. converts strings to > symbols in some other way???) > > Clearly this is not a good thing to do in general but since Ruby allows it > as a language, it seems that it should be supported in IronRuby.FYI, there are a few cases in the core classes that use e.g to_s or to_a instead of to_str or to_ary to coerce. I don''t remember them off the top of my head. - Charlie _______________________________________________ Ironruby-core mailing list Ironruby-core at rubyforge.org http://rubyforge.org/mailman/listinfo/ironruby-core
Tomas Matousek wrote:> Yes, we have Protocols class that implements various flavors of conversions that are used in libraries. > The binder idea is that there would be an attribute you can apply on C# methods that would disable the default conversions implemented in binder. So if 90% of methods do the conversion one way their implementation could be simplified. The rest would be marked by the attribute.Nice, I''ll have to add that. At the moment, everything generifies to a common type, and the method itself calls the appropriate coercion mechanism. But it would be nice to eliminate that. - Charlie
Charles Oliver Nutter:> > The binder idea is that there would be an attribute you can apply on > C# methods that would disable the default conversions implemented in > binder. So if 90% of methods do the conversion one way their > implementation could be simplified. The rest would be marked by the > attribute. > > Nice, I''ll have to add that. At the moment, everything generifies to a > common type, and the method itself calls the appropriate coercion > mechanism. But it would be nice to eliminate that.The other nice thing about this is that it would be trivial to generate a report on all of the exceptions. This way we can drive some meaningful design discussions about all of the exceptional cases and get them fixed in the libs. -John
Lots of things are going on around here, and we have a few mutually interdependent changes that are causing a delay in getting a new update to SVN. We have a nasty blocking bug, #19971, that keeps us from running real programs (like the latest rubinius specs). It showed up on Monday as a result of a change to the DLR. The fix is on the way. Once it is checked in, we should be able to check in the latest rubinius specs that Jim has been working on, and show the results of running against them. http://rubyforge.org/tracker/index.php?func=detail&aid=19971&group_id=4359&atid=16798 Tomas has a new MutableString implementation that is being reviewed this morning. Once that is done and through SNAP, we''ll be able to apply my bugfixes shelveset that fixes a number of issues that are preventing various apps from running. Curt Hagenlocher has recently joined our team and is on loan to IronRuby for a few weeks. He is working on getting Dir#glob and File#fnmatch up and running. He''s also looking at getting Ruby marshaling up and running as well. Thanks, -John -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://rubyforge.org/pipermail/ironruby-core/attachments/20080509/1d11b585/attachment.html>