freenode/#clim - IRC Chatlog
Search
3:54:27
jackdaniel
a short screencast showing integration of the interactor/listener with the inspector on genera: https://vimeo.com/536080282
5:07:57
lukego
Hey I have a big package MYAPP that will be doing CLIM things. So far I've made a separate package MYAPP-CLIM that uses :CLIM-LISP instead of :COMMON-LISP. Trouble is though that I want to access a lot of internal APIs within MYAPP so the code has a lot of MYAPP::X accesses that feel a bit dirty. How do other applications deal with this? Export lots of stuff? Or put use CLIM-LISP from the main package?
5:27:46
pjb
lukego: well, the later, but the best would be to have lose coupling between your app and clim…
5:29:07
lukego
Yeah but that's not really convenient when hacking away experimentally or writing ad-hoc code to debug internal stuff. Feels more like an optimal solution would be for MYAPP-UI to be able to import internal symbols of MYAPP in those cases.
5:30:08
lukego
but yeah thanks for the sanity check! I guess the trade-offs are more or less the way I imagined them
5:31:20
pjb
lukego: well, you can import the stuff dynamically, or use "conduit" packages. https://github.com/tfeb/conduit-packages
5:32:28
pjb
(do-symbols (s "MYAPP") (import s)) ; this is violent, all local symbols will be imported…
5:33:22
pjb
lukego: what you could do is to define a defpackage MYAPP-EXPORT-ALL with (:export . #.(let (e) (do-symbols (s "MYAPP" e) (push (symbol-name s) e))))
5:33:41
pjb
then you can just load one package definition or the other, depending on the circumstance.
5:43:01
jackdaniel
also for biggish packages I provide two packages: api package that only exports, and (defpackage foo.impl (:use #:clim-lisp #:foo)) where the latter doesn't export anything
6:49:06
lukego
jackdaniel: Good idea. Yeah, my main application package loads okay using CLIM-LISP, I'll try to stick with that.
6:53:43
jackdaniel
lukego: the most important thing the clim-lisp package introduces is a shadowed defclass that records the class definition at compilation time
6:55:07
jackdaniel
we also do something what can't be called a good citizen behavior - #'cl:read is redefined (after taking down temporarily the package lock), but let that not bother you
7:06:11
beach
What about the printer? The standard says it is undefined behavior to specialize the STREAM parameter of PRINT-OBJECT.
7:07:01
pjb
Well, what is undefined behavior here is weither the method will be used to print the object.
7:08:02
pjb
Because to print an object, the implementation may use a stream of any strange class. But print-object can be used directly by application code too.
7:08:22
beach
... or could an implementation use a special dispatch function on PRINT-OBJECT that allows only single dispatch.
7:11:40
pjb
For example, (print obj) could do something like: (format t "stuff ~A stuff" (with-output-to-string (out) (print-object obj out))) so print-object would get a string-output-stream, instead of terminal-io stream or a swank/gray::slime-output-stream, as one could expect…
7:21:14
jackdaniel
the clim interface to presenting objects is clim:present (and that function sometimes calls princ/prin1 etc i.e for the textual-view)
7:22:17
jackdaniel
read is somewhat special, because the data flow is reverse: we want to be able to read from the clim stream (i.e make READ call CLIM:ACCEPT where appropriate)
8:03:47
Krystof
For what it's worth, sbcl would like to discourage specializations of the stream argument of print-object
8:04:26
Krystof
the reason is to do with being able to guarantee printing conditions and restarts even in cases of heap or stack exhaustion
8:05:07
Krystof
we build a special discriminating function for print-object which always has the effective methods for printing conditions, restarts and one or two other things precomputed
8:05:27
Krystof
but our precomputation assumes that there aren't specializations of the stream argument; if there are, we give up and you're on your own :-)
9:25:55
dim
hi! how can I find out which of my ASDF dependencies or their dependencies require a given system, here CFFI (or actually abcl-cffi)?
9:41:21
jackdaniel
maybe because dim wants (format-graph-from-roots "cffi" #'print (lambda (s) (asdf:system-depends-on (asdf:find-system s)))) ;? :)
9:42:04
dim
I have too many problems with just being able to load pgloader in any CL implementation today to even consider doing McCLIM on macOS this week, you know
9:43:19
dim
SBCL 2.1.3 is broken (sigabort), CCL 1.12 is broken (sigabort), ECL is broken (too many open files), ABCL seems to work but I need to avoid loading some CFFI systems (that I will replace with JDBC components or Java native things anyway)
10:05:32
lukego
annoying that CLIM and ALEXANDRIA conflict on SIMPLE-PARSE-ERROR when you USE-PACKAGE both
10:10:29
scymtym
there is no choice for McCLIM since SIMPLE-PARSE-ERROR is in the CLIM specification
10:11:06
lukego
and actually the annoying part is mostly just my ignorance about how easy this is to resolve with :shadowing-import-from. kicks the can down the road a bit anyway...
10:12:00
lukego
hm it doesn't seem to be mentioned in the alexandria documentation so maybe it could even be changed there potentially
10:34:52
lukego
Since SIMPLE-PARSE-ERROR is not referenced in Alexandria's reference manual it could potentially be renamed to avoid a conflict. Or at the least, I can shadow it without worrying about confusing myself with the Alexandria docs in the future
10:35:58
lukego
but I'll probably tease my code into more structured packages later. first I need to celebrate the milestone that I've started testing and refactoring more than just sketching and rewriting.
10:45:45
jackdaniel
many people will disagree, but I find too many packages in a single project very taxing on maintanance
10:48:14
lukego
ACTION nods, more than one way to do it, glad to be able to just do what feels right