fluid-work IRC Logs-2008-10-10
- Fluid IRC Log Bot
[07:41:28 EDT(-0400)] * michelled (n=team@142.150.154.197) has joined #fluid-work <Bosmon> <Bosmon> <Bosmon> You just have <Bosmon> var fors = fluid.transform(labels, function(element) ); <Bosmon> , <Bosmon> , <Bosmon> ]}
[08:19:56 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-67-245.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[08:37:00 EDT(-0400)] * EricDalquist (n=EricDalq@adsl-76-208-67-245.dsl.mdsnwi.sbcglobal.net) has joined #fluid-work
[08:51:49 EDT(-0400)] * jacobfarber1 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[09:25:46 EDT(-0400)] * anastasiac (n=stasia@72.33.23.226) has joined #fluid-work
[09:43:03 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[09:43:36 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279475053.dsl.bell.ca) has joined #fluid-work
[10:06:13 EDT(-0400)] * EricDalquist (n=EricDalq@static-210-59.vpn.wisc.edu) has joined #fluid-work
[10:10:54 EDT(-0400)] * apetro (n=apetro@72.33.23.236) has joined #fluid-work
[10:24:14 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[10:31:35 EDT(-0400)] <anastasiac> Bosmo1, good morning/afternoon
[10:32:48 EDT(-0400)] <anastasiac> I'm wondering if you can help me understand some rendering stuff
[10:33:10 EDT(-0400)] * Bosmon (n=Antranig@ginger.caret.cam.ac.uk) has joined #fluid-work
[10:33:33 EDT(-0400)] <anastasiac> Bosmon, I'm looking at the preferable use of the renderer that was just committed about 10 minutes ago
[10:33:56 EDT(-0400)] <anastasiac> it works, but i wouldn't have thought it would based on how I thought things worked
[10:34:16 EDT(-0400)] <michelled> that's with the dehydrated form of the tree that you talked me through, Bosmo1
[10:34:20 EDT(-0400)] <anastasiac> the component tree has "opts: null", etc
[10:34:41 EDT(-0400)] <anastasiac> I would have thought that the 'null' would have told the renderer to render that node with nothingness
[10:34:57 EDT(-0400)] <anastasiac> I'm clearly not understanding the nature/purpose of this tree...
[10:35:01 EDT(-0400)] <Bosmon> Ah, yes
[10:35:10 EDT(-0400)] <Bosmon> Well, you have to view it in terms of the "undehydrated" form
[10:35:24 EDT(-0400)] <Bosmon> "opts: null" expands to
[10:35:33 EDT(-0400)]
[10:35:42 EDT(-0400)] <Bosmon> And null is really indistinguishable from undefined
[10:35:52 EDT(-0400)] <Bosmon> which means you are supplying "no value" from the component tree side
[10:35:53 EDT(-0400)] <anastasiac> ok, but I still would have thought the same thing, null/undefined/{}
[10:36:09 EDT(-0400)] <anastasiac> that's my point - if you're supplying 'no value' then why is it rendering?
[10:36:11 EDT(-0400)] <Bosmon> Now, the real meaning of "supplying no value" is "I am happy with what is in the template already"
[10:36:20 EDT(-0400)] <anastasiac> ah!
[10:36:22 EDT(-0400)] <Bosmon> it is rendering because there is a component
[10:36:30 EDT(-0400)] <anastasiac> fog, lifting
[10:36:32 EDT(-0400)] <Bosmon> If there is a component, then things render
[10:36:37 EDT(-0400)] <Bosmon> If there is no component, then things do not render
[10:37:06 EDT(-0400)] <Bosmon> Now, components have values bound to them.... and values which are "no value" are a symbol which says, "I don't want to influence this piece of markup"
[10:37:30 EDT(-0400)] <anastasiac> light bulb brightening, albeit slowly
[10:37:44 EDT(-0400)] <Bosmon> The "rendering idiom" is really a sort of "do no harm" idiom 
[10:37:58 EDT(-0400)] <Bosmon> Basically, unless you say something to influence something, you get whatever is already written in the markup
[10:38:07 EDT(-0400)] <anastasiac> ok, but if you don't want to change the template, why put an rsf:id on it at all?
[10:38:17 EDT(-0400)] <Bosmon> You might want to conditionally change the template
[10:38:32 EDT(-0400)] <Bosmon> Putting the rsf:id on it is a signal that you might want to take the driving seat in some cases
[10:38:49 EDT(-0400)] <anastasiac> ok, cool - makes sense
[10:38:57 EDT(-0400)] <Bosmon> But of course you must always have the option to "give away" your control
[10:38:59 EDT(-0400)] <anastasiac> I guess in differing situations, you may want to render
[10:39:03 EDT(-0400)] <anastasiac> very nice
[10:39:04 EDT(-0400)] <Bosmon> And revert it back to the markup author
[10:39:17 EDT(-0400)] <anastasiac> though I have to say, seeing 'null' is a bit unintuitive at first
[10:39:24 EDT(-0400)] <Bosmon> Yes 
[10:39:26 EDT(-0400)] <Bosmon> Maybe
[10:39:27 EDT(-0400)] <anastasiac> not sure I can think of anything better, though
[10:41:36 EDT(-0400)] <anastasiac> ok, cool. more pieces of the puzzle finding their spot in my head...
[10:41:48 EDT(-0400)] <anastasiac> thanks!
[10:42:43 EDT(-0400)] <anastasiac> I think I will spend a bit of time learning more about the hydrated form of the component tree, since that seems to be the more 'real' format...
[10:42:54 EDT(-0400)] <Bosmon> Yes
[10:42:56 EDT(-0400)] <Bosmon> It is
[10:43:00 EDT(-0400)] <anastasiac> better to learn to write properly before learning shorthand
[10:43:50 EDT(-0400)] <anastasiac> so, regarding how to give control away, Bosmon...
[10:43:57 EDT(-0400)] <anastasiac> null, undefined, {}
[10:44:08 EDT(-0400)] <anastasiac> is there a preferred, more 'proper' choice of these three?
[10:44:31 EDT(-0400)] <anastasiac> I would think {} would be most appropriate. It doesn't have the
[10:44:34 EDT(-0400)] <Bosmon> Well, {} is really "not right"
[10:44:39 EDT(-0400)] <Bosmon> It actually represents an "object"
[10:44:42 EDT(-0400)] <anastasiac> ok...
[10:44:58 EDT(-0400)] <Bosmon> "null" is the preferred option
[10:45:15 EDT(-0400)] <Bosmon> Since I think it is not really good for "undefined" to be stored as a value member
[10:45:16 EDT(-0400)] <anastasiac> I would think that {}, being an object, might be more correct, since you do want the node rendered, you just don't want to supply your own value.
[10:45:23 EDT(-0400)] <anastasiac> but ok, null is the way to go
[10:45:26 EDT(-0400)] <Bosmon> Yes, but {} IS a value
[10:45:36 EDT(-0400)] <anastasiac> yes, and you do want the node rendered
[10:45:44 EDT(-0400)] <anastasiac> but you don't want to supply a 'custom' value
[10:45:48 EDT(-0400)] <Bosmon> Yes, but you have written a component
[10:45:50 EDT(-0400)] <Bosmon> To represent that
[10:46:01 EDT(-0400)] <anastasiac> I have??
[10:46:04 EDT(-0400)] <Bosmon> Yes
[10:46:22 EDT(-0400)]
[10:46:29 EDT(-0400)] <Bosmon> This object here represents a component
[10:46:32 EDT(-0400)] <anastasiac> right, ok, got it
[10:46:34 EDT(-0400)] <Bosmon> You could either write it, or not
[10:46:48 EDT(-0400)] <anastasiac> thanks so much for your patience with these pretty basic questions
[10:46:54 EDT(-0400)] <Bosmon> So having written it, it seems "double dealing" to then supply a further value inside it representing, actually, that you want "nothing" to happen
[10:47:00 EDT(-0400)] <Bosmon> No, these questions are essential
[10:47:01 EDT(-0400)] <anastasiac> they're probably annoying to you, but they're very helpful to me
[10:47:07 EDT(-0400)] <Bosmon> We need to find some way to get these speed bumps levelled
[10:47:21 EDT(-0400)] <Bosmon> They are the sorts of issue that lead people to label this templating system as "complex"
[10:47:34 EDT(-0400)] <anastasiac> well, I'm going to try to simplify it
[10:47:48 EDT(-0400)] <Bosmon> When really, it follows a number of quite simple, regular rules
[10:47:57 EDT(-0400)] <Bosmon> Which taken in isolation, all seem pretty reasonable and straightforward
[10:49:01 EDT(-0400)] <anastasiac> hopefully, we can find a way to convey that to newbies effectively
[10:49:16 EDT(-0400)] <anastasiac> I think user testing of documentation is going to be very important for the renderer
[10:50:12 EDT(-0400)] <michelled> anastasiac, another speed bump that I rammed into was the use of nesting in a component tree
[10:50:32 EDT(-0400)] <anastasiac> right! that was another question I had
[10:50:37 EDT(-0400)] <michelled> I had thought that the nesting followed the structure of the markup, but really nested denotes looping and branching
[10:50:53 EDT(-0400)] <anastasiac> yes, that does seem to be the case, doesn't it?
[10:51:34 EDT(-0400)] <michelled> Bosmon, does that mean that I would only have nesting following a ':' ?
[10:52:56 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[10:53:10 EDT(-0400)] <Bosmon> michelled: Yes, that is generally right
[10:53:19 EDT(-0400)] * athena7 (n=athena7@75.58.126.207) has joined #fluid-work
[10:53:41 EDT(-0400)] <Bosmon> Nesting only goes with : tags and components
[10:53:59 EDT(-0400)] <Bosmon> When we had types, a colon tag was associated with a component of type "UIBranchComponent"
[10:54:12 EDT(-0400)] <Bosmon> But now we don't have types, you just detect these by virtue of the fact they have a member named "children"
[10:54:56 EDT(-0400)] <michelled> so do we still require the ':'?
[10:55:04 EDT(-0400)] <Bosmon> Yes, you must always write the :
[10:55:17 EDT(-0400)] <Bosmon> In theory, you could miss it out in the component tree, since the types are obvious
[10:55:21 EDT(-0400)] <Bosmon> But you couldn't miss it out in the template
[10:55:36 EDT(-0400)] <Bosmon> So then it would become confusing if you had a mismatch between what you write in the template and what you write in the component tree
[10:56:02 EDT(-0400)] <michelled> yes
[10:56:39 EDT(-0400)] <michelled> my previous questions was trying to get at that. so if I communicate my looping or branching in the component tree, why do I need to communicate it also in the template?
[10:56:46 EDT(-0400)] <Bosmon> Yes
[10:56:51 EDT(-0400)] <Bosmon> It is just a matter of consistency
[10:57:54 EDT(-0400)] <michelled> what I'm trying to get at is: can we get rid of the ':' in the template by communicating our branching needs in the component tree?
[10:58:08 EDT(-0400)] <Bosmon> Well, no
[10:58:16 EDT(-0400)] <Bosmon> At least, I don't believe so
[10:58:30 EDT(-0400)] <Bosmon> I couldn't think of a way of writing the template parser in such a way that it wasn't "warned" by the presence of : tags
[10:58:59 EDT(-0400)] <Bosmon> I remember we had a debate about this around the time RSF 0.7 was released
[10:59:05 EDT(-0400)] <Bosmon> Since we had an opportunity then to change this...
[10:59:30 EDT(-0400)] <michelled> I don't remember that - was it with me?
[10:59:37 EDT(-0400)] <Bosmon> No, I mean "we here"
[10:59:40 EDT(-0400)] <Bosmon> It was more than 2 years ago
[10:59:49 EDT(-0400)] <michelled> ah
[10:59:53 EDT(-0400)] <Bosmon> There is a very distinct meaning to writing repeated things in the template WITH a colon, and without
[10:59:56 EDT(-0400)] <Bosmon> For example, this:
[11:00:25 EDT(-0400)] <Bosmon> <div>
[11:00:25 EDT(-0400)] <Bosmon> <span rsf:id="text">My text</span>
[11:00:25 EDT(-0400)] <Bosmon> <input rsf:id="text">My input</input>
[11:00:25 EDT(-0400)] <Bosmon> </div>
[11:00:33 EDT(-0400)] <Bosmon> This shows a repetition using a non-colon id of "text"
[11:00:37 EDT(-0400)] <Bosmon> But here there is only ONE COMPONENT
[11:00:52 EDT(-0400)] <Bosmon> These different tags will all pair up with a single component in the tree, which must be unique within its container
[11:00:54 EDT(-0400)] <Bosmon> Whereas writing this:
[11:01:11 EDT(-0400)] <Bosmon> <ul>
[11:01:11 EDT(-0400)] <Bosmon> <li rsf:id="item:">My item 1</li>
[11:01:23 EDT(-0400)] <Bosmon> <li rsf:id="item:">My item 2</li>
[11:01:23 EDT(-0400)] <Bosmon> </ul>
[11:01:36 EDT(-0400)] <Bosmon> This represents (what will be) MULTIPLE COMPONENTS
[11:01:49 EDT(-0400)] <Bosmon> That is, the repetitions are only examples of the "potentially repeated component"
[11:02:15 EDT(-0400)] <Bosmon> and there will in general be an unknown number of components with the id "item:" in the tree, and they will each give rise to a DIFFERENT block of markup
[11:02:45 EDT(-0400)] <Bosmon> Well, again you might say here, that this is something that could perfectly well be determined in the component tree, and doesn't need to be written in the tree....
[11:02:59 EDT(-0400)] <anastasiac> Bosmon, a question about these two examples:
[11:03:25 EDT(-0400)] <Bosmon> In example one, you get exactly what you write in the markup
[11:03:31 EDT(-0400)] <Bosmon> That is, exactly the same number of things which you wrote
[11:03:38 EDT(-0400)] <Bosmon> In example two, the number of repetitions is driven by the tree
[11:03:46 EDT(-0400)] <anastasiac> the second example I think I understand - there are only multiple <li>s in the template for preview kinds of purposes, right?
[11:03:52 EDT(-0400)] <Bosmon> However many you wrote in the template, you get the number that was in the tree
[11:03:56 EDT(-0400)] <Bosmon> anastasiac: That's right, yes
[11:04:07 EDT(-0400)] <anastasiac> I'm not clear ont he first example, though
[11:04:15 EDT(-0400)] <Bosmon> The first example is "a little odd"
[11:04:17 EDT(-0400)] <anastasiac> woudl rendering either render one or the other? or both?
[11:04:25 EDT(-0400)] <anastasiac> what might the tree look like for it?
[11:04:26 EDT(-0400)] <Bosmon> But you can imagine it is quite useful, for example, in the case of "inline edit"
[11:04:31 EDT(-0400)] <Bosmon> The tree simply has one component
[11:04:37 EDT(-0400)] <Bosmon> But both things in the template are rendered
[11:04:49 EDT(-0400)] <Bosmon> It is useful, in the case where you just want "the same thing" to appear in several places
[11:05:11 EDT(-0400)] <Bosmon> But for example, in our "self-rendering baseball table" we can use this trick to avoid having to "double up" the component tree
[11:05:26 EDT(-0400)] <Bosmon> Since really the "editable" and "non-editable" views of the component are really "the same component"
[11:06:33 EDT(-0400)] <michelled> if the second example has multiple items for preview purposes, why wouldn't we just drop the rsf:id on those? or use an rsf:ignore? basically tell the parser that we don't want this content
[11:06:37 EDT(-0400)]
[11:07:07 EDT(-0400)] <Bosmon> michelled: We can't drop the rsf:id, since in that case it would be "always rendered" which would probably not be what you want
[11:07:17 EDT(-0400)] <Bosmon> an "ignore" is an option, but I guess it would look a bit odd
[11:07:31 EDT(-0400)] <Bosmon> And there is a "slight subtlety" with repeated components sometimes, which is this matter of "glue"
[11:07:49 EDT(-0400)] <Bosmon> Sometimes you write tiny bits of markup "in between" the repeated components, that you might want to be duplicated along with them
[11:07:57 EDT(-0400)] <Bosmon> Perhaps a spacer, or an arrow, or some other thing
[11:08:10 EDT(-0400)] <Bosmon> "I was told" that in general people "should prefer" to do this kind of thing using CSS
[11:08:16 EDT(-0400)] <Bosmon> But i think sometimes it is nice to have the option
[11:08:58 EDT(-0400)] <Bosmon> Say you wrote something like this: <span rsf:id="thing:"> -> <span rsf:id="thing:">
[11:09:17 EDT(-0400)] <Bosmon> Now, however many "thing:" components you write, each of them will end up being spaced by this "glue" in between them
[11:09:24 EDT(-0400)] <Bosmon> Consisting of the little right arrow thing
[11:09:39 EDT(-0400)] <Bosmon> It is probably often not very useful, but sometimes it is....
[11:09:50 EDT(-0400)] * anastasiac was distracted about 5 minutes ago, but is catching up now
[11:10:05 EDT(-0400)] <Bosmon> So, this is one of the reasons you might write 2 or more repetitions of something in the template which might be repeated
[11:10:12 EDT(-0400)] <Bosmon> But yes, you can always get away with just 1
[11:10:12 EDT(-0400)] <jessm> anastasiac: doing double duty in uPortal and here
[11:10:24 EDT(-0400)] <Bosmon> And writing "ignore" is another option yes, it just looks a bit odd
[11:11:10 EDT(-0400)] <anastasiac> jessm, yep
[11:14:29 EDT(-0400)] <apetro> (discussion in ##uportal about including Fluid in build, URL namespace as deployed, and in browser responses)
[11:14:55 EDT(-0400)] <anastasiac> thanks, apetro
[11:17:38 EDT(-0400)] <Bosmon> Why do we have two ## in ##uportal
[11:25:50 EDT(-0400)] <apetro> JASIG hasn't worked through the administrivia to formally register with irc.freenode.net
[11:26:01 EDT(-0400)] <EricDalquist> http://mojo.codehaus.org/javascript-maven-tools/guide-javascript-development.html
[11:27:42 EDT(-0400)] <apetro> Bosman, as I understand it ## channels are dynamically allocated and rely on people being adult about it, whereas # channels are more formally registered and have ownership. JASIG has claim on ##uportal only by convention, whereas FLUID has formal claim on #fluid-work.
[11:28:04 EDT(-0400)] <Bosmon> How interesting
[11:28:25 EDT(-0400)] <anastasiac> oh! I thought it was the otherway around, that ## channels were more formally registered
[11:28:28 EDT(-0400)] <anastasiac> but I'm often wrong
[11:28:30 EDT(-0400)] <Bosmon> I guess this is why we have no "bot" controlling us
[11:28:47 EDT(-0400)] <Bosmon> Your "bot" is your insurance, to substitute your lack of registration...
[11:29:04 EDT(-0400)] <apetro> entirely possible I have it backwards. FreeNode has a whole writeup about this somewhere tho.
[11:29:50 EDT(-0400)] <EricDalquist> actually the bot there is because I use the /chanserv commands to request it
[11:30:06 EDT(-0400)] <Bosmon> I see
[11:30:08 EDT(-0400)] <EricDalquist> that way the title and modes don't disappear when the channel is empty
[11:30:17 EDT(-0400)] <EricDalquist> since it is never empty as chanserv is always there
[11:32:04 EDT(-0400)] <Bosmon> I remember the IRC "glory days"
[11:32:08 EDT(-0400)] <Bosmon> Of the 90s
[11:32:20 EDT(-0400)] <Bosmon> Although for all I know, there are now more people on IRC than there ever were then....
[11:37:03 EDT(-0400)] <Bosmon> I love fluid.transform
[11:37:15 EDT(-0400)]
[11:37:45 EDT(-0400)] <Bosmon> Although in a "really cool" language this would be even shorter...
[11:42:21 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-59.LIPS.Berkeley.EDU) has joined #fluid-work
[12:05:39 EDT(-0400)] <anastasiac> Bosmon, I have a question about the format of a hydrated component tree, if you have a moment?
[12:06:06 EDT(-0400)] <anastasiac> if the dehydrated tree looks like this:
[12:06:10 EDT(-0400)] <Bosmon> Hi
[12:06:16 EDT(-0400)] <anastasiac> var tree = { "entry-field": "this-value",
[12:06:16 EDT(-0400)] <anastasiac> "field-list:": ["value1", "value"]
[12:06:17 EDT(-0400)] <anastasiac> }
[12:06:23 EDT(-0400)] <Bosmon> It's funny you say that
[12:06:27 EDT(-0400)] <Bosmon> Since I just wrote a tree like that
[12:06:28 EDT(-0400)] <anastasiac> then what would the corresponding hydrated tree look like?
[12:07:10 EDT(-0400)] <Bosmon> The hydrated tree looks like this:
[12:07:14 EDT(-0400)] <Bosmon> (fully hydrated)
[12:09:11 EDT(-0400)] <Bosmon> var tree = {
[12:09:11 EDT(-0400)] <Bosmon> children: [
[12:09:11 EDT(-0400)]
[12:09:11 EDT(-0400)]
[12:09:11 EDT(-0400)]
[12:09:32 EDT(-0400)] <Bosmon> At least, it should be possible for the system to convert what you wrote into this form
[12:10:54 EDT(-0400)] <anastasiac> ah! "children: []"
[12:10:59 EDT(-0400)] <anastasiac> that's what my mental model was missing
[12:11:10 EDT(-0400)] <anastasiac> thanks!
[12:11:15 EDT(-0400)] <Bosmon> yes, the "overall root" is actually a "container"
[12:11:17 EDT(-0400)] <Bosmon> An implicit one
[12:11:36 EDT(-0400)] <Bosmon> In "RSF Server" it is a special kind of UIBranchContainer of type ViewRoot
[12:11:53 EDT(-0400)] <Bosmon> But as usual in Javascript it is just a mass of JSON
[12:12:37 EDT(-0400)] <Bosmon> I guess we need a whole battery of test cases just to ensure that hydration is working as we generally expect
[12:14:46 EDT(-0400)] <Bosmon> it's interesting how many bugs in the overall algorithm are being exposed by porting it into Javascript...
[12:14:56 EDT(-0400)] <Bosmon> There are all sorts of "odd conditions" that noone seems to have ever provoked on the server...
[12:18:26 EDT(-0400)] * ecochran (n=ecochran@dhcp-169-229-212-59.LIPS.Berkeley.EDU) has joined #fluid-work
[12:18:30 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined #fluid-work
[12:18:50 EDT(-0400)] <anastasiac> yes, fluid seems to be good at producing odd conditions
[12:27:11 EDT(-0400)] <anastasiac> I'm off to the airport, all
[12:27:22 EDT(-0400)] <anastasiac> have a great weekend, and I'll see you Toronto folks next week!
[12:29:43 EDT(-0400)] * phiggins (n=dante@c-68-34-199-67.hsd1.tn.comcast.net) has joined #fluid-work
[14:03:55 EDT(-0400)] <Bosmon> "From a quart of cream and a process to convert a quart of cream into a pound of butter, one may obtain a pound of butter."
[14:09:02 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[15:28:23 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[15:37:30 EDT(-0400)] * athena7 (n=athena7@adsl-75-58-126-207.dsl.wlfrct.sbcglobal.net) has joined #fluid-work
[15:49:23 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has joined #fluid-work
[17:46:14 EDT(-0400)] * jacobfarber1 (n=Main@CPE00095bc35ea1-CM001692f5798c.cpe.net.cable.rogers.com) has joined #fluid-work
[18:08:59 EDT(-0400)] * theclown (n=theclown@guiseppi.atrc.utoronto.ca) has left #fluid-work
[18:11:03 EDT(-0400)] * apetro (n=apetro@h69-128-111-235.mdsnwi.dedicated.static.tds.net) has joined #fluid-work
[18:13:49 EDT(-0400)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work
[20:09:59 EDT(-0400)] * jessm (n=Jess@c-76-19-199-61.hsd1.ma.comcast.net) has joined #fluid-work
[23:12:50 EDT(-0400)] * lessthanzero (n=lessthan@CPE001ff342457c-CM001ac352aefc.cpe.net.cable.rogers.com) has joined #fluid-work