libera/#commonlisp - IRC Chatlog
Search
21:32:18
_death
I don't mind my PRs languishing in other projects so much, because I just use my own fork.. if I submit a patch to a project and I get no reply, I just avoid submitting more patches, but I continue to patch my own fork
21:34:25
_death
EdLangley[m]: no.. the reason I submitted those in the first place was because I was asked.. but I don't mind that they weren't merged (though the other user of tree-sitter may feel differently?), and maybe there are better solutions to those problems in the future anyway
21:34:46
_death
EdLangley[m]: one of them breaks backwards compatibility, so indeed I hope there's a better solution
21:36:19
EdLangley[m]
And I was happy to find your version of an API wrapper because I was running into some edge cases of passing structs around by value
21:36:38
seragold[m]
<aeth> "semz: well, Python has its own..." <- not so true today. everyone moved to python3 finally. Not that that is altogether good.
21:37:02
drakonis
aeth: as far as i'm concerned, python has bigger problems than the move from 2 to 3
21:37:39
moon-child
jpm still has 30m lines of python code, and will continue to maintain the python2 interpreter because _it_ is only 3m lines of code
21:38:32
EdLangley[m]
So, my experience with Python 2->3 is the other reason I’m anti-breaking changes
21:40:00
_death
EdLangley[m]: cool :).. I don't use tree-sitter nowadays (I wrote it one weekend when I discussed some source code transformation on another irc channel) but I think sel still makes good use of it
21:40:39
seragold[m]
much of the day job is in python. would give a lot if it would stop trying to kill lambda and would have every bloody function return something reasonable. and if they would make the python3 special collection wrappers work as the actual collections they replaced
21:44:23
seragold[m]
looked at it but its almost but not quite nature made me a bit uneasy. that and the rest of the day job team would likely string me up
21:48:46
_death
looked one up because I remembered a post that made my chuckle.. https://mailman.common-lisp.net/pipermail/cello-devel/2008-November/000191.html
22:29:37
seragold[m]
One of my first CS classes was a Survey of Programming Languages and they took us to Symbolics when they were still operational for a few glorious days. Left me rather disgruntled with the state of much of the software world ever since due to the early exposure.
22:44:41
seragold[m]
They even had C and Fortran running as a layer on top of Lisp! So you had all their Lisp environment to use even working in those languages.
22:45:50
seragold[m]
On Lisp alludes to this "mere skin on top of Lisp" approach but was first time I saw it done.
22:46:31
White_Flame
technically, I don't think they converted C and Fortran to Lisp, but compiled down to its CPU code. I could be wrong, though
22:47:09
EdLangley[m]
Using iota, they managed to compile doom to some sort of lisp and run it on mezzano
22:48:01
seragold[m]
I remember once upon a time there was a C or was it Objective-C interpreter that could dynamically load and reload object files. IIRC Micro$loth bough them and the tech was never seen again.
22:48:24
White_Flame
yeah I'm sure that Mezzano has low-level operations exposed to lisp sexprs for C style stuff
22:49:28
dbotton
I plan on using it in future to encourage people to use CLOG with C, Python etc running on top if CL
22:50:13
White_Flame
ooh, neat. though it's in the ti explorer tree for some reason? I guess that's why I never noticed it there on bitsavers
22:50:44
seragold[m]
one of these days I should play with Clasp when it comes to bringing Lisp and llvm/clang worlds together. https://github.com/clasp-developers/clasp
22:51:19
EdLangley[m]
Iota translates llvm bitcode to CL, so you should be able to use any LLVM language with lisp
22:51:58
Shinmera
Iota works in the same way Emscripten/etc work -- you compile instructions to operate on some sort of byte array, and then plug whatever extra ops you need to flush the relevant memory areas to screen and plug in other i/o bytes.
22:52:25
dbotton
Vacietis works by loading C code into a Common Lisp runtime as though it were Lisp code"
22:52:31
EdLangley[m]
The advantage being that since the target is inside Lisp, it can’t crash your lisp process or cause memory faults
22:52:56
phoe
dbotton: also see https://github.com/y2q-actionman/with-c-syntax as a half-joke attempt
22:53:14
seragold[m]
EdLangley[m]: It may have made since with Symbolic early support international character sets. :)
22:53:37
phoe
it's half-joke until you scroll the readme down to the Duff's device - then you realize that it's half-joke half-terrifying
22:55:17
White_Flame
it could technically all be done, just the "pointers" would get big and there'd be a ton of runtime tests to figure out what the heck is being pointed at
22:56:42
EdLangley[m]
I think vacietis is designed to exploit a bunch of UB that people assume isn’t UB
22:57:38
dbotton
For my purposes it vacietis works, I want people to try out using CL even if they are using C to do it (or python), eventually people always want to dig more and will try the real thing
22:58:24
seragold[m]
s/It may have made since with Symbolic early support international character sets. :)/It may have made sense with Symbolic early support of international character sets. :)/
22:58:29
moon-child
White_Flame: NB. bytearray has its own problems. How do you do function pointers?
22:59:00
White_Flame
moon-child: yeah, at least in webasm, a function pointer's value is an index into an out-of-scope array that only the runtime has access to
22:59:08
seragold[m]
I gave up because I tried to get into it with Rust which I found way too frustrating.
0:35:40
rotateq
hm if companies search for people which translate COBOL to Java it would make more sense using ABCL ^^
3:30:52
fitzsim
I'm trying to create a project there but I get "The form contains the following error: Namespace is not valid"
3:53:53
fitzsim
it seems like I'm an "external" user for some reason; I'll stick to sr.ht for now, I guess
4:03:24
sveit_
hi. i am trying to use both local and global inlined functions to replace macros, and was wondering if for this purpose flet or let-assigned functions are generally friendlier to the compiler (specifically SBCL)? In certain cases that I haven't been able to predict it seems the functions are not reliably inlined when using flet
4:05:48
beach
sveit_: How did you determine that the function wasn't inlined? Did you read the disassembly?
4:06:30
beach
sveit_: And why do you absolutely want functions to be inlined? Don't you trust the compiler to make this call?
4:07:45
moon-child
well, I would not trust the compiler. But I would also not make such decisions without benchmarking
4:08:27
sveit_
i am doing this in some performance-sensitive code that needs to increment certain counters, so i have functions floating around like (let ((counter 0)) (flet ((incf-counter (step) (incf counter-var step))) (declare (inline incf-counter))...)) where #'incf-counter is passed to other (also inlined) functions taht only funcall it
4:09:52
sveit_
i /was/ doing this with macros that wrote the inner functions that would increment inner-counter, but it is much cleaner to pass such functions around. it seems that, somewhat unpredictably to me, some of the outer flets are not properly inlined
4:10:34
sveit_
on the other hand sometimes such things /are/ inlined, and i haven't been able to understand the pattern
4:13:21
sveit_
EdLangley[m]: i'm aware, but SBCL is intelligent enough that it would be great to trade some code clarity for trusting the compiler to do some magic :)
4:14:18
moon-child
sure, but if you are optimizing, you are already trusting to the performance characteristics of a given implementation or a few given implementations; so you can count on whatever behaviour they exhibit wrt compiler macros
4:14:31
moon-child
and, whereas inlining is a black art, compiler-macro expansion is a relatively simple matter
4:31:15
sm2n
Are there implementations worth doing performance engineering on today that don't respect (declare (inline))?
4:33:19
aeth
modern optimizing compilers (not SBCL, and not Common Lisp in general) tend to ignore this sort of thing these days because they think they know better than you
5:15:45
White_Flame
sveit_: if you pass around #'incf-counter, then it becomes a closure, and closures aren't inlinable
6:01:33
beach
fe[nl]ix: I must have completely missed the fact that you seem interested in having an IDE for Common Lisp. Are you aware of the bits and pieces being worked on by scymtym and (somewhat) myself?
6:05:22
sveit_
are there "extra" registers in SBCL assembly? I am seeing things like writes to "NL1", which I am not familiar with and can't seem to find on google
6:11:34
sveit_
sure, disassembly under SBCL HEAD for (defun my-incf (input) (declare (type fixnum input)) (+ input 7)):
6:19:26
sveit_
moon-child: not directly relevant but i'd be interested to learn how you are doing this (I assume you're copying the opcodes into some kind of file and running it through objdump?)
6:20:14
moon-child
on x86 I have more fine-grained tools, but I haven't spent much time with arm yet
6:21:55
moon-child
White_Flame: well, objdump knows nothing of the instruction that sbcl identifies as stp nl1, nl0, [tmp]. So I assume something fucky is going on
6:23:40
nwoob
I'm learning CL from David S. Touretzky book. Since I am familiar with Javascript, I am thinking to write programs mentioned in book in both JS and CL for learning.
6:25:12
sveit_
i also wonder what is being computed by [THREAD, #40], but I at least have some rough idea of what is going on there
6:28:24
sveit_
is there a way to just directly take the raw opcodes and disassemble them in some other tool (i am not that experienced with writing assembly)
6:40:31
White_Flame
but I think it's an appropriate question for #sbcl if nobody's jumping to answer in here
6:42:26
sveit_
well i put it through onlinedisassembler.com and it seems fairly consistent that NL1 really means X1. I'm sure if I were more experienced in assembly that something like this must have been going on would have been "obvious", but I'm still not comfortable with all the prefixes in front of register