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

2011-04-06 Thread Boroondas Gupte 
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] Review Request: Allow override of the autobuild platform for configuration testing

2011-04-06 Thread Oz Linden 

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

Review request for Viewer, Brad Kittenbrink and Alain Linden.


Summary
---

When merging the changes for OPEN-50, I found that I wanted to be able to use 
the --dry-run option to see what system commands would be executed for the 
configure and build sub-commands on each of the platforms. At present, the 
platform used is always the real local platform, but I wanted to be able to 
override that so that I could see how a configuration change would affect the 
system commands used on a different platform.

Adding a command line argument for this would have been quite complex, since it 
would have meant adding the args down through all the possible routes 
(including possible recursive autobuild invocations) to the low level routine 
that reads the python sys.platform and translates the name to the autobuild 
conventional names.  Especially given that this should be relatively rarely 
used, that complexity did not seem justified.

Instead, I added an environment variable AUTOBUILD_PLATFORM_OVERRIDE that may 
be set to the desired autobuild conventional platform name; if that is set, 
then it is used directly and if not then the sys.platform value is translated 
as before.  It's a one line change.


This addresses bug open-57.
http://jira.secondlife.com/browse/open-57


Diffs
-

  autobuild/common.py 5067ba42a9c8 

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


Testing
---

Execute --dry-run commands preceded by 'AUTOBUILD_PLATFORM_OVERRIDE=linux' (and 
for 'windows') on a Mac, and observed that the echoed commands changed 
appropriately; also observed that overriding to the local platform produced the 
same command as produced when no override was used.


Thanks,

Oz

___
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: OPEN-57: Allow override of the autobuild platform for configuration testing

2011-04-06 Thread Oz Linden 

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

(Updated April 6, 2011, 3:32 a.m.)


Review request for Viewer, Brad Kittenbrink and Alain Linden.


Summary (updated)
---

When merging the changes for OPEN-50, I found that I wanted to be able to use 
the --dry-run option to see what system commands would be executed for the 
configure and build sub-commands on each of the platforms. At present, the 
platform used is always the real local platform, but I wanted to be able to 
override that so that I could see how a configuration change would affect the 
system commands used on a different platform.

Adding a command line argument for this would have been quite complex, since it 
would have meant adding the args down through all the possible routes 
(including possible recursive autobuild invocations) to the low level routine 
that reads the python sys.platform and translates the name to the autobuild 
conventional names.  Especially given that this should be relatively rarely 
used, that complexity did not seem justified.

Instead, I added an environment variable AUTOBUILD_PLATFORM_OVERRIDE that may 
be set to the desired autobuild conventional platform name; if that is set, 
then it is used directly and if not then the sys.platform value is translated 
as before.  It's a one line change.


This addresses bug open-57.
http://jira.secondlife.com/browse/open-57


Diffs
-

  autobuild/common.py 5067ba42a9c8 

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


Testing
---

Execute --dry-run commands preceded by 'AUTOBUILD_PLATFORM_OVERRIDE=linux' (and 
for 'windows') on a Mac, and observed that the echoed commands changed 
appropriately; also observed that overriding to the local platform produced the 
same command as produced when no override was used.


Thanks,

Oz

___
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: OPEN-57: Allow override of the autobuild platform for configuration testing

2011-04-06 Thread Boroondas Gupte 

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

Ship it!


Looks good

- Boroondas


