freenode/#lisp - IRC Chatlog
Search
1:11:30
aeth
There's https://github.com/sharplispers/clx/blob/master/extensions/gl.lisp and there's https://github.com/3b/cl-opengl/
1:15:05
aeth
Is there anything that stops a CL X client from using cl-opengl? It looks like there's something called DRI that bypasses the X server. https://en.wikipedia.org/wiki/Direct_Rendering_Infrastructure
1:16:07
aeth
Unless I'm mistaken, it looks like it might be possible to write a pure CL 3D application for Linux except for OpenGL (and sound?) by writing an X client.
1:18:08
aeth
The Windows backend would still have to use more foreign code, either directly or through something like cl-sdl2.
1:30:48
aeth
I'm starting to think that the only way I can get the level of control I want for my game engine is to either write my own X client or write my own wrapper to xlib and then keep the cl-sdl2 backend for Windows until I eventually replace it with something built on the Windows API directly.
1:39:32
pfdietz_
Time prints to a stream, so with-output-to-string lets you bind the appropriate stream variable to a string-stream, then return the string.
1:39:37
aeth
(with-output-to-string (string-stream) (let ((*trace-output* string-stream)) (time (+ 1 2))))
1:40:01
emaczen
aeth: I was looking for *trace-output* -- I literally tried all streams except that one!
1:40:21
aeth
The hyperspec says trace output. http://www.lispworks.com/documentation/HyperSpec/Body/m_time.htm
1:44:58
aeth
Generally, for timing you want this (* (/ internal-time-units-per-second) (get-internal-real-time)) unless its precision is too low (then you might need a foreign library? strange how its precision in SBCL is lower than SBCL's time precision)
1:46:33
aeth
Except you probably don't want rational, so you probably want to define a constant that's e.g. (coerce (/ internal-time-units per-second) 'double-float) because otherwise SBCL will complain (at max optimization level) that it can't really optimize it.
1:47:45
aeth
double-float will almost certainly cons under normal circumstances, which could affect your timing. One way to avoid this that might work on some implementations (it works in SBCL) is to work with double-floats stored to arrays of :element-type double-float.
1:49:26
aeth
e.g. (defconstant +seconds-per-time-unit+ (coerce (/ internal-time-units-per-second) 'double-float)) (declaim (inline %current-second)) (defun %current-second () "Converts internal CL time to a double-float second." (* (get-internal-real-time) +seconds-per-time-unit+))
1:50:03
aeth
You'll want to inline that function because (1) it's trivial arithmetic that should never change and (2) otherwise you'll allocate a double-float when you can avoid that by setting to double-float arrays
1:52:37
aeth
#'%current-second will appear to cons if you disassemble it, but if you use it in a setf to an array of :element-type 'double-float it should potentially be non-consing, depending on if the implementation is that advanced. SBCL handles it afaik.
1:54:12
aeth
You can define a struct that's really just a vector if you want to have a higher level interface above the array, e.g. (defstruct (times (:type (vector double-float)) (:conc-name nil)) (current-time 0d0 :type double-float) ...) and make sure to always setf values of that struct with no non-constant intermediate doubles.
2:03:48
aeth
This portable code should be non-consing in SBCL for a time struct of 3 values: (defun time-diff (times) (declare ((simple-array double-float (3)) times) (optimize (speed 3))) (setf (new-time times) (%current-second) (time-diff times) (- (new-time times) (current-time times)) (current-time times) (new-time times)) times)
2:10:58
aeth
single-floats should be non-consing in most if not all 64 bit implementations, but it afaik depends on the time interval you're working with. If you do a short non-consing workaround and then coerce the end result to 'single-float, if you're careful, you shouldn't cons anywhere along the line
2:14:54
aeth
The custom function should be update-time-diff and then you can add one more function to get the single-float value, which won't cons: (defun time-diff-to-single (times) (declare ((simple-array double-float (3)) times) (optimize (speed 3))) (coerce (time-diff times) 'single-float))
2:17:29
aeth
I use something very similar and I just tested these in the REPL and they should be non-consing in SBCL. (Other implementations might cons, but if they do, someone should probably submit a patch. The hardest one to patch would be CLISP because it doesn't even have double-float arrays.)
2:28:30
aeth
and it should match the first line of SBCL's time, that says e.g. "3.610 seconds of real time"
2:42:37
aeth
It doesn't appear to cons in the disassemblies. It does appear to cons slightly when I run it repeatedly in sb-profile:profile, but I think that that's the struct itself. (declare (dynamic-extent ...)) might even be able to get rid of that. (room) doesn't show up any double-floats so it's probably good enough in SBCL. I'm not sure how I could profile other implementations to check.
3:34:31
drmeister
I'm using ASDF to build a monolithic fasl file for several systems that have dependencies between them.
3:35:20
drmeister
It uses (asdf:load-asd ...) for every dot-asd file that is part of the final monolithic bundle
5:42:37
drmeister
If the package :energy does not exist (find-package :energy) -> NIL then the system should signal a package-error - correct?
6:09:25
pjb
drmeister: defpackage forms cannot include circular dependencies. For this you have to use run-time package functions.
6:23:14
drmeister
Monolithic ASDF builds for the win - I can package up all of the cando Common Lisp source code along with cl-jupyter, cl-jupyter-widgets and nglview (for viewing molecules) into a single fasl file.
7:26:19
borodust
phoe larsen: that's unfortunate, but no :) i forged the API before Shinmera's :flow was introduced: naming is so hard, i don't feel like redoing all the name-fiddling again :/. More details in the issue comment.
7:42:17
borodust
obviously, i'm the only one to blame for not pushing :cl-flow to quicklisp, but at the time i didn't feel like it was complete enough
7:59:00
borodust
Shinmera: nope, this nicknames is introduced exactly for the reason to have sound full symbol names
8:10:27
larsen
yesterday night I was commenting on the general idea of nicknames defined by package authors. it seems to me a bad idea in general: wouldn't they serve the same purpose if it was the user assigning them when a package is used ?
8:24:24
larsen
I'm more concerned about one bit in the comment to the issue: " those two systems (this and Shinmera's flow) would never be able to coexist". Besides naming, do you see any other technical problem preventing them to work together ?
8:25:24
borodust
i meant that i'm not going to rename package and neither Shinmera, i'm pretty sure ;p
8:28:59
borodust
larsen: oh! Fare has a thing exactly for such cases: https://github.com/fare/package-renaming
8:30:10
borodust
now that's a good reason to have whatever convenient nickname and jibberish main package name (java-style or whatever)
8:47:48
Shinmera
borodust: It's already released on QL and people might be using it, so I can't without breaking people's code.
8:50:23
Shinmera
Before I release anything I always check QL for systems with the same name to avoid problems like this
8:52:39
Shinmera
I also prepare for the day when package-local-nicknames will be available on all implementations that matter by internally using FQDNs. I could then remove the shorter name for all of my systems in a big, breaking change. Alas I don't see the p-l-n future coming any time soon.
8:55:44
borodust
i'll investigate Fare's package-renaming and maybe add something convenient for bodge dist users
8:57:07
Shinmera
In other news apparently Harmony's WASAPI backend is pretty badly broken... but only on some Windows setups. SIGH.
10:21:28
resttime
Is there a good way of handling C opaque structures as pointers without know the size of the structure in the CFFI?
10:26:18
Shinmera
I don't know what you mean. You have a pointer and you want to do... what with it?
10:27:46
Shinmera
The struct is going to remain in memory whether you have a pointer to its starting address or not
10:29:50
resttime
So I'm forced to define the cstruct with CFFI and then allocate the structure before then passing
10:31:03
resttime
varjag: There isn't, Use cases seem to be defining the keystate like: ALLEGRO_KEYBOARD_STATE keyState;
10:31:05
p_l
varjag: looks like there's no allocator, but you're expected to do malloc(sizeof struct_type)
10:31:36
Shinmera
What you do in this case is write a C program that emits the sizeof and then just allocate that.
10:32:20
Shinmera
Remember to run that program and record the size for all systems you want to run on. It might change!
10:32:53
Shinmera
Zhivago: Then you'd have to compile that C program on every system and you'd be back to the same deal.
10:33:24
resttime
I was hoping to be able avoid external C stuff, but I guess it's "impossible" after all.
10:35:10
resttime
p_l: Well they do have a new event system which mostly gets used. Someone using the bindings I wrote for allegro was wondering if there could be more support for the keyboard routines, so I started looking into this
10:38:58
resttime
Shinmera: Well at this point I'm thinking that the structure probably won't be changing so I'll define the opaque type and write a WITH-KEYBOARD-STATE macro that could work
10:42:15
Zhivago
resttime: If the structure is opaque, you should not be allocating yourself in the first place. There is somewhere that it will have a complete type, and that's where the allocator needs to be.
10:43:29
resttime
http://www.gamefromscratch.com/post/2017/11/10/Allegro-Tutorial-Series-Part-4-Keyboard-and-Mouse.aspx
10:47:59
Zhivago
opaque is gibberish made up by people to express an intent realized via a pointer to an incomplete type.
10:48:29
Zhivago
struct foo; <- this type is incomplete here. struct foo { int i; }; <- Now struct foo is a complete type, and has a sizeof, etc.
10:54:01
borodust
resttime: shameful self-plug: if all you need is simple graphics, audio and input for your game w/o diving into native and/or configuration land, trivial-gamekit might work for you
10:55:10
resttime
borodust: Counter plug, if you need a monolith game programming library you can use my cl-liballegro :D
11:12:40
borodust
resttime: not only that, but you would require users to install whole gnu thing onto their machines for groveller to work :/
11:13:27
resttime
borodust: Also cl-bodge looks interesting, game engines and stuff are currently above me since my knowledge is meagre :P
11:15:20
resttime
Maybe one day I'll have my own to add onto the pile of game enginers laying around
11:18:01
resttime
borodust: In your exp do think making a game is orthogonal to making a game engine?
11:18:12
borodust
cl-bodge is a pile of functionality at the moment with vast api i literally don't have time to cover with docs - part of the reason trivial-gamekit exists
11:19:35
borodust
unless there's not tools, but then you would just write specific tool, not an engine
11:53:10
Shinmera
resttime: If you're interested in gamedev and game engine dev: I have a weekly stream on Sundays where I do exactly that. https://events.tymoon.eu/1 https://www.youtube.com/playlist?list=PLkDl6Irujx9MtJPRRP5KBH40SGCenztPW
11:56:47
borodust
resttime: i also can recommend Bagger's vids: https://www.twitch.tv/baggers___ https://www.youtube.com/channel/UCMV8p6Lb-bd6UZtTc_QD4zA
11:57:25
borodust
Pushing Pixels with Lisp series: https://www.youtube.com/watch?v=82o5NeyZtvw&list=PL2VAYZE_4wRITJBv6saaKouj4sWSG1FcS
11:59:50
borodust
resttime: also i can recommend #lispgames channel for sharing and acquiring lispgamedev experiences (not always on topic)
12:03:43
beach
wxie: You may be wasting your time. paule32 has come here for quite some time, and he doesn't follow the advice he is given.
12:04:17
beach
wxie: He continues to submit code that does not follow accepted conventions, and he refuses to go read a book about Common Lisp.