libera/#commonlisp - IRC Chatlog
Search
10:01:42
hayley
Shinmera: What would you want to min/maximise with a "better" GC in Kandria? Minimising dropped frames seems like an interesting target to me, but I'd better check.
10:02:48
Shinmera
on most systems the GC is not a problem as-is, but there's been a couple reports from people that had stutters as a result of GC.
10:03:37
Shinmera
Ideally I could set a deadline for how long a pause will take and distribute it over time, but I know that's a lot to ask for :)
10:03:51
hayley
Yeah, avoiding dropped frames on this system might be too easy; pause times would give more information.
10:05:18
Shinmera
and in the debug settings you can activate an fps counter (will have to use the cheat `i am a developer` to get the debug menu)
10:05:31
Shinmera
you can also use the F10 diagnostics overlay, but that produces garbage of its own, so
10:07:32
hayley
Right. We looked at the GC pause meter there some time ago in #shirakumo. I'm trying to work out a sorta higher level target that I can measure, rather than raw pause times, based on advice that I should look at "user-observed latency". But if my desktop is too good at GCing, there's not much to observe.
10:08:43
hayley
The effect on frame time could be a compromise; it still exists even if I don't drop frames.
10:09:09
pve
Hi! If I call (change-class my-object ...) inside a method body, is it specified what happens if I call (call-next-method) if the class of my-object is relevant to the list of applicable methods for that call to the generic function in question?
10:10:21
Shinmera
pve: the type of the arguments may not change, whether you pass them explicitly to c-n-m or not.
10:11:09
phoe
pve: notes for CLHS CHANGE-CLASS "a programmer must not use change-class inside a method if any methods for that generic function access any slots, or the results are undefined."
10:11:55
Shinmera
hayley: I suppose one thing to look for would be maximum time spent (without GC) between frames. that'll give you a bound for GC time.
10:18:47
phoe
pve: in particular, the effective method may already be computed by the time you change the class, and you may be calling methods that were never intended for the object
10:20:25
phoe
kind of a farfetched example but imagine (defclass foo () ()) (defclass bar (foo) ()) (defclass baz (foo) ())
10:20:48
phoe
and then a generic function with methods defined for all three classes and also :MOST-SPECIFIC-LAST method combination
10:21:23
phoe
if the method for FOO does CHANGE-CLASS on its argument from BAR to BAZ, then the method for BAR might get called with an instance of BAZ
10:23:35
pve
but if I have a normal generic function, with an around method at the least specific level, could the very last thing I do in that method be change-class?
10:25:09
phoe
like, you should be able to C-N-M normally if you CHANGE-CLASS between sibling classes - like, if you had a GF without :MOST-SPECIFIC-LAST, you should be able to call C-N-M freely
10:25:36
phoe
and changing class from BAR to BAZ does not change the fact that the object is still a FOO because both BAR and BAZ subclass FOO
10:27:06
pve
ok I need to see if there's a better way to do what I want, this change-class business might be too scary :)=
10:40:47
pve
phoe: it's dumb, but I'm exploring attaching instances to packages so that I could have a sub-package "MY-APP.FOO" (used in a single file) inherit features from "MY-APP" by querying the parent instance. So when I say (create-package "MY-APP.FOO") it should default to whatever features the parent instance suggests. At the same time, I don't want to "hard-code" how exactly the parent instance and package is
10:42:06
phoe
maybe the trick is to "short-circuit" your function at C-N-M, as in, do not call any next methods - but, instead, you can call the full GF instead, which will redo the dispatch
10:42:27
pve
the child instance for MY-APP.FOO is initially a "dummy" instance, and at some point we call the gf (initialize-package-with-parent child parent)
10:45:15
phoe
or you can split up your functionality in some way - call two functions in a row, the first of which ensures the class is changed, and another that is a GF that will dispatch based on the new class of the object
10:45:28
pve
I could also just have the initialize function *return* the instance that should be used
10:46:03
phoe
returning it makes little practical difference because the instance before changing its class is EQ to the instance after changing its class
10:46:57
phoe
that would no longer be INITIALIZE-FOO but MAKE-FOO if we want consistency with CL naming conventions
10:58:16
pve
btw, my current method of attaching instances to packages in a non-intrusive way is to intern a "special" symbol and stuff the instance in that symbol's plist :)
10:59:04
pve
storing the association in a hash table would be better, but then if the package is deleted, the hash table would have to scanned for deleted packages
11:00:06
phoe
if you control the creation and deletion of your packages then you can write your own code for your DELETE-PACKAGE
11:05:32
pve
a lot of this could be accomplished by a project specific create-package macro, so I'm not sure if all this CLOSsing around is worth it
12:08:56
pjb
gendl__: you may also consider https://gitlab.com/com-informatimago/com-informatimago/-/tree/master/common-lisp/telnet
14:23:28
pjb
Ap0gee: so you could 1- test them sequentially in any order (a first sanity check). and
14:24:11
pjb
Ap0gee: 2- test them in parallel, still independently, in separate threads. To run the tests, you'll need a thread-safe test framework, and not forget to thread-join the threads at the end, before reporting the results.
14:26:09
pjb
Ap0gee: now, of course, the parallel processes may sometimes need to have synchronisation between them. (eg. a consummer and a producer). In that case, you may try to test different situations by adding delays, or other modifications to the code, but it would be more testing the synchronization primitives than anything else. Better modelize the processes and prove they should work, using eg. CSP.
14:26:50
pjb
Ap0gee: of course, you still need to be aware of the limitations of such a formal proof. Have a look at