freenode/#lisp - IRC Chatlog
Search
18:23:14
drmeister
makomo: Thank you - I encountered those incongruent lambda lists in some code from someone that I trust and I know that it is accepted in sbcl. I couldn't believe that clasp/ecl determined correctly that the lambda lists were correct and that the author and sbcl were incorrect.
18:35:34
drmeister
s/I couldn't believe that clasp/ecl determined correctly that the lambda lists were correct and that the author and sbcl were incorrect./I couldn't believe that clasp/ecl determined correctly that the lambda lists were INCONGRUENT and that the author and sbcl were incorrect./
19:28:51
phoe
generally there's always a newline in the DEFUN form after you finish typing the arguments
19:29:18
zhlyg
I *think* you should add tuple :if-does-not-exist :create to your with-open-file form (I'm cargo culting from PCL).
19:34:11
phoe
when you're opening the file for input, you likely don't want to supersede it if it exists
19:34:15
jmercouris
are there any VIM plugins for proper indentation? I belive steve losh is also a vim usr
19:35:18
j`ey
zhlyg: wouldnt I still need to get the different bytes out of the value into a sequence?
19:35:56
jmercouris
well, ':input will just evaluate to :input, not sure why you would do one over the other
19:36:40
pjb
jmercouris: a bad compiler could generate better code for ':input than :input. But it would need to be very bad.
19:37:10
pjb
jmercouris: it can never be different (unless the implementation allow for non-conforming setting of the keyword value)
19:38:00
pjb
But of course, this is only when they'er evaluated. If not, then there's a big difference: (quote (:foo ':foo)) #| --> (:foo ':foo) |# doesn't contain two symbols!
19:41:31
zhlyg
j`ey: scratch my idea of using write-sequence, it won't work because you are building an little-endian integer.
19:42:02
pjb
j`ey: a displaced array is an array whose elements are actually stored in another array.
19:43:06
pjb
and similarly, read-sequence, once you've read the dimensions and initialized the multidimensional array.
19:43:51
j`ey
now im confused. why am I doing all this byte stuff if write-sequence and read-sequence can write out an array?
19:46:33
pjb
j`ey: ah, well, this is not an array of bytes, so you still need to convert the elements into sequences of bytes (if you want to write your file portably).
20:03:14
pjb
(loop :for i :below (reduce (function *) (array-dimensions a)) :do (write-sequence (element-to-byte-sequence (row-major-aref a i)) stream))
20:05:29
pjb
(loop :with buffer (make-array +size-of-serialized-element+ :element-type '(unsigned-byte 8)) :for i :below (reduce (function *) (array-dimensions a)) :while (= +size-of-serialized-element+ (read-sequence buffer stream)) :do (setf (row-major-aref a i) (element-from-byte-sequence buffer)))
20:12:03
aeth
pjb: Yeah, I'm just saying when everyone's reaction is to go to the documentation maybe a simpler form is better
20:17:14
pjb
j`ey: didn't tell you that you should never use a literal value directly in the code? Instead, define a constant!
20:18:03
pjb
(eval-when (:compile-toplevel :load-toplevel :execute) (defconstant +byte-size+ 8)) and then :element-type `(unsigned-byte ,+byte-size+) and (logand (1- (expt 2 +byte-size)) ...)
20:20:33
pjb
But seriously, given the cost of studies, and the final results, I can't wait to see a suit asking refund.
20:20:51
aeth
pjb: Personally, I wouldn't use a constant for something like that, I'd use a *macro*.
20:22:04
pjb
You can also start with (deftype octet () `(unsigned-byte 8)) and use that type in :element-type everywhere…
20:22:29
aeth
https://gitlab.com/zombie-raptor/zombie-raptor/blob/5135a3ca53351660aa6482c18a1044afa04d5b9e/util/types.lisp
20:26:30
pjb
Then, there remains all the little monasteries and abbey where copist had libraries of volumes.
20:33:15
j`ey
in the CLHS it shows you can (map 'string..), with characters, is there a simple way to do it but with a list of strings?
20:36:37
aeth
I think you could probably do it with a mapfoo (probably not map) but it would be functionally equivalent to the reduce, but more verbose.
20:38:49
aeth
It doesn't look like my version of SBCL has a fast route for string concatenation when the types are known. i.e. this won't speed up your reduce (it will slow it down slightly, to check the types of x and y): (defun concatenate-string (x y) (declare (string x y)) (concatenate 'string x y))
20:40:42
aeth
j`ey: That will turn it into (concatenate 'string a b c d e ...) where "a b c d e ..." are elements of the list. It might be slower or faster. It's limited to call-arguments-limit
21:40:13
pfdietz
It might be nice if SBCL images could make the standard part shareable between different images, like libraries. Or is that the case already?
21:47:36
slyrus1
pfdietz: I agree. It might already be a thing, but, without thinking about it too deeply, something like dougk's shrinkwrapped binaries linked against a common libsbcl would be awesome.
21:52:49
slyrus1
Then again I'm busy downloading a 17MB string handling R package as some chained dependency so clearly nobody cares about package size anymore...
22:04:15
pfdietz
../../include/clasp/asttooling/astVisitor.h:30:10: fatal error: 'clang/AST/RecursiveASTVisitor.h' file not found
22:04:37
Colleen
Unknown command. Possible matches: 8, roll, clhs, set, say, mop, get, login, block, time,
22:06:12
oni-on-ion
who me? Colleen was mentioned here just earlier, thats where i first heard the name. i searched CL irc bot and got the same name, these reasons are why i say hi to her.
22:15:03
oni-on-ion
julia, colleen, ruby .. lady names are easy to remember, and at least partially altruistic =)
22:26:12
vsync
women do tend to score higher in extraversion, agreeableness, and conscientiousness, sure, but I prefer to keep the focus mainly on the individual
22:41:10
oni-on-ion
vsync: i mean for man to treat a lady. software and computers like we call the cars we work on "our baby"
22:44:24
oni-on-ion
Shinmera: broken link on colleen README.md - points to http://plaster.tymoon.eu/view/5A
23:00:58
Colleen
Shinmera: drmeister said 6 hours, 23 minutes ago: You used (:local-nicknames (#:cst #:concrete-syntax-tree))
23:00:58
Colleen
Shinmera: drmeister said 6 hours, 23 minutes ago: https://github.com/quicklisp/quicklisp-client/blob/master/dists/quicklisp/software/staple-20180711-git/parser/package.lisp#L11
23:00:58
Colleen
Shinmera: drmeister said 6 hours, 22 minutes ago: That last link won't work of course: https://github.com/Shinmera/staple/blob/master/parser/package.lisp#L11
23:00:58
Colleen
Shinmera: drmeister said 5 hours, 7 minutes ago: In staple here https://github.com/Shinmera/staple/blob/master/inference.lisp#L43 you use the symbol definition:declaration - that is only defined for sbcl.lisp in the definitions system.
23:00:58
Colleen
Shinmera: drmeister said 4 hours, 33 minutes ago: There are some incongruent lambda lists in staple. https://github.com/quicklisp/quicklisp-client/blob/master/local-projects/staple/page.lisp#L30 the methods look like they need to have &allow-other-keys added to them.
23:11:46
pfdietz
Even ignoring GFs, it could make sense to do that with ordinary functions, since you can pass keyword parameters if you include a :allow-other-keys t pair of arguments.
23:14:01
Shinmera
We're specifically talking about (defgeneric f (a &key b &allow-other-keys)) (defmethod f (a &key))
23:16:54
Shinmera
drmeister: the sbcl-isms in staple should be fixed now. (except for the local nicknames)
23:18:37
drmeister
It means when you are in a particular package - that certain additional nicknames are available.
23:19:28
Shinmera
adding a local-nickname table to the package object and making intern look there when it searches for symbols
23:20:22
pfdietz
The various standard functions that take packages are arguments may have to be modified, as well as the reader and the printer.
23:21:45
Shinmera
right. there's also a protocol to query the system, if you want to be fully compatible with onther implementations
23:23:27
pfdietz
I've been thinking there should also be "standard" local nicknames for a package, and a way to say "use that package's standard local nicknames inside this package". The standard local nicknames could collide, but if they do it's immediately detectable and you just manually specify a different one for one of the colliding packages.
23:44:43
oni-on-ion
Shinmera: oh!! alright. it was the first search result and i've come across it before, and seen her here in chan.
23:51:47
oni-on-ion
in framework? could be a good thing. i've got some wierd big ideas for something; ive had a couple game servers that had irc integration for eg.
0:09:57
oni-on-ion
yeh but its possible to accomplish in other ways surely. dang tho, its not a good solution ?
0:10:51
AeroNotix
oni-on-ion: no no I meant "dang I didn't realise export was a function on its own"
0:32:31
oni-on-ion
(loop for value being the hash-values of (irc:users *con*) using (hash-key key) do (print value)) ;; holy moses....!
0:39:11
oni-on-ion
putting it in #lispgames because i want to generate some amusing fake titles among other useful bits of musery
0:50:23
commanderkeen
it's been a long time since i've touched common lisp. how do i access a variable defined via defvar from another package? say im package :stumpwm and I want to access *servers* in :swank. my initial thought was swank:*servers* but that doesnt work
0:54:46
AeroNotix
commanderkeen: but that's because it's not exported. Single colon works when the symbol is exported from the package.
0:55:11
AeroNotix
Double is for accessing unexported package symbols. Not recommended to build software around relying on unexported symbols.
0:56:26
commanderkeen
AeroNotix: thanks for the info. i was just reading up on the difference. i just wanted get running swank servers from my window manager.
0:56:29
no-defun-allowed
aeth: `(maphash (lambda (k v) (declare (ignore k)) (print v)) (irc:users *con*))`
0:56:50
Shinmera
oni-on-ion: I created it because I wanted a general framework for chat systems, and that's what it is.
1:04:23
saturn2
it no longer compiles with the latest sbcl and i wonder if they still want to maintain it or if i should try to figure it out
1:08:21
oni-on-ion
Shinmera: alright, just curious, it looks awesome. i will try to get it to connect later, playing with cl-irc right now
1:13:06
oni-on-ion
ie. a privmsg hook added, then change the hook , still uses the "old" one. maybe there is a priority for "compiled" code? i've been using C-c C-c in slime and i think its doing something different than my usual C-x e
1:17:14
AeroNotix
rove has some fancy pants symbols showing test success/failure (tick/cross) which sb-cover chokes on
1:22:35
AeroNotix
rove has some unicode chars within its source. It seemed sb-cover was choking on those
1:23:01
AeroNotix
hmm, I remvoed them from the rove source (to test), sb-cover worked, I've since replaced them and now it's not failing in the exact same way
1:34:13
AeroNotix
anyway, looks like you can pass :external-format to sb-cover:report any way. That might help if I can see why it's not failing again
1:40:53
AeroNotix
Ugh, is there a better coverage system than sb-cover then? Now I'm running in to a different issue.
1:41:13
AeroNotix
It's spitting out weird warnings about lisp files it can't find but their names are lists of numbers like (3 3 3 2 2 1 2 3)
1:41:27
AeroNotix
1) in file /home/xeno/.quicklisp/dists/quicklisp/software/portable-threads-20180131-git/portable-threads.lisp
1:42:41
AeroNotix
yeah, deleting the fasls, recompiling without sb-coverage enabled removes those warnings
1:48:11
saturn2
on further investigation it wasn't city-hash's fault but a different package, nibbles, and updating that fixed things
1:59:06
AeroNotix
oni-on-ion: runs your code (e.g. your test suite) and outputs a set of files which highlight what parts of the code were actually ran. Helps figure out what code is left untested.
2:51:36
AeroNotix
oni-on-ion: it shows in green what was ran, yellow where only one branch in a conditional was taken e.g. (if (some-predicate) (foo) (bar))
2:53:01
AeroNotix
It looks like it doesn't deal with how WHEN expands (always leading it to be yellow)
2:55:00
no-defun-allowed
re a previous discussion on generational hypothesis: i read the gc handbook and it says older objects are often less mutated
2:55:26
no-defun-allowed
still a remembered inter-gen set is necessary otherwise i'd be pulling a lot of data to keep no old->new pointers
2:58:54
AeroNotix
johnjay: there's some metrics somewhere on the quicklisp blog about downloads by implementation. SBCL was far and away the most widely used implementation, at least as far as using quicklisp
3:00:36
no-defun-allowed
yeah emacs isn't a great lisp for general purpose computing but it's certainly the most used
3:02:21
aeth
Emacs Lisp is essentially a time capsule of an old pre-CL Lisp with some things ported from CL much later on
3:05:00
oni-on-ion
no-defun-allowed: https://github.com/emacs-mirror/emacs/blob/master/etc/NEWS#L897
3:05:42
aeth
johnjay: I don't really like Emacs, though. I like its concept of being programmable in a Lisp and I like its key bindings.
3:06:26
aeth
I think pretty much every other editor is worse than GNU Emacs, especially for Common Lisp programming, but that doesn't make Emacs Lisp a good editor.
3:07:29
aeth
Look at GNU Emacs new? I'd be looking at about 4 years before being comfortable in it. I can understand why people try to avoid it.
3:08:08
aeth
If anything needs an interactive gamified tutorial, it's GNU Emacs, but it can't because it's not capable enough.
3:08:46
aeth
oni-on-ion: What editors are available? Especially years ago. ed, nano, vim, emacs, gedit, kate, etc.
3:08:52
oni-on-ion
i've been using it since hmm 1994 i guess, didnt really truly grasp as much as i do in the last couple years. (i took a hiatus from comp/tech before that)
3:09:07
aeth
Of these Unix editors, emacs might be the only editor that's both graphical and terminal-based.
3:22:13
no-defun-allowed
it runs on i386 with no GC and there's a commodore 64 fork which has a faulty GC
3:22:34
johnjay
https://www.reddit.com/r/lisp/comments/5zbmwo/lisp_os_is_mezzano_the_closest_to_being_a_modern/
3:24:57
no-defun-allowed
oni-on-ion: which requires serialisation and deserialisation. a real lispos could pass a pointer quite easily
3:27:05
ym
The only thing which stops me from implementing/porting LISP OS is Altera's proprietary bitstream format.
3:27:19
Oladon
johnjay: I don't think beach was actually suggesting that you never wonder again, just that you don't wonder about that specific item anymore.
3:29:25
aeth
A Linux distro is just something with its own package repositories, possibly with its own package manager, too. (Most just use an existing one with custom repos, though.)
3:29:28
oni-on-ion
well i need to know because i was designing a pretend computer using a count of 22 for something
3:29:39
no-defun-allowed
here's some names you might be able to complain to: Thomas F Knight Jr, David Moon, Jack Holloway and Guy L Steele Jr
3:30:44
aeth
I've been using Fedora since 2006. I stopped even trying out other distros in VMs probably 6 years ago.
3:30:46
no-defun-allowed
iirc there's a J1 fpga processor which runs forth. add some tags and clean up the function stack and you're halfway to a lispm
3:31:46
ym
The original CADR was highly constrained with technical capabilities of that time. One can expand it any way.
3:32:08
no-defun-allowed
i'd have a go at trying replace-string 22 32 but it might not work like that
3:33:28
aeth
But GNU is politically opposed to "nonfree software" so you won't be able to easily run things like Steam on it. Well, you might be able to get around that with the Steam Flatpak. Drivers will be trickier. I guess you'd need to use an AMD GPU.
3:34:25
aeth
Most people have some proprietary software that they want to run. That's one of the advantages of a "LispOS" running Android-style on top of the Linux kernel
3:35:23
no-defun-allowed
according to the doc, the cadr machine is hardware to run lispm firmware but i say the cadr machine is a lisp machine
3:35:27
aeth
Note that copyfarleft's added restrictions would make it neither open source nor free software
3:36:15
oni-on-ion
no-defun-allowed: ok. says here that cadr machine is the microprocessor, and lisp machine is cadr machine plus microcode to interpret
3:37:15
no-defun-allowed
in other words: 3d print the keycaps and make your own hall effect switches
3:41:22
aeth
If you wanted to make a LispOS on top of the Linux kernel you would need: (1) a package manager, (2) a terminal emulator, (3) a posix shell, (4) a Lisp shell, (5) a text editor, (6) a file manager (not everything is convenient in the terminal)
3:42:04
aeth
stumpwm isn't very convenient on laptops, though, because there it's nice to have a bar for wifi/battery/volume/brightness
3:42:05
johnjay
aeth: i thought i could see how to do a terminal emulator by looking at xfce-terminal's code. but it refers to vte which does the actual term emulation
3:42:50
aeth
johnjay: most things in the C world are so hard that they just use libraries to do all of the real work
3:43:02
no-defun-allowed
i broke the emulator and it's telling me someone can't use the elevator to get to the ninth floor
3:43:13
johnjay
would there be architectural or performance differences between a LispOS on a linux and something like mezzano, that's lisp all the way down?
3:43:18
aeth
e.g. there's like two libraries that do font rendering and they share a common core iirc
3:45:00
aeth
johnjay: With Lisp on Linux you have a decision to make fairly early on. Do you put everything in one Lisp image or do you accept having 10x the memory use of the equivalent C application by running one Lisp image per thing?
3:45:43
oni-on-ion
ah nice. get wayland going on a bare linux kernel, emacs loaded with exwm and slime connected to system, use eshell and yea
3:47:11
aeth
I wouldn't recommend making your own CPU, though. If that's your concern, just use RISC V.
3:48:38
no-defun-allowed
it's not lisp all the way down and the "lisp machine" abstraction would end when the kernel starts
3:48:46
beach
johnjay: This document http://metamodular.com/lispos.pdf is not about Mezzano, but it explains how different a Lisp OS could be.
3:49:02
aeth
CPUs have a network effect. That's one of the reasons why Lisp on x86 quickly was faster than Lisp on LispMs even though 32 bits isn't really enough for Lisp imo (36-bit is good because of tags)
3:49:42
aeth
Even if you wanted 100% FOSH, RISC V will be faster and more feature complete than what you can design and make
3:50:52
aeth
oni-on-ion: you don't want a lot of logic in the microcode (or the circuits or whatever)
3:51:07
aeth
oni-on-ion: Optimizing compilers on general purpose hardware is generally the way to go.
3:51:41
aeth
Besides, people aren't going to update their hardware every 2 years these days, so updates will come much faster for software.
3:52:45
aeth
oni-on-ion: You are probably not going to beat the performance of SBCL on x86-64 ever. It will optimize faster than you can with your Lisp-on-a-chip.
3:53:40
aeth
(i.e. by the time you get to the level of performance SBCL is now, SBCL will have had dozens of revisions and x86-64 will get its annual 10% improvements)
3:55:17
aeth
oni-on-ion: A Lisp on a GPU would be really fast at things like MAP, but not in general
3:56:13
kristof
for all the ugly architectures we've had and all the good ones in the dust bin (I think SPARC is beautiful), mass producing intel chips has resulted in a computing power explosion
3:56:34
kristof
that people rarely appreciate in the same way as if there house suddenly doubled in size every two months
4:02:17
oni-on-ion
my phone is faster and way better gfx than my desktop and tablet probably combined
4:02:36
kristof
https://upload.wikimedia.org/wikipedia/commons/thumb/9/9d/Moore%27s_Law_Transistor_Count_1971-2016.png/1200px-Moore%27s_Law_Transistor_Count_1971-2016.png
4:03:17
aeth
kristof: Transistor count used to translate into single-threaded performance. Now we're at the point where that's essentially false
4:03:42
aeth
Single-threaded performance is still going up a bit, but mostly due to cleverness (of the kind that causes Spectre/Meltdown)
4:05:06
johnjay
aeth: the concept of process was just designed for computers with small memory/addressing?
4:05:10
aeth
I suspect what we'll see is consumer CPU core counts dramatically increasing until that also hits a wall. (I wonder where that wall will be. 128? more?)
4:07:35
beach
johnjay: Pretty much. In some cases (like Unix), it was meant to emulate the raw machine so that old technology could be used for compilers and linkers.
4:07:41
oni-on-ion
typing in little letters with our fingers and it explodes into essentially a heaven of information and entertainment and complexity and discovery, the computers multiply those key presses ...
4:08:43
ym
I can't see a heaven. I can see overthinked specifications and constant reimplementations.
4:09:01
johnjay
beach: i feel like im learning more in the last 5 minutes than 5 years of programming (!)
4:09:10
beach
johnjay: Now, if you look at the OS literature, it is often presented as a security thing. It is true that running programs in separate address spaces gives a certain degree of security.
4:09:38
beach
johnjay: Though, attacks like overwriting the return address on the stack are hard to prevent.
4:10:25
beach
johnjay: Plus, there is a case of turning the implication arrow the wrong way. Security can be obtained with other means than processes, and processes are definitely overkill in other respects.
4:10:56
beach
johnjay: In order to communicate between programs, you can't just pass a pointer. You have to serialize and unserialize everything.
4:11:53
beach
johnjay: I know what you mean. #lisp has some smart and knowledgeable people, so people who have not come here before often learn a lot.
4:15:25
johnjay
ah ok. i think that's some kind of security flaw or something. link to a document with you real name.
4:16:15
johnjay
beach: just a little joke there. i was able to figure out you wrote the document from the way you spoke about it
4:16:57
beach
johnjay: Lots of #lisp participants know each other quite well. We meet every year at ELS.
4:17:03
kristof
Although I also like the idea of sandboxing code that might use raw addresses like C programs.
4:17:35
AeroNotix
kristof: ah, it's not referenced in the sections talking about the issues with a single address space
4:17:36
beach
johnjay: I don't think froggey has the same considerations with Mezzano as I have in that document.
4:17:55
johnjay
i haven't heard of mezzano before today but it appears to be all lisp. a lot of it is lisp that is emitting machine code though. -_-
4:19:10
aeth
johnjay: What Lispers generally do is they put things in s-expressions and then turn that into the desired output. You see this with asm, HTML, XML, JSON, CSS, JavaScript, GLSL, SQL, etc.
4:19:52
kristof
AeroNotix: Really? You think incorrect permission bits are a valid concern even though it's the equivalent of bugs in a UNIX kernel?
4:21:40
AeroNotix
Suit yourself. Not sure if you're offended by something I've said or done in the past. If so, just let me know in PM or whatever. Wouldn't like there to be beef
4:22:37
AeroNotix
read/writing it. I'd love to see an explanation of how concurrency is supposed to work in a system like this
4:22:43
beach
AeroNotix: I am not offended. Just tired of repeating the same arguments over and over again, even though they are all spelled out in the document and in the OS literature.
4:23:35
kristof
AeroNotix: You were right about glossing over the essay since there was an entire section on concurrency.
4:24:35
beach
johnjay: Generally, #lisp will recommend PCL to people who already know some programming.
4:25:19
AeroNotix
kristof: dealing with concurrency issues within a single program, with threads and locks is already tedious and requires careful testing. Imagine that being multiplied by additional external processes, some of whose code you may not be in control of.
4:25:22
no-defun-allowed
it's the only one i have in hard copy (cause it was only $30, compared to SICP's $100)
4:25:30
kristof
johnjay: You will be surprised to learn that Common Lisp has *more* "good" books than most other programming languages do. Combined, eevn.
4:25:31
beach
johnjay: Practical Common Lisp, PAIP, On Lisp, OO programming in Common Lisp, Common Lisp recipes, etc, etc.
4:26:18
kristof
The past four (!) decades has produced an amazingly large amount of good books written in lisp.
4:26:32
AeroNotix
kristof: it sounds like a good use-case of this single address space could be something akin to "plugins". You write code that plugs into a separate code base to read/write it's internal datastructures. Are the locks administered by the programmer writing the code which shares these pointers around?
4:26:58
aeth
johnjay: I'd recommend The Little Schemer before SICP. It's a simpler book. Yes, both are Scheme, but most of the concepts do translate. Both are probably the most relevant books written in Scheme for a CL programmer. The main thing you want to keep in mind if you're coming from Scheme is that tail recursion cannot be relied upon to be optimized in CL.
4:27:35
aeth
(Okay, I've heard that another relevant Scheme book for a Lisper is Lisp in Small Pieces, but that's an advanced book for writing language implementations)
4:28:55
no-defun-allowed
while waiting for the book to arrive, one played the song over microphone in every game we'd play so he probably liked it
4:29:30
kristof
AeroNotix: I don't want to sound dismissive but this sounds like an easy problem to me. The first observation is that Lisp is strongly typed, meaning you can only operate mutably on data structures using the correct accessing functions.
4:30:15
AeroNotix
kristof: sure, it's easy to create the tools to implement safe guards. Using them correctly however, is another matter.
4:30:39
kristof
The second is that "concurrent access" is well within the realm of a capability, right? So the underlying system can very easily make accesses guarded by lock granularity etc.
4:30:45
AeroNotix
and adding another vector to use them incorrectly surely warrants a fresh look on what kind of safe guards are needed
4:31:28
johnjay
beach: thanks for the recommendations. it would be cool if i could learn enough to work on that mezzano thing. it looks amazing
4:32:27
kristof
AeroNotix: Well, the Lisp philosophy is that you should give people the tools to do things the right way, and you shouldn't worry about an imaginary person that is intent on doing them the wrong way.
4:32:43
kristof
AeroNotix I already know that you know that but I think the reminder here is appropriate
4:32:53
AeroNotix
kristof: it's not like a single address space is a thing unique feature only a LispOS could provide.
4:33:41
no-defun-allowed
this idiot called John Quest is supposed to be finding correlations between internet usage and fertility rates and also needs a bunch of other crap for some reason
4:33:41
kristof
if you get rid of the arbitrary process boundary? I am willing to make that tradeoff.
4:33:53
johnjay
aeth: i'm wondering how hard it is to write a driver for say fat32 or intel HD audio bus. mezzano already has both of those
4:34:12
AeroNotix
kristof: even then it's essentially saving on the serialization/deserialization of requests to improve execution times?
4:34:33
beach
AeroNotix: Correct. The document in question does not introduce anything new. All of what is described there has been used in the past, tested, verified, etc. That is why it makes me so tired to have to explain it over and over again.
4:34:59
kristof
AeroNotix: It's worse than that. Making byte boundaries the common interface is like making your programming language only accept strings.
4:35:28
aeth
AeroNotix: There's "LispOS" as in an OS written in Lisp and "LispOS" as in a proposal for what such an OS could look like.
4:36:07
AeroNotix
aeth: Sure, I just LispOS as a shorthand for a general set of operating systems like this
4:38:13
aeth
AeroNotix: Personally, if I made an OS in Lisp I'd make it POSIX compatible and port a C compiler as one of the first steps (probably would actually need to port both GCC and LLVM these days). I'm sure everyone has their own design in mind.
4:38:41
AeroNotix
aeth: all I'd care about is whether or not the guts of the system used a non tedious language like C
4:38:42
aeth
(My reasoning is pretty simple, I don't think anyone would run a desktop OS without a web browser, and it's probably easier to port Firefox than to write one.)
4:38:47
kristof
AeroNotix: Sending everything in JSON helps, but how do I make thread B modify thread A's data structures using JSON?
4:39:32
AeroNotix
kristof: in a single address space how do you make thread B modify thread A's data structure in a way that won't cause it to crash?
4:39:35
aeth
no-defun-allowed: You need to build a layer that C can talk to. The only difference is that the C layer wouldn't be the bottom layer.
4:40:12
kristof
AeroNotix: That's a weird question. People let threads modify other thread's datastructures all the time: using well defined interfaces and shared type definitions.
4:40:27
aeth
Interestingly, I think this means that SBCL would also be able to be ported to the OS and SBCL might (okay, it will) outperform the host CL. That would be a bit awkward.
4:40:50
beach
AeroNotix: It won't crash, but you might get error messages. If the programmer writes incorrect code, there is nothing I can do about it.
4:41:51
AeroNotix
kristof: beach: I understand how the situations are similar. Intefaces must be used to guarantee safety/correctness in both cases, but in a single address space it has the difference of more "spooky action at a distance" type behaviours that multithreaded programs are prone to
4:42:17
johnjay
beach: would it be relatively straight forward to write a parser in lisp for C header files?
4:42:38
beach
AeroNotix: You must be thinking of multi-threaded programs where the threads all share the same raw address space.
4:44:09
johnjay
my particular use case is i have a giant .h file that seems to be wrapped in one giant #ifdef ... else .. #endif
4:44:44
kristof
AeroNotix: I think there's something you might not be getting. The proposal is not "take our existing most-minimal, obvious operating system, and add all this flexibility to it that I might not need." There is not very much about UNIX that is obvious, like first principles or something.
4:44:59
no-defun-allowed
i'm sure you can "break" the syntax of C so that it's very different with different defines
4:45:57
johnjay
no-defun-allowed: i thought of something like that. like add 1 to an variable if a new #ifdef appears and subtract one when #endif appears. something like that.
4:46:52
AeroNotix
kristof: I'll print out beach's paper and read it once more, then. Please don't get the idea I'm just shitting all over it from superior understanding. I just hear something like "single address space" and try to think how I would use it and how it could be misused.
4:47:16
kristof
UNIX already imposes a baseline that all other users must adhere to. Dynamic linking must include symbol tables with offsets into machine code, for instance. Executables accept an array of c-string arguments. Etc.
4:48:41
no-defun-allowed
is it a microkernel if all your drivers are in functions which can be compiled quickly and can't execute dangerous code?
4:49:16
no-defun-allowed
AeroNotix: i think the idea was that all the concepts have been implemented before.
4:52:09
AeroNotix
https://github.com/robert-strandh/SICL/blob/master/Ideas/package-extensions.text#L4-L8 <- always thought about thi
4:52:11
kristof
AeroNotix: Some propositions that necessitate a paradigm shift: maybe operating system data should be strongly typed, i.e. it is not an interpretable set of bytes but rather a computational object in its own right
4:52:48
oni-on-ion
hehe i wrote a little squeak plugin for 3d gfx engine tests and some basic multiplayer demo
4:52:50
AeroNotix
kristof: at some point it must be an interpretable set of bytes. Somewhere on the machine
4:53:24
kristof
AeroNotix: This is as true as "at some point you must write to memory mapped hardware"
4:54:05
kristof
AeroNotix: There shouldn't be one programming language, but maybe processes, or threads, or applications, or whatever should be able to freely share data with one another, and
4:54:58
kristof
rather than the operating system catering to the *lowest* common denominator (C), it should cater to the highest common denominator, a strongly typed language with a garbage collector and whose objects carry their type information with them
4:56:05
kristof
Common Lisp is an extraordinarily good language in this regard. You can get dynamic duck typed languages pretty easily (like Javascript, using a-lists or association vectors of symbols) and you can still share data with statically typed languages
4:56:33
kristof
which simply don't need to do the same type checks that Lisp does. The representation doesn't need to change at all between F# and Lisp.
4:57:08
kristof
These Common Language Runtimes have been proposed for decades because they're really good ideas.
4:57:32
aeth
kristof: Why shouldn't there be one programming language? I'd imagine that in such an environment everything would compile to CL
4:58:23
kristof
Even Symbolics Genera supported at least two different programming languages (Lisp Machine Lisp and Common Lisp)
4:59:32
kristof
I think one of Guy Steele's most important contributions was getting people to understand that there are two things that people confuse: programs, which are abstract, mathematical constructs that "compute", and the languages we use to describe them
5:00:22
kristof
What I'm saying by proposing that the operating system should have a baseline high level language is more like saying that everyone can write whatever programming language they want to target a system that has the denotational semantics of common lisp.
5:01:54
kristof
aeth: Anyway, these are examples of "propositions" that would necessitate a total paradigm shift in conventional operating system design.
5:02:30
aeth
kristof: I think it would be more like CLR or JVM, where it's not like you can program whatever language you want, but that there's an equivalent to Foo as Bar in the runtime.
5:03:19
oni-on-ion
its fun to live in a logical digital world but the analog of change is why we code
5:03:26
kristof
aeth: You can program whatever language you want on the CLR or JVM. They're just machines.
5:04:31
kristof
beach: I hit the "paradigm shift" only recently, when I watched a presentation by a symbolics developer show off Genera. It all clicked, and suddenly I was very impressed.
5:07:13
johnjay
i was browsing his wikipedia and i thought from java to lisp... to parallel C... this is all very broad
5:08:24
kristof
It was from Lisp to Java. Well, to Pizza. Which is not quibbling, because Pizza was notable precisely for the things that were not in Java.
5:08:39
aeth
kristof: What tends to happen in practice is that people program in conceptual ports that interoperate better on the common environment, such as F# on CLR instead of a port of ML or Haskell.
5:09:24
kristof
aeth: In practice, sure. But F# is the way it is because of *C#* compatibility, not because of anything inherent in the CLR.
5:11:03
kristof
I happen to know F# very well, better than i know Common Lisp, so this is sort of my wheelhouse. :P
5:11:04
aeth
kristof: I would suspect that C# compatibility is itself an example of that. The C# built-in things it interoperates with are probably well-optimized.
5:13:04
kristof
The only example I can think of is that the CLR, unlike other garbage collected environments, distinguishes between heap allocated composite datatypes (classes) and stack allocated ones (structs). But that's still a CLR thing, not a C# thing.
5:14:10
aeth
kristof: Since you program in a language with a modern type system... I wonder: What is the CL type system missing?
5:16:28
aeth
kristof: Well what I mean is, I've done some reading on various things that languages brag about in their type system and CL has a lot of direct equivalents, e.g. the maybe type appears to be (or null foo), although that obviously won't work on lists, symbols, or booleans.
5:17:16
aeth
kristof: What can't be expressed well in CL and would it be worth trying to get it into implementations as an extension?
5:17:19
kristof
You know people talk about type safe nullables a lot and they cause more pain than they're worth. The first issue of course is the syntactic overhead.
5:18:34
aeth
kristof: but CL is itself a language where only lists, symbols, and booleans are nullable without (or null foo), at least afaik. And with booleans it really doesn't count because NIL *is* false.
5:19:50
kristof
In fact what I think you mean to say is that "only lists, symbols, and booleans are not trivially nullable in Common Lisp"
5:20:53
aeth
Although if you give a type something (various ways, only CHECK-TYPE and maybe ASSERT being guaranteed) you do have to (or null foo) to permit nil
5:23:28
kristof
Types are important. But what statically typed languages think types are and what lisp, and mathematicians, think types are is totally different.
5:23:45
aeth
kristof: No. I suspect I mix (implementation-optional) static typing and dynamic typing often enough in my CL that neither group would be happy.
5:24:54
kristof
aeth: Have you ever read this? https://groups.google.com/forum/#!msg/comp.lang.lisp/7nhbeh2NIuw/fD-PUkA1yBoJ
5:25:12
p_l
kristof: I think comparing LML and Symbolics CL is a bit of a missm at least on later versions where I think ZL differed mostly in available library
5:26:15
p_l
OTOH, pretty sure the Symbolics C, Fortran, Pascal and Ada compilers all used Lisp as intermediate stage
5:27:12
aeth
kristof: I do write CL sort of like what could be described as "gradually typed", but that's not really a good name for it because there are definitely places where I will never add type declarations or CHECK-TYPE or typed slots or whatever, especially in macros and "gradually typed" sort of implies that you start with T and eventually refine yourself into a Haskell program or something.
5:28:32
kristof
aeth: Sure, I agree, and I would say that the people who repackaged lisp type systems and called it "gradual typing", pretending it was novel, do not intend to fully type their programs, either
5:29:57
kristof
Because static typing is primarily about optimization, not correctness, and optimization is only important in certain places.
5:30:15
aeth
kristof: Repackaged lisp type systems? I hope they included both the numerical tower and multiple kinds of floating point!
5:30:40
kristof
aeth: I remember when Hack came out and they tried to pretend they had done something novel and I thought "this is already on SBCL"
5:31:23
p_l
kristof: arguably Ada's type system is concerned with correctness, not speed (what with subtyping that touches halfway to CL's 'satisfies)
5:31:45
kristof
That's true, and I can't think of any usable programming languages that come anywhere near Ada's type system.
5:34:18
aeth
kristof: this will give a compilation warning in SBCL (and it will compile BAR to always throw a SIMPLE-TYPE-ERROR). (with-compilation-unit () (defun foo (x) (+ x x)) (defun bar () (concatenate 'list (foo 42) "Hello")))
5:34:44
aeth
And if you (setf sb-ext:*derive-function-types* t) then it will always happen, even outside of a compilation-unit or file.
5:35:13
aeth
kristof: So types in CL can be useful for catching bugs early... and I didn't even statically type my example
5:35:45
aeth
But I do have to tell it to sb-ext:*derive-function-types* to make full use of it because it violates the ANSI standard iirc
5:36:35
aeth
(That variable tells it to assume that function types will not be redefined even when functions are redefined, which allows the compiler to make more assumptions.)
5:37:05
kristof
aeth: That's good, but do you think you never would have caught that bug if you didn't have static typing there?
5:37:41
aeth
kristof: I would have caught it in the middle of executing the program. FOO and BAR might be very far apart, and that runtime error might happen rarely, or after a long time.
5:38:06
kristof
You would have caught it in the middle of executing the *line*, not necessarily the whole program.
5:38:35
aeth
I like it when things fail early, especially if it's running in a program that has to CFFI, which can make debugging less fun.
5:38:40
kristof
line coverage also solves the problem of "I don't know when this might be triggered." Go on and trigger it yourself!
5:39:13
kristof
aeth: When I hear this argument for (completely, not gradually) statically typed languages, I like to compare it to spellcheckers
5:39:39
kristof
I think there is a set of things that I would want to check for when I write an essay. I think spelling is a good one, and it's also an easy one. I think there are many more ipmortant things, though, than spellchecking.
5:41:10
aeth
If I don't know how to spell a word, I just type it into *scratch* as "foo", i.e. as a string, so flyspell-prog-mode catches it
5:41:31
kristof
He or she specifically asked me "What do you thinks Lisp's type system is missing that other languages have", and I countered that it's other languages that should adopt Lisp's more general, more useful type system.
5:44:47
aeth
kristof: I'm still wondering what I'm missing in a typed slot, e.g. (defstruct foo (name nil :type (or null keyword))) ; it's unfortunate that :type, while optional in both, is respected in defstruct more than in defclass... I actually have a metaclass that enforces a type check portably on a slot
5:46:33
aeth
When I want to rely on a type check, I use a metaclass that has a :checked-type arg that does this: https://gitlab.com/zombie-raptor/zombie-raptor/blob/e404e51d899b45808e6fc4b7af281861073892a1/util/util.lisp#L536-543
5:47:25
aeth
kristof: Yes, where it does not check types and you can set it to whatever you want in a writer or in a constructor
5:48:30
aeth
I cannot assume that my users will use higher safety levels, especially because I am writing a game engine, where the focus will be on performance. But I do try to use the type system to ensure that I'll catch bad input as early as possible, and in Lisp rather than when feeding it to the CFFI (which is necessary for a 3D game, unfortunately)
5:50:23
kristof
Yeah, I would have expected default safety and speed levels to warn on provably bad input
5:52:00
kristof
In a game engine I would expect there to be a *lot* of type directed dispatch though, right?
5:53:03
kristof
I would imagine there's a fair amount of difficulty when it comes to type propagation and CLOS but I don't want to speculate.
5:54:08
aeth
kristof: Not at the moment. I'm still working on the optimized core (it's not really premature optimization, this is the stuff that's run 60 or 100 times a second in a hot loop at the core of everything else)
5:54:51
aeth
There are some higher order functions already, though. Where those make sense. I think at the moment that's input and scripting
5:55:22
aeth
(Maybe it's not wise as far as performance goes to funcall items from an array for all of the input, but it's just too convenient.)
5:55:53
aeth
(And I funcall 'foo, not #'foo, so I can have them recompiled. Not sure if that would hurt performance even more. But, again, a necessary evil.)
5:57:35
kristof
aeth if you're worried about performance I'm actually quite surprised you funcall a symbol :P
6:01:01
aeth
ldb: Well, I guess an alternative to an array might be to make it a several hundred line CASE, but I doubt SBCL optimizes for that. Still might be faster, though.
6:01:05
kristof
The correct thing to do is to define your own reader macro, or perhaps redefine #', so that in dev mode you get (quote foo), and in release mode (function foo)
6:06:55
aeth
kristof: redefining #' might actually be the way to go, although I would have to make sure that anywhere where I have CHECK-TYPE or :TYPE etc I use (or symbol function)
6:07:29
aeth
I suspect I already have type 'bugs' like that in my engine. I should probably define (or symbol function) as a type.