freenode/#lisp - IRC Chatlog
Search
7:16:15
Posterdati
please help, how can I capture the output of a linux process launched by uiop:program from a bordeaux-threads thread?
7:17:31
Posterdati
please help, how can I capture the output of a linux process launched by uiop:run-program from a bordeaux-threads thread?
7:17:56
shka_
(let ((output *standard-output*)) (bt:make-thread (let ((*standard-output* output)) (run...
7:18:21
shka_
(let ((output *standard-output*)) (bt:make-thread (lambda () (let ((*standard-output* output)) actually
7:19:13
gendl
Sano stood there in Montreal in 2014 (I think) and introduced Roswell, and was to tentative and shy about it,
7:19:39
gendl
he was making it sound like a piece of crap that I probably didn't want or need to spend time with at that point
7:20:10
shrdlu68
Posterdati: If using Slime, the manual says the output might go to the *inferior-lisp* buffer.
7:20:18
gendl
not just brilliant, but taking a huge amount of patience to work through tedious stuff
7:20:38
gendl
yes, sorry, disconnected. Sometimes that happens in here, I think. Interleaving threads of conversation.
7:20:39
phoe
shka_: yes, that's because for threads, the default value for *standard-output* is the output stream for the inferior lisp buffer.
7:23:04
gendl
At this point what I care about is someone willing to take the time to keep a central repository of up to date implementations.
7:27:35
LdBeth
ACTION uploaded an image: 屏幕快照 2018-10-22 上午12.27.13.png (227KB) < https://matrix.org/_matrix/media/v1/download/matrix.org/AgLexMDwMtfqahZpNdLjUtAJ >
7:27:55
phoe
sharpsign macros are dispatch reader macros; dispatch, because the reader macro function on #\# dispatches on the character that comes right after it
7:29:00
LdBeth
that's what I feel unfair about: ask a newcomer on features not defined in standard language report
7:29:53
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
7:30:41
phoe
(also, yes, we have colliding names, LoL stands for both Let over Lambda and Land of Lisp)
8:18:13
Posterdati
shka, could be *default-special-bindings* used to achieve uiop:run-program process output in a thread?
8:21:30
Posterdati
shka_: I did: (setf ,,, ,,, bt:*default-special-bindings* (list (cons 'output *standard-output*)))
8:23:51
shka_
this alist is supposed to hold association of special variable symbol and form to evaluate
8:27:19
jackdaniel
how about (let ((#1=bt:*default-special-bindings* (list* (cons '*standard-output* *standard-output*) #1#))) (bt:make-thread …)) ;?
8:47:51
shrdlu68
He should still see something: "Also :output means redirecting the error output to the output stream, in which case nil is returned."
8:53:10
jackdaniel
shrdlu68: I don't see uiop's run-program having default value :output for the error-output
8:54:11
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
8:54:43
Posterdati
(simple-inferiors:run "wget" (list -O (format nil "~{~a ~}" (list destination file-url))) :output *standard-output* :copier :character)
8:55:38
jackdaniel
shrdlu68: try (uiop:run-program "wget google.com" :error-output *standard-output*) ; (output!)
8:55:45
jackdaniel
and (uiop:run-program "wget google.com" :output *standard-output*) ; (no output!) :)
9:01:36
jackdaniel
as of meaning of the docstring: if you did (uiop:run-program "foo" :error-output ;output :output *bam*)
9:02:53
Posterdati
(simple-inferiors:run "wget" (list -O (format nil "~{~a ~}" (list destination file-url))) :output *standard-output* :copier :character)
9:03:51
jackdaniel
Posterdati: if you had read what I've said above, you'd use :error-output in the original code
9:04:15
jackdaniel
also, before you try things with thread-local dynamic bindings *First* verify it works from repl as you had expected it to work
9:05:58
jackdaniel
(let ((#1=bt:*default-special-bindings* (list* (cons '*standard-output* *standard-output*) #1#)))
9:06:01
jackdaniel
(bt:make-thread (lambda () (uiop:run-program "wget google.com" :error-output *standard-output*))))
9:06:34
jackdaniel
because that works here locally, so either you have malfunctioning wget, lisp or uiop
9:22:37
Posterdati
(simple-inferiors:run "wget" (list -O (format nil "~{~a ~}" (list destination file-url))) :error *standard-output* :copier :character)
9:38:10
jackdaniel
Posterdati: maybe I didn't suggest it clear enough: try using your implementation's run-program, not uiop's
9:38:42
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
9:41:18
jackdaniel
and if it does the same thing as external-program and uiop, then that could be seen as a nih syndrome
9:47:20
phoe
jackdaniel: it seems to be based on UIOP and specifically solves the issue of capturing process output
9:49:20
jackdaniel
phoe: external-program is just a portability lyaer for implementation-specific run-program
9:49:37
jackdaniel
uiop is a spaghetti with its own code accidently using implementation-specific extensions
9:50:49
jackdaniel
it could use some work, but my point is that external-program aims to be minimal abstraction unlike uiop in this regard
12:02:53
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
12:04:15
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.
12:06:46
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."
12:49:33
didi
Uh, so the slides "Tutorial on Good Lips Programming Style", by Norvig and Pitman is a treasure trove.
12:50:22
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.
12:51:09
didi
Unfortunately, as slides go, it's too terse to read out of context. I wish it was an article, or even a book.
13:07:07
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.
13:09:38
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.
13:15:47
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.
13:17:56
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
13:17:58
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.
13:18:35
beach
shrdlu68: No, (unless (null foo) (aref foo n)), or even better (if (null foo) (error..) (aref foo n))
13:18:38
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
13:19:09
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.
13:19:20
Xach
schweers: this was quite general but in practice there was only only a couple frequently-used operations
13:19:50
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
13:19:57
sjl
HighMemoryDaemon: you can also use rlwrap to add the nice editing functionality, so that's another reason reason it's not worth bothering.
13:20:32
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?
13:21:31
jackdaniel
that could be an illustration where such information would be beneficial, but I didn't have exactly that in mind
13:24:52
HighMemoryDaemon
sjl: I haven't worked on it for a while, but I was following through the BuildYourOwnLisp course and I remember they did go over cross-platform readline support. (Well, they 'faked' readline support) http://buildyourownlisp.com/chapter4_interactive_prompt#the_c_preprocessor
14:39:14
phoe
READ error during COMPILE-FILE: Symbol "FUNCALLABLE-INSTANCE-FUN" not found in the SB-KERNEL package.
14:40:50
phoe
The issues seem to be here, https://github.com/hu-dwim/hu.dwim.web-server/blob/ac489a8eac77e3719cbbf093dd32784f8a33d8b2/source/application/session-logic.lisp#L147
14:54:01
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.
14:57:21
jcowan
I think a cond is more readable than (if (progn (this) (that)) (progn (these) (those)))
14:59:08
jcowan
even if it's just one or the other if branch that needs multiple forms, I prefer cond
15:00:55
jcowan
I never got an answer to the question about the propriety of using qualified internal symbols (other than for testing, debugging, etc.)
15:01:11
jcowan
seems like it would be a code smell to me: if you need outside access, export the symbol
15:12:11
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).
15:59:15
pfdietz
I ask because the global package namespace is a source of real aggravation in CL. Collisions are rampant in quicklisp.
16:00:24
Xach
pfdietz: I don't often see people write about encountering the conflicts in real life.
16:00:55
gendl
pfdietz: wasn't there some effort to portableize Franz' package-local hierarchical package names?
16:01:27
gendl
Also what about asdf systems names? Those can get collisions too. How about system-local systems...
16:01:46
gendl
But, I know not much of what I speak. It could be opening cans of worms that we'd best not.
16:02:08
pfdietz
ASDF system names can be made long without great pain, so collisions can be largely avoided.
16:02:09
gendl
Having the possibility of conflicts also forces people to collaborate more, which might have its upsides.
16:02:15
Xach
I think package-local nicknames would be nice. I think they should be implemented differently from how they are right now.
16:02:33
pfdietz
But the package namespace includes concise nicknames, which are much more prone to collision.
16:03:51
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.
16:04:41
Xach
I'd like a system that can be used without loading portability packages or shims or anything like that.
16:06:19
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
16:06:23
pfdietz
I have wondered if the global namespace(s) could be made more first class. A sort of internal containerization systems for Lisp.
16:08:06
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.
16:08:57
gendl
I also wonder if there could be broken out a "diet" version of ASDF which doesn't deal with upgrading itself -
16:09:33
pfdietz
Curation and enrichment of QL systems seems to me to be an important area of focus for CL, perhaps the most important.
16:10:47
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.
16:12:39
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).
16:14:39
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.
16:15:54
gendl
Maybe use asdf:system-relative-pathname during development, isolated in development-only scripts and stuff
16:16:29
Xach
gendl: I also think asdf calls should not be present in project source code, but it's a tempting convenience.
16:17:02
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?
16:18:39
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.
16:19:36
Xach
gendl: Yeah? Do you feel it's unlike javascript, python, ruby development in that regard?
16:20:31
gendl
Well at least some of those are described as "scripting" languages, for example Python and Perl,
16:21:18
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.
16:22:31
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
16:22:53
gendl
Sometimes it's advantageous to be able to deploy a program and have it just run like any other program.
16:24:55
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.?
16:25:12
Xach
It would be helpful to have a guide to "how to write code so it can be easily delivered"
16:25:44
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
16:26:42
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.
16:26:44
Xach
something as simple as a checklist of little things that make it harder would be handy
16:27:27
Xach
People are motivated by many things and I don't think "take CL mainstream" is high on the list for many people.
16:27:55
gendl
I started a development blog ages ago that started to address this kind of thing, but kind of abandoned it for the past 5 years or so..: http://gendl.blogspot.com/2013/03/saving-images-with-asdf3.html
16:31:28
shka_
gendl: how many languages assume that user is supposed to modify deployed application by editing the source code?
16:32:29
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.
16:32:47
gendl
But I think the question is more of an application-specific one than a language-specific one.
16:33:17
gendl
the question should be "how many applications assume that user is supposed to modify deployed application by editing the source code?"
16:34:37
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.
16:35:51
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.
16:38:38
didi
I disagree with the "mainstream" statement, but I'm with Xach: an article about deploying applications would be nice.
16:39:32
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
16:39:32
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.
16:42:32
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
16:46:24
shka_
gendl: i honestly think that you are making this issue to appear larger then it really is
16:47:46
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.
16:48:19
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.
16:50:01
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.
16:51:00
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.
16:51:43
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.
16:52:08
gendl
And by the way, a large percentage of what's in alexandria is likely available in UIOP as well.
16:52:51
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.
17:03:35
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.
17:03:45
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.
17:05:09
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.
17:05:26
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.
17:05:37
Xach
"if tree shaking was so great then someone would already have done it for us, therefore tree shaking is bad"
17:09:03
gendl
pfdietz: Do you think docker will eventually eliminate the need for languages (e.g. CL) to support certain OSs directly, (e.g. Windows)?
17:11:06
gendl
so we just target a single platform and let Docker deal with all portability issues? Or am I barking up the wrong tree?
17:15:46
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?
17:16:30
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.
17:17:08
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.
17:18:01
shka_
my colleague mad for instance complete portable development env in docker with all the libs, gcc, and good damn web browser included
17:18:41
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?
17:19:17
gendl
shka_: ok, then I'm confused by your statement "you can deploy desktop applications inside docker"
17:19:59
jcowan
In Flavors packages were strictly hierarchical, inheritance was strictly up the tree, and symbols had names like FOO:BAR:BAZ (no ::)
17:20:02
oni-on-ion
pfdietz: are docker 'services' typically serving just one client ? then i can see the benefits
17:20:38
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.
17:22:45
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.
17:23:08
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.
17:24:08
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
17:26:22
shka_
so if you can essentially save-lisp-and-die and have standalone binary, that's awesome
17:26:34
gendl
That might make a good YC startup idea -- "containerize Paul Graham so we can replicate him across the Internet"
17:26:42
didi
Maybe something like (local-package foo ...) which rewrites every DEFUN as LABELS and God knows what else. /me shivers
17:28:16
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?
17:29:11
buffergn0me
If for nothing else than to support multiple conflicting library versions in the same image
17:30:23
gendl
shka_: well how it works on OSX and Windows is no big mystery - it's running a Linux VM.
17:30:48
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
17:30:51
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.
17:31:55
didi
buffergn0me: Sounds like a plain to fragmentation and code rot, but I guess the availability of such feature isn't bad.
17:34:29
|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
17:35:23
|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
17:36:48
|3b|
ACTION 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
17:38:28
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
17:40:43
|3b|
you would need foo.bar.baz loaded with foo.blah-1.2, foo.bar.baz loaded with foo.blah-1.3, etc
17:41:13
|3b|
if some other libs depends on foo.bar.baz with explicit dependencies on blah-1.2 and blah-1.3
17:47:06
buffergn0me
The "name" of that package would include dependency information. Nix handles that using hash trees of the build info of each system
17:47:31
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
17:50:30
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".
17:50:31
|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
17:50:44
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)
17:55:27
buffergn0me
The question with environments is, should symbols share identity across them? Or is full virtualization of packages needed?
17:55:56
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).
17:57:28
|3b|
(packages are unrelated to the naming provided by symbols, they only map from text to symbol objects)
17:58:08
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.
18:00:12
meepdeew
Hi all, so towards the end of PCL Ch 20 (Special Operators), the writing gets into EVAL-WHEN, LOAD, COMPILE-FILE, etc..
18:00:23
meepdeew
It briefly touches on some of the differences between LOAD and COMPILE-FILE, and the implications.
18:00:28
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.
18:00:42
meepdeew
But I'm still a bit unclear on some things addressed there, like what forms COMPILE-FILE must evaluate and why.
18:01:01
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.
18:02:26
Bike
the basic version is that compile-file evaluate, at compile time, toplevel forms in an EVAL-WHEN with the :compile-toplevel situation.
18:02:52
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.
18:06:57
Bike
keep in mind that the expansion is going to differ between implementations, and it's possible one will do something else
18:09:39
buffergn0me
meepdeew: I would also take a look at the CLtL chapter on compilation: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node224.html
18:12:50
buffergn0me
meepdeew: Actually, this is probably even more relevant to your question: https://www.cs.cmu.edu/Groups/AI/html/cltl/clm/node227.html
18:19:31
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
18:23:27
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.
18:24:16
jcowan
I don't understand this sentence: "The compiler must treat any binding of an undeclared variable as a lexical binding."
18:25:12
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...
18:25:32
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
18:25:41
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...
18:26:09
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
18:26:46
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)
18:29:03
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.
18:31:04
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.
18:36:23
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.
18:38:58
jcowan
What is the purpose of the :intern clause in DEFPACKAGE? (I know what it does, not why you'd use it)
18:40:09
jcowan
To intern a symbol in a package, it suffices to mention it. Under what circumstances would you wish to avoid mentioning it?
18:40:11
pjb
Packages are basically collections of symbols. So it's natural that you can enter symbols in them, when you create a package.
18:41:15
Xach
jcowan: if you want to establish all your package definitions before loading any code.
18:41:17
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.
18:43:30
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">
18:43:50
pjb
without the :intern, A could be used in B without error. This may not be what you want.
18:45:04
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.
18:47:23
pjb
I have a example here: https://github.com/informatimago/lisp/blob/master/tools/dummy-asdf.lisp
18:47:49
pjb
where I define a dummy asdf package, so I may load and define some things even when asdf is not available.
18:49:40
pjb
jcowan: also, another example, in https://github.com/informatimago/patchwork/blob/dialog/src/packages.lisp
18:50:30
jcowan
In the first example, ISTM that (in-package "ASDF") would be better instead of qualifying every symbol being defined
18:51:21
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.
18:52:50
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.