jackdaniel changed the topic of #commonlisp to: Common Lisp, the #1=(programmable . #1#) programming language | Wiki: <https://www.cliki.net> | IRC Logs: <https://irclog.tymoon.eu/libera/%23commonlisp> | Cookbook: <https://lispcookbook.github.io/cl-cookbook> | Pastebin: <https://plaster.tymoon.eu/>
avocadoist has quit [Ping timeout: 255 seconds]
waleee has quit [Ping timeout: 256 seconds]
eddof13 has quit [Quit: eddof13]
mgl has quit [Ping timeout: 255 seconds]
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
habamax has quit [Remote host closed the connection]
mzan has quit [Quit: https://quassel-irc.org - Chat comfortably. Anywhere.]
habamax has joined #commonlisp
mzan has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
Oladon has quit [Quit: Leaving.]
Gleefre has quit [Remote host closed the connection]
pfdietz has joined #commonlisp
random-nick has quit [Ping timeout: 246 seconds]
Gleefre has joined #commonlisp
tyson2 has joined #commonlisp
akoana has quit [Remote host closed the connection]
akoana has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
Gleefre has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
pfdietz has quit [Quit: Client closed]
anticrisis has quit [Read error: Connection reset by peer]
edr has quit [Quit: Leaving]
terrorjack has quit [Quit: The Lounge - https://thelounge.chat]
anticrisis has joined #commonlisp
terrorjack has joined #commonlisp
anticrisis has quit [Read error: Connection reset by peer]
kurfen has joined #commonlisp
anticrisis has joined #commonlisp
kurfen_ has quit [Ping timeout: 276 seconds]
Alfr has quit [Remote host closed the connection]
Alfr has joined #commonlisp
makomo has quit [Ping timeout: 252 seconds]
akoana has quit [Quit: leaving]
oneeyedalien has joined #commonlisp
beach has quit [Ping timeout: 255 seconds]
beach has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
oneeyedalien has quit [Quit: Leaving]
decweb has quit [Ping timeout: 240 seconds]
<beach> dnhester26: It seems the links to other pages in the "See also" sections were lost. How do I use Markdown to turn those references into links?
gxt has quit [Remote host closed the connection]
gxt has joined #commonlisp
chomwitt has joined #commonlisp
igemnace has joined #commonlisp
semarie has quit [Quit: WeeChat 4.0.5]
easye has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1)]
pve has joined #commonlisp
easye has joined #commonlisp
Pixel_Outlaw has quit [Quit: Leaving]
notzmv has quit [Ping timeout: 268 seconds]
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
<jcowan> beach: surely there are extensions o the standard library that ought to be standardized, such as the MOP
donleo has joined #commonlisp
rtypo has joined #commonlisp
donleo has quit [Ping timeout: 268 seconds]
traidare has joined #commonlisp
JamesF has quit [Ping timeout: 255 seconds]
JamesF has joined #commonlisp
shka has joined #commonlisp
meritamen has joined #commonlisp
semarie has joined #commonlisp
JamesF has quit [Ping timeout: 260 seconds]
JamesF has joined #commonlisp
anticrisis has quit [Read error: Connection reset by peer]
donleo has joined #commonlisp
easye has quit [Remote host closed the connection]
easye has joined #commonlisp
attila_lendvai has joined #commonlisp
<beach> I don't quite understand this attitude. People use "languages" every day where not one single feature is part of an independent standard. We are lucky that a significant part of the features we need are part of such a standard.
<beach> But suddenly, for some people, it becomes unacceptable to use a feature that is not part of the Common Lisp standard.
<beach> Perhaps all those people always use languages with independent standards, and that it is this particular standard that doesn't seem complete to them.
<beach> But I suspect not. I suspect those are the same people who then happily go ahead and use a language without any standardized feature.
<beach> Sure, there are some things that might be appropriate to have in the standard, but I think "ought to" is too strong, and I would much rather modify the standard in some uncontroversial way like the WSCL project mentions.
thollief has joined #commonlisp
notzmv has joined #commonlisp
<splittist> Perhaps we should be thinking about a world with, not 5, but 50 (++) implementations, aimed at all sorts of deployments, not just workstations/servers, and a wider array of chip types than has been seen in the last decade or so.
<beach> And what action would be required as a result of such thinking?
<splittist> Not changing the standard (:
<beach> Ah, OK.
prxq has quit [Quit: http://quassel-irc.org - Chat comfortably. Anywhere.]
<younder> How about something like HTML. A Whole set of standards. A core standards. And various extension. That way you can pick which are appropriate. A microcontroller lisp can be different from a HPC lisp.
<beach> younder: You are totally at liberty to write such an extension.
Jach has quit [Ping timeout: 268 seconds]
azimut has quit [Ping timeout: 240 seconds]
<younder> Already we are seeing the "standard" including things like alexandia, hunchentoot, cl-ppcre, lparalell.
<beach> I would be more careful about the use of the word "standard" for those.
<beach> And what is your point?
bilegeek has quit [Quit: Leaving]
<younder> It could be bundled as a new standard extension. Most use them anyhow.
<beach> Sure, go ahead and write it down.
mgl has joined #commonlisp
<beach> I am not going to use it though, because I use neither Hunchentoot, cl-ppcre, nor lparallel .
<beach> younder: Of course, if it is to be an extension with the same quality as the standard, you have to write down the definition of every operator, type, etc., available to the client.
<beach> younder: And you have to be careful to specify the semantics as well as the syntax of those things.
<beach> younder: Otherwise, we are back to the "languages" without a standard, i.e., the specification is "whatever the single implementation does".
<younder> Yeah, guess no-one want's to sit down an write standards anymore. They'd rather write code.
<beach> younder: You see, that's what so surprising to me. People accept "whatever the single implementation does" every day in most "languages" used. Suddenly, when we *have* a standard, that's not enough.
<hayley> cl-ppcre? In *my* language standard?
<beach> Heh, right, you already have something better, right?
<younder> The world has moved on since 1994. Clearly language use adapts or the language goes out of use. What's so surprising about that? If not the standard the implementation and the libraries.
<beach> younder: You don't get it, do you?
<hayley> It's not strictly better, but it's really good when it's good.
<younder> No, I fail to see your point.
<beach> younder: Common Lisp has moved on as well. It is just that it has moved on with independent libraries that are not part of the standard, just like most other "languages" out there with no standard at all.
easye has quit [Remote host closed the connection]
<younder> I know that much..
<hayley> If you want to write a new standard, please include a concurrency model, because threads cannot be implemented as a library.
<beach> younder: So what was your point about 1994. I know that's when the standard was written, but why is that important?
easye has joined #commonlisp
<younder> And it's nice to have core written 20 years ago work today. I have go code written 2 years ago, and already github complains that it's a security risk because the compiler used is too old
<beach> younder: So you seem to agree with me. Good!
<hayley> My statement maybe exaggerates matters, as we have a library Bordeaux-threads which is a portable shim over implementation-specific things, but atomic/lock-free stuff is much less specified and has less implementation support. (And my statement includes the name of a very good paper by Hans Boehm on the matter.)
habamax has joined #commonlisp
<beach> Oh, yes, a concurrency model would be great to have. Again, I don't see why it would then have to be part of a new standard.
<beach> Such a thing, and other things like WSCL could just be specifications that a Common Lisp implementation decides to follow, or not.
<hayley> Well, it doesn't need a new Common Lisp standard, but the concurrency model would be more elaborate than Bordeaux-threads.
<beach> Totally!
<beach> What bike wrote is already fairly complete, no?
Jach has joined #commonlisp
<hayley> It's quite good, yes.
<younder> To me the point of a standard is to 'freeze' the implementation in time, saying it needs to behave like this. That way code written it it now works in 20 years because although people extend the standard they are not allowed to change behavior.
<hayley> From memory he specifies that data races are undefined behaviour (like C11) rather than some bare minimum of safe behaviour (like Java) which I think is unfortunate, but that isn't meant to diminish his efforts.
<hayley> (But he wrote that implementations are encouraged to do something safe. Hopefully they do.)
dcb has quit [Quit: MSN Messenger 4.1.2]
dajole has quit [Quit: Connection closed for inactivity]
Jach has quit [Ping timeout: 268 seconds]
<hayley> In the case of standardising random libraries, we also have to consider what behaviour actually matters to the user, to permit some freedom in implementation. A counter-example is that the C++ std::unordered_map is over-specified, and has to be implemented as a very specifically crappy kind of hash table.
<hayley> Tangetically related, I've released my final project for university, which brute forced a theoretical game with lots of parallelism and Common Lisp*: <https://github.com/no-defun-allowed/platypus-games-without-frontiers>
<ixelp> GitHub - no-defun-allowed/platypus-games-without-frontiers: It's a knockout!
<boigahs> ooh
<hayley> (* Common Lisp contents may vary; the GPGPU part is not controlled by Common Lisp. Check with your doctor before trying to make sense of data-parallel algorithms.)
aliosablack has joined #commonlisp
markb1 has quit [Ping timeout: 256 seconds]
makomo has joined #commonlisp
markb1 has joined #commonlisp
Jach has joined #commonlisp
Lord_of_Life has quit [Ping timeout: 255 seconds]
Lord_of_Life_ has joined #commonlisp
Lord_of_Life_ is now known as Lord_of_Life
aliosablack has quit [Quit: Leaving]
traidare has quit [Ping timeout: 268 seconds]
glaucon has joined #commonlisp
bendersteed has joined #commonlisp
danza has joined #commonlisp
edgar-rft has quit [Read error: Connection reset by peer]
edgar-rfx has joined #commonlisp
meritamen has quit [Remote host closed the connection]
edgar-rfx is now known as edgar-rft
traidare has joined #commonlisp
pfdietz has joined #commonlisp
Gleefre has joined #commonlisp
easye has quit [Remote host closed the connection]
easye has joined #commonlisp
heisig has joined #commonlisp
avocadoist has joined #commonlisp
green__ has quit [Ping timeout: 260 seconds]
<younder> hayley: I'll consult Dr. Iverson. (Professor of Mathematics at Harward befor he joined IBM and created APL)
avocadoist has quit [Remote host closed the connection]
Guest33 has joined #commonlisp
danza has quit [Ping timeout: 252 seconds]
glaucon has quit [Quit: WeeChat 3.5]
<younder> Seriously, setting the problem up correctly is half the solution, just like in physics.
yitzi has joined #commonlisp
<edgar-rft> everything is easy, but only if you know how it works
random-nick has joined #commonlisp
tyson2 has joined #commonlisp
<jcowan> beach: Scheme is a standardized language, but it does release new versions of the standard from time to time. The fact that Common Lisp doesn't is not, in my view, a virtue. And yes, we have 50++ implementations with varying degrees of conformance and quality.
<jcowan> hayley: I wouldn't have a standard specify cl-ppre or any other package. But there's nothing wrong with standardizing an interface to regular expression engines.
<moon-child> I don't think the scheme standardisation process should be pointed to as a shining example of anything
habamax has quit [Quit: ERC 5.5.0.29.1 (IRC client for GNU Emacs 29.1.90)]
<yitzi> I suspect there is a middle ground. A second version of the CL standard could at least make "deprecated" in respect to find-if-not, etc. mean something.
<gilberth> jcowan: See that's the trouble. I want POSIX regular expressions. Joe wants his variant of Perl regular expressions. Jane wants something else. Why standardize that? And who is to say which?
<gilberth> There is absolutely no need to standardize RE. CL has everything needed to implement that as a library.
<gilberth> Unlike other things, which cannot be implemented as a library and/or are missing puzzle pieces. Lexical environments come to my mind. That and the missing &optional environment argument to EVAL and COMPILE. READ-BYTE-NO-HANG would be something that I'd really like to see, another missing puzzle pieces, that you cannot implement in conforming ANSI-CL.
<jcowan> That argument proves too much. Why did Steele and company standardize the list functions? Why not stick to CAR, CDR, CONS, RPLACA, and RPLACD (or their SETF equivalents)? Everything else can be implemented as a library.
<beach> gilberth: What aspect of Trucler (lexical environments as a library) makes it unacceptable?
<jcowan> Add a similar number of vector functions, and poof, the vector-specific and sequence functions? No need to standardize them.
<hayley> There aren't very many ways to write MEMBER.
<jcowan> By that uncompromising rule, probably 75% of CL disappears.
<gilberth> beach: Whatever that is. Access to lexical environments is missing with ANSI-CL.
<hayley> Not so for SORT though; there's probably a few books on different ways to write SORT.
<beach> gilberth: Sure, but we have it in a library.
Guest33 has quit [Ping timeout: 250 seconds]
<beach> gilberth: Oh, but you mean it has to be in there from the start?
<jcowan> My reply: We standardize things to create a shared context of understanding between humans. I want to be able to look at your code, see LENGTH, and not have to wonder what it does.
<gilberth> beach: I'm not talking about libraries, but about a something like a standard.
cage has joined #commonlisp
<beach> gilberth: I am trying to figure out what you meant by "Unlike other things, which cannot be implemented as a library and/or are missing puzzle pieces. Lexical environments come to my mind."
<gilberth> beach: Just given ANSI-CL, you cannot implement lexical environment access as mapped out in CLtL2.
<jcowan> Portably, that is.
<gilberth> Likewise just given ANSI-CL, you cannot compile or eval in a given lexical environment.
<gilberth> Thus you cannot implement code walking just given ANSI-CL. (_unless_ you process top level forms only).
<gilberth> Further you cannot implement read-byte-no-hang just given ANSI-CL. Nor a read-sequence that returns short reads. Missing puzzle pieces for any network client or server that doesn't want to read a byte at a time.
<beach> We must mean different things by "implement lexical environment access", and I am not understanding the difference. Not that it matters.
<gilberth> For external formats we might want to have some agreement on OCTETS-TO-STRING and STRING-TO-OCTETS. Although you can do that portably, you can't do it in a way that is compatible with the Lisp implementation at hand.
<jcowan> Can you explain hat last?
green__ has joined #commonlisp
<bike> beach: i think gilberth is just saying that trucler relies on unstandardized language extensions. it couldn't exist without those extensions. so having an actual standard extension would be good.
<ixelp> 8.5. Environments
<beach> bike: But that's not how I understood "can't be implemented as a library".
<bike> it's like how you couldn't meaningfully implement bordeaux threads as a library if you didn't have some implementation make-thread available.
<beach> .. which is why I was asking what was meant. But it is not important. I'll drop it.
<gilberth> beach: Then you can implement everything as a library for one particular given CL implement. You're point?
<beach> It doesn't matter.
danza has joined #commonlisp
<bike> oh, we were talking about read-byte-no-hang the other day. did you know clim has streams of gestures or something? it might make sense to have general read-element and read-element-no-hang and allow weird stream element types
<gilberth> What are tried to say is that there are things (like those mentioned RE) that you can implement in conforming ANSI-CL. And other things you just cannot. I see no value on investing time on pondering the former. I'm after missing puzzle pieces.
<gilberth> bike: That is orthogonal, when you want to have streams that read and write something beyond bytes or chars.
<bike> orthogonal to read-byte-no-hang? sure, it's just an interesting idea i think
<jcowan> I meant specifically: "What do you mean by saying that o-t-s and s-t-o can't be implemented 'in a way that's compatible with the Lisp implementation at hand?'"
<jcowan> s/?'"/'?"
<gilberth> I'm not done yet and still have to give the issue some thought. The least I want is read-sequence that can report short reads. A timeout argument would be nice as well. The best case would be direct buffer access or unread-sequence.
<gilberth> jcowan: I give you an external format object and an octet vector, please give be characters. Can you do that in ANSI-CL? You may not touch the filesystem.
<bike> is unread-sequence even something you can do with posix?
<jcowan> Sure. But how do implementations in fact differ on this point?
<gilberth> A modified LISTEN could work as well. LISTEN is broken as it returns NIL on EOF.
<gilberth> bike: We do buffered I/O anyway.
<gilberth> My problem is: I want to read something, fast, but don't know how much.
<jcowan> bike: Not on raw file descriptors, no. But file descriptors are wrapped by streams, which could include a buffer of characters that have been pushed back.
<bike> yeah, i mean read-sequence analogous to read(2) certainly makes sense
<gilberth> There are two use cases: (1) some network protocol. I want read-sequence to not block until the full is full, but only once. Like UNIX read(2). The other is modularity. See, CLEX can process characters at 7\tau per char on average. You want to use it to parse something from a stream, but when that input is done, you want to parse something else using somebody else's library.
<gilberth> atm, all you can do is read a byte or character at a time.
semz has quit [Quit: ZNC 1.8.2+deb2build5 - https://znc.in]
<gilberth> And for network servers, or clients, you cannot poll a socket for data available and/or EOF. LISTEN is broken and returns NIL on EOF.
<bike> what should listen return on eof?
<gilberth> IMHO, it should return T. But we cannot fix that.
<gilberth> Like LISTEN being T => READ-CHAR or READ-BYTE won't hang.
danza has quit [Quit: Leaving]
<bike> i see...
danza has joined #commonlisp
<gilberth> There read-char-no-hang, but no read-byte-no-hang. However even READ-CHAR-NO-HANG cannot be implemented to have my LISTEN. Let's call it READ-WONT-BLOCK-P.
<jcowan> This is a reason (not a sufficient reason it itself) for issuing revised standards: to correct semantic errors in the existing standard.
Lycurgus has quit [Quit: leaving]
<jcowan> And yes, LISTEN should return T on EOF, because something is available: the next read operation will not hang.
semz has joined #commonlisp
Lycurgus has joined #commonlisp
<gilberth> jcowan: Yes, but we can't fix LISTEN. We need some new name.
<jcowan> It's not that you can't, it's that you probably don't want to, because it is what the C standardizers calll a silent breaking change.
danza has quit [Client Quit]
danza has joined #commonlisp
<jcowan> so yes, deprecate LISTEN and add something else, like CHAR-READY-P (pick your own name)
<gilberth> LISTEN is CHAR-READY-P.
pranavats has left #commonlisp [Error from remote client]
<gilberth> It returns T when a character is available.
pranavats has joined #commonlisp
<hayley> (listen <input stream> :like-thieves t)
<gilberth> Actually I want that read-sequence with a timeout.
<fe[nl]ix> sync I/O is pretty much a solved question, it looks like you want basically what Franz did, coming up with a better I/O layer (simple streams) then implementing standard CL on top of it
<jcowan> gilberth: Fair enough. Pick your own name, just so it correctly returns T on EOF.
<jcowan> hayley: why "thieves"?
<gilberth> fe[nl]ix: Not really. I'm fine with Gray Streams.
<hayley> jcowan: No good reason. (Because that's the name of a song and an album by INXS)
<gilberth> And with telling character streams and byte streams apart.
<gilberth> I should write some article about that topic.
<jcowan> It's problematic to have a version of LISTEN and READ-CHAR-NO-HANG in a multiple charset world.
<yitzi> How so?
<jcowan> You definitely need to be able to buffer more than one octet in the stream.
<yitzi> UNREAD-CHAR already implies that.
<gilberth> I don't see a problem with multi-byte characters.
<gilberth> When there is only half a character, report that there is no input. Done.
decweb has joined #commonlisp
<gilberth> Anyhow, one might argue that you can always implement your own stream class to have all that. However, that won't be modular. I, as a library writer, may not have control over the stream passed to me.
green__ has quit [Ping timeout: 252 seconds]
jmdaemon has quit [Ping timeout: 276 seconds]
dra has joined #commonlisp
dra has quit [Changing host]
dra has joined #commonlisp
green__ has joined #commonlisp
igemnace has quit [Read error: Connection reset by peer]
waleee has joined #commonlisp
edr has joined #commonlisp
igemnace has joined #commonlisp
traidare has quit [Ping timeout: 268 seconds]
pfdietz has quit [Quit: Client closed]
fe[nl]ix has quit [Quit: Valete!]
heisig has quit [Quit: Leaving]
fe[nl]ix has joined #commonlisp
attila_lendvai has quit [Ping timeout: 260 seconds]
tyson2 has quit [Remote host closed the connection]
azimut has joined #commonlisp
waleee has quit [Ping timeout: 255 seconds]
xlymian has joined #commonlisp
yitzi has quit [Remote host closed the connection]
varjag has joined #commonlisp
tyson2 has joined #commonlisp
traidare has joined #commonlisp
tyson2 has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
eddof13 has joined #commonlisp
overclucker has quit [Read error: Connection reset by peer]
overclucker has joined #commonlisp
eddof13 has quit [Quit: eddof13]
Pixel_Outlaw has joined #commonlisp
eddof13 has joined #commonlisp
shka has quit [Ping timeout: 260 seconds]
masinter has quit [Remote host closed the connection]
masinter has joined #commonlisp
<paulapatience> Is it permitted to manually increment i in (loop for i below 10 do (princ i) (incf i))? SBCL does what I would expect, but I didn't find any mention of mutating loop iteration variables in the specification.
<beach> Let's see if I can find the relevant text...
<beach> Hmm, no I can't find anything.
<aeth> that could actually break in theory if someone implemented FOR (but not WITH) variables differently than the most straightforward way.
<beach> Yes, but that might not be allowed.
<beach> I don't see any phrase either way.
<aeth> imo, if it's not forbidden, then you'd have to assume that a future implementation of LOOP might break it even if it works on all current implementations, although maybe they wouldn't be able to do that if it breaks too much existing code. Though maybe there is something in the fine print somewhere.
<masinter> restart X3J13 and clean it up
<masinter> these days, compilers can detect when they can do variable elimination
<paulapatience> I guess I'll avoid that pattern just in case.
<beach> I would avoid it.
azimut has quit [Ping timeout: 240 seconds]
<masinter> on the grounds of ease of reading
<gilberth> Well. https://novaspec.org/cl/6_1_The_LOOP_Facility#sec_6_1_1_4 says that there is one binding for the iteration variables. So much for that. <https://novaspec.org/cl/6_1_The_LOOP_Facility#sec_6_1_2_1> says (sixth paragraph) "At each iteration, variables can be stepped1 by an increment or a decrement or [...]"
<ixelp> 6.1 The LOOP Facility | Common Lisp Nova Spec
<gilberth> That "increment" or "decrement" could imply some (INCF I ...) or (DECF I ...) happening.
<gilberth> In contrast to (SETQ I new-i).
<aeth> I think the question is if you're allowed to have an explicit increment apart from the implicit increment... though "one binding" would prevent e.g. tail recursion (though non-trivial LOOPs may find it hard/impossible to do that, anyway)
<aeth> but I guess there may be weird optimizations going on like maybe e.g. loop unrolling... though maybe it can just check for potential mutation in the loop body and not do that if it's there
<gilberth> However the glossary entry for "step" says that the iteration variable is assigned a new value. Well, INCF and DECF assign as well, but that won't outrule having a hidden I, say #:I42, increment that and do a (SETQ I #:I42) to do the stepping.
danza has quit [Ping timeout: 240 seconds]
<gilberth> aeth: Irrelevant.
<gilberth> It's a different story with DOTIMES, where it says that it's UB to modify the iteration variable. IIRC you even could get a new binding each turn.
<gilberth> Anyhow, I personally won't ever touch an iteration variable of a FOR .. BELOW clause. That's confusing anyways.
<younder> Fair enough. Changing a iteration variable is begging for undefined behavior.
danza has joined #commonlisp
eddof13 has quit [Quit: eddof13]
<gilberth> younder: Not only that, I find it surprising as a reader.
<gilberth> I mean, you read "FOR I BELOW 10". I read it as "Let I be any value from 0 below 10, one after another." Then someone sets I to some other value and this isn't true anymore.
tyson2 has quit [Remote host closed the connection]
eddof13 has joined #commonlisp
waleee has joined #commonlisp
<aeth> I'd assume the big one, though, is when you hit the terminating condition
<aeth> depending on how you do it, two implementations might loop off-by-one amount of times
<aeth> I think?
<aeth> and it makes it look at a glance like the code will straightforwardly terminate when it might infinitely loop, assuming a non-trivial dozens-of-lines LOOP where the SETFing might not be obvious while the "for i from 0 below 10" near the top is obvious
<aeth> assuming you conditionally DECF instead of INCF
chomwitt has quit [Ping timeout: 245 seconds]
Alfr has quit [Quit: Leaving]
Gleefre has quit [Remote host closed the connection]
yitzi has joined #commonlisp
NotThatRPG has joined #commonlisp
JamesF has quit [Ping timeout: 255 seconds]
varjag has quit [Ping timeout: 260 seconds]
varjag has joined #commonlisp
varjag has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
bjorkintosh has quit [Quit: Leaving]
zxcvz has joined #commonlisp
danza has quit [Ping timeout: 268 seconds]
chiselfuse has quit [Remote host closed the connection]
pfdietz has joined #commonlisp
chiselfuse has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has joined #commonlisp
bjorkintosh has quit [Changing host]
akoana has joined #commonlisp
chomwitt has joined #commonlisp
Gleefre has joined #commonlisp
NotThatRPG has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
tyson2 has quit [Read error: Connection reset by peer]
pfdietz has quit [Quit: Client closed]
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
pfdietz has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
rogersm has joined #commonlisp
Gleefre has joined #commonlisp
szkl has quit [Quit: Connection closed for inactivity]
dcb has joined #commonlisp
ec has quit [Remote host closed the connection]
ec has joined #commonlisp
Gleefre has quit [Remote host closed the connection]
cage has quit [Quit: rcirc on GNU Emacs 29.1]
thollief has quit [Quit: Leaving]
yitzi has quit [Remote host closed the connection]
shka has joined #commonlisp
enzutwo is now known as enzuru
enzuru has quit [Changing host]
enzuru has joined #commonlisp
eddof13 has quit [Quit: eddof13]
pve has quit [Quit: leaving]
eddof13 has joined #commonlisp
rgherdt has joined #commonlisp
cimento has joined #commonlisp
OlCe has joined #commonlisp
attila_lendvai has joined #commonlisp
xlymian has quit [Ping timeout: 255 seconds]
igemnace has quit [Read error: Connection reset by peer]
igemnace has joined #commonlisp
traidare has quit [Ping timeout: 264 seconds]
zetef has joined #commonlisp
glaucon has joined #commonlisp
chomwitt has quit [Remote host closed the connection]
zetef has quit [Remote host closed the connection]
grawlinson has quit [Ping timeout: 256 seconds]
zxcvz has quit [Quit: zxcvz]
zxcvz has joined #commonlisp
grawlinson has joined #commonlisp
zxcvz has quit [Client Quit]
rtypo has quit [Ping timeout: 268 seconds]
Jach has quit [Ping timeout: 252 seconds]
attila_lendvai has quit [Ping timeout: 256 seconds]
Jach has joined #commonlisp
makomo has quit [Quit: zZzzZZZZzzZZZZzZZZZzzZZZZzz]
glaucon has quit [Read error: Connection reset by peer]
bilegeek has joined #commonlisp
notzmv has quit [Ping timeout: 260 seconds]
Jach has quit [Ping timeout: 255 seconds]
Jach has joined #commonlisp
rgherdt has quit [Ping timeout: 246 seconds]
mgl has quit [Ping timeout: 264 seconds]
rgherdt has joined #commonlisp
Devon has quit [Ping timeout: 276 seconds]
azimut has joined #commonlisp
bendersteed has quit [Quit: bendersteed]
dustinm` has quit [Quit: Leaving]
dustinm` has joined #commonlisp
jmdaemon has joined #commonlisp
pfdietz has quit [Quit: Client closed]
JamesF has joined #commonlisp
random-nick has quit [Ping timeout: 260 seconds]