Re: [opensource-dev] "Nearby" people tab

[Trilo Byte]

There's a debug setting, I believe called NearMeRange, that you can adjust to a 
number that better suits your needs.

On Jan 29, 2011, at 3:50 PM, Dave Booth wrote:

> Whats the expected behavior of this tab of the people sidebar? I'm 
> currently sitting in a room with 14 other folks, half of whom are on my 
> flist and all within chat range - but this tab tells me "no one nearby". 
> Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second 
> Life Development) but to be honest I dont think I've EVER seen that tab 
> populated, no matter what build or how crowded the venue.
> ___
> 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] attempting to compile a viewer

[Andromeda Quonset]

I am using VS2005, attempting to compile viewer 1.22 (I wanted to 
start with 1.23.5, but the source seems unavailable).

My problem ATM is with running develop.py

I am getting the following error message:


CMake Error at cmake/Python.cmake:47 (message):
   No Python interpreter found
Call Stack (most recent call first):
   cmake/Prebuilt.cmake:3 (include)
   cmake/Audio.cmake:2 (include)
   llaudio/CMakeLists.txt:6 (include)


-- Configuring incomplete, errors occurred!
Cleaning 'build-vc80'
Error: the command 'cmake' exited with status 1

There are some messages prior to this, but they seem to be warnings 
related to a lack of CMakeLists.txt in the Input directories, and I 
assume I can ignore them for now.

___
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] "Nearby" people tab

[Ricky]

I have had no issues with the "nearby" tab of the sidebar.  I
regularly exist at 2000 to 4000 meters, and occasionally at ground
level (our island is platformed instead of parceled).  However, I DO
wish to note that I have the maximum range of the list set at 4096...
I use it as a better performing replacement for my scripted radar.
(Which is why https://jira.secondlife.com/browse/STORM-642 and
children exist.)

My tested systems are currently largely Intel Macs (Mini, Pro Desktop,
MacBook Pro, and MacBook) with a couple of Windows XP boxes.  My
beloved Linux box recently was placed in suspended decay due to
hardware problems...

Ricky
Cron Stardust

On Sat, Jan 29, 2011 at 4:01 PM, Kadah Coba  wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA1
>
> Are you above 1000m?
>
> On 1/29/2011 3:50 PM, Dave Booth wrote:
>> Whats the expected behavior of this tab of the people sidebar? I'm
>> currently sitting in a room with 14 other folks, half of whom are on my
>> flist and all within chat range - but this tab tells me "no one nearby".
>> Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second
>> Life Development) but to be honest I dont think I've EVER seen that tab
>> populated, no matter what build or how crowded the venue.
>> ___
>> 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
>
> -BEGIN PGP SIGNATURE-
> Version: GnuPG v1.4.9 (MingW32)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQEcBAEBAgAGBQJNRKpHAAoJEGUNvxojA31thvcIAI78LVkHyDYwejCbLaehmDAE
> LlAe+mLqGyb1D7yO9NeAQkdhwNZSInKqdvKrHCMYQFifbQk/Z1aE+nYUoRoMa7/J
> 42Wo52L87mKEdA9fg7aPlWHEBgiP+d/6y5oK4hRDtJLcH1G6sHGSIeCFsvaTo2la
> OEMzSP5l3N4c0hzxFeDR80YwPT1iYKrRqXdfUNhwyyQV3/QHrEnNmmkdk3dXSsQ2
> hDpk9g3ui+uBh1zW/IzZ7RXgCPcMxHQdTONesLmeK1F9c6iLi4MIbrZ5WJkSGAtn
> 4kTyUeCPu8CTumXNX1n4pwKkO/gAyCXpifa4Aow/CGvjGyt2AY/SPcDmjvGJfzw=
> =EZAf
> -END PGP SIGNATURE-
> ___
> 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

Re: [opensource-dev] VWR-3156

[Argent Stonecutter]

On 2011-01-25, at 03:09, Nexii Malthus wrote:
> It would be great if the mini bar graphs would make a comeback. But I think 
> they might need some improvement so they can be easier to "relate to".

