freenode/#lisp - IRC Chatlog
Search
19:25:50
jasom
I'm writing some software for an rpi; any tips or gotchas for using lisp to develop for it? Will swank and tramp-mode just work similar to how I would do between two x86oids?
19:36:10
boeg
Is it possible to have an optional argument (with or without default value) as *not* the last parameter. So say a function takes argument (a b &optional (c "") d), and the function can then be called with 3 argument (where c will get default value) or 4 arguments?
19:37:33
_death
you could implement your own arglist parsing, though that's a good sign you should rethink the interface
19:39:48
pjb
boeg: you can either 1- use &key arguments they are optional! or 2- use &rest and parse the list of arguments yourself!
19:41:38
pjb
(defun foo (a b &rest args) (let (c d cp dp) (ecase (length args) ((0)) ((1) (setf d (car args) dp t)) ((2) (setf c (car args) cp t d (cadr args) dp t))) (list a b cp c dp d))) (foo 1 2 3) #| --> (1 2 nil nil t 3) |# (foo 1 2 0 3) #| --> (1 2 t 0 t 3) |#
20:39:08
eeeeeta
jasom: you'd want to use CCL on a pi if you want threading; I was able to get swank working that way
2:02:16
asarch
Is there any way to get the PNG file of the (com.informatimago.common-lisp.picture.cons-to-ascii:draw-list *values*)?
2:04:53
pjb
asarch: otherwise, there are ascii-art web services that will convert that into a svg and png…
2:06:59
no-defun-allowed
pjb: Well yes, screenshotting text is annoying, but no need to hang people who do that.
2:13:32
pjb
You can use: (progn (with-open-file (*standard-output* "/tmp/aa.txt" :direction :output :if-does-not-exist :create :if-exists :supersede) (com.informatimago.common-lisp.picture.cons-to-ascii:draw-list *values*)) (uiop:run-program "ditaa /tmp/aa.txt") (uiop:run-program "open /tmp/aa.png"))
2:44:31
LdBeth
It seems to be the only comprehensive book on macro assemblers http://www.davidsalomon.name/assem.advertis/AssemAd.html
5:50:43
no-defun-allowed
I think there was a front-end processor file system which was probably for booting and a LMFS which was for user data.
5:52:20
no-defun-allowed
The MIT CADR stuff got released to http://www.unlambda.com/cadr/, and I guess the (relatively) newer Symbolics machine OS is still available if you can find a lispm or can spend $5,000 on the emulator.
5:59:34
remexre
hm, I think I might have a memory leak in my interfacing w/ an FFI lib on SBCL; is there an easy way of determining where it's coming from?
6:00:28
White_Flame
HiRE: the emulator was around way back, ever since x86 started getting faster than the lisp hardware
6:01:09
HiRE
White_Flame, I see so it was there to maintain compatibility with old hardware during the transition
6:01:42
HiRE
my AI professor routinely talked about symbolics machines but I was surprised when it was mentioned someone might still be using one :P
6:03:08
beach
HiRE: The way the tools are integrated can not be replicated on Unix-like systems because of the process model of those systems.
6:04:53
beach
HiRE: I mean, the process model of "modern" operating systems requires tools to turn everything into a sequence of bytes in order to communicate with others.
6:05:31
HiRE
beach, that sort of confuses me. How did the symbolics machine differ? I figured it'd still need to translate lisp code down to CPU language
6:06:11
HiRE
> Symbolics' initial product, the LM-2, introduced in 1981, was a repackaged version of the MIT CADR Lisp machine design. The operating system and software development environment, over 500,000 lines, was written in Lisp from the microcode up, based on MIT's Lisp Machine Lisp.
6:06:15
no-defun-allowed
It's not really much of a CPU problem as much as it is an OS problem, but they did have CPUs that had instructions that mapped closer to Lisp functions.
6:06:28
beach
The important thing is that an application can just hand a pointer to another application.
6:07:30
no-defun-allowed
The OS didn't have seperate memory spaces and had a global garbage collector (I don't think they were first to it, but the lispms had generational collection very early on), so it was possible to pass objects around very easily between threads and functions.
6:08:49
no-defun-allowed
You could skim http://bitsavers.org/pdf/symbolics/software/genera_8/Genera_Concepts.pdf too.
6:09:26
beach
HiRE: There are already two such systems, Movitz and Mezzano, but what I am planning is a bit more sophisticated.
6:12:32
beach
HiRE: Here is one problem: People see the interactive REPL. Then they think "interpreter", and then, of course "interpreter" implies "slow".
6:12:49
no-defun-allowed
A Lisp operating system could be faster than a Un*x system in several ways, too.
6:13:24
HiRE
beach, yeah. A similar argument was made a few years back for haskell. Unfortunately the "REPL = Slow" argument is pervasive.
6:13:33
beach
HiRE: This implication is incorrectly assumed by ignorant people who do not know much about language implementation.
6:14:20
HiRE
beach, right. Whats even more amazing is even talking to graduates in CS the belief is still pervasive.
6:15:37
HiRE
no-defun-allowed, how do you think a lisp operating system could be faster than *nix? I have no dog in the fight I'm just curious.
6:16:57
no-defun-allowed
Again, data sharing is faster as it's literally moving a pointer, with no serialisation or memory spaces to deal with.
6:19:13
loke
HiRE: You could use an Atari ST right now. No context switcihing (yes, I know, it's a joke)
6:19:17
no-defun-allowed
A tracing garbage collector is typically much faster than "typical" manual memory management, so some programs which cons a lot can expect to run faster (but avoiding consing is sometimes a good optimisation strategy).
6:19:27
beach
HiRE: I keep saying this here, but that's because everyone is so convinced that we have to program as if we have access to the entire memory (including the stack) of a physical machine, just like we did 60 years ago.
6:20:34
no-defun-allowed
Then when threads are involved, they can probably be made much more light-weight than in Un*x, so context switches would be much faster when they are necessary.
6:20:52
White_Flame
genera still has multithreaded support, so it does context switching in that aspect, but doesn't change any global config like processes
6:22:21
White_Flame
although other people can network in and get their own REPLs and desktop and such, it's all in the same flat image
6:23:10
HiRE
I guess because I never experienced a lisp machine I never thought of processes as anything different than a nix system
6:23:18
no-defun-allowed
And to clarify, not requiring context switches between different, well I'll call them "contexts" while I search the book to see if there is a better word, such as between file system and user code or a hardware interrupt handler and a server that uses that hardware, decreases latency too.
6:24:06
HiRE
it makes sense. I can see why you said a garbage collector can perform better than other memory management forms
6:24:35
no-defun-allowed
That alone could make datacenter peoples' eyes roll into dollar signs as they do in cartoons.
6:25:09
beach
It was invented so that the Bell Labs people could use as large a subset as possible of Multics, but on a tiny machine.
6:25:11
White_Flame
the entire OS is basically made up of the same plain function calls as everything else
6:25:43
White_Flame
unix is great if your entire model of computing is expressable in individual, independent lines of plain 7-bit text
6:26:02
HiRE
beach, right without an MMU they'd need to swap stuff in and out (which is what we learned in CS undergrad)
6:26:07
no-defun-allowed
https://cacm.acm.org/magazines/2017/4/215032-attack-of-the-killer-microseconds is relevant to that; the authors have figured that fast storage devices won't play nicely with current designs.
6:27:15
no-defun-allowed
To be honest, I would rather have lighter threads than "asynchronous" code, since the latter usually involves special language constructs, CPS-converting in the programmer's head or both.
6:27:54
loke
All kinds of threads need that, unless you're tlaking about "green" threads (i.e. cooperative)
6:29:18
no-defun-allowed
ACTION probably shouldn't have mentioned it; any threading more complex than lparallel:pmap hurt her head.
6:30:52
HiRE
good first round interview gutcheck is to explain the difference between concurrency and parallelism
6:31:37
no-defun-allowed
Typically articles like that try to create solutions that would work in a Un*x environment, maybe because it is less drastic to do so.
6:33:11
no-defun-allowed
Oh dear....is concurrency when some tasks can run "simultaneously", splitting up resources over time, and parallelism when they can truly run at the same time?
6:35:55
White_Flame
huh, yeah I guess the GC terms are a bit different when it comes to "concurrent"
6:37:39
no-defun-allowed
Yeah, a GC is "concurrent" if it can run at the same time as the mutator, but "incremental" if it splits up time between itself and the mutator.
6:38:29
HiRE
Opinion here but GC is a dirty word just like interpreted. I wish more people would learn that good GCs exist and it's just most of them are bad
6:49:09
asarch
How would you implement low-level code in the REPL for the processor? Would it be available in an own package? (cpu:int :address 80 :data my-code)?
6:49:50
White_Flame
you would generally generate an array of bytes that represent the machine code, and fiddle internal flag bits to get it in the exeuction stream
6:50:36
White_Flame
lisp implementations have various degrees of intermediate representation, and cpu-specific back ends, like any other compiler
6:52:34
White_Flame
which code? many of them are open source, and the DISASSEMBLE function will show you the compilation output
6:53:36
White_Flame
in SLIME, with your implementation fully installed with source references, you can use M-. to jump into the implementation Lisp code just as easily as your own code
6:54:25
no-defun-allowed
https://www.memorymanagement.org/ is a good reference for GC jargon and design.
6:55:45
no-defun-allowed
asarch: Yes, most Common Lisp implementations are written almost entirely in Lisp.
6:56:24
no-defun-allowed
https://github.com/sbcl/sbcl is (a mirror to) the SBCL source repository, and https://github.com/robert-strandh/SICL is the repository for SICL which might be easier to understand.
7:00:05
asarch
I was watching a video of the classic Street Fighter II video game and wondering if it was possible that they used Lisp (in some secret way) to develop the game
7:00:51
asarch
That game in its time was advanced (music, sprites, the speed when you pressed a button, etc)
7:03:45
asarch
When the programmers were entering all the required code so the game could run successfully
7:03:46
White_Flame
game development (and HPC) is typically very married to the specifics of the hardware, especially in that era
7:04:08
no-defun-allowed
There are lot of little tricks intricate knowledge of the hardware involved could give you. One simple example is that a programmer could provide more colours across the screen by counting the vertical lines drawn (which are generated sequentially) and changing palettes at specific counts.
7:04:22
White_Flame
so I wouldn't expect a very high level language, but rather a system of byte tokens driving states & animations