Difference between revisions of "SLDev-Traffic 16"

From Second Life Wiki
Jump to navigation Jump to search
(New page: {{SLDevTraffic}} sldev-traffic no 16 sldev discussions through June 15, 2007 == "About Land" Floater Patch == Zi Ree offered a patch, attached to {{JIRA|VWR-1140}}, which makes the Abou...)
 
Line 15: Line 15:
Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.
Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.


== UUID Alignment ==
== Data Alignment ==
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer. One issue Dana runs across are UUIDs, which are often stored as U8 arrays, but read as U32s. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'd so that Lindens can consider whether the change should be made uniformly.
Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.


A UUID with explicit alignment looks like this:<br />
A global buffer with explicit alignment looks like this:<br />
  U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));
  U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));
 
Of course the above could cause concern because the #define UUID_BYTES, which is 8, can not be used in the <CODE>aligned</CODE> attribute.  However, there are only a few of these globals that need such alignment for at the moment they are workable.
 
And a dynamic allocation of a U8 buffer of <CODE>size</CODE> bytes with word boundary alignment looks like this:<br />
  U8* mBuffer = (U8 *)(new U32[size/4]);
 
Each of the above  ensures that the data is aligned properly and is portable across CPU architectures.


== Please Use .txt File Extensions in JIRA ==
== Please Use .txt File Extensions in JIRA ==

Revision as of 04:24, 19 June 2007

SLDev Traffic

sldev-traffic no 16

sldev discussions through June 15, 2007

"About Land" Floater Patch

Zi Ree offered a patch, attached to VWR-1140, which makes the About Land floater resizable, citing problems with some widgets, such as the ban list, being far too small. There wasn't follow-up on-list, but Zi's patch was accepted and applied. Thanks, Zi!

Visual Studio 2005 (VS8) Project Files

Nicholas Beresford posted a set of up-to-date Visual Studio 2005 project files, explaining some small amount of trouble in getting them to work. Listmember Dirk Moerenhout notes the importance of the 2005 project files, in that the "Express" edition of the 2005 compiler is free, opening up access to developers who can't or won't spring for the Microsoft tools.

This lead to some discussion within Linden Lab about the best way to maintain 2005 projects as an ongoing concern, and one of our release engineers has created a script that scans for disparity in the files present in VS7 and VS8 projects, noting "Extending this to cover XCode and SCons files should be doable as well." In the interim, until the 2005 process is smoothed out, Brian O'Sullivan (Linden) confirmed on-list that Linden Lab would gladly accept VS2005 project patches. Nicholas posted a set at VWR-1151, which Brian has assigned to himself. The first set had conflicts with other work, but Nicholas has posted a newer set.

Of note, for the curious, we still use 2003 as the primary platform internally, but are pushing to erase the last restrictions preventing our using 2005.

Data Alignment

Dana Fagerstrom previously noted success in creating a Solaris build of the viewer on x86 and he's now doing the same for SPARC. One issue Dana runs across while working on the SPARC port are buffers that get created as U8's and are then cast as U32's, etc. Dana requests that developers consider adding explicit alignment. For now, Dana's making a patch set with the alignment #ifdef'ed for SPARC so that Lindens can consider whether the change should be made uniformly.

A global buffer with explicit alignment looks like this:

 U8 mData[UUID_BYTES] __attribute__ ((aligned(8)));

Of course the above could cause concern because the #define UUID_BYTES, which is 8, can not be used in the aligned attribute. However, there are only a few of these globals that need such alignment for at the moment they are workable.

And a dynamic allocation of a U8 buffer of size bytes with word boundary alignment looks like this:

  U8* mBuffer = (U8 *)(new U32[size/4]);

Each of the above ensures that the data is aligned properly and is portable across CPU architectures.

Please Use .txt File Extensions in JIRA

Dzonatas Sol suggests that text-based attachments carry a .txt file extension in JIRA. The rationale is that JIRA doesn't add a MIME type, preventing users from viewing the attachment within the browser without the file extension as a type hint.

Email to Objects Broken

