freenode/#clasp - IRC Chatlog
Search
21:31:39
drmeister
I'd say maybe 5 min on the cclasp compilation time. This is bclasp though - so I'm not sure.
21:36:27
drmeister
akkad: I do - it's a decent example of Clasp - but it's a couple of weeks old and has some things you aren't expecting (1) chemistry code (2) runs a Jupyter notebook server.
21:56:30
drmeister
Ok, this is from digging into the output and extracting the cclasp compilation times - it doesn't include the link times and time to build ASDF
21:56:55
akkad
yeah this was it. [C 21:56:42.695 NotebookApp] No such file or directory: /home/app/bash
21:57:33
Shinmera
drmeister: It would be even nicer if it also had memory peak, total allocations, disk i/o, etc.
21:58:49
drmeister
akkad - it's pretty stripped down to keep it as small as possible. But there is a bash shell.
21:59:23
drmeister
I'm not sure why they have --entrypoint - but my friend who helped me set these docker scrips put that together.
21:59:59
drmeister
I have gotten into the docker container and mucked about in the shell to verify things.
22:00:51
drmeister
But that docker image is designed to start a Jupyter notebook server for non programmer chemists. You can start a slime session from the Jupyter notebook and talk to the Clasp environment through slime.
22:01:20
drmeister
I love docker - it opens up all sorts of possibilities and solves lots of problems.
22:02:26
drmeister
This is why I'm putting time into speeding up the cclasp compiler - because it takes a long time to compile all the Common Lisp dependencies to prepare that docker image.
22:05:36
drmeister
It's a little different with LLVM. It's more compile-C++/compile all Common-Lisp/link everything together into one executable.
22:06:26
drmeister
And yes - it can do that. You could do things like compile quicklisp and all dependencies and your code and link everything with the compiled C++ code into one executable.
22:13:27
drmeister
I'll combine this with fastgf and I need to figure out how to get more glue out of the generic function calls. It's copying arguments at least twice for every GF call.
23:03:04
drmeister
Bike: This is probably more of a beach question: I do this in Cleavir: (setf (fdefinition 'cleavir-primop:call-with-variable-bound) (fdefinition 'core:call-with-variable-bound))
23:03:26
drmeister
I'd like to replace the core:call-with-variable-bound call with something special.
23:04:08
Bike
but you could define call-with-variable-bound as a special operator instead. pretty sure.
23:36:58
drmeister
Bike: With that (setf (fdefinition 'cleavir-primop:call-with-variable-bound) (fdefinition 'core:call-with-variable-bound))
23:37:33
drmeister
Calls to (core:call-with-variable-bound symbol value thunk) are being generated every time a special variable is bound
23:38:09
drmeister
That generates a call to a useless wrapper that then calls core__call_with_variable_bound
23:38:47
drmeister
I can convert that to use a special operator (core:multiple-value-foreign-funcall "call_with_variable_bound" symbol value thunk) and cut out the useless wrapper.
23:40:50
Bike
currently cleavir generates a funcall ast and such directly. i could maybe rewrite it to fully convert a form instead, in which case you could use a macro
23:49:50
drmeister
Is there any other way? So rather than (funcall cleavir-primop:call-with-variable-bound symbol value thunk) I'd like (core:multiple-value-foreign-funcall symbol "call_with_variable_bound" symbol value thunk)
23:54:17
drmeister
I think there are some other things like this as well - but I think I have more control. Like how unwind-protect is implemented and catch and throw.
0:39:05
drmeister
Bike: Thank you - if/when you make that change, can you give me a heads up? At that point I'll define a macro.
0:58:19
Bike
https://github.com/Bike/SICL/commit/bab9c10a1df4bf068c45965682bfa7066e21a4cf don't seem to be any problems
1:01:21
drmeister
I mean - how much trouble is it to update the repository and maintain the &va-rest stuff.
1:01:37
Bike
i don't anticipate having to mess with lambda list parsing at all. i didn't put this in the clasp repository yet though.
1:34:17
Bike
shouldn't you have to worry about invoke for any use of multiple-value-foreign-call, then?
1:38:36
drmeister
This is what it was about. Cavalier use of 'call' when I need to be using 'invoke' when there is a landing-pad set up in the function.
1:39:13
Bike
i'm still not sure i get it. A caller needs to use 'invoke' when the caller is prepared to except abnormal exits from the called function, right?
1:39:33
drmeister
I just noticed that multiple-value-foreign-call was not completely fixed up. I'm not using it much and the things I'm using it for may not unwind the stack - or a nasty bug is waiting to bite me in the butt.
1:40:33
drmeister
Yes, precisely. The caller must use 'invoke' when the caller needs to evaluate cleanup code if the callee unwinds the stack.
1:41:20
Bike
i mean, not here. presumably call_with_variable_bound has some unwind-protect type thing.
1:41:21
drmeister
In cleavir it reduces to... if the translate-xxxx-instruction is passed a landing pad - then use it and use invoke.
1:42:55
drmeister
Yes, the call_with_variable_bound uses RAII - so it's going to do the right thing. But the stack unwinding can keep going - and it might want to stop in this function.
1:43:44
drmeister
There is nothing in the function to cleanup anymore - I'm going to do the stack backtrace cleanup in an outer function - that will simplify things.
1:48:58
drmeister
multiple-value-xxxx usually means the call uses the multiple values returned by something else.
2:33:23
drmeister
Up until a few hours ago a call-with-variable-bound involved a wrapper, the call-with-variable-bound and a funcall of the thunk with zero arguments. I removed the funcall of the thunk and it had no observable effect on compilation time.
2:34:49
drmeister
The cclasp compilation time now is 2474seconds and with the funcall it was 2454 seconds.
3:04:50
drmeister
But it supports this proposal of beach's that binding dynamic variables doesn't happen that often.
3:12:41
drmeister
Ugh - I have a crash in /Users/meister/Development/clasp/src/lisp/kernel/contrib/sicl/Code/Cleavir/Kildall/Specializations/Escape/transfer.lisp
3:20:57
Bike
https://github.com/Bike/SICL/blob/clasp-changes/Code/Cleavir/Kildall/Specializations/Escape/transfer.lisp#L104-L124 specifically
3:21:39
drmeister
https://github.com/Bike/SICL/blob/master/Code/Cleavir/Kildall/Specializations/Escape/transfer.lisp#L104
4:32:20
drmeister
I had a crash compiling mislib.lsp. I then ran it under the debugger and it's compiling fine - bleh.
5:44:45
Bike
beach: sent a pull request. i implemented the ast primop we were talking about for something else (more flexibility for call-with-variable-bound)
6:56:06
beach
By the way, real quick, I know it's late for you: I am making significant progress on the lambda-list parser for the CST. I am still changing my design frequently because I realize simpler ways of doing what I want.
6:57:11
beach
One thing I want to be possible to customize is what happens when a forbidden lambda-list keyword is encountered, and what happens when a symbol starting with & is encountered.
7:01:52
beach
... but I also need to do that tax declaration, which is going to be more complicated this year. :(
7:02:31
beach
Then, the CST stuff needs to be thoroughly tested, and after that, integrated into Cleavir.
7:03:08
beach
Since it is a separate library, it is appropriate to write good tests and good documentation. My new motto. :)
7:03:44
Bike
well, sounds like a plan. i have the kildall rewrite thing working but i'm not sure what the interface should be, and i've been kind of distracted with finding housing and stuff. but it shouldn't take too long to work something out.
7:04:53
beach
Unrelated: I am also very pleased with the progress on McCLIM. There is lots of activity and everybody is going a great job. It means I can concentrate on other stuff.
7:05:14
Bike
And this is kind of random, but sicl-format won't load without sicl-format-test because it has a package definition for sicl-format-test which uses lisp-unit.
7:06:13
beach
I am also moving away from unit-testing frameworks in general. I find them not worth the trouble.