freenode/#lisp - IRC Chatlog
Search
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
3:31:15
no-defun-allowed
If you break and evaluate (room t), SBCL provides a list of object types which have instances which occupy the most memory.
4:10:06
charles`
beach, no-defun-allowed: I'm not sure 😁. I would really appreciate a you taking a look. It works perfectly on sbcl. Let me write a test that displays what is wrong. Then I will share a link.
4:58:43
minion
charles`: SICL: SICL is a (perhaps futile) attempt to re-implement Common Lisp from scratch, hopefully using improved programming and bootstrapping techniques. See https://github.com/robert-strandh/SICL
5:02:00
charles`
that would be when you need to do some operations, how to decide which registers to put the data in?
5:02:20
beach
It is based on the OPT (imaginary) paging algorithm in that it estimates the distance to the next use of lexical variables, and when it needs to spill, it spills the one with the greatest estimated distance.