SLDev-Traffic 6

Open Source Portal > Communicate > SLDev > SLDev Traffic

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 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:

  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 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:

  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:

  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)