libera/#commonlisp - IRC Chatlog
Search
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
9:58:36
mgl
If the asdf system xxx/test depends on something not yet in quicklisp, does that break xxx in quicklisp?
10:06:56
phoe
the system XXX/TEST will not be included in Quicklisp if it cannot be loaded due to missing dependencies
10:07:20
phoe
if XXX and XXX/TEST are defined in the same file (which is very likely), it means that XXX transitively won't be included in Quicklisp either
10:09:45
phoe
no idea - if it's included in the same tarball/repository then Quicklisp might nonetheless try to recognize and load it
10:44:06
Krystof
sveit_: we have different names for registers because those registers have special meanings (either to Lisp-land, to the Garbage Collector, or both)
10:45:06
Krystof
On arm you see the results of a partitioned register set: NLx I *think* stands for Non-Lisp, but whatever the name, they're registers that are guaranteed never to hold lisp pointers. (So the Garbage Collector can ignore them, and the compiler can put untagged data in them)
10:45:34
Krystof
THREAD holds a pointer to thread-local storage; NULL holds NIL; I can't remember if there is a ZERO on arm64, but if there is, it holds 0.
11:46:38
rotateq
jackdaniel: of course I didn't include myself ^^ but yes, there is always more to learn, even for a master/expert
11:50:48
sabra
researchers I support sometimes get gigs of data in json form from who knows where. No web stuff here
11:57:03
rotateq
but when i see XML data format it seems to me it's a very exhausting one and that so much work is unnecessarily doubled and tripled by bringing it to a computable layout
12:41:09
yitzi
sabra: Thanks for your review of shasht. I'll look into the rough edges that you did find. I appreciate the your detailed reviews as always!
12:42:48
sabra_
Yitzi: thanks. Let me know if there is anything I can do or should correct or update
12:51:34
yitzi
sabra_: Aside from the some of the issues that you mentioned that I obviously need to look at I did notice that you said that "[123.456e78]" fails...
12:52:57
yitzi
shasht reading of floating point is affected by `*read-default-float-format*` so setting that to 'double-float or doing `(shasht:read-json* :stream "[123.456e78]" :float-format 'double-float)` should work.
12:53:59
yitzi
There could be a better way to handle that issue. I am open to suggestions/criticism.
13:02:22
yitzi
Awesome. I don't think it is an ideal solution, but it does follow the core CL behavior so at least it is not unexpected.
13:12:10
yitzi
sabra_: Can you give me the test case that caused shasht to hang on nil? I am probably just being dense, but I am not seeing it.
14:08:32
phoe
if they are defined in the same ASD file, how does Quicklisp work in that situation though?
14:10:08
Xach
Quicklisp tries to build every system it can find. If it builds, it is indexed in systems.txt and can be found via QL's system search function. If it doesn't, it isn't.
15:12:25
beach
fe[nl]ix: scymtym maintains Clouseau, the inspector. And we are both working on Second Climacs as an editor. I have a paper about debugging and McCLIM has a backtrace inspector "debugger".
15:13:49
beach
And scymtym has done work on incremental analysis of Common Lisp code. He occasionally shows a demo here.
15:15:10
beach
The main thing holding Second Climacs back is that I can't make up my mind about the data structure for computing indentation.
15:22:57
fe[nl]ix
and the list of features I'd need in order to switch to it as my main editor is pretty large
15:23:46
fe[nl]ix
last time I tried to do anything with it I have up after 5 minutes because it was full of bugs
15:27:09
beach
It is being actively maintained and improved by jackdaniel and many others. I am sure they would appreciate "issues" that you find.
15:27:53
beach
It is quite usable as it is, but there are some very nice improvements being worked on.
15:28:36
foxfromabyss
Let's say I have a class `(defclass point () (x y))` and a list `(list p1 p2 p3 p4)`
15:28:36
foxfromabyss
And I would like to splice(?) the values of the class instances into the list, so that it looks like `(list x1 y1 x2 y3 x3 y3 x4 y4)`
15:28:37
foxfromabyss
I initially tried to do that with `mapcar` but that obviously doesn't work, since I would need to return multiple values for that which is not supported by `mapcar` afaik
15:30:27
phoe
it's not the lisp way because it doesn't have many parens and doesn't feel "lispy" the same way the rest of the language does
15:30:54
phoe
it's very the lisp way because CL allows you to design sublanguages meant for specific things, like iteration, formatting text, regex matching, pattern matching et al
15:31:11
phoe
the moment you reconcile these two approaches you will attain one of the first steps for lisp enlightenment™
15:32:44
phoe
if you need functional programming, do it; if you need OOP, do it; if you need declarative programming, do it; if you need imperative control like GOTO, do it; if you need to mix all four, do it; if you need to design another four paradigms, just do it as well
15:33:28
jackdaniel
except that when you join the irc channel everyone will shun you down if you don't go full-clos road (or be caustious to not speak about it:)
15:34:37
jackdaniel
re mcclim, I'm not sure whether these are small things, many important parts are rewritten and there may be regressions
15:35:00
scymtym
beach: i couldn't read the who discussion and i would like to make a new demo (in particular with some semantic highlighting), but for now https://techfak.de/~jmoringe/second-climacs-1.ogv and https://techfak.de/~jmoringe/drei-experiment-2.ogv may give an impression
15:35:30
rotateq
foxfromabyss: even some older professors at universities still think that or can't distinguish from generic LISP
15:35:52
random-nick
foxfromabyss: CL is a general purpose language with the speciality of being general purpose
15:36:31
random-nick
pretty much any paradigm can be implemented in CL or has already been implemented in CL
15:43:49
foxfromabyss
even more unrelated: i am using the Sketch library for some visualizations. Is it possible to render the image and save it to memory, instead of displaying it?
15:44:09
foxfromabyss
sorry if I am asking too many dumb questions, googling was not too much of a success tbh
15:51:00
phoe
looks like it should be possible to get out the contents of the foreign SDL2-WINDOW object somehow, but I have no idea how
15:51:13
phoe
I'd open an issue on GitHub and ask for adding that to the manual - it does sound like a good use case