libera/#commonlisp - IRC Chatlog
Search
6:08:18
flip214
How can I check whether some symbol exists in a package? Do I need to check (eq (find-symbol (symbol-name foo) (find-package :bar)) foo), or is there something like (package-contains (find-package :bar) foo)?
6:11:52
flip214
I'm also not entirely sure whether a symbol always has to have the same name in another package...
6:13:25
flip214
Can I intern eg. a GENSYM into a package later on? (SETF (symbol-package foo) ...) won't work, I guess)
6:16:04
flip214
WITH-PACKAGE-ITERATOR might be a way to find a symbol in a package, but it might be a bit slow for my purposes...
10:54:21
pjb
gin: instead of (lambda () t) which is a new function, or worse, (constantly t) which builds a new closure each time you call it, you could use a function such as (lisp-implementation-type) which will return a generalized boolean true value always, and which already exists in the image, and (eq (lisp-implementation-type) (lisp-implementation-type)) #| --> t |# so it doesn't even cons.
10:54:56
pjb
gin: (setf (fdefinition 'always-true) (fdefinition 'lisp-implementation-type)) (always-true) #| --> "Clozure Common Lisp" |# ;-)
10:56:53
pjb
flip214: you can set the home package of an uninterned symbol, by importing it in the package.
11:00:08
flip214
pjb: doesn't work for me. Value of SYM1 in (INTERN SYM1 :CL-USER) is #:X, not a STRING.
11:00:18
Alfr
pjb, also I'd expect an always-true to take arbitrarily many (up to call-arguments-limit) arguments.
11:13:33
pjb
Alfr: well, there are requirements that gin left unspecified, so (constantly t) is the best solution so far, despite its consing.
11:14:17
gin
thanks pjb for the messages. gave me a lot more to think about and learnt more lisp too
13:15:23
atgreen
I just updated sbcl (2.2.7) and quicklisp (latest), and now my app is generating "CORRUPTION WARNING in SBCL pid 16 tid 16:
13:15:23
atgreen
Memory fault at (nil) (pc=0x54100a44 [code 0x54100750+0x2F4 ID 0xc530], fp=0x7f94219ef4d0, sp=0x7f94219ef4a0) tid 16
13:17:51
hayley
I believe 2.2.7 now puts some constants in a read-only space after SAVE-LISP-AND-DIE, but then there would be a more instructive address rather than (nil).
13:19:43
hayley
The next step should be to work out how to get a backtrace; I think memory corruptions signal CL errors and so you can work it out from there. Or start SBCL with --lose-on-corruption (I think), then you'll land in a debugger called "ldb", and can issue the "backtrace" command.
13:21:01
atgreen
hmm.. this is a little complicated. the app is running on kubernetes, where it needs access to other kubernetes-hosted services to run. I can get in via sly, but will that give me an ldb prompt?
13:26:00
hayley
It won't, so I guess ldb might not be feasible then. You'd have to see if something is swallowing the generated exceptions.
14:47:48
dim
can I have a defmethod with an eql specifier on nil, like (defmethod foo (variant (eql nil)))?
14:49:41
beach
The AMOP uses the preposition "to" for specialization, and I think that's a good idea, so a method "on" a generic function specialized "to" null.
14:51:08
dim
well in my case I'm maintaining code that already has (defgeneric adjust-data-types (catalog variant) (:documentation "Adjust PostgreSQL data types depending on the variant we target."))
14:51:52
dim
it just happens that sometimes the variant is nil, I'm not sure why, and I'm okay with it being nil after all (two values are supported at the moment, :pgdg and :redshift, and nil would behave the same as :pgdg, I'm okay with that)
14:52:15
dim
(defmethod adjust-data-types ((catalog catalog) (variant (eql nil))) catalog) ; that's what I have in my code now
14:52:33
pjb
equivalent to: (defmethod adjust-data-types ((catalog catalog) (variant null)) catalog)
14:53:31
dim
given that context, I think I prefer the (eql nil) specified, it's better aligned with the intention here somehow
14:54:46
pjb
I think using (variant null) is more efficient than using (variant (eql nil)), but that would depend on the compiler.
14:58:04
dim
oh I don't have a perf issue there, it's done in a costly part of the code and only once
14:58:50
atgreen
Using --lose-on-corruption --disable-debugger worked. Corruption triggered in cl-postgres: https://paste.centos.org/view/51641cc2
15:01:07
_death
nasty (safety 0) in that function (parse-message-binary-parameters) which may hide something else