01:40:35 lar1 left #tunes
01:59:18 nate37 joined #tunes
02:18:00 smkl joined #tunes
05:09:35 Kyle_L joined #tunes
05:34:00 eihrul joined #tunes
05:37:00 [QUIT] eihrul quit: Leaving
06:02:29 [QUIT] Kyle_L quit: Leaving
06:10:53 [QUIT] JALH quit: Ping timeout for JALH[user38-186.jakinternet.co.uk]
06:44:12 hcf joined #tunes
07:10:27 [QUIT] nate37 quit: irc.linux.com adams.openprojects.net
07:11:47 nate37 joined #tunes
07:12:49 yuriz joined #tunes
07:14:53 <yuriz> hello guys! Why this channel is so silent? ;)
07:32:13 yuriz left #tunes
08:17:08 <waffle> is fare on vacation?  i haven't seen him around for a while. 
08:37:45 [QUIT] karltk quit: milton.openprojects.net irc.linux.com
08:37:45 [QUIT] smkl quit: milton.openprojects.net irc.linux.com
08:37:45 [QUIT] nate37 quit: milton.openprojects.net irc.linux.com
08:37:45 [QUIT] JALH quit: milton.openprojects.net irc.linux.com
08:38:25 karltk joined #tunes
08:38:25 smkl joined #tunes
08:38:25 nate37 joined #tunes
09:38:09 eihrul joined #tunes
09:46:07 [QUIT] eihrul quit: Leaving
09:53:18 [QUIT] hcf quit: Ping timeout for hcf[207-172-225-32.s32.tnt1.pld.me.dialup.rcn.com]
10:23:49 [NICK] ult[zen] changed nick to: ult
10:29:52 hcf joined #tunes
11:01:42 coreyr joined #tunes
11:09:44 [NICK] ult changed nick to: ult[learning]
11:11:30 nate37 left #tunes
11:26:01 coreyr joined #tunes
12:05:47 eihrul joined #tunes
12:33:58 Fare joined #tunes
12:36:43 <hcf> abi: interlisp is at http://server1.florida-software.com/algorithms/downlispf4.shtml
14:26:41 ult_ joined #tunes
14:44:39 eihrul joined #tunes
15:43:14 witten joined #tunes
15:45:09 <Fare> ain't witten the name of a Fields-medal laureate?
15:46:12 <witten> witten is the name of a lot of things/people
15:46:16 <witten> usually, I'm not any of them
15:47:24 <eihrul> 'lo
15:48:08 <witten> hello
15:48:20 <witten> eihrul: tell me, what's the point of meta objects?
15:49:06 <eihrul> well, introspection
15:49:11 <witten> yeah
15:49:17 <eihrul> exactly how a message is sent or a function is applied or whatever
15:49:32 <witten> it just seems like meta objects are a particularly kludgey means of introspection
15:49:36 <eihrul> is usually a primitive and hard-wired process that you can't extend or interposition yourself with
15:49:46 <eihrul> uh, huh
15:49:50 <eihrul> how are they?
15:49:57 <witten> the whole meta regress thing
15:50:16 <eihrul> the regression is bounded
15:50:25 <witten> I know, it just doesn't feel right :)
15:50:33 <eihrul> why not?
15:50:46 <eihrul> the regression means it can be extended indefinitely...
15:51:00 <eihrul> there are regressions in any OO language you can look at
15:51:19 <witten> the meta object describes the object's layout, the meta meta object describes the meta object's layout, and the meta meta object describes its own layout, right?
15:51:19 <eihrul> usually of the class variety
15:51:19 <eihrul> reason you don't see them is because noone chose to address them :)
15:51:48 <eihrul> whatcha mean "layout"?
15:51:53 <eihrul> as in "memory layout"?
15:51:55 <witten> members
15:51:57 <Fare> meta-structure is not always mapped to base-level objects
15:52:02 <eihrul> no, not in slate
15:52:06 <witten> member layout
15:52:20 <eihrul> in slate, that isn't even much addressed
15:52:23 <witten> Fare: meaning what?
15:52:29 <witten> eihrul: what isn't?
15:52:30 <eihrul> there are hidden meta-objects in the current implementation called maps
15:52:41 <Fare> for instance, meta-information like "the total stack size needed to run a program" is not associated to individual base objects
15:52:52 <eihrul> that describe the mapping of fields to memory for the primitive message protocol
15:53:08 <eihrul> the meta-objects in slate otherwise just handle the process of message-passing
15:53:17 <witten> eihrul: so how is the meta object a true object?
15:53:26 <eihrul> it is a true object...
15:53:44 <eihrul> with 'lookup' and 'apply' methods defined on it that are used to send methods to objects within their "meta space" :)
15:53:49 <witten> so if you ask for the meta object's members, it must either consult its *own* meta object, or be able to describe itself?
15:53:59 <eihrul> yes
15:54:00 <Fare> or maybe the base-level objects constitute an equation that has a high-level solution in which the original objects dissolve into meaninglessness
15:54:04 <witten> meta space. that's one term I didn't get..
15:54:05 <eihrul> a meta-object has a meta-object as well
15:54:15 <eihrul> this regression is terminated by the object "Top", which is its own meta-object
15:54:28 <Fare> (e.g. change of point of view much like the fourier transform)
15:54:29 <witten> eihrul: and how does Top describe itself? and is it a true object?
15:54:40 <eihrul> witten: it is its own meta-object, that's how
15:54:42 <witten> Fare: you lost me :)
15:54:46 <eihrul> witten: and yes, it is a true object
15:55:04 <eihrul> witten: implementationally, this means checking if the object's meta-object is Top, and if it is, using the understood protocol that Top provides
15:55:17 <witten> eihrul: okay
15:55:25 <eihrul> otherwise, it would still regress :)
15:55:25 <Fare> in the fourier transform of a function defined by its values at given points, nothing corresponds to the value of the original function at a given point.
15:55:47 <witten> eihrul: and when do you decide when a meta object should be Top or not?
15:55:50 <witten> when/how
15:56:21 <eihrul> witten: eh, by default, object's have Top as their meta-object... you can just change the meta-object, though
15:56:43 <eihrul> s/object's/objects
15:57:01 <Fare> So that if your program computes some stuff from a JPEG files, that happens may be optimized from uncrompssed representation, we may as well skipt decoding the FFT.
15:57:14 <witten> eihrul: and how can an object have members like lookup and apply if they're defined in its meta object? because presumably you need to consult the meta object in order to execute members..
15:58:11 <eihrul> eh? rephrase that, coherently :)
15:58:32 <witten> my_object.lookup(something)
15:58:38 <witten> lookup is a member of my_object
15:58:54 <witten> looked needs to be looked up in the meta object's list of object's members
15:59:07 <witten> how can that be done?
15:59:13 <eihrul> rmm... lookup is not looked up in the object
15:59:18 <eihrul> lookup is a member of the meta-object :)
15:59:21 <eihrul> for instance:
15:59:31 <eihrul> myObject . message (parameter)
15:59:44 <eihrul> we first look for myObject . metaObject (this slot is primitively handled)
16:00:07 <eihrul> after that, we then do metaObject . lookup (myObject, "message")
16:00:22 <eihrul> k?
16:00:34 <witten> okay, and how does metaObject . lookup() work?
16:00:48 <eihrul> well, the primitive version? :)
16:00:58 <eihrul> or in general?
16:01:06 <witten> in general.. is it a primitive?
16:01:22 <eihrul> well, it is not primitive if someone defines their own meta-object :)
16:02:11 <witten> hmm
16:02:19 <eihrul> as for the primitive version
16:02:24 <eihrul> its pretty much how Self does lookups
16:02:30 <eihrul> each object has an implicit "map"
16:02:39 <eihrul> that maps message selectors to slots in the object
16:02:52 <witten> so the meta object doesn't store the object's map/list of members?
16:02:54 <eihrul> this is consulted to find the correct slot, and the value of that slot in the object is retrieved
16:03:01 <eihrul> no
16:03:07 <eihrul> it does not
16:03:09 <eihrul> well, yes and no
16:03:09 [NICK] ult changed nick to: ult[food]
16:03:12 <witten> then what good is a meta object?
16:03:14 <eihrul> there are many types of meta-objects :)
16:03:27 <eihrul> the meta objects we're concerned with in slate are to define the lookup protocol
16:03:36 <eihrul> that's what they are good for
16:03:57 <witten> that's it?
16:04:12 <eihrul> that's it
16:04:32 <eihrul> but, you seem to have a narrow view of "to define the lookup protocol"
16:05:03 <eihrul> there's lots of stuff you can do with that :)
16:05:06 <witten> like?
16:05:34 <eihrul> like synchronization, distribution, access control, etc.
16:05:48 <witten> and what do you get from meta objects that you can't get from vanilla inheritance or aggregation?
16:05:48 <eihrul> pretty much anything you could do with "aspect oriented programming" and more :)
16:05:54 <witten> oh okay
16:06:01 <eihrul> they fill the same niche
16:06:22 <witten> it just seems like a roundabout way to do it
16:06:36 <witten> the introspection claim, I might buy
16:06:39 <eihrul> "roundabout"?
16:06:52 <witten> but your meta objects don't even have a list of members to introspect
16:06:53 <eihrul> it is the most direct way to do it!
16:07:04 <eihrul> rather than having to modify the compiler to make it do stuff you want
16:07:13 <eihrul> eh?
16:07:27 <witten> why would you have to modify the compiler? just override "lookup" in an object or some such
16:07:44 <eihrul> rmm, that was my point...
16:07:47 <witten> can you explain how meta objects support introspection? that was the whole purpose behind them, I originally thought
16:07:51 <eihrul> without meta-objects, you have to modify the compiler :)
16:08:06 <witten> but you can override lookup without meta objects
16:08:14 <eihrul> how so?
16:08:50 <witten> instead of putting lookup in the meta object, put it in the object itself
16:09:16 <eihrul> and why is that better?
16:09:20 <witten> if there's a member called "lookup", that's used instead of the primitive lookup
16:09:45 <witten> because you don't have to mess with funky meta objects, and you can get all their other purported benefits via aggregation,whatever
16:09:56 <eihrul> how are meta-objects funky?
16:10:02 <eihrul> they're just a factoring of that
16:10:04 <eihrul> nothing more
16:10:22 <witten> they seem to be breaking away from the goal of universalization
16:10:33 <eihrul> eh?
16:10:46 <witten> er, unification
16:10:55 hcf joined #tunes
16:11:29 <eihrul> well, i now have to go take a mandatory CMU course on how to make spreadsheets in a program i don't use for an operating system i don't use
16:11:31 <witten> objects are functions are objects, etc etc. and then you have these weird like meta-objects which don't quite fit in
16:11:36 <eihrul> sorry :/
16:11:39 <witten> that sounds a lot of fun
16:12:22 <eihrul> how don't meta-objects fit in? they're objects :)
16:13:11 <witten> you just haven't sold me on their utility, when it seems like you can do the same thing they do without introducing another concept
16:13:29 <witten> maybe introspection would be a reason, but it doesn't sound like they're really used for that
16:13:41 <eihrul> how is placing the protocol in the objects not introducing a new concept?
16:13:49 <eihrul> because either way, you're introducing the same concept
16:14:23 <witten> hm, good point
16:14:35 <eihrul> as i said, meta-objects just factor this
16:14:52 <eihrul> in the same way classes can factor behavior of a class of objects
16:15:05 <witten> however, you can factor this with already-available means like inheritance or aggregation
16:15:35 <eihrul> i don't see why this is such a big issue, man
16:15:46 <witten> it's not
16:16:00 <eihrul> now of course this does bring up the other issue :)
16:16:02 <witten> I just thought slate was big on unification
16:16:08 <witten> which other issue?
16:16:11 <eihrul> how to modify the system of meta-objects itself
16:16:26 <eihrul> ;)
16:16:27 <witten> yeah, that's sort of tough
16:16:43 <eihrul> you'd need to introduce another layering of meta-objects :)
16:17:00 <witten> that's part of my complaint :)
16:17:01 [NICK] kc-meeting changed nick to: kc5tja
16:17:11 <witten> meta objects belong *primitively* to objects
16:17:11 <eihrul> or just do so in the old way (modify the compiler/language system)
16:17:27 <eihrul> # water: you listening? :)
16:17:40 <witten> there's no way for joe slate programmer to get at an object and say, I want you to switch to *this* meta object
16:18:08 <eihrul> eh, a programmer can switch which meta-object he wants to use for an object, as easy as any other slot
16:18:26 <witten> oh okay
16:18:44 <eihrul> the problem is if you want objects to be fully self-representing including meta-behavior, you'd need another system of meta-objects to manage how the MOP works, too :)
16:18:47 <eihrul> but anyway
16:18:55 <witten> so it primitively belongs to an object, but you can still get at it by traditional means?
16:18:57 <eihrul> i gotta go take this stupid M$ excel course
16:19:04 <witten> have fun
16:19:13 <eihrul> yes, the meta-object slot behaves like a normal slot :)
16:19:21 <witten> ok
16:19:27 <eihrul> it justs just you can't modify the lookup protocol there
16:19:34 <witten> aha
16:19:34 <eihrul> because you'd have a nasty regression :)
16:19:38 <witten> yup
16:19:50 <eihrul> would need the meta-object to lookup itself, and you'd never be able to find it
16:19:53 <eihrul> okay, bbiab
16:19:53 [QUIT] eihrul quit: Leaving
17:09:59 eihrul joined #tunes
17:19:33 <eihrul> witten: any more questions about meta-objects??
17:19:45 [QUIT] eihrul quit: Leaving
17:29:44 eihrul joined #tunes
17:29:44 <eihrul> sigh
17:31:07 <witten> what?
17:31:17 <eihrul> that class was lame...
17:31:27 <eihrul> the only consolation is i can telnet into bespin from there
17:31:47 <eihrul> (save when the teacher is walking near my workstation)
17:31:49 <witten> you can't laugh at it and have fun the same way you can at a bad movie?
17:32:09 <eihrul> i tend to walk out of bad movies
17:32:15 <witten> oh heh
17:34:25 <eihrul> this class is mandatory though :/
17:34:28 <eihrul> bad movies aren't!
17:34:33 <witten> true
17:34:43 <witten> I don't see why that'd be mandatory at cmu
17:34:55 <eihrul> you don't go to cmu, do you?
17:35:10 <eihrul> there's a lot of cluelessness, even in the CS department :)
17:35:43 <witten> no, I don't
17:35:59 <eihrul> almost makes me happy i'm in the math department...
17:38:37 <witten> I was in the math department here for a while
17:38:46 <witten> til I remembered that I didn't like math
17:39:53 <witten> so, about that introspection..
17:40:02 <witten> how will ya do it?
17:41:14 <eihrul> eh, what about it? :)
17:41:28 <eihrul> meta-objects :P
17:41:37 <witten> meta objects, or however else you'll do it
17:41:59 <witten> how will you implement/handle.. object.show_me_a_list_of_your_members_please()
17:42:09 <eihrul> meta-objects :)
17:42:29 <eihrul> although
17:42:31 <witten> even though the list of members is stored within the object?
17:42:35 <eihrul> we did have some discussion on mirrors for that purpose
17:42:43 <witten> mirrors?
17:42:45 <eihrul> but i think in the end we decided to just use meta-objects to do that :)
17:42:48 <eihrul> mirrors ala Self
17:42:56 <witten> how do self mirrors work?
17:43:15 <eihrul> they just return an object that makes visible certain underlying details of the object
17:43:22 <eihrul> which meta-objects can do, in and of themselves
17:43:50 <witten> why meta objects and not the object itself?
17:44:02 <eihrul> again, because its a better factoring :)
17:44:13 <eihrul> it would kinda clutter up the object to have all that stuff in the object itself
17:45:54 <witten> fuck, I just hosed this box
17:46:01 <eihrul> oh well :)
17:46:07 <witten> waaah
17:46:08 <eihrul> could be worse
17:46:32 <witten> no it couldn't.. I haven't done a cvs commit all day
17:47:39 <eihrul> you could be taking mandatory spreadsheet courses, so hush :P
17:47:47 <witten> hah
17:48:50 <witten> ok, fixed it
17:48:52 <witten> phew
17:49:29 <witten> so the general purpose of an object is to contain members, and the general purpose of a meta object is to access those members?
17:51:11 <eihrul> yes
17:51:33 <eihrul> (not to mention defining how to apply the stuff looked up)
17:52:26 <witten> "apply", as in invoke/get?
17:57:33 <eihrul> yeah
17:57:46 <eihrul> as in after you look up the method/function, you need to apply it to make it do something :)
17:59:15 <witten> right
18:04:35 <witten> excuse my obtuseness today, but how do you call a primitive member function (such as "lookup") from within the slate environment?
18:05:30 <eihrul> whatcha mean?
18:06:26 <witten> well lookup has to be primitive because.. well, it handles lookups.. if it weren't primitive, you'd have to lookup lookup
18:06:46 <witten> so how can you, say, call "object . lookup()" explicitly?
18:06:50 <witten> if you wanted to do that
18:07:28 <witten> I'm having a real problem seeing exactly where the rubber hits the road
18:07:43 <eihrul> not an issue...
18:07:47 <eihrul> example:
18:07:51 <eihrul> given myObject
18:07:57 <eihrul> where myObject . metaObject = Top
18:08:08 <witten> ook
18:08:14 <eihrul> and we want to do: myObject . message
18:08:20 <eihrul> evaluation might go like so:
18:08:38 <eihrul> first retrieve myObject . metaObject using the primitive lookup method
18:08:55 <eihrul> next, attemp to lookup 'lookup' in metaObject
18:09:11 <witten> (using primitive metaobject lookup method)
18:09:23 <eihrul> now, first examine the metaObject's metaObject
18:09:39 <eihrul> if it is Top, then use primitive lookup method to get the lookup method :)
18:09:49 <eihrul> then... finally apply this to lookup "message" in myObject
18:09:59 <eihrul> now... kinda messed up in this example
18:09:59 <witten> okay
18:10:08 <eihrul> because you actually wouldn't need to lookup lookup
18:10:12 <eihrul> if the metaObject is Top
18:10:18 <witten> okay
18:10:23 <eihrul> if it were some other metaObject whose metaObject was Top though, you would need to :)
18:12:21 <witten> I really don't know, but this doesn't sit well with me. perhaps I need to roll it around in my head some more
18:12:39 <eihrul> why not?
18:12:48 <eihrul> what don't you like?
18:13:16 <witten> I don't know
18:13:54 <witten> I don't think I'll like any solution, because no matter how you slice the cake, you'll have to make special cases for primitives that actually do the work
18:15:12 <witten> and primitives are so.. primitive
18:15:34 <eihrul> well, without any primitives, then how can you make anything at all?
18:15:40 <eihrul> you need some grounding... somewhere
18:15:44 <witten> I know
18:15:51 <witten> I just wish the grounding felt nicer
18:16:14 <eihrul> the issue is extending the primitives to suit your needs and making them suitably extensible :)
18:16:26 <witten> heh yeah
18:16:42 <eihrul> which is where tunes comes in :P
18:16:50 <witten> I suppose it feels wrong to send messages to objects that aren't "true" messages
18:17:51 <eihrul> what do you mean "true messages"?
18:17:55 <eihrul> what is a "true message"?
18:18:15 <witten> a honest-to-goodness object
18:18:18 <witten> brb
18:18:24 <eihrul> do you want objects to attach a stamp to an envelope, stick a letter with all their requests in them, and send them via USPS?
18:18:32 <witten> hahah
18:18:39 <eihrul> dude, these are honest-to-goodness objects :P
18:18:55 <witten> back
18:19:11 <witten> but are the messages honest-to-goodness objects?
18:19:21 <witten> even calling lookup()?
18:23:07 <witten> it seems like you need some mechanism to send primitive messages
18:24:36 <eihrul> eh
18:24:53 <eihrul> the message passing conventions are in a way primitively defined
18:25:03 <eihrul> which is necessary or else you can't have the MOP in the first place
18:25:11 <eihrul> MOPs don't exist in isolation
18:25:19 <eihrul> they are meant to augment a framework :)
18:25:40 <eihrul> if you have no primitive way to handle messages, you're fucked
18:26:22 <witten> MOP?
18:26:45 <witten> so are all messages primitive?
18:29:44 <witten> are messages not objects?
18:29:51 [NICK] coreyr{dikt2} changed nick to: cor{study}
18:30:49 <eihrul> messages are objects
18:31:01 <eihrul> the meta-object protocol
18:32:20 <witten> so messages are objects, but they are passed primitively..
18:32:32 <eihrul> unfortunately, yeah
18:32:35 <eihrul> that's how that works :)
18:33:52 <eihrul> the implementation just has to be readily available and open though
18:33:55 <eihrul> as with Squeak
18:34:00 <eihrul> so that can be worked around :)
18:34:15 <witten> how can one add members to an object interactively?
18:34:30 <eihrul> messages? :)
18:34:37 <witten> nah, members
18:34:47 <eihrul> just send an addSlot message or whatever :)
18:35:14 <witten> and addSlot is a primitively-implemented function that modifies the list of members stored in the object?
18:35:38 <eihrul> in a manner of speaking, yes
18:35:52 <witten> how else would you describe it?
18:36:17 <eihrul> well, 1) its a hash table, not a list
18:36:33 <witten> okay
18:36:39 <eihrul> 2) not quite sure at this point, but may go for a more non-destructive approach (i.e. adding a slot creates a new object)
18:37:02 <witten> okay
18:37:28 <witten> wouldn't it be nicer if the members of the object could be represented as a true-object slate hash/dictionary?
18:37:39 <witten> so you could, say, object.get_members()
18:38:03 <eihrul> well
18:38:23 <eihrul> you will be able to get a collection of the members and fields of the object
18:38:25 <eihrul> no big deal
18:38:34 <eihrul> that's actually what Self uses mirrors for :)
18:38:38 <witten> aha
18:38:41 <witten> I should read up on that
18:39:46 <witten> oh, and isn't the distribution/concurrency/whatever features more a result of apply() than it is of lookup()?
18:40:50 <eihrul> sure...
18:40:56 <eihrul> but slate allows you to customize both :)
18:41:07 <eihrul> whereas a language without a MOP allows you to customize NEITHER :P
18:41:23 <witten> so what use is customizing the lookup?
18:41:53 <eihrul> well, lots :)
18:42:09 <witten> examples?
18:42:11 <eihrul> debugging, access control, adding new lookup protocols (multiple inheritance, consultation, et.), distribution
18:42:14 <eihrul> as i said :)
18:42:31 <witten> in terms of modularity, isn't apply() better handled by the object being applied rather than the object that contains the object being applied?
18:42:54 <eihrul> well, its still debatable which object actually handles apply
18:43:00 <eihrul> but i'm leaning towards the object itself :)
18:43:12 <witten> yeah, I went that direction recently
18:43:16 <witten> works pretty nice
18:43:49 <witten> debugging I can buy..
18:44:21 <eihrul> build a feature, and users will come :)
18:44:41 <witten> hah, or sneer :P
18:44:53 <eihrul> now yes, i don't believe that this one feature alone is anywhere near making a tunes
18:45:03 <eihrul> nor does it in any way constitute tunes
18:45:07 <eihrul> just one little piece :)
18:45:27 <witten> what feature, the programmable lookup?
18:45:28 <eihrul> lots of other stuff in the implementation itself (which somehow water manages to gloss over, no offense >:]) is also important :)
18:45:41 <eihrul> witten: the MOP (which constitutes lookup + apply) :P
18:45:48 <witten> oh okay
18:46:20 <witten> try not to come with with new terms and acronyms.. it tends to turn off people with more closed minds
18:46:25 <witten> s/come/come up/
18:46:31 <witten> s/with//
18:46:48 <witten> wherever possible
18:48:05 <eihrul> well, MOP isn't invented
18:48:11 <eihrul> )
18:48:16 <eihrul> it predates us
18:48:46 <witten> well it sounds obscure and academic to me :)
18:48:54 <witten> I don't have a problem with that, but many do
18:49:46 <eihrul> sure, it is obscure and academic
18:50:09 <eihrul> could be worse though
18:50:20 <witten> of course, you could be those zigzag/xandu people
18:50:23 <eihrul> if you want to see obscure and academic, subscribe to the haskell mailing list
18:50:28 <witten> heh
18:50:44 <witten> or the tunes mailing list :)
18:50:44 <eihrul> lots of people in a pissing contest to see who can sound the most intellectual
18:50:53 <eihrul> tunes mailing list is much, much better
18:51:05 <eihrul> mostly because it is more casual, in general :)
18:51:12 <witten> that's good
18:53:52 <eihrul> (no offense to haskell or anything) >:)
18:56:35 <witten> now you've got me wondering whether I need/want user-definable lookups
18:59:59 <eihrul> good!
19:00:35 <witten> bastard :)
19:04:46 <eihrul> i try
20:31:51 Brianna joined #tunes
22:26:54 abi joined #tunes
22:26:54 ult[sleep] joined #tunes
22:26:54 Fare joined #tunes
22:26:54 smkl joined #tunes
22:39:59 karltk joined #tunes
22:57:30 smkl joined #tunes
23:13:52 bhachech joined #tunes
23:14:24 <bhachech> bhachech
23:16:12 bhachech left #tunes
00:27:53 cor{study} joined #tunes