Re: [opensource-dev] Intra-sim teleports and Local Chat History

[Opensource Obscure]

On Sun, Mar 27, 2011 at 18:46, Opensource Obscure
 wrote:
> Which is the expected behaviour for intra-sim teleports
> and Local Chat History? should these teleports show up,
> like when you teleport to a different region?
>
> They currently don't, but they're correctly recorded in the
> Teleport History in Sidebar.
>
> This is why I waited before closing
> https://jira.secondlife.com/browse/VWR-15259 as Released.
>
> Note that it was filed against viewer 1.23, which lacked
> sidebar, so chat history was the only place where teleports
> could show up.
> Still, the behaviour is different for intra-sim and extra-sim
> teleports so I'd like to know if this is by design.

Should I ask this question somewhere else? Where?

-- 
Opensource Obscure
http://twitter.com/oobscure - http://opensourceobscure.com/lol
___
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

Re: [opensource-dev] Intra-sim teleports and Local Chat History

[Tateru Nino]

On 7/04/2011 6:09 PM, Opensource Obscure wrote:
> On Sun, Mar 27, 2011 at 18:46, Opensource Obscure
>  wrote:
>> Which is the expected behaviour for intra-sim teleports
>> and Local Chat History? should these teleports show up,
>> like when you teleport to a different region?
>>
>> They currently don't, but they're correctly recorded in the
>> Teleport History in Sidebar.
>>
>> This is why I waited before closing
>> https://jira.secondlife.com/browse/VWR-15259 as Released.
>>
>> Note that it was filed against viewer 1.23, which lacked
>> sidebar, so chat history was the only place where teleports
>> could show up.
>> Still, the behaviour is different for intra-sim and extra-sim
>> teleports so I'd like to know if this is by design.
> Should I ask this question somewhere else? Where?
>
It seems like an appropriate venue to me. I get the feeling that the
non-orthogonality of it is something of an oversight - that intrasim
teleports follow a different code-path (which is to be expected, I
suppose), but that the asymmetry is the result of key code only being
added to the extra-sim teleport code-path.

-- 
Tateru Nino
http://dwellonit.taterunino.net/

___
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

Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

[Ima Mechanique]

> Linden Lab should not be distributing either of these libraries, as
> they do not have a license that permits them to do so(from what I have
> heard from them in other dialogs). So this violates and possibly voids
> their license for Kakadu, as well as all of their careful planning to
> keep it out of every developers hands except for their own.
> 
> I hope that they will take these down, and it is not an error that you
> should NOT be able to download them. The error here is that they are
> trying to be downloaded at all.

This is something of a grey area. 
For KDU, this is not distributing per se, as it is only the headers and
lib file to link against, not the final library being made available.
I'm not privy to the license details so have no idea if this would be a
breach of terms..

For FMOD, things are clearer.

"The contents of the FMOD distribution archive may not be redistributed, 
reproduced, modified, transmitted, broadcast, published or adapted in any 
way, shape or form, without the prior written consent of the owner, 
Firelight Technologies, be it by tangible or non tangible media.

The fmod.dll file may be redistributed without the authors prior permission, 
and must remain unmodified."

LL have both modified the archive (by creating a new one) and are
redistributing that modified version, so I hope they have obtained
written permission from Firelight Technologies  I'd hope that FT would
be happy to grant permission, as it relieves their servers of the
download bandwidth required.


> On Wed, Apr 6, 2011 at 23:34, Glimmering Sands
>  wrote:
> > Well, I have discovered, through the wonders of Mr. Google, that there
> > is an older copy autobuild.xml out there at:
> >
> > https://bitbucket.org/merov_linden/viewer-autobuild2010/src/44f214103cff/autobuild.xml
> >
> > and I was able to simply use the
> >
> > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/...
> >
> > lines for both fmod and kdu (would it be considered a bug that Linden
> > Labs is distributing an autobuild.xml that uses internal only paths
> > rather than using the external paths (that I guessed the used to
> > have?)
> >
> > One can also wonder why you would let internal DNS records be allowed
> > to external sites as well...
> >
> > Sometime later I will discover if this solves my grey goo box problem or 
> > not :-)
> >
> > Hugs,
> >
> > Glimmering


