freenode/#lisp - IRC Chatlog
Search
15:04:12
fe[nl]ix
jackdaniel: when do we get an ECL release ? I'd like to update the version used in cl-travis
15:45:13
jackdaniel
fe[nl]ix: best case in May (unless some unexpected stream of contributors appears)
15:51:53
New585
Hello, How can I know if I have aptitude for programming? Is it something which I can know?
15:52:59
New585
beach: So if i work hard i can be good at it? It doesn't matter if I am weak at maths or not a bright student?
15:53:25
beach
New585: I suggest you read a book entitled "Peak, secrets from the new science of expertise"
15:53:35
New585
stacksmith: I do enjoy it. Whenever I am able to solve a question I get a sense of satisfaction
15:54:07
malice
New585: Unfortunately, all of us have left our crystal balls at different dimensions, so we can't say for sure, but if you keep practicing, you will at least become decent, which is good enough.
15:54:30
stacksmith
Minimal math helps, but you can figure it out as you go. It makes more sense when you see why you need it.
18:49:19
scmlinux
Could someone please share a tutorial on the installation of CLSQL in GNU CLISP? Bonus points if it has simple examples of its usage too.
19:10:56
jackdaniel
random-nick: McCLIM ;-) see frequently asked questions here: https://common-lisp.net/project/mcclim/involve
19:13:58
stacksmith
scmlinux: SBCL is used by a good majority of Lisp programmers... Anecdotally ~80% of market share.
19:21:48
pjb
Too bad quicklisp download stats don't dispatch per implementation… This could be gathered easily by quicklisp…
20:18:28
fiveop
Hi, a question regarding FILE-LENGTH. The Hyperspec says "For a binary file, the length is measured in units of the element type of the stream".
20:24:00
comborico1611
scmlinux: I'm very new to Lisp, but I also would like to know of such a tutorial.
20:29:33
fiveop
it makes sense, because for variable length encodings you have to parse the whole file to determine its length, but why not mention that in the standard :/
20:37:10
aeth
stacksmith, pjb: Quicklisp doesn't have a tracking code built in for data or something, afaik. That's based on HTTP requests.
20:38:26
aeth
Or maybe a handful of people run a lot of SBCL servers that pull directly from Quicklisp?
20:39:18
aeth
SBCL is probably the most common by far, but I don't think that that blog post gives exact numbers.
23:02:03
pillton
shka_: alexandria:parse-ordinary-lambda-list does a lot of the work needed to do that task.
0:02:50
_death
unexpected mention of common lisp in https://blog.jessfraz.com/post/nerd-sniped-by-binfmt_misc/
1:24:30
dandruff
Would the Lisp Machine operating systems have been more portable and able to compete with Unix if they had been built around a Lisp that compiled to VM bytecode like Smalltalk?
1:45:03
caffe
the lisp machine processors don't actually understand lisp natively, it worked more in the sort of fashion you're describing
1:45:32
aeth
dandruff: The thing that killed Lisp Machines was, afaik, performance. The much cheaper commodity hardware eventually beat specialized hardware in Lisp performance.
1:48:18
aeth
krwq: Well, I tried implementing it. I decided it wasn't worth my time to continue along that path because of how hard it is, even compared to directly writing in assembly. It looks like dandruff's link takes a much easier approach. Modify an existing C compiler, and then simply write a Lisp interpreter.
1:49:54
aeth
It was very hard. Strings that aren't NUL-terminated (it's trivial when they are) probably would take a week to write. I never finished that part.
1:52:59
dandruff
caffe: right, I remember hearing that they were stack machines hardware support for bignums and GC. I can't find much on them, though. I haven't even been able to find if they used a monolithic kernel or something else entirely. I've been thinking about writing a Forth implementation in assembly with their features as a compilation target for Lisp Machine Lisp and looking for the source code.
2:09:34
stacksmith
I've spent a lot of time exploring ideas like that (and a few decades of writing Forth-like system for almost every imaginable platform)... It's one of those things like trying to build an interstellar spaceship... A couple of decades of technology will make yours obsolete every time.
2:10:53
stacksmith
Stack machines are dead - register architectures beat them every time. It almost made sense a couple of decades ago to make super-simple super-fast Forth machines, but a decent compiler on a mobile phone can outstrip them for an general purpose tasks.
2:11:45
dandruff
caffe: Isn't the spec similar to Common Lisp's? Yikes. Anyone can implement Scheme in a day at most; SBCL couldn't even have been built from the ground up.
2:14:08
dandruff
stacksmith: so that means that it would be impossible to make a reasonably performant system where a stack machine on an FPGA handles the compiled OS language and communicates with a normal CPU?
2:15:22
caffe
dandruff: i'm not sure i'd start from the ground up... more likely taking something like SBCL or GCL and building down
2:16:22
stacksmith
Chuck more has some gigahertz async stack machines, like a hundred of them, but they are so small that they are useless.
2:18:40
stacksmith
Yup. Check out Green Arrays. There is no clock, they run as fast as possible. Generally stack machines have a couple of dozen instructions, and his processors do them all simultaneously while the decoder is figuring out the opcode. Then the one you want gets the results latched.
2:19:57
stacksmith
But, Green Arrays is a couple of hundred async cpus with something like 256 bytes of ram each. Just loading code into them makes me want to go take a bath.
2:23:09
caffe
if you really want to 'compete' with linux... the best way is to not compete with it at all
2:24:45
pjb
caffe: well, not for CL, but for scheme. How many times did you use the scheke linux loadable module?
2:26:11
dandruff
If it's all embarrassingly parallel and they're an intermediary between an OS and the *real* hardware (some AMD or Intel chip), would the system still take a huge hit? pjb: Java is competitive with C, isn't it? Also, Android uses Linux IIRC. What I'd really like is something like Emacs all the way down with orthogonal persistence; I don't want to displace Linux.
2:26:24
aeth
There are two ways to do a LispOS. Bottom up and top down. By bottom up I mean start with the kernel and build your way up. By top down I mean start with user space applications and eventually replace intermediate components with Lisp equivalents.
2:26:44
aeth
Starting with LispM hardware isn't even really a viable option for a LispOS at the moment.
2:26:54
caffe
but honestly, i'd rather let linux kernel devs work for me than try to work against them myself