freenode/#lisp - IRC Chatlog
Search
17:00:37
pjb
beach: you don't mean "AI", you mean stockastic machine learning ;-) Hofstadter wouldn't call that AI…
17:21:00
flip214
Is there a function to convert a 2-dimensional array to 1-dimensional, like ROW-MAJOR-AREF then addresses it?
17:39:31
flip214
when given a function like #'=, is there a way to get back to the symbol? (doesn't work for anonymous functions or closures, of course)
17:51:47
flip214
TheWild: '(1) potentially gives you an immutable list - it could be stored in ROM, for example. So changing the CDR of that CONS is not allowed.
19:27:50
TheWild
lists in Lisp are linked lists or something similar. I wanted to see what will happen if I connect end of the list to its beginning.
19:35:23
vms14
this makes lisp reader check if the member of that list was seen yet by tracking what it reads
19:40:38
sjl
I wish backquote DID have to produce a fresh list each time... it would make it more generally useful, I think. But, oh well.
19:42:39
pjb
(setf *print-circle* t) #| prepare the printer |# (let ((item (list 1 2 3))) (setf (cdr (last item)) item) #| make it circular |# item) #| --> #1=(1 2 3 . #1#) |#
19:43:22
pjb
You can also use com.informatimago.common-lisp.cesarum.list:ensure-circular which does the same.
19:43:31
pjb
(com.informatimago.common-lisp.cesarum.list:ensure-circular (list 1 2 3)) #| --> #1=(1 2 3 . #1#) |#
20:44:39
puchacz
hi, can I loop :in many lists, but to the longest one, not the shortest, as by default please?
20:49:46
pjb
puchacz: (loop :for c1 := l1 :then (cdr c1) … :for cn := ln :then (cdr cn) :for e1 := (car c1) … :for en := (car en) :while (and c1 … cn) :do (something e1 … en))
20:53:09
pjb
(loop :for cs := (list l1 … ln) :then (mapcar (function cdr) cs) :for es := (mapcar (function car) ls) :while (some (function identity) cs) :do (apply (function something) es))
20:58:29
aeth
That might be the first time I've seen that be genuinely useful rather than just a question of ergonomics/style
21:02:33
pjb
otherwise, if cs contains list: ((a nil b) (c nil) (nil nil)) es will be (nil nil nil) the second time, and you'd stop there.
2:28:08
jsatk
Hi all. I'm new to Common Lisp. And I'm a vim user. I installed Quicklisp & Vlime (Slime-like plugin for vim). Whenever I start up my server via Vlime I get this strange error. http://i.jsatk.us/AH2bpp
2:49:10
sjl
That's "interesting". I use Vlime and don't get those warnings (well, I do get the emacs-inspect one, but that's fine). The warnings about undefined variables I wasn't seeing.
2:50:01
sjl
But I haven't updated my Quicklisp dist in a while. So I updated, and now I see those same errors.
2:50:04
p_l
first run of slime after update of either SBCL or SLIME always printed a bunch of warnings for me
2:50:30
sjl
Looking at the commit history, there was this on Feb 26 which "fixed" something for SBCL, but actually causes those warnings
2:51:13
sjl
Then there's this from Mar 1 https://github.com/usocket/usocket/commit/5c4c99568a49958adcab137516b6a05ced1a7fb6 which changed them back
2:51:46
sjl
But the version in the latest quicklisp dist is 0.8.1, not 0.8.1.1, so I guess the latest dist just missed getting that extra fix
2:52:06
sjl
Anyway, you can just ignore those errors. They won't affect you unless you try to run usocket's unit tests
3:47:26
beach
I found that writing papers for ELS takes 4 months per year. It is hard to concentrate on anything else for that time. First, figure out what to write about, then figure out how to write it. Then write it, fix it, submit it. Then modify according to the wishes of the referees. Then submit again. Then prepare the talk, make travel plans, buy tickets, reserve hotel rooms, travel.
3:48:21
beach
So I decided I have 8 months to think about design and coding, and I decided to work very hard to try to get an initial native version of SICL going before the end of that period.
3:51:12
beach
I have been kind of stymied with respect to changes in SICL and Cleavir because I now have a very important client (Clasp). So I finally decided to bite the bullet and "branch" Cleavir so that I can take care of some problems without disturbing the client(s). This decision turned out to be the right one.
3:55:32
equwal
Yeah, I recognise the difficulty of it. I remember you said you though nobody had done anything like SICL before. How is it different from other bootstrapping papers like the ones from this page of Lisp In Small Pieces? spensertruex.com/static/LiSP-bootstrappers.pdf
3:55:32
equwal
I know you compiled with the object first, and Clasp (a very influential project) now uses your compiler!
3:57:06
equwal
Is primarily that you used more modern stuff (since those are all pretty old papers)? Original or not, Clasp is a really big deal.
3:58:07
beach
For my bootstrapping talk, I figured out the main difficulty of building a Common Lisp system, compared to building ordinary "file-processing compilers", like a C++ compiler, for instance.
3:58:26
beach
The main difficulty is that a Common Lisp system does not contain just code to execute the way a C++ compiler does.
3:59:22
beach
A symbol contains a name and a package. A package contains a list of exported symbols.
4:00:54
beach
For Clasp, this is not so good because they have to create the discriminating function of more than 1000 generic functions at startup time and that takes many seconds.
4:01:46
beach
It is also possible to do something like Emacs does (or used to do, I haven't looked for some time), i.e. load up stuff and dump the current image as an executable.
4:02:24
beach
Image-based Common Lisp systems do that exclusively. They never start from source code. They modify an existing image and dump it.
4:03:14
beach
equwal: Yes, I think so. Unless it turns out that LLVM is a major performance bottleneck as has been hinted in the past.
4:03:21
equwal
My understanding of Clasp is that it is pretty nonperformant (I have never compiled it, I can't on my machine) despite it's purpose of scientific computing.
4:04:22
beach
But we have a long way to go with optimizing Cleavir, so that part will eventually no longer be a problem.
4:05:43
beach
Though, as long as Clasp is written in C++ and they can't dump the image, the startup time is not going to be great.
4:06:18
beach
As I recall, Clasp now has several compilers and several interpreters, for various aspects of the system, in order to get it fast enough.
4:27:45
p_l
beach: a significant issue that some people face with Clasp is that its compiler appears to over-eagerly inline functions
4:30:52
beach
p_l: And we currently have no decision procedure for determining WHETHER something should be inlined.
4:31:14
p_l
beach: also, I think it should be possible to generate discriminating functions and include them in "C++ image"
4:31:18
beach
It is entirely possible that the LLVM slowness is due to the fact that we submit HUGE functions to it.
4:31:48
beach
p_l: Bike has done some work on that as I recall. The limitations of C++ are very puzzling to me.
4:32:01
p_l
beach: it was definitely mentioned to me as an issue by one of the attendees I talked with, except for him it was making it too big to compile usable systems
4:33:13
p_l
beach: in practice, for normal OS, you have an external "image builder" which makes the image from different files
4:33:50
p_l
so I see no reason why it couldn't reuse ECL approach, or even create object files that would get relinked with main executable at some point
4:35:14
beach
I know it is possible in C to create a data structure in the executable. You just make top-level struct definitions and creations, linking them as appropriate.
4:37:08
p_l
I wonder if there might simply be an unholy mess at the crossroads of LLVM codegen, C++ runtime, GC, and Clasp's compiler which makes otherwise simple task into an attempt at unmaking spaghetti
4:37:51
beach
I wouldn't attempt anything like that myself, because I would never be able to sort it out.
4:38:39
beach
Luckily, drmeister has much more time and energy than I do to deal with issues like that.
4:39:29
beach
Bike has been working on inlining, but it has taken a long time just to make the mechanism work correctly, so he hasn't had time to think about the WHEN aspect of it.
4:40:59
beach
But, yeah, for SICL, I will definitely not depend on external software that I have to track. Especially not software written in C++.
4:41:48
beach
p_l: It has been proposed that I use LLVM (by several different people) and MPS (same), but I am not going to attempt that.
4:42:19
p_l
beach: an old idea of mine was to perhaps write a parser/writer for ELF objects and try to make SBCL use them as FASL format that is inherently memory-mappable
4:44:46
beach
I think it's the right decision, especially with respect to CLOSOS, because it would be nearly impossible to verify the safety of a FASL consisting of only executable code.
4:54:54
p_l
kinda want to be proven wrong on certain ideas (because it might be more interesting to be proven wrong than right)