On April 6, 2011, 3:32 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/253/
> ---
> 
> (Updated April 6, 2011, 3:32 a.m.)
> 
> 
> Review request for Viewer, Brad Kittenbrink and Alain Linden.
> 
> 
> Summary
> ---
> 
> When merging the changes for OPEN-50, I found that I wanted to be able to use 
> the --dry-run option to see what system commands would be executed for the 
> configure and build sub-commands on each of the platforms. At present, the 
> platform used is always the real local platform, but I wanted to be able to 
> override that so that I could see how a configuration change would affect the 
> system commands used on a different platform.
> 
> Adding a command line argument for this would have been quite complex, since 
> it would have meant adding the args down through all the possible routes 
> (including possible recursive autobuild invocations) to the low level routine 
> that reads the python sys.platform and translates the name to the autobuild 
> conventional names.  Especially given that this should be relatively rarely 
> used, that complexity did not seem justified.
> 
> Instead, I added an environment variable AUTOBUILD_PLATFORM_OVERRIDE that may 
> be set to the desired autobuild conventional platform name; if that is set, 
> then it is used directly and if not then the sys.platform value is translated 
> as before.  It's a one line change.
> 
> 
> This addresses bug open-57.
> http://jira.secondlife.com/browse/open-57
> 
> 
> Diffs
> -
> 
>   autobuild/common.py 5067ba42a9c8 
> 
> Diff: http://codereview.secondlife.com/r/253/diff
> 
> 
> Testing
> ---
> 
> Execute --dry-run commands preceded by 'AUTOBUILD_PLATFORM_OVERRIDE=linux' 
> (and for 'windows') on a Mac, and observed that the echoed commands changed 
> appropriately; also observed that overriding to the local platform produced 
> the same command as produced when no override was used.
> 
> 
> Thanks,
> 
> Oz
> 
>

___
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

2011-04-06 Thread Monty Brandenberg 
On 4/5/2011 4:03 PM, Jonathan Welch wrote:
> I have not had much chance to compile since viewer-development took in
> the autobuild changes.  This afternoon I gave it a try and fixed a few
> issues but am stumped at how to fix this, which occurs in a number of
> places:
>
> -- Build started: Project: llwindow, Configuration: Release Win32 --
>   llwindowwin32.cpp
>   lldxhardware.cpp
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
> syntax error : identifier '__RPC__out_xcount_part'
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
> syntax error : ')'
> e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
> C1903: unable to recover from previous error(s); stopping compilation
>
> I fiddled a bit with the include path in the props file and this is
> what I currently have:
> E:\Microsoft Visual Studio 10.0\VC\INCLUDE;e:\Microsoft
> SDKs\Windows\v7.1\Include;e:\Microsoft
> SDKs\Windows\v7.1\Include\gl;e:\Microsoft DirectX SDK (June
> 2010)\Include;e:\Microsoft
> SDKs\Windows\v7.1\Samples\winui\TSF\tsfapp;$(WindowsSdkDir)\include;$(IncludePath)
>
> That first entry is a result of my fiddling.  This is happening in
> vs2010 but also via autobuild in a dos window.
>
> Googling on this error says it is an issue of having the include file
> list in a certain order, but as far as I can tell my list is
> correct...and worked when we were testing autobuild builds before the
> code got merged into viewer-development.
>
> Can you shed any light on this?  I am stumped.

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"


___
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] Doxygen finally completed.

2011-04-06 Thread Brandon Husbands 
http://developer.dimentox.com/de/db5/classLLViewerCamera_a38fbfdd64a1e1d277aa218103331acfc.html#a38fbfdd64a1e1d277aa218103331acfc
Shows the call graph.

http://developer.dimentox.com/de/db5/classLLViewerCamera.html
Shows the other graphs.

Make sure you press the down arrows to see the images.

The graphs are in UML format.


Unfortunately this takes like 3 days to complete due to all the calls and
such.

Hope this helps.
-- 
---
This email is a private and confidential communication. Any use of email may
be subject to the laws and regulations of the United States. You may not
Repost, Distribute nor reproduce any content of this message.
---
---
___
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] Almost Daily Scrum Summary - Wednesday, April 6, 2011

2011-04-06 Thread Anya Kanevsky 
 Sprint 13, ends 04.11.11 Wednesday, April 6 General Notes
--

   - MMOTD: Oz

Team Status
--
 Merov Linden
--

