User:Babbage Linden/Office Hours/2010 03 03

From Second Life Wiki
Jump to: navigation, search

Transcript of Babbage Linden's office hours:

[03:00] Sebastean Steamweaver: Hey there Babbage

[03:00] Babbage Linden: morning all

[03:00] Nock Forager: Hello Babbage

[03:00] Ceawlin Steamweaver: Mornin!

[03:00] Becky Pippen: Hi Mr. B

[03:00] Xugu Madison: Babbage, congrats on 1.38 hitting Agni!

[03:00] Cerdita Piek: Hello Babbage :)

[03:00] Xugu Madison: erm, Aditi

[03:00] Xugu Madison: beta grid

[03:00] Babbage Linden: hmm, let me see if I can sort out some light here

[03:00] Sebastean Steamweaver: Indeed :)

[03:00] Fred Rookstown: in b4 someone attaches a supernova facelight

[03:01] Xugu Madison: Squirrel! Yikes, isn't it some insane time of day for you?

[03:01] Hypatia Callisto: I have attached lights off... someone turned on the light and dropped it :P

[03:01] Squirrel Wood: high noon it is

[03:01] Squirrel Wood: in fact, LUNCH tiem

[03:02] Ceawlin Steamweaver: High lunch. :o

[03:02] Xugu Madison: Ah, for some reason thought you were US based

[03:02] Hypatia Callisto: mm lunch. I just ate mine a few minutes ago :D

[03:02] Fred Rookstown: 3:02AM. Yay for insomnia

[03:02] Babbage Linden: nope I'm in Brighton in the UK

[03:02] Ceawlin Steamweaver: 6am here, lol.

[03:02] Squirrel Wood: add a couple 1000 miles to my current location and you could call it that :p

[03:02] Sebastean Steamweaver: I think Xugu meant Squirrel

[03:02] Xugu Madison: Erm, I meant Squirrel...

[03:03] Kopilo Hallard: hmms, there is an idea, a facelight that burns the face off of the avatar that is using it

[03:03] Babbage Linden: ok, what would you all like to talk about today?

[03:03] Ceawlin Steamweaver: Cool stuff!

[03:03] Squirrel Wood: Pie

[03:03] Xugu Madison: What's changed in 1.38? :)

[03:03] Fred Rookstown: llGetAgentInfo -type functions?

[03:03] Sebastean Steamweaver: Cake

[03:03] Fred Rookstown: :P

[03:03] Kopilo Hallard: what is 1.38?

[03:03] Hypatia Callisto: server

[03:03] Fred Rookstown: So we can get viewer channel and reported version

[03:03] Sebastean Steamweaver: A server version with many good things

[03:03] Kopilo Hallard: ahh thanks

[03:03] Jonathan Yap: This enhancement request

[03:03] Hypatia Callisto: mhm

[03:04] Actingill Igaly: any rough indication of when 1.38 will be released to agni? providing testing is ok of course

[03:04] Actingill Igaly: oh an slice on llSetPrimitiveParams

[03:04] Babbage Linden: so, 1.38

[03:04] Babbage Linden: anything else for the agenda?

[03:04] Sebastean Steamweaver: Yes

[03:04] Kopilo Hallard: lsl?

[03:04] Sebastean Steamweaver: llSetObjectSCale

[03:04] Kopilo Hallard: >_>

[03:04] Fred Rookstown: llGetAgentInfo

[03:04] Kopilo Hallard: how about LSL functions?

[03:04] Cerdita Piek: will we see SVC-3895 fixed in 1.38?

[03:05] Sebastean Steamweaver: There's a reason I'm bringing it up again ;)

[03:05] Actingill Igaly: llSetPrimitiveParams

[03:05] Ceawlin Steamweaver: I am now supposed to start bugging you about memory limits, exp. scripts > 64k, now that 1.38 is on aditi. Lol. ;P

[03:05] Ceawlin Steamweaver: *esp

[03:06] Ceawlin Steamweaver: /me ducks.

[03:06] Sebastean Steamweaver: I think small scripts are coming before big scripts, aren't they?

[03:06] Babbage Linden: OK, so 1.38, SVC-3895, LSL functions, llGetAgentInfo and Memory Limits

[03:06] Sebastean Steamweaver: Or are you doing them at the same time?

[03:06] Babbage Linden: a reasonable list to start with

[03:06] Jonathan Yap: Babbage, can I add

[03:06] Sebastean Steamweaver: SVC-3895?

[03:06] JIRA-helper (left hip):

