libera/#clasp - IRC Chatlog
Search
3:37:35
Bike
haven't looked in detail. they didn't seem especially serious. one was that i made changes to wscript, which has been deleted in main. easy to resolve.
6:23:12
drmeister
::notify Bike I tried your sjlj branch and ran perf top watching the process. I don't see UnwindFind_FDE in the top 20 functions. It used to be the top with >90% of the time spent in UnwindFind_FDE
10:26:53
Colleen
yitzi: drmeister said 6 hours, 50 minutes ago: I fixed all the compile errors with --source-debug
13:31:59
Colleen
Bike: drmeister said 7 hours, 8 minutes ago: I tried your sjlj branch and ran perf top watching the process. I don't see UnwindFind_FDE in the top 20 functions. It used to be the top with >90% of the time spent in UnwindFind_FDE
13:35:40
yitzi
I compiled with `--source-debug` and it worked. I think drmeister got all the fmt stuff fixed.
13:39:59
yitzi
I am getting some "unexpected failures" in ansi-tests on that CI testing PR. Has anybody run ANSI tests lately?
13:41:42
yitzi
You can also look at https://github.com/clasp-developers/clasp/runs/6385903554?check_suite_focus=true
13:42:26
drmeister
I ran the static analyzer on main yesterday - I'll hold off pushing anything until Bike pushes his changes.
13:43:16
yitzi
I we can get a clean run of ANSI tests then that PR can be merged and we can get CI testing on GitHub!
13:44:29
yitzi
Yeah, its weird. I thought they were clean. Hoping koga hasn't jacked a compilation option.
13:47:28
drmeister
Bike: When I was playing around with sjlj-unwind I couldn't see UnwindFind_FDE taking any time at all.
13:47:58
Bike
yeah, i think i got just about everything in C++ that calls lisp, and a good fraction of the C++ that signals errors
13:49:43
drmeister
I got borodust's claw-usb to work well enough to give me a list of all attached USB devices.
13:50:26
drmeister
It uses a C library called libusb - it should be pretty straightforward to use. It's refreshing to use a simple C API.
13:51:55
drmeister
I'm getting a RFID printer in a couple of days. My plan is to figure out how to print RFID labels with the libusb API.
13:59:07
Bike
should all uses of the BF macro be gone? there are a few here, but they're not compiled https://github.com/clasp-developers/clasp/blob/main/src/core/evaluator.cc#L1866-L1881
14:00:49
drmeister
I'm stiff and sore and feeling old this morning. But I have a simple three step plan to fix things - it involves Cando and libusb.
14:06:38
drmeister
Bike: This is what I normally get when I run `perf top` when cclasp is building and loading/compiling inline.lisp and later files...
14:07:50
drmeister
At the risk of repeating myself - yesterday, with sjlj-unwind - I couldn't see it in the top functions.
14:14:32
drmeister
For reference later, building ASDF: Time real(51.441 secs) run(51.441 secs) consed(3907625424 bytes) interps(547) unwinds(6138)
14:15:56
Bike
there might be some failures in obscure bits of ansi tests. yesterday i realized i screwed up one case of progv because we happened to have it in our tests, but it never came up in just building clasp and cando
14:18:44
Bike
anyways, so right now i'm running the analyzer, and that's gonna take a while. if possible it would be convenient if there were no more commits to main until i finish up here
14:34:25
yitzi
I am wondering if we should call the snapshot versions of cando `scando` instead of `dcando`. (or `cando-snapshot`) Yes they normally get made in the d stage, but in the "user based" installer I am contemplating that is confusing. Users don't really know what the stages are.
14:38:14
yitzi
In the scheme I am trying out the package based installers don't build the d stage. Instead there is an script that the user can run like this `clasp-user-install --snapshot-cando --jupyter`
14:39:26
yitzi
This would make a snapshot of cando using their quicklisp installation into `~/.local/bin/scando` and then create a jupyter kernel for it at `~/.local/jupyter/kernels/scando/`
14:41:41
drmeister
I'm running the ansi-tests and watching `perf top -p <pid>`. _Unwind_Find_FDE swings from a few percent to over 80% as we go from test to test.
15:04:14
Bike
https://gitlab.common-lisp.net/ansi-test/ansi-test/-/blob/master/auxiliary/char-aux.lsp#L49-61 and that in turn does catch-type-error...
15:07:19
Bike
if we need to, i could also do some other stuff to make the dynamic environments more informative, e.g. i could have the unknown-marker dynenvs store the name of the function they're from or something
15:07:20
drmeister
I don't know if ansi-tests prints the test before it starts it or after it completes it. So it may have been char-upcase.3 or char-upcase.5
15:11:11
Bike
hrm, for type errors we go through multiple-value-foreign-call, might be a bit of funkiness there
15:14:27
yitzi
drmeister: So I got this mocked out now `(clasp-user-install::install :snapshot '(:cando) :jupyter '(:clasp :cando :scando))`, which makes a cando snapshot and installs jupyter kernels for clasp, cando and scando. It also applies some logic to the kernel names. For example, if the user only installs an scando kernel then the kernel name is just "Cando". If they install both cando and scando then the kernel names are "Cando" and "Cando (snapshot)"
15:15:56
Bike
cppreference says it has a race condition and that it's better to use std::tmpfile or mkstemp
15:16:34
yitzi
Yes, but I was not really able to figure if mkstemp or really std::tmpfile really would work for that application.
15:17:00
Bike
alright, none of those look immediately like unwinding problems. some of the miscs might be
15:18:06
Bike
we fail a lot of the arithmetic because we have problems with SIGFPE, that's been the case for a while
15:18:18
yitzi
If there are tests we don't pass they should be added to expected failures list. Otherwise I can't make the GitHub CI test every give you a success.
15:18:26
Bike
the main thing leaping out at me here is the MAKE-LOAD-FORM.ORDER failures, but yitzi said that was in main too
15:19:06
drmeister
I see - so fix the unexpected failures or punt and move them into expected failures?
15:20:08
Bike
yeah, ok, as usual the misc tests are doing a bunch of obscure stuff that could be causing problems, i'll see what i can do about fixing them
15:21:02
Bike
https://gitlab.common-lisp.net/ansi-test/ansi-test/-/blob/master/misc/misc.lsp#L11082-11095 but like this doesn't look like it's unwinding, for example
15:21:17
yitzi
I can explain the tmpnam issue whenever. Maybe someone has a better solution then I do.
15:21:59
Bike
when debugging a single test i usually just dump the code into clasp without bothering with the test harness
15:22:24
yitzi
I have not added a way to do that via koga. I need to investigate how the test selection works.
15:22:47
Bike
https://gitlab.common-lisp.net/kpoeck/ansi-test/-/wikis/How-to-run-the-tests-for-clasp details here
15:23:45
Bike
so for example to run just the misc tests, you'd pass -f ansi-partial-execution -f ansi-load-misc
15:24:17
yitzi
If that is the case then you should be able to do `CLASP_FEATURES=ansi-partial-execution,ansi-load-misc ninja -C build ansi-test`
15:24:36
Bike
we're failing a bunch of the cl:bit tests actually, there's probably some weirdness there disconnected from the unwinder
15:24:39
drmeister
For later - running the ansi tests on zeus: Time real(3377.787 secs) run(3377.787 secs) consed(189978738168 bytes) interps(176) unwinds(130451)
15:26:13
Bike
oh, alright. i was trying to figure out if they indicated the new unwinder breaking anything, but i guess not
15:27:31
drmeister
`CLASP_FEATURES=ansi-partial-execution,ansi-load-misc ninja -C build ansi-test` works great!
15:30:33
drmeister
Of course all my timing data is shite because Bike is building on zeus as well. The unwinds will be useful.