Second Life Wiki - User contributions [en]

Template:Main Page/Featured Pages

2007-06-11T14:40:03Z

Soft Noel:

<div id="box">

<h2>News</h2>
<div style="padding: 0.5em">
'''June 8''' - [[SLDev-Traffic 15]] is now available.</div>
</div>

SLDev Traffic

2007-06-11T13:14:19Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 15]] - through June 8, 2007
* [[SLDev-Traffic 14]] - through June 1, 2007
* [[SLDev-Traffic 13]] - through May 25, 2007
* [[SLDev-Traffic 12]] - through May 18, 2007
* [[SLDev-Traffic 11]] - through May 11, 2007
* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 15

2007-06-11T13:13:31Z

Soft Noel: New page: {{SLDevTraffic}} sldev-traffic no 15 sldev discussions through June 8, 2007 == Mute Visibility == Nicholaz Beresford created {{JIRA|VWR-1017}} to propose the ability to suppress object...

{{SLDevTraffic}}

sldev-traffic no 15

sldev discussions through June 8, 2007

== Mute Visibility ==
Nicholaz Beresford created {{JIRA|VWR-1017}} to propose the ability to suppress objects owned by others. There was some discussion on list about what form muting might take. Tateru Nino pointed out that since physics are performed server-side, the viewer alone couldn't make objects phantom, which poses a problem when colliding with ghosts. Able Whitman suggested the ability to set a partial alpha on these objects and suppress touch, llTargetOmega rotations and texture display. There was some further discussion toward refining the concept, and Able Whitman has begun researching how object and texture display is initiated by the viewer, including posting the sequence of functions used in bringing an object into view on the viewer, but no firm plan or design for visibility muting yet exists.

== Debian Etch i386 Builds ==
Paul Hampson announced that a user had performed i386 builds against his Debian patches. The result can be found at http://alzental-castle.de/~rd/SL/ - there is the added requirement of libcurl-openssl3, available from http://snapshot.debian.net

== Debian Packaging ==
Paul Hampson stated his intention to get the SL viewer included in Debian's official release. Soft Noel (Linden) inquired about whether Debian would accept packages that quickly become outdated, and Paul pointed to the existence of the [http://www.debian.org/volatile/ debian-volatile project], which now offers special case handling of exactly this type of fast moving target.

== Bug Triage and Housekeeping ==
Rob Lanphier (Linden) made a request for help in sorting out an agenda for a bug triage Monday, June 11. Nicholaz Beresford and Able Whitman pitched in, and Dzonatas Sol moved the agenda to a static, undated label at [[Bug triage/Agenda]] so wiki users could watch the page.

As a reminder, on Mondays, bug triages happen at 3pm at [http://slurl.com/secondlife/Grasmere/112/81/26/?&title=Rob+Linden%27s+office+in+Grasmere Rob's office in Grasmere]. If you're curious what goes into a triage, you can read the previous transcript at [[Bug_triage/2007-06-04]].

== CPU Detection ==
There was previous discussion about the best way to identify the CPU speed under Linux, with regard to issues {{JIRA|VWR-940}}, {{JIRA|VWR-962}}, {{JIRA|VWR-975}} and others. Dzonatas Sol posted code with an additional approach for CPU clock speed detection. The approach was to simply read the CPU cycle counter, sleep a few microseconds, read again, and scale to a one second interval.

Dzonatas also posts an updated patch against {{JIRA|VWR-962}}, for CPU type detection, with Thomas Rowland helping out with a minor fix.

== Contributing Code You Didn't Write ==
There was some speculation about the authorship of one piece of code under consideration for CPU speed detection, and what license it might fall under. Rob Lanphier (Linden) took the opportunity to post a strong reminder that any code not authored by the contributor should be noted as such. "Almost every software license out there (including MIT and BSD) have minimal requirements for acknowledgement." Treating code under a relatively unencumbered license as if were in the public domain is dangerous and potentially costly. Even code assumed to be in the public domain should be noted.

To be completely safe, Rob requests that third-party code be linked to in the JIRA, but not actually submitted as a patch.

== Patch for VWR-176 ==
Nicholaz Beresford posts a fix for {{JIRA|VWR-176}}, a crash activated by a sequence of object manipulations sometimes performed by accident. The patch is attached to the JIRA issue.

== Soft Linden ==
Soft Noel, your humble SLDev-Traffic editor, announced becoming a Linden this week.

To break the third-person schtick for a bit, thank you all so much for the congratulations on-list and off. Don't be shy about saying hi in-world, and if you're a signed contributor, consider friending Soft Linden so you're easier to harass with patch questions!

In response to the announcement, Nicholaz Beresford, aka "The Mad Patcher," got a bit silly with a terrible bit of Photoshoppery. The image is currently visible on [http://nicholaz-beresford.blogspot.com/ his blog]. Stick to coding, Nick. ;) And thanks again. :)

SLDev-Traffic 14

2007-06-11T11:56:49Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 14

sldev discussions through June 1, 2007

== Debit Permission Spoofing ==
There is a still-running conversation about how to address debit permission spoofing. In summary, its possible to lump together multiple permission requests in a permission request dialog, making it non obvious that debit permission is being granted. To wit, the dialog looks exactly as other dialogs users maya be accustomed to accepting blindly for actions as common as hugging and dancing.

Able Whitman attached a patch to {{JIRA|VWR-650}}, which makes the permissions dialog red if the debit permission is part of the request, as well as emitting the granter and the grantee's names to the log. Able's summary of the patch is also attached to the patch as a .txt file, wherein Able notes minor problems with the patch and asks for input.

More to follow when the thread runs its course. For now, the issue is still open and the problem still exists.

== Comment at End of LSL File Crash Fixed ==
Nicholaz Beresford was running the game with the debugger attached and found a hard lock. After posting the location of the lock as {{JIRA|VWR-869}}, Lex Neva provided input that helped Nicholaz confirm that this lock happened when an LSL script ended in a comment. Nicholaz submitted a patch, and Sardonyx Linden confirmed that the bug was now fixed.

== Crash with Invisible or Unrendered Flexis Crash Fixed ==
Nicholaz Beresford found a codepath wherein flexies could crash with an uninitialized variable. Nicholaz posted a patch against {{JIRA|VWR-870}}, and Tofu Linden confirmed that it had been applied.

== Dead Data Elimination Patch ==
Nicholaz Beresford identified some uninitialized variables, which turned out to be uninitialized as they were unused. A cleanup patch is posted against {{JIRA|VWR-873}}. Nicholaz identified it as a low-priority fix, and to date it has not been accepted.

== Uninitialized Members in llVolume ==
Nicholaz found some minor uninitialized variables. No malfunction was associated with these, but initialization would be safe, and Sardonyx Linden accepted the patch.

== More Leaks Fixed ==
Nicholaz Beresford identified memory leaks in the group dialog. After some back and forth with Sardonyx Linden, Sardonyx confirmed that a fix had been developed. Nicholaz provided a patch, attached to {{JIRA|VWR-966}}, which Sardonyx reports fixed as well.

Nicholaz links to [http://nicholaz-beresford.blogspot.com/2007/05/leftovers-leaks-and-leak.html a post] in his blog about his work so far. Thanks, Nicholaz!

== VWR-364 Still Open ==
{{JIRA|VWR-364}} persisted in this week's update, causing some further discussion on the mailing list and on the JIRA. Patches are attached and awaiting criticism or integration.

== Particle System Review ==
Nicholaz Beresford is continuing to examine why particle systems are not rendering consistently, with some emitters no longer emitting particles at all - reference {{JIRA|VWR-418}} for discussion and one possible patch. Of note, Nicholaz found that there used to be a block of code in llViewerPartGroup.cpp that randomly selected a particle system to begin with on each update (as well as apparently choosing whether the systems would be updated in forward or reverse order) - this code is no longer there. Further, while the viewer allows activating a large number of particles, the particle count is capped at 4096 at llviewerpartsim.cpp:44 (look for uses of MAX_PART_COUNT).

A comment in some older particle code suggests that the author didn't want to sort particle systems, and Argent Stonecutter suggested that a "slow bubble sort" would be an improvement if a full sort weren't desired - presumably this means a single pass through what's normally the outer loop of a bubble sort. Argent also suggested preventing particle systems from spawning if they're outside the view distance.

Nicholaz posted a patch to the list which implements an approach which does not require sorting, though it does not appear to be copied to the JIRA yet. There was no review of the patch on the list.

== Sticky Admin Options ==
Gigs Taggart posted a patch against {{JIRA|VWR-893}}, which makes the "view admin options" persist between logins.

== Object to Object IM Discussion ==
Kamilion Schnook asked whether object to object IM support would happen. Gigs Taggart, Erik Anderson and Strife Onizuka exchanged several ideas on why the functionality might not exist at current, while Tateru Nino noted that the task had been voted up and accepted in the old feature voting system, but that the state of the feature was currently unknown. Chance Unknown pointed to a [http://forums.secondlife.com/showthread.php?t=119570 2005 post] by Zero Linden, which detailed one method of accomplishing object to object communications via a user-hosted PHP script.

Kelly Linden confirmed suspicions that the cost of central object location tracking was one reason why object to object communications could be difficult, but made the suggestion that it would be feasible to offload the duty of region tracking to the scripter, who would include a region ID along with the target object ID. For any application with a known location for one end, this would be an easy win.

== CPU Identification ==
Gigs Taggart asked about {{JIRA|VWR-784}}, in which odd messages are given for identified CPUs under Linux. Several issues are linked to this one in JIRA, not all of them Linux-related. Dzonatas Sol pointed to a patch she submitted against {{JIRA|VWR-962}}, which lead to a continued discussion on the topic within JIRA on this and {{JIRA|VWR-975}}. Tofu Linden suggests that /proc/cpuinfo may be the better source of CPU information under Linux, and that he believes he recalls that CPU vendors recommend that people stop using CPUID.

Setting the above aside, Dzonatas Sol also posted a note about a bogus comparison which was resulting in streaming extensions always being reported as present, at {{JIRA|VWR-1062}}. This one didn't get any follow-up to date. (Thanks for your persistence on this, Dzonatas!)

== Entering Brackets and Braces Crashes German Viewer - Fixed ==
Some users had noted that entering certain characters in international viewers caused crashes. As it turns out, features from the debug render features menu were being toggled by these keys! Nicholaz Beresford attached a fix to {{JIRA|VWR-349}}. There was no follow-up discussion.

== Submitting Patches ==
Bryan O'Sullivan (Linden) posted, offering guidelines for how to submit patches that the Lindens can rapidly accept and integrate. Nicholaz Beresford took Bryan's request and added more details, producing [[Submitting patches]]. Gigs Taggart asked for some clarification on names being placed in the code, in response from a request by Rob Lanphier (Linden) to put credits in doc/contributions.txt as part of the patch. Ryan Williams (Linden) notes that names are only placed in code to note the most egregious hacks, for blame and cleanup, not for credit. Says Ryan, "So, we shouldn't be doing that, either."

== SLDev Traffic-12 Errata ==
In SLDev Traffic-12, I wrote about Callum Lerwick's patches for supporting OpenAL:<br/>
This could be a first step toward eliminating the need for fmod. In the past, there has also
been discussion of replacing fmod with gstreamer, but no patches have been submitted.
To be clear, fmod provides not only an audio voice playback API, but decoding as well. OpenAL and gstreamer would be complementary in replacing fmod, handling the voice abstraction and stream decoding respectively... ultimately we'd love to see both integrated, not one or the other. Seg Baphomet pointed out the ambiguity of my statement.

(Thanks for keeping me on my toes. -- Soft) :)

Template:Main Page/Featured Pages

2007-06-05T16:38:57Z

Soft Noel:

<div id="box">

<h2>News</h2>
<div style="padding: 0.5em">
'''June 1''' - [[SLDev-Traffic 14]] is now available.</div>
</div>

SLDev Traffic

2007-06-04T08:13:43Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 14]] - through June 1, 2007
* [[SLDev-Traffic 13]] - through May 25, 2007
* [[SLDev-Traffic 12]] - through May 18, 2007
* [[SLDev-Traffic 11]] - through May 11, 2007
* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 14

2007-06-04T08:12:24Z

Soft Noel: New page: {{SLDevTraffic}} sldev-traffic no 14 sldev discussions through June 1, 2007 left off at Object to Object Instant messaging (may 28) == Debit Permission Spoofing == There is a still-ru...

{{SLDevTraffic}}

sldev-traffic no 14

sldev discussions through June 1, 2007

left off at Object to Object Instant messaging (may 28)

== Debit Permission Spoofing ==
There is a still-running conversation about how to address debit permission spoofing. In summary, its possible to lump together multiple permission requests in a permission request dialog, making it non obvious that debit permission is being granted. To wit, the dialog looks exactly as other dialogs users maya be accustomed to accepting blindly for actions as common as hugging and dancing.

Able Whitman attached a patch to {{JIRA|VWR-650}}, which makes the permissions dialog red if the debit permission is part of the request, as well as emitting the granter and the grantee's names to the log. Able's summary of the patch is also attached to the patch as a .txt file, wherein Able notes minor problems with the patch and asks for input.

More to follow when the thread runs its course. For now, the issue is still open and the problem still exists.

== Comment at End of LSL File Crash Fixed ==
Nicholaz Beresford was running the game with the debugger attached and found a hard lock. After posting the location of the lock as {{JIRA|VWR-869}}, Lex Neva provided input that helped Nicholaz confirm that this lock happened when an LSL script ended in a comment. Nicholaz submitted a patch, and Sardonyx Linden confirmed that the bug was now fixed.

== Crash with Invisible or Unrendered Flexis Crash Fixed ==
Nicholaz Beresford found a codepath wherein flexies could crash with an uninitialized variable. Nicholaz posted a patch against {{JIRA|VWR-870}}, and Tofu Linden confirmed that it had been applied.

== Dead Data Elimination Patch ==
Nicholaz Beresford identified some uninitialized variables, which turned out to be uninitialized as they were unused. A cleanup patch is posted against {{JIRA|VWR-873}}. Nicholaz identified it as a low-priority fix, and to date it has not been accepted.

== Uninitialized Members in llVolume ==
Nicholaz found some minor uninitialized variables. No malfunction was associated with these, but initialization would be safe, and Sardonyx Linden accepted the patch.

== More Leaks Fixed ==
Nicholaz Beresford identified memory leaks in the group dialog. After some back and forth with Sardonyx Linden, Sardonyx confirmed that a fix had been developed. Nicholaz provided a patch, attached to {{JIRA|VWR-966}}, which Sardonyx reports fixed as well.

Nicholaz links to [http://nicholaz-beresford.blogspot.com/2007/05/leftovers-leaks-and-leak.html a post] in his blog about his work so far. Thanks, Nicholaz!

== VWR-364 Still Open ==
{{JIRA|VWR-364}} persisted in this week's update, causing some further discussion on the mailing list and on the JIRA. Patches are attached and awaiting criticism or integration.

== Particle System Review ==
Nicholaz Beresford is continuing to examine why particle systems are not rendering consistently, with some emitters no longer emitting particles at all - reference {{JIRA|VWR-418}} for discussion and one possible patch. Of note, Nicholaz found that there used to be a block of code in llViewerPartGroup.cpp that randomly selected a particle system to begin with on each update (as well as apparently choosing whether the systems would be updated in forward or reverse order) - this code is no longer there. Further, while the viewer allows activating a large number of particles, the particle count is capped at 4096 at llviewerpartsim.cpp:44 (look for uses of MAX_PART_COUNT).

A comment in some older particle code suggests that the author didn't want to sort particle systems, and Argent Stonecutter suggested that a "slow bubble sort" would be an improvement if a full sort weren't desired - presumably this means a single pass through what's normally the outer loop of a bubble sort. Argent also suggested preventing particle systems from spawning if they're outside the view distance.

Nicholaz posted a patch to the list, though it does not appear to be copied to the JIRA yet. There was no review of the patch on the list.

== Sticky Admin Options ==
Gigs Taggart posted a patch against {{JIRA|VWR-893}}, which makes the "view admin options" persist between logins.

== Object to Object IM Discussion ==
Kamilion Schnook asked whether object to object IM support would happen. Gigs Taggart, Erik Anderson and Strife Onizuka exchanged several ideas on why the functionality might not exist at current, while Tateru Nino noted that the task had been voted up and accepted in the old feature voting system, but that the state of the feature was currently unknown. Chance Unknown pointed to a [http://forums.secondlife.com/showthread.php?t=119570 2005 post] by Zero Linden, which detailed one method of accomplishing object to object communications via a user-hosted PHP script.

Kelly Linden confirmed suspicions that the cost of central object location tracking was one reason why object to object communications could be difficult, but made the suggestion that it would be feasible to offload the duty of region tracking to the scripter, who would include a region ID along with the target object ID. For any application with a known location for one end, this would be an easy win.

== CPU Identification ==
Gigs Taggart asked about {{JIRA|VWR-784}}, in which odd messages are given for identified CPUs under Linux. Several issues are linked to this one in JIRA, not all of them Linux-related. Dzonatas Sol pointed to a patch she submitted against {{JIRA|VWR-962}}, which lead to a continued discussion on the topic within JIRA on this and {{JIRA|VWR-975}}. Tofu Linden suggests that /proc/cpuinfo may be the better source of CPU information under Linux, and that he believes he recalls that CPU vendors recommend that people stop using CPUID.

Setting the above aside, Dzonatas Sol also posted a note about a bogus comparison which was resulting in streaming extensions always being reported as present, at {{JIRA|VWR-1062}}. This one didn't get any follow-up to date. (Thanks for your persistence on this, Dzonatas!)

== Entering Brackets and Braces Crashes German Viewer - Fixed ==
Some users had noted that entering certain characters in international viewers caused crashes. As it turns out, features from the debug render features menu were being toggled by these keys! Nicholaz Beresford attached a fix to {{JIRA|VWR-349}}. There was no follow-up discussion.

== Submitting Patches ==
Bryan O'Sullivan (Linden) posted, offering guidelines for how to submit patches that the Lindens can rapidly accept and integrate. Nicholaz Beresford took Bryan's request and added more details, producing [[Submitting patches]]. Gigs Taggart asked for some clarification on names being placed in the code, in response from a request by Rob Lanphier (Linden) to put credits in doc/contributions.txt as part of the patch. Ryan Williams (Linden) notes that names are only placed in code to note the most egregious hacks, for blame and cleanup, not for credit. Says Ryan, "So, we shouldn't be doing that, either."

== SLDev Traffic-12 Errata ==
In SLDev Traffic-12, I wrote about Callum Lerwick's patches for supporting OpenAL:<br/>
This could be a first step toward eliminating the need for fmod. In the past, there has also
been discussion of replacing fmod with gstreamer, but no patches have been submitted.
To be clear, fmod provides not only an audio voice playback API, but decoding as well. OpenAL and gstreamer would be complementary in replacing fmod, handling the voice abstraction and stream decoding respectively... ultimately we'd love to see both integrated, not one or the other. Seg Baphomet pointed out the ambiguity of my statement.

(Thanks for keeping me on my toes. -- Soft) :)

Template:Main Page/Featured Pages

2007-05-28T17:31:35Z

Soft Noel:

<div id="box">

<h2>News</h2>
<div style="padding: 0.5em">
'''May 27''' - [[SLDev-Traffic 13]] is now available.</div>
</div>

SLDev-Traffic 13

2007-05-28T04:12:46Z

Soft Noel: /* Memory Leak Patches, Leak in libcurl */ Nicer formatting

{{SLDevTraffic}}

sldev-traffic no 13

sldev discussions through May 25, 2007

== Memory Leak Patches, Leak in libcurl ==
Nicholaz Beresford (corrent the name if it's wrong and combining two people! - I believe I'm uniting a RL and SL name being used interchangeably in several postings -- Soft) posted patches dealing with memory leaks, and requested peer review. The patches are found attached to {{JIRA|VWR-364}}. There was no follow-up on the list.

Subsequently, Nicholaz also identified a leak that may be fixed in newer versions of libcurl. Nicholaz tested with 7.16.2. It's not clear from contet whether this usurps the patch for llcurl.h in {{JIRA|VWR-805}}.

More leak finds followed from Nicholaz, each without further discussion on-list:
::{{JIRA|VWR-802}} fix a leak in llmessageconfig
::{{JIRA|VWR-803}} fix a leak in llcallingcard
::{{JIRA|VWR-804}} fix a leak in llviewerwindow
::{{JIRA|VWR-807}} fix a leak in lltoolmgr.cpp
::{{JIRA|VWR-808}} fix a leak in message.cpp
::{{JIRA|VWR-809}} fix a leak in llviewermenu.cpp
::{{JIRA|VWR-810}} fix a leak in llview.cpp
::{{JIRA|VWR-794}} fix a leak in llviewerpartsource.cpp, which paralleled the problem at {{JIRA|VWR-364}}

== System Memory Use Spiked by High End Graphic Boards ==
Nicholaz also discovered that the viewer allocates system memory matching the size of the video card's texture memory, plus a small multiple. This is problematic for low memory systems with high end graphics cards. Nicholaz posted a proposed patch, attached to {{JIRA|VWR-733}} and Steve Linden took the patch up for examination. After a revision and discussion, a fix may go into the next viewer.

Nicholaz posts a related patch at {{JIRA|VWR-778}}, which tackles the problem in the opposite direction, where texture buffers are too small on low-end cards. This one didn't receive attention. Callum Lerwick noted that this was related to {{JIRA|VWR-207}}, and Nicholaz updated the patch to address this issue as well.

== Texture Debug Console Fixes ==
Nicholaz again! Nicholaz posted changes that unclutter the texture-mem part of the Shift-Ctrl-3 texture debug console. The change also fixes a couple uninitialized variables. This, at {{JIRA|VWR-779}}

== Possible Particle Patch ==
Nicholaz (time for a macro!) also posted a patch, attached to {{JIRA|VWR-418}}, which attempts to solve the problem of new particles not showing up when lots of infinite-life (lifespan of zero) particles are emitted. As part of the patch, Nicholaz also fixes a particle memory leak associated with region crossings/changes. There is some ambiguous discussion on the list, and it's not clear whether this patch overlaps the patch on {{JIRA|VWR-794}}, also from Nicholaz.

Nicholaz is one busy Second Lifer!

Tateru Nino offered Nicholaz a kiss. :)

== SL Viewer Stats Requested ==
LL loves keeping stats. Jason Giglio inquired as to whether SLDev could learn the breakdown on platforms in use, video cards, CPUs, average framerates, or any other information that might help the list.

To date there hasn't been a response.

== Dead Code ==
Ben Byer notes that there seems to be a lot of dead code in the SL Viewer. Callum Lerwick points out that some of the code is common to the viewer and to server code, with Jason Giglio pointing out that shared code should exist in llcommon... the rest is fair game.

Ben made a first attempt at identifying dead code, however he was bitten by inlining making some functions appear to be unreferenced when linking. Nobody has yet tried again with inlining disabled. Meanwhile, Jacek Antonelli points to llanimalcontrols.cpp, llcape.cpp, llgenepool.cpp and llhippo.cpp as likely candidates for removal.

== Bridie Holds Bug Triage ==
Rob Lanphier (Linden) was out this week. Bridie Saccocio (Linden) stepped in to take over Monday's session. Notes are at [[Bug_triage/2007-05-21]]. Thanks, Bridie!

== Survey Contest ==
A.C.Vandergraaf posted a survey link to the list, stating that there was a L$ prize for answering the questions. I'm not linking the survey directly; instead read [https://lists.secondlife.com/pipermail/sldev/2007-May/001942.html the message] and judge whether you think it's appropriate to the list. (I honestly couldn't decide, so I'm erring on the side of reproducing this -- Soft) Vandergraaf also posts a link, promising the results of the survey will appear there.

== Texture Cache Update ==
Steve Linden posts a heads up that the texture cache is changing dramatically, specifically in the code pertaining to the entry lists. Check with Steve if you've got open patches against this system and want to know if they'll still apply. Steve indicates that the interface to LLTextureCache hasn't changed, so anyone working on a complete replacement - something Steve encourages - will be unaffected.

== Sculpted Prims Patch ==
Dirk Moerenhout posts a patch to the list, stating that it speeds up patch generation and fixes problems with 32x32 textures. There was no JIRA created, and no discussion followed. The patch is attached to the [https://lists.secondlife.com/pipermail/sldev/2007-May/001962.html original message].

SLDev Traffic

2007-05-28T04:03:54Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 13]] - through May 25, 2007
* [[SLDev-Traffic 12]] - through May 18, 2007
* [[SLDev-Traffic 11]] - through May 11, 2007
* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 13

