Search
Sunday, 11th of November 2018, 23:09:45 UTC
9:52:38
flip214
With git HEAD I get an error in MAYBE-EMIT-MAKE-LOAD-FORMS: https://pastebin.com/LSUexMF6
9:52:51
flip214
with SBCL from 2 or 3 months ago it worked okay
9:57:22
flip214
can anybody help me, please?
9:58:22
scymtym
you are loading local-time, right?
9:59:23
flip214
yeah... and did so for quite a few years
10:00:35
scymtym
ACTION tries to reproduce the issue with SBCL HEAD
10:00:43
flip214
I believe the (defparameter *default-timezone-repository-path*
10:00:43
flip214
(flet ((try (project-home-directory)
10:00:56
flip214
(eval-when (:compile-toplevel :load-toplevel :execute)
10:00:56
flip214
(defconstant +months-per-year+ 12)
10:07:28
scymtym
quickload local-time worked fine with a newly built SBCL 4a37e8676
10:07:42
scymtym
maybe i don't have the right local-time version
10:24:58
|3b|
flip214: does it break without slime?
10:25:08
flip214
scymtym: I just did a ql:dist-update
10:25:47
flip214
I just verified - sbcl 1.4.13.debian loads :local-time
10:26:58
flip214
and the current SBCL does (ql:quickload :local-time) too
10:27:08
flip214
perhaps it's some other library that breaks things?
10:27:30
flip214
F 6. (SB-C::MAYBE-EMIT-MAKE-LOAD-FORMS #P"/dev/random" NIL)
10:28:02
|3b|
anything odd about your filesystems?
10:28:52
flip214
I don't think so?! ext4 on an SSD, been that on this machine for 15 months
10:32:52
flip214
F 6. (SB-C::MAYBE-EMIT-MAKE-LOAD-FORMS #P"/Library/Application Support/Clon/" NIL)
10:33:03
flip214
What's that doing here? I'm on Debian, not MacOS.
10:34:19
flip214
Now I'm using a different order in my ql:quickload list - and :local-time loads, but clon and ironclad break.
10:35:04
scymtym
flip214: could you trace MAKE-LOAD-FORM before loading the library. maybe something installed a bogus method
10:35:05
|3b|
that's there in case you run it on macos :p
10:38:01
flip214
looks like (most) libraries can be QL'ed by themselves... but when more are loaded into one image, at some point it breaks.
10:39:09
flip214
old SBCL can load the whole QL list
10:41:39
flip214
scymtym: does that help? https://pastebin.com/ZmK8Nexd
10:45:21
|3b|
if you hit v on the "error printing frame" frames, does it find any source?
10:45:24
scymtym
flip214: maybe. i'm comparing the output. there is also (trace … :methods t). that may help spotting additional methods
10:46:25
|3b|
or if you inspect the error condition (hit enter on error at top of sldb), do you get more info?
10:50:14
flip214
you're right - printing the frame and finding the source are independent!
10:51:15
flip214
the topmost frame is in swank-presentation-streams.lisp -- monkey-patch-stream-printing
10:51:19
|3b|
what is your *default-pathname-defaults* ?
10:53:02
flip214
|3b|: trying to inspect just returns me to "invalid number of arguments: 3" and a new stacktrace
10:53:36
flip214
just my current directory. valid, accessible, not removed.
10:54:26
|3b|
if you open the LABELS ... MAYBE-EMIT-MAKE-LOAD-FORMS frame can you inspect the pathname?
10:55:13
|3b|
any of them that break there
10:55:31
flip214
for *d-p-d* I did just that from the backtrace, yes
10:55:33
scymtym
swank-presentation-streams.lisp defines a method on PRINT-OBJECT for pathname. that could have something to do with it (and i don't think it is permitted)
10:56:46
|3b|
ah, i guess look at the source where you end up from top frame and see if it is passing 3 arguments to something
10:58:39
scymtym
for the "visit source of unprintable frame" method, better untrace everything first so print errors don't get in the way
11:04:19
|3b|
flip214: i meant inspect the pathname argument to the frame
11:04:43
flip214
I *believe* that ~/src/sbcl/src/code/print.lisp output-object print-it, the (funcall fun stream object) call is the bad call
11:05:37
flip214
but why would pprint-dispatch return sb-impl::%print-unreadable-object? that's incompatible, too
11:06:47
flip214
oh, (sb!xc:defmacro print-unreadable-object ((object stream &key type identity)
Monday, 12th of November 2018, 11:09:45 UTC