From oz at lindenlab.com  Thu Nov  1 08:44:50 2012
From: oz at lindenlab.com (Oz Linden (Scott Lawrence))
Date: Thu, 01 Nov 2012 11:44:50 -0400
Subject: [opensource-dev] Snowstorm dev build
In-Reply-To: <1351608503.80380.YahooMailNeo@web171501.mail.ir2.yahoo.com>
References: <mailman.1.1351450803.13976.opensource-dev@lists.secondlife.com>
	<1351608503.80380.YahooMailNeo@web171501.mail.ir2.yahoo.com>
Message-ID: <509298F2.7050803@lindenlab.com>

On 2012-10-30 10:48 , Hitomi Tiponi wrote:
>
> As day 10 is approaching of the next dev viewer build being 'in 
> progress' I am filled with anticipation at the goodies it must contain 
> to take so long to build.  Or is it stuck again and no-one noticed?

No... we're focused on the problems in beta, so nothing new is happening 
in development.  There is a deep queue of goodies building up though....

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121101/649c3259/attachment.htm 

From kf6kjg at gmail.com  Thu Nov  1 09:09:49 2012
From: kf6kjg at gmail.com (Ricky)
Date: Thu, 1 Nov 2012 09:09:49 -0700
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>

Wouldn't it be better if the crash could be reported anyway - just marking
the correct version?  With this in place at least crashes won't be
misreported, but they also will be not reported to the servers at all,
causing statistical deviation - what I believe is the core idea to be
fixed.  More comments in the JIRA,

Ricky
Cron Stardust

On Wed, Oct 31, 2012 at 6:42 PM, Oz Linden <oz at lindenlab.com> wrote:

>    This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/607/
>   Review request for Viewer.
> By Oz Linden.
> Description
>
> In all the marker files used to detect how the viewer run terminates, record the version.  When checking the results, report errors only if the current version matches the version in the file.  This prevents errors in one version from being reported against the subsequent version.
>
>   Testing
>
> Several simulated crashes both of the modified and unmodified viewers, and some in which the marker file was modified manually to simulate different viewers. Launched the new viewer after different crashes (and normal exits) and confirmed (using logging temporarily added for that purpose) that the reported last exec event was correct - and is always reported as Normal if the previous version and the running version were not the same.
>
>   *Bugs: * storm-1850 <http://jira.secondlife.com/browse/storm-1850>
> Diffs
>
>    - indra/newview/llappviewer.h (3d35a13561fc)
>    - indra/newview/llappviewer.cpp (3d35a13561fc)
>
> View Diff <http://codereview.secondlife.com/r/607/diff/>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121101/65fec488/attachment.htm 

From secret.argent at gmail.com  Thu Nov  1 10:34:24 2012
From: secret.argent at gmail.com (Argent)
Date: Thu, 1 Nov 2012 12:34:24 -0500
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
	<CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
Message-ID: <CAKXV3Zt0BmtcMqhVHbsFJDJWH+yuDPvnLVtZwYqHUV5gM8K+ZQ@mail.gmail.com>

Wouldn't this only be an issue, normally, for people switching from one the
viewer to another, where there was an leftover crash filer from the older
viewer? Doesn't seem like leaving these events out would cause significant
deviation.

On Thu, Nov 1, 2012 at 11:09 AM, Ricky <kf6kjg at gmail.com> wrote:

> Wouldn't it be better if the crash could be reported anyway - just marking
> the correct version?  With this in place at least crashes won't be
> misreported, but they also will be not reported to the servers at all,
> causing statistical deviation - what I believe is the core idea to be
> fixed.  More comments in the JIRA,
>
> Ricky
> Cron Stardust
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121101/ad0cd11d/attachment.htm 

From kf6kjg at gmail.com  Thu Nov  1 19:30:23 2012
From: kf6kjg at gmail.com (Ricky)
Date: Thu, 1 Nov 2012 19:30:23 -0700
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <CAKXV3Zt0BmtcMqhVHbsFJDJWH+yuDPvnLVtZwYqHUV5gM8K+ZQ@mail.gmail.com>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
	<CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
	<CAKXV3Zt0BmtcMqhVHbsFJDJWH+yuDPvnLVtZwYqHUV5gM8K+ZQ@mail.gmail.com>
Message-ID: <CAFsNfZ++Oc0wq+VKKs7YVwqnqRrER6fZ4Bx5oVS64KvqLoyB5g@mail.gmail.com>

Well, all I have is anecdotal evidence from my own family of four, everyone
an SL user: we all keep multiple versions of the SL viewer, and even a few
TPVs, on our machines.  If one viewer crashes it's more often that the
person it crashes on will relog in another version or viewer - just to
avoid the perceived, if possibly inaccurate, cause of the crash. We may
switch viewer versions on the second or third crash, depending on the
individual, but the effect is the same.

Like I said, it's anecdotal. Also I can hardly take my family as typical of
SL users, but it's the only population of SL users I can observe.  To me it
seems that if it's both possible and feasible, the viewer should report and
attempt to clean up after a crash - even if it is not its own.  This would
eliminate any deviation from appearing from this source.

Either that, or the marker files should be filename keyed to a version, in
which case the next time that particular version launches it will be able
to do its own report and cleanup.  However this has the negative that the
viewer version may not ever be launched again, leaving the keyed marker
files cluttering the filesystem.  Not a good picture on this logical path
either - though it could be kept sane by having any markers older than X be
automatically removed - if they are too old it matters little.  This path
of logic does keep the deviation very minimal, though not eliminated: only
those viewer versions that crash and are never re-launched get their report
missed.

Ricky
Cron Stardust

On Thu, Nov 1, 2012 at 10:34 AM, Argent <secret.argent at gmail.com> wrote:

> Wouldn't this only be an issue, normally, for people switching from one
> the viewer to another, where there was an leftover crash filer from the
> older viewer? Doesn't seem like leaving these events out would cause
> significant deviation.
>
>
> On Thu, Nov 1, 2012 at 11:09 AM, Ricky <kf6kjg at gmail.com> wrote:
>
>> Wouldn't it be better if the crash could be reported anyway - just
>> marking the correct version?  With this in place at least crashes won't be
>> misreported, but they also will be not reported to the servers at all,
>> causing statistical deviation - what I believe is the core idea to be
>> fixed.  More comments in the JIRA,
>>
>> Ricky
>> Cron Stardust
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121101/3dc1f6f8/attachment.htm 

From secret.argent at gmail.com  Thu Nov  1 23:05:55 2012
From: secret.argent at gmail.com (Argent Stonecutter)
Date: Fri, 2 Nov 2012 01:05:55 -0500
Subject: [opensource-dev] Review Request: Put the viewer version into
	marker files, and report errors only when the version matches
In-Reply-To: <CAFsNfZ++Oc0wq+VKKs7YVwqnqRrER6fZ4Bx5oVS64KvqLoyB5g@mail.gmail.com>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
	<CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
	<CAKXV3Zt0BmtcMqhVHbsFJDJWH+yuDPvnLVtZwYqHUV5gM8K+ZQ@mail.gmail.com>
	<CAFsNfZ++Oc0wq+VKKs7YVwqnqRrER6fZ4Bx5oVS64KvqLoyB5g@mail.gmail.com>
Message-ID: <577E01A5-0D52-4A83-8D3D-458D408E1546@gmail.com>

On 2012-11-01, at 21:30, Ricky <kf6kjg at gmail.com> wrote:
> Well, all I have is anecdotal evidence from my own family of four, everyone an SL user: we all keep multiple versions of the SL viewer, and even a few TPVs, on our machines.  If one viewer crashes it's more often that the person it crashes on will relog in another version or viewer - just to avoid the perceived, if possibly inaccurate, cause of the crash. We may switch viewer versions on the second or third crash, depending on the individual, but the effect is the same.

Different versions of the _same_ viewer can have incompatibilities in its config file, to the point where Firestorm recommends you do a clean install when upgrading, and you're running _different_ viewers on the same config? I suspect you will have fewer crashes if you give each viewer its own directory... and the crashes you're getting may not be statistically useful as a result.

From adeonwriter at live.com  Fri Nov  2 08:01:37 2012
From: adeonwriter at live.com (Adeon Writer)
Date: Fri, 2 Nov 2012 11:01:37 -0400
Subject: [opensource-dev] Formal Animation Set Replacer
Message-ID: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>

A few months back there seemed to be interest on this mailing list in a formal way to have custom animation sets for avatars without LSL scripts (Animation Overriders)

The last I heard there were inquiries on how TPV's were pulling it off (fully client-controlled isn't the most ideal implementation in my opinion, but it works) but after that the mesh deformer seemed to take center stage.

Was there any result to the discussion? Is Linden Lab interested in a feature similar in function to TPV client AO's?

From oz at lindenlab.com  Fri Nov  2 13:55:46 2012
From: oz at lindenlab.com (Oz Linden)
Date: Fri, 02 Nov 2012 20:55:46 -0000
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121102205546.22977.69340@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/607/
-----------------------------------------------------------

(Updated Nov. 2, 2012, 1:55 p.m.)


Review request for Viewer and Callum Prentice.


Description
-------

In all the marker files used to detect how the viewer run terminates, record the version.  When checking the results, report errors only if the current version matches the version in the file.  This prevents errors in one version from being reported against the subsequent version.


This addresses bug storm-1850.
    http://jira.secondlife.com/browse/storm-1850


Diffs
-----

  indra/newview/llappviewer.h 3d35a13561fc 
  indra/newview/llappviewer.cpp 3d35a13561fc 

