3:50:42gigamonkeySo is there some clever way between SLIME and Emacs to automatically get Emacs's font-locking to colorize uses of macros that are the moral equivalent of DEFUN similar to DEFUN?
3:59:46nyefgigamonkey: Have you tried naming the macros something that starts with DEF ?
4:00:09nyefACTION has no idea if that would actually work, but it could be worth a shot.
4:00:39Bikelooks like you need to set the 'common-lisp-indent-function' property of the thing to 'defun'. no idea what that means but it sounds possible
4:01:17|3b|yeah, i think def* and check* get highlighted specially
4:01:21nyefThat... sounds like it would also affect indentation, not merely fonting?
4:01:37Bikeoh. yeah i might be looking in the wrong place.
7:59:10beachSo I think I understand why it is tempting to parse lambda lists using some ad-hoc code rather than some existing parsing technique. Existing parsing techniques assume a linear sequence of tokens, but lambda lists can be nested, and no existing parsing technique can handle that.
7:59:56beachBut ad-hoc code won't do for Cleavir, because I need for the client Common Lisp system to be able to customize the lambda-list parsers.
8:26:51shrdlu68_Someone recommended it for cl-tls.
8:27:48shrdlu68_"Remember that you can use e.g. tcpflow to record TCP traffic to files, which can then be used as samples for radamsa."
8:30:14shrdlu68_It's trivial to make cl-tls dump ssl packets to a file. But then when radamsa tries to fuzz cl-tls live (or any other ssl implementation), it can only go so far because it is not ssl-capable.
9:29:34pjbshrdlu68: there are other fuzzers that take into account the paths taken by the program (they have to instrument it), to explore and find the right input to exercise all the paths.
9:30:10pjbPerhaps they would be able to "crack" ssl?
9:56:58pjbshrdlu68: all about fuzzing ;-) : https://fuzzing-project.org/
9:58:19pjbNow, of course, http://lcamtuf.coredump.cx/afl/ instruments C code. Perhaps it could be adapted to instrument CL code (using something like eg. cl-stepper).
11:27:28shrdlu68When used properly it's great to work with.
11:27:37p_lI do as well, but ASN.1 shows in so many places that having a single, good implementation that is portable it would be great
11:28:18p_lshrdlu68: I often find myself thinking that OSI protocol stack etc. was probably better for *today* even if it was too heavy in the past
11:28:48shrdlu68p_l: I'll put cl-tls on github i the next hour or so. The ASN.1 code so far is mostly a prototype, but I'd like your opinion on it.
11:29:38shrdlu68It's not as comprehensive as I'd like at this point, but that's something I'll work on.
11:30:29shrdlu68I'd also like to create a way to generate asn-compiling code from a spec.
11:31:21shrdlu68I noticed the work I was doing was something that could be automatable. Mostly iterating over an octet vector while ensuring types match, lengths are okay, etc.
11:31:26p_lshrdlu68: there's a lot of that done already in cl-snmp, but ideally it would be a separate library/toolkit