search for: readeryaml

...te: > 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...

> 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...

...which turns the yaml into an in-memory binary object, then runs the Reader to return a File*. I'll be prototyping this approach for mach-o. -Nick On Oct 25, 2012, at 9:59 AM, Sean Silva wrote: >> 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...

...object, then runs the > Reader to return a File*. I'll be prototyping this approach for mach-o. > > -Nick > > > On Oct 25, 2012, at 9:59 AM, Sean Silva wrote: >>> 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 upd...

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

Hey Nick, what's the status on YAML IO? The other thread seems to have died. -- Sean Silva

..., then runs the Reader to return a File*. I'll be prototyping this approach for mach-o. >> >> -Nick >> >> >> On Oct 25, 2012, at 9:59 AM, Sean Silva wrote: >>>> 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...

...Reader ? > Do you mean different than if the yaml reader accepts it? Tons of > files will be valid yaml syntactically. It is the semantic level > checking that is hard, and that is what YAML I/O does. > Yes, if the YAML reader accepts it and figures out that its not the format what ReaderYAML needs. >> 2) How are you plannning to represent section groups in the YAML ? > You mean the ELF concept of section groups in YAML encoded ELF? The > YAML encoding of ELF (or COFF or mach-o) does not know anything deeper > about the meaning of the files. It is just the bytes fro...