Kaisyu72 has quit [Quit: ERC (IRC client for Emacs 26.3)]
bitmapper has quit [Ping timeout: 265 seconds]
FreeBirdLjj has joined #lisp
ralt has quit [Quit: Connection closed for inactivity]
pjb has joined #lisp
karlosz has joined #lisp
libertyprime has joined #lisp
v3ga has quit [Quit: WeeChat 2.7.1]
v3ga has joined #lisp
lawr3nce has quit [Remote host closed the connection]
ahungry has joined #lisp
wxie has quit [Ping timeout: 264 seconds]
wxie has joined #lisp
Kaisyu7 has joined #lisp
pjb has quit [Ping timeout: 272 seconds]
efm has quit [Ping timeout: 264 seconds]
Jeanne-Kamikaze has joined #lisp
efm has joined #lisp
SGASAU` has quit [Quit: ERC (IRC client for Emacs 26.3)]
GuerrillaMonkey has quit [Ping timeout: 260 seconds]
SGASAU has joined #lisp
Bourne has quit [Ping timeout: 256 seconds]
wxie has quit [Ping timeout: 258 seconds]
akoana has quit [Quit: leaving]
elflng has joined #lisp
wxie has joined #lisp
EvW has quit [Ping timeout: 272 seconds]
kinope has joined #lisp
wxie has quit [Ping timeout: 264 seconds]
wxie has joined #lisp
gaqwas has quit [Ping timeout: 246 seconds]
gaqwas has joined #lisp
seoushi_ has joined #lisp
iAmDecim has joined #lisp
iAmDecim has quit [Ping timeout: 246 seconds]
thmprover has quit [Quit: ...and miles to go before I sleep.]
Bike has quit [Quit: leaving]
<beach>
Good morning everyone!
jeosol has joined #lisp
seoushi_ has quit [Ping timeout: 264 seconds]
jesse1010 has quit [Remote host closed the connection]
jesse1010 has joined #lisp
<userself>
good evening beach
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
jesse1010 has quit [Ping timeout: 256 seconds]
mathrick has joined #lisp
wxie has quit [Ping timeout: 260 seconds]
freshpassport has joined #lisp
pjb has joined #lisp
thmprover has joined #lisp
<fe[nl]ix>
good morning beach !
slyrus__ has joined #lisp
<fe[nl]ix>
Xach: did the bordeaux-threads release break something ?
slyrus_ has quit [Ping timeout: 256 seconds]
pjb has quit [Ping timeout: 272 seconds]
shka_ has joined #lisp
pjb has joined #lisp
thmprover has quit [Remote host closed the connection]
mrcom has quit [Ping timeout: 265 seconds]
yonkunas has quit [Quit: Connection closed for inactivity]
Blukunfando has quit [Ping timeout: 260 seconds]
kinope has quit [Quit: Connection closed for inactivity]
mrcom has joined #lisp
shifty has quit [Ping timeout: 240 seconds]
v3ga has quit [Read error: Connection reset by peer]
gravicappa has joined #lisp
gxt has joined #lisp
seoushi_ has joined #lisp
v3ga has joined #lisp
Jeanne-Kamikaze has quit [Ping timeout: 260 seconds]
hapticFeels has joined #lisp
remexre has quit [Quit: WeeChat 2.7.1]
hdasch_ has quit [Quit: ZNC 1.6.6+deb1ubuntu0.2 - http://znc.in]
hdasch has joined #lisp
sdumi has quit [Ping timeout: 246 seconds]
sdumi has joined #lisp
terpri has joined #lisp
wxie has joined #lisp
pjb has quit [Ping timeout: 272 seconds]
narimiran has joined #lisp
sdumi has quit [Read error: Connection reset by peer]
sdumi has joined #lisp
h4milton_ has joined #lisp
<h4milton_>
what do people use Python for ?
taof has quit [Read error: Connection reset by peer]
wxie1 has joined #lisp
wxie has quit [Ping timeout: 246 seconds]
wxie1 is now known as wxie
<h4milton_>
I seem to be interested in Bloom Filters than Lamda Calculus, but none of the Python people seem to think that is Pythony enough ...
<phoe>
that is an unusual question to ask on a Lisp channel
<h4milton_>
apparently if you are interested in Lambda Calculus you should use LISP
terpri has quit [Remote host closed the connection]
<phoe>
wat
<phoe>
both python and lisp are general purpose languages though, you can express both bloom filters and lambda calculus in them
<h4milton_>
I started studying Lisp and got interested in Bloom Filters ,,, but the subject seems too esoteric for the freenode crowd .. is the a LISP or Clojure implementation for Bloom Filters ?
<h4milton_>
I meant Python ...
<h4milton_>
I started with Python ... but I am told my interests are too niche
pikajew has quit [Ping timeout: 264 seconds]
<h4milton_>
after spending two days figuring out where to start
terpri has joined #lisp
<h4milton_>
I think I need to start with Bloom filters and SipHash
ahungry has quit [Remote host closed the connection]
JohnMS_WORK has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
<h4milton_>
i seem to have Bloom Filter implementations up for both languges ... now i need to learn enough Lisp to see the Hash functions
rgherdt has joined #lisp
shangul has joined #lisp
jw4 has quit [Read error: Connection reset by peer]
jw4 has joined #lisp
sunset_NOVA has joined #lisp
terpri has quit [Remote host closed the connection]
ebrasca has joined #lisp
terpri has joined #lisp
<beach>
If you don't know much Common Lisp, and you would like to learn, I recommend #clschool.
estest has quit [Ping timeout: 246 seconds]
wxie1 has joined #lisp
wxie has quit [Ping timeout: 260 seconds]
wxie1 is now known as wxie
Cymew has joined #lisp
zaquest has quit [Quit: Leaving]
zaquest has joined #lisp
v3ga has quit [Ping timeout: 272 seconds]
DGASAU has joined #lisp
<no-defun-allowed>
Are there any libraries for supervising and restarting threads that "crash" for whatever reason?
iAmDecim has joined #lisp
DGASAU has quit [Remote host closed the connection]
shifty has joined #lisp
iAmDecim is now known as v3ga
<phoe>
no-defun-allowed: erlangen for CCL
DGASAU has joined #lisp
pjb has joined #lisp
<no-defun-allowed>
Right, thanks.
<no-defun-allowed>
Is it only for Clozure CL?
<phoe>
yes
<no-defun-allowed>
Bummer.
<shka_>
lparallel allows for forwarding conditions to the original thread
<shka_>
this is but one step from actually restarting threads
<no-defun-allowed>
I might hack something up next time I feel like hacking something random.
rogersm has joined #lisp
<shka_>
no-defun-allowed: make it portable
<phoe>
^
<shka_>
it shouldn't be complicated to do
seoushi_ has quit [Ping timeout: 260 seconds]
<no-defun-allowed>
shka_: Well, yeah, that's why I want to do that.
<shka_>
you can look at lparallel error forwarding, this is like 85% of challenge
<no-defun-allowed>
I can imagine an error forwarding system, where each thread calls its working function, with a handler that sends errors to a mailbox that the supervisor thread continually receives messages from.
<shka_>
yup
<shka_>
that's a good way to do it
rogersm has quit [Ping timeout: 258 seconds]
<shka_>
that's also what i am doing for error forwarding
<shka_>
from there, it is a matter of actually restarting thread which looks like a simpler part
<shka_>
though user should be careful about closures
<no-defun-allowed>
Then when the supervisor gets a message, it updates some information about the working function that signalled, and decides what to do.
<shka_>
either decides, or asks user
<phoe>
it's a matter of passing a message to that thread where the message is (lambda () (invoke-restart restart))
<phoe>
the restart object should be valid since it's still in the dynamic extent of the paused thread
<phoe>
so closing over that restart in another thread, in theory, should work
<no-defun-allowed>
Good idea! That's probably a more idiomatic recovery for Common Lisp.
<phoe>
in theory though - I have no idea if there are any complications of doing that
<phoe>
obviously never try to invoke restarts from other threads, but creating closures that close over them should be good
<phoe>
as long as these closures are then executed in the matching threads
dddddd has quit [Ping timeout: 260 seconds]
<shka_>
one potential problem with this system is handling the state changes in the working thread
narimiran has quit [Read error: Connection reset by peer]
<shka_>
although what phoe wrote is slick in concept, it will probably not always work
narimiran_ has joined #lisp
<phoe>
shka_: which case are you thinking of?
<shka_>
when there is a foreign code at play
<phoe>
like, somewhere on the stack?
<no-defun-allowed>
If it could be an issue, could you just send restart names between threads? That indirection could be slightly slower, but slightly more portable.
<phoe>
no-defun-allowed: as long as you have no name collisions.
<shka_>
phoe: like your stupid C library just errored and now you have to clean the allocated memory because of course
<phoe>
then that'll work, you are just passing symbols around
<phoe>
shka_: why is that a problem
<phoe>
UNWIND-PROTECT should take care of that
<shka_>
oooh, i see what you mean
<shka_>
yeah, makes sense
<phoe>
if you don't use UNWIND-PROTECT to deallocate DX foreign memory, you've already sort of lost
<phoe>
and if the memory is not DX and should be instead passed around and then destroyed, then there's nothing to clean up at this level
<phoe>
that's the role of UNWIND-PROTECT in the thread where the C code segfaulted or something
<no-defun-allowed>
(Although I don't know if I can properly implement the "screw it, kill everyone and everything, and start over" strategy without making every involved thread unwind the stack correctly.)
<shka_>
agreed
<phoe>
no-defun-allowed: you need to unwind all the stacks properly to do that
<phoe>
otherwise the UNWIND-PROTECT forms may not get executed and cleanup forms will be lost
<phoe>
you can achieve it via a toplevel WITH-SIMPLE-RESTART
<shka_>
phoe: there is one complication i can think of
<no-defun-allowed>
Alright.
<phoe>
like (bt:make-thread (lambda () (with-simple-restart (nuke "Unwind and kill the thread.") ...)))
<phoe>
and then just invoke the NUKE restart in all threads you want to nuke
<phoe>
shka_: what is it?
<shka_>
what about changes made to the lexical env (or perhaps even dynamic variables with altered values)
<shka_>
this won't change after restart
<no-defun-allowed>
Can I be sure I'll interrupt a thread, say with BT:INTERRUPT-THREAD, in its current dynamic context?
<shka_>
obvious solution is not to write this style of code
<phoe>
like, eventually, it will get interrupted, unless it loops in without-interrupt
<phoe>
shka_: what do you mean, lexical env?
<no-defun-allowed>
Close enough?
<phoe>
no-defun-allowed: I guess, so, you can't really get any better than that
<shka_>
phoe: (let ((i 0)) (lambda () (incf i)))
<phoe>
yes, that's a closure
<shka_>
ok, now consider something like this
<phoe>
if you want to access I, you need to grab a lambda that accesses it and then pass it to another thread I guess
<no-defun-allowed>
I meant, if I had a thread with that kind of top-level restart, would (interrupt-thread <thread> (lambda () (invoke-restart 'git-out))) be sure to have access to the thread's restarts?
<phoe>
no-defun-allowed: it would
<phoe>
the function is invoked in the dynamic context of the offending thread, so it will access the offending thread's restarts
<no-defun-allowed>
Great! That should work then. Thanks.
<phoe>
also why do you defparameter at non-top-level
<shka_>
phoe: because i can :)
<phoe>
right
<shka_>
now this is properly wrong
jprajzne1 has joined #lisp
<phoe>
yes, *NEW-VARIABLE* is an unbound lexical variable
<phoe>
you'd need LOCALLY DECLARE SPECIAL for that to work
<phoe>
..."LOCALLY DECLARE SPECIAL" sounds strangely like cobol and this gave a chill to my heart
<shka_>
whatever, point is that if you just restart by recalling the function
<shka_>
and let's say that do-more-stuff has a proper declaration
fluxwave has quit [Quit: leaving]
<shka_>
because of course
<shka_>
the *new-variable* won't be reinitialized to 0
<phoe>
that's a non-issue
<shka_>
it is a corner case
<phoe>
you used DEFVAR, not DEFPARAMETER, so obviously you don't want it reinitialized
<phoe>
so, works as intended
<shka_>
you are a little bit to certain :-)
<phoe>
DEFVAR is Lispian for "don't overwrite the old value"
<phoe>
whereas DEFPARAMETER can be translated as "haha setf go brrrr"
<phoe>
so, yes, I am certain :D
<no-defun-allowed>
brrrr
<shka_>
if this would be a general purpose library it is bound to be used in a variety of ways, for instance to load-file
<shka_>
i don't know if this can be accounted for
<phoe>
if this was a general purpose library then I wouldn't let a non-toplevel DEFVAR/DEFPARAMETER pass code review
<phoe>
you can /= you should
<shka_>
phoe: sadly, it is not up to you to decide if something passes the review or not
<phoe>
:(
<shka_>
unless you want to review every single line o lisp code ever written
<phoe>
that's a useless generalization though; we're talking about concrete code cases here
<easye>
shka_: phoe is trying to advise you on best practices for contemporary ANSI. You may do whatever you want, of course.
<shka_>
regardless, i think that this is something that should be put into readme, it can't be handled
<phoe>
if someone comes at me with such a code example then I can tell them "toplevel defvar is a no-no"
<shka_>
phoe: we are talking about library for restarting threads, right?
<phoe>
shka_: yes
pjb has quit [Ping timeout: 272 seconds]
<phoe>
and if someone uses smelly code like nontoplevel global variable definition in *their* code, not inside that library, then that's not really the problem of that library
<shka_>
phoe: or uses library that contains smelly code
<shka_>
which happens
<phoe>
shka_: yes, that's a different problem though; and that's kinda solved by filing merge requests or bug tickets on one's dependencies
<phoe>
or changing the dependencies, whatever
<phoe>
but that's already a way different issue than a nontoplevel DEFVAR
<phoe>
so, I'll stop here
<shka_>
well, you can also (lambda () (load "~/completly-legit-code.lisp")) if it makes you feel any better ;-)
<phoe>
let's assume that the code no-defun-allowed writes does not contain code smells like these, and I guess the dependencies for such a lib are small enough to be audited as a whole
* phoe
shrug
<phoe>
you can't solve the programmer being stupid
holycow has joined #lisp
<phoe>
so I guess doing so is out of scope of a thread supervision library
<shka_>
eh, whatever
<phoe>
exactly my point
<shka_>
i think that you need a little bit of reality check but that's not my problem :P
<phoe>
#p"~/completely-legit-code.lisp" can contain (sb-sys:without-interrupts (loop))
<shka_>
phoe: or it may contain some sort of example code
<no-defun-allowed>
I was just thinking I wanted a more robust system for handling errors in my Netfarm server. Threads probably shouldn't signal any errors that aren't handled somewhere, but that's probably someone's famous last words.
<phoe>
"hey, that's a bug in the supervision library, it executed my code without checking if it's bug-free!"
ralt has joined #lisp
<shka_>
is it really fair to say that your code has bugs if it was in file that was never meant to be loaded more than once?
<phoe>
depends on the code standards we have
<shka_>
no-defun-allowed: one more thing
<shka_>
i suspect that this solution can be harmful in one more way
<phoe>
I know that pgloader in its current form cannot reload itself
<shka_>
namely if you have thread that simply errored with something unhandled
pve has joined #lisp
<shka_>
you actually DON'T want to restart it
marusich has joined #lisp
<shka_>
you want to debug it
terpri has quit [Remote host closed the connection]
libertyprime has quit [Ping timeout: 260 seconds]
<no-defun-allowed>
True.
<shka_>
anyway, i think that there are two options
<shka_>
a) handle every error precisely how it should be handled
<phoe>
like, (progn (asdf:load-system :pgloader :force t) (asdf:load-system :pgloader :force t)) will signal an error
<shka_>
b) separate processes, erlang style
<phoe>
but that's a bug in pgloader since I assume that ASDF-loadable code should be reloadable
<phoe>
with a stress on "I assume"
<shka_>
this is because although you can restart thread, some resources (like for instance memory) are global
<no-defun-allowed>
Restarting the problematic thing is always the last option, and I assume that at this point, any errors that are signalled are beyond what I can fix.
<shka_>
and i managed to crash sbcl way to many times :/
terpri has joined #lisp
liberliver has joined #lisp
<no-defun-allowed>
Then we may want to reset whatever state is used if we reset all the threads.
<shka_>
or just restart whole lisp process
<shka_>
which is not elegant but works
<shka_>
and effectively resets everything :D
<no-defun-allowed>
Provided all the state is managed somehow, it would be somewhat faster to reset the state without restarting the Lisp process.
<shka_>
yes, it would
<shka_>
however, it woudn't be always possible
<phoe>
if you manage to interrupt each thread and get it to fully unwind, then your state is manageable
<shka_>
and this is not the normal situation
<phoe>
however if you call bt:destroy-thread even once or get some thread into uninterruptible sleep/loop and therefore need to destroy it, you have a possible leak
<phoe>
so that's a question of how well behaved your threads are
<shka_>
phoe: you can also have buggy implementation of CL
<shka_>
and you do have a buggy implementation of CL
<no-defun-allowed>
(Also, I need to add logging to decentralise2, but don't really want to fix it to one logging library. More grownup gal stuff to do.)
<shka_>
no-defun-allowed: the way i see it is that you want to have 100% certainty of nearly 100% uptime
libertyprime has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
<ralt>
talking about 100% uptime without talking about distributed systems is kinda... missing a big part of the picture
<shka_>
to do so, handle every error, and then use erlang style over watching of the lisp process itself
<ralt>
erlang doesn't have global state, which means it can "restart every thread" whenever, which is what you don't want to do...
<shka_>
unfortunately heap can be exhausted, gengc can fail, libs can be buggy and so one
<shka_>
and not everything can be handled in a single thread
<shka_>
so as a last resort, you need to kill your process anyway
<shka_>
or just swap it out so it can be debugged
marusich has quit [Quit: zzz]
hineios73039 has joined #lisp
<shka_>
ralt: yeah, ability of erlang to restart everything, anytime is nice, i don't like the price you are supposed to pay for that
<shka_>
:(
<shka_>
no-defun-allowed: makes sense, anyway?
rogersm has joined #lisp
<no-defun-allowed>
shka_: I don't disagree, but if you have "localised" state well enough, it makes sense that you can just restart part of the program, and have the computer figure out what has to be restarted.
gaqwas has quit [Remote host closed the connection]
<shka_>
no-defun-allowed: yes, my point is that world is not perfect
<shka_>
and sbcl is not perfect either
<ralt>
what could be really nice would be some sort of mix between manardb and netfarm...
<White_Flame>
erlang doesn't just blindly restart threads if they crash. You have to set up supervision trees, tell it thresholds for how fast/often to restart before propagating out consistent failure errors, etc
<White_Flame>
it's a good model to read up on an internalize, even if I've moved away from the language
hineios7303 has quit [Ping timeout: 260 seconds]
<no-defun-allowed>
Sure, but we're talking about something going wrong, which is very unlikely hopefully, and then it being a bug in the implementation, which is unlikely again.
<shka_>
no-defun-allowed: given time, it is bound to happen
<White_Flame>
in telephony, recording an error & continuing, or even ignoring errors (if they don't repeat too often) and continuing could suffice
<no-defun-allowed>
So most of the times something goes wrong, we can do something intelligent, and very rarely would we have to restart entirely.
<White_Flame>
but, a lot of communications stuff is more stateless than general applications
<White_Flame>
"do something intelligent" means writing way more code than throwing away broken state and starting fresh
<White_Flame>
if there are weird edge cases, or resource contentions, or a dropped socket or something, those could be ignorable and restartable
<White_Flame>
but the erlang supervision stuff would catch if something is just flailing in constant restarts without progress
<White_Flame>
which would indicate an actual coding bug or broken environment
wxie has quit [Remote host closed the connection]
holycow has quit [Quit: Lost terminal]
fluxwave has joined #lisp
<no-defun-allowed>
Yeah, it would.
<shka_>
no-defun-allowed: i guess it is fine, i just wanted to highlight that restarting same thread means that you can no longer debug it
<shka_>
and you can always have a global failure of shared resources
<no-defun-allowed>
I suppose I'm fortunate enough to have a situation in which everything is almost isolated.
<shka_>
no you don't :-)
<no-defun-allowed>
:(
<shka_>
you never got GC invariant lost from sbcl?
<White_Flame>
shka_: the assumption is that the errored thread produced a useful crash report before restarting
<shka_>
White_Flame: this is cool, but ability to attach debugger is superior imho
<White_Flame>
maybe
<White_Flame>
but debug logs tend to be way more useful
<no-defun-allowed>
Maybe once or twice in three years?
<shka_>
wow
<White_Flame>
as the path to achieve the broken state almost always starts well before the error site
* shka_
is under impression that sbcl hates him
* White_Flame
has never gotten a GC invariant error
<White_Flame>
and I do a ton of stuff at safety 0
<White_Flame>
and had a lot of other ways SBCL crashed ;)
<phoe>
if you get an implementation crash then restart the implementation
hdasch has quit [Read error: Connection reset by peer]
<shka_>
well, it got waaaaaaaaay better in 2020
<no-defun-allowed>
I can't say I count them, but I don't usually witness implementation bugs.
<White_Flame>
and if you blow the stack and just get a warning, restart the implementation
<phoe>
that's actually one of the nicer crashes you can get because all allocated resources are freed when the process dies ;)
<White_Flame>
yeah, erlang gets a lot of that advantage in-process, because each of its "processes" (threads) is treated similarly, each with its own private heap & resources
<shka_>
no-defun-allowed: ok, i don't have anything useful to add at this point
rogersm_ has joined #lisp
<shka_>
sorry if i was annoying
hdasch has joined #lisp
<phoe>
I think you weren't annoying
<phoe>
just heavily pessimistic
<no-defun-allowed>
shka_: No, that was fine. More stuff to think about.
<shka_>
phoe: only paranoid survive!
<White_Flame>
but in any case, your execution environment dying is not really the responsibility of the code within it to defend against
<White_Flame>
as it really can't
<shka_>
also, i lost my job recently, so i am a little bit anxious
<phoe>
shka_: survival isn't all that's required from life
<phoe>
ouch :( sorry to hear that
<phoe>
s/required/wanted/
<no-defun-allowed>
That blows.
<shka_>
i would say that surviving is a good start :)
<shka_>
i will be fine though, don't worry
rogersm_ has quit [Ping timeout: 264 seconds]
jonatack_ has quit [Quit: jonatack_]
nostoi has joined #lisp
h4milton_ has quit [Quit: Lost terminal]
kaftejiman has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
hhdave has quit [Quit: hhdave]
jonatack has joined #lisp
younder has joined #lisp
nostoi has quit [Quit: Verlassend]
hhdave has joined #lisp
pjb has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
<ebrasca>
I don't think it is good answer for all cases.
<phoe>
yes, as for cleaning up stuff and/or upgrades it won't work
<phoe>
since you need to remove old stuff as well
<phoe>
I don't think the Lisp world currently has a good solution to that problem; maybe beach's work on first-class environments would be of use
wxie has quit [Ping timeout: 260 seconds]
milanj has joined #lisp
<phoe>
since, in theory, you could try and discard the whole environment which has e.g. an old version of bordeaux-threads loaded in, and then switch for an environment that has a new version ready to use
<phoe>
there is still an issue of what happens to the currently alive objects of type bt:thread, and such
<phoe>
but then again, that's a question of upgrading Lisp software in long-running images
<phoe>
I wonder if/how Genera did that...
<pjb>
ebrasca: fundamentally, this is like that in lisp, because lisp was invented to do symbolic AI, and therefore, when the AI learns something, such as for example, that car may mean also some kind of vehicule, then the definition and property list of the symbol CAR must be mutated.
<edgar-rft>
ebrasca: first create a perfect universe, then start to think about things of minor importance :-)
<pjb>
ebrasca: in symbolic AI, it was expected to "compile" the meaning of things into lisp code too, for efficiency. So function definitions must be mutable at run-time (when the AI learns).
<pjb>
ebrasca: note that human brains work symbolically too. At least in non feral humans, (and I would assume in a number of non-feral domestic animals too), there's a symbolic layer working over the statistical neural network layer. And when you learn something, there's some "compilation", some translation of the symbolic structure to the statistical neural network.
<pjb>
For example, when you learn the multiplication tables, and perform painfully a multiplication by the rule, this is purely symbolic processing. But once you can guess a multi-digit multiplication instantaneously, it's compiled statistical neural network processing.
<pjb>
Or, when you learn the ballistic equations, vs. when you learn to throw a stone.
<pjb>
So as long as we don't perform a fusion of symbolic AI with statistical AI, we won't be able to reach AGI.
<pjb>
This is why AI-interested people should keep learning lisp (and the symbolic AI history coming with it), along with nvidia…
<Xach>
Shinmera: i think an update to bordeaux-threads may have damaged maiden
<kpoeck>
fe[nl]ix great (and our life with clasp will be much easier with the new release so thanks for that)
<jackdaniel>
that reminds me, that I need to update it (and first contact prof Attardi), apparently ECoLisp is an open sourced version on Delphi
gko has joined #lisp
wsinatra has joined #lisp
toorevitimirp has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 264 seconds]
toorevitimirp has joined #lisp
ggole has joined #lisp
orivej has joined #lisp
efm has quit [Quit: Konversation terminated!]
ech has quit [Ping timeout: 256 seconds]
funnel has quit [Ping timeout: 260 seconds]
SGASAU has quit [Remote host closed the connection]
funnel has joined #lisp
ayuce has joined #lisp
SGASAU` has joined #lisp
SGASAU` has quit [Remote host closed the connection]
SGASAU` has joined #lisp
wxie has joined #lisp
dddddd has joined #lisp
bitmapper has joined #lisp
yonkunas has joined #lisp
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #lisp
ahungry has joined #lisp
EvW1 has joined #lisp
nalik891 has joined #lisp
Bourne has joined #lisp
nullniverse has quit [Ping timeout: 272 seconds]
nalik891 has quit [Max SendQ exceeded]
nalik891 has joined #lisp
nalik891 has joined #lisp
orivej_ has quit [Ping timeout: 246 seconds]
orivej has joined #lisp
funnel has quit [Ping timeout: 246 seconds]
scymtym_ has joined #lisp
funnel has joined #lisp
scymtym has quit [Ping timeout: 272 seconds]
igemnace has joined #lisp
wxie has quit [Ping timeout: 260 seconds]
shifty has joined #lisp
cantstanya has quit [Remote host closed the connection]
ldb has joined #lisp
<ldb>
good evening
cantstanya has joined #lisp
scymtym_ has quit [Remote host closed the connection]
scymtym has joined #lisp
<fe[nl]ix>
Xach: is there an wasy way to download all systems that depend on Bordeaux-threads ?
Kundry_Wag has joined #lisp
bendersteed has quit [Ping timeout: 264 seconds]
ldb has quit [Quit: leaving]
Bourne has quit [Ping timeout: 264 seconds]
<Shinmera>
fe[nl]ix: only including direct dependencies: (loop for system in (ql-dist:provided-systems T) when (find "bordeaux-threads" (ql-dist:required-systems system) :test #'string=) collect system)
rgherdt has quit [Ping timeout: 272 seconds]
<Shinmera>
you should be able to just mapc ql-dist:ensure-installed that list.
theseb has joined #lisp
dkovalev__ has joined #lisp
nalik891 has quit [Ping timeout: 272 seconds]
<fe[nl]ix>
(mapc #'(lambda (s) (ql-dist:ensure-installed (ql-dist:find-system s))) (ql:who-depends-on "bordeaux-threads"))
<fe[nl]ix>
Shinmera: thanks
<fe[nl]ix>
I had a vague plan of removing recursive locks
<fe[nl]ix>
from Bordeaux-threads
rgherdt has joined #lisp
<froggey>
fe[nl]ix: you pinged me a little while ago, I assume about the mezzano PR for BT, any problems?
<fe[nl]ix>
yes, but it's solved
<froggey>
ok, good
<fe[nl]ix>
the amount of packages using recursive locks is surprising
<fe[nl]ix>
yes, but more essentially because recursive locks are almost never necessary except for porting legacy single-threaded code to multi-threaded environments
<fe[nl]ix>
also because a number of implementations don't have acquire/release for recursive locks
terpri has joined #lisp
<jackdaniel>
another reason could be that using recursive locks with condition variables is unreliable at least on some implementations
<fe[nl]ix>
that too
<phoe>
yes, I can understand that
<Bike>
slime still uses recursive locks in its gray streams... i feel like that could be rewritten but i dunno...
<phoe>
up to the point of implementing them itself I guess
<garbochock>
Hi lispfolk, I'm new to the language and currently reading (mostly doing the exercises) of Common LISPcraft by Robert Wilensky. Currently reading about property lists and would like advice on my implementation of intersection. The book states that by 'marking' symbols you only have to go through each list once - however I can't seem to figure out how to go through each list only once and still remove all properties! Currently my
<garbochock>
function leaves the symbols marked after execution.
<phoe>
garbochock: could you give me an example? (intersection-mark '(a b c f g) '(c d e u v)) ;=> (C)
sjl_ has joined #lisp
<Bike>
i ran into this because i didn't check the docstring on make-lock that says it has to be recursive, and thought "i know, clasp doesn't have to use recursive locks here", and horrible problems happened.
<beach>
garbochock: That kind of trick is not recommended anyway. It messes with the global environment.
<garbochock>
phoe: Yes, that works fine, the problem is if you execute (intersection-mark '(a b c) '(d e f)) followed by (intersection-mark '(d e f) '(a b c)) => (C B A)
<beach>
garbochock: We used to do that kind of stuff in the old days. Not anymore.
<garbochock>
I see, the book is most likely outdated by current standards
<beach>
Yeah. I forget the year of publication, but it was a while ago.
<beach>
Currently, most people here would recommend PCL.
<jackdaniel>
minion: tell garbochock about pcl
<minion>
garbochock: please look at pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<jackdaniel>
minion: tell garbochock about paip
<minion>
garbochock: paip: Paradigms of Artificial Intelligence Programming. More about Common Lisp than Artificial Intelligence. Now freely available at https://github.com/norvig/paip-lisp
<jackdaniel>
these two books are excellent references
<phoe>
garbochock: this is because your SETF GET persists between calls to that function. It doesn't clean up after itself.
<phoe>
also, what beach and jackdaniel said, symbol property lists are kind of a blast from the past
<beach>
Ah, 1984. Way before the ANSI standard was published.
<phoe>
still found in software that is 20+ years old, but not really done nowadays
<phoe>
this sounds more like CLtL1
<beach>
Definitely.
<garbochock>
Thanks for the advice! I mostly went into LISPcraft due to the many exercises at the end of each chapter. I will look into reading PCL and paip! Did head into PCL a while ago but find that I learn best through solving problems by myself!
<beach>
garbochock: The ANSI standard of 1994 added the Common Lisp object system, which changes the way many programs are written.
<garbochock>
Now I have a better foundation in programming in general and bit more experience with the lisp syntax though!
<beach>
garbochock: Though, for simple problems, the solutions are the same of course.
xuxuru has quit [Quit: xuxuru]
<phoe>
oh and one more thing
<phoe>
minion: tell garbochock about gentle
<minion>
garbochock: direct your attention towards gentle: "Common Lisp: A Gentle Introduction to Symbolic Computation" is a smoother introduction to lisp programming. http://www.cs.cmu.edu/~dst/LispBook/
<beach>
I don't recommend "gentle" for people who already know some programming.
<phoe>
you could try this one if you feel like the previous two are going a bit too fast
orivej has quit [Ping timeout: 258 seconds]
<phoe>
oh right, I was about to mention what beach said
<phoe>
if you already got rolling with implementing your own INTERSECTION then I guess gentle might be too slow
orivej has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
theseb has quit [Quit: Leaving]
bhartrihari has joined #lisp
kinope has joined #lisp
<kinope>
Morning all
<beach>
Hello kinope.
<kinope>
Hi beach
<phoe>
heyyy
5EXAAFRTG is now known as ober
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
<kinope>
I have a question about locks. I've been working on a thread-safe queue implementation, the execution time to enqueue 10 million objects is down to 40 seconds from 250 seconds but, I've noticed that if I remove all locking associated functions the execution time drops to 9 seconds. Now, I know I need the locks (using bordeaux-threads currently) but I'm wondering If locks come in lighter weight varieties? The implementation
<kinope>
uses condition variables to wait and notify on/for underflow and overflow conditions. Is a spinlock something I should look into since I think they dont yield, I don't think the worker threads need to yeild back to the OS.
<kinope>
hey phoe
bitmapper has quit [Ping timeout: 260 seconds]
<beach>
kinope: Are you sure there aren't any lock-free queue techniques?
<beach>
Google seems to think so.
<beach>
... think that there are such implementations, I mean.
<jackdaniel>
kinope: you may also check out a recently closed PR to bordeaux-threads which was proposing a thread-safe queue based on condition variables to compare implementations
* jackdaniel
sniffles
<jackdaniel>
kinope: in this pr one of reviewers mentions two queues, one in lparallel and one named genserve if I remember correctly
ahungry has quit [Remote host closed the connection]
<kinope>
Thanks for the info everyone, there is always something novel to chew on!
<kinope>
Great, thanks jackdaniel
akoana has joined #lisp
sdumi has quit [Ping timeout: 256 seconds]
ahungry has joined #lisp
sdumi has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
rumbler31 has quit [Remote host closed the connection]
orivej has joined #lisp
cosimone has quit [Ping timeout: 256 seconds]
cosimone has joined #lisp
kpoeck has left #lisp [#lisp]
ober has quit [Remote host closed the connection]
torbo has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 265 seconds]
X-Scale` is now known as X-Scale
pjb has quit [Ping timeout: 272 seconds]
jprajzne has quit [Quit: jprajzne]
jprajzne has joined #lisp
jprajzne has quit [Client Quit]
jprajzne has joined #lisp
orivej has quit [Ping timeout: 258 seconds]
orivej has joined #lisp
terpri has quit [Remote host closed the connection]
terpri has joined #lisp
milanj_ has joined #lisp
FreeBirdLjj has quit [Remote host closed the connection]
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
FreeBirdLjj has joined #lisp
milanj has quit [Ping timeout: 246 seconds]
bhartrihari has joined #lisp
pjb has joined #lisp
FreeBirdLjj has quit [Ping timeout: 260 seconds]
SGASAU` has quit [Remote host closed the connection]
SGASAU` has joined #lisp
asarch has joined #lisp
andrei-n has joined #lisp
EvW1 has quit [Ping timeout: 256 seconds]
orivej has quit [Ping timeout: 256 seconds]
Bourne has joined #lisp
wnh__ has quit [Quit: wnh__]
orivej has joined #lisp
rgherdt has quit [Ping timeout: 272 seconds]
SGASAU` has quit [Remote host closed the connection]
SGASAU` has joined #lisp
dominic34 has joined #lisp
ebrasca has quit [Remote host closed the connection]
bitmapper has joined #lisp
rogersm has quit [Quit: Leaving...]
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
ebrasca has joined #lisp
SGASAU` has quit [Read error: Connection timed out]
SGASAU` has joined #lisp
ayuce has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 246 seconds]
lnostdal has joined #lisp
rgherdt has joined #lisp
<pve>
Hi, has it always been customary to start a file with an (in-package ...) expression?
<phoe>
I guess that genera modelines automatically took care of that since they had a "Package: ..." field
<pve>
Like, was there a time when a loader would bind *package* and load some files "into" that package?
<phoe>
I guess you can do anything with LOAD, including (let ((*package ...)) (load ...))
<pjb>
pve: not always.
<pve>
Yep, but has it ever been common practice? Before asdf, defsystem etc
<phoe>
some Lisp software still loads itself this way, including ANSI-TEST AFAIR
<pjb>
pve: notably, you can have files designed to be loaded in different packages.
dominic34 has quit [Ping timeout: 246 seconds]
<pjb>
pve: for example, I have a html.lisp file, that can be loaded in a html generator, or in a html parser.
<pjb>
It contains the definition of the html grammar, as defelement and defentity forms.
<pve>
right
<_death>
with package-inferred-systems it's customary to begin with a defpackage form.. in one old codebase I'm reviving some files are useful to load in whatever is the current package, given that it has the right symbols
<pjb>
pve: the question to ask is what is the development environment model you use. If you use the classic unix file based development environment, then you may adopt asdf (quicklisp), and in that case a degree of "staticity" in the source files is a good idea; you will want the in-package forms.
<pjb>
Other development environment models would have other requirements.
<pve>
I'm building a loader (or trying to, anyway) for my symbolic-smalltalk "language", and now I'm considering the pros and cons of having a file "know" its package
rixard has quit [Read error: Connection reset by peer]
rixard has joined #lisp
<pve>
but thank you, for the input.. I'll ponder this some more
gaqwas has joined #lisp
kpoeck has joined #lisp
<phoe>
how are these files of yours structured?
<phoe>
or, how do Lisp packages come into play when you play with smalltalk?
rogersm has joined #lisp
dra_ has joined #lisp
dra_ has quit [Client Quit]
dra_ has joined #lisp
<pve>
phoe: when a file is loaded it results in one or more classes defined plus their methods
<pve>
at least thats the plan for now
<phoe>
pve: what are the names of these classes?
<phoe>
is there any kind of class/method namespacing in Smalltalk?
dra_ has quit [Client Quit]
<pve>
it's running inside lisp so the classes are just lisp standard-classes
<pve>
and their names are symbols
remexre has joined #lisp
<phoe>
I mean, if all symbols share a global namespace
<phoe>
then all of your Smalltalk would fit in a single Lisp package
kaftejiman has quit [Remote host closed the connection]
dra_ has joined #lisp
dra_ has quit [Remote host closed the connection]
dra has joined #lisp
<pve>
ah, so when I start a new project I would also define a lisp package, just like when making a CL lib
<phoe>
you mean a Smalltalk project?
<pve>
the methods all go into a shared method package, however (at least by default, it's configurable)
<pve>
yes
<phoe>
oh, okay
<phoe>
I know nothing about namespacing in Smalltalk, but that would work, I guess
<pjb>
There's no namespace in Smalltalk. Only classes.
<pve>
it's not really even necessary to use a loader, as it's possible to mix the smalltalk code into the lisp code with a [ ... ] reader macro
rumbler31 has joined #lisp
<pve>
but I'd like to make one, for completeness
<pve>
it's probably technically wrong to refer to it as "Smalltalk", since it's currently just about the syntax and some core functionality.. no smalltalk standard lib or anything
<pve>
but it does cover large parts of CL...
<phoe>
lisptalk
Krystof has quit [Ping timeout: 260 seconds]
rumbler31 has quit [Ping timeout: 264 seconds]
<pve>
so you can do for instance [ Hash-table eq :at 'foo :put 'hello ]
lnostdal has quit [Ping timeout: 265 seconds]
ncakerlist has joined #lisp
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
<jcowan>
Okay. It wasn't what I expected when I first saw it: it defines a DAG of protocols rather than a tree of classes.
heisig has quit [Quit: Leaving]
<pve>
implementing all of that would have been so daunting, I decided to start with the syntax and class definitions and make a thin layer on top of CL, which I'm more familiar with
rumbler31 has joined #lisp
<jcowan>
What, only 300 pages! CL has 1300 or whatever.
<pve>
class definitions meaning the methods necessary to support defining new classes.. i.e. subclass: etc
* jcowan
nods
<pve>
but fortunately CLOS gives good tools for all of this
<jcowan>
Yes.
lnostdal has joined #lisp
lnostdal has quit [Remote host closed the connection]
garbochock has quit [Ping timeout: 272 seconds]
<jcowan>
There are only 6 required classes and 25 required classes-or-classlike-things
shangul has quit [Remote host closed the connection]
shangul has joined #lisp
<jcowan>
there are 93 protocols, but many are very small
<jcowan>
and yes, CLOS is The Right Thing, since it supports multiple inheritance even though ST does not.
lucasb has joined #lisp
dominic34 has joined #lisp
bitmapper has quit [Remote host closed the connection]
kini has quit [Remote host closed the connection]
bhartrihari has left #lisp ["Disconnected: Replaced by new connection"]
bhartrihari has joined #lisp
kini has joined #lisp
sauvin has quit [Read error: Connection reset by peer]
bitmapper has joined #lisp
kini has quit [Excess Flood]
dominic34 has quit [Ping timeout: 246 seconds]
kini has joined #lisp
msk has quit [Quit: Leaving]
<seok>
Is there function to parse string -> float?
<pjb>
seok: it's basic language implementation bootstrapping.
<pjb>
seok: the question is what language implementations are available to you?
<pjb>
seok: if you have a CL implementation available, then you can implement your CL in CL.
<pjb>
seok: one big advantage of implementing a language X in X, is that it ensures that your implementation is (relatively) bug-free, since it has at least to compile itself to a program that you can easily check, by using it to compile itself again, and compare the results.
<Bike>
much like you can build gcc with itself and such
<pjb>
seok: in the prehistory of computing, there was no lisp compiler. So you had to write the first lisp in a different programming language. There weren't a lot of them at the time: only assembler and fortran!
<pjb>
So they choose to use assembler.
<pjb>
They only implemented an interpreter in assembler. Then they implemented the lisp compiler in lisp, and used the interpreter to compile the compiler.
<seok>
Right, if you compile it, it becomes binary anyway I guess
<pjb>
exactly.
<seok>
There is no difference in compiled program written in C or lisp or anything
<seok>
Now I see
<pjb>
But nowadays, you can use any high level programming language. Since CL is a good high level programming language, it's a good choice to use it.
<pjb>
Another good choice could be haskell.
<pjb>
Or any programming language that can be easily proven.
<seok>
haskell is still a good choice?
<pjb>
haskell is always a good choice :-)
<seok>
for writing CL you mean right?
<pjb>
Well, I prefer to use CL anyways. But if you like haskell, haskell is not a bad choice.
<seok>
I've never used haskell
<pjb>
So CL is a good choice.
<seok>
How long would you take to write CL implementation in CL?
<seok>
: D
<pjb>
seok: anything between, say, 1 month to 10 years or more.
<seok>
1 month to build it, 9 years to optimize?
<pjb>
seok: if you're a good CL programmer, already knowing CL, and in good health, you could write a CL interpreter in a week, and take the 3 following weeks to implement the rest of the CL library (you would take all the shortcuts allowed by the CL specifications, and perhaps use a few libraries).
doomlist3 has joined #lisp
<pjb>
seok: but if you want to use top-notch compiler tech, yes, it will take more time.
milanj_ has quit [Quit: This computer has gone to sleep]
<pjb>
drmeister started from ecl sources and made clasp, a CL implementation working on C++ and with C++, in about six months IIRC.
dra has quit [Quit: Leaving]
<seok>
I'm reading on haskell and found out that it's not as old as I imagined
<pjb>
beach has been working from scratch on sicl for six year I believe, and should be competed in 4.
<kpoeck>
I am a bit puzzled that the wike.c2.com claims that "OpenMCL for example can be bootstrapped with just a C compiler"
<pjb>
kpoeck: yeah, I don't think it was ever possible.
<kpoeck>
does not seem correct
<pjb>
I've seen old sources of MCL, for Macintosh 680x0, and there was CL code to be compiled with the lisp image.
<kpoeck>
They must have confused that with ecl or clisp
ncakerlist has quit [Ping timeout: 256 seconds]
<pjb>
ecl and clisp also have a sizeable part of CL code.
<pjb>
But ecl and clisp are indeed bootstrappable on a system with only a C compiler, and no lisp image.
milanj_ has joined #lisp
<pjb>
ccl needs a ccl lisp image (like its ancestors openmcl, rmcl and mcl, AFAIK).
<seok>
wow beach is doing a lot of huge projects
<seok>
is he getting paid for this?
karlosz has joined #lisp
<pjb>
he's a university professor.
<seok>
he teaches CL?
<pjb>
yes.
<seok>
nice
<seok>
what about you pjb?
<pjb>
freelance programmer.
<seok>
Do you get jobs in lisp?
<pjb>
sometimes.
<seok>
What kind of work are companies after when asking for lisp?
<dlowe>
pg is very opinionated and you'll find that very few people here share his opinions
<dlowe>
despite his unfortunate and accidental position as spokesperson for lisp
<phoe>
seok: which page of On Lisp?
<seok>
He mentions it for functions, but not macros
<phoe>
also don't get me started on pg and his opinionatedness :D
<seok>
it makes sense that it is ok for macros
<seok>
I've read that part yesterday, let me look it up
<seok>
pg 29
<seok>
with bad-reverse example
<phoe>
oh, yes
<phoe>
not only his code is broken, it does not conform
<phoe>
mutating literal data is undefined behavior
<phoe>
congrats, pg, congrats
<seok>
he messed up?
<phoe>
yes!
<phoe>
he purposefully writes a destructive function, purposefully calls it on non-fresh data, and then goes "look this is bad style lol"
karayan has quit [Remote host closed the connection]
<phoe>
hey, you asked for it, man; garbage in, garbage out
<seok>
isn't that his intention?
<seok>
how did he mess up
<phoe>
mutating '(1 2 3) is undefined behavior, since it is a literal
<phoe>
using toplevel SETQ is another undefined behavior, though all implementations I know do the "Right Thing" in this case and allow it
<phoe>
anyway, bad-reverse is a very inefficient implementation of nreverse, not reverse
<phoe>
so the third way he screwed up is in the naming - he should have named it bad-nreverse
<phoe>
to show that this function destroys stuff in its wake
karayan has joined #lisp
<phoe>
also, he talks about complexity; nreverse is linear in time, just like reverse
<phoe>
but pg conveniently doesn't mention that nreverse has constant space complexity while reverse has linear space complexity
<aeth>
Literal lists/vectors/strings are basically immutable sequences without any kind of static or dynamic checking to prove that they're kept immutable. So never mutate them.
<phoe>
another place where he conveniently screws up to prove his point
<phoe>
soooo, I sadly call BS on this part of On Lisp
<phoe>
that's like, four in a row I could find.
<axion>
Hopefully people aren't as critical on your book :)
<phoe>
hope they are
<phoe>
I want to fix it all in the next revision ;_;
<seok>
Heh, nobody likes PG here?
<seok>
Is On Lisp bad to read?
<phoe>
On Lisp as a whole is a valuable book
<seok>
it is on awesome-cl recommendation
<phoe>
especially if you want to write macros
<phoe>
and, as a Lisp programmer, you will want to write macros at some point
<seok>
Yes,
* axion
would recommend reading PCL first, as it touches on a lot of problems you've been asking and is generally accepted as the must first read
<seok>
is that principles of common lisp?
<phoe>
I'm just kind of biased against pg, since he has some strong opinions that are not true in my opinion and that have, IMO, poisoned how Lisp the language and the Lisp community is viewed
<phoe>
Practical Common Lisp
<phoe>
minion: tell seok about pcl
<minion>
seok: please see pcl: pcl-book: "Practical Common Lisp", an introduction to Common Lisp by Peter Seibel, available at http://www.gigamonkeys.com/book/ and in dead-tree form from Apress (as of 11 April 2005).
<seok>
I've already read that one
<phoe>
:D
<axion>
Then you must not have understood it; read it again and do all practicals
<seok>
:D
<seok>
ok :(
<seok>
you got me I've sort of winged it
c_nix has quit [Ping timeout: 256 seconds]
FreeBirdLjj has joined #lisp
c_nix has joined #lisp
scymtym_ has joined #lisp
scymtym has quit [Ping timeout: 246 seconds]
ebrasca has quit [Remote host closed the connection]
FreeBirdLjj has quit [Ping timeout: 260 seconds]
the4 has quit [Remote host closed the connection]
Krystof has joined #lisp
theseb has quit [Quit: Leaving]
kinope has quit [Quit: Connection closed for inactivity]
adip has joined #lisp
torbo has quit [Ping timeout: 246 seconds]
wsinatra has quit [Quit: WeeChat 2.8]
emacsomancer has quit [Ping timeout: 256 seconds]
torbo has joined #lisp
pjb has quit [Ping timeout: 272 seconds]
gaqwas has joined #lisp
kaftejiman has joined #lisp
doomlist3 has quit [Ping timeout: 272 seconds]
jonatack has quit [Remote host closed the connection]
jonatack has joined #lisp
emacsomancer has joined #lisp
yonkunas has quit [Quit: Connection closed for inactivity]
pjb has joined #lisp
<pjb>
seok: push should have been named pushf but people found it funny.
ggole has quit [Quit: Leaving]
xuxuru has quit [Quit: xuxuru]
shifty has quit [Ping timeout: 264 seconds]
wgl has joined #lisp
wgl has quit [Remote host closed the connection]
wglb has joined #lisp
ahungry has quit [Remote host closed the connection]
SAL9000 has quit [Quit: WeeChat 2.7.1]
pve has quit [Quit: leaving]
gekkou has joined #lisp
narimiran has quit [Ping timeout: 260 seconds]
gravicappa has quit [Ping timeout: 260 seconds]
SGASAU` has quit [Quit: ERC (IRC client for Emacs 26.3)]
SGASAU has joined #lisp
kpoeck has left #lisp [#lisp]
nikkal has joined #lisp
rgherdt has quit [Ping timeout: 272 seconds]
yonkunas has joined #lisp
dominic34 has joined #lisp
aap has quit [Ping timeout: 256 seconds]
pjb has quit [Ping timeout: 272 seconds]
aap has joined #lisp
dkovalev__ has quit [Quit: Leaving]
potta_coffee has quit [Quit: Konversation terminated!]
ech has joined #lisp
dominic34 has quit [Ping timeout: 246 seconds]
random-nick has quit [Ping timeout: 256 seconds]
cosimone has quit [Quit: Quit.]
pjb has joined #lisp
rixard has quit [Read error: Connection reset by peer]
hapticFeels has quit [Ping timeout: 240 seconds]
andrei-n has quit [Quit: Leaving]
<dlowe>
itym push! :)
rixard has joined #lisp
thmprover has joined #lisp
Lord_of_Life has quit [Ping timeout: 240 seconds]
Lord_of_Life has joined #lisp
grewal has quit [Ping timeout: 260 seconds]
grewal has joined #lisp
X-Scale` has joined #lisp
X-Scale has quit [Ping timeout: 258 seconds]
X-Scale` is now known as X-Scale
<jcowan>
pjb: I once had to write an Arpanet finger utility for TOPS-10 in Cobol, because that was the only language the mgr could be sure of getting maintenance programmers for