libera/#commonlisp - IRC Chatlog
Search
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