frgo has quit [Read error: Connection reset by peer]
<akoana>
paule32: With all due respect, I'm sorry I can't help in this case, I have no idea what you're intending to do, it all sounds very vague. Maybe someone else can help you.
<paule32>
at the moment, i simply catch thing together, not related to a finaly goal, simply learn things step wider
<paule32>
now, i try to handle exception, so i have a nice output on developer mistake
<paule32>
i speak about developer, because i was getting from many there, that the lisp system is handled by a programmer, not strict user
razetime has quit [Ping timeout: 260 seconds]
razetime has joined #commonlisp
razetime_ has joined #commonlisp
razetime has quit [Ping timeout: 268 seconds]
cage has joined #commonlisp
akoana has quit [Quit: leaving]
attila_lendvai_ has quit [Ping timeout: 240 seconds]
karlosz has joined #commonlisp
epony has quit [Ping timeout: 252 seconds]
karlosz has quit [Ping timeout: 268 seconds]
razetime has joined #commonlisp
razetime_ has quit [Ping timeout: 268 seconds]
razetime has quit [Ping timeout: 260 seconds]
razetime has joined #commonlisp
razetime has quit [Ping timeout: 264 seconds]
prokhor_ has quit [Ping timeout: 260 seconds]
razetime has joined #commonlisp
X-Scale has quit [Remote host closed the connection]
ttree_ has quit [Ping timeout: 244 seconds]
pjb has quit [Ping timeout: 248 seconds]
razetime has quit [Ping timeout: 260 seconds]
razetime has joined #commonlisp
random-nick has joined #commonlisp
epony has joined #commonlisp
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest399
comatory has quit [Ping timeout: 240 seconds]
comatory has joined #commonlisp
glaucon has joined #commonlisp
lisp123 has joined #commonlisp
comatory has quit [Ping timeout: 264 seconds]
razetime has quit [Ping timeout: 260 seconds]
comatory has joined #commonlisp
razetime has joined #commonlisp
igemnace has joined #commonlisp
comatory has quit [Ping timeout: 260 seconds]
lisp123 has quit [Remote host closed the connection]
comatory has joined #commonlisp
comatory has quit [Ping timeout: 268 seconds]
comatory has joined #commonlisp
dBc has joined #commonlisp
comatory has quit [Ping timeout: 252 seconds]
comatory has joined #commonlisp
comatory has quit [Ping timeout: 240 seconds]
comatory has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Quit: karlosz]
karlosz has joined #commonlisp
karlosz has quit [Ping timeout: 260 seconds]
orestarod has joined #commonlisp
razetime has quit [Ping timeout: 252 seconds]
karlosz has joined #commonlisp
karlosz has quit [Client Quit]
aartaka has quit [Ping timeout: 240 seconds]
pranavats has joined #commonlisp
aartaka has joined #commonlisp
cercopith has quit [Ping timeout: 244 seconds]
cercopith has joined #commonlisp
gin_ is now known as gin
<gin>
does (getf plist :foo) take linear time to find :foo and return the value? or is it optimized to take logarithmic or constant time on an average?
<beach>
gin: A plist is a singly linked list, so it can't do better than linear time. What made you think it could?
frgo_ has quit [Ping timeout: 260 seconds]
<gin>
beach: I wanted to find out if the CLHS spec allows implementations to optimize the access time by introducing a backing-hashtable or a backing-tree on top of the plist. especially because it is a very commonly used data structure.
pranavats has left #commonlisp [Error from remote client]
<beach>
Where would it store that additional object?
nij- has quit [Ping timeout: 244 seconds]
<hayley>
Is it a commonly used data structure?
<beach>
gin: And if you think there is a possible place for such an additional object to be stored, how would you make that object change if you do something like (setf (cdr (nthcdr 1000000 plist)) nil).
<gin>
beach: now I understand why what I was wondering about is stupid. thanks for the insightful questions!
frgo has joined #commonlisp
<jcowan>
beach: In the symbol itself, doubtless. Such optimizations were not unknown in the old days, when the symbol's name and global values were maintained on the plist and it was constantly being searched. Granted, you could break them by getting access (via cdr, of all things) to the plist directly.
<beach>
jcowan: What symbol?
<jcowan>
The symbol to which the plist belongs.
<hayley>
GETF, not GET.
<beach>
jcowan: Nobody mentioned a symbol.
<jcowan>
Ah, I missed that.
<beach>
gin: Pleasure.
<beach>
gin: I wouldn't use the word "stupid" though.
<jcowan>
Though it could still be done even in that case using a weak hash table
<beach>
No.
<gin>
but then we would not be able to update the weak hash table when we set a place in plist with setf
<hayley>
Mutating the list would require invalidating the other representations.
<hayley>
.oO(If we had CDR coding, the search could hypothetically be vectorised. It'd still be linear time, but the constant factor might be lower.)
<beach>
And there could be arbitrary sharing of the tail of the list, so you could mutate the list from some other form that doesn't mention the original list, which was the subject of my sequence question.
<jcowan>
If you mutate it with (setf car) and (setf cdr), no. A lot of what is done with lists is regulated by convention. It is only convention that prevents us from mutating alists, for example.
<beach>
So you would introduce an optimization that violates the semantics of the language unless a convention is respected.
<beach>
Not such a great idea.
<jcowan>
No.
<beach>
Good!
karlosz has joined #commonlisp
<hayley>
No one up for CDR coding still? Should I wait for the 2070s or so?
<hayley>
(Kidding, kidding. But it would be nice, though perhaps I'll find it near where they put the ponies.)
pjb has joined #commonlisp
waleee has joined #commonlisp
thuna` has joined #commonlisp
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
tyson2 has joined #commonlisp
glaucon has quit [Quit: WeeChat 3.5]
cercopith has quit [Remote host closed the connection]
cercopith has joined #commonlisp
frgo has quit [Remote host closed the connection]
nij- has joined #commonlisp
nij- has quit [Remote host closed the connection]
dBc has quit [Quit: leaving]
anticomputer has quit [Remote host closed the connection]
anticomputer has joined #commonlisp
nij- has joined #commonlisp
shka has joined #commonlisp
frgo has joined #commonlisp
igemnace has quit [Remote host closed the connection]
<jcowan>
hayley: The natural target for CDR coding is a memory-constrained environment like the IoT. But you'd need some sort of tree-shaker for deployment as well.
pjb has quit [Ping timeout: 268 seconds]
<aeth>
jcowan: do memory-constrained environments really exist anymore?
<pl>
aeth: yes
<pl>
maybe not as constrained as in 1970s, but considerably enough
<pl>
and IIRC it turned out that CDRcoding didn't help as much as it was thought, which led to dropping it from usage despite considerable theoretical difference in memory usage
<aeth>
The Pi 3 is 1 GB... the Pi 4 is 1-8 GB. The Pi Zero is 0.5 GB. And these are old.
<aeth>
It would have to be a microcontroller to not have a lot of RAM, but I doubt people are going to program those in a (mainstream) Lisp
<pl>
aeth: I've been in rather heated discussions at work regarding using less than 128MB of extra ram in a new change. We have 16GB machines, and we actually do get issues if we add 128MB of extra memory usage to them
masinter has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
nij- has quit [Ping timeout: 268 seconds]
tyson2 has joined #commonlisp
rgherdt has joined #commonlisp
rgherdt_ has quit [Remote host closed the connection]
jmdaemon has joined #commonlisp
epony has quit [Ping timeout: 252 seconds]
epony has joined #commonlisp
<mathrick>
what do people use for high-resolution timers and sleep? I know SBCL has SB-EXT:TIMER (but it's also not clear to me whether they're Linux-specific?), but that's about it. The manual doesn't specify any resolution for SLEEP, even as an approximation. CCL is similarly mum on the topic, and doesn't seem to have a comparable facility to SB-EXT:TIMER
<mathrick>
I guess it's just "use bindings to libevent"?
tyson2 has quit [Remote host closed the connection]
comatory has quit [Ping timeout: 264 seconds]
comatory has joined #commonlisp
<masinter>
medley uses milliseconds, which isn't enough resolution
<masinter>
there's a heuristic of when you want to pop up a breakpoint window vs. let it error
eddof13 has joined #commonlisp
<mathrick>
masinter: what's medley?
eddof13 has quit [Client Quit]
<masinter>
medley interlisp... the common lisp is CLTL1 mainly but we're working on it
<mathrick>
so it's a multi-dialect implementation?
<masinter>
Interlisp is just the IL package
<masinter>
there's CL:LAMBDA and IL:LAMBDA
<masinter>
CL:EVAL and IL:EVAL
<masinter>
but CAR and CDR and LIST and CONS are shared
eddof13 has joined #commonlisp
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
vassenn has joined #commonlisp
<mathrick>
that's pretty neat, but I don't think it addresses the practical consideration of "how do I make my game engine able to sleep for precise durations?" :)
aartaka has quit [Ping timeout: 260 seconds]
<|3b|>
if you need sub-frame precise sleeps, you probably need to be paying attention to OS details anyway :/
Conatus has quit [Ping timeout: 252 seconds]
eddof13 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<|3b|>
and for best results, also paying attention to whether you are on battery or not, etc (since if you aren't the OS might start paying attention to it for you anyway)
<|3b|>
i think on windows you can set the timer resolution down to 1-2ms resolution or so (from 15? ms default), though if possible you'd probably get better results if you wait on some meaningful event instead
<mathrick>
right, which also points towards libevent or similar
<masinter>
the problem is you don't want to specify 'sleep' for a particular sleep interval, because the amount of sleep time depends on the performance of the machine
<mathrick>
but that is very much the idea, I don't want to just spin until it's time to draw the new frame
<|3b|>
well, just an event sent by something else that set a timer won't help much :)
<mathrick>
|3b|: not sure what you mean
<|3b|>
libevent doesn't know when it is time to draw a frame either
<mathrick>
but my code will
Lord_of_Life_ has joined #commonlisp
<mathrick>
masinter: sure, but that's how main loops work. You do an iteration, do what you need to, calculate when the next time to wake up will be, then set a timer for that
<|3b|>
so asking libevent to send you an event in 5ms is no better than sleeping for 5ms
<mathrick>
if something else wakes you up earlier, that's fine
<mathrick>
otherwise, that's the next time you look at stuff
<|3b|>
currently it is still hard to do frame timing well from what i understand though :/
Lord_of_Life has quit [Ping timeout: 252 seconds]
<mathrick>
|3b|: unless of course (sleep 5ms) is not guaranteed to be 5ms, but might be 25ms
<|3b|>
APIs are starting to get useful events for stuff like "time to draw a frame" that you could actually wait on
<|3b|>
mathrick: sure, but if libevent is just going to sleep 5ms (which might be 25) then send you an event, you still lose
<mathrick>
and there are other things that need timing, like OpenAL (whose API is abysmal btw)
vassenn has quit [Remote host closed the connection]
<mathrick>
|3b|: but the whole point of binding to libevent is that it's likely to be more precise than that
<mathrick>
the issue is that SBCL's SLEEP resolution is entirely undefined
<|3b|>
if it is, then you can be too without an extra lib
euandreh has quit [Ping timeout: 244 seconds]
Lord_of_Life_ is now known as Lord_of_Life
causal has joined #commonlisp
<mathrick>
in principle, yes, in practice I think it will be a better experience than trying to wrap the 7 or so OS-specific APIs libevent interfaces with
<|3b|>
but yeah, lisp-level SLEEP is probably the wrong answer either way
<|3b|>
possibly
euandreh has joined #commonlisp
<|3b|>
though might be harder to control things like handling "on battery" well
frodef has joined #commonlisp
<|3b|>
either being nice and dropping res by few ms (which makes a big difference for power usage), or dealing with OS deciding to do that for you, and noticing your timer resolution isn't what you designed for anymore
ttree_ has joined #commonlisp
sjl has joined #commonlisp
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Conatus has joined #commonlisp
<masinter>
i had to go in and add longer delays in all of the Medley "idle hacks" because they were running too fast
<mathrick>
|3b|: a big part of me worrying about timers is that I explicitly want it to be nice to batteries, and thus it's not being built with any sort of fixed frame rate, which a lot of traditional PC games do. It's supposed to run happily at 0.3 FPS if there's an idle animation that only runs every 3s
<mathrick>
but for that, reliable timers are necessary
<mathrick>
because it needs to move from "frames are playing" to "nothing's happening"
<|3b|>
right, so you need to be actively managing the system timer resolution
<mathrick>
yes
<|3b|>
setting the system to check timers every 1ms so you can get your 3second sleep precisely to 1ms will burn battery :/
puchacz has joined #commonlisp
<mathrick>
not necessarily, as long as the screen is on, battery-powered hardware generally has high-resolution hardware timers that can be set in fire and forget fashion. Resolution only suffers when you're asking to be woken up when in the background and the device is off / in standby
<mathrick>
but yes, it's an OS-level consideration
<jcowan>
So that assumes that 0.03% error is actually problematic, which since you are far below the human eye's fusion rate seems improbable to me.
<mathrick>
I think the answer is definitely "it's not gonna be anything provided by the implementation"
<mathrick>
jcowan: if the idle animation starts 10ms later, it's not an event. But if the audio sample is 10ms late, it's a huge event
<mathrick>
similarly, if the animation *starts* 10 ms late, it's less important than if the frame timing is off by 10ms frame to frame
<|3b|>
mathrick: no, i mean having the OS set to 1ms timer resolution on its own can cost power. cpu handling interrupts more often = less sleep
* |3b|
needs to get better at saving links, was reading some stuff about frame timing recently but can't find it anymore :(
puchacz has quit [Quit: Client closed]
puchacz has joined #commonlisp
<mathrick>
|3b|: right, I know there are OS-specific issues that might make it problematic. But it's generally not *inherent* to the idea of sleeping for a precise amount of time, and in fact variable timing is the primary way OS's save battery power these days. If all your processes are currently waiting for I/O and no time slice is due for the next 4ms, great, you can drop down into a lower P state for 4 ms!
<mathrick>
the fact that HPET is kind of a turd and doesn't do a very good job on x86-64 notwithstanding :)
<mathrick>
but your kernel has been doing precisely-timed sleeps for years
<aeth>
oh, and just to be unclear, nobody's going to be close to 100% in a game loop
<aeth>
at least, on any CPU remotely recent
masinter has joined #commonlisp
<aeth>
the kind of thing you want to do every tick or every n ticks isn't that involved, unless you're making a Factorio clone or something (that game tracks every individual item on conveyer belts)
paule32 has quit [Ping timeout: 252 seconds]
shka has quit [Ping timeout: 252 seconds]
jmdaemon has joined #commonlisp
dra has joined #commonlisp
tyson2 has joined #commonlisp
notzmv has quit [Ping timeout: 244 seconds]
mrcom_ has quit [Ping timeout: 252 seconds]
karlosz has quit [Remote host closed the connection]
nyx_land_ has joined #commonlisp
nyx_land has quit [Ping timeout: 248 seconds]
nyx_land_ is now known as nyx_land
titan has joined #commonlisp
Conatus has quit [Remote host closed the connection]
thuna` has quit [Remote host closed the connection]
pve has quit [Quit: leaving]
<aeth>
(random 10) => 6
<aeth>
just having some fun; if you saw the answer in #lispcafe, don't spoil it
<aeth>
you'll want a fresh REPL, and just like cold reading, it won't work on everyone, but it will surprisingly work on far more than 1/6 of the readers. Maybe 60% to 70%?
jmdaemon has quit [Read error: Connection reset by peer]
<aeth>
you would expect 1/10
Oladon has joined #commonlisp
ebrasca has quit [Remote host closed the connection]
titan has quit [Remote host closed the connection]
bc4m has joined #commonlisp
orestarod has quit [Ping timeout: 268 seconds]
<mathrick>
aeth: interesting. Does a static seed get saved in the default Debian image or something?
<mathrick>
it's 6 here as well
<mathrick>
and yes, the seed is saved in the image, it always proceeds in the same sequence
<aeth>
mathrick: default image in general, I think. SBCL.
<aeth>
although it would be interesting if Windows is different
<mathrick>
that's probably worthy of a bug report :)
dra_ has joined #commonlisp
flip214 has quit [Read error: Connection reset by peer]
<aeth>
if it's different or if it's the same? I'm assuming if it's different it would be a bug
<mathrick>
I'd say it's a bug that the random seed is static and saved in the image
jmdaemon has joined #commonlisp
dra has quit [Ping timeout: 248 seconds]
<mathrick>
as much as RANDOM is not expected to be cryptographically secure, this is a good deal less random than anyone's expectation I'd wager
<aeth>
the portable way to do it is to either create a local random state or set that to the global one
<aeth>
sbcl also lets you (sb-ext:seed-random-state 1234) but if you wanted a consistent seed across implementations you'd have to write your own random number generator
<aeth>
(even if other implementations also let you seed it)
flip214 has joined #commonlisp
<mathrick>
sure, but I don't think it's expected that the RANDOM-STATE is entirely fixed across invocations and across systems and builds
e3d3 has joined #commonlisp
<mathrick>
in other words, I expect my SBCL to start with a fresh random state each time it launches
<mfiano>
Then tell it to do that if you need that feature.
<aeth>
you can put that in your init
<mfiano>
The same could be said for the other side of the argument.
<aeth>
you can even sb-ext::seed-random-state with an OS call to the OS's random
<aeth>
in your init
<mathrick>
mfiano: except that code that wants a specific, fixed random state knows to arrange for it specially. OTOH, it's generally unexpected that all SBCL cores in the universe share their random state and it represents an unnecessary gotcha for casual use
<mfiano>
I think it's more of a gotcha that one would want a MT sequence to begin with.
<Bike>
re: you'd have to write your own random number generator
<mfiano>
I prefer cl-pcg myself
<hayley>
sicl-random anyone?
<mathrick>
mfiano: what does MT stand for?
<mfiano>
Mersenne Twister
<hayley>
minion: what does MT stand for?
<minion>
Monophagous Traulism
<mathrick>
oh, I don't think anyone would need an MT sequence, but CL code can reasonably want a couple random numbers for non-cryptographic use, such as simulating dice rolls
<mathrick>
or not MT sequence specifically
<mathrick>
just "something approximately random"
<mfiano>
MT has many flaws, and it's not considered a cryptographically secure PRNG
<mfiano>
It is quite dated, and the one SBCL uses is the older 32 bit one at that
<mathrick>
???
<mathrick>
how does that relate to any part of what I said?
e3d3 has left #commonlisp [#commonlisp]
<mfiano>
It's slow, and it fails many statistical tests. It wouldn't be simulating a dice roll very well. Those are fast and usually not biased
<mfiano>
It's also needlessly monolithic
comatory has quit [Ping timeout: 264 seconds]
comatory has joined #commonlisp
dra_ has quit [Remote host closed the connection]
jello_pudding has quit [Ping timeout: 255 seconds]