libera/#clasp - IRC Chatlog
Search
15:14:13
Bike
i think i may see the problem. i don't think it will affect your database, but it will be generated without tracking refs, so maybe it's bigger than it has to be
15:23:38
Bike
basically, tracking-refs evaluates its first parameter to get a ref-context object, which is a conspack thing, and then evaluates the body with ref tracking in that context. but you have an empty body, so it just evaluates the "ref context", which is in this case the encode-file call. so the encoding will be done without ref tracking, but it will be done.
16:50:16
yitzi
Bike: The sharpsign-equals-protocol protocol branch already been merged in Eclector. Just FYI. Not the recent eof fixes, obviously.
16:56:15
Bike
i'm hoping to wait for the release tag so we can use that instead of a commit hash in repos.sexp
17:08:41
Bike
i'm going to merge in my bytecode file compiler changes into main (after testing). the bytecode file compiler will be off by default but i'll add a cmp::enable-bytecode-file-compiler. things aren't finalized yet but they're pretty far along.
17:25:24
phantomics
Hi, I was trying the latest Clasp and can't get into Slime, Swank fails to start with a message that says "The name must not be NIL", has anyone else run into this?
17:38:30
yitzi
Bike: have you done PR's recently to slime? I use sly so I'll have to PR those if they haven't already.
17:40:59
Bike
https://github.com/slime/slime/pull/750 yitzi. i had another one but i think i screwed up and deleted it. shit.
17:56:19
scymtym
would you prefer to tackle the question of client code binding *READTABLE* before a potential Eclector release or after?
18:05:17
Bike
hell if i understand why slime is suddenly doing (make-lock), though. i don't see it in the code we should be loading.
18:06:47
phantomics
In good news, all of April's standard libraries compile now when they didn't before
19:01:30
Bike
come to think of it, conspack is based on the fast io library. that might need special support to actually be fast.
19:02:37
Bike
our read-sequence could probably be faster, though. i think we just repeatedly read a byte right now
19:24:28
yitzi
I am trying to understand the purpose of our AnsiStream_O. It just seems like an extra class in the precedence list of the stream classes. Nothing specializing on it. And as a result we have precedence lists like (SYNONYM-STREAM ANSI-STREAM STREAM GENERAL T) versus (SYNONYM-STREAM STREAM T)
19:30:44
Bike
we might not dispatch it, but we check for ansi-stream-ness in a couple places in lispStream.cc, right?
19:34:57
yitzi
And in predlib.lisp there is a type declaration for STREAM as (OR EXT:ANSI-STREAM GRAY:FUNDAMENTAL-STREAM) ... which isn't technically correct since Gray streams have a STREAMP generic. Gray streams don't actually have to be subclasses of GRAY:FUNDAMENTAL-STREAM or CL:STREAM
19:36:40
Bike
i mean i can see right here we're doing AnsiStreamP in stream_dispatch_table, and StreamOps is presumably not going to work for a gray stream
19:37:05
yitzi
Yeah, but everything that is in AnsiStream is in Stream_O. And you can't subclass STREAM cause it is a builtin.
19:38:59
yitzi
And the dispatch table isn't used a per instance thing for Gray streams....it gets bypassed into the static CLOS stream dispatch table for all Instance_O.
19:40:45
Bike
maybe we need to move some stuff from stream to ansi-stream then. i think you brought that up a few weeks ago?
19:48:17
Bike
well, i suspect that stream-we-can-use-internal-operations-with versus stream-we-go-through-clos-for is still a useful distinction, but you've looked more into it than i have
19:52:11
drmeister
I found a "hole" in the training molecules and when I filled it another 2,000 training molecules were added. Yikes. Now I'm up to 9,656 of them.
21:19:14
yitzi
Well, at least poking around in lispStreams.cc has illuminated some issues I had with stream columns in Inravina. Looks like there are a few missing Gray stream methods like STREAM-LINE-COLUMN ((stream ansi-stream)....)
21:22:11
yitzi
Also, it seems like ANSI-STREAM is mostly useful to create Gray methods for the low level streams and avoid specializing on STREAM. So, I'm am going to go back to my original idea and move as much stuff from Stream_O into AnsiStream_O as possible.
1:28:05
Bike
should be fixed as of https://github.com/clasp-developers/clasp/commit/0c62ddec338f977a4d0b19cf33f32f429e1fc380
1:33:17
Bike
there's a bit of a deeper bug in slime that makes the error pop up instead of just going to an empty buffer, but it shouldn't go to an empty buffer to begin with
1:39:17
Bike
and i'm assuming where you see it is where i usually see it, which is i C-c C-c something and then try to M-. or go to frame source in sldb
2:52:19
Bike
so for the fasl format and native code, i think i may have to work with the JIT a little more directly
2:52:46
Bike
if i understand the faso code, what basically happens is that we load in an object file as a blob of bytes, and then we ask the jit for a special startup function that's in the object file, and then call that
2:53:49
Bike
but what i'd like is if we could load an object file, and then we just make a bunch of Function_O objects from the code in there, and maybe call them/etc normally later.
2:55:39
Bike
which is how it works with the bytecode. we load in the bytecode module, and then make a bunch of different bytecode functions with different entry points into the module.