Be very careful. The last time they decided to "improve" them the result was 
the worthless lag meter.

Humans are very good at pattern matching and pattern detection. Let us use that 
capability.

___
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] from debug to prefences

[Argent Stonecutter]

On 2011-01-24, at 11:25, Erin Mallory wrote:
> Here's how it would work. We take the existing advanced preferences tab and 
> turn it into a floater activated if you click on where the advanced tab is 
> now. we then bump many of the preferences that are in the debug over.  we can 
> do it in kinda a category form as the sketch here shows or break it up into 
> tabs.  

I like the general idea.

How about making it like the "about:config" screen in Firefox? That's an 
interface that works well for complex preferences, doesn't require any 
significant per-reference customization, is familiar to people who are likely 
to be messing with it, and is much easier to browse than the debug window?

___
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] "Nearby" people tab

[Kadah Coba]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Are you above 1000m?

On 1/29/2011 3:50 PM, Dave Booth wrote:
> Whats the expected behavior of this tab of the people sidebar? I'm 
> currently sitting in a room with 14 other folks, half of whom are on my 
> flist and all within chat range - but this tab tells me "no one nearby". 
> Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second 
> Life Development) but to be honest I dont think I've EVER seen that tab 
> populated, no matter what build or how crowded the venue.
> ___
> 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

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iQEcBAEBAgAGBQJNRKpHAAoJEGUNvxojA31thvcIAI78LVkHyDYwejCbLaehmDAE
LlAe+mLqGyb1D7yO9NeAQkdhwNZSInKqdvKrHCMYQFifbQk/Z1aE+nYUoRoMa7/J
42Wo52L87mKEdA9fg7aPlWHEBgiP+d/6y5oK4hRDtJLcH1G6sHGSIeCFsvaTo2la
OEMzSP5l3N4c0hzxFeDR80YwPT1iYKrRqXdfUNhwyyQV3/QHrEnNmmkdk3dXSsQ2
hDpk9g3ui+uBh1zW/IzZ7RXgCPcMxHQdTONesLmeK1F9c6iLi4MIbrZ5WJkSGAtn
4kTyUeCPu8CTumXNX1n4pwKkO/gAyCXpifa4Aow/CGvjGyt2AY/SPcDmjvGJfzw=
=EZAf
-END PGP SIGNATURE-
___
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] "Nearby" people tab

[Dave Booth]

Whats the expected behavior of this tab of the people sidebar? I'm 
currently sitting in a room with 14 other folks, half of whom are on my 
flist and all within chat range - but this tab tells me "no one nearby". 
Currently on Second Life 2.6.0 (21) Jan 29 2011 12:57:40 (Second 
Life Development) but to be honest I dont think I've EVER seen that tab 
populated, no matter what build or how crowded the venue.
___
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: Do not fail when no scp command is found, unless it is actually needed to fetch something

[Boroondas Gupte]

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



autobuild/common.py


The docstring of find_executable should probably indicate that ...



autobuild/common.py


... the return value is None when no matching executable can be found, as 
we (somewhat) rely on what the return value is in that case. (Not your fault, 
the old code already relied on that, too.)



autobuild/common.py


Usually one would test for None with
if self._scp is None:
as testing for `not self._scp` will also trigger when the value is False 
(obviously) or (maybe less obvious) becomes False when casted to bool.

However, because we don't want self._scp to be an empty string when 
building the command below ...



autobuild/common.py


... testing for `not self._scp` here might actually be better, I'm not sure.


- Boroondas


On Jan. 29, 2011, 5:01 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/127/
> ---
> 
> (Updated Jan. 29, 2011, 5:01 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> During initialization, if there is no scp or pscp command found then 
> autobuild fails immediately.  This is true whether or not any scp urls need 
> to be used.
> 
> This change modifies the behavior so that a warning is printed if no command 
> is found, but execution proceeds until an scp command is needed, at which 
> time execution fails with an explanatory message.
> 
> This patch can print the warning multiple times - I didn't attempt to 
> suppress the extras.
> 
> 
> Diffs
> -
> 
>   autobuild/common.py 9ae505976dfa 
> 
> Diff: http://codereview.secondlife.com/r/127/diff
> 
> 
> Testing
> ---
> 
> I've tested this locally, simulating the error by temporarily modifying the 
> names of the commands to be found for scp.
> 
> I have not checked it on Windows, where the original problem was found.
> 
> 
> 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] Very Strange occurrence...

