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

[Celierra Darling]

Ah, for some reason USE_KDU was already true, which caused cmake to keep
hallucinating that it needed KDU (regardless of whether the KDU package
existed in autobuild).  With -DUSE_KDU=FALSE on the command line, I ended up
not needing to touch the autobuild xml files:

autobuild configure -- -DFMOD:BOOL=FALSE -DINSTALL_PROPRIETARY:BOOL=FALSE
-DUSE_KDU:BOOL=FALSE

(Since cmake/LLKDU.cmake sets USE_KDU to true when INSTALL_PROPRIETARY is
true, maybe it should also explicitly falsify USE_KDU when
INSTALL_PROPRIETARY is set to be false?)

With Visual Studio 2010, you also apparently have to run the IDE at least
once prior to configuring, or else the background Visual Studio instance
that it spawns ends up crashing out.

Celi

On Sun, Apr 10, 2011 at 7:11 AM, Oz Linden (Scott Lawrence) <
o...@lindenlab.com> wrote:

>  On 2011-04-09 22:57, Celierra Darling wrote:
>
> Hmm, this didn't work for me; autobuild still attempts to download kdu even
> if I specify DINSTALL_PROPRIETARY.  (If it helps, the same thing happens if
> I use autobuild configure -c OpenSourceRelWithDebInfo , though I don't
> have to specify DFMOD there.)
>
>
> Sorry - I wasn't clear.
>
> To prevent the attempt to download, you have to take the installable out of
> the autobuild configuration.  The cmake variable only prevents trying to use
> it.
>
>
___
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.

[Vadim ProductEngine]

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



indra/newview/llimview.cpp


This looks even worse than the original fix: AFAIU, until the name is 
resolved, IMs won't be saved at all.


- Vadim


On April 7, 2011, 4:16 p.m., Seth ProductEngine wrote:
> 
> ---
> 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.
> 
> 
> 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
> -
> 
>   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

Re: [opensource-dev] Review Request: (STORM-1042) Disabled 'Save' button at the 'Create Landmark' panel

[Seth ProductEngine]

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

(Updated April 11, 2011, 9:27 a.m.)


Review request for Viewer.


Summary (updated)
---

Fixed the inventory observers of newly added items.

The problem was caused by an outdated message name stored in 
LLInventoryObserver::mMessageName and not updated properly in 
LLInventoryModel::notifyObservers(). 
The message name used in LLInventoryAddedObserver::changed() was the name of 
the message most recently passed by LLInventoryModel::notifyObservers(), 
instead of the name of the latest actually received message. Using the most 
recent message name in this case fixed the problem.


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


Diffs
-

  indra/newview/llinventorymodel.h d30636c2a83a 
  indra/newview/llinventorymodel.cpp d30636c2a83a 
  indra/newview/llinventorymodelbackgroundfetch.cpp d30636c2a83a 
  indra/newview/llinventoryobserver.h d30636c2a83a 
  indra/newview/llinventoryobserver.cpp d30636c2a83a 

Diff: http://codereview.secondlife.com/r/261/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

Re: [opensource-dev] Review Request: (STORM-1042) Disabled 'Save' button at the 'Create Landmark' panel

[Vadim ProductEngine]

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

Ship it!


- Vadim


