freenode/#sicl - IRC Chatlog
Search
6:39:59
phoe
scymtym: I am sorry; for personal reasons, I will need to schedule the next online Lisp meeting one week later. so, on 7th
6:43:09
scymtym
phoe: no need to be sorry, i hope everything is ok. as i said before, thank you for making the online lisp meetings happen. a one week delay may in fact make it easier for me to attend in chat
6:44:20
no-defun-allowed
I've updated Flexichain (only 1.25 years late) to use trivial-garbage, and now I'm confused as to how to convince git that my changes supersede the changes that add ECL and Clasp-specific code to it.
6:47:35
no-defun-allowed
It's okay, I've removed any evidence of my incompetency with version control, and I'll just try to make a pull request from my "outdated" branch.
7:01:32
no-defun-allowed
I tried to follow the instructions it gave to help me rebase, but I got stuck in a loop.
7:04:33
no-defun-allowed
beach: Should I merge https://github.com/robert-strandh/Flexichain/pull/4 then? (There's an option to squash out my commits experimenting with a supports-weak-pointers-p interface, which I don't use now.)
10:21:16
no-defun-allowed
I have to save the byte for machines and implementations trivial-garbage doesn't support.
10:24:00
no-defun-allowed
A good question. Usually I avoid constants because I don't seem to grasp how constant they have to be, but I guess that should be a very constant constant.
10:27:03
jackdaniel
another question: why do you bind a value? couldn't you simply put: (let ((can-do (weak-pointer-p (make-weak-pointer 42)))) …) ;?
10:28:09
no-defun-allowed
In the unlikely case a GC happens between MAKE-WEAK-POINTER and WEAK-POINTER-P. It's really unlikely, but I don't want to hear about it if it does happen.
10:29:04
jackdaniel
but it is not that the weak pointer disappears when the object is garbage collected, it is the value what disappears
10:29:37
jackdaniel
it doesn't matter, you are testing whether weak pointers are supported, not how long the object lives
10:30:11
no-defun-allowed
Wait, no, it's a sneaky feature in trivial-garbage. make-weak-pointer returns NIL if weak pointers aren't supported.
10:30:12
jackdaniel
you assume that if make-weak-pointer returns the object which is a wak pointer, then weak pointers /are/ supported
10:31:03
jackdaniel
and you don't really care about the value (whether it is garbage collected or not), because that's not what the test is about
10:31:42
no-defun-allowed
I could just do (weak-pointer-p (make-weak-pointer value)) then, sure. (If it's not supported, w-p-p also returns NIL)
10:32:21
jackdaniel
otherwise, when weak pointers are supported, *can-make-weak-pointer* may contain arbitrary object (i.e not suitable for a constant)
10:34:49
froggey
I'd suggest removing the test entirely. which implementations don't have weak pointers?
10:36:26
jackdaniel
I'd keep the test and the warning (i.e for sake of potentially new implementations which does not have coverage in the library)
10:38:26
no-defun-allowed
jackdaniel has been reviewed by independent fact checkers and is putting out false information
14:27:28
mseddon
it's not clear from the fairly short "source tracking" chapter in the SICL documentation, but am I right in thinking that every function in the /compilation environment/ has versions of e.g. cdr etc, that will walk through CST as though it were not there?
14:31:21
mseddon
perhaps more generally, is there any decent way to maintain good source information through macroexpansion without setting everything on fire?
14:34:33
Bike
mseddon: the macroexpansion in cleavir takes the "raw" cst, that is the form, and passes it to the macroexpander function. then it takes the result form and runs it through cst:reconstruct, which makes a new cst based on the original cst.
14:34:59
Bike
conses that are identical in the before-after of the macroexpansion are given the same cst i.e. the same source info, and any new conses get a default source info of the head of the macro form.
14:35:26
Bike
so the stuff in the environment doesn't matter. this is supposed to work in any implementation
14:36:30
mseddon
or is it literally a simple, standard s-expr and a separate hashtable for anything eq in that s-expr to it's source info?
14:36:33
Bike
https://github.com/s-expressionists/Cleavir/blob/master/CST-to-AST/convert-cst.lisp#L73-L79
14:36:57
Bike
https://github.com/s-expressionists/Concrete-Syntax-Tree/blob/master/reconstruct.lisp here is the explanation in comments
14:37:44
Bike
we also have with-current-source-form which is analogous to with-source-form, but it's not really for source info in this fashion, more to do with signals
14:40:31
mseddon
i suppose no useful information on atoms, but where you want it is stepping over complex forms anyway.
14:41:05
mseddon
and generally you can pass source from the containing cons downward in the compiler.
14:41:54
Bike
which is a difference from the external hash table approach, since you can have multiple CSTs with different source locations for the same atom
14:43:18
beach
Someone told me that SBCL solves the problem by associating source information with the CONS cell immediately preceding the atom. Or maybe they told me that this is another way of doing it.
14:43:22
mseddon
right- this is more like my approach that i am messing with, but my issue becomes i have this extra CST type in the compile environment
14:46:24
beach
And the first phase of Cleavir is CST-to-AST, so there is no special stuff there either. The compiler is just written to process CSTs rather than S-expressions.
14:51:10
jackdaniel
if anyone is interested, there is a recent blog post about cpython compiler implementation (https://tenthousandmeters.com/blog/python-behind-the-scenes-2-how-the-cpython-compiler-works/)
15:00:12
jackdaniel
"the main reason to use pypy is because it is faster than cpython" -- quite lame advertising strategy if you ask me
15:02:45
shka_
JIT compilation is the only viable approach to optimize python code and that's what pypy does
15:07:34
jackdaniel
from a technical standpoint it is intelectually dishonest -- they present benchmarks favorable to them and don't mention that there are problems with portability when switching to pypy. but I don't care that much about python, so I'm only noting the lameness of their pitch ,)
15:08:31
jackdaniel
this may be less biased I suppose: https://pybenchmarks.org/u64q/benchmark.php?test=all&lang=pypy&lang2=cython&data=u64q
15:15:12
jackdaniel
hm, I posted a wrong benchmark, sorry. either way, I've found the post above quite interesting