Open Source Meeting/2009-12-10

Transcript

• [13:59] Thickbrick Sleaford: it looks like snowglobe tends to fail at baking more often than other viewers
• [13:59] Twisted Laws: it doesn't keep the avatar textures, only the bake.. the others are expired
• [14:00] Dzonatas Sol: It's the, on 64bit when it clears it also clears the baked textures. I thought it was just my hacked viewer
• [14:00] Dzonatas Sol: lol
• [14:00] Dzonatas Sol: the cache*
• [14:00] Youri Ashton: remember that from next week on a lot of lindens wont show due to the holidays
• [14:00] Thickbrick Sleaford: you mean for your own avatar, or other people's?
• [14:00] Ardy Lay: That picture is not what I see.
• [14:00] Youri Ashton: hey merov
• [14:01] Merov Linden: hey
• [14:01] Twisted Laws: well it definitely expires other peoples
• [14:01] Merov Linden looking for a place to sit
• [14:01] Twisted Laws: hey Merov
• [14:01] Shorahmin Femto: apparently I have all these seats taken lol
• [14:02] Susan Tsuki: Hi Morgaine, do you know Merov?
• [14:02] Ardy Lay: Hello Merov, I have new media issues and camera weirdness. :-(
• [14:02] Merov Linden: ok, it's 2pm and Morgaine is here so we can start... :)
• [14:03] Youri Ashton: lol
• [14:03] Twisted Laws: anyone else fly when they open about box in 1.3 ?
• [14:03] Hank Ramos: Any work towards making Snowglobe work better with lesser hardware, suh as netbooks?
• [14:03] Youri Ashton: reads easier for me
• [14:03] Merov Linden: Ardy did again a great job on the meeting agenda
• [14:03] Morgaine Dinova: LOL
• [14:03] Geneko Nemeth shrugs
• [14:03] Susan Tsuki: agenda url please
• [14:03] Merov Linden: https://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda #Agenda
• [14:03] Susan Tsuki: thank ou!
• [14:03] Morgaine Dinova: Well I'm not intimate with Merov, but I know he's a damn fine dev ^_^
• [14:03] Susan Tsuki: you*! (darn input thread bug)
• [14:04] Merov Linden blushes
• [14:04] Geneko Nemeth: Curses, whose translator is that?!
• [14:04] Morgaine Dinova chuckles
• [14:04] Merov Linden: I added the first item being a 1.3 check point / status
• [14:04] Merov Linden: I emailed sldev yesterday wrt this
• [14:05] Merov Linden: we have quite a bit of patches in the pipe and I'd like to see some commits this week
• [14:05] Merov Linden: thanks for those of you who jumped in and commented on PJIRA
• [14:05] Merov Linden: this helps a lot!
• [14:06] Merov Linden: on the timeline now, the plan initially with Snowglobe was to use a time driven release rather than feature driven
• [14:06] Morgaine Dinova senses Merov is trying to ramp up Snowglobe hacking :-)
• [14:07] Merov Linden: 1.2 sort of broke that because SNOW-222 was sooo darn big that it rocked the trunk for a long time
• [14:07] Merge LLMedia Plugin API in SnowGlobe
• [14:07] Pixel Gausman: whew, at least we're not blaming 215
• [14:07] Merov Linden: I think we should get back into the better habit of regularly posted releases
• [14:07] Merov Linden: what doyou guys think?
• [14:08] Pixel Gausman: Merov: does that mean more frequent releases?
• [14:08] Youri Ashton: sure is a great feature to have
• [14:08] Youri Ashton: why not?
• [14:08] Susan Tsuki: I think that sounds fantastic!
• [14:08] Merov Linden: Pixel: yes, basically a release every 10 weeks
• [14:08] Shorahmin Femto: that would mean less testing inbetween though
• [14:08] Merov Linden: proposed timeline for 1.3 is here BTW: http://wiki.secondlife.com/wiki/Snowglobe_Current_Cycle
• [14:09] Merov Linden: we need to test continuously
• [14:09] Susan Tsuki: most of the bugs manifest quickly. Time for testing internally can never catch enough, without regular releases the users become complacent
• [14:09] Pixel Gausman: that would be really good, unless that means a smaller window that people can get code checked in
• [14:09] Morgaine Dinova: Well, things are ready when they're done. While it's nice to see regular releases, all it really means is that every so often you freeze new features and kill a few bugs, then release.
• [14:10] Lillie Yifu: what about being more formal
• [14:10] Thickbrick Sleaford: it means smaller windows, but more frequent windows too
• [14:10] Merov Linden: Susan: trues, this is why I started the "weekly" release (based on trunk) so there's a binary to test
• [14:10] Lillie Yifu: have a tick tock... one cycle features, the next cycle bugs
• [14:10] Susan Tsuki: great!
• [14:10] Shorahmin Femto: I like that Lil
• [14:10] Morgaine Dinova: Merov: how about taking it to the limit ..... continuous release. In other words, after each commit, a release is automatically built.
• [14:10] Susan Tsuki: there used to be a "First Look" program where basically anyone could volunteer to beta. Why that ended is a mystery to me
• [14:11] Twisted Laws: i prefer skipping releasing bugs :p
• [14:11] Shorahmin Femto: nor rigidly but a matter of emphsise
• [14:11] Youri Ashton: do you test every time after doing something or just once a week? could mean you find problems quicker
• [14:11] Pixel Gausman: so we're in favor, as long as it doesnt mean Merov *only* spends time fussing with release cycle stuff. we want Merov doinglots and lots of coding
• [14:11] Morgaine Dinova: If Merov is spending more than 5% of time on managing this, the process is wrong.
• [14:12] Morgaine Dinova: Or 2% :-)
• [14:12] Merov Linden: Morgaine: I think quite a few less adventurous folks like to use a release that had gone through a fair amount of tests or survived in the wild with other using it
• [14:12] Pixel Gausman: there's probably actually a fair amt of his time fussing with it.
• [14:12] Youri Ashton: I used to work on red Alert and C&C generals modding a long time, every time i added evena small thing i went testing to see if it would work. saves up a lot of time and problems finding what the problem may be
• [14:12] Lillie Yifu: but lots of projects release a "last good build"
• [14:12] Lillie Yifu: and then release the "most recent build"
• [14:12] Merov Linden: thanks for thinking of me as coding, I prefer that indeed
• [14:13] Morgaine Dinova: Merov: they don't need to pick the latest build! You could even tag the continuous releases with quality marks, or "Recommended".
• [14:13] Lillie Yifu: this being SL, there are plenty of pepole who are willing to use the latest anythign howeverpainful that is
• [14:13] Thickbrick Sleaford: on the other hand I think some people are using the test builds without understanding what that means
• [14:13] Merov Linden: that's why I like a simple flowing process so I don't have to think about it too much
• [14:13] Morgaine Dinova: I think a continuous build system would free you of work and effort.
• [14:13] Pixel Gausman: flowing meaning no build breaks.
• [14:13] Morgaine Dinova: Yes!
• [14:14] Thickbrick Sleaford: Morgaine: there's nightly (semi-)automated builds posted to sldev/commits
• [14:14] Thickbrick Sleaford: sldev-commits
• [14:14] Morgaine Dinova: As Pixel says --- you end up very cautious in your commits, because if it breaks, the finger points at you
• [14:14] Merov Linden: If that includes "standalone builds", that's not making less work for me :(
• [14:15] Merov Linden: I'm trying hard not to break the parabuilds builds for sure
• [14:15] Morgaine Dinova: I don't know the situation with standalone builds currently.
• [14:15] Dzonatas Sol: standalone builds just mainly need to do : make secondlife-bin
• [14:15] Pixel Gausman: so what would be the difference between the automagic builds that we see in sldev-commits, and a 'release'?
• [14:15] Merov Linden: 3049 apparently got Aleric screaming at me
• [14:16] Thickbrick Sleaford points at the after-next issue on the agenda
• [14:16] Morgaine Dinova: I'm spoiled by using Gentoo. I just type "emerge snowglobe-trunk" and Techwolf's ebuild gives me a standalone build automatically :P
• [14:17] Merov Linden: Thickbrick's correct: back to the agenda
• [14:17] Merov Linden: :)
• [14:17] Merov Linden: about 1.3 timeline, looks like we got consensus with some folks suggesting a more continuous automatic build for trunk
• [14:18] Merov Linden will talk to CG about that
• [14:18] Merov Linden: next item on the agenda
• [14:18] Morgaine Dinova: Btw, what's the make target for "just bring install the prebuild libs, don't compile" ?
• [14:18] Dzonatas Sol: if the continous build break, let the committer fix it?
• [14:18] Youri Ashton: darned autism makes me sleepy = better put on some music to wake me up :o
• [14:18] Dzonatas Sol: breaks*
• [14:19] Ardy Lay: Morgaine, prepare is think is what you are asking for.
• [14:19] Susan Tsuki: Merov, regarding "Support for third party speech-text programs " which doesn't seem to have any Jira, how about starting with speech synthesis first, then some way to script video-voicemail and buffer it in the other direction, so for example you could have a threaded tree, each leaf a prim with a different message to be played back when touched
• [14:19] Morgaine Dinova: Ardy: tnx, I'll check that
• [14:19] Merov Linden: Morgaine: ./develop.py build prepare
• [14:19] Morgaine Dinova: Make target, not develop.py, yuck :P
• [14:20] Dzonatas Sol: I think it would be easier to just keep the mediaplugins as 32bit for now
• [14:20] Merov Linden: wait wait
• [14:20] Susan Tsuki: if someone wanted to reply to a node, presumably they would touch a different part of the leaf. The important thing is that speech synthesis is probably good in one diretion, then you need asynchronous buffering in the other direction before you're ready for speech-to-text things
• [14:20] Merov Linden: I'm lost now: item on the agenda is: "internal branches"
• [14:20] Susan Tsuki: sorry
• [14:21] Susan Tsuki: I was lost
• [14:21] Thickbrick Sleaford: heh
• [14:21] Merov Linden: so, some folks (Aleric again but others too) wondering what all those "big blind merges" are all about
• [14:22] Merov Linden: first: there's no such big blind merges since a while at least
• [14:22] Merov Linden: the last few ones that happened were done by me
• [14:22] Thickbrick Sleaford: Merov, is it possible to get some sort of dump of the internal commit messages that sort of correspond to these mergese (when they happen)?
• [14:22] Merov Linden: and got logged under PJIRA with patches before landing in trunk
• [14:22] Merov Linden: namely : SNOW-222 and SNOW-301
• [14:22] Update pluginapi code so to support newest API
• [14:23] Merov Linden: Thickbrick: the problem is that those are not straight merges, unfortunately
• [14:23] Merov Linden: more like backport from viewer 2.0 to the 1.23 code base
• [14:24] Morgaine Dinova: Tell us more ^_^
• [14:24] Merov Linden: untangling what we needed to keep pluginapi moving forward has been quite a piece of work
• [14:25] Pixel Gausman: do they tend to be big blobby features like media plugin, or do we also see buckets of small unnamed fixes?
• [14:25] Merov Linden: big blobby features Pixel
• [14:25] Merov Linden: no unnamed fixes
• [14:25] Merov Linden: the only odd one being the security patch we had to take
• [14:26] Merov Linden can't rememeber the SNOW reference for that one right now
• [14:26] Susan Tsuki: perhaps it's better we don't know
• [14:26] Thickbrick Sleaford: lol
• [14:27] Pixel Gausman: is Aleric here to talk? he seemed torqued today in IRC, so i'd like him to be able to discuss it
• [14:27] Thickbrick Sleaford: he said he can't make it to the meeting
• [14:27] Pixel Gausman: poo.
• [14:27] Merov Linden: anyway, the short story on that one is : no big merge of that kind is planned right now, *except* for pluginapi update
• [14:28] Merov Linden: since I think we want their improvements and keep the API up to date
• [14:28] Twisted Laws: using Trac can show the changes anyway if someone really wants to know. i know i've looked at version diffs often
• [14:28] Merov Linden has a terrible headache right now...
• [14:29] Pixel Gausman: i think they are a fact of life for us, really. it's good that we can leverage what the linden devs are doing internally
• [14:29] Pixel Gausman dcc's Merov an aspirin
• [14:29] Merov Linden: the origin of this really is the new situation with llqtwebkit
• [14:29] Thickbrick Sleaford: the other part of Aleric's rant is this: <Aleric> 2) Basically, the communication is not optimal... and that didn't get any better after Rob left... It would be greatly beneficial if there was open communication possible about server changes as well, so that viewer and server coders can work together on features / improvements that need changes on both.
• [14:29] Merov Linden: which is considered as a 3rd party lib but really a LL tweaked qtwebkit lib
• [14:30] Pixel Gausman: i dont think snowglobe devs are gonna get to wrangle linden into server changes
• [14:30] Merov Linden: that's one thing that I let fell through the crack
• [14:30] Thickbrick Sleaford: but the published source is a moving target, and so is Snowglobe - so that breaks standalone often
• [14:30] Youri Ashton: susan, your avi shows its legs occasionally
• [14:30] Youri Ashton: may need to re attach the suit
• [14:31] Susan Tsuki: sorry
• [14:31] Merov Linden: Thickbrick: I emailed sldev with an answer to Aleric question just before that meeting
• [14:31] Youri Ashton: dont say sorry, i just noticed it :p
• [14:31] Morgaine Dinova: Susan: Fine on Imprudence
• [14:31] Thickbrick Sleaford: oh. sorry, didn't see that yet.
• [14:32] Susan Tsuki: I like the sound of "plugin api"
• [14:32] Susan Tsuki: "media plugin api" sounds even better
• [14:32] Merov Linden: np, the thing is that his question is formulated in a way that can't be answered really: no one person if "making protocol changes"
• [14:32] Susan Tsuki: the fact that animations are being considered media is really great
• [14:32] Morgaine Dinova: For those of us not on IRC, is there some kind of major argument or disagreement there?
• [14:32] Merov Linden: it's more complex than that
• [14:33] Shorahmin Femto: iiirc?
• [14:33] Shorahmin Femto: IRC?
• [14:33] Thickbrick Sleaford: #opensl on EFNet
• [14:33] Morgaine Dinova: Shorah: Merov was reporting on a discussion on IRC
• [14:33] Youri Ashton: IRC = chat
• [14:34] Merov Linden: but there's nothing preventing discussions on features that require server side changes, it's just more complex, longer to deploy as you can imagine
• [14:34] Youri Ashton: internet relay chat if i say that correct
• [14:34] Shorahmin Femto: ty
• [14:34] Susan Tsuki: IRC is like a gust of methane in a walled garden. If it ain't in Jira, good luck
• [14:35] Morgaine Dinova: Or SLdev m/l at least
• [14:35] Merov Linden: ok, I think I answered that one to the best of my ability really
• [14:35] Thickbrick Sleaford: anyway, about llqtwebkit, I think the problen is, to quote Callum Linden from MOZ-39: "That interface changed recently and will most like change again soon."
• [14:35] llqtwebkit hg rev greater then 240 will cause snowglobe standalone build to fail.
• [14:35] Morgaine Dinova: Agreed. I've seen that too, on a Techwolf ebuild
• [14:36] Susan Tsuki: I owe Andrew Linden a Jira about why the server implementation of LSL should be expanded with rotation primitives allowing for composition of a list of rotations and utilities to make the practice easier, but ... I just can't motivate myself, it feels too much like work
• [14:36] Merov Linden: yes, I *need* to talk to Callum and the media team about a process to get a repo available for llqtwebkit
• [14:36] Thickbrick Sleaford: if the hg head of llqtwebkit is too fluid, can you publish a tarball of the srouce used to build the version in install.xml ?
• [14:36] Merov Linden: again, that one is one I let fall through the cracks as I was not impacted by it
• [14:36] Robin Cornelius: +1 Thickbrick a known good revision that the API in snowglobe expects
• [14:37] Thickbrick Sleaford: since that changes from both the library and the viewr side often
• [14:37] Robin Cornelius: someone must be packaging the lib somewhere, for the build non standalone to work
• [14:37] Dzonatas Sol: I put a suggested fix to qtwebket on SNOW-285 -- skip it on standalone build like it all other system libraries are skipped
• [14:37] Standalone build fails due to not finding system webkit
• [14:37] Youri Ashton: oh merov, you may like to tell the server team to fix the asset server, its been acting up past few days again
• [14:38] Youri Ashton: also count for chat, private IM and group IM
• [14:38] Merov Linden: Youri: I'm sure they know! :)
• [14:38] Merov Linden: and are all over it already
• [14:38] Youri Ashton: hope so, its been bad since last week
• [14:38] Morgaine Dinova: Really we need access to Ops. Pity none of them have OHs
• [14:39] Shorahmin Femto: this is the wrong place for that I think
• [14:39] Morgaine Dinova: Yeah
• [14:39] Merov Linden: ok, I think we identified a task for me from a project management standpoint: make sure the llqtwebkit code is posted, up to date, etc...
• [14:40] Dzonatas Sol: llqtwebkit shouldn't be built when --standalone is specified.
• [14:40] Morgaine Dinova is horrified at Merov taking on paperwork. (Seriously)
• [14:40] Youri Ashton: lol
• [14:40] Merov Linden is not taking paperwork... no way...
• [14:40] Morgaine Dinova: :-)
• [14:40] Shorahmin Femto: comes with the paygrade? lol
• [14:41] Youri Ashton: lol
• [14:41] Robin Cornelius: Dzonatas you mean the webkit plugin should not be built?
• [14:41] Susan Tsuki: use mail-merge :D
• [14:41] Dzonatas Sol: yes
• [14:41] Robin Cornelius: llqtwebkit is the libray that the plugin links too, just clarifiying
• [14:41] Youri Ashton: merov is a smart guy, he probably uses a lot of expansive words some may not understand. so infact it isnt his fault :)
• [14:42] Robin Cornelius: i still want a way to build it standalone though, i do so now and what to keep that working
• [14:42] Dzonatas Sol: all llmediaplugins can be precompiled... they don't need to be built with --standalone. i do agree there should still be a way to build the plugins, but not when --standalone is specified
• [14:42] Merov Linden leaves Robin and Dzonatas debate the --standalone question
• [14:43] Youri Ashton: lol
• [14:43] Morgaine Dinova: Well we don't have mixed builds. It's either prebuilt (all of 'em) or it's standalone (none of 'em).
• [14:43] Robin Cornelius: the issue with that is that LL have always insisted on static linkage, i always use dynamic linkage, this has allowed be in the past to switch out mozlib and webkit on the older viewers at run time
• [14:44] Robin Cornelius: i naged and naged during the development of qtwebkit but i could not get the devs to go static linkage
• [14:44] Youri Ashton: component builds may be usefull, then any new update doesnt take long to install (if person wants to have this update)
• [14:44] Susan Tsuki: I have to leave early. But I just want to say, this general media plug-in api is exacly right. I hope only that you don't make the mistake the web browsers did and allow of all kinds of download players (you already have a lot) and not input. That you're specifically addressing input is like manna from heaven
• [14:45] Dzonatas Sol: It would be better to run develop twice for standalone builds... once with static linkage to buid the plugins. Then run it again with --standalone to build the viewer
• [14:46] Robin Cornelius: why do we need static linkage at all?, i link llqtwebkit against my system qt4?
• [14:46] Susan Tsuki: static trades known compatibility for size
• [14:46] Merov Linden: Note: the viewer does rely on some plugins to be present, in particular webkit, for help, search and other UI elements using HTML content
• [14:47] Susan Tsuki: I hope we get asynchronous voice and video to complement the syncronous voice
• [14:47] Youri Ashton: thas what i mean merov, might be handy to allow peopel to experiment with it. it could end up with excellent updates for future viewers
• [14:47] Robin Cornelius: for known compatability you can still ship well defined versions of libraries in shared form, there is no need to make it static, static just makes in monolythic
• [14:47] Morgaine Dinova: Maybe we're doing this wrong. Perhaps instead of prebuilt and standalone, we should have a "do_not_build" file that lists libraries that should not be downloaded nor built. After all, a prebuilt compile often requires prebuilt libs to be deleted, and a standalone compile often requires some of the prebuilt libs brought down.
• [14:47] Susan Tsuki: bye and thanks all!
• [14:48] Morgaine Dinova: Cyu Susan
• [14:48] Dzonatas Sol: Here the scenario I work with: I can build with --standalone (skip the plugins) and download the pre-built plugins from LL.
• [14:48] Merov Linden: actually, I wrote that the wrong way: the viewer relies on *some plugin* to handle html rendering
• [14:49] Merov Linden: OK, looks like we won't solve that issue right here and there
• [14:49] Dzonatas Sol: The 32bit pre-built plugins work with a 64bit bit viewer.
• [14:49] Merov Linden: and I'm sure some people like Techwolf would have interesting things to say about this
• [14:49] Robin Cornelius: basicly we are looking for an extra switch to enable no plugins, --stadnalone plugins or download prebuilt plugins
• [14:49] Thickbrick Sleaford: MErov: short term solution is to have a know-good source package
• [14:50] Thickbrick Sleaford: *known-good
• [14:50] Merov Linden: so let's bring that discussion to sldev
• [14:50] Dzonatas Sol hasn't had mocha cocoa java lava today
• [14:51] Merov Linden: Robin: yes, I can understand the need and use of all those options
• [14:51] Dzonatas Sol: the install.xml file could fetch the pre-built plugins if someone wants to run --standalone and hack a build for a package
• [14:51] Merov Linden: hope that someone will come up with patches for the build scripts :)
• [14:51] Robin Cornelius: oh Dz, isn't there a danger that with a 32bit plugin and a 64bit viewer the SCM could be outside the 32bit addressable range?
• [14:52] Youri Ashton: talking about 64bit, is the new viewer going to support that?
• [14:52] Shorahmin Femto: zing...
• [14:52] Youri Ashton: every time i start up SL now i get a return to 32bit mode thing in my screen
• [14:52] Youri Ashton: very annoying
• [14:52] Dzonatas Sol: when in 32 bit ... shared memory maps into 32 bit address space
• [14:53] Youri Ashton: makes screen as well very small
• [14:53] Youri Ashton: only viewer that doesnt do this is 1.23 nightly
• [14:53] Dzonatas Sol: shared memory has a segment limit that is defined by each system... it doesn't matter if it is 32 or 64 bit
• [14:53] Thickbrick Sleaford: but if the viewer runs in 64bit, and SPlugin in 32, will it work?
• [14:53] Dzonatas Sol: yes, i do that now
• [14:54] Thickbrick Sleaford: oh
• [14:54] Youri Ashton: it runs on 64bit machines, it just reverts back to 32bit mode
• [14:54] Robin Cornelius: ok thanks, i was just wondering if there was an edge case where the location of the shared memory because impossible for the 32bit plugin to access
• [14:54] Youri Ashton: when sl closes, it returns to 64bit
• [14:54] Robin Cornelius: but you seem to have cleared that up
• [14:55] Robin Cornelius: Youri we are actually running the viewer as a 64bit application
• [14:55] Youri Ashton: think that is the main thing to focus on now, all those tools are nice n all, but what do you have on tools if you cant really use the viewer that well?
• [14:55] Dzonatas Sol: np =)
• [14:55] Youri Ashton: no, its running as 32bit program :p
• [14:56] Robin Cornelius: i can assue you that on my Dz's Carjays, Alerics and Tecwolfs system it is 64bit
• [14:56] Merov Linden: ok, we have this "Support for 64 bit" as something to do
• [14:56] Carjay McGinnis: yes, native 64 bit
• [14:56] Youri Ashton: yes merov, highest priority if you ask me
• [14:57] Merov Linden: I suppose Youri is talking about providing binaries
• [14:57] Merov Linden: right?
• [14:57] Youri Ashton: testers for snowglobe, or any viewer just can not work propperly without that on a 64bit machine
• [14:57] Youri Ashton: yes merov
• [14:58] Dzonatas Sol: Not having to build the plugins makes working on the viewer alot easier as in a major dent
• [14:58] Youri Ashton: some basic support for it may help out a lot
• [14:58] Merov Linden: my problem here is identifying build machines and quite a bit of script to change
• [14:58] Youri Ashton: should be added merov
• [14:58] Youri Ashton: with time the 32bit machine will dissapear
• [14:59] Youri Ashton: so it is kinda forced upon you :p
• [14:59] Shorahmin Femto: does anyone remember 16 bit lol
• [14:59] Merov Linden: I do!
• [14:59] Youri Ashton: dont even mention the 128bit machines that will come with time!
• [14:59] Merov Linden: :)
• [14:59] Dzonatas Sol: 64bit plugins is not an immediate need, as being able to use 32bit means it's not a showstopper issue
• [15:00] Youri Ashton: 128bit may only be 10 years from now, so is LL willing to get that far behind on the truth?
• [15:00] Merov Linden: I remember writting a dithering algorithm to display 24 bits images on an 8 bit display
• [15:00] Merov Linden: you guys were all in K at the time I bet :)
• [15:00] Youri Ashton: i started with the 386 :p
• [15:00] Merov Linden stops talking about old time
• [15:00] Youri Ashton: 286 even
• [15:00] Twisted Laws: i started on 8-bit
• [15:01] Pixel Gausman: Merov: you carved source code onto stone tablets back in those days?
• [15:01] Merov Linden: Twisted: I knew it! :)
• [15:01] Thickbrick Sleaford: /anyway, building on 64 bit is in some way more important than 64 bit binaries, because every day the build is broken in that enviroment we are losing potential devlopers
• [15:01] Twisted Laws: haha
• [15:01] Merov Linden: Pixel: punch cards!
• [15:01] Dzonatas Sol: I started with nybbles
• [15:01] Shorahmin Femto: I started with a bendiz paper tape machine and graduated to a 1620 punchcard machine
• [15:01] Merov Linden: my first Landsat image was a stack of punch cards
• [15:01] Shorahmin Femto: bendiz*
• [15:01] Robin Cornelius: +1 Thickbrick, a message from the autobuilder it broke, will get a bunch of us jumping on it
• [15:01] Twisted Laws: hmmm i worked on landsat
• [15:02] Youri Ashton: im just 27, so kinda am behind on most of you :p
• [15:02] Shorahmin Femto: the meeting must be over...
• [15:02] Merov Linden: you think twice when you need 2 passes on your image...
• [15:02] Merov Linden: ok, yes, we're over time
• [15:02] Morgaine Dinova: UXIG starting now, this zone, other end.
• [15:02] Pixel Gausman: later, hippos
• [15:02] Youri Ashton: later pixel
• [15:03] Thickbrick Sleaford: did we talk abotu SNOW-238 ? I thought that's a flamewar witing to happen
• [15:03] Add SOCKS 5 proxy support
• [15:03] Merov Linden: taht was a very good meeting with, of course, a few action items for me
• [15:03] Morgaine Dinova: Thanks Merov
• [15:03] Robin Cornelius: heh no
• [15:03] Youri Ashton: thanks for this meeting merov!
• [15:03] Carjay McGinnis: thanks, Merov
• [15:03] Shorahmin Femto leaves mumbling to himself media api, standalone, 32/64/128 screammmm
• [15:03] Youri Ashton: and please, try to find something on the 64bit problem for me :p
• [15:03] Robin Cornelius: i propsosed some damage limitation to merov on IRC for 238
• [15:03] Dzonatas Sol: thank you everybody!
• [15:03] Youri Ashton: kinda relly annoying :p
• [15:04] Twisted Laws: thanks and cyas later
• [15:04] Merov Linden: Robin: yes, I fired a question to ChrisC who owns the definition of that work load
• [15:05] Ardy Lay: As I sit here and stare at my computer would somebody briefly explain what would improve for the end user when he finds a 64 bit client to compare with the current 32 bit client?
• [15:05] Robin Cornelius: ok thanks, we need to be careful or us and opensource will get the shitty end of the stick over the proxy issue
• [15:05] Robin Cornelius: it will be held as another example of bad opensource stealing content and hiding there tracks, when infact LL want this for cooporate customers behind firewals
• [15:06] Merov Linden: yeap
• [15:06] Youri Ashton: think ill be hopping as well
• [15:06] Youri Ashton: bye bye everyone!
• [15:06] Thickbrick Sleaford: A certain someone can surely tie those both together with the communis agenda
• [15:06] Thickbrick Sleaford: *communist
• [15:07] Morgaine Dinova: Robin: there's no stopping the clueless making clueless remarks, they're designed for it. Just ignore those criticisms.
• [15:07] Merov Linden: ah! that's our Godwin point :)
• [15:07] Thickbrick Sleaford: heh, yeah
• [15:07] Morgaine Dinova: See you all peeps, off to UXIG
• [15:07] Merov Linden likes the "stalmanites" references too
• [15:08] Thickbrick Sleaford: see you everybody
• [15:08] Merov Linden: see you :)
• [15:08] Robin Cornelius: Ok i'm heading to bed, Merov, i'll wait for a ping re Chris's reply
• [15:08] Ardy Lay: Is it solely for the application to have access to more memory address space?
• [15:08] Carjay McGinnis: night Robin
• [15:09] Ardy Lay: Or am I missing something important?
• [15:09] Robin Cornelius: Night all
• [15:09] Dzonatas Sol: Ardy, 32 bit is limited to about 2-3 Gb addressable space, 64GB goes well, beyond
• [15:09] Dzonatas Sol: dtc
• [15:09] Dzonatas Sol: tc
• [15:09] Ardy Lay: Only reason to need wider pointers then?
• [15:10] Merov Linden: ok, need to attend some commits now :)
• [15:10] Merov Linden: cheers!
• [15:10] Dzonatas Sol: big faster better more
• [15:10] Ardy Lay: Have fun Merov.
• [15:10] Carjay McGinnis: laters
• [15:11] Ardy Lay: I can't imagine waiting for a frame needing more than 2GB of textures to render.
• [15:11] Ardy Lay: Would be awesome boring.

Generated with SLog Wikifier