Known Networks ChatZilla error Connected Networks URL irc://foo/bar Not Connected Lag URL irc://efnet/opensim-osgrid Mode +tn Users 17, 0@, 0%, 0+ Topic URL irc://foo/bar Connected via Connected to File Progress #opensim-osgrid : :) : great tleiades : danx0r what kind of help do you need on the physics front? : Charles, opinion on mono? I think the others are in a better position to say, as they use mono more than me : I think it is safe to move mono requirements up to 1.2.4, now gutsy has been released : also, some of the other folks here on IBM are looking at helping to fill out the LSL implementation. No promisses on speed, as it is all free time stuff, but hopefuly more patches from folks like Illumious coming : I remember we discussed the fact that ubuntu was stuck on 1.2.3 : If no one objects, I will begin heading in the direction of updating OSGrid from mono-1.2.3.1 to mono-1.2.4 over the next week or so. : yeh, 1.2.4 is probably recommended new version : If no one objects, I will begin heading in the direction of updating OSGrid from mono-1.2.3.1 to mono-1.2.4 over the next week or so. : very good : sounds good cfk : sounds good : i think thats great charles sounds good! : danx0r you still in world? : also since Rookiie is here we should acknowledge his really amazing Grid Web Interface : oh, another thing, MW posted a great glossary explanation on the mailing list : he really did a great job : Does the top 10 bug list on the wiki make sense to everyone? Add to it as appropriate. But, only 10 on the list max. : http://www.sourceforge.net/projects/opensimwi Great job, Rookiie! : is there a volunteer to build a glossary in the wiki based on that post? : yes, great job on opensimwi : I love the top 10 bug list : sdague, mw. I would like to adopt this, but have some issues with modifying the users table. I dont want to make it incompatible with OpenSim on OSGrid. : of course though I am for 0.5 being a big release, the problem with big releases in a open source project are that when there are busy months for the developers (on non project releated things) it does effect the release more than if it was a small feature release : I think the top 10 bug list is definitely a good thing : perhaps an intermediate release is more appropriate? : drawing on ur 0.4.x idea : Does anyone think that adding fields to the user table have any adverse effects on grid mode functionality? : Charles, I think perhaps it would be good to email out the top 10 bug list to the mailing list o na weekly basis : are we agreed that ODE goal is no more ugly crashes? : cfk... if you can send me the table defs, I can have a look at updating the table layout : danx0r I agreed : i personally dont see how it could effect it but would like others opinions : as opposed to focusing on niceties like not bouncing 500 meters : yes : yep : :) : ok I may put in hax to basically reset physics if I get that exception : crashing is worse than things not working right : Tleiades maybe you can just download the opensimwi : done, Neas. Next subject, I will put my concerns about adopting opensimwi on the mailing list also. I need some technical guidance before I modify the users table. : so instead of crashing it will just zero velocities and make positions sane : and have a look : def : I think the problem with 0.4.x releases is "what have we done that provides incremental benefit to 0.4 that's as reliable as the features in 0.4" : ok : I remember why I didn't do it before: this is a C++ hack : 0.4 was very solid for what it supported : well what would be your targets for a 0.4.x? : over a 0.5? : danx0r how can I help on the physics debug front? : yeah true, if we did 0.4.X releases they really would be peacemeal 0.5 releases rather than mantiance releases on 0,4 : ie. stable ODE etc =0.4.x then 0.5 inv assets grid?> : let's not worry about releases per say over the next month and just push on hard on the grid and physics stability fronts : yes, I think we agreed not to invest too heavily in branching in svn : agreed : sakai, I don't think you could back port what we have really : ok : face, it, I'm the one that beat everyone up a lot to get 0.4 out the door :) : neas - issue is this means we are forking ODE : so if I see everyone getting complacient, I'll start beating up again :) : ;) : hehe : I think most people still run from svn version anyway so releases aren't so much a issue just yet, and we have the nightly builds : since we need to change ODE's exception handling logic : ok : true we only use ur svn;s : I'm OK with that, I think it's enevitable whichever engine is used : well, do you think that is more or less sensible than digging on bullet? : just means have to merge if we want new ODE versions : how far is Bullet from being up to ODE level ? : neas -- I think it's sensible to get ODE stable, then move to bullet after 0.5 : ah ok : Wright -- it needs quite a bit of work : i dont think its even close : bullet is very unstable : and we need to detangle some things from the ODE plugin : ok, so probably we'll want to create a sepereate opensim-ode repo : I've also seen bullet eat up ALOT of cpu : /me shudders : and ODE so far has seemed surprisingly light on CPU from what I've heard : ok, fair enough : I could do some comparisons if you like : /me considers danx0r the physics master : I agree long-term bullet looks good, but it's new -- almost no docs : and despite our issues, I suspect ODE is more stable due to maturity : (physical) : are we still going with c# bullet or as I saw danx suggest before, a wrapper on c/c++ Bullet? : and BTW there is still active ODE developers -- note they moved from 0.8 to 0.9 in a few months : ok, good to knwo : and finally, it's simply the case that I'm very familiar with ODE and not with Bullet : so presumably we'd start with 0.9, and modify the exception handling? : and so far new physics coders have not stepped up to fulltime involvement : tho gerard is doing excellent work on meshing prims : yeah so sticking with ODE seems the best (as you are doing most of the work, think we should stick with whatever you think) : neas - yes, since ODE is now in opensim-libs, I feel comfy hacking on it : ok, sounds good : /me has confidence in danx0r's work : only thing is when it gets hacked, we have to update binaries in opensim/bin : agreed then. I may be quiet for a bit, stressful workday : I'll probably bug you a bit more on IRC about getting up to speed on physics so I can help there : neas -- great, later this aft will be better : boss is right here, wondering why I'm complaining he blocks UDP ports : lol : btw corporate firewalls -- opensim shuld be better than LL : yep, probably tomorrow actually, as I have municipal wireless meeting in RL after this : we should have TCP connect, check for UDP/ports -->| Tedd (~tedd@c85-196-75-106.static.sdsl.no) has joined #opensim-osgrid : like video streamers do : tell him that opensim is a great robot simulator enviorment (or will be) : maybe a TCP backstop? : 4 SL meetings and 1 RL meeting in one day makes for little real work :) : well it does help me with physics, which I use on the job : but it's a tentative argument at best : any comments from you net wizards on TCP/firewalls? : I think we are limited by the viewer : danx0r I think that we'll get a bunch of that as the Linden environment evolves : we haven't run into any issues with the opensim : yeh, it's view issues right now : I think all opensim code uses tcp : d'oh of course it's a client-side issue : 'nother reason for our own client... : from all the Linden talk that I've heard, the viewer will be able to opperate in TCP mode in a years time : though I have been thinking that the current inter region protocol is in efficient : yeah, custom client ++. Think sooner or later someone will start work on one (even if we don't) : I've opnly seen small hacks on the LL Client : I've always been -- on custom client, as I think we gain a lot from compatibility :) : ++ on sean's comment : we live on the ll viewer : at least until we're a bit further on the back end implementation : Tleiades, I think all our inter-X protocols are inefficient, thats what I mean by thinking we need to do major work on the protocols : that would be a good ML discussion : yeah but there are a lot of things that the LL viewer is no right for, a lot of things don't need all the bloat in it for example : silly flying people : hey tedd : ah, it's tedd : hey tedd : is hipihi based on the LL client? : ted : carefull man : hwo is the script engine coming? : your gonna crash the server : so while yes I don't think we should stop being compatiable with the SL viewer, I do think having a custom client that uses the same protocol would be good : just leave it tedd : just checking ;) : not during meetings please : yeh, we had one crash earlier, so trying to not upset things too much :) : server crashes when you move object? : hmm... I didn't know that :) : Tedd, sometimes. : ode collisons : yeah Tedd, just get on with your excersises, if you come to gym class, you have to work : hehehe : ok, so I admit it, I'm the master SL griefer : so, Tedd, how goes the script engine work? : Ref: 333Mbyte, 67% CPU, 13 avatars : ouch : nice charles : sakai, remember, there is like 0 optimization yet : 67% seems high : I suspect the 67% has more to do with locks then anything else. : yes it dows : does : well, it kinda stopped last week again ... temporarily. The good news is that I'm able to participate on IRC and write some code now and then : mmm... about scripting... somebody heavy in lsl scripting already thinked to attempt to make a prims rezzer for LL grid using xml export from opensim? could be fun to can use opensim in sandbox for offline building... : as compared to a few weeks/a month ago when I only had time to do some scetch-book planning : true : Nahona: Mantis feature request would be best for this, I believe. : cool : I know someone I can ask : does anyone know how I can get mantis to send me email on changes to anything, like it says it is doing? : but isn't : Current status is: I have implemented TCP server/client. I am designing a binary protocol and have sort of started implementing what I call the "Packet factory" (the class that makes the binary packets) nice : I have created a separate stand-alone for script engine called script server and moved (copied) ScriptEngine to it. : cool : Neas, it used to send updates if a issue was assigned to you, but don't think it has done that for months now : But because ScriptEngine needs scene and the comm is not operational yet it will not compile : any best guess on when it might go into tree? : in fact there are a lot of things that will not compile : its at least 2-3 weeks depending on my spare time : Wright: that's sort of problematic : OpenSim has first priority on my spare time activites : cfk, any chance you can beat up openmv folks on that front? : cool :) : Huh? What front, sorry : mantis not sending email : I have started talking to Babbage, he seems interested in the new Script Engine approach : Sure. CPrior is my contact, I will see what I can do : nifty : he also says we should not attempt implementing microthreading : and I have been thinking a lot about it and I agree ... there are so many problems that we should not start it, it is just dead wrong from a design perspecitve : Tedd.. I have a question, are you using interpreted code or CIL? is my av still there? battery died : that's definitely progress : haven't they implemented microthreading in their mono implementation? : Cprior-gram sent re Mantis-non-mail. danx0r: nope i dont see your avatar anymore : right now I am using C# for everything, I was using CIL on the LSL ByteCode : well... two things : If I can speak on a purely personal level.. I think we'll find that LL will not implement C# ... : 1) won't injecting thread.sleep and threadpools be just as good as microthreading? : right, I think we'll still need the LSL implementation : and .. what about security, CAS doesn't work on mono : I think there was confusion over them adding Mono : vs. C# : I might have to boogie, but will do the chat log onto the wiki later. : Ciao Charles : bye cfk : Tedd, presumably the new script engine doesn't preclude using LSL like the current model? cya : yeah I'm going to have to go too, will stay logged in , but not really here : later cfk : Answers: 1) Then we can not move running scripts between servers or pack them into inventory. BUT, with new ScriptServer we can at least have script moved between regions... then next problem is that you can only have a few hundred threads per operating system : or, per computer : 14 avs, 68% CPU, 340Mbyte : Security is a big problem... it is THE reason why I think we will not see C# and Mono in SL for a long time why is it so hard to sandbox mono code? isn't that the whole point of a managed bytecode? : The technical side with microthreading can be solved with a lot of work, although its one of those "its possible in theory but nobody would ever be so mad as to actually ytry it" implementations : danx0r it gets jitted : but what about mint? : It would be easier to implement a virtual machine with a minimal OS that can run Mono and run scripts inside it instead with 1 thread per OS so tedd -- you have a thread for every script now? Doesn't LL do some sort of smart sleep() injection : *1 thread per script ahh, frakkin JIT well it must be hard, because Guido punted on it in Python, and he doesn't even use JIT he just pulled the module and said you're all on your own, I absolve myself of any and all liability for security problems : one can in theory microthread Mono, and it might be that LL already has done that ... but the security aspect of it is just impossible there are interesting microthread-like things for cpython though, like the greenlets(?) or something like that .. so i guess it is not all just theory? 1 thread per script is not scalable, ne? there's microthreads for python sorta, but I'm talking about trusted execution : no, 1 script per thread won't work... operating systems have a big overhead for each thread I guess these issues intersect : it's kill a bit of hardware I remember something from LL about smart yield() injection : I'm thinking of looking into JavaScript : I wonder how many mono threads you can have on linux before things get wonky which is a form of microthreading, morally speaking : tedd, do you have a good test case to test practical limits? : Babbage tested that, a few hundred on Linux and close to a hundred on Win yah afaik the cpython greenlets etc yield. dunno if microthreading is interconnected with sandboxing or a separate issue : but Windows NT has something called "fibres", but I think maybe the app has to support it somehow : threads have almost the same overhead as processes : not on linux : I've been looking at yield, but I'm not sure if we should go down that path at all yield() seems like the right thing I did something on Python where I just inserted a yield after every line of code wasn't scaled up, but it could have been I think heh the idea is to insert a yield anywhere you have a CPU capture : yield actually causes some interesting issues with the os schedulars from my previous experience it's part of the theory of continuations neas -- it doesn't have to be an OS yield : anyway, I've got to run to this wireless meeting : see you all later * antont notices his words are not relayed to wright plaza (danx0r's speech does show there) : thanks for so many people showing u : up sorry I need to be more specific. Yield() in python is a python thing, it returns control to the VM : Ciao Neas thanx cya! : well, IF Linux can support say 500 threads ... this means we can have 500 scripts with loops in them. or we could have 499 scripts with loops and 10.000 scripts without loops antont: that sucks -- wonder why : if you see my point : well, that might be a fine place to start so mono doesn't have a microthreading capability or python-like yield() next() ?? : its 500x better than where we are now :) : and with remote script server we can cluster multiple script servers to serve one region, meaning we can without any big problem run 10k's of scripts if so that's too bad. I guess python is strictly runtime interpreted so it's easier : mono has yield(), but there are problems ... : and 20x slower * sdague goes poof <--| sdague has left #opensim-osgrid (Client exiting) : 01 41 43 54 49 4F 4E 20 73 61 79 73 20 73 6F 6D .ACTION says som : wow : what happened there? :P : lol * antont goes to eat : Mono microthreading only works with the subset of CIL > assembler opcodes that the LSL to CIL compiler emits : tedd.. wouldn't threadpooling work? : point is that there are a lot of small obstacles to overcome to implement Mono microthreading, some are of those that can be overcome, while others are not : couple questions about other topics??? : "open up everything, allow anyone to run any .Net app on my computer. Now try to restrict the application." <- its just the wrong way to go : whats your questions blue? : what needs to be done to make animations work? : threadpooling can work to some degree now that we have script server as stand alone, but when its integrated into OpenSim its very dangerous : why not have it as a standalone server? : well that would def be a good point from a hardware pool side : it will be, but threadpool works as "if you are kind enough to lend me back my thread so I can continue execution" ooh, Wright Plaza is back up? Blue: the last thing I heard was that we need someone to make opensource versions of the LL animations? Is that wrong? : that is not so cool :) : yes gareth it was only down for about 1 minute i picked the wrong minute : which is where emitting thread.slepp(0) comes into play : there were a bunch of animations packaged with avimator heh : ah thats not so hard i'll hop on : similar to the yield() Blue: someone was looking into the "sit" today. : can't remember what the license was... : sit would be a good starting point : yeah i've got afew bucket fulls of animations too : chillken was working on sit : BSD license is important I recall reading in backscroll on #opensim-dev that sit was being looked into. : yea lmmz it was chi11ken : hehe irc delat : delay I dont know if the animations are part of the client or are downloaded from LL. : in initial implementation of script engine we will have thread based execution of scripts. It is not a 1:1 ratio between thread and script. If the script is not working then no thread is assigned to it. : they are an asset : i beleive : so if you have 10.000 scripts waiting for an event then no threads are in use. : not in client : asset yes, but i thought they were executed on the client the client contains an xml file with keys to LL animations, but I imagine we dont want to use LL's animations. :) : haven't looked into it too deeply thought : are the animations on the client? can we just send the right keys? : isn't that how walk works now? : no : its a animation : an asset I dont think they're on the client unless youve downloaded em from LL grid. : animations are not in the client : where abouts are you all? : upstairs in the building Gareth I've seen some custom animations play locally in OpenSim, but they dont play inworld, yet. : upstairs : this looks like a crazy cult meeting : one more thing to put on the list :) : it's like smith in the matrix, but ruth hopefully, chillken (?) will make som eprogress on it, today. :) : correct... there are three animations in opensim right now... hard coded case statement for walk, fly and something else : ok walk, fly and gym class? : something like stop flying but i can't remember : yea in the Data folder : there is an xml file : that defines the animations : and their asset UUID Blue, chi11ken is probably the one to work with on animations. : will do : great .. I'd love to see more animations : are people seeing my shape changes? : dsaf : great .. I'd love to see more animations : a busty woman? Gareth, yes. Nice headlights. : rofl : i got a screenshot : thats going on the wiki : my sexy av? : lol : u can currently accept animations direct from avimator? : amongst you mere mortal ruths : why are animations hardcoded? : yea one problem is animations in your inventory : only you can see them : it doesnt animate to world : i can put animations in my library (from avimator) : i can even play them locally : can't play them in world though : yea only works locally Sakai, I think so, yes. But without an asset system, they would not stay in inventory. And they only play locally. : yea : assets isn't implemented fully and completely : lol - so true : yea that should be done 1st : before doing to much with animations : I think I'll contact ch11ken then I have a ton he can have straight up : first the infrastructure for assets and inventory needs to be set up Sakai, nice. : my borther has made 100's for SL : but you should talk with him : as assets is not far off : few weeks : well that's exciting I suppose we get to decide how assets are persisted between grids, after that. :) : speaking of assets... any idea when i can put textures in a prim? (looking to build a projector for biz meetings) : the viewer fetches assets over HTTP now - does anyone know how to provide them? : ok, I'll be on IRC .. need to do some more work :) Cya, tedd! : you all have a nice workout : yes persistent between grids would be impressive but could really dig the bandwidth : Gareth going for hot nurse? : well, I have been thinking about writing a client side asset and inventory storage engine : that way, the inventory and assets could follow the user between grids : but I Gotta run! Great meeting! The IRC bridge is the shiz! : how would you get around duplicate asset entries?