pranavats has left #commonlisp [Disconnected: Replaced by new connection]
pranavats has joined #commonlisp
tibfulv has quit [Remote host closed the connection]
tibfulv has joined #commonlisp
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 260 seconds]
jmd_ has quit [Ping timeout: 268 seconds]
jmdaemon has joined #commonlisp
dre has joined #commonlisp
attila_lendvai has quit [Ping timeout: 260 seconds]
frgo has joined #commonlisp
comatory_ has quit [Ping timeout: 252 seconds]
comatory_ has joined #commonlisp
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
comatory_ has quit [Ping timeout: 252 seconds]
comatory_ has joined #commonlisp
dlowe has quit [Ping timeout: 255 seconds]
comatory_ has quit [Ping timeout: 260 seconds]
comatory_ has joined #commonlisp
<dre>
how do I stop SBCL from taking std in and going back to the repl?
<dre>
ie:
<dre>
atm I can just freetype anything, and typing forms are not evaluated.. ^D doesn't do anything
<dre>
is it just in this "stdin mode" because I have slynk running?
<|3b|>
it is probably either in the middle of a READ (unclosed ( or " or whatever)), or it is still evaluating previous form
<|3b|>
in either case, ctrl-c might interrupt whatever it is doing and give you a debugger where you can try to determine what that was
<dre>
well if i connect to slynk, then eval `(read-line)` -- i can get what i wrote, line by line
<dre>
^C just shows up, doesn't break
<dre>
I wonder if it is some sort of stdin mode
<dre>
" ' ` doesn't finish the quote or whatever so that doesn't work
<|3b|>
is this running in a terminal and you started slynk manually, or in *inferior-lisp* started for you by slynk?
<dre>
if I give it a (defun ..) over slynk, I do get the `WARNING: redfining common lisp ......`
<|3b|>
well, you would have to match the unfinished whatever... if it was waiting for ) then " would just add another unfinished thing it would need to see before being able to see the ) it was waiting for
<dre>
terminal with starting slynk manually
dlowe has joined #commonlisp
<|3b|>
does the function to start slynk return?
jmdaemon has joined #commonlisp
<dre>
well i though that ^D would've done that
* |3b|
wouldn't expect it to
<dre>
ohhh that's ... intersting. is it because the slynk function hasn't finished?
<|3b|>
though i would have expected ^c to interrupt it
jmd_ has quit [Ping timeout: 260 seconds]
<dre>
nice. i can send it (quit) and I got a fatal error in sbcl. starting LDB
<dre>
cool, I think that solves it really
<dre>
but. hm, maybe not
<|3b|>
LDB sort of solves it in the sense that it will now respond to input, but probably fails in the sense that it wants LDB input rather than repl input
<dre>
yeah
<dre>
so this is how I'm starting it: sbcl --eval "(ql:quickload :slynk)" --eval "(slynk:create-server :dont-close t)"
* |3b|
suspects disconnecting sly would have worked better
<|3b|>
ah, with :dont-close it might not have
<dre>
I tried that, didn't work.. or well, I'm writing a vim sly clone, so if there's something I should've done here, then I should do that
<|3b|>
try starting without the create-server form, then enter it into the repl manually
jmd_ has joined #commonlisp
<|3b|>
if you don't get a repl prompt after that, then that's what the problem is
<dre>
with dont-close ?
<|3b|>
either way
* |3b|
would expect them to be the same until the first sly connection exits
<dre>
nope, I get a repl.
jmdaemon has quit [Ping timeout: 260 seconds]
<|3b|>
repl keeps responding after calling slynk:create-server?
<dre>
even when I start with the command above I get a repl for a little while. so I wonder if it was just a case of waiting for something
<dre>
if I left it hanging with an unbalanced " - how would I close / cancel it ?
<dre>
(I'm running linedit if that makes a difference, not to muddy the waters here...)
shka has joined #commonlisp
<|3b|>
hmm, possibly linedit could be confusing things
<|3b|>
looks like it has a M-H for help, possibly C-O would close whatever unfinished sexp?
<|3b|>
i guess if you have working sly connection you could also try listing threads and interrupting the repl thread from there to see what it is doing
<dre>
hmm, C-O didn't work for me, but in this case ))))))))))))))) did :P
<dre>
thanks you've been a tonne of help, i should get rid of linedit i think
<dre>
for now
pve has joined #commonlisp
<|3b|>
previously, was (read-line) returning stuff you had typed before, or stuff you typed after running (read-line)?
jmdaemon has joined #commonlisp
jmd_ has quit [Ping timeout: 252 seconds]
<|3b|>
if it was stuff you had typed before, probably something you evaluated before never returned
<dre>
hmm, yeah it was stuff I've done before, but i usually accidently get into this state, not explicitly running long running commands.
<dre>
might it be that linedit is being that function that isn't running properly?
<dre>
anyway my goal is to write the vim slynk client, so i need to not get too caught up in linedit shenanigans
* |3b|
was assuming accidentally long running (infinite loop etc)
<|3b|>
no idea what affects linedit has though, so skipping that and seeing if that helps sounds reasonable :)
<dre>
ah ye, by accidently i mean i was flapping around on the keyboard, not explicitly writing much code other than (print "hi")
aartaka has joined #commonlisp
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
Dynom_ has joined #commonlisp
Dynom_ is now known as Guest7158
jmd_ has quit [Ping timeout: 252 seconds]
jmdaemon has joined #commonlisp
pjb has joined #commonlisp
_cymew_ has joined #commonlisp
cage has joined #commonlisp
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
orestarod has joined #commonlisp
dlowe has quit [Ping timeout: 244 seconds]
random-jellyfish has quit [Quit: Client closed]
dlowe has joined #commonlisp
jmd_ has quit [Ping timeout: 268 seconds]
jmdaemon has joined #commonlisp
azimut_ has joined #commonlisp
azimut has quit [Ping timeout: 268 seconds]
pjb has quit [Ping timeout: 268 seconds]
dlowe has quit [Ping timeout: 260 seconds]
igemnace has joined #commonlisp
azimut_ has quit [Remote host closed the connection]
azimut has joined #commonlisp
dlowe has joined #commonlisp
random-nick has joined #commonlisp
epony has joined #commonlisp
igemnace has quit [Remote host closed the connection]
enzuru has quit [Ping timeout: 268 seconds]
epony has quit [Read error: Connection reset by peer]
enzuru has joined #commonlisp
<phoe>
is it possible to tell the slime inspector to not show inactive elements in vectors with fill pointer?
<phoe>
asking because seeing them confuses me to no avail - plump uses fill pointers to denote removed XML nodes, but these still show up in the inspector by default
epony has joined #commonlisp
<phoe>
doesn't seem so
<beach>
I highly recommend Clouseau over the SLIME inspector, but I don't remember whether it does what you want.
<beach>
It does.
<beach>
The elements beyond the fill pointer are in gray.
<_death>
phoe: maybe plump to set these elements to nil, to avoid leakage
<_death>
*should set
dlowe has quit [Ping timeout: 255 seconds]
ttree has quit [Ping timeout: 268 seconds]
<phoe>
beach: thanks, that's good to know
<phoe>
_death: hm, that's also a possibility, kinda orthogonal to my issue but it'd help to see NILs rather than possibly meaningful values
<_death>
it's also evidence for the usefulness of displaying the inactive elements
<_death>
so if you choose to modify the slime inspector, maybe the clouseau approach (display with indication) is a good idea
<phoe>
yes, it's useful to display the inactive elements - it's just that there's no clear visual indication that they are inactive, unless someone actually looks at the fill pointer and then the indices
szkl has quit [Quit: Connection closed for inactivity]
<Shinmera>
Aha. I'm not opposed ho making vector-pop null it, as long as the docementation doesn't prohibit us doing so.
<phoe>
actually I think that array-utils is doing the correct thing in not setting the element to NIL there
<Shinmera>
Can't look atm, currently on a train and all.
<phoe>
since the original CL:VECTOR-POP is specified to simply decrease the fill pointer and return the proper element
<_death>
vector-pop could've let you choose whether to destroy the reference or not
<Shinmera>
A train which is late by an hour... DB, you see.
<phoe>
_death: I don't think it can do so in a meaningful way - see specialized arrays
<_death>
since often you do want to do so, you may define an operator to do just that
pjb has joined #commonlisp
<_death>
phoe: could supply the value to use
<phoe>
_death: that works
theBlackDragon has quit [Quit: Lost terminal]
<phoe>
I think that ARRAY-UTILS:VECTOR-POP-POSITION is good with what it's doing and consistent with CL:VECTOR-POP, it's Plump that needs to explicitly null the value; would you accept a PR that does this?
<phoe>
Shinmera: ^
theBlackDragon has joined #commonlisp
waleee has joined #commonlisp
lisp123 has quit [Remote host closed the connection]
<Bike>
sure, but the language could have left it undefined instead of saying the elements have to remain, right?
<jcowan>
You don't actually have to overwrite them, any more than you actually have to have a garbage collector.
<pjb>
jcowan: _death is right. You can collect the unused slots later.
<_death>
but what if you want to keep them and later on set the fill pointer explicitly (say, back to the full vector's dimension)
<jcowan>
pjb: Malwarebytes thinks termbin.com hosts a trojan.
<pjb>
LOL. THe simpliest, flatest services are considered trojans by the javascript bloatwares…
<jcowan>
_death: Sure, it's' a question of which is a more likely scenario
<_death>
I suppose you could then write your own vector-pop that just decrements the fill pointer..
<_death>
yeah, as it is vector-pop has a gotcha
<jcowan>
I was actually not thinking of changing vector-pop, but of saying that all inactive elements of a vector are garbage.
<jcowan>
of course, if there is no fill pointer, all elements are active.
<_death>
but it's a feature that they are retained
<pjb>
jcowan: well, I think the reason why changing the fill-pointer doesn't change the slots, is that because vectors have an element-type, and that would require to have some element to store.
<pjb>
(decf (fill-pointer of-this-vector)) what to put in (aref of-this-vector 41) ??? 33 or 122 or something else?
<_death>
pjb: often you can deduce a garbage element for the upgraded array type.. and as I said earlier, in the worst case you can have the user provide a value
<_death>
*upgraded array element type
<pjb>
but that's the point, it's way too complicated for something that should be a mere increment or decrement!
<_death>
pjb: so vector-pop could either take more arguments, or there could be a vector-discard or something
<pjb>
and upgraded array element types are not the same depending on the implementaiton, therefore (decf (fill-pointer foo)) wouldn't be conforming anymore! (if you look at what's beyond the fill-pointer).
<jcowan>
pjb: The answer is, it is undefined. Pushing and popping are still cheap; when the gc runs, it reclaims the contents of inactive slots and nils them out.
<jcowan>
The road not taken, that's all.
<pjb>
Again,it's simplier, faster, and way more powerfull to let the user decide what to store when he decrements the fill-pointer.
<jcowan>
Neither simpler nor faster; it complicates the gc slightly.
<Shinmera>
phoe: I disagree, as the object/s left over are not the object/s that are popped out.
<pjb>
jcowan: it's simplier to provide two different functions (f) and (g) that each does its thing and to let the user combine then as he wants (progn (f) (g)) or just (f) rather than provide a function (fg) that prevent the user to do just (f)! It's obvious.
<pjb>
worse, if you provide (fg), then now the user must write (g^-1) and do (progn (fg) (g^-1)) when he wants (f)!!!
<jcowan>
So it would be simpler to provide (make-cons) to return a cons with arbitrary contents and then use rplaca and rplacd to initialize it?
sjl has joined #commonlisp
<_death>
if it would've been useful, why not?.. anyway, that's different from fill pointers and more like uninitialized contents of arrays
<phoe>
Shinmera: I don't think we understand each other, so maybe another way: (aref (p:children (p:strip (p:parse " <foo> </foo> "))) 1)
<phoe>
this returns a parentless empty text node
<phoe>
which is pretty much a (tiny) memory leak
<phoe>
the 1st element of that vector was instead set to NIL, that node would be GCable
* phoe
adds an "if" to the beginning of the above sentence
pjb has quit [Remote host closed the connection]
<_death>
think you mean the 2nd element ;)
enzuru has quit [Ping timeout: 268 seconds]
<phoe>
I think I mean the 1st (if you are indexing from 0)
<_death>
the first element has index 0.. the second element has index 1, etc.
jmdaemon has joined #commonlisp
<phoe>
oh well :D
waleee has quit [Ping timeout: 268 seconds]
<_death>
I've seen this confusion before.. maybe non-native speakers of english miss that "1st" is synonym for "first" and "2nd" for "second" (I'm not a native speaker myself)
<aeth>
fwiw, numbers seem to be the hardest part to learn from another language when written in Arabic numeral form... probably because they seem like English words mixed into otherwise non-English prose
<aeth>
if I see "42" I will read it as "forty-two" in my head
<aeth>
I wonder if "2nd" seems like nonsense in that sense.
<_death>
a german would read it as 2 and 40 :)
<jcowan>
aeth: I have the same experience
notzmv has joined #commonlisp
<contrapunctus>
_death: as would a Hindi speaker
<jcowan>
"Second" is a very strange case.
<aeth>
_death: that's one of those things when people learn English... they can say things that are technically valid, but rare. "2 and 40" is perfectly valid English, you will just only see it in a poem or similar, in order to twist the language to meet the structure of the poem/song/etc.
<_death>
maybe because english is a germanic language
aartaka has quit [Ping timeout: 260 seconds]
<jcowan>
"When I was one and twenty / I heard a wise man say / Give pounds and crowns and shillings / But not your heart away ...
<aeth>
_death: yes, a lot of Germanic or Romance things will technically *work* in English
<aeth>
But it's definitely weird by any linguistic standard that (first '(1 2 3)) => 1 but (nth 1 '(1 2 3)) => 2
<phoe>
_death: "zeroth", yes
<_death>
another one is here people would say 3500 as "3 thousands and 5 hundreds" but english (american?) use often may be 35 hundreds
<jcowan>
American
<phoe>
_death: wait until some German folk start reading 52 as "two-and-fifty"
<_death>
I mentioned this ;)
<phoe>
but, oh well, I think the Lisp nomenclature is that "first" refers to the element with index 0
<phoe>
so I stand corrected
<phoe>
_death: woop :D
<aeth>
I tend to say "one hundred and one, one hundred and two, ..." because it has a better rhythm to it, but "one hundred one", "one hundred two", etc. is more correct, at least in American English
<_death>
but there are even worse differences.. like when telling the time, or the hindi use of lakhs (iirc)
<aeth>
well, perhaps "a hundred and one" sounds even better
<jcowan>
In Welsh, you count one ... ten, one on ten, two on ten, ... fiveten, one on fiveten, two on fiveten, twonine, four on fiveten, twenty, one on onetwenty, ... four on fiveten on onetwenty, twotwenty, ... hundred
<jcowan>
come to think of it, I guess the word for 20 has "one" in it, so should be glossed "onetwenty"
<_death>
then there's french :)
<jcowan>
well, in most places
<jcowan>
Wikt says septante is used in Belgium, Switzerland, Congo, Acadian, and Savoyard
<Shinmera>
phoe: yea? I just disagree with your idea that it *shouldn't* be unset in array-utils
jmd_ has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
jmdaemon has quit [Ping timeout: 252 seconds]
enzuru has joined #commonlisp
<_death>
jcowan: ah, didn't know that.. never been to a french-speaking region (except quebec for a bit, I guess).. at school I learned a bit of french, but don't remember learning to count further than 10 ;)
<aeth>
school French would be French French, from France.
<aeth>
(on the other hand, school Spanish is usually Mexican Spanish in North America)
<_death>
well, depends on the teacher ;)
<aeth>
("computadora", not "ordenador" is a good test)
<aeth>
(but "computador" also apparently exists)
jmd_ has quit [Read error: Connection reset by peer]
jmdaemon has joined #commonlisp
jmd_ has joined #commonlisp
jmdaemon has quit [Ping timeout: 268 seconds]
waleee has joined #commonlisp
gxt_ is now known as gxt
<jcowan>
_death: Ah. I thought you brought up French because in the French of France and Quebec 70, 80, 90 are "sixty-ten", "four-twenties", "four-twenties-ten". This is an imitation of the Celtic pattern.
<_death>
jcowan: I did.. but I didn't know it was conditioned on the place
<phoe>
Shinmera: my idea is there for consistency with vector-pop which does not overwrite the popped element; I thought that a pop at arbitrary location should have the same behavior
<Shinmera>
the element beyond the fill pointer is not the popped element
<phoe>
oh yes - I see what you mean now, it's the same as one of the other elements
<phoe>
for whatever reason I thought you were doing something like ROTATEF on them
<phoe>
(which would also, in a weird way, be consistent with VECTOR-POP, albeit slower)
notzmv has joined #commonlisp
azimut has quit [Ping timeout: 268 seconds]
tyson2 has joined #commonlisp
<Shinmera>
right. So a PR to array-utils to make the behaviour of nulling documented would be great.
<phoe>
then I guess the only issue is to find the "neutral element" for the different array specializations to find the "neutral element" in question... 0, 0f0, 0d0, NIL
thomaslewis has joined #commonlisp
<Shinmera>
right.
<phoe>
the ideal way would be to query the user for that, but that would be an API change
<phoe>
like, two more optional arguments? erase-element-p + default-value to erase with
<Shinmera>
That will break things if it can't already reliably determine a proper default to use on its own.
<Shinmera>
And if we have that anyway, imo, that's good enough.
<phoe>
yes, so erase-element-p must be false by default for backwards compatibility
<Shinmera>
No
waynebarry has quit [Quit: Client closed]
<Shinmera>
Just determine a default with array-element-type
<phoe>
hmmm - bit, single-float, double-float, t, are there specialized arrays whose AET is not compatible with any of these?
<phoe>
like, in the actual wild
<Shinmera>
doubt it.
aartaka has joined #commonlisp
<Shinmera>
the semantics don't allow it for anything except things that can't be EQ tested.
<Shinmera>
so
<phoe>
welp, complexes
<phoe>
and these are not EQ-testable
<phoe>
so this can get a bit nasty
* phoe
thinks
<Shinmera>
what's the problem, just #c(0,0)
<phoe>
need to handle (complex integer), (complex single-float), and (complex double-float)
<_death>
note that #C(0 0) is 0.. similarly for other complex subtypes
<Shinmera>
tbh I doubt any implementation actually implements specialised arrays for it exactly because of that complexit
<Shinmera>
y
<_death>
(welp, not for other subtypes, heh)
<Shinmera>
just as it can't for bignums
<phoe>
yes, SBCL seems to do it only for floats
* phoe
will go for a walk and think about it
<Shinmera>
enjoy
brettgilio has quit [Ping timeout: 268 seconds]
thomaslewis has left #commonlisp [#commonlisp]
cosimone` has quit [Remote host closed the connection]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 252 seconds]
thomaslewis has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
thomaslewis has left #commonlisp [#commonlisp]
<contrapunctus>
Shinmera: hey o/ Someone I know reckons you wrote an object store/ODBMS, but I can't seem to find it. And I'm guessing it's not Ubiquitous, although there's some overlap...any idea?
<Shinmera>
I have not.
<Shinmera>
Ubiquitous is the closest, being that it stores objects and has "transactions", but not really anything that would be usable as a large-volume DB.
<Shinmera>
I just use SQL for scalable data storage
<contrapunctus>
I see...thanks.
<Shinmera>
I thought about doing something like it many years ago, but these days I consider it a solved problem, as in solved much better than I ever could by other services and libraries.
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
waynebarry has joined #commonlisp
cosimone has joined #commonlisp
Devon has quit [Ping timeout: 268 seconds]
<phoe>
Shinmera: do you upcase T even when it denotes a type?
comatory_ has quit [Ping timeout: 268 seconds]
<Shinmera>
I don't know about my historical precedent, using T for a type is very rare
<Shinmera>
I guess typecase would be the most common, in which I do upcase it.
comatory_ has joined #commonlisp
<phoe>
okie
<Shinmera>
if you're talking about, like (eql T (array-element-type x)) then it's still upcased because it's a constant for itself ;)
<phoe>
(subtypep 'T aet)
<phoe>
more like this
<Shinmera>
then I guess not.
<Shinmera>
though using subtypep seems silly, there's no type above T.
comatory_ has quit [Ping timeout: 260 seconds]
<phoe>
kinda sorta, yeah, it's for uniformity with all the other subtypeps in the function
<phoe>
I'll push it for review in a sec
<masinter>
there are types where it is undecidable whether they are proper subtypes
<Shinmera>
is there a need for subtypep at all? we're testing low types already.
<Shinmera>
masinter: uh. yeah, and?
<_death>
maybe what you actually want is (subtypep 'null type) and if true set to NIL
waynebarry has left #commonlisp [#commonlisp]
comatory_ has joined #commonlisp
<phoe>
Shinmera: yes, in case of integer types
<Shinmera>
ah. that's the only case, though, yeah?
<phoe>
you don't know if AET is going to be BIT or (UNSIGNED-BYTE 2) or (SIGNED-BYTE 2) or whatever
<phoe>
I don't know, truth be told; I'd rather not do optimizations like that at the moment
<phoe>
I'm only getting myself rusted off in lisp after a long hiatus
* phoe
pushes
tyson2 has quit [Remote host closed the connection]
<phoe>
I don't know how to write tests for that - AFAIK the only array specializations guaranteed by the specification are T, BIT, BASE-CHAR, and CHARACTER
<Shinmera>
there you go then.
<phoe>
I guess I could add a bit vector/string test if we care enough
comatory_ has quit [Ping timeout: 260 seconds]
<Shinmera>
and, now that you mention it you missed 'character for your array-empty-element function :)
<phoe>
aw shite
<phoe>
what do we overwrite with, #\Nul?
<Shinmera>
(and the last cond clause should be T not t)
<Shinmera>
sure.
comatory_ has joined #commonlisp
<phoe>
I knew we'd miss something and I'm sure that pushing this change is going to have someone remind us that we missed another something
* phoe
fixes
<_death>
for such objects it's not really important to overwrite them anyway
<phoe>
...kinda, yeah
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<phoe>
maybe we should only limit ourselves to when the AET is T?
epony has quit [Remote host closed the connection]
<_death>
bignums may be important.. double-floats/single-floats, meh
<Shinmera>
Glad to have another customer in any case.
<mathrick>
although all have something going for them and something I'm not 100% happy with, but I did my best to resist the temptation to write Yet Another one :)
<Shinmera>
What else is upsetting?
<mathrick>
I'm already writing Yet Another game engine, that's more than enough
<Shinmera>
terrible :v
<mathrick>
in my defence, I'm doing my best to make this one well-documented!
<Shinmera>
I *do* wish Trial was used by others.
jeosol has quit [Quit: Client closed]
<mathrick>
that's 95% of the reason I haven't used any of the existing ones
<Shinmera>
Partial docs will happen early next year
<mathrick>
Shinmera: my two biggest complaints so far are: 1) operations on default stuff (ie. repl faucet & co.) are cumbersome, largely because of piping 2) I'm a bit concerned that turning off logging has basically no effect on performance, but that's offset by the fact it's happening in another thread, so it's not likely to be a massive issue
<Shinmera>
you can wrap everything in a muffle-logging, which should aid performance.
<Shinmera>
if that's a concern, for some reason?
<mathrick>
actually, why didn't you base Verbose on DEEDS instead of Piping? I assume the reason is "I wrote DEEDS after Verbose"
<Shinmera>
deeds is wayyyy later
<Shinmera>
(and also sucks imo)
<mathrick>
I mean turn off in the sense of "logging at a level that's filtered out"
<mathrick>
oh, you think so?
<mathrick>
how does it suck?
<mathrick>
it is a bit, hmm, large
<Shinmera>
it goes too far in the other direction, being too bulky.
<jcowan>
What are the float types of Clasp? I assume that short = single = binary32 and double = long = binary64, but is that wrong?
<mathrick>
I do like the idea of optimising the loop by precompiling them
<Shinmera>
jcowan: why don't you try #clasp
<Shinmera>
mathrick: I mean... logging *really* is not a performance concern if you're actually making a game
<mathrick>
well, it depends on how much stuff you turn logging on
<Shinmera>
let's put it this way: I'm making actual games and logging is so far down the line of anything it doesn't even appear anywhere.
<mathrick>
sure, I get that, and that's also why I'm not super concerned right now and will wait until I see performance issues. But I also want to be able to log multiple times per frame if needed :)
<Shinmera>
People are way too scared of the performance boogeyman.
<mathrick>
I'm not scared, but I also want to be mindful
<mathrick>
Shinmera: so you don't actually use DEEDS for your event handling? Or you do, but aren't super happy with it?
<Shinmera>
I use Deeds in Maiden, which I also hate :)
<mathrick>
cause I am looking at either DEEDS or event-glue I think to avoid writing my own event handling implementation
<mathrick>
heh
<Shinmera>
I don't use it in Trial.
<mathrick>
what do you use in Trial?
<aeth>
Shinmera: logging seems to be more of a thing for multiplayer games, in particular if you're running a game server
<mathrick>
Shinmera: heh, that's tiny. I might just whip something up then
<aeth>
wow
<Shinmera>
the ghosts whisper in your ear: just use trial... ;)
<aeth>
amazing how different Shinmera's approach is to mine
ttree has joined #commonlisp
<aeth>
I "unobject" everything in my game loop since it's a loop
<aeth>
meanwhile that's entirely object oriented
<Shinmera>
CLOS is perfectly fine to use.
<mathrick>
Shinmera: well, I mean, it does sound much like what I'm trying to get at the end of my engine journey, but also I really want mine to be documented
* Shinmera
sighs
* Shinmera
stares longingly into the distance
pve has quit [Quit: leaving]
_cymew_ has quit [Ping timeout: 268 seconds]
Cymew has joined #commonlisp
<lagash>
Careful, the distance might stare back!
kaskal has quit [Ping timeout: 260 seconds]
tyson2 has joined #commonlisp
karlosz has joined #commonlisp
karlosz has quit [Quit: karlosz]
Cymew has quit [Ping timeout: 252 seconds]
bitmapper has joined #commonlisp
waleee has quit [Ping timeout: 248 seconds]
rgherdt has quit [Remote host closed the connection]
thomaslewis has joined #commonlisp
thomaslewis has left #commonlisp [#commonlisp]
ttree has quit [Ping timeout: 252 seconds]
dtman34_ has quit [Ping timeout: 244 seconds]
dre has quit [Ping timeout: 260 seconds]
ecocode[m] has joined #commonlisp
kaskal has joined #commonlisp
shka has quit [Ping timeout: 252 seconds]
comatory_ has quit [Ping timeout: 252 seconds]
comatory_ has joined #commonlisp
ttree has joined #commonlisp
euandreh has quit [Ping timeout: 268 seconds]
tyson2 has quit [Remote host closed the connection]
Alfr has quit [Quit: Leaving]
morganw has quit [Remote host closed the connection]
<neominimum>
Good morning, is there anyone with Clog experience in here?
thomaslewis has joined #commonlisp
Alfr has joined #commonlisp
madnificent has quit [Read error: Connection reset by peer]