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 <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/ <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> https://github.com/neovim/neovim/wiki/Related-projects#api-clients <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.