freenode/#lisp - IRC Chatlog

4:09:42 stylewarning aeth: is LOOP a different language that compiles to CL? If yes, then yes Coalton is

4:10:19 stylewarning Ty for newlisp note

4:12:25 stylewarning aeth: my hope is that Coalton can be compiled and type checked at macro time and expand into efficient Common Lisp code

4:12:54 stylewarning I don’t want it to be a language atop Lisp as much as a language within Lisp

4:16:46 stylewarning I’m just not sure I’ll be able to do everything properly at macroexpansion time. Coalton is having issues currently with side effects happening at macro time

4:18:43 aeth stylewarning: Well, if you do make it a language that compiles to Common Lisp with almost-but-not-quite-identical syntax to CL then you need to solve the same problem that my Airship Scheme is working on solving, which is why I asked about the distinction.

4:19:23 aeth stylewarning: One of the trickiest parts seems to be ASDF integration since it's not obvious at all where to intercept the ASDF file compiler to tell it to use a custom reader but otherwise treat it as a Common Lisp file.

4:22:13 stylewarning I want the usual Lisp reader to work

4:23:03 stylewarning This file is an example https://github.com/stylewarning/coalton/blob/master/src/library.lisp#L3

4:24:22 aeth stylewarning: What exactly are the issues with side effects at macro time? The only way I can think around that is if you do side effects in a way that multiple (almost always just double) evaluation doesn't impact the macro. "No side effects in macros" is only a rule of thumb, after all. e.g. a global INCFed variable is afaik fine, since it should only go up.

4:24:44 aeth Also INTERNing is the most notable exception to the no-side-effects-in-macro rule, since INTERNing twice isn't problematic.

4:25:28 aeth I guess DEFUNs are similar.

4:26:26 stylewarning aeth: I modify and query a global database at macro time and it causes all sorts of funky stuff, esp. since those side effects aren’t put into a FASL

4:26:52 stylewarning See eg https://github.com/stylewarning/coalton/blob/master/src/library.lisp#L3

4:28:53 stylewarning Oops wrong link

4:29:07 stylewarning https://github.com/stylewarning/coalton/issues/11

4:30:45 aeth stylewarning: what is the database?

4:30:57 stylewarning Holds types of all global functions and variables

4:31:10 aeth yes, but what is it?

4:31:32 stylewarning Here: https://github.com/stylewarning/coalton/blob/master/src/global-environment.lisp#L15

4:31:37 stylewarning A hash table with structs

4:32:05 aeth What if instead of using one hash table you defined functions in a different package namespace? So you'd look up with function calls.

4:32:18 aeth And changing the type would just be redefining functions.

4:32:43 stylewarning Kind of kooky but I dig it

4:33:22 stylewarning Using FDEFINITIONS and symbols as a database itself

4:34:28 stylewarning The difficult part is setting and querying still. I think I’d have to EVAL or SETF FDEF to get that to work

