<utis>
is there a way to suppress messages to stderr for a certain library? portaudio is producing a lot of clutter.
<phoe>
utis: sounds like a portaudio question rather than a CL one
<utis>
not if there's a general way to suppress messages from a library
<phoe>
there is none that I'm aware of, especially if you are not in the CL land anymore and it's foreign code that prints to stderr
puchacz has joined #commonlisp
<beach>
Also Common Lisp does not have a "stderr".
<phoe>
yeah, but portaudio is a foreign library
<beach>
Then all bets are probably off.
<utis>
surely it has something that corresponds to stderr when one compiles a unix program
<utis>
?
<phoe>
it does, cl:*error-output*
<beach>
utis: But if a foreign library does not go through the corresponding Common Lisp stream, then there is probably not much the implementation can do.
<phoe>
but I'm pretty sure cl-portaudio does not wrap portaudio's errors written to stderr only to redirect them to *error-output*
<_death>
utis: on unix-like systems, stderr has file descriptor number of 2.. you can close it and open, say, /dev/null to "redirect" any bytes written to it
<phoe>
it's a per-process global resource too, so this way you'll redirect messages from all libraries which is likely not what is wanted
<phoe>
but yeah, short of recompiling portaudio to do something more meaningful I can't see any other option - its code is littered with fprintf(stderr, ...); and all such invocations would need to be replaced at least with a different file descriptor
Brucio-61 has quit [Ping timeout: 252 seconds]
<phoe>
sounds like a possible PR to portaudio itself, and once it's there, you should be able to configure it from cl-portaudio
scymtym has quit [Ping timeout: 246 seconds]
<phoe>
but yeah, nothing else that can be done on the lisp side to solve this problem, especially from the CL side.
cosimone has joined #commonlisp
<utis>
for now i'll wrap a calls to portaudio in (handler-bind ((warning #'muffle-warning)) ...)
<utis>
s/a/all
cage has joined #commonlisp
<beach>
If the library writes directly to stderr, I don't see how that will fix your problem.
<utis>
i don't know, it does seem to work
<utis>
or maybe not, sorry
xlarsx has joined #commonlisp
<utis>
so to be clear, there's no way to get the effect of 2>/dev/null /inside/ the program?
<beach>
You would have to use the Unix interface provided by the implementation.
<beach>
But, as phoe pointed out, that is probably way overkill and not recommended. Error messages indicate problems, and the problems should be fixed instead.
<_death>
I too close my eyes when the road shows me warning signs ;)
<beach>
Yes, exactly that.
<phoe>
utis: weird, I cannot see any calls to WARN inside cl-portaudio - I don't think HANDLER:BIND will prevent it from writing to stderr
<phoe>
but to get unix fd redirection like that I guess you could manually call unix close on fd 2, then open /dev/null under the same fd
<phoe>
but that's already dirty unix stuff that I don't feel knowledgeable enough in
scymtym has joined #commonlisp
Brucio-61 has joined #commonlisp
<utis>
yes, sorry, i forgot i already had 2>/dev/null in my command, so the handler-bind didn't do anything
chip_x has quit [Quit: Leaving]
<utis>
seems that people have been complaining to portaudio about these warnings for more than 10 years
xlarsx has quit [Remote host closed the connection]
xlarsx has joined #commonlisp
szkl has joined #commonlisp
<phoe>
probably the best thing to do would be to grep all of portaudio's code for `fprintf(stderr` and replace these with a call to a logging function that can be configured to print somewhere else, but this is already #portaudio content
aartaka has quit [Ping timeout: 268 seconds]
aartaka has joined #commonlisp
random-nick has joined #commonlisp
xlarsx has quit [Ping timeout: 250 seconds]
xlarsx has joined #commonlisp
xlarsx has quit [Ping timeout: 268 seconds]
jmdaemon has quit [Ping timeout: 248 seconds]
attila_lendvai has joined #commonlisp
xlarsx has joined #commonlisp
tyson2 has joined #commonlisp
xlarsx has quit [Ping timeout: 248 seconds]
lisp123 has joined #commonlisp
<lisp123>
What is CLX used for?
<jackdaniel>
to interface with X11 server
<lisp123>
Can it be used to create GUIs?
<lisp123>
I'm not sure where the boundaries between X11/Wayland and GTK lie
<jackdaniel>
it may be used to create GUI's, sure
<jackdaniel>
X11/Wayland are both so-called display servers - they provide an abstraction over actual hardware with a common API
<jackdaniel>
s/common/specified/
<jackdaniel>
GTK is a client that talks with said display server
<jackdaniel>
a display server will typically manage windows, so there may be numerous clients
<jackdaniel>
when you use clx, then you may create a window, receive events from this window and request drawing on it
<jackdaniel>
toolkits like gtk give you more high level tools - like abstract away certain requests and event handling into particular gadgets/widgets - i.e a push button
<lisp123>
I see
<lisp123>
Does McClim use CLX?
<jackdaniel>
in principle it would be possible to write GTK backend that directly talks with (i.e) a framebuffer and processes events by reading /dev/whatever
<jackdaniel>
it does (in its default backend)
<lisp123>
Good stuff
<lisp123>
I have a linux machine now, I'm might do more mcclim hacking in the future
<beach>
Well, sort of (good stuff). CLX is old. It predates many X11 additions, and it doesn't use generic functions and standard classes. I would very much like to see a more modern version of CLX that prioritizes modern use of X11.
<lisp123>
beach, Although X11 seems to be on a slow way out (Wayland). A bit no man's land given Wayland doesn't cover everything in Xorg, but that's a separate discussion
Mandus has quit [Read error: Connection reset by peer]
<lisp123>
I'm perfectly happy with X11 though
<jackdaniel>
soon™ we'll release an SDL2 backend (FFI based whew), that works on all major platforms
<beach>
I have heard that X11 is on its way out for years, perhaps more than a decade.
<jackdaniel>
it is indeed mor ethan a decade
<lisp123>
If I create a McClim app, can it be made into a 'executable'?
<jackdaniel>
12 years iirc
<jackdaniel>
yes it can
Mandus has joined #commonlisp
<lisp123>
On linux, what's the ideal way to package lisp apps?
<lisp123>
For now I just would run sbcl and run the app
pranavats has left #commonlisp [Error from remote client]
<jackdaniel>
that depends on your package manager
<lisp123>
No one size fits all?
<lisp123>
i guess .deb and .rpm might cover a lot (or flatpak?)
<jackdaniel>
if you distribute things as rpm, then you build the binary, add dependant files and finally archie it as rpm ready to extract
<lisp123>
I see
<jackdaniel>
or if you create a source code distribution, then you create a bundle with all dependencies and that's all, the user will use asdf to load it
<lisp123>
Yeah that seems like the better way to begin with, unless it was a really commercial app that needed one-click install
<jackdaniel>
another thing is that sometimes you may want to daemonize your software, then you also package unit file or other init script
<lisp123>
For now I might just end up doing that to-do list app that was always on my list
<jackdaniel>
well, that's a dev ops job fwiw
attila_lendvai has quit [Ping timeout: 260 seconds]
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
Mandus has quit [Ping timeout: 260 seconds]
Mandus has joined #commonlisp
notzmv has quit [Ping timeout: 260 seconds]
lisp123 has quit [Quit: Leaving]
xlarsx has joined #commonlisp
xlarsx has quit [Ping timeout: 268 seconds]
cage has quit [Quit: rcirc on GNU Emacs 27.1]
Everything has joined #commonlisp
karlosz has joined #commonlisp
<judabuda>
could it be a problem
<judabuda>
Could it be a problem/big difference if running CL on linux or on windows?
<phoe>
no
xlarsx has joined #commonlisp
<judabuda>
I'm having trouble starting hunchentoot
xlarsx has quit [Remote host closed the connection]
xlarsx has joined #commonlisp
vn36 has quit [Ping timeout: 246 seconds]
vn36 has joined #commonlisp
causal has joined #commonlisp
xlarsx has quit [Ping timeout: 260 seconds]
motherhucker has joined #commonlisp
_cymew_ has joined #commonlisp
cosimone` has joined #commonlisp
ttree has joined #commonlisp
Brucio-61 has joined #commonlisp
pjb has joined #commonlisp
cosimone` has quit [Remote host closed the connection]
igemnace has quit [Remote host closed the connection]
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
motherhucker has quit [Ping timeout: 250 seconds]
thuna` has joined #commonlisp
Oladon has joined #commonlisp
causal has quit [Quit: WeeChat 3.6]
McParen has left #commonlisp [#commonlisp]
xlarsx has joined #commonlisp
IPmonger has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
IPmonger has joined #commonlisp
attila_lendvai has joined #commonlisp
IPmonger has quit [Remote host closed the connection]
vn36 has quit [Ping timeout: 250 seconds]
aartaka has quit [Ping timeout: 248 seconds]
aartaka has joined #commonlisp
perrierjouet has joined #commonlisp
_cymew_ has quit [Ping timeout: 252 seconds]
HiPhish has joined #commonlisp
<HiPhish>
Hi there, a couple of months back I posted here an announcement for cl-cmark
<HiPhish>
It's a wrapper library around the official C library for CommonMark (a well-defined Markdown dialect)
<HiPhish>
I want to announce that the library is now close to a stable release and I would appreciate if as many people as possible could at least give it a try.
<HiPhish>
This is my first time writing a real thing in Common Lisp and I hope it can be useful to other people.
<HiPhish>
Thanks for letting me shill my stuff, have a good day. Goodbye :)
cage has quit [Quit: rcirc on GNU Emacs 27.1]
<lagash>
HiPhish: ah! I had that in my bookmarks! I can't remember what CL project I was possibly going to use that for...
xlarsx has quit [Remote host closed the connection]
tyson2 has joined #commonlisp
<phoe>
HiPhish: might want to use #: in your DEFPACKAGE form to avoid interning stuff into other people's packages
<phoe>
but that's a nitpick, looks like a pretty damn nice library, congrats!
<kakuhen>
^
<HiPhish>
phoe: Which DEFPACKAGE forms are using interned keywork symbols? I just ran `ack defpackage` over the project and they all seem to use `#:...`