<Oladon>
Anyone around with experience in parser combinators? I'm trying to do two things with bbcode-tag (L90): 1) make it work, and 2) make it recursive. https://pastebin.com/an96mFSK
<Oladon>
I'm pretty new to the concept of parser combinators, so I suspect I'm missing something fairly obvious.
markoong has quit [Ping timeout: 256 seconds]
emys has quit [Ping timeout: 264 seconds]
iissaacc has joined #lisp
<iissaacc>
any postmodern experts here
<Oladon>
iissaacc: Best to just ask your question. :)
<iissaacc>
trying to insert a dao with a nil in one of the slots, getting the following error. I can't find anythng in the manual about how nils in daos are treated
<iissaacc>
Database error 22007: invalid input syntax for type timestamp: "false"
<iissaacc>
i assume I'll have to convert the nil to db-null before i do the (insert-dao dao)
<aeth>
Ah, I see why... it uses a heuristic system, and any "define" with no "defun" (or I guess not enough "defun"s since you have one) is seen as NewLisp... which leads to quite a few false positives even without custom macros since sometimes people have files with only DEFINE-CONDITIONs in them.
<aeth>
Alternatively, they do recognize emacs modes in the header (well, I know Gitlab does) so you could just add ";;;; -*- mode: common-lisp; -*-" to the top of that file.
kinope has joined #lisp
space_otter has joined #lisp
<stylewarning>
aeth: is LOOP a different language that compiles to CL? If yes, then yes Coalton is
<stylewarning>
Ty for newlisp note
<stylewarning>
aeth: my hope is that Coalton can be compiled and type checked at macro time and expand into efficient Common Lisp code
<stylewarning>
I don’t want it to be a language atop Lisp as much as a language within Lisp
<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
emys has joined #lisp
<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.
<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.
<stylewarning>
I want the usual Lisp reader to work
<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.
remexre has joined #lisp
<aeth>
Also INTERNing is the most notable exception to the no-side-effects-in-macro rule, since INTERNing twice isn't problematic.
johntalent has quit [Quit: leaving]
<aeth>
I guess DEFUNs are similar.
emys has quit [Ping timeout: 272 seconds]
<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
<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.
<aeth>
And changing the type would just be redefining functions.
<stylewarning>
Kind of kooky but I dig it
<stylewarning>
Using FDEFINITIONS and symbols as a database itself
<stylewarning>
The difficult part is setting and querying still. I think I’d have to EVAL or SETF FDEF to get that to work
<aeth>
I was thinking along the lines of generating `(defun coalton.type:foo () 'whatever-you-use-for-types)
<aeth>
Then you'd just get it with (coalton.type:foo)
<stylewarning>
Yes I understand
<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)
<aeth>
(In case you haven't encountered that before)
<stylewarning>
But I need to change and query that value at macro time
<stylewarning>
Not just generate a value which I can play with at runtime
<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
<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.
<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).
<stylewarning>
Yeah I would lobby for that
<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.
<stylewarning>
Is it possible to define a new component type? We do that for compiling C libraries
<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.
<aeth>
If you just copy and paste the implementation of the .lisp stuff (through quite a few files) I think it would work
<aeth>
But that just seems wrong...
<stylewarning>
That converts a FORTRAN file into a .so via an ASDF component
<aeth>
ah
<stylewarning>
The definition for that is above
<aeth>
Does that use its own file extension, distinct from .lisp? Coalton might need its own extension.
<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
<stylewarning>
If airship scheme is a scheme compiled to Lisp in Lisp that sounds awesome
<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
<aeth>
Ideally, a custom extension in ASDF with before/after stuff would just produce .FASLs and reuse almost all of ASDF's CL machinery.
OpenZen has quit [Ping timeout: 258 seconds]
<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
<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
<stylewarning>
Sounds like airship and Coalton would need to solve a lot of the same problems
<stylewarning>
Lexical bonding, file compilation, an “FFI”
<stylewarning>
bonding lol
<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
<aeth>
Well that and guaranteed tail recursion.
<aeth>
Afaik, continuation passing style + thunks + trampoline will solve that, not that much boilerplate, and almost all of it handled by macros
<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.
<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/
<aeth>
Or Coalton, I guess. If that's at all possible.
<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)
<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...
<stylewarning>
aeth: the Coalton language is really intended to be a scheme like
<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
<stylewarning>
Except one that’s type safe and with type defining operators
Retropikzel has quit [Quit: Konversation terminated!]
<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.)
<aeth>
I am also considering writing a Lua implementation as a test of this framework, since Lua is a tiny, but notable language.
emys has joined #lisp
<aeth>
The idea being that any language that doesn't use s-expressions would first be parsed into a high-level s-expression representation
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<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
<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
anatrope has joined #lisp
<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)
kleptoflora has quit [Ping timeout: 265 seconds]
<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.
<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
<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.
<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.
<aeth>
s/if the function's inline/if the function is inline or a built-in CL function/
emys has quit [Ping timeout: 272 seconds]
emys has joined #lisp
troydm has quit [Quit: What is Hope? That all of your wishes and all of your dreams come true? To turn back time because things were not supposed to happen like that (C) Rau Le Creuset]
troydm has joined #lisp
emys has quit [Ping timeout: 246 seconds]
<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
<fe[nl]ix>
fbmnds: it does actually, there's mp:compare-and-swap
emys has joined #lisp
<fbmnds>
fe[nl]ix: thank you
wxie has joined #lisp
fe[nl]ix has quit [Remote host closed the connection]
Blkt has quit [Read error: Connection reset by peer]
Blkt has joined #lisp
fe[nl]ix has joined #lisp
karlosz has quit [Quit: karlosz]
ukari has quit [Remote host closed the connection]
fbmnds has left #lisp [#lisp]
ukari has joined #lisp
fbmnds has joined #lisp
fbmnds has quit [Quit: Connection closed]
<jackdaniel>
ftr, I saw this ;) and it deos, thanks fe[nl]ix
emys has quit [Ping timeout: 260 seconds]
ukari has quit [Remote host closed the connection]
ukari has joined #lisp
technobean has left #lisp ["WeeChat 2.8"]
bsd4me has quit [Quit: Leaving]
brown121407 has joined #lisp
technobean has joined #lisp
ahungry has quit [Remote host closed the connection]
orivej has joined #lisp
karlosz has joined #lisp
emys has joined #lisp
scymtym has joined #lisp
zaquest has quit [Quit: Leaving]
wxie has quit [Ping timeout: 260 seconds]
zaquest has joined #lisp
emys has quit [Ping timeout: 260 seconds]
brown121407 has quit [Remote host closed the connection]
emys has joined #lisp
emys has quit [Ping timeout: 240 seconds]
dislocated has left #lisp ["ERC (IRC client for Emacs 26.1)"]
whiteline has joined #lisp
Oladon has quit [Quit: Leaving.]
shangul has joined #lisp
brown121407 has joined #lisp
Retropikzel has quit [Ping timeout: 256 seconds]
orivej_ has joined #lisp
orivej has quit [Ping timeout: 256 seconds]
<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)?
pve has joined #lisp
<shangul>
Note that I have not studied the Compiler Design lesson in uni, yet.
orivej_ has quit [Ping timeout: 256 seconds]
orivej has joined #lisp
liberliver has joined #lisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #lisp
karlosz has quit [Quit: karlosz]
ukari has quit [Ping timeout: 260 seconds]
ukari has joined #lisp
mankaev has quit [Ping timeout: 272 seconds]
bhartrihari has joined #lisp
mankaev has joined #lisp
Lycurgus has quit [Remote host closed the connection]
mankaev has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
Necktwi has quit [Ping timeout: 240 seconds]
<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.
mankaev has joined #lisp
<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.
<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.
<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.
<shangul>
That's true. But don't you think performance of CL on ARM is too poor comparing to C?
<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.
<beach>
I haven't looked into that, actually.
<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.
<shangul>
Ok. If I wished to do so, my goal wouldn't be "as fast as C" but "faster than what it is now"
<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.
fbmnds has joined #lisp
<fbmnds>
jackdaniel: thx
<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.
<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.
fbmnds has left #lisp [#lisp]
<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.
<beach>
shangul: So the main idea these days is to avoid memory operations if possible.
<beach>
shangul: Oh, and then you need to read up on synchronization, because we must now plan for thread safety.
<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.
Guest98444 has joined #lisp
<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.
<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.
<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.
<beach>
Shall I go on?
<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.
<shangul>
I should go but my client is open so that I'll read them later.
kapil_ has joined #lisp
<beach>
I think I have said most of what came to mind.
<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.
lerax has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 264 seconds]
orivej has joined #lisp
iissaacc has joined #lisp
Retropikzel has joined #lisp
ayuce has joined #lisp
ukari has quit [Remote host closed the connection]
ukari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
anatrope has joined #lisp
kleptoflora has quit [Ping timeout: 240 seconds]
bhartrihari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
EvW1 has joined #lisp
bhartrihari has joined #lisp
luna_is_here_ has quit [Ping timeout: 240 seconds]
<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.
<beach>
Oh, definitely. But it's a long-term project and it is not going to be easy.
<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?
<beach>
You can do that, sure.
<beach>
I would drop the 32-bit version, though.
<beach>
Concentrate on 64-bit.
<shangul>
My current decision's that I don't want to spend a LOT of time on that...
<shangul>
beach, you mean 32 bit ARM?
<beach>
Yeah.
luna_is_here has joined #lisp
<shangul>
But the device which I've got is 32 bit
<beach>
I think you mentioned 32-bit arm.
<beach>
I see.
<shangul>
Also lots of SBCs have 32 bit ARM rather than 64
<shangul>
let me check to make sure
<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.
<beach>
I may be wrong of course.
gigetoo has quit [Ping timeout: 256 seconds]
gigetoo has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
<shka_>
it is possible for 32 bits to stick around here and there
<shka_>
mostly for embedded systems that don't need a lot of memory
<shka_>
but why would you program that in lisp?
<shka_>
well, other than "because lisp is cool"
bhartrihari has left #lisp ["Disconnected: closed"]
bhartrihari has joined #lisp
<shka_>
otherwise, yeah it seems that ARM is the future of the desktops
Guest98444 has quit [Ping timeout: 256 seconds]
edgar-rft has joined #lisp
<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.
<phoe>
or lose the bet
<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.
<beach>
phoe: Sure, there is that possibility.
<beach>
But then the RISC-V instruction set would not be too bad for a bytecode interpreter.
brown121407 has quit [Remote host closed the connection]
<shka_>
beach: hm, why so high hopes for RISC-V?
<beach>
Because I have read up and I have followed several talks about it.
terpri__ has joined #lisp
<shka_>
and you consider it that good?
<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.
<shangul>
They're cute, you know
<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.
<beach>
shangul: I take your word for it.
<shka_>
beach: got it
orivej has quit [Ping timeout: 265 seconds]
orivej_ has joined #lisp
ukari has quit [Ping timeout: 240 seconds]
<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.
terpri_ has quit [Ping timeout: 260 seconds]
<shka_>
uhm, ok
<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.
<shka_>
well, i am really not a hardware expert
<shka_>
not a single bit
<shka_>
so my opinion is not all that important
<shka_>
or useful
<beach>
I am not an expert either. I studied computer architecture a bit, but that's it.
<shka_>
common instruction set for GPU and CPU sounds interesting though
<beach>
And disk controllers, and, and ....
shangul has quit [Ping timeout: 265 seconds]
<shka_>
yes, this as well, but well i am in the machine learning crowd
<shka_>
and this would mean OpenCL would become even better
<shka_>
so this is why i care
ukari has joined #lisp
<beach>
I took a graduate-level course for Jim Goodman the inventor of the cache-coherence protocol, and of the speculative lock-elision protocol.
<shka_>
I will watch some talks anyway, good for treadmill at least :-)
<beach>
Oh, yes, NVIDIA is creating a processor based on RISC-V for machine learning.
<shka_>
really?
<beach>
Yes.
<shka_>
this is not very nvidia thing to do
<beach>
NVDLA
<beach>
NVIDIA Deep Learning Accelerator.
<shka_>
wow
<beach>
I guess I got your attention now? :)
<shka_>
yes, and i dislike nvidia slightly less now
<iissaacc>
beach, this is interesting, do you have any links to RISC-V stuff you'd recommend
<beach>
I haven't archived any. I would start on YouTube with some recent presentation.
narimiran has quit [Ping timeout: 240 seconds]
shangul has joined #lisp
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
ukari has quit [Ping timeout: 256 seconds]
wxie has joined #lisp
orivej has joined #lisp
<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.
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
<jackdaniel>
the key feature (from adoption perspective) it is that it doesn't require royalty fees for implementing it in hardware
<jackdaniel>
(unlike i.e arm)
<beach>
Exactly. That's what I meant by "not being controlled by a commercial company", but you are right to emphasize that.
wxie1 has joined #lisp
<beach>
And since the instruction set is extensible, people who are into such things could figure out some extension for Common Lisp.
wxie has quit [Ping timeout: 256 seconds]
wxie1 is now known as wxie
orivej has quit [Quit: No Ping reply in 180 seconds.]
<beach>
More generally, figure out how to best use the existing instruction set(s) for executing Common Lisp code.
<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 :)
<jackdaniel>
s/synq/zynq/
<beach>
That's cute.
<shka_>
that's also why intel bought altera
orivej has joined #lisp
markong has joined #lisp
<jackdaniel>
I can imagine compilation with (declare (optimize (compilation-speed 0) (speed 3))) putting a function as a hardware submodule ;-)
<shka_>
by putting fpga on the CPU dice, they can fight those pesky semi-custom designs
markoong has quit [Ping timeout: 264 seconds]
ukari has quit [Ping timeout: 240 seconds]
<jackdaniel>
it depends on size of the fpga (i.e how much you can put on it and how many pins are available)
<lukego>
Hey is there an easy way to see SBCL IR code? like an IR version of DISASSEMBLE or suchlike?
<shka_>
actually, now when i think about it, it is possible that there will be flood of semi custom RISC-V at some point
ukari has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
orivej has joined #lisp
wxie has quit [Ping timeout: 260 seconds]
wxie has joined #lisp
<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.
random-nick has joined #lisp
terpri_ has joined #lisp
<lonjil>
(And hopefully, a few years after that, RISC-V is mature enough for the CPUs of any new supercomputers)
Lord_of_Life_ has joined #lisp
orivej has quit [Ping timeout: 260 seconds]
orivej_ has joined #lisp
terpri__ has quit [Ping timeout: 260 seconds]
Lord_of_Life has quit [Ping timeout: 260 seconds]
Lord_of_Life_ is now known as Lord_of_Life
wxie has quit [Ping timeout: 240 seconds]
<p_l>
jackdaniel: the speed drop of talking to the FPGA side is significant enough that it won't work that nice
space_otter has quit [Remote host closed the connection]
<jackdaniel>
phoe: programming fpga is slow, but other than that it is ordinary hardware device
wxie has joined #lisp
<jackdaniel>
p_l: ^
fanta1 has joined #lisp
<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)
wxie has quit [Ping timeout: 246 seconds]
<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)
<jackdaniel>
s/decode/decoder/
<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
<p_l>
(CAPI nicely enough has a library to generalize attachment to accelerator device)
EvW1 has quit [Ping timeout: 260 seconds]
<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
<jackdaniel>
that said, I think we got into offtopic (what is admittedly my fault)
lerax has joined #lisp
<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
d4ryus has joined #lisp
borodust has quit [Remote host closed the connection]
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
EvW has joined #lisp
vornth has joined #lisp
vornth has quit [Read error: Connection reset by peer]
orivej_ has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
<beach>
froggey: I see.
<beach>
froggey: Do you mean "complicates" in that the GC has to know which registers contain Common Lisp objects and which registers don't?
<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:
<loke>
everything worked fine, but for some reason I never saw the plist itself change. Pop quiz: What did I actually do?
<lonjil>
Symbol plist of :xim
<phoe>
you meant getf
<beach>
That's nasty.
<shka_>
i think it is funny :-)
notzmv has quit [Remote host closed the connection]
notzmv has joined #lisp
orivej_ has quit [Ping timeout: 260 seconds]
bitmapper has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
<froggey>
beach: no, complicates as in the GC now needs to efficiently be able to convert interior pointers back to there original objects
<froggey>
assuming that the GC can interrupt the program at mostly arbitrary points
Codaraxis_ has joined #lisp
rixard_ has joined #lisp
minion has quit [Disconnected by services]
minion has joined #lisp
<froggey>
it's not a particularly difficult issue to resolve, but it's just more added work
technobe` has joined #lisp
aap_ has joined #lisp
Misha_B` has joined #lisp
Harag` has joined #lisp
mgsk- has joined #lisp
jurov_ has joined #lisp
johnweldon has joined #lisp
aindilis` has joined #lisp
mangul has joined #lisp
ukari has quit [Ping timeout: 256 seconds]
<beach>
froggey: Oh, I was just thinking of making sure that the original object is still referred to, either by a different register or by some stack location.
logicmoo has joined #lisp
ayuce` has joined #lisp
<beach>
Also, I would think it is already complicated to allow for a GC to happen at any point in time.
<froggey>
right. that's reasonable a solution, tying the register that holds the interior pointer to another register (or stack location) that holds the original object
jbgg_ has joined #lisp
<beach>
Yeah.
vert2_ has joined #lisp
srji_ has joined #lisp
flip214_ has joined #lisp
<beach>
And RISC-V has plenty of registers.
em-bee has joined #lisp
wooden_ has joined #lisp
shrysr_ has joined #lisp
SAL9000_ has joined #lisp
ukari has joined #lisp
kopiyka has quit [Remote host closed the connection]
seisatsu_ has joined #lisp
narendraj9_ has joined #lisp
EvW has quit [Ping timeout: 260 seconds]
shangul has quit [*.net *.split]
ayuce has quit [*.net *.split]
technobean has quit [*.net *.split]
gaqwas has quit [*.net *.split]
rixard has quit [*.net *.split]
srji has quit [*.net *.split]
jw4 has quit [*.net *.split]
flip214 has quit [*.net *.split]
Misha_B has quit [*.net *.split]
aindilis has quit [*.net *.split]
wooden has quit [*.net *.split]
Codaraxis has quit [*.net *.split]
Harag has quit [*.net *.split]
jurov has quit [*.net *.split]
narendraj9 has quit [*.net *.split]
jbgg has quit [*.net *.split]
aap has quit [*.net *.split]
bacterio has quit [*.net *.split]
getha has joined #lisp
catern has quit [*.net *.split]
eMBee has quit [*.net *.split]
samebchase has quit [*.net *.split]
mgsk_ has quit [*.net *.split]
dmiles has quit [*.net *.split]
sukaeto has quit [*.net *.split]
Colleen has quit [*.net *.split]
APic has quit [*.net *.split]
tychoish has quit [*.net *.split]
karstensrage has quit [*.net *.split]
SAL9000 has quit [*.net *.split]
shrysr has quit [*.net *.split]
seisatsu has quit [*.net *.split]
thijso has quit [*.net *.split]
vert2 has quit [*.net *.split]
narendraj9_ is now known as narendraj9
v88m has quit [Remote host closed the connection]
Colleen has joined #lisp
tychoish has joined #lisp
thecoffemaker has quit [Ping timeout: 246 seconds]
karstensrage_ has joined #lisp
v88m has joined #lisp
thecoffemaker has joined #lisp
sukaeto has joined #lisp
bacterio has joined #lisp
APic has joined #lisp
samebchase has joined #lisp
catern has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
wxie has joined #lisp
terpri has joined #lisp
terpri_ has quit [Ping timeout: 260 seconds]
Inline has joined #lisp
vornth has joined #lisp
heisig has joined #lisp
Inline has quit [Client Quit]
Inline has joined #lisp
Bike has joined #lisp
random-nick has quit [Ping timeout: 240 seconds]
<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
random-nick has joined #lisp
<lukego>
I saw there was an ELS talk about Lisp generating C/C++/CUDA recentlyish, looked really interesting I thought
wxie has quit [Ping timeout: 265 seconds]
iissaacc has quit [Ping timeout: 265 seconds]
<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?
<phoe>
C-Mera possibly?
<lukego>
somehow it feels weird that only the top-level object is a presentation
SAL9000_ is now known as SAL9000
<lukego>
(how was it on Genera?)
<beach>
lukego: You can try the CLIM listener if you want to do stuff like that.
<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.
<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.
<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
<lukego>
I wonder if Emacs could draw things too e.g. inline SVG. I'm not sure how that support is nowadays realistically.
elflng has quit [Read error: Connection reset by peer]
borodust has joined #lisp
elflng has joined #lisp
<lukego>
I've been meaning to try using org-babel instead of the REPL but old habbits are hard to break..
ukari has quit [Ping timeout: 240 seconds]
ukari has joined #lisp
<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.)
johnweldon has quit [Read error: Connection reset by peer]
jw4 has joined #lisp
<beach>
We are working on making it less painful to give up Emacs. But it's going to take some more time.
<beach>
And by "give up Emacs" I mean just for editing Common Lisp code.
<beach>
And, yes, I am aware that there are advantages to having a single editor for everything.
<beach>
But the plan is to make the Common Lisp editor so good for editing Common Lisp code that it is irresistible.
<lonjil>
Will work well for me, since I already only use Emacs for CL. (Mostly Vim for everything else)
lerax has quit [Remote host closed the connection]
terpri_ has joined #lisp
Bourne has joined #lisp
iissaacc has joined #lisp
terpri has quit [Ping timeout: 256 seconds]
elflng has quit [Read error: Connection reset by peer]
elflng has joined #lisp
renzhi has joined #lisp
iissaacc has quit [Ping timeout: 256 seconds]
Necktwi has joined #lisp
<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.
<lukego>
I've been using Blender a bit lately and that whole UI is just completely ❤️ that it makes Emacs feel like pico.
terpri_ has quit [Remote host closed the connection]
<lukego>
not so much the programming features as the general "power user" feel
terpri_ has joined #lisp
<beach>
Yes, I see.
<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
<p_l>
Things like tracing macros, or working WHO-CALLS database
<p_l>
lukego: as for CL generating code for smaller embedded system, that's how at least the original Roomba was programmed
<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.
<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.
heisig has quit [Quit: Leaving]
<p_l>
I've been needling someone to fund my LW obsession just so I could easily make a GUI
arpunk has joined #lisp
<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.
TwoNotes has joined #lisp
iissaacc has joined #lisp
Inline has quit [Ping timeout: 265 seconds]
kopiyka has joined #lisp
iissaacc has quit [Ping timeout: 260 seconds]
<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.
<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.
aindilis` has quit [Remote host closed the connection]
<beach>
In Bordeaux, at LSM/RMLL.
<beach>
I needed a GUI library for Gsharp, so I got the ball rolling.
aindilis has joined #lisp
ukari has quit [Remote host closed the connection]
<lukego>
Are you still are Bordeaux, btw? (pardon my out of the loopedness, haven't been keeping up much since ECLMs)
elflng has quit [Read error: Connection reset by peer]
<beach>
I am, yes.
elflng has joined #lisp
jesse1010 has joined #lisp
<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 :)
<jackdaniel>
beach: did you manage to start clovetree?
<beach>
jackdaniel: I haven't had time to try it yet. I'll do that now.
<jackdaniel>
no rush, I was just worried that you've encountered some problems
<beach>
Not yet. :)
<jackdaniel>
hah
<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
<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)
<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
elflng has quit [Read error: Connection reset by peer]
elflng has joined #lisp
<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.
<SAL9000>
lukego: plus routing rules for certain signal types, on top of that
<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 :)
<SAL9000>
e.g. the traces for USB differential pairs have to have equal length to within a certain precision
<jackdaniel>
embedded systems are a lot of fun, but eventually you get fed up with C and Verilog
elflng has quit [Read error: Connection reset by peer]
elflng has joined #lisp
bitmapper has joined #lisp
aap_ is now known as aap
<beach>
jackdaniel: I can execute it no problem.
elflng has quit [Read error: Connection reset by peer]
<beach>
I'll play around with it during the coming week.
<beach>
But I need to finish my presentation for the online Lisp meeting first.
elflng has joined #lisp
<loke>
phoe: yeah, I ended up setting the NIL member of :XIM's plist :-)
<Josh_2>
afternoon
elflng has quit [Read error: Connection reset by peer]
elflng has joined #lisp
<jackdaniel>
beach: thanks for confirmation
<Josh_2>
how do I see the lisp meeting?
<easye>
Josh_2: the Online Lisp Meeting? It will be streamed through twitch.tv, and later available on YouTube.
<Josh_2>
okay
<Josh_2>
Is there gonna be a notification in here?
borodust has quit [Remote host closed the connection]
RedMallet has joined #lisp
dredrim has joined #lisp
thetabit has joined #lisp
<lukego>
nirved: thanks!
<lukego>
maybe swank:eval-in-emacs could be abused in a lot of interesting and convenient ways..
<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?
<phoe>
yep
<phoe>
what's up?
<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
<thetabit>
appropriate to use all the time?
<phoe>
eww
<phoe>
that sounds like a SQL injection simulator
<phoe>
postmodern has its own S-expression based DSL for generating SQL that should work better than operating on raw strings
<phoe>
I mean, (format nil "SELECT ~A FROM users;" ...) is easily abusable if the user somehow controls ~A
<thetabit>
yes, this is just for me for producing the source code, that is committed so no other devs are using this
<phoe>
oh, you mean that you use Lisp to produce source code for other people
<Josh_2>
Does this mean you have a common lisp to PHP library :P
<pve>
thetabit: you probably need to apply some kind of escape function to some (all?) of your format arguments
<_death>
thetabit: such an operator can be further extended so that you can easily generate ad-hoc code
<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
<Josh_2>
thats pretty awesome
<Josh_2>
maybe you could make this library public?
<thetabit>
_death, thanks for that article, I've been looking for counter arguments
<thetabit>
Josh, yeah, I will probably release the generalized code
iissaacc has joined #lisp
<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 ;)
<_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)
nckx has joined #lisp
orivej_ has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
<thetabit>
whoa
terpri__ has joined #lisp
terpri_ has quit [Ping timeout: 260 seconds]
Jeanne-Kamikaze has joined #lisp
cosimone has joined #lisp
<Oladon>
Anyone know if eugeneia hangs out here under some other name?
<phoe>
I think I remember that he used to use the handle mrottenkolber
<Oladon>
Hrm, well, that's not promising -- auto away on 3/25
<Oladon>
phoe: Thankee for the helpful information.
orivej has quit [Quit: No Ping reply in 180 seconds.]
<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
<phoe>
s/yet/now/
orivej has joined #lisp
entel has joined #lisp
Jesin has quit [Quit: Leaving]
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
terpri__ is now known as terpri
borodust has joined #lisp
abhixec has joined #lisp
frgo_ has joined #lisp
lambda-smith has joined #lisp
frgo has quit [Ping timeout: 260 seconds]
akoana has left #lisp ["Leaving"]
ukari has quit [Ping timeout: 240 seconds]
mangul has quit [Ping timeout: 256 seconds]
ukari has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
Jesin has joined #lisp
orivej has joined #lisp
lambda-smith has quit [Remote host closed the connection]
lambda-smith has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
Inline has quit [Ping timeout: 256 seconds]
terpri_ has joined #lisp
ukari has quit [Ping timeout: 256 seconds]
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
lambda-smith has quit [Remote host closed the connection]
terpri has quit [Ping timeout: 256 seconds]
ukari has joined #lisp
<adlai>
shka_: please please PLEASE DEAR GOD don't ever make that fucking dies/dice typo ever ever again
<phoe>
adlai: huh
lambda-smith has joined #lisp
<adlai>
phoe: perhaps an intended pun got run over by the chat.
<phoe>
I can't see shka_ saying "dies", at least according to the tymoon log
<phoe>
it should, but it isn't - welcome to English
<phoe>
the greatest living statue of backwards compatibility on Earth.
<adlai>
no thank you, welcome to "live languages can shock your nuts off if you listen to grammarly"
<phoe>
I consider that to be equivalent
<adlai>
this conversation is henceforth off-topic.
ukari has quit [Ping timeout: 256 seconds]
* adlai
reads that blog post with baited fangs
shangul has joined #lisp
<phoe>
truth is, that conversation was off topic from the start
* phoe
cocks gun
ukari has joined #lisp
<Oladon>
So... Lisp... anyone have any experience with maxpc, and/or want to help me figure it out? :P
<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
<Oladon>
phoe: *dangles Lispy problem*
<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.
<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.
<Oladon>
In cl-parser-combinators you'd use mdo for that
adlai has left #lisp [""enjoy your cretes""]
<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
<Oladon>
I.e. I'm trying to parse "bxb" or "cxc" or "dxd" but ensure that the last letter matches the first
<shka_>
Oladon: well, do you know how parser combinators work internally?
Misha_B` has quit [Remote host closed the connection]
Misha_B` has joined #lisp
Misha_B` has quit [Client Quit]
<shka_>
Oladon: so the thing is you are describing is not a context free grammar AFAIK
Misha_B has joined #lisp
<shka_>
while you gonna need recursive context
<shka_>
in a form of stack probably
<shka_>
anyway, you will likely need some other parser
karlosz has joined #lisp
<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.
<shka_>
oh, how?
<shka_>
as is: can you show your source code
<Oladon>
Is that going to help you help somehow?
<shka_>
no, i am just curious, i was not expecting this to be possible
<shka_>
sorry for bothering you
<Oladon>
You're fine, just tone is hard to read over chat.
<Oladon>
In cl-parser-combinators there's a monadic do (mdo) which allows you to use <- for binding.
<Oladon>
So you can do (mdo (<- x1 parser1) (<- x2 (parser2 x1)))
<shka_>
yeah, i just checked how it is implemented
<shka_>
clever!
<Oladon>
indeed
<Oladon>
So I figure there must be something analogous in maxpc, just can't quite figure it out
<shka_>
i wouldn't be so sure about this
<shka_>
that mdo trick goes ever so slightly over the parser combinators paradgim
gaqwas has quit [Remote host closed the connection]
gigetoo has quit [Ping timeout: 256 seconds]
gigetoo has joined #lisp
<Bike>
seok: yes, you can use &rest and &key together. what's the error?
<_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
<seok>
so when calling with key, do I need to (query (:auth x) body) ?
<_death>
also note that the default value is the symbol *auth*, not the value of *auth* at macroexpansion time
<seok>
Right
<_death>
yes
<seok>
Actually I was trying to get around that
<seok>
This is not the way eh?
<_death>
around what?.. if you're determined to use your original syntax, you can do that
Inline has joined #lisp
<seok>
I want to use the value for *auth*
<seok>
So I need a function with quotes then?
<_death>
the value at macroexpansion time? unlikely that you want that
<seok>
the preset value
<_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
<seok>
I want to use the value for *auth* at the time of macro definition
<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.
<_death>
seok: that makes even less sense to me
<_death>
aeth: fasls may not even be portable across CL implementation versions..
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
mercourisj has joined #lisp
<_death>
aeth: for example sbcl fasl format has a version field, and I don't think it supports values other than the "current version"
<aeth>
_death: I wonder if that makes semver impossible, since every release would be a breaking one
iissaacc has joined #lisp
jonathanschlink has joined #lisp
arpunk has quit [Remote host closed the connection]
deselby has quit [Quit: Idle for 30+ days]
gaqwas has quit [Remote host closed the connection]
iissaacc has quit [Ping timeout: 265 seconds]
<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.
ggole has quit [Quit: Leaving]
<mercourisj>
what does it mean for emacs to be 'sticky'?
<lukego>
in the sense that it would take a strong force to pull a person away from.
fanta1 has quit [Quit: fanta1]
<pve>
is it good or bad that Pharo is its own world?
<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.
mercourisj has quit [Remote host closed the connection]
<pve>
ah! a smalltalk fan!
<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.
<lukego>
well love-hate with smalltalk. I hack some smalltalk every ten years and then flame out after some weeks or months :)
<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 :)
<pve>
I'm implementing a kind of smalltalk-in-lisp, it's been really fun
<lukego>
maybe that's why I get nostalgic for Lisp now. Hard to get shit done without a stable foundation to work from.
<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
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #lisp
<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 :)
easye` has joined #lisp
specbot has quit [Remote host closed the connection]
specbot has joined #lisp
iissaacc has joined #lisp
easye has quit [Ping timeout: 272 seconds]
<lukego>
pve: cool :)
<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 :)
<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 :)
<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 :)
<lukego>
pve: I don't think I've ever seen a Lisp-Smalltalk hybrid actually? seems to make potentially a lot of sense :)
<lukego>
if it's public I'd be curious to see :)
abhixec has quit [Ping timeout: 258 seconds]
<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
TwoNotes has quit [Quit: Leaving]
<pve>
I'm cleaning it up as we speak, going to throw it up on github hopefully soonish
<lukego>
cool :)
<pve>
hmm I had some pictures of what it looks like at least, hold on
iissaacc has quit [Ping timeout: 260 seconds]
<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.
<pve>
the first picture defines a source file class for the loader, the second does some asdf integration
<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
<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.
<lukego>
aeth: Maybe. CMUCL had Hemlock but it felt like I was one of maybe three people in the world using it :)
bsd4me has joined #lisp
<lukego>
looks very intriguing pve :)
<pve>
lukego: thanks
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
<lukego>
oh hey I have the clim listener running now :) just kludged in another hard coded path to look for truetype fonts
<lukego>
climacs too
<aeth>
lukego: yeah, but the thing is, it's not Emacs, it's GNU Emacs. GNU Emacs has GNU, which is a little more popular than CMUCL, especially in the 90s
<lukego>
clouseau is fun :)
<p_l>
lukego: seems like a lot of people like and use Hemlock, though not necessarily under that name ;)
<lukego>
lispworks you mean?
<lukego>
ok really bedtime now
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
<aeth>
I mean, being more popular than the official editor of GNU-as-a-platform isn't really an impossible advantage to beat these days. Emacs' moat has probably never been smaller.