freenode/#sbcl - IRC Chatlog
Search
12:00:42
scymtym
stassats: re highlighting in source text: maybe https://github.com/scymtym/text.source-location/tree/future has something useful
12:16:26
stassats
i could instrument each standard reader macro, and that wouldn't be much of a problem, but i'd also prefer it to work on non-standard macros
12:22:40
stassats
i could change the path format that sbcl uses, but then it wouldn't work on older slimes and it would be hard to use on s-exp forms, not text
12:22:53
scymtym
stassats: reader macros in general or reader macros performing recursive calls to READ?
12:23:51
stassats
scymtym: in general, i'm wrapping each form returned by READ in a structure, so things like #+, which examine what read returns, do not work
12:26:10
stassats
i could build a parallel structure, just by recording the bounds and then establishing nesting, etc.
12:27:04
scymtym
that sounds similar to what eclector does: https://github.com/robert-strandh/Eclector/blob/master/code/concrete-syntax-tree/read-cst.lisp
12:28:26
stassats
i guess #-abc returns zero values, so i need to stop building including the collected substructures until read returns non-zero values
12:30:08
stassats
i was thinking, if #+abc x, then it'll have two substructures, both ending at the same character, no normal form can end at the same character, so disregard the outer form, leaving X, but that doesn't work well with #(a b c)
12:33:05
stassats
so the only solution would be probably to change the way we record form paths for character streams
12:37:47
scymtym
i'm not following in detail (got a cold), but are you suggesting storing each source location a second time, in an augmented format?
12:41:20
stassats
right now we store form paths into s-exps, but also storing form paths into each call to READ
12:45:41
scymtym
i may be missing some context, but why not character offsets if we define a new source location format alongside the old?
12:45:52
stassats
when the form is an atom, i'm already not locating atoms, but their surrounding conses
12:48:12
stassats
but i think i'm going to have the same problem with approach, but on the encoding step, not decoding
12:50:19
scymtym
i was never sure how well the increased robustness against source changes of the path approach works in practice. maybe switching to character offsets would make me realize that it works pretty well
12:58:13
stassats
ideally, it shouldn't intern symbols, so, if i use uniterned symbols, they are not unique
15:59:11
stassats
atoms with a form have order, so if i just count which atom is that i can reconstruct the original form
18:03:22
wtjones
just started learning lisp and already loving it. Thanks for making this awesome lisp compiler!
18:29:31
corci
Project sbcl-master ยป without-threads,ubuntu_trusty_64bit build #3120: FAILURE in 6 min 1 sec: http://ci.cor-lab.de/job/sbcl-master/featureset=without-threads,label=ubuntu_trusty_64bit/3120/
19:43:55
fiveop
I was looking into implementing a few syscalls with the instruction that stas kindly added. Passing integer arguments is easy enough. Passing in pointers to strings seems to be another matter. I looked into what is done in the alien function related code
19:44:36
fiveop
My impressions is, that a lot of the stuff (around deport etc.) might be necessary as well for syscalls, though I did not fully understand that yet.
19:46:39
fiveop
stassats: thanks for your comment on the syscall snippet. I have a follow up question. If I declare the arg types as you suggested and check in the lisp code that I do not pass anything in but (unsigned-byte 64), will the compiler handle for me dealing with values larger than most-positive-fixnum
19:49:33
fiveop
Suppose I write (syscall1-no-return (1+ most-positive-fixnum) 0), won't the first argument be a bignum (assuming it cannot be optimized away, because it's not a constant but a input derived value)?
20:05:25
fiveop
(syscall1-no-return 231 (1+ most-positive-fixnum)) yields a 0 exit code (as it should), in particular, it does not crash! :)
20:11:38
fiveop
is it possible that the two instructions share the same label (e.g. L8 and L9) in the disassemble output, but only one is shown?
20:14:06
fiveop
so I thought, that maybe the error trap has two labels (L8 and L9) but only one is shown
20:47:41
fiveop
I want to say that a temporary is valid after the syscall instruction was executed. Can I do that with :from (:eval N) ?
20:56:24
stassats
it just saves all registers, if you know which is are volatile you can specify them
21:21:45
fiveop
I can syscall open now and get the right fd, but something with the path is still not working (I tried vector-sap for conversion): https://gitlab.com/snippets/1703371