freenode/#lisp - IRC Chatlog
Search
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
22:34:56
nihil
though I was thinking of something that's probably not directly relevant to CL but program design in general...
22:41:03
save-lisp-or-die
what issues are you bumping up against? Or are you just sort of... feeling uncertain?
22:42:37
nihil
I guess it's a question of style, whether it makes sense to make a class to save in slot definitions
22:44:17
nihil
but then I also thought "what about elements that won't require a name and a description?"
22:45:28
save-lisp-or-die
My personal taste is to not give in to the temptation of "factoring out" classes unless that class will actually serve a different role in the running application.
22:45:53
ane
uh, if I have a cffi function like this: void foobar(size_t *blah);, which in C I would call like this size_t blah; foobar(&blah); ... how would I do that using cffi? something like (with-foreign-object (blah :uint) (let ((ptr (foreign-alloc :uint))) (setf (mem-aref ptr :uint) blah) (foreign-funcall "foobar" :pointer ptr :void))
22:45:57
save-lisp-or-die
But using "mix -ins" for augmenting "main classes" is a useful strategy for some application domains.
22:46:40
save-lisp-or-die
nihil without seeing your application, its hard to say what you should do. I see your concern. I say go with your gut and come back when things get hairy
22:47:30
phoe
but then again, what exactly should your set of superclasses be depends on your application logic
22:48:23
phoe
and that's a question of what you want your inheritance graph to look like, how do you want to apply the Liskov substitution principle, and which classes of your graph are meant to be protocol classes (not meant to be instantiated directly).
22:48:53
save-lisp-or-die
nihil like. I wrote a (fairly crappy, just-for-friends) matrix bot framework a while back. It used a mixin approach. I made a main client - then each bot had "components" that I could mix in to customize the behavior of the particular bot in question.
22:49:16
save-lisp-or-die
I could even install new behaviors in old bots (while they were running) by adding in a new class to the list of superclasses for the bot in question.
22:49:42
save-lisp-or-die
so. It can be a good idea, but it can also get icky. Like people are suggesting. It depends on the specifics of your application.
22:51:32
phoe
if some place in your code accepts something of class X, it should also accept all subclasses of X
22:57:40
save-lisp-or-die
Gnuxie[m] not really intended for human consumption. Just something that a friend and I were using last summer to play around.
23:14:52
Gnuxie[m]
save-lisp-or-die: that's quite nice, I have some ideas in the pipeline to make writing this sort of thing easier in the future, I've not really talked about them too much publicly
23:16:18
Gnuxie[m]
if you looked at cl-matrix, you'll notice there's a sort of generator, but i was a bit naive and didn't generalize it at the time but I did start fixing that https://gitlab.com/Gnuxie/rest-api-description
23:17:05
Gnuxie[m]
some people have wrote generators for swagger apis but the problem with that is that if the thing you're trying to wrap is not expressed in swagger than you're sorta stuck
23:18:04
Gnuxie[m]
so i started trying to make a model for it all in CLOS, but it's a bit of a big task tbh, hopefully you'd be able to do things for webservers from this library too
23:19:20
Gnuxie[m]
https://gitlab.com/Gnuxie/invidious-api-description/-/blob/master/description.lisp here's an example of something I made that uses it
4:13:22
drmeister
beach: I'm using the call-history for dispatching as clasp boots up - it works pretty well. It's faster than the cache and mutex that I stole from ECL.
4:14:40
drmeister
I didn't think an alist would be fast enough - but it was. So an alist updated with CAS is faster than a fancy cache with a mutex.