| Pseudonym | Anyway. | 00:00 |
|---|---|---|
| Pseudonym | So there are all these interesting synchronisation models coming up at the moment. | 00:00 |
| Pseudonym | Anyway, Tom and I have worked out a way to implement B-trees in a way that uses these transactions. | 00:00 |
| Pseudonym | And, as a bonus, we've incorporated various methods (not discovered by us) to avoid the difficult cases. | 00:01 |
| Pseudonym | So what we've got is a B-tree which uses no locking, is simple to implement, and also supports high concurrency. (We think.) | 00:01 |
| Pseudonym | That seems like a good thing to write up. | 00:02 |
| Pseudonym | I probably lost you somewhere along the way. Sorry about that. :-) | 00:04 |
| Pseudonym | The way we avoid the difficult cases, by the way... | 00:05 |
| Pseudonym | OK, let me back up a bit. | 00:05 |
| Pseudonym | I'm sure you've gone through balanced binary search trees, right? Like AVL trees? Splay trees, maybe? | 00:05 |
| cgTobi | not too extensively, we did just basic stuff | 00:07 |
| Pseudonym | Right. | 00:08 |
| Pseudonym | That's good, actually. :-) | 00:08 |
| Pseudonym | Because the only real reason why you rebalance binary search trees is to avoid the worst-case behaviour. | 00:08 |
| Pseudonym | You know that if you insert [1, 2, 3, 4, 5..] into a binary search tree without balancing it, you get a very bad data structure. | 00:10 |
| Pseudonym | It's a linked list, pretty much. | 00:10 |
| Pseudonym | So you balance it to avoid that behaviour. | 00:10 |
| Pseudonym | Given that, any balance method (AVL, whatever) is as good as any other. | 00:11 |
| Pseudonym | And in particular, you can tolerate a bit of unbalancing so long as it gets fixed before it does any damage. | 00:11 |
| Pseudonym | So what we do is allow the B-tree to get unbalanced, but record somewhere that this node is unbalanced. | 00:11 |
| Pseudonym | Then you have another thread which comes along and fixes that up. | 00:12 |
| Pseudonym | And fixing a node may result in the parent node becoming unbalanced. | 00:12 |
| Pseudonym | So you record that, and the thread will eventually fix that, too. | 00:12 |
| Pseudonym | This avoids all the tricky cases (where you need to rebalance "up" several stages) by making all modifications local. | 00:13 |
| Pseudonym | You only ever deal with one node at a time. | 00:13 |
| Pseudonym | Which makes it friendly for this transactional threading model. | 00:13 |
| *** render has quit IRC | 01:05 | |
| *** Pseudonym has quit IRC | 01:18 | |
| *** Pseudonym has joined #Aqsis | 01:18 | |
| *** cgTobi sets mode: +v Pseudonym | 01:19 | |
| cgTobi | wb :) | 01:19 |
| Pseudonym | Thanks. | 01:20 |
| *** [1]ShortWave has quit IRC | 02:23 | |
| *** ShortWave has quit IRC | 02:32 | |
| *** ShortWave has joined #aqsis | 02:32 | |
| *** [1]ShortWave has joined #aqsis | 02:33 | |
| *** scorp007 has joined #aqsis | 02:36 | |
| *** cgTobi sets mode: +vvv [1]ShortWave scorp007 ShortWave | 02:45 | |
| *** scorp007 has quit IRC | 03:27 | |
| *** cgTobi has quit IRC | 04:03 | |
| *** cgTobi has joined #Aqsis | 04:09 | |
| *** ChanServ sets mode: +o cgTobi | 04:09 | |
| *** AlexK has joined #aqsis | 06:15 | |
| *** Pseudonym has quit IRC | 06:31 | |
| *** AlexK has quit IRC | 07:26 | |
| *** pgregory has joined #aqsis | 08:01 | |
| cgTobi | morning Paul | 08:01 |
| *** ChanServ sets mode: +o pgregory | 08:01 | |
| pgregory | morning all | 08:02 |
| *** AlexK has joined #aqsis | 08:02 | |
| *** pgregory sets mode: +v AlexK | 08:02 | |
| pgregory | anyone around? | 08:07 |
| cgTobi | If I count as 'anyone' :) | 08:09 |
| *** scorp007 has joined #aqsis | 08:13 | |
| *** pgregory sets mode: +v scorp007 | 08:13 | |
| pgregory | morning scorp007 | 08:13 |
| scorp007 | hi | 08:13 |
| scorp007 | I made a little summary earlier in the day about issues with teqser | 08:15 |
| pgregory | care to share? | 08:15 |
| scorp007 | in the forums | 08:15 |
| pgregory | I have virtually no access at the moment | 08:15 |
| scorp007 | why so? No web browser? | 08:15 |
| pgregory | internet only, from a text shell | 08:15 |
| scorp007 | got lynx? | 08:15 |
| pgregory | not yet, I've asked Tobi to find the URL for me so that I can wget it. | 08:16 |
| pgregory | I need the rpm for RHEL4 | 08:16 |
| scorp007 | I suggest elinks instead, though | 08:16 |
| scorp007 | newer and easier to use | 08:16 |
| pgregory | aha, that seems to be installed, cheers | 08:16 |
| scorp007 | no problem | 08:16 |
| scorp007 | you will see the importance of designing a compliant site, after using a text browser. And elinks is quite forgiving. | 08:17 |
| scorp007 | ah, but I guess you cant view images, unfortunately. | 08:19 |
| scorp007 | what would happen if i call RiBegin, and return out of the function before I call RiEnd? | 08:26 |
| pgregory | scorp007: If you then try to run RiBegin again, you should get an error. | 08:31 |
| scorp007 | ok | 08:31 |
| scorp007 | and if I dont? | 08:31 |
| pgregory | if you're going to exit straight away, then probably nothing. | 08:31 |
| scorp007 | will there be memory leaks? | 08:31 |
| pgregory | it'll just leave lots of stuff around until you exit. | 08:31 |
| scorp007 | ok | 08:31 |
| scorp007 | so did you see my thread? | 08:38 |
| pgregory | sort of, it's difficult to read in 80x40, but I got the gist. | 08:42 |
| pgregory | I'll need to see the images | 08:42 |
| pgregory | thanks for taking the time to analyse the problem further. | 08:43 |
| pgregory | the more information we have, the better the chance of finding the fault. | 08:43 |
| scorp007 | haha, yeah, all those tables make it bad for a terminal | 08:43 |
| scorp007 | no problem, I'd love to see aqsis get as good as 3delight | 08:43 |
| scorp007 | the only thing that slows 3delight is its license manager | 08:43 |
| *** cgTobi has quit IRC | 08:46 | |
| scorp007 | with my rather unoptimized exporter, I just rendered 10.2 millions faces in 10,000 objects directly from max, in 2:26 minutes. | 08:54 |
| scorp007 | I'll save the picture | 08:54 |
| pgregory | scorp007: rendered in what? | 08:58 |
| scorp007 | 3DL | 08:58 |
| scorp007 | for anyone with an image viewer, http://img218.imageshack.us/img218/2702/maxtor10milgw6.jpg | 09:04 |
| *** Aren has joined #aqsis | 09:09 | |
| *** Aren has quit IRC | 09:10 | |
| *** Aren has joined #aqsis | 09:15 | |
| scorp007 | is there any way you can make a display driver tell the renderer to abort? | 09:44 |
| scorp007 | I have a better image, this time 1920x1080 pix, and catmull-rom, instead of ugly box. 7:25 mins to render | 09:48 |
| scorp007 | (including my exporting) | 09:49 |
| *** pgregory has left #aqsis | 09:49 | |
| *** pgregory has joined #aqsis | 09:53 | |
| *** ChanServ sets mode: +o pgregory | 09:54 | |
| pgregory | back | 09:54 |
| scorp007 | did you get any of my previous messages? | 09:54 |
| pgregory | nope | 09:54 |
| scorp007 | [19:05] <scorp007> for anyone with an image viewer, http://img218.imageshack.us/img218/2702/maxtor10milgw6.jpg | 09:54 |
| scorp007 | [19:11] * Aren has joined #aqsis | 09:54 |
| scorp007 | [19:11] * Aren has quit IRC (Client Quit) | 09:54 |
| scorp007 | [19:16] * Aren has joined #aqsis | 09:54 |
| scorp007 | [19:45] <scorp007> is there any way you can make a display driver tell the renderer to abort? | 09:54 |
| scorp007 | [19:50] <scorp007> I have a better image, this time 1920x1080 pix, and catmull-rom, instead of ugly box. 7:25 mins to render | 09:54 |
| scorp007 | [19:50] <scorp007> (including my exporting) | 09:54 |
| Aren | ? | 09:55 |
| Aren | why was i pasted? | 09:55 |
| Aren | ohh i see | 09:55 |
| scorp007 | sorry, I just copied it all at once | 09:55 |
| Aren | not a problem | 09:55 |
| pgregory | scorp007: no, there is currently no way for the display to abort a render. | 09:56 |
| scorp007 | damn | 09:56 |
| scorp007 | is that a limitation of the renderman display spec? | 09:56 |
| pgregory | yes | 09:57 |
| scorp007 | damn.. I wonder how 3delight does it | 09:57 |
| pgregory | they have a custom communications channel back to the renderer. | 09:57 |
| scorp007 | I see | 09:57 |
| *** cgTobi has joined #Aqsis | 09:58 | |
| *** ChanServ sets mode: +o cgTobi | 09:58 | |
| *** cgTobi sets mode: +v Aren | 09:59 | |
| cgTobi | howdy folks | 09:59 |
| scorp007 | hi | 10:01 |
| *** AlexK has quit IRC | 10:06 | |
| *** renderguy has joined #aqsis | 10:12 | |
| renderguy | Morning all | 10:12 |
| scorp007 | hi | 10:12 |
| renderguy | scorp007: Seems you're making good progress on your Max exporter, congrats. | 10:13 |
| scorp007 | thanks :) did you see the picture> | 10:14 |
| scorp007 | ? | 10:15 |
| renderguy | scorp007: Yep... you 'Teapot' freak. ;-) | 10:19 |
| scorp007 | For the interested, or not, here's a summary and some (new) pictures: http://forums.cgsociety.org/showthread.php?f=6&t=469087 | 10:19 |
| scorp007 | renderguy, hehe | 10:19 |
| *** Anteru has joined #aqsis | 11:01 | |
| Anteru | Hi! | 11:02 |
| scorp007 | hi | 11:06 |
| *** scorp007 has quit IRC | 11:21 | |
| *** Anteru has quit IRC | 11:32 | |
| *** render has joined #aqsis | 11:39 | |
| *** cgTobi sets mode: +vv render renderguy | 11:45 | |
| *** cgTobi has quit IRC | 12:26 | |
| tcolgate | mornin' all | 12:49 |
| pgregory | morning Minty | 12:52 |
| tcolgate | hey | 12:52 |
| tcolgate | I managed to do my ankle in last night, was rushing to get to Tesco before it closed (and after the pub :( ). | 12:52 |
| pgregory | oops | 12:53 |
| tcolgate | I've taken a sicky today and will probably be working from home tomorrow. | 12:53 |
| tcolgate | I'm going to hobble into the shower then get started on one of my aqsis todo ites. Probably the Attribs thing. | 12:59 |
| tcolgate | Incidentally, were you happy with the fix for the shadervm leak? I can't help thinking that if it was that simple MJ or I should have spotted it when we were both pounding away at it a while ago. | 13:00 |
| tcolgate | But then again, it loks sensible enough, I'll re run some atmosphere shader tests and some valgrind stuff if I get the chance and see how we are doing. | 13:00 |
| pgregory | need to look into it properly, haven't had a chance yet. | 13:01 |
| tcolgate | It just looks to easy from the patch. But if we haven't had any regressions since then I guess it is OK, maybe. | 13:01 |
| pgregory | I'm more interested at the moment in why the texture mipmapping is behaving so strangely | 13:05 |
| tcolgate | I've not looked at that forum posting yet, I noticed someone on IRC moaning about trqser having somme odd behaviour, that can't have changed in a long time though. | 13:06 |
| *** Aren has quit IRC | 13:08 | |
| tcolgate | hmm, done tiffinfo concurr with his inding about the number of pages etc? | 13:09 |
| pgregory | good question | 13:09 |
| pgregory | hold on... | 13:09 |
| *** ShortWave has quit IRC | 13:13 | |
| *** [1]ShortWave is now known as ShortWave | 13:13 | |
| *** c42f has joined #aqsis | 13:13 | |
| c42f | Hi guys | 13:14 |
| *** [1]ShortWave has joined #aqsis | 13:14 | |
| pgregory | hi Chris | 13:14 |
| *** pgregory sets mode: +vv c42f [1]ShortWave | 13:14 | |
| c42f | tcolgate: Just read the logs & saw your question about the shadervm patch: good. The more eyes the better. | 13:15 |
| c42f | tcolgate: I've checked with valgrind before & after the patch; the memory leak definitley goes away here. | 13:16 |
| c42f | I also was surprised that I hadn't seen the problem earlier though. It seems rather simple in hindsight... | 13:17 |
| pgregory | that's not a surprise to me at all | 13:17 |
| pgregory | the VM is fairly complex, it only takes a simple error like that to turn it on it's head. | 13:17 |
| pgregory | yes, tiffinfo concurs with the findings. | 13:18 |
| tcolgate | sorry, got knocked off my connection. | 13:19 |
| tcolgate | paul: yes, in my abscense I tried a test with gimp->teqser and I see it too. | 13:19 |
| tcolgate | chris: I spent alot of time hammering on that issue using some atmosphere shaders to test with and valgrind, so it's quite irritating that I didn't spot it if it is a genuine fix :) | 13:21 |
| pgregory | hmmm | 13:21 |
| tcolgate | My only concern is around the reference counting. | 13:21 |
| pgregory | I think I see what might be wrong with the mipmap generation. | 13:21 |
| tcolgate | ? | 13:21 |
| pgregory | it appears that we are generating each level from the initial image. | 13:22 |
| pgregory | not sure if that's right. | 13:22 |
| tcolgate | right, and it should be done by reerence to the prevous? | 13:22 |
| pgregory | I need to have a think about this, but my gut feeling is we should generate level n from level n-1. | 13:22 |
| pgregory | or then again, maybe not.. | 13:24 |
| *** AlexK has joined #aqsis | 13:24 | |
| c42f | that would seem to be most efficient... In effect you're getting a much wider filter 'for free' | 13:24 |
| * c42f doesn't know anything much about texture filtering though. | 13:25 | |
| tcolgate | ahh cool, handy hint for those on linux... | 13:26 |
| tcolgate | tiff2pdf handles multi page tiffs, seem to work well for viewing tx files. | 13:26 |
| tcolgate | right, I'm getting into the shower... | 13:26 |
| c42f | oh, cool, thanks for the tip. | 13:26 |
| c42f | tristan: which piece of reference counting were you worried about? | 13:27 |
| tcolgate | chris: nothing specific as I haven't looked at the patch in context, but my gut feeling was that if I was going to be worried about anything it would be whether that temp needed to be kept around. | 13:29 |
| *** cgTobi has joined #Aqsis | 13:29 | |
| *** ChanServ sets mode: +o cgTobi | 13:29 | |
| tcolgate | As I say, purely on gut instint, I've had my battles with the VM before, it's never fun. | 13:29 |
| tcolgate | back in a bit. | 13:29 |
| pgregory | aha | 13:36 |
| c42f | ? | 13:36 |
| cgTobi | hey all | 13:36 |
| c42f | hi Tobi | 13:36 |
| cgTobi | hi Chris, good evening | 13:36 |
| pgregory | the problem is, we *should* be downsampling the zero image, that much is correct, but, for each subsequent level, we should double the filterwidth | 13:36 |
| pgregory | the reason we need to downsample from the original is that filters other than box aren't constant over width | 13:37 |
| pgregory | and the reason we're getting wrong levels is due to the logic that calculates the stopping point. | 13:38 |
| pgregory | I think | 13:38 |
| c42f | Cool! Sounds very reasonable :) | 13:38 |
| pgregory | it makes sense to me when I try to visualise the filtering process in my (aching) head. | 13:39 |
| c42f | I can see what you mean about filters other than box. Sampling the smaller images wouldn't necessasarily give the same thing if the filter was constant for each level. | 13:41 |
| cgTobi | ok guys, I need some sleep, shift starts in 9 hours | 13:45 |
| cgTobi | cya | 13:45 |
| c42f | bye Tobi. | 13:45 |
| c42f | renderguy: did you get my patch for the irc logs script? | 13:47 |
| pgregory | hmm, looks like we might already be increasing the width, in which case, something else is wrong :-( | 13:47 |
| pgregory | actually no, the filtering code is rubbish. | 13:51 |
| *** cgTobi has quit IRC | 13:54 | |
| *** Joron has joined #Aqsis | 13:55 | |
| c42f | Hi MJ | 13:57 |
| renderguy | c42f: Yep, got your patch (thanks), but was busy yesterday and today... probably won't get to do anything till tomorrow. | 13:58 |
| renderguy | c42f: I'll give you a shout if I get stuck. ;-) | 13:58 |
| renderguy | Joron: Morning... just in time. ;-) | 13:58 |
| Joron | Hello | 13:59 |
| Joron | Ok Yestersday I look for the generation of the mipmap; well it could be fixed in particular we could look a bit closer the result and compared with other renderer. But the rendering part has a problem for an imager shader I get different of mipmap level from left to right this one causes visual artifacts. A good example is Bug1031110.rib; | 14:02 |
| Joron | you could perceive the image is not right if you compare the amount of blur on the left side versus the right side of the image. | 14:02 |
| Joron | look "gra" versus "yscale image..." | 14:03 |
| Joron | I'm still investigated both issue the mipmap generate and the rendering. | 14:04 |
| pgregory | Joron: I'm looking at the mipmap as well at the moment | 14:05 |
| c42f | renderguy: np & thanks. | 14:09 |
| tcolgate | paul: just an observation, but I did a test with a diagonal gradiant image from gimp. There are some filtering artefacts, which may well be perfectly normal, an evenly sized pale grid across the image. | 14:11 |
| tcolgate | But.. | 14:11 |
| tcolgate | The grid seems to be the same number of pixels across for each of the smaller images, so it doesn't scale with the size of the image. | 14:11 |
| Joron | I got a better mipmap generation; I could commit the changes therefore more eyes could look for the other issue ? | 14:13 |
| pgregory | Joron: before you commit, can you explain what you did, and why? | 14:14 |
| tcolgate | Joron: Might be a good idea to mail a patch file to the list. | 14:14 |
| Joron | I revert the mipmap generation to an earlier version; because the way the width was compute since to be prone to rouding errors. | 14:14 |
| pgregory | ok, commit and I'll take a look | 14:15 |
| Joron | I could send my texturemap.cpp to Paul. | 14:15 |
| pgregory | that might be a good idea | 14:15 |
| Joron | I will e-mail it. | 14:15 |
| pgregory | save polluting subversion until we're sure it makes sense | 14:15 |
| Joron | agree | 14:15 |
| tcolgate | for what it is worth, svn diff generates a perfectly decent looking patch file. | 14:17 |
| Joron | sent | 14:18 |
| pgregory | gmail is being a pain at the moment | 14:21 |
| Joron | I sent to pgregory@aqsis.org ? | 14:23 |
| Joron | is it ok ? | 14:23 |
| pgregory | yep, gottit | 14:28 |
| Joron | one clue is CalculateLevel() might be wrong (in texturemap.cpp) since for the bug1031...rib which should have used the same level of mipmap across the rendering... it returns 0 and 1 in some cases. No sure if CalculateLevel() is wrong or the parameters we pass to it lead to the wrong computation. | 14:30 |
| Joron | evaluate, test the mipmap generation I will continue on my end the investigation for the level of mipmap aqsis employs. | 14:31 |
| Joron | bye bye | 14:31 |
| *** Joron has quit IRC | 14:32 | |
| *** c42f has quit IRC | 15:05 | |
| tcolgate | paul: I'm having some diificulties with my C++ thinking, any chance you can give me some pointers? (Not the C kind :) ) | 16:16 |
| tcolgate | I've added my new interfaces for pulling the attribs by an ID to attributes.h, but it seems that I need to add it to the iattributes.h interface aswell, which makes some sense, but... | 16:21 |
| tcolgate | putting the enum in iattributes.h doesn't seem right to me. | 16:22 |
| tcolgate | should I put an int based interfaces in and just cast my enums to ints when I call the functions instead? | 16:22 |
| tcolgate | Hm, given that they are going to be an index into a vector I suppose that owuld be OK. | 16:28 |
| *** AlexK has quit IRC | 16:39 | |
| tcolgate | well I've got the interface building anyway, but need to put something on the back end of it now :) | 16:46 |
| * renderguy is counting the minutes till he leaves. | 17:09 | |
| renderguy | 5... 4... 3... 2... 1... I'm outta here, laterz. | 17:27 |
| *** renderguy has left #aqsis | 17:27 | |
| tcolgate | Gregory:!!!!! Please spell Colour for me!!! How did I not notice this before!!! | 17:35 |
| tcolgate | Any C++ types around? | 18:45 |
| *** render has quit IRC | 18:51 | |
| ShortWave | http://www.celtx.com/features.html | 19:36 |
| *** AlexK has joined #aqsis | 19:50 | |
| tcolgate | Shortwave: Sounds great, have you tried it? | 20:14 |
| *** Aren has joined #aqsis | 20:18 | |
| *** pgregory_ has joined #aqsis | 20:28 | |
| tcolgate | Hey | 20:29 |
| *** pgregory has quit IRC | 20:32 | |
| *** pgregory has joined #aqsis | 20:32 | |
| *** ChanServ sets mode: +o pgregory | 20:32 | |
| *** pgregory sets mode: +vv AlexK Aren | 20:33 | |
| tcolgate | hey | 20:34 |
| pgregory | hi Minty, how's the ankle? | 20:34 |
| tcolgate | cool, as long as I don't walk or stand up :) | 20:35 |
| tcolgate | I'e made some preogress on the attribs stuff, I think it's looking alright in theory anyway. | 20:35 |
| pgregory | excellent | 20:36 |
| tcolgate | Might need some pointer on the shared pointer aspect and the copy on write side of things, but the code kind of feels right if that makes snese. | 20:36 |
| pgregory | I'm just about to tackle the mipmap filtering. | 20:36 |
| tcolgate | can I send you a patch? I was going to create a branch but the code doesn't actually work at all yet. | 20:36 |
| tcolgate | The diff might give you a sense of what I've been on about. | 20:37 |
| pgregory | email it, and I'll take a look, do you specifically want me to look tonight? | 20:37 |
| pgregory | I have some time if you do, it's not a problem. | 20:37 |
| tcolgate | If you could have a glance and tell me if I'm mad then that would be handy. | 20:37 |
| tcolgate | It doesn't need a great deal of analysis, just an umm or an ahhh | 20:38 |
| pgregory | sure | 20:38 |
| tcolgate | OK, should be on its way. | 20:39 |
| tcolgate | ingnore the spec file bit :) | 20:40 |
| tcolgate | I've not hooked it into the actual code yet, but it should give you the principle of the thing. | 20:40 |
| pgregory | ok | 20:41 |
| tcolgate | Ideally, if it is all cool, I'd move the fast path versions into the attributes.h header so they will inline. | 20:41 |
| tcolgate | I'm tryinng not to think of it as a micro-optimisation, more of a "doing the right thing" kind of thing. The array could become a vector if it makes sense to expand it to cover arbitrarily declared attr's | 20:42 |
| tcolgate | Oh, I kiled some of the comments in iatrributes.h, that was just ot make the code a bit more readable, hope it doesn't cause offence.... | 20:44 |
| * tcolgate waits with baited breath. | 20:44 | |
| pgregory | as long as they weren't Doxygen comments. | 20:44 |
| tcolgate | nope, the attrs stuff might be a good example of stuff that might work for template functions, as much as I hate templates. | 20:46 |
| tcolgate | oooh, it's all been a bit of a rush really, haven't written any code in a very long time. | 20:50 |
| tcolgate | did you get it, did ya', did ya', did'a??? | 20:50 |
| tcolgate | atleast it all compilers, that wasn't fun, completely forgot what declaring an enum actually means. | 20:52 |
| * pgregory is looking now... | 20:52 | |
| pgregory | hmm, those were Doxygen comments. | 20:53 |
| tcolgate | eek, OK, well I can put them back. | 20:54 |
| tcolgate | I only got rid of them to help me read the code really | 20:54 |
| * tcolgate has visions of red biro crosses on essays, rolls a cigarette. | 20:57 | |
| *** ShortWave has quit IRC | 20:58 | |
| *** [1]ShortWave is now known as ShortWave | 20:58 | |
| pgregory | ok, taken a look | 20:59 |
| pgregory | looks fine | 20:59 |
| pgregory | basically, the identifier versions of the getters shortcut the search, right? | 21:00 |
| pgregory | but the search will still work, as they are registered in both locations? | 21:00 |
| tcolgate | yep | 21:00 |
| pgregory | so you should be able to plug it directly in with no immediate changes and change the access calls gradually. | 21:00 |
| pgregory | gets my vote. | 21:00 |
| tcolgate | yep, that's the plan. | 21:00 |
| tcolgate | If we figure out a nice way to use it for the other stuff then cool, but the idea is that if it is a parameter that we create and utilize directly in the code then we can fast path straight to it. | 21:01 |
| tcolgate | I don't think the performance benefits are going to be mind blowing for most of our test content, but the principle seems right, and it doesn't destroy the generality of the attr's/param's code that is already there. | 21:02 |
| tcolgate | For the Write side of things, should I hreat a new version of each of those params in the copy constructor for CqAttributes? | 21:12 |
| tcolgate | Hmmm, not quite foing to work, perhaps I put the manual attributes copuing back somehow, I have to keep the two sets of parameters pointing at the same thing. | 21:16 |
| pgregory | hold on... | 21:17 |
| tcolgate | sorry, don't mean to distract you, I can work through it, your time is better spent elsewhere. | 21:18 |
| pgregory | it's difficult to be sure what is the best way to do it. | 21:22 |
| pgregory | it's important that the id-->value mapping get's copied, but you can't copy the attributes directly, that's handled elsewhere. | 21:23 |
| tcolgate | Doing the lookups to point at the right value afterwards is problematic since I don't really want/need to keep the association of the string with the internal stuff, and I don't want to copy them individually. | 21:25 |
| tcolgate | Right, need to make some dinner. | 21:30 |
| *** AlexK is now known as AlexK_ZZzzZZzZz | 21:34 | |
| *** render has joined #aqsis | 21:49 | |
| *** pgregory has left #aqsis | 22:03 | |
| *** AlexK_ZZzzZZzZz has quit IRC | 22:04 | |
| *** Aren has quit IRC | 23:21 | |
| *** cgTobi has joined #Aqsis | 23:34 | |
| *** ChanServ sets mode: +o cgTobi | 23:34 | |
| cgTobi | evening all | 23:34 |
| *** Aren has joined #aqsis | 23:36 | |
| *** cgTobi sets mode: +vv Aren render | 23:37 | |
Generated by irclog2html.py 2.3 by Marius Gedminas - find it at mg.pov.lt!