Kamilion pointed out that scripts were not receiving email from outside the secondlife.com domain, posting a sample script. This lead to a lengthy discussion about past unreliability in the XMLRPC and mail systems, with some speculation about how reliability could be improved. Kelly Washington (Linden) posted some details about the various communication methods available, noting that llHTTPRequest is the simplest and most reliable of the communication methods. Kelly also noted that Linden Lab were investigating the issue, and Kamilion confirmed that he'd heard back from James Linden, and that Don Linden was leading a recovery effort. Chance Unknown confirmed that some very old messages - as old as 2 weeks - were now coming through.

Any further observations about delays or breakage would be appreciated!

Another Call for CPU Statistics

In the context of a thread about CPU optimization and what programmatic and manual optimizations might help and hurt different platforms, Dirk Moerenhout made a renewed call for statistics about what kinds of CPUs are in use by Second Life residents. To date, there hasn't been a posting of this information, however Laurent Laborde posted a link to a hardware survey from Valve, makers of Half Life.

Dead Flag

Max Okumoto noted that the LL_USE_KDU flag wasn't actually used in the viewer, and Phoenix Linden confirmed that it had now been removed internally. Thanks for pointing that out, Max.

LLMuteList::loadFormFile() Parses the Mute List Improperly

Able Whitman found a discrepancy between how the mute list was formatted and how it was parsed. Brian O'Sullivan (Linden) confirmed the discrepancy and fixed the parsing internally. Nicholaz Beresford gave kudos for a nice catch - agreed!

Sculpted Prims - .OBJ Import

Dzonatas Sol posted a basic .OBJ importer. .OBJ files are a common 3D mesh format, and Dzonatas' importer can handle 64x63 sphere meshes "made with Wings3D, or other modelerst hat can create such meshes." Qarl Linden expressed concern about the importer, as it would only work with very specifically formatted meshes. Periapse Linden suggested that Linden Lab should provide more details on what would make the patch usable at Dzonatas' offer to further tailor the code.

Particle Appearance Changed

Argent Stonecutter noted that the appearance of particles had changed in the 1.17 viewer. Nicholaz Beresford didn't see any relevant changes in a comparison of the old and new partsim and partsource.

Argent reported progress in working with Farallon:

  The problem is that if you have "PSYS_PART_FOLLOW_SRC_MASK" then
  "PSYS_SRC_BURST_RADIUS" is ignored... you can't create a particle
  system that uses "PSYS_PART_FOLLOW_SRC_MASK" and starts the particle
  emission at a distance. Why not, I don't know, it's always been an
  annoyance to me, but I'd just gotten used to it. Farallon had some
  particle systems he'd modified that had a non-zero radius set, and he
  hadn't zeroed them out...
  
  Before 1.15 or so, it acted as if "PSYS_SRC_BURST_RADIUS" was zero.
  
  Now it seems to create the particles at "PSYS_SRC_BURST_RADIUS" then
  applies the "PSYS_PART_FOLLOW_SRC_MASK" rule on the following frame.
  
  The correct "fix" is uncertain.

Nicholaz pointed to a related JIRA at VWR-1154, which is as-of-yet unresolved. Discussion continues about whether to support the old misuse of the system, or to break content by making the particle system work as designed and described in the documentation.

Lex and Yacc Gurury

Soft Linden investigated VWR-68, which was designed to fold some constant expressions in LSL and fix a problem where a subtraction expression could be swallowed as a negative number, creating a nonsense pair of tokens. Soft noted a case where constants could be folded improperly and asked for suggestions on a fix. Dzonatas Sol offered some input, and Argent Stonecutter, author of the original patch, offered a follow-up. Soft has promised to test and import the result.

Bug Triage

This is a reminder that Rob Lanphier (Linden) holds bug triage sessions on Mondays. This is a perfect opportunity to weigh in on JIRA issues that need attention, or that may proscribe fixes you disagree with.

The agenda can always be found on the wiki, and volunteers, including Dzonatas Sol and Gigs taggart have been doing a fantastic job of keeping the agenda up to date!

1.17 PJIRA Cleanup

Dzonatas Sol also volunteered to do some maintenance on the public JIRA following the 1.17 release. I love y'all so much. :)