On Tue, Jul 18, 2017 at 9:00 AM, Julián Díaz <[email protected]> wrote:
> Appreciate the endorsement! > > I did in fact borrow some of that test data directly, though there's an > interesting divergence in the TypeScript version of the packing algorithm > so I wound up editing segmented-packed by hand to match: > https://github.com/jdiaz5513/capnp-ts/pull/10. > Hmm. I suspect this is because the C++ implementation packs each segment separately, and so the two runs of zeros came before and after a segment boundary. Unfortunately, assuming my suspicion is correct, then I suspect the C++ implementation will not be able to unpack your version. This is because it unpacks each segment into a separate array, but for speed reasons the core unpacking loop targets a single array at a time and has no way to pass along its state to the next call. I suppose this needs to be documented. You can check if this is the case by using `capnp decode -p` on your version of the data. I suspect it will throw an error. If it doesn't throw an error, then I'm confused. -Kenton > Still making slow but steady progress writing tests and finding broken > stuff. I'll publish to npm once the serialization part isn't so... broken. > > - Julián > > On Monday, July 17, 2017 at 8:36:36 PM UTC-4, Kenton Varda wrote: >> >> So I looked at this today and I'm pretty impressed! Code looks clean and >> seems to be following best practices. I made some notes on the issue >> tracker, as you probably saw, but generally looks pretty good. I'm pretty >> excited to start using this -- and I really want to migrate Sandstorm to >> TypeScript. >> >> One question: Have you written tests using the test data in the capnp >> repo? >> >> https://github.com/capnproto/capnproto/tree/master/c++/src/capnp/testdata >> >> This would help check for any misreads of the spec. >> >> -Kenton >> >> On Thu, Jun 8, 2017 at 7:01 PM, Julián Díaz <[email protected]> wrote: >> >>> For those itching to get on the bleeding edge, I've got a working schema >>> compiler now! >>> >>> Serialization seems to be working okay with some unimplemented edges >>> here and there. Perhaps not surprisingly, I'm already seeing places where >>> this can outperform JSON.parse, so that's a major win! >>> >>> I almost had compile-to-JS support working as well, but the TypeScript >>> compiler is refusing to play nice with me right now. (See: >>> https://github.com/jdiaz5513/capnp-ts/issues/5) >>> >>> If anyone is really interested in using this stuff *today* please reach >>> out to me so I can better understand what you need and perhaps rearrange >>> how I implement things. Otherwise, there's still lots to do before 1.0.0! >>> >>> PS: For the compiler nerds: the schema compiler actually uses the >>> TypeScript compiler API directly to build an AST before printing it to a >>> file. >>> >>> On Thursday, May 11, 2017 at 12:58:03 PM UTC-4, Julián Díaz wrote: >>>> >>>> Can't use proxies at all in TypeScript unless I set the target to ES6 - >>>> right now I want to keep it compiling to ES5 so it's immediately useful for >>>> a wider range of people. >>>> >>>> It also seems like it's going to perform like crap: >>>> http://thecodebarbarian.com/thoughts-on-es6-proxies-performance.html >>>> >>>> I'll add it to the TODO, regardless; a separate ES6 build would be >>>> useful for many people. I could document it with the caveat that .get() >>>> will always be faster. >>>> >>>> On Thursday, May 11, 2017 at 11:10:16 AM UTC-4, Kenton Varda wrote: >>>>> >>>>> On Wed, May 10, 2017 at 11:17 PM, Mark Miller <[email protected]> >>>>> wrote: >>>>> >>>>>> https://kangax.github.io/compat-table/es6/ >>>>>> >>>>>> It looks like proxies are supported everywhere. >>>>>> >>>>> >>>>> Unfortunately a lot of people still use old browsers. >>>>> >>>>> http://caniuse.com/#feat=proxy -- click on the "usage relative" box. >>>>> >>>>> -Kenton >>>>> >>>>> >>>>>> >>>>>> >>>>>> On Wed, May 10, 2017 at 8:54 PM, Kenton Varda <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Sweet! >>>>>>> >>>>>>> Totally random comment from totally randomly opening a file and >>>>>>> looking at it: >>>>>>> >>>>>>> I see lists are accessed via a method .get(n). Have you considered >>>>>>> using proxies to allow array subscript [] syntax? I guess some 10-20% of >>>>>>> browsers still don't support proxies but that number will only go down. >>>>>>> >>>>>>> -Kenton >>>>>>> >>>>>>> On Tue, May 9, 2017 at 2:03 PM, Julián Díaz <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> I'm happy to report some real progress! >>>>>>>> >>>>>>>> https://github.com/jdiaz5513/capnp-ts >>>>>>>> >>>>>>>> Right now it's not very useful at all (I just barely have >>>>>>>> serialization working) but it's a solid starting point to wrap up the >>>>>>>> serialization API. The peanut gallery can start poking around to see >>>>>>>> how I >>>>>>>> organized things – it does depart slightly from the reference >>>>>>>> implementation but I'm still aiming to make an external API that's very >>>>>>>> similar to the C++ one. >>>>>>>> >>>>>>>> Once the Struct/List classes are complete I'll move on to the >>>>>>>> schema compiler, which looks like it'll be a cinch. Hoping I can keep >>>>>>>> up >>>>>>>> the steady progress from here. >>>>>>>> >>>>>>>> On Monday, April 10, 2017 at 1:45:01 AM UTC-4, Ian Denhardt wrote: >>>>>>>>> >>>>>>>>> Quoting Kenton Varda (2017-04-09 18:35:48) >>>>>>>>> >>>>>>>>> > 1) libcapnp and libkj together add up to some 730k of code >>>>>>>>> (text >>>>>>>>> > segment) these days. Unless emscripten builds are >>>>>>>>> significantly >>>>>>>>> > smaller, that's probably too big. >>>>>>>>> >>>>>>>>> Hard to know without trying it, but it may well be the case that >>>>>>>>> wasm >>>>>>>>> builds will be smaller. The VM seems to be designed for small code >>>>>>>>> size >>>>>>>>> (sensibly, given its target use case). This obviously doesn't >>>>>>>>> apply to >>>>>>>>> the asm.js output. >>>>>>>>> >>>>>>>>> That said, I agree having a pure JS implementation is preferable. >>>>>>>>> >>>>>>>> -- >>>>>>>> You received this message because you are subscribed to the Google >>>>>>>> Groups "Cap'n Proto" group. >>>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>>> send an email to [email protected]. >>>>>>>> Visit this group at https://groups.google.com/group/capnproto. >>>>>>>> >>>>>>> >>>>>>> -- >>>>>>> You received this message because you are subscribed to the Google >>>>>>> Groups "Cap'n Proto" group. >>>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>>> send an email to [email protected]. >>>>>>> Visit this group at https://groups.google.com/group/capnproto. >>>>>>> >>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> Cheers, >>>>>> --MarkM >>>>>> >>>>>> -- >>>>>> You received this message because you are subscribed to the Google >>>>>> Groups "Cap'n Proto" group. >>>>>> To unsubscribe from this group and stop receiving emails from it, >>>>>> send an email to [email protected]. >>>>>> Visit this group at https://groups.google.com/group/capnproto. >>>>>> >>>>> >>>>> -- >>> You received this message because you are subscribed to the Google >>> Groups "Cap'n Proto" group. >>> To unsubscribe from this group and stop receiving emails from it, send >>> an email to [email protected]. >>> Visit this group at https://groups.google.com/group/capnproto. >>> >> >> -- > You received this message because you are subscribed to the Google Groups > "Cap'n Proto" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to [email protected]. > Visit this group at https://groups.google.com/group/capnproto. > -- You received this message because you are subscribed to the Google Groups "Cap'n Proto" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. Visit this group at https://groups.google.com/group/capnproto.
