Open Source Meeting/2008-07-24

Agenda

• "Fixed Internally" number is ballooning again. Is there a process to reconcile shipped code? Gigs Taggart 17:41, 23 July 2008 (PDT)

• VWR-8194 Anyone got a clue what is happening and why my fix works? Michelle2 Zenovka

• (Replacing my old issue) Memory leaks and corruption, what can we do to try to hunt them down? (-Michelle2)

• Valgrinding, I've done quite a bit and identified quite a few issues, most minor but things like uninitalised vars used for branch decisions with in the viewer code, is this worth chasing? shall i open JIRA's for each small issue or just jump it together? Michelle2 Zenovka

• Quickie update on pyogp... Saijanai 13:50, 24 July 2008 (PDT)

• Viewer 1.21 branching shortly - be ready for cmake --Soft Linden 13:59, 24 July 2008 (PDT)

Raw Transcript

• [14:02] Soft Linden: We can give it a couple more minutes for folks to trickle in...
• [14:02] Soft Linden: But Rob's gone today and probably won't be logging in. We'll still work off the agenda
• [14:02] Saijanai Kuhn: hmmm come to think of it I havent' seen a whiteout view in a while. Maybe that got fixed...
• [14:02] Carjay McGinnis: Rob not in today?
• [14:02] Soft Linden: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
• [14:02] Carjay McGinnis: oh, ok
• [14:03] Soft Linden: Right. So he'll miss the fun. We'll make lots of exciting changes without him.
• [14:03] Carjay McGinnis: oh dear, do we even have an agenda?
• [14:03] Michelle2 Zenovka: a short one yes
• [14:03] Squirrel Wood: In case of emergency, rejoice knowing that help is underway. See [1] for details.
• [14:04] Carjay McGinnis: well, longer than some others
• [14:04] Michelle2 Zenovka: hehe
• [14:04] Soft Linden: Hey, let's jump in.
• [14:04] Squirrel Wood: head first?
• [14:04] Michelle2 Zenovka: why not
• [14:05] Soft Linden: "Fixed Internally" number is ballooning again. Is there a process to reconcile shipped code? Gigs Taggart 17:41, 23 July 2008 (PDT)
• [14:05] Squirrel Wood: I personally would rename "fixed internally" to "In QA testing"
• [14:05] Soft Linden: So yes, once 1.20 is finalized, someone will go through and mark all of those as resolved and close them.
• [14:06] Soft Linden: Well, the place people are seeing that the most is on 1.20 branches, where source is available. You can download and test that yourself if you like.
• [14:06] Squirrel Wood: as to 1.20 being finalized... [2]
• [14:06] Soft Linden: Right. So shortly someone will clear those out for the VWR- issues.
• [14:06] Aimee Trescothick: lol, was just going to say that "about now then "
• [14:06] McCabe Maxsted: someone from LL, or a volunteer?
• [14:07] Carjay McGinnis: right, I saw that
• [14:07] Soft Linden: If there are SVC- issues where that's not getting cleared, then that should change.
• [14:07] Michelle2 Zenovka: oh crap, thats my bandwidth screwed
• [14:07] Soft Linden: I'm not sure who's done it in the past, if it was a Linden or a resident.
• [14:08] Soft Linden: Anyone got an older issue on hand that went through that cycle? You can look at the JIRA history.
• [14:08] Soft Linden: Otherwise, I'll dig one up here...
• [14:08] Carjay McGinnis: don't dig too deep, you never know what you might turn up
• [14:08] Squirrel Wood: likely something nasty :p
• [14:09] Carjay McGinnis: with claws
• [14:09] Aimee Trescothick: might disturb the foundations
• [14:09] Soft Linden: I see Alexa's done a few.
• [14:09] Soft Linden: I'll make a note to ask her if she's the one who will do that this time through, or if we should be searching for volunteers.
• [14:09] McCabe Maxsted: if nobody's going to do it, I wouldn't mind going through the release notes and close them
• [14:09] McCabe Maxsted: likes keeping the JIRA tidy
• [14:09] Soft Linden: Cool, thanks :>
• [14:10] Soft Linden: I'll ping Alexa and let you know what I hear.
• [14:10] McCabe Maxsted: kk
• [14:10] Soft Linden: Anything else on the first item?
• [14:10] Squirrel Wood: cake.
• [14:10] Soft Linden: Next is...
• [14:10] Soft Linden: * VWR-8194[c
• [14:10] Soft Linden: https://jira.secondlife.com/browse/VWR-8194
• [14:11] Michelle2 Zenovka: Yea strange gfx corruption, i do not understand why that fixes it
• [14:11] Michelle2 Zenovka: its seems pushing more that 660 nodes on a single matrix blows my gl context
• [14:11] Michelle2 Zenovka: and not only me this time one other has seen it too
• [14:12] Michelle2 Zenovka: Carjay who has nvidia and also 64bit does not see it
• [14:12] Carjay McGinnis: which it should not do, I checked the specs, they say there is no limit
• [14:12] Carjay McGinnis: for how many primitives you can send down during a Begin/End
• [14:13] Carjay McGinnis: so it's mysterious
• [14:14] Michelle2 Zenovka: other than try to dump the exact gl calls and repo external i'm stuck
• [14:14] Gigs Taggart: did we skip over the fixed internally item or did I miss it?
• [14:14] Carjay McGinnis: you just managed to miss it by 20 seconds or so
• [14:14] Gigs Taggart: oh heh
• [14:14] Gigs Taggart: ok can someone send me a notecard please
• [14:15] Michelle2 Zenovka: so it probably should be filed as "why does it allways happen to me" and left at that
• [14:15] Soft Linden: I'd like to pass it to one of the rendering gurus
• [14:16] Soft Linden: That you have a speicific fix might tip one of them off
• [14:16] Michelle2 Zenovka: that would be cool Soft to know if there is something there
• [14:16] Soft Linden: I'll import this after the meeting and push it to the rendering guys
• [14:17] Soft Linden: Gigs, you get a card?
• [14:17] Michelle2 Zenovka: cool, just a quick look, would be cool i suspect a nvidia issue but hey
• [14:17] Gigs Taggart: `soft now
• [14:17] Soft Linden: In a nutshell, it's time to clear those out with the VWR- issues in 1.20. I'll ping Alexa who flipped those over last time.
• [14:17] Gigs Taggart: no
• [14:17] Tree Kyomoon: I'll send one, Gigs.
• [14:17] Gigs Taggart: thanks
• [14:17] Soft Linden: Thanks!
• [14:18] Soft Linden: Next item was: (Replacing my old issue) Memory leaks and corruption, what can we do to try to hunt them down?
• [14:18] Soft Linden: Whose was this?
• [14:18] Michelle2 Zenovka: mine again
• [14:18] Michelle2 Zenovka: Any good plans for trying to weed out these leaks
• [14:18] Gigs Taggart: uninit vars shouldn't cause leaks
• [14:19] Soft Linden: I don't actually know what tools we're using right now.
• [14:19] Gigs Taggart: soft I brought up a static analysis a while back
• [14:19] Michelle2 Zenovka: this pretty much relateds to my next issue, that was about the unint vars but they are used for if() decisions
• [14:19] Gigs Taggart: thanks liana
• [14:19] Gigs Taggart: accepted your inventory offer.
• [14:20] Soft Linden: Are there any open source malloc libraries that fence allocations to look for overwrites that don't add huge runtime overhead? Even on a debug build, most of those are painfully slow. Enough that people wouldn't use them for day-to-day development.
• [14:21] Michelle2 Zenovka: for whatever reason glibc malloc() is kind of doing this by ungracefully crashing, and there are notes about this in malloc.c
• [14:21] Saijanai Kuhn: Apple's tools (instruments) might do it, but they're platform specific
• [14:22] Soft Linden: Well, even that would help if it were on by default on Mac debug builds and didn't punish Mac developers too badly.
• [14:22] Soft Linden: It would sure be nice to be cross-platform though.
• [14:22] Gigs Taggart: I haven't used any, which ones have you tried already soft?
• [14:22] Soft Linden: In games, we always seemed to reinvent the same tools every time.
• [14:23] Gigs Taggart: the only one that comes to mind off the top of my head open source wise is electricfence.
• [14:23] Carjay McGinnis: is it any good?
• [14:23] Soft Linden: Have you used it?
• [14:23] Gigs Taggart: No, not more than just a trivial test of it :P
• [14:23] Nyx Linden: arent we moving to tcmalloc?
• [14:23] Gigs Taggart: Bruce Perens maintains it.
• [14:23] Saijanai Kuhn: they do a application startup from within a special shell of test services. NOt sure how fast they run, but I've heard good things
• [14:24] Soft Linden: From the description: "Electric Fence (efence) stops your program on the exact instruction that overruns (or underruns) a malloc() memory buffer. GDB will then display the source-code line that causes the bug. It works by using the virtual-memory hardware to create a red-zone at the border of each buffer - touch that, and your program stops. Catch all of those formerly impossible-to-catch overrun bugs that have been bothering you for years. "
• [14:24] Carjay McGinnis: wow, that sounds great
• [14:24] Soft Linden: To catch the exact instruction, you'd pretty much have to be working with page permissions. I doubt that's cross-platform
• [14:24] Carjay McGinnis: now for the small prints...
• [14:24] Gigs Taggart: Well if we catch them on one platform :)
• [14:24] Soft Linden: Requires gdb, anyway
• [14:24] Soft Linden: Right. It will catch the problems in the common code.
• [14:24] Tree Kyomoon: Sounds like it could do my dishes too.
• [14:24] Carjay McGinnis: yes and will probably need huge amounts of memory
• [14:25] Gigs Taggart: I would estimate 95% of the viewer is common.
• [14:25] Gigs Taggart: Don't you agree?
• [14:25] Carjay McGinnis: well, but I doubt it will do windows
• [14:25] Michelle2 Zenovka: dosn't valgrid do that too and if its implementing a custom malloc with tracking it should have similar penilities too>
• [14:25] Gigs Taggart: Well anyway I have no idea how fast or slow it is on an app of this magnitude. :P
• [14:25] Carjay McGinnis: hm, I thought valgrind was not able to detect overruns
• [14:26] Soft Linden: If it's putting every allocation on its own page, that's going to require a 64-bit build, and it'll constantly blow out the MMU set. So yeah, it's going to have a performance penalty.
• [14:26] Carjay McGinnis: just a wee bit :)
• [14:26] Gigs Taggart: why would it require 64-bit? Electricfence is ancient
• [14:26] Soft Linden: Because we've got irresonsible numbers of tiny allocations.
• [14:26] Gigs Taggart: oh
• [14:26] Gigs Taggart: :P
• [14:27] Soft Linden: And the viewer already runs up to 1 gig pretty easily.
• [14:27] Michelle2 Zenovka: if it can run fast enough to process server messages and keep the viewer alive, tis enough, you can walk off and leave it untill it catches something
• [14:27] Gigs Taggart: well I can take a look at it and see
• [14:27] Nyx Linden: I believe we're moving to replacing malloc with tcmalloc - a quick google search turns up some options for heap-checking with tcmalloc, but I havent personally looked into the details
• [14:27] Michelle2 Zenovka: oh god, the viewer, valgrind and gdb use an enormous amount of memory
• [14:27] Gigs Taggart: heh
• [14:27] Carjay McGinnis: ah, ok, it just does not do this with static or stack arrays
• [14:28] Gigs Taggart: the heap is where you get in trouble most of the time anyway
• [14:28] Carjay McGinnis: indeed
• [14:28] Carjay McGinnis: yes, see Michelle
• [14:28] Gigs Taggart: I would hope we are not newb enough to be be blowing the bounds on our stack arrays too often hehe
• [14:28] Carjay McGinnis: well, you should use std::vector for that anyway
• [14:29] Saijanai Kuhn: [3]
• [14:29] Soft Linden: So the one thing that always saved us in game development was checking a little guard area we inserted before and after every allocation. Those were prefilled with a fixed value, and over the course of a couple seconds those were all checked - a fraction of them every frame to avoid a significant runtime penalty.
• [14:30] Gigs Taggart: soft that sounds like what electricfence does
• [14:30] Soft Linden: No, it looks like electric fence catches the problem right when it happens with a page fault.
• [14:30] Michelle2 Zenovka: i've got an instance running now
• [14:31] Soft Linden: Michelle2 - what does memory use look like with that going?
• [14:31] Michelle2 Zenovka: ElectricFence Exiting: mprotect() failed: Cannot allocate memory
• [14:31] Gigs Taggart: hehe
• [14:31] Michelle2 Zenovka: *sigh*
• [14:31] Soft Linden: I hope that wasn't the 64-bit build :)
• [14:31] Michelle2 Zenovka: yea
• [14:32] Saijanai Kuhn: its mac specific but you guys really should loo at the instruments options...
• [14:32] Carjay McGinnis: hm, I can't seem to find a project page for electric fence
• [14:32] Soft Linden: Should we take this back to the sldev list, with electricfence and instruments as suggestions?
• [14:32] Michelle2 Zenovka: yea, if we can get any working it might produce results
• [14:32] Carjay McGinnis: how much memory do you got, Michelle?
• [14:32] Soft Linden: To the agenda item - it does sound like we could be doing more. Maybe Brad or Nyx can also add details on what tcmalloc brings to the table.
• [14:33] Michelle2 Zenovka: right now 1G actual many gigs swap, but i'm upgrading to as much as i can jam in
• [14:33] Nyx Linden: Brad is working on it, I only work next to him ;)
• [14:33] Carjay McGinnis: 1G is not much
• [14:33] Soft Linden: Cool :)
• [14:33] Michelle2 Zenovka: no i know
• [14:33] Saijanai Kuhn: Its a special shell that launches the application. You can use the predefined instruments as modules, or customize your own. It will record things and even let you playback input to recreate the bug
• [14:34] Carjay McGinnis: "things"?
• [14:34] Saijanai Kuhn: user input and the like
• [14:34] Saijanai Kuhn: keypresses, mouse movement, etc
• [14:34] Soft Linden: That's awesome. I know there's a similar tool for Windows that costs huge $$$
• [14:34] Carjay McGinnis: hm, ok, sounds like a QA tool
• [14:34] Saijanai Kuhn: free with Leopard
• [14:34] Soft Linden: Next issue on the list:
• [14:35] Soft Linden: Valgrinding, I've done quite a bit and identified quite a few issues, most minor but things like uninitalised vars used for branch decisions with in the viewer code, is this worth chasing? shall i open JIRA's for each small issue or just jump it together? Michelle2 Zenovka
• [14:35] Gigs Taggart: Windows 3.1 used to come with the excellent macro.exe
• [14:35] Gigs Taggart: I was sad when MS removed that
• [14:35] Soft Linden: I'd open individual issues if they're spread all over. If you see a few in one area of code, go for it.
• [14:36] Soft Linden: Single patches that touch a ton of different files tend to get frowned at massively.
• [14:36] Michelle2 Zenovka: they are spread,but 99% are things like overridden constructor where something was not initalised in one version, but it tends to be only start up code and sorts itsself out later so nothing ground breaking
• [14:36] Soft Linden: It's tough to create good QA plans for that. "Test everything teleport-related, inventory-related and rendering-related"
• [14:36] Soft Linden: Right.
• [14:37] Soft Linden: Key thing though is the related system still needs to go through QA. And if there's a fix fail on it, that means all those systems need to get retested when resubmitting that JIRA.
• [14:37] Gigs Taggart: michelle looks like DUMA is a fork of eFence that is more up to date.
• [14:37] Carjay McGinnis: lol
• [14:38] Gigs Taggart: [4]
• [14:38] Carjay McGinnis: sounds russian
• [14:38] Michelle2 Zenovka: apt-get install duma
• [14:38] Carjay McGinnis: Detect Unintended Memory Access
• [14:38] Carjay McGinnis: ah, kay
• [14:39] Soft Linden: Next item is:
• [14:39] Soft Linden: Quickie update on pyogp... Saijanai 13:50, 24 July 2008 (PDT)
• [14:39] Saijanai Kuhn: Ah, just a heads up. We're meeting three times a week
• [14:39] Saijanai Kuhn: MWF at 9:30 am. The Friday meeting is at Enus' office hours
• [14:40] Saijanai Kuhn: we gots a pjira entry, irc, mailing list and website set up now
• [14:40] Michelle2 Zenovka: ok duma looks useful but need to link it agains the binary
• [14:40] Tree Kyomoon: Great, Saijanai. Thanks.
• [14:40] Gigs Taggart: I thought you linked electricfence too
• [14:40] Gigs Taggart: it's been quite a few years since I looked at it
• [14:40] Saijanai Kuhn: https://wiki.secondlife.com/wiki/Pyogp and https://wiki.secondlife.com/wiki/Pyogp/Links
• [14:41] Carjay McGinnis: the German article mentions Visual C++ 6.0
• [14:41] Carjay McGinnis: so seems to work on VC, too
• [14:41] Soft Linden: There's a 10 second summary of pyogp for anyone who's unfamiliar. From Saijani's first link:
• [14:41] Soft Linden: Pyogp is an open source project between Linden Lab and AWG to support the testing of the Open Grid Protocol (OGP). Written in Python, Pyogp will consist initially of a client library and test functionality that will enable testing of OGP enabled virtual worlds like Second Life and compatible OpenSim implementations.
• [14:42] Saijanai Kuhn: Main Instruments intro: [5]
• [14:42] Saijanai Kuhn: its pretty slick and easy to do simple meinded thigns with
• [14:42] Soft Linden: That's been seeing a heck of a lot of activity on that, visible in the sl svn.
• [14:43] Saijanai Kuhn: once it gets going, it should be the backbone of testing. We're hoping to support all the old protocols as well as the OGP ones
• [14:43] Saijanai Kuhn: so you could do a swarm test with 1,000 avatars just aftar a rolling restart
• [14:43] Soft Linden: Oh god please don't :)
• [14:44] Saijanai Kuhn: hey stress tests are important...
• [14:44] Soft Linden: Right! Just - please try it on the dev grid first. Rumor is the main grid gets pretty shaky around that 55k mark.
• [14:44] Saijanai Kuhn: just have them TP, rez something delete it TP out and repeat
• [14:45] Saijanai Kuhn: could run them all from a text file
• [14:45] Carjay McGinnis: you need to register those 1000 avatars before you can do that though
• [14:45] Soft Linden: Cool. Anything else on that update, or on to the last item?
• [14:46] Saijanai Kuhn: Enus has about 500 or so I think
• [14:46] Carjay McGinnis: lol
• [14:46] Saijanai Kuhn: xxx Tester
• [14:46] Soft Linden: Right. If you need to register a bunch of avatars for testing, we could probably help out on that with a bit of advance warning. Raise that on sldev with a description of what you mean to try - and again, ideally make it for the dev grid first.
• [14:47] Saijanai Kuhn: absolutely. Enus would be in charge of that anyway
• [14:47] Soft Linden: It would be nice to see new scaling issues appear on the dev grid rather than the production grid.
• [14:47] Squirrel Wood: 1000 avatars in a single sim ...
• [14:47] Saijanai Kuhn: well, probably not
• [14:48] Tree Kyomoon: On a similar note, if you need parcel control access for testing, let me know. I might be able to give you access to a parcel on Hippotropolis for testing.
• [14:48] Saijanai Kuhn: kool Far in the future. Tao is still trying to get the automated build and svn stuff working with WIndows right now
• [14:48] Soft Linden: Definitely not 1000 on a sim any time soon. Sadly, there are still a number of O(n^2) things happening on the simulator.
• [14:48] Carjay McGinnis: thought 50 as the limit
• [14:48] Gigs Taggart: at least not 2^n
• [14:48] Carjay McGinnis: was
• [14:48] Tree Kyomoon: / "you" being any sldev-ers
• [14:49] Soft Linden: I think the cap, including god mode emergency access, is 100 right now.
• [14:49] Soft Linden: Things still run surprisingly smoothly at 80.
• [14:49] Saijanai Kuhn: Zha has 100 in her sim, so that sounds right
• [14:49] Squirrel Wood: I've seen 150 once I believe
• [14:49] Carjay McGinnis: god mode emergency access, oh, sounds nice
• [14:49] Gigs Taggart: estate owners can lock themselves out :(
• [14:49] Gigs Taggart: at leats lindens can't
• [14:50] Soft Linden: That's a bit silly. There's already a JIRA for that?
• [14:50] Carjay McGinnis: lol
• [14:50] Soft Linden: I'm thinking EMs should have unconditional access.
• [14:50] Aimee Trescothick: wonders if there's a god mode emergency exit too
• [14:50] Saijanai Kuhn: we got griefed at Which's O H so bad onc, his viewer crashed when he tried to use God Mode
• [14:50] Gigs Taggart: soft a tenant with EM access set his sim to 0 once
• [14:50] Saijanai Kuhn: that particular bug was fixed pretty fast though
• [14:50] Soft Linden: Oh nice
• [14:50] Carjay McGinnis: did it happen to you, Gigs?
• [14:50] Gigs Taggart: two bugs really, that you can set it to 0 and also that EMs count toward the limit
• [14:50] Gigs Taggart: yeah carjay a tenant set his sim to 0 limit
• [14:51] Gigs Taggart: I had to call a linden :P
• [14:51] Carjay McGinnis: ah, ok, I would think 0 means "no limit"
• [14:51] Soft Linden: Gigs - if there are JIRAs for those (or if you want to make 'em real quick) I'll import those directly.
• [14:51] Carjay McGinnis: obviously, it doesn't :)
• [14:51] Gigs Taggart: soft let me see
• [14:51] Soft Linden: That's it for the agenda.
• [14:52] Tree Kyomoon: Any other updates -- from Lindens or otherwise?
• [14:52] Gigs Taggart: I have a concern
• [14:52] Soft Linden: Oh, sorry- there was one more item - from me, no less.
• [14:52] Soft Linden: Go ahead though, Gigs?
• [14:52] Gigs Taggart: cmake pretending that it is a package manager is annoying me to no end
• [14:52] Gigs Taggart: it is nearly impossible to do a non-standalone build with newer libs because cmake keeps trying to download and overwrite my newer libs
• [14:53] Gigs Taggart: with older ones that it thinks are better
• [14:53] Gigs Taggart: this is really a step backward from the old way
• [14:53] Soft Linden: Isn't there a command line option that prevents downloading and installing?
• [14:53] Gigs Taggart: just standalone
• [14:53] Kiosk: SL: Open Source General Info whispers: Thank you! Your items will be delivered to you soon!
• [14:53] Michelle2 Zenovka: sounds like we need a command line
• [14:53] Gigs Taggart: but standalone prefers system libs
• [14:53] Gigs Taggart: and we might not want that
• [14:53] Soft Linden: Gotcha, so you don't want to do a standalone, but you have a few specific libs you've swapped out
• [14:54] Gigs Taggart: what I did was comment out everything in prebuild.cmake
• [14:54] Gigs Taggart: and then it works the way I like
• [14:54] Gigs Taggart: so if everything in prebuild.cmake could be conditional then that would be nice :P
• [14:54] Soft Linden: You may be able to slash them out of install.xml as well
• [14:54] Gigs Taggart: anyway I have a feeling that you will see more complaints along these lines once cmake version goes mainstream
• [14:55] Soft Linden: I'd JIRA/sldev that one. The people working on that aren't here, but do read sldev.
• [14:55] Gigs Taggart: thanks
• [14:55] Squirrel Wood: other things... any plans on setting up a group for volunteers to get the wiki back in shape? like, add/complete information in the lslwiki and such ? Or does such a group already exist?
• [14:55] Tree Kyomoon: Gigs: Yes, please Jira your concerns. I'll be sure to ping the cmake team.
• [14:55] Soft Linden: Unfortunately, that whole download system went in without advance warning. I'm not sure why it didn't go through a public branch first like the rest of the cmake changes did.
• [14:56] Gigs Taggart: soft hehe
• [14:56] Soft Linden: I don't know of anything like a community wiki work team.
• [14:56] Tree Kyomoon: We could sure use one though, Squirrel.
• [14:56] Soft Linden: It would be helpful to start by flagging pages that need attention somehow. Would that be a good use of the category feature?
• [14:57] Squirrel Wood: that could work
• [14:57] Soft Linden: Or a template that added that category and also put a warning at the head of the page. "This page may contain outdated or incorrect information. Here's how you can help..."
• [14:57] Gigs Taggart: soft: [6]
• [14:58] Gigs Taggart: already imported with 49 votes
• [14:58] Gigs Taggart: estate owner locked out of own sim
• [14:58] Soft Linden: Gigs: Internally that's marked as 'open' instead of 'proposed' so it's not hitting triage. I'll fix that.
• [14:58] Gigs Taggart: thanks
• [14:58] Soft Linden: Or I'll just triage it now. Feh.
• [14:58] Gigs Taggart: being able to set limit to 0 is probably another bug
• [14:58] Gigs Taggart: but if this one is fixed it doesn't matter as much
• [14:59] Soft Linden: Yeah - please do a separate one for that, if you would.
• [14:59] Gigs Taggart: ok
• [14:59] Soft Linden: I think that one would sail through without opposition. The full one will need some discussion.
• [15:00] Gigs Taggart: [7]
• [15:00] Gigs Taggart: now
• [15:00] Gigs Taggart: I haven't reproed this
• [15:00] Gigs Taggart: for obvious reasons
• [15:00] Gigs Taggart: but a tenant did manage to do it several months ago
• [15:00] Soft Linden: Okay - I'll import this one in a sec.
• [15:00] Saijanai Kuhn: By the way, this [8]
• [15:01] Saijanai Kuhn: and this [9]
• [15:01] Saijanai Kuhn: give an idea of how slick instruments is
• [15:01] Saijanai Kuhn: not sliders for "playback"
• [15:01] Saijanai Kuhn: note* sliders
• [15:01] Soft Linden: The last issue on the agenda - the 1.21 viewer branches shortly. If you haven't already, please have a go at building release/. That's to become the viewer branch. If you see anything just hideously horribly wrong or confusing with the cmake build system, now's the best time to hear about it.
• [15:02] Aimee Trescothick: been there done that :P
• [15:02] Soft Linden: Otherwise, what you see in there is likely to be close to 1.21, minus the bugs fixed in a (hopefully much shorter) RC cycle.