libera/#commonlisp - IRC Chatlog
Search
6:30:03
Josh_2
I have a print-object method specialized on a class X that uses ~T, I am trying to now have another print-object for a class Y that has an instance of X within it and I'm using ~S to display it, but how can I tabulate all of the output for X?
6:31:00
Josh_2
I use ~T in my print-object for Y to try and tabulate the display of instance X then only the first line is tabulated, I want to move all of the output over 10 spaces
8:16:12
dnhester90
I'm stuck in ASDF system definition failing me. I've tried reading and following examples from other projects to no avail...
8:18:41
dnhester90
Ah! @beach, how are you? I haven't been here for a while because I was busy with non lisp things, finally I'm back at it, and you helped me a lot a few years ago. Thank you!
8:20:09
dnhester90
Do you know any good guides (besides the official docs) for learning ASDF? I tried reading through the official docs but it wasn't so helpful in trying to debug my issue of a circular dependency...
8:22:30
beach
To simplify your ASDF system definition, remove the :DEPENDS-ON and just say :SERIAL T at the top. If it is then still circular, then there is a circular dependency not between components, but between systems. Also, restart your image to make sure there is no stale stuff.
8:25:20
dnhester90
@beach thanks, I restarted the image a couple of times. I'll ad the serial option. But does that mean I have to manually set the compile order each time I add a file?
8:26:30
beach
It's not that hard. You will be warned by the compiler if something is undefined when a file is compiled.
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.