Diff: http://codereview.secondlife.com/r/607/diff/


Testing
-------

Several simulated crashes both of the modified and unmodified viewers, and some in which the marker file was modified manually to simulate different viewers. Launched the new viewer after different crashes (and normal exits) and confirmed (using logging temporarily added for that purpose) that the reported last exec event was correct - and is always reported as Normal if the previous version and the running version were not the same.


Thanks,

Oz Linden

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121102/633043e6/attachment.htm 

From secret.argent at gmail.com  Sat Nov  3 09:49:36 2012
From: secret.argent at gmail.com (Argent Stonecutter)
Date: Sat, 3 Nov 2012 11:49:36 -0500
Subject: [opensource-dev] Formal Animation Set Replacer
In-Reply-To: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
References: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
Message-ID: <AFCFBC53-6354-45C0-96D9-90E227874206@gmail.com>

I think the requirement for this is somewhat overstated, and I hope that LL does not include any such function in the viewer. A well written LSL based AO has very little overhead, because it can get by with fairly slow timers by using control inputs to detect state changes. Even the somewhat convoluted Franimation Overrider is low overhead, and I suspect the overhead of running it is not much different from the network overhead of a client-based AO.

From carlo at alinoe.com  Sat Nov  3 20:39:56 2012
From: carlo at alinoe.com (Carlo Wood)
Date: Sun, 4 Nov 2012 04:39:56 +0100
Subject: [opensource-dev] Formal Animation Set Replacer
In-Reply-To: <AFCFBC53-6354-45C0-96D9-90E227874206@gmail.com>
References: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
	<AFCFBC53-6354-45C0-96D9-90E227874206@gmail.com>
Message-ID: <20121104043956.2b0d1a8d@hikaru.localdomain>

On Sat, 3 Nov 2012 11:49:36 -0500
Argent Stonecutter <secret.argent at gmail.com> wrote:

