Search
Friday, 15th of February 2019, 8:48:10 UTC
8:56:37
splittist
morning, all y'all
12:01:26
Lord_of_Life_
** NICK Lord_of_Life
12:48:55
Ukari
https://plaster.tymoon.eu/view/1178, is it impossible to export function printop in eval-when block in this situation?
12:51:24
_death
it is impossible to export functions.. only symbols are exported
12:51:58
_death
what is the purpose of eval-when and #. here
12:53:16
Ukari
https://lispcookbook.github.io/cl-cookbook/process.html#print-a-message-onto-the-top-level--read-time-eval-macro
12:54:02
_death
this is bad.. don't emulate it
12:55:21
Ukari
how to print message in a thread without eval-when and #.*standard-output*
12:55:42
_death
my advice is to use a logging library, such as log4cl
12:56:29
phoe
Ukari: what do you mean, print message in a thread?
12:56:54
phoe
you don't print messages in threads, you print stuff to streams
12:56:59
phoe
which stream do you want to print to?
12:57:17
_death
when you create a thread, it is possible to bind *standard-output* to the calling thread's *standard-output* value
12:59:56
phoe
https://trac.common-lisp.net/bordeaux-threads/wiki/ApiDocumentation
13:00:04
phoe
look at *default-special-bindings*
13:00:12
phoe
Ukari: the standard-output of what exactly?
13:00:40
phoe
the value of *standard-output*? if yes, then the value in which thread?
13:13:27
Ukari
https://plaster.tymoon.eu/view/1179
13:14:14
Ukari
it didn't work as I thought, where wrongs?
13:16:19
phoe
beach: those are quotes, not earmuffs
13:16:39
phoe
Ukari: you want `((*standard-output* . ,*standard-output*))
13:16:45
phoe
you want an alist, not a cons
13:16:49
phoe
so a list of conses, not a single cons
13:17:04
phoe
also, it is already defined as a variable; just SETF it
13:17:28
Ukari
in my sbcl it is undefined
13:17:45
phoe
are you using bordeaux-threads?
13:18:06
phoe
well, I don't know SBCL-specific functionality for that
13:18:46
Ukari
I will switch to use bordeaux-threads
13:38:05
Ukari
Is it a good practise to change a third library global variable, like bt:*default-special-bindings*?
13:39:02
phoe
(let ((*bt:default-special-bindings* ...)) (bt:make-thread ...))
13:39:21
phoe
but generally, only set it globally if you really need to
16:04:20
Xach
when i was young i thought it was weird to write pkg:*foo* instead of *pkg:foo*
16:04:36
Xach
but now i don't think that way
16:05:03
antoszka
does it work both ways?
16:12:56
phoe
CL-USER> (defpackage *pkg (:export #:foo*))
16:12:56
phoe
CL-USER> (defvar *pkg:foo*)
16:14:11
antoszka
yeah, I did the same in my mind :)
16:16:14
phoe
look, that's a dynamic variable in a dynamic package
16:17:55
Ukari
could (let ((*pkg:foo* nil))) works? i get a "Package *pkg does not exist." error
16:18:12
Xach
Ukari: if the package is nmaed "*PKG" and the symbol is named "FOO*"
18:06:30
cage_
i have two systems with conflicting nicknames, how can load (via ASDF) both in the same system?
18:07:23
cage_
my best "solution" (so to say) is to define a system that just remove the offending nickname from one of the system that needs to be loaded
18:07:53
phoe
load one system, remove the offending nickname, load another system.
18:08:27
phoe
either that or wait for package-local nicknames to gain widespread usage and then for library writers to stop using nicknames
18:09:09
cage_
i am one of those that use nicknames in library, sorry :(
18:09:19
phoe
cage_: nah, no problem with it
18:09:23
phoe
(until there's a collision)
18:09:26
cage_
i won't i future i promise! ;)
18:09:52
phoe
cage_: when there's PLNs, there will not be much use for short nicknames since library writers will be able to define their own per-package nicknames
18:10:55
cage_
i see, so far is just CCL that does not have this feature?
18:12:13
phoe
https://github.com/Clozure/ccl/issues/111
18:12:24
phoe
I'm getting closer and closer to close that gap
18:12:44
phoe
(and LW and ACL, but these are beyond repair)
18:14:56
phoe
cage_: I won't say it's done 'til it's merged
20:01:32
Ukari
what is the possible operation-options for ASDF? I read it from here https://tinyurl.com/qa4c9gy
20:13:56
akr
Hi, I'm having some issues with SBCL's run-program:
20:13:59
akr
(sb-ext:run-program "uname" '())
20:14:26
akr
this returns an error, complaining that it can't find the program uname
20:14:55
akr
even if I pass :environment '("PATH=/bin"), the error stays the same
20:15:04
akr
I checked that I have /bin/uname
20:15:40
ThomasLewis[m]
Is it expecting a string or a pathname?
20:18:22
akr
the docs don't really say, I guess
20:18:44
akr
http://www.sbcl.org/manual/#Running-external-programs
20:19:59
ThomasLewis[m]
Yeah, I was just reading that. It is supposed to inherit the environment by default and use execvp to find the executable. Try providing the full path in the `program` string. If that doesn’t work, try #P”/path/to/uname”
20:20:56
akr
but I want to use the PATH variable
20:22:14
akr
damn, I thought that would be the default behavior
20:23:51
akr
scymtym: thanks! now it works
20:25:12
Xach
i heart sb-ext:run-program
20:27:23
Xach
sb-ext:run-program's cmucl kitchen-sink functionality roots make me happy
20:30:15
dim
mmm, I now see :wait nil :status-hook ... and I wonder how much I'm missing
20:31:15
dim
I should really learn how to avoid “Heap exhausted during garbage collection” when using SBCL, then I guess I would be quite happy with that implementation
20:31:22
Xach
:pty is cool too, and :directory
20:31:56
dim
:directory is easy to achieve with uiop:with-current-directory, so ok
20:33:03
Xach
dim: i don't think the semantics are the same in the face of threads.
20:33:24
dim
also, is :pty meaning that you can read the output of a program while it's running, PIPE style?
20:33:49
Xach
dim: yes, you can read and write to interactive programs as if you were a user.
20:34:06
Xach
different from pipes in that regard
20:34:19
Xach
the programs thinks it is talking to a real user on a real tty, but it is a pseudo tty!
20:35:45
dim
expect libs and things, or just mutli-threaded control of background jobs, sounds quite powerful
20:36:08
Xach
dim: i had a program that did (with-current-directory "foo" (run-program "bar")) but with threads it broke, and using (run-program "bar" :directory "foo") fixed it.
20:36:24
dim
anyway, I can't depend too much on SBCL until I know how to make its GC happy, and I obviously am very far from that at the moment
20:36:27
Xach
I think run-program's guts do the chdir after the fork and before the exec.
20:36:38
Xach
haven't checked, just been a happy user
20:36:49
dim
best position to be in in my book ;-)
20:37:02
dim
“just works” is under-appreciated
20:37:24
pjb
Personnally, I'm done with uiop:run-program. I'll complete my own implementation.
20:37:59
dim
pjb: it really looks like you have your own implementation of about anything and everything though...
20:38:29
pjb
I started to use CL too early, perhaps.
20:38:51
dim
you might be the perfect example of the infamous lisp curse, to some non trivial degree
Friday, 15th of February 2019, 20:48:10 UTC