freenode/#lisp - IRC Chatlog
Search
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)
5:07:06
p_l
I'd be probably going for something closer to IBM AS/400 design, where safety is guaranteed partially by hw
5:12:19
beach
p_l: The only way to find out what won't work is to attempt it. At least for me. I am unable to think through a design completely without implementing it.
5:20:58
beach
p_l: With respect to Clasp, if it were up to me, I would have rewritten Cando in Common Lisp (including the libraries it uses) and just used an existing high-performance Common Lisp implementation like SBCL. It is several orders of magnitude simpler to implement an application than to create something as complex as a high-performance Common Lisp system.
5:20:59
beach
However, as I often remark, I am not good with strategic decisions like that, and I would have made the wrong one. The decision drmeister made has generated a huge amount of interest in Clasp by people unrelated to chemistry, simply because it can make Common Lisp and C++ work together. This decision has also attracted millions of dollars in grants, supported several graduate students and developers, etc. With me in charge, none of
5:23:30
loke`
beach: If the development of Clasp had been a strategic decision, I'm not sure it would have been taken.
5:23:40
beach
I know I am bad with this stuff, because I often think about what I would have done in Richard Stallman's position. I would have chosen Lisp as the basis for the free system. And that would have been the wrong strategic decision, because then Unix programmers would not have been attracted, and we would not have the body of free software that we do today.
5:23:51
loke`
Many huge projects started because the original developer didn't know that it was impossible. :-)
5:25:53
loke`
beach: True. But when the initial decisions were taken, I'm pretty sure drmeister didn't know the full scope of the work.
5:27:47
loke`
on a smaller scale... Would I have started making Climaxima if I had known that I would have to learn harfbuzz/freetype and implement a new font renderer, along with the copy&paste stuff, etc, etc? Unlikely. I would probably have targetted GTK+ or something instead.
5:28:58
p_l
as for Linus... he publicly stated that it was only his frustration with Minix and lack of availability of other useful OSes at acceptable prices (as a poor student with a 386)
5:29:28
loke`
p_l: right. and he also stated that he'd never expect it to be big and successful (“like Hurd” if I recall correctly)
5:30:36
loke`
So many developments happening due to random things happening by individual people in the past.
5:31:17
loke`
p_l: a lot of what he set out to do has come true. Of course, from his point of view it's not perfect (not enough GNU and too much BSD license)
5:32:57
p_l
loke`: probably didn't help that some of the projects where RMS was more visible had to take a long road to devolve themselves of RMS (and got better for it), and with how people view RMS and FSF as pretty much the same
5:34:38
p_l
beach: ehh, I remember a rather... militant? side around GPL in late 1990s (might be localized effect though), and I do feel disillusioned especially when more than once I caught FSF on FUD campaign :(
5:36:47
beach
I see, so you are one of the disillusioned people. I think we had better not discuss that here. It is off topic, and I am a member of the FSF, even though I don't follow everything they do in detail.
5:38:18
p_l
I dunno if it got disseminated further, but I've seen a fancy CLIM-based visualizer for Cleavir?
5:42:37
beach
To get back to Clasp, one of the main difficulties is that drmeister wanted Cleavir too early. My idea was to work pretty much alone on making the compiler generate good code. But Clasp has build-time and startup-time performance problems, which suggests the need to make the Cleavir compiler faster, as opposed to making it generate fast code.
5:43:25
beach
So there is currently this "conflict" between working on the code generated by the compiler, and working on the way the compiler generates its code.
5:44:11
beach
As it turns out, the latter often suggests special-purpose code, which I am allergic to, because it means a bigger maintenance burden.
5:45:30
beach
This is partly the reason I "branched" Cleavir. It is better to let Bike and karlosz work on the existing version and for me to work on a branch where I am not concerned with the execution time of the compiler itself, at least not for now.