freenode/#lisp - IRC Chatlog
Search
13:48:04
ralt
phoe: it's a known bug with gitlab... wait for the page to be fully loaded before clicking on the SSO buttons.
13:55:37
ralt
Gitlab is very good with progressive enhancement. When the JavaScript hasn't finished loading, the SSO buttons will do a GET. But the backend only supports POST. So you get a 404 if you click too fast.
17:14:39
lukego
Just running around in my head... I think if you wanted to do CLIM like presentations in Emacs you'd use Vecto. Each discrete object would be rendered separately to create a mask for (X,Y) positions where it can be clicked (imagemap) and then the composite image would be displayed inline by Emacs.
17:15:17
lukego
Emacs has SVG support built-in but that's actually just converting to a bitmap as the first step so no real upside to letting Emacs do the rasterization
18:26:31
markasoftware
I noticed a library on Github that "added" a superclass to all instances of a metaclass by specializing `compute-class-precedence-list` as `(cons the-extra-superclass (call-next-method))`
18:27:07
markasoftware
Is this the right way? I thought compute-class-precedence-list was just supposed to sort the superclasses.
18:41:38
Bike
"All methods on this generic function must compute the class precedence list as a function of the ordered direct superclasses of the superclasses of class. The results are undefined if the rules used to compute the class precedence list depend on any other factors. "
18:44:38
Bike
that particular definition sounds wrong cos the next method will have the class itself as the first element, though, i think
18:48:30
markasoftware
well, the-extra-superclass is not a direct or indirect superclass -- it is arbitrarily added by the compute-class-precedence-list. I'm quite sure this author is going against the spec
18:50:28
fwoaroof[m]
e.g. when it talks about standard-object being the superclass of every class of type standard-class or something like that?
18:55:39
fwoaroof[m]
sbcl's standard-class has thi in DEFAULT-INITARGS: :direct-superclasses (list the-class-standard-object)))
18:56:46
sjl_
This paper goes to extra pains to not include the special class in the superclass list if a superclass already does, but I'm not sure why. Just general cleanliness?
18:57:39
fwoaroof[m]
if STANDARD-OBJECT is a direct superclass of every class, it'd probably make DEFMETHODS behave unexpectedly in some edge cases
18:58:42
sjl_
I'm not sure about standard-object, but in the example they're adding a different class they've defined... I don't think it would really make a difference one way or the other in their example.
19:00:00
fwoaroof[m]
I forget the class precedence rules, but in (defclass a (foo)) (defclass b (a)), you might run into issues if they both have C as an implicit direct superclass
19:00:30
fwoaroof[m]
because you probably want a DEFMETHOD to prefer a method on A to one on C when called with an instance of B
19:00:58
sjl_
Maybe that's what they're worried about. I haven't though it through all the way (and can't at the moment). Would be interesting to have a concrete example where it would cause an obvious problem.
19:02:11
markasoftware
they are making a json serialization metaclass, and they want a method that is only applicable to objects from classes that are json-serializable
19:04:04
markasoftware
also fwoaroof[m], I do see the default-initargs :direct-superclasses on standard-class now that I look at it, but SBCL additionally checks this in shared-initialize
19:04:41
markasoftware
there's what amounts to a (when (null direct-superclasses) (setf direct-superclasses (list the-class-standard-object))
21:27:57
seok
Would it be a bad design to define a lot of similar classes, say 4000 of them? how big of an overhead would that be?
21:31:22
Xach
seok: not inherently bad, but that number would require some pretty decent justification and abstraction.
21:33:19
seok
But would it be a bad idea to make a prototype for each of those units with (defclass name (unit)) ?
21:34:53
seok
In the former case the blueprints for each of those unit would have to be stored somewhere anyway, so how bad is it to store them as class definitions?
21:39:31
tychoish
I tend to think of classes as "kind of thing" and then have instances for "the collection of things," and have all of the different kinds of things be parameters/slots on the class
21:41:25
tychoish
I heard a trick, I think from like Ward Cunningham or something, where you give yourself three index cards and attempt to model the objects in whatever problem you're working out in terms of the three cards, and it's a bit extreme, but broadly, it's how I model things, I think
21:43:03
mfiano
Inheritance trees quickly turn into graphs in any sophisticated game design, not to mention it is not great for the CPU cache, and after all game development is all about efficient data transmission.
21:44:40
seok
So you'd mach rather a method which makes instances of one definition of class rather than few thousand of them?
21:44:55
mfiano
With inheritance, you keep pushing slots up to the root until you have a "god object" that everything inherits from.
21:45:40
tychoish
seok: it really depends on the use case. I tend to be "small numbers of classes" and "composition over inheritance" but also i don't write games
21:45:57
aeth
Unless they're multiplayer and the code is shared with server code, the processes tend to be short-lived
21:46:48
mfiano
We already have that, to some degree. Virality Engine has been in active development for 4 years and behaves very similarly to Unity or Unreal already, sans the GUI.
21:47:05
aeth
GUI-oriented game engines don't really fit the same niche that Common Lispers are in, so it's doubtful that a CL game engine's editor would use similar principles
21:50:18
aeth
Other engines include https://github.com/borodust/cl-bodge https://github.com/vydd/sketch/ https://github.com/cbaggers/cepl https://gitlab.com/dto/xelf https://github.com/Shirakumo/trial https://gitlab.com/zombie-raptor/zombie-raptor
21:50:40
aeth
There's a fairly active community over at #lispgames but it hasn't really been active this month. The summer? Corona? Who knows
21:50:56
aeth
A few other engines haven't been active in a while, e.g. https://github.com/BradWBeer/CLinch
21:51:21
mfiano
drawing pictures is done by constructing geometry, filling buffers, applying some linear algebra, and writing shaders. Same as any other modern game engine :)
21:52:15
aeth
I think a lot of people were on IRC in the background while at work, and that's suffered a bit in 2020
21:53:28
mfiano
Virality Engine is in the process of a huge overhaul. We had to develop a custom CPU emulator to support the component ordering in an atomic fashion. We're almost done writing that CPU, after nearly a year and a half. That is the reason for the lack of commits, but we are working on it live on stream every week.
21:53:39
aeth
https://github.com/bufferswap/ViralityEngine https://github.com/borodust/cl-bodge https://github.com/borodust/trivial-gamekit https://github.com/vydd/sketch/ https://github.com/cbaggers/cepl https://gitlab.com/dto/xelf https://github.com/Shirakumo/trial https://gitlab.com/zombie-raptor/zombie-raptor https://github.com/BradWBeer/CLinch
21:54:26
aeth
There are lists e.g. on the Lisp games wiki, but they're out of date and incomplete, e.g. still calling Virality "First Light". https://github.com/lispgames/lispgames.github.io/wiki/Common-Lisp
21:56:35
aeth
My engine is Zombie Raptor (2013), which might be the second oldest after dto's xelf (2007???), but progress is glacial because it focuses on high-performance, which has involved... quite a lot of from-scratch work, e.g. my own utility library.
21:57:28
aeth
Quite a lot has spun out of that project over the years, including an entire R7RS-small implementation in Common Lisp that's almost ready. I'm trying to complete it before the end of 2020, which is why I've been neglecting my engine this year.
21:57:39
seok38
So it looks like there are a lot of small groups each working on different game engines
21:57:45
mfiano
Virality Engine is the concatenation and reorganization of code back to 2008 from 3 developers.
21:58:06
seok38
Do each of these game engines serve a different niche? Or is there a chance for one big general game engine?
21:59:09
aeth
CEPL is more of a thing focused on live-coding than a proper engine, Virality is focused on proper architecture, cl-bodge is more about wrapping foreign libraries than most Lispers are comfortable with, and Zombie Raptor is designed around unnecessarily-high performance requirements just to prove that it's possible
21:59:39
mfiano
sketch doesn't have any concepts found in a game engine. bodge is a collection of bindings so more of a framework, etc.
22:00:07
aeth
You could argue that every Common Lisp game engine is actually a game framework since these days, "game engine" often implies that there's an editor
22:00:20
mfiano
A game engine contains collision detection, draw order, prefabs, and other concepts needed for game development.
22:00:59
mfiano
That said, a game engine is nothing more than a set of choices someone made for you, so it is possible a game engine unless very general purpose and developed by hundreds of people, is not the right choice for your game
22:03:51
mfiano
Virality Engine's running game is its editor for the most part. It's just that, everything (about a couple dozen DSLs) is live recompilable, so instead of using that mouse thing, you just redefine a prefab and anything composed from it is updated on the spot, or a texture definition, or a component, or game logic, etc
22:04:48
seok38
mfiano, I've got some game engine specific questions, mind if we move to #lispgames?
22:05:22
mfiano
It also has a custom shader language so GPU functions and their dependencies are also update-able online.
22:06:30
mfiano
I mostly only pay attention to #bufferswap, as its where all my energy is emitted :)
22:07:05
aeth
And as for "why doesn't everyone just work on one engine", this highlights why people have different design priorities. For instance, my engine's basic design philosophy is, essentially, "Do everything at compile time if possible."
22:07:18
aeth
I'll insert some live coding features where possible at some later date, but I mostly focus on elaborate macros.