4:34:37 aeth I was thinking along the lines of generating `(defun coalton.type:foo () 'whatever-you-use-for-types)

4:34:51 aeth Then you'd just get it with (coalton.type:foo)

4:35:26 stylewarning Yes I understand

4:35:38 aeth As long as you only use 'coalton.type:foo and (coalton.type:foo) without using any #'coalton.type:foo in your code, then it will always query the fresh value and not go stale (the #' could go stale)

4:36:01 aeth (In case you haven't encountered that before)

4:36:08 stylewarning But I need to change and query that value at macro time

4:36:25 stylewarning Not just generate a value which I can play with at runtime

4:37:13 stylewarning All of this hacking does lead me to believe I ought to have special ASDF support so I can do stuff before and after the compilation unit

4:37:21 aeth I think defining and redefining functions is an acceptable side effect in macros. If it's not, you can add a versioning system of always-incrementing version numbers for each function, since always-incrementing afaik is safe.

4:38:01 stylewarning aeth: consider this function which gets executed as a part of a macroexpansion https://github.com/stylewarning/coalton/blob/master/src/toplevel-declare.lisp#L35

4:38:15 aeth Please lobby for that special ASDF support because I know that you're doing it for types and not a custom reader, but Airship Scheme needs the exact same thing (telling it to use a custom reader before the compilation unit and then restoring it after, or something along those lines).

4:38:32 stylewarning Yeah I would lobby for that

4:39:12 aeth I've been looking through ASDF off and on over the past few years and have found some possible candidates for interception (if I wrote it down somewhere...) but it would really just be a hack and not something official afaik like it should be.

4:39:51 stylewarning Is it possible to define a new component type? We do that for compiling C libraries

4:40:38 aeth The problem is that you'd want the least possible work, since you want it to otherwise use the CL compiler just with some before/after stuff.

4:40:56 stylewarning aeth: https://github.com/rigetti/magicl/blob/master/magicl-transcendental.asd#L56

4:40:59 aeth If you just copy and paste the implementation of the .lisp stuff (through quite a few files) I think it would work

4:41:08 aeth But that just seems wrong...

4:41:22 stylewarning That converts a FORTRAN file into a .so via an ASDF component

4:41:26 aeth ah

4:41:50 stylewarning The definition for that is above

4:42:09 aeth Does that use its own file extension, distinct from .lisp? Coalton might need its own extension.

4:42:59 aeth It's not as bad as it sounds since most tools should respect ";;;; -*- mode: common-lisp; -*-" so it would just add one line of boilerplate to every file

4:44:26 stylewarning Yes it’s .f

4:44:49 stylewarning aeth that’s controlled by https://github.com/rigetti/magicl/blob/master/magicl-transcendental.asd#L9

4:45:41 stylewarning If airship scheme is a scheme compiled to Lisp in Lisp that sounds awesome

4:46:22 aeth ouch, that file uses way more lines than I thought that the solution would take, and since that just calls a foreign compiler, that's probably fewer lines than reimplementing ASDF's CL compiler logic

4:46:45 aeth Ideally, a custom extension in ASDF with before/after stuff would just produce .FASLs and reuse almost all of ASDF's CL machinery.

4:48:45 aeth stylewarning: Yes, Airship Scheme is written in Common Lisp + R7RS Scheme and will compile to Common Lisp, and interoperate with Common Lisp using the hack of case inversion so Scheme's case-sensitive "foo" is really "FOO"... https://gitlab.com/mbabich/airship-scheme

4:49:04 aeth stylewarning: I got like 90% of the way to a version 0.0.1 in April and then it stalled out a bit and I needed to take a break from it

4:49:19 stylewarning Sounds like airship and Coalton would need to solve a lot of the same problems

4:49:33 stylewarning Lexical bonding, file compilation, an “FFI”

4:49:38 stylewarning bonding lol

4:50:27 aeth Airship Scheme even has a minimal "runtime" since it adds continuation passing style to everything. What I'm going to do is add it at the exposed-to-CL entrypoints, but also have internal Scheme procedure definitions that don't add the runtime

4:50:39 aeth Well that and guaranteed tail recursion.

4:50:59 aeth Afaik, continuation passing style + thunks + trampoline will solve that, not that much boilerplate, and almost all of it handled by macros

4:52:13 aeth stylewarning: Airship Scheme will probably also support optional static typing, since I already do some static typing in CL with my DEFINE-FUNCTION macro... https://gitlab.com/zombie-raptor/zr-utils/-/blob/24f747564418f65b91df186028655c408fe18244/util.lisp#L66

4:53:06 aeth I've just added a few tests so you can see the massive amounts of boilerplate DEFINE-FUNCTION can save: https://gitlab.com/zombie-raptor/zr-utils/-/blob/24f747564418f65b91df186028655c408fe18244/tests/all.lisp#L68-178

4:53:26 aeth Well, the test cases are simple so it's not entirely apparent, but see e.g. line 166 for one of the more elaborate examples.

4:55:05 aeth stylewarning: I might add some extensibility to DEFINE-FUNCTION and the other macros in the collection to support some other libraries that deal with types, e.g. specialization-store (a type-based generic dispatch, rather than class-based... useful for numbers/sequences) https://github.com/markcox80/specialization-store/

4:55:10 aeth Or Coalton, I guess. If that's at all possible.

4:57:16 aeth (If I do, I'd do it through optional ASDF systems in subdirectories so zr-utils doesn't suddenly depend on half a dozen type-system-expanding CL libraries... or just through exposing an API for those libraries to use)

4:59:12 aeth stylewarning: I'm also considering (when Airship Scheme is more complete) moving some code out of airship-scheme and/or zr-utils to serve as a sort of embedding-languages-in-CL framework...

4:59:34 stylewarning aeth: the Coalton language is really intended to be a scheme like

4:59:45 aeth One of the things that's delaying Airship Scheme is that I'm overengineering the reader in Airship Scheme so it can be upstreamed to the language framework

4:59:47 stylewarning Except one that’s type safe and with type defining operators

5:01:22 aeth I'd really love if Airship Scheme could interoperate in every language that's embedded into CL, not just CL itself. (I know of several: Shen, Clojure (two?), Python, JavaScript, etc.)

5:01:58 aeth I am also considering writing a Lua implementation as a test of this framework, since Lua is a tiny, but notable language.

5:02:32 aeth The idea being that any language that doesn't use s-expressions would first be parsed into a high-level s-expression representation

5:04:04 aeth stylewarning: If your emphasis is on types, then that overlaps quite a bit with Airship Scheme. Scheme is portably only "predecately" typed, e.g. a list is just something that satisfies "list?" which could naively (and inefficiently) just be CL SATISFIES types

5:04:34 aeth But another way to do it would be to generate a CL DEFTYPE and a type predicate at the same time, and maybe even use the ?s at the end of the name for the type since Scheme is a Lisp-1

5:06:23 stylewarning aeth the focus for me is being able to define parametric types (a list-of T) and have them all statically type checked before code is executed (allowing me, in turn, to put safe DECLARES that will never be violated)

5:08:56 aeth Well, statically typed and/or immutable sequences are coming to Airship Scheme at some point, hopefully before milestone 1.0, but if not, then at least for 2.0.

5:09:10 aeth Of course, they'd also be exposed to the CL, via something like https://github.com/Shinmera/trivial-extensible-sequences/

5:09:54 aeth Checking arbitrary, generic CONSes for their contents seems O(n), though

5:10:41 aeth I have a prototype, inconvenient-to-use typed-list/typed-cons using structs here, which I use in a handful of places in my game engine: https://gitlab.com/zombie-raptor/zr-utils/-/blob/24f747564418f65b91df186028655c408fe18244/data-structures.lisp#L48

5:13:52 stylewarning Verifying at runtime it’s true you need O(n) checks

5:16:39 stylewarning Coalton doesn’t need such checks because all functions capable of constructing lists in the first place are also verified

5:17:34 aeth Airship Scheme can't do that because then any use of CLFFI could (and probably would) break the type system

5:18:05 aeth It sounds similar to what TypeScript does afaik, though

5:18:29 stylewarning Right. In Coalton you have to tell Coalton what type your lisp ffi is. If you lie you die and Coalton automatically rm -rf /

5:21:33 stylewarning Lisp ffi example https://github.com/stylewarning/coalton/blob/master/src/library.lisp#L77

5:24:05 aeth stylewarning: here's mine at the moment: https://gitlab.com/mbabich/airship-scheme/-/blob/cbc61ba6390d4c955cc1f7175ae94933387e7490/standard-procedures.lisp

5:24:56 aeth Several things. First, I didn't add the optional static types there yet. I'd probably use pretty similar syntax to DEFINE-FUNCTION... except, of course it would be (define-scheme-procedure (foo (x integer)) ...) instead of (define-function foo ((x integer)) ...) since the idea is to use almost Scheme-like syntax

5:25:47 aeth And second, I'm not quite settled on how to handle arbitrary-length procedures... At the moment, I just use APPLY because if the function's inline, SBCL knows what to do and optimizes it away.

5:26:29 aeth Oh, I suppose the third thing to note is that I do it in CL, not in Scheme, while you seem to do yours in Colton... although in principle I should be able to have parallel macros in Scheme for most things I'm doing in CL.

5:27:21 aeth s/if the function's inline/if the function is inline or a built-in CL function/

5:43:32 contrapunctus stylewarning: "Right. In Coalton you have to tell Coalton what type your lisp ffi is. If you lie you die and Coalton automatically rm -rf /" lmao

6:01:35 fbmnds good morning

6:04:29 fbmnds jackdaniel: (in case you'll see this later) - ECL appears not to have a compare-and-swap implementation (ref. https://github.com/lmj/lparallel/blob/master/src/thread-util.lisp#L113). Is there a known workaround?

6:07:31 fe[nl]ix fbmnds: it does actually, there's mp:compare-and-swap

6:12:28 fbmnds fe[nl]ix: thank you

6:32:30 jackdaniel ftr, I saw this ;) and it deos, thanks fe[nl]ix

7:52:17 shangul Hello guys. A few days ago I started learning ARM assembly(32bit) just for fun. But a little after that a shining lamp appeared above my head: How about optimizing existing CL compilers for ARM so that CL can run as fast as C on ARM, too(as it is already as fast as C on x86 or even sometimes faster). What do you think and what are the requirements for doing so(other than having knowledge of CL and ARM ASM)?

7:53:12 shangul Note that I have not studied the Compiler Design lesson in uni, yet.

8:32:10 beach shangul: All that is required in order to get a Common Lisp implementation to run as fast on ARM as it does on x86 is to apply all the optimization tricks that are documented in the literature of compiler design.

8:33:12 beach shangul: But, let me say this again, it is highly unlikely that any Common Lisp implementation will run as fast as the best C implementation on any modern architecture.

8:34:03 beach The reason is simple. The semantics of the two languages are very different. So to respect the semantics of Common Lisp, more work needs to be done at run-time that what is needed for C.

8:36:07 beach shangul: Furthermore, C compilers exploit a lot of undefined behavior (as the C standard allows them to do) so as to maximize performance, no matter the consequences to safety. A typical example would be array bounds checking. Since the C standard does not require such checks, most C compilers don't generate them.

8:37:14 shangul That's true. But don't you think performance of CL on ARM is too poor comparing to C?

8:38:00 beach Now, there is a lot of undefined behavior in the Common Lisp standard as well, but historically, Common Lisp implementations try to keep the code safe. For a Common Lisp implementation to be as fast as the best C compiler, you would have to change that fact. And then you would have a Common Lisp system that crashes when you make a mistake, rather than signaling an error.

8:38:16 beach I haven't looked into that, actually.

8:38:45 beach But you are probably right. I think told you before that it is simply the case that less time has been spent on optimizations for ARM.

8:39:55 shangul Ok. If I wished to do so, my goal wouldn't be "as fast as C" but "faster than what it is now"

8:40:35 beach Anyway, if you want to start optimizing some existing implementation for ARM, you have a lot to learn first. You need to understand how the implementation represented code in intermediate and low-level form. Then you need to read up on compiler technology (I recommend Muchnick's book for an overview). Finally, you need to implement those techniques.

8:41:13 fbmnds jackdaniel: thx

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:44:54 beach shangul: So the main idea these days is to avoid memory operations if possible.

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:50:03 beach Shall I go on?

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:52:05 shangul I should go but my client is open so that I'll read them later.

8:52:36 beach I think I have said most of what came to mind.

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:34 beach Oh, definitely. But it's a long-term project and it is not going to be easy.

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:42:03 beach You can do that, sure.

9:42:27 beach I would drop the 32-bit version, though.

9:42:39 beach Concentrate on 64-bit.

9:42:50 shangul My current decision's that I don't want to spend a LOT of time on that...

9:42:58 shangul beach, you mean 32 bit ARM?

9:43:02 beach Yeah.

9:43:13 shangul But the device which I've got is 32 bit

9:43:13 beach I think you mentioned 32-bit arm.

9:43:24 beach I see.

9:43:38 shangul Also lots of SBCs have 32 bit ARM rather than 64

9:43:43 shangul let me check to make sure

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:44:21 beach I may be wrong of course.

9:48:25 shka_ it is possible for 32 bits to stick around here and there

9:48:54 shka_ mostly for embedded systems that don't need a lot of memory

9:49:06 shka_ but why would you program that in lisp?

9:49:31 shka_ well, other than "because lisp is cool"

9:53:37 shka_ otherwise, yeah it seems that ARM is the future of the desktops

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:28 phoe or lose the bet

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:01:17 beach phoe: Sure, there is that possibility.

10:01:44 beach But then the RISC-V instruction set would not be too bad for a bytecode interpreter.

10:05:12 shka_ beach: hm, why so high hopes for RISC-V?

10:05:48 beach Because I have read up and I have followed several talks about it.

10:06:30 shka_ and you consider it that good?

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:07:25 shangul They're cute, you know

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:08:25 beach shangul: I take your word for it.

10:08:48 shka_ beach: got it

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:48 shka_ uhm, ok

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:10:23 shka_ well, i am really not a hardware expert

10:10:27 shka_ not a single bit

10:10:34 shka_ so my opinion is not all that important

10:10:38 shka_ or useful

10:11:19 beach I am not an expert either. I studied computer architecture a bit, but that's it.

10:11:27 shka_ common instruction set for GPU and CPU sounds interesting though

10:11:39 beach And disk controllers, and, and ....

10:12:20 shka_ yes, this as well, but well i am in the machine learning crowd

10:12:39 shka_ and this would mean OpenCL would become even better

10:12:55 shka_ so this is why i care

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:14:09 shka_ I will watch some talks anyway, good for treadmill at least :-)

10:14:21 beach Oh, yes, NVIDIA is creating a processor based on RISC-V for machine learning.

10:14:29 shka_ really?

10:14:32 beach Yes.

10:14:36 shka_ this is not very nvidia thing to do

10:15:01 beach NVDLA

10:15:14 beach NVIDIA Deep Learning Accelerator.

10:15:21 shka_ wow

10:16:01 beach I guess I got your attention now? :)

10:16:22 shka_ yes, and i dislike nvidia slightly less now

10:16:33 iissaacc beach, this is interesting, do you have any links to RISC-V stuff you'd recommend

10:16:58 beach I haven't archived any. I would start on YouTube with some recent presentation.

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:23:25 shka_ this reminds me of 80s transputers

10:23:45 beach ... handling multiple values. Memory management, synchronization.

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:25:43 jackdaniel (unlike i.e arm)

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:27:56 wxie1 ** NICK wxie

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:28:56 jackdaniel s/synq/zynq/

10:29:14 beach That's cute.

10:29:27 shka_ that's also why intel bought altera

10:29:54 jackdaniel I can imagine compilation with (declare (optimize (compilation-speed 0) (speed 3))) putting a function as a hardware submodule ;-)

10:29:55 shka_ by putting fpga on the CPU dice, they can fight those pesky semi-custom designs

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)

10:55:58 Lord_of_Life_ ** NICK Lord_of_Life

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:19:09 jackdaniel p_l: ^

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:24:38 jackdaniel s/decode/decoder/

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:25:50 p_l (CAPI nicely enough has a library to generalize attachment to accelerator device)

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:27:37 jackdaniel that said, I think we got into offtopic (what is admittedly my fault)

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

11:59:03 beach froggey: I see.

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:31 loke (setf (get :xim (display-plist DISPLAY)) xim)

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?

12:03:17 lonjil Symbol plist of :xim

12:03:34 phoe you meant getf

12:04:12 beach That's nasty.

12:07:20 shka_ i think it is funny :-)

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:24:44 phoe C-Mera possibly?

13:24:59 lukego somehow it feels weird that only the top-level object is a presentation

13:25:04 SAL9000_ ** NICK SAL9000

13:25:04 lukego (how was it on Genera?)

13:25:45 beach lukego: You can try the CLIM listener if you want to do stuff like that.

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:03 beach And by "give up Emacs" I mean just for editing Common Lisp code.

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:08:36 lukego not so much the programming features as the general "power user" feel

14:10:08 beach Yes, I see.

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:04 p_l Things like tracing macros, or working WHO-CALLS database

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:16:23 p_l I've been needling someone to fund my LW obsession just so I could easily make a GUI

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:31:54 beach In Bordeaux, at LSM/RMLL.

14:33:39 beach I needed a GUI library for Gsharp, so I got the ball rolling.

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:36:21 beach I am, yes.

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:41:13 jackdaniel beach: did you manage to start clovetree?

14:41:39 beach jackdaniel: I haven't had time to try it yet. I'll do that now.

14:41:50 jackdaniel no rush, I was just worried that you've encountered some problems

14:41:58 beach Not yet. :)

14:42:01 jackdaniel hah

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:51:39 SAL9000 lukego: plus routing rules for certain signal types, on top of that

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

14:59:48 aap_ ** NICK aap

15:03:07 beach jackdaniel: I can execute it no problem.

15:03:32 beach I'll play around with it during the coming week.

15:03:51 beach But I need to finish my presentation for the online Lisp meeting first.

15:04:14 loke phoe: yeah, I ended up setting the NIL member of :XIM's plist :-)

15:05:01 Josh_2 afternoon

15:10:37 jackdaniel beach: thanks for confirmation

15:11:03 Josh_2 how do I see the lisp meeting?

15:11:47 easye Josh_2: the Online Lisp Meeting? It will be streamed through twitch.tv, and later available on YouTube.

15:11:57 Josh_2 okay

15:12:05 Josh_2 Is there gonna be a notification in here?

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:22:04 phoe Josh_2: I'll post a few minutes before it begins

15:22:12 phoe the mailgroup has an ical invitation

15:22:30 Josh_2 how do I add myself to that?

15:22:37 phoe https://mailman.common-lisp.net/listinfo/online-lisp-meets

15:24:09 Josh_2 Awesome thanks

15:28:21 nirved lukego: one could display images in repl, here is a svg example: https://gist.github.com/nirved/e59aa01f2cd6d75ca6d5dde08c037519

15:44:32 lukego nirved: thanks!

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:45:56 phoe yep

15:45:58 phoe what's up?

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:49:19 thetabit appropriate to use all the time?

15:49:34 phoe eww

15:49:43 phoe that sounds like a SQL injection simulator

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:51:46 phoe oh, you mean that you use Lisp to produce source code for other people

15:51:57 thetabit correct

15:51:59 phoe so not in actual application code

15:52:04 thetabit correct

15:52:05 phoe I guess that works well enough then

15:53:36 Josh_2 Does this mean you have a common lisp to PHP library :P

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:55:39 Josh_2 thats pretty awesome

15:55:56 Josh_2 maybe you could make this library public?

15:56:15 thetabit _death, thanks for that article, I've been looking for counter arguments

15:56:38 thetabit Josh, yeah, I will probably release the generalized code

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:00:24 Josh_2 yes that is very cool

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)