[00:18] jelmer: I find it amusing that a feature designed to reduce spam still spams when used via email. [00:20] lifeless: oh, you're getting the affectsmetoo emails? [00:20] sorry about that, I'll avoid using that via email [00:20] jelmer: https://bugs.launchpad.net/launchpad/+bug/925224 [00:20] <_mup_> Bug #925224: affectsmetoo emails still spam all subscribers of a bug < https://launchpad.net/bugs/925224 > [00:40] wallyworld_: yes, submitted and missed 3 tests [00:40] wallyworld_: I've got to fix those and resubmit [00:41] StevenK: howdy [00:41] rick_h: ok. i've had to merge that branch locally inro my own own. if you could ping me when you've finished updating, that would be great [00:41] s/own own/own work [00:41] wallyworld_: will do, might be a bit. Out with some people atm [00:41] rick_h: np. i didn't mean now, tomorrow if fine :-) [00:42] wallyworld_: k, sounds good. Yea, just some stray doctests checking for YUI() vs LPJS so should be quick updtes [00:42] cool :-) [00:52] lifeless: I think I'm getting bug 775214 from one of the Launchpad doc tests. I think the test passing but testr just ouputs "String or Integer object expected for key, unicode found". Is this actually a failure? [00:52] <_mup_> Bug #775214: On python 2.7: String or Integer object expected for key, unicode found < https://launchpad.net/bugs/775214 > [00:55] huwshimi: where are you seeing this? [00:56] Output from "testr run -- -t sprites" (in the file lib/lp/services/doc/sprites.txt) [00:56] lifeless: ^ [00:57] lifeless: But only from my modified version of that file [00:58] huwshimi: probably not that bug [00:58] huwshimi: does 'bin/test -t sprites' error ? [00:59] lifeless: nope: http://paste.ubuntu.com/825853/ [01:00] ok, could you run [01:00] bin/test --subunit -t sprites > foo.log [01:00] and then mail me that log file ? [01:01] lifeless: sure [01:02] lifeless: Mailed [01:03] ok, so possibly you are seeing that [01:03] what testr version are you running ? [01:05] jelmer: was that irony?! [01:05] lifeless: testrepository 0.0.5-1.1 I think [01:05] add the testing-cabal PPA [01:05] that should sort things out for you [01:06] lifeless: Great, I'll try that [01:11] lifeless: Perfect, works now :) [01:14] cool [01:14] I have on my todo one more patch then a release for testr [01:16] lifeless: I assume that ec2 test won't be confused by this somehow? [01:27] it won't be [01:34] awesome [03:04] StevenK: do you know how the lp credentials/ssh keys get into the ec2 instances, such that bzr commands against lp "just work" inside the instance [03:06] wallyworld_: You might want to avoid thinking about it. [03:06] ssh -A [03:06] WCPGW [03:06] wgrant: i've got a canonistack instance i'm playing with [03:06] and i want to run some commands to pull lp trunk and run tests etc [03:07] i think ec2 test just uses ssh -A [03:07] RIght. [03:07] It uses ssh -A [03:07] Which is why it's really not healthy to think about it for long. [03:08] so i do "ssh -A " ? [03:08] However you normally ssh into the instance, add -A [03:08] right [03:08] will try that, thanks [03:08] However [03:08] Depending on your SSH config that may not work. [03:09] but it works when ec2 scripts do it [03:09] Right, but they don't go through the DC. [03:09] and the DC is more locked down? [03:10] It is, but that's not relevant here. I think it was recommended at one point to locally disable forwarding for some hosts. [03:10] But I don't have anything in mine, so I may have been misremembering. [03:10] ok, will try it and see :-) [03:10] thanks [03:30] wgrant: How do I QA the TTBJ failure on DF? [03:30] Since I've managed to avoid TTBJs completly until now [03:34] StevenK: Difficult [03:34] StevenK: TTBJs are normally done on staging [03:34] But the code may not be there yet. [03:35] wgrant: Happy enough to qa-untestable it, since let's face it, it's 3 lines [03:35] Yeah [03:35] And they were broken for a year without anybody noticing. [03:35] So I'm not too concerned. [03:35] I'm not interested in deploying either, given it's effectively the only change. [03:43] StevenK: We can't deploy for a while anyway. [03:43] stub landed some DB user changes that require production changes. [03:44] They're still going through buildbot [03:44] Ah [03:44] Not interested in deploying 3 revisions with one change. [03:44] No :) [03:46] * StevenK stabs gnome-terminal [03:47] StevenK: hey, got a sec? [03:47] rick_h: Sure do [03:47] hey, so I started working on getting the YUI tests back up and linked right away from icing [03:47] and to do that, I think I need the lp js files in the build/js/lp dir like we started out with [03:48] and then just make all tests walk up ../../../build/... [03:48] and then our convoy dir would be a symlink from build/js/lp off to the convoy root instead of building into the convoy root as we do now [03:48] Why would we do that? [03:49] I'm uncomfortable with out-of-tree symlinks [03:49] for a couple of reasons. The YUI code is there now, and I want to keep that so we can swap out YUI versions in tests with a new make command that would swap out a symlink build/js/yui -> 3.3.0/3.4.0 [03:50] and I don't want to build twice, once into build/js/lp and once into $convoy_root/js/lp [03:50] since we do things like min and such [03:51] and if we create a build/js/lp then all the tests can point there and you it provides one place for all the files to be and if they're missed in the build step, the tests will fail [03:51] rick_h: So, we don't currently build the rootdir automatically since it will blow up on qas/staging/prod, so I'm not sure about this plan. [03:51] StevenK: right, so we don't currently build into the convoy dir [03:52] make build is used by too many things currently [03:52] but there's nothing that prevents us from the build/js dir [03:52] rick_h: But we already build into icing [03:52] rick_h: so the way we do it for icing is that the deploy process makes one symlink *into* our tree [03:52] we build a single .js file into icong [03:52] lifeless: and that could still do that right? It would symlink into build/js/lp [03:52] rick_h: there are several symlinks in a farm in the root directory of the icing area on the apache server [03:53] right now, the combo-rootdir places files into a $convoy_root dir but I want them to exist in build [03:53] rick_h: yes, thats my proposal. So the symlinks point *into* our tree [03:53] I don't think convoy follows symlinks [03:53] lifeless: right, that's what I'm trying to change to [03:53] StevenK: well, thats fixable :) [03:53] rick_h: +1 [03:53] StevenK: ah right, I think that was the issue wasn't it. Well maybe I need to take a stab at fixing that then [03:53] But I'm happy to investigate that change [03:54] I'd like this to be as close to icing as possible, given they are so conceptually similar [03:54] less surprises for new folk staring at it [03:54] StevenK: ok, well I wanted to bring it up, see what we thought. Like lifeless says, I'd like the files to exist in our tree for the test purposes and then work out from there [03:54] I don't want the tests knowing about $convoy_root and I'd like the tests to look at the build files in case the build is broken to know at the test level [03:54] So we can populate build/js and then make /var/tmp/convoy be a symlink to that dir [03:55] StevenK: yea, and if convoy doesn't follow symlinks I'll work on fixing that [03:55] I think that'll be closer to what we do now with icing and would be cleanest. [03:55] I'll see about doing that [03:55] ty much [04:10] * StevenK grumbles [04:11] Can't create a yui symlink under build/js since yui is already a directory [04:11] StevenK: I thought there was a new command for installing the alt yui versions and such working [04:13] The yui directory has changed from yui to build/js/yui [04:16] StevenK: yea, that's part of what needs moving because if I want to run all the JS tests from YUI 3.3 to 3.4 then I need to update the seed file on all the tests [04:16] so I want to write the tests to build/js/yui and have a make command to swap that symlink to the "active" yui version running [04:17] Can you deal with build/js/yui/yui ? [04:17] I can give you that easily [04:17] yea, it can be whatever we want [04:17] we just need to figure out what we want and stick with that standard [04:18] but it needs to be coordinated between the make script, the test's seed file, and potentially convoy [04:18] I might change the buildout yui stuff [04:19] that's why I wanted to chat with you on it? :) I'm reading the Make book, but still researching make/buildout [04:20] * StevenK learnt make out of sheer self-defense [04:20] anyway, time for bed here, really appreciate the help and let me know what goes wrong and how I can work on getting it going [04:20] sorry to keep changing things over and over [04:22] And now the icing yui links to the convoy rootdir? [04:22] BAH [04:22] * StevenK shakes his fist at wallyworld_ [04:22] why? [04:23] You can't break icing like that [04:23] icing is served statically on banana/nutmeg and they won't have convoy installed [04:24] I'd prefer icing's js stuff is left entirely alone [04:47] the original build scripts from ages ago put yui stuff in icing [04:48] I'm trying to sort this out, so I can bend build/js to my will [04:50] cool [04:51] wgrant: I can use inplace, since that is the default make target, but qas/s/prod don't call it [05:28] huwshimi: That mockup is sort of along the lines of what I'd been thinking, but I was trying to work out how to distinguish some and all. Possibly all has a border or something. [05:28] Because distinguishing them is reasonably important. [05:30] wgrant: Ah ok. Maybe we can think about colouring each status instead of all being grey. A bit like what Curtis had done for the text, but for the background. [05:31] That's a possibility. [05:31] But it seems like that might make more sense to indicate the policy. [05:31] But I guess that's not so important if we show Nothing. [05:31] I was assuming we'd not show policies with no access. [05:32] wgrant: Yeah, me too [05:32] wgrant: I guess then you'd have to have a "Add policy" button [05:32] Right, there'd probably be an Add/+ link at the right which lets you select a new policy. [05:33] But given that there's probably only three policies, it might be nicer to have them more tabular like this. [05:33] wgrant: Yeah. [05:33] Then it becomes very scannable, particularly if we visually distinguish All and Some. [05:34] wgrant: It might be sensible if the reality is that there are a lot of "nothings" [05:34] There are loooots of nothings. [05:34] wgrant: I might actually mock something up and send it to the list. I don't remember ever hearing why that changed (my original intention had been to hide the nothings) [05:37] wgrant: I guess it would be slightly less scannable though [05:43] wgrant: Also I guess it's slightly less explicit [05:46] wgrant: How often is it that a user/team will have more than one policy? [05:48] huwshimi: Most projects will have either just proprietary or both embargoed security and user data. Some projects will have all three. Of those, project owners will generally have all of the available policies, most other users will only have user data, but the occasional user will probably have both security and user data. [05:49] * StevenK blinks [05:49] Why is os.path.exists(full) returning False? :-( [05:49] StevenK: Note that it follows symlinks. [05:50] wgrant: Ok, so in most cases we're talking about one or two policies being used for the whole project (so there won't be a jumble of all three very often) [05:50] So will return False if the path points at a broken one. [05:50] huwshimi: Right. [05:50] wgrant: Great. [05:50] lrwxrwxrwx 1 steven steven 53 2012-02-02 16:22 /var/tmp/convoy -> /home/steven/launchpad/lp-branches/combo-url/build/js [05:50] That looks fine to me [05:56] [Thu Feb 02 16:55:41 2012] [error] [client 127.0.0.1] IOError: [Errno 13] Permission denied: '/var/tmp/convoy/yui/yui/yui-min.js' [05:56] Hm, the plot thins [05:59] Hmm, /var/tmp is 1777, so perhaps you can only cd if the owner matches [06:00] Which sounds likely [06:00] Since root can't cd either [06:02] huwshimi: I think the scannability may recover if each policy type gets a colour. [06:02] As lots of sites do with tags nowadays. [06:03] wgrant: I guess you could still do a lighter/darker shade of that colour to show "some" or "all" [06:03] Exactly. [06:09] StevenK: why ~/launchpad/lp-branches/combo-url? is that local or on prod? [06:09] i'd think we'd want it to point to somewhere in the tree [06:12] That is the tree! [06:12] not the tree where the lp source code is checked out to [06:13] ie why not somewhere under lp-branches/my-lp-checkout/... [06:13] Because I use seperate directories per branch [06:14] :-( [06:14] that's even more reason to put it under the proper source tree [06:14] so different branches have their own copy [06:15] It is in the source tree! [06:15] That's the point of the build/js at the end [06:15] The symlink is so I don't have to rewrite /usr/share/convoy/convoy.wsgi and reload apache everytime the branch changes [06:15] so if your working tree for launchpad is lp-branches/my-lp-sandbox, how is lp-branches/combo-url in the launchpad working tree? [06:16] What? You've lost me [06:17] so the lp source code is checked out to lp-branches/some-working-dir [06:17] and under there is lib/lp etc etc ie all the lp source [06:17] so i would expect all build artifacts for that checkout to be located under that source dir [06:17] not a level above [06:18] wallyworld_: http://pastebin.ubuntu.com/826045/ [06:19] StevenK: oh, that is the name of a branch [06:19] i thought it was just a directory where stuff got built into [06:19] Yes! [06:20] sorry, misunderstanding === almaisan-away is now known as al-maisan [07:50] anyone up for a small revu ? [08:25] * lifeless makes a note to ring telecom tomorrow and complain about shocking performance occuring again [08:46] I'd like to submit a really small fix and wonder if a change to lib/lp/testing/_login.py should be accompanied by unit tests? [08:47] http://paste.ubuntu.com/826108/ is what I'd like to do btw since that would have let me know about trying to use the wrong function. [08:55] good morning [09:25] * wgrant declares victory over triggers. [09:25] wgrant: Oh, so you didn't win, you're just declaring victory? [09:26] I think I've ironed out the last bugs. [09:26] And they're not too slow. [09:26] And they seem to do the right thing. [09:26] (mapping legacy bug disclosure onto modern disclosure, and keeping it up to date across task/subscription/bug transitions and removals. [09:37] wgrant: Can't we just unilaterally move the legacy stuff to modern terms? [09:38] StevenK: Not in 20 seconds, no. [09:39] wgrant: Hmm. And I guess a garbo job won't help? [09:39] StevenK: The source data changes constantly. [09:39] And we need to have it consistent eventually so we can flip the switch. [09:40] The switch will tell the appservers to update the new schema instead, and tell the triggers to stop mirroring. [09:41] (although some of the triggers will remain forever, the really ugly bits are only for the migration) [09:42] wgrant: question, i have a test failure where it says httplib.HTTPSConnection does not exist, yet from the command line i can dir(httplib) and see that class is there. any ideas? [09:43] wallyworld_: Hm, it exists in both 2.6 and 2.7. [09:44] yes, hence mu confusion, although this error is in a canonistack instance [09:44] running oneiric [09:45] i've hand crafted some scripts to set up the instance, based on those used for aws. only a few test failures so far [10:00] wallyworld_: Some scripts, or changes to lib/devscripts/ec2test? [10:01] StevenK: some hand crafted python scripts to set up the instance and prepare launchpad, based on what's in devscripts [10:02] StevenK: so far, about 1/2 way through, 3 test failures due to httplib.HTTPSConnection not being found, plus [10:02] the only 2 other failures so far - one of them has output that includes a SHA512 checksum, causing the assert equals to fail https://pastebin.canonical.com/59271/ [10:02] so i'm not too disappointed for a first attempt [10:08] wallyworld_: Nice. So perhaps the next step is to integrate your scripts into devscripts? [10:19] StevenK: that is the plan - there's a cloud instance object that i'm thinking about factoring out and making pluggable, depending on whether --aws or --canonistack is specified [10:32] wallyworld_: Hmmmm. I'd prefer it try canonistack first and fall back if there is no credientals or it can't start an instance. [10:33] StevenK: details, details :-) i was merely talking generally [10:33] the test run just blew up with an out of memory error, so need to arrange for a bigger instance [10:34] You can specify the size when you start it [10:35] * wallyworld_ goes to find doco [10:35] Perhaps you should find a lack of work :-P [10:36] wallyworld_: You may need to ask IS about which sizes are configured, too [10:36] yeah, might call time for today. but you can't be too critical yourself :-P [10:36] i've been talking to andrew who has been most helpful [10:36] I'm waiting for Steam to install a game, so speak for yourself. :-P [10:38] wallyworld_: Is this on the private LP canonistack? [10:38] Or the main canonistack? [10:38] wgrant: i have no idea tbh [10:38] perhaps the private one if i had to guess [10:50] Anyone recall if there is a reason we are still using psycopg2 2.2.2? [10:56] Nope... that's not it. Seems we or Storm are breaking string quoting [10:57] >>> c.execute("SELECT %s", ("Hello\nMom",)) [10:57] >>> c.fetchone()[0] [10:57] 'Hello\\nMom' [10:57] stub: I thought it was psycopg2 that was the problem. [10:57] Sure you upgraded the right one? [10:58] With raw psyocpg2 [10:58] >>> cur.execute("SELECT %s", ("Raw\nPsycopg2",)) [10:58] >>> cur.fetchone()[0] [10:58] 'Raw\nPsycopg2' [10:59] Works. Thought it was I had 2.4.2 installed and lp was using 2.2.2. Upgraded lp and still happening. Suspect a dodgy Storm decision in the past. [10:59] Sure you reran buildout etc. sufficiently? [10:59] Or maybe we broke it for some reason [11:00] Yes... psycopg2.__version__ reports what I expect [11:00] :( [11:03] Hmm... [11:04] So 'make harness', 'from lp.services.database.sqlbase import cursor' gives the bug [11:04] But 'make harness', 'import psycopg2; connect; cur=con.connect' etc. works [11:04] And then the cursor() helper in sqlbase gives the right answers [11:05] Huh [11:06] nah... mixed up my cursors. [11:07] raw psycopg2 works in make harness, cursors returned through that helper are busted. [11:08] Yay. Think I'm about to wade through connection and cursor wrappers... [11:08] :D [11:09] It's a bit of an awful mess. [11:09] oic. The 'cursor' does its own interpolation for some reason, using sqlvalues. And sqlvalues won't know about the stricter quoting I want. [11:09] Heh [11:09] And fixing sqlvalues should fix gobs [11:11] I guess we do that so we get sane statement logs containing interpolated values [11:18] And the root quoting is done by... sqlobject.sqlbuilder.sqlrepr [11:18] Which is Storm :) [11:28] Nope... looks like us in lib/sqlobject.py [11:28] Huh [11:28] Indeed [11:28] WTF is that still there [11:28] circa 2007 [11:28] * stub puts on his fedora [11:28] I thought lib/sqlobject was just importing stuff from Storm :/ [11:30] I have a feeling fixing that to do strict E quoting is going to have a lot of doctest fallout... [11:30] We'll find out soon :) [11:31] I could still chicken out and leave it 'for later' [11:47] morning === al-maisan is now known as almaisan-away [12:32] wallyworld_: heads up, relanding the LPJS stuff so hopefully will be merged when you get going again [13:15] I just proposed a tiny change and I haven't really pestered anyone to review it earlier. :) would anyone want to have a look at this? https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265 === rick_h changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h* | Firefighting: - | Critical bugtasks: 4*10^2 [13:18] mabac: is this in response to a bug? Isn't there already email validation? [13:20] rick_h, I didn't file a bug (yet). this function gives me confusing zope errors when I passed a Person to it by mistake. I figured that it might help someone else to debug tests if it would give a better error. [13:20] rick_h, it's not related to production code btw, it's in testing/ [13:26] mabac: do you know off hand what a "participation" is? [13:26] mabac: the docstring there suggests you can pass an email, a const, and a participation [13:27] mabac: and it appears the participation can implement IPublicationRequest so that would be some object that would fail your str test [13:28] bah, too early in the morning [13:28] that's a second param [13:28] sorry mabac, sending you in wrong circles this morning [13:28] rick_h, thanks, that saved me some typing ;) [13:29] rick_h, no problem [13:29] so the only concern is what the ANONYMOUS constant is, and it appears that's set to a string as well [13:29] rick_h, yup, I think that constant is used as if it would be an email address [13:30] rick_h, seems to be mostly (only?) used in calls to this function [13:30] rick_h, rather these login* functions [13:31] mabac, rick_h, we can't use 'str' there because most callsites are actually passing in unicode. so basestring, maybe? [13:31] argh, good catch salgado. thanks [13:32] salgado: sounds like a good plan [13:32] a full test run, for those who can afford it, would've caught that as well, though :) [13:33] salgado: yea, definitely, but still nice to get it before several hours of ec2'ing [13:33] rick_h, salgado I'll fix that and try to survive running the tests locally again ;) [13:34] mabac: so noted in the MP, let me know when the change is up and I'll ok and pass it to my mentor [13:34] rick_h, will do. thanks for you time! [14:27] rick_h, I've pushed a new revision https://code.launchpad.net/~mabac/launchpad/login-raises-non-string/+merge/91265 [14:28] mabac: ok, looks good thanks === jcsackett changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: rick_h*, jcsackett | Firefighting: - | Critical bugtasks: 4*10^2 [14:46] abentley: yea, that wiki update looks good to me. Thanks! [14:46] rick_h: cool. === matsubara is now known as matsubara-lunch === salgado is now known as salgado-lunch [16:02] Is there any sort of status on bug #881019? This is causing problems with Summit where users aren't able to retrieve their schedules and could cause them to miss private business meetings that they can only see if they are logged in properly. [16:02] <_mup_> Bug #881019: Lp login is broken after account merge < https://launchpad.net/bugs/881019 > [16:20] cjohnston, We are not working on it really.The current understanding is that the issue with offsite systems misunderstanding how OpenId works and that Lp supports multiple identifiers [16:21] cjohnston, You should comment on the bug to provide information about what is broken for the summit site [16:21] sinzui: ty === salgado-lunch is now known as salgado [16:30] rick_h: fancy a review? https://code.launchpad.net/~adeuring/launchpad/bug-829074/+merge/91302 [16:31] adeuring: sure thing [16:31] thanks === matsubara-lunch is now known as matsubara [16:59] does it really take ages to run 'make newsampledata'? [17:16] 30 minutes at 100% CPU and counting [17:18] well sampledata needs to diaf [17:18] salgado: you're not adding sample data are you ? [17:18] jcsackett: ola! - https://code.launchpad.net/~lifeless/loggerhead/bug-594591/+merge/91212 [17:19] salgado: (but 30 minutes is 5-6 times too long) [17:20] lifeless, I am! (I probably won't commit it but I did newsampledata just so that I can restore my sampledata changes after a make schema) [17:20] maybe there's an easier way to do that? [17:24] lifeless, while I have your attention... I'm working on a script to migrate work items from the whiteboard of blueprints into a separate table. it uses a fresh transaction for every BP because it rolls back if anything goes wrong. is it worth using DBLoopTuner for that (also, we're talking about 2500 BPs that have work-items on their whiteboard) [17:27] salgado: (I hate my internets) [17:28] salgado: so, sampledata is officially reviled; the current practice is to use the factory to add test data [17:28] salgado: and do it per test [17:28] salgado: if you need the same exact test data in a number of tests, wrap it in a Fixture [17:28] lifeless, I know that; I once gave a talk on why sampledata was bad ;) [17:29] and that's why we now have two sets of sampledata [17:30] righto :) [17:30] * lifeless wasn't sure how much you'd forgotten over in the land of django [17:30] I'm only changing the -dev sampledata, and even then I probably won't submit those changes [17:31] whew ;> [17:31] it has the ~2500 BPs from production that have work-items on their whiteboard, and I'm testing my new script against that [17:32] and I wanted to restore those after a make schema, but I can probably avoid a make schema or dump just the one table I care about [17:32] but anyway, I have one important question for you... :) [17:32] lifeless, while I have your attention... I'm working on a script to migrate work items from the whiteboard of blueprints into a separate table. it uses a fresh transaction for every BP because it rolls back if anything goes wrong. is it worth using DBLoopTuner for that (also, we're talking about 2500 BPs that have work-items on their whiteboard) [17:33] yes [17:33] dblooptuner is trivial and solves plenty of issues ;) [17:33] shove it in the garbo hourly [17:34] if there is no native way to show 'BP x was done' you can use memcache to store the highest migrated whiteboard (o [17:35] oh, but we I don't think we want that as a cronjob... we should run it just once [17:35] salgado: so, you could manually arrange it [17:35] but garbo means no sysadmin intervention [17:35] you add it, watch the logs, remove it all without having to ask a single question [17:36] and it shouldn't hurt to run it a few extra times, so maybe that's a good idea [17:39] we need a data migration specific helper I think [17:39] one that will ignore cluster lag, has a dedicated storage area for point-migrated-to [17:39] yeah, that'd be nice [17:39] but this is orthogonal to using it or not, just would make it easier to do each time [17:50] lifeless: where's that thing you wrote about what to do instead of using an ORM? [17:52] I can see https://dev.launchpad.net/LEP/PersistenceLayer, but ISTR something with implementation notes [17:52] adeuring: man, you know how to build a MP phew [17:52] rick_h: how dow mean ;) [17:53] brain melted I think [17:53] jml: you might mean two things [17:53] sorry... let me know if I can help to up the mess# [17:53] jml: do you mean having the template service depeend wholly on services [17:54] lifeless: no, I think I mean the other thing [17:54] jml: or do you mean a rethink of how appservers that do both data access and business logic would get at their data? [17:54] lifeless: that one [17:54] I think that LEP is what there is [17:54] hmm. [17:54] there was a list thread with science fiction in it [17:54] I'm sure I remember you & wallyworld talking more about it [17:54] maybe the list thread is it [17:54] * jml looks [17:55] jcsackett: hi [17:59] lifeless: thanks. [18:01] jml: you founds it ? [18:02] lifeless: hi. [18:02] jcsackett: still reviewing ? [18:02] lifeless: all day. :-) [18:02] jcsackett: oh, nvm, jam got to it [18:02] * lifeless fishslaps himself [18:03] lifeless: righto. :-) [18:03] you have a fish that near at hand? that's useful. :-P [18:03] lifeless: yeah, over a couple of threads. [18:03] no comment :P [18:03] lifeless: think my head was conflating some of the code snippets from the API thing that Foundations was doing at roughly the same time [18:04] yeah, some similarities [18:04] lifeless: the "Simple made easy" talk has had me thinking about what I would want to use instead of ORMs [18:04] aiming at similar sorts of overheads [18:04] jml: cool [18:04] e.g. scala? :) [18:04] lifeless: well, Hickey would say Clojure, I think. [18:05] lifeless: mostly I'm thinking about stuff within Python for now. [18:05] lifeless: since most of my output needs to be deployed to Canonical DC [18:06] and I'm disappointed with Go not having Haskell-like type classes. (I blame niemeyer for raising my hopes) [18:07]