On April 11, 2011, 9:27 a.m., Seth ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/261/
> ---
> 
> (Updated April 11, 2011, 9:27 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Fixed the inventory observers of newly added items.
> 
> The problem was caused by an outdated message name stored in 
> LLInventoryObserver::mMessageName and not updated properly in 
> LLInventoryModel::notifyObservers(). 
> The message name used in LLInventoryAddedObserver::changed() was the name of 
> the message most recently passed by LLInventoryModel::notifyObservers(), 
> instead of the name of the latest actually received message. Using the most 
> recent message name in this case fixed the problem.
> 
> 
> This addresses bug STORM-1042.
> http://jira.secondlife.com/browse/STORM-1042
> 
> 
> Diffs
> -
> 
>   indra/newview/llinventorymodel.h d30636c2a83a 
>   indra/newview/llinventorymodel.cpp d30636c2a83a 
>   indra/newview/llinventorymodelbackgroundfetch.cpp d30636c2a83a 
>   indra/newview/llinventoryobserver.h d30636c2a83a 
>   indra/newview/llinventoryobserver.cpp d30636c2a83a 
> 
> Diff: http://codereview.secondlife.com/r/261/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

Re: [opensource-dev] C++ Need help to resolve stdint.h typedef conflicts between Quicktime and VS2010

[Nicky Perian]

Kiptic,

Over this past weekend while working with Ardy Lay I found that my advice to 
uninstall Quicktime SDK was wrong. When uninstalled the system builds a stub 
quicktime_plugin.dll that fails in world when the plugin is invoked.. The 
quicktime from here 
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/quicktime-7.3-windows-20110127.tar.bz2
 works. But it doesn't download automatically for any Opensource 
configurations.It has a modified stdint.h. I assume this was a vs2010 make work 
mod by linden developers. I have not diffed the entire include yet and there 
may 
be other modified headers. At one time earlier in autobuild I think this was 
delivered and of course solved the problem of not having a separate quicktime 
SDK for each open source developer.

I work on imprudence also and have the Quicktime SDK installed. I have modified 
headers to make it compile a good plug in when working autobuild 
viewer-development and then return to the original headers when working 
imprudence. This is not ideal but, works.

http://dl.dropbox.com/u/7833186/CGBaseab.h
The ab stands for autobuild and is appended for identification. This replaces 
C:\Program Files (x86)\QuickTime SDK\CIncludes\CGBase.h

http://dl.dropbox.com/u/7833186/stdintab.h
This replaces C:\Program Files (x86)\QuickTime 
SDK\CIncludes\GNUCompatibility\stdint.h

   


Sorry for the confusion,

Nicky




From: Nicky Perian 
To: Kiptic ‌ ; opensource-dev@lists.secondlife.com
Sent: Tue, April 5, 2011 4:21:46 PM
Subject: Re: [opensource-dev] C++ Need help to resolve stdint.h typedef 
conflicts between Quicktime and VS2010


If you are going to stick with vs2010 and not look back the easy solution is 
uninstall the Quicktime SDK and let autobuild deliver the the required items to 
build in package. If you still need to build 1.x or 2.x with develop.py there a 
some include guards that can be used for autobuild and then rename to original 
headers to for develop.py builds.






From: Kiptic ‌ 
To: opensource-dev@lists.secondlife.com
Sent: Tue, April 5,  2011 4:12:00 PM
Subject: Re: [opensource-dev] C++ Need help to resolve stdint.h typedef 
conflicts between Quicktime and VS2010

 >  media_plugin_quicktime.cpp
> C:\Program Files (x86)\QuickTime SDK\CIncludes\GNUCompatibility/stdint.h(49): 
> error C2371: 'int_fast16_t' : redefinition; different basic types
>   C:\Program Files (x86)\Microsoft Visual Studio 
> 10.0\VC\include\stdint.h(34) : see declaration of 'int_fast16_t'

> there are more errors like these but the same header just different int's

> I have tried #include  and #undef and that doesn't help.

Oh, interesting, I just had the same problem after switching to VS2010. Thought 
I'd share my solution :)

It turns out the geniuses at Microsoft had decided not to include stdint.h in 
their include directory (which is required by the C99 standard, that Microsoft 
apparently ignores).

This got the Apple people worried, so they added their own stdint.h to the 
QuickTime SDK. Nice, except that now for some unknown reason Microsoft decided 
it was  time to add stdint.h to VS2010! Obviously with completely different 
definitions :)

Also, they failed defining the standard _STDINT_H that would tell other headers 
it exists, instead they define _STDINT only. Brilliant.

