dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
attila_lendvai_ has quit [Ping timeout: 268 seconds]
printfdebugging has quit [Quit: printfdebugging]
decweb has quit [Quit: Konversation terminated!]
rkazak has quit [Ping timeout: 245 seconds]
Oddity has joined #commonlisp
rkazak has joined #commonlisp
<fosskers>
fengshaun: in this case it's not enough to specify your own defmethod with an `:after`, etc.?
printfdebugging has joined #commonlisp
printfdebugging has quit [Client Quit]
admich1 has quit [Ping timeout: 276 seconds]
shka has quit [Ping timeout: 245 seconds]
istewart has quit [Quit: Konversation terminated!]
shka has joined #commonlisp
admich1 has joined #commonlisp
istewart has joined #commonlisp
dtman34 has joined #commonlisp
<fengshaun>
boigahs, fair enough
<fengshaun>
fosskers, I did not know about that, I haven't gotten into CLOS yet, will read up
<fengshaun>
thanks
rkazak has quit [Ping timeout: 276 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
rtypo has quit [Ping timeout: 260 seconds]
ndanilov has quit [Remote host closed the connection]
ndanilov has joined #commonlisp
<beach>
fengshaun: I highly recommend you check out CLOS.
triffid has quit [Remote host closed the connection]
triffid has joined #commonlisp
steew has quit [Remote host closed the connection]
rkazak has joined #commonlisp
smlckz has quit [Ping timeout: 244 seconds]
steew has joined #commonlisp
steew is now known as Guest2579
smlckz has joined #commonlisp
smlckz has quit [Changing host]
smlckz has joined #commonlisp
akoana has quit [Quit: leaving]
rkazak has quit [Ping timeout: 248 seconds]
dtman34 has joined #commonlisp
admich1 has quit [Remote host closed the connection]
admich1 has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
mange has joined #commonlisp
printfdebugging has joined #commonlisp
notzmv has quit [Ping timeout: 248 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
istewart has quit [Quit: Konversation terminated!]
King_julian has quit [Ping timeout: 245 seconds]
rkazak has joined #commonlisp
King_julian has joined #commonlisp
<pl>
CLOS is awesome
<pl>
one of the biggest things Dylan promised back when it was still S-expression based was to make CLOS-like ubiquitous
<fengshaun>
yea, I'm sloooowly going through practical CL, I'm also doing a relatively big project in cl right now so I'm jumping topics
rkazak has quit [Ping timeout: 252 seconds]
<fengshaun>
speaking of jumping, I'm hitting an issue with type assertions in sbcl, I feel like I'm not understanding something. Purpose is to have type check on the function as seen here, but I'm getting `Type assertion too complex`. The return value of the function is just a byte vector, so I'm not sure why sbcl is asking me to add (values ...) to return type.
<beach>
fengshaun: I think you should worry about types much later in your project.
<beach>
fengshaun: It seems common for people who come from statically typed languages to overemphasize type declarations early on.
<fengshaun>
alright
<fengshaun>
would still love to understand it though, if there are any resources
<beach>
fengshaun: Also, something many people are missing, is that type declarations can be totally ignored by the implementation, and that type declarations are promises to the compiler, and not as in statically type languages, a demand for the types being checked.
<beach>
So, in fact, using type declarations may make your program less safe.
<beach>
Less safe, and harder to debug, because type declarations may make the implementation check fewer types (since the type has been promised after all), so error messages may be more cryptic, or you can get memory faults instead of good error conditions.
<fengshaun>
ah fair enough
<fengshaun>
thanks
<beach>
Sure.
<beach>
fengshaun: If you are worried about types, I suggest you use CHECK-TYPE instead of type declarations.
<fengshaun>
oh alright, thanks!
<fengshaun>
I want to make sure I'm getting correct inputs just in case I make errors
<fengshaun>
thanks
<beach>
Sure.
<aeth>
the declaim ftype syntax is... counterintuitive. It's best to generate it if you decide to go that way.
<aeth>
you can fix anything with macros
<beach>
fengshaun: Also, if you use generic functions, then you get some automatic type checks in that methods are applicable only when given object of the right class.
<fengshaun>
I've been looking at the output of (describe) to figure things out
dtman34 has joined #commonlisp
<fengshaun>
input side is understandable, I'm not sure what I'm doing for the output side though, sbcl describe just says '*' and moves on
<aeth>
Annoyingly, there is no solution for types. CHECK-TYPE loses a lot of useful information because it's a runtime continuable error so the compiler doesn't have to compile if you call something with the wrong type because the compiler can, for some reason, think that maybe you want the thing to fail at runtime and continue only after being prompted to replace the value at runtime.
<aeth>
s/doesn't have to compile/doesn't have to compiler error/
bpanthi977 has joined #commonlisp
<fengshaun>
interesting, so compile-time type checks may not be the way to go
<fengshaun>
at least exhaustively
<beach>
aeth: How is that different from type declarations. They also do not require the compiler to signal errors or warnings.
<beach>
fengshaun: If you want compile-time checks, I recommend you use a statically typed language.
<aeth>
DECLARE does check types, in SBCL, anyway. beach is right that there could be an evil-CL that assumes types outside of (safety 0), which is essentially why you should never use (safety 0), too.
<aeth>
To a limited extent, anyway. Better than nothing.
<beach>
Oh, so we are not using Common Lisp, but SBCL?
<fengshaun>
sbcl does seem to do compile-time type checking which has been really solid so far
<beach>
fengshaun: You need to decide, then, whether you are programming for (current versions of) SBCL or for Common Lisp.
<fengshaun>
Just trying to figure out how to specify the output type with declaim
<beach>
fengshaun: People coming from single-implementation languages often do not see the difference.
<fengshaun>
I know, I'm playing around
<aeth>
It still runs on other implementations. It's just potentially unsafe. You could, for instance #+sbcl around the type declarations if you're that worried.
<fengshaun>
I'm not worried, it's not that serious
<aeth>
Not having the compilation typecheck step would have wasted me weeks on something that already took me a year.
bpanthi977 has quit [Ping timeout: 276 seconds]
<beach>
aeth: But I am not sure (from what I hear you say sometime) that your kind of project is representative.
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
<aeth>
Well, no, it's not... what I'm talking about in particular is a 10,000 line not-quite-yet-complete SPIR-V shader-compiler that also targets CL
<fengshaun>
impressive
<aeth>
Which is, incidentally, probably about how large something needs to be before such things matter
<aeth>
But you have to fully commit to it, unfortunately.
<aeth>
Otherwise you just lose information
<aeth>
which means spending a day or so adding type anotations because the whole file doesn't really do much until the whole file's functions do
<fengshaun>
make sense
<fengshaun>
makes*
<aeth>
It's not an impossible style, but it's not something you go to first in a new project.
<fengshaun>
fair enough, I'll take it easy on type for now
<aeth>
The thing is, you have to rely heavily on metaprogramming. And then sometimes SBCL decides to treat the whole file compilation unit as the whole file compilation unit, which means you have to start recompiling files instead of recompiling forms, and these files heavily use metaprogramming, and do a bunch of not-normally-done typechecking, etc. So you give yourself long (maybe 2 second) compilation times!
<aeth>
Which is not even getting into the issue with other implementations (which is usually just CCL wanting more things wrapped in EVAL-WHEN than everyone else when you're doing metaprogramming)
edgar-rft` has joined #commonlisp
<fengshaun>
fair enough, I'll try it later when the need arises
<aeth>
But the style is not, as beach implies, impossible/infeasible, it just adds complexity that most things don't need. Especially if you want to #-foo for some implementation that handles type DECLAIM/DECLAREs in a very bad way (which is probably yet another reason to always generate them instead of writing them directly, but I'm still not aware of what to put for #-foo here).
<fengshaun>
how would you generate them?
<aeth>
In a macro, anything in a PROGN still counts as a top-level form as long as it is itself part of a top-level form or actually top-level. Otherwise, this would be impossible.
<fengshaun>
oh alright
<fengshaun>
thanks for the tips
<aeth>
so (progn (declaim ...) (defun ...)) is the same as (declaim ...) (defun ...) directly, so you can come up with an automatic way to do it
<aeth>
or at least, a better syntax way to do it
<fengshaun>
interesting
<aeth>
But I personally do an incredible overkill macro, which can generate both DECLAIM/DECLARE (you need the DECLAIM if you specify a return type and otherwise just DECLARE inside of the DEFUN is fine) and CHECK-TYPE depending on the state.
edgar-rft has quit [Ping timeout: 268 seconds]
rkazak has joined #commonlisp
<aeth>
Which is a bit annoying because they happen at different places. But then you can use DECLARE in SBCL for the compile time type checking but use implementation-specific #+ and #- flags to use the almost-equivalent CHECK-TYPE elsewhere if needed
<aeth>
Almost as if I wrote (that part of) the macro based solely to address criticism of my use of this style in #commonlisp
<fengshaun>
lol!!
<beach>
fengshaun: Another newbie mistake I often see is to try to get their low-level Common Lisp code to have performance comparable to (say) the equivalent low-level C++ code.
<beach>
The thing is that this is usually very hard, but what they fail to see is that C++ code doesn't scale into real project (because of the lack of automatic memory management), so to get the big C++ project maintainable, they resort to smart pointers and reference counters, thereby totally ruining the performance advantage of low-level code.
<beach>
So the Common Lisp advantage happens mostly in large projects with many modules.
<fengshaun>
I'm not thinking about performance yet, but that's good to keep in mind
<beach>
But since it is rare to see a large project written both in C++ and Common Lisp for performance comparison, people still believe that C++ has a performance advantage for large projects.
<beach>
fengshaun: Sure. Just saying what was on my mind, because related to type declarations and such.
<aeth>
To get Common Lisp performance to match/beat C++, you probably have to put _everything_ into arrays of e.g. (unsigned-byte 32), (signed-byte 32), single-float, etc., assuming you have a 64-bit implementation (so (unsigned-byte 32) is smaller than a fixnum). And if you use integers, you have to actually put in the work to prevent them not to overflow (into bignums in this case) and hope that the
<aeth>
implementation can optimize that.
<aeth>
This is probably less convenient than actually using C++.
<aeth>
Safer, though, unless you abuse (safety 0) in an implementation that removes safety at (safety 0)
<beach>
aeth: No, the other way to get Common Lisp performance to beat that of C++ is to have a real project with many independent modules.
<beach>
... because then the C++ code is either unmaintainable or slow.
<aeth>
beach: well, I was more thinking about the benchmarks game that always changes its URL if it's even still around
<aeth>
or stuff perhaps a bit less useless than the benchmarks game, but still about array processing of numbers, probably
<beach>
Yes, and that's precisely the mistake I was referring to.
<aeth>
I think you can even invent your own C++-style resource management with UNWIND-PROTECT (and introduce C++-style bugs!)
<beach>
And make your code unmaintainable just like the equivalent C++ code.
pranav has quit [Read error: Connection reset by peer]
<aeth>
Oh no, I just thought of something both evil and implementation-specific (although anyone can implement a similar API)
<aeth>
(sb-simd:u16+ 65535 1) => 0
<aeth>
You can (ab)use the functionality of sb-simd on scalars (not SIMD packs) to get C/C++ style semantics in arithmetic there, apparently.
<aeth>
This would've helped the person that left this channel a year or two ago with the impression that you couldn't do this
<aeth>
For when you want broken integer semantics without actually specifying it with something like (mod (+ 65535 1) (expt 2 16)) that the compiler can just optimize, anyway.
<aeth>
There are very few bad ideas that Common Lisp won't let you do, especially when you permit compiler extensions (and hopefully write a trivial-foo portability library over those piles of hacks)
pve has joined #commonlisp
<aeth>
or e.g. (sb-simd:s32+ 2147483647 1) => -2147483648 ; maybe, because aren't signs overflowing undefined?
lusciouslover has joined #commonlisp
mgl has joined #commonlisp
rkazak has quit [Ping timeout: 265 seconds]
dtman34 has joined #commonlisp
ingeniot has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
chomwitt has joined #commonlisp
printfdebugging has quit [Quit: printfdebugging]
notzmv has joined #commonlisp
rgherdt has joined #commonlisp
ingeniot has quit [Ping timeout: 260 seconds]
rkazak has joined #commonlisp
dtman34 has joined #commonlisp
dra has joined #commonlisp
dra has quit [Changing host]
dra has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
admich1 has quit [Ping timeout: 265 seconds]
lcn_ has joined #commonlisp
rkazak has quit [Ping timeout: 252 seconds]
admich1 has joined #commonlisp
Oddity has quit [Ping timeout: 252 seconds]
notzmv has quit [Ping timeout: 252 seconds]
printfdebugging has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
mgl has quit []
ndanilov has quit [Remote host closed the connection]
ndanilov has joined #commonlisp
ndanilov has quit [Ping timeout: 248 seconds]
attila_lendvai_ has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
rkazak has joined #commonlisp
rkazak has quit [Ping timeout: 276 seconds]
ndanilov has joined #commonlisp
ndanilov has quit [Ping timeout: 260 seconds]
rkazak has joined #commonlisp
mwnaylor has quit [Ping timeout: 245 seconds]
admich1 has quit [Read error: Connection reset by peer]
admich1 has joined #commonlisp
ndanilov has joined #commonlisp
rkazak has quit [Ping timeout: 252 seconds]
mwnaylor has joined #commonlisp
rkazak has joined #commonlisp
rkazak has quit [Ping timeout: 276 seconds]
rkazak has joined #commonlisp
fosskers has quit [Remote host closed the connection]
Guest2579 is now known as steew
<|3b|>
fengshaun: to answer the specific details of your question: it isn't an error, just an optimization note, and the type you specified only says "the first value returned by the function is an octet vector", but it doesn't rule out returning more values of unspecified types. The version it suggests with VALUES and &OPTIONAL specifies it returns exactly 1 value
steew has quit [Changing host]
steew has joined #commonlisp
rkazak has quit [Ping timeout: 252 seconds]
* |3b|
agrees that you should be using check type inside the function instead though, and possibly also not globally setting SPEED to 3 (without which you wouldn't have gotten that message to start with)
dra has quit [Ping timeout: 276 seconds]
<|3b|>
also, (DIGIT-CHAR-P x 16) would be more portable and more accurate than allowing anything with a char code between 48 and 102, and EVERY to check a predicate holds for all of a sequence rather than comparing original sequence to REMOVE-IF-NOT
ndanilov has quit [Ping timeout: 248 seconds]
notzmv has joined #commonlisp
bpanthi977 has joined #commonlisp
bpanthi977 has quit [Ping timeout: 276 seconds]
euandreh has joined #commonlisp
ndanilov has joined #commonlisp
yitzi has joined #commonlisp
heeenkk has joined #commonlisp
Lord_of_Life_ has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 252 seconds]
rkazak has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
varjag has joined #commonlisp
printfdebugging has quit [Quit: printfdebugging]
dtman34 has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
gpiero has quit [Quit: No Ping reply in 180 seconds.]
apac has joined #commonlisp
gpiero has joined #commonlisp
admich1 has quit [Ping timeout: 252 seconds]
admich1 has joined #commonlisp
rkazak has quit [Ping timeout: 265 seconds]
puke has quit [Quit: puke]
admich1 has quit [Read error: Connection reset by peer]
admich1 has joined #commonlisp
random-nick has joined #commonlisp
dtman34 has joined #commonlisp
notzmv has quit [Ping timeout: 245 seconds]
Oddity has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
Everything has joined #commonlisp
rkazak has joined #commonlisp
printfdebugging has joined #commonlisp
rkazak has quit [Ping timeout: 248 seconds]
cercopith has quit [Read error: Connection reset by peer]
decweb has joined #commonlisp
ndanilov has quit [Remote host closed the connection]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
admich1 has quit [Ping timeout: 252 seconds]
shawnw has quit [Ping timeout: 252 seconds]
<beach>
Alfr: But now I wonder whether the standard clearly defines what is meant by the phrase "a function named F" as contained in section 3.2.2.3.
admich1 has joined #commonlisp
rkazak has joined #commonlisp
treflip has quit [Ping timeout: 252 seconds]
ndanilov has joined #commonlisp
flip214 has quit [Ping timeout: 245 seconds]
printfdebugging has quit [Quit: printfdebugging]
heeenkk has quit [Quit: Connection closed for inactivity]
jonatack has joined #commonlisp
flip214 has joined #commonlisp
ndanilov has quit [Ping timeout: 260 seconds]
<beach>
This smells like a WSCL issue. I mean, if a function (named say by the metavariable F) is the result of a call to (fdefinition 'FOO), and we then do (progn (setf (fdefinition 'BAR) (fdefinition 'FOO)) (fmakunbound 'FOO)) what is the name of F now?
<|3b|>
does that clause get FLET wrong? it only says "named f" and ignores whether the scope includes the definition
<beach>
If it is, then we are in deep trouble if we took advantage of 3.2.2.3 because a call such as (FOO ...) inside F is no longer an apparent recursive call, so we would have to invoke the compiler again.
<inline>
you bind the function definition of foo to that of bar and then get rid of foo
<beach>
inline: Yes, I know the semantics of what I wrote. I am wondering what 3.2.2.3 means in this case.
<inline>
hmmm
<|3b|>
but i'd say "named f" means "currently being defined with that name" (or "F was passed as 'name' to COMPILE")
<|3b|>
changing names after definition doesn't matter, and would be included in the undefined behavior
<beach>
|3b|: It can't be "currently being defined", because of what I wrote. It has to be the latter.
<inline>
a named f instead of an anon lambda ?
<beach>
inline: That's exactly the problem.
<|3b|>
beach: you aren't doing that during compilation though, are you?
<|3b|>
(which admittedly is an edge case that is probably poorly specified)
<beach>
Doing what?
<|3b|>
calling (setf fdefinition)
rkazak has quit [Ping timeout: 252 seconds]
<beach>
It doesn't have to be during compilation to pose a problem with a certain definition of "a function named F".
<|3b|>
in the case where you called (COMPILE 'FOO) before fmakunbound, it was named FOO. If you called (COMPILE 'BAR) before fmakunbound, it was named foo (and also bar)
<inline>
won't there be a symbol named F with a function cell if it is named ?
<|3b|>
if you called it after, it was not named FOO
<|3b|>
my point is that the compiler can only care about the name during compilation
<beach>
|3b|: I agree with that, but then "a function named F" does not make much sense.
<beach>
Hence the WSCL issue.
<|3b|>
if the compiler sees it accessible through the name FOO during compilation, it is allowed to make a recursive call
<|3b|>
yeah, it could probably be specified better
* |3b|
might also argue "undefined" is excessive, and could be "unspecified" like the file compilation case
<beach>
Oh, so then (setf (fdefinition 'foo) (compile nil (lambda ....))) can not be what the compiler does. It has to be (setf (fdefinition 'foo) (lambda ...)) and then (compile 'foo).
<beach>
Er, (compile nil '(lambda ...))
<|3b|>
(compile 'foo '(lambda ...)) works too
<beach>
I guess so.
<|3b|>
(possibly with fmakunbound first to avoid macros)
bpanthi977 has joined #commonlisp
<|3b|>
but that's why i said "currently being defined" to allow compilers to recognize constructs that define functions with names
* |3b|
might even argue (setf (fdefinition..) (compile..)) could be considered atomic enough to be validly interpreted as qualifying
rgherdt has quit [Ping timeout: 248 seconds]
<beach>
I see your point now, and it makes me think that (compile 'foo '(lambda ...)) is the only construct that lets the compiler associate a name with a function.
YaShhhh has joined #commonlisp
<inline>
for a single it is sufficiently atomic maybe, but won't you need sequencing when one depends on the other ?
<|3b|>
arguably that could be part of the reason for the vague description
<beach>
But then, file compilation is out of the question, because file compilation does not call COMPILE like that.
bpanthi977 has quit [Ping timeout: 260 seconds]
<beach>
Or, rather, file compilation can not take advantage of 3.2.2.3.
<|3b|>
next clause expands that to all functions in the file though, which i'd assume would include the recursive case
<|3b|>
(though with less severe consequences)
<beach>
True.
<|3b|>
and i think it is reasonable to assume "named F" includes any compiler knowledge that "this function is being defined with the name F", rather than specifically (COMPILE 'F ...)
<beach>
That does take care of the file-compilation case.
<|3b|>
so the compiler knows DEFUN, LABELS, etc have that intent, and can thus apply the recursion clause to them
varjag has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.3)]
YaShhhh has quit [Client Quit]
<beach>
I don't think that's reasonable, at least not until clarified (say by WSCL).
<|3b|>
well, without a clarification, i'd assume the intent is "if the function looks recursive, the compiler can assume it is"
<bike>
well, for labels/flet it's impossible to change what the name refers to, so that one's pretty safe
<beach>
bike: Indeed. The hard part is with globally defined functions.
<beach>
Anyway, I think this is interesting from the point of view of a WSCL issue, but the use of the planned call-site manager in SICL makes it unnecessary to take advantage what 3.2.2.3 allows.
<|3b|>
bike: though for FLET, it is definitely not recursive, despite being "named F" :) :
<bike>
true
<|3b|>
yeah, i'd agree a better specification would be an improvement
<beach>
Good, that's settled then! :) I might work on a WSCL issue for this.
decweb has quit [Quit: Konversation terminated!]
decweb has joined #commonlisp
rgherdt has joined #commonlisp
printfdebugging has joined #commonlisp
dtman34 has joined #commonlisp
printfdebugging has quit [Client Quit]
ndanilov has joined #commonlisp
King_julian has quit [Read error: Connection reset by peer]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
rkazak has joined #commonlisp
King_julian has joined #commonlisp
mange has quit [Remote host closed the connection]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
apac has joined #commonlisp
pkal has joined #commonlisp
admich1 has quit [Read error: Connection reset by peer]
admich1 has joined #commonlisp
treflip has joined #commonlisp
rkazak has quit [Ping timeout: 248 seconds]
printfdebugging has joined #commonlisp
printfdebugging has quit [Client Quit]
cage has joined #commonlisp
treflip` has joined #commonlisp
treflip has quit [Ping timeout: 260 seconds]
printfdebugging has joined #commonlisp
dtman34 has joined #commonlisp
thingit has joined #commonlisp
treflip` has quit [Ping timeout: 248 seconds]
rkazak has joined #commonlisp
ndanilov has quit [Ping timeout: 276 seconds]
phil_bb has quit [Remote host closed the connection]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
ndanilov has joined #commonlisp
ndanilov has quit [Ping timeout: 252 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
rgherdt_ has joined #commonlisp
rgherdt has quit [Ping timeout: 248 seconds]
Ruby2 has joined #commonlisp
bpanthi977 has joined #commonlisp
Ruby has quit [Ping timeout: 260 seconds]
ndanilov has joined #commonlisp
rkazak has quit [Ping timeout: 276 seconds]
printfdebugging has left #commonlisp [#commonlisp]
thingit has quit [Quit: WeeChat 4.6.3]
apac has quit [Ping timeout: 276 seconds]
treflip has joined #commonlisp
gnoo has quit [Ping timeout: 260 seconds]
rkazak has joined #commonlisp
gnoo has joined #commonlisp
rkazak has quit [Ping timeout: 272 seconds]
rkazak has joined #commonlisp
ndanilov has quit [Remote host closed the connection]
ndanilov has joined #commonlisp
apac has joined #commonlisp
gnoo has quit [Ping timeout: 276 seconds]
gnoo has joined #commonlisp
brokkoli_origin has quit [Ping timeout: 252 seconds]
treflip is now known as pilfert
ingeniot has joined #commonlisp
brokkoli_origin has joined #commonlisp
rkazak has quit [Ping timeout: 260 seconds]
dtman34 has joined #commonlisp
rkazak has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
zxcvz has joined #commonlisp
ingeniot has quit [Ping timeout: 252 seconds]
zxcvz has quit [Client Quit]
apac has quit [Ping timeout: 260 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
stirl has joined #commonlisp
dtman34 has joined #commonlisp
pilfert has quit [Ping timeout: 248 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
pkal has quit [Ping timeout: 276 seconds]
chomwitt has quit [Ping timeout: 276 seconds]
stirl has quit [Ping timeout: 276 seconds]
jonatack has quit [Ping timeout: 265 seconds]
Thermoriax has quit [Ping timeout: 268 seconds]
dtman34 has joined #commonlisp
Thermoriax has joined #commonlisp
rkazak has quit [Ping timeout: 244 seconds]
stirl has joined #commonlisp
dajole has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
yitzi has joined #commonlisp
rkazak has joined #commonlisp
ndanilov has quit [Remote host closed the connection]
ndanilov has joined #commonlisp
uhuh has joined #commonlisp
uhuh has quit [Changing host]
uhuh has joined #commonlisp
ndanilov has quit [Ping timeout: 260 seconds]
pkal has joined #commonlisp
uhuh has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.4)]
cdegroot has quit [Remote host closed the connection]
varjag has joined #commonlisp
dtman34 has joined #commonlisp
cdegroot has joined #commonlisp
ndanilov has joined #commonlisp
jonatack has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
jonatack has quit [Ping timeout: 268 seconds]
ndanilov has quit [Ping timeout: 276 seconds]
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]
dtman34 has joined #commonlisp
stirl has quit [Ping timeout: 260 seconds]
cage has quit [Quit: rcirc on GNU Emacs 30.1]
shawnw has joined #commonlisp
rkazak has quit [Ping timeout: 252 seconds]
ndanilov has joined #commonlisp
lusciouslover has joined #commonlisp
dtman34 has quit [Quit: ZNC 1.8.2+deb3.1+deb12u1 - https://znc.in]