freenode/#lisp - IRC Chatlog
Search
3:28:52
mathpacka
so I have an issue with packages in lisp, I install a package close emacs, then it vanishes, open emacs have to reinstall the package, I just installed emacs/sbcl/quicklisp/slime and I think the "quicklisp" folder is getting confused with the "(dot).quicklisp" folder
3:37:42
mathpacka
I changed where it was pointing to, and that's helped, but it's still loosing packages
3:39:30
mathpacka
so I have to run (ql:quickload :trivial-gamekit) before I can run (load "test.lisp") every time i run it, that's not normal is it?
3:43:00
pjb
mathpacka: you forgot to save the image, and then to launch the saved image, instead of the original lisp.
3:45:51
pjb
mathpacka: that's why I keep using loader files. Files named loader.lisp that perform all the ql:quickloading required and other initialization I want for each project. Then I have a repl command named ll (or a symbol-macro) that runs (load "loader.lisp")
3:54:36
pjb
mathpacka: also, you can just never quit emacs. This is just what I do. I boot linux, and never quit emacs, until linux crashes. (which may occur a couple of times every ten years).
3:55:23
pjb
On macOS: (emacs-uptime) "Up 12d 6h 41m 0s (Fri 2019-01-18 22:14:05), 45 buffers, 4 files"
3:57:08
pjb
On linux: (emacs-uptime) "Up 75d 13h 45m 13s (Fri 2018-11-16 15:10:56), 24 buffers, 6 files"
4:21:06
beach
jeosol: Bike is working on improving the intermediate language of the Cleavir compiler. And heisig is working on creating fast generic versions of the sequence functions, and in the process implemented sealing.
4:21:46
beach
My own work is stalled because of ELS submissions. Once we submit our papers (which are SICL related, of course) I'll be working on code generation.
4:22:50
jeosol
Not sure, you had sent me a list of topics in the past, but I then started to relocated, so lost track
4:24:15
jeosol
I am not a compiler or language expert, but mostly I focus on application and utilities. Maybe I could learn some of the former concepts from the project
4:24:39
beach
pillton: Restricting things like inheritance and method additions for certain classes.
4:25:34
beach
pillton: The idea is to define the sequence functions as generic functions, but to avoid the generic dispatch if the sequence is a list or a vector.
4:26:59
aeth
Oh that would be amazing, to see an implementation use specialization-store for the sequence functions like we in the community have to for everything else.
4:33:14
pillton
beach: You should be able to write (for ((item (the container arbitrary-container))) (my-function item)) for any type of container and have the macro generate efficient code. For arrays that would mean no range checks and no dereferencing displaced arrays when retrieving items.
4:34:16
beach
That part has been done, at least for the standard sequence classes. It's in our paper from a few years back.
4:36:13
pillton
I'll have to read the paper again. I thought what I was working on went further than what was mentioned in the paper.
4:36:57
beach
This is the way heisig has defined FIND: https://github.com/robert-strandh/SICL/blob/master/Code/Sequence/Generic/find.lisp
4:41:19
beach
For the vector types? No, each implementation just defines the macro so that every vector class is mentioned.
4:42:19
pillton
For arrays with rank greater than 1 you have to use row-major-aref for element access.
4:44:21
pillton
I know, but there are problems where you need to iterate over elements and or subsets. e.g. (for ((item (column (the (array double-float (* *)) array) 1))) ...)
4:45:17
pillton
The macro I was working on could interpret the container form and generate efficient code.
4:49:03
pillton
Restricting yourself to the builtin containers makes sense. Opening it up to generic containers requires a bit of thought on the consequences. I have documented an initial attempt at this problem here https://github.com/markcox80/template-function/wiki/Motivating-the-Template-Function-System .
4:54:06
beach
Looks good. You should definitely talk to heisig about what you have done. If there is something we can add to SICL to make things easier to implement, or faster, we should consider it.
4:54:50
beach
Since we are in control of how environments are represented (as first-class global environments), it is easy to add new things.
4:56:07
pillton
Well, there is the argument that all of what is done in template-function could be done in HIR/MIR.
4:57:46
beach
Like for arithmetic, we just inline the full dispatch code. Then we let the type inferencer prune it.
4:58:01
pillton
People fear templates in C++ as well. Template-function is very close to C++ templates.
5:00:12
pillton
I was referring to inlining the full dispatch code. You can always introduce (locally (declare (optimize take-as-long-as-you-want)) ...).
5:01:42
beach
Anyway, I need to concentrate on getting SICL working, so I need to delegate some stuff. Maybe you and heisig can think of this together?
5:02:20
beach
Once I have things working, I will definitely revisit optimizations and such, so I might get back to it, but that's not imminent.
5:03:32
beach
He is also a regular visitor to our home. We can have a week of brainstorming here. :)
5:05:15
beach
Oh, and #sicl is the main place for SICL-specific stuff, so as to avoid boring the #lisp people.
5:07:06
pillton
(Sorry. I was thinking about our discussion.) I think the problem boils down to finding the right balance between normal order reduction and applicative order reduction.
5:10:57
pillton
I have for years been trying to decide whether I want to cross over the line and wade through compiler design and implementation.
5:20:42
beach
SICL is (in my opinion, of course) a unique opportunity to create a modern Common Lisp implementation from scratch, so if we have new ideas on how to make it fast while still keeping it highly maintainable, this is the time to do it. Just to give you more information to help you decide. :)
8:19:35
shrdlu68
This is pretty neat, has anyone had success running it? https://www.cliki.net/Epilog%20System%20and%20Episodic%20Logic
9:26:01
jackdaniel
pillton: since SICL uses full CL as its host language working on implementing it should be quite pleasent and not much different than working on other Common Lisp applications