2007-05-28T04:02:44Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 13

sldev discussions through May 25, 2007

== Memory Leak Patches, Leak in libcurl ==
Nicholaz Beresford (corrent the name if it's wrong and combining two people! - I believe I'm uniting a RL and SL name being used interchangeably in several postings -- Soft) posted patches dealing with memory leaks, and requested peer review. The patches are found attached to {{JIRA|VWR-364}}. There was no follow-up on the list.

Subsequently, Nicholaz also identified a leak that may be fixed in newer versions of libcurl. Nicholaz tested with 7.16.2. It's not clear from contet whether this usurps the patch for llcurl.h in {{JIRA|VWR-805}}.

More leak finds followed from Nicholaz, each without further discussion on-list: {{JIRA|VWR-802}} contains a fix for a leak in llmessageconfig. {{JIRA|VWR-803}} contains a fix for a leak in llcallingcard. {{JIRA|VWR-804}} contains a fix for a leak in llviewerwindow. {{JIRA|VWR-807}} fixes a leak in lltoolmgr.cpp. {{JIRA|VWR-808}} contains a fix for a leak in message.cpp. {{JIRA|VWR-809}} fixes a leak in llviewermenu.cpp. {{JIRA|VWR-810}} fixes a leak in llview.cpp. {{JIRA|VWR-794}} fixes a leak in llviewerpartsource.cpp, which paralleled the problem at {{JIRA|VWR-364}}.

== System Memory Use Spiked by High End Graphic Boards ==
Nicholaz also discovered that the viewer allocates system memory matching the size of the video card's texture memory, plus a small multiple. This is problematic for low memory systems with high end graphics cards. Nicholaz posted a proposed patch, attached to {{JIRA|VWR-733}} and Steve Linden took the patch up for examination. After a revision and discussion, a fix may go into the next viewer.

Nicholaz posts a related patch at {{JIRA|VWR-778}}, which tackles the problem in the opposite direction, where texture buffers are too small on low-end cards. This one didn't receive attention. Callum Lerwick noted that this was related to {{JIRA|VWR-207}}, and Nicholaz updated the patch to address this issue as well.

== Texture Debug Console Fixes ==
Nicholaz again! Nicholaz posted changes that unclutter the texture-mem part of the Shift-Ctrl-3 texture debug console. The change also fixes a couple uninitialized variables. This, at {{JIRA|VWR-779}}

== Possible Particle Patch ==
Nicholaz (time for a macro!) also posted a patch, attached to {{JIRA|VWR-418}}, which attempts to solve the problem of new particles not showing up when lots of infinite-life (lifespan of zero) particles are emitted. As part of the patch, Nicholaz also fixes a particle memory leak associated with region crossings/changes. There is some ambiguous discussion on the list, and it's not clear whether this patch overlaps the patch on {{JIRA|VWR-794}}, also from Nicholaz.

Nicholaz is one busy Second Lifer!

Tateru Nino offered Nicholaz a kiss. :)

== SL Viewer Stats Requested ==
LL loves keeping stats. Jason Giglio inquired as to whether SLDev could learn the breakdown on platforms in use, video cards, CPUs, average framerates, or any other information that might help the list.

To date there hasn't been a response.

== Dead Code ==
Ben Byer notes that there seems to be a lot of dead code in the SL Viewer. Callum Lerwick points out that some of the code is common to the viewer and to server code, with Jason Giglio pointing out that shared code should exist in llcommon... the rest is fair game.

Ben made a first attempt at identifying dead code, however he was bitten by inlining making some functions appear to be unreferenced when linking. Nobody has yet tried again with inlining disabled. Meanwhile, Jacek Antonelli points to llanimalcontrols.cpp, llcape.cpp, llgenepool.cpp and llhippo.cpp as likely candidates for removal.

== Bridie Holds Bug Triage ==
Rob Lanphier (Linden) was out this week. Bridie Saccocio (Linden) stepped in to take over Monday's session. Notes are at [[Bug_triage/2007-05-21]]. Thanks, Bridie!

== Survey Contest ==
A.C.Vandergraaf posted a survey link to the list, stating that there was a L$ prize for answering the questions. I'm not linking the survey directly; instead read [https://lists.secondlife.com/pipermail/sldev/2007-May/001942.html the message] and judge whether you think it's appropriate to the list. (I honestly couldn't decide, so I'm erring on the side of reproducing this -- Soft) Vandergraaf also posts a link, promising the results of the survey will appear there.

== Texture Cache Update ==
Steve Linden posts a heads up that the texture cache is changing dramatically, specifically in the code pertaining to the entry lists. Check with Steve if you've got open patches against this system and want to know if they'll still apply. Steve indicates that the interface to LLTextureCache hasn't changed, so anyone working on a complete replacement - something Steve encourages - will be unaffected.

== Sculpted Prims Patch ==
Dirk Moerenhout posts a patch to the list, stating that it speeds up patch generation and fixes problems with 32x32 textures. There was no JIRA created, and no discussion followed. The patch is attached to the [https://lists.secondlife.com/pipermail/sldev/2007-May/001962.html original message].

Open Source Portal

2007-05-23T13:35:32Z

Soft Noel: Revert spam

__NOTOC__

{|cellspacing="5px"
|valign="top" width="50%"|
{{Open Source Portal/News}}
|valign="top" width="50%"|
{{Open Source Portal/Links}}
|}
<div id="box">
<center>''Getting started''</center>
{|cellspacing="5px"
|valign="top" width="50%"|
<div id="box">

<h2>Learn</h2>
<div style="padding: 0.5em">

{{OSWikiLearnBox}}
A lot of the documentation below is geared toward developers. However, many aspects of the system don't require a deep technical background to learn. Much of this is still a work in progress, but since this is a wiki, you can help fill in the blanks!

* '''[[Features]]''' - An overview of the major components of the system as seen from an end user's perspective. Links to specifications, test plans and other documentation can be found here.
* '''[[Viewer architecture]]''' - This is an overview of the viewer from a developer's perspective.
* '''[[Protocol]]''' - in depth documentation of the protocol
* '''[[Extended FAQ]]''' - For questions that don't get covered in {{OSWebsite|faq|alt=the main open source FAQ}}.

[[Documentation|more...]]

</div></div>
|valign="top" width="50%"|
<div id="box">

<h2>Participate</h2>
<div style="padding: 0.5em">

{{OSWikiContribBox}}

We want your help to make the Second Life Viewer better! You don't need to know C++ or even programming to help. Some of the toughest jobs in software development have nothing to do with writing code. Just grab [[Downloading test builds|a test build]] and try playing around with it. Let us know what you think on email, on the forum, or IRC. If it's not working for you, try to get help there. If it is working for you, try helping someone who isn't having as much luck as you are. If you run into issues, see if a bug report has been filed, and if it isn't file it. If it has been filed, vote for it, perhaps filling in more detail.

Of course, if you ''are'' a developer, we can use your help. Download the code, and see if you can get it to build. Try your hand at fixing a bug, or extending the software through one of the APIs. There's a ton of ways you can help, and we welcome you regardless of your skill level.

[[Participating|more...]]
</div></div>
|-
|}
</div>

[[Category:Portals]]

User talk:Soft Noel

2007-05-23T00:10:04Z

Soft Noel:

== <nowiki>{{Jira Reporter}}</nowiki> ==

Hi Soft Noel.
Consider to include <nowiki>{{Jira Reporter}}</nowiki> on your user page. It'll link to Jira issues reported by you.
--[[User:Boroondas Gupte|Boroondas Gupte]] 15:49, 22 May 2007 (PDT)
:Done, thanks! --[[User:Soft Noel|Soft Noel]] 17:10, 22 May 2007 (PDT)

User:Soft Noel

2007-05-23T00:07:26Z

Soft Noel:

Developer and editor of [[SLDev Traffic]]

{{Jira Reporter}}

SLDev Traffic

2007-05-21T03:35:56Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 12]] - through May 18, 2007
* [[SLDev-Traffic 11]] - through May 11, 2007
* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 12

2007-05-21T03:35:17Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 12

sldev discussions through May 18, 2007

== OpenAL Support Patch ==
Callum Lerwick posted a patch enabling OpenAL support - OpenAL is an open source audio library that is to audio what OpenGL is to 3D graphics. Callum has tested the patch under Linux only, and lists a few problems. There was no follow-up conversation on the list. The patch can be found attached to the original [https://lists.secondlife.com/pipermail/sldev/2007-May/001764.html announcement].

This could be a first step toward eliminating the need for fmod. In the past, there has also been discussion of replacing fmod with gstreamer, but no patches have been submitted.

== Boo to BOOL ==
Alan Grimes attempted a patch converting all BOOLs to standard C++ bools, and posted a rough benchmark showing less runtime consumed when running for "about ten minutes," as well as a smaller memory footprint. Paul Hampson looked over the large patch and noted some changes that would cause problems or that didn't change code as intended. After some further discussion, Andrew Meadows (Linden) suggested that an all-at-once BOOL to bool patch would not work. In summary, there were too many opportunities for subtle bugs to be introduced, and the patch would go stale fast in touching so many systems at once. He suggested that the best SLDev members could do would be to make all new code use bools and to make BOOL to bool conversions opportunistically when submitting patches in local code -- eventually a sweeping replacement would be easier to effect.

== unicode.ttf Link ==
Alan Grimes notes that the unicode.ttf link is invalid with his *nix distribution. Tofu Linden replied, saying that the link is an interim workaround until fontconfig support is implemented. The link can be treated as a reminder to add an appropriate link if the link is invalid for a given system.

Alissa Sabre followed up with a fontconfig patch. There was no indication that the patch had been added to the JIRA. The patch can be found in Alissa's [https://lists.secondlife.com/pipermail/sldev/2007-May/001869.html original message].

== Privacy Pockets ==
A very wide-reaching discussion of the need for and design of privacy pockets continues. Some SLDev members questioned the need and effectiveness. Justifications for the need for privacy were given that didn't just pertain to sexual activities, but also business meetings, development of projects under non-disclosure, and the cost-effectiveness of private islands as the current only privacy solution. The effectiveness of the pockets varied with the proposed implementation - there were many proposals, all centering around the theme of making the contents of a pocket invisible to other classes of users, be they predefined sets, owner-customizable sets, or users not entering the same WoW-like "instances" with multiple parallel instantiations of the same space.

List members noted that there has been resistance to changing the size of the usable vertical area of a region, and that proposals for putting the private areas below 0 meters or above the current 768ish height were likely to present non-trivial technical challenges. In reply to a discussion about the scaling challenges of pockets, which might affect different users' view of the map, Kelly Washington (Linden) posted, noting that anything that had an effect localized to a region wasn't a scaling issue - but things that affected non-local users, such as the contents of the global map, did present scaling issues.

There haven't been any hard conclusions, and near-term patches are unlikely as this would largely be a server-side implementation issue.

SLDev Traffic

2007-05-14T02:52:28Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 11]] - through May 11, 2007
* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 11

2007-05-14T02:52:02Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 11

sldev discussions through May 11, 2007

== Cleaning Up the Linux Build ==
Alan Grimes posted a patch aimed at using standard system-provided headers for more of the Linux build. He specifically named GL headers, noting that the current redefinition of GL types is dangerous. There was no follow-up discussion, and no indication that a JIRA was created for the patch. Despite an initial difficulty in posting the patch, the patch is now archived here:<br/>http://lists.secondlife.com/pipermail/sldev/attachments/20070508/cca387d9/changes-0001.bin

== Debian and OpenSUSE Packages ==
Paul Hampson is working on a .deb packaging of the viewer -- this should work for Debian and Ubuntu alike. The repository is at http://www.tbble.net/debian/ although it appears that at present, only a PowerPC build exists. There was no further discussion about the package or whether other processor builds would follow from Paul.

Rob Lanphier (Linden) spoke with Seth Arnold from SuSE about using the OpenSUSE build service, which allows users to build software for multiple distributions on SuSE's own servers. Marc Dietrich used the service, producing RPMs for OpenSUSE, and also expressed the intent of producing Fedora and Debian packages in the future. The existing packages can be found here:<br/>http://software.opensuse.org/download/home:/marvin24/

== Filing Bugs with Ambiguous Categories ==
Alissa Sabre asked what should be done when filing a bug that seemed to cover more than one area of functionality, giving an example of one bug that could arguably be an internationalization bug, a UI bug, or even a graphics bug. Rob Lanphier (Linden) noted that it's possible and acceptable to select multiple categories. Rob also asked for a volunteer who might document the reporting process, offering to link from JIRA to a suitable writeup on the wiki.

== Command-Line History Patch Accepted ==
Zi Ree's patch for command-line history went in, received a few votes, got noticed, and boom - in it goes. Tofu Linden acknowledged that the patch had been applied to the maintenance branch after some brief on-JIRA discussion between Zi Ree, Tofu Linden, and Torley Linden. As Elbereth Witte said on {{JIRA|VWR-671}} -- "awesome."

The absolute best way to get a patch accepted is to follow Zi's procedure of posting the patch to the JIRA and including a note on the mailing list. List members can vote the bug upward after review, and the JIRA will be mentioned on SLDev-Traffic as well.

== Cursor Position Patch Accepted ==
Zi Ree posted another patch as {{JIRA|VWR-682}}, which maintains a cursor X position when scrolling past short lines in a multi-line text box. Tofu Linden reviewed and committed the patch. Thanks again, Zi!

== Automatic Name-Filling on Object Abuse Reports ==
Tateru Nino filed {{JIRA|VWR-597}} requesting that when filing abuse reports against objects, the owner's name be filled automatically. Jacek Antonelli attached a patch to this JIRA that accomplishes this, as well as auto-filling the abuse reportee's name when selecting an avatar. There was no further discussion on the list.

== Privacy Pockets ==
There is an ongoing discussion about "privacy pockets," also JIRA'd at {{JIRA|SVC-205}}. The discussion does not look to have settled yet, so I'll document this further next week. In brief, the concept is that users would like to be able to create pockets of space that can only be seen and heard from within the pocket. These would reside at the top of the buildable range on parcels flagged for pocket participation.

SLDev-Traffic 10

2007-05-07T04:33:55Z

Soft Noel: Trademark

{{SLDevTraffic}}

sldev-traffic no 10

sldev discussions through May 4, 2007

== Top Viewer Crashes ==
Dan Maronn (Linden) posted the ten most frequent Windows viewer crashes at [[Fixing bugs]], as well as the five most common Mac viewer crashes. Dan will attempt to keep these updated weekly. Each item includes a link to the relevant JIRA issue, where users and developers can discuss the crashes, as well as a dump of the call stack.

At present, the information is minimal, lacking a register dump or an indication of the type of crash, but these may be useful for visual code inspection or adding extra error checking code in local builds to identify unexpected behaviors.

Ben Byer also notes that the Mac crashes don't indicate whether the version in use is Intel or PowerPC and asks if Linden Lab are familiar with [http://smartcrashreports.com/ Smart Crash Reports], a tool for producing better crash reports on the Mac. Dan says that Aric Linden is looking at it.

== Working with Sculpted Prims ==
John Hurliman wrote a C# viewer for sculpted prims, posting the full source to SLDev. Windows and XNA Game Studio Express is required to run the viewer. John noted that lossy image compression of the sculpting texture added significant visual distortion to sculpted prims, and inquired whether lossless JPEG-2000 compression would be available. Ryan Williams (Linden) said he believed this was the plan, and that the sculpting texture delivery piggybacked on the existing texture delivery mechanism, enabling progressive models.

John Hurliman also created a program attempting to turn arbitrary meshes into sculpted prim textures, but met with limited success and solicited ideas for improvement. Andrew Meadows (Linden) notes that sculpted prims really only work with objects having the topology of a sphere, however he suggested one method whereby a mesh of springs could be wrapped about an arbitrary model, allowed to stabilize as springs with an additional constraint limiting them to the surface, and the vertices would then be quantized to the nearest pixel.

Erik Anderson inquired as to whether torus topology sculpted prims would help, allowing objects to be modeled with a single hole as well. Frans notes that Qarl Linden already promised this for the second revision on [[Talk:Sculpted_Prims]]. Actually, Qarl promises several more permutations!

