<markasoftware>
does that work with flet no-defun-allowed?
<markasoftware>
I thought it did not
<Shinmera>
no-defun-allowed: run tarjan's algorithm for topological sorsting?
<no-defun-allowed>
markasoftware: No, CL doesn't provide anything to inspect local environments.
<no-defun-allowed>
Shinmera: That was another suggestion. Guess I could do that.
oxum has quit [Remote host closed the connection]
oxum has joined #lisp
<markasoftware>
isn't (macro-function) sort of a way to inspect the local environment?
<markasoftware>
not in the way i want
<beach>
markasoftware: You can always handle the error.
buffergn0me has joined #lisp
rippa has joined #lisp
Arcaelyx has quit [Ping timeout: 258 seconds]
<phoe>
no-defun-allowed: I once wrote a cycle-detecting algorithm in Lisp. One second...
<phoe>
...well, maybe not, since it's ugly and slow as hell
<no-defun-allowed>
It could be possible to write a function that, given an object, finds that object in the object's references, and then another to find all the objects in a graph. Then I just check over every object with the first function.
shka_ has joined #lisp
Lycurgus has joined #lisp
<MichaelRaskin>
no-defun-allowed: yes, that has complexity number of objects times number of references
<MichaelRaskin>
But if you create nodes one by one without modification cycles it is impossible to create a cycle anyway
<no-defun-allowed>
Indeed.
<no-defun-allowed>
Oh, I interpreted "modification" as "cycle detection occurs when an object is modified", which isn't right.
buffergn0me has quit [Quit: ERC (IRC client for Emacs 26.2)]
jfb4_ has quit [Ping timeout: 258 seconds]
earl-ducaine has joined #lisp
t3rtius has joined #lisp
t3rtius has quit [Ping timeout: 260 seconds]
Lycurgus has joined #lisp
william1 has joined #lisp
earl-ducaine has quit [Ping timeout: 260 seconds]
Lycurgus has quit [Quit: Exeunt]
ggole has joined #lisp
t3rtius has joined #lisp
t3rtius has quit [Client Quit]
kajo has quit [Ping timeout: 252 seconds]
kajo has joined #lisp
amerlyq has joined #lisp
space_otter has quit [Remote host closed the connection]
william1 has quit [Ping timeout: 265 seconds]
_paul0 has quit [Remote host closed the connection]
_paul0 has joined #lisp
hsaziz has quit [Ping timeout: 240 seconds]
dddddd has joined #lisp
karlosz has quit [Quit: karlosz]
vidak` has quit [Quit: going shopping]
libertyprime has quit [Remote host closed the connection]
basketha1 has quit [Remote host closed the connection]
jonatack has quit [Ping timeout: 260 seconds]
cosimone has joined #lisp
madrik has joined #lisp
hsaziz has joined #lisp
decent-username has quit [Ping timeout: 252 seconds]
jayspeer has joined #lisp
Lycurgus has joined #lisp
jonatack has joined #lisp
cosimone has quit [Remote host closed the connection]
cosimone has joined #lisp
Lycurgus has quit [Quit: Exeunt]
pilne has quit [Quit: For Sale: Parachute. Only used once, never opened, small stain.]
atgreen_ has joined #lisp
atgreen_ has quit [Remote host closed the connection]
atgreen_ has joined #lisp
uint has joined #lisp
dale has quit [Quit: My computer has gone to sleep]
_whitelogger has joined #lisp
Guest73624 has joined #lisp
earl-ducaine has joined #lisp
luna_is_here has joined #lisp
decent-username has joined #lisp
william1 has joined #lisp
quantumbird has joined #lisp
quantumbird has quit [Client Quit]
kajo has quit [Ping timeout: 260 seconds]
kajo has joined #lisp
william1 has quit [Ping timeout: 260 seconds]
vidak`` has joined #lisp
vidak`` has quit [Client Quit]
vidak has joined #lisp
earl-ducaine has quit [Ping timeout: 260 seconds]
bacterio has quit [Read error: Connection reset by peer]
jayspeer has quit [Quit: X crashed damn it]
jonatack has quit [Quit: jonatack]
earl-ducaine has joined #lisp
cosimone has quit [Quit: Terminated!]
cosimone has joined #lisp
raghavgururajan has joined #lisp
earl-ducaine has quit [Ping timeout: 268 seconds]
stux|RC has quit [Ping timeout: 245 seconds]
jayspeer has joined #lisp
cosimone has quit [Quit: Quit.]
earl-ducaine has joined #lisp
stux|RC has joined #lisp
shifty has quit [Ping timeout: 258 seconds]
random-nick has joined #lisp
shifty has joined #lisp
hdasch has quit [Ping timeout: 268 seconds]
jmercouris has joined #lisp
count3rmeasure has joined #lisp
<jmercouris>
hello, I'm having a bit of an issue with generating a string
<jmercouris>
I am using parenscript which automatically handles strings in some way
<jmercouris>
What I'm trying to do is produce the following javascript: var z = document.querySelector("[next-identifier='J']");
<jmercouris>
not a very complex statement
<jmercouris>
I am doing this: (ps:ps (ps:chain document (query-selector (ps:lisp (format nil "[next-identifier=\"~a\"]" "J")))))
<jmercouris>
which unfortunately produces this: "document.querySelector('[next-identifier=\\\"J\\\"]');"
<jmercouris>
some sort of triply escaped quote
<jmercouris>
I guess something is trying to escape the quotes I already escaped?
hhdave has joined #lisp
smokeink has quit [Ping timeout: 260 seconds]
<jackdaniel>
did you try to print it with princ?
<jmercouris>
jackdaniel: the result of format, or what specifically?
<jmercouris>
the whole parenscript statement?
<jmercouris>
so the whole statement princ'd looks like: document.querySelector('[next-identifier=\"J\"]');
<jackdaniel>
is this correct?
<jmercouris>
this is incorrect
<jmercouris>
I want it to look like this: document.querySelector('[next-identifier="J"]');
<jackdaniel>
what is a difference in javascript between '' pair and "" pair?
<jackdaniel>
(also, do you know how strings are printed in Common Lisp?; speaking of escaping #\")
<jmercouris>
apparently they are the same thing
<jmercouris>
I'm only familiar with the printer on a most cursory level
<jackdaniel>
how they are printed *readably* that is
<jmercouris>
Yes, I know a very small amount about that
<jmercouris>
I knew what you meant
<jmercouris>
now, I WOULD just change the type of quotes I'm using to swap single and double
<jmercouris>
but parenscript will not let me do that
<jackdaniel>
to be capable to read back string by a reader, it is enclosed with a pair of #\", any #\" inside is escaped to avoid ambiguity
<jmercouris>
it automatically encapsulates all strings in single quotes
<jackdaniel>
princ prints the string aesthetically, basically what a ~A directive does in format
<jackdaniel>
regarding the order questions (i.e that you don't like the order of quotes) it is irrelevant from correctnes, I suppose that there is some variable controlling that in postscript internals
<jackdaniel>
correctness point of view°
<jmercouris>
postscript?
baby_yoda has quit [Quit: -a- Connection Timed Out]
<jackdaniel>
parenscript
<jmercouris>
the order is irrelevant, yes
<jmercouris>
BUT I could easily write (format nil "[potato='fish']") and get correct output, however parenscript will wrap it again
<jmercouris>
and then I get: document.querySelector('[next-identifier=\\'J\\']');
<jackdaniel>
I think you should read about printer, because I think that the product you've mentioned is equivalent to what you have expected from it to print. (or print strings with princ for verification)
<jmercouris>
I'll investigate
baby_yoda has joined #lisp
hsaziz has quit [Ping timeout: 260 seconds]
hhdave has quit [Quit: hhdave]
<phoe>
jmercouris: wait a second though
<phoe>
TEST> (format t "document.querySelector('[next-identifier=\\\"J\\\"]');")
<phoe>
in \\\", the first slash escapes the second slash and the third slash escapes the quote
<jackdaniel>
phoe: that's what I've suggested a few minutes back?
<jmercouris>
maybe?
<jmercouris>
all of these slashes are starting to confuse me
<phoe>
jackdaniel: I'm still reading the text (though I admit that it is surprisingly heavy on my eyes, with two people talking with equal nick length and first letter of their nickname)
<phoe>
(I never thought it would become a readability issue for me!)
<jackdaniel>
yes, I find it very unfortunate that jmercouris nick has the same length and the same first letter
<jmercouris>
jackdaniel: sure, just change your name to dkochmansi
<jmercouris>
kochmanski*
* phoe
googles for colored nicks in irssi in meantime
<jmercouris>
phoe: it is supported in circe
<jackdaniel>
I'm not sure where did it come from, but that was kind of rude, see you later
luna_is_here_ has joined #lisp
<jackdaniel>
(and you are welcome for help)
<jmercouris>
It wasn't rude, but OK
<jmercouris>
thanks indeed for the help!
<phoe>
jmercouris: anyway, it's a non-issue - the escaping works as intended in Lisp
* phoe
goes "aaaaaah~" after installing colornicks in irssi - much better now
raghavgururajan has quit [Remote host closed the connection]
jmercouris has quit [Ping timeout: 268 seconds]
<uint>
phoe: do you happen to have a link to that close by? sounds handy
<phoe>
uint: "/run scriptassist" then "/script install nickcolor" should do it for irssi.
bitmapper has joined #lisp
jmercouris has joined #lisp
<jmercouris>
parenscript is indeed doing stuff to how things are printing...
slyrus__ has joined #lisp
<jmercouris>
somehow somebody is messing with the string on the way to the interpreter...
<jmercouris>
the rabbit hole goes deeper..
* phoe
sings, the ciiiiiiircle of liiiiiife™
<jmercouris>
the way you wrote the string, which I had tried before, was correct...
<jmercouris>
it seems the problem is not where I think it is
hhdave has joined #lisp
manualcrank has quit [Quit: WeeChat 1.9.1]
slyrus_ has quit [Ping timeout: 240 seconds]
<uint>
phoe: thanks!
<jmercouris>
OK, so the problem was actually in JS...
<jmercouris>
parenscript has got to be the hardest CL to debug, I think I'll make some tools for that
jonatack has joined #lisp
<phoe>
jmercouris: do you have unit tests for your code? I mean both unit tests for the code that uses PS to generate stuff and unit tests that test the generated JS
<jmercouris>
phoe: not yet, not for that part at least, but that is a good idea!
<phoe>
jmercouris: some time ago I have noticed that I cannot put trust in code that is not properly tested, and unit tests are a pretty cheap and simple way to increase that trust
lucasb has joined #lisp
fivo has joined #lisp
jmercouris has quit [Ping timeout: 260 seconds]
jmercouris has joined #lisp
hostile has joined #lisp
earl-ducaine has quit [Ping timeout: 260 seconds]
EvW has joined #lisp
jmercouris has quit [Ping timeout: 258 seconds]
mn3m has joined #lisp
earl-ducaine has joined #lisp
Lord_of_Life_ has joined #lisp
Lord_of_Life has quit [Ping timeout: 265 seconds]
Lord_of_Life_ is now known as Lord_of_Life
nowhere_man has joined #lisp
cosimone has joined #lisp
clothespin_ has quit [Read error: Connection reset by peer]
<Xach>
beach: hmm, that could take the crown instead
LiamH has joined #lisp
LiamH has left #lisp [#lisp]
baby_yoda has quit [Quit: -a- IRC for Android 2.1.55]
anewuser has quit [Ping timeout: 260 seconds]
<beach>
vms14: What is your definition of "metaprogramming"?
<beach>
vms14: I mean, pretty much any Common Lisp macro generates code.
<vms14>
beach: things to be aware, or some light/introduction about
<vms14>
I feel very lost while doing this
<vms14>
and it's just some sort of js transpiler
<beach>
I still don't know your definition, but that sounds like plain old programming to me.
<vms14>
my problem is idk what approach I should take
<vms14>
for example I've started with functions returning only transpiled js text
<vms14>
but it's a problem and I need to have track of what I'm doing
<phoe>
your questions are way too general for me to be able understand what *exactly* your problem is
<beach>
I understand, but that does not make your problem one of metaprogramming.
<vms14>
oh
<phoe>
it does seem like you have a problem with structuring your original issue in general
<phoe>
like, how to even approach trying to transpile CL into JS
<phoe>
and this isn't a CL problem, this is a software architecture problem
<phoe>
some CL features and gimmicks might help you with working on the architecture, but CL won't completely erase the fact that you need to figure out the logic of how exactly your compiler is going to work
<phoe>
and what its internal logical structure is supposed to be like
dyelar has joined #lisp
<pjb>
vms14: in general, it's useful to have an internal representation of the thing you want to generate, so you can manipulate it before generating it. So instead of generating directly the final code, generate a data structure that represents the final code. Then you can have functions to generate the code from this data structure, or to process it otherwise.
shka_ has quit [Ping timeout: 258 seconds]
<vms14>
pjb ty for the hint
<vms14>
that was what I was looking for
Arcaelyx has joined #lisp
edgar-rft has quit [Quit: Leaving]
dale_ has joined #lisp
amerigo has quit [Quit: Connection closed for inactivity]
dale_ is now known as dale
<phoe>
Random piece of news: LispWorks is going to add PLN support in their next release.
<phoe>
mfiano: ^
fitzsim has joined #lisp
vms14 has quit [Remote host closed the connection]
fortitude has joined #lisp
clothespin has quit [Ping timeout: 252 seconds]
ArthurStrong has joined #lisp
<Xach>
nice
madage has quit [Remote host closed the connection]
<galdor>
does it mean one will be able to use package local nicknames without using the trivial- system ?
<jackdaniel>
in defpackage operator yes
<Xach>
galdor: My understanding is that you can use much of the functionality directly but some functionality has to be papered over with the trivial-pln thing, because e.g. modifying and querying nicknames is in implementation-specific packages.
<Xach>
I wish that were not the case
<jackdaniel>
for parts of the protocol (i.e add-local-package-nickname function), you need to take them from a package
<jackdaniel>
which differ
Fare has joined #lisp
<phoe>
galdor: yes.
<phoe>
the part that actually matters for an average programmer is going to be integrated into CL:DEFPACKAGE.
<phoe>
Only if you need to programmatically query the nicknames or add/remove them, the trivial-pln package might be useful for you.
<phoe>
(Or if you want to run trivial-pln's test suite, which I need to remove into a separate ASDF system.)
random-nick has joined #lisp
<no-defun-allowed>
beach, phoe: I hate to disappoint but I don't feel like Clomptroller is of the same quality as my other projects, nor is it any good for accounting.
karlosz has joined #lisp
<phoe>
no-defun-allowed: oh well, okay
<no-defun-allowed>
That is partially because it was a project for school, and most of my time was spent planning which left me with little time to program.
<p_l>
Xach: I wonder if we could have a small panel at ELS or the like where integration of new common functionality could be discussed by people from implementation vendors/maintainers
<no-defun-allowed>
So I don't really want to release it.
<phoe>
Xach: galdor: someone from the Lisp Discord server has asked me for a very brief description/example of how PLNs might be used, and I've quickly thrown together some words at https://gist.github.com/phoe/2b63f33a2a4727a437403eceb7a6b4a3 that badly needs some proofreading, and likely removal of like 70% of its contents. Mostly because it's less of an actual blog article and more of a tired holiday shitpost.
<galdor>
oh nice!
<phoe>
p_l: so, basically, extending the de-facto standard library?
<p_l>
phoe: yes
<no-defun-allowed>
A comptroller "is a management-level position responsible for supervising the quality of accounting and financial reporting of an organization."
<pilne>
so something kinda like cl21 but "officially standard"?
<phoe>
galdor: I'm tired, and particularly salty today after realizing that my first paycheck for 2020 is unexpectedly small, so only tell me it's nice once you've verified that this text is worth the time.
<galdor>
I'm reading it :)
<phoe>
pilne: and without the issues that plague cl21.
<pilne>
fair
<p_l>
phoe: I mean, variations of nicknames and hierarchical names have been going on in various implementations since late 1980s or early 1990s
<phoe>
p_l: yes, but I don't think you only want to stop at PLNs
<Xach>
p_l: it is good for stakeholders to discuss things. i think els attracts only a particular type of stakeholder - not enough
<phoe>
I'm curious about what other things you have in mind
X-Scale has joined #lisp
<p_l>
Xach: I think the only implementation that wasn't represented at the ELSes I've been at, that is still alive, is CMU
<p_l>
maaaaybe CLISP
shifty has quit [Ping timeout: 240 seconds]
<galdor>
@phoe it was interesting :)
<p_l>
... come to think of it, both kinda float around death/undeath point
<galdor>
I really like to possibility to stop using :USE
<p_l>
Xach: so I think we could have a possibility
shifty has joined #lisp
<phoe>
galdor: PLNs give you that chance, and I'm already utilizing that chance in the new code that I write
<galdor>
because up to now it was either introducing potential conflicts or typing really long package names
<p_l>
I'm not talking anything big
<phoe>
galdor: bingo, exactly this
<MichaelRaskin>
I guess a unified name for things everyone has already implemented should be low-conflict enough to say ELS is representative enough
<galdor>
actually the most exciting thing is that it feels to me it's the first time almost all CL implementations manage to agree to evolve something that fundamental
atgreen_ has quit [Remote host closed the connection]
<p_l>
so, if PLNs are finally getting into common use *without* using your own CL package, after 30 years, I'd like to get shit a bit faster
atgreen_ has joined #lisp
<p_l>
I know that Franz and LW might not have much manpower to push changes
<p_l>
but getting some common ground and possibly public domain code that could be adapted without legal issues in spirit of cooperation...
<galdor>
so the new "clean" way would be 1/ no :NICKNAMES 2/ no :USE (apart from :CL) and 3/ :LOCAL-NICKNAMES
* p_l
knows he is a dreamer
<phoe>
galdor: not really the first time I think
<phoe>
Gray streams and MOP are two things I can see that happened earlier - but likely because both are very old concepts
<galdor>
well ASDF seems like something all implementation include, but given the debate regarding an update for SBCL, I'm not so sure it's settled ^^
<galdor>
gray streams still require a separate system, so does mop
<Xach>
p_l: hmm, that could make it more feasible then.
<Fare>
Yeah, ASDF got bad blood with SBCL.
<galdor>
oh hey Fare
<Fare>
and with Quicklisp
<galdor>
well I'm trying really hard to push for an update
<p_l>
galdor: ASDF is result of a decade of trying to get shit running after Symbolics DEFSYSTEM and related got pushed out of standard because "standard is too big already"
brown121407 has quit [Read error: Connection reset by peer]
<Fare>
I readily admit I'm not great at QA. But rpgoldman and Anton V did a great job at getting ASDF tested.
<Fare>
Also, even not being great at QA, I feel that the gripes against ASDF have been inflated.
<Fare>
Of all the projects I've published, ASDF is the one where I've done lots and lots of testing.
<Xach>
p_l: in the past I have underestimated the degree to which progress happens without financial incentive - sbcl has an interesting but not really representative history in this regard
<galdor>
to be honest I believe ASDF is both too smart for its own good, but it works, and having something that works is a lot better than not having it
<jackdaniel>
maybe a way of forcing changes got in a way too?
<p_l>
galdor: we then had a bunch of incompatible attempts at DEFSYSTEM, then I think semi compatible MK:DEFSYSTEM, then ASDF that finally brought everyone to common space by virtue of supporting everyone in ways that are easy to use legally
<Fare>
jackdaniel, which changes do you think of in particular?
<Xach>
p_l: that is, I don't think it works to simply present something good, agree that it is good, and then see progress happen automatically
<p_l>
Xach: no, it doesn't :(
<Fare>
I've been keen on consulting the community and backing off changes that did get significant push back.
<galdor>
p_l: this is my point; everyone uses it, every implementation has it, it's maintained
<Xach>
I think for some it requires a customer saying "this is good, i want it, make it or i will stop paying"
<galdor>
so the whole "let's not update it because reason" is harmful
notzmv has joined #lisp
manualcrank has joined #lisp
<Fare>
also for many years, rpgoldman, not I, is the one who's been calling the shots.
<p_l>
that's why I'm suggesting going for something like "here's a library that does 80%, and it's legal to integrate into implementation no matter the license"
gravicappa has quit [Ping timeout: 265 seconds]
<jackdaniel>
I was started to writing an answer, but 1) I'm tired, 2) that would escalate into flamewar, so I'll pass ;)
<Xach>
p_l: it's possible that reader algorithms are also finely tuned to customer needs and any disruption could be rejected
<Fare>
jackdaniel, no emergency, but if someday you're bored and write it, please publish it.
<Xach>
i can think of someone who generates weird code with a bajillion symbols/packages and they are/were important
<Xach>
but maybe their time is in the past
<MichaelRaskin>
Bajillion packages reminds me of hu.dwim.walker
<p_l>
Xach: I remember that at least one commercial implementation (I think it was ACL) allowed enough freedom that I think conduits libs actually reimplemented bits of the walker there
<jackdaniel>
that would raise unnecessary bad blood; it is enough to say that I'm *personally* not amused with many things in ASDF
<MichaelRaskin>
Which relied on a good chunck of hu.dwim namespace
<Fare>
p_l, speaking of Symbolics DEFSYSTEM, it had glaring bugs in it... and MK:DEFSYSTEM and ASDF 1 inherited some of it, without the workarounds.
<phoe>
jackdaniel: one such thing is UIOP or at least UIOP/UTILITY, isn't it
<Xach>
phoe: it's possible that longtimeuser4 in that example is paying $$$$$$ and so you have to pretend to care deeply about their needs.
<jackdaniel>
fact taht uiop is a preloaded system is part of the problem, sure
<MichaelRaskin>
phoe: are you actively trying to fan a flamewar?
<phoe>
MichaelRaskin: nope - I simply think that UIOP/UTILITY and all the other utility libraries that happen and even Alexandria are the symptom of a much bigger problem with CL as a language - that is has a shi^Wvery bad standard library by contemporary standards
<jackdaniel>
he is ,)
<MichaelRaskin>
Alexandria is kind of fine
<galdor>
is there a problem with UIOP being loaded ? it's not "contaminating" anything afaik
<p_l>
Fare: I wouldn't have expected them to be left alone
<phoe>
and, since it's as easy to create one's own standard library as it is to create a new unit testing framework, bam, we have at least twenty of each
ArthurStrong has quit [Quit: leaving]
<p_l>
phoe: not that easy
<MichaelRaskin>
I would like to know a way to make as many trivial-* as possible unnecessary
<galdor>
and regarding standard libraries, I'm not sure that having tons of code which will never be fixed because "omg backward compatibility" helps (see erlang with ssh and http libs, go with virtually anything, etc.)
<p_l>
kinda hard to rip open COMMON-LISP and replace stuff in there without breaking shit
<jackdaniel>
phoe: actually uiop was created in order to solve the problem you talk about, am I right Fare ?
* jackdaniel
switches context to visualising ECL's IR
<MichaelRaskin>
I mean, I tried to write CDR-discoverability but maybe I need to take over the CDR process first
<phoe>
jackdaniel: I know - xkcd standards was invoked though. And, for that, I have no good solution that doesn't involve herding lispers full-time for months.
<phoe>
MichaelRaskin: I suggest that you do, I don't know if the process is moving anywhere at the moment, like, at all
<phoe>
and I hope that I'm just blind and that it actually does move.
<Xach>
p_l: there are a few escape hatches
<Xach>
p_l: not enough, probably
<Fare>
jackdaniel, some of it. ASDF 1 was totally non-portable in its treatment of pathnames (and more, but mostly pathnames). ASDF 2 did a good enough job in the common case, but there were still a ton of corner cases, that ASDF 3 and UIOP did a systematic job at handling well.
<MichaelRaskin>
Well, at some point I thought that it is stalled because nobody writes CDRs
vms14 has joined #lisp
<galdor>
why writing CDRs if they are not implemented
<MichaelRaskin>
And talking to Marco left me with the same impression
<galdor>
it's a chicken and egg problem
<jackdaniel>
phoe: I think that you are barking the wrong tree. lack of people willing to write a good solution is not a problem ;the problem is people who do not will to put time in discovering existing software
<MichaelRaskin>
galdor: I have a CDR draft that I have already written, and which is pretty cheap to implement
<Xach>
MichaelRaskin: a CDR is a "here is a Thing" document. there are many steps after that, like, "we all agree this is a Good Thing", and "we all agree that not adding this Thing to our implementation is critically Bad"
<MichaelRaskin>
Xach: these steps are, ideally, not really _after_ that
<phoe>
jackdaniel: you are correct, the discoverability problem is serious, but there is no central repository for discovering projects that are actually worthwhile. This means that people tend to either use the first thing they find or write their own half-baked buggy implementations.
<phoe>
Quicklisp is good for downloading stuff that you already know about, and for ql:system-apropos that only lists some of the stuff as long as you are lucky with your search query.
<galdor>
MichaelRaskin: I'd be willing to read it and comment for what it's worth; but the problem is more "how to implement it for all implementations" and "how to convince these implementations to accept it"
<Xach>
"we will pay one or more engineers to make sure we faithfully implement this Thing"
<Fare>
I remember when ITA had trouble hiring reliable people to hack on SBCL. Eventually, they found Dan K inside ITA who became a big SBCL expert.
<_death>
the standardization committee argued about the design of Thing.. is writing a CDR a start point or an end point
<phoe>
galdor: I think both are actually doable. "how to implement it for all implementations" is doable since you have the source code, and the "convincing" part is optional - you can publish it on Quicklisp as a quasi-portability library that also has implementation baked in.
<Fare>
ITA also funded a lot of CCL development (a strategic mistake, I believe, but I liked the CCL people a lot, and they were reliable).
<jackdaniel>
Fare: I'm not arguing that asdf didn't progress (under some metrics); all I'm saying is that some changes were not necessarily called for and that they were kind of shoved into osme peple throats, what is maybe more a public relations problems than a technical one, still it is a problem which influences how technology is perceived, adopted and in consequence - in its further development
<galdor>
I'll read it and get back to you
<phoe>
And if an extension is good enough to gain traction in the Lisp world, it'll get picked up by the commercial ones too - see PLNs.
<phoe>
Fare: why a mistake?
<MichaelRaskin>
Some implementation representatives said at ELS that probably code for that would be easy to get accepted
<phoe>
I ask as a person who is hacking on CCL nowadays for fun and to get it somewhat into shape for future hackers who may come.
<Fare>
jackdaniel, agreed I'm bad at public relations. I was mostly not directly paid to work on ASDF, either, it was a side on my main job.
<Fare>
phoe: dividing our ecosystem development effort.
<phoe>
MichaelRaskin: yes, the code for that is trivial - we push some stuff into *FEATURES* on each implementation, and each impl knows what to push into it.
<Fare>
we could have funded development on SBCL and have saved efforts for more results. And we did, eventually.
<Fare>
CCL support died with the demise of QRes, anyway :-(
<MichaelRaskin>
phoe: no, just pushing to *FEATURES* is only half-useful
<phoe>
Fare: so basically, fewer people to work on SBCL and, at the same time, not enough people to work on CCL?
<Fare>
yup
<phoe>
MichaelRaskin: oooh, yes, I re-read and noticed. CDR-* packages too. That'll need support from each implementation... but is doable as well, even from the outside.
earl-ducaine has joined #lisp
<MichaelRaskin>
Yes, and it should be relatively cheap for implementations to maintain if initial overview is donated to them
<phoe>
Fare: got it.
<MichaelRaskin>
Typically, implementations _know_ when they restructure something
<vms14>
I have something a bit "better", but it generates a lot of boilerplate
<MichaelRaskin>
And CDR process is valuable here just as a namespace assignment process
brown121407 has joined #lisp
<no-defun-allowed>
If one is working on implementing a CDR proposal in their favourite implementation, are they CDR coding?
<MichaelRaskin>
I want to get a formal CDR number before I startrallying people around implementing a standard critically dependent on CDR numbers being assigned in a timely manner
<p_l>
maybe we should have semi-automatic way to get them assigned
<MichaelRaskin>
I would also like to fix a few links on the CDR list website
<MichaelRaskin>
I guess I should ask for addition to the list of people who can do things
<jackdaniel>
another thing is that there are not that many things missing in the standard, we are "good to go" for implementing actual software instead of extending the language ;-)
<MichaelRaskin>
Erm.
<MichaelRaskin>
There is a ton, actually
space_otter has joined #lisp
<MichaelRaskin>
Let's start with sockets
<jmercouris>
Don't get me started with sockets
<jackdaniel>
there are many things which you *could* add, but not many which you *must* add to make the language viable
<jackdaniel>
usockets works reasonably well as a protocol, bugs aside. it is easier to push for better coverage of usocket functionality than forcing uniform api on implementers
<vms14>
jackdaniel: has usocket support for local sockets?
<jmercouris>
NO!
<jackdaniel>
it does not; yet it would be imo easier to work on usocket and add implementation-specific bits
<jackdaniel>
than drafting a new standard, then pursuing adoption
<vms14>
meh
<jmercouris>
And that, is a huge problem
<MichaelRaskin>
jackdaniel: I am not really for pushing a fully unified API, I am more in favour of having same-name aliases in a non-conflicting namespace for _exact same_ functions already present in various implementations under different names
<MichaelRaskin>
Typical Common Lisp should not do feature probing worse than well-written Javascript
<galdor>
I rarely see any good socket library in any language, most of the time they just copy the BSD API
<p_l>
MichaelRaskin: the best thing we could do was not hardcode the shitshow that is BSD Sockets into language
<jackdaniel>
isn't that a definition of a protability alyer?
<vms14>
I've played a bit with sbcl sockets, but have no idea how to "flush" the socket text without closing it
<MichaelRaskin>
jackdaniel: portability layers not integrated with implementations like bitrotting
<galdor>
CFFI is... particular
<p_l>
galdor: because BSD API, or rather, TOPS-20 API, was ported with clear purpose of providing bare minimum so that DoD could switch to Unix
<phoe>
and baking the current version of usocket API into the de-facto standard of the language
<vms14>
no-defun-allowed: XD then I was doing something wrong with the C client
<galdor>
it depends on other libraries, has a really hacky groveller
<MichaelRaskin>
Groveller is kind of optional
<jackdaniel>
MichaelRaskin: all software will bitrot if it is not maintained, implementation interfaces included
<p_l>
galdor: depends on what? libffi? It's a bit hard to implement the bits that libffi provides without it
<vms14>
but I was lucky to find a solution with the problem I had with clx so I didn't need to create such abomination
<phoe>
and then doing the same with bordeaux-threads, closer-mop, trivial-gc, cffi, and so on
<no-defun-allowed>
Perhaps it won't happen again, but the thing I worry about with FFI, sockets and other portability libraries is they assume the usage of a Unix/C machine, but I guess that is basically what everyone uses now.
<galdor>
it's not really optional unless you want to hardcode a ton of values, the alternative being parsing header files at runtime (and you do not want to)
<phoe>
honestly, I think this would be good enough
<jackdaniel>
I find libraries mentioned by phoe sufficient
<MichaelRaskin>
jackdaniel: I actually fix bugs in CL-Emb when they are reported. Let me tell you it does not itrot
<jackdaniel>
and there is no need to use a lot of hours to push for semi-standards
<vms14>
still, if you can, try to avoid ffi
<no-defun-allowed>
By "it", I mean that there won't be more operating system (standards) to have to support, which manifested in the pathname system in some ways.
<jackdaniel>
MichaelRaskin: then you are maintaining it, that does not contradict what I've said
<p_l>
no-defun-allowed: curiously enough, Go is the one presently-popular language that doesn't even support BSD Sockets
<p_l>
Somehow people accepted that
<MichaelRaskin>
galdor: If the groveller breaks tomorrow, things you have grovelled today will still work
<galdor>
well I'm not reimplementing X509 so openssl and ffi it is
<MichaelRaskin>
jackdaniel: Zero changes in let me count years
<vms14>
p_l: what? I used golang in netbsd, made a little server and it was working
<MichaelRaskin>
All the reported bugs have been inherited from many years ago
<MichaelRaskin>
(of course they are about corner cases)
<p_l>
no-defun-allowed: Using BSD Sockets as API interface ensures your code is future-unproofed
<galdor>
the Go socket API is slightly different but the idea is the same
<_death>
I don't much like usocket and often find myself reaching for sb-bsd-sockets when experimenting
<p_l>
vms14: it has to use them in the runtime
<jackdaniel>
MichaelRaskin: I don't get your point. If it is maintained, then it doesn't bitrot. If it is not, then it does. I'm saying that adding semi-standards won't change that principle
<MichaelRaskin>
Software maintenance is a symptom of problems, not a desirable state of software
<p_l>
but the Go standard library doesn't use BSD API, and isn't descended from it
<no-defun-allowed>
p_l: doesn't Go recreate the whole libc, and don't they make clear it is the opposite of a LFSP?
<p_l>
no-defun-allowed: Go doesn't use unix libc, period
<p_l>
it uses Plan9 runtime
<MichaelRaskin>
jackdaniel: conformant Common Lisp does not bitrot
<_death>
neither are CL-quality interfaces... and neither are cffi, bordeaux-threads, alexandria..
<p_l>
including Plan9 network library
<jackdaniel>
so it is enough to write CL which doesn't need maintenance and then fix usockets to match that CL and you are golden
<jackdaniel>
it never bitrots
<vms14>
the only thing I know is golang was made with lex and yacc until they rewrote the compiler with go, and not sure if it's right
<earl-ducaine>
sbcl has a function sb-kernel::valid-type-specifier-p, but there doesn't seem to be any portable way to check whether a type specifier is valid. Is that because there is something inherently problematic about defining one?
<phoe>
p_l: how do we want to design the hypothetical CL sockets then?
<no-defun-allowed>
The latter is not really relevant, but I recall C and Python sockets being much less clean than usocket, so I would expect Go to clean it up into a subset of the BSD system.
<p_l>
phoe: I'd look at XTI interface (from SysV) instead of BSD Sockets, or Plan9 API
<jackdaniel>
earl-ducaine: how about (subtypep 'xyz t) ;?
<MichaelRaskin>
jackdaniel: as long as we do not have at least a semistandard for usockets, we do not have that nice non-bitrot property
Lycurgus has quit [Quit: Exeunt]
brettgilio has quit [Quit: Quit]
brettgilio has joined #lisp
<jackdaniel>
having a semistandard won't give you such property either. usocket afaik has stable api; why can't we treat it as such semistandard?
<galdor>
one of the hard things with sockets is correctly handling interruptions and timeouts, and this is a far more general problem in all common lisp implementations
<jackdaniel>
sure, fixing problems is another thing
<galdor>
doing anything non-blocking is a crazy can of worms
<phoe>
why should we treat is as semistandard if it's actually a standard, as shown by its widespread usage
<galdor>
it immediately relates to threads and parallelism in general
<jackdaniel>
my point is that forcing N parties to agree on something new when there is something existing what works (and is de facto standard) won't fly far
<phoe>
the question is whether the hypothetical cltl4 is going to have its own socket API that directly descends from usocket, or whether it is still going to delegate to usocket for its networking
<p_l>
I'd say it's necessary that it doesn't descent from usocket
<phoe>
p_l: I'd say it's necessary for it to exist
<p_l>
with usocket compat interface like CFFI used to have UFFI interface
<MichaelRaskin>
jackdaniel: because it had to manually add Clasp support, and _every_ trivial-* library also had, and there is nothing Clasp could do about this without exactly mimicking ECL?
<phoe>
and as much as usocket and unix sockets are a pain, we have nothing better at the moment
<_death>
when considering an API, I often ask myself: could I imagine it being part of CL?.. most of the time, the answer is no.. because it's really hard to design a CL-quality API (which is also imperfect of course)
<p_l>
phoe: a backwards compat library? yes. Usockets, being pretty direct clone of BSD sockets, ensures our network code is forever broken
brettgilio has quit [Ping timeout: 260 seconds]
<MichaelRaskin>
p_l: note that non-broken network code must e non-runnable
<jackdaniel>
MichaelRaskin: I have an interesting datapoint whcih you may find interesting (however it is not 100% match for what we are discussing) -- just thought you may like it
<p_l>
MichaelRaskin: there are different layers of broken
<jackdaniel>
ECL had FFI implemented natively to correspond to UFFI protocol
<phoe>
p_l: we'll need to create one though
<jackdaniel>
so ECL's implementation for FFI has 1-to-1 resemblence in UFFI standard (so there was no need or uffi to have a separate implementation for ECL)
<p_l>
MichaelRaskin: which is how, in 1998, even BSD-style sockets got getaddrinfo, badly copied from XTI
<phoe>
we can't easily replace a BSD-sockets API with a no-sockets API without some people getting annoyed at that fact
xuxuru has joined #lisp
<p_l>
phoe: somehow, Go did it, and some people didn't even notice
malm has quit [Ping timeout: 258 seconds]
<p_l>
we need an API that follows from XTI tradition for future proofing (Genera network library is, for various reasons, too much)
malm has joined #lisp
<earl-ducaine>
dackdaniel: unfortunately (subtypep '(mygarbage *** (3)) t) returns true, i.e. if it *was* a valid type, then t is a subtype.
<MichaelRaskin>
jackdaniel: yes, this just happens to go further than I dare to ask
<earl-ducaine>
But it doesn't check if the type is valid.
sloanr has quit [Ping timeout: 260 seconds]
<phoe>
p_l: could you point me to some description that shows how Go has it different? a random tutorial found in google at https://yalantis.com/blog/how-to-build-websockets-in-go/ shows me stuff that's similar to usocket api
jonatack has quit [Quit: jonatack]
<p_l>
phoe: consider that BSD Sockets are a hack written by bunch of graduate students on short term grant over short time because military needed it ASAP, and they worked it out by porting code they got provided
<phoe>
p_l: that's nothing, let me tell you about the origins of Javascript
<p_l>
phoe: I know them. Even got corrected on amount of days by the guy himself
<p_l>
as for that tutorial? it uses wrapper functions around actual core API
<phoe>
p_l: I am well aware that you know them - and it's really sad that #<unreadable object> like this sticks around forever
<_death>
nodejs also has a non-bsd socket interface
<phoe>
p_l: yes, there's listening, connecting, binding to addresses, sending and reading data - looks like usual socket stuff to me
<phoe>
same as if I were using usocket
<p_l>
the low level functions in Go are `dial`, `announce`, `listen`, `accept` and `reject`
bitmapper has quit [Ping timeout: 268 seconds]
* phoe
reads up
<p_l>
phoe: you're missing the part where a) BSD sockets require that you give low-level socket details for the connection b) Plan9 `dial` asks you for "hostname and high level protocol to use"
sloanr has joined #lisp
<p_l>
so you ask for connection to a *host*, not specific IP address (of course it will parse IP address for you if you pass one), and the *service* you want to connect
<phoe>
p_l: ooh.
<p_l>
"tcp" happens to be one of those services
<phoe>
We could steal that model off to Lisp, why not.
<phoe>
CLOS will make it extensible, too.
<p_l>
in OSI APIs like XTI, you told the OS that you want "stream with finalization" and a hostname
<fe[nl]ix>
p_l: what are "announce" and "reject" ?
shunter has joined #lisp
<p_l>
fe[nl]ix: announce sets up a socket that can be connected to (one that you can call "listen" on), reject is the other state change in TCP than accept, i.e. CONNECTION REFUSED
<MichaelRaskin>
Of course this nice host abstraction will leak once you talk to a BSD-socket-using multi-IP server with different listeners on the same port on different IPs
<p_l>
fun fact: you don't have to listen on a socket to accept a connection to it
<phoe>
p_l: wait, how
<p_l>
MichaelRaskin: guess what, BSD socket api doesn't handle that at all, it's all extensions
<MichaelRaskin>
p_l: well, 4.2BSD socket API started to handle bind
<p_l>
phoe: listen->accept creates a *new* socket
<fe[nl]ix>
phoe: listen assigns a local address to the socket. if you call accept before listen, the kernel will bind it to all interfaces and a random port
brettgilio has joined #lisp
<phoe>
fe[nl]ix: p_l: let me parse it for a moment
<p_l>
listen establishes that the socket is to follow the "create new socket" path in the TCP state machine
<p_l>
you can also do "both sides connect()" path
<p_l>
legal, little known, used mostly by malware
<MichaelRaskin>
I thought it was used for NAT traversal at some point?
<MichaelRaskin>
But probably less reliable than UDP punching
<Fare>
isn't something like that used by software that goes through masquerading firewalls?
<Fare>
^ ahem, something went wrong with the space bar.
<Fare>
yeah, I believe the UDP equivalent of that is usually used.
<p_l>
fe[nl]ix: net package is a bit high level
<_death>
iolib or basic-binary-ipc, I think those are less annoying than usocket for many purposes
notzmv has quit [Ping timeout: 260 seconds]
<p_l>
MichaelRaskin: that said, there are ways to specify more detail, like interface to use, specific address to use, things like that
<p_l>
the point is, BSD sockets expose details of chosen implementation in way to raw way
<p_l>
till they grabbed GAI from XTI, pretty much
<p_l>
XTI idea: if you don't *need*, just tell me host and service and OS will figure connection details
space_otter has quit [Remote host closed the connection]
Volt_ has joined #lisp
<p_l>
this means that XTI API doesn't care for the typical "connect me to HTTP service" case whether you connect over IPv4, IPv6, X.25, serial link direct to other computer, carrier pigeons
<p_l>
you tell "host", "service", worst case you specify extra details
<p_l>
even in Go's "connectTCP", you can give it a hostname, iirc
notzmv has joined #lisp
atgreen_ has quit [Ping timeout: 260 seconds]
quazimodo has joined #lisp
akoana has joined #lisp
<p_l>
because it translates into (from memory): dial("tcp!host!port")
<p_l>
it might have drifted a bit, but `dial` is still there in the core
<p_l>
note that at no point is an IPv4 or IPv6 address hamfisted into a binary struct with underdefined details
<p_l>
if put in an address, it will get parsed to the best knowledge of the underlying system
<phoe>
posting it here since I thought that some people might want to know about it
sloanr has quit [Quit: sloanr]
ebrasca has joined #lisp
xuxuru has quit [Quit: xuxuru]
EvW has joined #lisp
dilated_dinosaur has joined #lisp
jmercouris has quit [Ping timeout: 268 seconds]
random-nick has quit [Ping timeout: 258 seconds]
jonatack has joined #lisp
terpri has joined #lisp
gabiruh has joined #lisp
<froggey>
phoe: thanks. I wasn't sure if mentioning it here was ok
<phoe>
froggey: well, in the worst case, I'll get the banhammer and not you
<Fare>
is that the makeExtensible thing in lib/fixed-points.nix ?
hhdave has quit [Quit: hhdave]
LiamH has quit [Quit: Leaving.]
vms14 has quit [Remote host closed the connection]
pjb has quit [Remote host closed the connection]
anewuser has quit [Ping timeout: 265 seconds]
jmercouris has joined #lisp
* p_l
declares that as at least one part time, rarely ever on, not-feeling-part-of-community-anymore OP, he wouldn't drop the banhammer on mentioning that a CL project got a funding option on Patreon
shifty has quit [Ping timeout: 240 seconds]
<p_l>
... though I might drop down the OP hat
<p_l>
(and I meant permanently)
vidak has left #lisp ["ERC (IRC client for Emacs 26.2)"]
wxie has joined #lisp
vidak` has joined #lisp
akoana has quit [Read error: Connection reset by peer]
payphone` has joined #lisp
Fare has quit [Ping timeout: 268 seconds]
akoana has joined #lisp
wxie has quit [Ping timeout: 260 seconds]
quazimodo has quit [Ping timeout: 240 seconds]
slyrus_ has joined #lisp
Fare has joined #lisp
slyrus__ has quit [Ping timeout: 265 seconds]
whiteline has quit [Ping timeout: 265 seconds]
whiteline has joined #lisp
quazimodo has joined #lisp
hsaziz has joined #lisp
orivej has quit [Ping timeout: 260 seconds]
orivej has joined #lisp
lavaflow has quit [Ping timeout: 265 seconds]
luna_is_here_ has quit [Ping timeout: 260 seconds]