09:03 <cfbolz> It seems I'll have a peg parser for us soon

10:22 <mattip> I am stuck trying to fix a _ssl test failure with openssl3

10:23 <mattip> when reading from a socket with some edge case error condition, CPython emits a BrokenPipeError from a signal,

10:24 <mattip> with openssl 1.1.1 we don't get the signal, but do set a proper error condition,

10:25 <mattip> but on the py3.7-openssl3 branch the call to read() raises a generic error that makes the test fail

10:47 <cfbolz> mattip: that kind of stuff really sucks :-(

13:13 <cfbolz> cool, I just boldly replaced the parser and many interpreter/test things actually work!

14:32 <catern> should I expect arrays in structs with defines to work with cffi cdef? i.e. if I have "#define LEN 16\n struct { char buf[LEN]; };" - seems like that gives me "unsupported expression: expected a simple numeric constant" which I find a bit surprising

14:37 <catern> hm, also, do defines of string constants work? i.e. if I have '#define COOLSTRING "hello world"' in a header and put "#define COOLSTRING ..." in a cdef... is that expected to work? (because it seems like cffi assumes all defines are numeric)

14:42 <atomizer> cffi doesn't do preprocessing

14:43 <atomizer> no ifdefs, defines or includes

14:44 <catern> well, it does support defines

14:44 <atomizer> weird

14:46 <catern> lots of APIs have defines for special argument values (the libc API for example) so it would be quite limiting to not have that

14:46 <catern> string defines are less common so I guess it's believable that they aren't support but it's still disappointing...

16:33 <cfbolz> catern: that would require being able to parse a lot more C code though

16:36 <catern> cfbolz: which part? defines as array sizes, or defines as string constants?

16:36 <cfbolz> catern: both

16:36 <catern> i guess defines as array sizes would require a fair bit of toil yeah, but the string constants seems not so hard

16:40 <krono> It requires a notion of strings for the parser in the first place…

16:41 <catern> sure, but that still doesn't seem so hard? it only has to exist in #defines

16:41 <catern> er, sorry, actually I'm being confusing

16:42 <catern> the cdef would be "#define COOLSTRING ..." so the parser wouldn't need any extra support for strings

16:42 <catern> cffi already supports returning char*s from functions so it has a notion of them; there would just need to be some kind of... dynamism... maybe...

16:43 <catern> alternatively it could be literally "#define COOLSTRING ...string" to indicate that this define is going to be a string constant so it should be handled like a string constant

16:44 <cfbolz> Does cffi handle string constants in other places?

16:46 <catern> sure, ffibuilder.cdef("const char* my_cool_constant;") works just fine

16:48 <catern> even ffibuilder.cdef('const char* my_cool_constant = "foo";') works, although = "foo" isn't actually used by cffi (I think?)

16:55 <cfbolz> Right

16:55 <cfbolz> It's a question for arigato, who is on vacation I think

17:08 <Corbin> In a fresh codebase, what's the difference between "vec" and "vec_all"? AIUI "vec_all" forces all JIT drivers to try to vec, while "vec" only does this for drivers that were created with vec=True?

17:09 <Corbin> Er, *vectorize=True, whoops. Still reading code.

17:18 <Corbin> There should be docs on how to tune JIT drivers. I should write docs. I have no idea how to tune a JIT though.

17:21 <cfbolz> Corbin: I have no idea

17:21 <cfbolz> Nobody understands this code anymore, I think

18:53 <fijal> did it ever work correctly?

19:55 <cfbolz> fijal: yes, for careful exacmples