freenode/#lisp - IRC Chatlog

12:01:45 DGASAU ** NICK ASau

12:09:18 ASau ** NICK DGASAU

12:25:33 DGASAU ** NICK ASau

12:31:16 ASau ** NICK DGASAU

13:07:48 pjb flip214: no, we're not: https://twinstrangers.net

13:42:27 tetero phoe: Oh god. I call that "get alongism"

14:25:52 schweers when I have an object like this: #<MYCLASS {100359AB03}> the last part is a memory address or some other kind of identity, right? Can that change over time due to the garbage collector? I’m using sbcl

14:27:01 Bike it is, and i don't know, but it's possible.

14:27:01 Shinmera It is a representation of the object's identity, and thus cannot change.

14:27:02 schweers or when threading is involved?

14:27:35 Bike the identity is only used in print-unreadable-object. i don't think there are any guarantees on it at all.

14:27:36 schweers Shinmera: even if it’s the address? or is the original address saved somehow?

14:27:44 schweers hmm

14:28:15 Bike you should definitely not rely on it meaning anything in particular.

14:28:17 Shinmera Well, I can't find a guarantee in the spec that it won't change

14:28:37 schweers Bike: I normally wouldn’t, I’m debugging a really weird bug

14:28:47 Bike What is it?

14:30:01 schweers I pass an object via a closure to another thread. I do this in a loop. Normally each thread should have its own instance of this object/class (it’s basically a calispel:channel). But for some reason I have the situation that two or more threads share an object, thus weird things happen

14:30:13 beach schweers: It can definitely change over time.

14:30:21 schweers beach: thanks a lot

14:30:40 schweers not what I hoped for, but good to know

14:30:56 schweers can this behaviour be changed, at least temporarily?

14:31:12 beach schweers: You can try to avoid running the GC.

14:31:16 Bike you can define your own print object method that prints some more specified identity

14:31:17 Shinmera FWIW I have yet to observe it changing, at least during debugging.

14:31:21 Bike a value in a hash, for instance

14:31:34 beach schweers: Why do you not want it to change?

14:31:51 Bike however, for your problem it sounds like you could just eq-test objects from different threads?

14:32:02 schweers beach: normally I wouldn’t care, but I’m trying to debug a situation where I care about identities

14:32:16 beach schweers: The identity remains the same.

14:32:30 beach If you compare it to a saved value, they will be EQ.

14:32:47 schweers I’m not sure how to grab references to both objects to put them into an EQ call

14:33:17 beach schweers: So what are you attempting instead? Visual inspection of the printed representation?

14:33:24 schweers for now, yes

14:33:32 schweers which obviously fails

14:33:57 Shinmera When you create a thread, push its object to a global list or something, and then look at it to see if any of them are the same

14:34:18 beach schweers: Try comparing the sxhash then.

14:34:28 schweers beach: sxhash?

14:34:42 Shinmera ::clhs sxhash

14:34:43 Colleen Clhs: function sxhash http://www.lispworks.com/documentation/HyperSpec/Body/f_sxhash.htm

14:34:43 beach clhs sxhash

14:34:44 specbot http://www.lispworks.com/reference/HyperSpec/Body/f_sxhash.htm

14:34:58 schweers hmmm, never heard of it, I’ll take a look

14:34:58 jackdaniel sxhash doesn't guarantee distinct values for distinct objects (try calling it on two different vectors on sbcl)

14:35:50 beach jackdaniel: No, but at least it won't change as a result of GC.

14:37:01 schweers thanks for the tip, I’ll try it out

14:37:22 beach Sure. Write a method in print-object specialized to your class that uses (say) sxhash.

14:37:43 beach It is not perfect, but it is very unlikely that two objects get the same value then.

14:38:20 schweers clhs print-object

14:38:20 specbot http://www.lispworks.com/reference/HyperSpec/Body/f_pr_obj.htm

14:38:23 beach schweers: Other possibility: add a slot to your class and initialize it to some huge random number.

14:38:32 schweers this this the method I want to use?

14:38:41 schweers or a gensym

14:38:42 beach You want to write one.

14:38:53 schweers yes, but is print-object what I’m looking for?

14:38:58 beach Yes.

14:38:59 schweers i.e. what I want to specialize?

14:39:01 schweers thanks

14:39:12 schweers never done this, only read about it (not in much detail)

14:39:49 beach (defmethod print-object ((object my-class) stream) (format stream "..." (sxhash object)))

14:40:04 beach But you might still want to use PRINT-UNREADABLE-OBJECT.

14:40:28 schweers “use” as in explicitly use?

14:41:33 beach (defmethod print-object ((object my-class) stream) (print-unreadable-object (object stream :type t) (format stream "~s" (sxhash object))))

14:41:45 schweers ah, thanks a lot

14:43:09 beach Anytime.

14:44:35 pjb schweers: clhs print-unreadable-object says: If identity is true, the output from forms is followed by a space character and a representation of the object's identity, typically a storage address.

14:45:37 beach pjb: Except that I don't think schweers knows that PRINT-UNREADABLE-OBJECT is what is used by default for printing his objects.

14:45:40 pjb The identity of an object should not change (even if its address changes), so I would expect it not to change. But I guess an implementation may consider the identity at the instant of printing, not over long periods.

14:45:42 schweers pjb: and I’m afraid that changes

14:46:06 beach pjb: So he doesn't (or didn't) know whether that value could change over time.

14:46:46 beach pjb: And in SBCL, it does change as a result of the GC moving the object.

14:46:47 pjb AFAIK, most implementations use the address there, and since the address may change, it's safer not to rely on it over time, to identify the objects.

14:47:09 pjb This is rather confusing during debugging…

14:47:16 beach Very much so.