--
Ima Mechanique
ima.mechanique(at)blueyonder.co.uk

___
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

Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

[WolfPup Lowenhar]

Ok I see two things here Glimmering Sands:

1.  You are using an old repository the current one is actually viewer
development as autobuild has been merged in.

2.  FMOD and KDU are actually somewhere in http://s3-proxy.lindenlab.com
of which we as Open Source Developers have NO access to and are NOT allowed
to have access to.

 

Ima Mecanique,

The FMOD and KDU libs are not distributed externally if you look at a
current copy of the autobuild.xml you will find that the address is a
private one for them and a few others LL cannot freely distribute. Now LL
has 'provided' a way for those that have FMOD already to 're-pacakage' this
one for use in the autobuild. LL dose not actually modify any of the FMOD
files but actually creates a 'wraper' in the form of llaudio to interface
with fmod.dll so that those that are on Windows will have working sound.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ima
Mechanique
Sent: Thursday, April 07, 2011 7:03 AM
To: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP
address?

 

> Linden Lab should not be distributing either of these libraries, as
> they do not have a license that permits them to do so(from what I have
> heard from them in other dialogs). So this violates and possibly voids
> their license for Kakadu, as well as all of their careful planning to
> keep it out of every developers hands except for their own.
>
> I hope that they will take these down, and it is not an error that you
> should NOT be able to download them. The error here is that they are
> trying to be downloaded at all.

This is something of a grey area.
For KDU, this is not distributing per se, as it is only the headers and
lib file to link against, not the final library being made available.
I'm not privy to the license details so have no idea if this would be a
breach of terms..

For FMOD, things are clearer.

"The contents of the FMOD distribution archive may not be redistributed,
reproduced, modified, transmitted, broadcast, published or adapted in any
way, shape or form, without the prior written consent of the owner,
Firelight Technologies, be it by tangible or non tangible media.

The fmod.dll file may be redistributed without the authors prior permission,
and must remain unmodified."

LL have both modified the archive (by creating a new one) and are
redistributing that modified version, so I hope they have obtained
written permission from Firelight Technologies  I'd hope that FT would
be happy to grant permission, as it relieves their servers of the
download bandwidth required.


> On Wed, Apr 6, 2011 at 23:34, Glimmering Sands
>  wrote:
> > Well, I have discovered, through the wonders of Mr. Google, that there
> > is an older copy autobuild.xml out there at:
> >
> >
https://bitbucket.org/merov_linden/viewer-autobuild2010/src/44f214103cff/aut
obuild.xml
> >
> > and I was able to simply use the
> >
> > http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/...
> >
> > lines for both fmod and kdu (would it be considered a bug that Linden
> > Labs is distributing an autobuild.xml that uses internal only paths
> > rather than using the external paths (that I guessed the used to
> > have?)
> >
> > One can also wonder why you would let internal DNS records be allowed
> > to external sites as well...
> >
> > Sometime later I will discover if this solves my grey goo box problem or
not :-)
> >
> > Hugs,
> >
> > Glimmering


--
Ima Mechanique
ima.mechanique(at)blueyonder.co.uk

___
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 

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1209 / Virus Database: 1500/3556 - Release Date: 04/06/11

___
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

[opensource-dev] request for double-check about "Releases / Fixed" status

[Opensource Obscure]

I see a couple of issues where the issue status may
have improperly been set to "Releases / Fixed":

https://jira.secondlife.com/browse/WEB-3795
https://jira.secondlife.com/browse/SH-1295

-- 
Opensource Obscure
http://twitter.com/oobscure - http://opensourceobscure.com/lol
___
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

Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP address?

[Glimmering Sands]

Curious assertions you make, WolfPup Lowenhar.  So, I wonder, what
would be a more up to date repository than the one retrieved from by:

hg clone http://hg.secondlife.com/viewer-development

Which is precisely where I retrieved the repository that I used just a
few days previous.  I also followed the instructions on the public
wiki for how to use autobuild.  Perhaps it is naive to assume that as
it is documented, published, and available, that it might actually be
of use (in particular since it appears the older documentation of how
to work with fmod is gone).