[Opensource Obscure]

Happened again a few hours ago with the same username (Grumpity),
unfortunately I couldn't take note of which viewer build I was using.

Photo: http://www.plurk.com/p/afagjx

In a comment to that photo, another user reports noobs sending
Abuse Report against Grumpity, and again this happened yesterday.

On Thu, Jan 6, 2011 at 15:36, Carlo Wood  wrote:
> On Wed, Jan 05, 2011 at 04:44:31PM -0500, Kent Quirk (Q Linden) wrote:
>> So the reason that semi-plausible strings are used for these things is that 
>> they're the only strings available when we use the test floater feature from 
>> the login screen.
>>
>> But we should probably try not to use real names.
>>
>> And yes, Jonathan, these should mostly never be visible. But sometimes 
>> things happen.
>
> Nevertheless, it is a bug; if whatever failed is outside the influence of
> the viewer itself, then still it should not have shown this. The viewer
> should be fixed to show the account name, or at least the UUID, in
> this -hopefully- rare case.
>
> --
> Carlo Wood 
> ___
> 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 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] Review Request: STORM-864: As as developer, I would like an object oriented wrapper to make safe use of memory pools easier

[Aleric Inglewood]

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

(Updated Jan. 29, 2011, 9:10 a.m.)


Review request for Viewer.


Changes
---

This new diff incorporates the changes as discussed above, and is updated to be 
based on revision fe7fe04ccc9a (Fri Jan 28 21:23:35 2011 -0700).
I also added comments in this version on every line that correctly uses 
apr_pool_t, so it's easy to just do a grep on apr_pool_t and check if nobody 
accidently used that instead of LLAPRPool (in the future).

I made this patch (again) available as mercurial repository, here:

hg clone https://bitbucket.org/aleric/viewer-development-storm-864

(that is the same name as before, but be warned that I destroyed
the old one and created a new repository).


Summary
---

Please see http://jira.secondlife.com/browse/STORM-864

I made a mercurial repository available for testing here:

hg clone https://bitbucket.org/aleric/viewer-development-storm-864

>From the commit message:

Introduces a LLThreadLocalData class that can be
accessed through the static LLThread::tldata().
Currently this object contains two (public) thread-local
objects: a LLAPRRootPool and a LLVolatileAPRPool.

The first is the general memory pool used by this thread
(and this thread alone), while the second is intended
for short lived memory allocations (needed for APR).
The advantages of not mixing those two is that the latter
is used most frequently, and as a result of it's nature
can be destroyed and reconstructed on a "regular" basis.

This patch adds LLAPRPool (completely replacing the old one),
which is a wrapper around apr_pool_t* and has complete
thread-safity checking.

Whenever an apr call requires memory for some resource,
a memory pool in the form of an LLAPRPool object can
be created with the same life-time as this resource;
assuring clean up of the memory no sooner, but also
not much later than the life-time of the resource
that needs the memory.

Many, many function calls and constructors had the
pool parameter simply removed (it is no longer the
concern of the developer, if you don't write code
that actually does an libapr call then you are no
longer bothered with memory pools at all).

