summaryrefslogtreecommitdiffstats
path: root/2021/talks/bindat.md
blob: e9cfffaa7eea557f8879a7ca4fd211b76abcdbb4 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
[[!meta title="Turbo Bindat"]]
[[!meta copyright="Copyright © 2021 Stefan Monnier"]]
[[!inline pages="internal(2021/info/bindat-nav)" raw="yes"]]

<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Turbo Bindat
Stefan Monnier

[[!inline pages="internal(2021/info/bindat-schedule)" raw="yes"]]


# Table of Contents



Bindat is an ELisp library to help manipulate binary data. This is a
niche library that is used by packages such as Websocket, EMMS, and
cpio-mode. Its implementation was repeatedly caught harassing hapless
kitten while at the same time providing poor service slowly. For
Emacs-28, Bindat was rewritten so as to make it more efficient and
flexible while respecting the kitten. In this presentation I intent to
show how we saved those. Not recommended for birds.

# Discussion

-   Q1: bindat seems very similar to GNU Poke (except that GNU Poke is a
    superset, and then some, with a different syntax). I'm wondering if
    it might be good to add a bindat variant that translates to/from
    Poke if need be (using libpoke), for sheer insane blazing
    native-code JITted speed. (And, later, maybe letting bindat gain
    some of the insanely expressive capabilities GNU Poke has got). Its
    use of eval blocked this in times past. but now...
    -   A:GNU Poke is indeed the natural evolution, and is much more
        powerful.  Given the fairly little use of BinDat so far, I'm
        not sure there will be enough motivation to give access to GNU
        Poke from Emacs, tho.  One of the main benefits of using GNU
        Poke would probably be that lots of formats are already
        available for GNU Poke, so you could directly re-use them.
-   Q2: Is your dog's name something Lisp or PL related...? :)
    -   A:Winnie?  I don't think so, no (we didn't choose the name, in
        any case)
-   Q3: This looks amazing!  Is it merged into mainline Emacs, a patch,
    an external library?
    -   A: It's in Emacs-28
-   Q4: Are there benchmarks of this vs. the older bindat?
    -   A:There is a benchmark for it in the `elisp-benchmarks`
-   Q5: Do you know of any CL or Scheme libs similar to bindat.el?
    -   A: No, but I'd be interested to hear about it if someone else
        does.
-   Q7:  You are a hero of kittens everywhere.  Do you have any feline
    pets as well?  :)
    -   A: Not yet.  If you're near Montreal and you have a kitten for
        me, I'm interested
- I *hope* cl-loop is more efficient than building a bunch of intermediate lists when you chain map/filter/reduce operations.
- Curious: how is gnu poke more flexible?
- What hobbies/interests do you have besides Emacs (and PL)?  :)
- do you have any thoughts about how to make EmacsConf even better next year?
- I was surprised to see that a whole new DSL was developed for poke from scratch. Do you think would have been better to develop/improve a library like bindat on top of an existing language instead?
- What are some of your favorite talks from this conf so far?
- what kind of dog is Winnie?
  - comment: I hadn't heard of that breed before
- How do you see more control over types (type hints/decl through type specifiers etc) (SBCL like programming model) coming into Elisp?
- Do you plan to add bit-level support?

Other comments:

- I can imagine using bindat to improve Emacs's music player packages
- yes last year the Q&A periods were much longer
  - last year some of the presentations were live though
- I've asked this question to them during LPC 2020 but infact haven't got a very satisfactory answer :)
- If you ever write a library for window management in Emacs, you could call it winnie.el :)
- hints in unoptimized code should be assertions
- we probably need both ways of compiling: safe and less safe :)
- I think this is classic problem that is almost impossible to accomplish. many libraries try to do that but in the end the only  working ones are relaying on C compilers.
- also you have the problem of size of objects. like how big is a long? this is not specified and is arch dependent
- parsing a generic .h file is way more difficult but is another subject.
- yep, the automatic translation is more for libraries trying to write automatically C bindings

[[!inline pages="internal(2021/captions/bindat)" raw="yes"]]

[[!inline pages="internal(2021/info/bindat-nav)" raw="yes"]]