The autobuild reveals three problems.  The first is that it attempts
to retrieve files from s3-proxy.lindenlab.com which resolves to a
non-routable IP address.  The second is that linden labs would allow
internal IP addresses to leak to the outside.  The third is that the
documentation on how to build the viewer gives no indication of what
do do about the situation.

Perhaps you misunderstood that I repaired the two lines of the
autobuild.xml file such that the autobuild will work.  I did so with
the help of Mr. Google who pointed out an older autobuild.xml that
referenced an alternate location of the two particular files in
question using a globally routable address.  If you are concerned that
this solution resulted in out dated copies of said files, please do
not be stressed as they appear to be the same ones referenced by the
new "broken for everyone but lindens" autobuild.xml file as the
checksums match.  So, contrary to your assertion, you do have access
to the said files if you care to repair your autobuild.xml, the issue
presented that linden labs should not have placed said files there not
withstanding.

My task was a simple one, to simply build a current viewer without
grey goo by using the publicly available instructions.  Of course,
building the SL viewer is never that easy.  Fortunately this time the
task was accomplished with only having to modify two lines in one
file.

Hugs,

Glimmering

On Thu, Apr 7, 2011 at 4:45 AM, WolfPup Lowenhar
 wrote:
> Ok I see two things here Glimmering Sands:
>
> 1.  You are using an old repository the current one is actually viewer
> development as autobuild has been merged in.
>
> 2.  FMOD and KDU are actually somewhere in http://s3-proxy.lindenlab.com
> of which we as Open Source Developers have NO access to and are NOT allowed
> to have access to.
>
>
>
> Ima Mecanique,
>
> The FMOD and KDU libs are not distributed externally if you look at a
> current copy of the autobuild.xml you will find that the address is a
> private one for them and a few others LL cannot freely distribute. Now LL
> has ‘provided’ a way for those that have FMOD already to ‘re-pacakage’ this
> one for use in the autobuild. LL dose not actually modify any of the FMOD
> files but actually creates a ‘wraper’ in the form of llaudio to interface
> with fmod.dll so that those that are on Windows will have working sound.
>
>
>
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Ima
> Mechanique
> Sent: Thursday, April 07, 2011 7:03 AM
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] s3-proxy.lindenlab.com points to a private IP
> address?
>
>
>
>> Linden Lab should not be distributing either of these libraries, as
>> they do not have a license that permits them to do so(from what I have
>> heard from them in other dialogs). So this violates and possibly voids
>> their license for Kakadu, as well as all of their careful planning to
>> keep it out of every developers hands except for their own.
>>
>> I hope that they will take these down, and it is not an error that you
>> should NOT be able to download them. The error here is that they are
>> trying to be downloaded at all.
>
> This is something of a grey area.
> For KDU, this is not distributing per se, as it is only the headers and
> lib file to link against, not the final library being made available.
> I'm not privy to the license details so have no idea if this would be a
> breach of terms..
>
> For FMOD, things are clearer.
>
> "The contents of the FMOD distribution archive may not be redistributed,
> reproduced, modified, transmitted, broadcast, published or adapted in any
> way, shape or form, without the prior written consent of the owner,
> Firelight Technologies, be it by tangible or non tangible media.
>
> The fmod.dll file may be redistributed without the authors prior permission,
> and must remain unmodified."
>
> LL have both modified the archive (by creating a new one) and are
> redistributing that modified version, so I hope they have obtained
> written permission from Firelight Technologies  I'd hope that FT would
> be happy to grant permission, as it relieves their servers of the
> download bandwidth required.
>
>
>> On Wed, Apr 6, 2011 at 23:34, Glimmering Sands
>>  wrote:
>> > Well, I have discovered, through the wonders of Mr. Google, that there
>> > is an older

Re: [opensource-dev] UI produces just grey boxes

[Glimmering Sands]

Thank you, Boroondas.  First, the grand news, once autobuild.xml was
repaired I was able to build a functioning viewer!  Hurray!

