freenode │20:09:20 jamwt | hi there.. you're the author of nom, right?
geeknode │21:46:19 geal | yes
mozilla │21:46:26 geal | do you need any help?
oftc │22:56:25 geal | if I do not see your message on irc in time, you can still send me your questions at contact@geoffroycouprie.com
2.#ilerouge │22:56:30 geal | I'll answer as soon as I can
3.#ccteam │23:44:32 jamwt | thanks! I think we sorted it out
4.#botnets.fr │23:44:40 jamwt | we're using it quite a bit at Dropbox
5.#botconf-orgas │23:44:48 jamwt | just trying to keep up with all the nightly activity
6.#rust-fr │-- Tue, 24 Mar 2015 --
7.#videolan │05:42:05 geal | jamwt: can I ask what you are doing with it at Dropbox? I would like to know more about use cases
8.#vlc-ports │05:42:44 geal | FYI, I am pushing a big update, either today or tomorrow, with the new unnamed parser syntax, to embed macro calls in other macros
9.#ecn │05:43:18 geal | this will make the code a lot easier to write
10.#cryptodotis │05:45:18 geal | https://github.com/Geal/nom/blob/master/README.md has been updated with the new syntax
11.#cryptocat │11:40:46 geal | ok, the new version is published on crates.io, 0.2.0. There is a small changelog describing the breaking changes since 0.1.6: https://github.com/Geal/nom/blob/master/CHANGELOG.md
12.#rust │11:41:29 geal | I am sorry I had to break the syntax, but it was needed to make nom better in the long run. Combined macros are very useful :)
13.#rust-osdev │-- Wed, 25 Mar 2015 --
14.#rust-gamedev │22:27:29 jamwt | yeah, no worries, we're all current now
15.#cryptoloutre │22:27:44 jamwt | we're using nom for two things right now
16.#last.tv │22:27:55 jamwt | 1. an in-house http system
17.#naohack │22:28:12 jamwt | 2. parsing rust backtraces to feed them into a reporting system
18.#exherbo │22:28:21 jamwt | (when they occur in production)
19.#haskell │22:29:01 jamwt | we have a kind of generalized exception tracking system, so we needed to standardize rust's stacks into that format
20.#guardianproject │22:29:21 geal | I see. Any reason you're not using other rust http implementations?
21.#tahoe-lafs │22:29:34 geal | managing software errors at scale is challenging, yes :)
22.#cryptography-dev │22:29:59 jamwt | we have a lot of very specific requirements that aren't usually available in open source implementations
23.#cryptosphere │22:30:02 jamwt | especially young ones
24.udgover │22:30:13 jamwt | like fine grained timeout stuff, specific size limits, etc
25.nicoo │22:30:25 jamwt | the second reason is the multiprocessing model is a little different for us
26.Indie │22:30:50 jamwt | we have I/O threads using mio and then a small worker pool that takes dispatched requests when they're completely ready to process
27.#hammer │22:31:06 jamwt | so we don't block threads on http I/O
28.shreshtha │22:31:43 jamwt | might change to using httparse though now that the hyper guys have split out the parsing side of things
29.ewdafa │22:31:45 geal | ok, so you need to parse http in streaming?
30.Shellu │22:32:00 jamwt | yep
31.gordon │22:32:08 geal | that is COOL :)
32.jamwt │22:32:19 jamwt | yeah, it all works, it's great
│22:32:25 jamwt | nom's been working out
│22:32:50 jamwt | we have a few recovering haskell programmers over here, so things that are (atto)parsec-like are up our alley
│22:32:58 geal | I am really happy to hear that. You probably have the largest scale implementation of a nom parser
│22:33:19 jamwt | well, we're going to run it on our fleet of storage machines in the fall
│22:33:32 jamwt | 200,000+ disks
│22:33:50 geal | on the disks?
│22:34:00 geal | oh, ok as frontend for the storage
│22:34:07 jamwt | frontend for the storage engine
│22:34:40 geal | did you encounter any issues while working with nom?
│22:35:24 jamwt | not serious ones.. mostly just gaps or confusion in documentation
│22:35:30 jamwt | but reading your code and your examples fills the gaps
│22:37:06 geal | please report issues when you see inconsistencies. I write docs regularly, but I forget stuff :)
│22:37:53 jamwt | will do. the rust world has been moving so fast lately that we're just trying to keep above water, keeping the build working every day
│22:37:58 jamwt | esp w/all the dependencies
│22:38:52 geal | BTW, I'm working on a way to represent state machines that are checked by the type system. Other people did it before, but I am just formalizing stuff enough to make it usable with libs like nom. The switch based state machine
│ | examples do not please me
│22:41:18 geal | would you care to write a bit about your experience writing parsers with nom? Or can I cite your work as real world usage? I understand the need for confidentiality, but this is very cool, moreover for such a young project :)
│22:43:06 jamwt | yeah, feel free to cite it
│22:43:53 jamwt | LMK if I can answer any questions.
│22:44:19 jamwt | nom is expressive enough that the sum total of our lines of parsing code is only like... 100 maybe? but those 100 work well :-)
│22:44:58 geal | with the latest version?
│22:45:14 geal | I saw a big reduction of code quantity in my parsers too
│22:45:35 jamwt | we didn't collapse all our tags or anything yet, so can't say for sure
│22:46:33 jamwt | we pretty much ported over what we had, including putting named!( ) around our existing constructs
│22:46:44 jamwt | with the new changes, we probably would have put more of those inline
│22:46:51 jamwt | but haven't done that refactoring yet
│22:48:10 geal | please do some benchmarks before and after that refactoring. I saw a small decrease in performance for the mp4 parser that I have not identified yet
│22:48:52 geal | also, be careful, inlining the macros increases the compilation time, so sometimes, defining one more function with named! is useful
│
│