freenode/#clim - IRC Chatlog
Search
7:15:18
jackdaniel
scymtym: to not go on in already merged PR I'll answer here: if /they/ set *package* to something what has defpackage and/or in-package shadowed, arguably they want to augument how these operators behave
7:23:37
scymtym
jackdaniel: i think, as it stands, both solutions are unsatisfactory: on the one hand, as you point out, CL:IN-PACKAGE prevents "injecting" other operators, on the other hand just IN-PACKAGE opens the door to unpredictable behavior since the "read environment" is not controlled by anything
7:24:44
scymtym
so i don't know. in the pr, i honestly chose one over the other out of habit. if we make a policy for McCLIM, i would be fine with either one
7:28:59
scymtym
as i said: i'm fine with either variant (as long as we avoid the (in-package :cl-user) (defpackage …) pattern)
7:30:03
jackdaniel
although I think that asd definitions should have (in-package #:asdf-user) for sake of older asdf (and overall sanity) despite the "asdf best practices" document
7:33:53
scymtym
(using the PRINT-TEST-PAGE thing reveals pretty severe differences between the backends)
7:37:47
jackdaniel
drawing-tests demo tests backends with many drawing cases, you may generate i.e postscript documents or pdf ones with that
7:41:07
beach
What is wrong with executing the DEFPACKAGE form in CL-USER, and in what package should it be executed instead?
7:43:00
beach
CL-USER is known to have the symbol DEFPACKAGE, and the only other package that is sure to have that is CL which you can't use for this purpose.
7:44:04
scymtym
true but a DEFPACKAGE form written as (cl:defpackage #:uninterned … (:use …)) does not depend on the value of *PACKAGE*
7:44:18
jackdaniel
beach: if someone compiles software from *package* which doesn't have standard common lisp symbols it is their own doing, otoh leaving this open for augumentation of operators gives them some opportunities
7:44:59
beach
scymtym: Sure, so that is what you are advocating? I.e., no explicit in-package and always use the package prefix?
7:46:41
scymtym
beach: well, i would say that jackdaniel and i came to the conclusion that either (defpackage …) or (cl:defpackage …), both without preceding IN-PACKAGE, are appropriate, depending on which behavior is intended
7:47:54
jackdaniel
is anyone eager to review (and possibly merge) https://github.com/McCLIM/McCLIM/pull/820 ? maybe loke ?
7:50:24
scymtym
sure, i was just wondering whether work on that pr would be invalidated by the event changes
8:37:44
loke
The drag and drop stuff looks interesting. I don't have time to look at it right now though.