<div dir="ltr">Well, I don't know what language you are using, but the only protobuf implementation for ocaml (piqi) is actually pretty powerful in that you can write a piqi spec, and then export it to json, xml and from protobuf export you can automatically go between language vernacular representation to serialized string, it's very straight forward. I'm really not even certain if that handles your use case, but just using piqi doesn't mean you have to use ocaml. You can use whatever language you want if you can just export your data via protobuf, because there are bindings for protobuf in just about every single language. <br><br>I'm currently working on some improvements to it that should make it more capable of handling large amounts of data much better in that it will make library usage tail recursive.</div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Jun 26, 2015 at 8:29 PM, Alec Taylor <span dir="ltr"><<a href="mailto:alec.taylor6@gmail.com" target="_blank">alec.taylor6@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">*bump*<br></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Jun 21, 2015 at 8:10 AM, Alec Taylor <span dir="ltr"><<a href="mailto:alec.taylor6@gmail.com" target="_blank">alec.taylor6@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Dear Stephen, Kenneth and <the rest of the mailing-list>,<div><br></div><div>Thanks for your replies.</div><div><br></div><div>Was intentionally not giving the full picture (because I didn't want the cake given away; I.e.: wanted to figure things out for myself [then open-source it all]).<br><br>Anyway, I'll tell you why I want JSON as the intermediary and what kind of format it should confirm to.</div><div><br></div><div>Here's an example setup when applied to the Web domain, but it would also apply to other domains:</div><div>0. JSON written that generates documentation for the user/developer</div><div>1. This JSON then used to generate a REST API in language <y>, including database models, endpoints and t<span style="color:rgb(34,34,34);font-size:14px;line-height:22.1200008392334px">ests</span> with JSON mocks (via LLVM). Additionally input validation code will be attached to the models (and/or endpoints)</div><div>2. Language <y> edited in a restricted place (e.g.: adding a new mock and a new field to the database model, and adding a new endpoint)*</div><div>3. "JSON documentation" (like 0.) generated from this source-code (via LLVM)</div><div>4. JSON documentation used to generate frontend code, including tests with mocks, endpoint request (success/error handling), input validation & form generation (via JSON schema)</div><div>5. Restricted* changes made to frontend code, e.g.: validation logic (regex?)</div><div>6. Repeat 3. Repeat 1.</div><div><br></div><div>By 6. you start to see the advantage of merging the changed into an existing code-base (rather than starting fresh). The existing code-base would have all the implementation specific logic, such as widgets and themes on the frontend, and transaction design, caching and complex database queries on the REST API end.</div><div><br></div><div>Will likely confirm to the API Blueprint (AST [JSON]) format or Swagger. In addition to them thinking of edge-cases I haven't, they also do some [limited] code-generation themselves, such as basic clients (and sometimes servers) in various languages, and HTML documentation.</div><div><br></div><div>Now that you know my full use-case you'll be better equipped to provide suggestions with how to proceed</div><div><br></div><div>Thanks for your continued help,</div><div><br></div><div>Alec Taylor</div><div><br></div><div>* Edits to non-restricted places are fine, but won't get picked up by the JSON generator</div><div><br>PS: capn proto is awesome [for unrelated stuff], thanks for the link :)</div><div><br>PPS: As I flesh this out more and more, looks like I could generate everything from just looking in the tests rather than code from elsewhere<div><div><br><br>On Saturday, June 20, 2015, Kenneth Adam Miller <<a href="mailto:kennethadammiller@gmail.com" target="_blank">kennethadammiller@gmail.com</a>> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">Possibly protobuf or capn proto would be much more clean alternatives to json. I was working with interpreting instruction semantics a while back, and you shouldn't have to write a parser to get the data structure back into coherent form, you can get what you want automatically and have the structure isolated into a common schema.</div><div class="gmail_extra"><br><div class="gmail_quote">On Sat, Jun 20, 2015 at 9:22 AM, Stephen Cross <span dir="ltr"><<a>scross@scross.co.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> reproduce the code in that language<br>
<br>
</span>Is the intention to exactly reproduce the original source code? Or<br>
some code that's functionally equivalent?<br>
<div><div><br>
On Sat, Jun 20, 2015 at 8:05 AM, Alec Taylor <<a>alec.taylor6@gmail.com</a>> wrote:<br>
> Considering engineering my own code-generator. If I do go ahead, will<br>
> open-source the end result.<br>
><br>
> Needs to read [parse] one language, and output JSON (conformant to a<br>
> specific JSON-schema).<br>
><br>
> Then needs to read JSON, and reproduce the code in that language, and<br>
> [possibly] merge the generated code with existing code.<br>
><br>
> Languages I'm looking to support are all rather popular (Python, Go, Rust,<br>
> JavaScript).<br>
><br>
> Any pointers—e.g.: specific LLVM libraries and sub-projects to use—would be<br>
> appreciated.<br>
><br>
> Thanks<br>
><br>
</div></div>> _______________________________________________<br>
> LLVM Developers mailing list<br>
> <a>LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
> <a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
><br>
<br>
_______________________________________________<br>
LLVM Developers mailing list<br>
<a>LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" rel="noreferrer" target="_blank">http://llvm.cs.uiuc.edu</a><br>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" rel="noreferrer" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a><br>
</blockquote></div><br></div>
</blockquote></div></div></div>
</blockquote></div><br></div>
</div></div></blockquote></div><br></div>