freenode/#lisp - IRC Chatlog
Search
8:41:37
beach
shangul: Muchnick's book is good as an overview of what exists, but his algorithmic language sucks, so I always go find the original papers after I read a chapter in the book.
8:43:23
beach
shangul: You probably also need to get an idea of the relative performance of different ARM instructions, and that information may vary according to the chips.
8:44:27
beach
shangul: But as a general estimation, register operations are fast. If you go to the L1 cache, you take a factor 5 or so performance hit. More in L2 and L3 (if there is one), and up to a factor 100 if you need to go to memory.
8:45:29
beach
shangul: Oh, and then you need to read up on synchronization, because we must now plan for thread safety.
8:46:38
beach
shangul: You may actually find that, in the implementation you are thinking of, memory management was designed at a time when memory accesses and register operations had roughly the same cost, so you may have to redesign the memory manager.
8:47:42
beach
shangul: Then, you might discover that the data representation was designed without threads in mind, so that there are way more locks that you would want. As a result, you may have to redesign the entire way data is represented so that it will be a better fit for threading.
8:48:52
beach
shangul: And you may find that the importance of cache memory was not as great when the implementation was designed as it is now, so there are lots of things you might have to alter in order to improve locality.
8:49:55
beach
To take but one example, a typical copying garbage collector accesses memory a lot, and when you move code, the instruction cache may very well be trashed.
8:51:18
beach
shangul: Part of the reason I started the SICL project was that I was totally convinced that it would be much harder to transform an existing implementation into something that would be adapted to the architectures of today, than to start a new implementation from scratch.
8:55:03
beach
Oh, but wait, when you said "How about optimizing existing CL compilers for ARM ...", perhaps you meant "How about you guys get your act together and work to optimize for ARM as well..."? If so, I may have bad news for you. People don't sit around waiting for others to suggest work for them.
9:41:03
shangul
beach, I just read all of your messages. By "How about optimizing existing CL compilers for ARM..." I meant if this is a good work/idea for myself.
9:41:49
shangul
beach, Isn't it better that for now I just learn ARM assembly and in the future when I studied the Compiler Design lesson in uni, look into compilers?
9:44:17
beach
My prediction is that, by the time you get around to working on a Common Lisp compiler, there won't be any 32-bit platforms left that can run a modern Common Lisp implementation.
9:59:55
beach
Well, that's not my analysis. In fact, if I were in shangul's position, I would bet that RISC-V is going to kill both ARM and x86. Then I would have a few years to figure out the best code generation of a Common Lisp compiler, and I would be ahead of the competition.
10:00:36
beach
Of course, since shangul doesn't have a RISC-V device either, an emulator would have to be used, or a device would have to be bought.
10:07:17
shangul
beach, If I had enough money, I would buy another NanoPi NEO and host it in my grandpa's house and use it as a server.
10:08:08
beach
shka_: It has several positive sides to it. First, the instruction set is not controlled by a commercial company. Second, it doesn't have any historical baggage, so the design is more orthogonal than existing ones.
10:09:26
beach
shka_: Furthermore, one convincing argument is that the same basic instruction set can be used in several situations, like mobile, desktop, micro controllers, GPUs etc., so that the toolchains can be reused for different purposes.
10:09:52
beach
shka_: But don't take my word for it. I suggest you read up and watch a few talks like I did. Then we can see what you think.
10:13:46
beach
I took a graduate-level course for Jim Goodman the inventor of the cache-coherence protocol, and of the speculative lock-elision protocol.
10:23:10
beach
There is lots of stuff to do for Common Lisp on RISC-V, like determining a good function-call protocol, figuring out the best way to handle overflow of fixnum addition, how to implement generic dispatch, etc.
10:25:28
jackdaniel
the key feature (from adoption perspective) it is that it doesn't require royalty fees for implementing it in hardware
10:26:17
beach
Exactly. That's what I meant by "not being controlled by a commercial company", but you are right to emphasize that.
10:27:46
beach
And since the instruction set is extensible, people who are into such things could figure out some extension for Common Lisp.
10:28:24
beach
More generally, figure out how to best use the existing instruction set(s) for executing Common Lisp code.
10:28:50
jackdaniel
talking about extensibility, I'd love it if the idea proposed by the synq chip was adopted broadly - they put a cpu (arm cpu though) and a fpga on the same bus, so it was possible to reprogram hardware from linux :)
10:29:54
jackdaniel
I can imagine compilation with (declare (optimize (compilation-speed 0) (speed 3))) putting a function as a hardware submodule ;-)
10:30:35
jackdaniel
it depends on size of the fpga (i.e how much you can put on it and how many pins are available)
10:32:44
lukego
Hey is there an easy way to see SBCL IR code? like an IR version of DISASSEMBLE or suchlike?
10:32:45
shka_
actually, now when i think about it, it is possible that there will be flood of semi custom RISC-V at some point
10:50:43
lonjil
The European Union is currently planning to build several large supercomputers in the next couple of years, that will use ARM CPUs, and custom RISC-V accelerator chips.
10:51:16
lonjil
(And hopefully, a few years after that, RISC-V is mature enough for the CPUs of any new supercomputers)
11:04:11
p_l
jackdaniel: the speed drop of talking to the FPGA side is significant enough that it won't work that nice
11:16:24
jackdaniel
phoe: programming fpga is slow, but other than that it is ordinary hardware device
11:20:43
p_l
jackdaniel: yes, and you will suffer all the typical peripheral device issues if you just try to wrap a random function in it, as they are not connected by coprocessor port but are plain MMIO devices (essentially, you have common access to memory bus, and FPGA using it impacts CPU performance negatively)
11:23:34
jackdaniel
the part about a function compiled to hardware device was a joke, however specialized hardware to smooth computations is a thing (i.e a gpu, or a decode etc)
11:25:17
p_l
well, yes. though for all practical purposes the performance option in this case would not be Zynq, but one of the Xeons with embedded Altera FPGA, or a POWER9/10 with CAPI-attached FPGA
11:27:26
jackdaniel
I've worked with zynq (not on the fpga part though), and my co-worker implemented a device to speed up graphical rendering on it, I don't know details but it was certainly commercial project with practical purpose
11:35:42
froggey
beach: RISC-V strikes me as a particularly poor target for CL. it doesn't have a reg+reg addressing mode, so array accesses need to construct interior pointers to objects, which complicates the GC
12:00:30
beach
froggey: Do you mean "complicates" in that the GC has to know which registers contain Common Lisp objects and which registers don't?
12:01:07
loke
I made the silliest mistake just now... A CLX display object has a plist, and I needed to set the value for :XIM to an instance of xim. So I did this:
12:01:59
loke
everything worked fine, but for some reason I never saw the plist itself change. Pop quiz: What did I actually do?
13:22:41
lukego
I'm a little fascinated by the idea of Lisp for embedded systems e.g. on RISCV lately. The picture I have in my mind is a big heavy workstation for development and then the little embedded system running minimal code e.g. without much/any lisp runtime system. maybe along the lines of Squeak's "Slang" having a relatively weak language that can be translated to bare metal C but can also be run as Lisp for devel/debug
13:23:15
lukego
I saw there was an ELS talk about Lisp generating C/C++/CUDA recentlyish, looked really interesting I thought
13:24:42
lukego
Silly question maybe but would it be better if SLIME made all objects into presentations - e.g. each individual element of each list that is printed in the REPL? what if it also provided CLIM style commands where you can select args from the presentations in emacs?
13:27:40
beach
lukego: With McCLIM, you have the listener, a "debugger" (which is really a backtrace inspector), and Clouseau which is an inspector that is way more competent than the SLIME inspector.
13:28:55
beach
Plus, the listener REPL is in the CLIM-USER package by default, so you can invoke CLIM functions at the REPL to draw things.
13:28:57
lukego
Right. I guess I'm wondering if it would be a big step towards CLIM for SLIME to just have finer grained presentations and also commands. I like the presentations-and-commands UI paradigm and I miss having it since I prefer to live in Emacs
13:29:36
lukego
I wonder if Emacs could draw things too e.g. inline SVG. I'm not sure how that support is nowadays realistically.
13:31:27
lukego
I've been meaning to try using org-babel instead of the REPL but old habbits are hard to break..
13:34:22
lukego
(it would be nice if the Emacs and McCLIM universes would play nicely together somehow. I like the idea of McCLIM but it feels like I have to give up too much to go that route.)
13:40:37
beach
We are working on making it less painful to give up Emacs. But it's going to take some more time.
13:41:31
beach
And, yes, I am aware that there are advantages to having a single editor for everything.
13:41:58
beach
But the plan is to make the Common Lisp editor so good for editing Common Lisp code that it is irresistible.
13:44:01
lonjil
Will work well for me, since I already only use Emacs for CL. (Mostly Vim for everything else)
14:05:03
lukego
beach: would be really cool. lots of people use and love the Lispworks IDE so that's a sign that there's room for competition with Emacs.
14:07:50
lukego
I've been using Blender a bit lately and that whole UI is just completely ❤️ that it makes Emacs feel like pico.
14:10:41
p_l
lukego: a non-trivial part of what people love about LW IDE relates specifically to LW runtime more so than the IDE itself
14:11:49
p_l
lukego: as for CL generating code for smaller embedded system, that's how at least the original Roomba was programmed
14:11:49
lukego
fair enough. but they are still willing to "pay the price" of not using Emacs for those features. and I suppose quite a few people are put off learning Lisp in the first place because of Emacs.
14:14:17
lukego
I'd really like a "worse is better" version of CLIM personally. that's what makes me wonder if SLIME could have a contrib/worse-clim.el that gave me basics like more pervasive presentations and commands.
14:17:39
lukego
but also maybe the repl is fine for me really, I don't have a good reason to be thinking about presentations etc at the moment. just something that pops up in the mind sometimes.
14:30:11
lukego
it's amazing the timescales that Lisp plays out over :). just reflecting that the one time I wrote a little McCLIM app was like 15 years ago.
14:31:15
beach
Yeah, McCLIM basically started happening in 2000. Mike McDonald had written some code before that, and so had gilberth, but that's when it really started happening.
14:36:11
lukego
Are you still are Bordeaux, btw? (pardon my out of the loopedness, haven't been keeping up much since ECLMs)
14:41:01
jackdaniel
McCLIM was once considered young compared to symbolic's clim, however now McCLIM has 20 years while CLIM-TOS has 30 years, so the relative gap is closing :)
14:43:07
jackdaniel
lukego: one day I'd love to be able to do: (ed (open-project "~/my-project/")) from the console and have full featured CLIM ide open
14:46:37
lukego
I'm learning electronics now. I want to design circuit boards that feature FPGAs prominently and then fabricate, assemble, and program them. So I'm kind of imagining a suite of homebrew Lisp CAD code. very vague at this stage :) but has some graphical nature - circuit board design is similar to vector graphics with various constraints (e.g. lines can't cross or come within distance X of each other, etc)
14:48:14
lukego
Just now coming to the part about writing code. Had to learn how to solder first :). Seems like PCB design is a bunch of sub-problems that have to awkwardly/heuristically fit together and each probably has its own fundamental data structures. e.g. problem of untangling the grid of pins under a chip verses problem of connecting two chips together without creating new tangles in the process
14:51:32
lukego
Standard open source CAD tools like KiCad seem to take a very concrete central data structure, basically a multilayer vector graphics drawing, and do most things manually. I'd like to try doing things more abstractly where the master data is a bunch of custom objects/data-structures and the concrete layouts are more like pretty-printed output of those.
14:52:08
lukego
yeah. and at this stage it's not clear if I'll end up really using the software, or just write it as a vehicle for understanding how the hell this stuff works :)
14:52:13
SAL9000
e.g. the traces for USB differential pairs have to have equal length to within a certain precision
14:52:16
jackdaniel
embedded systems are a lot of fun, but eventually you get fed up with C and Verilog
15:11:47
easye
Josh_2: the Online Lisp Meeting? It will be streamed through twitch.tv, and later available on YouTube.
15:12:30
easye
Josh_2: Maybe, but see <https://www.reddit.com/r/lisp/comments/hsa0m2/online_lisp_meeting_5/> for more information.
15:28:21
nirved
lukego: one could display images in repl, here is a svg example: https://gist.github.com/nirved/e59aa01f2cd6d75ca6d5dde08c037519
15:45:10
lukego
maybe swank:eval-in-emacs could be abused in a lot of interesting and convenient ways..
15:45:49
thetabit
Hello everyone, I just found this channel on common-lisp.net, was curious if this would be a proper place to discuss specific technical aspects of cl?
15:49:19
thetabit
Awesome, so I was curious about the use of the format function. I have been using it, especially for producing sql and php code for my job. (since I hate writing this code directly) I have been using post modern for the sql, but for php I am generating code based on our companies style... Things are going great, but I feel very dirty using the format function? Is this my imagination? I wanted to know if the format function is
15:50:22
phoe
postmodern has its own S-expression based DSL for generating SQL that should work better than operating on raw strings
15:50:55
phoe
I mean, (format nil "SELECT ~A FROM users;" ...) is easily abusable if the user somehow controls ~A
15:51:25
thetabit
yes, this is just for me for producing the source code, that is committed so no other devs are using this
15:53:36
_death
thetabit: there are alternatives to format.. for example the approach described in http://cs-www.cs.yale.edu/homes/dvm/format-stinks.html
15:53:41
pve
thetabit: you probably need to apply some kind of escape function to some (all?) of your format arguments
15:54:39
_death
thetabit: such an operator can be further extended so that you can easily generate ad-hoc code
15:54:51
thetabit
@Josh, yeah, I have been producing very specific php code for my company lol. They are a Russian team and have a very particular format that they use, so I just automate must of it away
15:58:05
thetabit
It became clear that I could generalize the code, and then automate specific idioms that the companies use, while also not failing code reviews ;)
16:08:40
_death
thetabit: here's an example how it might look like.. https://plaster.tymoon.eu/view/1962#1962 (in actuality, there are a few more macros on top to make it a bit cleaner)
16:24:45
phoe
Xach: please don't try to build clcs-code yet, I'm figuring out the repository structure where I can both have a complete repo for Apress and have separate repos for clcs-code and portable-condition-system
17:18:53
adlai
shka_: please please PLEASE DEAR GOD don't ever make that fucking dies/dice typo ever ever again
17:22:13
adlai
no thank you, welcome to "live languages can shock your nuts off if you listen to grammarly"
17:23:46
Oladon
So... Lisp... anyone have any experience with maxpc, and/or want to help me figure it out? :P
17:24:04
adlai
for all I know, the author of that blog post never even saw a photograph of a silicon ingot being drawn, sliced, nor verified as NOT BEING A CASINO DICE
17:24:38
adlai
it is better for the plural of the determinist noun to collide against a verb conjugation, than for the two plural nouns of differing determinist to collide against eachother.
17:25:37
Oladon
Yeah, that's what I'm referencing. I'm trying to figure out how to set this up so that one parser matches the value matched by an earlier parser in the series.
17:26:40
Oladon
I thought I could do it by nesting =destructure, but it doesn't seem to be working -- it's eventually returning a closure instead of my result
17:27:27
Oladon
I.e. I'm trying to parse "bxb" or "cxc" or "dxd" but ensure that the last letter matches the first
17:44:26
Oladon
shka_: I'm really just looking for library help. As I said, I can do it just fine in cl-parser-combinators using mdo, just trying to figure out the analog in maxpc.
17:48:21
Oladon
In cl-parser-combinators there's a monadic do (mdo) which allows you to use <- for binding.
17:49:37
Oladon
So I figure there must be something analogous in maxpc, just can't quite figure it out
17:57:10
Oladon
(let ((letter)) (parse "bb" (=list (=transform (=element) (lambda (s) (setf letter s) s)) (=subseq (?satisfies (\lambda (s) (string-equal s letter)))))))
17:59:38
Oladon
I've been enjoying it. I don't think I'll mind a couple of slightly-ugly lets in one function.
18:50:37
phoe
if they didn't nest, the comment would instead end on the first |#, leaving a contextless chunk of code full of mismatched closing parens
19:03:40
jackdaniel
it was one of first lex excercises we had at uni - implement nested block comment in c (non-conforming)
19:32:26
specbot
Notes about Style for Sharpsign Vertical-Bar: http://www.lispworks.com/reference/HyperSpec/Body/02_dhsb.htm
19:36:19
_death
seok: yes, you can use them together.. in fact it's sometimes a good idea when defining a macro, to determine the appropriate order of evaluation given the macro form
19:41:37
_death
also note that the default value is the symbol *auth*, not the value of *auth* at macroexpansion time
19:46:10
_death
I'm not sure what you're asking.. if your macro gets a symbol (like *auth*) you can use it in an evaluative context within the macroexpansion without trouble
19:47:12
aeth
On the earlier topic of architectures and compilers... Can RISC V replace ARM? Definitely. Can RISC V replace x86-64 on desktops/laptops? Probably not. Nobody (except Apple) is going to break backwards compatibility with 3-4 decades of software binaries. I don't think FASLs are typically portable across architectures, are they? So this even affects CL.
19:53:30
_death
aeth: for example sbcl fasl format has a version field, and I don't think it supports values other than the "current version"
19:54:29
aeth
_death: I wonder if that makes semver impossible, since every release would be a breaking one
20:05:49
lukego
beach: Just reflecting that Emacs is not as sticky as I often think. I've been writing a lot of Lua in Emacs and there it doesn't support much of anything beyond indentation and syntax highlighting. I've been writing R in RStudio which is a 90s style crappy IDE that just happens to make it easy to plot and render RMarkdown out of the box. Pharo smalltalk is its own world too. So McCLIM seems quite plausible in that sense.
20:09:28
lukego
I'd say it's an "it's complicated" but I'm only using it as an example of a system that I've been quite willing to "live" inside despite being an Emacs weenie and having to give up all Emacs features to work with it.
20:10:26
lukego
I think you have to choose your battles carefully when you're making a "parallel" computing world. I don't think you want to reinvent things like git.
20:10:49
lukego
well love-hate with smalltalk. I hack some smalltalk every ten years and then flame out after some weeks or months :)
20:11:34
lukego
I spent quite some time working with the GToolkit object inspector library recently. very love-hate. it's the opposite problem to Common Lisp world - anything written more than one year ago is hopelessly obsolete, anything newer is hopelessly unstable :)
20:12:15
lukego
maybe that's why I get nostalgic for Lisp now. Hard to get shit done without a stable foundation to work from.
20:13:06
lukego
I should try to get McCLIM up and running. just had a build error last time that was complicated by my very quirky usage of Quicklisp via Nix that prevented me from being able to tweak the code
20:13:58
lukego
also Emacs changes. I enabled company-mode, ivy, etc, that everybody is into these days and I don't know what the hell is going on anymore :)
20:16:26
lukego
pve: I do really like the way Smalltalk code is factored. I don't really like the IDE though. I like my code organized into files. my brain is linear :)
20:17:00
lukego
I haven't read the Blue Book and would like to one day see how it's implemented under the hood. I've gone down that rabbit hole with Forth and that was worth the trouble for sure :)
20:17:41
lukego
ok I have mcclim giving me the instllation error but running from a local checkout that I can actually patch. bedtime now but added to my procrastination vehicle rotation :)
20:18:21
lukego
pve: I don't think I've ever seen a Lisp-Smalltalk hybrid actually? seems to make potentially a lot of sense :)
20:20:04
pve
lukego: at this stage it's mostly a syntax thing, but I wanted to see what would happen if one could mix lisp with smalltalk style message passing
20:22:41
lukego
I also fantasise a little about doing LuaJIT style tracing in Lisp at least as an experiment/illustration. run code for a while, discover the in-practice types of some variables and definitions of some functions, and call COMPILE to create chains of specialized fast-path functions.
20:25:33
pve
the first picture defines a source file class for the loader, the second does some asdf integration
20:27:54
pve
as you can see, it's not exactly smalltalk, but if you squint you can kind of see where the inspiration came from.. and besides, it's in a pretty early stage
20:30:50
aeth
lukego: Imo, people don't use tools based on the merits of the software itself, but based on the ecosystem. Emacs is Emacs, but any CL-based editor with tight integration to a popular CL platform would win over most of the CL community.
20:33:32
lukego
aeth: Maybe. CMUCL had Hemlock but it felt like I was one of maybe three people in the world using it :)
20:38:18
lukego
oh hey I have the clim listener running now :) just kludged in another hard coded path to look for truetype fonts