> - I think you should have one module, `msgpack` that exports everything
OK. I my defense, I was originally planning to have a number of ‘pack-*’
methods like ‘pack-uin8’, ‘pack-uint16’ and so on, but there was nothing to be
gained but a bloated interface.
> - You should rewrite your modules to use the `#lang racket/base`
> language so they don't force users to import so much stuff
Good idea, I’ll do that.
> - On integer->integer-bytes, I think that we should support 8-bit
> integers, but in the meantime, I think you should write your own
> version (integer->integer-bytes*) rather than having the handling in
> many places in the code.
Yes, I’ll do that eventually, I was just exhausted from getting it working and
presentable first.
> - 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?
> - 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.
> - 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
> <hiph...@openmailbox.org> 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.
>
>
>
> --
> -=[ 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 racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
