<gendl>
I've been thinking it would be a good idea to have all gitlab.common-lisp.net projects mirrored on github as well, since it seems a lot of statistics reporting assumes everything is just on github and only mines that for their stats.
<no-defun-allowed>
indeed
<aeth>
Well, CL projects can be (and probably should be) at one of three locations, generally: github, gitlab.com, and gitlab.common-lisp.net
<aeth>
(Every now and then there's one on bitbucket or sourceforge)
<gendl>
aeth: tell that to the stats collectors.
<aeth>
Probably best to mirror at all three, though, so you have an authoritative copy on them. Especially a github mirror.
<aeth>
gendl: People collect stats to make the argument they want to make.
<gendl>
i'm sure 99% of them miss gitlab.common-lisp.net
<aeth>
gendl: If someone wants to make the argument that C/C++/Java/etc. is dead and JS is the new big language, they'll use Github stats.
<gendl>
aeth: yep they bend stats to make their argument. I want to do the same.
python476 has quit [Ping timeout: 252 seconds]
<gendl>
aeth: In principle I agree with mirroring things around, but is there a danger of it causing confusion?
<no-defun-allowed>
100% of programs are written in CL, sourced from gitlab.common-lisp.net
<gendl>
no-defun-allowed: lol.
<no-defun-allowed>
pretty good that cmucl is on there
<gendl>
aeth: I agree with mirroring things around, but how to avoid confusion - e.g. what if someone sees a CL repo on github, but the active one is actually on gitlab, and they open a Pull Request etc.
<LdBeth>
really? you'd better hope i can't find one mix language project there
<gendl>
cmucl is on there, asdf is on there... [gendl is on there ;) ]
pjb has joined #lisp
Josh_2 has joined #lisp
<gendl>
i mean the active one is actually on gitlab.common-lisp.net... I mean, how to avoid a chaos of Issues, Pull Requests or Merge Requests on other mirrors
<gendl>
or is that not how mirrors work --
<gendl>
are they identified as mirrors, and point to the place where Issues and Pull Requests should go?
<aeth>
I'm not sure if there is a way to disable pull requests. I think you can disable the rest, e.g. issues/wiki/etc.
<gendl>
The github one has an ancient (legit-looking) pull request which has been ignored.
<gendl>
The gitlab.common-lisp.net one is the one which goes into Quicklisp.
meepdeew has quit [Remote host closed the connection]
<gendl>
I just did a different Merge Request on the common-lisp.net one, and trying to figure out how to transfer the ancient github Pull Request over to the common-lisp.net one
<gendl>
(I'll probably just manually re-do it myself, it's two tiny changes)
<gendl>
but yeah, I guess that's my concern with mirrors.
<gendl>
By the way, this is jumping the gun a bit, but what kind of CL-specific services would people like to see from common-lisp.net?
Kundry_Wag has joined #lisp
<gendl>
I've been thinking that it would be nice if common-lisp.net could maintain a continuous integration thingie with several up-to-date CL implementations
<Josh_2>
Hey, the site has changed
<Josh_2>
Where'd the flower go?
<gendl>
such that projects hosted at gitlab.common-lisp.net could press a button and get a report of their build and/or test pipeline run through a bunch of CL implementations
<gendl>
The flower was a victim of a male redesigning what was a female-designed site.
<Josh_2>
Yeh I know
<Josh_2>
#bringbacktheflower!
<gendl>
Females very much welcome and solicited as volunteers
<gendl>
I have confidence that there's a female out there who can bring back the flower better, faster, stronger than it was...
stereosphere has quit [Read error: Connection reset by peer]
<Josh_2>
What happened to the original lady?
<gendl>
Maybe the original female can make a triumpant return
<Josh_2>
I remember I once met her on some now defunct social media site because I had some lisp in my name xD
Kundry_Wag has quit [Ping timeout: 244 seconds]
ryan_vw has quit [Ping timeout: 264 seconds]
anewuser has joined #lisp
<gendl>
I know only a bit about her story and her whereabouts. But I don't want to talk about other people here when they're not here.
<gendl>
I do encourage anyone here to reach out to her and let her know that her past efforts were appreciated and she'd be welcome back to contribute to the new site.
<gendl>
For various (personal) reasons I ought not do that myself. Whoever wants to reach out, direct-message me here and I'll give you what contact info I have.
<gendl>
Back to my previous idea -- something like a customized, managed cl-test-grid running at gitlab.common-lisp.net
<gendl>
Could we leverage off of existing stuff to make that happen? I saw there's a CL-TRAVIS project..
<gendl>
Also what about private repos at gitlab.common-lisp.net (I'm also trying to think of ways the site can generate some revenue to sustain and expand itself better, without going cyberbegging through fundraisers all the time)
<Josh_2>
adverts
<Josh_2>
non-invasive adverts
<gendl>
Speaking for my own employer, I know we would gladly pay a couple hundred $$ per month for private repos and access to patched, updated, tested CL implementations and customized runnings of our test pipelines through those implementations.
<gendl>
I'm pretty sure Franz and probably LW would be on board for donating licenses for use in a test suite.
graphene has quit [Remote host closed the connection]
<gendl>
Josh_2: we already have an "ad" -- see the "sponsored link" of Allegro CL on the Downloads page.
<gendl>
(the "Get Started" page, that is)
graphene has joined #lisp
<gendl>
And maybe LW will want to sponsor one after the new year.
<gendl>
And maybe Genworks can manage one.
<gendl>
Who else would be good for ads? I wouldn't think we should have random unrelated ads on there.
<gendl>
but more sponsors would certainly be welcome.
ryan_vw has joined #lisp
<gendl>
We also are supposed to be a general CL promotional thing - so we have to be careful about appearing to play favorites among implementations, libraries, etc. But I don't suppose clearly marked and transparent "sponsored links" or sponsored logos should be a problem.
<gendl>
But to me, ads and sponsored links are just one fraction of what CLF and common-lisp.net can be doing. But I'll move any more detailed discussion of this into #common-lisp.net or #clo-devel, since they indeed have their own channels...
<no-defun-allowed>
what'd the flower look like? i forgot
graphene has quit [Remote host closed the connection]
<gendl>
I'm not gonna unilaterally change those permissions without talking to the other site maintainers, as I'm guessing there is a reason for the permissions the way they are.
<gendl>
The old site is a bit of an embarrassment on a number of levels (even more of an embarrassment than the new one, I should say). So maybe it should stay a bit buried.
<gendl>
But the flower is nice.
<gendl>
Note i'm not saying the basic design was an embarrassment - just the way the site was allowed to atrophy was one.
Kundry_Wag has quit [Ping timeout: 252 seconds]
<gendl>
I'm not sure why that looks so faded there.
<gendl>
with Flower and other design suggestions/ideas...
<Josh_2>
Well it was only a suggestion
<gendl>
suggestions mentioned here casually are at risk of washing away like so many tears in the rain.
<gendl>
in #common-lisp.net channel will be more likely to grow legs
zigpaw has quit [Remote host closed the connection]
<gendl>
and posted as Issues even more likely (keeping in mind a "rule of reason" with adding too many Issues, of course).
<gendl>
and if you feel like taking something into your own hands, with a gitlab.common-lisp.net account you can always fork the site repository, do some enhancements yourself, and lodge a Merge Request.
<Josh_2>
hmmm
pjb has joined #lisp
vmmenon has quit [Ping timeout: 246 seconds]
Josh_2 has quit [Remote host closed the connection]
orivej has quit [Ping timeout: 240 seconds]
Kundry_Wag has joined #lisp
sjl has quit [Quit: WeeChat 2.2-dev]
<gendl>
Josh_2: of course, it'd be a good idea to share your intentions with the maintainers, before spending tons of time modifying a fork then surprising with a huge Merge Request out of the blue...
Kundry_Wag has quit [Ping timeout: 252 seconds]
wanz has joined #lisp
wanz has quit [Remote host closed the connection]
esrse has joined #lisp
<beach>
Good morning everyone!
pjb has quit [Ping timeout: 250 seconds]
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
Lycurgus has joined #lisp
Kundry_Wag has joined #lisp
Copenhagen_Bram has quit [Read error: Connection reset by peer]
Kundry_Wag has quit [Ping timeout: 264 seconds]
<gendl>
Good evening Robert.
<beach>
Hey. What's up?
<gendl>
I was trying to clean up a bunch of stuff and github has been down.
<beach>
Oh! :(
<beach>
Is it back up now?
<gendl>
and I mentioned "meanwhile, gitlab.common-lisp.net continues to hum along, just saying..."
<beach>
Heh, yes. I see.
<beach>
I should probably consider moving.
<gendl>
which sparked a bit of discussion around common-lisp.net which maybe is ok.
<gendl>
if you move, there's a link up there somewhere talking about how you can keep an automatic mirror back at github.
<beach>
I saw it. I try to read the scrollbacks.
<gendl>
the only concern as far I see now being possible confusion with pull requests going to different places...
didi has left #lisp ["O bella ciao bella ciao bella ciao, ciao, ciao."]
<beach>
Ah, yes, that could be confusing.
<gendl>
but if the number of mirrors is kept to a reasonable number, like two or three, should be manageable.
<gendl>
I think it will be nice to have a critical mass of CL repositories on gitlab.common-lisp.net, for ease of Merge Requests among them, and for the eventual possibility of common-lisp.net offering more in terms of continuous-integration services integrated with the local gitlab.common-lisp.net repo.
<beach>
Sounds like a plan.
<gendl>
... as well as archival services, escrow services - all with special regard for the Lisp based nature of the things.
<gendl>
for example, escrow services with build verifications for the beneficiaries.
<beach>
I see. Do we have staff for all that?
<gendl>
No. All that would need funding, either self-generated from the services, or injected ahead of time in order to help get things rolling.
<beach>
Hmm. OK.
<gendl>
Anyway, I was also saying that continued talk about such details should probably bump itself over to #common-lisp.net channel.
<beach>
I didn't know it existed. :(
<beach>
I need to vanish for about 30 minutes. I'll be back.
<gendl>
both to avoid irritating folks here, and better to catch the eyes of the site maintainers.
Kundry_Wag has joined #lisp
Roy_Fawlty has quit [Read error: Connection reset by peer]
nowolfer has quit [Ping timeout: 246 seconds]
nowolfer has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
Copenhagen_Bram has joined #lisp
Bike has quit [Quit: Lost terminal]
Copenhagen_Bram has quit [Read error: Connection reset by peer]
Copenhagen_Bram has joined #lisp
* beach
is back.
* Elronnd
cannot seem to understand macros
<beach>
What seems to be the problem?
<Elronnd>
I'm trying to make a make a macro analogous to (defun s (&rest args) (list args))
<beach>
Analogous to DEFUN?
<Elronnd>
a macro analogous to s
<beach>
Why would you want to do that?
<Elronnd>
for fun
<beach>
Macros are useful only when function-call semantics is not appropriate.
dddddd has quit [Remote host closed the connection]
<beach>
You need to pick a meaningful exercise. One that has to transform the code.
<Elronnd>
if I can't understand how to make so simple a macro as that, how can I hope to make something interesting?
<beach>
You are trying to make a macro for something that macros are not meant for.
<beach>
So you will learn nothing.
<Elronnd>
ok
<beach>
Try something like IFNOT instead.
<beach>
(IFNOT <condition> <else> <then>)
<beach>
That's a very simple macro.
<beach>
And it can't be done as a function.
<Elronnd>
tada!
<Elronnd>
(defmacro ifnot (a b c) `(if (not ,a) ,b ,c))
<beach>
There you go. Or `(if ,a ,c ,b)
<emaczen>
Elronnd: A good macro example is to make one that implements the basic SQL query statements select from where group-by having order-by ...
<beach>
Elronnd: For macrology, I recommend the book "On Lisp" by Paul Graham. It is available online for free.
<emaczen>
Elronnd: implement each statement as a function
<emaczen>
Elronnd: Then make a macro called "select"
Kaisyu has joined #lisp
<jcowan>
(Another use case for a macro is when you need to force inlining and the compiler is refusing to do it.)
<beach>
That sounds like a very bad idea.
<emaczen>
Elronnd: Then it can be really cool if you have any tabular data in a program you are writing to use your implementation of a small SQL query language
<beach>
emaczen: That might be a tad too complicated for someone who only recently successfully finished the IFNOT macro.
<Elronnd>
also, I don't *really* know sql
<Elronnd>
I used it very minimally, once
<beach>
Yeah, that too.
<emaczen>
Elronnd: Ahh, well keep it in the back of your mind
didi has joined #lisp
<Elronnd>
is it possible to use a macro as an argument to apply?
<jcowan>
beach: that assumes that the compiler always knows better than the programmer. But if that were the case, there would be no need for the INLINE and NOTINLINE declarations, especially the latter.
<Elronnd>
didn't work when I tried it
<jcowan>
Elronnd: No.
<emaczen>
Elronnd: I made a bunch of really small macros too when I started, and then a few months later I implemented a small SQL language
<Elronnd>
then how should I implement similar functionality? Eval?
Lycurgus has quit [Quit: Exeunt]
<didi>
How do I construct a struct for which there is no constructor function? Say (defstruct (foo (:constructor nil)))
Kundry_Wag has joined #lisp
Tordek has quit [Ping timeout: 252 seconds]
<emaczen>
Elronnd: A great class of macros to learn about and implement are "anaphoric" macros
Kundry_Wag has quit [Ping timeout: 268 seconds]
xkapastel has quit [Quit: Connection closed for inactivity]
<Elronnd>
ok
Tordek has joined #lisp
<pillton>
emaczen: Really? I thought anaphoric macros split the community in two.
flazh has quit [Ping timeout: 246 seconds]
<emaczen>
pillton: Why? I implemented aif, really liked it and then implemented acond, acase and atypecase
azimut_ has quit [Ping timeout: 244 seconds]
azimut has joined #lisp
<emaczen>
pillton: It is way too tedius to not have anaphora
<beach>
jcowan: The use for NOTINLINE is so that the client can be sure that it is not necessary to recompile callers when the function changes.
<beach>
jcowan: That is something the compiler can not guess.
<pillton>
emaczen: It is contentious as the macro determines the binding rather than the user.
<beach>
Elronnd: Seriously, have a look at "On Lisp".
<emaczen>
anaphoric macros are covered in "On Lisp"
<beach>
emaczen: Don't turn the implication around, please.
<beach>
It is not just because it is covered in that book that it is good.
<beach>
There can still be things in that book that are good.
<beach>
Elronnd: It's a good book. It explains the pitfalls of macro writings, such as order of evaluation and multiple evaluation.
<emaczen>
beach: I don't think I implied that, Elronnd can learn about them there.
<beach>
Yes, but they are usually not a great idea to use.
<beach>
They are fun for illustration, though.
<emaczen>
beach: Can you explain to me why anaphoric macros are bad?
<beach>
pillton already did.
<beach>
emaczen: Also, I didn't say they are bad.
<pillton>
emaczen: Furthermore, they don't compose.
flazh has joined #lisp
<emaczen>
I've only implemented aif, acond, acase, and atypecase
<beach>
emaczen: I said that they are usually not a great idea. That means that there are better ways in most cases. Letting the user supply the variable to bind is often a much more scalable way.
<beach>
emaczen: Implementing them is a good exercise.
<emaczen>
if cond case and typecase don't compose do they?
<beach>
?
makomo has quit [Ping timeout: 240 seconds]
<pillton>
Cond, case and typecase don't introduce new bindings.
<beach>
emaczen: Here is another reason AIF (and similar) is a bad idea: The expectations of the person reading the code is that the condition in an IF form be a Boolean. for AIF to be useful, it has to be a form with some arbitrary value. So that is a direct violation of the expectations, and the LUV slides by Norvig and Pitman explain (slide number 13 in particular).
<emaczen>
beach: I think #'find is a good usage for AIF
<beach>
Can you give a short example?
<beach>
Oh, you mean its implementation?
<emaczen>
just any function that returns either a value or nil
<emaczen>
when find fails it returns nil
<emaczen>
aif allows you to store that result in a binding named it
<emaczen>
We do it all the time in English...
<emaczen>
pun intended lol
<beach>
emaczen: Again, for AIF to be useful, the condition must be a form that returns something other than T or NIL, and that is a direct violation of the expectations of the person reading the code, as slide number 13 explains.
pjb has joined #lisp
<beach>
emaczen: I know what AIF does.
<beach>
emaczen: I suggest you read those slides.
Kundry_Wag has joined #lisp
<russellw>
I often use generalized booleans in conditions anyway, even when I'm not using anaphors
<beach>
russellw: Can you give an example?
<russellw>
Sure. In Lisp, I find the most common example is a recursive function or loop working its way through a list, checking to see whether there are more elements to process: just use my-list as the conditional, instead of (not (null my-list))
<beach>
russellw: That is also a direct violation of the expectations of the person reading the code, as slide number 13 explains.
<beach>
I absolutely never do that.
<russellw>
beach, that depends on the person reading the code :) this difference in style is not confined to lisp; in Algol family languages, you would be on the Pascal side and I would be on the C side
<beach>
russellw: It definitely should NOT depend on the person reading the code.
<russellw>
But empirically it does, because I do not have the expectation that you suggest
<beach>
russellw: That would totally against the idea of widely adopted conventions.
anewuser has quit [Ping timeout: 264 seconds]
<beach>
It is funny how all these discussions always turn from the general idea to "Well *I* prefer...", showing a total disregard for conventions.
Kundry_Wag has quit [Ping timeout: 252 seconds]
<beach>
russellw: Maybe you don't expose your code to others. So that is fine then.
<russellw>
Actually, I'm afraid you're the one disregarding the conventions built into the language. If this were scheme, you could make that claim. But in common lisp, I am right and you are wrong; the language is explicitly designed to support my style.
<beach>
Fine.
<russellw>
So if you are going to carry on like that, you know where to find scheme
<beach>
russellw: Make sure you transmit that message to Norvig and Pitman as well.
<emaczen>
Was Norvig on the original committee?
<beach>
I don't know. Why does it matter?
<beach>
He is a brilliant software engineer.
<russellw>
Pitman's memoir of his time writing the language standard is instructive: to his credit, he was very careful to keep his personal preference separate from the consensus that went into the language design
<beach>
There is a huge difference between "grammatical phrases" of a language, and "idiomatic phrases". The people designing a language only do the former. The latter is a matter of conventions that are established over time. The idiomatic phrases represent a tiny subset of the grammatical phrases. So thinking that all grammatical phrases are idiomatic is a big mistake.
<emaczen>
I was just curious as to what the language designers had in mind, because generalized booleans do seem to be part of the language since anything but nil evaluates to true
<beach>
But I'll be quiet now.
ryan_vw has quit [Ping timeout: 264 seconds]
<emaczen>
Beach: I see your poin
<emaczen>
point*
zigpaw has joined #lisp
Oladon has quit [Quit: Leaving.]
fikka has joined #lisp
fikka has quit [Ping timeout: 252 seconds]
pjb has quit [Ping timeout: 264 seconds]
Kundry_Wag has joined #lisp
aindilis has quit [Ping timeout: 245 seconds]
Lord_of_Life_ has quit [Ping timeout: 252 seconds]
mathrick_ has joined #lisp
aindilis has joined #lisp
mathrick_ has quit [Remote host closed the connection]
mathrick_ has joined #lisp
Kundry_Wag has quit [Ping timeout: 245 seconds]
mathrick has quit [Ping timeout: 264 seconds]
frodef has joined #lisp
<gendl>
Hi, who feels like debugging something which looks like lots of fun in CCL (this is for the common-lisp.net site builder).
dale has quit [Quit: dale]
<gendl>
Ok great. Thanks for offering. the steps to reproduce are real easy:
<gendl>
Welp, this is a bit embarrassing. I need to get myself more automated with keeping my impls up to date. Maybe should be hooking up with Portacle or cl-travis or something...
frgo has joined #lisp
<gendl>
how many impls does Portable provide?
<gendl>
and cl-travis - is that just for running test pipelines online? Do they also maintain downloadable installations?
<gendl>
Portacle*
vlatkoB has joined #lisp
<russellw>
between (mapcar (lambda (x) (f a x)) xs) and (loop for x in xs collect (f a x)) is just a matter of taste, right? No reason to e.g. expect one to run faster than the other?
<|3b|>
no portable reasons
varjag has joined #lisp
<|3b|>
(you could expect the LOOP to know XS is a list, or the LAMBDA to add a function call, but implementations might not take advantage of the extra knowledge, or might optimize away the extra function call)
<russellw>
makes sense, thanks
<gendl>
What I know is Paul Graham says "The use of Loop cannot be recommended."
<|3b|>
gendl: so sounds like a vote in favor of loop?
<gendl>
I read that sentence in 1996 or 1997, and have not used loop since.
<russellw>
School of thought that dislikes loop for being not lispy enough?
<gendl>
Oh, don't we like Paul Graham here?
<|3b|>
wasn't he the one who also didn't like clos?
<gendl>
Well I for one can never decypher loops when I see them. But maybe that's cause i never use them.
<russellw>
Personally loop is one of my favorite features of the language, but I'm aware not everyone shares my taste in this regard
<gendl>
I suppose loops can be more efficient in terms of not creating a bunch of intermediate lists when mapping stuff.
* |3b|
likes LOOP, and finds iterate hard tor ead
stereosphere has joined #lisp
<|3b|>
the various MAP functions are OK, if you happen to have a function ready
<russellw>
Paul Graham didn't like clos, but that's not because he thinks it's a bad object system, it's just that he doesn't like object-oriented programming in general
<gendl>
but i've never detected that kind of thing to be a bottleneck.
<|3b|>
yeah, lisps tend to optimize for short-lived garbage
* russellw
agrees with |3b|, I use map if I can just supply the name of a function
<russellw>
otherwise I find loop more readable
<|3b|>
main other place i use map is when i don't know sequence type
<gendl>
One of my issues these days is dealing with legacy ICAD code which had a proprietary iteration thing called `let-streams`
<russellw>
good point
<|3b|>
lack of 'sequence' iterator is a big weakness of LOOP, along with lack of portable extensibility
varjag has quit [Ping timeout: 244 seconds]
<gendl>
apparently back in the day, the whole `let-streams` was a competing idea with something else which also didn't make it into the standard -
<gendl>
but there's a portable library which implements the other thing
<phoe>
gendl: I use Roswell as an implementation manager. I consider it to be mature enough by now.
<gendl>
phoe: how many impls does it manage?
<phoe>
gendl: one second...
<gendl>
sorry i shouldn't ask you to do my legwork...
<phoe>
looks like it manages abcl, allegro, ccl, clasp, clisp, cmu, ecl, lw, mkcl, sbcl
<phoe>
no no, it's just one command call for me
<phoe>
$ ros list versions
<phoe>
so I think all the alive contemporary ones
<gendl>
oh gheez, i've been out of touch. When SANO first presented it I think it was just doing SBCL
<gendl>
and on Windows, Linux, Mac?
<phoe>
though I have no idea if it manages free or pair versions of ACL and LW.
<phoe>
Hm, one second
<phoe>
Linux for sure
<gendl>
yeah i need full version of at least Allegro
<phoe>
There are Linux, macOS and Windows entries there
<phoe>
So I guess that all are supported.
<gendl>
holy crap i need to look into this.
<phoe>
As for full versions, I don't know - you could open an issue to ask about that.
<phoe>
Or just make it download allegro from wherever it downloads it, and then remove the downloaded binary and symlink it to your original full one. (:
<phoe>
should work, I think.
<gendl>
well, i'd like to automate the downloading of the original full one too!
<phoe>
roswell still tends to explode once in a while (especially during installation), but it's generally stable enough for my use.
<phoe>
oh, I see
<gendl>
but you have to accept license agreements even to download it (even though it's not functional without a valid license key file)
<phoe>
in that case ask on its github - I don't know if they have any support for that.
<gendl>
but Allegro is constantly being patched - they have a (sys:update-allegro) which you're supposed to run on each platform, which pulls down all the bits, then you run an ./update.exe or ./update.sh to build new images.
<gendl>
That gets to be tedious on at least (* 3 2 2) platforms (Windows, Linux, Mac) x (SMP non-SMP) x (32-bit 64-bit)
<gendl>
although I think we're pretty much done with 32-bit
<gendl>
and hope we can be done with non-SMP soon.
<oni-on-ion>
is there a way to do (defmethod + ((string a) (string b)) ..) so that for eg. (+ "abc" "def") is "abcdef" ?
<phoe>
oni-on-ion: nope
<oni-on-ion>
ok
<phoe>
unless you shadow +
<phoe>
#'CL:+ is a standard function and cannot be redefined.
<phoe>
but, you may want (uiop:strcat "abc" "def")
<oni-on-ion>
ah, then call-next-method ? but + is not a method ? would defgeneric be required
<oni-on-ion>
hmm. =)
<phoe>
yes, + would need to be a generic function.
<phoe>
and it's not.
<phoe>
but UIOP is present on every sane contemporary Lisp, so you can use it.
<gendl>
anyway it'd be nice just to do a `git pull` and keep all impls up do date. The whole Allegro (sys:update-allegro) thing appears to be from the old days when people really had to minimize bandwidth so they avoid having you have to download the built images.
<oni-on-ion>
alright
<oni-on-ion>
can't mix generic method and function/macro hmm. thats ok, will shadow or use uiop if need to do this
shrdlu68 has joined #lisp
<gendl>
I'll just take this opportunity to mention that github is still down (https://status.github.com/messages) meanwhile gitlab.common-lisp.net continues happily serving repositories and welcoming new ones.
<shrdlu68>
Good morning, commoners!
shka_ has joined #lisp
<shka_>
good morning
flamebeard has joined #lisp
<shrdlu68>
shka_: Some improvement: Implementing my own bit-vectors and hash function gets me ~4s faster.
<shka_>
ok
<shrdlu68>
That is, using sbcl's hash-tables extensions.
<shrdlu68>
Using my own hash-table, I'm 1s faster, but with some promising paths for improvement. All this, without the benefit of inlining yet.
<beach>
Hello shka_.
<beach>
oni-on-ion: It would have been difficult to make + generic since it has a variable number of arguments. The way Dylan did it, was that it specified that + calls binary-+ which was specified to be generic.
<shrdlu68>
The function sb-c::check-ds-list has 545 samples. My top function has 2055, for comparison. I've looked at that function's source, but I can't tell what it's for.
<shka_>
shrdlu68: interesting
<shrdlu68>
At first I used murmurhash for hashing, but, to my astonishment, a function I clobbered together turned out to be faster and have less collisions.
<oni-on-ion>
beach: ahh, true! forgot about + being vararg
<shka_>
shrdlu68: that is not so surprising!
Posterdati has joined #lisp
<Posterdati>
hi
robotoad has quit [Quit: robotoad]
<beach>
Hello Posterdati.
<Posterdati>
please help, how can I capture the output of a linux process launched by uiop:program from a bordeaux-threads thread?
<phoe>
Posterdati: there is no uiop:program
<Posterdati>
I used :output *standard-output* but the output stay mute
<phoe>
there's either launch-program or run-program
<Posterdati>
uiop:run-program sorry
<Posterdati>
please help, how can I capture the output of a linux process launched by uiop:run-program from a bordeaux-threads thread?
<phoe>
sharpsign macros are dispatch reader macros; dispatch, because the reader macro function on #\# dispatches on the character that comes right after it
<phoe>
oh, this looks like something custom-introduced
<phoe>
is this from LoL? if yes, then it's likely defined somewhere earlier in the book
kushal has quit [Ping timeout: 256 seconds]
SlashLife has quit [Ping timeout: 252 seconds]
<LdBeth>
that's what I feel unfair about: ask a newcomer on features not defined in standard language report
<oni-on-ion>
phoe: ahh, so like 'keymaps'
<phoe>
LdBeth: Let over Lambda is *not* a book for newcomers
<phoe>
it's a book for people who are already somewhat competent in Lisp and want to broaden their knowledge about Lisp macros and learn a few tricks about them
<oni-on-ion>
Land of Lisp
<phoe>
oh wait
<phoe>
is that screenshot from Land of Lisp? really?
<phoe>
(also, yes, we have colliding names, LoL stands for both Let over Lambda and Land of Lisp)
<LdBeth>
phoe (IRC): yes, so even seasoned programmer can get confused
<LdBeth>
lol
<shrdlu68>
Let over Lambda: Ein Buch für alle und keinen.
<phoe>
Xach: I'd like to request download stats for Quicklisp
<shka_>
LOL is not lol!
kdas_ is now known as kushal
angavrilov has joined #lisp
<oni-on-ion>
also stands for.. =)
scymtym has joined #lisp
ryan_vw has joined #lisp
<gendl>
i never knew of LOL is "Lots of Laughs" or "Laugh out Loud"
<oni-on-ion>
out loud; it was important back in the day to distinguish
orivej has quit [Ping timeout: 244 seconds]
SlashLife has joined #lisp
montxero has quit [Quit: Lost terminal]
Kundry_Wag has joined #lisp
nirved has joined #lisp
HDurer has quit [Remote host closed the connection]
SlashLife has quit [Max SendQ exceeded]
Kundry_Wag has quit [Ping timeout: 240 seconds]
hhdave has joined #lisp
jochens has joined #lisp
ryan_vw has quit [Ping timeout: 264 seconds]
HDurer has joined #lisp
JohnMS_WORK has quit [Read error: Connection reset by peer]
<shrdlu68>
Create an output stream and see if you get back a string?
<phoe>
Posterdati: have you tried simple-inferiors?
<Posterdati>
phoe: no!
<phoe>
I think you should - it seems to have solved the problem you're facing now
<Posterdati>
phoe: nice, I'm going to try it then
<Posterdati>
thanks
easye has joined #lisp
fikka has joined #lisp
easye has quit [Remote host closed the connection]
easye has joined #lisp
<jackdaniel>
Posterdati: wget outputs to stderr not to stdout
<shrdlu68>
He should still see something: "Also :output means redirecting the error output to the output stream, in which case nil is returned."
fikka has quit [Ping timeout: 264 seconds]
<jackdaniel>
shrdlu68: I don't see uiop's run-program having default value :output for the error-output
<jackdaniel>
tbh I find uiop's layer for run-program a total mess (especially when it comes to streams: slupring, mangling and other error-prone walls of code) - I usually use run-program provided by the implementation directly
<jackdaniel>
or a portability layer external-program
<shka_>
oni-on-ion: i suggested dexador already, but Posterdati insist on wget
<oni-on-ion>
ah=)
Kundry_Wag has joined #lisp
zfree has quit [Quit: zfree]
<jackdaniel>
Posterdati: maybe I didn't suggest it clear enough: try using your implementation's run-program, not uiop's
<jackdaniel>
for sbcl it will be sb-ext:run-program, for ccl it is ccl:run-program nad for ecl it is ext:run-program
<jackdaniel>
all three have almost identical interface
Kundry_Wag has quit [Ping timeout: 252 seconds]
<jackdaniel>
and as of simple-inferiors, it is the first time I head about this library
<jackdaniel>
and if it does the same thing as external-program and uiop, then that could be seen as a nih syndrome
JohnMS_WORK has quit [Read error: Connection reset by peer]
JohnMS_WORK has joined #lisp
<phoe>
jackdaniel: it seems to be based on UIOP and specifically solves the issue of capturing process output
<phoe>
and external-program is superseded by UIOP, AFAIK
rumbler31 has joined #lisp
python476 has joined #lisp
<jackdaniel>
phoe: external-program is just a portability lyaer for implementation-specific run-program
<jackdaniel>
uiop is a spaghetti with its own code accidently using implementation-specific extensions
<jackdaniel>
it could use some work, but my point is that external-program aims to be minimal abstraction unlike uiop in this regard
<jackdaniel>
but sure, UIOP wants (and claims to) supersede many libraries
rumbler31 has quit [Ping timeout: 264 seconds]
heisig has joined #lisp
orivej has joined #lisp
esrse has quit [Ping timeout: 264 seconds]
hhdave has joined #lisp
trittweiler has quit [Ping timeout: 252 seconds]
Kaisyu has quit [Quit: Connection closed for inactivity]
SaganMan has joined #lisp
m00natic has joined #lisp
nowolfer has quit [Quit: leaving]
ebzzry has quit [Read error: Connection reset by peer]
zfree has joined #lisp
ebzzry has joined #lisp
dueyfinster has joined #lisp
rozenglass has joined #lisp
Essadon has joined #lisp
<Posterdati>
I used drakma as suggested by oni-on-ion
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
<shka_>
Posterdati: and it just works?
Kundry_Wag has joined #lisp
<jdz>
Why would drakma not "just work"?
Kundry_Wag has quit [Ping timeout: 240 seconds]
<shka_>
jdz: it should!
<Posterdati>
shka_: worked with jackdaniel hints
dddddd has joined #lisp
Kundry_Wag has joined #lisp
Kundry_Wag has quit [Ping timeout: 252 seconds]
Lycurgus has joined #lisp
cylb has joined #lisp
<jcowan>
Obviously LoL and LoL belong to different packages
<jcowan>
beach: Your reference to Scheme preferring strict to generalized booleans is incorrect; generalized booleans (where #f is false and everything else, including (), is true) are common in Scheme
<jcowan>
Indeed, there is slightly better support for them than in CL. Scheme adds to the classic cond-clause another type of the form (<test> => <expr>) where expr must evaluate to a procedure. If <test> is true, then its value is passed to the procedure, and whatever it returns is the value of the cond.
<beach>
jcowan: I don't think I would have had any opinions about Scheme.
<beach>
Not here, at least.
<beach>
You must confuse me with someone else.
<jcowan>
sorry, my bad; s/beach/russelw
<beach>
Oh, what a mistake!
scymtym has quit [Ping timeout: 260 seconds]
nirved has quit [Ping timeout: 264 seconds]
<jcowan>
Eh, in f2f conversation I once misattributed a remark to Northrop Frye; it turned out to have been published by the person I was speaking to! "All die. Oh, the embarrassment."
Folkol has joined #lisp
xkapastel has joined #lisp
Josh_2 has joined #lisp
nirved has joined #lisp
Kundry_Wag has joined #lisp
schweers has joined #lisp
orivej has quit [Ping timeout: 245 seconds]
Kundry_Wag has quit [Ping timeout: 245 seconds]
<russellw>
Ah, I didn't know about that feature of scheme. Fair enough!
MetaYan has joined #lisp
anewuser has joined #lisp
python476 has quit [Remote host closed the connection]
scymtym has joined #lisp
logicmoo has quit [Ping timeout: 264 seconds]
dmiles has joined #lisp
scymtym has quit [Ping timeout: 276 seconds]
igemnace has quit [Remote host closed the connection]
igemnace has joined #lisp
nirved is now known as Guest61411
Guest61411 has quit [Killed (leguin.freenode.net (Nickname regained by services))]
nirved has joined #lisp
svillemot has quit [Quit: ZNC 1.6.5+deb1+deb9u1 - http://znc.in]
hvxgr has quit [Quit: leaving]
Kundry_Wag has joined #lisp
didi has joined #lisp
<didi>
Uh, so the slides "Tutorial on Good Lips Programming Style", by Norvig and Pitman is a treasure trove.
<beach>
It is.
<beach>
Especially since I believe those two people have more experience in software development, including in an industrial setting, than most people who hang out here.
groovy2shoes has joined #lisp
<didi>
Unfortunately, as slides go, it's too terse to read out of context. I wish it was an article, or even a book.
<beach>
I totally agree.
vlatkoB has quit [Remote host closed the connection]
Cymew has quit [Remote host closed the connection]
Cymew has joined #lisp
scymtym has joined #lisp
<beach>
Personally, I have way less experience than Norvig and Pitman do when it comes to software development, and way way less experience than they do when it comes to software development in an industrial context. I would therefore not dream of making rules contrary to their recommendations. I would rightly be accused of hubris if I did.
<phoe>
Xach: thanks! Will they be published on the blog?
<Xach>
phoe: possibly!
<phoe>
<3
<phoe>
also, I have a different question - can I get stats for not just the top 100? I'm thinking of using theis data to find some interesting projects that are not in the top 100.
<Xach>
sure, hang on
<Xach>
phoe: the file is updated
sjl has joined #lisp
Folkol has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
HighMemoryDaemon has joined #lisp
<schweers>
The style guide by Norvig and Pitman says one should be as specific as
<schweers>
data abstractions warrant, but no more. I get why one should not be overly
<schweers>
disadvantage. Am I missing something?
<schweers>
specific, but why not more abstract? I only see performance reasons as a
<schweers>
Ugh, what did ERC do there?
<shrdlu68>
I have code like (and foo (aref foo n)), which violates their style guide.
cylb has quit [Remote host closed the connection]
<HighMemoryDaemon>
What's the reason SBCL doesn't have a bash-like REPL? (By that I mean features such as C-l to clear, up/down error keys to go through your history, etc) Doesn't matter too much when you have Emacs+SLIME but I'm still curious.
cylb has joined #lisp
LiamH has joined #lisp
<shrdlu68>
They would rather (if foo (aref foo n))
<jackdaniel>
schweers: code is primarily meant for reading. this is an additional hint for the reader (which may be the same person) of what he deals with
<schweers>
I’m not sure I’m satisfied by that answer. Depending on the algorithm it shouldn’t really matter if I pass in a list or vector.
<schweers>
warweasle has joined #lisp
<beach>
shrdlu68: No, (unless (null foo) (aref foo n)), or even better (if (null foo) (error..) (aref foo n))
<schweers>
jackdaniel: not sure why a sequence is less clear than a list or vector
<Xach>
schweers: i don't know what they had exactly in mind, but one example that i think of is asdf's original design for interaction
<shka_>
schweers: if your algorithm is stand-alone then sure
<Xach>
schweers: to use asdf, you would do (asdf:operate asdf:operation thing)
<beach>
schweers: The situation they are referring to is that the reader of the code should get as much information as early as possible when reading the code.
<shka_>
but if it is part of something that is meant to work on just vectors, fail early
<Xach>
schweers: this was quite general but in practice there was only only a couple frequently-used operations
<jackdaniel>
schweers: if you are 100% certain that it will be a simple vector, then using svref in the code passes that knowledge to the reader. I find such hints very useful when I try to understand what's going on
<Xach>
HighMemoryDaemon: i think it has to do with the availability and use of readline
<shrdlu68>
beach: The unless form seems more convoluted to me.
<sjl>
HighMemoryDaemon: you can also use rlwrap to add the nice editing functionality, so that's another reason reason it's not worth bothering.
<beach>
shrdlu68: Sorry to hear that.
<schweers>
Ah, so if this one operation works with -- say -- both lists and vectors, but other parts of the library will work only with one of the two, one should prefer a specific operation?
<schweers>
<ggole>
Almost all style guides proscribe some amount of reasonable code
<HighMemoryDaemon>
sjl: That's pretty neat. Just gave it a try.
<schweers>
I think it`s beginning to make more sense, thanks guys!
<jackdaniel>
that could be an illustration where such information would be beneficial, but I didn't have exactly that in mind
<HighMemoryDaemon>
Xach: Interesting. By availability do you mean platform support?
<sjl>
HighMemoryDaemon: yeah, it's a handy tool to have around.
nly has joined #lisp
rumbler31 has joined #lisp
<Xach>
HighMemoryDaemon: platform and installation support
<phoe>
Xach: thanks!
rumbler31 has quit [Remote host closed the connection]
<phoe>
He seems to be using SBCL internals to generate log messages with source locations.
<phoe>
The symbol is still present in 1.4.11 - is it removed from the version you are using?
pjb has joined #lisp
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
meepdeew has joined #lisp
meepdeew has quit [Ping timeout: 240 seconds]
<Xach>
phoe: SBCL 1.4.12.108-f7df95e does not have it
<Xach>
the version is at the top of the report
dale_ has joined #lisp
dale_ is now known as dale
<phoe>
Xach: got it
<phoe>
then the symbol was removed, and this is why the projects break now
<phoe>
the most simple workaround is to comment out that #+sbcl form; a proper fix would be to ask #sbcl what functionality should be used for source locations now.
shka_ has quit [Quit: WeeChat 1.9.1]
<phoe>
I'll upgrade to 1.4.12 and try to check that.
wanz has joined #lisp
JohnMS_WORK has quit [Ping timeout: 240 seconds]
JohnMS_WORK has joined #lisp
* jcowan
reads the Norvig slides
<jcowan>
Is two-armed cond really considered a Bad Thing?
<phoe>
if it's replaceable by an IF, then no need to use a COND
<jcowan>
I think a cond is more readable than (if (progn (this) (that)) (progn (these) (those)))
<phoe>
wait, why a progn in the test
<jcowan>
(oops, left out the test)
<jcowan>
s/if/if (test)
<phoe>
ooh, if you have multiple forms in each if branch
<phoe>
that's when I use a cond
<jcowan>
just so
<phoe>
(cond (x (foo) (bar)) (t (baz) (quux)))
<phoe>
it's more readable than IF with two PROGNs.
anewuser has quit [Quit: anewuser]
<phoe>
(at least to me)
<jcowan>
right
<jcowan>
even if it's just one or the other if branch that needs multiple forms, I prefer cond
<phoe>
Xach: 1.4.12 *still* has that symbol
<phoe>
so it must be some newest commit that removed it
<phoe>
I'll ask on SBCL
wanz has quit [Quit: wanz]
<jcowan>
I never got an answer to the question about the propriety of using qualified internal symbols (other than for testing, debugging, etc.)
<jcowan>
seems like it would be a code smell to me: if you need outside access, export the symbol
<phoe>
that symbol was external
<phoe>
though it was exported from SB-KERNEL, so, theoretically still internal
<jcowan>
I meant in general
<jcowan>
it seems like an invitation to let your code break
<pfdietz>
I agree; :: is a code smell.
flamebeard has quit []
nowhere_man has joined #lisp
<jcowan>
I'm kicking around ideas for adding modularity to ISLisp. I think that DEFPACKAGE and IN-PACKAGE suffice (and can be implemented without having packages at runtime).
<jcowan>
And single colons only (currently : is reserved in ISLisp identifiers)
<pfdietz>
I ask because the global package namespace is a source of real aggravation in CL. Collisions are rampant in quicklisp.
FreeBirdLjj has quit [Remote host closed the connection]
Inline has quit [Read error: Connection reset by peer]
Inline has joined #lisp
<Xach>
pfdietz: I don't often see people write about encountering the conflicts in real life.
<Xach>
pfdietz: it may be that they don't write about it, but it happens often enough.
<pfdietz>
I guess my use case was weird. :)
<gendl>
pfdietz: wasn't there some effort to portableize Franz' package-local hierarchical package names?
<Xach>
Sure. I think it would be nice if there were no conflicts.
<gendl>
Also what about asdf systems names? Those can get collisions too. How about system-local systems...
<gendl>
But, I know not much of what I speak. It could be opening cans of worms that we'd best not.
<pfdietz>
ASDF system names can be made long without great pain, so collisions can be largely avoided.
<gendl>
Having the possibility of conflicts also forces people to collaborate more, which might have its upsides.
varjag has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<Xach>
I think package-local nicknames would be nice. I think they should be implemented differently from how they are right now.
<pfdietz>
But the package namespace includes concise nicknames, which are much more prone to collision.
<pfdietz>
PLN is what I want to see also.
<gendl>
pfdietz: yep, pretty much where ever I've had problems, it's been with nicknames.
<Xach>
pfdietz: I've been working on a design that does not involve any new packages, but only new keyword arguments and return values from existing standard functions.
* Xach
wishes to finish it to get feedback
<Xach>
I'd like a system that can be used without loading portability packages or shims or anything like that.
<gendl>
jackdaniel: regarding UIOP and its notion of superseding several other targeted portability libraries, I understand that other targeted ones can have more purity and appear less "accidental," but from a practical standpoint, uiop is so ubiquitous and necessary for asdf (as long as asdf remains predominant, which is a discussion for another day), as far as I'm concerned, the more of the routine portability stuff that can be
<gendl>
handled by UIOP, the better.
<pfdietz>
I have wondered if the global namespace(s) could be made more first class. A sort of internal containerization systems for Lisp.
<gendl>
so i'm hoping more people can make a sincere effort to understand and contribute maintenance and improvements to uiop & asdf, rather than simply dissing them.
<gendl>
I also wonder if there could be broken out a "diet" version of ASDF which doesn't deal with upgrading itself -
<pfdietz>
Curation and enrichment of QL systems seems to me to be an important area of focus for CL, perhaps the most important.
FreeBirdLjj has joined #lisp
Lycurgus has joined #lisp
<gendl>
how much simpler could a "lite" ASDF be if it could assume that it's being loaded into a clean image (or re-loaded on top of itself with the same version). From what I've seen over the years it seems like Faré had to dump inordinate amounts of resources into making ASDF be able to upgrade itself in-place from all kinds of ancient versions.
FreeBirdLjj has quit [Remote host closed the connection]
shka_ has joined #lisp
FreeBirdLjj has joined #lisp
<shka_>
good evening
<gendl>
By the way - PSA - UIOP is separated out from ASDF for a reason. Application and library code shouldn't be depending on anything form ASDF or its sub-packages. Application and library code can freely depend on UIOP stuff (that horse has pretty much left the barn).
<gendl>
Occasionally I'll run into a quicklisp library which still is assuming that ASDF is present, in places other than its .asd file. This kind of thing is easy to miss during development because ASDF is usually always there in development. But then things start failing when trying to make standalone executables and runtime builds.
<Xach>
gendl: people are often encouraged to use asdf:system-relative-pathname
<Xach>
I think even by the best-practices document
<gendl>
encouraged by whom?
graphene has quit [Remote host closed the connection]
<Xach>
gendl: the asdf documentation, common practice, advice here
<gendl>
Maybe use asdf:system-relative-pathname during development, isolated in development-only scripts and stuff
<Xach>
gendl: I also think asdf calls should not be present in project source code, but it's a tempting convenience.
<gendl>
but for what it's worth, I certainly can't recommend using that in an actual library source code. How can one assume that source code will even be available at runtime, to think that an asdf:system-relative-pathname will even exist?
graphene has joined #lisp
<Xach>
It fits a certain development style
rippa has joined #lisp
<gendl>
... a development style that assumes source code is always there with the application, all the time. That's an example of the kind of development style which keeps tending to isolate CL on its own little island.
* didi
recoils
SlashLife has joined #lisp
<Xach>
gendl: Yeah? Do you feel it's unlike javascript, python, ruby development in that regard?
<gendl>
I don't know enough about those.
<didi>
Perl, shell, haskell...
<gendl>
Well at least some of those are described as "scripting" languages, for example Python and Perl,
<gendl>
so it wouldn't be surprising to expect source code to be around all the time.
<Xach>
But it's enough to put CL on its own little island?
<gendl>
And people often (incorrectly) refer to CL as an "interpreted" language. Treating it like Python or Perl probably only serves to reinforce that misconception.
<Xach>
And put it on a little island?
<gendl>
Maybe "its own little island" doesn't really capture what I'm trying to say.
<gendl>
Maybe my point is more that with that style of CL development and deployment, the fact that it's Lisp is always in the user's face, whether they want or need to know about that or now
<gendl>
not*
<gendl>
Sometimes it's advantageous to be able to deploy a program and have it just run like any other program.
<gendl>
and not draw gratuitous attention to the fact that it's a "Lisp" program.
<gendl>
And regarding JS, Python, Ruby, Perl, shell, haskell: How many other languages make it a matter of routine to assume that their build system is always loaded and available during production running of an application.?
<Xach>
It would be helpful to have a guide to "how to write code so it can be easily delivered"
<gendl>
i mean, ... How many of those languages...
<Xach>
I don't think that's a primary motivating factor for many people, but it would be nice to know how, for those for whom it is
<gendl>
The fact that it's "not a primary motivating factor" for many people, to me, is a red flag, and one of the things that keeps CL out of the mainstream.
<Xach>
something as simple as a checklist of little things that make it harder would be handy
<Xach>
People are motivated by many things and I don't think "take CL mainstream" is high on the list for many people.
<shka_>
gendl: i guess programmability is not exactly mainstream anymore
<gendl>
shka_: I'm not sure what you're saying exactly.
<shka_>
gendl: how many languages assume that user is supposed to modify deployed application by editing the source code?
<gendl>
shka_: Ah I see what you're saying. CL applications are potentially programmable after they're deployed. Sure, that's a feature and it makes sense to take advantage of it in some circumstances.
kuwze has joined #lisp
<shka_>
it is a mindset
<gendl>
But I think the question is more of an application-specific one than a language-specific one.
<gendl>
the question should be "how many applications assume that user is supposed to modify deployed application by editing the source code?"
zfree has quit [Remote host closed the connection]
<gendl>
and the answer is X% of applications.
<gendl>
While in Y% of applications that would be neither helpful nor desired.
cage_ has joined #lisp
<shka_>
for Z% of users of those applications
<gendl>
The fact that CL can do both is a great testament to CL. But it doesn't mean that 100% of CL applications must therefore necessarily ship with a development and build environment built into them.
<gendl>
ok.. and that Z% of users can range anywhere from 0% to 100%, depending on the application domain and a bunch of other factors.
stereosphere has joined #lisp
kuwze has quit [Ping timeout: 256 seconds]
<didi>
I disagree with the "mainstream" statement, but I'm with Xach: an article about deploying applications would be nice.
<gendl>
I worked at Ford in ICAD in the 1990s. (ICAD was a CL based knowledge based engineering system with a solid modeler -- in principle an ICAD application could automate tons of manual CAD design). ICAD was able to demonstrate some fantastic, amazing, miraculous, unbelievable things from a development seat. But very few applications ever made it out into actual enterprise-wide mission-critical production. We sucked at actually
<gendl>
deploying anything into production. And I feel one reason for that is the environment is so geared toward development that it might even seem to actively _discourage_ production deployment.
* didi
wonders how Smalltalk handles it
<gendl>
And I suppose people are entitled to their opinions. This attitude of "well, CL people don't really have production deployment or mainstream acceptance as a priority" may be fact today, but nothing says it has to stay that way foreve.r
jochens has quit [Remote host closed the connection]
<didi>
gendl: I guess someone has to champion it.
jochens has joined #lisp
hhdave has quit [Ping timeout: 244 seconds]
<shka_>
gendl: i honestly think that you are making this issue to appear larger then it really is
dueyfinster has joined #lisp
jochens has quit [Ping timeout: 252 seconds]
<gendl>
shka_: maybe I'm making a mountain out of a molehill. Someone said it's a matter of subtle mindset, and I think that's right.
meepdeew has joined #lisp
<gendl>
But the practical ramification that started this rant is when things like `asdf:system-relative-pathname` show up in mainline application or library code.
<gendl>
I firmly stand by my opinion that that kind of thing should be avoided.
<gendl>
That is all.
<didi>
Hum. Can't we think of it as any other package?
<gendl>
didi: No. You can only think of it as a package which is available in a development mode, when all your ASDF systems are actually present.
<didi>
gendl: But despite it being ASDF, isn't it like, I don't know, ALEXANDRIA:FOO?
<gendl>
If you want your application to be forever bound by the baggage of its ASDF system and source codebase, then that is of course your right to do so, but it should be done deliberately with eyes wide open.
<gendl>
alexandria:foo is not assuming the presence of a certain ASDF system in your filesystem. It's just doing some generic portability convenience thing for you.
jkordani_ has joined #lisp
<gendl>
And by the way, a large percentage of what's in alexandria is likely available in UIOP as well.
cylb has quit [Remote host closed the connection]
cylb has joined #lisp
<gendl>
if UIOP can supersede cl-fad, alexandria, and several other little "trivial" libraries, I for one would find that a happier state of affairs.
FreeBirdLjj has quit [Remote host closed the connection]
jkordani has quit [Ping timeout: 252 seconds]
nowhere_man has quit [Ping timeout: 240 seconds]
jmercouris has joined #lisp
HighMemoryDaemon has quit [Remote host closed the connection]
Bike has joined #lisp
<gendl>
Xach: I appreciate the way you state facts as you see them (whether happy facts or not), you sometimes express your desires ("I wish.."), and you avoid idle speculation.
<didi>
gendl: I see. Thank you. Personally I don't use ASDF functions, but despite morally, I can't see it been different from any other package.
<Xach>
gendl: I think sometimes there is a tendency to reject good things because they are difficult, rather than because they are bad, and wishing for good things is my way of acknowledging what is good without talking about how likely they are to come to pass.
<gendl>
didi: Morals has nothing to do with it. I'm talking about practicality, and the concept that a developer should be aware of what assumptions he/she/it is making when doing certain things.
<didi>
gendl: I see.
<Xach>
"if tree shaking was so great then someone would already have done it for us, therefore tree shaking is bad"
<Xach>
or "easy delivery", or or or
<pfdietz>
Easy delivery = docker these days.
<Xach>
pfdietz: for some styles, yes
<gendl>
pfdietz: Do you think docker will eventually eliminate the need for languages (e.g. CL) to support certain OSs directly, (e.g. Windows)?
<gendl>
so we just target a single platform and let Docker deal with all portability issues? Or am I barking up the wrong tree?
<pfdietz>
I couldn't say.
<gendl>
Is that not one of the intended benefits?
<pfdietz>
I wonder what an OS would look like if it were intended to just run containers.
<shka_>
gendl: it kinda already did this
nowhere_man has joined #lisp
cylb has quit [Remote host closed the connection]
<gendl>
shka_: so you mean nobody is running CL on Macs or Windows directly anymore?
cylb has joined #lisp
<shka_>
gendl: no
<oni-on-ion>
pfdietz: these days the OS is just a container for the web browser OS.
<gendl>
pfdietz: maybe this is a discussion for a different channel, but is it usually 1 application per container? And we're talking about just server applications right? Like webservers or web API servers right?
<gendl>
and the benefit is that the 1 application can have all its runtime libraries installed and guaranteed to be there and guaranteed not to conflict with other ones for other applications, etc.
<pfdietz>
I guess you could call them server applications, but there's no reason they have to serve more than one client. The web browser provides the UI.
<oni-on-ion>
gendl: isnt that what users were for, quarantine ?
<shka_>
gendl: you can deploy desktop applications inside docker…
<shka_>
my colleague mad for instance complete portable development env in docker with all the libs, gcc, and good damn web browser included
<shka_>
and i was like
<shka_>
"i am not even mad, this is amazing"
<gendl>
shka_: how would a desktop application running in a docker on a Linux VM on a Windows host show up on that Windows desktop?
<shka_>
i have no idea
<shka_>
it was for linux
<gendl>
shka_: ok, then I'm confused by your statement "you can deploy desktop applications inside docker"
<shka_>
i can ask if that monstrosity worked on windows
<shka_>
because IIRC it was supposed to work
<jcowan>
In Flavors packages were strictly hierarchical, inheritance was strictly up the tree, and symbols had names like FOO:BAR:BAZ (no ::)
<oni-on-ion>
pfdietz: are docker 'services' typically serving just one client ? then i can see the benefits
varjagg has joined #lisp
<didi>
jcowan: But we still need to be careful to not clash the top level, right?
<gendl>
to me, docker sounds like a band-aid (maybe a necessary one) over a broken global ecosystem with a chaos of libraries, languages etc.
Lord_of_Life has quit [Ping timeout: 252 seconds]
<gendl>
To me, a CL application is already kind of its own "container" (if it's done properly). Containerizing a CL application inside another (docker) container might be belts & suspenders. But I speculate. I have to know more about docker before I speak more on this.
<jcowan>
The Java trick works well for Java, which has probably a thousand times as many publicly available packages, to say nothing of all the proprietary-nobody-else-cares ones.
<jcowan>
my tagsoup library, e.g. lives in org.ccil.cowan.tagsoup, and you can tell the compiler that tagsoup is a (local) nickname for this
<jcowan>
so perhaps what's really needed is scoped nicknames
<shka_>
gendl: in practice, many cl applications will require other stuff (like PG) to work
<gendl>
shka_: what is PG.
<shka_>
postgres
<edgar-rft>
Paul Graham
<jcowan>
more conflicting global nicknames!
<shka_>
heh
<shka_>
so if you can essentially save-lisp-and-die and have standalone binary, that's awesome
<jcowan>
java limits the nickname to be a suffix of the full name, which is weaksauce
<gendl>
That might make a good YC startup idea -- "containerize Paul Graham so we can replicate him across the Internet"
<shka_>
but it is not always the case
<didi>
Maybe something like (local-package foo ...) which rewrites every DEFUN as LABELS and God knows what else. /me shivers
<shka_>
gendl: jesus christ, graham should not be propagated any further :P
<edgar-rft>
I suspect very little Lisp stuff will need Paul Graham to work.
<gendl>
shka_: the last thing, then we'll drop the docker subject I promise, cause it certainly belongs in its own channel (which prolly exists here), but what's the basic diff between a container and a chroot environment?
<shka_>
gendl: branding
<shka_>
also, docker somehow works on OSX and windows with linux stuff
<buffergn0me>
I think some kind of system around package nicknames would be useful
<gendl>
Really? So it's essentially a branded chroot environment?
<buffergn0me>
If for nothing else than to support multiple conflicting library versions in the same image
m00natic has quit [Remote host closed the connection]
<shka_>
gendl: plus image format, plus ecosystem for deploying...
<shka_>
but it starts with chroot
<shka_>
at least on linux
<shka_>
on windows and osx i think that virtualization gets involved
<gendl>
shka_: well how it works on OSX and Windows is no big mystery - it's running a Linux VM.
<shka_>
well, ok
<buffergn0me>
So when loading a system, you would specify that package #:foo.bar.baz is a nickname for #:version-package-store.foo.bar.baz.2.7
<gendl>
The trick is that each container doesn't need to be its own whole VM. It's a chroot environment on that same VM. Much lighter weight than running so many actual VMs.
<shka_>
i never was interested in details
<buffergn0me>
Which could be extended to Nix-style hash trees for dependency versioning
<didi>
buffergn0me: Sounds like a plain to fragmentation and code rot, but I guess the availability of such feature isn't bad.
<didi>
s/plain/plan
jkordani has joined #lisp
Lord_of_Life has joined #lisp
<buffergn0me>
didi: The build system would handle the package renaming
<|3b|>
multiple versions available at once sounds nice at a coarse level (like separate applications having different versions of dependencies), but could get ugly if 2 things in same project used different versions
<|3b|>
like you try to handle foo:some-error, but the lib signaled foo-2:some-error and you tried to handle foo-3:some-error due to different versions
jkordani_ has quit [Ping timeout: 252 seconds]
* |3b|
wonders how hard it would be to inject versioned local nicknames into package-local-nicknames style, don't think i thought about that use case
<buffergn0me>
Yes, this is why this scheme needs to be done at the build system (ASDF) level
<|3b|>
so i guess it would just fail loading if they requested different versions?
<buffergn0me>
Basically a library would be loaded into #:version-package-store.foo.bar.baz.2.7 by the build system. The library still thinks it is #:foo.bar.baz, and the systems using the library would see it as #:foo.bar.baz
<|3b|>
incremental loading would be messy with that setup
<buffergn0me>
A single ASDF system would get a single version of the library
<|3b|>
you would have to version the entire tree, not just foo.bar.baz
graphene has quit [Remote host closed the connection]
<|3b|>
you would need foo.bar.baz loaded with foo.blah-1.2, foo.bar.baz loaded with foo.blah-1.3, etc
<|3b|>
if some other libs depends on foo.bar.baz with explicit dependencies on blah-1.2 and blah-1.3
graphene has joined #lisp
<buffergn0me>
Exactly. That's how Nix works
<|3b|>
so you have 2 different versions of foo.bar.baz.2.7 loaded at once
rk[ghost] has quit [Ping timeout: 252 seconds]
<buffergn0me>
With different dependencies
Kundry_Wag has joined #lisp
<buffergn0me>
The "name" of that package would include dependency information. Nix handles that using hash trees of the build info of each system
<jcowan>
cross-platform docker, btw, uses a virtual machine under the covers, but iirc there is only one vm for all containers in that situation
Kundry_Wag has quit [Read error: Connection reset by peer]
<pfdietz>
|3b|: this is what made me think about first class global environments. Load each library into its own internal-to-lisp sandbox, to avoid interference. There would have to be some mechanism for propagating information between these "worlds".
<|3b|>
i think you could do that with current package system, though would probably have to poke at asdf a bit to get fasl caching correct
<jackdaniel>
gendl: I'm not going to discuss many problems I have whenever I truly depend on UIOP, my point was that there are often better tools for a job (quality and/or abstraction-wise) and calling them superseded is unfair (especially in a context of discussion, where uiop fails due to abstraction-creep on run-program streams)
warweasle has quit [Ping timeout: 264 seconds]
<|3b|>
pfdietz: yeah, i can see wanting that sort of thing for some use cases
* |3b|
mostly is OK with just loading 1 version of everything though :)
<buffergn0me>
The question with environments is, should symbols share identity across them? Or is full virtualization of packages needed?
shrdlu68 has quit [Quit: WeeChat 2.2]
<gendl>
jackdaniel: I understand. "Superseded" is more of an aspiration than a reality in the present tense. I wish those better tools can eventually be merged into UIOP (assuming they are not so huge that they would bloat UIOP unreasonably).
<|3b|>
symbols name things, so if the things are distinct, the symbols must be distinct
<|3b|>
pretty much whole point of separating the packages would be to get separate symbols
<|3b|>
(packages are unrelated to the naming provided by symbols, they only map from text to symbol objects)
<pfdietz>
And to separate their effects on the global environment.
<pfdietz>
(other than packages)
<oni-on-ion>
superceded*
<gendl>
but I guess there's a philosophical question of whether UIOP wants to provide more than the bare minimum of what ASDF needs & uses. I think it's already doing that, though. For example I don't think ASDF exercises all the options of uiop:run-program.
<|3b|>
yeah, i guess you could have packages shared by multiple environments
Josh_2 has quit [Quit: ERC (IRC client for Emacs 26.1)]
<meepdeew>
Hi all, so towards the end of PCL Ch 20 (Special Operators), the writing gets into EVAL-WHEN, LOAD, COMPILE-FILE, etc..
<meepdeew>
It briefly touches on some of the differences between LOAD and COMPILE-FILE, and the implications.
<meepdeew>
For example, footnote 12 - why loading a lisp file with an IN-PACKAGE doesn't change the *package* for the context loading the file was illuminating for me.
<meepdeew>
But I'm still a bit unclear on some things addressed there, like what forms COMPILE-FILE must evaluate and why.
<meepdeew>
Can anyone recommend others writings, links, or resources to learn more about those areas specifically? Or is the really best (only?) way to just dig into the hyperspec and/ or implementation source code? It's struggling with these kinds of things that make me feel like I have blind spots and should go back and read SICP.
<Bike>
um, sicp isn't going to help with this.
<Bike>
the basic version is that compile-file evaluate, at compile time, toplevel forms in an EVAL-WHEN with the :compile-toplevel situation.
<Bike>
so if you look at the macroexpansion of (defmacro whatever ...) you'll probably see code wrapped in such an eval-when, so that the macro is defined during compilation.
warweasle has joined #lisp
<meepdeew>
Oh interesting, Bike, I'd actually never macroexpanded a defmacro form before.
<Bike>
keep in mind that the expansion is going to differ between implementations, and it's possible one will do something else
<jackdaniel>
gendl: I don't share your enthusiasm for "ubiquitous" solutions (disregarding what they are), but I'm aware it is a matter of a personal aesthetic
warweasle has quit [Remote host closed the connection]
<gendl>
jackdaniel: in general I agree, but the situation is that uiop is _forced_ to be ubiquitous by its nature and its role in supporting the (current) fundamental build system. It's run and exercised and tested constantly (still not enough to be sure, but more than your average QL library out there). So I wish there was not a perceived need to replicate so much of its functionality in other targeted libs.
<gendl>
i should say "still not enough, to be sure, ... "
<jcowan>
I don't understand this sentence: "The compiler must treat any binding of an undeclared variable as a lexical binding."
<jcowan>
How can it do that? A lexical variable is necessarily visible in the lexical scope.
<Bike>
meaning a binding of a variable not declared special
<gendl>
I suppose if UIOP could be an assembly of all the best targeted libraries (i.e. uiop.asd would just contain a bunch of :depends-on and importing/re-exporting symbols) rather than a monolithic thing, that could be an answer...
<jackdaniel>
gendl: The point is that it replicates other libraries functionality (and declares it, arogantly I'd say, deprecated). Also I don't consider m4 being anything but autoconf companion, but it is as popular on systems as uiop on asdf-enabled implementations
<gendl>
but again, that would open up UIOP to so many points of failure, by depending on so many little libraries, all with twisty passages going in different directions...
emaczen has quit [Quit: ERC (IRC client for Emacs 24.5.1)]
<jackdaniel>
I'd be much more at ease, if uiop were a library on ql and asdf/uiop were its copy in different package for asdf
<jackdaniel>
current state is that uiop is not updated, because uiop.asd is somewhere in implementation guts (which asdf finds), so ql doesn't see a need to download it (by default)
<gendl>
jackdaniel: I always keep a latest uiop/ in quicklisp/local-projects/
didi has quit [Remote host closed the connection]
<gendl>
but yes, ASDF has been a bit flakey as of late in terms of whether it see it there or not, especially for the monolithic-compile-op operations. Currently my build scripts have to manually prepend the uiop--system.fasl to the build result.
<jackdaniel>
I hope I've voiced my opinion, I agree to disagree about uiop's place
<gendl>
jackdaniel: yep, it's good to know all these opinions. Too easy to be doing things one way and end up thinking that's the only way.
flazh has quit [Read error: Connection reset by peer]
flazh has joined #lisp
johnjay has joined #lisp
<jcowan>
Bike: In what lexical scope is the undeclared variable assumed to be bound?
<Bike>
it's not.
<Bike>
i'm just reading this as saying, if the compiler sees a binding of a variable, and there's no declaration of that variable to be special, it's lexical.
<jcowan>
OIC, yes
<jcowan>
🧠 :fart:
<Bike>
so it can't, e.g., bind *foo* as special just because it has asterisks
<jcowan>
Sure
<jcowan>
"Names are but names", said Stallman to the novice
<jcowan>
What is the purpose of the :intern clause in DEFPACKAGE? (I know what it does, not why you'd use it)
<pjb>
jcowan: so you may create symbols.
<jcowan>
To intern a symbol in a package, it suffices to mention it. Under what circumstances would you wish to avoid mentioning it?
<pjb>
Packages are basically collections of symbols. So it's natural that you can enter symbols in them, when you create a package.
<pjb>
You would need to "read" the symbol while *package* is bound to that package.
<Xach>
jcowan: if you want to establish all your package definitions before loading any code.
<pjb>
Also, you may want to intern it preventively, to force conflicts if you later use or import a package exporting a symbol with the same name.
<Xach>
jcowan: if a package imports from another, the symbol has to be interned first.
<jcowan>
preventive interning makes sense to me
<pjb>
(defpackage "A" (:use) (:export "X")) (defpackage "B" (:use) (:intern "X")) (in-package "B") (use-package "A") #| ERROR: Using #<Package "A"> in #<Package "COMMON-LISP-USER">
<pjb>
x a:x
<pjb>
would cause name conflicts with symbols already present in that package:
<pjb>
|#
<pjb>
without the :intern, A could be used in B without error. This may not be what you want.
frodef has joined #lisp
* jcowan
nods
<jcowan>
However I don't understand the other argument. When you load the code, it is presumably within the (implicit) scope of an IN-PACKAGE and so will be interned at that time.
<pjb>
Not always.
<jcowan>
As for example?
<pjb>
You can have things like (in-package "BAR") (defun foo:f (x) (foo::g x x))
<jcowan>
In the first example, ISTM that (in-package "ASDF") would be better instead of qualifying every symbol being defined
<pjb>
This was an old program, without much structure to the code, and basically, circular dependencies between the packages, defined at run-time… Creating the asdf system was a daunting task of untangling this messy web. I had to use :intern to have those symbols existing to be able to import them in another package, line 352.
sigjuice has quit [*.net *.split]
sigjuice has joined #lisp
<pjb>
So granted, we'd rather write well structured programs, where the dependency graph between packages and modules is not circular. In which case, :intern might be less useful. But if you want to take advantage of the possibility to have circular dependencies between packages and use non-exported symbols in other packages, you may have to use :intern.
sbenitezb has joined #lisp
sbenitezb has quit [Client Quit]
jochens has joined #lisp
jochens has quit [Ping timeout: 264 seconds]
warweasle has joined #lisp
jmercouris has quit [Ping timeout: 240 seconds]
warweasle has quit [Quit: rcirc on GNU Emacs 24.4.1]
warweasle has joined #lisp
cage_ has quit [Quit: Leaving]
warweasle has quit [Quit: later]
aydio has joined #lisp
asymptotically has quit [Remote host closed the connection]
asymptotically has joined #lisp
<jcowan>
yeah, I guess I have never lived in a world of circular dependencies
emaczen has joined #lisp
aydio has quit [Ping timeout: 276 seconds]
<LdBeth>
hello everyone
makomo has joined #lisp
aydio has joined #lisp
aydio has quit [Client Quit]
aydio has joined #lisp
azimut has quit [Ping timeout: 264 seconds]
<Lycurgus>
yello LdBeth
<jcowan>
holloa
* Lycurgus
synchronistically just learned about conformal cyclic cosmology
dueyfinster has quit [Quit: My iMac has gone to sleep. ZZZzzz…]
anamorphic has quit [Quit: anamorphic]
azimut has joined #lisp
anamorphic has joined #lisp
<jcowan>
If I had to pick just one good thing about CL, it is the ability to write debuggers that make sense to non-programmers
<anamorphic>
What do you mean by that?
<phoe>
jcowan: I'd pick it being Common Lisp
void_pointer has joined #lisp
<jcowan>
Existenz ist kein Predicaet
<jcowan>
anamorphic: I mean the ability to have restarts with user-intelligible explanations that allow a user to say how to proceed from this point
<jcowan>
Most languages don't have restarts at all: they just give you a traceback and die
<phoe>
or, if that's not an acceptable answer, I'd pick the fact that all the partial features forming the language (homoiconicity, macros, conditions, restarts, CLOS, debugger, interactivity, livepatching, introspection, syntax macros, ..., ...) actually work together in order to empower the programmer on their task
<jcowan>
or catch it at a high level
pjb has quit [Ping timeout: 264 seconds]
<Bike>
restarts are nice. i haven't used a lot of the interactive features,though.
heisig has joined #lisp
<phoe>
oh, right - that's the ability for Lisp to notice when and what screwed up, present the user with available options, and then be able to unwind safely to a predetermined spot and continue execution from there
<jcowan>
Just so. I think that emphatically beats all the other features in a ranking of excellence, though I agree that the effects of the other features are synergistic
<cgay>
s/give you a traceback// (tracebacks are scary)
<jcowan>
Yes, not surprising considering where it comes from
<phoe>
the interactive debugger is awesome, correct.
<jcowan>
MIT Scheme has a lot of MacLisp features still surviving that other Schemes never adopted
<phoe>
including the ability to actually introspect the condition object using the Lisp inspector, which is an equally awesome mechanism (if not more!)
sunset_NOVA has quit [Quit: leaving]
<oni-on-ion>
ah interesting
<phoe>
and, from the condition object (or from the stacktraces!), inspecting subsequent Lisp objects that happened on the way to the final INVOKE-DEBUGGER call
<Bike>
imagining that mit scheme has hunks
sunset_NOVA has joined #lisp
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
<makomo>
speaking of the condition system, what would be a nice way to handle a signalled condition (using SIGNAL), log it somewhere and continue going as if nothing happened
<makomo>
i.e. F calls G and G uses SIGNAL to signal a condition
<makomo>
F wants to handle it, but only to be able to log it later on. it wants G to continue its work nonetheless
<phoe>
makomo: d'oh
<Bike>
just use handler-bind in F
<phoe>
(handler-bind ((condition (lambda (c) (format t "WAAH! A condition happened!~%~A~%" c)))) (foo))
<Bike>
if you don't transfer control, SIGNAL will just return NIL
<makomo>
the handler that does the logging shoudln't decline the handling, i.e. it should perform a non-local transfer. but i'm not sure if there's a "pretty" way to do that?
<phoe>
shouldn't decline the handling?
<phoe>
what do you mean?
<makomo>
a handler declines to handle a condition by returning normally
<phoe>
"continue going as if nothing happened" - what do you mean by that?
<Bike>
"declining" just means that another higher level handler can deal with it.
<phoe>
execution continues from the SIGNAL call?
<makomo>
phoe: yes
sunset_NOVA has quit [Quit: leaving]
<Bike>
if you decline to handle a condition signaled by SIGNAL, SIGNAL will still return normally (i.e. G will just keep going)
<phoe>
then you cannot perform a NLToC
<makomo>
Bike: right, but i still don't like the idea of it bubbling up and disappearing
<phoe>
bubbling up and disappearing?
<Bike>
why not?
<makomo>
i mean, that would give me what i want, but i want to be the one that will stop it
<Bike>
why?
<phoe>
I don't understand what you want to achieve
shka_ has quit [Ping timeout: 252 seconds]
<makomo>
idk, perhaps it's just unnecessary ""overhead""
<phoe>
A condition is signaled. You want to log it, and then continue execution.
<makomo>
why not handle it once and for all and stop it from bubbling up
<makomo>
phoe: right
<phoe>
That's a HANDLER-BIND with a single FORMAT call.
<Bike>
you should consider condition handling slow anyway, as far as efficiency is concerned
<phoe>
You seem to want a way for a handler to prevent handlers higher-up from firing.
<Bike>
if you really really want to prevent higher level handlers, i guess use a restart
<makomo>
yeah, that's pretty much what i want
<phoe>
Then use a restart around the call.
<makomo>
but how would that restart look like? don't restarts have to perform a non-local transfer as well, otherwise INVOKE-RESTART returns with w/e
<Bike>
restart-case takes care of that
<Bike>
the transfer, i mean
<makomo>
mhm
<Bike>
(restart-case (signal ...) (continue ())) would be fine, i think
azimut has quit [Ping timeout: 246 seconds]
<phoe>
makomo: basically
<phoe>
all you want is to log something and then continue execution, right?
<Bike>
not sure i've seen restart-bind used ever, come think
<makomo>
Bike: ah, right, restart-case will just return normally
<phoe>
you want NO other handler to fire, correct?
<makomo>
phoe: yup
<phoe>
makomo: why use conditions at all?
<phoe>
replace the SIGNAL call to a call to your logging function
<makomo>
well, that's a good question. here's the use case, or at least an experiment
<phoe>
you'll achieve what you want - the logging function will log your stuff, and execution will continue
<phoe>
conditions are for going up the stack
<phoe>
you don't seem to want to go up the stack
<Bike>
so that you could have a different F that does something other than log, perhaps.
<phoe>
you want to log things and continue.
<phoe>
Bike: he said that he wants no other handlers to call.
<makomo>
i have a LU decomposition algorithm thingy. now, i want to report a "warning" when the matrix is nearly singular or similar
<phoe>
s/call/be called/
<Bike>
phoe: sure, but there's still a separate f and g
<phoe>
makomo: highfive, I'll be writing the same thing next week
Lycurgus has quit [Quit: Exeunt]
<makomo>
and since i already have this function returning multiple values, i really don't want to add more return values to signify "the matrix could be nearly signular"
<makomo>
singular*
<makomo>
and i don't want to do th elogging from within the LU algorithm itself, for obvious purposes
<makomo>
phoe: nice :D
<phoe>
hm, I see
<Bike>
that sounds quite reasonable to me.
<makomo>
the only clean way i can think of doing this is SIGNALing a condition
<Bike>
i do think you should just let it bubble up, though.
<makomo>
the outer function logs it, gets the results, and then maybe prints out the warning when printing out the result
<phoe>
you can have F have a handler that stores the condition in some list, and then calls the continue restart.
azimut has joined #lisp
<phoe>
then, when G finished, F can print out all conditions it got from inside G.
<Bike>
like if you use WARN (instead of signal) you automatically allow a given F to suppress warnings or not.
<makomo>
Bike: right, that might be simpler, but i somehow want to "clean up after myself". do you think that's just wasted effort or?
<phoe>
clean up?
<phoe>
what do you mean?
heisig has quit [Quit: Leaving]
<makomo>
in the sense that, i want to be the only one to deal with the condition, and not let it bubble up
<Bike>
wants to keep the conditions outside of the external interface
<phoe>
if you handle all conditions in F, there's nothing left to clean up
<phoe>
a restart should be enough
<makomo>
right, that will surely work
<Bike>
but i don't like to hide information like that.
<makomo>
but bike suggested just letting it bubble up
<phoe>
I suggest the same
<makomo>
Bike: hm, why do you say "hide"?
<phoe>
because the information doesn't propagate
pjb has joined #lisp
<makomo>
right, but why would i want it to?
<phoe>
debugging purposes
<makomo>
hmm
<phoe>
and inquisitive programmers that may want to handle this information themselves
<Bike>
like maybe later you do something with a million matrices, and you don't want the interface for that to print a thousand warnings, but you do want a handler that just counts instances instead of logging something
<phoe>
for example, you want to immediately break out when you find a singular matrix
<Bike>
just, something else might want that info later, in a format it can deal with
<phoe>
instead of computing the remaining 99999 ones
<phoe>
for example, to invoke an external debugger, so the user may inspect the matrix and decide what to do
<phoe>
if your code is used as a library, then the information that your code signals a SINGULAR-MATRIX-WARNING might be valuable to programmers that write code that uses your code.
<phoe>
by catching all of those warnings yourself, you prevent them from getting that information.
<makomo>
Bike: oh, the function doing the logging is really a "top-level function", not meant to be called by other functions. like a REPL or something
<makomo>
it calls the underlying algorithms on some tasks and reports the solutions and warnings
<Bike>
okay, but what if it's not later.
<makomo>
well then i guess i would modify it not to call the restart, and let the signal bubble up
<phoe>
makomo: if it's a top level function, then I say that you write a handler in F that logs the thing to standard-output and then declines, and signal the condition in G.
<phoe>
should be enough.
<makomo>
right, that's the "let it bubble up" way
<phoe>
if it's toplevel, then there's a very short handler stack, so efficiency won't hurt you.
<makomo>
hm, i guess
<makomo>
yeah, i suppose so
<phoe>
so, in my opinion, we're speculating.
<makomo>
meh yeah, not like i benchmarked it or that i really care anyway, but i just wanted to be as "pedantic" as possible
<phoe>
write it, and if it turns out to be too slow for you, I guess there'll nonetheless be many, maaany other things to fix rather than "oh this thing is signaling a condition".
aydio has quit [Read error: Connection reset by peer]
<HerrBlume>
Hello, I'm trying to add an jdbc backend to clsql (for abcl.) To get it going i have to remove the ffi dependency from the clsql core package. Does someone know the cannonical repository or mailing list?
<phoe>
HerrBlume: hm, why remove the FFI dependency?
<phoe>
is it causing you trouble for loading clsql under ABCL?
scymtym has quit [Ping timeout: 252 seconds]
<HerrBlume>
phoe: It does not compile on my machine without throwing errors. And I think it should not be needed for clsql/clsql-sys. So my thought was to remove the cffi/uffi thingy. Writing a clsql-jdbc part should be trival (no other dependency, since the jdbc drivers are loaded via the classpath)
<phoe>
HerrBlume: hm - I think you might need to fork the github repostory for clsql and add your modifications there.
<HerrBlume>
I will. Thank you.
Roy_Fokker has joined #lisp
mkolenda has joined #lisp
mkolenda has quit [Client Quit]
rippa has quit [Quit: {#`%${%&`+'${`%&NO CARRIER]
HerrBlume has left #lisp ["ERC (IRC client for Emacs 25.2.2)"]
mkolenda has joined #lisp
rumbler31 has joined #lisp
<emaczen>
how do we make *stdout* thread safe?
<emaczen>
I mean *standard-output*
asarch has joined #lisp
azimut has quit [Read error: No route to host]
<phoe>
emaczen: what do you mean, thread-safe?
azimut has joined #lisp
<emaczen>
phoe: If I create a bunch of threads with bt:make-thread and then do (format t ...) on them, each threads output gets tangled together
<emaczen>
How do I
<emaczen>
Maybe synchronize is a better word
<emaczen>
How do I synchronize them?
lnostdal has quit [Ping timeout: 252 seconds]
<phoe>
emaczen: make a lock and hold it around each call that prints something to *\standard-output*
<sjl>
Write a thread-safe-output-stream with trivial-gray-streams that wraps another output stream and uses locks from bordeaux-threads or whatever to synchronize writes to it, then (setf *standard-output* (make-thread-safe-output-stream *standard-output*)
<phoe>
or play around with gray-streams using the trick sjl described
scymtym has joined #lisp
lnostdal has joined #lisp
asymptotically has quit [Remote host closed the connection]
asymptotically has joined #lisp
azimut has quit [Ping timeout: 268 seconds]
<emaczen>
phoe: Can you point me to an example of using locks?
johnjay has quit [Ping timeout: 256 seconds]
asarch has quit [Ping timeout: 240 seconds]
Josh_2 has joined #lisp
graphene has quit [Remote host closed the connection]
<phoe>
for a less dumb case, also write a gray stream, as sjl mentioned
asymptotically has quit [Remote host closed the connection]
Lycurgus has joined #lisp
<emaczen>
phoe: What you suggested seems to work, why go through the extra work with the gray stream?
<sjl>
because then anything else that writes to standard-out will Just Work automatically
<phoe>
emaczen: so you can avoid wrapping all of your FORMAT calls with the lock calls.
<phoe>
and you can forget about locks altogether and just write FORMAT like you usually would.
<phoe>
your client code doesn't need to know nothing about locks.
<emaczen>
Okay I see.
<phoe>
it just writes to a stream; and the fact that the stream happens to be thread-safe is just a handy coincidence.
meepdeew has quit [Remote host closed the connection]
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
<no-defun-allowed>
are there any native machine vision libraries (similar to opencv without the floating point traps) for cl?
<sjl>
Note that you might also want to deal with *terminal-io* -- for anything but FORMAT, a stream of t means *terminal-io*, not *standard-output*
anamorphic has quit [Quit: anamorphic]
<sjl>
e.g. (format t "foo") writes to *standard-output*, but (princ "foo" t) writes to *terminal-io*
<aeth>
I'm considering implementing BLAS in native CL (and possibly also in a Lispy-lang-on-GPU as well) because the current options for this sort of thing disappoint me that much. From there it's only 3-4 steps to a useful library.
anamorphic has joined #lisp
rumbler31 has quit [Remote host closed the connection]
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
<Josh_2>
o kewl internet
anamorphic has joined #lisp
anamorphic has quit [Client Quit]
warweasle has joined #lisp
<no-defun-allowed>
nice
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
azimut has joined #lisp
sjl has quit [Quit: WeeChat 2.3-dev]
azimut has quit [Ping timeout: 252 seconds]
sjl has joined #lisp
graphene has quit [Remote host closed the connection]
jcowan has quit [Quit: Connection closed for inactivity]
robotoad has quit [Ping timeout: 268 seconds]
varjagg has quit [Ping timeout: 264 seconds]
phoe has joined #lisp
robotoad has joined #lisp
Lycurgus has quit [Quit: Exeunt]
azimut has joined #lisp
nirved has quit [Quit: Leaving]
rumbler31 has joined #lisp
rumbler31 has quit [Remote host closed the connection]
azimut has quit [Ping timeout: 240 seconds]
pjb has quit [Ping timeout: 264 seconds]
jcowan has joined #lisp
<jcowan>
Does anyone have practical experience with loading third-party plugins into their application with LOAD?
Lycurgus has joined #lisp
azimut has joined #lisp
graphene has quit [Remote host closed the connection]
graphene has joined #lisp
azimut has quit [Quit: Adios]
azimut has joined #lisp
<aeth>
jcowan: as in this? (load (compile-file path))
pjb has joined #lisp
<jcowan>
yes
<aeth>
The only differences with that and ASDF (assuming you load the files in the same order) are, afaik, that you'll recompile every time and the FASL will be in the same directory (possibly implementation-specific?) instead of in ~/.cache/common-lisp
<jcowan>
well, it can just as well be (load path-to-compiled-file)
<jcowan>
but what I'm asking about is whether people exploit the ability to load a file whose name is computed at runtime.
<jcowan>
hence the reference to plugins
<aeth>
The laziest way to do this would be to use Quicklisp to quickload an ASDF system. There's probably a proper way to do this via ASDF.
<jcowan>
but do people routinely load systems whose name they compute?
Lycurgus has quit [Quit: Exeunt]
<jcowan>
that's what interests me
shifty has joined #lisp
<aeth>
jcowan: I think the idiomatic way to solve that problem in modern CL would be to compute the directory containing the foo.asd file that describes the system foo and then have ASDF recognize that directory (would that be by pushing it to asdf:*central-registry*? not sure here)
<jcowan>
I see two problems, or perhaps only one: you can't sandbox what you load easily, and you don't know how to interface with it except by convention or reflection.
<aeth>
Sandboxing is apparently impossible in current implementations. Iirc, beach is working on an implementation that permits sandboxing as one of its goals.
Copenhagen_Bram has quit [Ping timeout: 264 seconds]
anewuser has joined #lisp
Copenhagen_Bram has joined #lisp
Bike has quit [Ping timeout: 256 seconds]
edgar-rft has quit [Ping timeout: 264 seconds]
pjb has quit [Ping timeout: 264 seconds]
ym has quit [Quit: Leaving]
edgar-rft has joined #lisp
dmiles has joined #lisp
pierpa has joined #lisp
aindilis has quit [Ping timeout: 264 seconds]
angavrilov has quit [Remote host closed the connection]
DGASAU has quit [Ping timeout: 264 seconds]
Essadon has quit [Quit: Qutting]
jack_rabbit has joined #lisp
griddle has joined #lisp
<griddle>
I've got a quick question. I've been working on implementing a small lisp interpreter and I'm interested in how '(...) and (quote (...)) relate
<griddle>
is it almost a 1:1 mapping in common lisp, at least?
<no-defun-allowed>
'thing is a reader macro for (quote thing)
ryan_vw has joined #lisp
<griddle>
so I can just parse 'x as (quote x) and handle that special form in my interpreter
<no-defun-allowed>
yep
<griddle>
awesome, thanks!
lavaflow_ is now known as lavaflow
rumbler31 has joined #lisp
Bike has joined #lisp
rumbler31 has quit [Remote host closed the connection]