phf: gabriel_laddel: i was drunk when answering you last time. i like the idea of a self-contained lisp system with ux built on top of xproto/xlib/zen, because can still attach c program outputs, and stream own output to unix systems proper. i've been building my own tools to be essentially a combination of cmucl repl, that spawn xlib windows on demand. not sure if you know but x is essentially a binary network protocol (described in

phf: variations of "X Window System Protocol" documents), with xlib being its C implementation. core protocol is pretty simple, but problems start with protocol extensions of various levels of retardation (like xinerama, etc.)

phf: how xserver talks to hardware is entirely outside the scope of protocol, since server accepts the xproto packets and then does rendering

phf: main problem with zen right now is that it does rendering, but it uses opengl (glx specifically) as the framebuffer. i've not looked at the implementation bits, but i assume that it goes beyond simple blit, so you might be able to retarget it to other opengl, but not necessarily straight to framebuffer, without implementing your own blit level rendering primitives

phf: also zen doesn't support most of the modern x11 extensions, that you might want for running something like firefox. in fact last time i checked it didn't support xrander, which is an old image composition extension that might as well be standard

phf: !up gabriel_laddel

phf: gabriel_laddel: gnuplot, xfoil kind of output, i.e. batch graphic, or anything that requires input with a mouse

phf: i know you do clim, but running clim through zen is essentially simultaneously trying to debug two 70% speed/coverage projects. even simple handwritten xlib proggies don't work out of the box.

phf: gabriel_laddel: i'm saying that it's only worthwhile to bring in zen if you want to ultimately do x11 support for foreign code. right now your problem is clim+xlib, you want your problem to be clim+xlib+zen+cl-opengl+glx. if the ultimate goal is drop x, then might as well try and retarget clim to framebuffer. the two (adding zen and framebuffer clim) or at 100% identical in the amount of effort

phf: mircea_popescu: i think that there's a bunch of people trying to chuck moore their way out of "modern computing" here, as such there's not native anything

phf: *people here

phf: mircea_popescu: here as in in #b-a

phf: mircea_popescu: oh, no, that was the answer to "there is no native lisp gfx engine?"

phf: everything talks to xlib, win32, carbon/cocoa and on top of that to opengl, directx. there are parts of that stack implemented in lisp (either as clients or as hosts). there's no opengl in lisp, there's opengl client in lisp. there's both xlib client and server in lisp, etc. there's not enough lisp code to run the whole graphics stack from the lisp machine to the video card end to end

phf: mircea_popescu: the spirit is willing, but the flesh is weak?

phf: mircea_popescu: oh they do, that's a common argument

phf: mircea_popescu: there's a limited number of lispers and they all scratch their own itch. without centralized visions results barely compose. gabriel_laddel needs working clim for his projects. robert strandh only occasionally hacks on mcclim anymore, spends most of his time on n-th rewrite of emacs, etc. and of course there are arguments of what the components should be and how they should compose. the only common ground is the

phf: specification and some symbolics artifacts

phf: here's an s-graphics made animation instead https://www.youtube.com/watch?v=BdTGJChDKrM

phf: my condolences, mp

phf: irc messages go over a loose knit federated system that's entirely outside of your control. even if you do dcc it's plaintext on the wire ☟︎

phf: copypaste: the fact that your "tens of thousands of dollars" deals have not been compromised is entirely due to "uncatchable joe" factor. is russian joke, "this there is uncatchable joe. -- woah, nobody can catch him? -- no, nobody cares to"