Hey Nick, what's the status on YAML IO? The other thread seems to have died. -- Sean Silva
On Oct 22, 2012, at 4:40 PM, Sean Silva wrote:> Hey Nick, what's the status on YAML IO? The other thread seems to have died.\I'm waiting on Michael Spencer's feedback. The issues I know of right now are: 1) Should we structure YAML I/O to be a more general I/O utility that could support reading and writing other data formats such as JSON or plists. RIght now, all the code is in the llvm::yaml:: namespace. I we planned to generalize later, only the yaml specific parts should be in the llvm::yaml namespace. You mentioned that YAML (1.2) is a superset of JSON. While that is true, there is some impedance mismatch: a) that does not help writing JSON documents, and b) there is the issue that JSON requires all strings to be quoted, whereas YAML does not. 2) Can the template meta programming used by YAML I/O work in C++03? My current implementation was written in C++11, but then back ported to C++03 in a way that works with clang, but may not work with other compilers. Here is an example: template <class T> struct has_output { private: static double test(...); #if __has_feature(cxx_access_control_sfinae) template <class U, class X> static auto test(U& u, X& x) -> decltype(U::output(std::declval<const X&>(), std::declval<llvm::raw_ostream&>()), char()); #else template <class U, class X> static __typeof__(U::output(std::declval<const X&>(), std::declval<llvm::raw_ostream&>()), char()) test(U& u, X& x); #endif public: static const bool value = (sizeof(test(std::declval<ScalarTraits<T>&>(), std::declval<T&>())) == 1); }; -Nick
On Oct 22, 2012, at 5:07 PM, Nick Kledzik wrote:> On Oct 22, 2012, at 4:40 PM, Sean Silva wrote: >> Hey Nick, what's the status on YAML IO? The other thread seems to have died. > > I'm waiting on Michael Spencer's feedback.To better understand how a client would use YAML I/O. I've completely rewritten the ReaderYAML and WriterYAML in lld to use YAML I/O. The source code is now about half the size. But more importantly, the error checking is much, much better and any time an attribute (e.g. of an Atom) is changed or added, there is just one place to update the yaml code instead of two places (the reader and writer). This code requires no changes to the rest of lld. The traits based approach was thus non-invasive. It is able to produce yaml from existing data structures and when reading yaml recreate the existing data structures. The example also shows how context sensitive yaml conversion is done, using io.getContext() to make conversion decisions. The StringRef ownership works, but is a little clunky. Because one yaml stream can contain many documents, the ownership of the input file MemoryBuffer cannot be handed off to the newly created lld::File object (which would have allowed any StringRefs provided by the parse to be used as is). Instead whenever a trait needs to keep a StringRef it must make a copy of the underlying string, and the copies are owned by the generated lld::File object. -------------- next part -------------- A non-text attachment was scrubbed... Name: ReaderWriterYAML.cpp Type: application/octet-stream Size: 42575 bytes Desc: not available URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20121024/90283f3f/attachment.obj> -------------- next part -------------- -Nick