freenode/#lisp - IRC Chatlog
Search
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.