Again let me know if you think I should stop and do something else or
if you want to get involved.
John M. has been working in his spare time on porting Ola’s JvYAML
parser to .NET and he’s made quite a lot of progress already. It’s
probably the best direct port that is out there.
That said, we’re running into problems with our MutableString
implementation that we have to address first since the next major sets
of things that we’re looking to get working are Regex and YAML.
If you’re looking for things to work on, porting JRuby’s Regex engine
would be awesome … we’re meeting today to hash out some details about
our string implementation and I’ll post later on how we’re proceeding
with that.
On Fri, 01 Feb 2008 05:38:07 -0700, Peter Bacon D. [email protected] wrote:
The PyYaml processor is MIT licensed and the implantation is fairly
straightforward to follow. I have modified the google Yaml.NET project
to
be MIT licensed too. It appears from John L.'s posts last September
that
MS permissive + MIT would be acceptable.
Right on. Will PyYaml run via IronPython? If yes, then why not just
place
focus on using PyYaml directly via the DLR?
I think it would be good to get a C# port up and running and then
look at F# and how it could fit in/replace bits.
Good idea. For runtime reference I’ve created an IKVM’d version of
JRuby
You can reference the code in any C# source file via adding reference to
the jruby.dll file contained in the above directory and then adding
whichever from the following list you might need,
using org.jvyamlb;
using org.jvyamlb.events;
using org.jvyamlb.nodes;
using org.jvyamlb.tokens;
using org.jvyamlb.utils;
There are of course
Silverlight issues - do the F# libraries run on it?
On Fri, 01 Feb 2008 07:41:34 -0700, John L. (DLR) [email protected]
wrote:
John M. has been working in his spare time on porting Ola’s JvYAML
parser to .NET and he’s made quite a lot of progress already. It’s
probably the best direct port that is out there.
So I was about to ask the following: “Does a list exist somewhere,
preferably on a wiki (though handwritten on a napkin would work for the
time being ;-), that provides a simple TODO:, TODONE:, and
TODONOTTOUCHTHISSPACE: list of project pieces?”
And then I decided “Before you make a fool of yourself, look on the
wiki!”
… or something to that effect? If nothing else, it would advertise
the
fact that these pages exists, and while it’s never going to be 100%
up-to-date, something is better than nothing.
And of course to update the wiki - way down at the bottom of the StdLib
page
is a lonely little Yaml? with no name attached.
John M would you like to open source your Yaml port or stick it into the
project I created? I think there are lots of .NET users out there who
are
not going to use Ruby or Python but might benefit from a decent Yaml
processor.
I will probably dump what I have done so far into the SVN at http://code.google.com/p/yaml-dot-net for the time being and see what
happens.
Pete
And of course to update the wiki - way down at the bottom of the StdLib
page is a lonely little Yaml? with no name attached.
Yikes. Will fix that.
John M would you like to open source your Yaml port or stick it into
the project I created? I think there are lots of .NET users out there
who are not going to use Ruby or Python but might benefit from a decent
Yaml processor.
This makes sense if when we refactor the parser from the API. I suspect
it’s probably factored that way in JvYAML today, but jomes knows for
sure.
Sorry to be so late to the YAML party. I started working on a port of
JvYAML to C# last fall, but the absence of a byte-based MutableString
makes
it very hard to get it right. I eventually made my own MutableString as
a
placeholder, but there are still alot of holes and issues and bugs and
issues with the code I ended up with.
I’m excited to hear that John M is working on a port. How can I best
help?
I had started working on porting JvYaml to c#. It is really rough,
currently
exporting to Yaml is working, I didn’t get a chance to start on the
other
direction though. I don’t know if it’s of any value, but I would be more
than happy to contribute what I got working.
IronRuby’s YAML library needs to more than just be a YAML lib available
to
.NET. It needs to match the API that the Ruby lib implemented with Syck
has. It has a particular API, which is why Ola wrote RbYAML in the
first
place. We could use RbYAML (which is written entirely in Ruby) for the
yaml
lib in IronRuby, but the JRuby guys found that the performance wasn’t
there.
YAML is used in lots of apps, and having it be an order of magnitude
slower
on one platform vs. the other isn’t good. So Ola wrote JvYAML, which
follows the Syck API but is written in Java. That’s the port I started
on,
and that’s what John M is currently working on.
I understand there are other YAML libs out there. Personally, I’d love
to
experiment with F# to get one written. But unless they follow Syck then
they won’t match what Ruby already has. I know there was an effort at a
university somewhere to write a C# port of Syck, but I don’t think it
was
ever released. And I seem to remember the JRuby guys saying that it was
simpler to write it in Java than port Syck. Also, I seem to recall Syck
isn’t going to be worked on anymore.
