libera/#sicl - IRC Chatlog
Search
21:40:20
mfiano
beach: How do you normally subscribe to changes in the model from the view, in a sophisticated CLOS-based application? I am mainly talking about "problem 1" in section 2.1 of the "Using Stealth Mixins to Achieve Modularity" paper (the paper only addresses the "problem 2"). I have considered the observer pattern, but that loosely couples the view in the model, and such mutual dependency circularities
21:40:23
mfiano
make me upset. I am just curious what other options there are, as I've been really thinking on how to make my code more modular lately.
3:05:16
beach
mfiano: I don't have access to the paper, so you need to describe the problems in addition to enumerating them.
3:06:09
mfiano
in summary, the view layer needs to compute some information about the various objects of the model, and store this information for later use. problem 1 is the view subscribing to any modifications in the model, so that these annotations can be
3:07:06
beach
Wouldn't the view then just define an :AFTER method specialized to the stealth mixin class?
3:08:35
mfiano
I don't understand. The stealth mixin paper assumes the reader finds a solution to this problem before stealth-mixins is of use
3:09:08
beach
Oh, sorry, I haven't had my coffee yet. You want to know how this is done without stealth mixins?
3:09:40
mfiano
No, I want to know a solution to the prerequisite discussed that stealth-mixins requires
3:14:27
beach
Well, I don't know of any acceptable solution to the problem without stealth mixins, but the traditional way is the observer pattern.
3:15:14
beach
But, like I said, with stealth mixins, you can then stick an :AFTER method on the operations you want to observe, specialized to the mixin class.
3:16:29
mfiano
I'm reading AMOP, and again I'm greatly confused. It references class-direct-methods in several parts of the prose/examples of chapter 2, but the api index only lists specializer-direct-methods. I am assuming that chapter 2 is just wrong.
3:18:43
beach
The AMOP is a great book (as Alan Kay says) in terms of the message, but it is not that well written.
3:19:11
beach
Several technical books are like that, unfortunately. The garbage collection handbook is another.
3:19:30
mfiano
Well thanks. I've just been doing a lot of reading and asking questions regarding other people's architectural choices in order to refine my process a bit to be more modular.
3:21:36
mfiano
Yes. I spent the last week designing a rather complex multi-layered protocol, and I'm not 100% happy with it. I have some ideas how I would do it better now, but still thinking/reading.
3:27:14
beach
In Cluffer, the view does not subscribe to changes at all. And that's so that the model can change as a result of multiple operations without any actions on the part of the view. For example, deleting a region can be implemented as a loop over each element of the region, and it would not be a good idea to inform the view for each element.
3:29:24
beach
So the model instead tags modifications (coarsely) with a time stamp. When the view needs to be updated (say because it is visible), it invokes the modification protocol to update its stored version of the model according to modifications made after the previous update.
3:30:25
beach
Typically, every view is updated at the end of each iteration in some kind of command loop, but each command can then result in an arbitrary number of modifications to the model.
3:31:35
beach
Yeah, Paul Wilson (of GC fame) taught me this technique when I spent a year with his group in Austin.
3:34:21
mfiano
I use them in a few different ways actually. In one way, the subject sends messages to an event (priority) queue with a relative _future_ time, and each tick events are dequeued and dispatched to all subscribers until the priority queue's next element is > the absolute current time
3:36:39
mfiano
I probably explained that poorly, but subscribing to a message is a progn combination method, and is just a way i designed to queue future event hooks in a not so coupled manner
3:38:14
mfiano
Oh sure. I use that in lots of places actually, usually generational though to solve the ABA problem.
3:39:16
mfiano
I personally think of the timestamps you speak of as simply "serial numbers", so I didn't make the connection at first.
3:41:10
hayley
A problem in concurrent programs which is caused by confusing the properties of "this object wasn't modified" and "this object is the same as it was before".
3:41:11
mfiano
It's usually explained in terms of a multi-threading problem, but it is simpler than that...
3:42:48
hayley
One way to alleviate it is to use a monotonically increasing timestamp, which will change on every modification.
3:46:20
mfiano
Yes, hayley, though generational indices are used when these "timestamps" are pointers to objects, likely stored in an array. it is important to recycle integers/indices, while still detecting the generation.
3:49:04
hayley
Yesterday I remembered reading an article which covered both kinds of ABA problem, which read that reusing pointers while they are still "live" made it too easy to introduce bugs with lock-free algorithms and manual memory management.
3:52:50
hayley
mfiano: So, it is a "generational" index because the counter is only incremented when an element is removed?
3:54:36
mfiano
I am probably too tired to answer, but this crabby readme seems like maybe a decent explanation of what i do https://github.com/fitzgen/generational-arena
3:55:38
mfiano
basically each integer is a monotonically increasing number packed together with a generational counter at the time of insertion
4:08:47
mfiano
This video explains it. The author did a poor job of explaining the DS in general though. He hand waves over a very important detail. I had to bother him in an email to confirm my suspicion after spending 2 weeks of debugging
4:11:30
mfiano
This type of data-oriented optimization isn't really worth it most of the time with uniform reference semantics.
4:15:02
mfiano
This young dude seems like it's his first time ever giving a talk or learning about a data structure.
4:17:46
hayley
I still don't see what is different to maps in Self, which is decidedly not data-oriented.
4:18:03
mfiano
The sad part is the same person submitted a proposal and code to have this included into the C++ stdlib, with the same mistakes I pointed out in his talk, and with a few thousand lines of templating nonsense for a trivial thing.
4:21:11
mfiano
As I know nothing about Self, I can't answer that. But this data structure is useful so that you can have linear time iteration, and constant time insert/remove/search, like a hash table, but contiguous in memory
4:24:18
mfiano
The idea is you can keep the objects you're pointing to close together in memory when scanning the collection, so theoretically less cache misses.
4:26:36
hayley
Hm, maybe not if we are dealing with multiple objects. But objects using maps (aka "hidden classes" in JavaScript) do have the properties of acting like a contiguous "hash table".
4:30:41
mfiano
This is a specialization of an age old DS known as a "packed array", and many other names.
4:32:36
mfiano
I am out of brainpower for the day to care to think about anything other than my protocol design. Thanks for the chat everyone. Sorry to hijack the SICL channel with my ranting.