> I think the requirement for this is somewhat overstated, and I hope
> that LL does not include any such function in the viewer. A well
> written LSL based AO has very little overhead, because it can get by
> with fairly slow timers by using control inputs to detect state
> changes. Even the somewhat convoluted Franimation Overrider is low
> overhead, and I suspect the overhead of running it is not much
> different from the network overhead of a client-based AO.
> _______________________________________________ Policies and
> (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev Please read the
> policies before posting to keep unmoderated posting privileges

LSL AO's have always failed majorly.
I'd welcome any official server-level support for replacing
the standard stand/walk/run/sit/turn animations, so they work
like the non-AO ones (not that is flawless... happens too
often you "walk" while playing the 'stand' animation :/)

-- 
Carlo Wood <carlo at alinoe.com>

From secret.argent at gmail.com  Sun Nov  4 03:57:28 2012
From: secret.argent at gmail.com (Argent Stonecutter)
Date: Sun, 4 Nov 2012 05:57:28 -0600
Subject: [opensource-dev] Formal Animation Set Replacer
In-Reply-To: <20121104043956.2b0d1a8d@hikaru.localdomain>
References: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
	<AFCFBC53-6354-45C0-96D9-90E227874206@gmail.com>
	<20121104043956.2b0d1a8d@hikaru.localdomain>
Message-ID: <AC3731A3-F654-4748-A854-28146ADA631C@gmail.com>

On 2012-11-03, at 22:39, Carlo Wood <carlo at alinoe.com> wrote:
> LSL AO's have always failed majorly.


I have used and written LSL AOs for 7 years now, and I haven't seen this "majorly" failing. Certainly nothing compared to the shortcomings of client-side AOs. Being able to load AOs from a wearable is kind of a key feature, in fact not having that is a deal-breaker, and none of them even attempt to implement it.

Server-side AOs that can be loaded with wearables would be great, but they're out of scope for this list.

From gcanaday at gmail.com  Sun Nov  4 08:15:08 2012
From: gcanaday at gmail.com (glen)
Date: Sun, 04 Nov 2012 10:15:08 -0600
Subject: [opensource-dev] Formal Animation Set Replacer
In-Reply-To: <AC3731A3-F654-4748-A854-28146ADA631C@gmail.com>
References: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
	<AFCFBC53-6354-45C0-96D9-90E227874206@gmail.com>
	<20121104043956.2b0d1a8d@hikaru.localdomain>
	<AC3731A3-F654-4748-A854-28146ADA631C@gmail.com>
Message-ID: <1352045708.1577.22.camel@jessica-laptop>

I've written and used my own LSL AOs for years. I also don't agree with
Carlo's "majorly fail" assessment since he didn't really give a reason,
but relying on control inputs rather than a moderately quick timer (? la
Argent) also doesn't work.

Control events aren't reliable enough for this as an AO that does rely
on them, as the first version of mine did, only *usually* picks up on
button presses and releases. It's likely Frances Chung and Ziggy Puff
ran into the same problem, which is why they also used timers. When you
use an arrow key to walk and then release it to stand, the control()
event does not always fire. This causes your avatar to stop moving as
you'd expect but the AO doesn't always get the opportunity to stop the
walking animation and resume a standing one. This is only one example
but it's the most noticeable one. I do not know the actual cause or
location of the control() snafu, be it the script VM, client-server
communications lag, dropped packets, or whatever, or I'd file a jira for
it in a heartbeat. It would make my script so much simpler.

I've found that a timer of about 0.25 seconds gives a good balance
between seamless animation pickups and moderate to low server load,
which only means that this is the slowest timer I could reliably get
away with!

Client-based AOs often don't offer the same flexibility as LSL-based
ones do, which is why after trying the one in Firestorm (a pretty good
client AO by most accounts and used by probably thousands of people) I
ended up going back to mine.

--GC

On Sun, 2012-11-04 at 05:57 -0600, Argent Stonecutter wrote:
> On 2012-11-03, at 22:39, Carlo Wood <carlo at alinoe.com> wrote:
> > LSL AO's have always failed majorly.
> 
> 
> I have used and written LSL AOs for 7 years now, and I haven't seen this "majorly" failing. Certainly nothing compared to the shortcomings of client-side AOs. Being able to load AOs from a wearable is kind of a key feature, in fact not having that is a deal-breaker, and none of them even attempt to implement it.
> 
> Server-side AOs that can be loaded with wearables would be great, but they're out of scope for this list.
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges



From angel_of_crimson at hotmail.com  Tue Nov  6 19:41:12 2012
From: angel_of_crimson at hotmail.com (Erin Mallory)
Date: Tue, 6 Nov 2012 22:41:12 -0500
Subject: [opensource-dev] Message From Second Life
In-Reply-To: <20121106163903.D7A1CBD4F@sim6273.agni.lindenlab.com>
References: <20121106163903.D7A1CBD4F@sim6273.agni.lindenlab.com>
Message-ID: <SNT136-W61054650F06C75002789C7C06A0@phx.gbl>


no, its not too late... Please do apply! 

> From: zzzccbemdo6ciqt4xm3rxtvbcqqhsiwa6reddjmztyo7joxfz2y5nd2p2lebrae7 at im.agni.lindenlab.com
> To: Angel_of_Crimson at hotmail.com
> Subject: Message From Second Life
> Date: Tue, 6 Nov 2012 16:39:03 +0000
> 
> [16:38] soraya Vaher: hello there
> [16:38] soraya Vaher: is it too late to apply for the tentacle hunt?
> 
> 
> ---
> To stop receiving these emails, login to https://secondlife.com/my/account/contact.php and uncheck "I would like to receive offline IMs via Email" or visit:
> https://secondlife.com/my/account/im_off.php?k=zzzccbemdo6ciqt4xm3rxtvbcqqhsiwa6reddjmztyo7joxfz2y5nd2p2lebrae7
> 
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121106/4a6926f4/attachment.htm 

From fuerholz at gmx.net  Thu Nov  8 15:50:58 2012
From: fuerholz at gmx.net (=?iso-8859-1?Q?Martin_F=FCrholz?=)
Date: Fri, 9 Nov 2012 00:50:58 +0100
Subject: [opensource-dev] Materials
Message-ID: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>

Hello,
Maestro Linden just announced that the materials project is live on Aditi,
is there a link for a project viewer to test the changes?
 
Thank you in advance.
 
MartinRJ
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/d5d6af58/attachment.htm 

From geenz at geenzo.com  Thu Nov  8 16:05:06 2012
From: geenz at geenzo.com (Jonathan Goodman)
Date: Thu, 8 Nov 2012 19:05:06 -0500
Subject: [opensource-dev] Materials
In-Reply-To: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
References: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
Message-ID: <A7F9003A-5927-45AA-BC5D-60329C925173@geenzo.com>

Nope!  Not yet at least.

On Nov 8, 2012, at 6:50 PM, Martin F?rholz <fuerholz at gmx.net> wrote:

> Hello,
> Maestro Linden just announced that the materials project is live on Aditi,
> is there a link for a project viewer to test the changes?
>  
> Thank you in advance.
>  
> MartinRJ
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting privileges

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121108/3d923a25/attachment.htm 

From sldev at hotmail.com  Fri Nov  9 02:45:42 2012
From: sldev at hotmail.com (Henri Beauchamp)
Date: Fri, 9 Nov 2012 11:45:42 +0100
Subject: [opensource-dev] Viewer About floater and server release notes URL.
Message-ID: <20121109114542.09113010.sldev@hotmail.com>

Greetings,

I'm posting this bug report here because:
1.- It's related with viewer development and its newest features.
2.- I don't use the JIRA any more due to how it was screwed up ("for
    Lindens' eyes only" bug reports).

It has been several server releases in a row that the viewer (including
latest v3.4.x viewers) fail to retreive the server release notes URL
("Error fetching server release notes URL."). When the viewer sends the
request using the "ServerReleaseNotes" capability, it gets a "400 - Bad
request" in return and the header for this reply doesn't contain the
"location" header field that should itself contain the URL of the server
release notes.

To diagnose this more accurately, I modified the code of the
LLServerReleaseNotesURLFetcher class so that it logs the header (as a
LLSD) and the body (as HTML) of the reply. I get:

---------------------
DEBUG: LLServerReleaseNotesURLFetcher::completedHeader: Status: 400 -
Reason: Bad Request - Header (as LLSD):
<llsd>
    <map>
    <key>connection</key>
        <string>close</string>
    <key>content-length</key>
        <string>226</string>
    <key>content-type</key>
        <string>text/html; charset=iso-8859-1</string>
    <key>date</key>
        <string>Fri, 09 Nov 2012 10:29:08 GMT</string>
    </map>
</llsd>

DEBUG: LLServerReleaseNotesURLFetcher::completedRaw: Body (as HTML):
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>400 Bad Request</title>
</head><body>
<h1>Bad Request</h1>
<p>Your browser sent a request that this server could not understand.<br />
</p>
</body></html>
---------------------

Apparently, either the method to retreive the server release notes
URL recently changed, and the viewers didn't yet catch up, or someone
is not doing properly their job in the server team and keeps
copy/pasting buggy code (there have been a few server releases with
such an issue in the past, but the next release usually got it right
while it's been several weeks in a row that we got this issue now...).

So, it would be nice that either:
- LL implements the necessary changes to the viewer side code if a
  new method for retreiving the release notes URL is needed.
- The server team eradicates once and for all this error and stops
  copy/pasting the buggy code in their next releases.

Regards,

Henri.

From oz at lindenlab.com  Fri Nov  9 12:32:39 2012
From: oz at lindenlab.com (Oz Linden (Scott Lawrence))
Date: Fri, 09 Nov 2012 15:32:39 -0500
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
References: <20121101014214.22977.72528@domU-12-31-38-00-90-68.compute-1.internal>
	<CAFsNfZJgSqsv5srDaP0aqzDLY+j4+bDd-QBu6uHkSzF_RbhVGQ@mail.gmail.com>
Message-ID: <509D6867.6030303@lindenlab.com>

On 2012-11-01 12:09 , Ricky wrote:
> Wouldn't it be better if the crash could be reported anyway - just 
> marking the correct version?  With this in place at least crashes 
> won't be misreported, but they also will be not reported to the 
> servers at all, causing statistical deviation - what I believe is the 
> core idea to be fixed.  More comments in the JIRA,

Unfortunately, because of the way the stats collection service works, 
that would be much more difficult.

My goal with this change is just to ensure that version A crashes are 
not counted as version B crashes, at the cost of possibly not counting 
all version A crashes.



From oz at lindenlab.com  Fri Nov  9 12:34:58 2012
From: oz at lindenlab.com (Oz Linden (Scott Lawrence))
Date: Fri, 09 Nov 2012 15:34:58 -0500
Subject: [opensource-dev] Formal Animation Set Replacer
In-Reply-To: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
References: <BLU0-SMTP176300D6786409E62F78CAACD670@phx.gbl>
Message-ID: <509D68F2.2050706@lindenlab.com>

On 2012-11-02 11:01 , Adeon Writer wrote:
> A few months back there seemed to be interest on this mailing list in a formal way to have custom animation sets for avatars without LSL scripts (Animation Overriders)

Yes, this did kick off some interesting and fruitful discussions 
internally, but we've been consumed with other higher priority things 
since.  The issue is not forgotten, just not something we've got time 
for at the moment.


From oz at lindenlab.com  Fri Nov  9 12:36:38 2012
From: oz at lindenlab.com (Oz Linden (Scott Lawrence))
Date: Fri, 09 Nov 2012 15:36:38 -0500
Subject: [opensource-dev] Materials
In-Reply-To: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
References: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
Message-ID: <509D6956.4020808@lindenlab.com>

On 2012-11-08 18:50 , Martin F?rholz wrote:
> Nachricht
> Hello,
> Maestro Linden just announced that the materials project is live on Aditi,
> is there a link for a project viewer to test the changes?
>
Large parts of the server side support for storing and retrieving the 
material data are running on a couple of Aditi regions, but we don't 
have a Project viewer yet.

Don't worry - when we do, we won't keep it a secret.

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/23694cad/attachment.htm 

From dahliatrimble at gmail.com  Fri Nov  9 12:54:27 2012
From: dahliatrimble at gmail.com (Dahlia Trimble)
Date: Fri, 9 Nov 2012 12:54:27 -0800
Subject: [opensource-dev] Materials
In-Reply-To: <509D6956.4020808@lindenlab.com>
References: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
	<509D6956.4020808@lindenlab.com>
Message-ID: <CAAQTD4XWH7G5j7ZNfqYVUsLDb7o0epQCjkz+ZuZD9dDKdDcXYQ@mail.gmail.com>

Are the protocol changes documented anywhere? Who might be able to provide
any information about them?

On Fri, Nov 9, 2012 at 12:36 PM, Oz Linden (Scott Lawrence) <
oz at lindenlab.com> wrote:

>  On 2012-11-08 18:50 , Martin F?rholz wrote:
>
> Hello,
> Maestro Linden just announced that the materials project is live on Aditi,
> is there a link for a project viewer to test the changes?
>
>  Large parts of the server side support for storing and retrieving the
> material data are running on a couple of Aditi regions, but we don't have a
> Project viewer yet.
>
> Don't worry - when we do, we won't keep it a secret.
>
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/8eb02756/attachment.htm 

From oz at lindenlab.com  Fri Nov  9 13:16:43 2012
From: oz at lindenlab.com (Oz Linden (Scott Lawrence))
Date: Fri, 09 Nov 2012 16:16:43 -0500
Subject: [opensource-dev] Materials
In-Reply-To: <CAAQTD4XWH7G5j7ZNfqYVUsLDb7o0epQCjkz+ZuZD9dDKdDcXYQ@mail.gmail.com>
References: <9A7DED450CC8470EA24EA62094CCD4D8@martinpc>
	<509D6956.4020808@lindenlab.com>
	<CAAQTD4XWH7G5j7ZNfqYVUsLDb7o0epQCjkz+ZuZD9dDKdDcXYQ@mail.gmail.com>
Message-ID: <509D72BB.9080509@lindenlab.com>

On 2012-11-09 15:54 , Dahlia Trimble wrote:
> Are the protocol changes documented anywhere? Who might be able to 
> provide any information about them?

Not until we've got both sides implemented and tested, no.


From richard at lindenlab.com  Fri Nov  9 14:05:57 2012
From: richard at lindenlab.com (Richard Nelson)
Date: Fri, 09 Nov 2012 22:05:57 -0000
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <20121102205546.22977.69340@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121102205546.22977.69340@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121109220557.32257.21612@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/607/#review1273
-----------------------------------------------------------

Ship it!


Functionally, it looks good...just one minor comment about structure


indra/newview/llappviewer.cpp
<http://codereview.secondlife.com/r/607/#comment1161>

    Structurally, it seems like this would be cleaner if opening the file, writing out the marke version, and closing it all happened in one function.  Otherwise, you have this constraint that the file needs to be opened before being passed into recordMarkerVersion and closed afterwards.
    
    Just picking a nit, sorry.


- Richard Nelson


On Nov. 2, 2012, 1:55 p.m., Oz Linden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/607/
> -----------------------------------------------------------
> 
> (Updated Nov. 2, 2012, 1:55 p.m.)
> 
> 
> Review request for Viewer and Callum Prentice.
> 
> 
> Description
> -------
> 
> In all the marker files used to detect how the viewer run terminates, record the version.  When checking the results, report errors only if the current version matches the version in the file.  This prevents errors in one version from being reported against the subsequent version.
> 
> 
> This addresses bug storm-1850.
>     http://jira.secondlife.com/browse/storm-1850
> 
> 
> Diffs
> -----
> 
>   indra/newview/llappviewer.h 3d35a13561fc 
>   indra/newview/llappviewer.cpp 3d35a13561fc 
> 
> Diff: http://codereview.secondlife.com/r/607/diff/
> 
> 
> Testing
> -------
> 
> Several simulated crashes both of the modified and unmodified viewers, and some in which the marker file was modified manually to simulate different viewers. Launched the new viewer after different crashes (and normal exits) and confirmed (using logging temporarily added for that purpose) that the reported last exec event was correct - and is always reported as Normal if the previous version and the running version were not the same.
> 
> 
> Thanks,
> 
> Oz Linden
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/a5bf33e1/attachment.htm 

From oz at lindenlab.com  Fri Nov  9 14:50:03 2012
From: oz at lindenlab.com (Oz Linden)
Date: Fri, 09 Nov 2012 22:50:03 -0000
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <20121109220557.32257.21612@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121109220557.32257.21612@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121109225003.30217.2482@domU-12-31-38-00-90-68.compute-1.internal>



> On Nov. 9, 2012, 2:05 p.m., Richard Nelson wrote:
> > indra/newview/llappviewer.cpp, line 3376
> > <http://codereview.secondlife.com/r/607/diff/1/?file=8087#file8087line3376>
> >
> >     Structurally, it seems like this would be cleaner if opening the file, writing out the marke version, and closing it all happened in one function.  Otherwise, you have this constraint that the file needs to be opened before being passed into recordMarkerVersion and closed afterwards.
> >     
> >     Just picking a nit, sorry.

I didn't do that because the usage of the two marker files is so different: the exec marker file is locked, but the logout marker file is not; and there is at least one code path in which the logout marker file is (apparently deliberately) not closed at all.


- Oz


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/607/#review1273
-----------------------------------------------------------


On Nov. 2, 2012, 1:55 p.m., Oz Linden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/607/
> -----------------------------------------------------------
> 
> (Updated Nov. 2, 2012, 1:55 p.m.)
> 
> 
> Review request for Viewer and Callum Prentice.
> 
> 
> Description
> -------
> 
> In all the marker files used to detect how the viewer run terminates, record the version.  When checking the results, report errors only if the current version matches the version in the file.  This prevents errors in one version from being reported against the subsequent version.
> 
> 
> This addresses bug storm-1850.
>     http://jira.secondlife.com/browse/storm-1850
> 
> 
> Diffs
> -----
> 
>   indra/newview/llappviewer.h 3d35a13561fc 
>   indra/newview/llappviewer.cpp 3d35a13561fc 
> 
> Diff: http://codereview.secondlife.com/r/607/diff/
> 
> 
> Testing
> -------
> 
> Several simulated crashes both of the modified and unmodified viewers, and some in which the marker file was modified manually to simulate different viewers. Launched the new viewer after different crashes (and normal exits) and confirmed (using logging temporarily added for that purpose) that the reported last exec event was correct - and is always reported as Normal if the previous version and the running version were not the same.
> 
> 
> Thanks,
> 
> Oz Linden
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/2d9104d6/attachment-0001.htm 

From richard at lindenlab.com  Fri Nov  9 14:54:02 2012
From: richard at lindenlab.com (Richard Nelson)
Date: Fri, 09 Nov 2012 22:54:02 -0000
Subject: [opensource-dev] Review Request: Put the viewer version into
 marker files, and report errors only when the version matches
In-Reply-To: <20121109220557.32257.21612@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121109220557.32257.21612@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121109225402.30214.16740@domU-12-31-38-00-90-68.compute-1.internal>



> On Nov. 9, 2012, 2:05 p.m., Richard Nelson wrote:
> > indra/newview/llappviewer.cpp, line 3376
> > <http://codereview.secondlife.com/r/607/diff/1/?file=8087#file8087line3376>
> >
> >     Structurally, it seems like this would be cleaner if opening the file, writing out the marke version, and closing it all happened in one function.  Otherwise, you have this constraint that the file needs to be opened before being passed into recordMarkerVersion and closed afterwards.
> >     
> >     Just picking a nit, sorry.
> 
> Oz Linden wrote:
>     I didn't do that because the usage of the two marker files is so different: the exec marker file is locked, but the logout marker file is not; and there is at least one code path in which the logout marker file is (apparently deliberately) not closed at all.
>

Hmmm, ok.  Fair enough.


- Richard


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/607/#review1273
-----------------------------------------------------------


On Nov. 2, 2012, 1:55 p.m., Oz Linden wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/607/
> -----------------------------------------------------------
> 
> (Updated Nov. 2, 2012, 1:55 p.m.)
> 
> 
> Review request for Viewer and Callum Prentice.
> 
> 
> Description
> -------
> 
> In all the marker files used to detect how the viewer run terminates, record the version.  When checking the results, report errors only if the current version matches the version in the file.  This prevents errors in one version from being reported against the subsequent version.
> 
> 
> This addresses bug storm-1850.
>     http://jira.secondlife.com/browse/storm-1850
> 
> 
> Diffs
> -----
> 
>   indra/newview/llappviewer.h 3d35a13561fc 
>   indra/newview/llappviewer.cpp 3d35a13561fc 
> 
> Diff: http://codereview.secondlife.com/r/607/diff/
> 
> 
> Testing
> -------
> 
> Several simulated crashes both of the modified and unmodified viewers, and some in which the marker file was modified manually to simulate different viewers. Launched the new viewer after different crashes (and normal exits) and confirmed (using logging temporarily added for that purpose) that the reported last exec event was correct - and is always reported as Normal if the previous version and the running version were not the same.
> 
> 
> Thanks,
> 
> Oz Linden
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121109/22c35591/attachment.htm 

From tonya.souther at gmail.com  Sun Nov 11 09:55:44 2012
From: tonya.souther at gmail.com (Tonya Souther)
Date: Sun, 11 Nov 2012 11:55:44 -0600
Subject: [opensource-dev] Rebuilding Breakpad
Message-ID: <CA+BE2c5H44M-+jg=uaHef=0B1eUet3SVL=wTJkL3Dg6nykKq_g@mail.gmail.com>

I need to rebuild Breakpad for OS X to make the dump_syms command
64-bit, because Firestorm has gotten too big for the 32-bit version.
(The rest of you may run into this before very long.)

I'm trying to use the 3p-google-breakpad repository, forked into
https://bitbucket.org/tonyasouther/3p-google-breakpad-64 (with one
previous Linux change I made for standalone builds). No matter what I
do, though, I can't force cmake to stop using the 10.4u SDK. Since I'm
building on Lion, this makes the build crash and burn exacrtly on the
piece I need.

I'm about to throw my computer out the window after a morning of
fighting cmake and Breakpad. Any suggestions on where the
^&&#$%#$%^&*($#%^@#$^%*& switch is getting set?

From nickyperian at yahoo.com  Sun Nov 11 10:06:55 2012
From: nickyperian at yahoo.com (Nicky Perian)
Date: Sun, 11 Nov 2012 10:06:55 -0800 (PST)
Subject: [opensource-dev] Rebuilding Breakpad
In-Reply-To: <CA+BE2c5H44M-+jg=uaHef=0B1eUet3SVL=wTJkL3Dg6nykKq_g@mail.gmail.com>
References: <CA+BE2c5H44M-+jg=uaHef=0B1eUet3SVL=wTJkL3Dg6nykKq_g@mail.gmail.com>
Message-ID: <1352657215.73339.YahooMailNeo@web126105.mail.ne1.yahoo.com>

I saw some message list traffic on the cmake list about the newer cmake versions having some lion?behavior tweaks.
http://www.cmake.org/mailman/listinfo/cmake that is the subscribe link, You should be able to find the archive from there.

I don't have a mac so, I don't kn0w the details.
?




>________________________________
> From: Tonya Souther <tonya.souther at gmail.com>
>To: opensource-dev at lists.secondlife.com 
>Sent: Sunday, November 11, 2012 11:55 AM
>Subject: [opensource-dev] Rebuilding Breakpad
> 
>I need to rebuild Breakpad for OS X to make the dump_syms command
>64-bit, because Firestorm has gotten too big for the 32-bit version.
>(The rest of you may run into this before very long.)
>
>I'm trying to use the 3p-google-breakpad repository, forked into
>https://bitbucket.org/tonyasouther/3p-google-breakpad-64 (with one
>previous Linux change I made for standalone builds). No matter what I
>do, though, I can't force cmake to stop using the 10.4u SDK. Since I'm
>building on Lion, this makes the build crash and burn exacrtly on the
>piece I need.
>
>I'm about to throw my computer out the window after a morning of
>fighting cmake and Breakpad. Any suggestions on where the
>^&&#$%#$%^&*($#%^@#$^%*& switch is getting set?
>_______________________________________________
>Policies and (un)subscribe information available here:
>http://wiki.secondlife.com/wiki/OpenSource-Dev
>Please read the policies before posting to keep unmoderated posting privileges
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121111/efc768be/attachment.htm 