== Sculpted Prim -- Will It Blend?'''™''' ==
Amanda Levitsky has begun working with sculpted prims in Blender, and posts [http://amandalevitsky.googlepages.com/sculptedprims this tutorial]. Of note, Blender is free, and [http://www.blender.org available for all Second Life platforms].

If you're new to Blender, Amanda suggests:<br />
http://www.blender.org/tutorials-help/quickstart/<br />
http://www.blender.org/tutorials-help/tutorials/tutorial-folder/blender-user-interface-tutorial/

Blender's interface is notoriously intimidating. Says Amanda:<br />
The UI isn't intuitive to learn, but it /is/ well used by its developers and very
efficient to work with.

Jessicatz Fairymeadow also suggests a Wiki book on Blender:<br />
http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

== Python Using Spaces ==
Linden Lab have standardized on spaces four-space indentation, no tabs, for Python scripts. Paul Hampson ran into this detail, and Rob Lanphier (Linden) noted the change.

For the uninitiated, this isn't a bikeshed argument. Spacing is a non-trivial detail in Python. Python uses indentation to identify control blocks, as opposed to curly braces, "BEGIN" and "END" or the like. Mixing tabs and spaces with a non-standard tab size can create blocks that are visibly in the same block, but logically are not.

== Chat Logging Patch ==
Harold Brown posted [https://lists.secondlife.com/pipermail/sldev/2007-May/001701.html a patch] that allows logs to include not just times, but date stamps, as well as a few other features. A screenshot [http://www.rpgstats.com/SL/chatlog.jpg is available]. There were no responses, and there was no indication that a JIRA had been created.

== Chat History Patch ==
Zi Ree created support for chat line history, posting it to {{JIRA|VWR-671}}. There were no responses on-list or in the JIRA. If you'd like this one to go in, now's a good time to vote on the JIRA issue.

== Subversion Repository! ==
Big news! Rob Lanphier (Linden) posts:
Hi folks,

After way too much delay (sorry), I'm happy to announce that we now have
an official version control repository. Details are here:

https://wiki.secondlife.com/wiki/Version_control_repository

Note that the only thing that's in the source repository is the source
code. All of the supporting libraries, art, fonts, etc, still need to
be received via downloaded zipfile/tarball. In order to (hopefully)
ensure things start off on the right foot, I've created snapshots
corresponding to the latest checkins on the four current branches:

https://wiki.secondlife.com/wiki/Source_downloads#Betas_and_other_snapshots

Enjoy!

Of note, there are free [http://subversion.tigris.org/links.html#clients GUI and command-line Subversion tools] available on all Second Life platforms and for all major IDEs. For the uninitiated, the authoritative book on Subversion is [http://svnbook.red-bean.com/ available online] for free, or in hardcopy from major book sellers. The impatient can start [http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.initial here].

The first step to getting a submitter account is to submit a signed code contributor agreement to Linden Lab. Further details are on the [[Version control repository]] page.

SLDev-Traffic 10

2007-05-07T04:31:43Z

Soft Noel: /* Sculpted Prims in Blender */

{{SLDevTraffic}}

sldev-traffic no 10

sldev discussions through May 4, 2007

== Top Viewer Crashes ==
Dan Maronn (Linden) posted the ten most frequent Windows viewer crashes at [[Fixing bugs]], as well as the five most common Mac viewer crashes. Dan will attempt to keep these updated weekly. Each item includes a link to the relevant JIRA issue, where users and developers can discuss the crashes, as well as a dump of the call stack.

At present, the information is minimal, lacking a register dump or an indication of the type of crash, but these may be useful for visual code inspection or adding extra error checking code in local builds to identify unexpected behaviors.

Ben Byer also notes that the Mac crashes don't indicate whether the version in use is Intel or PowerPC and asks if Linden Lab are familiar with [http://smartcrashreports.com/ Smart Crash Reports], a tool for producing better crash reports on the Mac. Dan says that Aric Linden is looking at it.

== Working with Sculpted Prims ==
John Hurliman wrote a C# viewer for sculpted prims, posting the full source to SLDev. Windows and XNA Game Studio Express is required to run the viewer. John noted that lossy image compression of the sculpting texture added significant visual distortion to sculpted prims, and inquired whether lossless JPEG-2000 compression would be available. Ryan Williams (Linden) said he believed this was the plan, and that the sculpting texture delivery piggybacked on the existing texture delivery mechanism, enabling progressive models.

John Hurliman also created a program attempting to turn arbitrary meshes into sculpted prim textures, but met with limited success and solicited ideas for improvement. Andrew Meadows (Linden) notes that sculpted prims really only work with objects having the topology of a sphere, however he suggested one method whereby a mesh of springs could be wrapped about an arbitrary model, allowed to stabilize as springs with an additional constraint limiting them to the surface, and the vertices would then be quantized to the nearest pixel.

Erik Anderson inquired as to whether torus topology sculpted prims would help, allowing objects to be modeled with a single hole as well. Frans notes that Qarl Linden already promised this for the second revision on [[Talk:Sculpted_Prims]]. Actually, Qarl promises several more permutations!

== Sculpted Prim -- Will It Blend? ==
Amanda Levitsky has begun working with sculpted prims in Blender, and posts [http://amandalevitsky.googlepages.com/sculptedprims this tutorial]. Of note, Blender is free, and [http://www.blender.org available for all Second Life platforms].

If you're new to Blender, Amanda suggests:<br />
http://www.blender.org/tutorials-help/quickstart/<br />
http://www.blender.org/tutorials-help/tutorials/tutorial-folder/blender-user-interface-tutorial/

Blender's interface is notoriously intimidating. Says Amanda:<br />
The UI isn't intuitive to learn, but it /is/ well used by its developers and very
efficient to work with.

Jessicatz Fairymeadow also suggests a Wiki book on Blender:<br />
http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

== Python Using Spaces ==
Linden Lab have standardized on spaces four-space indentation, no tabs, for Python scripts. Paul Hampson ran into this detail, and Rob Lanphier (Linden) noted the change.

For the uninitiated, this isn't a bikeshed argument. Spacing is a non-trivial detail in Python. Python uses indentation to identify control blocks, as opposed to curly braces, "BEGIN" and "END" or the like. Mixing tabs and spaces with a non-standard tab size can create blocks that are visibly in the same block, but logically are not.

== Chat Logging Patch ==
Harold Brown posted [https://lists.secondlife.com/pipermail/sldev/2007-May/001701.html a patch] that allows logs to include not just times, but date stamps, as well as a few other features. A screenshot [http://www.rpgstats.com/SL/chatlog.jpg is available]. There were no responses, and there was no indication that a JIRA had been created.

== Chat History Patch ==
Zi Ree created support for chat line history, posting it to {{JIRA|VWR-671}}. There were no responses on-list or in the JIRA. If you'd like this one to go in, now's a good time to vote on the JIRA issue.

== Subversion Repository! ==
Big news! Rob Lanphier (Linden) posts:
Hi folks,

After way too much delay (sorry), I'm happy to announce that we now have
an official version control repository. Details are here:

https://wiki.secondlife.com/wiki/Version_control_repository

Note that the only thing that's in the source repository is the source
code. All of the supporting libraries, art, fonts, etc, still need to
be received via downloaded zipfile/tarball. In order to (hopefully)
ensure things start off on the right foot, I've created snapshots
corresponding to the latest checkins on the four current branches:

https://wiki.secondlife.com/wiki/Source_downloads#Betas_and_other_snapshots

Enjoy!

Of note, there are free [http://subversion.tigris.org/links.html#clients GUI and command-line Subversion tools] available on all Second Life platforms and for all major IDEs. For the uninitiated, the authoritative book on Subversion is [http://svnbook.red-bean.com/ available online] for free, or in hardcopy from major book sellers. The impatient can start [http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.initial here].

The first step to getting a submitter account is to submit a signed code contributor agreement to Linden Lab. Further details are on the [[Version control repository]] page.

SLDev Traffic

2007-05-07T04:30:55Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 10]] - through May 4, 2007
* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 10

2007-05-07T04:29:51Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 10

sldev discussions through May 4, 2007

== Top Viewer Crashes ==
Dan Maronn (Linden) posted the ten most frequent Windows viewer crashes at [[Fixing bugs]], as well as the five most common Mac viewer crashes. Dan will attempt to keep these updated weekly. Each item includes a link to the relevant JIRA issue, where users and developers can discuss the crashes, as well as a dump of the call stack.

At present, the information is minimal, lacking a register dump or an indication of the type of crash, but these may be useful for visual code inspection or adding extra error checking code in local builds to identify unexpected behaviors.

Ben Byer also notes that the Mac crashes don't indicate whether the version in use is Intel or PowerPC and asks if Linden Lab are familiar with [http://smartcrashreports.com/ Smart Crash Reports], a tool for producing better crash reports on the Mac. Dan says that Aric Linden is looking at it.

== Working with Sculpted Prims ==
John Hurliman wrote a C# viewer for sculpted prims, posting the full source to SLDev. Windows and XNA Game Studio Express is required to run the viewer. John noted that lossy image compression of the sculpting texture added significant visual distortion to sculpted prims, and inquired whether lossless JPEG-2000 compression would be available. Ryan Williams (Linden) said he believed this was the plan, and that the sculpting texture delivery piggybacked on the existing texture delivery mechanism, enabling progressive models.

John Hurliman also created a program attempting to turn arbitrary meshes into sculpted prim textures, but met with limited success and solicited ideas for improvement. Andrew Meadows (Linden) notes that sculpted prims really only work with objects having the topology of a sphere, however he suggested one method whereby a mesh of springs could be wrapped about an arbitrary model, allowed to stabilize as springs with an additional constraint limiting them to the surface, and the vertices would then be quantized to the nearest pixel.

Erik Anderson inquired as to whether torus topology sculpted prims would help, allowing objects to be modeled with a single hole as well. Frans notes that Qarl Linden already promised this for the second revision on [[Talk:Sculpted_Prims]]. Actually, Qarl promises several more permutations!

== Sculpted Prims in Blender ==
Amanda Levitsky has begun working with sculpted prims in Blender, and posts [http://amandalevitsky.googlepages.com/sculptedprims this tutorial]. Of note, Blender is free, and [http://www.blender.org available for all Second Life platforms].

If you're new to Blender, Amanda suggests:<br />
http://www.blender.org/tutorials-help/quickstart/<br />
http://www.blender.org/tutorials-help/tutorials/tutorial-folder/blender-user-interface-tutorial/

Blender's interface is notoriously intimidating. Says Amanda:<br />
The UI isn't intuitive to learn, but it /is/ well used by its developers and very
efficient to work with.

Jessicatz Fairymeadow also suggests a Wiki book on Blender:<br />
http://en.wikibooks.org/wiki/Blender_3D:_Noob_to_Pro

== Python Using Spaces ==
Linden Lab have standardized on spaces four-space indentation, no tabs, for Python scripts. Paul Hampson ran into this detail, and Rob Lanphier (Linden) noted the change.

For the uninitiated, this isn't a bikeshed argument. Spacing is a non-trivial detail in Python. Python uses indentation to identify control blocks, as opposed to curly braces, "BEGIN" and "END" or the like. Mixing tabs and spaces with a non-standard tab size can create blocks that are visibly in the same block, but logically are not.

== Chat Logging Patch ==
Harold Brown posted [https://lists.secondlife.com/pipermail/sldev/2007-May/001701.html a patch] that allows logs to include not just times, but date stamps, as well as a few other features. A screenshot [http://www.rpgstats.com/SL/chatlog.jpg is available]. There were no responses, and there was no indication that a JIRA had been created.

== Chat History Patch ==
Zi Ree created support for chat line history, posting it to {{JIRA|VWR-671}}. There were no responses on-list or in the JIRA. If you'd like this one to go in, now's a good time to vote on the JIRA issue.

== Subversion Repository! ==
Big news! Rob Lanphier (Linden) posts:
Hi folks,

After way too much delay (sorry), I'm happy to announce that we now have
an official version control repository. Details are here:

https://wiki.secondlife.com/wiki/Version_control_repository

Note that the only thing that's in the source repository is the source
code. All of the supporting libraries, art, fonts, etc, still need to
be received via downloaded zipfile/tarball. In order to (hopefully)
ensure things start off on the right foot, I've created snapshots
corresponding to the latest checkins on the four current branches:

https://wiki.secondlife.com/wiki/Source_downloads#Betas_and_other_snapshots

Enjoy!

Of note, there are free [http://subversion.tigris.org/links.html#clients GUI and command-line Subversion tools] available on all Second Life platforms and for all major IDEs. For the uninitiated, the authoritative book on Subversion is [http://svnbook.red-bean.com/ available online] for free, or in hardcopy from major book sellers. The impatient can start [http://svnbook.red-bean.com/nightly/en/svn-book.html#svn.tour.initial here].

The first step to getting a submitter account is to submit a signed code contributor agreement to Linden Lab. Further details are on the [[Version control repository]] page.

User:Soft Noel

2007-05-01T16:15:13Z

Soft Noel:

Developer and editor of [[SLDev Traffic]]

User:Soft Noel

2007-05-01T16:14:47Z

Soft Noel:

Developer and editor of [[SLDev Traffic]]

Testing if the user notification stuff has been fixed

Talk:SLDev-Traffic 9

2007-04-30T21:31:54Z

Soft Noel:

SOFT, THESE SUMMARIES RAWK! Thanx for doing 'em. --[[User:Torley Linden|Torley Linden]] 12:53, 30 April 2007 (PDT)

virtual love machine++ <3 --[[User:Soft Noel|Soft Noel]] 14:31, 30 April 2007 (PDT)

SLDev-Traffic 9

2007-04-30T02:43:09Z

Soft Noel: /* Solaris Life */

{{SLDevTraffic}}

sldev-traffic no 9

sldev discussions through April 27, 2007

== Quiet Week ==
There weren't any hot issues on the list this week, and most visible efforts were focused on Rob Lanphier's (Linden) bug triage sessions. This made for low volume on the list this week.

== Third-Party Client Logins ==
Answering a request from John Hurliman, Ryan Williams (Linden) detailed a new parameter added to the login.cgi xml-rpc schema. "channel" may be an arbitrary string identifying a client. At present, specifying a new channel will allow a third-party client to log into a grid without its version number being checked. This will prevent artificially rejecting clients which may still be compatible with the grid.

== 1.15.0.2 is a Patchy Client ==
Rob Lanphier posted the 1.15.0.2 viewer, which will only work on the beta grid at present. For people compiling without libxul, Tofu Linden's patch was included with the announcement.

Of note, the fonts are now in the platform-specific library files in order to consolidate assets with like licenses.

== VS 2005 ==
The Lindens are not generally working with Visual Studio 2005 yet. James Cook (Linden) explains that one of the server libraries isn't available in 2005 format at present, and LL employees use the same environment for the server and viewer alike. Those who are having Visual Studio 2005 build issues can find help at {{JIRA|VWR-259}} until LL are ready to change over to 2005.

== Triage ==
The next bug triage is coming up Monday at 3pm SLT at {{SLurl|region=Grasmere|x=112|y=81|z=26|title=Rob's office in Grasmere}}. The notes for this triage are available at [[Bug_triage/2007-04-30|2007-04-30]]. Even if you aren't a seasoned developer, helping with the triage is a great way to get involved and learn more about the workings of Linden Lab and Second Life alike.

== Unit Test Harness - Patch 6 ==
New from Adroit this week, Gaurav Sharma posted the sixth unit testing patch. The message and patch can both be found [https://lists.secondlife.com/pipermail/sldev/2007-April/001660.html in the SLDev archive].

== Solaris Life ==
Dana Fagerstrom from Sun has continued work on porting Second Life to run under Solaris. The viewer now runs, and Dana even posted a snapshot. Curious? [https://lists.secondlife.com/pipermail/sldev/attachments/20070427/49d76705/secondlife-0001.png Have a peek]!

Rob Lanphier invited Dana to submit the patches required to make the viewer compile under Solaris with an eye toward including them in the main repository. Dana indicated that the changed fileset is minimal, which is a promising sign.

A heartfelt Welcome to the Family, Solaris. :)

SLDev Traffic

2007-04-30T02:39:05Z

Soft Noel:

{{SLDevTraffic}}

Periodic Summaries of [https://lists.secondlife.com/cgi-bin/mailman/listinfo/sldev SLDev mailing list] and [http://efnet.org EFNet] #opensl discussion

* [[SLDev-Traffic 9]] - through Apr 27, 2007
* [[SLDev-Traffic 8]] - through Apr 20, 2007
* [[SLDev-Traffic 7]] - through Apr 13, 2007
* [[SLDev-Traffic 6]] - through Apr 6, 2007
* [[SLDev-Traffic 5]] - through Mar 30, 2007 ([[SLDev-Traffic 5 (FR)|French]])
* [[SLDev-Traffic 4]] - through Mar 23, 2007
* [[SLDev-Traffic 3]] - through Mar 16, 2007
* [[SLDev-Traffic 2]] - through Mar 9, 2007
* [[SLDev-Traffic 1]] - through Mar 2, 2007
* (newest at the top)

Add this page to "my watchlist" to be reminded of updates.

SLDev-Traffic 9

2007-04-30T02:38:32Z

Soft Noel:

SLDev-Traffic 8

2007-04-23T03:11:41Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 8 - THE "OCHO"

sldev discussions through April 20, 2007

== Bug Triage ==
One of the more involved and difficult-to-summarize developments in the past week, Rob Lanphier (Linden) reports further favorable results from the in-world bug triages. Recent triages are available at [[Bug_triage/2007-04-16|2007-04-16]] and [[Bug_triage/2007-04-13|2007-04-13]], with the next triage scheduled for Monday. Rob has listed steps for advance participation at [[Bug_triage]].

A significant number of bugs have been tested, filtered, and imported, with the promise of many more if subsequent sessions go as well as the past two. Listmembers and Lindens alike have stepped in to help pound these out. Get involved if you can!

== Vectorizing ==
James Cook (Linden) did some profiling with [http://developer.apple.com/tools/sharkoptimize.html Shark] and found hot spots in a vector matrix transform, vector matrix rotation, and LLViewerJointMesh::updateGeometry(). He posted some patches that cut up to 1ms off of each frame on an unspecified Mac, asking for advice from people with SSE experience and postulating that these, as well as the matrix lerp(), could be further enhanced by vectorization. Callum Lerwick suggested enabling automatic vectorization, which lead to a discussion about how many platforms were still supported without streaming SIMD extensions -- the 1GHz Athlon Thunderbird falling within stated minimal requirements seems to be the proverbial fly in the ointment for SSE-only builds. James indicated that he'd research whether many of these were in use in order to make a decision about enabling SSE globally. There wasn't any answer on this yet, but Dzonatas Sol and James continued conversation along with some experiments showing potential further speedup.

Argent Stonecutter asked why automatic vectorization would be turned off on the Mac and didn't get an answer. Presumably all supported Macs have AltiVec instructions.

== Unused Packets ==
John Hurliman posted [https://lists.secondlife.com/pipermail/sldev/2007-April/001598.html a list of 117 message packets] that the viewer doesn't need to be aware of, suggesting that these might be used by back-end services exclusively. These may be of use to anyone writing his or her own client.

== Source Drops Going Smoothly ==
Recent source drops have built much more smoothly on multiple platforms. If anyone has been hesitant to jump in for fear of time spent working past build issues, now is a fantastic time!

== OpenSL for Solaris on Intel... SPARC - Almost ==
Dana Fagerstrom (Sun Microsystems) announced work on a Solaris build for x86/x64 and SPARC. Things seemed quite near working, save problems with Dana's graphics card not supporting a 32-bit framebuffer for testing the SPARC build. David Fries offered up a patch that should help with other bit depths, but there wasn't any reply yet. Once working, Dana hopes to spend some time profiling Solaris performance in DTrace.

== Protocol Changelog ==
John Hurliman noted some changes in the message protocol, of interest to anyone writing his or her own client. John noted that most seemed to increase precision on existing variables, and Joshua Bell (Linden) explained the remainder.

== Good-Bye, Jesse ==
Jesse Malthus passed away this past Thursday. Jesse, also known by Jesse Nesbitt (on-list) and Jesse Higginbotham (meatspace) will be missed. Jesse was memorialized in-world, on-list, in most SL-related IRC channel topic lines, and even on multiple Second Life blogs and Twitter-blogs. Jason Giglio broke the sad news on-list, and Rob Lanphier linked to [http://www.secondlifeinsider.com/2007/04/20/in-memory-of-jesse-malthus/ an article] on Second Life Insider. Jesse was 17.

Several people have passed around a snapshot of Jesse in-world, wearing a rocket pack at 102km above a sim, far above us all and still climbing fast.

SLDev Traffic

2007-04-23T03:11:02Z

Soft Noel:

SLDev-Traffic 8

2007-04-23T03:10:30Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 8

sldev discussions through April 20, 2007

== Bug Triage ==
One of the more involved and difficult-to-summarize developments in the past week, Rob Lanphier (Linden) reports further favorable results from the in-world bug triages. Recent triages are available at [[Bug_triage/2007-04-16|2007-04-16]] and [[Bug_triage/2007-04-13|2007-04-13]], with the next triage scheduled for Monday. Rob has listed steps for advance participation at [[Bug_triage]].

A significant number of bugs have been tested, filtered, and imported, with the promise of many more if subsequent sessions go as well as the past two. Listmembers and Lindens alike have stepped in to help pound these out. Get involved if you can!

== Vectorizing ==
James Cook (Linden) did some profiling with [http://developer.apple.com/tools/sharkoptimize.html Shark] and found hot spots in a vector matrix transform, vector matrix rotation, and LLViewerJointMesh::updateGeometry(). He posted some patches that cut up to 1ms off of each frame on an unspecified Mac, asking for advice from people with SSE experience and postulating that these, as well as the matrix lerp(), could be further enhanced by vectorization. Callum Lerwick suggested enabling automatic vectorization, which lead to a discussion about how many platforms were still supported without streaming SIMD extensions -- the 1GHz Athlon Thunderbird falling within stated minimal requirements seems to be the proverbial fly in the ointment for SSE-only builds. James indicated that he'd research whether many of these were in use in order to make a decision about enabling SSE globally. There wasn't any answer on this yet, but Dzonatas Sol and James continued conversation along with some experiments showing potential further speedup.

Argent Stonecutter asked why automatic vectorization would be turned off on the Mac and didn't get an answer. Presumably all supported Macs have AltiVec instructions.

== Unused Packets ==
John Hurliman posted [https://lists.secondlife.com/pipermail/sldev/2007-April/001598.html a list of 117 message packets] that the viewer doesn't need to be aware of, suggesting that these might be used by back-end services exclusively. These may be of use to anyone writing his or her own client.

== Source Drops Going Smoothly ==
Recent source drops have built much more smoothly on multiple platforms. If anyone has been hesitant to jump in for fear of time spent working past build issues, now is a fantastic time!

== OpenSL for Solaris on Intel... SPARC - Almost ==
Dana Fagerstrom (Sun Microsystems) announced work on a Solaris build for x86/x64 and SPARC. Things seemed quite near working, save problems with Dana's graphics card not supporting a 32-bit framebuffer for testing the SPARC build. David Fries offered up a patch that should help with other bit depths, but there wasn't any reply yet. Once working, Dana hopes to spend some time profiling Solaris performance in DTrace.

== Protocol Changelog ==
John Hurliman noted some changes in the message protocol, of interest to anyone writing his or her own client. John noted that most seemed to increase precision on existing variables, and Joshua Bell (Linden) explained the remainder.

== Good-Bye, Jesse ==
Jesse Malthus passed away this past Thursday. Jesse, also known by Jesse Nesbitt (on-list) and Jesse Higginbotham (meatspace) will be missed. Jesse was memorialized in-world, on-list, in most SL-related IRC channel topic lines, and even on multiple Second Life blogs and Twitter-blogs. Jason Giglio broke the sad news on-list, and Rob Lanphier linked to [http://www.secondlifeinsider.com/2007/04/20/in-memory-of-jesse-malthus/ an article] on Second Life Insider. Jesse was 17.

Several people have passed around a snapshot of Jesse in-world, wearing a rocket pack at 102km above a sim, far above us all and still climbing fast.

SLDev-Traffic 7

2007-04-16T21:52:18Z

Soft Noel: /* SL Competitors' Best Features */

{{SLDevTraffic}}

sldev-traffic no 7

sldev discussions through April 13, 2007

== Documenting the Second Life Protocol ==
Dzonatas Sol inquired about documentation for the Second Life protocol. Rob Lanphier (Linden) pointed to [[Protocol]], noting that the protocol was still in flux. Jesse Nesbitt reminds users about Lib SecondLife, as well as the message template, which includes some useful comments.

== More OpenJPEG Progress ==
Dzonatas Sol continues optimizing OpenJPEG. This week, Dzonatas published a patch facilitating vectorization throughout dwt.c. The details of some of this are non-trivial, but the upshot: "Actual speed-up will vary overall, but it ranges from 2x to 20x in just DWT time." There is some more detailed discussion on the list about how different compilers handle automatic vectorization, as well as floating point versus fixed point performance in this context.

== Garbage Collection ==
A discussion about destroying textures lead to the question of whether unreferenced textures were ever recycled. James Cook (Linden) confirmed that there is garbage collection, but that it's very slow:

There is garbage collection, but as you noted it is very slow.
Basically we scan the entire world dataset, including inventory items,
region state files (textures on objects, textures as inventory items
inside objects) and assets (notecards and script text). Anything that
looks like a texture UUID is added to a list, then textures (well, all
assets really) that aren't on the list are deleted.

So if you have a raw key reference to a texture inside a script the
texture will not be garbage collected. If it is, then our garbage
collector is broken. (It has broken in the past. We don't immediately
delete the garbage -- we keep it around for a few days just in case we
screwed something up so we can put it back.)

And the gotcha:<br />
If you do something silly like this, though, the texture will be garbage
collected:

key texture_id = (key)("12345678-abcd-abcd-" + "abcd-123456789012");

== UUID Generation ==
The garbage collection discussion opened the question of whether UUIDs could be reused, and how they were generated. John Hurliman points to lluuid.cpp, where the current time and seed are MD5ed (verbing nouns weirds language -- Calvin) to generate the UUID. The time component lowers the chance of UUID reuse within our lifetimes. James Cook points out that the seed is the ethernet MAC address.

== Plugin Licensing ==
Discussion continued about plugin licensing. To rehash previous discussions, the big question is whether Linden Lab will cooperate with developers who wish to create closed source extensions to the viewer. There has been discussion of what obligations exist for code used by, but not directly linked against, GPL code. There has also been discussion about architecting plugins in ways to work around any imposed licensing, or subverting the viewer altogether by operating directly on the network stream.

The number of people pushing these discussions is small but not trivial, and it remains a contentious topic with widespread discussion every time it's revisited. There is no plugin system in the short term, and Rob Lanphier encourages developers to focus on the architecture and implementation of a plugin system in advance of LL being able to answer the question.

== Unit Test Harnes - Patch 5 ==
Gaurav Sharma from Adroit posted the fifth unit testing patch.

1.Unit Tests:
Completed: llinventory, llpermission, llsaleinfo, v3color, v4color,
v4coloru
In progress: llevent.h
2.Fixed llinventory.cpp and llsaleinfo.cpp:
i) Added a ref to fix a crasher bug
ii) Fixed incosistance in exportFileXML and importXML in how "flags" get
storted
iii) Fixed inconsistancy in exportFileXML for some properties that did not
get exported correctly(uuid, parent_uuid, type, price, creation date)

Next up:
Unit Tests for the following:
i) llcommon - llevent
ii) llmath - lltreenode, llocttree
iii) Determine classes that uses LLSD serialization/deserialization and
write unit tests for the same
iv) Start spending more time in SL using debug build to repro potential
crashes and apply fixes.

(As is the usual case, there was no on-list follow-up to the unit test harness patch. If anyone is running these tests, it could be useful to document the process so that other sldev members can contribute or confirm the tests. -- Soft)

== SL Competitors' Best Features ==
Plugin licensing discussions kicked off a discussion about what other virtual worlds are close to Second Life. Callum Lerwick provided an initial list, and John Hurliman and Tim Shephard narrowed the ones with user-created content to:<br />
Croquet http://www.croquetconsortium.org/index.php/Main_Page
OSMP http://metaverse.sourceforge.net/
There http://www.there.com/
Active Worlds http://www.activeworlds.com/
HiPiHi http://www.youtube.com/results?search_query=HiPiHi

Thomas Rowland believes that Entropia is moving toward participant content as well.

John Hurliman asked what the best features of each competitor are, and whether SL is lacking in any of them. He began by noting that OSMP has an offline sandbox, as well as a portal system. He took the occasion to suggest that this could be approximated with some clever building and allowing LSL scripts to teleport users between sims.

Farallon likes that in There, inventory placed in the world can be recalled from afar and a placeholder exists in inventory for this action. In There, inventory can also be marked as transitory, allowing users to demo objects for a period of time before the inventory vanishes. Farallon also notes that he believes There's vehicle physics are better than SLs, even if There is lacking in a great number of other ways he listed. Lastly, Farallon notes that There bump shields are 100% effective.

Callum Lerwick observed that on There, it's possible to travel over miles of seamless terrain without SL's sim-crossing glitchiness. Several list members mentioned the overall interface on There as being smoother than SL's, despite some odd Internet Explorer dependencies.

== Ben Glenn (Linden) User Experience Office Hours ==
Ben Glenn notes that Tuesdays and Thursdays, he's holding office hours to talk about UI design, usability, upcoming features, the sky's the limit.

When: Tuesdays and Thursdays, 10:00-11:00 AM<br />
Where: [[http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village Benjamin Linden's office]]

== Inventory System Patch ==
Jason Giglio uploaded a substantial bit of work on the inventory system, attached to {{JIRA|VWR-326}}:<br />
This patch:

1. Implements VWR-326 by adding a "5 items in 10 seconds" throttle.
Throttled items are still accepted, just not displayed.
This prevents the DoS attack described in VWR-326.

2. Adds a debug menu toggle to disable auto-opening of new inventory
completely. This menu option persists between sessions.

3. Refactors the way new inventory items are opened/highlighted to
remove the old hacky way.

4. Fixes a leaking observer in the inventory system related to 3

5. Fixes a rare crash by removing a null pointer dereference.

Jason has been adored by Lindens and external contributors alike. :)

== Cameras in Non-Adjacent Sims ==
John Hurliman inquired as to whether it was possible to place cameras in non-adjacent sims. He noted that the "child camera" can leapfrog across sims by peering from one sim into another, but wondered if it were possible to move the camera to an arbitrary sim without regard for nearness or continental connectivity. There was no discussion past John's question and a subsequent clarification of the question.

== Japanese Input ==
Matsuu Takuto inquired about using Japanese symbols in chat under Linux. To this end, Alissa Sabre has released [[http://secondlife-wiki.main.jp/modules/pukiwiki/index.php?plugin=attach&pcmd=info&file=SDL-patch.zip&refer=%5B%5B%C6%FC%CB%DC%B8%EC%A5%C1%A5%E3%A5%C3%A5%C8%5D%5D a patch]] against SDL. Tofu Linden hopes to bundle the matching SDL version with the viewer by default if Alissa's patch is accepted by the SDL project.

== Teleportation Disconnections ==
John Hurliman has been investigating disconnections when teleporting. He notes that, using some bot code, he found that the client receives TeleportStart, TeleportProgress, TeleportProgress, and the connection to the current simulator times out before the teleportation completes. He wonders if this could be handled more gracefully, if the current simulator is always assuming a successful teleport from TeleportStart onward.

== Liana Holmberg Introduces Herself On-List ==
Liana introduced herself on sldev, noting that her first order of business is to clear out the backlog in the licensing mailbox and to address current questions in the wiki and JIRA. Liana appreciates patience while catching up. For new questions:<br />
please use the following protocol:
-Announce an issue or ask a question in SLDev
-Take conversations to the wiki (noting the link in SLDev)
-Make jira requests for actionable items and post constructive comments and design recommendations there.

You can also:
-Email specific or private requests for license info to licensing@lindenlab.com
-Contact me directly at liana@lindenlab.com.

Currently, I hold office hours on Tuesdays and Thursdays from 8:30-9:30 am PDT. Feel free to stop by:
Liana Linden Living Room in Ambleside (132, 14, 29) http://slurl.com/secondlife/Ambleside/132/14/29/

And:<br />
You all have my thanks and admiration for the work you've done on OpenSL

Liana was openly welcomed by the list.

== Friday Bug Triage ==
Rob Lanphier (Linden) used his Friday office hours to triage bugs. There was discussion in advance about how to identify the most important bugs, how to differentiate between bugs and feature requests, and whether Linden-created and resident support issues would ever be pushed to the public JIRA. Rob indicated that Linden-created bugs may be pushed to the public JIRA, but that it was too soon to look at floods of in-world support issues.

(Unfortunately I couldn't schedule time for this Friday's office hours so I couldn't make it. I'll endeavor to get a log and read some of the follow-up on-list this week so next week I can tell you how it went. In the mean-time, Rob indicates that it went exceptionally well, and has even scheduled another for Monday at 3! -- Soft)

Discussion continues on-list about how to make these triage sessions even more useful, as does discussion about specific bugs and bug categories that should be sooner addressed.

SLDev Traffic

2007-04-16T05:15:51Z

Soft Noel:

SLDev-Traffic 7

2007-04-16T05:15:23Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 7

sldev discussions through April 13, 2007

== Documenting the Second Life Protocol ==
Dzonatas Sol inquired about documentation for the Second Life protocol. Rob Lanphier (Linden) pointed to [[Protocol]], noting that the protocol was still in flux. Jesse Nesbitt reminds users about Lib SecondLife, as well as the message template, which includes some useful comments.

== More OpenJPEG Progress ==
Dzonatas Sol continues optimizing OpenJPEG. This week, Dzonatas published a patch facilitating vectorization throughout dwt.c. The details of some of this are non-trivial, but the upshot: "Actual speed-up will vary overall, but it ranges from 2x to 20x in just DWT time." There is some more detailed discussion on the list about how different compilers handle automatic vectorization, as well as floating point versus fixed point performance in this context.

== Garbage Collection ==
A discussion about destroying textures lead to the question of whether unreferenced textures were ever recycled. James Cook (Linden) confirmed that there is garbage collection, but that it's very slow:

There is garbage collection, but as you noted it is very slow.
Basically we scan the entire world dataset, including inventory items,
region state files (textures on objects, textures as inventory items
inside objects) and assets (notecards and script text). Anything that
looks like a texture UUID is added to a list, then textures (well, all
assets really) that aren't on the list are deleted.

So if you have a raw key reference to a texture inside a script the
texture will not be garbage collected. If it is, then our garbage
collector is broken. (It has broken in the past. We don't immediately
delete the garbage -- we keep it around for a few days just in case we
screwed something up so we can put it back.)

And the gotcha:<br />
If you do something silly like this, though, the texture will be garbage
collected:

key texture_id = (key)("12345678-abcd-abcd-" + "abcd-123456789012");

== UUID Generation ==
The garbage collection discussion opened the question of whether UUIDs could be reused, and how they were generated. John Hurliman points to lluuid.cpp, where the current time and seed are MD5ed (verbing nouns weirds language -- Calvin) to generate the UUID. The time component of this prevents UUID reuse within our lifetimes. James Cook points out that the seed is the ethernet MAC address.

== Plugin Licensing ==
Discussion continued about plugin licensing. To rehash previous discussions, the big question is whether Linden Lab will cooperate with developers who wish to create closed source extensions to the viewer. There has been discussion of what obligations exist for code used by, but not directly linked against, GPL code. There has also been discussion about architecting plugins in ways to work around any imposed licensing, or subverting the viewer altogether by operating directly on the network stream.

The number of people pushing these discussions is small but not trivial, and it remains a contentious topic with widespread discussion every time it's revisited. There is no plugin system in the short term, and Rob Lanphier encourages developers to focus on the architecture and implementation of a plugin system in advance of LL being able to answer the question.

== Unit Test Harnes - Patch 5 ==
Gaurav Sharma from Adroit posted the fifth unit testing patch.

1.Unit Tests:
Completed: llinventory, llpermission, llsaleinfo, v3color, v4color,
v4coloru
In progress: llevent.h
2.Fixed llinventory.cpp and llsaleinfo.cpp:
i) Added a ref to fix a crasher bug
ii) Fixed incosistance in exportFileXML and importXML in how "flags" get
storted
iii) Fixed inconsistancy in exportFileXML for some properties that did not
get exported correctly(uuid, parent_uuid, type, price, creation date)

Next up:
Unit Tests for the following:
i) llcommon - llevent
ii) llmath - lltreenode, llocttree
iii) Determine classes that uses LLSD serialization/deserialization and
write unit tests for the same
iv) Start spending more time in SL using debug build to repro potential
crashes and apply fixes.

(As is the usual case, there was no on-list follow-up to the unit test harness patch. If anyone is running these tests, it could be useful to document the process so that other sldev members can contribute or confirm the tests. -- Soft)

== SL Competitors' Best Features ==
Plugin licensing discussions kicked off a discussion about what other virtual worlds are close to Second Life. Callum Lerwick provided an initial list, and John Hurliman and Tim Shephard narrowed the ones with user-created content to:<br />
Croquet http://www.croquetconsortium.org/index.php/Main_Page
OSMP http://metaverse.sourceforge.net/
There http://www.there.com/
Active Worlds http://www.activeworlds.com/
HiPiHi http://www.youtube.com/results?search_query=HiPiHi

Thomas Rowland believes that Entropia is moving toward participant content as well.

John Hurliman asked what the best features of each competitor are, and whether SL is lacking in any of them. He began by noting that OSMP has an offline sandbox, as well as a portal system. He took the occasion to suggest that this could be approximated with some clever building and allowing LSL scripts to teleport users between sims. Farallon likes that in There, inventory placed in the world can be recalled from afar and a placeholder exists in inventory for this action. In There, inventory can also be marked as transitory, allowing users to demo objects for a period of time before the inventory vanishes. Farallon also notes that he believes There's vehicle physics are better than SLs even There is lacking in a great number of other ways he listed, and that There bump shields are 100% effective. Callum Lerwick observed that on There, it's possible to travel over miles of seamless terrain without SL's sim-crossing glitchiness. Several list members mentioned the overall interface on There as being smoother than SL's, despite some odd Internet Explorer dependencies.

== Ben Glenn (Linden) User Experience Office Hours ==
Ben Glenn notes that Tuesdays and Thursdays, he's holding office hours to talk about UI design, usability, upcoming features, the sky's the limit.

When: Tuesdays and Thursdays, 10:00-11:00 AM<br />
Where: [[http://slurl.com/secondlife/Beaumont/148/155/46/?title=Linden%20Village Benjamin Linden's office]]

== Inventory System Patch ==
Jason Giglio uploaded a substantial bit of work on the inventory system, attached to {{JIRA|VWR-326}}:<br />
This patch:

1. Implements VWR-326 by adding a "5 items in 10 seconds" throttle.
Throttled items are still accepted, just not displayed.
This prevents the DoS attack described in VWR-326.

2. Adds a debug menu toggle to disable auto-opening of new inventory
completely. This menu option persists between sessions.

3. Refactors the way new inventory items are opened/highlighted to
remove the old hacky way.

4. Fixes a leaking observer in the inventory system related to 3

5. Fixes a rare crash by removing a null pointer dereference.

Jason has been adored by Lindens and external contributors alike. :)

== Cameras in Non-Adjacent Sims ==
John Hurliman inquired as to whether it was possible to place cameras in non-adjacent sims. He noted that the "child camera" can leapfrog across sims by peering from one sim into another, but wondered if it were possible to move the camera to an arbitrary sim without regard for nearness or continental connectivity. There was no discussion past John's question and a subsequent clarification of the question.

== Japanese Input ==
Matsuu Takuto inquired about using Japanese symbols in chat under Linux. To this end, Alissa Sabre has released [[http://secondlife-wiki.main.jp/modules/pukiwiki/index.php?plugin=attach&pcmd=info&file=SDL-patch.zip&refer=%5B%5B%C6%FC%CB%DC%B8%EC%A5%C1%A5%E3%A5%C3%A5%C8%5D%5D a patch]] against SDL. Tofu Linden hopes to bundle the matching SDL version with the viewer by default if Alissa's patch is accepted by the SDL project.

== Teleportation Disconnections ==
John Hurliman has been investigating disconnections when teleporting. He notes that, using some bot code, he found that the client receives TeleportStart, TeleportProgress, TeleportProgress, and the connection to the current simulator times out before the teleportation completes. He wonders if this could be handled more gracefully, if the current simulator is always assuming a successful teleport from TeleportStart onward.

== Liana Holmberg Introduces Herself On-List ==
Liana introduced herself on sldev, noting that her first order of business is to clear out the backlog in the licensing mailbox and to address current questions in the wiki and JIRA. Liana appreciates patience while catching up. For new questions:<br />
please use the following protocol:
-Announce an issue or ask a question in SLDev
-Take conversations to the wiki (noting the link in SLDev)
-Make jira requests for actionable items and post constructive comments and design recommendations there.

You can also:
-Email specific or private requests for license info to licensing@lindenlab.com
-Contact me directly at liana@lindenlab.com.

Currently, I hold office hours on Tuesdays and Thursdays from 8:30-9:30 am PDT. Feel free to stop by:
Liana Linden Living Room in Ambleside (132, 14, 29) http://slurl.com/secondlife/Ambleside/132/14/29/

And:<br />
You all have my thanks and admiration for the work you've done on OpenSL

Liana was openly welcomed by the list.

== Friday Bug Triage ==
Rob Lanphier (Linden) used his Friday office hours to triage bugs. There was discussion in advance about how to identify the most important bugs, how to differentiate between bugs and feature requests, and whether Linden-created and resident support issues would ever be pushed to the public JIRA. Rob indicated that Linden-created bugs may be pushed to the public JIRA, but that it was too soon to look at floods of in-world support issues.

(Unfortunately I couldn't schedule time for this Friday's office hours so I couldn't make it. I'll endeavor to get a log and read some of the follow-up on-list this week so next week I can tell you how it went. In the mean-time, Rob indicates that it went exceptionally well, and has even scheduled another for Monday at 3! -- Soft)

Discussion continues on-list about how to make these triage sessions even more useful, as does discussion about specific bugs and bug categories that should be sooner addressed.

Talk:Plugin architecture

2007-04-10T20:23:25Z

Soft Noel: /* Security Concerns */

{{Open Source Talk Page}}

Glad to see a conversation blooming here. Any chance we can see a little consolidation of these pages, though? Looks like we're sprawling out quite a bit. -- [[User:Rob Linden|Rob Linden]] 20:01, 12 February 2007 (PST)

== semantics ==

This should probably be moved to [[Project:Plugin architecture]]
<br />[[User:SignpostMarv Martin|SignpostMarv Martin]] 13:17, 14 February 2007 (PST)
:No, Project: is used for official metainformation about the open source project from linden lab. Things like policy statements and such. This namespace is fine. [[User:Gigs Taggart|Gigs Taggart]] 13:30, 14 February 2007 (PST)
::Is that LL policy, or a practice borrowed from the Wikipedia ?
::[[User:SignpostMarv Martin|SignpostMarv Martin]] 13:35, 14 February 2007 (PST)
:::Yes, it is LL's policy. The bug in Jira to use multiple namespaces was shot down and closed WONTFIX. Fragmenting the namespace has negative effects on searching and no real benefit. Namespaces should be used for pages that are fundamentally different in some way, not as a way to partition articles. Please don't use the Project: namespace for articles. Just create the article and then tag it with categories it fits in. People can bring up the category page to look through pages in that category. [[User:Gigs Taggart|Gigs Taggart]] 13:45, 14 February 2007 (PST)
::::{{JIRA|WEB-22}} was Rob shooting down Strife's request to have "LSL" added as a custom namespace, '''not''' Rob shooting down any and all uses of built-in namespaces.
::::If this article is intended to be a hub for the standardisation and development of plugins & plugin architecture, then it should be moved to [[Project:Plugin architecture]], as it would be a "project" within the SL Wiki, as opposed to an article which describes the plugin architecture once it's defined.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 14:35, 14 February 2007 (PST)
::::P.S. This wouldn't go under "This wiki should function as one wiki, rather than as a bunch of tiny wikis that happen to share the same domain name.", as it is purely for organisational purposes, whereas Strife seems to want to segregate the wiki.
::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 14:40, 14 February 2007 (PST)

Actually, "Project:" should be reserved for meta information about this wiki itself. On most MediaWiki installs, the "Project:" namespace is equal to the name of the wiki itself, but I unset that option, thus "Project:" is the sole way of getting to that namespace. The things that go into the "Project:" namespace should be limited to those things that are about editing policy, etc. -- [[User:Rob Linden|Rob Linden]] 14:47, 14 February 2007 (PST)
:Ah. So is [[User talk:SignpostMarv Martin/Sandbox/Project:Internationalisation|Project:Internationalisation]] a good use of the namespace or not ?
:[[User:SignpostMarv Martin|SignpostMarv Martin]] 15:16, 14 February 2007 (PST)
::Looks good to me. [[User:Gigs Taggart|Gigs Taggart]] 15:56, 14 February 2007 (PST)

== plugin creation complexity ==

#How complex are plugins going to be to create ?
#Could plugins be written in notepad, or would they have to be developed in an IDE then compiled ?
#If a plain-text scripting language were to be used, what languages would be advocated for use ? Javascript <small>(yay greasemonkey!)</small> ? Perl ? Ruby ? Python ? All of the above ?

[[User:SignpostMarv Martin|SignpostMarv Martin]] 19:34, 14 February 2007 (PST)

:We're not even close to this point in development or planning. I'm pretty sure higher level scripting languages will make it into client plugins eventually.
:--- [[User:Baba Yamamoto|Baba Yamamoto]] 19:10, 16 February 2007 (PST)
== parameter passing ==
I don't like the idea of anonymous pointers for parameter passing. I think that some kind of parameter list is essential.
<pre>
typedef struct {
int sl_param_id; // Defined in the particular function's API
enum {
SL_INT32, SL_INT64, SL_FLOAT32, SL_FLOAT64, SL_STRING, SL_ALLOCED_STRING, ...
} sl_type; // Plugin may ignore parameters
int sl_required; // If set, plugin MUST handle this parameter
int sl_changed; // Zero before any plugin called, non-zero if any plugin has changed it
int64_t sl_value; // If the type is only 32 bits long, high 32 bits must be zero.
} sl_param;
typedef enum { SL_OK, SL_INCOMPATIBLE, SL_ERROR, SL_BREAK } sl_result;

sl_result sl_plugin(int count, sl_param params[], sl_param *error_info);
</pre>
The function calling the plugin can have all these set in a static structure, and only needs to zero out the sl_changed parameters and set up the initial values. Plugins do not call plugins, the list of plugins for the function are called sequentially by the sl_handle_plugins routine.
<pre>
if(my_plugins != NULL) {
my_params[0].sl_changed = 0;
my_params[0].sl_value = whatever;
final_result = sl_handle_plugins(my_plugins, 1, my_params, &error_param);
if(final_result == SL_BREAK) return success;
if(final_result == SL_ERROR) {
panic(error_param);
return failure;
}
}
</pre>

The plugin must at a minimum:

* verify that the sl_param_id values are what it expects and handle (even if by ignoring) the wrong values
* handle (even if by ignoring the parameter) the "wrong" types
* return SL_INCOMPATIBLE if any of the parameters it's ignoring have sl_required set.
* set sl_changed for any parameters it's changed
* fill in error_info if it returns SL_ERROR
* free an SL_ALLOCED_STRING if it changes the string
** make sure that the type of the new string parameter is SL_ALLOCED_STRING or SL_STRING to let the caller or later plugins know how to deal with them

The plugin may:

* Handle changes to the order of parameters as indicated by sl_param_id
* Handle changes to the types of parameters as indicated by sl_type
* Behave differently if a previous plugin has changed a parameter

Return values:

* SL_OK - Normal return, go on to the next plugin
* SL_INCOMPATIBLE - This plugin no longer works with this call. Let the user know and don't call this plugin again.
* SL_ERROR - This plugin has detected an error sufficiently severe that this call must abort. Should be rare.
** error_info must be set to { original_param_id, SL_STRING or SL_ALLOCED_STRING, TRUE, TRUE, error_message }.
* SL_BREAK - Don't call any further plugins, don't run the rest of the function, the plugin has completely handled the call.

-- [[User:Argent Stonecutter|Argent Stonecutter]] 06:48, 22 February 2007 (PST)

== content from Implementing new features ==

=== Embedded scripting language for client-side plugins ===
[[User:Heather Goodliffe|Heather Goodliffe]], [[User:Yumi Murakami|Yumi Murakami]], [[User:Argent Stonecutter|Argent Stonecutter]]

* Make the client more powerful and plugable
* Embed a scripting language, such as Javascript or Tcl or LUA or Python, within Second Life to enable client plug-ins to be written in a modular fashion. Client plugins would be distributed via Second Life itself; hopefully LL would eventually agree to create a new object type for these, but for testing purposes notecards would probably suffice.
* Let me second that: I'd like to see client-side scripting as well. It should be easy to add that (in particular, using Lua), and it would let users fix so many usability problems. At a minimum, the scripting language should be able to access the functionality available through the menus, it should permit key bindings and grab keys, access preference settings, and it should be able to listen to chat and IM, so that commands can be triggered from there. [[User:Jherek Cerminara|Jherek Cerminara]]

:One way of doing this would be to exploit the xpcom architecture of Mozilla. Exposing the viewer core as xpcom interfaces. That way the flexibility and extensibility of the Mozilla engine could be used.
:The viewer already includes the mozilla engine, using xpcom it will be possible to use Javascript, Java, C++ (Mono/.Net is under way).
:This would require that a definition of an interface layer between the core viewer and the xpcom system inside Mozilla, once that was defined and implemented, the viewer functionality could be extened using almost any language.
:[[User:Duffy Langdon|Duffy Langdon]] 12:34, 10 January 2007

* Something to note: the above plugin architecture would make automatic glue code for scripting languages easy to write. [[User:Argent Stonecutter|Argent Stonecutter]] 06:56, 22 February 2007 (PST)

[[Category:Future Roundtables]]

== Automated Agents ==

Just curious, how does "Automated Agents" become a plugin ?

Or are you referring to "headless agents" in the context of having all IMs for a Resident's alts routed through into one instance of SL ?

[[User:SignpostMarv Martin|SignpostMarv Martin]] 22:15, 23 February 2007 (PST)

== Security Concerns ==

I believe the hardest part of the plug-in system will be to overcome to security concerns. How many trust being able to download and plug-in arbitrary code that might set off a money event. I've heard the casual user of SL not want to deal with such concerns. For that reason, I believe a scripting language is the way to go. We can limit the availability of the API to the scripts. This can be the default to allow arbitrary code in the form of scripts. [[User:Dzonatas Sol|Dzonatas Sol]] 01:54, 7 April 2007 (PDT)
: Unless a plugin disables the big-ass blue box notice that says "You just have Resident X L$10k", I think that it'll be difficult to wholesale rip people off.
: The suggested method for getting around the security concerns thing would be to have something like https://plugins.secondlife.com whereby each plugin listed on the site has been given the all-clear by Linden Lab as "not ripping people off".
: The API cannot be limited, as it'll be just a case of modifying the source code.
: [[User:SignpostMarv Martin|SignpostMarv Martin]] 04:56, 7 April 2007 (PDT)
::I'm pretty sure that a review system as you suggested above won't scale. [[User:Dzonatas Sol|Dzonatas Sol]] 11:29, 8 April 2007 (PDT)
::: Of course it won't. It's more reliable than limiting the API though.
::: [[User:SignpostMarv Martin|SignpostMarv Martin]] 02:53, 9 April 2007 (PDT)
::::It would be easier to allow an option to limit access to the API by default. Let the user decide to over-ride that. Also, there could be certification key like web browser do now. It wasn't the intent to make it impossible for even certifiable plug-ins to gain greater access. [[User:Dzonatas Sol|Dzonatas Sol]] 13:49, 9 April 2007 (PDT)
:::::L$ handling should go through the same permissions system an LSL-initiated call goes through.
:::::''''Plugin Foo created by Bar requests permission to debit your account''''
:::::A web-based interface along the lines of flickr should be a usable means of managing permissions.
:::::[[User:SignpostMarv Martin|SignpostMarv Martin]] 16:45, 9 April 2007 (PDT)
: Some of this discussion happened a couple months back during Rob's office hours. Really, if the plugins are dynamically loadable libraries, you can't do much for security. Even if you don't expose something in the API, it's still accessible so long as the plugin has access to the memory space. What would make a lot of sense is creating scripting engines as plugins. If a scripting system proves to be secure, we might be able to eventually convince Linden Lab to ship the scripting system themselves.
: Creating a scripting system plugin should be pretty straightforward once the plugin system exists, so long as the scripting language has a nearly a one-to-one mapping of script functions to plugin API functions. --[[User:Soft Noel|Soft Noel]] 13:23, 10 April 2007 (PDT)

SLDev-Traffic 6

2007-04-09T02:52:10Z

Soft Noel: Extra brackets

{{SLDevTraffic}}

sldev-traffic no 6

sldev discussions through April 6, 2007

== Build Benchmarks ==
Dale Glass benchmarked builds under Gentoo and Ubuntu (Edgy) Linux. He found that it took about 4GB of RAM to cache the full build so that drive speeds became unimportant. Gentoo had a 15% edge over Ubuntu for compilation speeds, possibly owing to a platform-optimized compiler, however scons ran only half as quickly under Gentoo. The reason for scons' slower build under Gentoo was not explored, although Dale suggested it could be a good area for investigation if there are any python hackers about.

James Cook (Linden) produced an internal email he had written about the benefit of a faster build drive, which was previously quoted by Kelly Linden in [https://wiki.secondlife.com/wiki/SLDev-Traffic_3#Faster_Viewer_Builds SLDev-Traffic #3].

== Unit Tests for the Message System ==
Gaurav Sharma from Adroit inquired about the best way to write unit test cases for the message system without actually connecting to a server. Peekay Semyorka suggested that making a small test server or refactoring real server services into test services was about the only way. There was no follow-up.

== OpenJPEG Optimization ==
Callum Lerwick and Dzonatas Sol continued with OpenJPEG optimizations. Of note, Callum prepared a set of benchmarks and found that he's nearing half the speed of KDU with his changes alone, and Dzonatas noted that the decoder is set up so that each stride could have its own thread, although it's not currently set up this way. John Hurliman also pointed out some low hanging fruit:<br />
the LayerData (terrain patch) decoder
reinitializes several data tables for every patch it decodes (256 per
sim). It does this because the original decoder was designed to work
with arbitrary sized patches, but the grid only used 16x16 and 32x32
patches, and now it only uses the full resolution 16x16 patches.

François-Olivier Devaux of the OpenJPEG group confirmed that he had tested some of the patches provided by Callum and Dzonatas and indicated that the code would likely be integrated in the next OpenJPG version.

== PGP Keys Revisited ==
Argent Stonecutter noted that PGP keys could be matched to user accounts with the help of an in-world key verification kiosk without Linden involvement. There wasn't further discussion of this topic since the last SLDev-Traffic.

== SLDev-Traffic en Français ==
Laurent Laborde translated SLDev-Traffic #5 into French as an experiment, which is now linked from the main [[SLDev Traffic|SLDev-Traffic index page]]. Know any French-only hackers? Share the link and see if you can generate some interest.

== Leak Checking ==
Alissa Sabre asked whether anyone had run valgrind, with a focus on memory leaks. Gigs Taggart said that he had, but found no leaks. Tofu Linden noted that, for those running valgrind, running with LL_VALGRIND=x set would avoid problematic SIMD detection code in fmod.

During Rob's office hours, Gigs Taggart noted that Observers are being leaked. Even if they are cleaned up at teardown and not being recognized as resource leaks, they may be chewing increasing amounts of CPU time as a viewer session progresses.

== Source Drop with Voice Support - Not Yet ==
Mike Monkowski asked when SLDev would see a drop of the viewer with voice support. Rob Lanphier (Linden) indicated that this wouldn't come before beta 2 as there was some work to be done in moving third-party code out of the viewer, and added that the timeframe would probably be measured in weeks.

== SLDev Workgroups ==
Laurent Laborde proposed creating workgroups for specific tasks not just limited to writing code. The idea was originally brought up during Rob's office hours, and followed up on-list. Laurent suggested JIRA review, wiki cleanup, source documentation, patch review and testing, and benchmarking/profiling, as well as platform-specific porting and maintenance tasks. The overall response has been positive, and discussions continued about the best venue for these groups, be they mailing lists, in-world groups, or web forums.

The proposal summary Laurent presented on-list:<br />
A lot of small but usefull tasks are left undone.
Mostly because people do not know it's needed, or because they focus
or some more glorious tasks like optimisation, debugging, patching,
... But behind thoses hard tasks requiring expertise and experimented
coders, there is a lot of small tasks to be done and they do not need
a lot of expertise.

Here is a few samples of the tasks that could be done by some workgroups :

Jira reviewing :
---------------------
* closing/merging duplicated bug report.
* Trying to reproduce a bug and comment the report accordingly
* When possible, complete an incomplete bug report
* Creating a "Bug review bulletin" (weekly ? montly ?) to help the
developpers and user to find/view the current "hot" bug, reporting
fixed bug, ...
* Helping the developpers to focus on the most important bug.

Wiki l33t
-------------
* Reworking some page according to the SL wiki guideline
* Indexing page with similar topic.
* Adding Wiki Link when possible
* looking for orphaned page
* Commenting wikipage with tags (like wikipedia)
* Review the "Talk Page" and editing the "Article" accordingly
* Googling expert to add a link to a reliable source when possible
(RFC, ISO, WhitePaper, SDK Reference (MSDN/ADC/ManPage/...), ...)

Code related subgroups
----------------------------------
* A subgroup to work on documenting the source code
* A subgroup to work on plateform specific code (win32, Mac, Linux)
* A subgroup of patch reviewer and tester. (check that the patch don't
add more bug than it correct)
* A subgroup of Benchmarker/Profiler for different platform/hardware
...

etc ... (please add/rework workgroups if needed)

Everyone could "subscribe" to more than one workgroup.
sldev should be kept as "master list" to synchronize the workgroups,
report work, request help, ... and of course the usual development
discussion.

Individual, or other workgroups, may request help from individuals or
other workgroups on sldev.

== Liana Linden ==
Liana Linden made an introductory appearance during Rob Lanphier's (Linden) office hours. Liana indicated she would post an intro to SLDev in the future, but in the interim, here's a brief teaser:<br />
Liana Linden: Essentially, I'm project managing, liaising, advising and doing
some lifting for legal, dev, and community where they intersect with the
opening of SL code

Liana Linden: Long version, I have background in open access publishing and
have worked closely with Creative Commons wrangling gnarly copyright issues

Be sure to check out Liana Linden's profile for office hours!

== In Closing ==
There's a discussion about plugin licensing that started in this period, but which is still very hot. It will be summarized in next week's SLDev-Traffic.

(And to all the Lindens and San Franciscans I met last week -- thanks for the food and fun! -- Soft)

SLDev Traffic

2007-04-09T02:46:09Z

Soft Noel:

SLDev-Traffic 6

2007-04-09T02:45:27Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 6

sldev discussions through April 6, 2007

== Build Benchmarks ==
Dale Glass benchmarked builds under Gentoo and Ubuntu (Edgy) Linux. He found that it took about 4GB of RAM to cache the full build so that drive speeds became unimportant. Gentoo had a 15% edge over Ubuntu for compilation speeds, possibly owing to a platform-optimized compiler, however scons ran only half as quickly under Gentoo. The reason for scons' slower build under Gentoo was not explored, although Dale suggested it could be a good area for investigation if there are any python hackers about.

James Cook (Linden) produced an internal email he had written about the benefit of a faster build drive, which was previously quoted by Kelly Linden in [[https://wiki.secondlife.com/wiki/SLDev-Traffic_3#Faster_Viewer_Builds SLDev-Traffic #3]].

== Unit Tests for the Message System ==
Gaurav Sharma from Adroit inquired about the best way to write unit test cases for the message system without actually connecting to a server. Peekay Semyorka suggested that making a small test server or refactoring real server services into test services was about the only way. There was no follow-up.

== OpenJPEG Optimization ==
Callum Lerwick and Dzonatas Sol continued with OpenJPEG optimizations. Of note, Callum prepared a set of benchmarks and found that he's nearing half the speed of KDU with his changes alone, and Dzonatas noted that the decoder is set up so that each stride could have its own thread, although it's not currently set up this way. John Hurliman also pointed out some low hanging fruit:<br />
the LayerData (terrain patch) decoder
reinitializes several data tables for every patch it decodes (256 per
sim). It does this because the original decoder was designed to work
with arbitrary sized patches, but the grid only used 16x16 and 32x32
patches, and now it only uses the full resolution 16x16 patches.

François-Olivier Devaux of the OpenJPEG group confirmed that he had tested some of the patches provided by Callum and Dzonatas and indicated that the code would likely be integrated in the next OpenJPG version.

== PGP Keys Revisited ==
Argent Stonecutter noted that PGP keys could be matched to user accounts with the help of an in-world key verification kiosk without Linden involvement. There wasn't further discussion of this topic since the last SLDev-Traffic.

== SLDev-Traffic en Français ==
Laurent Laborde translated SLDev-Traffic #5 into French as an experiment, which is now linked from the main [[SLDev Traffic|SLDev-Traffic index page]]. Know any French-only hackers? Share the link and see if you can generate some interest.

== Leak Checking ==
Alissa Sabre asked whether anyone had run valgrind, with a focus on memory leaks. Gigs Taggart said that he had, but found no leaks. Tofu Linden noted that, for those running valgrind, running with LL_VALGRIND=x set would avoid problematic SIMD detection code in fmod.

During Rob's office hours, Gigs Taggart noted that Observers are being leaked. Even if they are cleaned up at teardown and not being recognized as resource leaks, they may be chewing increasing amounts of CPU time as a viewer session progresses.

== Source Drop with Voice Support - Not Yet ==
Mike Monkowski asked when SLDev would see a drop of the viewer with voice support. Rob Lanphier (Linden) indicated that this wouldn't come before beta 2 as there was some work to be done in moving third-party code out of the viewer, and added that the timeframe would probably be measured in weeks.

== SLDev Workgroups ==
Laurent Laborde proposed creating workgroups for specific tasks not just limited to writing code. The idea was originally brought up during Rob's office hours, and followed up on-list. Laurent suggested JIRA review, wiki cleanup, source documentation, patch review and testing, and benchmarking/profiling, as well as platform-specific porting and maintenance tasks. The overall response has been positive, and discussions continued about the best venue for these groups, be they mailing lists, in-world groups, or web forums.

The proposal summary Laurent presented on-list:<br />
A lot of small but usefull tasks are left undone.
Mostly because people do not know it's needed, or because they focus
or some more glorious tasks like optimisation, debugging, patching,
... But behind thoses hard tasks requiring expertise and experimented
coders, there is a lot of small tasks to be done and they do not need
a lot of expertise.

Here is a few samples of the tasks that could be done by some workgroups :

Jira reviewing :
---------------------
* closing/merging duplicated bug report.
* Trying to reproduce a bug and comment the report accordingly
* When possible, complete an incomplete bug report
* Creating a "Bug review bulletin" (weekly ? montly ?) to help the
developpers and user to find/view the current "hot" bug, reporting
fixed bug, ...
* Helping the developpers to focus on the most important bug.

Wiki l33t
-------------
* Reworking some page according to the SL wiki guideline
* Indexing page with similar topic.
* Adding Wiki Link when possible
* looking for orphaned page
* Commenting wikipage with tags (like wikipedia)
* Review the "Talk Page" and editing the "Article" accordingly
* Googling expert to add a link to a reliable source when possible
(RFC, ISO, WhitePaper, SDK Reference (MSDN/ADC/ManPage/...), ...)

Code related subgroups
----------------------------------
* A subgroup to work on documenting the source code
* A subgroup to work on plateform specific code (win32, Mac, Linux)
* A subgroup of patch reviewer and tester. (check that the patch don't
add more bug than it correct)
* A subgroup of Benchmarker/Profiler for different platform/hardware
...

etc ... (please add/rework workgroups if needed)

Everyone could "subscribe" to more than one workgroup.
sldev should be kept as "master list" to synchronize the workgroups,
report work, request help, ... and of course the usual development
discussion.

Individual, or other workgroups, may request help from individuals or
other workgroups on sldev.

== Liana Linden ==
Liana Linden made an introductory appearance during Rob Lanphier's (Linden) office hours. Liana indicated she would post an intro to SLDev in the future, but in the interim, here's a brief teaser:<br />
Liana Linden: Essentially, I'm project managing, liaising, advising and doing
some lifting for legal, dev, and community where they intersect with the
opening of SL code

Liana Linden: Long version, I have background in open access publishing and
have worked closely with Creative Commons wrangling gnarly copyright issues

Be sure to check out Liana Linden's profile for office hours!

== In Closing ==
There's a discussion about plugin licensing that started in this period, but which is still very hot. It will be summarized in next week's SLDev-Traffic.

(And to all the Lindens and San Franciscans I met last week -- thanks for the food and fun! -- Soft)

Source downloads

2007-04-07T04:48:13Z

Soft Noel: VPR-169 persists in 1.14.0.1

__NOEDITSECTION__
{{CompileNav}}
__TOC__

Below is a list of all of the releases of the Second Life viewer source code, in reverse chronological order. Be sure to pay attention to the {{OSWebsite|licenses|alt=applicable licenses}}.

<div id="box">
{| border="1" cellspacing="0"
|-
|
==Date==
 
|
==Branch==
(see [[#Branching process|Branching process]] below)
|
==Source==
 
|
==Libs==
 
|
==Build Notes==
 

{{SourceArchiveRow|2007-Apr-03|release-candidate (beta, r59992)|beta-1.14.1.1|Mac: {{JIRA|VWR-399}}}}
{{SourceArchiveRow|2007-Apr-03|Branch_1-14-0 (r59907)|1.14.0.1|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-27|Branch_1-14-0 (r59765)|1.14.0.0|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|Branch_1-14-0 (r59558, First Look)|FL-1.13.3.59558|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|release (r59510)|20070321a|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-20|Branch_1-14-0 (r59492 - branched from release at r59315, First Look)|FL-1.13.3.59492|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-16|release (r59315, First Look)|FL-1.13.3.59315|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-09|release (r59036, First Look)|FL-1.13.3.59036|}}
{{SourceArchiveRow|2007-Mar-09|release-candidate (beta, r59027)|beta-1.13.4.7|}}
{{SourceArchiveRow|2007-Mar-07|release (r58877, First Look)|FL-1.13.3.58877|}}
{{SourceArchiveRow|2007-Mar-05|release (r58754)|20070305a|}}
{{SourceArchiveRow|2007-Feb-27|release-candidate (beta, r58550)|beta-1.13.4.3|}}
{{SourceArchiveRow|2007-Feb-24|Branch_1-14-0 (First Look, r58390)|FL-1.13.3.58390|}}
{{SourceArchiveRow|2007-Feb-20|Branch_1-14-0 (First Look, r58185)|FL-1.13.3.58185|}}
{{SourceArchiveRow|2007-Feb-14|Branch_1-14-0 (First Look, r58018)|FL-1.13.3.58018|}}
{{SourceArchiveRow|2007-Feb-09|Branch_1-14-0 (First Look, r57876)|FL-1.13.3.57876|}}
{{SourceArchiveRow|2007-Feb-08|Branch_1-14-0 (First Look, r57837)|FL-1.13.3.57837|}}
{{SourceArchiveRow|2007-Feb-05|Branch_1-14-0 (First Look, r57679)|FL-1.13.3.57679|}}
{{SourceArchiveRow|2007-Feb-02|Branch_1-14-0 (First Look, r57575)|FL-1.13.3.57575|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/02/slviewer-darwin-libcares-FL-1.13.3.57575.tar.gz Mac OS X libcares libraries (will be included with libraries next release)]
|
{{SourceArchiveRow|2007-Jan-31|Branch_1-14-0 (First Look, r57520)|FL-1.13.3.57520|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-textures-FL-1.13.3.57520.tar.gz Texture files (will be included with source next release)]
|
{{SourceArchiveRow|2007-Jan-31|Release (r57511)|20070131a|}}
{{SourceArchiveRow|2007-Jan-31|Branch_1-13-3 (r57502)|1.13.3.2|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-14-0 (First Look)|FL-1.13.2.57209|}}
{{SourceArchiveRow|2007-Jan-26|Release (r57221)|20070126a|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-13-2 (r57190)|1.13.2.15|}}
{{SourceArchiveRow|2007-Jan-19|Branch_1-13-2 (r56958), last synced with release at r56659 |1.13.2.12|}}
{{SourceArchiveRow|2007-Jan-17|Release (r56851)|20070117a|}}
|- valign="top"
|'''(1.13.2.11)'''
==2007-Jan-17==
|Branch_1-13-2 (r56833), last synced with release at r56659
|''links deleted: wrong source was uploaded''
|''links deleted: wrong source was uploaded''
|
|- valign="top"
|'''(20070112a)'''
==2007-Jan-12==
|Release (r56702)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz Mac/Linux (LF)]
'''Other'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Linux]
|
|- valign="top"
|'''(20070108c)'''
==2007-Jan-08==
|open source prep branch (r56647), branched from release (r56551)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.tar.gz Mac/Linux (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/slviewer-win32-libs-20070108c.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/slviewer-darwin-libs-20070108c.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/slviewer-linux-libs-20070108c.tar.gz Linux]
|
|}
</div>

The "branch" column indicates what branch the source was pulled from in Linden Lab's internal source repository, as well as the version number. This is helpful in determining how and when to do merges.

== Branching process ==

Though Linden Lab doesn't provide a public version control repository, it's useful to understand how Linden Lab deals with branches for understanding the code drops above.

Linden Lab does feature development on independent branches. As those features mature, they are merged into the "release-candidate" branch. The [[QA]] group tests the feature, and either reject or approve it for inclusion in "release". When a major release is about to happen, a branch is created for work on that release (e.g. "Branch_1-13-2"), which gets synced with the "release" branch periodically. Then, stability work is done on the branch, and the new code is deployed. After that, any stability work gets merged back into "release", and the process repeats for the next major release. In the meantime, stability work continues on the branch for maintenance releases.

Note that the dated releases (e.g. 20070117a) are sourced from the working trunk (the "release" branch), and the numbered releases (e.g. 1.13.2.xx) are to sync with the official viewer releases. This means that often, but not always, the dated releases are newer.

[[Image:Branching model.png]]

Source downloads

2007-04-07T04:17:32Z

Soft Noel: Mac fails build of beta-1.14.1.1 with VWR-399

__NOEDITSECTION__
{{CompileNav}}
__TOC__

Below is a list of all of the releases of the Second Life viewer source code, in reverse chronological order. Be sure to pay attention to the {{OSWebsite|licenses|alt=applicable licenses}}.

<div id="box">
{| border="1" cellspacing="0"
|-
|
==Date==
 
|
==Branch==
(see [[#Branching process|Branching process]] below)
|
==Source==
 
|
==Libs==
 
|
==Build Notes==
 

{{SourceArchiveRow|2007-Apr-03|release-candidate (beta, r59992)|beta-1.14.1.1|Mac: {{JIRA|VWR-399}}}}
{{SourceArchiveRow|2007-Apr-03|Branch_1-14-0 (r59907)|1.14.0.1|}}
{{SourceArchiveRow|2007-Mar-27|Branch_1-14-0 (r59765)|1.14.0.0|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|Branch_1-14-0 (r59558, First Look)|FL-1.13.3.59558|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|release (r59510)|20070321a|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-20|Branch_1-14-0 (r59492 - branched from release at r59315, First Look)|FL-1.13.3.59492|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-16|release (r59315, First Look)|FL-1.13.3.59315|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-09|release (r59036, First Look)|FL-1.13.3.59036|}}
{{SourceArchiveRow|2007-Mar-09|release-candidate (beta, r59027)|beta-1.13.4.7|}}
{{SourceArchiveRow|2007-Mar-07|release (r58877, First Look)|FL-1.13.3.58877|}}
{{SourceArchiveRow|2007-Mar-05|release (r58754)|20070305a|}}
{{SourceArchiveRow|2007-Feb-27|release-candidate (beta, r58550)|beta-1.13.4.3|}}
{{SourceArchiveRow|2007-Feb-24|Branch_1-14-0 (First Look, r58390)|FL-1.13.3.58390|}}
{{SourceArchiveRow|2007-Feb-20|Branch_1-14-0 (First Look, r58185)|FL-1.13.3.58185|}}
{{SourceArchiveRow|2007-Feb-14|Branch_1-14-0 (First Look, r58018)|FL-1.13.3.58018|}}
{{SourceArchiveRow|2007-Feb-09|Branch_1-14-0 (First Look, r57876)|FL-1.13.3.57876|}}
{{SourceArchiveRow|2007-Feb-08|Branch_1-14-0 (First Look, r57837)|FL-1.13.3.57837|}}
{{SourceArchiveRow|2007-Feb-05|Branch_1-14-0 (First Look, r57679)|FL-1.13.3.57679|}}
{{SourceArchiveRow|2007-Feb-02|Branch_1-14-0 (First Look, r57575)|FL-1.13.3.57575|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/02/slviewer-darwin-libcares-FL-1.13.3.57575.tar.gz Mac OS X libcares libraries (will be included with libraries next release)]
|
{{SourceArchiveRow|2007-Jan-31|Branch_1-14-0 (First Look, r57520)|FL-1.13.3.57520|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-textures-FL-1.13.3.57520.tar.gz Texture files (will be included with source next release)]
|
{{SourceArchiveRow|2007-Jan-31|Release (r57511)|20070131a|}}
{{SourceArchiveRow|2007-Jan-31|Branch_1-13-3 (r57502)|1.13.3.2|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-14-0 (First Look)|FL-1.13.2.57209|}}
{{SourceArchiveRow|2007-Jan-26|Release (r57221)|20070126a|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-13-2 (r57190)|1.13.2.15|}}
{{SourceArchiveRow|2007-Jan-19|Branch_1-13-2 (r56958), last synced with release at r56659 |1.13.2.12|}}
{{SourceArchiveRow|2007-Jan-17|Release (r56851)|20070117a|}}
|- valign="top"
|'''(1.13.2.11)'''
==2007-Jan-17==
|Branch_1-13-2 (r56833), last synced with release at r56659
|''links deleted: wrong source was uploaded''
|''links deleted: wrong source was uploaded''
|
|- valign="top"
|'''(20070112a)'''
==2007-Jan-12==
|Release (r56702)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz Mac/Linux (LF)]
'''Other'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Linux]
|
|- valign="top"
|'''(20070108c)'''
==2007-Jan-08==
|open source prep branch (r56647), branched from release (r56551)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.tar.gz Mac/Linux (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/slviewer-win32-libs-20070108c.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/slviewer-darwin-libs-20070108c.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/slviewer-linux-libs-20070108c.tar.gz Linux]
|
|}
</div>

The "branch" column indicates what branch the source was pulled from in Linden Lab's internal source repository, as well as the version number. This is helpful in determining how and when to do merges.

== Branching process ==

Though Linden Lab doesn't provide a public version control repository, it's useful to understand how Linden Lab deals with branches for understanding the code drops above.

Linden Lab does feature development on independent branches. As those features mature, they are merged into the "release-candidate" branch. The [[QA]] group tests the feature, and either reject or approve it for inclusion in "release". When a major release is about to happen, a branch is created for work on that release (e.g. "Branch_1-13-2"), which gets synced with the "release" branch periodically. Then, stability work is done on the branch, and the new code is deployed. After that, any stability work gets merged back into "release", and the process repeats for the next major release. In the meantime, stability work continues on the branch for maintenance releases.

Note that the dated releases (e.g. 20070117a) are sourced from the working trunk (the "release" branch), and the numbered releases (e.g. 1.13.2.xx) are to sync with the official viewer releases. This means that often, but not always, the dated releases are newer.

[[Image:Branching model.png]]

SLDev Traffic

2007-04-03T04:40:03Z

Soft Noel:

SLDev Traffic

2007-04-02T02:47:00Z

Soft Noel:

SLDev-Traffic 5

2007-04-02T02:46:23Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 5

sldev discussions through March 30, 2007

== Custom Linden Plants ==
Argent Stonecutter noted that very little data goes into defining trees and plants, as used in Second Life. The entire object could be specified in a taglist and deployed in much the way particle systems are. This affords opportunities for more script control over the plants and reduced prim usage. The full details are in the wiki [[Custom Linden Plants]] with a JIRA at {{JIRA|VWR-303}}.

== Squelching the Viewer Logs ==
Tom "Spot" Callaway expressed an interest in reducing the amount of viewer log output. He found mention of logcontrol.xml and logcontrol-dev.xml but couldn't find examples of their use. Ryan Williams (Linden) wrote up an entry on the [[Error Logging System]]. Phoenix Linden noted that the noisiest output was actually coming from OpenJPEG as direct writes to stderr, thereby bypassing the logging system. Phoenix indicated that a fix would be forthcoming, and "Guido" noted that {{JIRA|VWR-100}} shows how to disable OpenJPEG error output in the interim.

== Taming Wild Threads ==
Discussion continues about the best way to handle very high-volume topics. At current, Rob Lanphier (Linden) has asked users to create JIRA issues or use Wiki talk pages. There was significant continued discussion about the merits of this on the [[Talk:SLDev|SLDev Talk page]]. Rob pointed out some benefits of using the wiki for this, including the fact that some topics will continue to be discussed or referenced for months or years coming. He gave the example of the [[Talk:Texture_Cache|texture cache discussion]], which will likely surface again.

Rob also pointed to the problem of threads that seemed to be discussion for entertainment purposes. These often start out when someone tosses a topic or idea out for discussion without the intent of writing code, and others with no programming plans take up positions in a lengthy debate without so much as producing documentation.

Regarding separating topics into the JIRA and Wiki, there has been continued pushback against this from some list members, who have proposed keeping everything on the list, using forums, or multiple mailing lists. Discussion about this continued in-world, where the idea of a list limited to contributors with signed LL agreements resurfaced, as did the idea of a list for issues where a list member has committed to doing some code work, and the idea of taking some discussions in-world and posting summaries back to the list.

There is nothing like a consensus leaning toward any one answer. Before shooting it down untested, Rob Linden asked on the SLDev talk page that list members give the Wiki and JIRA branching an honest try for a couple more weeks. During Monday office hours, Rob also noted that he hadn't yet gotten enough Linden feedback on the proposed list guidelines.

One point with unanimous agreement is that the Wiki's email notification signup system needs to be fixed. During Rob's office hours, Soft noted that if it were possible to receive an email about every change on a subscribed item, it would be functionally identical to the mailing list for those who favor the list's push format.

(One note - if these discussions continue in the Wiki, people need to be better about signing comments. SLDev's Talk page was very hard to read. -- Soft)

== Controlling the Build Mode ==
Ettore Pasquini expressed interest in learning how the mouse and keyboard control the build mode. Specifically, Ettore is looking for "which classes or functions take care of movements." Ettore is interested in hooking up a 3D controller for use in controlling build mode with high precision.

There was some discussion about available controllers and even a link to a driver for using a Wiimote as an input device but to date, Ettore has no answer.

== More mingw Cross-Build Work ==
Dzonatas Sol posted another patch for building the Windows viewer using mingw. The [https://lists.secondlife.com/pipermail/sldev/2007-March/001324.html new patch] does not appear to be attached to an existing JIRA entry, although Dzonatas mentions that it addresses {{JIRA|VWR-186}}, {{JIRA|VWR-187}} and {{JIRA|VWR-198}}. This patch was made against First Look 58390.

== Disconnected Without Warning ==
Laurent Laborde noted that the user is not explicitly warned when the current simulator times out and disconnects. Callum Lerwick notes that his wife has lost hours worth of work in continuing to make changes to objects without realizing that the map has gone red. Callum suggested that an explicit dialog warning about the disconnection would work if somehow saving the data for later upload or immediately reconnecting were infeasible. Erik Anderson advocates an immediate reconnection, noting that less capable systems can take minutes to relog.

== GPL v3 Released ==
Dzonatas Sol noted that third draft GPL has been released. Of particular interest, the third draft removes language that required copyright holders to protect downstream licensees from patent infringements. "There is now an overall clarification of how a covered work is conveyed and when one conveys such a work that one must abide by the terms of the license to disclaim patent infringement or likewise." Dzonatas indicated the wiki would be updated when more was known about these changes.

== OpenJPEG - Bigger, Better, Stronger, Faster ==
Callum Lerwick found a loop where an array was being zeroed in row order instead of column order. James Cook (Linden) noted that a memset would work even better than correcting the order here, as memset was guaranteed to be optimized for each platform. Stefan Westerfeld noted some work being done on cleaning up this code already and also noted the existence of an OpenJPEG optimization mailing list. Francois-Olivier Devaux, part of the OpenJPEG project, noted that a new version of OpenJPEG was imminent, and suggested that this fix could be included if someone offers a patch. Callum Lerwick followed up with a patch of work in progress.

== Reading Others' Friendlists ==
Marco Milanesio inquired as to whether it was possible to read other users' friendlists. There were no helpful replies for Marco Milanesio. Whether this is possible remains unanswered, though Dale Glass expressed that he hoped it would never be possible.

== GPG Keysigning ==
Dale Glass inquired as to whether there would be interest in LL GPG keysigning. He suggested that LL should create a master key used to sign all employees, as well as creating an automated signing mechanism running on the SL website which allowed signing against a player name or the registered account name. Dale went on to discuss various applications for the keys such as SLDev patch signing and eventual plugin signing. Dale also suggested that key trust levels could be used to differentiate between users with payment info on file, payment info used, Linden Lab employees, and so on.

Phoenix Linden noted that his key is available on his wiki page and via subkeys.pgp.net. Phoenix has signed many of the LL developer keys already and notes:<br />
I will sign keys of people that I meet and that I prove to
myself match their proposed email address.

A secure and automated method of proving identity and key mappings
would take a while, so no one is spending much time thinking about
it. I will think about how to do this, and talk to Zero to see if
there is a good way to roll that into our current Agent Domain
scalability work.

Until that time, I am the best gateway (aka bottleneck) for signing
contributor keys.

== Submitting Patches Requiring Translation Work ==
Jason Giglio asked what to do about patches that included new UI text.

Leyla Farazha (Linden) noted that contributors needed only make changes to the US English text. There is a process in place to detect what needs translation before release. Further:<br />

Help with the translation process is always welcome, and once we have
set up the pipeline for that work we'll let you all know. :-)

Jean Miller (Linden) requests that users please not include machine translations and noted that Linden Lab are putting together tools which would allow contributing translations for missing strings via the Wiki. Jean invited list members to contribute a snazzy format for such a wiki page.

Alissa Sabre, a native Japanese speaker, noted that the Japanese translation is very poor. Jean Miller indicated that the responsible translation service was no longer in use, and that LL were aware of cleanup work to be done here. Laurent Laborde was happier with the French version, "Not super-perfect, but good enough to be 100% useable."

== Identifying JIRAs Needing Action ==
Rob Lanphier (Linden) previously indicated that list members could help tremendously by voting on issues needing attention. Some issues are still getting lost in the volume of the public JIRA however. During Rob's office hours, Gigs Taggart pointed to a few hot issues. It was also noted that it was possible to search for JIRAs with patches attached, and that these would be good high-priority candidates.

Rob indicated that LL are looking to hire someone who can help handle JIRAs and patches offered by the public.

== Physics ==
During Rob Lanphier's (Linden) office hours, Soft Noel inquired about why LL was using an old version of Havok for physics in Second Life. Rob explained that much user content relied on quirks and precise behaviors of the older engine. Rob hoped that coming changes in SL that make it possible to do incremental rollouts might offer a step toward phasing in a faster engine.

Drewan Keats wondered if there had been any discussion about open source physics engines. There was no follow-up discussion on the point.

== Adroit's Unit Testing Patches ==
Soft Noel asked if anyone had been using or testing Adroit's unit testing patches. Nobody in Rob Lanphier's office hours had any positive response, though Rob pointed to the unit testing framework in use as the [http://tut-framework.sourceforge.net tut-framework].

== Rob Linden Needs a Bear ==
You can't have this many in-world meetings and not have a prize at the end, just in case a meeting actually turns out to be boring and all. "Oh hey, and look - FREE BEAR!" is a perfect save. Does SLDev have any qualified bear makers?

Talk:Custom Linden Plants

2007-04-02T00:30:12Z

Soft Noel:

In jira as {{JIRA|VWR-303}} -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:30, 26 March 2007 (PDT)

== Interesting ==

I'm interested. Would the Lindens create another type of ObjectExtraData (ala flexi) to store this? Currently, particle system data (the closest function to the proposed) is stored in a block inside the ObjectUpdate packet, and I think it's already pretty full.

''I would think it could be exclusive with llParticleSystem. It could even be implemented for testing in the Open Source client by using a special texture for face 0 of a cube to indicate that this prim was really a Custom Plant, and then re-assigning the llParticleSystem() parameters as llPlantSystem parameters.'' -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:24, 26 March 2007 (PDT)

Talk:Custom Linden Plants

2007-04-02T00:29:27Z

Soft Noel: Jira template markup

In jira as {{JIRA:VWR-303}} -- [[User:Argent Stonecutter|Argent Stonecutter]] 08:30, 26 March 2007 (PDT)

== Interesting ==

I'm interested. Would the Lindens create another type of ObjectExtraData (ala flexi) to store this? Currently, particle system data (the closest function to the proposed) is stored in a block inside the ObjectUpdate packet, and I think it's already pretty full.

''I would think it could be exclusive with llParticleSystem. It could even be implemented for testing in the Open Source client by using a special texture for face 0 of a cube to indicate that this prim was really a Custom Plant, and then re-assigning the llParticleSystem() parameters as llPlantSystem parameters.'' -- [[User:Argent Stonecutter|Argent Stonecutter]] 13:24, 26 March 2007 (PDT)

Source downloads

2007-03-28T04:13:19Z

Soft Noel: VWR-169 still there

__NOEDITSECTION__
{{CompileNav}}
__TOC__

Below is a list of all of the releases of the Second Life viewer source code, in reverse chronological order. Be sure to pay attention to the {{OSWebsite|licenses|alt=applicable licenses}}.

<div id="box">
{| border="1" cellspacing="0"
|-
|
==Date==
 
|
==Branch==
(see [[#Branching process|Branching process]] below)
|
==Source==
 
|
==Libs==
 
|
==Build Notes==
 

{{SourceArchiveRow|2007-Mar-27|Branch_1-14-0 (r59558)|1.14.0.0|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|Branch_1-14-0 (r59558, First Look)|FL-1.13.3.59558|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-21|release (r59510)|20070321a|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-20|Branch_1-14-0 (r59492 - branched from release at r59315, First Look)|FL-1.13.3.59492|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-16|release (r59315, First Look)|FL-1.13.3.59315|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-09|release (r59036, First Look)|FL-1.13.3.59036|}}
{{SourceArchiveRow|2007-Mar-09|release-candidate (beta, r59027)|beta-1.13.4.7|}}
{{SourceArchiveRow|2007-Mar-07|release (r58877, First Look)|FL-1.13.3.58877|}}
{{SourceArchiveRow|2007-Mar-05|release (r58754)|20070305a|}}
{{SourceArchiveRow|2007-Feb-27|release-candidate (beta, r58550)|beta-1.13.4.3|}}
{{SourceArchiveRow|2007-Feb-24|Branch_1-14-0 (First Look, r58390)|FL-1.13.3.58390|}}
{{SourceArchiveRow|2007-Feb-20|Branch_1-14-0 (First Look, r58185)|FL-1.13.3.58185|}}
{{SourceArchiveRow|2007-Feb-14|Branch_1-14-0 (First Look, r58018)|FL-1.13.3.58018|}}
{{SourceArchiveRow|2007-Feb-09|Branch_1-14-0 (First Look, r57876)|FL-1.13.3.57876|}}
{{SourceArchiveRow|2007-Feb-08|Branch_1-14-0 (First Look, r57837)|FL-1.13.3.57837|}}
{{SourceArchiveRow|2007-Feb-05|Branch_1-14-0 (First Look, r57679)|FL-1.13.3.57679|}}
{{SourceArchiveRow|2007-Feb-02|Branch_1-14-0 (First Look, r57575)|FL-1.13.3.57575|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/02/slviewer-darwin-libcares-FL-1.13.3.57575.tar.gz Mac OS X libcares libraries (will be included with libraries next release)]
|
{{SourceArchiveRow|2007-Jan-31|Branch_1-14-0 (First Look, r57520)|FL-1.13.3.57520|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-textures-FL-1.13.3.57520.tar.gz Texture files (will be included with source next release)]
|
{{SourceArchiveRow|2007-Jan-31|Release (r57511)|20070131a|}}
{{SourceArchiveRow|2007-Jan-31|Branch_1-13-3 (r57502)|1.13.3.2|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-14-0 (First Look)|FL-1.13.2.57209|}}
{{SourceArchiveRow|2007-Jan-26|Release (r57221)|20070126a|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-13-2 (r57190)|1.13.2.15|}}
{{SourceArchiveRow|2007-Jan-19|Branch_1-13-2 (r56958), last synced with release at r56659 |1.13.2.12|}}
{{SourceArchiveRow|2007-Jan-17|Release (r56851)|20070117a|}}
|- valign="top"
|'''(1.13.2.11)'''
==2007-Jan-17==
|Branch_1-13-2 (r56833), last synced with release at r56659
|''links deleted: wrong source was uploaded''
|''links deleted: wrong source was uploaded''
|
|- valign="top"
|'''(20070112a)'''
==2007-Jan-12==
|Release (r56702)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz Mac/Linux (LF)]
'''Other'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Linux]
|
|- valign="top"
|'''(20070108c)'''
==2007-Jan-08==
|open source prep branch (r56647), branched from release (r56551)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.tar.gz Mac/Linux (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/slviewer-win32-libs-20070108c.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/slviewer-darwin-libs-20070108c.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/slviewer-linux-libs-20070108c.tar.gz Linux]
|
|}
</div>

The "branch" column indicates what branch the source was pulled from in Linden Lab's internal source repository, as well as the version number. This is helpful in determining how and when to do merges.

== Branching process ==

Though Linden Lab doesn't provide a public version control repository, it's useful to understand how Linden Lab deals with branches for understanding the code drops above.

Linden Lab does feature development on independent branches. As those features mature, they are merged into the "release-candidate" branch. The [[QA]] group tests the feature, and either reject or approve it for inclusion in "release". When a major release is about to happen, a branch is created for work on that release (e.g. "Branch_1-13-2"), which gets synced with the "release" branch periodically. Then, stability work is done on the branch, and the new code is deployed. After that, any stability work gets merged back into "release", and the process repeats for the next major release. In the meantime, stability work continues on the branch for maintenance releases.

Note that the dated releases (e.g. 20070117a) are sourced from the working trunk (the "release" branch), and the numbered releases (e.g. 1.13.2.xx) are to sync with the official viewer releases. This means that often, but not always, the dated releases are newer.

[[Image:Branching model.png]]

SLDev Traffic

2007-03-25T21:33:36Z

Soft Noel:

SLDev-Traffic 4

2007-03-25T21:33:09Z

Soft Noel:

{{SLDevTraffic}}

sldev-traffic no 4

sldev discussions through March 23, 2007

== Intro ==
The big discussions revolved around performance this week. I've tried to break what mostly happened in two hugely intertwined threads into component parts. Feel free to be extra picky and edit the page if you think I've obfuscated anything by breaking apart the topics.

I'm also pulling more from the IRC and Rob Lanphier's (Linden) in-world office hours than in the past. Look for more of this in the future. And please don't say anything in #opensl or at Rob's office that you don't want repeated without noting it in advance. :) --[[User:Soft Noel|Soft Noel]] 14:33, 25 March 2007 (PDT)

== Build Errata on Source Download Page ==
There's an additional column on the [https://wiki.secondlife.com/wiki/Source_downloads source download page] for bugs that prevent building or running the viewer. If you run into a build issue, please get it into JIRA and add the bug in the new field. If you're stuck, check back to see if a bug has been added.

== Unofficial SVN ==
Dzonatas Sol announced a subversion repository for the viewer, including all existing public source drops. She added an intro to [[get source and compile]] and the repository is located here:<br />
http://oslcc.svn.sourceforge.net/svnroot/oslcc/ll/release/

Rob Lanphier (Linden) noted that the official LL repository was in the works, and that at least initially it would follow a method much like the one Dzonatas was using, relying on the same source drops seen in the zips and tarballs. During his Monday office hours, Rob indicated that he knew the internal and external repository system was unusual, but hoped the hybrid approach would work until LL can sort out a better approach.

The LL repository will initially be hosted with wush.net, a professional svn hosting service. Rob indicated that he wanted to see if it's something capable enough that LL's devs would feel comfortable using it for day-to-day work.

== Help Prioritize JIRAs ==
There are too many JIRAs for them all to be fully evaluated by LL with current resources. Please remember to vote on issues of importance. Who votes is every bit as important as the number of votes. If you're a productive voice on the mailing list, you can be a an especially productive voter as well.

== Forking Big Discussions ==
Rob Lanphier (Linden) requested that discussions generating more than 5 replies in a day be redirected to the JIRA to make the list easier to follow. If a topic dies down after a couple days, it's okay to bring the discussion back to the list, starting with a summary of the JIRA discussion.

Topics not specifically related to Second Life development should be moved to the JIRA immediately.

There was a small amount of follow-up discussion on the [https://wiki.secondlife.com/wiki/Talk:SLDev SLDev Talk page]. Dzonatas Sol seconded the suggestion while Iron Perth suggested that the wiki and JIRA were better used for documentation and bugs, but would be obstacles to discussion. Rob Linden suggested that forums could be used as an alternative target if appropriate.

Of note, there was an unusual drop-off in list readership in the past week as the texture discussion traffic increased, mentioned during Rob's Friday office hours.

== Performance part 1: Profiling ==
Laurent Laborde posted a hierarchical profile of the viewer running on his MacBook Pro and asked for some help in interpreting the output. Tielades offered a few notes. In summary: Unsurprisingly, a large amount of time is spent in OpenGL, and Tleiades noted that nVidia has a profiling tool that may shed extra light on where that time is going. There is a lot of dynamic memory freeing (presumably allocation too -- Soft) going on, and creating resource pools could help performance. LLOctreeTraveler::traverse may be a candidate for optimization -- it would be helpful to investigate how frequently render states change, and how many render batches are dispatched.

Laurent performed a subsequent profile, noting that it looked like QuickTime's MCIdle was being run more often than needed and quoted some material from the Apple developer documentation detailing ways of reducing the load here. Of particular interest may be the QTGetTimeUntilNextTask, which returns the number of milliseconds until an MCIdle call is actually needed again. There was no followup discussion on this point.

Laurent did another profile showing some curious STL behavior, but Dave Parks (Linden) noted that the behavior in question did not exist in release builds, only in debug.

== Performance part 2: Multithreading ==
Skal Tura asked whether any work was happening on multithreading and asked why it was difficult to do. Tleiades gave a brief primer about the types of work that could and couldn't be parallelized, the difficulties in adding parallelization to an existing object without fine-grained resource locking, and noted cases where threading could hurt performance instead of helping. Tleidas also speculated that the CPU may not be the true bottleneck for the viewer, but the amount of GPU setup if render state is too-often changed, or tiny work packets are being submitted. Tleidas emphasized the importance of measuring and isolating bottlenecks before trying to optimize.

Zack Geers noted that the render pipeline is all in one thread, and other threads include disk IO and jpeg2000 decoding. (Note: You can see where all of the threads are kicked off at the top of main() in viewer.cpp; it's a little bit finer-grained than this -- Soft) Zack said he believed some thread-safety work was being done in advance of adding threading to the render pipeline.

Dave Parks (Linden) stepped in with an [https://lists.secondlife.com/pipermail/sldev/2007-March/001116.html extensive post] about the performance work being done. From the end:<br />

In summary, the candidates for optimization are (in no particular order):
- Put LLPipeline::renderGeom on its own thread
- LLVertexBuffer::clientCopy - make it optimal and find the optimal
location from which to call it
- LLVolumeGeometryManager::rebuildGeom - build better batches, build
them faster
- LLOctreeTraveler::traverse - the faster the tree is, the better

Honorable mention but slightly out of my domain for discussion:
- Particle simulation (can't touch particle rendering, sorry). I ported
the particle rendering to point sprites, but it turns out 90% of the
particle systems out there won't port, so it was a wasted effort.
- Avatar animation - I'm sure there's some low hanging fruit in the
avatar animation system. In fact, one dev here claims it used to be a
ton faster than it is, so there might be a one line bug in there slowing
things down.
- Flexible object updates - Ugh.

With all that said, Dave implored people to make stability issues a priority. Previously, Lindens have urged the importance of researching crashes in list members' own builds. Some crashes may have never yet been seen by a Linden with a debugger active. This is one area where list members can really help.

== Performance part 3: Decoded Image Cache Reset on Teleport ==
In the multithreading thread, Skal Tura asked why all textures were apparently loaded again when teleporting to a new location and suggested that the slow rate at which the images were reloaded pointed to bad caching. Tateru Nino confirmed the observation by pointing to a point in code where the cache was effectively invalidated after teleporting. Steve (Linden) [https://lists.secondlife.com/pipermail/sldev/2007-March/001133.html stepped in] with clarification and details about the in-memory cache policy, and reminded list members to look at the First Look branch when doing their own research. He suggested that a good problem to tackle would be that of teleporting to a new location, waiting ~30s, then teleporting back. The system has dropped the in-memory decoded image cache by this point. He also noted that the focus cannot be only on memory, but also the cost of tracking many many in-memory textures.

== Performance part 4: JPEG2000 Decoding and Image Caching ==

Laurent Laborde noted that the jpeg2000 decoding cost a lot of CPU time, and other list members confirmed the observation. There was discussion about whether the viewer used a service thread for jpeg2000 decoding, and several list members confirmed that it was, with Callum Lerwick and Dave Parks (Linden) noting that the improvement was new to the First Look branch. Dzonatas Sol noted that jpeg2000 was designed to incorporate threading though it didn't exist in the current implementation. She pointed to [Openjpeg improvements] for some work already begun on speeding up jpeg2000 decoding.

Callum Lerwick noted that the KDU jpeg2000 decoder had functionality enabling it to decode for a number of milliseconds and then return, functionality openjpeg lacks. Douglas Soo (Linden) noted that he had added this himself as the threading quantum was large on some OSes, and on systems with more active threads than cores, there would be marked choppiness without voluntarily relinquishing a time slice. Adding this functionality to openjpeg could help considerably on low-end systems if openjpeg is decoding images to completion and enjoying preferential scheduling owing to its irregular load.

From here, the thread bloomed into a very extensive discussion about how already-decoded images could be cached and whether they should be. It was noted that the textures are all of similar fixed sizes which could specify a specialized fragmentation-resistant cache layout, and that they all had unique IDs already, which made one proposed relational database or any kind of hashing unnecessary for their tracking.

As an alternative to decoded image caching, list members also explored the idea of caching images in an alternative file format, either as a permanent local replacement for jpeg2000, or as an interim format for lower resolution images while the full resolution images were still being decoded.

Discussion continued on the [https://wiki.secondlife.com/wiki/Talk:Texture_cache texture cache talk page].

== Performance part 5: Performance Degrading Over Time ==
In the multithreading thread, Skal Tura noted that SL takes more and more memory over time, and runs perceptibly slower. No measurements were given. SLDev listmembers came down on both sides of whether this performance degradation existed. Skal Tura noted that he runs for ten hours or more at a time, and by this point there were visible pauses on a very high end machine.

== Performance part 6: How Low Do You Go? ==
There was discussion about SL targeting very low end machines, and about whether it would be advantageous to raise the bar a bit. Laptops, low-end macs still on the market today, international (third-world) users and those on fixed budgets were all mentioned. Some list members also noted that they were sticking with earlier versions of Windows and wanted to avoid anything that might force them to upgrade.

== gcc4 Fix ==
Ismail Dönmez followed the First Look 1.13.3.59315 release with a minor patch for gcc4 support, quipping that someone at Linden Lab must hate gcc4. Jesse Nesbitt noted that getting these into the JIRA would help. Ismail obliged and Tofu Linden accepted and applied it:<br />
https://jira.secondlife.com/browse/VWR-255 (no internal JIRA)

== XUL Editor ==
Vincent Capuano inquired about whether there was an approach to editing the XUL (user interface markup) XML files other than hand-hacking XML. John Hurliman said LL developers had previously stated that they edited by hand. Tinker LaFollette and Synthalor Mandelbrot suggested XML editors that might be a step above straight editing:<br />
http://www.activestate.com/products/komodo_edit/ (all platforms)<br />
http://symbolclick.com/index.htm (Windows)

== GPL'd Submissions ==
This thread began in the week prior, but was still continuing when SLDev-Traffic 3 was written. It has since tapered off.

There was extensive about whether and how Linden Lab could accept patches with a GPL license attached. A prior message from Rob Linden was quoted wherein he thanked Alynna for a submission but noted that the viewer has GPL-incompatible components, and so the patch could not be incorporated. Further confusion seemed to stem from contributors not understanding dual licensing, wherein Linden Lab providing the viewer source to the public under the GPL doesn't necessarily mean LL will use the GPL license for their own builds, which include non-free libraries.

Discussion continued in-world during Rob Lanphier's (Linden) Wednesday office hours. Dzonatas Sol wanted guidance on whether she could contribute some GPLd code. Rob said the code could be used by Dzonatas, but not submitted to Linden Lab under GPL. Discussion continued about whether the code, owned by Dzonatas Sol, could be relicensed in a way compatible with LL's needs and Dzonatas' needs alike. Rob asked Dzonatas to lay out the issue in the JIRA and then forward the request to LL licensing.

On-list again, Jason Giglio listed the non-free libraries that would currently prevent distributing an all-free version of the client. These included:<br/>
APR
*Cg
FMOD
Kakadu
OpenSSL
SmartHeap
SpeedTree

Callum Lerwick detailed substitutions and work-arounds for most of the above, pointing to APR and OpenSSL as the most substantial blockers.

Argent Stonecutter noted that QuickTime was not on the list, but probably should be. While GPL allows linking to libraries distributed with the OS, QT is only distributed with OS X, not with Windows.

== Unit Test Harness: Patch 4 ==
Gaurav Sharma posted the fourth Adroit unit test harness. This week it properly appears in the list archives:<br />
https://lists.secondlife.com/pipermail/sldev/2007-March/001254.html

== QuickTime Replacement ==
Linden Lab are investigating a replacement for QuickTime under Linux -- currently gstreamer, as mentioned during Rob Lanphier's (Linden) Friday office hours. One obstacle is that many .mov files are actually Sorenson video CODEC files, not mpeg4 H.264 CODEC files as many users believed they were. Current .mov is mostly H.264, but there may be other catches.

SLDev-Traffic 3

2007-03-19T19:06:03Z

Soft Noel: /* Line Endings */

{{SLDevTraffic}}

sldev-traffic no 3

sldev discussions through March 16, 2007

== Proprietary Voice Middleware ==
Gigs Taggart inquired as to why Linden Lab was choosing a closed-source solution for voice support. This resulted in extended discussions in all venues.

There was some discussion as to the CODECs in use. Siren14 (G.722.1(C) -- Soft) was named as one CODEC and Tom Callaway inquired with the Free Software Foundation about whether Polycom's implementation was Free or GPL-compatible. The FSF stated that it was not, noting that Polycom required reproduction of their trademark and held the ability to revoke the usage license at any point.

Joe Linden listed the CODECs in use, naming them as standard:
the codecs in use for voice are standard. We're using G.711 and
G.722.1 (annex C) both of which are described in relevant ITU
specifications. We use RTP as media transport - the standard payload
type is used for G.711 and a custom tag for G.722.1(C). The control
protocol is SIP (RFC 3261).

Callum Lerwick questioned the choice of G.711 and proposed building something around the speex CODEC. He pointed to the bandwidth required by G.711 and patent and license issues for G.722.1(C), as identified by Tom Callaway. Callum further pointed out Ekiga, which may be the open source project closest to what Linden Lab are trying to implement with Vivox:
http://www.gnomemeeting.org/

The Vivox code is acknowledged as closed. Joe and Rob Linden both noted that LL are pursuing an avenue for avoiding GPL licensing issues. List members were reminded as well that development on voice support precedes the open source release, with a variety of strong reactions.

== Linden Lab and Open Source ==
A large thread spun off from the voice middleware discussion, wherein list and IRC users criticized or questioned Linden Lab's commitment to open source. Boroondas Gupte and Callum Lerwick called for Linden Lab to explicitly define their position on open source, as between the cathedral or the bazaar, as in Eric S Raymond's noted essay. (10,000ft summary: both models are open source, but the cathedral model makes public releases while the bazaar model makes the full development process public -- Soft)

For reference:<br>
http://en.wikipedia.org/wiki/The_Cathedral_and_the_Bazaar<br>
http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar

Callum Lerwick went on to name using the same SCM and JIRA as two steps Linden Lab could take toward the bazaar position. He characterized the cathedral model as treating non-Linden Lab developers as second class citizens.

Dave Parks (Dave Linden?) emphasized that Linden Lab is not a monolithic entity, and had no position as a whole. Individual developers within Linden Lab choose their level of participation, and Dave notes that for each developer he knows, the decision will be made based on what gets the job done, not control, respect, or ideological issues. Dave noted that this philosophy will extend to the choice of third party libraries at times, where open standards would be used, but closed source was not ruled out. He encouraged developers to speak up whenever they could identify or offer a solution rivaling closed source, and promised they had his support and attention in this.

In response to questions about Linden Lab's level of commitment, Rob Linden laid out the fact that Linden Lab opened the Viewer source at a time when Second Life wasn't hurting for publicity or trying to regain a market position. He contrasted this with the more usual case where a company turns to open source as a last ditch effort in recapturing attention. He also explained that while he agreed that Linden Lab should be increasingly stringent about licensing concerns, going all out on every point at once and attempting to disrupt Second Life as a business was a good way to end up ignored and ineffective.

Boroondas Gupte called for Linden Lab to communicate the open source implications of new feature additions further in advance. He noted that Linden Lab already communicates much about new features in advance, and that adding this level of detail would help the development community better offer free solutions.

== License and Policy in JIRA ==
As the open source discussion consumed much of the list traffic this week, there was discussion about splitting the list into development and policy lists. A JIRA issue was created for discussing this, and it was further discussed during Rob Linden's Friday office hours.<br>
https://jira.secondlife.com/browse/MISC-44 (no internal JIRA)

In the end, there was concern about a second list reducing visibility of issues as developers might not take the step of joining the additional list and would therefore miss out on parts of the discussion. Instead, Rob proposed creating JIRA issues for issues like these, as well as the creation of a discussion/policy JIRA category. Those present during Rob's office hours agreed that this made sense.

== Unofficial SL License FAQ ==
Gigs Taggart created an unofficial Second Life license FAQ, available here:
https://wiki.secondlife.com/wiki/Unofficial_Licensing_FAQ

As with everything on the wiki, feedback and additions are encouraged.

There's another spin-off licensing discussion about GPLd submissions that's still very much alive and unresolved, and so it will be covered in SLDev-Traffic4.

== Object Extrusion Explained ==
Joel Riedesel was trying to understand how prims are represented and created in Second Life. John Hurliman explained the method by which two dimensional profiles are extruded along a three-dimensional path.

https://lists.secondlife.com/pipermail/sldev/2007-March/000940.html

== Faster Viewer Builds ==
Tobias Lang asked whether it were possible to speed up the build. With 1 gigabyte of memory, Callum Lerwick reported build times measured in hours, which were alleviated by adding a second gig of memory and using ccache.

Dzonatas Sol offered a patch that builds newview as a library before performing the final link, and said it made the difference between hitting swap for about 1.5 gigabytes and no swap activity at all:
https://jira.secondlife.com/browse/VWR-225 (no internal JIRA)

Dale Glass mentioned the benefits of using a RAMdisk given the amount of /tmp traffic. Specifically, mounting /tmp as a tmpfs can be most beneficial here.

Kelly Linden produced an excerpt showing the amount of time saved by building on a drive other than the main OS drive, and by moving to a faster 10,000RPM drive, as opposed to the 7,200RPM base. The times were 2m15s for a build on the Windows drive, 2m00s on a spare 7,200 drive, and 1m30s on a faster spare drive. Kelly also noted that getting rid of unnecessary includes can help link times, not just build times. Replacing #includes with class declarations was the example given. (class LLFoo;) Kelly Linden also noted Zero link for Mac users, and Soft Noel noted that it helps considerably, but that it may defer some link errors until missing functions are called.

Jesse Nesbitt suggested IncrediBuild, but noted that it's not Free or cheap. Soft Noel noted that Incredibuild doesn't help much on link times, only build times, but mentioned that Visual Studio 2005's linker was far faster than Visual Studio 2003's and that the 2005 linker was usable with 2003 for projects not yet migrated to the newer compiler. Also of note, Visual Studio 2005 builds projects within a solution in parallel on multiprocessor machines.

Soft inquired as to whether the Linux build had parallel-friendly dependencies. Dzonatas confirmed that they were for those not using distcc.

== Precision Avatar Positioning ==
Ettore Pasquini is looking for a way to move avatars with fine precision for a high resolution input device. John Hurliman noted that the libsecondlife team had accomplished this with crafted AgentUpdate packets and hoped he could dig up some code soon. Callum Lerwick suggested a teledash script. To date, no solution has been presented.

== More Unit Testing ==
Deepak Jain posted the third drop of the unit testing additions. There was no feedback on the list. Please consider reviewing the patch if you're curious to learn more about unit testing, or if you want to provide some guidance on what systems need the most protection going forward.

Deepak's March 13 message was not archived by the listserv, but the patch is still there:

https://lists.secondlife.com/pipermail/sldev/2007-March/000916.html

The original message contained this note on coming progress:
Next up:
A. Unit tests for the following:
i) llcommon - llevent
ii) llmessage - llcipher, llnullcipher, llxorcipher, llbuffer
iii)llmath - llquaternion, v4math
iv) llcharacter - lljoint (requested by community member - John)
B. Fix llnamevalue for the failed unit tests

== Cross-Compiling the Viewer ==
Dzonatas Sol posted progress on cross-compiling the SL Viewer. It relies on using Wine to install the Boost, DirectX and QuickTime SDKs, as well as the Minimalist GNU for Windows compiler, and has been tested under Debian and Debian derivatives. The project page is linked below. Progress is facilitated by a patch currently attached to VWR-187.

http://wiki.secondlife.com/wiki/User:Dzonatas_Sol/OSLCC
https://jira.secondlife.com/browse/VWR-187 (SL-37031 internally)

== Line Endings ==
SLDev users use a wide variety of OSes, editors, compilers and tools. One difference between the platforms is the use of CRLF (Windows) versus LF alone (Mac, Linux). An increasing number of files have been showing up with wrong or mixed endings. SpacedOut Fry's original report of 14 files is in VWR-157. A subsequent source drop had 9 more files with bad endings.

https://jira.secondlife.com/browse/VWR-157 (SL-36821 internally)

The line endings seem like a small detail, but it's worth noting that some editors don't handle mixed or foreign endings properly. Additionally, some diff utilities and SCMs misunderstand foreign line endings and may mark entire files as "changed," masking real changes.

To date, two sources of wrong line endings have been uncovered. The first was a utility applying the GPL license to files with LF only endings under Windows. The second was the use of tortoise svn, which Phoenix Linden identified as not setting eol-style on add. The first reported as fixed by Rob Linden. Phoenix Linden notified internal developers about the tortoise svn problem internally.

Peekay Semyorka noted that users installing cygwin in UNIX line ending mode instead of DOS mode can inhibit some automatic conversions from taking place as well. The preferred behavior is the default installation option, no matter how sacrilegious a CR-producing vim may feel.^M<br>
^M<br>
If you see more line ending troubles, please keep reporting them in JIRA. Every pair of eyes helps.^M<br>
^M<br>
^M<br>
^M

== Zero Linden's Office Hours ==
Many of you know about Rob Linden's office hours. SLDev-Traffic already makes mention of Rob's hours when list issues come up there, and will expand coverage in the future. Zero Linden introduced himself to the list and noted his office hours as well.

I thought I'd introduce myself: I'm Mark Lentczner, a.k.a. Zero Linden.

I'm the Director of Studio Icehouse at Linden Lab. I'm focused on
messaging between systems and the architectural underpinnings of
Second Life.

I hold office hours in world twice a week:
Grasmere 165,109
Tuesdays, 1pm
Thursdays, 7:30am

These are geeky-techy-nerdo office hours. Come talk about the
technology that runs Second Life.

Zero Linden regularly posts office hour transcripts to his wiki, and offers the March 1 transcript as a teaser:<br>
https://wiki.secondlife.com/wiki/User:Zero_Linden<br>
https://wiki.secondlife.com/wiki/ZeroTranscript2007Mar01

Can't go a weekday without a Linden? Subscribe to the Linden Office Hour calendar. It currently covers Rob, Jeska, Torley, Zero and Robin Linden:<br>
http://www.google.com/calendar/embed?src=mvktahmo6mjpvpkkkdnmabmghg%40group.calendar.google.com

== Message_Template.msg Ordering and Packing ==
John Plevyak believed he had found some bugs when investigating message_template.msg and its binary layout. The bugs revolved around ordering issues, apparent dependencies on STL and hash implementations, and a bug and an inefficiency in the hash function.

Zero Linden noted that there wasn't an STL dependency as the order of std::map guarantees a sort on the key, and said the error in the ordering in message_template.msg would be fixed in a coming release.

The bug noted in the hash function was that it ignored the first character of the material being hashed. This potentially results in single-character labels all being matched as the same string, as well as would be the case with strings identical save in the first position. This bug was not resolved in SLDev.

Zero Linden thanked the list, as it had indeed brough attention to an unknown problem. John Plevyak offered him a beer.

== Second Life User Experience ==
Bane Darrow kicked off a lengthy usability discussion when he wrote about a number of frustrating aspects of the Second Life UI, including character and camera movement during appearance editing, some non-resizable screen areas, and menu and inventory floater issues. Ben Glenn (Linden) took the opportunity to introduce himself as the new User Experience Designer at Linden Lab. Ben eagerly encouraged users to file bugs about usability issues as well as engaging him in discussion on list. Users followed up with many more issues and a pointer to a feature wanted from There.

Ben acknowledged that many residents express frustration about some of the same issues mentioned. He's looking for help in identifying and fixing them, and encouraged direct mail for people who want to "join forces."

The pool of JIRA suggestions begins here:

https://jira.secondlife.com/browse/VWR-221 (Virtual Folders, Labels)<br>
https://jira.secondlife.com/browse/VWR-222 (Moving camera and/or avatar when using edit appearance)<br>
https://jira.secondlife.com/browse/VWR-223 (Avatar turning to face object you are trying to edit)<br>
https://jira.secondlife.com/browse/VWR-224 (Console windows immovable)

Kelly Linden points to his page on Inventory UI Design and encourages additions:<br>
https://wiki.secondlife.com/wiki/Inventory_UI_Design<br>
Note that the discussion child page is active on this entry.

Discussion about the camera continued on-list, and Richard Nelson (Linden) noted one of the underlying reasons for an annoying inventory window behavior.

== Web Issues ==
When logging into JIRA, it's often necessary to visit the front page before the login is fully recognized. At current, it's possible to be in a half-logged-in state, where the username is displayed, but appropriate permissions are not given for adding comments or voting on issues. Many list users, including a few Lindens, confirmed the issue. Rob Linden is jabbing at the vendor for help. Seg Baphomet JIRAd the issue:

https://jira.secondlife.com/browse/WEB-47 (SL-32040 internally)

== Automated SVN Imports ==
Running your own SVN? Dale Glass posted a script for automating source drop imports:
http://daleglass.net/load_sl_archive

$ load_sl_archive <directory>

where the <directory> is the directory containing the required files
ONLY (art and source). Current version won't work if you add the
libraries but that can be fixed.

It will:
* Find the version based on the filenames
* Run svn up on the checked out source
* Find the repository's URL from a checked out copy
* Check that the source hasn't been imported already
* Extract the files
* Fix the unicode.ttf (svn_load_dirs doesn't like broken symlinks)
* use svn_load_dirs to load the source, creating a tag with the
release's name.

No interaction needed.

== Second Life Developer Directory ==
Rob Linden noted the current in-world developer directory, which gets more than two thousand views per week, and announced that a similar directory was being created for Viewer developers. The directory will be for individuals who have a signed contribution agreement with Linden Lab, accepted Viewer patches, and a valid business license.

Interested developers should visit this link and select the Software Developer category:<br>
http://secondlife.com/developers/submission.php

Rob anticipates the page going public after five developers are ready to be listed.

== Rob Linden at Virtual Worlds 2007 ==
Going to Virtual Worlds 2007? Meet Rob Linden:<br>
http://www.virtualworlds2007.com

== Victory For OpenJPEG Day ==
The past two issues of SLDev-Traffic have mentioned ongoing frustrations with the Viewer and OpenJPEG. The patch has landed. On March 16th, Tofu Linden acknowledged that the fix had passed testing.

https://jira.secondlife.com/browse/VWR-123#action_11102

Yay! :)

== Just For Fun ==
Scott (Gutherey?) contributed an SL maze generation program. It appears to be Windows only so far, but it's fun seeing projects not exclusively tied to the Viewer. Look in the Second Life Maze Generator directory at Scott's link:

http://sguthery.4shared.com/

== That's It ==
Busy week. My fingers are worn to painful nubs. But it's a good kind of hurt.

Source downloads

2007-03-18T03:36:37Z

Soft Noel: This isn't German. Insert a space.

__NOEDITSECTION__
{{CompileNav}}
__TOC__

Below is a list of all of the releases of the Second Life viewer source code, in reverse chronological order. Be sure to pay attention to the {{OSWebsite|licenses|alt=applicable licenses}}.

<div id="box">
{| border="1" cellspacing="0"
|-
|
==Date==
 
|
==Branch==
(see [[#Branching process|Branching process]] below)
|
==Source==
 
|
==Libs==
 
|
==Build Notes==
 
{{SourceArchiveRow|2007-Mar-16|release (r59315, First Look)|FL-1.13.3.59315|Mac: {{JIRA|VWR-169}}}}
{{SourceArchiveRow|2007-Mar-09|release (r59036, First Look)|FL-1.13.3.59036|}}
{{SourceArchiveRow|2007-Mar-09|release-candidate (beta, r59027)|beta-1.13.4.7|}}
{{SourceArchiveRow|2007-Mar-07|release (r58877, First Look)|FL-1.13.3.58877|}}
{{SourceArchiveRow|2007-Mar-05|release (r58754)|20070305a|}}
{{SourceArchiveRow|2007-Feb-27|release-candidate (beta, r58550)|beta-1.13.4.3|}}
{{SourceArchiveRow|2007-Feb-24|Branch_1-14-0 (First Look, r58390)|FL-1.13.3.58390|}}
{{SourceArchiveRow|2007-Feb-20|Branch_1-14-0 (First Look, r58185)|FL-1.13.3.58185|}}
{{SourceArchiveRow|2007-Feb-14|Branch_1-14-0 (First Look, r58018)|FL-1.13.3.58018|}}
{{SourceArchiveRow|2007-Feb-09|Branch_1-14-0 (First Look, r57876)|FL-1.13.3.57876|}}
{{SourceArchiveRow|2007-Feb-08|Branch_1-14-0 (First Look, r57837)|FL-1.13.3.57837|}}
{{SourceArchiveRow|2007-Feb-05|Branch_1-14-0 (First Look, r57679)|FL-1.13.3.57679|}}
{{SourceArchiveRow|2007-Feb-02|Branch_1-14-0 (First Look, r57575)|FL-1.13.3.57575|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/02/slviewer-darwin-libcares-FL-1.13.3.57575.tar.gz Mac OS X libcares libraries (will be included with libraries next release)]
|
{{SourceArchiveRow|2007-Jan-31|Branch_1-14-0 (First Look, r57520)|FL-1.13.3.57520|}}
|-
|| || || ||
* [http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-textures-FL-1.13.3.57520.tar.gz Texture files (will be included with source next release)]
|
{{SourceArchiveRow|2007-Jan-31|Release (r57511)|20070131a|}}
{{SourceArchiveRow|2007-Jan-31|Branch_1-13-3 (r57502)|1.13.3.2|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-14-0 (First Look)|FL-1.13.2.57209|}}
{{SourceArchiveRow|2007-Jan-26|Release (r57221)|20070126a|}}
{{SourceArchiveRow|2007-Jan-26|Branch_1-13-2 (r57190)|1.13.2.15|}}
{{SourceArchiveRow|2007-Jan-19|Branch_1-13-2 (r56958), last synced with release at r56659 |1.13.2.12|}}
{{SourceArchiveRow|2007-Jan-17|Release (r56851)|20070117a|}}
|- valign="top"
|'''(1.13.2.11)'''
==2007-Jan-17==
|Branch_1-13-2 (r56833), last synced with release at r56659
|''links deleted: wrong source was uploaded''
|''links deleted: wrong source was uploaded''
|
|- valign="top"
|'''(20070112a)'''
==2007-Jan-12==
|Release (r56702)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-src-20070112a.tar.gz Mac/Linux (LF)]
'''Other'''
*[http://secondlife.com/developers/opensource/downloads/2007/01/llmozlib-src-20070112a.tar.gz llMozLib (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-win32-libs-20070112a.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-darwin-libs-20070112a.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/2007/01/slviewer-linux-libs-20070112a.tar.gz Linux]
|
|- valign="top"
|'''(20070108c)'''
==2007-Jan-08==
|open source prep branch (r56647), branched from release (r56551)
|'''Viewer'''
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.zip Windows (CRLF)]
*[http://secondlife.com/developers/opensource/downloads/slviewer-src-20070108c.tar.gz Mac/Linux (LF)]
|
*[http://secondlife.com/developers/opensource/downloads/slviewer-win32-libs-20070108c.zip Windows]
*[http://secondlife.com/developers/opensource/downloads/slviewer-darwin-libs-20070108c.tar.gz Mac]
*[http://secondlife.com/developers/opensource/downloads/slviewer-linux-libs-20070108c.tar.gz Linux]
|
|}
</div>

The "branch" column indicates what branch the source was pulled from in Linden Lab's internal source repository, as well as the version number. This is helpful in determining how and when to do merges.

== Branching process ==

Though Linden Lab doesn't provide a public version control repository, it's useful to understand how Linden Lab deals with branches for understanding the code drops above.

Linden Lab does feature development on independent branches. As those features mature, they are merged into the "release-candidate" branch. The [[QA]] group tests the feature, and either reject or approve it for inclusion in "release". When a major release is about to happen, a branch is created for work on that release (e.g. "Branch_1-13-2"), which gets synced with the "release" branch periodically. Then, stability work is done on the branch, and the new code is deployed. After that, any stability work gets merged back into "release", and the process repeats for the next major release. In the meantime, stability work continues on the branch for maintenance releases.

Note that the dated releases (e.g. 20070117a) are sourced from the working trunk (the "release" branch), and the numbered releases (e.g. 1.13.2.xx) are to sync with the official viewer releases. This means that often, but not always, the dated releases are newer.

[[Image:Branching model.png]]