freenode/#lisp - IRC Chatlog
Search
11:05:58
jackdaniel
someone calls (open-connection whatever nil), I'm not sure if there is much moer to it given this scarce backtrace
11:08:24
jmercouris
we have this: https://gist.github.com/jmercouris/b98a3f3e24c47175aa09ea6010b9ef5e
11:10:35
jmercouris
so here is some more interesting stuff, I've used DBUS server/client ping/pong scripts I've written
11:11:04
jmercouris
echo $DBUS_LAUNCHD_SESSION_BUS_SOCKET -> /private/tmp/com.apple.launchd.3vLn74rWFQ/unix_domain_listener
11:11:36
jmercouris
can some of you Linux users please confirm if you have a value for $DBUS_SESSION_BUS_ADDRESS ?
11:35:33
mercourisj
so do you think this is something that belongs in CL D-Bus library, or should be handled by the user? if so, is there a better way?
12:37:55
jmercouris
is it basically only opengl when you want to have a cross-platform graphics lib?
12:39:58
jmercouris
I think the answer is basically just that, opengl or you'll have to maintain platform dependent bindings
12:41:47
|3b|
you need platform specific code to open windows for OpenGL or vulkan, and apple doesn't seem to want to support either
12:42:45
|3b|
(ms doesn't want to either, but let people write their own drivers so can't enforce it as well)
12:43:38
jmercouris
so if someone wanted a cross platform graphics library they would have to abstract these APIs somehow
12:43:40
aeth
jmercouris: Most of the graphics work seems to be on OpenGL paired with something like SDL (cl-opengl is essentially universal; cl-sdl2 is popular, but not universal)
12:44:11
aeth
jmercouris: The only real way to support macOS in the future is with moltenvk and Vulkan, but Vulkan isn't really a CL priority at the moment.
12:45:18
aeth
I mean, the way I see it is, if people just don't drop support for macOS altogether it'll basically be entirely through moltenvk going forward until Apple adopts Vulkan 10-15 years late.
12:46:05
|3b|
presumably opengl will continue to be supported by metal/vulkan wrappers even if vendors don't, like ANGLE does on dx
12:46:46
jmercouris
are you saying that people will write code that wraps opengl -> metal equivalent / vulkan equivalent calls?
12:46:46
|3b|
at some point there will probably be an opengl implementation with vulkan and/or metal backend
12:47:42
|3b|
probably not horrible, drivers are already doing lots of inefficient things for gl anyway :)
12:48:12
aeth
You're not going to be using an Apple computer for maximum performance here, anyway, so a little inefficiency is probably not an issue.
12:48:25
|3b|
biggest thing about the new apis (vulkan, dx12,metal) is just being a lot more explicit about what you are doing
12:49:16
|3b|
still the same hardware underneath, so no real fundamental differences in features, and the newer APIs match newer hardware better anywayy
12:49:54
|3b|
so if you need absolute peak performance, you should probably be looking at those, or at least using GL in a way that translates fairly well to them
12:52:24
jmercouris
I don't understand why they couldn't have just extended openGL to accomodate new features and versioned it up?