freenode/#sbcl - IRC Chatlog
Search
16:18:55
pagnol
Hi, I'm getting a "Heap exhausted" error while trying to compile a library with SBCL 1.4.3 and user phoe over on #lisp suggested that I report it here: https://gist.github.com/anonymous/706f615c5247fd1ad86997e26239ef65
16:21:42
jackdaniel
first of all, you shouldn't use require, ASDF hacks into require hooks if implementation provides them. use asdf:load-system (or ql:quickload). if it still blows, try loading manually file by file to narrow the problem to the file (in slime it is C-c C-k in file buffer), and then try loading toplevel-form after toplevel-form (C-c C-c) to narrow the problem to the specific construct
16:22:14
jackdaniel
than try to make a minimal reproducible case which may be easily reproduced by anyone having slime open
16:24:30
nyef``
Or it could be a "legitimate" heap-out, in which case increasing the dynamic space size might help.
16:24:43
pagnol
I only used require after ql:quickload kept getting stuck, to find out if it's related to quicklisp in any way
16:25:17
jackdaniel
nyef``: it is a little unlikely because from what I've read on #lisp the same applies to ccl
16:25:48
pagnol
err... I did not yet try compiling it with ccl, but according to the library's author it works with ccl
16:31:03
nyef``
It's an address-space allocation, not necessarily a memory allocation. That said, mind your overcommit configuration.
17:08:47
jackdaniel
phoe: it looks like compiler uses more than 1GB when compiling it, doesn't look like something breaks whatsoever
17:10:27
phoe
jackdaniel: yep, that's what I see. I just wonder if I can tweak the source code and/or SBCL compilation flags in a way that will not make SBCL explode when compiling with standard heap size.
17:33:11
scymtym
ACTION burned on all his SBCL bandwidth for trying a gazillion ways to rearrange variable and function name validation and ir1 conversion of binding constructs
17:39:22
scymtym
stassats: that's really nice. i should probably revisited some of my previous "more accurate error source locations" changes and see whether they can benefit from your changes
17:41:37
stassats
basically i'm just using the parent conses, that's why the whole (m) is highlighted there, but i found a way to highlight just the M
17:41:40
scymtym
stassats: what i wanted to do toady is reorganize and consistently use the various legal-{fun,var}-name-p, check-{fun,var}-name[-for-binding] functions, make the LET, FLET, MACROLET and friends ir1 translators more uniform and improve error source locations for errors from [SYMBOL-]MACROLET
17:43:05
stassats
and i modified the reader to optionally wrap each form with its boundaries, that way slime can actually parse the new info
17:47:04
stassats
but i'm going to modify the form-tracking-stream to be usable on any stream, not just fd-stream, and then make it able to perform modifications to the results
17:48:28
nyef``
stassats: This sounds like a huge win, and likely not something that I would know where to start with.
17:55:07
stassats
and it seems that it doesn't break backwards compatibility with slime, as it just ignores the additional forms
17:55:31
stassats
but i also need to adjust error locations, and source locations, as i want defstruct slots to be M-.able
19:43:26
scymtym
i'm not sure why we have this: (sb-int:valid-function-name-p '(defmacro (setf foo))) => T, FOO. there is a comment mentioning (DEFMACRO (SETF FOO)) but i'm pretty sure that's illegal. also, the whole thing doesn't seem to be ever called, at least during self-build
19:45:24
nyef``
SETF was rather a bit different in the CLtL1 days, and there may have been alternate branches of development as well. SBCL used to have a rather CLtL1 version of SETF, with various bits being ANSIfied but several CLtL1isms remaining.
19:46:41
nyef``
Is this the src/code/function-names.lisp implementation or the contrib/sb-introspect/introspect.lisp implementation?
19:50:15
scymtym
but the defmacro and macrolet "syntaxes" seem to be unused. at least by SBCL itself
19:52:33
scymtym
SETF and in particular CAS make sense as extended syntaxes. DEFMACRO and MACROLET - not so much as far as i can tell
20:10:14
scymtym
(defun (setf (defmacro (setf bar))) ()) is only prevented by package locks not using the function name syntax mechanism
20:28:13
nyef``
... Are you also going to provide a mechanism by which CLIM's SETF* functions can be realized?
20:31:54
scymtym
i'm only planning to remove things. the above was intended to demonstrate that the DEFMCARO syntax should be removed
21:40:09
nyef``
ACTION would like to get some PPC changes in before the freeze starts, or permission to merge them during freeze.
22:20:13
scymtym
Xof: it seems DEFMACRO has been changed to no longer depend on the special function name syntax in the meantime
2:20:02
corci
Project sbcl-master » without-unicode,MAC_OS_mavericks_64bit build #2910: FIXED in 26 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=MAC_OS_mavericks_64bit/2910/
2:23:50
corci
Project sbcl-master » without-unicode,ubuntu_trusty_64bit build #2910: FIXED in 30 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=ubuntu_trusty_64bit/2910/