Hi Alejandro, This looks cool!
I don't see it listed at pkgs.racket-lang.org. It would be easier for users to discover it if you posted it there. Vincent On Mon, 24 Jul 2017 08:17:30 -0500, Alejandro Sanchez 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 racket-users+unsubscr...@googlegroups.com. > For more options, visit https://groups.google.com/d/optout. -- 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 racket-users+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
