> On 24 Jul 2017, at 22:40, Jay McCarthy <[email protected]> wrote: > > On Mon, Jul 24, 2017 at 3:18 PM, Alejandro Sanchez > <[email protected]> wrote: >>> - I'm curious of the performance. In particular, I would expect that a >>> computed jump in unpack could do you good. Did you try that? >> I haven’t investigated performance yet. As I said, I am new to Racket, this >> is my first time doing anything useful in it, my only previous Scheme >> knowledge was from doing the exercises in SICP and dabbling in Guile a bit. >> What is a computed jump? > > Rather than having a big `cond`, you could look up the function that > does the work in a vector and then call it. IMHO, msgpack was designed > with that in mind, because tags that aren't immediate values are all > nicely ordered. So you'd check the size, subtract a constant, and grab > the appropriate procedure from a constant vector. OK, that’s the sort of thing I would have done in C where the tag would be an index into an array of function pointers. Can you please point me to where in the manual it explains how to profile a single function?
>>> - Your package collection is 'multi, which is fine, but normally you >>> just do that when you're defining something like data/heap or >>> net/turkeyrpc, where you are extending some existing collection. In >>> particular, you define msgpack and then you also define the test/pack >>> collection (where you might expect it to be tests/msgpack/pack). I >>> recommend having your collection be "msgpack" and putting your tests >>> inside a tests sub-directory. >> Just to make sure I understood correctly: ‘msgpack’ is the umbrella module >> that users import, ‘msgpack/test/pack’ (and ‘unpack’) are the test modules >> that will be run for testing only. How about the directory structure? I like >> to keep all source files in a source directory (my original reason for doing >> ‘multi), can I still do something like this? >> >> |-README >> |-LICENSE >> |-info.rkt >> |-source >> |-msgpack.rkt >> |-pack.rkt >> |-unpack.rkt >> |-test >> |-pack.rkt >> |-pack >> |- ... >> |-unpack.rkt >> |-unpack >> |- … >> >> It doesn’t have to be exactly this structure, but the idea is that all >> project-realted files are in the root, all the source files in the source >> directory and all the test files in the test directory. > > You can do that, but you'd have to have an additional `main.rkt` file > at the top-level that would require the things in `source` then > re-export them. It is not really Racket style to do what you're > talking about, however. If you did do that, then you could call the > `source` directory, `private` and then it would have a Racket-y name, > but your project isn't really large enough to warrant it and those > files aren't actually provide. > > Furthermore, your test/pack.rkt and test/unpack.rkt modules aren't > necessary, because you should be testing with `raco test -c msgpack`, > which will just go find everything. There's no need to build such > things yourself. (Although, FWIW, I also wouldn't have separate those > tests into such small files with just one or two, because they are, > again, so small.) I guess I’m weird that way, but I think of a project like a box. When you buy a thing and open the box you want all the contents to be neatly separated: here is the manual, here is the warranty card, here are the parts, all wrapped nicely in a bag. You wouldn’t want the contents to be loose and spill all over the floor. That’s why I like to separate the project into directories by functionality (documentation, source, tests, manuals, …). Oh well, if that is the Racket style I’ll do it your way. >>> - On a style level, I think you should remove your lets and turn your >>> if/begin blocks into conds, for example: >> Good point. >> >>> >>> On Mon, Jul 24, 2017 at 9:17 AM, Alejandro Sanchez >>> <[email protected]> wrote: >>>> Hello dear Racketeers, >>>> >>>> I have been writing an implementation of the MessagePack protocol for >>>> Racket >>>> and I think the library is ready to be showcased now: >>>> >>>> https://gitlab.com/HiPhish/MsgPack.rkt >>>> >>>> >>>> ### What is MessagePack? ### >>>> >>>> MessagePack is a binary data serialisation format. The website describes it >>>> "like JSON but fast and small". Unlike JSON the goal is not a format that's >>>> human-readable, but one that can be very quickly serialised, transported >>>> and >>>> serialised. >>>> >>>> http://msgpack.org/ >>>> >>>> >>>> ### About the Racket implementation ### >>>> >>>> My goal was to keep everything as simple as possible: there are only two >>>> functions: pack and unpack. If there is more than one way of packing an >>>> object >>>> the smallest format is selected automatically. Here is a taste: >>>> >>>> (require msgpack/pack msgpack/unpack) >>>> ;;; A wild hodgepodge to pack >>>> (define vec #(1 2 "hello" '(3 4) '() #t)) >>>> ;;; A byte string of packed data >>>> (define packed >>>> (call-with-output-bytes (λ (out) (pack vec out)))) >>>> ;;; Unpack the data again >>>> (define upacked >>>> (call-with-input-bytes packed (λ (in) (unpack in)))) >>>> >>>> >>>> As you can see, data is packed to and unpacked from a binary port. I think >>>> this >>>> is better than packing/unpacking to binary string because MessagePack is >>>> primarily used for inter-process communication, so there is not much point >>>> in >>>> keeping the packed data inside a process. >>>> >>>> I'd appreciate it a lot if a seasoned Racketeer could take a look at my >>>> code, >>>> in particular if the library is set up properly (the info.rkt files), this >>>> is >>>> my first time doing something in Racket. I am also open to suggestions >>>> about >>>> the API, I haven't committed to version 1.0 yet. In particular, I am not >>>> familiar with the modularity conventions of Racket libraries, i.e. if it is >>>> OK >>>> to have 'msgpack/pack' and 'msgpack/unpack' or if everything should be >>>> covered >>>> by one large 'provide' from 'msgpack'? There is one new type 'ext' >>>> declared, >>>> should that be part of 'msgpack' or should I move it to 'msgpack/types' >>>> instead? >>>> >>>> On a related note, I find it really annoying that 'integer->integer-bytes' >>>> and >>>> 'integer-bytes->integer' do not support 8-bit integers. Is there a reason >>>> for >>>> that? I had to write all sorts of ugly extra code for the 8-bit cases. I >>>> opened >>>> an issue on GitHub about it (#1754). >>>> >>>> >>>> ### What's next? ### >>>> >>>> Once the API settles I would like to move the library to typed Racket. I >>>> would >>>> also like to submit it to the Racket packages catalog. The reason I wrote >>>> this >>>> library is because I want to eventually write a Racket API client for >>>> Neovim: >>>> >>>> https://github.com/neovim/neovim >>>> https://github.com/neovim/neovim/wiki/Related-projects#api-clients >>>> >>>> Neovim is a fork of Vim which aims to stay backwards compatible with Vim, >>>> but >>>> at the same time bring the code base to modern standards, add long-wanted >>>> features and make the editor easier to extend. They have already done a lot >>>> of >>>> work, such asynchronous job control, a built-in terminal emulator, Lua >>>> scripting and in particular a remote API. >>>> >>>> The remote API allows one to write plugins in any language, provided there >>>> is a >>>> client for that language. In contrast, Vim has to be compiled with support >>>> for >>>> additional scripting languages and the integration burden was on the Vim >>>> developers. This meant that popular languages like Python would be pretty >>>> well >>>> supported, but more obscure languages were practically useless because no >>>> one >>>> would re-compile their Vim just for one plugin. The remote API approach >>>> means >>>> that Racket integration can be de-coupled from the editor development, and >>>> we >>>> can write plugins that can make use of Racket libraries. One could for >>>> example >>>> implement some of the DrRacket features using DrRacket as a library instead >>>> of >>>> re-inventing the wheel. It would also be possible to integrate Neovim >>>> inside >>>> DrRacket or write a Neovim GUI in Racket (GUIs are just very complex >>>> plugins >>>> in >>>> Neovim). >>>> >>>> -- >>>> You received this message because you are subscribed to the Google Groups >>>> "Racket Users" group. >>>> To unsubscribe from this group and stop receiving emails from it, send an >>>> email to [email protected]. >>>> For more options, visit https://groups.google.com/d/optout. >>> >>> >>> >>> -- >>> -=[ Jay McCarthy http://jeapostrophe.github.io ]=- >>> -=[ Associate Professor PLT @ CS @ UMass Lowell ]=- >>> -=[ Moses 1:33: And worlds without number have I created; ]=- >> > > > > -- > -=[ Jay McCarthy http://jeapostrophe.github.io ]=- > -=[ Associate Professor PLT @ CS @ UMass Lowell ]=- > -=[ Moses 1:33: And worlds without number have I created; ]=- -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/d/optout.
