Open Source Meeting/2010-02-18

== List of Attendees ==
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
*
== Transcript ==
[14:00]	:	I was inspired by it and by what Robin has been doing recently
[14:00]	:	ok guys, the clock struck 2pm
[14:00]	:	time to get in with our meeting
[14:00]	 	gets the agenda
[14:00]	:	Evil Rabbit I pull your Right Ears Long.
[14:00]	:	hehe
[14:01]	:	http://wiki.secondlife.com/wiki/Open_Source_Meeting/Agenda
[14:01]	:	so we have a couple of 1.3 bugs first to discuss
[14:02]	:	The true show stopper is SNOW-431
[14:02]	:	http://jira.secondlife.com/browse/SNOW-431
[00:00]	:	[#SNOW-431] Boost downloads for Snowglobe 1.3 aren't really 1.39.0
[14:02]	:	I'm still waiting for Brad on that one
[14:02]	:	I saw you fired a buld this week and it failed but the logs were not accessible out side LL
[14:02]	:	is it really a showstopper? it's annoying, but mostly from a FTBFS angle.
[14:02]	:	I'd be doing it myself if I wasn't so busy with Snowglobe rebasing...
[14:03]	:	well: we are in the (good) habit of providing source code tarballs for official builds and that one is tainted by that
[14:04]	:	that's why I'm considering it as show stopper
[14:04]	:	Does he need a gentle poke?
[14:04]	:	he's sticking next to me today
[14:04]	:	a subitle bottle of wine ;-)
[14:04]	:	let me try kick his chair
[14:04]	 	does this
[14:04]	:	Haha
[14:04]	:	Some of those pre-built tarballs contain patches by LL, Where are those patches?
[14:05]	:	he said "oho!"
[14:05]	:	counter it with an "aha!"
[14:05]	:	Techwolf: good point, we should do tarballs for them and make them public too
[14:05]	:	ohh that would be good
[14:06]	:	there's nothing sikrit in them as far as I know
[14:06]	:	that would instantly solve 2008 issues by making rebuilds easy
[14:06]	:	Like the openjpeg patches. The webkit patches can be gleemed from the linden hg site, but that all the patches I have found so far.
[14:06]	:	more things like work around bugs or specific compile options we use
[14:07]	:	Techwolf: those are the "real" (serious code) patches
[14:07]	:	the others, at least, the ones I've been looking into are really super minor
[14:07]	:	some of these are caused by old versions, xmlrpc is still 0.51 used by LL
[14:07]	:	it's really a matter of kicking my butt to get this posted somewhere
[14:07]	:	i didn't go to the trouble of hijacking that project and fixing the bugs for nothing ;-p
[14:08]	:	I think you're right Robin
[14:08]	:	actually, with the rebase, lots of those libs used are newer versions and use no patch at all
[14:08]	:	(which should make Techwolf happy)
[14:08]	:	yay
[14:08]	:	o/
[14:08]	:	I just wanted the patches that changed the code from what is found on a linux system source code from the source code LL uses to make the downloaable tarballs used in builds.
[14:09]	:	curl is a fun one, that is a custom build against c-ares, non standard WRT most linux distros
[14:09]	:	we should really have a JIRA on this
[14:09]	:	curl is indeed one
[14:10]	:	but that's one specifically which is all about building against c-ares and using some specific compile options
[14:10]	:	not a "patched" version really
[14:10]	:	true
[14:10]	:	I do the gentoo ebuilds on my overlay. Portage has the power to handle more then one verion or different libery. Or can use the patches and re-build the liberiases on the fly as part of the build process.
[14:11]	:	actually, I think that curl now uses cmake to build and that supports the c-ares options
[14:11]	:	anyhow, yes, 3rd party libs are a pain and minimizing the diff we need is good for everybody
[14:12]	:	ok, let's review those 2 bugs added to the agenda
[14:12]	:	i have 1/2 of a 3rd ;-p
[14:12]	:	SNOW-488
[14:12]	:	http://jira.secondlife.com/browse/SNOW-488
[00:00]	:	[#SNOW-488] Malformed animation crash
[14:12]	:	I just reviewed this and commented on it Robin
[14:13]	:	+1 to push into 1.3
[14:13]	:	it's odd but important if it avoids a crash
[14:13]	:	mass crashing more likely :p
[14:13]	:	mass crashing?
[14:14]	:	it took out 95% of a help island
[14:14]	:	oh! right...
[14:14]	:	thats how i got the UUID and backtrace
[14:14]	:	yes, even better then: commit!
[14:14]	:	Thanks Robin :)
[14:14]	:	next
[14:15]	:	SNOW-485
[14:15]	:	that one is more complex
[14:15]	:	I haven't reviewed all the attached files yet
[14:15]	:	ok the last one i uploaded is the most interesting the others from me are earlier versions of the same thing
[14:16]	:	I'm running on one of Robin's builds that has one of the earlier patches and I've not dead locked once.
[14:16]	:	i've not hit one deadlock issue since doing that, Sahkolihaa is running an earlier version no deadlocks
[14:16]	 	reading the patch
[14:17]	:	wow!
[14:17]	:	oh and launchpatd is building the latest ubuntu one as we speak
[14:17]	:	o/
[14:17]	:	it's really a tricky piece of code
[14:18]	:	its taken me a week to get to this stage
[14:18]	:	that needs testing and careful analysis really
[14:18]	:	I'm not surprised!
[14:18]	:	well, that needs testing for sure
[14:18]	:	ok well its up to you how to play this out
[14:18]	:	others able to build with that patch and test it?
[14:19]	:	i didn't had issues while testing Robin's build - but that was a limited testing
[14:19]	:	I've been running it for -hours-
[14:19]	:	hmmm... I wouldn't be confortable +1-ing that one without testing myself
[14:19]	:	Busy sandboxes, clubs, office meetings - no problem.
[14:19]	:	Good patch for an RC?
[14:20]	:	could you guys comment in the JIRA if you did test? even (especially) if you found no problem
[14:20]	:	Sure.
[14:20]	:	I am running at revision 3125 and not see issues but maybe silly me doesn't know what to look for.
[14:20]	:	I'll wait until I've gotten the latest ubuntu package though.
[14:20]	:	it always make me feel more confortable if I know other people have been using a patch
[14:20]	:	running with the patch here for the last 50 minutes - no problems so far.
[14:21]	:	all that seems good
[14:21]	:	i've been camping in help islands with it on windows for a few days
[14:21]	:	Ardy, you really can't miss a deadlock
[14:21]	:	hence the animation crash debug ;-)
[14:21]	:	well, give me a chance to apply and run locally at least for a day
[14:21]	:	ok?
[14:21]	:	sure its a fragile peice of code
[14:21]	:	my previous attempted leaked
[14:22]	:	yeap! been there and been biten already
[14:22]	:	that's why I'm cautious
[14:22]	:	i checked the request handles did sum to zero
[14:22]	:	I guess I am not getting exposed to what causes the issue the patch in 485 is to fix. Is there a consistent reproduction process I can look at?
[14:22]	:	Turn Rendinging->Run Multiple threads on for one
[14:22]	:	It's on
[14:23]	:	clear cache and visit busy aresa
[14:23]	:	Do that daily.
[14:23]	:	got to malls with lots of ventors
[14:23]	:	You don't suffer it then.
[14:23]	:	and have a fast multi-core computer
[14:23]	:	Lusk and Ahern
[14:23]	:	it does not effect everyone
[14:23]	:	Q6600 2.4GHz
[14:23]	:	It hits me hard but this build of Robin's can last 18+ hours.
[14:23]	:	That's good.
[14:23]	:	It was affecting me every 5-20 minutes until 3125 came out
[14:23]	:	pre SNOW-196 we had big issues
[14:23]	:	http://jira.secondlife.com/browse/SNOW-196
[00:00]	:	[#SNOW-196] Deadlock in LLTextureFetchWorker::lockWorkMutex / LLThread::lockData / LLTextureFetch::lockQueue
[14:24]	:	that got the worst offendoer out of the way
[14:24]	:	then we were left with the 485 one
[14:24]	:	oh and it appears to have sped up texture fetch a lot
[14:24]	:	Yeah, I noticed that.
[14:25]	:	ok, for 1.3 then, the plan is: get 488 committed, test 485, get it in or not (depending on test), then build
[14:25]	:	I started having deadlocks somewhere after 3109 and the ended somewhere near 3125.
[14:25]	:	Crazy stuff happened in that area
[14:25]	:	I'll try out the patch in 485.
[14:25]	:	Merov, will you make a RC with 485 in it in about 2 days?
[14:25]	:	then we can all get going and test the binaries at least
[14:26]	:	if the tests are good, yes
[14:26]	:	can make one tomorrow (Friday) night
[14:26]	:	I also wanted to drop in SNOW-492
[14:26]	:	http://jira.secondlife.com/browse/SNOW-492
[00:00]	:	[#SNOW-492] LLDataPacker::unpackstring() is unsafe
[14:26]	:	another animation crash bug
[14:26]	:	but its kind of still in progress as the actual crash was way more subitle than i expected
[14:26]	:	llwarns was dieing with a malformed/long string
[14:27]	:	sorry i'm late
[14:27]	:	on windows anyway, made my PC scream, Aleric on 64bit just got propper warnings
[14:27]	:	hmmm.... I see (just read the JIRA)
[14:27]	:	so the fix i added avoides the possibility of strlen() getting an unsafe buffer, but even a memory safe buffer can kill llwarns
[14:27]	:	I should add Soft as a watcher on that one
[14:28]	:	he's all over security issues these days
[14:28]	:	I can give you the UUID to trigger it
[14:28]	:	I suppose putting the UUID in the JIRA would be asking for troubles
[14:28]	:	i'm also not sure how many of these effect 2.0
[14:28]	:	Are these destructive assets deliberately created? Good for hardening either way.
[14:29]	:	that's something Soft will test for sure!
[14:29]	 	adds soft
[14:29]	:	soft has rewritten some of the sanity checks on animations
[14:29]	:	The FN sandboxes get hit on purpose with them.
[14:29]	:	It's -NOT- fun when I'm the only EM around and oh, I crash.
[14:30]	:	Oh Merov we also spotted a big issue with the sanity check code
[14:30]	:	^^^ it's not sane
[14:30]	:	it checks for a buffer overflow, sets a flag based on that, reads the buffer anyway, then returns based on status flag
[14:31]	:	well, that's something to signal to him for sure
[14:31]	:	ok, on 1.4 may be: the build I tried failed
[14:32]	:	saw that, could not access the build logs
[14:32]	:	Robin asked me about it already and I had no time to work on this :/
[14:32]	:	is it internal build server issues? or a problem?
[14:32]	:	Quickly OT - Robin, your snowglobe build built successfully (says on the web page).
[14:32]	:	whohoo
[14:32]	:	yeah, my time is super tight these days
[14:33]	:	super tight time can be fixed by applying time dilation :p
[14:33]	:	k, I'll spend a couple of hours tomorrow on those things so to unblock them
[14:33]	:	Wine helps
[14:33]	:	Wine doesn't help in my case...
[14:33]	:	Awwww
[14:33]	:	the drink or the emulator?
[14:33]	:	it makes the problem *seem* smaller
[14:34]	:	Wine is not an emulator :)
[14:34]	:	Wine Is Not an Emulator
[14:34]	:	Beat me to it.
[14:34]	:	jinx!
[14:34]	:	nice
[14:35]	:	so yeah, I've been *entirely* consumed by beating the crap out of the export scripting code for Snowglobe 2
[14:35]	:	doing sh and python like a maniac
[14:36]	:	Did it surrender?
[14:36]	:	it's almost there, really, and I hope you'll like it
[14:36]	 	wrote very Merov-resistant code
[14:36]	:	lol
[14:36]	:	^^
[14:36]	:	Is that hard? ,)
[14:36]	:	I just hope i've not wasted a lot of time fixing 1.3 if not of that is needed/portable
[14:36]	:	I'm working with CG actually today to solve some of the remaining issues
[14:37]	:	Robin: I think the code you touched is actually the same in 2.0
[14:37]	:	sweet
[14:37]	:	so the merge won't be hard
[14:37]	:	What do those "export scripts" do? AFAIK, unlike the Second Life Viewer, Snowglobe doesn't have different internal and external repos.
[14:37]	:	will have to recheck deadlocks though any mutex changes and its a whole new game
[14:38]	:	well, internally, all our code live in a giant repo, server and viewer mixed up
[14:38]	:	we have to untangle that
[14:38]	:	plus make sure we export things with the proper license
[14:38]	:	well what i touched is llcommon code, any chance the server could benifit from the fix?
[14:39]	:	it will, eventually
[14:39]	:	it might not actually be effected in anyway by the conquences of it, something i can't comment on not knowing its structure
[14:40]	:	anyway, cleaning up things to make them gpl compliant and all is a bit of work
[14:40]	:	I won't make the list of all the gotchas but I had to go through plenty
[14:41]	:	short story though: it's almost there and, though I don't think there's been an official date announced, it's going to be soon
[14:41]	:	(otherwise there'd be no point having me loose sleep about it...)
[14:41]	:	Coming with a public beta or a final release?
[14:42]	:	for Viewer 2.0 itself? wow! I don't know that schedule. I was talking about getting the Open Source Snowglobe 2.0 code out
[14:42]	:	ah
[14:43]	:	that's the version of Snowglobe rebased off Viewer 2.0
[14:43]	 	does an about take
[14:43]	:	The open beta for Viewer 2.0 was announced for "February", so I guess that'll still come before the final release.
[14:43]	:	Reading back, replacing all "2.0" by "Snowglobe 2.0"
[14:43]	:	So we might have SG 2.0 before the main Viewer 2.0 comes out?
[14:44]	:	I wont like any client 2.0 if its missing all the additional snowglobe stuff. ^^
[14:45]	:	Sg runs like greased lightning now ;-)
[14:45]	:	yah
[14:46]	:	And its pretty stable.
[14:46]	:	Tillie: Merovs working on adding SG juicy bits back in
[14:46]	:	the SG2.0 code will be out soon, yes *but*
[14:46]	:	suspense
[14:46]	:	I'd like to add that that code won't be the *official* SG2
[14:46]	:	I cant remember when I used the non-snoglobe client last. ^^
[14:46]	:	I have to turn off Basic Shaders in SG to get the same frame rate I do in Cool Viewer with Shaders on (it has a patch for an ATI bug)
[14:46]	:	*because* we'll still be missing some SG features like Login-OGP for instance
[14:47]	:	merci, for that Merov
[14:47]	:	but of course, to get help from Pixel on this, we need to get the code tree out
[14:47]	:	Jonathan: ati is working for you with SL? If I plug in the ati card I crash all the time.
[14:47]	:	Viewer2.0, unofficial SG2.0, and official SG2.0. /me moans
[14:47]	:	Morgaine: need a scorecard to keep up?
[14:48]	:	Yeah
[14:48]	:	haha
[14:48]	:	I know Morgaine, I moan too
[14:48]	:	it's simple in my head
[14:48]	:	"the viewer formerly known as..."
[14:48]	:	but for bizarre reason, I just can't explain that clearly
[14:48]	:	Yes Tillie, but your card must be different than my chip (a X1300)
[14:48]	 	thinks he should switch to French may be...
[14:49]	:	Next we'll have all the 3rd party viewers moving to 2.0, and we'll be still referring to "2.0". Babel was an anti-climax.
[14:49]	:	The viewer formerly known as ☥
[14:49]	:	Jonathan: ah you probably use the old drivers then that dont have problems yet. the 5850 crashes a lot with current drivers.
[14:49]	:	lol Sai
[14:50]	:	ok, try again: the source tree will available and open before we have an official SG2.0 binary release
[14:50]	:	makes sense
[14:50]	:	Call it SG 1.9999999
[14:50]	:	consider it as a SG2.0 trunk
[14:50]	:	lol
[14:50]	:	which, actually, will be its name
[14:51]	:	I just don't want people all over me complaining that this and that SG feature are still missing the day the tree goes public
[14:51]	:	makes sense?
[14:51]	:	Merov, if there are any crazy new dependencies any chance of a little heads up even off the record so some of us can get them in place on our repros
[14:51]	:	Merov: yup.
[14:51]	:	Merov: will the build process be the same for it?
[14:52]	:	It might help to make it more clear on the SG wiki page what's a "Test build" and what's a "release", for non-technical people
[14:52]	 	expects i have to port some of my features over to the new code
[14:52]	:	yes, the build process will be very much the same
[14:52]	:	(as in, will my current machine that i build on just work with 2.0?)
[14:53]	:	So the source will be a mostly patched snowglobe 2.0 then, lacking stuff your probably forgot. :P
[14:53]	:	Robin: yes, I'm counting on you for SOCKS5 :)
[14:53]	:	Tillie: lacking what he was *afraid* to port. :)
[14:53]	:	we need some UI work on that
[14:53]	:	Tillie: subversion doesn't forget anything...
[14:53]	:	Pixel: Or that part. That is the worse part. :P
[14:54]	:	Merov: will it still be svn?
[14:54]	:	or hg?
[14:54]	:	svn
[14:54]	:	How much demand is there for SOCKS5. Corps and Unis mostly, yeah?
[14:54]	:	I know, that's a surprise considering we're using hg interna;;y
[14:54]	:	Morgaine, i did that for LL's Enterprise department
[14:54]	:	well, at some point i keep expecting you guys to pul the big red hg switch on us
[14:55]	:	Robin: aha, makes sense
[14:55]	:	wouldn't the export scripts become much simpler when using hg for SG 2.0, too?
[14:55]	:	but it'll make our life easier merging from svn SG to that new branch
[14:55]	:	agree
[14:55]	:	do you plan to swith to hg after 2.0 is stabilized, or keep it svn for now?
[14:56]	:	Boroondas: not really, considering all I said before about the other code that is not gpl ready and the license check scripts and all
[14:56]	:	ic
[14:56]	:	Thickbrick: there is a plan internally to separate hg repos so we don't mix source code with different licenses in the same tree
[14:57]	:	then export will be as simple as "hg clone"
[14:57]	:	that'd be ideal
[14:57]	:	I would think that would have to be done before viewer 2.0 is put out also. re:gpl, licience, etc.
[14:57]	:	sounds like Merov is getting to do some hand weeding of the code
[14:57]	:	well, it wasn't
[14:58]	:	Will we still get sours tarballs for the standard viewer when 2.0 comes out?
[14:58]	:	*source*
[14:58]	:	hand weeding: it feels that way, very much!
[14:58]	 	hopes for Merov that hg has an equivalent of git's --filter-branch
[14:58]	:	[14:58] Oskar Linden: server beta office hours on ADITI now for anyone interested
[14:59]	:	Mm: i hope so, those are nice to have
[14:59]	:	Mm Alder: yes, creating those tarballs is mostly what I've been working on
[14:59]	:	[14:57] Jacek Antonelli: It's nearly time for everyone's favorite weekly UXIG meeting! Yay! http://slurl.com/secondlife/Hippotropolis/33/106/26
[14:59]	:	o right: 3pm
[14:59]	:	I don't mean from Snowglove SVN, I mean for 2.0 Hg.
[15:00]	:	Right now those tarballs been bianary only and I have been buging LL for the source. :-)
[15:00]	:	I heard you Mm Alder
[15:00]	:	Merov, keep us informed of whats happening,
[15:00]	:	Thanks, Merov
[15:00]	:	I will
[15:00]	:	i've got 1.3.1+ SNOW 485 tests out in the wild now
[15:00]	:	Merov: and thanks for sharing details with us here.
[15:00]	:	I've been silent on IRC and email 'cause I'm rushing right now
[15:01]	:	Question for anyone that can answer: What is this export/import stuff that was discussed porting over to snowglobe. Is it similar to emerl export/import feature?
[15:01]	:	Robin, if you can take a stab at http://jira.secondlife.com/browse/SNOW-472 some day I would be so happy
[15:01]	 	
[00:00]	:	[#SNOW-472] RenderDeferred / obsolete OpenGL libs in RC / FPS drops down to 2fps
[15:01]	:	but I'm confident we're moving in the right direction wrt Snowglobe
[15:02]	:	And Merov, a reasonable comment on the Client-side scripting thread on opensource-dev would be appreciated too. After Rob's departure, open source seems to be being abandoned, and the latest post on that list are not encouraging.
[15:02]	:	We want Rob 2.0!
[15:02]	:	and where there is only silence from LL, people tend to assume the worst
[15:03]	:	I want Rob2.0 too.
[15:03]	:	well, everyone seems to pounce in frothy foaming rantiness whenever a Linden posts to the list
[15:03]	:	Mm: +1 on Rob 2.0
[15:03]	:	Oh, and Hippo Awards too!
[15:04]	:	maybe we can clone() Merov to produce Rob 2.0?
[15:05]	:	Linden->getInstance("Merov").clone()
[15:05]	:	Don't mention the hippos, i may have to give my land up ;-p
[15:05]	:	Linden factory!
[15:06]	:	Sorry, Merov is a singleton. :-)
[15:06]	:	dang!
[15:06]	 	decides to head off back home.
[15:07]	:	Merov's probably reading the thread, went totally quiet.
[15:07]	:	anybody got a trascript of last week's meeting?
[15:07]	:	wow, the helicopters finally stopped (the airplane crash in austin was a mile away from my house today)
[15:07]	:	or Q's meeting, while we're at it?
[15:07]	:	Hi, am I too late? :)
[15:08]	:	lol Aleric
[15:08]	:	yes :-)
[15:08]	:	Merov poofed
[15:08]	:	He saw me!
[15:08]	:	scaaaaaared of me :)
[15:08]	:	Aleric, Oskar is meeting on the beta grid now in Morris
[15:08]	:	airplane crash in Austin?
[15:08]	:	Hi Thickbrick :)
[15:09]	:	hi
[15:09]	:	Hi Aleric
[15:09]	:	yes, a guy went whacko and drove into the IRS bulding here
[15:09]	:	Hi :)
[15:09]	:	Nah, wasn't you, Aleric. I asked him to comment on the Client-side scripting thread. That did it .... might be fearing for his job to break silence.
[15:09]	:	either that, or he went for the asbesthos underwear closet
[15:09]	:	The average LL employee has to sign 20 NDA's before they are allowed near a keyboard.
[15:09]	:	lol
[15:10]	:	Morgaine: My idea (re the 'ignore') is to ignore whatever LL is doing and just write our own client-side scripting.
[15:11]	:	I'm going over to see jackek
[15:11]	:	That's not a bad suggestion. But in which viewer?
[15:11]	:	Yeah, I need to head to UXIG too.
[15:12]	:	First question is: are we talking about private scripts that run local, or are we talking about scripts in objects that are downloaded to anyone and everyone that run client-side?
[15:12]	:	I like to see the plug-in API used and make a client side scripting plug-in using whatever engine the plug-in maker wants to use.
[15:12]	:	techwolf: that would be the first kind: a way to control your own client, but not the viewer of others.
[15:12]	:	Aleric, public scripts running client side.
[15:13]	:	It's two different use cases. I know I need local scripting that I write myself, and I certainly don't need a sandbox --- they need to integrate with local applications. But LL seems to have a downloadable crap in mind, hence the sandboxing.
[15:13]	:	And your opinion Morgaine?
[15:13]	:	The only way to have private scripts is what LL is currently doing. Running them on the server.
[15:14]	:	I think LL is aiming for the "put a script in an object and have everyone that passes it download it and execute it"... in which case mono and a sandbox make sense.
[15:14]	:	I'm not going to run any CLR binaries received off the net, that's for certain. And nor should anyone else that's not stupid.
[15:14]	:	While if you just want to write your own cyborg code, you want total control, in cluding sockets and disk access and third party libs etc
[15:14]	:	If it's safe, ...
[15:14]	:	Hahaha
[15:15]	:	So you you're only interested in running client-side scripts that you wrote yourself?
[15:15]	:	I have a bridge that I'll be selling to a lot of fools.
[15:15]	:	so how much additional work would it make for someone writing a viewer from scratch?
[15:15]	:	Aleric: I don't mind if multiple use cases are considered, as long as the power-scripter's use case is supported.
[15:15]	:	...and that viewer is in a browser sandbox env.
[15:16]	:	took the realXtend people about a year or so, to get to pre-alpha viewer
[15:16]	:	Pixel: I could do that, but I'd estimate it would take me 5 years on my own, maybe even 10. So, it's too much work for one person.
[15:16]	:	yeah, that's what i'm worried abt.
[15:17]	:	also, i dont want to drive up the compute requirements for the viewer. the poor thing struggles on woosie enterprise laptops as it is
[15:17]	:	We're not talking about a new viewer. We're talking about adding a scripting engine, plus an inner viewer API which hooks into it.
[15:17]	:	One of the main problems with any project like this is that there STILL is *no* portable library for basic things that are needed (like a GOOD threading model)
[15:17]	:	I could work 10 years on basic "system" libraries alone, lol :p
[15:18]	:	Morgaine: well, some people (not me) are working on other non-Linden viewers
[15:18]	:	Don't use threading, it's a nightmare. Use system processes, they provide perfect isolation and concurrency.
[15:18]	:	Yes. Threads when done properlly are a godsin to UI performance. Everything is smooth no matter what.
[15:18]	:	Tech: +1
[15:18]	:	And if you start to write a project like this viewer based on *existing* libraries, you automatically get something as instable as we have now :/
[15:19]	:	MorgainL how would you use that for something as high-throughput as J2K decoding?
[15:19]	:	We came up with a structure for it in Imprudence -- http://imprudenceviewer.org/wiki/Image:Plugin_system_flow_APIs.png
[15:20]	:	What foiled us was the mess that is the viewer internally.
[15:20]	:	Making that "Viewer API" block is not trivial.
[15:20]	:	My expertise is debugging, system (library) code (thus not UI) and networking (protocols and heavy duty stuff). I have little to no experience with graphics or non-UNIX portability.
[15:21]	:	Oskar just mentioned Viewer 2.0 goes public beta next week
[15:21]	:	"he thinks"
[15:21]	:	Anyway to split out the networking code in the viewer? Right now, if FPS is 1fps, ping time is 1 second.
[15:21]	:	No graphics involved in client-side scripting, unless people want to code up separate external panels, which is perfectly feasible (Dzonatas did it).
[15:22]	:	Ie, I could rewrite the whole texture download and decoding and caching stuff, just as long as I don't have to do the part where it's send to GL :p, and as long as I can rely on openjpeg, and as long as I have a good server-client protocol description of what is involved... But I would never be able to write the 3D stuff such that it works on three platforms.
[15:23]	:	Aleric: thank goodness for OpenGL
[15:23]	:	Naali's probably the best bet there, Aleric. I think it's likely to become Opensim's "reference viewer", and others will hone it to work well with SL.
[15:23]	:	posting the transscript, at what time should I cut?
[15:24]	:	I only wrote ONE small application in openGL, quite a while ago (a transparent torus that I could rotate around with the mouse, to visualize solutions of an elliptic curve over finite fields ;)
[15:24]	:	heh, Aleric, merov wasn't runnign away from you, he crashed.
[15:24]	:	Everything I say in public is public. If I screw up, it's my fault. Stick it all in the transcript.
[15:24]	:	He only really crashed if he returned :p
[15:25]	:	ok :-)
[15:25]	:	Hehe i should have fired off one of my test animations to see whos using a new build ;-p
[15:25]	:	heh
[15:25]	:	Feeling like exploiting the bugs now Robin? Tssssk
[15:25]	:	Go for it. I got gdb going. hehe
[15:25]	:	i've got no new ones tha crash me now
[15:26]	:	back to help island i guess
[15:26]	:	Off to UXIG. Poor Jacek, we always overrrun here.
 
Generated with SLog Wikifier