*PAST*

   - Attended STORM Triage meeting
   - Attended Viewer Coding and Design meeting: lots of build discussion,
   some discussion on JPEG2000
   - STORM-746 : Use KDU precincts : worked on test cases:
  - Looked at VRR cases : no problem found
  - Dug through VWR texture issues, triaged a bunch while at it. Will
  look into VWR-20322 in details as some of what I did in STORM-746 could
  address those.
   - STORM-610 : Environment Editor: water color : Issues with pull and
   transplant so had to redo the changeset for testing. Milky water issue on
   Mac still repros.
   - STORM-954 : Build test

*FUTURE*

   - STORM-746 : Use KDU precincts : Post test results
   - STORM-610 : Environment Editor: water color : Fix that Mac milky water
   issue

*IMPEDIMENTS*

   - none

Oz Linden
--

*PAST*

   - pulled three issue changes to viewer-development
   - Review of OPEN-50 open source development changes
  - most changes resolved, need review from Chopper on remaining diffs
  - working repo http://bitbucket.org/oz_linden/open-50
   - Viewer Evolution User Group
   - re-started work on open build farm

*FUTURE*

   - continue with OPEN-50 changes
   - meeting re: STORM-2
   - Open Development User Group
   - supporting 2.6.3 beta repairs
   - work on open build farm

*IMPEDIMENTS*

   - none

Wolf Linden
--

*PAST*

   - No update

*FUTURE*

   - Meeting with Oz re: Storm-2
   - need to catch up with Grumpity re: Storm-1077

*IMPEDIMENTS*

   - none

Grumpity ProductEngine
--

*PAST*

   - STORM-1065, STORM-1071, STORM-1066, STORM-1109
   - STORM triage
   - crashhunters

*FUTURE*

   - VWR-20826, VWR-303
   - add Fix Version: open-developer to VWR
   - VWR triage process
   - WLES follow up

*IMPEDIMENTS*

   - OOO this PST afternoon

Paul ProductEngine
--

*PAST*

   - BUG STORM-595 (Viewer should stop spamming AgentThrottle messages as
   the slider is dragged)
  - WIP. Estimate ~2 hours.
   - BUG VWR-25444 (Win7: 2.6.3 Beta1 crashes on startup if locale differs
   from English)
  - Working on this issue now with Seth. Can't give estimate for now.

*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 updating the fix according to review feedback. Some more
  changes in chat logging required.
   - BUG (STORM-1071) Switching language in preferences creates new calling
   cards folders for each language
  - Checking debug settings suggested by Stone's though they don't seem
  to be related to the issue.

*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
  - Looks like it needs a server side fix.

Vadim ProductEngine
--

*PAST*

   - Worked on reporting the autobuild issue we've recently faced with.
  - It turned out to be mostly fixed already. Reopened OPEN-34 with one
  more use case.
   - STORM-1126 (Windlight Region Settings):
  - Fixing known bugs.

*FUTURE*

   - Work on bugs from the bug queue.

*IMPEDIMENTS*

   - Should STORM-1025 (Chat preferences > font size should affect Chat and
   IM text input boxes) be closed as a dupe of STORM-1094 and/or STORM-1095?

Andrey ProductEngine
--

*PAST*

   - passed smoke & integrity tests against 2.6.1 release build#2, see
   IQA-118 for more details
   - started smoke & integrity tests against 2.6.3 Beta1

*FUTURE*

   - finish 2.6.3 beta1 smoke tests (IQA-120)
   - test 2.6.3 beta1 changes (IQA-122)
   - switch to vs2010 tests on the latest v-d build

*IMPEDIMENTS*

   - none

Wolfpup Lowenhar
--

*PAST*

   - Working inworld (this is part of testing locally built viewers).
   - Attended OH.
   - STORM-941 : posted comment to RB.
   - STORM-1098 : Replied to comments on RB and had Merov move issue to
   current Sprint.

