freenode/#lisp - IRC Chatlog
Search
16:40:53
MrtnDk[m]
minion: memo for jcowan: I wonder what "idiotic mysticism" is then. Can thou please elaborate on that phrase, please, thank you.
19:03:16
thomasb06
Hello. Currently, I'm trying to install Ulubis, and I get this backtrace: https://x0.at/URP.log
19:14:15
Bike
i'm not familiar with ulubis, but it's hard to imagine that log helping. did it really not even give you an error code?
19:21:24
thomasb06
it's a window manager so I should run it from console mode, but the only trace I get is in this file
19:22:11
Bike
https://github.com/malcolmstill/ulubis/blob/master/ulubis.lisp#L139-L141 looks like you're supposed to be getting a backtrace, but evidently not
19:23:16
Bike
print-backtrace prints to *debug-io* whereas that format will print to *standard-output*. maybe the log is only getting the standard output.
19:24:23
Bike
i guess you could try replacing the print-backtrace call with (let ((*debug-io* (make-two-way-stream *standard-input* *standard-output*))) (trivial-backtrace:print-backtrace e)), and then it will print the backtrace to standard output as well.
19:28:24
thomasb06
ah, let me have a look. (it doesn't show but I'm on a sugar crash... had a huge patisserie few hours ago and obviously it was more sugary that what I'm used too)
19:34:29
thomasb06
so I've put `(trivial-backtrace:print-backtrace e :output *standard-output* :verbose t)` and now I recompile
19:42:38
fiddlerwoaroof
luis: one thing that would be really useful on macOS is support for the @executable_path, @loader_path and @rpath variables, although I think this would also need implementation-level changes
20:09:19
Bike
https://github.com/malcolmstill/ulubis/issues/62 well, someone else has the same problem.
20:11:38
Bike
https://github.com/malcolmstill/ulubis-drm-gbm/blob/master/ulubis-drm-gbm.lisp#L35-L39 i suppose it's one of these ioctl calls.
20:12:05
Bike
i have very little idea about graphics programming, let alone ulubis, so that's as far as i go
20:13:12
jcowan
I see I have been massively misinterpreted by several different people, and I hate that (Geek Answer Syndrome)
20:18:41
jcowan
So: I'm not annoyed with the Lisp community and never have been. What is more, someone else applied the phrase "idiotic mysticism" to Zen, not to Lisp, and I denied that Zen was in any way mystical. What I did do was compare certain Lispers (unnamed) to irascible Zen masters: they know a lot, but they have no patience with those who don't.
20:20:36
jcowan
It only now came to my attention. "Need brooks no delay, yet late is better than never."
20:21:05
mfiano
I have been trying to decide if I should be offended by "some very useful help tends to be available only from rather grumpy people"
20:23:19
jcowan
"An insult is like a drink: it affects one only if it is accepted." If you don't think you meet that description, then I see no reason to be offended. I certainly did not have you in mind.
20:35:19
thomasb06
as I don't know any of Lisp, I won't go that far at all... Thank you for your help
21:02:42
Josh_2
Xach: I have a lot of overlapping circles and I was hoping that when two overlap I could do a composite colour
21:25:22
Feldman
I was wondering, does anyone know *why* CL-CONT is so slow, on the technical level?
21:34:20
Shinmera
even without that you basically need to wrap a ton of stuff in lambdas and thus create a lot of indirection and allocation that is otherwise not necessary. Without direct implementation support you can't do much better.
21:35:24
_death
Feldman: not only that, it calls f/cc-function (a generic function) each time as well.. no dynamic-extent declaration for the &rest arg though maybe it's inferred
21:36:04
_death
you can do much better.. personally I like https://8c6794b6.github.io/posts/Delimited-continuations-with-monadic-functions-in-Common-Lisp.html
21:36:06
Feldman
_death: Not quite sure how dispatch is done for funcallable instances, but would implementing Robert Strandh's fast dispatch solve or help that?
21:37:02
Bike
a funcallable instance is just a function with some other slots attach. it doesn't do any kind of dispatch unless you define it to do so.
21:38:59
_death
https://gitlab.common-lisp.net/cl-cont/cl-cont/-/blob/master/src/special-transformers.lisp#L211
21:39:15
Feldman
I would've imagined if FIs weren't generic, they would be as fast as normal functions
21:40:21
Bike
i mean, slow because every call does an apply of this other function, which i guess applies VALUES?
21:41:00
phoe
but given the sheer number of repetitions I seriously don't think that fin overhead is what makes things slow
21:41:10
Bike
phoe: huh, that's way worse than i'd expect... oh, well, actually sbcl is almost certainly going to inline your second lambda there
21:42:41
Bike
defining them both as global functions declaimed notinline is one way, but ofc then you get a little bit of overhead from looking up the global
21:44:08
Bike
anyway, it looks like this other stuff cl-cont is doing is going to be slow regardless of how instances work.
21:44:53
Feldman
I'm asking because I was thinking about a tagbody (and possibly symbol-macro) based approach that would avoid wrapping stuff in lambda (they would be wrapped in tagbodies instead, which I assume are lighter)
21:46:31
luis
fiddlerwoaroof: maybe my next computer will be a mac again, but right now I don't have any macs (not sure if the powerbook still boots :D). Last one got stolen a few years back.
21:48:00
_death
Feldman: just removing that f/cc-function call would likely make it much faster (funcallable-standard-instance-access?)
21:51:48
Feldman
_death: yeah I saw that and was like ??, I suppose FGF would actually help there!, still I wonder why the overhead is 10× for funcallable instances on SBCL in general...
21:52:07
_death
Feldman: I'm guessing for the funcallable-instance-function simply having (apply function #'values args) will do.. if the function slot does not change
21:53:45
Bike
i tried making them global and the funcallable instance is called pretty much exactly as quickly as a regular function.
21:55:17
Bike
luckily, death has identified several other horrible efficiency issues to gasp in distress at
21:57:07
Bike
seems like some other stuff will get screwed up too, here. if every lambda expression is made into one of these funcallable things, that's going to inhibit a lot of normal compiler optimizations
21:59:05
_death
Bike: me neither.. there's use of the reader, and that can turn into f-i-s-a or something..
22:03:14
asarch
This is a meme about how hard a programming language could be. What is "The Lambda Tessaract"? Is it related to Common Lisp? https://pasteboard.co/JVwyaeU.jpg
22:47:36
thomasb06
Bike the 'Status' section in the readme.md says to get in touch with Nvidia issue: https://github.com/malcolmstill/ulubis/issues/64
3:17:36
charles`
It has for me too, but in this one situation, it continues to pull form latest quicklisp release
3:22:48
thermo
i'm using sbcl, and i'm struggling to diagnose a slow OOM. i was hoping to get some related info by setting sb-kernel:gc-logfile and inspecting the output --- but nothing seems to be being written. are there further flags i'm meant to set?
3:28:26
thermo
i'd also be happy to just hear generic tips about diagnosing memory problems. if there's a way to see statistics what's still alive and where it was allocated, that'd be amazing