freenode/#lisp - IRC Chatlog
Search
8:49:41
beach
flip214: When a chunk is in use, there is no reserved word at the end of it. There is only one word at the beginning indicating the size. The rest is user data. That's why there is an additional bit in the following chunk that indicates whether the preceding one is in use or not.
8:51:41
beach
flip214: Allocating a chunk involves either finding a free one with the right size or splitting a bigger one. There is no need to mention both cases separately. They are both considered to be allocation.
8:54:05
beach
flip214: I am not updating the ARM specification right now because it contains incorrect information, and I will very likely eliminate it entirely and instead use ARM 64.
8:59:43
no-defun-allowed
i would have guessed for many CL names the authors avoided duplicate letters and vowel/consonant clusters
9:01:28
beach
flip214: I am not using "downward" or "upward" for the direction of stack growth, because the address space is usually drawn with 0 on top of the page. So a stack that grows toward smaller addresses grows downward when it comes to addresses and upward on the page.
9:01:56
beach
frodef: I created a #sicl channel to avoid polluting #lisp and #clasp with my own specific stuff.
9:03:16
beach
frodef: Your name (or rather that of Movitz) has come up a few times when there are people who come here and ask why there are no operating systems written in Common Lisp.
9:05:46
beach
Mezzano runs McCLIM and there is a translator from LLVM to Common Lisp, so that Mezzano can run some C programs.
9:06:58
no-defun-allowed
fitting on a floppy reminds me of native oberon and that was also a nice OS to hack with
9:08:01
no-defun-allowed
also if it still runs on i386 it can run on an old 1999 machine i have no better purpose for
9:08:49
beach
frodef: Would you like to help out with SICL and then CLOSOS (the name I have chosen for my planned Lisp OS).
9:10:44
beach
frodef: I am not planning to change the spec, but I am planning to modernize the code. I have a very modest plan to improve the spec. I call it WSCL (pronounce it Whistle) meaning Well Specified Common Lisp.
9:11:29
no-defun-allowed
that's quite cute if true, my parents named me after a lousy greek legend or something
9:11:30
beach
frodef: The purpose of WSCL is to specify many of the things that were left unspecified in the Common Lisp HyperSpec.
9:14:01
beach
If I had dpANS as a single LaTeX file that I could compile with `pdflatex', I would actually make some progress on WSCL, but it turns out not to be trivial to create such a file.
9:14:07
frodef
If you'll allow me some herecy, I think there are corners of CL that somewhat (too) rough.
9:17:53
frodef
I think it was one lesson learned from movitz, that staying true to CL incurred lots of work that also resulted in worse code.
9:30:36
frodef
p_l: nobody complains in other languages, because there it's like I'm proposing here :)
9:30:48
p_l
frodef: I'd like to see a keyword argument extending SUBSEQ with information on what to do in case of index going out of bounds
9:33:53
beach
frodef: I think it will be almost impossible to reach consensus on a change like that.
9:34:16
beach
frodef: And we are already very scattered as a community, so I am not going to try it.
9:36:20
jackdaniel
p_l: adding keyword argument as cdr extension -> non-conforming usage of said function which breaks code on implementations which don't implement it. way saner solution is to have a separate function for that
9:36:37
frodef
_death: two problems: substituting such basic operations rather hurts community-wide code readability, and also the performance hit is I think not insignificant.
9:37:29
p_l
and *FEATURES* should be used for detection... like they are used with code that works only on few implementations
9:37:35
frodef
beach: OTOH I suspect such warts (this is a small one) also hinders CL adoption. It really reeks of 1970's..
9:37:38
_death
frodef: well I wrote and used such functions more than once and this community of one has no trouble reading the code :).. also perf has not been an issue, because using subseq is a good indicator that you don't care for it
9:38:26
jackdaniel
well, having #+my-cdr(subseq …) #-my-cdr(subseq …) is hardly better than (cdr:subseq* …) ; (and it defeats whole purpose of the extension, you can't "just use it" to write portable code
9:39:20
p_l
jackdaniel: I was thinking more of having #-cdr-X (error "This code requires implementation supporting CDR-X)
9:40:10
jackdaniel
(especially for a functionality, which doesn't really require melding with the lisp implementation itself)
9:40:14
beach
frodef: I don't think fixing things like that will have a significant impact on Common Lisp adoption. There are much stronger psychological forces at work.
9:41:28
p_l
a much bigger issue for CL is universities using ancient crappy tutorials as part of some early courses
9:44:08
frodef
beach: Most people are pragmatic, I think... biggest obstacle I'd say is there are no particular reasons to adopt CL (except of course the beauty of parens etc. but pragmatic people don't care about such things.)
9:45:35
dim
a CL REPL integrated into vscode / atom / $EDITOR of the day would go a long way already, then a very easy way to consume “modern” APIs (http, json, etc), would be my guess
9:46:00
dim
make it so easy to scrap the web / use APIs interactively in CL than other solutions are looking cumbersome ;-)
9:46:01
beach
There are tons of reasons to adopt Common Lisp, but I don't think people have enough training, information, or psychological mindset to even consider doing it.
9:46:22
jackdaniel
hm, CL is being adapted by quite a few people. sure, it could be more popular, but I don't think that lack of people willing to use it is a problem
9:46:54
dim
beach: in my (limited) experience, most people (I've talked to) think of CL as a thing of the past, it was tried, it failed, move on
9:47:07
jackdaniel
(in fact, I don't think there is any problem, I don't have statistics but my impression is that CL mindshare is steadily growing since I've started using it)
9:47:43
p_l
beach: there's also "bad information", often from CS courses where you have a curious mix of LISP 1.5 and Scheme
9:47:46
dim
beach: well, what I'm saying is that you know they don't have enough information, but they are certain they do have enough of it.
9:48:45
dim
those people won't try to refresh the information they have, because they have no reason to, they won't make any effort when they know they don't need to, their knowledge is that CL is a funny piece of history, and dead.
9:49:33
frodef
p_l: my 3GHz, 2GB RAM, yet unbearably slow smartphone begs to agree on the performance thing.
9:50:08
beach
I think (and especially hope) that jackdaniel is right. I am convinced that the only way to fix this problem is to show that we can do great stuff with limited resources.
9:50:43
dim
my own personnal main difficulty with CL is experienced with pgloader each time I report a bug here: most of you guys try being helpful with advice about fixing the developer/run-time environment, but pgloader users know nothing about CL, they just use another /usr/bin/ tool in unix.
9:53:08
dim
and then the other side is that I get zero contributions on pgloader, because it's written in CL, even from people who are stuck and would hack away something written in Python, Perl, C or something they can relate to
9:53:40
frodef
p_l: yes, and bad programming results from bad programming systems (language, run-time, etc). Everything just gravitates to big balls of mud because one inevitably loses control and oversight.
9:53:50
dim
p_l: let's have more of us releasing /usr/bin tools to users who know nothing about CL and are happy to use the tool anyway?
9:55:23
dim
the problem I don't know how to solve, I feel like I'm the only one who needs to fix them anyway, and that doesn't help: loading the proper .so both at image build time and at run-time on a system you will never have access to, for instance, is one of my current big problems
9:56:09
dim
so yeah, we have problems to fix with CL if we want to see broader adoption, the model of the lone hacker being the hero of the interactive system is a great story, it can't be the only one
9:58:27
p_l
dim: you might need to write a function that attempts to find the canonical lib, in pure CL, then have it run before the code that will load the library
10:03:06
dim
https://github.com/dimitri/pgloader/issues/437 is interesting too, with many details and a solution at the OS level at the end
10:03:10
beach
frodef: What I think you would like in SICL: first-class global environments, bootstrapping CLOS first, using CLOS machinery for built-in classes fast generic dispatch, fast portable sequence functions, portable compiler, etc.
10:04:35
beach
frodef: How do you like this one, for instance: (defclass t () () (:metaclass built-in-class)?
10:05:39
dim
_death: I can't seem to think of another PL where loading openssl (or other .so) is such a problem as with CL
10:06:09
beach
frodef: The common part is compilation from CST to AST to HIR and them portable optimizations on HIR.
10:07:36
p_l
dim: openssl is a PITA everywhere, but people see it less because either the distro took care of it, or the program they are running bundled its own
10:11:15
frodef
p_l: yes, but I think that was basically an interface to openssl. I did have to fiddle a bit with some .so-files I seem to remember.
10:11:19
jackdaniel
dim: it would be useful, if you'd require also reporting openssl version in your ticket template
10:11:51
frodef
p_l: ..or I might misremember, perhaps it was something a bit further up in the webservice-stack.
10:12:57
_death
imagine choosing the path of cl-tls.. there will be problems, and to fix them would mean to fix cl-tls, which could benefit CL pretty good.. DLL hell is not unique to CL and its solutions require end-user participation
10:13:01
p_l
dim: Yeah, I know, just saying that while users are *usually* sheltered from it OpenSSL is a PITA that happens to many
10:13:58
dim
I would like to be able to bundle OpenSSL statically in SBCL and create a pgloader image with that
10:15:16
p_l
there are ready-made components, iirc, to use Bazel in a way that creates statically compiled SBCL with several libs you want
10:15:17
dim
as soon as you want to ship a /usr/bin tool, you stumble on FFI and run-time LD hell pretty quickly, really
10:15:21
Shinmera
Making a bearssl bindings lib is still on my todo, which would help this situation a lot
10:15:55
shrdlu68
dim: As far as I can tell, there are only two minor issues: 1. Implement OCSP stapling. 2. Use hashing to compare the CA cert sent with ones in local cert chain.
10:16:22
dim
another way to do it for me would be to use ABCL and provide pgloader.jar, so that the problem is on the JVM, and I think they use pure Java bits there ; I would use JDBC rather than the current drivers I am using, too
10:18:14
sixbitslacker
for some reason setting the trigger variable to be mode-local doesn't seem tow ork
10:18:42
sixbitslacker
they're generated by http://splode.com/~friedman/software/emacs-lisp/src/shop.el
10:25:55
beach
frodef: I am still working on the bootstrapping part. I am still working inside SBCL.
10:27:38
beach
shka_: Well, people keep distracting me with unrelated things. Like 2-3 trees for instance. :)
10:27:56
Shinmera
if you bundle shared libraries it's usually not a big problem. (the deploy system can help with that)
10:28:28
jackdaniel
beach: it's not that bad, imagine if someone had distracted you with 5 or 6 trees!
10:28:29
Shinmera
but always wanting to use system ones can be a hassle because of how many different places there are to look
10:29:06
Xach
I lumped them into the save-lisp-and-died binary, then pulled them out at runtime if needed.
10:29:41
Xach
It bloats the binary and requires write access on the target, but in some cases it could be workable.
10:30:19
p_l
AppImage is essentially a squashfs image wrapped in a program that mounts it on the end-users filesystem and runs
10:34:25
beach
v0|d: As a researcher, I am basically always working, because there are always some ideas in my head.
10:37:31
beach
frodef: The SICL specification is extensive, though not complete, and it contains some obsolete stuff. And there is the Cleavir documentation for the compiler. There are also quite a few ELS and ILC papers that concern SICL and Cleavir.
10:39:23
beach
frodef: Concrete Syntax Tree allows for source tracking, and it is in a separate repository. We also extracted the potentially-source-tracking reader as Eclector to a separate repository, now maintained (and used) by scymtym.
10:40:58
beach
v0|d: I don't believe in hard work (I don't think it's productive) so I try not to put too much pressure on myself. The past few days with progress on bootstrapping have been an exception to my rule.
10:47:45
beach
frodef: I started one too. Mine is the assembler with a difference. It doesn't have a surface syntax specified. It takes input in the form of a list of "instructions" which are standard objects that describe what should be done.
10:51:31
beach
The assembler basically works, but I need descriptions of many more instructions if it is going to be generally useful.
10:54:21
beach
Plus the Bologna system doesn't quite make it possible to use students as free labor.
10:59:07
frodef
beach: anyhow, my experience with movitz was that the standard-objects were just in the way, sexp syntax was more convenient and sometimes a requirement anyway.
11:00:32
beach
Anyway, it seems we are going different directions, so forget about my invitation to SICL and Cleavir. If you are right, it means I will hit the wall sometime in the future.
11:03:39
beach
so how do you like this one: (defclass symbol (...) ((symbol-name ...) (symbol-package ...)) (:metaclass built-in-class))?
11:10:14
frodef
beach: bootstrap in what sense? It's basicall all regular CL code that generates the bytes that make up a bootable x86 image.
11:12:22
beach
If so, does that mean that large parts of the system are written in some subset of Common Lisp like most existing Common Lisp implementations do?
11:12:27
frodef
beach: kind of I guess.. it's just another part of CL, implemented partly with "simpler" parts of CL and partly with.. well, inline assembly, I guess.
11:13:02
beach
I decided that for SICL, it was going to be too hard to maintain if I had to use a subset for some parts.
11:15:05
frodef
that doesn't quite suffice.. I assume you don't have e.g. (defun sort (&rest args) (apply 'sort args)) an dso on.._
11:17:24
beach
(defun car (x) (cond ((consp x) (cleavir-primop:car x)) ((null x) x) (t (error...))))
11:17:51
LdBeth
https://web.archive.org/web/20141209230003/http://cl-www.msi.co.jp/reports/wblcl.pdf
11:20:03
beach
frodef: One goal with SICL is to have excellent error messages and excellent debugging support.
11:22:17
frodef
seriously, unix's lack of dynamic error handling and debugging is what makes all software so shitty, I'm convinced.
11:39:46
jackdaniel
borodust: that link is actual attorney analysis about LGPL for Lisp (luckily conclusions are the same as mine) ↑
11:44:52
borodust
i'm gonna read full text, but conclusion still mentions LGPL doesn't cover some Lisp aspects (macros are specifically mentioned)
11:47:58
no-defun-allowed
Or, write in 64. It's self evaluating so it was evaluated before it even got to lisp.
11:48:37
jackdaniel
LdBeth: because software licenses are often about source code; macro is a way of transferring one code into another
11:49:02
jackdaniel
in this sense it is a compiler. borodust and in this light macros are results of calling library functions
11:49:42
jackdaniel
and even GPL doesn't cover resulting work of the application (i.e gcc doesn't relicense your binaries you build with it)
11:50:41
jackdaniel
jdz: if you bundle gcc with an application (and they are combined work), then indeed what you have is a derivative
13:32:23
shka_
for instance, here https://github.com/sirherrbatka/cl-data-structures/blob/8d7086fe1ca631b5287c9fb9c9a07013fa1302a9/src/common/rrb/common.lisp#L5
13:35:35
shka_
jackdaniel: 5 corresponds to 32 bits, if you want to switch to 64 bits, you can change it to 6, recompile and voila, it works
13:39:12
jackdaniel
maybe word cool mislead me into overthinking and trying to find any non-trivial usage of this operator
16:22:38
meepdeew
Does anyone know if (and if so, where) one can find electronic copies of either of the following books recommended in the preface of PAIP: (1) A Programmer's Guide to Common Lisp by Deborah G . Tatar, or (2) Common Lisp by Wade L. Hennessey.
16:23:50
phoe
meepdeew: they both concern CLtL1 as far as I understand, and no contemporary implementations I know are CLtL1 implementations
16:24:13
phoe
unless you have a very specialized need, I bet you'd be more interested in books about contemporary Common Lisp.
16:26:08
meepdeew
Ah, well then that's even better than an electronic copy, I suppose. The cover art of a person lounging on the beach on Hennessey's book had really drawn me in.
16:27:36
meepdeew
Thanks phoe. Before I proceed any further then, do you know if Common LISPcraft by Robert Wilensky or LISP (3rd edition) by Patrick H. Winston and Bertold Horn are also CLtL1 specific as well?
16:29:27
minion
meepdeew: please look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
16:29:31
minion
meepdeew: please see gentle: "Common Lisp: A Gentle Introduction to Symbolic Computation" is a smoother introduction to lisp programming. http://www.cs.cmu.edu/~dst/LispBook/
16:31:29
phoe
all in all, Portacle + PCL/Gentle is the beginner's toolkit that I'd suggest for the start.
16:36:36
meepdeew
That's the goal. I've read Gentle, and much of PCL. Was looking into starting PAIP as my next but saw Gentle at the top of Norvig's recommended intro books in the preface so I figured his list was worth checking out (thus the questions). Thanks for the input, I'll see which I prefer between CLRecipes and PAIP for my next. /end my noobing up of the #lisp channel
17:11:23
aeth
I'd go with Recipies. It was published too late for me, but reading through the book, it generally agrees with the consensus of this channel in most places. The main exception seems to be cl-fad instead of uiop iirc, but that's literally the book author's library so it's no surprise he prefers it.
18:38:41
flip214
beach: hmmm, I'm used to seeing address 0 at the bottom of the page. Never mind, though.