freenode/#clasp - IRC Chatlog
Search
15:49:56
Bike
we do need an interpreted function/compiled function distinction so that COMPILE and COMPILED-FUNCTION-P can work
16:08:57
beach
For type inference to be possible on temporaries, can you tell me if the following statement is true:
16:09:04
beach
Bike: For type inference to be possible on temporaries, can you tell me if the following statement is true:
16:09:06
beach
For each program point, we need to know what variables are equivalent (i.e. have the same value). But we do not need to know what variables in one program point are equivalent to what variables at some other program point.
16:09:17
shiho
The error is 'Received error of type: SIMPLE-ERROR Class #<The TRAITLETS:TRAITLET-CLASS CL-JUPYTER-WIDGETS:WIDGET> is not a valid superclass for #<The STANDARD-CLASS CL-JUPYTER-WIDGETS::VALUE-WIDGET> Debugger disabled - exiting."
16:10:11
beach
Bike: And if it is not true, I would like a small example where this statement is not true.
16:10:18
Bike
beach: i think so, yes. and of course we also need to know that a variable is equivalent to itself at another point
16:11:04
drmeister
Shiho: Actually - I don't need to. Can you go into ~/quicklisp/local-projects/cl-jupyter and pull the latest master branch?
16:11:34
beach
Bike: I am trying to design an algorithm for value numbering that gives the information you need for type inference.
16:12:20
beach
Bike: Type inference itself handles the case of knowing that a variable is equivalent to itself at some other point, doesn't it?
16:13:54
Bike
for a type inference algorithm operating on variables instead of value numbers like i've been rewriting it to do
16:16:17
Bike
it could be that we know the type of a variable that's not live but is equivalent to a variable that is
17:45:09
drmeister
I would argue that what really constitutes a tree is the roots. Which part can live on when you separate the top half of a tree from its roots?
17:46:18
Shinmera
On the other hand the mathematical definition of a tree means that any node can be the root.
17:46:20
drmeister
Case in point - I planted a plum tree last fall in my yard - a couple of weeks ago the wind knocked something on it and it snapped off at the ground. Now there are a few shoots coming out of the tiny stump. Life finds a way.
17:47:38
Bike
it depends, right? some plants you can cut off a stem and put it in the ground and bam, newplant
18:17:11
drmeister
I suppose things work because the entry point for all closures is a function pointer and closures only think they are interpreted - but they aren't.
18:18:00
drmeister
When I looked at it recently LLVM 5.0.1 didn't have the fix for the orc notifier but LLVM 6.0 does.
18:19:26
cracauer
although in hindsight that caused quite a bit of trouble given llvm's CMake's "interesting" compile-time configuration.
18:19:36
drmeister
Yeah - that was a stinker. That stupid typo in the orc notifier code caused us a lot of grief.
18:20:15
cracauer
Amazing, a coupe months ago it went just smoothly. Now I wanted to be fancy and got myself into fizz :-)
18:21:27
drmeister
I have to keep up with llvm - if I fall too far behind it's harder to get help and info on changes.
18:22:47
drmeister
kpoeck: I'll push a fix in a few minutes - once I confirm that it fixes the problem.
18:24:00
drmeister
LLVM? No - the LLVM folks have slowed down a lot in the last couple of years with the wrenching changes. But there are always API changes that I have to deal with.
18:24:39
drmeister
I climbed onto this treadmill around LLVM2.6 - and now we are up to LLVM6.0. Our little C++ library is growing up!
18:29:43
drmeister
How do you figure? I check here... https://llvm.org under "LLVM release schedule" on the right.
18:39:50
Kevslinger
beach: Is http://www.cs.yale.edu/publications/techreports/tr1049.pdf the article you were referring to in #lisp earlier?
18:59:36
Bike
the a, b, c letters in the stages refer to what level of clasp to build. aclasp has some lisp and a basic compiler, bclasp has a full common lisp, cclasp has a better compiler. when you build a later one it uses the earlier one to build it.
18:59:59
drmeister
Bike: I changed the way functions are printed. It was #<FUNCTION FOO> and now it's ...
19:00:06
drmeister
#<CLOSURE-WITH-SLOTS@0x11b0cc158 FOO :type cclasp :ftype :FUNCTION lambda-list: (A) :fptr 0x11d17a470>
19:01:02
Bike
anyway, having a validate-superclass method lets me define the class, and making an instance of it doesn't crash or anything
19:05:11
drmeister
cracauer: To build MPS Clasp needs the clasp/src/main/clasp_gc.cc file to be updated.
19:06:01
drmeister
That file is generated by a static analyzer (in clasp/src/lisp/modules/clasp-analyzer/clasp-analyzer.lisp) - but it's not trivial to run. I have AWS scripts that I use to launch it on AWS.
19:06:26
drmeister
Bike just made a fix that might fix the problem - I'm going to launch the static analyzer and see if it works.
19:07:42
drmeister
The mpsprep target is used to verify that the MPS version can build before the the static analyzer runs.
19:08:12
drmeister
clasp_gc.cc is out of date. It gets out of date whenever we add or remove classes or add or remove fields from classes that contain GC managed pointers.
19:09:48
drmeister
cracauer: At ELS Goran gave me some code that he asked the Ravenbrook people to write to interpret DWARF metadata - we haven't had time to look at it yet.
19:27:49
drmeister
cracauer: No - clasp_gc.cc is generated by running clasp-analyzer.lisp using iclasp-boehm
19:28:04
Bike
"Unhandled SIMPLE-ERROR in thread A nested errorwithin --disable-debugger error handling prevents displaying the original error" aaaaah
19:30:16
drmeister
Do you want me to look at it and give some pointers on how to debug these worst kinds of errors? I have a menu of approaches and techniques.
19:33:29
Bike
this is pretty weird though, it's complaining about a nested error but i'm pretty sure there's only one error
19:35:02
drmeister
You can use ./waf build_iboehm -v and get the Python list for each command and then run the offending one on the command line
19:35:18
drmeister
You have to fix it up though - to transform it from a Python list to a command line command.
19:53:37
drmeister
What I mean is the llvm folks haven't gotten lld to work on macOS. It says it does on the lld webpage - but the Apple engineers tell me not to touch it.
19:54:18
cracauer
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64 (tvOS)
19:58:20
drmeister
I found some changes in my local copy that I haven't pushed to github yet. I'm committing and building and then I'll try merging dev
20:01:30
drmeister
It's slow because we toss together all of the C++ code and the CL code as bitcode - and it tries to inline everything into everything. If we approached it a little more intelligently and linked/inlined just the stuff that makes sense to inline it would probably have a lot less work to do.
20:09:36
drmeister
Now that I say that about linking - I tried some experiments - it's a bit more complicated.
20:13:39
drmeister
If you run ./waf build_cboehm -v it will dump the Python lists that make up the build commands. I'd like to experiment with the linking stage and rather than link together all of the CL code and all of the C++ code at the same time, link subsets in two stages.
20:14:39
drmeister
There are a subset of C++ generated bitcode files that must be inlined into Common Lisp code.
20:15:42
drmeister
boehm-builtins-cxx.bc needs to be inlined into cclasp-boehm-common-lisp.bc(ll) and boehm-intrinsics-cxx.bc should probably also be inlined.
20:16:10
drmeister
I'm running some experiments right now - but they don't look like they are running much faster.
20:17:57
drmeister
rm cclasp-boehm --- that's the final executable that takes the longest to link together
20:19:59
drmeister
I think attila changed the wscript file to make things a bit easier to work with.
20:20:29
drmeister
I get the following - but it's a bit jumbled together so I have to cut things out...
20:21:53
drmeister
That links together the cando/build/boehm/fasl/cclasp-boehm-image.fasl file --- that is a dynamically loadable library that can be loaded into iclasp-boehm and gives you the full Common Lisp environment
20:23:11
drmeister
That links together the cando/build/boehm/cclasp-boehm executable - that is a standalone executable where all of the C++ code and CL code are LTO linked together - that takes the longest to link.
20:24:52
drmeister
We may not be able to speed up lto linking - it may just be the cost of doing business with lto that linking is slow.
20:25:24
drmeister
On Linux, if you set USE_LLD=True, then you use lld. If you don't set USE_LLD (or set if False) - then it uses ld
20:25:54
drmeister
lld is supposed to be faster than ld - but I haven't timed it. It seems faster - but they are both slow.
20:27:04
drmeister
There is another option: you can set LTO_OPTION = 'obj' in your wscript.config file
20:28:06
drmeister
The problem with that is lately (the past couple of months) it crashes the ld linker. I'll say that again - because it's a bit hard to believe - it crashes the linker.
20:28:59
drmeister
I've tracked it down to a problem with the DWARF metadata crashing the linker - but I don't see what's wrong with the DWARF metadata - it appears fine.
20:41:29
drmeister
What was that quote someone mentioned at ELS? Something about Lisp being the best language to use when you don't know what you are doing?
20:53:25
drmeister
Anyway, I haven't had a clear idea of how I'm going to use Cando to design molecular Lego based molecules for the past couple of years. I figured I'd sort it out when I got Cando to the point where I could do some exploratory programming.
20:53:50
drmeister
While working with the DNA origami in the past two weeks - a clear path forward is starting to gel.
21:27:36
drmeister
(ERROR "Mismatch in store function vs target function - you are attempting to store a value in a target where the store instruction is in a different LLVM function(~a) from the target value(~a)" "LAMBDA^COMMON-LISP^FN^^.3" "LAMBDA^COMMON-LISP^FN^^.1")
21:28:26
drmeister
I'm wondering if I'm looking at a different problem - or if it's the problem you saw an you have the fix in your branch
21:28:44
Bike
https://github.com/clasp-developers/clasp/blob/cst/src/lisp/kernel/cleavir/translate.lisp#L1216 this means no inlining is happening
21:31:56
drmeister
ACTION notes how this is very much like protein biochemistry, with inhibitors of inhibitors of inhibitors.
21:36:50
drmeister
Bike: That did the trick - cclasp is compiling now in cst. Once that finishes I'll try a merge of 'dev' into 'cst'.
23:02:13
scymtym
drmeister: if you have to/want to present source locations in a similar style from lisp, take a look at https://github.com/scymtym/text.source-location/tree/master
23:48:08
drmeister
Where do merge conflicts like this come from? I'm trying to merge 'dev' into 'cst'
23:48:45
drmeister
The one on the left is 'cst' - which should have been in 'dev' some time in the past.
23:49:17
drmeister
I thought merge conflicts only happen when both branches have changes in a range of source lines.
23:51:05
Bike
https://github.com/clasp-developers/clasp/commit/3be7458765bc201824d56aa2c1f99976852c071a#diff-39773bdc3e441809476e26f4f2f98c0b here.
23:54:40
drmeister
Here is a list of the files that still have merge conflicts - to give you a sense of the scale
23:55:42
drmeister
Hmm, there is a bit of a problem - it looks like there are folds and the contents of the folds are being copied.
0:05:35
drmeister
A lot of the differences make sense and I can pick which one to keep - but some are mysterious.
0:26:02
drmeister
I am making those changes by hand. Maybe tomorrow you can show me how to cherry pick without blowing everything up.
0:28:16
Bike
https://github.com/clasp-developers/clasp/commit/88b07f27bb306ec3a3feb500eb717eb0480cc9e2 probably this one
0:57:44
drmeister
This suggests we could run FreeBSD on AWS - this would help with debugging on Unix - because we can use dtrace
0:59:43
cracauer
Yes, dtrace and a bunch of other things. And I have FreeBSD on bigger boxes than my Macbook.