So, I had to do this:

1. In C:\Program Files (x86)\QuickTime SDK\CIncludes\CoreFoundation, comment 
out 
this on line 36:
#include 

2. In C:\Program Files (x86)\Microsoft Visual Studio 10.0\VC\include\stdint.h 
(keep a copy of the original if you like!), change line 4 from this:
#define _STDINT

...to this:
#define _STDINT
#define _STDINT_H

Voilà it now compiles properly, and so should everything else that uses 
stdint.h!

/Kip___
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-1118 Viewer crashes when user tries to upload image without JFIF header

[Vadim ProductEngine]

> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, line 97
> > 
> >
> > Magic number. (I guess it's BMP header (14) + DIB header - current 
> > position (File begin + 2)?)

Yep, pretty obvious. If I start documenting every line, code will eventually 
look even worse than without comments.


> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, line 147
> > 
> >
> > ... until here. (Assuming it's the same 8.) Might be worth another 
> > constant.

Come on, Boroondas, it wasn't difficult to find! ;-)


> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, lines 217-219
> > 
> >
> > Wouldn't a seek be a "cheaper" way to determine size than reading into 
> > an actual buffer? (According to indra/llcommon/llapr.h, it returns -1 on 
> > failure.)
> > 
> > There's also a static method LLAPRFile::size, but that seems to operate 
> > on not-yet-opened files given by filename.

seek() may go beyond the file end, so we can't use it to check whether the file 
contains the needed header.
Well, we could seek to the end of file, but accessing the whole file just to 
find out that it's of wrong type looks like overkill.
I agree that reading into a dynamically allocated buffer doesn't look nice, but 
I think we can live with it as long as we only read small chunks this way.


- Vadim


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


On April 7, 2011, 4:20 p.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/255/
> ---
> 
> (Updated April 7, 2011, 4:20 p.m.)
> 
> 
> 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

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

[Boroondas Gupte]

> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, line 147
> > 
> >
> > ... until here. (Assuming it's the same 8.) Might be worth another 
> > constant.
> 
> Vadim ProductEngine wrote:
> Come on, Boroondas, it wasn't difficult to find! ;-)

Ok, ok, I'll give you that one.


> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, lines 217-219
> > 
> >
> > Wouldn't a seek be a "cheaper" way to determine size than reading into 
> > an actual buffer? (According to indra/llcommon/llapr.h, it returns -1 on 
> > failure.)
> > 
> > There's also a static method LLAPRFile::size, but that seems to operate 
> > on not-yet-opened files given by filename.
> 
> Vadim ProductEngine wrote:
> seek() may go beyond the file end, so we can't use it to check whether 
> the file contains the needed header.
> Well, we could seek to the end of file, but accessing the whole file just 
> to find out that it's of wrong type looks like overkill.
> I agree that reading into a dynamically allocated buffer doesn't look 
> nice, but I think we can live with it as long as we only read small chunks 
> this way.

There's no pointer equivalent of /dev/null that could be used here instead of 
an actual buffer, is there?


> On April 8, 2011, 4:51 p.m., Boroondas Gupte wrote:
> > indra/llimage/llimagedimensionsinfo.cpp, line 97
> > 
> >
> > Magic number. (I guess it's BMP header (14) + DIB header - current 
> > position (File begin + 2)?)
> 
> Vadim ProductEngine wrote:
> Yep, pretty obvious. If I start documenting every line, code will 
> eventually look even worse than without comments.

Is it? Took me some while to figure this out, and even then I wasn't sure. An 
alternative to comments: Instead of a constant for DATA_LEN, have constants for 
its components, and re-use those constants here.


- Boroondas


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


On April 7, 2011, 4:20 p.m., Vadim ProductEngine wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/255/
> ---
> 
> (Updated April 7, 2011, 4:20 p.m.)
> 
> 
> 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

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

[Tateru Nino]

On 12/04/2011 9:31 AM, Vadim ProductEngine wrote:
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/255/
>
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> 
> (Diff revision 2)
>
> bool LLImageDimensionsInfo::load(const std::string& src_filename,U32 
> codec)
>
>
>   
>   97  
>
>   mInfile.seek(APR_CUR, 16);
>
> Magic number. (I guess it's BMP header (14) + DIB header - current 
> position (File begin + 2)?)
>
> Yep, pretty obvious. If I start documenting every line, code will eventually 
> look even worse than without comments.

That is what the documentation is for. The code can always be checked
against that.
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> 
> (Diff revision 2)
>
> bool LLImageDimensionsInfo::load(const std::string& src_filename,U32 
> codec)
>
>
>   
>   147 
>
>   mInfile.seek(APR_CUR, 8 /* chunk length + chunk type */);
>
> ... until here. (Assuming it's the same 8.) Might be worth another 
> constant.
>
> Come on, Boroondas, it wasn't difficult to find! ;-)
>
> On April 8th, 2011, 4:51 p.m., *Boroondas Gupte* wrote:
>
> indra/llimage/llimagedimensionsinfo.cpp
> 
> 
> (Diff revision 2)
>
>   
>
> bool LLImageDimensionsInfo::checkFileLength(S32 min_len)
>
>
>   
>   217 
>
>   char* buf = new char[min_len];
>
>
>   
>   218 
>
>   int nread = mInfile.read(buf, min_len);
>
>
>   
>   219 
>
>   delete[] buf;
>
> Wouldn't a seek be a "cheaper" way to determine size than reading 
> into an actual buffer? (According to indra/llcommon/llapr.h, it returns -1 on 
> failure.)
>
> There's also a static method LLAPRFile::size, but that seems to 
> operate on not-yet-opened files given by filename.
>
> seek() may go beyond the file end, so we can't use it to check whether the 
> file contains the needed header.
> Well, we could seek to the end of file, but accessing the whole file just to 
> find out that it's of wrong type looks like overkill.
> I agree that reading into a dynamically allocated buffer doesn't look nice, 
> but I think we can live with it as long as we only read small chunks this way.
>
> - Vadim
>
>
> On April 7th, 2011, 4:20 p.m., Vadim ProductEngine wrote:
>
> Review request for Viewer.
> By Vadim ProductEngine.
>
> /Updated April 7, 2011, 4:20 p.m./
>
>
>   Description
>
> * 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.
>
> *Bugs: * STORM-1118 
>
>
>   Diffs
>
> * indra/llimage/llimagedimensionsinfo.h (33ca961b0870)
> * indra/llimage/llimagedimensionsinfo.cpp (33ca961b0870)
>
> View 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

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

[opensource-dev] 3p-quicktime license and use

[Nicky Perian]

Quicktime SDK is an INSTALL_PROPRIETARY=TRUE archive download. The LL archive 
is 
modified to work with VS2010. The Apple Quicktime SDK has not been modified and 
fails compile.

I cloned 3p-quicktime and with autobuild build and package have the libraries. 
The procedure worked extremely well. 


Then, I modified autobuild.xml to point to the local copy. Now the catch, since 
QuickTimePlugin.cmake has:

if (INSTALL_PROPRIETARY)
include(Prebuilt)
use_prebuilt_binary(quicktime)
endif(INSTALL_PROPRIETARY) 

What autobuild setup or command line switch do I use to access the local copy?

I commented out the if(INSTALL_PROPRIETARY) and then it pulled from the local 
copy with autobuild.xml set to the location and md5sum printed as output of 
autobuild package command.

What are the planned methods to use local copies of what at one time were 
proprietary or license restricted packages and now can be cloned and built on a 
local computer and used?

Also, does INSTALL_PROPRIETARY make sense when the end result is the library is 
on the local computer and can be used?___
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