[03:33:44 EDT(-0400)] * mad (n=chatzill@pcit-6254.HIG.SE) has joined ##uportal
[03:47:53 EDT(-0400)] <higpetter> mad: http://83.178.29.247/cam
[03:51:24 EDT(-0400)] * apetro-_ (n=apetro@ip68-98-37-188.ph.ph.cox.net) has joined ##uportal
[08:02:42 EDT(-0400)] * jessm (n=Jess@wm280hi-109.102.Maroon.NetSurf.Net) has joined ##uportal
[08:48:11 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[09:17:55 EDT(-0400)] * athena7 (n=athena7@rs-69-169-146-128-0003.broadweave.net) has joined ##uportal
[09:25:52 EDT(-0400)] * jessm (n=Jess@user147-69.wireless.utoronto.ca) has joined ##uportal
[09:37:13 EDT(-0400)] * anastasiac (n=team@142.150.154.160) has joined ##uportal
[09:47:03 EDT(-0400)] * jessm (n=Jess@user147-69.wireless.utoronto.ca) has joined ##uportal
[09:47:41 EDT(-0400)] * colinclark (n=colin@bas1-toronto09-1279336337.dsl.bell.ca) has joined ##uportal
[09:59:23 EDT(-0400)] * bulloche (n=bulloche@134.250.4.77) has joined ##uportal
[10:22:42 EDT(-0400)] * EricDalquist (n=dalquist@bohemia.doit.wisc.edu) has joined ##uportal
[10:26:24 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal
[10:47:28 EDT(-0400)] <EricDalquist> grr ... I'm having issues with SVN line endings :/
[10:50:33 EDT(-0400)] <EricDalquist> if I edit the files manually svn diff works as expected
[10:50:51 EDT(-0400)] <EricDalquist> if I apply this patch diff shows the entire file as changed
[10:50:57 EDT(-0400)] <EricDalquist> unless I tell it to ignore line endings
[10:51:13 EDT(-0400)] <EricDalquist> not sure why applying a diff is mucking with line endings for the whole file
[10:55:26 EDT(-0400)] * athena7_ (n=athena7@128.187.218.229) has joined ##uportal
[10:59:06 EDT(-0400)] <EricDalquist> anyone here ever had to deal with svn line ending issues?
[11:01:59 EDT(-0400)] * jessm (n=Jess@user147-69.wireless.utoronto.ca) has joined ##uportal
[11:06:58 EDT(-0400)] * jessm (n=Jess@user147-69.wireless.utoronto.ca) has joined ##uportal
[11:16:24 EDT(-0400)] * apetro-_ (n=apetro@ip68-98-37-188.ph.ph.cox.net) has joined ##uportal
[11:17:49 EDT(-0400)] * grimesp (n=grimesp@134.250.4.177) has joined ##uportal
[11:17:55 EDT(-0400)] * holdorph (n=holdorph@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[11:22:46 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[11:42:03 EDT(-0400)] * jessm (n=Jess@142.150.154.101) has joined ##uportal
[11:58:20 EDT(-0400)] * colinclark (n=colin@user145-154.wireless.utoronto.ca) has joined ##uportal
[12:11:31 EDT(-0400)] <athena7_> hey EricDalquist
[12:11:36 EDT(-0400)] <EricDalquist> hi
[12:11:55 EDT(-0400)] <athena7_> yes, i've had a bunch of problems with svn line endings whenever i've done vendor imports of uportal
[12:12:14 EDT(-0400)] <EricDalquist> yeah I'm guessing we need to do this same fix in uPortal :/
[12:12:19 EDT(-0400)] <athena7> yes
[12:12:22 EDT(-0400)] <EricDalquist> right now I'm dealing with it in Cernunnos
[12:12:26 EDT(-0400)] <athena7> i've fixed files on occasion
[12:12:30 EDT(-0400)] <athena7> but there are still some badones
[12:12:39 EDT(-0400)] <athena7> and i think the bookmarks portlet has problems as well
[12:13:08 EDT(-0400)] <athena7> i don't know if you remember, but i posted a uportal-taylored subversion config file a while ago
[12:13:14 EDT(-0400)] <EricDalquist> yeah
[12:13:18 EDT(-0400)] <athena7> i think it would probably be a good idea to encourage people to use something like that
[12:13:18 EDT(-0400)] <EricDalquist> I thought I remembered that
[12:13:23 EDT(-0400)] <EricDalquist> is it in the wiki?
[12:13:25 EDT(-0400)] <athena7> otherwise i think we'll just keep having these problems
[12:13:26 EDT(-0400)] <athena7> yep
[12:13:28 EDT(-0400)] <EricDalquist> ok
[12:13:30 EDT(-0400)] <athena7> trying to remember where
[12:13:35 EDT(-0400)] <athena7> i can never find something in there
[12:13:59 EDT(-0400)] <EricDalquist> yeah
[12:15:11 EDT(-0400)] <athena7> it's sad when i can't even find things i added
[12:15:30 EDT(-0400)] <athena7> google saves the day!
[12:15:31 EDT(-0400)] <athena7> http://www.ja-sig.org/wiki/display/UPC/uPortal+3+Subversion+Configuration
[12:16:13 EDT(-0400)] <holdorph> yet another example of how subversion should have learned better from Perforce
[12:16:14 EDT(-0400)] <EricDalquist> wonderful
[12:16:31 EDT(-0400)] <athena7> perforce?
[12:16:32 EDT(-0400)] <holdorph> all those settings are IN the repository in Perforce.
[12:16:43 EDT(-0400)] <athena7> ah
[12:16:43 EDT(-0400)] <athena7> yeah
[12:16:46 EDT(-0400)] <athena7> they really should be
[12:16:49 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[12:16:51 EDT(-0400)] <holdorph> commercial software that did everything subversion did and better, long before subversion came out
[12:16:54 EDT(-0400)] <athena7> it drives me a little insane that it's defined on a user level
[12:16:56 EDT(-0400)] <athena7> ah
[12:16:58 EDT(-0400)] <EricDalquist> yeah ... we can look at doing it repo side
[12:17:07 EDT(-0400)] <EricDalquist> it would take writing a commit hook
[12:17:19 EDT(-0400)] <EricDalquist> holdorph: they should open source it
[12:19:59 EDT(-0400)] <holdorph> I wish I had time to investigate the new crop of third (or fourth depending on where you start counting) gen, source code control tools, like Git, Mercurial and Bazaar.
[12:20:23 EDT(-0400)] <holdorph> I'm not sure if they 'fix' any of the things I hate about subversion, but liked about perforce or not.
[12:33:59 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[12:48:58 EDT(-0400)] <lennar2> my favorite thing about perforce was the 'cheat sheet' shirt that had all the commands written upside down so that I could read them when I looked down.
[12:51:18 EDT(-0400)] <holdorph> that was cool, so was the rugby shirt they sent me, so I could be a member of the Perforce "team"
[12:53:06 EDT(-0400)] <lennar2>
[12:58:55 EDT(-0400)] * awills (n=awills@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[13:06:52 EDT(-0400)] <awills> so if you don't include a <version> within your <dependency> (inside a pom.xml), m2 just grabs the latest?
[13:08:12 EDT(-0400)] <awills> ok maybe I jumped the hun... looking at <dependencyManagement> now
[13:10:32 EDT(-0400)] <holdorph> you jumped a Hun? what did he look like?
[13:10:58 EDT(-0400)] <awills> *gun
[14:41:09 EDT(-0400)] * EiNZTEiN (n=einztein@205.241.143.3) has joined ##uportal
[14:45:38 EDT(-0400)] <EricDalquist> awills: yeah I forgot to include a note about the pom reorg in my email
[14:45:45 EDT(-0400)] <EricDalquist> I meant that to be a separate patch
[14:46:06 EDT(-0400)] <EricDalquist> as I learn more about maven I've found that is the recommended way of doing dependency declaration
[14:46:40 EDT(-0400)] <holdorph> for parent child maven situations it is
[14:46:43 EDT(-0400)] <EricDalquist> the version numbers and exclusions in the dependencyManagement block apply to transative dependencies too
[14:47:00 EDT(-0400)] <holdorph> i should say that's where it becomes important.
[14:47:10 EDT(-0400)] <EricDalquist> even for single level because of the transative dependency uses
[14:47:47 EDT(-0400)] <holdorph> well i meant, more on the front of child poms not having the dependency version numbers at all
[14:47:51 EDT(-0400)] * colinclark (n=colin@142.150.154.101) has joined ##uportal
[14:47:55 EDT(-0400)] <EricDalquist> ah yeah
[14:48:02 EDT(-0400)] <holdorph> because they're in a dependency mgmt block in the parent
[14:48:33 EDT(-0400)] <EricDalquist> ok, finally got my commit for the line ending stuff to go through
[14:48:43 EDT(-0400)] <EricDalquist> google code has been REALLY flakey for me the last few days
[16:18:07 EDT(-0400)] * jessm (n=Jess@142.150.154.101) has joined ##uportal
[16:20:20 EDT(-0400)] * dstn (n=dstn@unaffiliated/dstn) has joined ##uportal
[16:20:49 EDT(-0400)] * athena7 (n=athena7@128.187.218.229) has joined ##uportal
[16:22:16 EDT(-0400)] <dstn> anyone ever used jMeter to load test portlets?
[16:24:56 EDT(-0400)] <awills> i'm back... had a detist appt and forgot to set _away
[16:24:58 EDT(-0400)] <EricDalquist> not portlets specificly
[16:25:01 EDT(-0400)] <EricDalquist> but we do a lot with jmeter
[16:26:04 EDT(-0400)] <dstn> was just thinking it would useful for a problem we had with a portlet earlier today
[16:26:39 EDT(-0400)] <dstn> wasn't closing it's connections and caused too many open files error
[16:34:26 EDT(-0400)] <holdorph> just make the portlet the only thing on a dlm fragment, make that fragment the only thing your users get in their layout. and test
[16:34:59 EDT(-0400)] <holdorph> kind of a hokey setup, but once you do it once, it wouldn't be hard to change that environment to perf test a different portlet.
[17:03:47 EDT(-0400)] <grimesp> does anybody have an example of making an ajax call of some sort to keep a users session alive in uPortal?
[17:04:42 EDT(-0400)] * jessm (n=Jess@142.150.154.101) has joined ##uportal
[17:21:33 EDT(-0400)] <EricDalquist> woohoo!
[17:21:40 EDT(-0400)] <EricDalquist> so with all of the caching changes
[17:21:45 EDT(-0400)] <EricDalquist> and a 8 thread pool for export
[17:22:00 EDT(-0400)] <EricDalquist> I should be able to export ~100000 layouts in less than 45 minutes
[17:22:43 EDT(-0400)] <awills> that would put you basically on track to go round trip in 3 hrs, assuming it's as quick to import them
[17:22:44 EDT(-0400)] <holdorph> what's the equivalent time to write jdbc to export those database tables. Not that, what you would have would be useable, just curious what the remaining overhead is.
[17:24:00 EDT(-0400)] <EricDalquist> XSLT transformation, groovy execution, jexl execution, xpath execution about in that order
[17:24:33 EDT(-0400)] <EricDalquist> and duplicate query execution, if I was really pressed there are probably some SQL statements that could be moved around so they are only run once
[17:24:37 EDT(-0400)] <EricDalquist> or have a cache put around them
[17:24:50 EDT(-0400)] <EricDalquist> like the queries that do group lookup and such
[17:25:35 EDT(-0400)] <EricDalquist> though even then I'm not sure how much more you'd get
[17:26:02 EDT(-0400)] <holdorph> oh, i wasn't looking into specifics. just overall numbers. Like raw jdbc dumps the tables in x minutes. dumping the data with cernunnous uportal exports takes x+y minutes
[17:26:06 EDT(-0400)] <holdorph> i'm curious what 'y' is
[17:26:28 EDT(-0400)] <EricDalquist> would be interesting
[17:26:46 EDT(-0400)] <EricDalquist> when we get closer I can ask our dbas to time the backup dump they will be doing
[17:27:36 EDT(-0400)] <awills> will they be using "raw jdbc" to do that dump though? or oracle tools?
[17:27:44 EDT(-0400)] <EricDalquist> oracle tools
[17:27:48 EDT(-0400)] <EricDalquist> so I guess it isn't the same
[17:28:18 EDT(-0400)] <holdorph> definitely not the same.
[17:28:57 EDT(-0400)] <holdorph> could probably get closer, trying to use a tool like db visualizer, squirrel, or something like that, that uses jdbc drivers, and get all the data out for each affected table.
[17:29:50 EDT(-0400)] <EricDalquist> so awills, have you had a chance to look at the caching patch?
[17:32:11 EDT(-0400)] <awills> yes i have... would love to pour over every line, but the patch is immense... i've looked through it enough to feel like I understand the approach... the fact that it all works is still matter of faith atm but I'm not short of faith
[17:32:45 EDT(-0400)] <EricDalquist> well it 'works' in the context of the uportal import/export
[17:32:54 EDT(-0400)] <EricDalquist> but that is about as much testing as I can do with it
[17:33:00 EDT(-0400)] <awills> i have to say i love your use of nesteed types, where circumstances call for it, i thought i was the only one :?
[17:33:15 EDT(-0400)] <EricDalquist> I'm always mixed on them
[17:33:28 EDT(-0400)] <EricDalquist> but I use them when they're small and only the parent class uses them
[17:34:06 EDT(-0400)] <awills> yeah i use them, like Map.Entry, to make stronger association between two types in circumstances like those
[17:34:18 EDT(-0400)] <awills> but w/e, i like the approach
[17:34:41 EDT(-0400)] <holdorph> you'd not like them as much if you were trying to terracotta-enable the 'inner' type and not the 'outer' type.
[17:35:05 EDT(-0400)] <EricDalquist> also if you want to explore the request.getCache() route it should only requre changes in DynamicCacheHelper
[17:35:07 EDT(-0400)] <holdorph> I remain steadfast in that they suck. And weird how my current task is backing that up.
[17:35:09 EDT(-0400)] <awills> it's probably nicer not to have to add req.getCahce(EntityConfig), though I was prepared to do so for an important development like this
[17:36:13 EDT(-0400)] <EricDalquist> sounds good, again 100% of the caching logic is in that CacheHelper implementation so it will be very easy to change down the road
[17:36:17 EDT(-0400)] <awills> i like that you defined the CACHE and CACHE_MODEL reagents on the interface, not each individual task/phrase
[17:36:39 EDT(-0400)] <EricDalquist> heh, yeah I got fed up with having the same things everywhere
[17:36:43 EDT(-0400)] <awills> yes i like that too... it makes the tasks/phrases not have to deal with those complex considerations
[17:37:05 EDT(-0400)] <awills> i think it's great... here are my few ideas for tweeks atm...
[17:37:44 EDT(-0400)] <awills> (1) move the cache stuff to the parent pkg (...cernunnos) b/c the import statements are organized only to go up
[17:38:13 EDT(-0400)] <awills> (2) change CACHE_MODEL to an enum w/ 3 entries: ONE, ALL, NONE
[17:38:49 EDT(-0400)] * apetro-_ (n=apetro@wsip-98-174-242-39.ph.ph.cox.net) has joined ##uportal
[17:38:51 EDT(-0400)] <awills> i think that's pretty much it, and I was thinking i could take care of (1) and (2) myself, and let you wash your hands
[17:39:02 EDT(-0400)] <EricDalquist> on a note related to 2 I can't wait until crn gets the ability to do type coersion
[17:39:29 EDT(-0400)] <awills> neither of these changes functionality... should be the same performance characteristics
[17:39:46 EDT(-0400)] <awills> OH YES, type coersion will help here... was thinking that too
[17:39:47 EDT(-0400)] <EricDalquist> yeah they both sound good
[17:39:50 EDT(-0400)] <EricDalquist> and easy
[17:39:58 EDT(-0400)] <EricDalquist> yeah right now CACHE_MODEL will still be a String phrase
[17:40:08 EDT(-0400)] <EricDalquist> and I'll do the conversion in the code that reads it
[17:40:22 EDT(-0400)] <EricDalquist> since having to enter a ENUM in xml would be a pain
[17:41:08 EDT(-0400)] <EricDalquist> also, what are your thoughts on the pom changes?
[17:41:11 EDT(-0400)] <awills> i think it'd be ok to have the phrase return an enum value... make the default CACHE_MODEL= ONE... how often would you need to change it? (i guess that's a serious question)
[17:41:34 EDT(-0400)] <EricDalquist> yeah but it is then non-obviouos on configuring it
[17:41:54 EDT(-0400)]

<awills> naw, an enum in xml is just $

Unknown macro: {groovy(org.danann.cernunnos.CacheInterface.CACHE_ALL)}

or whatever

[17:41:56 EDT(-0400)] <EricDalquist> I read the grammardoc and see 'oh I just need to create an attribute with the value ALL'
[17:42:08 EDT(-0400)] <EricDalquist> yeah but where in the documentation does it tell me to do that?
[17:42:13 EDT(-0400)] <EricDalquist> I just have to 'know'
[17:42:24 EDT(-0400)] <awills> yeah that could be clearer...
[17:42:41 EDT(-0400)] <awills> there's an "Expected Type" column in the table, and there could be examples
[17:43:02 EDT(-0400)] <EricDalquist> I think we're better sticking with strings until we get coersion working then just change the code to make it cleaner
[17:43:10 EDT(-0400)] <EricDalquist> instead of making script writers jump through hoops
[17:43:17 EDT(-0400)] <awills> we could also have an Attributes.CACHE_MODEL that, if set, would override all the defaults to the value you specify at a higher level
[17:43:49 EDT(-0400)] <EricDalquist> ?
[17:44:17 EDT(-0400)]

<awills> $

Unknown macro: {AttributePhrase(Attributes.CACHE_MODEL, CacheModelEnum.ONE)}

when defining the reagent

[17:44:56 EDT(-0400)] <awills> would prefer the value of Attributes.CACHE_MODEL, then the default of ONE... unless you specify, which trumps all
[17:45:19 EDT(-0400)] <awills> sorry forget the ${} in the example above
[17:45:19 EDT(-0400)] <EricDalquist> yeah, that's what it does now right?
[17:45:24 EDT(-0400)] <awills> that would be in the java codde
[17:46:05 EDT(-0400)] <awills> yeah, looks like it does...
[17:46:06 EDT(-0400)] <awills> new AttributePhrase(Attributes.CACHE_MODEL, new LiteralPhrase("cache-one"))
[17:46:20 EDT(-0400)] <EricDalquist> oh and numbers from threading the layout export (300 layouts): 1-11972ms, 2-9576ms, 4-7581ms, 8-7474ms
[17:46:32 EDT(-0400)] <EricDalquist> that is on a dual core machine
[17:46:54 EDT(-0400)] <awills> if it were new AttributePhrase(Attributes.CACHE_MODEL, CacheModelEnum.ONE)
[17:47:07 EDT(-0400)] <awills> those numbers aree cool, very glad to see it makes a difference
[17:47:53 EDT(-0400)] <EricDalquist> yeah, again I'm not sold on making the script writer know they can't just use strings but I'll leave that up to you
[17:48:00 EDT(-0400)] <awills> are you just going to CacheModel.ALL across the whole import/export? i should think it would be totally safe
[17:48:13 EDT(-0400)] <EricDalquist> yeah
[17:48:22 EDT(-0400)] <awills> i'll make it a massive priority to get the coercion going

[17:48:24 EDT(-0400)] <EricDalquist> right now the top level task is a with that sets it to call
[17:48:28 EDT(-0400)] <EricDalquist> all*
[17:48:37 EDT(-0400)] <awills> that's great
[17:49:06 EDT(-0400)] <EricDalquist>

but if we just do strings in the scripts, once coercion is working we can just clean up the code, no need to change scripts
[17:49:55 EDT(-0400)] <awills> well yes, i had thought of that
[17:50:09 EDT(-0400)] <awills> it's a real point
[17:51:14 EDT(-0400)] <awills> would you just be able to use eclipse to move the cache classes to the root pkg before you commit?
[17:51:23 EDT(-0400)] <awills> i think that one's easy
[17:51:27 EDT(-0400)] <EricDalquist> oh yeah
[17:51:35 EDT(-0400)] <EricDalquist> and I can switch the code to use an enum too
[17:51:49 EDT(-0400)] <EricDalquist> and just do the lookup when I pull the value from the phrase
[17:52:01 EDT(-0400)] <awills> you'd have to implement a CacheModel.NONE... or would you leave that to me?
[17:52:39 EDT(-0400)] <EricDalquist> I can do that
[17:52:51 EDT(-0400)] <EricDalquist> it would be a very easy change in the cache helper
[17:52:53 EDT(-0400)] <awills> alright... i'm sure it's good then
[17:52:59 EDT(-0400)] <EricDalquist> it just checks and calls the factory on each call to it
[17:53:04 EDT(-0400)] <awills> yeah it sounds easy
[17:53:10 EDT(-0400)] <awills> yep
[17:53:27 EDT(-0400)] <EricDalquist> so ran export all layouts on a larger set (700 layouts) and it averages 20ms per layout there
[17:53:34 EDT(-0400)] <awills> I can't wait to see how some other things run w/ these enhancements

[17:53:46 EDT(-0400)] <EricDalquist> which puts our total export time for layouts around 30 minutes
[17:53:46 EDT(-0400)] <awills> w/ 8 threads in the pool?
[17:53:49 EDT(-0400)] <EricDalquist> 4
[17:53:52 EDT(-0400)] <awills> nice
[17:54:00 EDT(-0400)] <EricDalquist> wasn't much benefit with 8 over 4
[17:54:09 EDT(-0400)] <EricDalquist> my CPU is pegged there
[17:54:12 EDT(-0400)] <awills> yeah i think your numbers reflected that
[17:54:41 EDT(-0400)] <EricDalquist> yeah it should be a big boost
[17:54:54 EDT(-0400)] <awills> totally... that will be a lot of fun to see
[17:55:43 EDT(-0400)] <awills> i bet chris d. will have this tech patched and witnessing the speed himself before a week is out
[18:00:45 EDT(-0400)] <EricDalquist> would you like to see another patch after I make those changes?
[18:00:48 EDT(-0400)] <EricDalquist> or should I just commit?
[18:01:01 EDT(-0400)] <EricDalquist> I'll go create a matching issue in the google code webui
[18:02:06 EDT(-0400)] <awills> no, just commit... we've batted this one back and forth a few times... i think we've come to a good understanding now
[18:02:19 EDT(-0400)] <EricDalquist> sounds good
[18:06:18 EDT(-0400)] <awills> gl getting past inspector 502 :?
[18:06:31 EDT(-0400)] <EricDalquist> uhg yeah
[18:06:35 EDT(-0400)] <EricDalquist> you see that too at times?
[18:22:08 EDT(-0400)] <awills> i don't think I have... maybe a while back and I dismissed it as a one-time issue
[19:07:15 EDT(-0400)] <EricDalquist> awills: you still there?
[19:24:28 EDT(-0400)] <EricDalquist> I just ran a profile of a larger dataset org.danann.cernunnos.runtime.RuntimeRequestResponse.getAttributeNames() is using 11% of the total time
[19:24:38 EDT(-0400)] <EricDalquist> because of all of the many layers of set merging
[19:25:14 EDT(-0400)] <EricDalquist> it calls java.util.AbstractCollection.addAll(Collection) 2.5 million times when exporting about 1300 users and 700 layouts ....
[19:26:05 EDT(-0400)] <holdorph> what's it addAll'ing to?
[19:26:23 EDT(-0400)] <holdorph> it seems like the performance of that would hinge on whether the underlying collection allowed duplicates or not
[19:26:47 EDT(-0400)] <EricDalquist> HashMaps
[19:26:59 EDT(-0400)] <EricDalquist> for any particular task/phrase
[19:27:05 EDT(-0400)] <holdorph> well, at least that one is in the middle somewhere
[19:27:30 EDT(-0400)] <EricDalquist> if you do task.getAttribute or task.getAttributeNames() it has to do addall calls for every level in the crn tree up to the root
[19:27:33 EDT(-0400)] <holdorph> not as bad as certain other collections could be
[19:27:46 EDT(-0400)] <EricDalquist> and since it appears the parent's attributes can change after the parent is set as the parent
[19:27:49 EDT(-0400)] <EricDalquist> it is done for every call
[19:28:08 EDT(-0400)] <EricDalquist> but I have to run and catch a bus ...
[19:28:27 EDT(-0400)] <EricDalquist> night
[19:35:38 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal
[19:41:41 EDT(-0400)] * athena7 (n=athena7@rs-69-169-146-128-0003.broadweave.net) has joined ##uportal
[20:26:12 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal
[20:42:05 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal
[20:44:45 EDT(-0400)] * lennar2 (n=sparhk@wsip-98-174-242-39.ph.ph.cox.net) has left ##uportal
[20:55:31 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal
[21:07:22 EDT(-0400)] * Sememmon (n=Sememmon@ip70-190-242-64.ph.ph.cox.net) has joined ##uportal

Browser not supported