However, I kept the notion of short-lived and
long-lived allocations alive (see my remark in
the jira here: 
https://jira.secondlife.com/browse/STORM-864?focusedCommentId=235356&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-235356
which requires that the LLAPRFile API needs
to allow the user to specify how long they
think a file will stay open. By choosing
'short_lived' as default for the constructor
that immediately opens a file, the number of
instances where this needs to be specified is
drastically reduced however (obviously, any
automatic LLAPRFile is short lived).


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


Diffs (updated)
-

  doc/contributions.txt fe7fe04ccc9a 
  indra/llaudio/llaudioengine_fmod.cpp fe7fe04ccc9a 
  indra/llaudio/llvorbisencode.cpp fe7fe04ccc9a 
  indra/llcharacter/llbvhloader.cpp fe7fe04ccc9a 
  indra/llcharacter/llkeyframemotionparam.cpp fe7fe04ccc9a 
  indra/llcharacter/llstatemachine.cpp fe7fe04ccc9a 
  indra/llcommon/CMakeLists.txt fe7fe04ccc9a 
  indra/llcommon/llapp.cpp fe7fe04ccc9a 
  indra/llcommon/llapr.h fe7fe04ccc9a 
  indra/llcommon/llapr.cpp fe7fe04ccc9a 
  indra/llcommon/llaprpool.h PRE-CREATION 
  indra/llcommon/llaprpool.cpp PRE-CREATION 
  indra/llcommon/llcommon.h fe7fe04ccc9a 
  indra/llcommon/llcommon.cpp fe7fe04ccc9a 
  indra/llcommon/llerror.h fe7fe04ccc9a 
  indra/llcommon/llerror.cpp fe7fe04ccc9a 
  indra/llcommon/llfixedbuffer.cpp fe7fe04ccc9a 
  indra/llcommon/llscopedvolatileaprpool.h PRE-CREATION 
  indra/llcommon/llthread.h fe7fe04ccc9a 
  indra/llcommon/llthread.cpp fe7fe04ccc9a 
  indra/llcommon/llthreadsafequeue.h fe7fe04ccc9a 
  indra/llcommon/llthreadsafequeue.cpp fe7fe04ccc9a 
  indra/llcommon/llworkerthread.h fe7fe04ccc9a 
  indra/llcommon/llworkerthread.cpp fe7fe04ccc9a 
  indra/llcrashlogger/llcrashlogger.cpp fe7fe04ccc9a 
  indra/llimage/llimage.cpp fe7fe04ccc9a 
  indra/llimage/llimagedimensionsinfo.cpp fe7fe04ccc9a 
  indra/llimage/llimagej2c.cpp fe7fe04ccc9a 
  indra/llimage/llimageworker.h fe7fe04ccc9a 
  indra/llimage/llimageworker.cpp fe7fe04ccc9a 
  indra/llmath/llvolumemgr.cpp fe7fe04ccc9a 
  indra/llmessage/llares.cpp fe7fe04ccc9a 
  indra/llmessage/llcurl.cpp fe7fe04ccc9a 
  indra/llmessage/lliohttpserver.h fe7fe04ccc9a 
  indra/llmessage/lliohttpserver.cpp fe7fe04ccc9a 
  indra/llmessage/lliosocket.h fe7fe04ccc9a 
  indra/llmessage/lliosocket.cpp fe7fe04ccc9a 
  indra/llmessage/llmail.h fe7fe04ccc9a 
  indra/llmessage/llmail.cpp fe7fe04ccc9a 
  indra/llmessage/llpumpio.h fe7fe04ccc9a 
  indra/llmessage/llpumpio.cpp fe7fe04ccc9a 
  indra/llmessage/llurlrequ

Re: [opensource-dev] Review Request: Do not fail when no scp command is found, unless it is actually needed to fetch something

[Wolfpup Lowenhar]

> On Jan. 29, 2011, 7:28 a.m., Wolfpup Lowenhar wrote:
> > this is crashing devenv when you do autobuild build -c 
> > OpenSourceRelWithDebInfo  on a windows system

When i tested this second dif was not a clean reop will retest again after 
deleating build tree


- Wolfpup


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


On Jan. 29, 2011, 5:01 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/127/
> ---
> 
> (Updated Jan. 29, 2011, 5:01 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> During initialization, if there is no scp or pscp command found then 
> autobuild fails immediately.  This is true whether or not any scp urls need 
> to be used.
> 
> This change modifies the behavior so that a warning is printed if no command 
> is found, but execution proceeds until an scp command is needed, at which 
> time execution fails with an explanatory message.
> 
> This patch can print the warning multiple times - I didn't attempt to 
> suppress the extras.
> 
> 
> Diffs
> -
> 
>   autobuild/common.py 9ae505976dfa 
> 
> Diff: http://codereview.secondlife.com/r/127/diff
> 
> 
> Testing
> ---
> 
> I've tested this locally, simulating the error by temporarily modifying the 
> names of the commands to be found for scp.
> 
> I have not checked it on Windows, where the original problem was found.
> 
> 
> 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: Do not fail when no scp command is found, unless it is actually needed to fetch something

[Wolfpup Lowenhar]

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


this is crashing devenv when you do autobuild build -c OpenSourceRelWithDebInfo 
 on a windows system

- Wolfpup


On Jan. 29, 2011, 5:01 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/127/
> ---
> 
> (Updated Jan. 29, 2011, 5:01 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> During initialization, if there is no scp or pscp command found then 
> autobuild fails immediately.  This is true whether or not any scp urls need 
> to be used.
> 
> This change modifies the behavior so that a warning is printed if no command 
> is found, but execution proceeds until an scp command is needed, at which 
> time execution fails with an explanatory message.
> 
> This patch can print the warning multiple times - I didn't attempt to 
> suppress the extras.
> 
> 
> Diffs
> -
> 
>   autobuild/common.py 9ae505976dfa 
> 
> Diff: http://codereview.secondlife.com/r/127/diff
> 
> 
> Testing
> ---
> 
> I've tested this locally, simulating the error by temporarily modifying the 
> names of the commands to be found for scp.
> 
> I have not checked it on Windows, where the original problem was found.
> 
> 
> 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

[opensource-dev] [linux] /usr/bin/ld: error: unsupported symbol binding

[Aleric Inglewood]

If you are using linux and get this error while compiling the viewer:

  /usr/bin/ld: error: unsupported symbol binding

(or, for that matter:

  /usr/bin/gold: error: unsupported symbol binding

then you are using ld.gold version 2.20.x.
You need to upgrade it to 2.21.

If you are using debian then you can get that
from "experimental" (but only if you know what
you're doing ;) .. don't upgrade your whole
system to experimental by accident!), as follows:

To /etc/apt/preferences add:

Package: *
Pin: release a=testing
Pin-Priority: 990

where 'testing' is YOUR CURRENT RELEASE! So,
replace it if you are not using testing.
This preference is to avoid that you upgrade
your whole system: it will prefer 'testing' or
whatever you use over the rest.

Next, add to /etc/apt/sources.list an entry
for experimental:

deb http://ftp.nl.debian.org/debian/ experimental main contrib non-free
deb-src http://ftp.nl.debian.org/debian/ experimental main contrib non-free

replace ftp.nl.debian.org with your own favourite
debian server.

Run "apt-get update" to get the info from
this new entry. Now you could try

apt-cache policy binutils

To see that it would NOT upgrade your binutils
because of the preferences ;).

Next, you can upgrade /usr/bin/gold with:

sudo apt-get install -t experimental binutils

I only tried this on testing though. If you have
an older distribution it might want to upgrade
more than just binutils. If that's the case then
don't do it.

Please note that if you'd install binutils-gold
(which is on experimental) then that will
remove your nvidia kernel module because
that is not compatible with ld.gold. You don't
want that ;).  However, just upgrading binutils
is ok, and then use LDFLAGS="-Wl,-use-gold"
as before to cause the viewer compilation to
use gold.

Aleric

PS I used the same /etc/apt preferences and
/etc/apt/sources.list to get my nvidia driver
from experimental. As root:

update-pciids
apt-get install module-assistant
apt-get install -t experimental nvidia-kernel-source
m-a prepare
m-a clean nvidia
m-a a-i nvidia
apt-get install -t experimental nvidia-glx
depmod -a
modprobe nvidia

which gives me 260.19.21which supports
my video card, while testing still has the old
195.36.31that does not support 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: Do not fail when no scp command is found, unless it is actually needed to fetch something

[Oz Linden]

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

(Updated Jan. 29, 2011, 5:01 a.m.)


Review request for Viewer.


Changes
---

removed the (possibly repeated) warnings about not finding an scp command
changed to using None properly rather than a fixed string value

(added logging that should have shown for doing scp copies, but --verbose does 
not seem to do anything different issue)


Summary
---

During initialization, if there is no scp or pscp command found then autobuild 
fails immediately.  This is true whether or not any scp urls need to be used.

This change modifies the behavior so that a warning is printed if no command is 
found, but execution proceeds until an scp command is needed, at which time 
execution fails with an explanatory message.

This patch can print the warning multiple times - I didn't attempt to suppress 
the extras.


Diffs (updated)
-

  autobuild/common.py 9ae505976dfa 

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


Testing
---

I've tested this locally, simulating the error by temporarily modifying the 
names of the commands to be found for scp.

I have not checked it on Windows, where the original problem was found.


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: Do not fail when no scp command is found, unless it is actually needed to fetch something

[Boroondas Gupte]

> On Jan. 28, 2011, 2:46 p.m., Alain Linden wrote:
> > autobuild/common.py, line 415
> > 
> >
> > ...and test for None here.

Good idea. This would avoid bugs that could occur e.g. when the string is 
changed and not spelled the same in both places.


- Boroondas


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


On Jan. 28, 2011, 5:20 a.m., Oz Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/127/
> ---
> 
> (Updated Jan. 28, 2011, 5:20 a.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> During initialization, if there is no scp or pscp command found then 
> autobuild fails immediately.  This is true whether or not any scp urls need 
> to be used.
> 
> This change modifies the behavior so that a warning is printed if no command 
> is found, but execution proceeds until an scp command is needed, at which 
> time execution fails with an explanatory message.
> 
> This patch can print the warning multiple times - I didn't attempt to 
> suppress the extras.
> 
> 
> Diffs
> -
> 
>   autobuild/common.py f49808fe3c07 
> 
> Diff: http://codereview.secondlife.com/r/127/diff
> 
> 
> Testing
> ---
> 
> I've tested this locally, simulating the error by temporarily modifying the 
> names of the commands to be found for scp.
> 
> I have not checked it on Windows, where the original problem was found.
> 
> 
> 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: Use consistent path for all *.py scripts

[Boroondas Gupte]

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

Ship it!


Covers all occurrences of the variant with env, so should be fine.

As currently both variants are present, choosing only one of them (no matter 
which) should not hinder anyone who can already use the scripts today (except 
if they only used scripts with one of the variants, up to now.) If we later 
discover that using the other variant would bring any advantage (like, allowing 
to call the script directly rather than prepending the interpreter command) we 
can always make that change later.

- Boroondas


On Jan. 28, 2011, 5:56 p.m., Merov Linden wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> http://codereview.secondlife.com/r/129/
> ---
> 
> (Updated Jan. 28, 2011, 5:56 p.m.)
> 
> 
> Review request for Viewer.
> 
> 
> Summary
> ---
> 
> Simple consistency change, using "#!/usr/bin/python" in all python script.
> 
> 
> This addresses bug STORM-937.
> http://jira.secondlife.com/browse/STORM-937
> 
> 
> Diffs
> -
> 
>   indra/copy_win_scripts/start-client.py b542f8134a2b 
>   indra/develop.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_host_xml_parser.py b542f8134a2b 
>   indra/lib/python/indra/util/simperf_oprof_interface.py b542f8134a2b 
>   indra/lib/python/indra/util/test_win32_manifest.py b542f8134a2b 
>   indra/newview/generate_breakpad_symbols.py b542f8134a2b 
>   scripts/build_version.py b542f8134a2b 
>   scripts/install.py b542f8134a2b 
> 
> Diff: http://codereview.secondlife.com/r/129/diff
> 
> 
> Testing
> ---
> 
> Pulled into a test repo and build successfully on all platforms on TC so I 
> guess no bad surprise here.
> 
> 
> 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