Open Source Meeting/2010-05-11

Agenda Tuesday, 11 May 2010

1. Weekly Snowglobe update - Merov Linden
2. SNOW-646 SG 2.0.1, VC90, runtime error "The following Media Plugin has failed: media_plugin_webkit"
   • Possible Solutions? ---Nicky Perian 02:20, 11 May 2010 (UTC)
3. SNOW-643 Discuss possible solutions to enum 33bit problem

If we run out of topics before the end of the meeting, we'll triage Snowglobe or Open Source specific Jira Issues from the list below.

Note: We only had time for the main agenda, didn't discuss any additional jira issues from the list below, so they'll stay on the agenda list for coming meeting(s).

Jira Issues

1. SNOW-649 Changeset 3349 added unit test to llplugin but forgot LL_TESTS, resulting in a build failure in lltut.cpp
2. SNOW-650 Tries to build pulseaudio when pulseaudio not found.
3. SNOW-651 Standalone build failure r3349, cmake error on SLPlugin
5. Unscheduled SNOW issues triage: would be good to go with the community through those and decide for some what we should take immediately (2.0 or 1.4) or later.

Transcript

[14:01]	Ardy Lay:	Hi Merov
[14:01]	Merov Linden:	Hi guys
[14:01]	Nicky Perian:	Hi all
[14:01]	Merov Linden:	small crowd today...
[14:01]	Merov Linden:	minuscule...
[14:02]	Merov Linden:	the best of course... :)
[14:02]	Nicky Perian:	there was a sign up yesterday about no meeting this week
[14:02]	Ardy Lay:	Merov, remember that app URI I showed you Thursday? I commented out the code that makes it work.
[14:03]	Merov Linden:	which app URI Ardy?
[14:03]	Ardy Lay:	The sign I saw said no bug triage, which I took to apply to Soft Linden's Monday meeting here.
[14:03]	Merov Linden:	That was the Monday public bug triage I guess
[14:03]	Merov Linden:	not me...
[14:03]	Nicky Perian:	ok
[14:03]	Merov Linden:	I would have posted on opensource-dev
[14:04]	Ardy Lay:	secondlife:///app/chat/<channel>/<message>
[14:04]	Nicky Perian:	it did say triadge
[14:04]	Merov Linden:	a right, Ardy! I remember now
[14:04]	Merov Linden:	did you log that in a JIRA
[14:04]	Merov Linden:	?
[14:04]	Ardy Lay:	Merov, I borke it in my source tree as I am a social area moderator and we use chat command to control our moderation tools.
[14:05]	Ardy Lay:	Well, I can make one for it if we want to consider it a bug or something.
[14:05]	Merov Linden:	yeah
[14:05]	Merov Linden:	that is a bug, at least a problem as you mentioned
[14:05]	Merov Linden:	will make it easier to pass to the relevant folks managing griefing and such
[14:06]	Ardy Lay:	Okay, I'll create
[14:06]	Merov Linden:	thanks! :)
[14:06]	Merov Linden:	k, I think we should start anyhow since the folks who brought up some specific issues are there
[14:07]	Merov Linden:	first update on SG2.0 trunk: I synced with the internal "viewer-public" (2.0.2) and now working on getting that hooked and automatic!
[14:08]	Thickbrick Sleaford:	cool!
[14:08]	Merov Linden:	still some stuff to do internally but I expect to be done soon
[14:08]	Nicky Perian:	I pdated and built form that this morning
[14:08]	Nicky Perian:	updated
[14:08]	beer whispers:	Thanks from Sky Lounge!
[14:08]	Guinness Stout	whispers: Happy St. Patrick's Day
[14:09]	Merov Linden:	in the meantime, I'll do daily update and will turn on a script to get commit comment in clear
[14:09]	Merov Linden:	pffew..
[14:09]	Merov Linden:	getting there with this strategy at last
[14:10]	Merov Linden:	now, Nicky Perian suggested we talk about SNOW-646
[14:10]	1 and	2.0.2.3349 builds under VC90 without error but, run time has "The following Media Plugin has failed: media_plugin_webkit
[14:11]	Merov Linden:	I looked only rapidly at the Copy3rdPartyLibs9 diff
[14:11]	Merov Linden:	seems like you're not keeping backward compatibility wth VC8, correct?
[14:11]	Nicky Perian:	these are me first so there may be form problems 'no
[14:11]	Nicky Perian:	i havenet
[14:12]	Merov Linden:	hmmm, that's a problem
[14:12]	Merov Linden:	I'm pretty much stuck with vc8 here for a couple of months
[14:12]	Nicky Perian:	ok, I may need to rewrite some of
[14:12]	Nicky Perian:	it
[14:13]	Nicky Perian:	I just want ti get vc90 working
[14:13]	Merov Linden:	yeah, overall though, I like the idea
[14:13]	Merov Linden:	it's time we move to vc9
[14:13]	Boroondas Gupte:	does vc90 work with these patches or is more needed?
[14:13]	Merov Linden:	the only problem we have internally are with tools we use that do not work with vc9 yet
[14:13]	Nicky Perian:	builds w.o error
[14:14]	Thickbrick Sleaford:	BTW, to get (a little) more info on what goes wrong with loading the dll, you can uncmment the line that sets up the log file in main() in llplugin/slplugin/slplugin.spp
[14:14]	Nicky Perian:	but run time issues
[14:14]	Merov Linden:	or just starting to (like Incredibuild)
[14:14]	Nicky Perian:	ok
[14:14]	Thickbrick Sleaford:	that line = // LLError::logToFile("slplugin.log");
[14:15]	Nicky Perian:	ill give it a try
[14:15]	Merov Linden:	that being said, there's pressure also internally to move to VC9 so it's going to happen soon
[14:15]	Boroondas Gupte:	We need more verbose error messages for end users, too. There's quite some "The following Media Plugin has failed: media_plugin_webkit" issues on jira and the forums ...
[14:16]	Merov Linden:	Nicky, do you think you can work on those patches t make them vc8/vc9 compatible?
[14:16]	Merov Linden:	there's quite a bit of common stuff so some factoring seems to be in order
[14:16]	Merov Linden:	too
[14:16]	Nicky Perian:	yes but ir is a streach
[14:16]	Nicky Perian:	technically for me
[14:16]	WolfPup Lowenhar:	speaking of vc9 i still can not get sg V2 to compile on v9
[14:16]	Merov Linden:	Boroondas: you're right about the message and I think there's a JIRA on this
[14:17]	Merov Linden:	actually, I think I logged it IIRC...
[14:17]	Boroondas Gupte:	:-)
[14:17]	Thickbrick Sleaford:	there's also SNOW-440
[14:17]	Media plugins	have no way to log errors.
[14:17]	Merov Linden:	Nicky: OK, I might be able to help you on the cmake magic to refactor it
[14:17]	Nicky Perian:	ok
[14:18]	Merov Linden:	I'm no cmake guru but I know people who are :)
[14:18]	WolfPup Lowenhar:	it need to be figured out how to get it so that develop.py will also build for vc10
[14:18]	Nicky Perian:	some of the global variables in the python scripts baffle me
[14:18]	Merov Linden:	well, I'm going to assign 646 to me so to keep it under the radar
[14:19]	Merov Linden:	*on* the radar
[14:19]	WolfPup Lowenhar:	or rather vc100
[14:20]	Boroondas Gupte:	btw, is that already fully supported by CMake?
[14:20]	Merov Linden:	"hat" being?
[14:20]	Merov Linden:	"that" being? VC9?
[14:20]	Boroondas Gupte:	vc100
[14:20]	WolfPup Lowenhar:	i moded the develop.py to include VC100 but when it wen to launc cmake it failed
[14:21]	Merov Linden:	I don't know
[14:21]	Boroondas Gupte:	I tried to google around when the topic came up on the mailing list, but only found something about beta support
[14:21]	Merov Linden:	we should shoot a question to the Kitware folks
[14:22]	WolfPup Lowenhar:	there is not even a set of boost files for VC100 had to make then useing the newest boost files and those will not even make right
[14:22]	Merov Linden:	we have other cmake issues to discuss with them anyway
[14:22]	Ardy Lay	creates http://jira.secondlife.com/browse/SNOW-652
[14:22]	APP URI	to cause viewer to chat a specified message on a specified channel can be used to cause problems for others.
[14:23]	Merov Linden:	thanks Ardy!
[14:23]	Boroondas Gupte:	btw., is the guy behind the easybuild project still around? IIRC develop.py was planned to be removed completely, sometime.
[14:24]	Merov Linden:	Ha! You're right, that's why we need to talk to them
[14:24]	Merov Linden:	:)
[14:24]	Boroondas Gupte:	ah, cool
[14:24]	Merov Linden:	I've been told there are still some dangling issues with that
[14:24]	Boroondas Gupte:	wasn't sure whether that was abandonned, as that was quite some while ago
[14:24]	Merov Linden:	I need to check with the build folks (robla handled that relationship with Kitware and passed it to them when leaving)
[14:25]	Merov Linden	thinks there's lots of cmake hackery in his future
[14:26]	WolfPup Lowenhar:	i just built the viewer agian after updating from the SVN servers sinf you emailed about the updated merov and the new viewer crashes on loging in
[14:26]	Merov Linden:	I think we were collectively under pressure and dropped that easybuild ball
[14:27]	Merov Linden:	it's time to pick it up before we get too far down the next big release...
[14:27]	Techwolf Lupindo:	made it....
[14:27]	WolfPup Lowenhar:	hey tech
[14:27]	Boroondas Gupte:	o/
[14:27]	Techwolf Lupindo:	arg....no warning that this was going on.....
[14:27]	Techwolf Lupindo:	What I missed?
[14:27]	Merov Linden:	crashed on loggin... not good... :(
[14:28]	Merov Linden:	on Linux I suppose?
[14:28]	WolfPup Lowenhar:	it can not even send the log files
[14:28]	Merov Linden	didn't crash on Windows
[14:28]	WolfPup Lowenhar:	im running win 7 32-bit
[14:28]	Merov Linden:	I'm running XP...
[14:28]	Techwolf Lupindo:	I'me not sure if I made a jira or not. But any paramerter that the client does not reconized results in a crash
[14:29]	Nicky Perian:	I built with 9 on vista 32 and no crash
[14:29]	Techwolf Lupindo:	So if you typo a command line paramater, crash.
[14:29]	Nicky Perian:	just no webkit
[14:29]	Merov Linden:	latest Nicly? I mean: as of this morning?
[14:29]	WolfPup Lowenhar:	my build last week is stable and that is what im useing now
[14:29]	Nicky Perian:	yes
[14:29]	Nicky Perian:	latest
[14:29]	Nicky Perian:	2249
[14:30]	Nicky Perian:	3349
[14:31]	Merov Linden:	WolfPup: could be the plugins indeed... (used to display the splash screen)
[14:31]	Boroondas Gupte:	techwolf, we were discussing SNOW-646 and drifted away, or something
[14:31]	Merov Linden:	worth trying without them
[14:31]	Merov Linden:	well: we drifted from build to VC9 to easybuild
[14:31]	Merov Linden:	which are somewhat related
[14:31]	Merov Linden:	but yes, back to the agenda
[14:32]	WolfPup Lowenhar:	splas screen works fine it is when i got and click login on the viewer that it crashed
[14:32]	Aleric Inglewood:	Oh, I have a remark about easy build:
[14:32]	Merov Linden	hold his breath
[14:32]	Techwolf Lupindo:	I remember encountering that issue and it was due to linkage issues.
[14:33]	Aleric Inglewood:	The current state of the SVN is such that it is impossible, even for an expert to build the viewer without being hand held and getting personal help on IRC from a guru like Michelle.
[14:33]	Aleric Inglewood:	At least, the standalone build.
[14:33]	Aleric Inglewood:	That is not easy
[14:33]	Aleric Inglewood:	I downloaded the 2.0 sources today and gave up compiling it.
[14:33]	Boroondas Gupte:	I think for standalone that's always been the case.
[14:33]	Techwolf Lupindo:	Aleric, the easy build branch was 1.x and was merged. However, the 2.0 stuff badly broke it.
[14:34]	Merov Linden:	I don't recall easybuild was suppose to build standalone
[14:34]	WolfPup Lowenhar:	ok just checked the last cras log and found something interesting
[14:34]	Merov Linden:	it was supposed to gather the binaries in lieu of develop.py
[14:35]	Nicky Perian	thinks we spend way to much time and effort on build issues
[14:35]	Boroondas Gupte:	Well, I think the build process got CMake-y-fied with easybuild, which helped for standalone, too (a bit)
[14:35]	WolfPup Lowenhar:	found where the crash is occureing
[14:35]	WolfPup Lowenhar:	2010-05-11T21:01:53Z ../../llui/llpanel.cpp(622) : error 2010-05-11T21:01:53Z ERROR: LLPanel::getString: Failed to find string no_one_filtered_near in panel panel_people
[14:36]	Techwolf Lupindo:	I've gotten to know the build system pretty well now, except for LL internial stuff. Last night I pulled the lastes svn and filed three build breaking jiras.
[14:36]	Merov Linden:	Nicky: that's a problem woth FLOSS projects tryin to be built on a variety of OSes and environment.
[14:36]	Nicky Perian:	kk
[14:36]	Aleric Inglewood:	Well... the name "easybuild" might be confusing me when it's not intended to easily build the viewer, including standalone. LL is not supporting 64bit for some reason, and also not supporting standalone... so.. it's ... hard to compile on 64bit :/ It seems to always be broken.
[14:37]	Boroondas Gupte:	64bit (and standalone) get broken, because they don't get tested (because they're not officially supported). That hasn't too much to do with the build system, AFAIK.
[14:37]	Merov Linden:	"easybuild" intent was to support the 3 build we support off the gate: Mac, Windows, Linux 32
[14:38]	Merov Linden:	I don't know of a plan to build for Linux or Windows 64 bits internally
[14:38]	Merov Linden:	right now, we have lots of issues supporting new residents on low end machines... :/
[14:39]	Techwolf Lupindo:	If LL desides to create a project to fix the build system, I want to join. The more I work with cmake and LL build, the more I see that someone in LL was thinking C/C++ when doing the cmake files. I like to strighten out the cmake spaggitte mess, but that require me to be compensated somehow as I don't have that much free time to put into it.
[14:39]	Ardy Lay:	Merov, decent CPU and memory but crappy GPU?
[14:39]	Merov Linden:	Ardy: what we call "class 0" machines: crappy GPU and crappy CPU...
[14:40]	Merov Linden:	mostly Windows
[14:40]	Ardy Lay:	Ouch
[14:40]	Merov Linden:	that's what's out there :(
[14:40]	Techwolf Lupindo:	With netbook getting popular, low end hardware is going to be the norm.
[14:40]	Merov Linden:	on 3rd party libs though, there is the Autobuild project brewing
[14:41]	Merov Linden:	it's far from ready though
[14:41]	Merov Linden:	but that should make standalone building far easier
[14:41]	Thickbrick Sleaford:	WolfPup, about your crash, it sounds like you're missing (or have an old version of) panel_people.xml (or one of it's lacalized versions)
[14:41]	Merov Linden:	I hope to have more news on this in the coming weeks
[14:42]	Merov Linden:	k, can we move to the next issue? SNOW-643, by Techwolf
[14:42]	Water flickers	and disappears in patches (Snowglobe 2.0 clone of VWR-12984)
[14:42]	WolfPup Lowenhar:	did a ful SVn update this morning and that file was one that udtated
[14:42]	Techwolf Lupindo:	Merov, No. That will make it harder. Instead of prebuilt or use system liberies, we will have one more, build prebuilt against sytstme liberies, talk about depensity hell when linking.
[14:42]	Aleric Inglewood	pokes Thinkbrick
[14:42]	Aleric Inglewood:	Thick*
[14:43]	Thickbrick Sleaford:	ouch, "hey!"
[14:43]	WolfPup Lowenhar:	if any one want to look at the log it is here http://tinyurl.com/2e4u68g/SecondLifeCrashReport
[14:43]	Aleric Inglewood:	I was going to help with SNOW-643, but I need to be able to compile 2.0 before I can test any changes.
[14:44]	Merov Linden:	Techwolf: I see your point...
[14:44]	Thickbrick Sleaford:	it looks like the question is do we want to go the route of having a U64 mask?
[14:44]	Merov Linden:	Aleric: what prevents you to build 2.0?
[14:45]	Aleric Inglewood:	That would definitely be the easiest way. But ... personally my main goal is to get this patch as-is in the official viewer. So, the question is: do the internal devs want that too?
[14:45]	Techwolf Lupindo:	"Can RENDER_TYPE_PASS_* be moved into its own enum?"
[14:45]	Aleric Inglewood:	Merov: missing header files that I can't seem to find on the net.
[14:45]	Merov Linden:	? darn!
[14:45]	Aleric Inglewood:	(of libraries no doubt)
[14:46]	Boroondas Gupte:	We might not need masks at all, as Aleric mentioned on IRC. We could just compaire against the plain enum values, instead of doing bitwise logic gymnastics.
[14:46]	Merov Linden:	which ones?
[14:46]	WolfPup Lowenhar:	http://tinyurl.com/2e4u68g
[14:46]	Merov Linden:	it makes sense to do bitwise gymnastic only if you want to pack several values in a compounded integer
[14:47]	Merov Linden:	otherwise, it's just waste of code
[14:47]	Aleric Inglewood:	Merov: I copied indra/llwindow/glh from 1.4, and then ran against boost/coroutine/coroutine.hpp
[14:47]	Merov Linden:	so the question is, do we pack the flags in a mask?
[14:47]	Boroondas Gupte:	well, they're mutually exclusive
[14:48]	Techwolf Lupindo:	Aleric, I have the links for coroutine for you.
[14:48]	Merov Linden:	Aleric: ah, this pesky glh!!
[14:48]	Boroondas Gupte:	(or so it seems)
[14:48]	Merov Linden:	there's a JIRA assigned to me to fix that once and for all
[14:48]	Merov Linden:	grrr...
[14:48]	Aleric Inglewood:	I think the masks are only used to speed up a test of the form:
[14:48]	Aleric Inglewood:	if (var == possibility1	var == possibility3	...
[14:49]	WolfPup Lowenhar:	aleric which os you running?
[14:49]	Aleric Inglewood:	Instead they do:
[14:49]	Aleric Inglewood:	U32 mask = (1 << pos1 | 1 << pos2 | ..)... and then if (var & mask)
[14:50]	Aleric Inglewood:	Now, if those 'masks' are 'classes', then how many ... whats the mathematical word...
[14:50]	Aleric Inglewood:	sets that are never subdivided...
[14:50]	Merov Linden:	wait: may be var can be pos1 and pos2 then
[14:50]	Aleric Inglewood:	Ie, we have classes (sets): A, B and C, and masks A+B, and B+C.
[14:51]	Thickbrick Sleaford:	it looks like LLPipeline::hasRenderType is a candidate to do that (use flag1|flag2) but it doesn't.
[14:51]	Merov Linden:	and the tested that way further down
[14:51]	Aleric Inglewood:	Then it should be possible to set bits for classes, not elements of the sets.
[14:51]	Aleric Inglewood:	Thus instead:
[14:51]	Aleric Inglewood:	0001
[14:51]	Aleric Inglewood:	0010
[14:51]	Aleric Inglewood:	0100
[14:51]	Aleric Inglewood:	1000
[14:51]	Aleric Inglewood:	if the first two are in class A, and last two in class B, we do:
[14:52]	Aleric Inglewood:	0001
[14:52]	Aleric Inglewood:	0101
[14:52]	Aleric Inglewood:	0010
[14:52]	Aleric Inglewood:	0110
[14:52]	Aleric Inglewood:	where the last two bits are the class bits, and the first two enumerate the elements.
[14:52]	Aleric Inglewood:	and see: only three bits needed ;)
[14:54]	Aleric Inglewood:	It's just an idea... and would only be Right if those bitwise AND tests are indeed testing for render-type classes - which I don't know for sure until I'd understand all of it... :/ .. I just know for sure that it would work for a 'water class'.
[14:54]	WolfPup Lowenhar:	aleric but that only would give you a max of four 'clases' with four posibilities in each if you use 4 bits
[14:55]	Merov Linden:	yeap, I'm a bit worry of mucking with something that modifies rendering in unexpected ways...
[14:55]	Aleric Inglewood:	wolf: it was an example, you want me to give an example with 32 bits here?
[14:55]	WolfPup Lowenhar:	you want me type for the next 3 hours :?
[14:56]	Techwolf Lupindo	grins
[14:56]	Techwolf Lupindo:	Let see you type that out with any typos. lol
[14:56]	Boroondas Gupte:	I can write a python script to generate 32 bit examples, to save some typing ;-)
[14:56]	WolfPup Lowenhar:	that would be a miricale tech
[14:56]	Merov Linden:	k, the question on that render type so is to know if some of those values are stirctly exclusive
[14:56]	Aleric Inglewood:	Merov: I can garantee that it would work fine if I code it :p .. with not "right" I mean that it might confuse the internal dev next time (IF they adopt it at all) would start to change things again. I feel it is correct, but I didn't look very close to the source yet. If being correct than the result would only be that things are more robust and more maintainable imho
[14:56]	Merov Linden:	those don't need to be bitmasked
[14:57]	Thickbrick Sleaford:	I think tit would be less disruptive to move the RENDER_TYPE_PASS_* values to a different enum, if that's possible
[14:59]	Nicky Perian:	afk
[14:59]	Aleric Inglewood:	Thickbrick: it isn't necessarily the most logical thing to do though.
[14:59]	Merov Linden:	some of those are clearly exclusive: render type can't be sky, ground and grass all at the same time
[14:59]	Aleric Inglewood:	We can only know what is logical after understanding the current code.
[14:59]	Merov Linden:	+1 Aleric
[15:00]	Merov Linden:	it's hard to propose a solution looking at just this little keyhole...
[15:00]	Techwolf Lupindo:	I havn't tried to change U32 to U64 and see how it breaks.
[15:00]	Aleric Inglewood:	Look at setRenderType
[15:00]	Aleric Inglewood:	void setRenderType(S32 type) { mRenderType = type; } BOOL isRenderType(S32 type) { return mRenderType == type; }
[15:00]	Aleric Inglewood:	That doesn't look like they are bitmasks at all
[15:00]	Aleric Inglewood:	looks very exclusive
[15:01]	Merov Linden:	so I'd have a tendency to trust you with bringing up a good solution
[15:01]	Thickbrick Sleaford:	same goes for hasRenderType
[15:01]	Merov Linden:	knowing how deep it can run though, we may have to get Runitai to review the proposal before committing
[15:01]	Thickbrick Sleaford:	BOOL hasRenderType(const U32 type) const { return (type && (mRenderTypeMask & (1<<type))) ? TRUE : FALSE; }
[15:02]	Aleric Inglewood:	Merov: he is the internal dev? I'd really like to get approval and/or cooperation from the internal dev that has to add this to the official viewer, so we know they will do it.
[15:03]	Merov Linden:	he's the one who knows the rendering engine the best, not that he is the coder of that particular piece of code
[15:03]	Merov Linden:	at least, he'd be able to orient us to the next best person if he can't do the review
[15:05]	Merov Linden:	so, Aleric, do you feel like proposing a patch for this and I'll get Runitai and al. to review/comment?
[15:06]	Aleric Inglewood:	It would help if I could compile the viewer though, then yes.
[15:06]	Merov Linden:	he, right...
[15:06]	Boroondas Gupte:	we can help with that (probably)
[15:06]	Techwolf Lupindo:	Aleric, ping me after this OH. I can help you with that.
[15:07]	Aleric Inglewood:	I guess - anyone here on 64bit linux who can compile the viewer? Preferably debian?
[15:07]	Techwolf Lupindo:	here.
[15:07]	Merov Linden	ducks
[15:07]	Boroondas Gupte:	64bit gentoo here
[15:07]	Aleric Inglewood:	Techwolf: ok, got time now, after the meeting? :)
[15:07]	Merov Linden:	OK, it's 3pm and I need to run
[15:07]	Merov Linden:	great to have dug deep on those 2 issues
[15:07]	Techwolf Lupindo:	yep. I'll put off looking for work some more. heheh
[15:08]	Merov Linden:	see you Thursday guys
[15:08]	Thickbrick Sleaford:	see you
[15:08]	WolfPup Lowenhar:	tc merov
[15:08]	Aleric Inglewood:	bye Merov
[15:08]	Aleric Inglewood:	lets use IRC TechWolf

Generated with SLog Wikifier