libera/#commonlisp - IRC Chatlog
Search
8:33:18
dnhester90
I hear. If it turns out not to be a circular dependency after doing serial, does that mean the implementation of compiling based on system definition is broken? If so, where is it? Can I try to fix it? I haven't done this stuff in a while, but from what I remember it should just be doing depth first search on a Directed Acyclic Graph...
8:34:15
beach
It means that your system depends on some other system S which in turn depends on your system. Or that S is itself circular.
8:34:47
beach
If your system depends on no other system, I can't see how there could be any circular dependencies when you use :SERIAL T.
8:39:24
beach
If it is not circular after you do :SERIAL T it means that there is circularity in your :DEPENDS-ON, but I just don't see it.
8:43:20
dnhester90
Thanks, that's what I thought... I'm modifying it now to be serial... let's see if it works
9:04:07
dnhester90
@beach finally, it works! Turns out I had a `imports-from` statement in a defpackage in one of the files and that was the source, even though it wasn't the file being mentioned in the compiler error...
9:06:51
dnhester90
I don't know much about how this works, but I image if a package is being imported by a defpackage it must try to create a reference for that package at compile time for it to be available for any functions or variables used in the current file originating from that package, and that's why it breaks. It could be ASDF defines compile order, and the
9:06:52
dnhester90
compiler itself when dealing with the defpackafe definitions was giving the error
9:08:46
dnhester90
"The error message specifically mentions a circular dependency for ASDF." I know, that's why I was stuck and didn't try to look into the package definitions so much based on the advice I found online...
9:09:24
beach
What I am saying is that it can't possibly have anything to do with packages, because ASDF does not look at those.
9:09:54
dnhester90
I would imagine it would be a great project to have a tool figure out compile order automatically and all the files and dependencies based on imports from defpackage, like it is in most languages, and at most exclude a file, or just point to the main file and not include anything not imported from the main start poing of the project...
9:10:45
dnhester90
"What I am saying is that it can't possibly have anything to do with packages, because ASDF does not look at those." Ok, but that's what solved it. Removing a imports-from statement. So what can we say?
9:11:34
beach
That a single file must contain all the code in a particular package, if I remember correctly.
9:12:34
beach
You don't need to quote me. My memory is not that bad (yet). I still remember what I uttered a few minutes ago.
9:15:22
dnhester90
haha sorry, It's just that it's not always clear to which message I'm replying to. but ok, I'll refrain from doing so
9:51:15
ogamita
dnhester90: you may use com.informatimago.tools.check-asdf to help you find the circles in your dependencies.
9:53:37
beach
ogamita: That won't help if it is the package definition (which I still don't believe it can be, of course).
9:54:41
ogamita
dnhester90: at: http://github.com/informatimago/lisp with usage example: https://github.com/informatimago/lisp/blob/782607d960853d3269be963ded246ae2875a4139/tools/loader.lisp#L12
9:55:06
ogamita
Well, with package definitions, you get other kinds of errors in case of circularity.
9:55:31
ogamita
beach: unless, can you put a package definition in the asdf:defsystem form as seen in the paste? I assumed it was botched.
9:59:10
Nilby
I have in the past seen possibly bogus circular-dependency errors that seemed to go away on recompiling, which may have been due to be a mismatch between versions of Quicklisp and ASDF.
10:02:36
ogamita
notably, you can "build" those circularity when working in the image a long time, while loading successive versions. In the end, you only have the final versions of the files, and they have the circularity embedded so you cannot load them anymore from scratch.
10:03:34
ogamita
load old-a ; load old-b ; load a ; load b -> when loading a, it can depend on the old-b, while old-a didn't. Next loading b it depends on a, and the circularity is established.
10:04:50
Nilby
I understand that, but this was on a fresh image, and in cl-unicode, and went away when I got rid of old asdf versions.
15:42:42
gilberth
I'm having a question about ~A. In 22.3.4.1 it says "If arg is a string, its characters will be output verbatim." <https://novaspec.org/cl/22_3_Formatted_Output#sec_22_3_4_1> However of the Lisp implementation that I have all but CLISP and ECL invoke *print-circle* processing with ~A, even when the argument is a string. I get <https://termbin.com/bv53>
15:44:12
gilberth
The question is: Is it me reading the spec in a too naïve way, or is it the Lisp implementations being buggy here. Perhaps just saying PRINC with ~A.
15:58:07
splittist
Aren't the implementations differing in how (many times) PRINT-OBJECT is called, not in how ~A works?
15:59:48
gilberth
This issue concerns me a bit. For two reasons, at times I am not brave enough for FORMAT and punt like (format stream "~S is ~A integer." x (if signed "a signed" "an unsigned")) This breaks with *print-circle*. The other is: You often see idioms like (format nil "~{~A~^, ~}" strings) to join a list of strings by commas. The latter also would break.
16:01:03
gilberth
splittist: The question is whether PRINT-OBJECT is invoked on ~A an argument at all, when that argument is a string.
16:02:21
gilberth
That is whether pprint dispatch happens, whether *print-circle* processing happens. Or whether to take the spec verbatim and just invoke write-string with ~A when the argument is a string. Which is how I read that. But I'm not confident here, which is why I ask.
16:05:40
gilberth
And all those uses of FORMAT to craft strings from strings, e.g to generate some external representation would need to be wrapped around with-standard-io-syntax.
16:07:12
gilberth
Let me put this question somewhat differently. Sould (format stream "~A" (the string x)) always be the same as (write-string (the string x) stream) or not?
16:08:25
gilberth
Or should it rather be the same as (let ((*print-escape* nil) (*print-readably* nil)) (prin1 (the string x) stream)) ?
16:09:42
scymtym
there seems to be a contradiction: ~A is supposed to output a string argument verbatim but ~S is supposed to be "just like ~A". i don't think both can be true since outputting strings verbatim prevents print-read consistency
16:17:44
gilberth
Anyhow, I'm at a loss here. Do I fix my code or do I fix my Lisp implementation? Who's to blame?
16:20:03
gilberth
I first came across this with (format nil "~{~A~^, ~}" strings), which given that I'm lazy, I use a lot. I needed to turn on *print-circle* and my code broke.
17:06:33
gilberth
Here is another test, this time with ~:A printing NIL. Spec says "the colon modifier (~:A) will cause an arg of nil to be printed as ()". Doesn't happen either: https://termbin.com/y06j
17:30:50
gilberth
This is funny: <https://termbin.com/ro7kb> ;Note how SBCL special cases for (format nil "~a") and does not consult the pprint dispatch, while "~{~A~^, ~}" does. So someone, somewhen with SBCL share my interpretation. At least for some special case.
17:36:45
gilberth
Yet the spec says that when the argument is a string that string should be printed verbatim. It also says that when the colon is present, NIL should print as (). This doesn't happen.
17:38:14
yitzi
I don't think that is contradiction. It is just "pre-processing" by FORMAT's directives.
17:40:27
gilberth
It is. Not both claims "is printed with PRINC" and "If arg is a string, its characters will be output verbatim" can be true. Neither can the claim about NIL be true.
17:42:22
gilberth
I read "An arg, any object, is printed without escape characters (as by princ). If arg is a string, its characters will be output verbatim." like "printed as with PRINC, but a string is printed verbatim." Likewise I read the following about ~:A printing NIL as () as an exception.
17:47:08
yitzi
After digging around in the plumbing of the printer a fair amount I have come to the conclusion that there are some odd things that were brought into the spec from the XP printers, and at the same time almost no details of the pretty printer were brought into the spec. For example, there is no statement about what is in the initial dispatch table. It is very underspecified, IMHO.
17:48:52
NotThatRPG
Anyone out there using cl-async? I am facing some code that uses it and am lost. The code invokes `cl-asyn:start-event-loop` which, as far as I can tell, should return, but instead it hangs.
17:49:29
gilberth
The pretty printer dispatch isn't what concerns me here too much. It's *print-circle* that concerns me. And the use of format to stich strings together by means of ~A. The assumption that (format nil "~{~A~}" strings) would be like (concatenate 'string strings) is true or false depending on how you read the ~A spec.
17:49:30
NotThatRPG
I mean by "hangs" if I invoke it in the REPL, it never returns, not that it literally hangs.
17:55:10
NotThatRPG
oh, I see: that code is just wrong. The event-loop won't terminate, and shouldn't.
19:19:04
gilberth
It gets funnier. https://novaspec.org/cl/v_print-circle says "If a user-defined print-object method prints to a stream other than the one that was supplied, then circularity detection starts over for that stream." Doesn't happen with SBCL, CMUCL, or ABCL. <https://termbin.com/504d>
19:28:00
yitzi
gilberth: I'd be surprised if any implementation does that. They all use a single group of dynamic variables to control it. If one implementation is different it could be CLISP. All the other implementations use either the original XP code or CMUCL's rewrite.
19:29:18
HamzaShahid
I wanted to create permutations of a list like (0 1 2) to ((0 1 2) (0 2 1) (1 0 2) (1 2 0) ...) lexecographically
19:40:41
yitzi
I'm not sure about CCL, ECL and ACL. CLASP is based on ECL it doesn't attempt make circle detection stream specific.
19:44:36
gilberth
So with CMUCL^SBCL, ECL, ABCL circle printing also is ineffective when you print somewhere else. Again CCL, CLISP, ACL getting it right. IMHO.
19:49:53
pjb
HamzaShahid: it's the same code to create permutations of 2 values as for n values! Just modify my function (trivially).
19:50:54
pjb
HamzaShahid: (defun all-symbol-combinations (p n) (if (zerop n) '(()) (let ((rests (all-bit-combinations (- n 1)))) (mapcan (lambda (bit) (mapcar (lambda (rest) (cons bit rest)) rests)) (iota p))))) (all-symbol-combinations 4 3) #| --> ((0 0 0) (0 0 1) (0 1 0) (0 1 1) (1 0 0) (1 0 1) (1 1 0) (1 1 1) (2 0 0) (2 0 1) (2 1 0) (2 1 1) (3 0 0) (3 0 1) (3 1 0) (3 1 1)) |#
19:51:41
pjb
HamzaShahid: sorry, bad renaming; here it is: (defun all-symbol-combinations (p n) (if (zerop n) '(()) (let ((rests (all-symbol-combinations p (- n 1)))) (mapcan (lambda (bit) (mapcar (lambda (rest) (cons bit rest)) rests)) (iota p))))) (all-symbol-combinations 4 3) #| --> ((0 0 0) (0 0 1) (0 0 2) (0 0 3) (0 1 0) (0 1 1) (0 1 2) (0 1 3) (0 2 0) (0 2 1) (0 2 2) (0 2 3) (0 3 0) (0 3 1) (0 3 2) (0 3 3) (1 0 0) (1 0 1) (1 0 2) (1 0 3) (1 1
19:51:41
pjb
0) (1 1 1) (1 1 2) (1 1 3) (1 2 0) (1 2 1) (1 2 2) (1 2 3) (1 3 0) (1 3 1) (1 3 2) (1 3 3) (2 0 0) (2 0 1) (2 0 2) (2 0 3) (2 1 0) (2 1 1) (2 1 2) (2 1 3) (2 2 0) (2 2 1) (2 2 2) (2 2 3) (2 3 0) (2 3 1) (2 3 2) (2 3 3) (3 0 0) (3 0 1) (3 0 2) (3 0 3) (3 1 0) (3 1 1) (3 1 2) (3 1 3) (3 2 0) (3 2 1) (3 2 2) (3 2 3) (3 3 0) (3 3 1) (3 3 2) (3 3 3)) |#
19:53:30
pjb
HamzaShahid: since it can grow fast, you may want to do it incrementally. have a look at: https://gitlab.com/com-informatimago/com-informatimago/-/blob/master/common-lisp/cesarum/combination.lisp
20:18:42
gilberth
So it looks like SBCL abandoms *print-circle* processing when doing output to another stream altogether, but for the top-level object printed to that other stream. I can see why they have chosen to do so. Watch <https://termbin.com/y6fs>. This time using ~S. When asking for ~20S however, CCL fails to do *print-circle* processing because it first prints the argument to a string.
20:19:43
gilberth
However, completely abandoning *print-circle* may make you face some infinite recursion. I don't like that.