semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
semz has joined #commonlisp
certainty has joined #commonlisp
certainty has quit [Ping timeout: 256 seconds]
contrapunctus has joined #commonlisp
chomwitt has quit [Ping timeout: 255 seconds]
bh34e5 has joined #commonlisp
dcb has quit [Read error: Connection reset by peer]
dcb has joined #commonlisp
dcb has quit [Max SendQ exceeded]
dcb has joined #commonlisp
rgherdt has quit [Quit: Leaving]
tyson2 has joined #commonlisp
certainty has joined #commonlisp
ronald_ has joined #commonlisp
<mfiano>
Because LOOP is so complicated, is it permissible to bind a per-iteration variable (FOR and aliases) the bind an variable that is previous marked special, and have access to the new dynamic binding across any functions the loop iteration may call?
<mfiano>
s/the bind/that binds/
jmdaemon has joined #commonlisp
certainty has quit [Ping timeout: 276 seconds]
<younder>
COBOL in Lisp = LOOP
<bjorkintosh>
is LOOP avoidable?
<younder>
Let's face it the loop was really the only cool feature of Cobol
<younder>
bjorkintosh: yes, entirely avoidable
<bjorkintosh>
I thought it was the 'not having to write pay roll and accounting programs in Assembly' part.
<younder>
Embedded languages is one of the cool features of Lisp. I like loop. But if you don't you don't have touse it.
<younder>
There are many cl-ppcre regexps and of course April APL
<bike>
mfiano: yeah, if your variable is globally special than the bindings loop makes should also be special. i think.
<younder>
CL is not PURE, that is a Scheme thing.
<mfiano>
I am assuming such, just because of special semantics, but, we also really have MIT LOOP and I don't want to base things on a logical conclusion and an implementation's behavior.
<mfiano>
Or I suppose we have SICL loop too
<mfiano>
s/also/only/
<childlikempress>
'A variable binding has lexical scope unless it is proclaimed special'
<younder>
Loop has been around since the inception of Common Lisp an it isn't changing nor going anywhere
* mfiano
needs to stop making typos today
<childlikempress>
6.1.2.1
<childlikempress>
I don't see what space there is for things to go wrong
<mfiano>
Several LOOPS, all based on the reference implementation except one that I know of
<younder>
engage flyspell as beach suggested to me
<bike>
"A variable binding has lexical scope unless it is proclaimed special;" oh, yeah, there you go. thanks childlikempress.
<younder>
Yeah the spec is obtuse
<mfiano>
Can't get any more obvious than that.
<younder>
Took me years to get what special ment, but maybe I am just dumb ;)
<bjorkintosh>
younder, I suspect you were teaching yourself.
<younder>
indeed
<younder>
Luckily today we have Practical Common Lisp, nothing like that existed back in 1998
<younder>
it was all RTFM, which quite frankly didn't help
dcb has quit [Ping timeout: 255 seconds]
<aeth>
nothing beats just coding
dcb has joined #commonlisp
<aeth>
though by doing that without reading you do wind up with code that happens to work on the current system, which may or may not always do so in the future
<younder>
Yeah, Don't read anything I wrote before 2010. It is all shit ;)
<younder>
But we all learn eventually-
<aeth>
no, most people give up before they learn
<aeth>
survivorship bias
<younder>
Well I didn't
<younder>
That said Vulcan has it's own style. You can't really write Vulcan in a Lisp Style. It dictates it's own style. It is what it is.
<edgar-rft>
younder: you're not dumb, you're just special :-)
<younder>
I am hoping to bring Vulcan to CL. Without the lag. That might mean modding CFFI
<aeth>
k
<aeth>
vulkan
<younder>
The marshaling of packed structures is a problem
<younder>
30 FPS is not acceptable by today's standards we need 60 FPS
random-nick has quit [Ping timeout: 264 seconds]
<aeth>
The reason, imo, to go with Vulkan is that it, strangely enough, probably has better support than OpenGL 4.6 and you need (at least) one of the two to use SPIR-V.
<younder>
yes
<aeth>
Performance doesn't really come into the picture. First, a lot of initial Vulkan renderers didn't even beat the OpenGL ones in performance, which shows that it's hard to do (and that was probably in C++). Second, most people just don't need that kind of performance.
<aeth>
But SPIR-V means you can write a "proper" GPU Lisp instead of one that just transpiles to GLSL and shares GLSL's features and limitations exactly.
<aeth>
(or HLSL, but now you're just compiling to HLSL to probably then compile to GLSL)
<younder>
Wrong. I need gaming performance. Even though I am myself not into games
<aeth>
though I wonder how much SPIR-V tools can handle kebab-case for variable/function names and how much they don't even think about it.
<aeth>
younder: you don't have the budget to make a game where performance matters; nobody here does
<aeth>
content's expensive to make.
<younder>
true
<aeth>
either in money or time
<younder>
but we try
<aeth>
I think the only way you could possibly have to care about performance is if you were to write a ray tracing only game engine. At that point, it wouldn't really matter how elaborate the graphics are. Just shiny cubes or whatever would work.
<younder>
We just get the performance right, let someone else worry about the game
<aeth>
that's exactly backwards, though
<younder>
Vulcan is not a game engine, godot is a game engine
<aeth>
performance is a bottomless pit of work, largely isolated from everything else, where it eventually adds up...
<aeth>
you just have to avoid the obvious pitfalls (you can't not care about it at all or your architecture will be incompatible with future optimizations, if it even runs in real time at all) and leave the rest for someone to get to later
<younder>
I am a old C programmer. I actually like performance oriented programming
<aeth>
Imo, you have to architecture your code as if you are (or someone else is) going to come back later on and actually micro-optimize the heck out of it. But you probably won't get that far.
<younder>
Probably why people hated my old Lisp code
<aeth>
so e.g. ECS? yeah, that's fine. Writing SIMD to make that vec+ extra special fast? Too much work.
<younder>
Particularly XACH
<aeth>
On the other hand, I'm not a big fan of the heavy use of CLOS or methods in game engine architectures because at that point, you're probably making it architecturally impossible to pay someone later on to come triple the size of your code to make it 30% faster.
<younder>
I just need a interface to Vulcan. They do the optimizations.
<younder>
I am not micro optimizing with SIMD instructions or any thing like that.
<aeth>
Vulkan, if anything, is going to make your stuff slower. Because you're going from a giant OpenGL black box heavily optimized by Nvidia or AMD (but probably not so much Intel) and turning it into a not-so-optimized middle layer on top of a lower-level API.
<aeth>
But it does mean pulling more of the layer of the graphical application into CL. And in theory Mezzano or whatever other LispOS could implement the easier-to-implement Vulkan API, while none of them will ever add OpenGL.
<aeth>
It also means a proper Lisp on the GPU, through SPIR-V, with no transpiling to a C-like shader language in the middle (except when you turn SPIR-V into one to run in web browsers... oh well).
<aeth>
So I think it's worth it, but it's probably not going to help with performance.
certainty has joined #commonlisp
<aeth>
OpenGL also has some really weird cruft in its API design.
<hayley>
aeth: Pay me to triple the size of SBCL to make your CLOS 30% faster.
<aeth>
hayley: I almost mentioned that it doesn't need to be done in the application and it could be done in the implementation. But CLOS really isn't the right approach for this sort of thing, which should really be done at compile time. Though I guess you could roughly approximate it with a JIT and/or a ton of inlining.
certainty has quit [Ping timeout: 256 seconds]
<aeth>
when you play with the implementation itself (especially e.g. JIT) you can do whatever
X-Scale has joined #commonlisp
gooba has quit [Remote host closed the connection]
prpldmn has joined #commonlisp
gooba has joined #commonlisp
zetef has quit [Ping timeout: 256 seconds]
<aeth>
(fwiw, I do have e.g. a defclass for "shader"... 0 CLOS makes about as much sense as writing a 3D renderer entirely in classes and methods)
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
certainty has joined #commonlisp
dajole has joined #commonlisp
certainty has quit [Ping timeout: 255 seconds]
tyson2 has quit [Read error: Connection reset by peer]
contrapunctus has left #commonlisp [#commonlisp]
jon_atack has quit [Read error: Connection reset by peer]
jonatack has joined #commonlisp
contrapunctus has joined #commonlisp
Pixel_Outlaw has joined #commonlisp
certainty has joined #commonlisp
certainty has quit [Ping timeout: 255 seconds]
ronald_ has quit [Ping timeout: 256 seconds]
ronald_ has joined #commonlisp
akoana is now known as n-choose-k
n-choose-k is now known as akoana
dcb has quit [Quit: MSN Messenger 4.1.1]
X-Scale has quit [Quit: Client closed]
certainty has joined #commonlisp
certainty has quit [Ping timeout: 256 seconds]
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 256 seconds]
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
X-Scale has joined #commonlisp
habamax has joined #commonlisp
certainty has joined #commonlisp
certainty has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 255 seconds]
certainty has joined #commonlisp
akoana has quit [Quit: leaving]
ym has quit [Ping timeout: 252 seconds]
zxcvz has joined #commonlisp
zxcvz has quit [Client Quit]
bh34e5 has quit [Ping timeout: 264 seconds]
X-Scale has quit [Ping timeout: 250 seconds]
bitmapper has quit [Quit: Connection closed for inactivity]
Pixel_Outlaw has quit [Remote host closed the connection]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
habamax has joined #commonlisp
attila_lendvai has joined #commonlisp
zetef has joined #commonlisp
monospod has joined #commonlisp
monospod has quit [Remote host closed the connection]
monospod has joined #commonlisp
monospod has quit [Remote host closed the connection]
monospod has joined #commonlisp
monospod has quit [Remote host closed the connection]
monospod has joined #commonlisp
monospod has quit [Remote host closed the connection]
prpldmn has quit [Quit: quit]
anticrisis has quit [Read error: Connection reset by peer]
_cymew_ has joined #commonlisp
_cymew_ has quit [Ping timeout: 255 seconds]
rgherdt has joined #commonlisp
shka has joined #commonlisp
mgl_ has joined #commonlisp
donleo has joined #commonlisp
dajole has quit [Quit: Connection closed for inactivity]
pve has joined #commonlisp
amb007 has quit [Ping timeout: 256 seconds]
amb007 has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 264 seconds]
Lord_of_Life has joined #commonlisp
danlitt has joined #commonlisp
_cymew_ has joined #commonlisp
mgl_ has quit [Ping timeout: 264 seconds]
markb1 has quit [Ping timeout: 256 seconds]
dino_tutter has joined #commonlisp
minion has joined #commonlisp
minion has quit [Excess Flood]
mgl_ has joined #commonlisp
mgl_ has quit [Ping timeout: 264 seconds]
tyson2 has joined #commonlisp
waleee has joined #commonlisp
lisper29 has joined #commonlisp
random-nick has joined #commonlisp
thollief has joined #commonlisp
amb007 has quit [Ping timeout: 255 seconds]
amb007 has joined #commonlisp
chomwitt has joined #commonlisp
cage has joined #commonlisp
mgl_ has joined #commonlisp
jon_atack has joined #commonlisp
jonatack has quit [Read error: Connection reset by peer]
mgl_ has quit [Ping timeout: 256 seconds]
zetef has quit [Ping timeout: 256 seconds]
mgl_ has joined #commonlisp
waleee has quit [Ping timeout: 255 seconds]
zxcvz has joined #commonlisp
nij- has joined #commonlisp
Brucio-61 is now known as scymtym
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
zxcvz has quit [Quit: zxcvz]
ym has joined #commonlisp
lisper29 has quit [Quit: Leaving]
markb1 has joined #commonlisp
zetef has joined #commonlisp
attila_lendvai has quit [Ping timeout: 255 seconds]
attila_lendvai has joined #commonlisp
dnhester26 has joined #commonlisp
gooba has quit [Remote host closed the connection]
gooba has joined #commonlisp
nij- has quit [Ping timeout: 255 seconds]
shka has quit [Ping timeout: 252 seconds]
dnhester26 has quit [Remote host closed the connection]
waleee has joined #commonlisp
notzmv has quit [Ping timeout: 268 seconds]
dnhester26 has joined #commonlisp
contrapunctus has left #commonlisp [#commonlisp]
masinter has joined #commonlisp
_cymew_ has quit [Ping timeout: 264 seconds]
dino_tutter has quit [Ping timeout: 256 seconds]
contrapunctus has joined #commonlisp
bh34e5 has joined #commonlisp
bjorkintosh has quit [Quit: Leaving]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
dnhester26 has quit [Remote host closed the connection]
dnhester26 has joined #commonlisp
Grauwolf has quit [Quit: WeeChat 4.0.5]
Grauwolf has joined #commonlisp
danlitt has quit [Ping timeout: 256 seconds]
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
jmd_ has quit [Ping timeout: 256 seconds]
danlitt has joined #commonlisp
igemnace has joined #commonlisp
<jcowan>
younder: The ALTER...TO PROCEED TO... feature is much cooler.
monoidog has joined #commonlisp
<jcowan>
In addition, 60 FPS is insufficient, we need 9600 FPS.
<Equill>
You're saying we need to go ballistic?
<jcowan>
If not hyperbolic.
<Equill>
Over 9000 sounds hyperbolic to me.
<Equill>
On more CL-related news, that post-Quicklisp thing I was talking about a while ago, is starting to take workable shape. A bootstrap client will be an interesting job, though: now I understand why QL's client is HTTP-only.
<Equill>
I just need to write some docs, so people know what they're looking at. It's very much a prototype, especially the UI.
prokhor has quit [Remote host closed the connection]
<jcowan>
Better to be hyperbolic than hypergolic.
<Equill>
True, but are you sure you're not putting too much energy into this?
dnhester26 has quit [Remote host closed the connection]
ronald_ has quit [Ping timeout: 256 seconds]
danlitt has quit [Ping timeout: 252 seconds]
dcb has joined #commonlisp
dcb has quit [Max SendQ exceeded]
dcb has joined #commonlisp
<mfiano>
FPS is insufficient for measuring performance
dcb has quit [Client Quit]
ronald has joined #commonlisp
<mfiano>
Because such values are compared relative to one another, which doesn't make much sense due to the non-linearity. If you want to measure how long it takes to render, then do that, expressed as some unit of time per frame, rather than frames per some unit of time.