From secret.argent at gmail.com  Sun Nov 11 10:17:22 2012
From: secret.argent at gmail.com (Argent Stonecutter)
Date: Sun, 11 Nov 2012 12:17:22 -0600
Subject: [opensource-dev] Rebuilding Breakpad
In-Reply-To: <1352657215.73339.YahooMailNeo@web126105.mail.ne1.yahoo.com>
References: <CA+BE2c5H44M-+jg=uaHef=0B1eUet3SVL=wTJkL3Dg6nykKq_g@mail.gmail.com>
	<1352657215.73339.YahooMailNeo@web126105.mail.ne1.yahoo.com>
Message-ID: <98C596FC-CE10-48A4-B143-2E4A551E7D9E@gmail.com>

Shouldn't builds be based on build rules, and not on tweaks in the application?

On 2012-11-11, at 12:06, Nicky Perian <nickyperian at yahoo.com> wrote:

> I saw some message list traffic on the cmake list about the newer cmake versions having some lion behavior tweaks.
> http://www.cmake.org/mailman/listinfo/cmake that is the subscribe link, You should be able to find the archive from there.
> 
> I don't have a mac so, I don't kn0w the details.

From sllists at boroon.dasgupta.ch  Sun Nov 11 14:26:24 2012
From: sllists at boroon.dasgupta.ch (Boroondas Gupte)
Date: Sun, 11 Nov 2012 23:26:24 +0100
Subject: [opensource-dev] Rebuilding Breakpad
In-Reply-To: <98C596FC-CE10-48A4-B143-2E4A551E7D9E@gmail.com>
References: <CA+BE2c5H44M-+jg=uaHef=0B1eUet3SVL=wTJkL3Dg6nykKq_g@mail.gmail.com>
	<1352657215.73339.YahooMailNeo@web126105.mail.ne1.yahoo.com>
	<98C596FC-CE10-48A4-B143-2E4A551E7D9E@gmail.com>
