libera/#commonlisp - IRC Chatlog
Search
19:30:26
Fare
What are property based testing libraries for Common Lisp, in the style of Quickcheck? I see check-it...
19:47:42
foxfromabyss
Hi! :) Would anyone be so kind as to enlighten me how.. sketch (and probably the underlying C FFI?) manages to have a persistent window that gets re-rendered on reevalation? (as opposed to the window getting closed and opened again) I feel like there's some sort of trick but i haven't managed to find it in the source
19:53:55
yitzi
Sabra's testing framework comparison doesn't mention any other property based ones besides cl-quickcheck and check-it.
19:56:54
phoe
the window is opened when a function is called, the window is closed when a function is called
19:57:39
phoe
of course there can be caveats, such as needing to synchronize to some framerate or to draw only from a designated thread, but these are technical complications; the general idea is simple
19:57:51
foxfromabyss
so it's more of a common lisp property, rather than the particular implementation?
20:01:56
phoe
if you were writing in C and had some embedded REPL in it - lua, python, scheme, whatever - it would work the same
20:17:07
Shinmera
Phew, first draft https://github.com/Shinmera/talks/blob/master/els2023-kandria/paper.pdf
20:29:44
Shinmera
Content and format feedback is welcome, though please do not review grammar/syntax/etc. yet
21:06:33
prxq
Hi. Just published a wrapping of the Telegram Bot API for Common Lisp. https://github.com/prxq2/clbleepblop
21:19:53
prxq
yitzi: I used it because it uses plists, which were easy to morph into argument lists. What do you think can happen?
21:20:56
yitzi
I'd read Sabra's reviews for comparisions, if you haven't already. https://sabracrolleton.github.io/json-review.html
21:21:35
yitzi
keep in mind that plists may be a security risk if you don't know what the keys are ahead of time.
21:24:54
yitzi
Josh_2: Awesome that you are using it for API stuff. Network encoding/decoding is exactly what I wrote shasht for. Specifically Jupyter protocol. \
21:38:24
Josh_2
You can build a plist for initargs by mapping over the returned hash-table and looking up an initarg based on the key
21:39:01
Josh_2
I would rather do that than parse to plist. I made the mistake with my matrix-api of using plists only to see the problem with saturating your image with keywords
21:49:02
prxq
I actually thought about that, but since the JSON all comes exclusively from telegram, I think the number is finite. All possible keys are already generated while compiling, because they are keyword args of the json to object converters. Like (make-message :|parse_mode| "Markdown" etc)
21:50:01
prxq
I admit to being very lazy here. I call (apply #'make-message <jonathan-json>) and off it goes
21:58:17
NotThatRPG
Kind of painful debugging experience: I check for a bad result when it happens invoke break with a format string that uses ~S to present the incorrect data object. SBCL gives me a breakpoint but ... the incorrect data point is not available as a local!
21:59:06
NotThatRPG
Is there any way to tell SBCL "whatever you do, make sure this value is accessible in the debugger"?
22:02:19
NotThatRPG
ah, yes -- I put a declaration of debug 3 into the sexpression in the repl and that solves my problem. Thanks
22:03:09
NotThatRPG
I suppose it would be a low-priority feature enhancement, but compiling a call to BREAK at anything below debug = 3 seems like a weird thing to do.
22:10:44
phoe
NotThatRPG: BREAK invokes the debugger; use C to inspect the condition object and then inspect SIMPLE-CONDITION-FORMAT-ARGUMENTS
22:12:06
phoe
;; oh, all the rarely useful but funky stuff that comes to you when you're kinda good at the condition system
1:10:35
aeth
I usually use multiple values for that sort of thing if you don't actually want a subsequence, especially for 2D
4:58:35
char[m]
Maybe I could add it. Would you opposed to other extensions in a similar vein for hash-table and vector and so on? They could all share a system.
5:06:58
Bike
char[m]: i have not had much ability to use ctype for what i originally wanted it for (though i'm inching closer to that). if people want to use it to experiment with typing i'm all for that.
5:10:50
Bike
originally i wanted to use it for clasp, but i can't right now for boring reasons. so it's pretty much been staying where it is, i.e. a basically correct but not especially performant or extensible type system
5:14:33
char[m]
Seems pretty extensible to me. I have a somewhat working extension (that probably shouldn't be upstreamed). How would you it to be more extensible?
5:15:20
char[m]
It is sad you can't use it in clasp. Do you mean it is not performant because it makes heavy use of CLOS?
5:15:48
Bike
it's not performant because it doesn't cache anything (or at least i imagine that's the main problem)
5:17:40
Bike
as for extensibility, the API for introspecting on types needs some thought (or really any thought - the one that's there is basically just the slot accessors)
5:18:17
Bike
for example it's kind of not easy to ask questions like "what is the upgraded array element type of this arbitrary (e.g. disjunction) type"
5:18:39
Bike
and i should probably have it use the client dispatch pattern rather than having a bunch of special files