CommanderViral has quit [Quit: ZNC 1.7.1+deb1+bionic1 - https://znc.in]
<aeth>
jasom: +r is the one that stops unidentified names from joining right? That's subject to race conditions, especially with the traditional /msg nickserv login, but it's happened to me two or three times with the SSL login which transmits the password before I log in, not right after.
CommanderViral has joined #lisp
<aeth>
jasom: What that means is that when you disconnect, there's always a small chance that you won't notice and will be effectively auto-kicked from half of the channels you're in
<jasom>
aeth: huh, that's never happened to me with weechat; perhaps it waits before joining channels?
<aeth>
jasom: yeah, I wouldn't be surprised if your client waits like 1 second or something
<aeth>
That would make this situation very unlikely.
Bourne has quit [Read error: Connection reset by peer]
stentroad has joined #lisp
<aeth>
jasom: yes, but SASL authentication has a race condition on Freenode where you can still fail to appear authenticated, making +r a terrible idea because you can come back to IRC 8 hours later to find that you're not in half of your channels anymore, at least in theory.
<jasom>
aeth: I was pointing out that my client might fail with nicserv authentication, or maybe it's just really slow is all :)
<aeth>
Yeah, my point was, even with SASL over NickServ, it can still happen.
<aeth>
s/over/instead of/
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 256 seconds]
Lord_of_Life_ is now known as Lord_of_Life
zaquest has quit [Quit: Leaving]
stentroad has quit [Quit: qicr for android: faster and better]
stentroad_ has joined #lisp
Lycurgus has quit [Ping timeout: 256 seconds]
cosimone has joined #lisp
stentroad2 has joined #lisp
stentroad2 has left #lisp [#lisp]
zaquest has joined #lisp
Oladon has quit [Quit: Leaving.]
jfrancis has quit []
lucasb has quit [Quit: Connection closed for inactivity]
bitmapper has quit [Ping timeout: 246 seconds]
Necktwi has joined #lisp
Ven`` has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
EvW1 has quit [Ping timeout: 260 seconds]
Sammi has joined #lisp
yankM has quit [Ping timeout: 272 seconds]
Sammi is now known as chibi_robocop
Kaisyu7 has quit [Quit: ERC (IRC client for Emacs 26.3)]
chibi_robocop has quit [Quit: Konversation terminated!]
pjb has joined #lisp
<emacsomancer>
is there a cl internal equivalent of POSIX `command -v __` ?
hsaziz has joined #lisp
<no-defun-allowed>
What is that supposed to do?
<no-defun-allowed>
It finds the directory programs are stored in?
Oladon has joined #lisp
wxie has quit [Ping timeout: 244 seconds]
<axion>
emacsomancer: There isn't a truly portable method. uiop has uiop:argv0, but it assumes you dumped an image with uiop (*image-dumped-p* is non-nil). You could use (uiop:raw-command-line-arguments), or on SBCL: sb-ext:*posix-argv*.
<emacsomancer>
no-defun-allowed: yes, like which
<emacsomancer>
axion: thanks. i'll look into sb-ext:*posix-argv*
akoana has left #lisp ["Leaving"]
shifty has joined #lisp
pierpa has quit [Remote host closed the connection]
pjb has quit [Ping timeout: 272 seconds]
aindilis has quit [Ping timeout: 260 seconds]
rumbler3_ has joined #lisp
<beach>
Good morning everyone!
dxtr has quit [Remote host closed the connection]
sauvin is now known as Daddy
Daddy is now known as Daddums
Daddums is now known as Sauvin
pjb has joined #lisp
Jesin has quit [Read error: Connection reset by peer]
Jesin has joined #lisp
Jesin has quit [Client Quit]
Jesin has joined #lisp
efm has quit [Read error: Connection reset by peer]
efm has joined #lisp
ralt has quit [Quit: Connection closed for inactivity]
Oladon has quit [Quit: Leaving.]
FreeBirdLjj has joined #lisp
_jrjsmrtn has joined #lisp
FreeBirdLjj has quit [Ping timeout: 244 seconds]
__jrjsmrtn__ has quit [Ping timeout: 260 seconds]
pjb has quit [Ping timeout: 272 seconds]
shifty has quit [Ping timeout: 272 seconds]
buffergn0me has joined #lisp
dddddd has quit [Ping timeout: 264 seconds]
pjb has joined #lisp
yankM has joined #lisp
karlosz has quit [Quit: karlosz]
Oladon has joined #lisp
sdumi has quit [Ping timeout: 272 seconds]
sdumi has joined #lisp
patlv has quit [Quit: patlv]
karlosz has joined #lisp
narimiran has joined #lisp
lavaflow has quit [Ping timeout: 256 seconds]
madage has quit [Ping timeout: 240 seconds]
pjb has quit [Ping timeout: 272 seconds]
lavaflow has joined #lisp
madage has joined #lisp
shifty has joined #lisp
malm has quit [Quit: Bye bye]
jw4 has quit [Quit: tot siens]
jw4 has joined #lisp
yankM has quit [Quit: Leaving.]
ech has joined #lisp
Bourne has joined #lisp
ech has quit [Client Quit]
sdumi has quit [Ping timeout: 264 seconds]
Lycurgus has quit [Quit: Exeunt]
madage has quit [Ping timeout: 240 seconds]
madage has joined #lisp
gravicappa has joined #lisp
jw4 has quit [Quit: tot siens]
jw4 has joined #lisp
nullman has quit [Remote host closed the connection]
nullman has joined #lisp
pjb has joined #lisp
ech has joined #lisp
Oladon has quit [Quit: Leaving.]
aeth has quit [Read error: Connection reset by peer]
aeth has joined #lisp
quazimodo has quit [Ping timeout: 265 seconds]
benjamin-l has joined #lisp
wxie has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
quazimodo has joined #lisp
malm has joined #lisp
_whitelogger has joined #lisp
pjb has quit [Ping timeout: 265 seconds]
sdumi has joined #lisp
Jesin has quit [Ping timeout: 246 seconds]
<flip214>
emacsomancer: how about /proc/self/exe ?
orivej has quit [Quit: No Ping reply in 180 seconds.]
<flip214>
emacsomancer: oh, you need to find _other_ programs, not the CL process' executable
orivej has joined #lisp
<emacsomancer>
flip214: yeah, in retrospect, I realise my original question was not as clear as I had thought
hsaziz has quit [Quit: hsaziz]
shka_ has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
karlosz has quit [Quit: karlosz]
libertyprime has quit [Ping timeout: 256 seconds]
karlosz has joined #lisp
fanta1 has joined #lisp
pve has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
beach` is now known as beach
Bourne has quit [Read error: Connection reset by peer]
fluxwave has quit [Quit: leaving]
random-nick has joined #lisp
pjb has quit [Ping timeout: 265 seconds]
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #lisp
orivej has quit [Ping timeout: 240 seconds]
orivej has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
<phoe>
minion: memo for Bike: when we talked some time ago you mentioned that a large part of the condition system depends upon parsing types at runtime; is it really parsing, or just typechecking? or is typechecking meant to involve parsing due to how type specifiers work?
<minion>
Remembered. I'll tell Bike when he/she/it next speaks.
orivej has quit [Ping timeout: 256 seconds]
orivej has joined #lisp
Bourne has joined #lisp
refpga has quit [Read error: Connection reset by peer]
rgherdt has joined #lisp
pjb has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
doesthiswork has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
felideon has quit [Ping timeout: 252 seconds]
felideon has joined #lisp
phoe has quit [Ping timeout: 240 seconds]
phoe has joined #lisp
Bourne has quit [Read error: Connection reset by peer]
benjamin-l has quit [Ping timeout: 240 seconds]
benjamin-l has joined #lisp
orivej has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
Bourne has joined #lisp
Bourne has quit [Ping timeout: 240 seconds]
Jesin has joined #lisp
wxie has quit [Ping timeout: 256 seconds]
libertyprime has joined #lisp
ralt has joined #lisp
pjb has quit [Ping timeout: 244 seconds]
shka_ has quit [Ping timeout: 256 seconds]
shka_ has joined #lisp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
Cymew has joined #lisp
ljavorsk has joined #lisp
karlosz has quit [Quit: karlosz]
karlosz has joined #lisp
orivej_ has joined #lisp
orivej has quit [Ping timeout: 272 seconds]
karlosz has quit [Client Quit]
karlosz has joined #lisp
X-Scale` has joined #lisp
kbtr_ has quit [Ping timeout: 256 seconds]
solene has quit [Quit: Gateway shutdown]
X-Scale has quit [Ping timeout: 256 seconds]
X-Scale` is now known as X-Scale
kbtr has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
libertyprime has quit [Ping timeout: 264 seconds]
amerlyq has joined #lisp
<LdBeth>
I think it is because you can use `(simple-array `(,m ,n)) to construct type specifier at runtime
karlosz has quit [Client Quit]
karlosz has joined #lisp
<phoe>
correct, I'm thinking about conditions in particular though
pjb has joined #lisp
orivej_ has quit [Quit: No Ping reply in 180 seconds.]
orivej has joined #lisp
<jackdaniel>
you cant compute all types at compile time
<jackdaniel>
ie different ranges for numbers
<phoe>
correct, I'm thinking about conditions in particular though
karlosz has quit [Client Quit]
karlosz has joined #lisp
<jackdaniel>
it is the same for conditions, when you type (error foo bar qux) you need to construct condition from arguments, then you need to see if constructed condition matches any handler (which are dynamic)
ebrasca has joined #lisp
<phoe>
I fail to see how this is type *parsing* rather than type matching though; an implementation is allowed to preparse handler types and create predicate closures from them, which means that turning the list (or foo-condition bar-condition ...) into code happens at compile-time, not at execution-time
karlosz has quit [Client Quit]
karlosz has joined #lisp
<phoe>
therefore a sufficiently smart compiler™ is *not* required to parse condition types at runtime, it is only required to do runtime type checking
Bourne has joined #lisp
benjamin-l has quit [Ping timeout: 240 seconds]
<phoe>
I'm kinda nitpicky about words here, but these are words that I want to be 100% sure about since they get printed soon - hence my question
gaqwas has joined #lisp
karlosz has quit [Client Quit]
orivej has quit [Quit: No Ping reply in 180 seconds.]
karlosz has joined #lisp
orivej has joined #lisp
EvW has joined #lisp
kiboneu has quit [Remote host closed the connection]
karlosz has quit [Client Quit]
karlosz has joined #lisp
buffergn0me has quit [Ping timeout: 244 seconds]
karlosz has quit [Client Quit]
karlosz has joined #lisp
anticrisis has quit [Quit: Leaving]
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
<jackdaniel>
sufficiently smart compiler is a moot, but I suppose it's bike who knows best what he meant
karlosz has quit [Client Quit]
karlosz has joined #lisp
<MichaelRaskin>
Well, the relevant type specifiers for handler-bind and handler-case are constants known at compile time, preparing in advance to match them without re-parsing is not that unrealistic.
<MichaelRaskin>
But these are large parts by usage, maybe there is a large part by implementation size that does need re-parsing.
pjb has quit [Ping timeout: 246 seconds]
karlosz has quit [Client Quit]
karlosz has joined #lisp
<no-defun-allowed>
Can I dispatch on condition types with DEFMETHOD?
<Shinmera>
they're not classes, so no in theory
<no-defun-allowed>
):
ljavorsk has quit [Ping timeout: 258 seconds]
<Shinmera>
in practise though you can in most cases.
<no-defun-allowed>
Right.
<Shinmera>
(exceptions include initialize-instance)
<phoe>
for most pratcical cases you can do that, since all implementations implement condition types as condition classes
<phoe>
you can work around the fact that make-condition on SBCL does not follow the MOP initialization protocol by using make-instance instead of make-condition.
<Shinmera>
won't work if the user makes them though
<phoe>
yes, that's a big issue
<phoe>
it doesn't compose with SIGNAL, ERROR, and user code.
<phoe>
(unless user code also uses make-instance, but there's no way to enforce that)
<phoe>
;; by not composing with SIGNAL I mean (signal 'foo-condition ...) where internally MAKE-CONDITION is used instead of MAKE-INSTANCE
toorevitimirp has joined #lisp
karlosz has quit [Client Quit]
<no-defun-allowed>
Hm, I don't really mind how they're initialized; I want to generalise an event loop-kinda thing I have, and was thinking I could have a predicate for if a condition should stop the loop. If that's the case, I'll just rearrange the protocol to make it not a problem.
karlosz has joined #lisp
<phoe>
predicate, you mean, you want to specialize on a condition type?
<phoe>
(defmethod frob-p ((object my-condition)) t) will work just fine
<no-defun-allowed>
Yeah, the word is "specialize", but they aren't classes?
<phoe>
condition types are classes for all practical purposes and no currently alive implementation challenges this assumption
<phoe>
people who are standard purists will tell me that I am wrong because the standard does not mandate that, but *ALL* currently alive conforming implementations have condition types as classes.
<phoe>
so, in practice, you can always specialize on those, and things will work.
<no-defun-allowed>
Alright, thanks. I think I might be able to avoid that with a solution I think is better in some other ways, though.
<phoe>
you can use typep instead of class dispatch in order to be on the safe side, but that likely means either more code for you or static TYPECASE-style dispatch.
karlosz has quit [Client Quit]
karlosz has joined #lisp
rogersm has joined #lisp
<phoe>
I wholeheartedly wish that the Hypothetical Future Revision eliminates this mista^Wdistinction and mandates that conditions be standard-objects and follow all the CLOS and MOP protocols; it has so far brought a lot of annoyance to lispers who try to work with conditions the same way they work with CLOS
<phoe>
s/it/that distinction/
karlosz has quit [Client Quit]
karlosz has joined #lisp
<splittist>
lispers do have a tendency to want to accommodate entirely hypothetical lisp compilers while at the same time happily writing code that will work on a single flavour of OS
<phoe>
and only on SBCL
<splittist>
(:
toorevitimirp has quit [Remote host closed the connection]
toorevitimirp has joined #lisp
<p_l>
splittist: I think it's because /somehow/ compiler diversity is more visible and felt
<p_l>
splittist: how many OSes people use these days that won't accept unix-style *relative* path, for example?
<phoe>
also because CL has no standard library, using the modern definition of a standard library
<phoe>
since there's no COMMON-LISP.SOCKET in existence then some people go for SB-BSD-SOCKETS instead
<phoe>
not all code uses portability libraries
<p_l>
phoe: arguably the standard library is kind of like a spectrum, and how rich the standard library is impacts how code ends up written IMO
<phoe>
p_l: yes, that's my point - the fact that the CL standard library is poor causes a lot of interesting ways in which code tries to use sockets
<phoe>
that's less of an issue in the JVM environment, for example
* no-defun-allowed
will just use a second return value and have the client code handle conditions. That's something like hash table iterators.
<p_l>
phoe: it's poor compared to, let's say, Java, but it's rich compared to many other languages, which results in very weird middle position
Ven`` has joined #lisp
pjb has joined #lisp
<MichaelRaskin>
splittist: for _some_ issues entirely hypothetical compiler might be the next release of the one you use (like lexical environment representation). But if conditions are already classes everywhere, yeah, sounds unlikely anyone would ever want to deviate
jurov_ is now known as jurov
SAL9000 has quit [Remote host closed the connection]
<p_l>
phoe: I'd like to see some standardization happen in that area though, but we probably would need the same interface accepted by every implementation
<jackdaniel>
I recommend reading cl-implementers mailing list, where venders could *not* agree on the interface and package for QUIT function
orivej has quit [Quit: No Ping reply in 180 seconds.]
<phoe>
there's only one thing worse than herding cats, and that is herding lispers
<phoe>
jackdaniel: where is that mailing list at? I can't find it at clnet's mailman
<p_l>
jackdaniel: I find it easier to figure complaints about QUIT than about sockets
<p_l>
it's surprisingly possibly complex function :V
orivej has joined #lisp
<phoe>
we've discussed about socket design here anyway, I believe it was you who brought up the way the Dial function is done in golang
<phoe>
I think one could browse the channel logs to get that
karlosz has quit [Remote host closed the connection]
<phoe>
last activity: 2012, not counting a single mail from 2017
karlosz has joined #lisp
<phoe>
well
karlosz has quit [Remote host closed the connection]
<jackdaniel>
that shows how succesful it was
<jackdaniel>
I'm subscribed to the mailing list and I'm sure that at least some cl implementers are still subscribed to it
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<jackdaniel>
the problem is that there is no clear way to decide something (and, to enforce such decision)
<phoe>
yes, the problem of herding lispers
<jackdaniel>
all there is, is a proposal and people chipping in with their disagreements
<jackdaniel>
i.e no voting etc
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<jackdaniel>
no, it is not a problem of herding lispers but rather a problem of consensus
benjamin-l has joined #lisp
<benjamin-l>
is there a standard way to prompt for new values in interactive restarts?
<jackdaniel>
you would not be able to make C implementers agree on some feature either
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<phoe>
benjamin-l: nope, each restart function does it on its own; you can perhaps achieve some programmability by programming your own Gray stream and binding it to *query-io*
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<phoe>
jackdaniel: X3J13 achieved that by voting on issues, but X3J13 happened because there was money on the table
karlosz has joined #lisp
SAL9000 has joined #lisp
karlosz has quit [Remote host closed the connection]
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<phoe>
and while I think it's possible to achieve the same with 100% volunteer effort, the existing ossification of our ecosystem acts very well against that effort
<Shinmera>
more importantly it happened because the parties wanted to come together and make a common language.
<phoe>
^
<jackdaniel>
having stakeholders in a room and voting is the way to go, money is only means to make them sit in the room
karlosz has joined #lisp
karlosz has quit [Remote host closed the connection]
<phoe>
Shinmera: that's a pretty damn important point
<phoe>
plus, with all the portability libraries there's no incentive to sit down and make a common language
<Shinmera>
most implementors and most users are happy enough with the current situation.
<phoe>
why care if there's UIOP:QUIT
* jackdaniel
diplomaticly doesn't speak about his opinion on uiop
orivej has quit [Ping timeout: 260 seconds]
<jackdaniel>
diplomatically*
orivej has joined #lisp
<phoe>
jackdaniel: I am already aware of your opinion, yes ;)
<MichaelRaskin>
So we need to make a portability library universally hated by implementors to create an incentive for consensus?
<phoe>
MichaelRaskin: we've succeeded though
<phoe>
look at ASDF
<MichaelRaskin>
Well, apparently not enough
<phoe>
nimion: memo for rpg: can you do something about this situation?
Bourne has quit [Read error: Connection reset by peer]
lcn has joined #lisp
<phoe>
;; yes, the misspelling is intentional, please don't fix it
<_death>
it happened because DARPA had an interest in a Common Lisp, but I think today long-term survivability of codebases is no longer a goal for many organizations.. indeed its negation now seems to be the goal
<phoe>
nowadays you have Lisp codebases that survive because they depend on portability libraries or implementation-provided packages
<phoe>
no matter what you do, you are going to break those by implementing a hypothetical COMMON-LISP.SOCKETS package
libertyprime has joined #lisp
<phoe>
even if the breakage is as small as to be fixed by s/usocket/common-lisp.sockets/g
<phoe>
...unless usocket is then going to switch to common-lisp.sockets instead, which is the saddest scenario I can possibly think of
<phoe>
and the worst thing is that it is realistic
<phoe>
once I finish this book, I'll dig the UltraSpec out of its grave so we have a modern language specification that follows the original text 1:1
<phoe>
so then it can be forked and have its implementor-oriented content turned into actually user-useful language docs for Common Lisp.
<_death>
to me it seems a bit crazy to embed asdf and uiop in implementations.. without a spec every bit of accidental design becomes enshrined.. without discussion every eccentricism of the authors becomes everyone's burden
<phoe>
^
<phoe>
but, hey, modern Common Lisp development isn't driven by implementations
<phoe>
it isn't driven by libraries either
<phoe>
it's kind of driven by ASDF that connects *everything* together
<phoe>
so, on one hand, it makes sense to deploy it with implementations
<_death>
therefore, in my opinion code should only use asdf/uiop at the edges, and use it minimally
<phoe>
_death: which code?
Bike has joined #lisp
<_death>
all code
pjb has quit [Ping timeout: 272 seconds]
<_death>
phoe: it does not make sense to deploy the asdf code base in implementation
<_death>
*implementations
<phoe>
on one way, we are talking about code that is defined in ASDF:DEFSYSTEM forms, compiled by it, loaded by it, and having its test suites hooked up to it
<phoe>
and likely also uses some UIOP utility functions 'cause they are there
frgo has quit [Remote host closed the connection]
<_death>
phoe: it's like having a single FORMAT codebase shared by all implementations
<_death>
but without the spec :)
frgo has joined #lisp
<phoe>
_death: the first part sounded a bit like SICL
<_death>
phoe: SICL is its own implementation of a spec
<phoe>
yes
<phoe>
if I understand this post correctly, then, in a way, Common Lisp has become a single-implementation language
<phoe>
it's just the Lisp impls and libraries that are plugins of it
<_death>
Common Lisp is a language described in a specification.. it has many implementations
<phoe>
_death: that's not the point I wanted to make
<_death>
in the same way, a defsystem facility could have a specification, and each CL implementation could have its own implementation of that spec
<phoe>
one way of twisting this whole point of view is stating that ASDF is a language unto its own, it's just the Lisp implementations that are compiler plugins for it
<_death>
but the situation today makes this possible world unlikely
<Bike>
just gotta wait until annoyance at with-upgradability hits critical mass
<minion>
Bike, memo from phoe: when we talked some time ago you mentioned that a large part of the condition system depends upon parsing types at runtime; is it really parsing, or just typechecking? or is typechecking meant to involve parsing due to how type specifiers work?
<_death>
Bike: one result is that uiop:with-upgradability is here to stay, even if the internal asdf/uiop code is cleansed of it
<phoe>
Bike: sadly, luis has recently pushed a commit that relieves the annoyance somewhat, and has therefore set us back with the annoyance levels by several months at least
<Bike>
*break-on-signals* pretty much means parsing a type specifier for every call to SIGNAL
Ven`` has quit [Read error: Connection reset by peer]
<Bike>
though you can special case it with simple values like NIL i guess
<phoe>
Bike: oh! that's a good case, yes, for when it's non-NIL
<phoe>
otherwise it's just a (unless *break-on-signals* ...) which is cheap
<Bike>
lately i've realized you can pre convert the actual handler specification types to predicates, though. sbcl does
<Bike>
it gets kind of weird with redefining types, but what doesn't
<luis>
phoe: so sorry. I'm all for getting rid of ASDF upgrading altogether. I don't understand why it's necessary. Seems to be a massive complication.
<phoe>
luis: I forgot to mark my post with /s, apologies for that
matijja has quit [Ping timeout: 256 seconds]
<luis>
phoe: likewise!
<phoe>
:D
<luis>
phoe: I mean, I understood you were being sarcastic, but indeed we should get rid of asdf/upgrade. What's it for anyway?
<phoe>
there are two cases for upgrading ASDF that I am aware of
<phoe>
1) allowing long-running images to seamlessly load new versions of ASDF
toorevitimirp has quit [Ping timeout: 258 seconds]
* luis
shrugs
<phoe>
nowadays, who has long-running images though?...
<_death>
any server?
<Bike>
well i don't think that's unreasonable
toorevitimirp has joined #lisp
<Bike>
asdf attempting to load a newer version of itself any time you perform an operation, or however that works... less sold on that
<phoe>
_death: with reproducibility being the new default, people usually prefer to scrap their images and start them anew, *especially* during upgrades
hsaziz has joined #lisp
<_death>
phoe: this is a good rule for a certain scale of server
hsaziz has quit [Client Quit]
<_death>
what is good for google is not necessarily good for M&P
<phoe>
still, I agree - hot code loading is an important thing for these use cases
<phoe>
the other case is
<phoe>
2) solving the problem that ASDF created itself by bundling itself by default with each and every single Lisp image
matijja has joined #lisp
<phoe>
so it first loads ASDF 2.26, even implicitly, and then it needs to upgrade itself to ASDF 3.3.4
<_death>
asdf did not create this problem :).. the implementors did
<phoe>
_death: correct, together with implementors
<jeosol>
phoe: how long is "long-running images"?
<phoe>
jeosol: weeks, months, years I guess
<_death>
but how often do you really need to upgrade asdf
<phoe>
long enough to get new stable ASDF versions
<phoe>
no new ASDF version = no problem
<_death>
it seems to me that upgrading asdf becomes important only if it keeps creeping features
<jeosol>
I thought you were referring to run time for a session
Bourne has joined #lisp
<phoe>
jeosol: a session? what do you mean?
<phoe>
I refer to the time between when the Lisp process is started and when it is killed
<jeosol>
pardon my terminology, emacs+slime+sbcl
<jeosol>
Oh I see.
<phoe>
that's a development scenario though
<phoe>
in production, you usually deploy a Lisp image and optionally leave a swank server running on it
<jeosol>
My run time for cases can be up to weeks. I have had a case that ran for 6 weeks.
<phoe>
and then you conect it via a networked slime session; disconnecting that session does not kill the running Lisp image
<jeosol>
And it's only because I don't have powerful computing machines.
<phoe>
also, that too
<jeosol>
I am not running some kind of production for website or anything. It's just one time run, etc.
karlosz has joined #lisp
<_death>
there should be a lisp-implementation-uptime function :)
<jeosol>
The image I linked a few weeks back, I'd like to run, but can't manage the computation. Hence my trying to profile my code other day to figure out inefficient parts
<_death>
(well, better named..)
<phoe>
_death: get-internal-run-time?
<luis>
phoe: doesn't ASDF 3.x or whatever pride itself in being available with every major lisp implementation? Why does it need to be upgraded?
dddddd has joined #lisp
<phoe>
luis: 3.x isn't a single version of ASDF
<phoe>
what about 3.3.3.3 to 3.3.3.4
<phoe>
or 3.3.3.4 to 3.3.4
<_death>
phoe: on sbcl at least ;)
<_death>
so my lisp image on a personal server is 112 days old
<luis>
phoe: rebuild? delete-package :asdf? I dunno, this seems like a lousy trade-off. But, then again, I've never upgraded ASDF, I don't think. (Maybe I did and didn't notice because it's so seamless.)
<luis>
_death: how many times did you upgrade ASDF over that period?
<_death>
luis: :)
<phoe>
luis: the issue is that you want to preserve the identity of old systems and such, so (asdf:find-system :alexandria) stays the same before and after the upgrade
<phoe>
you can't easily do that if you perform a table flip and send the old ASDF package into the garbage collector
<_death>
luis: I guess developers of asdf tend to upgrade their asdf a lot
<phoe>
naturally, as expected of them
<phoe>
I mean, that's what I'd do if I was developing a system of that scale
<_death>
personally I don't mind the feature.. just its implementation'
<luis>
phoe: do I? I don't think I'd mind loading a fresh Lisp image and nuking the old ASDF.
<phoe>
luis: neither would I
<luis>
Anyway, the upgrade mechanism and tests involved seem like a HUGE barrier to ASDF hacking.
orivej has quit [Quit: No Ping reply in 180 seconds.]
<phoe>
that's the big point, restarting Lisp images is cheap and one usually does not want state that is only stored in a single Lisp image that can get nuked by a power outage, a kernel crash, or a software bug in Lisp code.
<phoe>
again, there's the point that _death mentioned about the size of an organization and such
orivej has joined #lisp
<phoe>
but I think that even the smallest players can work with the idea of "code as if your Lisp image could die at any moment, because it will do that for sure and it will do that sooner rather than later"
lcn has quit [Ping timeout: 245 seconds]
<phoe>
which, to me, means that the version of ASDF that I load at some point of a Lisp image can stay constant throughout the whole lifetime of that image
<_death>
in a specification this desideratum could be stated in a single sentence and there would be no need to get into the details of its implementation
<phoe>
yep
<jdz>
Another question is whether people load updated code in the long-running Lisp image using ASDF.
<_death>
I do
<jdz>
If ASDF supports code updating, but the code itself does not, then what's the point?
<phoe>
(alexandria:with-upgradability ...)
<_death>
that's why it's long-running.. otherwise I would have to restart every week or two
<jdz>
_death: So your code has support instance versioning and stuff, right?
<jdz>
*has support for
<ebrasca>
I like to never need to turn off my os (Mezzano) just for some update.
pjb has joined #lisp
<_death>
jdz: not explicitly.. the default CLOS redefinition rules usually work well enough.. I don't remember if I needed to define methods relevant to redefinition, but it's possible.. and this system is just not that large
<phoe>
Mezzano is another case that I thought of - an OS-wide Lisp image
<jdz>
_death: Also thanks for the flashback to 2000 link.
<phoe>
but then you need to go into the complexity that is required of an actual operating system - package versioning, rollbacks, dependencies, all that stuff that Windows Update and unix package managers have to deal with
<phoe>
and suddenly it *does* become complex out of necessity
shka_ has quit [Ping timeout: 256 seconds]
<jdz>
And suddenly microkernels and Erlang (OTP really) start making sense.
<phoe>
and first-class global environments
monokrom has joined #lisp
<phoe>
...how did this discussion (d)evolve from runtime requirements of the condition system into mentioning Windows Update
<jdz>
phoe: Just scroll up!
<aeth>
because how will Windows Update handle shipping ASDF in the future?
sdumi has quit [Read error: Connection reset by peer]
<phoe>
jdz: yes
<phoe>
aeth: no
sdumi has joined #lisp
<_death>
other long running images could be systems like those described in the gbbopen use cases btw
<_death>
I recently also did minimal work to get some of Copycat (an old AI system by Douglas Hofstadter) to run on sbcl.. it also used a blackboard architecture
<benjamin-l>
how should I approach debugging a memory fault with FFI stuff?
<benjamin-l>
I get the "unhandled memory fault at ..." condition, but I'm not sure how to get something gdb-like to figure out what's actually happening
pjb has quit [Ping timeout: 272 seconds]
orivej has quit [Ping timeout: 264 seconds]
orivej_ has joined #lisp
<phoe>
benjamin-l: what's the stacktrace?
<Shinmera>
standard debugging techniques. thank hard, reduce the test case.
<Shinmera>
*think
<benjamin-l>
my code, and then "bogus stack frame"
<phoe>
benjamin-l: is your code online somewhere?
<benjamin-l>
no, I could put it online if you want to look at it
<phoe>
sure; if possible try to minimize the test case
<benjamin-l>
I'm using a relatively uncommon C library (dav1d), so dealing with that might be annoying if it's not in your distro's package manager yet
libertyprime has quit [Remote host closed the connection]
<phoe>
welp
<phoe>
if its sources available online, then I guess we'll manage
<benjamin-l>
and yeah, this is currently about as minimal as I can get it, but it's still several hundred lines of code
<selwyn>
sometimes the address can give a clue, particularly if it's a special address like 0xFFFFFFFF or 0x0, or a very low address like 0x3
<benjamin-l>
mostly because of all the FFI struct definitions
Jesin has quit [Ping timeout: 246 seconds]
scymtym_ has quit [Remote host closed the connection]
<phoe>
why do you first close the context and then operate on stuff
<phoe>
this doesn't seem right, and I don't know the C codebase at all
<phoe>
oh wait, this is some custom unwind-protect variant...
<benjamin-l>
I have a macro unwind-protect* that's effectively just backwards unwind-protect
<benjamin-l>
sorry about that
<benjamin-l>
the address I'm getting is 0x3e8000003f8
<benjamin-l>
is attaching gdb to sbcl a thing you can do reasonably?
<benjamin-l>
from the dav1d-send-data call
<phoe>
I think so, yes; just expect to get a bunch of SIGSEGV along the way because that is what its garbage collector uses
<phoe>
you can continue normally from those though
<benjamin-l>
oh, weird
<phoe>
also, I'd compile all of that code with high debug and single-step through it
<benjamin-l>
I think there's a good chance the issue here is just that I don't understand the C library correctly
<phoe>
either that, or do printf-style debugging to isolate the actual point where the fault happens
<flip214>
3f8 and 3e8 are the ISA I/O ports of the serial ports 1 and 3... but I guess there's no relation to them here. OTOH, these look like two times 0x400 in 32bit minus one and minus three 64bit words.
<benjamin-l>
okay, I'm pretty sure the fault happens on the dav1d-send-data call
<benjamin-l>
I'm gonna go check through the C docs and examples very carefully to see if I've missed something
stentroad67 has joined #lisp
stentroad67 has quit [Remote host closed the connection]
pjb has joined #lisp
emys has joined #lisp
fanta1 has quit [Quit: fanta1]
stentroad has joined #lisp
EvW1 has joined #lisp
holycow has quit [Quit: Lost terminal]
<froggey>
that looks like a pair of single-floats that got mangled together. 0x3f800000 is 1.0 iirc, 0x3e800000 might be 0.5
<phoe>
froggey: or it could be 0x000003e8000003f8
<phoe>
because that is what 0x3e8000003f8 is
<phoe>
if we assume a 64-bit word, that is
<froggey>
they may have been 0x3f800000 0x3e800000 in memory, and the address that the value was originally read from was offset enough (due to type tags, for example) to combine them
<phoe>
okay, I see
<phoe>
still, weird that it would snap a byte in half and shift 0x80 into a 0x8
<jackdaniel>
windows updates, pointer arithmetic/guesswork, fun day isn't it? ,)
<phoe>
the only thing missing is McCLIM on linux terminal
<froggey>
ah, hmm. shifting by half a byte seems unlikely. I misread the zeros
<jackdaniel>
phoe: if you say, that lisp-related discussion is missing, then you are right
<phoe>
yes
<phoe>
...but then, come on, we've had a lot of ASDF-related discussion today
<phoe>
and that *was* lisp-related
* jackdaniel
does not negate that
pjb has quit [Ping timeout: 252 seconds]
karlosz has quit [Quit: karlosz]
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 246 seconds]
Lord_of_Life_ is now known as Lord_of_Life
renzhi has joined #lisp
holycow has joined #lisp
bitmapper has joined #lisp
EvW1 has quit [Ping timeout: 244 seconds]
cosimone has joined #lisp
benjamin1 has joined #lisp
<Cymew>
Coming a bit late to the party, I can interject that the major reason (as far as I understand) ASDF has that unwieldly updating code, is that the difference between v2 and v3 was huge, and needed some special care on implementations were v2 was bundled.
<Cymew>
If you know better, please correct me.
<Cymew>
But, then maybe it can be let go at some time.
pjb has joined #lisp
<jeosol>
Has anyone had code that was supposedly working correctly, then you found some bugs, corrected it, and now the supposedly corrected code is not working as expected. hmmm. I need to get some sleep.
<phoe>
jeosol: yes, it's called programming
<phoe>
99 little bugs in the code; fix one up, pass it around, 127 little bugs in the code
<_death>
that's why we picked up the term "snafu"
<luis>
jeosol: I sometimes do the "oh, btw, let me just refactor this little bit" and then that refactoring introduces 1 or 2 hard-to-debug bugs. Such a rookie mistake. :)
benjamin1 has joined #lisp
<jeosol>
phoe: lack of slot naming discipline caused these issues. Code was supposedly working many months ago, I decided to start using better variable names,inadvertently introduced a name for to replace a slot, but never updated it the rest of the files (5 other files).
<jeosol>
luis: exactly, it was refactoring and naming variables that messed me up.
<jeosol>
I just found I had two slots with different accessors (old and new), the old one being used in the many other files to represent the same idea.
<jeosol>
prematuring refactoring ....
<jeosol>
*premature
<jeosol>
Been up all night. It's now diminishing returns. I'll report when I fix the error later.
orivej_ has joined #lisp
<jeosol>
Have a nice day guys
<jeosol>
_death: yes, definitely snafu.
samlamamma has joined #lisp
benjamin1 has quit [Ping timeout: 252 seconds]
<samlamamma>
Has the ELS2020 videos been deleted from Twitch? I can only find 30 second clips now.
<jackdaniel>
I confirm, I can see only 30s videos there
<Josh_2>
Same
<phoe>
Shinmera: I think that it's time to revive the idea of submitting the talk videos to YouTube
<Josh_2>
^ might be worth just making an ELS2020 YouTube channel and uploading them
emys has joined #lisp
<jackdaniel>
unpopular opinion: please seed them as torrents so people are not forced to buy into googlegarden
<Josh_2>
could do that as well
<Shinmera>
they have been uploaded, just haven't had the time to enter the metadata
<Shinmera>
nor time to splice the chat into the full recordings
<phoe>
jackdaniel: or peertube
<Josh_2>
or LBRY
<jackdaniel>
ora ora ora (;
<samlamamma>
Shinmera:Are they private or unlisted?
<samlamamma>
(aka: can I have a link?)
doesthiswork has joined #lisp
<Shinmera>
they are 'draft'
<Shinmera>
so no
fanta1 has joined #lisp
Jesin has joined #lisp
shangul has joined #lisp
emys has quit [Ping timeout: 265 seconds]
emys has joined #lisp
scymtym has joined #lisp
frgo_ has joined #lisp
shangul has quit [Ping timeout: 256 seconds]
emys has quit [Ping timeout: 256 seconds]
shangul has joined #lisp
emys has joined #lisp
shifty has joined #lisp
theseb has joined #lisp
pjb has joined #lisp
jw4 has joined #lisp
emys has quit [Ping timeout: 260 seconds]
emys has joined #lisp
t3hyoshi has left #lisp ["WeeChat 2.8"]
fanta1 has quit [Quit: fanta1]
emys has quit [Ping timeout: 258 seconds]
<bitmapper>
Bike: is clasp normally this slow at compiling?
<Bike>
pretty much
<bitmapper>
sounds fun
<bitmapper>
what's causing that?
<bitmapper>
(if it's known)
<Bike>
we work to improve it, but llvm is not built for speed
<Bike>
we also cons a lot on the lisp level. there's no particular bottleneck
<bitmapper>
yeah i get that, i was just wondering if llvm was where the issue was
<samlamamma>
Bike:Will we see a new official release of Clasp soon :)?
aindilis has joined #lisp
<Bike>
that's up to drmeister. he's been buried in capitalism for a few weeks but he's coming out of it now.
emys has joined #lisp
pjb has quit [Ping timeout: 244 seconds]
ahungry has joined #lisp
emys has quit [Ping timeout: 256 seconds]
marcoxa has joined #lisp
emys has joined #lisp
cosimone has joined #lisp
<theseb>
Bike: Thanks a million for all your help yesterday on evaluation model. .. i spent more hours on it and completely understand now...i also paypal'ed phoe funds for some extra help he gave ;)
cg505 has joined #lisp
<phoe>
yay, I am making bread on Lisp now
rippa has joined #lisp
<flip214>
phoe: *baking
<phoe>
flip214: (bake-instance 'bread)
mason has joined #lisp
gko has joined #lisp
* edgar-rft
always thought the Common Lisp reader is using CAPITALISM by default
<phoe>
a capitalisp reader, performs upcapitalizing by default
pjb has joined #lisp
emys has quit [Ping timeout: 265 seconds]
emys has joined #lisp
rgherdt has joined #lisp
emys has quit [Ping timeout: 264 seconds]
_paul0 has joined #lisp
emys has joined #lisp
jperoutek has joined #lisp
shka_ has joined #lisp
emys has quit [Ping timeout: 246 seconds]
rogersm has joined #lisp
Jesin has quit [Ping timeout: 272 seconds]
<benjamin-l>
update on the FFI memory faults from earlier: after literally hours of poking at this with gdb and scrutinizing the dav1d source code, I realized that I got one of the argument types wrong for one of the C functions
<benjamin-l>
I was passing &context, when I should have just been passing context
<benjamin-l>
boy do I feel stupid now
<benjamin-l>
thanks for the help/advice earlier though
<benjamin-l>
this would have been a much longer process without that
orivej_ has quit [Ping timeout: 265 seconds]
<phoe>
<3
<phoe>
glad that we were of help
orivej has joined #lisp
<samlamamma>
benjamin-l:Reminds me of when I was trying to figure out why my C program was segfaulting and I had forgot to write a return statement in one of the functions
EvW has joined #lisp
<phoe>
thankfully lisp has no problem with returns, since they're implicit
<phoe>
and therefore, in the worst case, your function will return a meaningless value
<Bike>
your c compiler didn't warn you that control reached the end of a non void function?
<Bike>
or i guess it could just be that it continued into the rest of the function nonsensically, which is also possible in lisp
<samlamamma>
Bike:No, but I hadn't used any -W options!
<Bike>
oh. i kind of compulsively -Wall
<samlamamma>
Yeah, I was writing a small compiler which emitted C code. I typically never write any C.
<samlamamma>
So I'm not used to what you're supposed to do, etc.
<Bike>
mm.
<pjb>
-Wall -Werror
gaqwas has joined #lisp
<jasom>
So; I would like to test some code with a different value of *features*. In the interest of not reinventing the wheel, any suggestions?
<pjb>
jasom: to be super precise, it would be better to fork a new image. Because even with forcing reloading, there can be side effects left from previous loads.
<jasom>
pjb: well I'm the author of the system, so I don't have to worry about that.
<jasom>
or rather I control that
<jasom>
And fork is surprisingly poorly supported on most lisps
<pjb>
jasom: I use files named generate-<something>.lisp that contains a script setting up the *features*, erasing ~/.cache/common-lisp/ and quickloading the stuff before saving executable image, that I call from makefiles, with various targets, for different sets of features.
stentroad has joined #lisp
<jasom>
pjb: right, I was considering doing something like that
<_death>
the next Scheme standard should (sublis '((eval . yin) (apply . yang)) scheme)
<phoe>
that's called mutual recursion
<phoe>
yep
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
<_death>
bad wikipedia page is bad
<pjb>
theseb: (defun .evenp (n) (if (zerop n) t (not (.oddp (- n 1))))) (defun .oddp (n) (if (zerop n) nil (not (.evenp (- n 1))))) (.evenp 10) #| --> t |# (.evenp 11) #| --> t |#
<pjb>
theseb: note the tests!
<pjb>
theseb: also, note that those functions don't work on negative or non integer numbers.
<theseb>
i'm studying
_Posterdati_ has joined #lisp
<theseb>
pjb: your example keeps calling .evenp and .oddp with different arguments that eventually trend towards 0 to finish the loop
rogersm has quit [Ping timeout: 240 seconds]
refpga has joined #lisp
lavaflow has joined #lisp
rogersm has joined #lisp
<Bike>
it's not really different. and as death alluded to, sicp pretty much covers this
<Bike>
like, what did you expect? it would somehow bottom out even though there's no base case, because now there are two functions?
rogersm has quit [Quit: Leaving...]
orivej has joined #lisp
orivej_ has quit [Read error: Connection reset by peer]
<pjb>
theseb: that's the secret of recursive functions: never call them with the same arguments.
<pjb>
theseb: and eventually, don't call them at all.
marcoxa has quit [Quit: dinner time!]
<yottabyte>
how do I insert spaces into a uri for drakma? for example "curl --location --request GET 'https://postman-echo.com/get?foo1=hi%20hi';" reads the query paramter foo1 as "hi hi" but if you run the same request through drakma, it'll read "hi%20hi"
<yottabyte>
parameter*
<_death>
pjb: you can call them with the same arguments, if you memoize ;)
<theseb>
Bike: for extremely complex mutual recursion..i think the generic advice I was looking for, as was said, is just to carefully analyze all pathways and add checks/escape hatches for each infinite loop case as they are observed..
<theseb>
Anything thing better than that would probably violate the Halting Theorem or some such
sdumi has quit [Ping timeout: 246 seconds]
sdumi has joined #lisp
<Josh_2>
The little schemer is a good book on recursion
zooey has joined #lisp
borodust has joined #lisp
<drmeister>
Is this a valid logical pathname? #P"amber:dat;leap;cmd;oldff;leaprc.ff14SB.redq"
<drmeister>
The name of the file should be "leaprc.ff14SB" - I get that the period could cause problems. It is causing problems in clasp.
<phoe>
AFAIK a single period doesn't cause problems
<phoe>
but multiple periods do, and you have multiple of these here
gxt has joined #lisp
cracauer has joined #lisp
Jesin has joined #lisp
jperoutek has quit [Remote host closed the connection]
orivej has quit [Quit: No Ping reply in 180 seconds.]
zulu-inuoe has joined #lisp
orivej has joined #lisp
shangul has quit [Ping timeout: 240 seconds]
FishByte has joined #lisp
orivej_ has joined #lisp
orivej has quit [Ping timeout: 260 seconds]
narimiran has joined #lisp
frgo_ has quit []
<drmeister>
Thank you.
<phoe>
but this works on SBCL, hm
<phoe>
...that is because it gets interpreted as a physical pathname
<phoe>
sigh
gaqwas has quit [Read error: Connection reset by peer]
gaqwas has joined #lisp
gaqwas has quit [Changing host]
gaqwas has joined #lisp
orivej_ has quit [Ping timeout: 258 seconds]
orivej has joined #lisp
bitmapper has joined #lisp
_Posterdati_ has quit [Ping timeout: 258 seconds]
ayuce has joined #lisp
cosimone has quit [Quit: Terminated!]
jw4 has quit [Ping timeout: 260 seconds]
EvW has quit [Ping timeout: 260 seconds]
jw4 has joined #lisp
EvW has joined #lisp
_Posterdati_ has joined #lisp
jw4 has quit [Ping timeout: 256 seconds]
jw4 has joined #lisp
rogersm has joined #lisp
rogersm has quit [Client Quit]
<emacsomancer>
what's the right way to do timers (in sbcl)?
<Josh_2>
take the time now, and then the time when done
<Josh_2>
and take one from the other
<emacsomancer>
timers in the sense of executing a function periodically
<emacsomancer>
when I try to schedule a timer that executes a fairly trivial function, everything becomes very slow, even with a long interval
<emacsomancer>
I'm sure I'm doing something wrong
<Josh_2>
Oh right, well perhaps you could have a background thread (or async) and a list of functions to be executed and at what time interval
<Josh_2>
idk
<Josh_2>
I think that's how I'd do it
<emacsomancer>
what's the right place to look for examples of background threads/async?
<Josh_2>
bordeaux-threads for actual threads and there are quite a lot of async libraries like cl-async etc
edgar-rft has joined #lisp
<emacsomancer>
thanks
<_death>
there is a library called portable-threads (split from gbbopen) that has support for scheduled and periodic functions
<phoe>
_death: are there any big issues that prevent these from being merged into BT instead?
_Posterdati_ has quit [Ping timeout: 272 seconds]
<Josh_2>
nice, this library has most of the atomics as well
shifty has quit [Ping timeout: 256 seconds]
frgo has joined #lisp
<_death>
phoe: portable threads is more featureful, but I think the scheduled functions module shouldn't be hard to port.. one issue with this library is that it uses the same system name as the one in gbbopen :/
<phoe>
does this mean package name conflicts?
<emacsomancer>
ah, I'll look at portable-threads then too
<_death>
you don't even get there because you can't load both systems ;)
<phoe>
_death: amazing
<_death>
we've solved the packages issue!
<_death>
I wonder if Xach had an issue with it when gbbopen was in quicklisp
_Posterdati_ has joined #lisp
pwoineg has joined #lisp
_Posterdati_ has quit [Client Quit]
Posterdati has joined #lisp
paul0 has joined #lisp
_paul0 has quit [Ping timeout: 272 seconds]
<_death>
Josh_2: it seems the atomics implementation needs a little love though..
<pwoineg>
Hi. I was thinking of implementing the Gemini protocol (simple Internet protocol similar to Gopher) in CL. Looking through the specification at https://gemini.circumlunar.space/docs/spec-spec.txt I see that TLS v1.2 or higher is required. Does anyone have any ideas of the best way to use TLS in CL? I found e.g. https://github.com/shrdlu68/cl-tls but it is experimental according to the author. Other than that I was thinking FFI could be
<pwoineg>
a possible approach.
<_death>
pwoineg: there's cl+ssl but if you're into it putting effort into cl-tls could have a lot of impact in my opinion
<phoe>
pwoineg: cl+ssl uses OpenSSL
<phoe>
but what _death said
<phoe>
also, once you have a repo for that, please ping me - I've been thinking of a similar thing myself
<pwoineg>
Ooh, thanks for the resources, didn't know of cl+ssl, will try to use that. Also I imagined this more as a "weekend project" so further implementing the TLS standard for cl-tls might be a bit ambitious for me at this point in time _death
<arpunk>
phoe: There is also a phlog generator in CL but I haven't tested it yet: git://bitreich.org/cl-yag
<phoe>
arpunk: I don't know what a phlog is
<arpunk>
gopher blogs, but cl-yag also supports gemini content generation
<arpunk>
iirc
<pwoineg>
arpunk: Do you know of any Gemini clients written in CL by any chance?
gxt has quit [Ping timeout: 240 seconds]
<Josh_2>
_death: the atomic operations in that library are not atomic at all... they are all using a lock
<Josh_2>
Is this what you meant?
wsinatra has joined #lisp
<Josh_2>
Although it does say "defined here unless imported from the CL implementation"
<Josh_2>
I don't think It's a good idea to label an operation as "atomic" when it is using a lock...
<_death>
Josh_2: yes, specialized implementation for sbcl & friends needs to be added
<Inline>
Josh_2: what do you mean ?
<Bike>
they're atomic enough not to be interrupted, which is probably the point. lock freedom is another level
<jackdaniel>
freeeeelock -- William Wallace
<arpunk>
pwoineg: No, but it would be nice to have!
<pwoineg>
arpunk: If I ever get around to it I will make sure to share :)
<Josh_2>
Because you can end up locking up your program (excuse the pun) because you have inadvertently used what you thought was a lockless threadsafe operation but in fact is using a lock
<_death>
Josh_2: how?
pjb has quit [Ping timeout: 256 seconds]
<pwoineg>
jackdaniel: Do you think ECL could be embedded into the Godot game engine (written in C++)?
<phoe>
pwoineg: I recall someone's been working on that
<ralt>
_death: signals
* phoe
searches the logs
<Bike>
usting "atomic" to not include lock freedom is not uncommon, i'm sayin
<_death>
ralt: explain
<jackdaniel>
pwoineg: sure, it is as possible as using any shared library written in C from a C++ application
<ralt>
but yeah, atomic means you can't end up in a half-half situation, which is unrelated to using locks or not, albeit it's confusing because of the atomic operations that have the same name
<ralt>
_death: if a signal handler is taking a lock, then gets preempted to run the same signal handler again, you're in a bad place
<ech>
arpunk: thanks for the information
<pwoineg>
jackdaniel: Saw that one on Reddit, pretty cool!
<Josh_2>
Well in the SBCL manual they have "Following atomic operations are particularly useful for implementing lockless algorithms." so I apologize for assuming atomic operations meant thread-safe lockfree
<Bike>
Josh_2: yeah, in sbcl they say "without interrupts" and such for just uninterruptable
<pwoineg>
phoe: Thanks for the link!
<Bike>
but like in databases they talk about "atomic transactions" which i imagine are often lock based
<Bike>
C++ provides an 'atomics' interface that looks the same whether or not the machine can do the operations lock-free
<_death>
ralt: you're right, but it's a best effort thing
<Josh_2>
Hmm, well my definition of an "atomic operation" has now changed Bike
<p_l>
Bike: any good database is going to minimize amount of locking
<Josh_2>
Thanks
<p_l>
so usually you have variations of log replay
<Bike>
i don't do databases, but i saw flock(2) mentioned on wikipedia and was like ok sure good example
<_death>
ralt: but sbcl's mutex locking does have without-interrupts
<scymtym>
_death: that only protects the system from getting messed up by interrupts, not the user code under the lock. for example, you can interrupt (sb-thread:with-mutex ((sb-thread:make-mutex)) (sleep 1000)) just fine
<Inline>
whoa
<Inline>
the german wiki about atomic operations regards it as a bunch of operations which are regarded as a logical unit
<Inline>
the english wiki does not do that
<_death>
scymtym: yes, but if the body is a single incf form with a simple place, do you have an issue?
<scymtym>
_death: how can INCF of a simple place ever be an issue?
<Bike>
floating point exception?
<_death>
scymtym: that's what I mean.. we're talking about the implementation of atomic-incf using a lock
<Bike>
or something weird with bignums, maybe
<scymtym>
i mean w.r.t interruption. maybe i'm missing something
<Inline>
doesn't suffice to use an atomic instruction if interrupts can still be invoked, btw any other state changing operation takes places on one of the other cores or is already on it's was on the bus
<Inline>
s/was/way/
<scymtym>
ok, missed that
<Inline>
so atomicity is atomics instruction + no_interrupts + no bus operations + no other thread on some other core doing something on the shared data
<Inline>
hewww
<Inline>
so locking was not even included in that list
<Inline>
and there's a distiction between normal process locks and hw lock on the data bus
<Inline>
so true atomics requires hw lock on the data bus too
shka_ has quit [Ping timeout: 264 seconds]
<jdz>
pwoineg: I already saw one Gemini implementation in CL.
<Inline>
so it doesn't suffice that some instruction itself is atomic on the hw side
<_death>
the x86 instruction for atomic increment is usually LOCK INC [x] (or cmpxchg ;)
<borodust>
pwoineg phoe: this godot wrapper is highly experimental: at the time, i was just wondering how much time it would take to wrap a godot header with claw and what problems there might be. Conclusion is that there are none and will take smth like 15 minutes, but i never properly battle-tested these bindings, so you can disregard this library.
<Inline>
unless normal process locking would also guarantee hw lock, but i suppose that would also force stuff for busy waiting ?
<ralt>
so, hm, I'm struggling with UNIX-OPTS
<ralt>
I want to have an option that can have a value or not
<pwoineg>
jdz: Thanks. This is the same server that was linked by arpunk earlier. I meant a "browser" when I said Gemini client I guess.
<Bike>
a while back i tried sketching out an atomics extension for lisp, but it needs work
<ralt>
like `--d` and `--d foo` are both valid
<Josh_2>
Bike: Shinmera has made a portable atomics library
<jdz>
pwoineg: OK, ignore me then, was just catching up on scrollback.
<Bike>
Josh_2: that is a portability library, not an extension
<Josh_2>
SBCL has lockless queues which is neat
<Bike>
i mean it has a table showing what's supported where
<pwoineg>
borodust: Thanks for the heads up. I was mostly curious about the possibility of using ECL in Godot in the future, just something I was thinking about the recent days
<pwoineg>
jdz: np!
<borodust>
pwoineg: it would be awesome indeed to have a such integration!
<Inline>
a bunch or sequence of hw wise atomic operations could be seen as atomic logical unit too ofc
<Inline>
hmmm
<Inline>
with all the rest still holding wrt multi core stuff ....
<borodust>
pwoineg: (rn i'm integrating Filament into CL though by introducing C++ autogenerate ffi though xD)
<Inline>
but i suppose that distinction is not very helpful
<Inline>
cause i can group many stuff and call it a logical unit....
<pwoineg>
borodust: madlad xD
<borodust>
pwoineg: everyone got to have some bit of insanity within ;p
<pwoineg>
Indeed. Will have more time for such this summer :D
karlosz has joined #lisp
<_death>
surprised there isn't a cl-docopt
karlosz has quit [Client Quit]
karlosz has joined #lisp
pjb has joined #lisp
narimiran has quit [Ping timeout: 256 seconds]
<_death>
well, there is a cl-docopt-hack apparently
pwoineg has quit [Quit: ERC (IRC client for Emacs 27.0.90)]
Jesin has quit [Quit: Leaving]
karlosz has quit [Client Quit]
vaporatorius has joined #lisp
vaporatorius has joined #lisp
vaporatorius has quit [Changing host]
karlosz has joined #lisp
afidegnum has joined #lisp
afidegnum has quit [Quit: leaving]
karlosz has quit [Client Quit]
karlosz has joined #lisp
holycow has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
orivej has quit [Ping timeout: 265 seconds]
orivej has joined #lisp
afidegnum has joined #lisp
<afidegnum>
is there a way to execute lisp application in vim ?
<afidegnum>
as well as interracting with vim buffer?
ark has joined #lisp
<Inline>
afaik there's a vim extension to use lisp
<phoe>
slimv or vlime
<Inline>
ah yes
karlosz has quit [Client Quit]
<Inline>
i suppose i knew the first one slimv at some time i tried to use it
karlosz has joined #lisp
<afidegnum>
ok, let me look into it
karlosz has quit [Client Quit]
karlosz has joined #lisp
karayan has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
pjb has quit [Remote host closed the connection]
pjb has joined #lisp
davsebamse has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
devon has joined #lisp
anticrisis has joined #lisp
<pjb>
<drmeister> It is not a valid logical pathname. But you could write: #P"AMBER:DAT;LEAP;CMD;OLDFF;LEAPRC-FF14SB.REDQ" and have a logical-pathname-translation that would translate this logical pathname to a physical pathnaem such as #P"/nfs/amber/dat/leap/cwd/oldff/leaprc.ff14sb.redq".
karlosz has quit [Read error: Connection reset by peer]
karlosz has joined #lisp
Jesin has joined #lisp
freixo has joined #lisp
ahungry has quit [Remote host closed the connection]
<drmeister>
pjb: I can set up a logical-pathname-translation that changes the name of a pathname? I didn't know that was possible.
<pjb>
drmeister: the source and destination can be entirely uncorelated.
terpri has joined #lisp
<p_l>
anyone tried to implement a constant-time GC for CL?
<drmeister>
pjb: Thanks - I'd forgotten all about that.
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
refpga has quit [Read error: Connection reset by peer]
karlosz has joined #lisp
davsebamse has quit [Ping timeout: 265 seconds]
orivej_ has joined #lisp
orivej has quit [Ping timeout: 272 seconds]
karlosz has quit [Client Quit]
karlosz has joined #lisp
davsebamse has joined #lisp
karlosz has quit [Client Quit]
<Shinmera>
p_l: clasp supports mps, which if I remember correctly can do that kind of thing.
karlosz has joined #lisp
<p_l>
Shinmera: oh, interesting, when I looked at MPS long in the past it didn't seem to include that
<Shinmera>
I thought it had the option to promise hard upper bounds for a collection cycle, which would be what you're looking for, no?
<p_l>
Shinmera: well, all I need is that I can run *predictable* timings
<p_l>
whether that means the collection is time-sliced or whatever is irrelevant so long as I can ensure that part of the code will run with guaranteed wall-clock time
<Shinmera>
Whatever the case I would appreciate more/better GCs for SBCL :)
karlosz has quit [Client Quit]
<p_l>
me too :)
karlosz has joined #lisp
<p_l>
just not the time for starting from scratch, and also some of the algorithms I'd like to employ have pretty wild requirements (like extra pointer for every object)
<Shinmera>
p_l: beach might be interested in a discussion with you
<White_Flame>
how many implementations have the GC itself implemented in lisp?
<p_l>
White_Flame: not many, I think
<White_Flame>
it probably would have overlap with SICL goals, if not already part of it I guess
<White_Flame>
but, I think GC experimentation would be more explorable if that were an option
<jackdaniel>
mezzano probably has a gc implemented in lisp
<Shinmera>
beach already has a pretty good plan for a gc.
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
<selwyn>
re clasp mps: iirc the realtime gc configuration for mps (which is i think another name for what you are talking about) was made under licence by ravenbrook for a customer so actually using it may be tricky
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
bhartrihari has joined #lisp
devrtz has joined #lisp
cosimone has joined #lisp
tessier has joined #lisp
tessier has quit [Changing host]
tessier has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
<cracauer>
nnnnnnnnn......ion for mps (which is i n
<cracauer>
think another name for what you are talkingion for mps (which is i
<cracauer>
oops. Catwalk
refpga has joined #lisp
rgherdt has quit [Ping timeout: 265 seconds]
<selwyn>
that cat has been listening to someone smart :)
refpga has quit [Remote host closed the connection]
refpga has joined #lisp
karlosz has quit [Client Quit]
karlosz has joined #lisp
<phoe>
worse, that cat has been doing garbage collection
<phoe>
that might result in e.g. automatically managed litter boxes, a big net profit for many cat owners
karlosz has quit [Client Quit]
karlosz has joined #lisp
<_death>
automatic meowmory management, now available in CatLisp with conses and CATs and CDTs (content of address/decrement temporaries)
dnm has left #lisp [#lisp]
dnm has joined #lisp
<aeth>
catlisp would be a great name for a lisp
<aeth>
don't waste the name
<_death>
includes the lost sbcl kitten of death
<p_l>
hmm, the algorithm used in latest Oracle JVM could be used well enough on SBCL, as it doesn't require adding extra pointers, just using high 4 bits as tags, iirc
<p_l>
hmm... probably not *high* 4 bits, not even 43-47, but I will have to check one day
wsinatra has quit [Quit: WeeChat 2.8]
<solrize>
p_l what you want is called a real-time gc and they exist, try a web search
<p_l>
solrize: I know. I was essentially asking if anyone had *started* (i.e. written any code) to implement one for one of lisp implementations
<solrize>
allergo claims to have one
<solrize>
lispworks, rather
<p_l>
Lispworks claims to have done one for some client too
<p_l>
but I'd prefer to see at least something akin to IBM Metronome in open source
<solrize>
hm web search doesn't immediately find anything
<theseb>
Does CL always catch 1. wrong numbers of args and 2. wrong argument types?
<theseb>
or do we ever see undefined behavior?
<White_Flame>
if you turn the safety declarations down/off it might not check them
<White_Flame>
but in default use, it should always check
<theseb>
White_Flame: but you don't specify types so how does CL know what the argument types should be?
<White_Flame>
the primitive operations check the types
<p_l>
theseb: if you declare (optimize (speed 3) (safety 0)) you might have *weeeeeeeeeird* effect
<White_Flame>
to see if they're compatible with the operation
<White_Flame>
as a runtime check
* p_l
got SBCL to overwrite bits of compiled function by mistake using that
<White_Flame>
CL compilers can elide those checks if they can reasonably prove, and/or trust the programmer's declarations, that the types will always be compatible
<solrize>
p_l i suspect it hasn't been done much because most people don't find it important. erlang's soft realtime gc is good enough for most interactive applications, and if something is truly realtime you can write it in C or something
<solrize>
i mean you'd run the small realtime bits in a separate task or even on a separate cpu
<solrize>
or these days with an fpga
<solrize>
while having the main complicated application in lisp with occasional tolerable gc delays
<p_l>
solrize: well, I can technically keep the network code in separate partition, but I'd prefer to not have to write it in C if you catch my drift
<solrize>
why does the network code have hard deadlines? networks are designed to tolerate delays
<theseb>
White_Flame: but in general, beyond the core, if you use the wrong types we can't always predict what will happen?
<aeth>
Depending on what you're doing, you can mostly avoid the GC in SBCL if you use large, preallocated arrays of some numeric type
<p_l>
solrize: because nowhere is it actually said that networks are designed to tolerate delays
<White_Flame>
theseb: if you use the wrong types, the system will throw errors
<White_Flame>
*signal errors
<p_l>
solrize: there are, in fact, networks with strict timing requirements
<White_Flame>
(throw them at hte user)
<theseb>
ah ok
<p_l>
solrize: where if you miss three frames somewhere an audible alarm starts blaring
<solrize>
p_l what network are you talking about?
<White_Flame>
theseb: the system should not corrupt itself unless you fiddle with the safety declarations and do something wrong
<solrize>
networks are usually asynchronous
<p_l>
solrize: profinet protocol (which runs on top of ethernet in various forms)
<p_l>
solrize: *usually* != *always*
<White_Flame>
theseb: also, dynamic-extent (basically stack allocation) can screw you over if you hold on to references after a function exits
<p_l>
solrize: also, in fact, major realtime GC implementations for Lisp happened for network hw
<solrize>
ethernet itself tolerates delays, that's why it has collision detection with exponential backoff
<p_l>
solrize: *nobody* uses collision detection ethernet unless they really, really have to
<p_l>
I haven't seen physical collision detection ethernet since 2008
<p_l>
and that involved an unauthorized device that was few years out of date
<solrize>
haha
<p_l>
solrize: in fact, gigabit ethernet no longer supports collision detection at all
<solrize>
what major realtime gc's for lisp are there? weren't we just saying there aren't any?
<solrize>
oh that's interesting about gbe
<p_l>
solrize: *were*
<p_l>
both were commercial
<p_l>
AFAIK one of them was the lispworks one
<solrize>
what major realtime gc's for lisp were there?
<p_l>
the other one was part of Symbolics Minima
<solrize>
lispworks hmm
<p_l>
at least with Lispworks you can turn up with a big fat wad of money and get it
<p_l>
it's just that I have non-functional requirement of open source
<solrize>
was chang's phd thesis about a lisp implementation? i don't remember. it was about parallel gc and i vaguely remember something about lis p in it
<p_l>
Minima is deader than pretty much everything, cause I don't think even US DoD has any of those left
<solrize>
realtime gc's have high enough performance cost that you are better off avoiding it if you can
<p_l>
(and it's publicly known that at least few years ago US DoD had still a bunch of Symbolics Lisp Machines in production use)
<solrize>
minima = small maxima?
<solrize>
maxima is still around in some form
<p_l>
solrize: funnily enough, realtime GCs are now getting steam in Java land because with large enough heap and low enough consing rate, they make GCs much better
<no-defun-allowed>
Minima is small Genera from memory.
<p_l>
solrize: Minima was alternative OS for some Symbolics Lisp Machines (instead of Genera)
<solrize>
oh neat
<solrize>
i think some people are running old cadr systems under emulation
<p_l>
CADR is easy to emulate, so getting it running is pretty fast thing
<p_l>
there is even FPGA reimplementation
<solrize>
yeah but what about getting the software together
<p_l>
solrize: CADR software is open source and available in working form, though not the last version - there's ongoing work to recover code from newer versions
akoana has joined #lisp
<solrize>
i've never used a lisp machine beyond playing a little. i'd like to give an emulator a try
<p_l>
this involves quite a bit of software archeology, as you need to have compatible microcode and OS
<solrize>
i mean is there a usable older version of cadr? like if you want a pdp-10 there are a few different emulators you can download and run easily
<solrize>
ah thanks
<solrize>
nice, how much work is it to get that running? and does it busy loop the host cpu or anything like that?
<solrize>
brb
<p_l>
unfortunately it's going to pretty much busy loop, I tried to fix that but it's really, really non-trivial. Getting it working to the point where you can do everything you could on basic CADR (read: just console, no serial ports, no networks, no random special hw) is very quick
<p_l>
network support can take a moment depending on OS
<p_l>
connecting to inter-chaos-net is a matter of human-to-human coordination
terpri has quit [Remote host closed the connection]
<aeth>
solrize: Plenty of things could benefit from a RTGC more than a traditional GC. e.g. games.
terpri has joined #lisp
<p_l>
hell, any interactive program
<p_l>
in terms of classic performance metrics of a GC it might not be superfast, but it's going to have better results than manual management when it comes to latency
cosimone has quit [Ping timeout: 252 seconds]
bhartrihari has left #lisp ["Disconnected: closed"]
bhartrihari has joined #lisp
<solrize>
no one will care if a video game misses a frame update once in a great while
<solrize>
the hard realtime stuff in a game will be on a gpu
aindilis has quit [Ping timeout: 256 seconds]
<p_l>
solrize: hahaha
<p_l>
nope
<p_l>
solrize: the hard realtime stuff is input handling and preparing the frame
<p_l>
especially without G-Sync/Freesync
<solrize>
the gpu does that
arduo has joined #lisp
<p_l>
solrize: no
<p_l>
the GPU does just the rendering
<p_l>
preparing the frame = preparing GPUs *input*