<kvik>
in CL (SBCL), is there a way to determine the total memory size of a lisp object such as a list?
<kvik>
i don't need it for anything in particular, just wanna have some picture of how much space things take
<|3b|>
it is somewhat hard to define in general, since lists can share parts, or share values with other things
<|3b|>
i think sbcl does have some tools to get an answer of some sort though
cage has joined #commonlisp
cage has quit [Excess Flood]
<|3b|>
or you can estimate that every cons is about 2 words, and every value larget than a fixnum, character or single-float is probably a few words plus the actual contents of the object (again with the same problems of sharing for most objects)
nil78 has quit [Read error: Connection reset by peer]
<|3b|>
i think ROOM is the closest the spec provides, but that just gives some unspecified summary of how much space is used. TIME might also print out how much was allocated, but might not be byte-granularity even if it does
nil78 has joined #commonlisp
<|3b|>
(and 'word' above is "size of a pointer", so probably 8 bytes on 64bit implementations)
<scymtym>
sbcl has an "allocation profiler" called aprof. using aprof is a bit involved but it can report for each (instrumented) function how much memory that function allocated, including the number of allocations and a rough breakdown by object type
<|3b|>
an example of how "size" is hard to define, the list (T) is 1 cons, so 16 bytes for the list structure. Should you count the size of the symbol CL:T? if so, should you count the size of the package "COMMON-LISP" references by its symbol-package slot? all the other symbols accessible in that package? the functions and variable values of those symbols? the values they close over? etc
<|3b|>
but if not, what about the list (#:foo), where the symbol isn't otherwise accessible? then you miss out on a few words of the symbol structure, the string for its name, etc
Devon has joined #commonlisp
<kvik>
i see. makes sense.
cage has joined #commonlisp
mange has quit [Quit: Zzz...]
<|3b|>
looks like sbcl has sb-ext:primitive-object-size which will tell you a cons is 16 bytes, a symbol is 48, etc (but it just tells you the size of the first cons if you pass a list)
<kvik>
that's nice already
Devon has quit [Ping timeout: 252 seconds]
k_hachig_ has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
k_hachig_ has quit [Ping timeout: 260 seconds]
nil78 has joined #commonlisp
<kvik>
|3b| thanks for the explanations. i'm just starting to see how this question isn't as easy or even as meaningful as I thought :) (coming from a C and C++ programmer)
alfiee has joined #commonlisp
nil78 has quit [Read error: Connection reset by peer]
random-nick has joined #commonlisp
nil78 has joined #commonlisp
alfiee has quit [Ping timeout: 268 seconds]
nil78 has quit [Read error: Connection reset by peer]
nil78 has joined #commonlisp
<beach>
kvik: It is probably not meaningful in C or C++ either, because you can have sharing there as well.
<|3b|>
usually more obvious that you ask about the container in c though
<|3b|>
you explicitly put a pointer in the struct, so you expect the size of the pointer there
<|3b|>
also doesn't help that "list" in CL sounds like something more concrete than it actually is. in C you would talk about a linked list or tree or whatever and it would be more obvious you have a chain of nodes
<|3b|>
(c++ probably has more cases that are more ambiguous and/or hidden though)
<kvik>
beach: whatever sharing is what you explicitly programmed in C, so it's much easier to reason about space
<|3b|>
c also probably don't have the problem that a small integer, character or float might take up 0 bytes depending on where you put it and how you count things :)
manwithluck has joined #commonlisp
manwithluck` has quit [Ping timeout: 268 seconds]
alfiee has joined #commonlisp
<beach>
I see.
nil78 has quit [Read error: Connection reset by peer]
alfiee has quit [Ping timeout: 272 seconds]
nil78 has joined #commonlisp
manwithluck has quit [Ping timeout: 248 seconds]
manwithluck has joined #commonlisp
ym has joined #commonlisp
manwithluck has quit [Remote host closed the connection]
<cage>
Hi! Has anyone tried to load sdl2-ttf on aarch64 with sbcl? On my system loading fails because it tries to invoke the c2ffi command (unavailable on my system), forgive my ignorance seems odd to me that calling this executable is needed for using the library, i think it is needed just to generate the wrappers spec.
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
synchromesh has quit [Read error: Connection reset by peer]
synchromesh has joined #commonlisp
decweb has joined #commonlisp
bjorkintosh has quit [Remote host closed the connection]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
jonatack has joined #commonlisp
<cdegroot>
Is that aarch64 on Linux or on macOS? I think it's more to do with what OS you use, what packaging tools you use, etc, rather than something aarch64 specific (I use NixOS on aarch64 - my work VM - and I'd be extremely surprised if any of my CL stuff broke there.
<cage>
hi cdegroot! Thanks for your reply. After checking the code seems to me that the spec file for aarch64 (the file that c2ffi produces and that cl-autowrap consume to generate the FFI), is in effect, missing
<cage>
so is is necessary to generate it using c2ffi
<cage>
*it is
<cdegroot>
yeah, I'm not surprised that the tool is needed, just saying it's likely to have less to do with your machine architecture than with the exact environment you're running (OS, packaging tools, etc).
<cage>
i would say it is a fault form the user (me) :)
<cage>
i am going to build c2ffi and try to generate the spec file
<cage>
i hope it will works!
<cdegroot>
(I can warmly recommend Nix, it's super helpful for my CL work because it can just spin up the right setup for pretty much anything without affecting your setup outside your code). Anyway, good luck :-)
<cage>
nix is wonderful but i prefer guix, because scheme ^^;;
<cage>
thanks cdegroot! :)
cage has quit [Quit: rcirc on GNU Emacs 29.4]
alfiee has joined #commonlisp
ym has quit [Ping timeout: 244 seconds]
alfiee has quit [Ping timeout: 244 seconds]
k_hachig_ has joined #commonlisp
<cdegroot>
(off-topic-ish but I had to switch because getting Guix on my laptop was just too darn hard and now I'm not hating the Nix DSL anymore; in many places it's quite a bit simpler to work with than the internal DSL that Guix produced. But yeah, it was fun for a while to have a setup where the bottom layer was Scheme, then Elisp, and CL on top :-))
JuanDaugherty has joined #commonlisp
ingeniot has joined #commonlisp
bpanthi977 has quit [Remote host closed the connection]
bpanthi977 has joined #commonlisp
jon_atack has joined #commonlisp
jonatack has quit [Ping timeout: 260 seconds]
manwithluck has quit [Ping timeout: 268 seconds]
bpanthi977 has quit [Ping timeout: 268 seconds]
ingeniot has quit [Quit: Client closed]
manwithluck has joined #commonlisp
alfiee has joined #commonlisp
manwithluck has quit [Read error: Connection reset by peer]
manwithluck has joined #commonlisp
Guest47 has joined #commonlisp
alfiee has quit [Ping timeout: 252 seconds]
ingeniot has joined #commonlisp
ingeniot has quit [Client Quit]
bpanthi977 has joined #commonlisp
JuanDaugherty has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]
veqq has joined #commonlisp
ingeniot has joined #commonlisp
ingeniot has quit [Quit: Client closed]
waleee has joined #commonlisp
alfiee has joined #commonlisp
triffid has quit [Remote host closed the connection]
alfiee has quit [Ping timeout: 252 seconds]
triffid has joined #commonlisp
chomwitt1 has joined #commonlisp
varjag has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
<cage>
aeth: IIRC there is a stable release of SDL3
<cage>
i wish i could have the energy for writing a wrapper :(
<aeth>
my impression is, yes, nobody likes the main SDL2 bindings (cl-sdl2 and associated libraries), but no other SDL2 wrapper has really taken off as the de facto replacement, and now SDL3 is there, waiting to be wrapped (and probably take over from cl-sdl2 finally)
<cage>
if someone would starts such project (wrapping SDL3) i would be happy to contribute (even with my limited skills)!
<cdegroot>
ah, nodgui, nice. I last worked with Tk when it just came out lol
<cage>
cdegroot: thanks cdegroot :)
<cage>
i am using TK for GUI and SDL2 as a "pixel buffer/Opengl" widget, the code is a bit of a mess
<cage>
because the SDL2 mainloop need to be in a separate thread
<cage>
and nodgui mainloop too ^^;
<cage>
but it works someway ^^;;
<cdegroot>
I' ve done similar things (used wxWindows from Squeak Smalltalk) so I feel your pain :)
<cage>
:) :)
<cdegroot>
It worked and we delivered a product with it, but... well... I'm not gonna look at that code ever again.
ebrasca has quit [Read error: Connection reset by peer]
<cage>
cdegroot: :D :D :D
cqst has joined #commonlisp
soweli_iki has joined #commonlisp
alfiee has joined #commonlisp
alfiee has quit [Ping timeout: 252 seconds]
<cdegroot>
I'm not saying I'm volunteering to do the work, but I'm just curious: is creating an SDL3 wrapper not "simply" a matter of running c2ffi over it and importing the result and emit some code from it in a fairly straightforward fashion?
<cdegroot>
(I guess that the result won't make anyone happy so then a "lispy" manual wrapper around that is needed? I must confess, never looked into the bowels of CL GUI code, just use it)
<aeth>
SDL3 is a massive, complicated, odd, high-performance, low-level, etc., etc., etc. thing
<aeth>
I don't think automatic is going to do particularly well vs just manually wrapping what you need as you need it
<aeth>
and maybe it grows into something generally usable
<aeth>
I'll probably try soon
JuanDaugherty has joined #commonlisp
<aeth>
Of course, this means it won't be usable for anyone else
<cdegroot>
Yeah, I've used the latter approach in the past, but that generally also means that it's a "it scratches my own itch" sorta thing, not a "here, go and use it" kinda deal.
<aeth>
Then you have the people who insist on finalizers (cl-sdl2 used to have them) and they won't be happy no matter what
<aeth>
(Finalizers are essentially incompatible with the SLIME interactive dev workflow because there's no guarantee that resources will be freed between closing the SDL window/app and opening it again, all in the same SLIME REPL process... iirc)
<aeth>
So you have to design it for an unwind-protect around a main loop and this makes some people inherently unhappy about the situation
<cdegroot>
yeah, but if things get sufficiently complex you can never make everybody happy. Scratch-your-own-itch it is (and after my "bolt-wxWindows-on-Smalltalk" experience, I have turned in a user of graphics libs lol. I'll use what is there. A surprising large amount of stuff for CL, frankly. The hardest part is choosing :-))
<aeth>
CL gets a lot of graphics/gamedev stuff because adjacent languages aren't particularly suited for it.
k_hachig_ has joined #commonlisp
<aeth>
Scheme doesn't have a uniform FFI and in general each Scheme is on its own for libraries, especially wrapped libraries. And most Schemes only have one "flonum" type, double-float. Racket iirc even got rid of their single-float in the move to the Chez Scheme backend. But graphics/GPU essentially live in single-float, which is the default float for CL.
<aeth>
And most other similar-to-CL languages (e.g. Clojure) have way more of a focus on immutability and FP.
<aeth>
So I think this kind of skews CL towards this sort of role because people who are familiar with similar languages see CL as more ideal for this niche.
<cdegroot>
Well, I'm not complaining :-). I'm looking to write some visually-rich stuff - strictly for myself, hobby things - and it's been an interesting journey with a couple of really fun rabbit holes.
<cdegroot>
(I don't know how I got derailed, but I spent a lot of time looking at Trial and cl-fast-ecs lately, especially whether I can mash them up, and all the time all I need is Sketch :-) )
<aeth>
I'm not sure I'd use an ECS library, they're very easy to do
<aeth>
Basically just arrays of numbers at their core.
<aeth>
Maybe "fast-ecs" is faster, maybe not, but if you make it yourself, you get to build exactly the representation you want
jonatack has joined #commonlisp
<aeth>
Sorry, arrays-of-numbers and bits-as-booleans (for the entity).
<cdegroot>
yeah, that library comes with nice high level macros and under the hood crams it all into compact arrays, and getting that right from scratch is I think harder than it looks like. But I should not be looking at game stuff at all, I don't have time to write games :) (although ECS smells like a reasonable candidate for some more complex stuff I have in mind).
k_hachig_ has quit [Ping timeout: 260 seconds]
geminium has joined #commonlisp
uhuh has joined #commonlisp
geminium has quit [Ping timeout: 276 seconds]
k_hachig_ has joined #commonlisp
alfiee has joined #commonlisp
k_hachig_ has quit [Ping timeout: 244 seconds]
uhuh has quit [Remote host closed the connection]
alfiee has quit [Ping timeout: 244 seconds]
Pixel_Outlaw has joined #commonlisp
k_hachig_ has joined #commonlisp
bjorkintosh has quit [Quit: "Every day, computers are making people easier to use." David Temkin]
JuanDaugherty has quit [Quit: praxis.meansofproduction.biz (juan@acm.org)]