Message-ID: <50A02610.9010504@boroon.dasgupta.ch>

On 11.11.2012 19:17, Argent Stonecutter wrote:
> Shouldn't builds be based on build rules, and not on tweaks in the application?
Chances are these tweaks aren't in the cmake binary but in build rules
which are part of the CMake distribution. As these tweaks probably
compensate for differences between operating systems and operating
system versions (or build toolchains and their versions) it makes sense
to have them there rather than repeating them in the project-specific
build rules of each application using CMake.

Though, I don't know this specific case, so I could be completely off here.

Cheers,
Borun

From nickyperian at yahoo.com  Sun Nov 11 19:53:52 2012
From: nickyperian at yahoo.com (Nicky Perian)
Date: Mon, 12 Nov 2012 03:53:52 -0000
Subject: [opensource-dev] Review Request: OPEN-151. Provide an openal
 and gstreamer plugin streaming audio implementation.
In-Reply-To: <20121013140007.5033.79519@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121013140007.5033.79519@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121112035352.20143.92715@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/604/
-----------------------------------------------------------

(Updated Nov. 11, 2012, 7:53 p.m.)


Review request for Viewer.


Changes
-------

Corrected viewer_manifest.py. Audio libraries (dlls') were missing from the build/binary directory.


Description
-------

Provide an openal and gstreamer plugin streaming audio implementation.
Port from Kokua viewer as a starting point.
Uses windows has a proof of concept platform.
History of work started with Imprudence so there are many try patches that may not be needed and the work started before emphasis on style that is used today.


This addresses bug OPEN-151.
    http://jira.secondlife.com/browse/OPEN-151


Diffs (updated)
-----

  autobuild.xml 9539c10021ba 
  doc/contributions.txt 9539c10021ba 
  indra/cmake/Copy3rdPartyLibs.cmake 9539c10021ba 
  indra/cmake/GStreamer010Plugin.cmake 9539c10021ba 
  indra/cmake/OPENAL.cmake 9539c10021ba 
  indra/llmessage/llcurl.h 9539c10021ba 
  indra/llmessage/llcurl.cpp 9539c10021ba 
  indra/llplugin/llpluginclassmedia.h 9539c10021ba 
  indra/llplugin/llpluginclassmedia.cpp 9539c10021ba 
  indra/llplugin/llplugininstance.cpp 9539c10021ba 
  indra/llplugin/llpluginprocesschild.h 9539c10021ba 
  indra/llplugin/llpluginprocesschild.cpp 9539c10021ba 
  indra/llplugin/llpluginprocessparent.h 9539c10021ba 
  indra/llplugin/llpluginprocessparent.cpp 9539c10021ba 
  indra/media_plugins/gstreamer010/CMakeLists.txt 9539c10021ba 
  indra/media_plugins/gstreamer010/llmediaimplgstreamer.h 9539c10021ba 
  indra/media_plugins/gstreamer010/llmediaimplgstreamertriviallogging.h 9539c10021ba 
  indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.h 9539c10021ba 
  indra/media_plugins/gstreamer010/llmediaimplgstreamervidplug.cpp 9539c10021ba 
  indra/media_plugins/gstreamer010/media_plugin_gstreamer010.cpp 9539c10021ba 
  indra/media_plugins/webkit/media_plugin_webkit.cpp 9539c10021ba 
  indra/newview/CMakeLists.txt 9539c10021ba 
  indra/newview/llviewermedia.cpp 9539c10021ba 
  indra/newview/llviewermedia_streamingaudio.cpp 9539c10021ba 
  indra/newview/skins/default/xui/en/mime_types.xml 9539c10021ba 
  indra/newview/skins/default/xui/en/mime_types_mac.xml 9539c10021ba 
  indra/newview/skins/default/xui/en/notifications.xml 9539c10021ba 
  indra/newview/viewer_manifest.py 9539c10021ba 

Diff: http://codereview.secondlife.com/r/604/diff/


Testing
-------

Logged to parcel with streaming audio. Stream present.
Paused stream. Stream paused.
Resumed stream. Stream playing.
Toggled music check mark in preferences to off/on. Stream off / Stream on.
Teleport to another parcel with a different stream. Old stream stops and new stream plays.
Teleport back to starting point. Original stream plays.


Thanks,

Nicky Perian

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121112/23abd9c2/attachment.htm 

From nickyperian at yahoo.com  Thu Nov 15 05:56:14 2012
From: nickyperian at yahoo.com (Nicky Perian)
Date: Thu, 15 Nov 2012 05:56:14 -0800 (PST)
Subject: [opensource-dev] XML schema
Message-ID: <1352987774.44937.YahooMailNeo@web126103.mail.ne1.yahoo.com>

I am attempting to move some v1 based xml files to work with viewer 3. As is usual when starting something new my reach is short of what I need to grasp.

I will narrow this down, in v1 this attribute ?<border_drop_shadow_visible> is present and processed in imprudence but, fails in v3 based kokua.

It is not listed in?https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_attributes.

How is the XML schema delivered to the viewer?

Is there a source of additional attributes that can be referenced or added to v3 viewers?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121115/5d2765ca/attachment.htm 

From richard at lindenlab.com  Thu Nov 15 09:33:57 2012
From: richard at lindenlab.com (Richard Nelson)
Date: Thu, 15 Nov 2012 09:33:57 -0800
Subject: [opensource-dev] XML schema
In-Reply-To: <1352987774.44937.YahooMailNeo@web126103.mail.ne1.yahoo.com>
References: <1352987774.44937.YahooMailNeo@web126103.mail.ne1.yahoo.com>
Message-ID: <op.wntsevntf4xas0@richard-hp-pc>

That wiki page relies on being manually kept up to date, which is not  
something we've been doing.  While there is currently no official schema  
for XUI files, that will change in the future.  The parameter blocks as  
defined in code are theoretically able to generate their own schemata at  
runtime.  There is still a bit of work remaining to finish this and since  
it is relatively low priority, I can't promise a date when we'll have it  
done.  But rest assured, we recognize the need.

R.

On Thu, 15 Nov 2012 05:56:14 -0800, Nicky Perian <nickyperian at yahoo.com>  
wrote:

> I am attempting to move some v1 based xml files to work with viewer 3.  
> As is usual when >starting something new my reach is short of what I  
> need to grasp.
>
> I will narrow this down, in v1 this attribute   
> <border_drop_shadow_visible> is present and >processed in imprudence  
> but, fails in v3 based kokua.
>
> It is not listed in  
> https://wiki.secondlife.com/wiki/Skinning_HowTo/Common_XUI_attributes.
>
> How is the XML schema delivered to the viewer?
>
> Is there a source of additional attributes that can be referenced or  
> added to v3 viewers?
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121115/4df8006b/attachment.htm 

From Lance.Corrimal at eregion.de  Tue Nov 20 03:22:29 2012
From: Lance.Corrimal at eregion.de (Lance Corrimal)
Date: Tue, 20 Nov 2012 12:22:29 +0100
Subject: [opensource-dev] software development
Message-ID: <2500021.BimJXfLfgs@sai>

http://www.sandraandwoo.com/2012/11/19/0430-software-engineering-now-with-
cats/

No, I'm not affiliated with that website. it just gave me c|n>k.

From cjohndavies at gmail.com  Wed Nov 21 06:32:24 2012
From: cjohndavies at gmail.com (CJ Davies)
Date: Wed, 21 Nov 2012 14:32:24 +0000
Subject: [opensource-dev]  phantom avatar
Message-ID: <50ACE5F8.7010206@gmail.com>

I'm modifying the viewer to allow avatar & camera to be controlled from 
real world position/orientation data (think GPS, accelerometer, 
magnetometer). The idea is to allow you to explore a real world location 
simultaneously to a sim-based reconstruction/visualisation.

The modifications are pretty much working, however one issue is that the 
sim will often have obstructions that are not present in the real world 
location (eg walls that have fallen down). The simplest solution I can 
think of is to make the avatar phantom, as na?vely I assume that this 
requires less hacking than making all of thousands & thousands of prims 
in a sim phantom.

Thoughts?

Modifications are here if anybody's interest has been piqued
https://bitbucket.org/cj_davies/viewer-release-serial-io

Regards,
CJ Davies

From tinacloud at gmx.de  Wed Nov 21 10:32:45 2012
From: tinacloud at gmx.de (Zi Ree)
Date: Wed, 21 Nov 2012 19:32:45 +0100
Subject: [opensource-dev] phantom avatar
In-Reply-To: <50ACE5F8.7010206@gmail.com>
References: <50ACE5F8.7010206@gmail.com>
Message-ID: <201211211932.45482.tinacloud@gmx.de>

Am Mittwoch, 21. November 2012, 15:32:24 schrieb CJ Davies:

> location (eg walls that have fallen down). The simplest solution I can
> think of is to make the avatar phantom, as na?vely I assume that this
> requires less hacking than making all of thousands & thousands of prims
> in a sim phantom.

You could have the avatar sitting on a prim instead of just walking, and that 
prim can turn its physics off in case of a collision and move with 
llSetRegionPos() until the collision is over.

> CJ Davies

Zi

From kf6kjg at gmail.com  Sun Nov 25 20:23:56 2012
From: kf6kjg at gmail.com (Ricky)
Date: Sun, 25 Nov 2012 20:23:56 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
Message-ID: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>

Just reported BUG-885 <https://jira.secondlife.com/browse/BUG-885>,
"Edge-on prim rotation snaps when snap is disabled"  Patch attached.

Looks like this bug has been in place for a very long time - dates back to
revision 0 of the code repository, committed by James Cook (James Linden).

I've been delving back into the source code after a year and a half away.
 I have to compliment LL, and all else involved, on the streamlined compile
setup - smoother even than the old develop.py system, definitely better
than the transition period when I last attempted! :D

I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!

Ricky
Cron Stardust

PS, for Firestorm I also reported it as
FIRE-8338<http://jira.phoenixviewer.com/browse/FIRE-8338> as
that is where I originally found the bug - however it exists in every
viewer I've looked at.  Based on my research I think it's been in existence
since snapping was first introduced - whenever that was!
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121125/661a2cf1/attachment.htm 

From darien.caldwell at gmail.com  Sun Nov 25 21:33:37 2012
From: darien.caldwell at gmail.com (Darien Caldwell)
Date: Sun, 25 Nov 2012 21:33:37 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
Message-ID: <CAD1wxTSq=-8G1ndGXvOqrNjXm6HeJQ-YuCygXT=pWknfAE_Uug@mail.gmail.com>

I'm a little unsure what "Edge on rotation" means. I can rotate a prim on
every axis in-world with snap off, and it never snaps. At least, not unless
I make it snap by engaging the Angle ring outside the circumfrence of the
rotation handle. Then it snaps as it should.

I hope your patch isn't breaking this functionality, it's intended and
desirable.


On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:

> Just reported BUG-885 <https://jira.secondlife.com/browse/BUG-885>,
> "Edge-on prim rotation snaps when snap is disabled"  Patch attached.
>
> Looks like this bug has been in place for a very long time - dates back to
> revision 0 of the code repository, committed by James Cook (James Linden).
>
> I've been delving back into the source code after a year and a half away.
>  I have to compliment LL, and all else involved, on the streamlined compile
> setup - smoother even than the old develop.py system, definitely better
> than the transition period when I last attempted! :D
>
> I found this bug while I was working on learning/cleaning the code
> structure in the LLManip* classes in preparation for reviving an old
> project.  Imagine my surprise when I found that one of the cases didn't
> have a check for whether Snapping was enabled!  So I took to opportunity to
> delve deeper and work out a fix.  Enjoy!
>
> Ricky
> Cron Stardust
>
> PS, for Firestorm I also reported it as FIRE-8338<http://jira.phoenixviewer.com/browse/FIRE-8338> as
> that is where I originally found the bug - however it exists in every
> viewer I've looked at.  Based on my research I think it's been in existence
> since snapping was first introduced - whenever that was!
>
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121125/6912ac12/attachment.htm 

From kf6kjg at gmail.com  Sun Nov 25 22:13:52 2012
From: kf6kjg at gmail.com (Ricky)
Date: Sun, 25 Nov 2012 22:13:52 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <CAD1wxTSq=-8G1ndGXvOqrNjXm6HeJQ-YuCygXT=pWknfAE_Uug@mail.gmail.com>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
	<CAD1wxTSq=-8G1ndGXvOqrNjXm6HeJQ-YuCygXT=pWknfAE_Uug@mail.gmail.com>
Message-ID: <CAFsNfZJFuSmZ89UaY=fRMngVP=rgY_KQaBCye3oNJBEj9QhBgA@mail.gmail.com>

For a missing hyphen... :)  I meant edge-on.