[#SVC-3895] Rezzing Mono scripted object cripples sim FPS

[03:06] Sebastean Steamweaver: Ahh

[03:07] Babbage Linden: So, 1.38 is now on aditi

[03:07] Sebastean Steamweaver: And I would like to add SVC-5328

[03:07] JIRA-helper (left hip):

[#SVC-5328] llSetObjectScale and llGetObjectScale

[03:07] Actingill Igaly: and i SVC-5419

[03:07] JIRA-helper (left hip):

[#SVC-5419] Add flag parameter [vector slice] to llSetPrimitiveParams PRIM_TYPE flags PRIM_TYPE_BOX, PRIM_TYPE_CYLINDER, and PRIM_TYPE_PRISM

[03:07] Babbage Linden: (thanks for letting me know, I knew it was going to be this week, I didn't nkow it was there yet)

[03:07] Babbage Linden: please go and have a play with the new functionality

[03:07] Babbage Linden: which kelly has written up here:

[03:07] Sebastean Steamweaver: Already started ;)

[03:08] Babbage Linden: PRIM_TEXT:

[03:08] Babbage Linden: llGetLinkPrimitiveParams:

[03:08] Babbage Linden: llSetLinkPrimitiveParamsFast:

[03:08] Babbage Linden: llSetLinkTextureAnim:

[03:08] Xugu Madison: Awesome! :)

[03:08] Babbage Linden: llLinkParticleSystem:

[03:08] Sebastean Steamweaver: :D

[03:08] Ceawlin Steamweaver: Cool beans.

[03:08] Babbage Linden: please check the documentation is correct

[03:09] Babbage Linden: and either fix it or set up public JIRAs if it's now

[03:09] Babbage Linden: not

[03:09] Sebastean Steamweaver: I'm so so happy to hear llLinkParticleSystem made it.

[03:09] Babbage Linden: and if we need to fix anything

[03:09] Chaley May: wow great

[03:09] Fred Rookstown: That's great.

[03:09] Babbage Linden: 1.38 also includes partial fixes for SVC-3895

[03:09] Fred Rookstown: 2 fewer scripts on my jetpack :D

[03:09] Sebastean Steamweaver: Several in my builds.

[03:09] Babbage Linden: you should now only see stalls the first time a Mono assembly is rezzed

[03:10] Babbage Linden: (we're still working with the Mono developers to work out why that is)

[03:10] Babbage Linden: we've also greatly increased the size of the assembly cache

[03:10] Fred Rookstown: Great.

[03:10] Sebastean Steamweaver: Will the sim still lag out when people TP in?

[03:10] Babbage Linden: So common scripts will tend to be cached in simulators

[03:10] Babbage Linden: which means they won't need to be loaded

[03:11] Babbage Linden: which means you should see far fewer stalls in practice

[03:11] Fred Rookstown: Are you able to work around the lag via threading or some other magic?

[03:11] Qie Niangao: wait: stalls the first time a Mono assembly is rezzed *anywhere*? or the first time in *each* *sim* it rezzes?

[03:11] Babbage Linden: There are some Mono fixes for these stalls coming down the pipe

[03:11] Babbage Linden: So a full fix should happen when we deploy Mono 2.6.X at the latest

[03:11] Babbage Linden: Qie, first time per som

[03:11] Babbage Linden: sim

[03:11] Sebastean Steamweaver: Awesome

[03:12] Qie Niangao: ah. that's unfortunate. :(

[03:12] Babbage Linden: So, there's even more reason so share bytecode now

[03:12] Fred Rookstown: DLLs for SL? :p

[03:12] Fred Rookstown: *LSL

[03:12] Babbage Linden: The fewer distinct assemblies there are, the more likely they'll be cached

[03:13] Kopilo Hallard: .cpp and .h for lsl? :p

[03:13] Babbage Linden: for example, if you use the whizzy new LSL twitter library

[03:13] Morgaine Dinova: /me waves quietly

[03:13] Babbage Linden:

[03:13] Babbage Linden: please don't recompile it :-D

[03:13] Kopilo Hallard: /me e-hugs morgaine

[03:13] Fred Rookstown: .h is preprocessed before compilation

[03:13] Kopilo Hallard: >_>

[03:13] Babbage Linden: please test you lag detectors and mono rezzing tests on aditi and let me know how you get on

[03:14] Fred Rookstown: Emerald (which stole the idea from a C#-based project of mine) has preprocessors for LSL

[03:14] Babbage Linden: you should only see problems the first time you rez a script now

[03:14] Fred Rookstown: :|

[03:14] Babbage Linden: In terms of LSL functions, I've given you the documentation for the new functions in 1.38

[03:15] Imaze Rhiano: back

[03:15] Kopilo Hallard: eb

[03:15] Sebastean Steamweaver: Babbage, could I bring something up concerning llSetObjectScale, while we're on LSL functions?

[03:15] Babbage Linden: the only other functions I know of in the pipeline are :

[03:15] Babbage Linden: SVC-1773: STATUS_BLOCK_GRAB only affects individual prims in a linkset

[03:15] JIRA-helper (left hip):

[#SVC-1773] STATUS_BLOCK_GRAB only affects individual prims in a linkset

[03:16] Ardy Lay: Hey look, Morgaine! Now we all look blue like you!

[03:16] Morgaine Dinova: Blue is good

[03:16] Babbage Linden: and:

[03:16] JIRA-helper (left hip): [#SVC-3306] Add enumeration to llPassCollisions() to provide ALWAYS_PASS, PASS_IF_NOT_HANDLED, and NEVER_PASS as explicit options

[03:16] Fred Rookstown: Red iz bezt </ork>

[03:17] Sheryl Mimulus: /me is purple

[03:17] Babbage Linden: Sebastean, I don't think we need llSetObjectScale now we have llSetLinkPrimitiveParamsFast?

[03:18] Latif Khalifa: is it possible to read and/or change linked prim descriptions?

[03:18] Sebastean Steamweaver: That's actually what I'd like to talk to you about.

[03:18] Babbage Linden: you can just loop through the linkset setting transforms?

[03:18] Sebastean Steamweaver: *copypastes*

[03:18] Babbage Linden: (which should be relatively efficient in Mono)

[03:18] Sebastean Steamweaver: Babbage, concerning, Kelly linden in the comments asked if the function was still necessary, since we have llSetLinkPrimitiveParamsFast and llGetLinkPrimitiveParams. The original poster goes into why he believes we still need a dedicated function, and I have to agree. For a 100 prim object, such a loop would require at minimum 300 function calls, supposedly in a single sim frame. There are other reasons as well, such as script space and setup.

[03:18] JIRA-helper (left hip): [#SVC-5328] llSetObjectScale and llGetObjectScale

[03:18] Chaley May: :(

[03:18] Sebastean Steamweaver: That also brings up issues of throttling the loop, and 100 prims is conservative for several objects.

[03:19] Babbage Linden: 300 function calls should be OK, and will actually be made across several frames

[03:19] Ceawlin Steamweaver: I don't know for sure, but I think the functions that take LINK_SET run a loop internally anyway. I can see no significant difference between using LINK_SET and looping through the whole link set when sending link messages. <_<

[03:19] Sebastean Steamweaver: The loop requires a ton more setup than llSetObjectScale, and I know for my own use, it would make it much harder on a script already pressed for memory.

[03:19] Babbage Linden: so transforming an object with many calls is better than stalling the sim by asking it to scale many prims in the same frame

[03:19] Fred Rookstown: Also, why have two different llSetLinkPrimitiveParams, where the only difference is sleep?

[03:19] Actingill Igaly: Babbage, can I ask, would it not have been a good idea to include the Slice parameters with cubes and cylinders in llSetPrimitiveParams fast, as breaking old scripts has been quoted as the reason why this hasn't been done before?

[03:19] Imaze Rhiano: llSetObjectScale would be still nice to have - thought I think that you should be able scale invidually along axis if you want - for example llSetObjectScale( float scale, vector scalingfactors );

[03:20] Latif Khalifa: does setting rotation even work with set linked params properly?

[03:20] Babbage Linden: Fred, we have 2 functions as there will be scripts that rely on the old sleep behaviour

[03:20] Babbage Linden: and we try not to silently change behaviour

[03:20] Fred Rookstown: Imaze: llSetObjectScale(vector scale) would probably be easier

[03:20] Babbage Linden: so we added a new function rather than changing the existing one

[03:20] Imaze Rhiano: fred - ya

[03:20] Fred Rookstown: Babbage: oh ok

[03:20] Babbage Linden: Sebastien, the reason not to have llSetObjectScale is actually more philosophical

[03:21] Sebastean Steamweaver: For me, the main concern is memory space taken up, and also throttling. The other problem is if people try to put that loop on a slider control - that could cause problems.

[03:21] Kopilo Hallard: vector or just a float?

[03:21] Fred Rookstown: vector

[03:21] Imaze Rhiano: vector

[03:21] Kopilo Hallard: /me nods

[03:21] Kopilo Hallard: >_>

[03:21] Kopilo Hallard: <_<

[03:21] Babbage Linden: I would rather keep the ll* API surface area as small as possible

[03:21] Qie Niangao: can't actually scale more than one prim on arbitrary axes without changing the basic math of a prim

[03:21] Babbage Linden: (the bigger it is the harder it is to maintain and keep secure)

[03:22] Babbage Linden: I would rather add support for user libraries to allow you to implement llSetObjectScale in terms of llSetLinkPrimitiveParamsFast

[03:22] Fred Rookstown: Maybe break it up into smaller modules?

[03:22] Sheryl Mimulus: fred that's just as much code to screen

[03:22] Fred Rookstown: So you have LLPrim.SetScale(<x,y,z>)

[03:22] Babbage Linden: rather than have to add convinience library calls to make up for the lack or resident created libraries

[03:22] Fred Rookstown: But smaller files

[03:22] Fred Rookstown: Easier to find what you're looking for if you're maintaining them

[03:22] Babbage Linden: you lot are awesome, and there are many more of you than there are Linden engineers

[03:23] Babbage Linden: instead of giving you a fish

[03:23] Sheryl Mimulus: hence open source's many eyes win hehe

[03:23] Babbage Linden: I'd prefer to let you grow your own ;-)

[03:23] Actingill Igaly: can i bang on about slice again please - it seems a big opportunity is being missed here

[03:23] Fred Rookstown: Not to mention one could arguably do something analogous to python's import "something" or C#'s using Something.Something

[03:23] Babbage Linden: while there are many "low hanging fruit" and easy convinience functions we could add

[03:24] Qie Niangao: well, actually... speaking of shared compilation units, there needs to be exactly one of these resizer scripts in existence, if it's not a library function.

[03:24] Morgaine Dinova: Tell Q that, Babbage. He insists on keeping Firefly a state secret, and disallowing the many community eyeballs from having a say.

[03:24] Babbage Linden: we already have 400ish library calls and adding new ones we don't need is terrifying

[03:24] Imaze Rhiano: we need llSetScaleObject :P

[03:24] Sebastean Steamweaver: Well, it's the "don't need" that I would take issue with.

[03:24] Babbage Linden: Morgaine, that is Q's choice (and closer to the LL line too)

[03:24] Fred Rookstown: So opensource the Mono api so people can help maintain it.

[03:25] Babbage Linden: I'm sticking my neck out being as open as I am

[03:25] Fred Rookstown: and also initially make fun of your programming practices.

[03:25] Chaley May: yes you need set object scale because local position needs to be changed too

[03:25] Fred Rookstown: :p

[03:25] Babbage Linden: Fred, I would love to

[03:25] Jonathan Yap: /me wonders if having a resizer script in the common Inventory Library might be helpful

[03:25] Babbage Linden: I'm working on it

[03:25] Sheryl Mimulus: and we really appreciate it, Babbage :)

[03:25] Babbage Linden: Jonathan, having a resizer library would be wonderful

[03:26] Babbage Linden: and once it's possible it can improve at "resident speed" rather than "LL engineer speed"

[03:26] Babbage Linden: which is much faster :-D

[03:26] Fred Rookstown: and then I can make server-side Lua instead of piddling around with client-side Lua >_>

[03:26] Babbage Linden: it's the sign of a good protocol API that it can be simple and change slowly while enabling a lot

[03:27] Babbage Linden: HTTP only had 1 revision in the period when the web went from a hobby to the new economy

[03:27] Babbage Linden: I want to fix the underlying b0rkeness of the SL scripting platform

[03:27] Fred Rookstown: So say we all

[03:27] Babbage Linden: (allowing libraries, fixing the memory model, allowing other languages)

[03:28] Sheryl Mimulus: its more like javascript vs lsl rather than http vs lsl

[03:28] Kopilo Hallard: xD

[03:28] Babbage Linden: rather than add convinience functions that work around the b0rkeness

[03:28] Latif Khalifa: heh HTTP implements "give me bunch of bytes with this identifier" and "here you go", much easer not to have to change such a simple proto ;)

[03:28] Sebastean Steamweaver: Still, having a library resizer script doesn't fix the problem of how much memory it takes up. I was tempted to write a "mock" resizer script using the loop and one with fake llSetObjectScale functions just to demonstrate that.

[03:28] Babbage Linden: agreed Latif, but the analogy stands I think

[03:29] Babbage Linden: sebastean, having a resizer library and bytecode sharing fixes that problem

[03:29] Babbage Linden: (both of which should be possible soon)

[03:29] Sebastean Steamweaver: But not for a scripts limited memory

[03:29] Babbage Linden: sure, if everyone is using the same resizing library

[03:29] Babbage Linden: and the memory costs of it are shared

[03:29] Babbage Linden: then it's not a problem

[03:29] Sebastean Steamweaver: I only have 64k to play with right at the moment - that doesn't leave me much wiggle room if the resizer is integrated with another script I'm doing.

[03:29] Chaley May: setting a scale of an object is much harder than simply enlarguing every link.. you have to calculate the position each link needs to be at

[03:30] Kopilo Hallard: eh

[03:30] Sebastean Steamweaver: You also have to calculate the max distance and min distance a resize can take it.

[03:30] Kopilo Hallard: that's not the hard part really, that's just a % function

[03:30] Sheryl Mimulus: its just math

[03:30] Kopilo Hallard: checking each part can resize...

[03:30] Sebastean Steamweaver: Kopilo, it's far more complicated than that.

[03:30] Babbage Linden: sebastean, once you have bytecode sharing you will be able to write a script and send it a link message saying "change this size to blah"

[03:30] Kopilo Hallard: and optimising...

[03:30] Sebastean Steamweaver: Read the JIRA comments in what I linked.

[03:30] Chaley May: yes but then it shows you how much mroe the script needs to do to make it happen

[03:31] Kopilo Hallard: >_>

[03:31] Babbage Linden: once you have proper libraries you will be able to just make a call LinkSet.Resize(float)

[03:31] Babbage Linden: for example

[03:31] Kopilo Hallard: yeap

[03:31] Babbage Linden: the cost of that library will be shared between everyone using resizing on the sim

[03:31] Babbage Linden: (which is probably every shoe and haircut in the region)

[03:31] Kopilo Hallard: :D

[03:31] Sebastean Steamweaver: Hm

[03:32] Sebastean Steamweaver: I'm expecting I'll have to use a separate script for resizing, but I was hoping I wouldn't have to.

[03:32] Babbage Linden: Using a separate script will be much less onerous when you don't have to send text messages to it

[03:32] Babbage Linden: can can just say you're using it then make library calls to it

[03:32] Kopilo Hallard: will the libraries be stored in rom?

[03:33] Fred Rookstown: *RAM

[03:33] Fred Rookstown: >_>

[03:33] Kopilo Hallard: ew...

[03:33] Kopilo Hallard: >_>

[03:33] Sheryl Mimulus: /me shudders at the thought of scripters demanding to override libraries like polymorphic functions

[03:33] Sebastean Steamweaver: My current script wouldn't be using the library script, exactly. I'd be needing to use a custom resize script that I'd write.

[03:33] Fred Rookstown: ROM = readonly

[03:33] Qie Niangao: well, the *memory* cost will be shared, but the overhead of the multiple function calls per prim will hit every time the library function is invoked. Unless those function calls are at native speed, not bytecode.

[03:33] Kopilo Hallard: yes...

[03:33] Babbage Linden: libraries are mostly just scripts with no flows of control

[03:33] Fred Rookstown: Sheryl: But that's fun!

[03:33] Babbage Linden: and no static data

[03:33] Sebastean Steamweaver: Qie that's what I was afraid of.

[03:34] Fred Rookstown: print=function (hahaha) error("YOUR PROGRAMMING LANGUAGE HATES YOU") end

[03:34] Babbage Linden: qie, the loop will be in JITed bytecode

[03:34] Sebastean Steamweaver: JITed?

[03:34] Fred Rookstown: JIT = just in time

[03:34] Babbage Linden: and the calls from managed to unmanaged code are fast

[03:34] Sheryl Mimulus: just in time compiled

[03:34] Imaze Rhiano: jit = just in time - compiled to native processor code

[03:35] Sebastean Steamweaver: /me nods

[03:35] Babbage Linden: so, chatty APIs shouldn't be a problem

[03:35] Babbage Linden: (this is all in the simulator process, not across a network)

[03:35] Sebastean Steamweaver: So even if I'm resizing a 256 object, 3 function calls per prim (just for resizing) won't cause it to break?

[03:35] Babbage Linden: no, it shouldn't

[03:36] Sebastean Steamweaver: perhaps now would be a good time to ask how the functions will be throttled.

[03:36] Babbage Linden: and if it causes problems, I'd rather fix those problems than build a llMakeManyLibraryCallsInOneGo call

[03:36] Imaze Rhiano: ya... how those are going to be thrrottled?

[03:36] Babbage Linden: sebastean, the library calls will just use up the scripts time slice

[03:37] Babbage Linden: it will be able to make N calls per quanta

[03:37] Sebastean Steamweaver: 255*

[03:37] Latif Khalifa: Babbage, do you plan to upgrade to mono 2.6 before the c# scripting? I'm really happy with the amount of resource leakage reduced in it.

[03:37] Babbage Linden: and so will need prims * 3 / N frames to do the resizing

[03:37] Babbage Linden: latif, yes we're talking about that now

[03:37] Babbage Linden: we want to have as many distinct releases as we can

[03:38] Babbage Linden: Mono 2.6.1 should be shippable in isolation

[03:38] Latif Khalifa: i bet it would help balooning mem usage a lot

[03:38] Sebastean Steamweaver: I appreciate you discussing this with me Babbage, I know I've brought it up many times before.

[03:38] Babbage Linden: no problem sebastean

[03:38] Sebastean Steamweaver: One other concern I have Babbage:

[03:38] Babbage Linden: latif, hopefully TC Malloc will help us know where the ballooning memory is going

[03:39] Sebastean Steamweaver: The resize script will have problems if a prim in the linkset is edited outside of the script (by the user)

[03:39] Sebastean Steamweaver: Because that would throw off is max/min size/pos calcuations.

[03:39] Sebastean Steamweaver: calculations*

[03:39] Sebastean Steamweaver: its*

[03:39] Babbage Linden: sebastean, isn't the common case here that you use resizing as a "partial mod" permission

[03:39] Sebastean Steamweaver: Not always

[03:39] Latif Khalifa: yes

[03:39] Babbage Linden: in which case the object will be no mod to the user?

[03:40] Sebastean Steamweaver: No

[03:40] Jonathan Yap: Could the user be using a resize script at the exact same time they are editing an object?

[03:40] Sebastean Steamweaver: In my case, I have a system that allows one person to edit another person's attachments.

[03:40] Latif Khalifa: not likely in the common case

[03:40] Sebastean Steamweaver: The person has to have mod rights in order for it to work, of course, because it needs to install scripts.

[03:40] Babbage Linden: yes, so maybe you need a "Stand clear, rezing is about to happen" message?

[03:41] Sebastean Steamweaver: I wasn't as much worried about concurrency, really.

[03:41] Latif Khalifa: i'm worried about SET_ROT being broken

[03:41] Sebastean Steamweaver: I was more worried about the linkset being editied in between resizes. I don't want to have to "read" the linkset and recalcualte all of the max/mins before doing each resize.

[03:41] Latif Khalifa: you need to get root objects rotation to calculate local rotation properly

[03:41] Sebastean Steamweaver: That's one of the complications here.

[03:41] Babbage Linden: you probably will have to scan in the case when you allow modifications

[03:42] Babbage Linden: as you don't know what size everything is

[03:42] Sebastean Steamweaver: Exactly

[03:42] Sebastean Steamweaver: But the server does.

[03:42] JB Hancroft: morning all.. (sips coffee)

[03:42] Babbage Linden: sounds like you need a library ;-)

[03:42] Morgaine Dinova: Hi JB

[03:42] Ceawlin Steamweaver: Hey jb!

[03:42] Babbage Linden: actually, what you really need is a scene graph, so you can adjust the size on the single root transform

[03:43] Babbage Linden: that's the real way to get rid of scaning an many resizes

[03:43] Kopilo Hallard: nice

[03:43] Jonathan Yap: (ignorant scripter here) -- could you use the changed event to see if someone has manually resized your object?

[03:43] Sebastean Steamweaver: That takes up a lot of processing time as it is though Babbage. Having a loop to read and calculate all of those will eat up function calls before the resize even takes place.

[03:43] Sheryl Mimulus: yup, so when do we get direct access to the scene graph? :P

[03:43] Babbage Linden: scene graphs are a way off however ;-)

[03:43] Sebastean Steamweaver: Jon - unfortunately I don't believe so.

[03:43] Sebastean Steamweaver: There's no "CHANGED" for linkset positions.

[03:43] Babbage Linden: sheryl, unfortunately there is no scene graph

[03:43] Kopilo Hallard: John- changed event occurs when the object resizes.. so prehaps

[03:43] JB Hancroft: (tease ;)

[03:44] Sheryl Mimulus: sadly, I know...

[03:44] Sebastean Steamweaver: I'm not sure if it works for changed for a single child prim.

[03:44] Morgaine Dinova: Babbage: well we've been saying we need hierarchical ojects for years, and even Philip and Cory agree, so nothing new. But apparently you're not interested.

[03:44] Latif Khalifa: SVC-93 mandates that when you set linked prim rotation too do [PRIM_ROTATION, localrot * llGetRootRotation()], changing rotations on an attachment would be challenging

[03:44] JIRA-helper (left hip):

[#SVC-93] llSetPrimitiveParams PRIM_ROTATION and llSetRot incorrectly implemented for child prims

[03:44] Babbage Linden: morgaine, I'm very interested

[03:44] Ceawlin Steamweaver: I think what Babbage is trying to say here is that the calls between managed and unmanaged code are fast, so it doesn't matter if a script is requesting prim info via llgetlinkprimparams of unmanaged code in the LSL api is fetching it from in the sim somewhere: it'll be about the same speed.

[03:44] Sheryl Mimulus: its going to take viewer 3.0 to get scene graphs

[03:45] Babbage Linden: but adding a scene graph would be a bit like changing planck's constant

[03:45] Sebastean Steamweaver: Could someone select the non-blue sphere? 2.0 is making my prims disappear on me again.

[03:45] Ceawlin Steamweaver: And I typed that too late. X_x *hides*

[03:45] Sebastean Steamweaver: Thanks :)

[03:45] Babbage Linden: quite a lot of the world relies on scene graphs not existing

[03:45] Morgaine Dinova: Good to hear. But somehow I get the impression that you're the lone sensible engineer in LL, and everyone else has nothing but excuses for why progress is impossible.

[03:45] JB Hancroft: ouch.. something we want, but deeply entrenched...

[03:45] Sebastean Steamweaver: ... My prims do not want to stay visible.

[03:45] Object: Hello, Avatar!

[03:46] Babbage Linden: well progress is possible, but hard

[03:46] Latif Khalifa: We are getting some real progress here today

[03:46] Fred Rookstown: Management?

[03:46] Latif Khalifa: and some more good stuff is coming with scripting

[03:46] Object: Changed Scale

[03:46] Babbage Linden: so the trick is to figure out which kinds of progress are easier and to make the most value for money changes

[03:46] Morgaine Dinova: Everything worthwhile is hard.

[03:46] Latif Khalifa: /me is happy

[03:46] Sebastean Steamweaver: Apparently changing the scale of a child prim does trigger the changed event.

[03:46] Sebastean Steamweaver: However, I'd still need one for position.

[03:46] Babbage Linden: adding mono was hard, but now it's there adding C# is easy (relatively) for example

[03:46] Babbage Linden: adding scene graphs is hard

[03:47] Morgaine Dinova: Agreed

[03:47] Babbage Linden: adding resizing libraries would be easier

[03:47] Babbage Linden: (and get most of what you want)

[03:47] Sheryl Mimulus: except hinges :P

[03:47] Kopilo Hallard: :p

[03:47] Latif Khalifa: how would you include a library? and where does it live?

[03:47] Babbage Linden: anyway, we've got quite a long way off the agenda, let's see what else there was

[03:48] Sebastean Steamweaver: Babbage, do you think a CHANGED_LINK_POSITION would be a viable JIRA? Or one for LINK_ROTATION for that matter?

[03:48] Fred Rookstown: I'm considering using OpenSceneGraph, but the sheer size of it is....

[03:48] Ceawlin Steamweaver: And avatar kinematics available via LSL! XD

[03:48] Babbage Linden: latif, a lot of that is up for discussion, let's talk about it next week :-D

[03:48] Kopilo Hallard: include llscalelib; ?

[03:48] Latif Khalifa: Babbage, OK :)

[03:48] Babbage Linden: so, llGetAgentInfo, what was the question there?

[03:48] Cerdita Piek: May I ask if 1.38 will have any of those new features to see the memory usage of a resident, objects, etc, and if so, how could we use it? will we need a new viewer, or?

[03:49] Sheryl Mimulus: hi CG

[03:49] Babbage Linden: Cerdita, yes, 1.38 should grant caps for script usage

[03:49] Jonathan Yap: Cerdita, the features are in place, you can use viewer 2 on aditi, look in about land

[03:49] Fred Rookstown: Is it going to be implemented? Basically, are we going to have the ability to grab agent information (viewer channel/version)

[03:49] Babbage Linden: so, you should be able to test it on aditi now

[03:49] Babbage Linden: open up about land with viewer 2

[03:49] Babbage Linden: and you should see a script info button

[03:49] Chaley May: what is aditi?

[03:49] Babbage Linden: /me makes a note to go test it on aditi later

[03:49] Babbage Linden: the beta grid

[03:49] Latif Khalifa: only parcel owner lat time i checked

[03:49] Cerdita Piek: oh, with viewer 2, I see, thanks.

[03:49] Latif Khalifa: last*

[03:49] Chaley May: ah never been

[03:50] Sebastean Steamweaver: Under which tab Babbage?

[03:50] Morgaine Dinova: I also dispute that it would be hard, nor disruptive, because there are ways of adding hierarchy that don't impact on current 1-level linksets and which don't modify current LSL --- in effect the current calls would be a subset that just applies within a node of the hierarchical tree. It wouldn't be the cleanest approach, but it would avoid breakage and be evolutionary.

[03:50] Babbage Linden: ok, thanks latif, we've found a bug

[03:50] Babbage Linden: :-D

[03:50] Kopilo Hallard: I see no script info button

[03:50] Jonathan Yap: Chaley, you will need to use ctrl alt G on the viewer 2 screen to make a grid selection drop down appear (the login screen)

[03:50] Chaley May: people dont need to find out what memory usage the items their buying use after they buy it

[03:51] Chaley May: we need objects able to tell us their usage i think

[03:51] Sebastean Steamweaver: 2.0 has a spelling error: "Primative Usage"

[03:51] Kopilo Hallard: ..

[03:51] Babbage Linden: chaley, I anticipate people will advertise memory usage when they sell objects

[03:51] Babbage Linden: thanks sebastean :-D

[03:51] Kopilo Hallard: mms

[03:51] Latif Khalifa: yeah we need memory usage on edit object floater the same way we can see prims now

[03:51] JB Hancroft: this is great progress

[03:51] Morgaine Dinova: People telling us is not the same thing as the objects telling us

[03:52] Jonathan Yap: /me mentions SVC-5467

[03:52] JIRA-helper (left hip):

[#SVC-5467] Display a breakdown of script and URL usage per object

[03:52] Sheryl Mimulus: "low memory usage" isn't a good marketing slogan

[03:52] Hypatia Callisto: they will advertise when their stuff is laggy nonsense... never :P

[03:52] Babbage Linden: right, thanks morgaine and latif

[03:52] Babbage Linden: hehe

[03:52] Kopilo Hallard: though I wonder how many scripts will be built around using more cpu for less memory?

[03:52] Sebastean Steamweaver: I like that JIRA Jon

[03:52] JB Hancroft: is there an API for having the object send memory usage via a callback?

[03:52] Kopilo Hallard: >_>

[03:52] Chaley May: i think hoping that people tell the script usage wont turn out so well

[03:52] Cerdita Piek: can we say that memory usage of an object is: number of scripts in an object*64K (if they are mono)?

[03:52] Latif Khalifa: i can see on Aditi that my mystitool uses 3mb ;)

[03:53] Sebastean Steamweaver: People who mind their memory can advertise their memory usage. I'd be wary of people that didn't.

[03:53] Sheryl Mimulus: wow

[03:53] Babbage Linden: cerdita, yes

[03:53] Babbage Linden: for now

[03:53] Latif Khalifa: any idea what per avatar limit would be babbage?

[03:53] Babbage Linden: latif, yes I have an idea, but I need to nudge Jack to tell people about it

[03:53] Latif Khalifa: ok

[03:53] Babbage Linden: as it's his call

[03:54] Sheryl Mimulus: not even a rough estimate?

[03:54] Babbage Linden: there was a question about Big Script timing

[03:54] Ceawlin Steamweaver: Babbage, I'd really encourage y'all to focus on getting us code sizes larger than 64k for the next big thing. Aside from the primparams craziness, which you've fixed, trying to run RPC and shared memory over link messages just cos you can't exceed 64k code size is the next major LSL killer. :< Not only does it make for some seriously bloated code and resource hoggery, it's just plain hard to debug. X_x

[03:54] Chaley May: it better be plenty :)

[03:54] Morgaine Dinova: How can it be Jack's call to make a decision on a technical matter?

[03:54] Babbage Linden: at the moment I would like to ship script usage, then small scripts, then script limits, then big scripts

[03:54] Sebastean Steamweaver: Ceawlin, I'd second that.

[03:54] Babbage Linden: we need to have script limits before we allow people to reserve arbitrary memory sizes

[03:55] Sebastean Steamweaver: Ah, true.

[03:55] Latif Khalifa: Morgaine, Jack's descision on the timing of disclosure of limits, not the limits themselves

[03:55] Babbage Linden: but we don't want mono scripts to look unfairly bloaty when we ship script limits

[03:55] Sheryl Mimulus: liandra, its why I told you shared variables are scary, you want as few as possible

[03:55] JB Hancroft: Good order... small scripts will let us back off on memory pressure

[03:55] Babbage Linden: so it would be nice to have mono scripts be able to reserve a lower memory amount before script limits enforcement happens

[03:55] Latif Khalifa: yes

[03:55] Morgaine Dinova: Latif: I certainly *hope* that's the case.

[03:55] Ceawlin Steamweaver: I know. But I can't afoid it in LSLwith anything of nontrivial size. :<

[03:55] Sebastean Steamweaver: JB: my personal hope is that I would need fewer small scripts if I didn't have to split up functions over several different ones.

[03:56] Chaley May: Will you store memory usage as an asset of the object so we can call it with llGetInventoryMemory or something?

[03:56] Babbage Linden: sebastean, agreed, but there will be cases when many scripts is a nicer solution

[03:56] Actingill Igaly: or an essential one

[03:56] Babbage Linden: (you shouldn't have to break up scripts arbitrarily, but you should be able to)

[03:56] Sebastean Steamweaver: /me nods

[03:56] JB Hancroft: Sebastean - yes, and no. smaller scripts let me focus on things and run them with less state complexity

[03:57] Sebastean Steamweaver: Are there any plans of giving us some form of persistent memory storage?

[03:57] Saijanai Kuhn: That's called notecards...

[03:57] Babbage Linden: also there will still be scripts operating on doors that will hopefully just need to reserve a couple of KB or memory

[03:57] Sebastean Steamweaver: Writeable, persistent memory storage ;)

[03:57] Xugu Madison: (must run, sorry I've been quiet. 1.38 looks fantastic though! See you all later)

[03:57] Actingill Igaly: thats called manual Saijanai

[03:57] Morgaine Dinova: Sai: notecards are not writable and will never be. So some other new types is needed.

[03:57] JB Hancroft: bye Xugu

[03:57] Babbage Linden: sebastean, that's a big topic let's cover it another day

[03:57] Sebastean Steamweaver: All righty

[03:58] Squirrel Wood: considering that many scripts are cobbled together from various other scripts until they barely do what they are supposed to do....

[03:58] Babbage Linden: let me see if we can work through the other agenda items

[03:58] Babbage Linden:

[03:58] JIRA-helper (left hip): [#SVC-546] Makira been offline for some time.

[03:58] Latif Khalifa: llHttpRequest + google app engine store FTW ;)

[03:58] Ceawlin Steamweaver: Latif++, lol.

[03:58] Babbage Linden:

[03:58] JB Hancroft: Babbage - LSL API to query an object's memory usage.. not just through the V2.0 use?

[03:58] JIRA-helper (left hip): [#SVC-5328] llSetObjectScale and llGetObjectScale

[03:58] Sebastean Steamweaver: XD

[03:58] Babbage Linden:

[03:58] JIRA-helper (left hip): [#SVC-5419] Add flag parameter [vector slice] to llSetPrimitiveParams PRIM_TYPE flags PRIM_TYPE_BOX, PRIM_TYPE_CYLINDER, and PRIM_TYPE_PRISM

[03:58] Saijanai Kuhn: I'm pretty sure I've heard of bots that serve notecards.

[03:58] Actingill Igaly: yes the slice parameter (/me starts up the record)

[03:59] Babbage Linden: I will look at the last one

[03:59] Babbage Linden: I think we've talked about the others

[03:59] Actingill Igaly: could that not have been implemented with llSetPrimParamsFast?

[03:59] Actingill Igaly: as it wouldn't break existing scripts

[03:59] Babbage Linden: yes, but see the comment on API surface area

[03:59] Sebastean Steamweaver: llSetLinkPrimitiveParamsFast uses the same constants as llSetPrimitiveParams.

[03:59] Babbage Linden: I'll have a look and see if it makes sense

[03:59] Sheryl Mimulus: speaking of persistent storage, I've always been tempted to write a simple http service on google app engine that allows us to do that

[03:59] Latif Khalifa: it would be nice to be able to get/set linked prims description, I've heard it mentioned not sure if it made it in 1.38

[04:00] Ceawlin Steamweaver: /me has one up, but nobody uses it. :<

[04:00] Saijanai Kuhn: SHeryl it would need to implement a minimal bot as far as I know

[04:00] Babbage Linden: right, times up: next time remind me that we're going to talk about persistent storage and libraries

[04:00] Sebastean Steamweaver: With script versioning, one could add the SLICE component.

[04:00] Babbage Linden: thanks for coming everyone

[04:00] Actingill Igaly: okies thanls

[04:00] Latif Khalifa: Ceawlin, java or python?

[04:00] Squirrel Wood: thanks for having us :p

[04:00] Sebastean Steamweaver: Thanks for your time and indulgence Babbage, I really appreciate it :)

[04:00] Ceawlin Steamweaver: Thanks for you time, babbage!

[04:00] Sheryl Mimulus: ceawlin isn't yours more of a dns lookup for http-in?

[04:00] Ceawlin Steamweaver: Latif: Java.

[04:00] Cerdita Piek: Thank you, Babbage. Take care :)

[04:00] Latif Khalifa: Babbage, thanks for your time and for the cool new stuff in 1.38

[04:00] JB Hancroft: thanks, Babbage

[04:00] Qie Niangao: thanks Babbage.