Hey Ola, I''m glad to hear you are supportive of us porting your code. (Although I honestly expected no less.) I''ll volunteer to work on the port and I may be asking some questions. Is it better to ask those questions directly to you? Or to the jruby-dev mailing list? John, Ola''s original JvYAML was licensed under MIT. But the code in JRuby (JvYAMLb) appears to be tri-licensed under CPL, GPL, and LGPL. Is this an issue? On 9/13/07, Ola Bini <ola.bini at gmail.com> wrote:> > John Lam (CLR) wrote: > > > > Before we get too far down into the implementation details, perhaps it > > might be better to just port JvYAML? I''m adding Ola to this mail ? Ola > > do you think it would be a straightforward port to C#? > > > > Thanks, > > > > -John > > > > *From:* Mike Moore [mailto:blowmage at gmail.com] > > *Sent:* Thursday, September 13, 2007 8:37 AM > > *To:* John Lam (CLR) > > *Cc:* Eric Nicholson; ironruby-core at rubyforge.org > > *Subject:* Re: [Ironruby-core] zlib implementation > > > > Syck doesn''t have a dependency on the Ruby parser, but it does use > > lex/yacc style gram.y file. I know that the Ruby.NET guys cracked that > > nut and reused Ruby''s parser.y file, and it looks like IronRuby has a > > Parser.y file as well. I honestly haven''t looked at this very closely > > since I first saw it in Ruby.NET, so I''m just assuming that a .NET > > version of Syck could also use Syck''s gram.y file as a starting place. > > > > Hi, > > I would personally stay as far away as possible from Syck - the grammer > is quite straight forward but the rest of the implementation uses a > whole slew of pointer tricks to work. Of course, you _could_ do the same > thing in C# by using unmanaged code, but I don''t think it would be worth > it. It also seems Syck have some reliability problems. (I have recently > created a few roundtrip test cases that fail with MRI - I shall submit > them as bugs too, of course...) > > JvYAML would be much simpler to port (and make sure to use the JvYAMLb > version that exists in the JRuby source repository). There are two main > problems with that approach: it isn''t well documented, so in many cases > it may not be obvious exactly why I do something the way I do it in the > code. Secondly, JvYAML started out as a 1.1-compliant YAML system, but > have grown into being more 1.0-compliant since Syck is (so I need to be > compatible). That means that sometimes the code is going through some > interesting hoops. > > None of this makes it a hard thing to port JvYAML though. It would > probably not take many days. > > Feel free to ask me if you have any questions. > > Cheers > > -- > Ola Bini (http://ola-bini.blogspot.com) > JRuby Core Developer > Developer, ThoughtWorks Studios (http://studios.thoughtworks.com) > > "Yields falsehood when quined" yields falsehood when quined. > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: http://rubyforge.org/pipermail/ironruby-core/attachments/20070913/a4fa4401/attachment.html
> From: Ola Bini [mailto:ola.bini at gmail.com] > > > John, Ola''s original JvYAML was licensed under MIT. But the code in > > JRuby (JvYAMLb) appears to be tri-licensed under CPL, GPL, and LGPL. > > Is this an issue? > > > Eh. CPL should be fairly free, but I could separate everything that I''m > the sole author of and relicense it if you really need. (That will be a > hassle with ByteList though, since that is a generic JRuby class, that > many have contributed to.) >We have an issue here that we want to drive through legal, which is releasing IronRuby under multiple licenses. This shouldn''t be a problem, but it is an issue if we are going to try and package IronRuby for release ourselves (which we should do). Like a lot of things that we do around here, it''s always simpler if we could take one step at a time. I suspect that MsPL + MIT as a start would be nice. MsPL + CPL would be fine too. But MsPL + GPL + LGPL would be a much harder sell. Is there a chance that we could identify the bits that are GPL + LGPL and reimplement them ourselves? Thanks, -John
> From: Mike Moore [mailto:blowmage at gmail.com] > Sent: Thursday, September 13, 2007 11:40 AM > To: Ola Bini > Cc: John Lam (CLR); Eric Nicholson; ironruby-core at rubyforge.org > Subject: [Ironruby-core] JvYAMLb Port (CsYAML?)> Hey Ola, I''m glad to hear you are supportive of us porting your code. (Although I > honestly expected no less.) I''ll volunteer to work on the port and I may be asking some > questions. Is it better to ask those questions directly to you? Or to the jruby-dev > mailing list?Thanks for volunteering to drive this, Mike! -John
Mike Moore wrote:> Hey Ola, I''m glad to hear you are supportive of us porting your code. > (Although I honestly expected no less.) I''ll volunteer to work on the > port and I may be asking some questions. Is it better to ask those > questions directly to you? Or to the jruby-dev mailing list? > > John, Ola''s original JvYAML was licensed under MIT. But the code in > JRuby (JvYAMLb) appears to be tri-licensed under CPL, GPL, and LGPL. Is > this an issue?One decision you''re going to have to make pretty early on is whether to support Ruby''s strings exactly or to try wrapping CLR string constructs that use UTF-16 characters. We started out with the latter, and aside from the obvious down side of doubling memory use for all strings, we ran into much more serious problems trying to get decent IO performance; every operation required encoding and decoding to/from bytes. Then there''s the issues with so many libraries just expecting to work with bytes, expecting UTF-8 logic in regular expressions and String methods, and it just got progressively more complicated. JvYAML has both a char and a byte-based version. The byte-based version is directly incorporated into JRuby, while the char-based version is free-standing. - Charlie
> From: Ola Bini [mailto:ola.bini at gmail.com] > > That''s not how it works. The whole code base of JRuby is CPL AND GPL AND > LGPL at the same time. Just choose the license that works best for you.Got it. Thanks! -John
> On Behalf Of Charles Oliver Nutter: > > One decision you''re going to have to make pretty early on is whether to > support Ruby''s strings exactly or to try wrapping CLR string constructs > that use UTF-16 characters. We started out with the latter, and aside > from the obvious down side of doubling memory use for all strings, we > ran into much more serious problems trying to get decent IO > performance; > every operation required encoding and decoding to/from bytes. Then > there''s the issues with so many libraries just expecting to work with > bytes, expecting UTF-8 logic in regular expressions and String methods, > and it just got progressively more complicated. > > JvYAML has both a char and a byte-based version. The byte-based version > is directly incorporated into JRuby, while the char-based version is > free-standing.We''re wrapping CLR char arrays right now. But we''re fully planning on going to bytes in the future once things settle down a bit. We''re erring on the side of letting some things just work today vs. doing this correctly the first time and taking longer. We should start with the char based version today with an eye of moving toward the byte-based version once we fix MutableString. Thanks for the advice, Charlie! -John
John Lam (CLR) wrote:> We''re wrapping CLR char arrays right now. But we''re fully planning on going to bytes in the future once things settle down a bit. We''re erring on the side of letting some things just work today vs. doing this correctly the first time and taking longer. > > We should start with the char based version today with an eye of moving toward the byte-based version once we fix MutableString. > > Thanks for the advice, Charlie!I would be very interested in hearing your strategies for integrating with the rest of the CLR once you move to bytes. That''s the big trade-off we''ve had to make, translating byte-based strings to char-based strings and back whenever they cross that boundary. That''s a lot of overhead I wish we could avoid, and I suppose you''ll have to cope with that in one way or another as well. - Charlie