14:47:32 beach Makes it impossible to do it visually as schweers wanted to do.

14:48:02 beach Like in a trace, the same object may have a different appearance at different times during the trace.

14:48:12 pjb Better to allocate your own object ID in a slot to each objects you want to identify.

14:48:24 Shinmera using something like UUIDs for that is a good idea.

14:48:26 beach That was one of the suggestions, yes.

14:48:50 schweers I guess I’ll have to do exactly that

14:49:19 beach sxhash is workable, and quicker.

14:49:40 pjb sxhash is far from being a unique identifier…

14:49:40 shka well, it that's just for debugging

14:49:52 schweers if I use (gensym) repeatedly, it it guaranteed that the result always has a distinct printed representation, at least if done within one thread?

14:49:57 pjb Some implemnetations had degenerate cases…

14:49:59 shka you may just copy, right?

14:50:22 beach schweers: GENSYM should be fine.

14:50:37 beach schweers: It must be global, not per-thread.

14:50:58 beach shka: Copy?

14:51:11 Shinmera Running a primitive test, it takes //a lot// of allocation before the GC kicks in and decides to move my instance, thus changing the printed ID.

14:51:35 shka ‎[16:32] ‎<‎schweers‎>‎ beach: normally I wouldn’t care, but I’m trying to debug a situation where I care about identities

14:51:54 shka so i would simply try to log diffs and call it a day

14:52:29 beach shka: You speak in riddles.

14:53:08 shka i mean that schweers does not actually care about unique ids for classes, but he seems to just debug how content of class changes in another thread

14:53:23 shka or at the very least that's my impression

14:53:29 beach shka: I think you totally misunderstood.

14:53:40 schweers I believe that I have come the conclusion that my problem was not the gc moving objects around after all, yet I still have no clue what the problem actually is :/

14:54:23 beach schweers: Well, now you have one element of uncertainty removed.

14:54:28 Shinmera schweers: I've been having no idea what the problem in my system is for weeks.

14:54:40 shka beach: perhaps

14:54:59 schweers I do something like this: (iter (for obj in ...) (make-thread (lambda () ... s ...) :name ...))

14:55:20 schweers if I log `s' on every iteration they all turn out to be distinct (as expected)

14:55:21 shka yes?

14:55:34 Bike iter may not establish a new binding for each closure.

14:55:46 schweers yet on the other hand, there are at least two of these threads which have the same object

14:55:47 shka it does not

14:55:51 schweers uuuhhhhh

14:55:58 Bike try (let ((x s)) (lambda () ... x ...)) instead?

14:56:00 schweers but not all objects have the same

14:56:01 shka schweers: use map

14:56:06 Shinmera Make a (let ((s s)) ..) around your make-thread

14:56:56 beach So everybody except me understood that OBJ and S were the same?

14:57:02 schweers oops

14:57:06 schweers yes

14:57:12 shka beach: yup ;-)

14:57:15 beach ... as usual.

14:57:15 Shinmera beach: I was wondering about that too, but just assumed it was a typo.

14:57:26 beach ACTION is getting used to it.

14:58:02 shka beach: i thought that you already obtained your telepathic powers

14:58:08 schweers ACTION is now really confused, as that actually solved the problem

14:58:09 shka what a shame ;-)

14:58:15 shka schweers: yeah

14:58:36 schweers I’m really confused as to why ITER does this, it just seems wrong

14:58:41 beach I think my training as an engineer has given me this occupational disease.

14:58:43 schweers or is that intended?

14:58:47 Shinmera schweers: what iter does is probably something like this: (let ((s NIL)) (loop-somehow (setf s next-object) ...))

14:58:49 shka schweers: closure takes value from lexical env

14:58:55 shka you are changing value in the lex env

14:59:00 shka closure value is changed

14:59:02 schweers ugh, you’re probaly right

14:59:05 schweers ACTION sighs

14:59:07 beach schweers: It's the same for LOOP. The standard gives an option to behave this way for LOOP.

14:59:18 schweers you guys have been really helpful once more, thank you very much

14:59:29 Shinmera Modifying the binding is cheaper, so usually that's what loops do.

14:59:47 beach That's certainly what SICL LOOP does.

14:59:55 shka schweers: try this (let ((result nil)) (map 'nil (lambda (x) (setf result x)) '(1 2 3 4 5))

15:00:11 shka oh anyway…

15:05:55 rumbler31 sorry if this is obvious. I'm trying to work with a remote repl for which the network connection peridically drops

15:06:26 rumbler31 I renamed the emacs buffer for this connection. but when the connection drops and I re-issue slime-connect, a new repl opens instead of using the existing one

15:08:16 rumbler31 I get the impression that the emacs side is looking to open a buffer of the name *slime-repl implementation* and if it finds one, prompts me if I wish to close the old connection. I think if I say yes, the old buffer is reused, if no, a new repl is made

15:08:54 whoma hmm there has to be a way. slime-update-connection-list ? slime-reset? slime-restart-inferior-lisp ? slime-redirect-inferior-output etc ? i would google further.

15:10:14 rumbler31 hmm

15:10:17 whoma try through slime-connect perhaps

15:10:38 whoma im googling but i cant find any direct solution, almost like it never really happens

15:10:59 Shinmera restart-inferior-lisp will shut down your lisp process, so definitely don't use that.

15:11:09 whoma might be some info here: http://slime-devel.common-lisp.narkive.com/qYAuQeOD/port-file-and-dedicated-slime-instance

15:35:38 whoma ** NICK whoman

15:37:42 schweers thanks again to everyone here. I’m off on vacation which I can now really enjoy knowing that I fixed this annoying bug!

15:37:56 beach Have a nice vacation!

15:38:05 schweers thank you

15:42:14 foom2 ** NICK foom