I actually have been using Mercurial to retrieve the source tree for
some long time, however, when I pulled news sources several months
previous it led to the aforementioned situation.  The major change,
aside from using an alternate account, was to use autobuild to produce
the Xcode project from whence I conducted my final build.  Perhaps
time will be found in which I can examine the differences between the
old and the new to determine where things run afoul, but for the
moment it is happiness to simply have a method to banish the grey goo
from my display :-)

Hugs,

Glimmering

On Wed, Apr 6, 2011 at 12:31 AM, Boroondas Gupte
 wrote:
> On 04/06/2011 04:57 AM, Glimmering Sands wrote:
>> Thank you, I will try from a freshly made account.  The hint that it
>> is possibly the artwork bundle will hopefully help much.
> Note that since the move to mercurial, the artwork is included in the
> source tree (most of it in indra/newview/skins/*/textures/) so there
> isn't any artwork bundle anymore.
>
> Cheers,
> Boroondas
>
___
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

[opensource-dev] In-world groups

[Opensource Obscure]

What are currently the best in-world groups where to
discuss viewer issues, announce new JIRA entries or updates,
raise awareness about current bugs and such?

I'd welcome both official and unofficial groups.

I'm currently member of a number of official and unofficial
in-world groups which relate to viewer issues, but none of
them seems to be active / receptive. I'd want to be sure
I'm not missing the right groups.

-- 
Opensource Obscure
http://twitter.com/oobscure - http://opensourceobscure.com/lol
___
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

Re: [opensource-dev] request for double-check about "Releases / Fixed" status

[Yoz Grahame]

On 7 April 2011 04:52, Opensource Obscure wrote:

> I see a couple of issues where the issue status may
> have improperly been set to "Releases / Fixed":
>
> https://jira.secondlife.com/browse/WEB-3795
>  


Fixed by Brooke


> https://jira.secondlife.com/browse/SH-1295
>

The fix is done but not in a release viewer yet, so I've moved this back to
In Progress (since SH doesn't have "Fix Pending" in its workflow.)

Thanks for highlighting these, OO!

-- Yoz
___
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

Re: [opensource-dev] Windows compiling problem

[Monty Brandenberg]

On 4/6/2011 11:46 AM, Monty Brandenberg wrote:

> Confirmed (I get it myself). Probably has to do with sensitivity to
> the SDKs installed on the system. The offending include order,
> in reverse order, is:
>
> "C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\objid
> l.h"
> "C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\obj
> base.h"
> "C:\\Program Files (x86)\\Microsoft SDKs\\Windows\\v7.0A\\include\\ole2.h"
> "c:\\mcb\\hg\\viewer-development\\indra\\llwindow\\lldragdropwin32.h"

So I cleared this and the remainder of my problems by:

   -  Updating autobuild from bitbucket.

   -  Installing the 7.0A Windows SDK from MSDN on top of (or instead
  of, presumably) the 7.0A Windows SDK on the VS2010 DVD.

   -  Updated DirectX to June '10 (was still using August '08 based on
  old internal setup).

   -  Install UNSIS to clear error that looks like a path problem when
  we package.


___
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

[opensource-dev] How to handle JsonCpp's headers on STANDALONE?

[Boroondas Gupte]

Hi all

As you might have noticed, the prebuilt package for JsonCpp has changed
its path for headers to be included by applications from
*include/jsoncpp/* to *include/json/* some time ago. (Probably to better
match the upstream directory name
?)
The include search path for non-standalone was adapted accordingly
.
(Actually, it'll now search both places.) At the same time, the #include
for the one JsonCpp header we use, *reader.h*, was changed

to only the filename. (Before that, it had "jsoncpp/" prepended.)

So now the question is how to get this to work on STANDALONE. Currently,
during configuration, CMake will search for *jsoncpp/json.h*

in */usr/local/include/* and */usr/include/*
.
The first of those paths to contain the file jsoncpp/json.h will be
added as include search path, and thus searched by the compiler during
build for ... well, just "*reader.h*", which won't be there (it'd be one
level lower in the tree). The straight forward thing to do would be to
have CMake search for just *json.h* (in /usr/local/include/*json/* and
/usr/include/*json/*) during configuration, so that reader.h would later
be found when building.

However, if you have an unaltered JsonCpp installed so that json.h
resides at one of those paths, making that path an include search dir
has a nasty side effect, because in the same directory
,
there's a file named features.h. That filename collides with that of a
standard system header

which is included (indirectly) elsewhere in the viewer code. However,
with the .../*json* dir in the include search path, JsonCpp's features.h
will be included at those other places, too, which leads to essential
macros not being defined. (The prebuilt package avoids this by having
the header renamed
.)

We probably don't want to go rename system-installed headers, so we have
to change the #include line back to including the parent dir of json.h
as a namespacing measure. If there are no plans to use old JsonCpp
prebuilt packages (where that parent dir is called jsoncpp instead of
json), that line can be the same for non-standalone and standalone, I
guess. Otherwise, we can do some #if(STANDALONE)...#else...-thing so
that non-standalone can keep including from both paths.

Now my question is, is the name of the parent dir the same on all Linux
distributions that have a JsonCpp package? The ebuild from Techwolf's
gentoo linux portage overlay places the headers in
/usr/include/jsoncpp/, but I guess that was done just the accommodate
the Viewer build back then and could be easily changed to
/usr/include/json/.

So if you are on another Linux distribution (and especially if you do or
want to build in STANDALONE mode), I'd like to know:

   1. Is a JsonCpp package available for your distribution?
  If yes:
   2. Does it come from an official, semi-official or non-official
  package repository? (Or even just a manual download?)
   3. Does it install a features.h header? If so, where?
   4. Where does it install json.h and reader.h?

Cheers,
Boroondas
___
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

Re: [opensource-dev] How to handle JsonCpp's headers on STANDALONE?

[Robin Cornelius]

On Thu, Apr 7, 2011 at 8:25 PM, Boroondas Gupte
 wrote:

> Is a JsonCpp package available for your distribution?
> If yes:
> Does it come from an official, semi-official or non-official package
> repository? (Or even just a manual download?)
> Does it install a features.h header? If so, where?
> Where does it install json.h and reader.h?

There still is not as far as i know any offical jsoncpp package for
debian or ubuntu (there is a debug bug request for one #617325) but to
date i believe a lot of standalone debian/ubuntu users have been using
my package on apt.byteme.org.uk. As i'm packaging and the main purpose
for my package is viewer building its easy for me to update/change if
this is the best thing to do, but i want to keep this ideally close to
upstream as possible. If we need to start patching the (jsoncpp)
package to make the viewer play nice (and for no other good reasons),
it will never be an acceptable solution to get this included in debian
and all i will end up doing is patching the viewer on debian builds.

As for your question the dev package lay out is as follows :-

drwxr-xr-x root/root 0 2010-05-10 14:43 ./
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/share/
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/share/doc/
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/share/doc/libjsoncpp-dev/
-rw-r--r-- root/root   149 2009-09-22 21:00
./usr/share/doc/libjsoncpp-dev/copyright
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/lib/
-rw-r--r-- root/root575366 2010-05-10 14:43 ./usr/lib/libjson.a
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/include/
drwxr-xr-x root/root 0 2010-05-10 14:43 ./usr/include/jsoncpp/
-rw-r--r-- root/root 33577 2010-05-10 14:43 ./usr/include/jsoncpp/value.h
-rw-r--r-- root/root  1389 2010-05-10 14:43 ./usr/include/jsoncpp/config.h
-rw-r--r-- root/root   617 2010-05-10 14:43 ./usr/include/jsoncpp/forwards.h
-rw-r--r-- root/root  5765 2010-05-10 14:43 ./usr/include/jsoncpp/reader.h
-rw-r--r-- root/root  6202 2010-05-10 14:43 ./usr/include/jsoncpp/writer.h
-rw-r--r-- root/root   438 2010-05-10 14:43 ./usr/include/jsoncpp/autolink.h
-rw-r--r-- root/root   177 2010-05-10 14:43 ./usr/include/jsoncpp/json.h
lrwxrwxrwx root/root 0 2010-05-10 14:43 ./usr/lib/libjson.so
-> libjson.so.0

Robin
___
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

Re: [opensource-dev] Review Request: (STORM-941) IM log naming should go by SL name, not DN.

[Seth ProductEngine]

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

(Updated April 7, 2011, 4:16 p.m.)


Review request for Viewer.


Changes
---

Fixed resolving IM session participants names prior to writing messages to the 
log file to avoid temporary log files which could possibly appear if user names 
were not resolved before the first message had been written to the log.


Summary
---

Fixed IM history to use the resident's user name for the log file name.
Added conversions from legacy names or SLURLs with avatar id to the user names 
in cases of logging P2P sessions and inventory offers.


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


Diffs (updated)
-

  indra/newview/llgiveinventory.cpp d30636c2a83a 
  indra/newview/llimview.h d30636c2a83a 
  indra/newview/llimview.cpp d30636c2a83a 
  indra/newview/llnotificationhandler.h d30636c2a83a 
  indra/newview/llnotificationhandlerutil.cpp d30636c2a83a 

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


Testing
---


Thanks,

Seth

___
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

[opensource-dev] Review Request: STORM-1118 Viewer crashes when user tries to upload image without JFIF header

[Vadim ProductEngine]

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

Review request for Viewer.


Summary
---

* Added checks for image file contents not matching the file extension (e.g. a 
bitmap named file.jpg).
* Added checks for abnormally short files to avoid crashes when parsing them.


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


Diffs
-

  indra/llimage/llimagedimensionsinfo.h 33ca961b0870 
  indra/llimage/llimagedimensionsinfo.cpp 33ca961b0870 

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


Testing
---


Thanks,

Vadim

___
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

[opensource-dev] Review Request: KDU Improvements: Compress j2c with precincts

[Merov Linden]

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

Review request for Viewer.


Summary
---

This patch adds code to j2c to:
- compress images with the use of precincts and blocks
- use different ordering (RPCL) and markers in the codestream
- allow loading of images with region constraint

All this code can be exercised with a new set of arguments using 
llimage_libtest. For the moment, the viewer is still saving images with the old 
precinct and ordering. 

Things done in this patch:
- Add arguments to llimage_libtest:
-- on j2c output : --precincts, --blocks
-- on j2c input : --region, --discard_level
- Add InitEncode() and InitDecode() methods to llimagej2c (and derived classes) 
to implement new input and output parameters
- Fix perf analyzing report output in llimage_libtest (was broken)
- General llkdu code clean up: fixed all tab/white space issues, suppress code 
that was unused, enforced coding conventions, use proper Kakadu method to get 
its version number


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


Diffs
-

  indra/integration_tests/llimage_libtest/llimage_libtest.cpp d30636c2a83a 
  indra/llimage/llimagej2c.h d30636c2a83a 
  indra/llimage/llimagej2c.cpp d30636c2a83a 
  indra/llimagej2coj/llimagej2coj.h d30636c2a83a 
  indra/llimagej2coj/llimagej2coj.cpp d30636c2a83a 
  indra/llkdu/llimagej2ckdu.h d30636c2a83a 
  indra/llkdu/llimagej2ckdu.cpp d30636c2a83a 
  indra/llkdu/llkdumem.h d30636c2a83a 
  indra/llkdu/llkdumem.cpp d30636c2a83a 

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


Testing
---

Tested only on Mac. All the precincts code can be exercised through 
llimage_libtest (see ./llimage_libtest --help for details on the new arguments)

None of the precincts/blocks creation is used in the viewer though, since 
viewer code is modified, it would be good to test texture downloading, 
uploading, j2c creation (snapshots and uploads) and all kind of texture loading 
(sculpties, with and without alphas, small textures, big ones, etc...)


Thanks,

Merov

___
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

[opensource-dev] Daily Scrum Summary - Thursday, April 7

[Anya Kanevsky]

Sprint 13, ends 04.11.11 Thursday, April 7 General Notes
--

   - MMOTD: Oz

Team Status
--
 Merov Linden
--

*PAST*

   - Attended VWR Triage meeting
   - STORM-746 : Use KDU precincts : Ran lots of tests. So far, the use of
   precincts has very little impact on the decompression performance when
   measured on local files. I was expecting some gain when loading partial
   images (since precincts outside the regions are supposedly not decoded) but
   that doesn't translate in any significant performance gain. Wondering if I'm
   measuring the right thing...
   - STORM-610 : Environment Editor, persistent water color : Fixed "milky
   water" problem. Posted an RB. Moved to In Review.

*FUTURE*

   - STORM-746 : Use KDU precincts : Triple check my measurements and post
   test results. Post changes to RB for that JIRA and move to review.

*IMPEDIMENTS*

   - OOO tomorrow (Friday)


Oz Linden
--


Wolf Linden
--

*PAST*

   - Met with Oz, Vadim, Grumpity
  - Storm-1092, Storm-2, Storm-1077

*FUTURE*

   - Other projects

*IMPEDIMENTS*

   - Created a new issue for Storm-1077, but since the was no Sprint 14 yet,
   I just assigned it to myself; will update today

Grumpity ProductEngine
--

*PAST*

   - met with wolf on STORM-2 etc
   - can't close old sprints in jira b/c QA can't verify issues.

*FUTURE*

   - scehdule time with Bambers to resolve old issues
   - QA roundup
   - STORM triage
   - VWR-20826, VWR-303
   - VWR triage process
   - create TOOL issues for requested jira changes
   - Sprint retrospective prep

*IMPEDIMENTS*

   - need a new PO build

Paul ProductEngine
--

*PAST*

   - BUG STORM-595 (Viewer should stop spamming AgentThrottle messages as
   the slider is dragged)
  - WIP. Today will finish it and send for review.
   - Finished with aoutobuild

*FUTURE*

   - BUG STORM-595 (Viewer should stop spamming AgentThrottle messages as
   the slider is dragged)

*IMPEDIMENTS*

   - none

Seth ProductEngine
--

*PAST*

   - BUG (STORM-941) IM log naming should go by SL name, not DN.
  - Working on changes in IM chat logging.
   - BUG (STORM-1071) Switching language in preferences creates new calling
   cards folders for each language
   - BUG (STORM-1065) Shared calling card is placed into Friends/All folder
  - Checked the debug settings suggested by Stone, looks like it doesn't
  affect both issues.
   - Helped Paul with autobuild on windows.

*FUTURE*

   - BUG (STORM-1042) Disabled 'Save' button at the 'Create Landmark' panel
   - BUG (STORM-) Blocks of chat log are being read in from then
   rewritten with new timestamps.

*IMPEDIMENTS*

   - BUG (STORM-1071) Switching language in preferences creates new calling
   cards folders for each language

Vadim ProductEngine
--

*PAST*

   - Filed a couple of known WLES issues.
   - Bug STORM-1139 ("Apply Changes to Region" works for water but not for
   sky):
  - Investigated, commented in the ticket.
   - Bug STORM-1142 ("Use Estate Time" and "Use Local Time" buttons in the
   Environment Editor don't work):
  - Fixed.
   - Meetings.

*FUTURE*

   - Bug STORM-1118 (Viewer crashes when user tries to upload image without
   JFIF header).
   - STORM-1126 (Windlight Region Settings):
  - Fixing related bugs.

*IMPEDIMENTS*

   - none

Andrey ProductEngine
--

*PAST*

   - passed smoke tests for 2.6.3 Beta1
   - failed integrity test on Win7 by VWR-25444
  - looks like Win7 64-bit isn't officially supported, but 2.6.1 Release
  tested one day before worked fine
   - verified changes in scope of IQA-122, see tracking spreadsheet for more
   details
   - started testing of Avatar Physics in scope of IQA-124
  - reported VWR-25445, VWR-25447, VWR-25450

*FUTURE*

   - finish with IQA-124 stuff
   - process STORM/VWR issues assigned by Bao

*IMPEDIMENTS*

   - none

Wolfpup Lowenhar
--

*PAST*

   - Working inworld(this is part of testing locally built viewers).
   - STORM-1098 : Waiting for review approvals.

*FUTURE*

   - Working inworld (this is part of testing locally built viewers).

*IMPEDIMENTS*

   - Getting Autobuild system and security software to play nicely on my
   system.
   - May need to upgrade personal system(CPU, System Board, and Memory) to
   work better with autobuild system

Past
___
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