Here's how to reproduce the issue:
Rez a cube
Verify that Snap is disabled
Orient camera to directly face one of the prim faces
Select rotate mode or hold the correct modifier key(s)
Using the mouse drag on the rotate circle that is most like a line - aka it
is "edge-on"
Observe that as you drag along the line of circle the cube it rotates
smoothly (expected)
Observe that if you drag off the line - as if snapping was enabled and you
wished to snap - and then again in the direction of the line that it will
snap. (not expected)

Hope that helps clarify


Ps. Sorry for the dup email Darien, I forgot to reply all.

On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
wrote:
> I'm a little unsure what "Edge on rotation" means. I can rotate a prim on
every axis in-world with snap off, and it never snaps. At least, not unless
I make it snap by engaging the Angle ring outside the circumfrence of the
rotation handle. Then it snaps as it should.
>
> I hope your patch isn't breaking this functionality, it's intended and
desirable.
>
> On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:
>>
>> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
disabled"  Patch attached.
>> Looks like this bug has been in place for a very long time - dates back
to revision 0 of the code repository, committed by James Cook (James
Linden).
>> I've been delving back into the source code after a year and a half
away.  I have to compliment LL, and all else involved, on the streamlined
compile setup - smoother even than the old develop.py system, definitely
better than the transition period when I last attempted! :D
>> I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!
>> Ricky
>> Cron Stardust
>> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
originally found the bug - however it exists in every viewer I've looked
at.  Based on my research I think it's been in existence since snapping was
first introduced - whenever that was!
>> _______________________________________________
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
privileges
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121125/aa15b50f/attachment.htm 

From darien.caldwell at gmail.com  Sun Nov 25 22:41:51 2012
From: darien.caldwell at gmail.com (Darien Caldwell)
Date: Sun, 25 Nov 2012 22:41:51 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <CAFsNfZJFuSmZ89UaY=fRMngVP=rgY_KQaBCye3oNJBEj9QhBgA@mail.gmail.com>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
	<CAD1wxTSq=-8G1ndGXvOqrNjXm6HeJQ-YuCygXT=pWknfAE_Uug@mail.gmail.com>
	<CAFsNfZJFuSmZ89UaY=fRMngVP=rgY_KQaBCye3oNJBEj9QhBgA@mail.gmail.com>
Message-ID: <CAD1wxTRK+DmU+_A7X0e+yonhPFWk689kaipOFT-ZkE06Q5Adcw@mail.gmail.com>

Ahh, I see what you mean. it's acting as if the hidden snap ring is still
present.  A sneaky bug. :)


On Sun, Nov 25, 2012 at 10:13 PM, Ricky <kf6kjg at gmail.com> wrote:

> For a missing hyphen... :)  I meant edge-on.
>
> Here's how to reproduce the issue:
> Rez a cube
> Verify that Snap is disabled
> Orient camera to directly face one of the prim faces
> Select rotate mode or hold the correct modifier key(s)
> Using the mouse drag on the rotate circle that is most like a line - aka
> it is "edge-on"
> Observe that as you drag along the line of circle the cube it rotates
> smoothly (expected)
> Observe that if you drag off the line - as if snapping was enabled and you
> wished to snap - and then again in the direction of the line that it will
> snap. (not expected)
>
> Hope that helps clarify
>
>
> Ps. Sorry for the dup email Darien, I forgot to reply all.
>
> On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
> wrote:
> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
> on every axis in-world with snap off, and it never snaps. At least, not
> unless I make it snap by engaging the Angle ring outside the circumfrence
> of the rotation handle. Then it snaps as it should.
> >
> > I hope your patch isn't breaking this functionality, it's intended and
> desirable.
> >
> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:
> >>
> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
> disabled"  Patch attached.
> >> Looks like this bug has been in place for a very long time - dates back
> to revision 0 of the code repository, committed by James Cook (James
> Linden).
> >> I've been delving back into the source code after a year and a half
> away.  I have to compliment LL, and all else involved, on the streamlined
> compile setup - smoother even than the old develop.py system, definitely
> better than the transition period when I last attempted! :D
> >> I found this bug while I was working on learning/cleaning the code
> structure in the LLManip* classes in preparation for reviving an old
> project.  Imagine my surprise when I found that one of the cases didn't
> have a check for whether Snapping was enabled!  So I took to opportunity to
> delve deeper and work out a fix.  Enjoy!
> >> Ricky
> >> Cron Stardust
> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
> originally found the bug - however it exists in every viewer I've looked
> at.  Based on my research I think it's been in existence since snapping was
> first introduced - whenever that was!
> >> _______________________________________________
> >> Policies and (un)subscribe information available here:
> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >> Please read the policies before posting to keep unmoderated posting
> privileges
> >
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121125/3477538e/attachment.htm 

From kf6kjg at gmail.com  Sun Nov 25 23:26:53 2012
From: kf6kjg at gmail.com (Ricky)
Date: Sun, 25 Nov 2012 23:26:53 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <CAD1wxTRK+DmU+_A7X0e+yonhPFWk689kaipOFT-ZkE06Q5Adcw@mail.gmail.com>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
	<CAD1wxTSq=-8G1ndGXvOqrNjXm6HeJQ-YuCygXT=pWknfAE_Uug@mail.gmail.com>
	<CAFsNfZJFuSmZ89UaY=fRMngVP=rgY_KQaBCye3oNJBEj9QhBgA@mail.gmail.com>
	<CAD1wxTRK+DmU+_A7X0e+yonhPFWk689kaipOFT-ZkE06Q5Adcw@mail.gmail.com>
Message-ID: <CAFsNfZJKdSiewB-LjOf9w34GdR-9EQJ_tstf5FROzY=+8NP9qA@mail.gmail.com>

Yep - so sneaky it's not been noticed for years. I think it's because
no-one actually uses that part of the editors functionality!

Leaves me wondering about when the snap functionality was introduced... The
repository doesn't go back that far! :)