*FUTURE*

   - Working inworld(this is part of testing localy 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
   -
___
Policies and (un)subscribe information available here:
http://wiki.secondlife

Re: [opensource-dev] Windows compiling problem

2011-04-06 Thread Twisted Laws 

A possibility is the sequence of your includes ...  it needs the 7.1 version of 
the SDK
and to have \Microsoft SDKs\Windows\v7.1\Include as the first include

i have a batch file that i run after opening the Visual Studio Command Prompt 
window...
 
@set INCLUDE=C:\Program Files\Microsoft SDKs\Windows\v7.1\Include;C:\Program 
Files\Microsoft SDKs\Windows\v7.1\Include\gl;C:\Program Files (x86)\Microsoft 
DirectX SDK (June 2010)\Include;%INCLUDE%
@set LIB=C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib;C:\Program 
Files\Microsoft SDKs\Windows\v7.1\Lib\x64;C:\Program Files (x86)\Microsoft 
DirectX SDK (June 2010)\Lib;%LIB%
@set PATH=%PATH%;C:\Dev\hgbuilds\autobuild\bin
 
Maybe it helps, hope so.
 
> Date: Wed, 6 Apr 2011 11:46:39 -0400
> From: mo...@lindenlab.com
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Windows compiling problem
> 
> On 4/5/2011 4:03 PM, Jonathan Welch wrote:
> > I have not had much chance to compile since viewer-development took in
> > the autobuild changes. This afternoon I gave it a try and fixed a few
> > issues but am stumped at how to fix this, which occurs in a number of
> > places:
> >
> > -- Build started: Project: llwindow, Configuration: Release Win32 --
> > llwindowwin32.cpp
> > lldxhardware.cpp
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
> > syntax error : identifier '__RPC__out_xcount_part'
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
> > syntax error : ')'
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
> > C1903: unable to recover from previous error(s); stopping compilation
> >
> > I fiddled a bit with the include path in the props file and this is
> > what I currently have:
> > E:\Microsoft Visual Studio 10.0\VC\INCLUDE;e:\Microsoft
> > SDKs\Windows\v7.1\Include;e:\Microsoft
> > SDKs\Windows\v7.1\Include\gl;e:\Microsoft DirectX SDK (June
> > 2010)\Include;e:\Microsoft
> > SDKs\Windows\v7.1\Samples\winui\TSF\tsfapp;$(WindowsSdkDir)\include;$(IncludePath)
> >
> > That first entry is a result of my fiddling. This is happening in
> > vs2010 but also via autobuild in a dos window.
> >
> > Googling on this error says it is an issue of having the include file
> > list in a certain order, but as far as I can tell my list is
> > correct...and worked when we were testing autobuild builds before the
> > code got merged into viewer-development.
> >
> > Can you shed any light on this? I am stumped.
> 
> 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"
> 
> 
> ___
> 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

[opensource-dev] Review Request: STORM-610 : Changes to Environment Editor: water color change is not saved

2011-04-06 Thread Merov Linden 

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

Review request for Viewer.


Summary
---

This is a rework of Vadim's original fix plus additional fixes for 
initialization of water fog color issues that mysteriously show only on Mac. 
Compared to Vadim's fix, I just added init of mPrevFogColor, separated the 
various affectations and, critically, changed the default color in settings.xml 
(the color channel values are normalized between 0 and 1).


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


Diffs
-

  indra/newview/app_settings/settings.xml 33ca961b0870 
  indra/newview/llwaterparammanager.h 33ca961b0870 
  indra/newview/llwaterparammanager.cpp 33ca961b0870 

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


Testing
---

Built and tested on Mac. The issue I reported was fixed.


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

Re: [opensource-dev] Review Request: STORM-610 : Changes to Environment Editor: water color change is not saved

2011-04-06 Thread Vadim ProductEngine 

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

Ship it!


Thanks for help with this, Merov!

- Vadim


On April 6, 2011, 3:02 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/254/
> ---
> 
> (Updated April 6, 2011, 3:02 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a rework of Vadim's original fix plus additional fixes for 
> initialization of water fog color issues that mysteriously show only on Mac. 
> Compared to Vadim's fix, I just added init of mPrevFogColor, separated the 
> various affectations and, critically, changed the default color in 
> settings.xml (the color channel values are normalized between 0 and 1).
> 
> 
> This addresses bug STORM-610.
> http://jira.secondlife.com/browse/STORM-610
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 33ca961b0870 
>   indra/newview/llwaterparammanager.h 33ca961b0870 
>   indra/newview/llwaterparammanager.cpp 33ca961b0870 
> 
> Diff: http://codereview.secondlife.com/r/254/diff
> 
> 
> Testing
> ---
> 
> Built and tested on Mac. The issue I reported was fixed.
> 
> 
> 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

Re: [opensource-dev] Review Request: STORM-610 : Changes to Environment Editor: water color change is not saved

2011-04-06 Thread Oz Linden 

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

Ship it!


- Oz


On April 6, 2011, 3:02 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/254/
> ---
> 
> (Updated April 6, 2011, 3:02 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> This is a rework of Vadim's original fix plus additional fixes for 
> initialization of water fog color issues that mysteriously show only on Mac. 
> Compared to Vadim's fix, I just added init of mPrevFogColor, separated the 
> various affectations and, critically, changed the default color in 
> settings.xml (the color channel values are normalized between 0 and 1).
> 
> 
> This addresses bug STORM-610.
> http://jira.secondlife.com/browse/STORM-610
> 
> 
> Diffs
> -
> 
>   indra/newview/app_settings/settings.xml 33ca961b0870 
>   indra/newview/llwaterparammanager.h 33ca961b0870 
>   indra/newview/llwaterparammanager.cpp 33ca961b0870 
> 
> Diff: http://codereview.secondlife.com/r/254/diff
> 
> 
> Testing
> ---
> 
> Built and tested on Mac. The issue I reported was fixed.
> 
> 
> 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

Re: [opensource-dev] Windows compiling problem

2011-04-06 Thread WolfPup Lowenhar 
The Way Twisted Laws is doing it is one way, and here is another:

First see OPEN-37   for the
changes need to some specific local files.

Then instead of opening the VS Command Prompt use the one from the MS
Windows 7.1 SDK as this will automatically set the working environment and
can even be configured for different build environments (Release, Release
With Debug, and Debug) as well as the arch type(x86 or x64).

And lastly go to my local repository and start a build run.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Twisted
Laws
Sent: Wednesday, April 06, 2011 2:08 PM
To: SLDEV
Subject: Re: [opensource-dev] Windows compiling problem

 

A possibility is the sequence of your includes ...  it needs the 7.1 version
of the SDK
and to have \Microsoft SDKs\Windows\v7.1\Include as the first include

i have a batch file that i run after opening the Visual Studio Command
Prompt window...
 
@set INCLUDE=C:\Program Files\Microsoft SDKs\Windows\v7.1\Include;C:\Program
Files\Microsoft SDKs\Windows\v7.1\Include\gl;C:\Program Files
(x86)\Microsoft DirectX SDK (June 2010)\Include;%INCLUDE%
@set LIB=C:\Program Files\Microsoft SDKs\Windows\v7.1\Lib;C:\Program
Files\Microsoft SDKs\Windows\v7.1\Lib\x64;C:\Program Files (x86)\Microsoft
DirectX SDK (June 2010)\Lib;%LIB%
@set PATH=%PATH%;C:\Dev\hgbuilds\autobuild\bin
 
Maybe it helps, hope so.
 
> Date: Wed, 6 Apr 2011 11:46:39 -0400
> From: mo...@lindenlab.com
> To: opensource-dev@lists.secondlife.com
> Subject: Re: [opensource-dev] Windows compiling problem
> 
> On 4/5/2011 4:03 PM, Jonathan Welch wrote:
> > I have not had much chance to compile since viewer-development took in
> > the autobuild changes. This afternoon I gave it a try and fixed a few
> > issues but am stumped at how to fix this, which occurs in a number of
> > places:
> >
> > -- Build started: Project: llwindow, Configuration: Release Win32
--
> > llwindowwin32.cpp
> > lldxhardware.cpp
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11280): error C2061:
> > syntax error : identifier '__RPC__out_xcount_part'
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): error C2059:
> > syntax error : ')'
> > e:\Microsoft SDKs\Windows\v7.1\Include\objidl.h(11281): fatal error
> > C1903: unable to recover from previous error(s); stopping compilation
> >
> > I fiddled a bit with the include path in the props file and this is
> > what I currently have:
> > E:\Microsoft Visual Studio 10.0\VC\INCLUDE;e:\Microsoft
> > SDKs\Windows\v7.1\Include;e:\Microsoft
> > SDKs\Windows\v7.1\Include\gl;e:\Microsoft DirectX SDK (June
> > 2010)\Include;e:\Microsoft
> >
SDKs\Windows\v7.1\Samples\winui\TSF\tsfapp;$(WindowsSdkDir)\include;$(Includ
ePath)
> >
> > That first entry is a result of my fiddling. This is happening in
> > vs2010 but also via autobuild in a dos window.
> >
> > Googling on this error says it is an issue of having the include file
> > list in a certain order, but as far as I can tell my list is
> > correct...and worked when we were testing autobuild builds before the
> > code got merged into viewer-development.
> >
> > Can you shed any light on this? I am stumped.
> 
> 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"
> 
> 
> ___
> 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/3554 - 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

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

2011-04-06 Thread Glimmering Sands 
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

On Tue, Apr 5, 2011 at 8:14 PM, Glimmering Sands
 wrote:
> Sorry to bother you kind folks again.  I am attempting to follow the
> suggestion of building from scratch from a new account.  Given that
> the instructions for how to install fmod are now missing from the wiki
> I decided I should just follow the autobuild instructions.  Maybe they
> will work better?  But alas, fate would have it that this has a
> failure for me as well:
>
>
> downloading fmod archive from
> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2
> unable to download file: 
>
> So why does this download timeout?
>
> $ nslookup s3-proxy.lindenlab.com
> Non-authoritative answer:
> s3-proxy.lindenlab.com  canonical name = int.excod.lindenlab.com.
> Name:   int.excod.lindenlab.com
> Address: 10.6.3.104
>
> No, even in the fantastical world I might live in, I am quite certain
> I am not able to reach linden lab's private servers, nor do I think
> setting up my own 10.6/16 network would be of any assistance.  Perhaps
> this is an error by the DNS administrators at Linden Labs?
>
> Kind Regards,
>
> Glimmering
>
___
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?

2011-04-06 Thread Zabb65 
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.

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
>
> On Tue, Apr 5, 2011 at 8:14 PM, Glimmering Sands
>  wrote:
>> Sorry to bother you kind folks again.  I am attempting to follow the
>> suggestion of building from scratch from a new account.  Given that
>> the instructions for how to install fmod are now missing from the wiki
>> I decided I should just follow the autobuild instructions.  Maybe they
>> will work better?  But alas, fate would have it that this has a
>> failure for me as well:
>>
>>
>> downloading fmod archive from
>> http://s3-proxy.lindenlab.com/private-builds-secondlife-com/hg/repo/3p-fmod-private/rev/221852/arch/Darwin/installer/fmod-3.75-darwin-20110222.tar.bz2
>> unable to download file: 
>>
>> So why does this download timeout?
>>
>> $ nslookup s3-proxy.lindenlab.com
>> Non-authoritative answer:
>> s3-proxy.lindenlab.com  canonical name = int.excod.lindenlab.com.
>> Name:   int.excod.lindenlab.com
>> Address: 10.6.3.104
>>
>> No, even in the fantastical world I might live in, I am quite certain
>> I am not able to reach linden lab's private servers, nor do I think
>> setting up my own 10.6/16 network would be of any assistance.  Perhaps
>> this is an error by the DNS administrators at Linden Labs?
>>
>> Kind Regards,
>>
>> Glimmering
>>
> ___
> 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