freenode/#lisp - IRC Chatlog
Search
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.
6:15:05
aeth
Is (or symbol function) the correct type for funcallable things here? I think MOP adds funcallable instances, but I don't think they'd be used in this context. It looks like adding symbol as a possibility adds one test, so it probably won't hurt performance in a noticable way.
8:12:09
shka_
is change-class guaranteed to change existing instance instead of allocating and returning new one?
8:14:00
beach
For example, in SICL, every standard object has a header and a "rack". The header contains a (pointer to a) class and a (pointer to a) rack.
8:20:49
aeth
shka_: everything's boxed except for things smaller than 64-bit (assuming a 64-bit implementation). That's probably single-float, fixnum, symbol, keyword, maybe character. Definitely implementation-dependent. Fixnum has tag bits, possibly just one (like in SBCL, which makes it a (signed-byte 63)). single-float is obviously half of the size so it definitely fits (for 64-bit implementations).
8:21:50
j`ey
when (time..) on sbcl shows N bytes consed, I assume that's also talking about boxed things?
8:22:23
shka_
you don't have pointer to storage area, you have pointer to pointer to storage area :-)
8:25:03
beach
Though symbols would not need any indirection since you can't change the class of a symbol.
8:26:51
givre
Hi, i'm trying to build a macro to pass a bunch of functions to a cond statement. I've tried the following to no avail : (defmacro find-element-with-multiple-strategies (value l (&body strategies)) `(cond ,@(find-element ,value ,l #'strategies)))
8:27:52
beach
First COND is a "form" not a "statement". Then, how do you pass a function to a COND form?
8:28:28
beach
givre: I suggest you use a pastebin to show your code, but also what you expect from the expansion of your macro.
8:29:14
beach
givre: It would also be very unusual to have &body wrapped in a sub-lambda-list the way you did.
8:29:34
givre
beach: I want to unwrap the list of strategies to build a cond form containing all the functions
8:30:10
givre
beach: yeah that's what i figured, i'm not really familiar with macros, i'm going to post the code on pastebin + expansion
8:31:38
beach
givre: Also, when you do #'strategies, you are looking in the function namespace and not in the variable namespace.
8:32:12
shrdlu68
shka_: I've been thinking about that too. Using hash tables, at least as I currently use them, is untenable.
8:35:24
shrdlu68
shka_: What did you make of sb-sprof's output? Hashtables apparently aren't the bottleneck.
8:36:46
shrdlu68
shka_: I've also been thinking about implementing bit vectors in octet vectors with a little bit of overhead, but this is apparently exactly how SBCL does it.
8:37:07
aeth
(The HyperSpec says that "the actual internal representation of symbols and their attributes is implementation-dependent", but there might be a common implementation technique.)
8:37:09
beach
givre: ,@(find-element ...) will call the function FIND-ELEMENT and insert each element of the list that it returns.
8:37:24
shrdlu68
shka_: Does it account for the supermassive performance difference between SBCL and other implementations?
8:40:31
shka_
shrdlu68: i can't check right now, but it is possible that CCL does not like bitvectors as keys in hashtable so much it generates to O(n) lookup
8:41:42
shka_
simply populate hashtable with bitvectors measure time, populate hashtable with twice as many bitvectors, measure time again
8:43:49
givre
beach: honestly don't understand all the meaning of #' right now, so would be able to tell you why. I'm trying to abstract away the use of a cond, I want to be able to search in an assoc list with multiple matching strategies (right now i'm splitting a mail adress and matching user login with the first part of the mail for instance)
8:45:14
beach
givre: OK, but it is not going to be possible for you to write a macro unless you first know what ,@ does and what #' means.
8:48:06
beach
givre: But, you seem to think that it expands to (cond (list ...) (list ...) (list ...))
8:50:07
givre
beach: sorry, i meant the cond clause is not a cons. Yeah that's what i did obviously. It expands to (cond 1 2 3 234)
8:50:48
beach
So, why do you think your expansion will contain (find-element when mine doesn't contain (list?
8:53:14
givre
beach: I believed that placing the ,@ before a form instead of the parameter would splice differently, which is far fetched yeah
8:53:27
beach
givre: Like I said, ,@ will evaluate the form that follows, in my case (list 1 2 3 x) and then splice the elements of the resulting list into the COND.
8:59:25
givre
givre: the find-element function is awaiting a function parameter, i passed it this way and then applied it in the body when i was not using the list
8:59:41
beach
givre: I suggest you write a function that returns the list ((find-element 1 '(1 2 3) (lambda ...)) (find-element 1 '(1 2 3) (lambda ...))). Once you have that, you can stick a call to it after the ,@ in your macro body.
9:00:47
givre
beach: I guess for the #' I don't need to use it because my lambda will be #'ed in their list anyway right ?
9:02:00
beach
There are "functions" and "lambda expressions" (which are not functions, but code), so again, it depends.
9:06:37
beach
givre: Here is a better example: Consider the macro (defmacro baz (x y) `(list ,x ,y))
9:07:48
beach
In the first case, you are passing lambda expression to the macro function, because macros do not evaluate its arguments.
9:08:13
beach
In the second case, the reader will create functions for you and those will be passed to the macro function.
9:11:11
TMA
givre: to macroexpand is to call MACROEXPAND on the (quoted) form, not to _run_ it (possibly call MACROEXPAND-1 to look at one level of macroexpansion at time)
9:12:32
aeth
You usually want macroexpand-1 because macroexpand will leak implementation details as it keeps expanding well past the standard forms
9:13:29
beach
It is just amazing that you are trying to write a macro this early in your Common Lisp training.
9:14:51
beach
givre: So with all this information, you should be able to write a better version. But I this is too basic for #lisp, so next time you need help, I suggest you visit #clschool instead of #lisp.
9:15:43
givre
beach: i've been doing a bit of common-lisp for times to times over the past few years, but right now i've got the opportunity to write some POC at work and real code so here am I
9:16:09
shka_
givre: there are multiple ways to implement such functionality, and macros have major drawbacks
9:17:53
aeth
I recommend people stick to established patterns when learning how to write macros. DO-FOO, DEFINE-FOO, and WITH-FOO are all simple and are the vast majority of macros you'll probably see/write
9:19:02
givre
shka_: ok, i was about to ask for betters leads. higher order functions are something I can relate to a bit more indeed !
9:22:02
shka_
anyway, contrary to what many would say, you can spend whole day in CL without defining your own macro
9:28:29
givre
shka_a: Sure ! I'll write this macro anyway since I invested time in it, then I'll stick to actually writing code.
9:31:48
Demosthenex
so i have a simple http api to postgres project i'm doing, i'm considering threads to run requests in parallel. i have no global or shared variables, other than potentially postmodern's db connection and dexador's. i'm reading on bordeaux threads, any other suggested reading?
9:37:44
shka_
Demosthenex: lparallel is thread pool, futures, some paralleized higher order functions, sync queues and some other stuff
9:39:53
Demosthenex
i think this is a simple job and a good fit for parallelism... so i'll give it a go
9:46:39
makomo
i was scrolling through SBCL's sb-walker codewalker and stumbled upon this comment https://github.com/sbcl/sbcl/blob/master/src/pcl/walk.lisp#L393
9:47:48
makomo
implementing special forms as macros should be conforming afaik, but does the same hold for the reverse?
9:51:45
beach
"An implementation is free to implement a Common Lisp special operator as a macro. An implementation is free to implement any macro operator as a special operator, but only if an equivalent definition of the macro is also provided."
9:54:13
Demosthenex
shka_: give i know how many pages of data i'm downloading, i'm thinking of just using pmap
9:55:39
makomo
beach: so for the purposes of a code walker, one can just ignore the fact that a macro is implemented as a special operator when there will surely be an equivalent definition of the macro
9:57:22
makomo
beach: mhm. the "codewalker problem" is quite an interesting one, and i always wonder how useful would a codewalker within the standard be
9:58:35
pjb
makomo: or in a library, no need for a standard. The only thing, would be that implementation don't have macros that expand to non-standard special operators that don't have a macro expanding only to standard operators.
9:59:19
makomo
i've watched michael raskin's talk on a portable codewalker, and from what i've seen, doing it portably isn't really possible
9:59:37
pjb
beach: the implicit in "but only if an equivalent definition of the macro is also provided." is that this macro expands to standard special operators…
10:00:22
beach
makomo: So for those parts, come up with a CLOS protocol so that implementations can configure it.
10:00:43
makomo
beach: mhm, i get your idea, but it would still be nice if it could be done 100% portably
10:01:54
makomo
i think i have a vague idea (i forgot much of the talk) -- it might have something to do with environments
10:02:36
makomo
but, reasons for it not being possible aside, i would still wish that it could be done portably
10:03:51
beach
The problem is that the implementation may call MACROEXPAND on a lexical environment.
10:08:36
makomo
beach: reading your code walker specification that i just found -- good stuff! a minor typo: "and interpreter" https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L70
10:10:53
makomo
beach: i think christophe's post was about "let over lambda", not "land of lksp" (assuming we're thinking of the same article) https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L15
10:11:09
pjb
beach: I don't think a code walker should expand the standard special operator as macro ever.
10:11:14
makomo
here's the post about code walking: http://christophe.rhodes.io/notes/blog/posts/2014/naive_vs_proper_code-walking/
10:16:53
makomo
j`ey: a program that knows how to "interpret" common lisp code and that can tell you various stuff about it
10:16:56
jackdaniel
since body contains code, such macro has to understand meaning of special forms, macros, functions, variables etc
10:17:10
makomo
"interpret" not in the sense of executing it, but in the sense of "walking" it and "figuring out what the code does"
10:18:51
jackdaniel
since code walking is non-trivial in common lisp it is hard to get right (hence it is rarely used in "normal" applications)
10:23:33
pjb
beach: Yes, https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L98
10:24:12
pjb
The code walker should not always try the macro first. If it's a special operator, it should call the user function with it, and let it interpret the special form.
10:25:20
makomo
beach: ah :-). i suppose this text will eventually become part of the main SICL spec (the collection of tex/pdfs you maintain)?
10:25:21
pjb
beach: now, there may be an option to do what you specified, but in general, I wouldn't use it.
10:25:48
makomo
beach: "during during" https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L63
10:26:09
beach
makomo: Possibly. Since I couldn't remember having written it, it might have been forgotten.
10:26:30
makomo
beach: "body code" ("body of code" perhaps?) https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L79
10:26:48
pjb
The thing is that such special operator macro will most certainly do implementation specific things, such as ignoring ignorable special operatorns (eg. THE). A code walker will usually want to be conforming and extract the semantics of the program in an implementation independent way.
10:27:49
makomo
the thing about not trying macros first is also mentioned in the comments of sbcl's walker https://github.com/sbcl/sbcl/blob/master/src/pcl/walk.lisp#L389
10:39:27
makomo
beach: "a code walker (...) that collect (...)" https://github.com/robert-strandh/SICL/blob/master/Code/Cleavir/Code-walker/Specification/code-walker.text#L112
10:41:52
dim
as with many things in CL I though it was somewhat overkill until I had a use for it ;-)
11:23:07
jackdaniel
Xach: CG memos you've shared the other day by Alvy Ray Smith are true gems, thank you again for sharing the link
11:32:05
Xach
jackdaniel: many years ago i ran a GIMP web forum and he joined and asked if gimp was making the mistake of being rectangle- and square-centric with regard to images and layers, and a few deveopers chimed in that those were the most natural and anyway image formats are all square, and who are you, anyway, old man
11:32:20
Xach
jackdaniel: it was pretty embarrassing when i saw him in a pixar documentary and he was a founder
11:33:59
jackdaniel
truth to be told, orbitrary shapes/ transformations for various objects make my life certainly worse than it should be (mcclim-wise)
11:34:53
Xach
right - his notion is to break free of tradition and ease - kind of like how gc frees you, even though making gc work is difficult
11:34:56
jackdaniel
and it is just in time I've read it, because next biggish thing I want to add to mcclim are animations
12:48:32
oni-on-ion
aeth: are you still awake or up yet? what did you mean earlier when you said that funcall happens differently on 'foo than #'foo ? i think that might be part of a problem i ran into last nacth
13:13:08
EvilTofu
Moo. I've just downloaded CCL 1.11.1 from the Apple Mac App Store. HyperSpec look ups just give me a Map_Sym.txt file not found dialog. Is there a fix for this?
13:14:30
oni-on-ion
never heard of that before. i myself use slime in emacs with HyperSpec downloaded from lispworks.com and the help lookups (C-c C-d h) are great
13:21:27
oni-on-ion
aeth: ah it did solve my problem! i've got to learn the difference between #'foo and 'foo now.
13:33:41
pfdietz
"Because static typing is primarily about optimization, not correctness, and optimization is only important in certain places."
13:38:47
oni-on-ion
for me, types help to design data structures, which helps to plot and plan - where most i guess use paper or their own heads
14:26:51
oni-on-ion
slime-highlights is really great. make changes anywhere, they are highlighted, C-c C-c to compile those
14:34:57
oni-on-ion
could we use setf places in let forms? ie. (let (((slot-value h 'conn) (make-connection..))) ...)
14:38:47
trittweiler
oni-on-ion, search for LETF. It used to be provided on the Lisp machine. And implementation based on setf + unwind-protect is easy, but it doesn't really work well in multi-threading environment (contrarily to LET, both for lexical bindings (trivial) and dynamic bindings)
14:39:25
oni-on-ion
trittweiler: ohh,i thought that letf was for functions on just the right hand side only =)
14:40:06
trittweiler
there's also an implementation of lets in Emacs' cl implementation. Probably can just take that. Or search comp.lang.lisp
14:56:27
schweers
I have a hopefully quick question. I don’t indend on doing this, partly because I don’t know how. I just want to know a) if it could be done, and b) whether that would be considered sane. Suppose I want to place very simple datastructures (for the sake of argument, lets say something like a defstruct) in a specific place in memory, like a memory mapped file or shared memory, or something similar. Can the MOP be us
14:57:27
Xach
oni-on-ion: if it's (defmethod frob ...) you would inspect the #'frob generic function, and slime shows a list of methods with options to remove
14:57:49
oni-on-ion
https://github.com/robert-strandh/CLIMatis/tree/master/Applications/Clouseau <-- ah there is !
15:05:16
oni-on-ion
hey so. how come (slot-value h :conn) does not work, but (slot-value h 'conn) does -- when defclass slot was set to :initarg :conn ??
15:05:40
Xach
oni-on-ion: the :initarg is the symbol used in make-instance, not the name of the slot.
15:09:25
Xach
jasom: I am trying to build a cuda library and i don't care if it really works, i would just like a (possibly non-working) .so to see if I can make progress.
15:23:10
pjb
mkdir -p ~/quicklisp/local-projects/com ; cd ~/quicklisp/local-projects/com ; git clone https://github.com/informatimago/lisp.git informatimago
15:24:02
pjb
But it counts only from the time loaded, so you have to insert this (ql:quickload "com.informatimago.common-lisp") in your rc file.