You probably want `integer-in` for the contract on `ext`. Have you read about the special treatment of test submodules? https://docs.racket-lang.org/guide/Module_Syntax.html#%28part._main-and-test%29
That is the idiomatic Racket way to write tests that run automatically when you want them and don't get in the way when you don't. If you have particularly extensive tests, it can also make sense to have a file where the program consists of nothing but the test submodule. -Philip On Mon, Jul 24, 2017 at 5:50 PM, Alejandro Sanchez <hiph...@openmailbox.org> wrote: > > > On 24 Jul 2017, at 22:40, Jay McCarthy <jay.mccar...@gmail.com> wrote: > > > > On Mon, Jul 24, 2017 at 3:18 PM, Alejandro Sanchez > > <hiph...@openmailbox.org> 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 > >>> <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; ]=- > >> > > > > > > > > -- > > -=[ 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. > -- 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.
