freenode/#lisp - IRC Chatlog
Search
12:27:43
gendl
you were always using the full-blown api where you do the whole UI by yourself and call the stripe api explicitly
12:27:55
jmercouris
let's say I have the following (list 0 1 1 1 2 2 3) and I want to return a list with all of the matching elements like this (list (list 0) (list 1 1 1) (list 2 2) (list 3))
12:28:22
jmercouris
but that is a rather inefficient way, as I will have to traverse the list multiple times
12:30:28
adlai
for bonus points, destructively reuse the conses of the original list, and dynamic-extent the hashtable :)
12:40:27
phoe
(let ((result (make-hash-table))) (loop for x in (list 0 1 2 3 4 4 4 5) do (push x (gethash x result '()))) (alexandria:hash-table-values result))
12:44:22
adlai
if there is no guarantee that the test predicate is #'eql, then you can't use a histogram function
12:45:05
adlai
ACTION interprets jmercouris's original example as including the #'eq elements from the original list
15:24:49
minion
pfdietz, memo from phoe: I have some people who are interested in your work on random-testing the SBCL compiler and the techniques you used and the effects that it had and the bugs that it uncovered; is there any published code/research that I should link them to?
15:24:49
minion
pfdietz, memo from phoe: also, if you ever have the time to prepare and speak about it, I would love to listen to this on an Online Lisp Meeting someday (and so would these people).
15:25:45
phoe
pfdietz: Zoom; the link is theoretically public and visible at https://github.com/phoe-trash/meetings/blob/master/stack/2020/SG-11-30.md but I have no idea how the wasm people are going to react if they suddenly get a bunch of curious lispers watching the thing
15:26:37
aeth
pfdietz: re the memo... wow, the ANSI test suite is huge... https://github.com/pfdietz/ansi-test
15:27:36
phoe
travv0: I explicitly do not say that other people should join; I'm just pointing out that the meeting link is public, which might or might not be intentional - likely the latter
15:29:11
aeth
Hmmm... I wonder if I should try to programmatically convert the ANSI Common Lisp test files to test Airship Scheme CL compatibility. In theory, the semantics should be preserved where they make sense, even though in practice, many things (e.g. the macros like LOOP) would require reimplementations...
15:30:09
aeth
The only hard parts would be things that take advantage of the lisp-2 nature of CL while naming variables...
15:35:51
pfdietz
ansi-tests is really a combination of two things that should be separated: the tests traceable to specific parts of the spec, and the random testing infrastructure (which itself is composed of several different approaches.)
15:36:49
aeth
Hmmm... I actually wonder if the easiest way to use ansi-tests might be to make the meme a reality and implement CL in Scheme in CL...
15:37:32
pfdietz
The random tests come in three main flavors: generation of random integer-value forms to test the compiler, "random type prop" types that try to test type inference on small functions, and a mutational testing scheme that stitches together fragments of lisp code from public lisp projects to try to get the SBCL compiler to throw errors (this last
15:39:58
aeth
The point of implementing CL in Scheme in CL, of course, would be to (1) ensure that the semantics of the functions are preserved and (2) ensure that the reimplemented macros (at the very least, the iteration ones) are semantically identical.
15:42:27
phoe
and so you can run CL applications on Scheme and therefore verify the intermediate Scheme layer
15:42:51
pfdietz
Analogy generator failed on sea:submarin :: land:? https://boredhumans.com/analogy_generator.php
15:44:31
aeth
jcowan: Airship Scheme? It passes the first test, i.e. it reads the test file. This was fairly non-trivial.
15:45:08
pfdietz
I'm afraid I got a bit snippy on r/scheme when someone complained about all the funcalls in Common Lisp. If you look at quicklisp, about 0.4% of lines have a funcall on them. Granted, Scheme-style Common Lisp would have more.
15:45:23
aeth
I probably could've worked through the reader in a few days if I was willing to sacrifice quality.
15:46:06
aeth
pfdietz: I saw that and nobody got that right... You don't use funcalls for FP, you use it for higher-order-functions, which are just a subset of FP. And CLers use a lot of higher-order-functions, but usually ones that are preexisting, like map/mapcar.
15:47:38
aeth
jcowan: If I added semantics to define, I could probably get some minimal Scheme-like going already.
15:49:25
aeth
jcowan: As it stands, I can do this and it will read because I'm only missing #1= and #1# labels (like in the /topic here) in the reader: (with-open-file (s #P"~/git/other/no-backup/chibi-scheme/tests/r7rs-tests.scm") (scheme-read s))
15:49:58
phoe
I flip* through these slides real quick to animate their contents; 240 slides took me like 50 minutes to go through on the last Online Lisp Meeting
15:50:28
flip214
phoe: https://raw.githubusercontent.com/phoe-trash/meetings/master/stack/2020/presentations/2020-11-30-herda-control-flow-in-common-lisp.pdf
15:52:41
phoe
I remember heisig's greenscreen as the greatest non-strictly-technical thing of ELS 2020
15:53:07
flip214
but unless time is really reserved by booking a hotel, it's hard to find it again later on
15:54:11
flip214
perhaps 2022 there'll be a real ELS again... I could try to get there 3 days early and watch 2020 and 2021 ;/
16:01:32
phoe
and the form which ELS took this year gave me an idea for Online Lisp Meetings, so not all related to this year's covid situation is sad
16:03:37
aeth
I guess ELS 2021 is either going to be online again or is going to be delayed until the fall. Do we know which one?
16:07:07
aeth
It's possible that they're going to wait until closer to the event to decide whether it's online or not, but realistically speaking, until the vaccines are widespread, restrictions will remain in place, i.e. until some point in the middle of the spring
16:08:43
ioa
Oh I see they put the link on the meeting notes - strange, perhaps it is open after all.
16:12:04
beach
phoe: As I recall, in your OLM talk, you did not emphasize the need for special variables. But I guess the WASM people need to understand that.
16:12:30
phoe
beach: I did not emphasize it because dynamic variables can be implemented using unwind-protect
16:12:52
phoe
but yes, one of the final slides that are exclusive for the WASM version of the talk mention dynavar support
16:24:31
jcowan
Is there a program that can validate a fully macroexpanded CL program short of compiling it?
16:25:37
phoe
that it will return without signaling an error? (that's already halting problem territory)
16:34:49
beach
ioa: Still, there are things that can't be tested unless the language is not Turning complete.
16:35:16
jcowan
That it will compile without any errors on a compiler that accepts all programs (modulo implementaiton limits) that are valid according to the ANS.
16:36:32
Bike
"validity" would probably include type declarations being accurate, right? since the effects are UB otherwise? so you can probably do something something satisfies and make problems
16:36:48
beach
I am pretty sure there are cases where it can't be checked statically whether a program is conforming.
16:40:35
Bike
phoe: this is useful in that e.g. ERROR can be declared to have a return type of NIL, and from ther ea compiler can derive that (if (integerp x) (1+ x) (error ...)) has type integer, and such things
16:41:35
phoe
the functions ERROR and INVOKE-DEBUGGER have return type NIL because of their contracts
16:42:23
jcowan
phoe: Compilers are generally understood to generate code; in addition, they don't necessarily enforce all the rules of the spec. What I want is a linter.
16:43:19
phoe
it also happens to be a compiler, but yeah, it is going to tell you if the code it gets doesn't conform
16:44:32
phoe
(defun valid-lisp-p (form) (not (nth-value 2 (compile nil `(lambda () ,form))))) or something
16:44:34
mseddon
well yeah. and honestly 'linting' is best served BY a compiler, since it has all the information to hand and has done significant analysis.
16:45:52
phoe
OK, time to connect to Zoom; keep your fingers crossed, and please don't connect yourself since it seems that this meeting is *not* public
16:46:36
phoe
I'll attempt to lure people to heisig's Jitsi instance for some chat afterwards; I'll tell you if that's successful
16:56:20
jcowan
S.C. Johnson's "Lint: A C program checker" says: "The separation of function between lint and the C compilers has both historical and practical rationale. The compilers turn C programs. into executable files rapidly and. efficiently. This is possible in part because the compilers do not do sophisticated type checking, 'especially between separately compiled programs. Lint takes a more global, leisurely view of the.
16:58:56
jcowan
Perhaps not any more. If both compilation and linting are fast enough, it may pay to do them both at once.
17:03:00
Bike
i think a strict lint might do more analysis than a compiler would be willing to, because it's not actually relevant to optimization/whatever
17:03:26
beach
Maybe it is justified for languages such as C++ that have to include huge amounts of code in order to compile a single file.
17:16:40
beach
I would vote against such a separation. It may very well create a lot of code duplication, resulting in a higher maintenance burden.
17:16:41
jackdaniel
I've read an interview (sorry, I don't remember with whom) about code analysis performed by IDE (I think he was working on vscode) and the claim was that to do a good code analysis of C you basically need to compile it (but not necessarily to the executable)
17:16:41
jackdaniel
so basically even for C static code analysis (according to that person) is not sufficient to give a good insight
17:22:03
beach
Even so, I think it's a bad idea. Either the programmer runs both the compiler and the linter each time in which case the compilation time will essentially double. Or else, the programmer will waste time tracking down bugs that the linter would have found.
17:23:21
beach
For C, I have seen lots of people who don't even turn on all the warnings at compile time, and thereby wasting lots of time tracking down bugs that the compiler would have warned about.
17:25:35
beach
I think a much better idea would be to do incremental compilation in an IDE so that the programmer gets immediate feedback. And since it is incremental, it would not take a lot of time.
17:27:28
jackdaniel
I think that making distinction between compilers and linters is quite superficial (because the former may be repurposed as the latter, and the latter has a big overlap with the former); in other words I agree with beach
17:31:56
jcowan
beach: OTOH, since the linter is not perfect, it may catch non-bugs where the programmer does actually know better. This is the difference between Dialyzer-style static type checkers and more usual ones: the former complain only about code that is provably wrong, whereas the latter complain about code that is not provably right.
17:33:24
beach
I still remain unconvinced, perhaps as I would be one of the people who would always run both together.
17:35:42
jcowan
Which is why most lints (including the original lint) have some convention for suppressing lint output of a particular type and/or at a particular point in the program.
17:36:51
beach
In Common Lisp we already have things like that, yes, muffle-warnings, (declare (ignorable...))
18:16:20
phoe
I barely touched the condition system because there were lots of questions about the control flow and closures, so the basics - but I linked to the OLM recording so things should be good
19:57:07
pfdietz
phoe: to answer your earlier question about the bugs uncovered by the random tester...
19:58:21
pfdietz
phoe: the file misc/misc.lsp in ansi-tests contains a bunch of tests that were examples of failures in various lisps. Many have comments indicating which lisp it was.
19:59:34
pfdietz
These were produced either by the random form generator in random/random-int-form.lsp, or by the "rtp" tests in random/random-type-prop-tests-*.lsp
20:00:51
pfdietz
Eric Marsden was running the random tester for a while on sbcl; check the sbcl bug tracker. I have since renewed running it, check my entries there as well. Many of the recent entries are from that mutational tester I mentioned earlier.
20:01:29
pfdietz
There are (if I recall correctly) 11 bugs in the clisp bug tracker that came from the random tester.
20:02:57
pfdietz
The problem there is tracking down just where that bug tracker is. clisp has moved around.
20:10:03
pfdietz
sourceforge had the old tracker. Here's an example of a bug the tester found: https://sourceforge.net/p/clisp/bugs/200/
20:19:21
pfdietz
Here are some https://sourceforge.net/p/clisp/bugs/search/?q=+status%3Aclosed-fixed&page=13
20:24:10
Kurvivor
good evening. Does anyone have expedience with ECL's asdf:make-build extension? More specifically, with building monolithic static libraries
20:53:19
PuercoPop
pfdietz: Have you given any thought as to how best integrate code coverage information files or ASDF systems? Both sb-cover and cover work at the level of forms, not files afaiu
21:02:19
pve
Is there a function for detecting whether a symbol has been declared a global dynamic variable (even if unbound)?
21:03:52
pfdietz
PuercoPop: sb-cover can be enabled globally. (eval '(declaim (optimize sb-cover:store-coverage-data)))
21:06:55
pfdietz
For cover, you need to be able to fiddle with packages when annotation is turned on. This could be done by using the macroexpand hook to add that to in-package.
21:09:16
pfdietz
The problem I have with sb-cover is that is can screw up when the readtable is changed. It needs to somehow record readtable information to properly annotate source files.
21:09:43
pfdietz
cover works at the s-expression level, so that's not an issue there (but the coverage reports are harder to read).
21:10:38
pfdietz
cover fails with some macros that have code walkers, particularly iterate. I have a modified version of iterate that works with an enhanced version of cover.
21:14:03
PuercoPop
pfdietz: yeah, but I'm trying to think about how to compute the coverage 'diff' after running a test. afaiu sb-cover stores a coverage bit for each form it compiles, right? But you still have to check the coverage bit for the forms you care about. There is no way to run (test-foo) and then ask for what new 'paths' have been run
21:17:09
pfdietz
At previous job, we had an extension of cover that did things like allow rollback of coverage information, and also dumping coverage info to a file for combination (to get aggregate coverage from separate tests). But I left that behind for IP reasons.
21:17:53
pfdietz
The rollback would be useful for incremental generation of minimized unit tests that increase coverage.
21:23:40
PuercoPop
fwir the report is built by walking the forms in the file and checking the coverage bit for each form.
21:24:40
PuercoPop
So for 'rollbacks' or snapshots one would have to do that and store the information in a datastructure, right? But also one would have to know before hand which files to check. I guess one could use ASDF for that