freenode/#sbcl - IRC Chatlog
Search
15:06:03
scymtym
interesting effect on default and fancy core sizes of the "x86-64: Factor out and adjust double-wide CAS emitter" commit: https://ci.cor-lab.org/job/sbcl-master/featureset=default,label=ubuntu_trusty_64bit/plot/ https://ci.cor-lab.org/job/sbcl-master/featureset=fancy,label=ubuntu_trusty_64bit/plot/
16:06:36
scymtym
stassats: sure, the x86 cores grow and shrink in smaller increments and thus usually react to changes more directly, but this particular commit only affected x86_64
16:07:27
scymtym
unfortunately the plot plugin sucks. if you look at it wrong, let alone touch the configuration, it throws away all historic data
16:09:03
scymtym
yeah, all i'm hoping for is maybe catching dramatic changes between successive builds. it is not good enough for any form of longer term monitoring
16:25:21
scymtym
is it using this https://sourceforge.net/p/sbcl/sbcl-git-hooks/ci/master/tree/post-receive-email ?
16:53:36
Xof
re sbcl-commits: it is or was using that, but it is possible that sourceforge has changed things
16:53:54
Xof
and it is definitely true that sourceforge has broken shell access, so I can't actually see what's in the hooks for the master repository
16:54:30
Xof
honestly at this rate it might be quicker to get French citizenship for my children than get all of sourceforge working again
16:58:45
scymtym
maybe we had the git config variables described in the header comment of the script in the old GIT repository and they got lost in the migration. but as Xof says, no way to know without shell access
17:00:35
scymtym
i think you have to copy it into the repository for changes to go into effect. that's what the README seems to say
17:42:45
scymtym
i would like to push these changes to sb-sprof https://github.com/scymtym/sbcl/tree/wip-sb-sprof . the changes are sufficient for supporting an initial version of the clim flamegraph thing ( https://techfak.de/~jmoringe/clamegraph2.png ). do the changes look OK?
18:52:22
stassats
i think my final plan for source location would be to hook into reader macros, by function name, when READ is called by an unknown reader macro, unwrap the form but save all conses / atoms (some might be used only once), and when that reader macro returns, rewrap anything that is still EQ
18:57:22
scymtym
the crazy alternatives would be running macros and reader macros in a special interpreter or turning ATOM, CONSP, CAR, etc. into generic functions that also work on syntax objects
18:58:23
corci
Project sbcl-master » without-threads,ubuntu_trusty_32bit build #3124: FIXED in 14 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-threads,label=ubuntu_trusty_32bit/3124/
18:58:47
stassats
but for macros, i had another idea, since they are defined by defmacro usually, we can instrument stuff there, no need to interpret or compile anything
18:59:10
stassats
just see if a form just goes , into a list that is returned or into a third party function
19:01:19
scymtym
that could be a reasonable compromise. although i would worry about users piling all the code into DEFMACRO forms to get better source tracking
19:02:20
stassats
which means i need to finish my current level of support and just it and note where it falls short
19:04:20
scymtym
i suspect, the unwrap-and-reconstruct approach with the single-occurrence heuristic for atoms will work fairly well in practice
19:04:42
corci
Project sbcl-master » without-unicode,ubuntu_trusty_32bit build #3124: FIXED in 21 min: http://ci.cor-lab.de/job/sbcl-master/featureset=without-unicode,label=ubuntu_trusty_32bit/3124/
19:04:59
corci
Project sbcl-master » default,ubuntu_trusty_32bit build #3124: FIXED in 21 min: http://ci.cor-lab.de/job/sbcl-master/featureset=default,label=ubuntu_trusty_32bit/3124/
19:06:03
stassats
scymtym: for multiple use, could track depth first order of atoms, or something, but i'm afraid some reader macros might change the output orde
19:07:04
stassats
but each list form would be handled separately, so chances that a single list has multiple duplicate atoms are smaller
19:10:01
scymtym
maybe one of those surveys across all code in quicklisp would be in order to determine how frequent the different cases occur
19:12:34
stassats
if source location handling could be standardized, and things like named-readtables are used, it could prove functionality to supply routines to handle custom macros
19:13:30
stassats
so that you don't have to send definitions to slime and can extend it independently
19:13:36
scymtym
ACTION waits for a scheme person to join and be like "you know about syntax objects, right?"
19:15:25
corci
Project sbcl-master-windows » Windows_7_32bit build #2108: FIXED in 30 min: http://ci.cor-lab.de/job/sbcl-master-windows/label=Windows_7_32bit/2108/
19:15:26
scymtym
same goes for WITH-CURRENT-SOURCE-FORM, imo, since macros have no other way of indicating which part of the input caused a particular problem
19:17:42
scymtym
if you go the racket/guile route and have macro writers manipulate syntax objects, the situation is different
19:21:04
corci
Project sbcl-master » fancy,ubuntu_trusty_32bit build #3124: FIXED in 37 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fancy,label=ubuntu_trusty_32bit/3124/
19:21:36
scymtym
user programmable source locations would also be nice. for custom defFOO macros. i think lispworks already has something like that
19:25:25
scymtym
ok, i have one question though: do we have a smaller hammer than (coerce … 'function), i.e. that doesn't compile lambda expression, but higher level than SB-KERNEL:%COERCE-CALLABLE-TO-FUN?
19:25:26
corci
Project sbcl-master » safepoints,ubuntu_trusty_32bit build #3124: FIXED in 41 min: http://ci.cor-lab.de/job/sbcl-master/featureset=safepoints,label=ubuntu_trusty_32bit/3124/
19:28:21
scymtym
i can use that. i thought we might have something else since it looks pretty internal
19:35:02
scymtym
dougk_: COERCE-TO-INTERPRETED-FUNCTION turns lambda expression into interpreted functions. i want to only accept functions and function names
19:35:20
corci
Project sbcl-master » fasteval,ubuntu_trusty_32bit build #3124: FIXED in 51 min: http://ci.cor-lab.de/job/sbcl-master/featureset=fasteval,label=ubuntu_trusty_32bit/3124/
19:44:15
corci
Project sbcl-master » ccl,ubuntu_trusty_32bit build #3124: FIXED in 1 hr 0 min: http://ci.cor-lab.de/job/sbcl-master/featureset=ccl,label=ubuntu_trusty_32bit/3124/
20:57:53
stassats
read-preserving-whitespace is exactly like read when the recursive-p argument to read-preserving-whitespace is true.
21:46:52
dougk_
stassats: that aspect may be broken but the other aspect is whether it is permissible to for read-char to hit EOF ever. if recursive-p it can't, so I think that much works
23:35:19
stassats`
well, read-preserving-whitespace with recursive-p behaving exactly like read, that means read will be passed recursive-p as T as well, so it means read will be preserving whitespaces?
23:35:41
specbot
The RECURSIVE-P argument: http://www.lispworks.com/reference/HyperSpec/Body/23_acb.htm
23:36:22
stassats`
shouldn't they have said that read with recursive-p behaves like read-preserving-whitespace?
23:39:47
stassats`
sbcl returns the same result for the second example, but a different for the first, ccl is reversed
23:40:38
stassats`
"However, if read had been used instead of read-preserving-whitespace", but read-preserving-whitespace is using recursive-p, so it's exactly the same