00:04:20 lispbliss joined #tunes
00:04:20 abi joined #tunes
00:04:20 ult_NeedWork joined #tunes
00:04:20 water joined #tunes
17:21:15 Brianna joined #tunes
17:49:10 water joined #tunes
17:49:41 <water> re
18:05:50 Kyle joined #tunes
18:06:38 <water> hey kyle
18:06:47 <Kyle> hi
18:12:22 water is discussing slate in #{} again
18:12:29 <eihrul> atm...
18:13:01 <eihrul> methods objects are just going to be simple little constructs containing fields for variable and field holding code to be executed
18:13:20 <eihrul> s/variable/variables
18:13:24 <water> hrm
18:13:36 <water> care to elaborate?
18:13:40 <eihrul> for now, since its just interpreted code, they don't have to be enormously complex
18:13:48 <water> sure
18:14:04 <eihrul> "foreign methods" are going to be a bit simpler
18:14:16 water was considering perhaps a self-like system for objects-with-code
18:14:28 <eihrul> just a small object wrapper over a slot that holds an integer representing the address of the method :)
18:14:37 <water> ok
18:14:55 <eihrul> which just exists as a necessity to interface with the outside execution environment :)
18:15:03 <water> right
18:15:24 <water> more abstract than a bytecode, which is great
18:16:07 <water> well, here's a scheme i've been thinking of for method objects...
18:16:11 <eihrul> well, bytecode is one possible representation of code
18:16:24 <eihrul> a method object can hold many different representation of the same code, depending on whose interested :)
18:16:30 <water> for one, of course fields would be subobjects
18:16:36 <water> sure
18:16:52 <water> but for now, we need something that works and supports the code model we already have
18:17:22 <water> i'm thinking that one of the quotation aspects would be the array that holds the method code
18:17:29 <eihrul> well, interpreted code in pidgin is going to be pretty simple
18:17:37 <water> the sequence of slotname accessors and "." handles
18:18:05 <water> well, if it's so simple, explain it please :)
18:19:00 <eihrul> just a collection of literal objects (which have some annotation that makes them be treated as literal), and then you have symbols that are not annotated as literal, where the '.' symbol of course triggers application, and any other symbol triggers lookup
18:19:31 <eihrul> as for collection itself, could be an array, a vector, a list, doesn't matter much :)
18:20:16 <water> yeah but the interpreter being simple means that it knows just one protocol for stepping through code
18:20:38 <eihrul> well, like i said, it will be easy to make your own interpreter :)
18:20:45 <water> ok
18:21:30 <water> oh, and the parent slot will just be a handle to tell the MO what other object gets lazily mixed-in, right?
18:21:51 <water> (or maybe i need to roll that myself to do it right... hm...)
18:24:43 <water> yeah i suppose i do need to roll that myself
18:24:58 <water> since it goes hand-in-hand with lazy eval and the MOP
18:25:24 <water> it looks like Slate 0.1 is going to be really slooooooowww :)
18:25:41 <eihrul> to say nothing of pidgin 0.1 :)
18:25:54 <water> (MO's in interpreted pidgin implementing slate ;)
18:26:34 <water> well as long as pidgin is KIS-worthy
18:26:34 <eihrul> well, i'd rather implement an interpreter in C++ than an optimizing Slate compiler :)
18:26:36 <water> heh
18:26:43 <eihrul> lest one falls to the Self mistake
18:26:49 <water> yeah, that would just be one more headache for HLL fans
18:27:32 <water> well, their argument (re-iterated the other day) against self-hosting was that the optimizations bit gets tricky when reflectively applied
18:28:03 <eihrul> well, sure, you have to make some distinctions for bootstrapping
18:28:13 <eihrul> but C++ is a tricky beast all its own at that scale
18:28:17 <water> but then self has mutable semantics =)
18:28:22 <eihrul> for small projects, sure it can be manageable
18:28:32 <eihrul> but at the size of Self, it gets horrid
18:28:37 <water> no kidding
18:28:50 <eihrul> especially when you don't have good tools like an object browser for actually comprehending the code
18:29:33 <Kyle> what is the Self mistake?
18:30:28 <water> kyle: the implementation of Self is totally non-portable and not well-documented
18:30:57 <eihrul> and if you ever did want to make the system self-hosting
18:31:02 <eihrul> you'd have to rewrite everything
18:31:08 <Kyle> thanks
18:31:11 [QUIT] lispbliss quit: Ping timeout for lispbliss[sage.cortland.com]
18:31:22 <eihrul> being that it is in C++
18:31:50 [NICK] ink changed nick to: kf6sta
18:32:15 <water> btw, self mlist activity has picked up recently
18:33:45 <water> to what end, who knows. anyway...
18:33:52 [NICK] trans changed nick to: trans-sho
18:34:43 <water> i think that supporting slate in pidgin only really needs the ability to draw the object/MO distinction and code in it
18:34:54 <water> at least i hope so ;)
18:37:09 <water> eek!
18:37:21 <water> people are quoting me from irc on the self mlist :)
18:37:57 <eihrul> hah
18:38:03 <eihrul> where is the self archive? :)
18:38:58 <eihrul> egroups?
18:40:43 <water> yep
18:40:47 <water> self-interest
18:40:53 <water> they quote you, too
18:41:07 <eihrul> heh
18:42:47 <water> jsut grep irc
18:42:52 <water> s/su/us/
18:49:30 eihrul ponders joining the mailing list.
18:49:45 <eihrul> discussion interesting enough to warrant subscription?
18:51:41 <water> well look at the archives about the methods as objects discussion
18:52:06 <water> and if you don't like the discussion, ask dave and jecel the questions YOU care about
18:52:47 <water> the mlist is not incredibly active, though, until recently
18:55:23 <water> holy cow
18:55:29 <water> embedded qt
18:55:57 <water> or rather that embedded qt environment thing
18:56:18 <eihrul> QT is icky :)
18:58:02 <water> why?
19:04:16 <water> hm
19:05:08 <water> pidgin's procedural style might be an obstacle
19:05:51 <water> for one, every object in slate would have to be lazy... slots created as needed, etc
19:06:51 <water> for another, mutability is something i'm trying to make a very customizable thing... that means the MO system might get needlessly complex without some special support
19:07:01 <water> hrm
19:13:20 hcf joined #tunes
19:13:52 [NICK] trans-sho changed nick to: trans
19:14:56 <water> hey hcf
19:15:15 <hcf> hi
19:59:23 <eihrul> well
19:59:32 <eihrul> it is not like pidgin is going to be a large and complex system
19:59:44 <eihrul> where mutability is present, it will be rather contained
20:00:01 <eihrul> and exceedingly simple to contain :)
20:00:04 <water> ok
20:00:27 <water> btw i don't think we ever worked out the slot creation protocol
20:00:36 <water> you know the whole handshaking theory
20:01:25 <eihrul> well, i was just going to have some simple mixin stuff for that
20:02:25 <water> hm ok
20:02:39 <water> there's probably a few good ways to do it
20:03:19 <eihrul> also some slightly more "incremental" ways to build object
20:03:50 <water> well, the reason for the handshaking protocol was so that each object had a "say" in how the link would be handled
20:04:13 <water> like linearity of the reference, mutability aspects, etc.
20:04:57 <eihrul> well, i more or less have a "protocol" for setting and getting fields from an object
20:05:12 <eihrul> which could in theory be overloading :)
20:06:07 <eihrul> s/overloading/overloaded...
20:06:42 <eihrul> however...
20:06:48 <eihrul> that does bring up an issue
20:07:08 <water> ok
20:07:09 <eihrul> that we may need a third element of the slate MOP
20:07:32 <eihrul> if you look at it in the absence of the MO
20:07:34 <water> which would be?
20:07:43 <eihrul> there are two interesting things you can do to an object
20:07:58 <eihrul> you can: 1) 'get' the value of a field 2) 'set' the value of a field 
20:08:12 <eihrul> (1) is more or less covered by 'lookup'
20:08:19 <eihrul> but (2) really doesn't have any representation at all
20:08:27 <water> ":" ?
20:08:42 <water> hm you mean something different
20:09:00 <eihrul> well...
20:09:12 <eihrul> i'm just imagining from a simplistic perspective
20:09:18 <eihrul> that an object has two methods, 'set' and 'get'
20:09:28 <eihrul> they both take a symbol that denotes a field name
20:09:35 <eihrul> and 'set' optionally takes a value
20:09:35 <water> hum
20:09:46 <eihrul> which constitutes a small little protocol in and of itself :)
20:09:51 <water> right
20:10:01 <eihrul> where:
20:10:07 <water> but it's reflective
20:10:22 <eihrul> object get field = (object meta) lookup field in object
20:10:33 <eihrul> but...
20:10:34 <water> you're performing a base-level operation on the representation of the object
20:10:37 <eihrul> object set field to value = what? :)
20:11:31 <water> not sure i follow
20:11:43 <eihrul> well, i'm just thinking from a lispian perspective
20:12:12 <eihrul> for pretty much any way to access a "location", there is also a corresponding way to "set" or replace its value (possibly returning a new object in the process or whatever)
20:12:36 <eihrul> the idea of "set"ing can be more or less independent of mutability/immutability, but is still an important concept there :)
20:12:40 <water> it seems pretty clearly a meta-level op to me
20:12:59 <eihrul> yep, but one that doesn't quite have meta-level representation in slate
20:13:04 <water> but nothing separate per se
20:13:11 <water> why not?
20:13:12 <eihrul> which is what i'm trying to emphasize here :)
20:13:17 <eihrul> ':' is not meta-level
20:13:25 <water> i know it's not easily available in the syntax, for sure
20:13:37 <water> well, we're not talking about ':'
20:14:14 <eihrul> i think a richer protocol for slate could be get + set + apply
20:14:20 <water> lol
20:14:24 <eihrul> P
20:14:33 <water> sounds exactly like a self discussion recently
20:14:43 <water> not making fun
20:15:10 <water> but set is merely subsumed by the handshaking in order to obtain new slots
20:15:37 <eihrul> well...
20:15:49 <water> which i apparently need to work out better for you and others
20:16:25 <eihrul> "set" IS a meta-level operation comparable to "lookup" and "apply" in my mind
20:16:33 <eihrul> and i do think it bears representation in the protocol :)
20:16:54 <eihrul> and would make issues like "handshaking" and such easier to deal with
20:17:15 <eihrul> because it is now factored into its own little part of the protocol
20:17:25 <water> well that was the point about the handshaking thing
20:17:38 <water> to make it part of the MOP
20:17:51 <eihrul> well, i think "set" is the way to do this :)
20:18:57 <water> well, i think you're wrong ;)
20:19:06 <eihrul> why?
20:19:07 <water> or at least only half-right
20:19:27 <eihrul> how better can you handle this handshaking?
20:19:31 <water> it depends on what you mean by set
20:19:47 <eihrul> set: object x field -> object
20:19:49 <water> "set" usually means handling a nonlinear name :)
20:20:06 <eihrul> er...
20:20:10 <water> which you demonstrated now quite well :)
20:20:12 <eihrul> set: object x field x object -> object 
20:20:33 <eihrul> where does this presuppose linearity anywhere? :)
20:20:46 <eihrul> s/linearity/linearity or non-linearity
20:21:10 <eihrul> or rather... do you mean the non-linearity of the *value* placed into the field?
20:21:10 <water> i forgot you were using type notation
20:21:33 <water> i suppose the latter
20:21:37 <eihrul> OTOH... you could just as well clone the value
20:21:44 <eihrul> in the set part of the protocol
20:21:46 <eihrul> problem solved :)
20:21:57 <eihrul> if you desire linearity
20:22:05 <eihrul> and it encapsulates this all nicely :)
20:22:37 <water> kinda
20:23:37 <water> the problem is that how this works out should be co-operative at least
20:24:01 <water> similar to multi-dispatch over single-dispatch ;)
20:24:10 <eihrul> well...
20:24:19 <eihrul> why can't this cooperation be encapsulated in "set"?
20:24:46 <water> heh
20:25:11 <water> well if by "set" you mean whatever we're talking about, sure, but then you may as well call it "tribble" :P
20:25:52 <eihrul> sure, and we may as well call "lookup" as "supercalafragilisticexpialadocious" and "apply" as "volkswagon"
20:25:56 <eihrul> but we don't
20:26:30 <water> yeah ok we're stretching every notion
20:26:50 <water> but we already have another notion of "set" that i don't want this confused with
20:27:00 <eihrul> what is this other notion?
20:27:03 <water> ':'
20:27:24 <eihrul> well, i'm making the point that ':' should be replaced with an enriched protocol :)
20:27:33 <eihrul> unless you can make the case that it should not be
20:27:42 <water> no, ':' serves another function entirely
20:28:03 <eihrul> what is its function, then?
20:28:06 <water> in fact, ':' essentially is a specific kind of wrapper for this "set"
20:28:07 [QUIT] MysticOne quit: See ya!
20:30:04 <water> except that ':' is meant to supply an emulation of self/smalltalk style state
20:31:25 <eihrul> yes, but how does this differ from an element of a protocol that can be extended to emulate various behaviors?
20:31:41 <water> hm?
20:32:22 <eihrul> or rather, why must this emulation of "self/smalltalk style state" be provided in such an object? :)
20:32:55 <water> well it's better than "x/x:" pairs, if you ask me
20:33:12 <water> after all, we already have the "^" factoring
20:33:14 <eihrul> "x/x" pairs?
20:33:20 <water> no
20:33:26 <water> "x" and "x:"
20:33:27 <eihrul> er, "x/x:" pairs?
20:33:51 <eihrul> well, "set" also avoids this
20:33:59 <water> why?
20:34:13 <eihrul> if ':' is an operator much like '.' that invokes the "set" part of the protocol
20:34:21 <eihrul> you don't need "x/x:" pairs
20:34:35 <water> whoa ":" is not primitive to the syntax
20:34:41 <eihrul> i understand this
20:34:55 <eihrul> but i'm arguing that it should be in so far as '.' is
20:34:55 <water> so what are you saying?
20:35:25 <water> well, notice that '.' *does* move around and clone slots already
20:35:52 <water> (being a stack operator, where the stack is a set of slots linearly passed around)
20:36:50 <eihrul> well, while this particular protocol extension can be simulated with the functionality present
20:37:18 <eihrul> i think the simulation is at the cost of munging up the meta-level and making it less clear
20:37:27 <water> eh?
20:37:36 <water> i think we're miscommunicating
20:37:54 <eihrul> where? :)
20:38:02 <water> what exactly do you mean by this "set" mechanism?
20:38:48 <eihrul> simply, representation in the slate MOP for the idea of placing some object into a slot (whether this means mutation, cloning, or whatever)
20:39:04 <eihrul> complementary to the idea of retrieving a value from a slot
20:39:47 <water> yeah but in the slate model you have to retrieve the value in order to put it somewhere else
20:40:10 <eihrul> why does that pose a problem?
20:40:31 <water> it doesn't... but there's a certain more-literal-than-you-think aspect
20:41:02 <water> cloning something implicitly creates a slot somewhere to access it
20:41:24 <water> (aside from referring to the expression that generated the value)
20:42:00 <water> the whole idea behind the handshaking idea was to be the underlying mechanism for "adding" and "removing" slots
20:42:29 <eihrul> well, i don't see the protocol extension as particularly any different than existing mechanisms we had, only simplified and factored
20:42:45 <eihrul> so if there is some problem with this extension, then i believe it will manifest wherever you try to emulate it :)
20:42:50 <water> i've even considered that GC annotations would be done by that quote-shifting mechanism
20:43:10 <water> which protocol extension? yours or mine?
20:43:26 <eihrul> well, i thought we were discussing mine, i didn't know you had one :)
20:43:36 <water> um the handshaking bit?
20:43:45 <eihrul> okay... wait
20:43:49 <eihrul> clarification:
20:44:07 <eihrul> you're also proposing an extension to the slate MOP to handle a similar problem in a different way? :)
20:44:31 <water> yeah that's what i've been saying, or at least i've thought so
20:44:53 <eihrul> i'm dense, so could be that or me
20:45:14 <water> it doesn't matter now
20:47:22 <eihrul> well, in that case
20:47:44 <eihrul> i'm not necessarily clear where your handshaking idea exactly differs or why it is more expressive than mine
20:49:01 <water> yeah i need to elaborate
20:49:32 <water> hm most of the terms i know to express things, though, involve oo patterns or refactoring terms
20:51:05 <water> basically it abstracts from the implementation of the lookup table mechanism
20:51:43 <water> so you have a common protocol that allows each object to say how it wants its slots to be treated
20:51:52 <water> hm that doesn't explain right
20:52:01 hcf joined #tunes
20:52:43 <eihrul> would agree there
20:53:58 <water> basically it makes changes to the MO transparent to the one asking for the slot
20:54:30 <eihrul> clarify, por favor?
20:54:50 <eihrul> "changes to the MO?"
20:54:55 <water> yes
20:55:10 <eihrul> => ?
20:56:02 <water> for example, let's say you want an object to have a proxy that handles certain slot accesses specially if a remote object asks for a copy of that original
20:56:42 <water> or you want to enforce shared state when every client thinks that it is the only one fooling around with it
20:57:21 [QUIT] adu quit: 
20:58:11 <water> for example, i want only the "4" slot in "integers" to actually be the integer
20:58:29 <water> if someone else wants that integer, they don't get the original to fool with
20:58:50 <water> but you don't want the requester to have to know what it can and can't do
20:59:10 [QUIT] ult quit: Ping timeout for ult[149.149.201.30]
20:59:21 ult joined #tunes
20:59:52 <eihrul> where does this involve "changes to the MO"?
21:00:31 <water> well, you're run-of-the-mill copy is a blank object with a parent slot to its original, right?
21:00:44 <eihrul> ywa
21:00:47 <eihrul> s/ywa/yes
21:01:09 <water> if all of those had the same semantics, then you would be restricted in how they handle requests
21:01:53 <water> and for example, you couldn't say "forward this state update to the parent and not that one"
21:02:26 <eihrul> well, wouldn't that just involve giving it a new meta object?
21:03:20 <water> sure, but who does this?
21:03:27 <water> the client?
21:03:31 <water> bad idea
21:03:50 <water> so you put it into part of the protocol of the original object
21:04:05 <water> it's a reflective aspect of it, so in slate it goes into the MO
21:04:38 <eihrul> well, so are you advocating here making "cloning" itself part of MOP?
21:05:22 <water> yes, i guess i am
21:05:30 <eihrul> well...
21:05:41 <eihrul> if you weren't
21:05:45 <eihrul> i think i might :)
21:05:51 <water> ok
21:06:15 <eihrul> because, if you switch the meta-object, but otherwise leave the actual representation (hash table or whatever) of the object unchanged
21:06:24 <water> of course this is the kernel of the "clone" slot that a user would invoke
21:06:32 <eihrul> the representation may no longer be consistent with the new meta-object
21:06:50 <water> well you only have to mute part of the MO
21:07:15 <water> MO has to have components that can be incrementally over-ridden
21:07:32 <eihrul> well, i'm saying if you wanted to change the MO completely :)
21:09:04 <water> i'm saying you wouldn't
21:09:12 <eihrul> why wouldn't you?
21:09:42 <water> well for one, you probably couldn't
21:10:00 <water> (given the MMO's say in a relatively secure slate system)
21:10:21 <eihrul> well... the "couldn't" bothers me
21:10:34 <eihrul> it is hard to even express the idea of changing the MO completely without including this in the protocol :)
21:10:36 <water> but even if you could, you'd wind up with the inconsistencies you just mentioned
21:10:56 <eihrul> well, i could imagine cloning being performed in more or less this manner:
21:11:00 <water> i'm saying the MMO would not let you do it
21:11:14 <water> (the MMO i would implement)
21:11:18 <eihrul> iterating over the list of slots provided by the object, getting the values from the one object, and setting them in the other
21:11:31 <eihrul> "M"-MMO?
21:11:37 <eihrul> er... "M"-MO?
21:11:38 <water> just like how we used to talk about Top being permanently immutable ;)
21:11:49 <water> heh
21:12:01 <water> the MO of the MO
21:12:06 <eihrul> well, i'm not changing the original object
21:12:17 <eihrul> i'm just transferring its representation to another meta-object
21:12:36 <water> well suppose the representation is a slot of the MO
21:12:57 <water> which attempting to mute gets thrown out
21:13:13 <water> but the rest of the MO updates make it through
21:13:16 <water> voila
21:13:27 <water> you've changed part but not all of the MO
21:13:37 <water> without the client having to know it
21:13:46 <water> or manage it itself
21:14:08 eihrul got lost about "which attempting to mute gets thrown out."
21:14:16 <water> heh
21:14:27 <eihrul> i still don't see where mutation comes into the picture
21:14:40 <water> ok s/(that)/"and attempts to mute that one slot get thrown out"
21:14:45 <water> i.e. ignored
21:15:13 <eihrul> sure, but why would you try to mutate it? :)
21:15:23 <water> instead of throwing a damned exception or whatever, have it generate a context which the system refuses to compute
21:15:35 <water> you wouldn't, most likely
21:15:50 <water> the one-MO-per-object idea serves a purpose here
21:16:01 <eihrul> okay, but, i'm also lost as to how this actually relates to the idea of cloning :)
21:16:16 <water> you have shared MO parts which get thrown around and have no instance-specific data
21:16:53 <water> and then you have actual MOs which manage actual objects
21:17:39 <water> part of the MO library would be parts which are ready-made or readily-adapted (programmed) to the specific object or namespace
21:17:58 <water> cloning is meta-regressive
21:18:13 eihrul sighs.
21:18:36 <water> well, something gets cloned IFF the representation reflects it
21:19:12 <water> what did you expect?
21:19:30 <eihrul> well... i was more or less thinking: something can always invoke the cloning protocol (which infers that something can more or less always be cloned)
21:19:42 <eihrul> except you just have to have a way to transfer one representation to another
21:19:51 <water> the whole damned idea of this is to make the system more modular, you grok?
21:21:16 <eihrul> somewhere about half a page up
21:21:16 <water> "the cloning protocol"?
21:21:16 <eihrul> the actual point of this discussion got lost
21:21:16 <water> yeah well i told you to lead because my mind is doing somersaults
21:21:17 <eihrul> originally...
21:21:41 <eihrul> i start about a page ago expressing the idea that creating a new object that more or less is consistent with a new meta-object from an old object and its old meta-object
21:22:06 <eihrul> then...
21:22:18 <eihrul> you brought up the idea that this involving mutating the old MO in some fashion
21:22:26 <eihrul> for which reason i can still not fathom *why*
21:22:34 <water> heh
21:22:54 <water> let's just say that self's clones are really dumb
21:22:56 <eihrul> cloning in no way involves that, in my conception of the concept
21:23:29 <water> then your conception sucks
21:23:50 <eihrul> so what is a "better" conception? :P
21:24:08 <water> well, self's conception is one-size-fits-all
21:24:11 [QUIT] hcf quit: Leaving
21:24:26 <water> so is lisp's and smalltalk's and such
21:25:11 <water> with self, every damned thing has to use a physical, direct manipulation metaphor or it doesn't fit at all
21:25:19 <eihrul> well, there's no reason why cloning couldn't involve any sort of effect whatsoever
21:25:38 <water> yes but *transparent to the client*??
21:26:31 <eihrul> are we talking about implicit cloning or explicit cloning?
21:26:38 <water> if you have to comment your source with "if you clone me, please remember to forward your xCoordinate field-updates to me and not your clone", then it's a stupid implementation
21:26:44 <water> both
21:26:55 <water> mostly implicit, though
21:27:14 <water> since implicit involves the least client-side knowledge of all: 0 :)
21:27:30 <eihrul> well, rmm, if an object or meta-object can define what cloning means for an object, why is this so terribly problematic?
21:27:56 <water> do you mean the "clone" method, or the cloning mechanism?
21:28:04 <eihrul> both
21:28:47 <water> it's problematic because if you don't set the MO of the clone properly, then its dynamic behavior will not be as you planned
21:29:06 <water> you can't just set the clone's state and hope for the best
21:29:13 <eihrul> what prevents you from giving it the correct MO?
21:29:24 <water> heh
21:29:31 <water> why are you arguing my side now?
21:29:44 <eihrul> well, i'm not arguing your side:
21:29:46 <water> and who do you mean by "you"?
21:30:05 <water> client or server?
21:30:10 <eihrul> my perception of "your side" is that you see for some reason that existing mechanisms in slate do not account for this "cloning problem"
21:30:14 <water> s/server/slave/
21:30:25 <eihrul> and i'm just trying to assess what this problem is and why existing mechanisms make it a problem :P
21:30:35 <water> eh?
21:30:53 <water> slate can handle it in theory, i just want to make sure i'm elaborating it correctly for you
21:31:29 <water> especially since it has to get implemented, and pidgin AS SURE AS HELL won't do it right
21:31:30 <eihrul> okay, so this is exposition, and not argument? :)
21:31:41 <water> yes
21:32:07 <water> although this is the rationale for the handshaking biz
21:32:16 <water> which *was* an argument, IIRC :)
21:33:35 <eihrul> well, if the handshaking biz is a solution, then i'd assume a rationale for a solution would be a problem :)
21:34:10 <water> huh?
21:34:24 <eihrul> "slate can handle it in theory"
21:34:31 <water> this is not post facto rationale, asshole
21:35:33 <eihrul> rmm, if you wish to take the discussion that way, i'm going to call it a night
21:35:58 <water> well you're not picking on me at the right time
21:36:06 <water> i'm not in the mood for jokes at all
21:36:33 <eihrul> that wasn't a joke perse
21:36:45 <water> in that case, it was rude
21:36:48 <eihrul> but perhaps we should none-the-less wait till tomorrow
21:36:53 <water> you know me better than that
21:37:19 <eihrul> rmm, i think you misinterpreted the statement
21:37:28 <water> well explain it
21:37:37 <water> instead of cutting me off
21:37:55 <eihrul> well, going into this whole discussion
21:38:25 <eihrul> i was under the impression that "handshaking" was something that requires extension of slate
21:38:46 <water> everything is an extension in slate
21:38:54 <water> so what do you mean?
21:39:20 <eihrul> to the MOP itself, or atleast you seemed to more or less state that explicitly earlier (mistakenly or purposely)
21:39:49 <water> nah, more like a refinement of the current ideas and plans for code
22:02:21 [QUIT] kc5tja quit: THX QSO ES 73 DE KC5TJA/6 CL ES QRT (xchat)
22:04:22 [QUIT] eihrul quit: Leaving
22:57:49 [QUIT] diablovision quit: 
22:57:53 [QUIT] lar1 quit: 
02:47:26 _101 joined #tunes