1:50:09clintmIs clisp the one that gets updated by loading new code into a previous revs image? I remember reading about a CL that did that as opposed to building a new image like sbcl.
1:50:54ZhivagoYou can build an image from a system built from an imace in sbcl.
1:51:29ZhivagoI wouldn't recommend it these days. Image building is pretty much something that was useful until dynamic linkage became available.
1:51:31Plazmaoh Zhivago you hang out in here too eh?
1:52:12theemacsshibe[m]image making is nice tbh, i use it to distribute lisp programs to non-lisp users
1:53:06Plazmawhile not the same, smalltalk also uses images (that are pretty easy to build/strip down) which is a cool concept I think still, even if it's a bit dated
1:53:51theemacsshibe[m]ehh, it's like having a compiled binary from C IMO
1:54:12theemacsshibe[m]it's possible to mess (especially with -g) with but not as good as having sources
1:57:08Plazmain a sense it reminds me also of the .app binaries mac uses
4:24:13aethDoes anyone else use a macro as the way to access things to avoid potentially dozens of exports in a package? What I've been doing is a with-foo-accessors that places the accessor symbols in the package specified at the definition of that macro and also can add a prefix (for the case of structs with conc-name not set to nil).
4:25:03aethI find that this greatly simplifies things because then I only need to export the with-foo-accessors macro and/or a macro that indirectly uses that macro.
4:26:59aethe.g. (with-foo-accessors ((foo foo)) foobar ...) would macroexpand to (with-accessors ((foo the-package-containing-foobar::foobar-foo)) foobar ...) in the most complicated case (where it's a struct with prefixed accessors)
4:40:31pilltonaeth: Yes, but not to avoid the number of symbols that are exported.
4:44:08aethMy macro, in case anyone's curious: https://gitlab.com/zombie-raptor/zombie-raptor/blob/ec47910d88254d0c6a0e8c0a33aa33c7d4037513/util/util.lisp#L247-260
4:44:36aethdestructuring-lambda is just a lambda that does a destructuring bind on its one argument. It's surprisingly common. In fact, I just now noticed the pattern in define-accessor-macro
5:02:31lokeaeth: What's with the INTERN calls in the macro?
5:09:42aethloke: Otherwise the macro will produce something whose API is (zombie-raptor/util/util::foo)
5:28:01lokeaeth: instead of your reader macro dance, just use (intern "FOO" env)
5:33:15aethloke: I use #.(symbol-name ...) pretty much everywhere instead of hardcoding the symbol as a string of upper case characters
5:38:49aethI know it's essentially pointless, but at least to me it feels better to not hardcode the assumption about the reader that will almost certainly be valid. Perhaps this could be turned into something more concise?
5:42:31aethBut... I suppose I should be using &environment env instead of assuming intern without that argument would work correctly