freenode/#sbcl - IRC Chatlog
Search
18:03:53
nyef``
IIRC, it's normal flow for when the current allocation region is insufficient to handle the allocation, and so either a "large object" needs to be allocated or a new allocation region needs to be set up.
18:04:03
fortitude
I'm getting out of my depth here, but does the safepoint mechanism rely on threads being in an alertable wait state on windows?
18:04:46
stassats
fortitude: nobody knows what safepoints rely on windows, that's why they're broken
18:05:22
nyef``
ACTION has reasons for using 32-bit SBCL. They are HPPA, SPARC, PPC, MIPS, MIPS again, MIPS yet again...
18:05:57
fortitude
aside from more memory space and a larger register set, does 64-bit sbcl differ significantly from 32-bit?
18:09:22
fortitude
stassats: I know that's a non-trivial thing to have, but does it make a big difference architecturally (and not just perf-wise)?
18:12:50
nyef``
It's not alone in not having threads. And I have long had a theory about how to scare up that one extra register for the TLS block, but have never sat down to actually try it out.
18:14:58
nyef``
I actually don't have a working Linux ARM system anymore. Which is annoying, because my former Linux ARM system was set up as power control for my Linux PPC system.
18:51:02
fortitude
what is thread_in_lisp_raised used for? seems to be called by an exception handler, but I can't find where
18:55:34
nyef``
Two hits in interrupt.c, one in win32-os.c, one in thread.h, and a pile in safepoint.c, btw.
18:56:25
fortitude
nyef``: I've found the function, but the call stacks says the immediate parent is handle_exception, which doesn't look like any of those
20:33:05
fortitude
an hour later, I realize that the disassembly doesn't match the code for gc_stop_the_world() because there are /two/ of them
20:38:34
k-stz
Hey, I'm trying to read out from process memory. But when I feed some high address into it like: (file-position *process-mem-file* xffffffffff601000). I get a type error that it only accepts (SIGNED-BYTE 64), but I need (unsigned byte 64). (sbcl, on a linux)
20:38:45
k-stz
code piece: https://github.com/k-stz/cl-ptrace/blob/c6fdf5a1d4b122ac659cf9b91cec57a55730cf0a/cl-ptrace/proc-pid-dir.lisp#L137
20:50:08
nyef``
k-stz: Per the Linux man pages for lseek and lseek64, off_t is a signed type. You're not allowed to need (unsigned-byte 64) because it's not valid for that function.
20:53:22
foom
I'm pretty sure it will treat the signed value as an unsigned value if you use SEEK_SET.
20:54:42
nyef``
Right then, at which point you might as well mmap() chunks of the address space anyway?
20:57:09
k-stz
foom: IIRC recall some kernel guys telling me I shouldn't use those, as its not part of userspace and thus shouldn't be used outside the kernel code
21:02:06
nyef``
Every so often, I look at the idea of creating a debugger for Lisp code that runs from a separate address space.
21:03:49
k-stz
ah cool, yeah that's ptrace intended use after all. I wanted to stretch it and build a process memory hacking tool
21:05:46
nyef``
And attach doesn't require root, you can attach to processes owned by your current user id.
21:07:34
k-stz
yeah I use attach as well, I made a small youtube series if your interested, I walk through a development narative culminating in some cheat engine capability hacking games
21:09:16
k-stz
https://www.youtube.com/watch?v=PuGgCOyBMyc&index=1&list=PLBgJcoaU2hl-JnoVOzjYB5qk_PfYjPm-I feel free to leave some feedback! :)
21:11:26
nyef``
My own ptrace stuff, if you're curious, is at http://lisphacker.com/temp/unfinished-ptrace-stuff.tgz and also relevant to the whole idea is http://lisphacker.com/temp/article-drafts/object-memory-dumper.txt
21:19:02
nyef``
I sortof tried to make a point of having hooks for using different CPU types, possibly via a proxy program similar to the gdb remote debug protocol, where your debugger UI and its assorted logic runs on one machine, but the program being debugged runs on another.
21:20:23
nyef``
But also allowing different CPU types for the local machine as well. Not that I was necessarily going to implement any others, but making the point of not making it harder than it has to be to port seemed important.
21:23:07
k-stz
I just hacked away, and dealt and hardcoded some parts so it only works on 64bit cpu/os now. I see that you use a (ptrace ...) in code, but no :cffi, did you create bindings to the syscall as well?
21:29:06
k-stz
nyef``: I got some reading to do! If I find something useful, may I use it in my code?
21:34:25
stassats
something like (:TEST-NOT (FUNCTION-DESIGNATOR ((NTH-ARG 0) (NTH-ARG 1 :SEQUENCE T :KEY :KEY))))
21:36:15
stassats
gut the dependent function-designator casts working, just need to adjust the data format to the new scheme
21:37:14
stassats
right now, i'm actually not improving any of the old behavior, just improving the implementation
21:38:18
stassats
(function-designator * * :dynamic-extent t) would be an easy addition to the description format
21:41:18
stassats
and it turns out, casts have to depend not only on LVARs, but also on LEAFs, because of let conversion
23:40:04
karlosz
stassats: for the HOF syntax, wouldn't having something akin to ml-style type variables be more general for constraining types than (NTH-ARG 1 :SEQUENCE T)
23:44:02
karlosz
as in, the type signature for remove would be remove : 'a , sequence 'b, :test-not (function ('a 'b) boolean)
23:44:46
karlosz
'a and 'b can be anything, its just that the first argument of remove has to match the type of the first argument of the :test-not function
23:45:50
karlosz
giving the argument type names seems more general than describing them positionally
23:50:23
stassats
374 insertions(+), 679 deletions(-), i need to commit it quickly somewhere safe lest i lose it
23:56:10
stassats
nth-arg is not a new thing, it's a change from (:test (callable 2 :args (0 (sequence 1 :key 2))))
0:01:36
stassats
and function-designator now can specify result-types, so map-into can be checked, i haven't done that yet
0:02:14
stassats
i have "(defun foo (z x) (map-into (the string z) #'evenp x)) no conflict" in my notes
0:07:43
karlosz
is it possible to produce better code, in the case that the compiler can prove for (remove 97 x :key #'char-code) that 97 can be fixnum compared to the results of char-code
0:08:53
stassats
i was thinking about turning (remove-if (lambda (x) (eql (the char-code-limit x) 97)) y :key 'char-code)
0:09:51
stassats
but even without such drastic transformations, (remove-if (lambda (x) ...) "abc") X is not known to be a character
0:16:21
karlosz
if the result were derived to be null in the case of remove-if would that would result in code deletion
0:19:18
stassats
checking if a constant is shared with anything could be possible, but macros make things harder
0:27:07
karlosz
there are some compilers out there that do enough closure analysis to stack allocate
0:27:44
stassats
no need to analyse anything, (function-designator ((nth-arg 1 :sequence t :key key)) * :dx t)
0:42:46
nyef``
stassats: SBCL's DX implementation, while not necessarily *wrong*, is brain-damaged. It treats DX as an LVAR property, which it really, really isn't.
0:46:34
nyef``
Here's a simple one: you have an LVAR where the DEST is a variable declared DX, so it's a "DX LVAR". But it has multiple USEs, and only SOME of those uses are DXable.
0:47:05
nyef``
Because DXness is treated as an LVAR property, *none* of the USEs are permitted to stack allocate.
0:47:37
nyef``
The other one is that CLAMBDAs are an odd parallel to LAMBDA-VARs, but are treated very differently.
0:50:57
nyef``
True, it's not often that you DX LET bind the result of an IF, one branch of which causes allocation.
0:51:38
nyef``
But it's a valid enough use-case that we've actually had a bug from someone trying it.