On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
wrote:
> Ahh, I see what you mean. it's acting as if the hidden snap ring is still
present.  A sneaky bug. :)
>
> On Sun, Nov 25, 2012 at 10:13 PM, Ricky <kf6kjg at gmail.com> wrote:
>>
>> For a missing hyphen... :)  I meant edge-on.
>>
>> Here's how to reproduce the issue:
>> Rez a cube
>> Verify that Snap is disabled
>> Orient camera to directly face one of the prim faces
>> Select rotate mode or hold the correct modifier key(s)
>> Using the mouse drag on the rotate circle that is most like a line - aka
it is "edge-on"
>> Observe that as you drag along the line of circle the cube it rotates
smoothly (expected)
>> Observe that if you drag off the line - as if snapping was enabled and
you wished to snap - and then again in the direction of the line that it
will snap. (not expected)
>>
>> Hope that helps clarify
>>
>>
>> Ps. Sorry for the dup email Darien, I forgot to reply all.
>>
>> On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
wrote:
>> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
on every axis in-world with snap off, and it never snaps. At least, not
unless I make it snap by engaging the Angle ring outside the circumfrence
of the rotation handle. Then it snaps as it should.
>> >
>> > I hope your patch isn't breaking this functionality, it's intended and
desirable.
>> >
>> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:
>> >>
>> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
disabled"  Patch attached.
>> >> Looks like this bug has been in place for a very long time - dates
back to revision 0 of the code repository, committed by James Cook (James
Linden).
>> >> I've been delving back into the source code after a year and a half
away.  I have to compliment LL, and all else involved, on the streamlined
compile setup - smoother even than the old develop.py system, definitely
better than the transition period when I last attempted! :D
>> >> I found this bug while I was working on learning/cleaning the code
structure in the LLManip* classes in preparation for reviving an old
project.  Imagine my surprise when I found that one of the cases didn't
have a check for whether Snapping was enabled!  So I took to opportunity to
delve deeper and work out a fix.  Enjoy!
>> >> Ricky
>> >> Cron Stardust
>> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
originally found the bug - however it exists in every viewer I've looked
at.  Based on my research I think it's been in existence since snapping was
first introduced - whenever that was!
>> >> _______________________________________________
>> >> Policies and (un)subscribe information available here:
>> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> >> Please read the policies before posting to keep unmoderated posting
privileges
>> >
>> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121125/8cdb0b49/attachment-0001.htm 

From Lance.Corrimal at eregion.de  Sun Nov 25 23:48:15 2012
From: Lance.Corrimal at eregion.de (Lance Corrimal)
Date: Mon, 26 Nov 2012 08:48:15 +0100
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <CAFsNfZJKdSiewB-LjOf9w34GdR-9EQJ_tstf5FROzY=+8NP9qA@mail.gmail.com>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
	<CAD1wxTRK+DmU+_A7X0e+yonhPFWk689kaipOFT-ZkE06Q5Adcw@mail.gmail.com>
	<CAFsNfZJKdSiewB-LjOf9w34GdR-9EQJ_tstf5FROzY=+8NP9qA@mail.gmail.com>
Message-ID: <1515508.6rn8zR22J5@sai>

Verified - Now I'm sticking the patch in a test build to see if it breaks 
other stuff.

Do you have CA on file?

bye,
LC


Am Sonntag, 25. November 2012, 23:26:53 schrieb Ricky:
> Yep - so sneaky it's not been noticed for years. I think it's because
> no-one actually uses that part of the editors functionality!
> 
> Leaves me wondering about when the snap functionality was introduced... The
> repository doesn't go back that far! :)
> 
> On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
> 
> wrote:
> > Ahh, I see what you mean. it's acting as if the hidden snap ring is still
> 
> present.  A sneaky bug. :)
> 
> > On Sun, Nov 25, 2012 at 10:13 PM, Ricky <kf6kjg at gmail.com> wrote:
> >> For a missing hyphen... :)  I meant edge-on.
> >> 
> >> Here's how to reproduce the issue:
> >> Rez a cube
> >> Verify that Snap is disabled
> >> Orient camera to directly face one of the prim faces
> >> Select rotate mode or hold the correct modifier key(s)
> >> Using the mouse drag on the rotate circle that is most like a line - aka
> 
> it is "edge-on"
> 
> >> Observe that as you drag along the line of circle the cube it rotates
> 
> smoothly (expected)
> 
> >> Observe that if you drag off the line - as if snapping was enabled and
> 
> you wished to snap - and then again in the direction of the line that it
> will snap. (not expected)
> 
> >> Hope that helps clarify
> >> 
> >> 
> >> Ps. Sorry for the dup email Darien, I forgot to reply all.
> >> 
> >> On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com>
> 
> wrote:
> >> > I'm a little unsure what "Edge on rotation" means. I can rotate a prim
> 
> on every axis in-world with snap off, and it never snaps. At least, not
> unless I make it snap by engaging the Angle ring outside the circumfrence
> of the rotation handle. Then it snaps as it should.
> 
> >> > I hope your patch isn't breaking this functionality, it's intended and
> 
> desirable.
> 
> >> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:
> >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
> 
> disabled"  Patch attached.
> 
> >> >> Looks like this bug has been in place for a very long time - dates
> 
> back to revision 0 of the code repository, committed by James Cook (James
> Linden).
> 
> >> >> I've been delving back into the source code after a year and a half
> 
> away.  I have to compliment LL, and all else involved, on the streamlined
> compile setup - smoother even than the old develop.py system, definitely
> better than the transition period when I last attempted! :D
> 
> >> >> I found this bug while I was working on learning/cleaning the code
> 
> structure in the LLManip* classes in preparation for reviving an old
> project.  Imagine my surprise when I found that one of the cases didn't
> have a check for whether Snapping was enabled!  So I took to opportunity to
> delve deeper and work out a fix.  Enjoy!
> 
> >> >> Ricky
> >> >> Cron Stardust
> >> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where I
> 
> originally found the bug - however it exists in every viewer I've looked
> at.  Based on my research I think it's been in existence since snapping was
> first introduced - whenever that was!
> 
> >> >> _______________________________________________
> >> >> Policies and (un)subscribe information available here:
> >> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> >> >> Please read the policies before posting to keep unmoderated posting
> 
> privileges

From kf6kjg at gmail.com  Mon Nov 26 07:30:54 2012
From: kf6kjg at gmail.com (Ricky)
Date: Mon, 26 Nov 2012 07:30:54 -0800
Subject: [opensource-dev] Found long-standing prim rotation bug: BUG-885
In-Reply-To: <1515508.6rn8zR22J5@sai>
References: <CAFsNfZJjs5aNntS-P1nt+FUiK7agYm=h6xoPaeYjsmSEhfgLXg@mail.gmail.com>
	<CAD1wxTRK+DmU+_A7X0e+yonhPFWk689kaipOFT-ZkE06Q5Adcw@mail.gmail.com>
	<CAFsNfZJKdSiewB-LjOf9w34GdR-9EQJ_tstf5FROzY=+8NP9qA@mail.gmail.com>
	<1515508.6rn8zR22J5@sai>
Message-ID: <CAFsNfZLbTihYg_vo8q8AFiB_wjoXLDzRwM_GzsoSzsnS=qN0=g@mail.gmail.com>

On file for years now :)


On Sun, Nov 25, 2012 at 11:48 PM, Lance Corrimal
<Lance.Corrimal at eregion.de>wrote:

> Verified - Now I'm sticking the patch in a test build to see if it breaks
> other stuff.
>
> Do you have CA on file?
>
> bye,
> LC
>
>
> Am Sonntag, 25. November 2012, 23:26:53 schrieb Ricky:
> > Yep - so sneaky it's not been noticed for years. I think it's because
> > no-one actually uses that part of the editors functionality!
> >
> > Leaves me wondering about when the snap functionality was introduced...
> The
> > repository doesn't go back that far! :)
> >
> > On Sunday, November 25, 2012, Darien Caldwell <darien.caldwell at gmail.com
> >
> >
> > wrote:
> > > Ahh, I see what you mean. it's acting as if the hidden snap ring is
> still
> >
> > present.  A sneaky bug. :)
> >
> > > On Sun, Nov 25, 2012 at 10:13 PM, Ricky <kf6kjg at gmail.com> wrote:
> > >> For a missing hyphen... :)  I meant edge-on.
> > >>
> > >> Here's how to reproduce the issue:
> > >> Rez a cube
> > >> Verify that Snap is disabled
> > >> Orient camera to directly face one of the prim faces
> > >> Select rotate mode or hold the correct modifier key(s)
> > >> Using the mouse drag on the rotate circle that is most like a line -
> aka
> >
> > it is "edge-on"
> >
> > >> Observe that as you drag along the line of circle the cube it rotates
> >
> > smoothly (expected)
> >
> > >> Observe that if you drag off the line - as if snapping was enabled and
> >
> > you wished to snap - and then again in the direction of the line that it
> > will snap. (not expected)
> >
> > >> Hope that helps clarify
> > >>
> > >>
> > >> Ps. Sorry for the dup email Darien, I forgot to reply all.
> > >>
> > >> On Sunday, November 25, 2012, Darien Caldwell <
> darien.caldwell at gmail.com>
> >
> > wrote:
> > >> > I'm a little unsure what "Edge on rotation" means. I can rotate a
> prim
> >
> > on every axis in-world with snap off, and it never snaps. At least, not
> > unless I make it snap by engaging the Angle ring outside the circumfrence
> > of the rotation handle. Then it snaps as it should.
> >
> > >> > I hope your patch isn't breaking this functionality, it's intended
> and
> >
> > desirable.
> >
> > >> > On Sun, Nov 25, 2012 at 8:23 PM, Ricky <kf6kjg at gmail.com> wrote:
> > >> >> Just reported BUG-885, "Edge-on prim rotation snaps when snap is
> >
> > disabled"  Patch attached.
> >
> > >> >> Looks like this bug has been in place for a very long time - dates
> >
> > back to revision 0 of the code repository, committed by James Cook (James
> > Linden).
> >
> > >> >> I've been delving back into the source code after a year and a half
> >
> > away.  I have to compliment LL, and all else involved, on the streamlined
> > compile setup - smoother even than the old develop.py system, definitely
> > better than the transition period when I last attempted! :D
> >
> > >> >> I found this bug while I was working on learning/cleaning the code
> >
> > structure in the LLManip* classes in preparation for reviving an old
> > project.  Imagine my surprise when I found that one of the cases didn't
> > have a check for whether Snapping was enabled!  So I took to opportunity
> to
> > delve deeper and work out a fix.  Enjoy!
> >
> > >> >> Ricky
> > >> >> Cron Stardust
> > >> >> PS, for Firestorm I also reported it as FIRE-8338 as that is where
> I
> >
> > originally found the bug - however it exists in every viewer I've looked
> > at.  Based on my research I think it's been in existence since snapping
> was
> > first introduced - whenever that was!
> >
> > >> >> _______________________________________________
> > >> >> Policies and (un)subscribe information available here:
> > >> >> http://wiki.secondlife.com/wiki/OpenSource-Dev
> > >> >> Please read the policies before posting to keep unmoderated posting
> >
> > privileges
> _______________________________________________
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121126/e3090276/attachment.htm 

From kf6kjg at gmail.com  Mon Nov 26 19:58:55 2012
From: kf6kjg at gmail.com (Cron Stardust)
Date: Tue, 27 Nov 2012 03:58:55 -0000
Subject: [opensource-dev] Review Request: Fixed snapping of rotation in the
	edge-on case
Message-ID: <20121127035855.21466.13115@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/608/
-----------------------------------------------------------

Review request for Viewer.


Description
-------

Simply had to guard the snapping code, making sure that the last "else" case was preserved when either the outer or the inner tests failed.

Careful analysis and testing was performed to determine what clauses could/should be inside the guarding if statement, which led to the discovery that the else clause had to be preserved outside under a separate test.  Code structure was carefully designed to match the other llManip* classes in similar areas.


This addresses bug STORM-1919.
    https://jira.secondlife.com/browse/STORM-1919


Diffs
-----

  doc/contributions.txt 9505109727a3e948b11564910fd58ee93503b3df 
  indra/newview/llmaniprotate.cpp 9505109727a3e948b11564910fd58ee93503b3df 

Diff: http://codereview.secondlife.com/r/608/diff/


Testing
-------

Tested all rotation cases (edge-on & facing multiplied with snapping enabled & disabled) in Firestorm - however this area of code has not been modified in either viewer since ancient times and should therefore cause no ill effects.


Thanks,

Cron Stardust

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121127/e3a5a455/attachment.htm 

From kf6kjg at gmail.com  Mon Nov 26 20:09:05 2012
From: kf6kjg at gmail.com (Ricky)
Date: Mon, 26 Nov 2012 20:09:05 -0800
Subject: [opensource-dev] BUG-885/STORM-1919 up for review
Message-ID: <CAFsNfZ+Gpy+2+uao6zJ7+-fitsG8pEC4qZK-e2A4yakjGYeVvg@mail.gmail.com>

Got it readied for review - let me know what you all think.

Issue: https://jira.secondlife.com/browse/STORM-1919
CR: https://codereview.secondlife.com/r/608/
Repo: https://bitbucket.org/kf6kjg/storm-1919

Ricky
Cron Stardust
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121126/d872441c/attachment.htm 

From Lance.Corrimal at eregion.de  Mon Nov 26 23:31:59 2012
From: Lance.Corrimal at eregion.de (Lance Corrimal)
Date: Tue, 27 Nov 2012 07:31:59 -0000
Subject: [opensource-dev] Review Request: Fixed snapping of rotation in
	the edge-on case
In-Reply-To: <20121127035855.21466.13115@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121127035855.21466.13115@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121127073159.21461.99441@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/608/#review1276
-----------------------------------------------------------

Ship it!


I have tested this patch against a beta of my dolphin viewer 3, and it works fine even with deeply modified build tools.

- Lance Corrimal


On Nov. 26, 2012, 7:58 p.m., Cron Stardust wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/608/
> -----------------------------------------------------------
> 
> (Updated Nov. 26, 2012, 7:58 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> -------
> 
> Simply had to guard the snapping code, making sure that the last "else" case was preserved when either the outer or the inner tests failed.
> 
> Careful analysis and testing was performed to determine what clauses could/should be inside the guarding if statement, which led to the discovery that the else clause had to be preserved outside under a separate test.  Code structure was carefully designed to match the other llManip* classes in similar areas.
> 
> 
> This addresses bug STORM-1919.
>     https://jira.secondlife.com/browse/STORM-1919
> 
> 
> Diffs
> -----
> 
>   doc/contributions.txt 9505109727a3e948b11564910fd58ee93503b3df 
>   indra/newview/llmaniprotate.cpp 9505109727a3e948b11564910fd58ee93503b3df 
> 
> Diff: http://codereview.secondlife.com/r/608/diff/
> 
> 
> Testing
> -------
> 
> Tested all rotation cases (edge-on & facing multiplied with snapping enabled & disabled) in Firestorm - however this area of code has not been modified in either viewer since ancient times and should therefore cause no ill effects.
> 
> 
> Thanks,
> 
> Cron Stardust
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121127/6663ad33/attachment.htm 

From oz at lindenlab.com  Tue Nov 27 08:11:54 2012
From: oz at lindenlab.com (Oz Linden)
Date: Tue, 27 Nov 2012 16:11:54 -0000
Subject: [opensource-dev] Review Request: Fixed snapping of rotation in
	the edge-on case
In-Reply-To: <20121127035855.21466.13115@domU-12-31-38-00-90-68.compute-1.internal>
References: <20121127035855.21466.13115@domU-12-31-38-00-90-68.compute-1.internal>
Message-ID: <20121127161154.23753.75924@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/608/#review1277
-----------------------------------------------------------

Ship it!


Ship It!

- Oz Linden


On Nov. 26, 2012, 7:58 p.m., Cron Stardust wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/608/
> -----------------------------------------------------------
> 
> (Updated Nov. 26, 2012, 7:58 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Description
> -------
> 
> Simply had to guard the snapping code, making sure that the last "else" case was preserved when either the outer or the inner tests failed.
> 
> Careful analysis and testing was performed to determine what clauses could/should be inside the guarding if statement, which led to the discovery that the else clause had to be preserved outside under a separate test.  Code structure was carefully designed to match the other llManip* classes in similar areas.
> 
> 
> This addresses bug STORM-1919.
>     https://jira.secondlife.com/browse/STORM-1919
> 
> 
> Diffs
> -----
> 
>   doc/contributions.txt 9505109727a3e948b11564910fd58ee93503b3df 
>   indra/newview/llmaniprotate.cpp 9505109727a3e948b11564910fd58ee93503b3df 
> 
> Diff: http://codereview.secondlife.com/r/608/diff/
> 
> 
> Testing
> -------
> 
> Tested all rotation cases (edge-on & facing multiplied with snapping enabled & disabled) in Firestorm - however this area of code has not been modified in either viewer since ancient times and should therefore cause no ill effects.
> 
> 
> Thanks,
> 
> Cron Stardust
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121127/d12f4401/attachment.htm 

From nickyperian at yahoo.com  Tue Nov 27 16:35:24 2012
From: nickyperian at yahoo.com (Nicky Perian)
Date: Tue, 27 Nov 2012 16:35:24 -0800 (PST)
Subject: [opensource-dev] Crash reporting
Message-ID: <1354062924.10399.YahooMailNeo@web126103.mail.ne1.yahoo.com>

How is crash reporting set to on? ?Though command line -D or through a mod to 00-Common.cmake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121127/80ad1a2d/attachment.htm 

From log at lindenlab.com  Fri Nov 30 17:17:45 2012
From: log at lindenlab.com (Log Linden)
Date: Sat, 01 Dec 2012 01:17:45 -0000
Subject: [opensource-dev] Review Request: Fix for STORM-1854.
Message-ID: <20121201011745.21465.67942@domU-12-31-38-00-90-68.compute-1.internal>


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://codereview.secondlife.com/r/609/
-----------------------------------------------------------

Review request for Viewer.


Description
-------

This is a fix for STORM-1854. It prevents an assert failure that happens during viewer startup on linux systems with a sufficiently new version of the fontconfig library (I think fontconfig 1.9). It should not impact mac or windows because those platforms do not use llwindowsdl.cpp file, which was the only file changed.


This addresses bug STORM-1854.
    http://jira.secondlife.com/browse/STORM-1854


Diffs
-----

  indra/llwindow/llwindowsdl.cpp UNKNOWN 

Diff: http://codereview.secondlife.com/r/609/diff/


Testing
-------

This change builds successfully on all three platforms (Teamcity). I have verified that the startup error no longer occurs on Ubuntu 12.10. Ideally we would test that Linux systems with older versions of fontconfig can also still start the viewer, but I don't have easy access to one of those. 


Thanks,

Log Linden

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20121201/8f250d6b/attachment.htm