Re: [opensource-dev] Remaining build issues for 64bit linux standalone out-of-source (without unit tests)

[Oz Linden (Scott Lawrence)]

VWR-23296 : missing 
LL_TEST conditions (i.e. SNOW-651 
 *+* SNOW-654 
)


* The ability to turn off building and executing of /all/ unit
  tests is needed to work around other issues (which we'll have to
  fix later)
* Fixed at http://bitbucket.org/boroondas/vwr-23296
* Should be easy to review (but note there are several changesets)



I'm hesitant to move this to the main development branch, because I'd 
rather not make it easy to not do tests.  If they're broken, we should 
instead invest in fixing them (or the means of running them).


I'd like to hear more discussion on this... specifically, what are the 
problems that are causeing the tests not to be useful?


___
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] Remaining build issues for 64bit linux standalone out-of-source (without unit tests)

[WolfPup Lowenhar]

For some of us disabling of the tests means less time actually compiling the
code. Especially if the system the code is being compiled on is an older
system. As an example below is my system specs taken directly from the
current dev build I did over the weekend.

 

CPU: Intel(R) Pentium(R) D CPU 2.80GHz (2800.13 MHz)

Memory: 2046 MB

OS Version: Microsoft Windows 7 32-bit  (Build 7600)

Graphics Card Vendor: NVIDIA Corporation

Graphics Card: GeForce 8500 GT/PCI/SSE2

 

On the above system if I build and run everything from a clean checkout it
will take ~3hrs to do a complete build all the way to packaging. Now if I
turn off the building and running of those test but compile time is cut in
half which means more time for me to test any changes I have made in the
code. I know there are some out there that talk about doing incremental
builds when your testing something and that might be ok for if you make a
minor change the same day you have done a build but if you're making changes
over multiple days it is best to me for the date of the build in about
SecdondLife to be set to the new date each time so you can keep track of
those changes.

 

From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Oz Linden
(Scott Lawrence)
Sent: Monday, October 11, 2010 9:05 AM
To: Boroondas Gupte
Cc: Second Life Open Source Developer Mailing List
Subject: Re: [opensource-dev] Remaining build issues for 64bit linux
standalone out-of-source (without unit tests)

 


VWR-23296  : missing LL_TEST
conditions (i.e. SNOW-651   +
SNOW-654  )

*   The ability to turn off building and executing of all unit tests is
needed to work around other issues (which we'll have to fix later)
*   Fixed at http://bitbucket.org/boroondas/vwr-23296
*   Should be easy to review (but note there are several changesets)


I'm hesitant to move this to the main development branch, because I'd rather
not make it easy to not do tests.  If they're broken, we should instead
invest in fixing them (or the means of running them).

I'd like to hear more discussion on this... specifically, what are the
problems that are causeing the tests not to be useful?

  _  

No virus found in this message.
Checked by AVG - www.avg.com
Version: 10.0.1136 / Virus Database: 422/3190 - Release Date: 10/11/10

___
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] Jira Issue Resolution Issue

[Kent Quirk (Q Linden)]

So we've modified the JIRA system again to allow residents to reopen issues in 
VWR and STORM.

But with power comes responsibility -- we aren't going to tolerate edit wars, 
and we're not going to let JIRA be a place to vent your frustrations with us or 
with each other. Please keep it polite. Reopening because of a mistake or a 
misunderstanding is reasonable, especially when accompanied by a good 
explanation. But reopening because you don't like a decision is a waste of 
everyone's time, and will result in temporary or permanent loss of JIRA access.

I should note that on the Snowstorm team we're trying to aggressively prune 
down JIRA to actionable issues. 

"FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it, 
because it's too broad and unactionable. A summary JIRA with 3 separate 
problems doesn't help us track it, especially when 2 of them have been fixed. 
So we may close these, and we'll try to explain why. If the reason is that we 
can't use the issue the way it's written, then please don't reopen it, write a 
new and better one.

Thanks for your help on this. 
Q

On Oct 8, 2010, at 5:57 PM, Erin Mallory wrote:

> yes we used to have the ability to reopen. and the person in question has 
> closed allot. so have others. its like they dont READ the issue before 
> closing.  to the point i've considered aring them for a form of griefing
> 
> 
> > Date: Fri, 8 Oct 2010 14:00:24 -0700
> > From: br...@slearth.com
> > To: opensource-dev@lists.secondlife.com
> > Subject: [opensource-dev] Jira Issue Resolution Issue
> > 
> > As a user I would like to be able to reopen Jira issues wrongly closed by
> > ignorant people who can't read, creating havok. Like this one there:
> > 
> > Stone Tremont added a comment - 08/Oct/10 2:17 AM
> > This is not a bug because you do not pay prims, avatars are payed via whole
> > objects. This should be a feature request. I have a way to set different
> > prices for variations in vendors, you just need to make a more advanced,
> > intuitive script like mine.
> > 
> > https://jira.secondlife.com/browse/VWR-3048
> > 
> > Please reopen this issue! As per Gigs Taggart's comment, its used to work..
> > It you are going to allow any kiddo to close issues, the same should true
> > for reopening them, or it doesn't make any sense at all.
> > 
> > 
> > ___
> > 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

___
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] Jira Issue Resolution Issue

[Robert Martin]

On Mon, Oct 11, 2010 at 10:44 AM, Kent Quirk (Q Linden)  
wrote:
> If the reason is that we can't use the issue the way it's written, then
> please don't reopen it, write a new and better one.

Just make sure on the Linden side we have a few things laid out
1 if a linden closes a jira then there should be a comment with a
"long form" reason as to why it has been closed then close it

2 if a jira needs an edit/rewrite to be useful then leave a comment as
to why and how
(this is a meta issue , this needs to be split into N jiras for
tracking , fix requires breaking laws of Government/Physics, duplicate
of older jira, fix involves code we are dropping altogether ect)

3 "WorkingOnIt Linden"* should only have an issue assigned for maybe
two weeks since a lot of times WorkingOnIt Linden means BlowingItOff
Linden is actually NOT working on it.

-- 
Robert L Martin

*prove me wrong but if you look in the logs i would almost bet money
that WOI Linden assigned jiras are mostly closed by 1 target version
became outdated 2 no linden actually picked it up 3 some linden closed
it with WONT FIX/ CAN'T FIX or anything that boils down to it not
actually being fixed
___
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] Remaining build issues for 64bit linux standalone out-of-source (without unit tests)

[Oz Linden (Scott Lawrence)]

 On 2010-10-06 18:41, Boroondas Gupte wrote:
A lot of fixes from my previous list 
 
have been integrated by now, so the list of remaining 
not-yet-integrated build fixes for 64bit out-of-source has become a 
lot shorter :-) .


*Please note: Unit tests are currently broken for out-of-source builds 
.* 
Run cmake or develop.py configure with -DLL_TESTS:BOOL=FALSE or 
uncheck LL_TESTS in cmake-gui and reconfigure to disable them if you 
try building out-of-source.


I've isolated the fixes for the remaining issues into repositories of 
their own (except for those that should be pulled together) and turned 
them into daggy fixes to allow for easy merging with as many revisions 
as possible.


VWR-23047  (aka SNOW-512 
/ SNOW-287): PIC required for standalone


* Fixed - On Review (fix at http://bitbucket.org/boroondas/vwr-23047)
* Fixes for VWR-20911
   and SNOW-748
   are also in this
  repository
* Fixes for all 3 issues should be pulled together to avoid breakage


STORM-222 : expat.h not 
found on STANDALONE


* Fixed in http://bitbucket.org/boroondas/storm-222
* Approved by Vadim ProductEngine


VWR-23296 : missing 
LL_TEST conditions (i.e. SNOW-651 
 *+* SNOW-654 
)


* The ability to turn off building and executing of /all/ unit
  tests is needed to work around other issues (which we'll have to
  fix later)
* Fixed at http://bitbucket.org/boroondas/vwr-23296
* Should be easy to review (but note there are several changesets)


STORM-275  (a.k.a. 
VWR-20893): "class Linux_x86_64Manifest" missing from 
viewer_manifest.py Breaking linux 64-bit build.


* Fixed at http://bitbucket.org/boroondas/storm-275




I've posted a build made with all of the above except VWR-23296 (global 
switch to disable tests - see my other reply to this thread) at:

http://automated-builds-secondlife-com.s3.amazonaws.com/hg/repo/oz_viewer-review1/rev/211764/index.html

All platforms built, and since that's what these changes were about it's 
probably good.  The Mac version appears to be working fine - if a few 
people could do a quick smoke test of the other platforms and report all 
clear, then I'll push these changes into viewer-development.


___
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 - Monday, October 11

[Anya Kanevsky]

Date: Mon Oct 11

== GENERAL NOTES ==
* Merge Monkey of the Day:  Merov ... again
* Beta fixes should be done on a beta branch
* With rare exceptions when we need to stabilize and release a beta,
beta fixes should merged into Beta asap.

== DAILY SCRUM ==

=== Merov ===
PAST
* STORM-137: Fixed a last Windows viewer packaging issue. Emailed
chopper on what I did. Asked community members to help me test the
standalone build case. Ready for review.
* SH-277 (Attachments are visible in mouselook mode): Found a 1 liner
fix in the nick on time on Friday evening! Emailed opensource-dev to
get folks to test if that really fixed the issue but didn't get
anything useful. How to
* Finished HR paperwork

FUTURE
* Beta monitoring and merge monkey-ing (merges, try to identify bugs I
can contribute to)
* SH-277 : Finish so we can push a fix on beta.
* STORM-105 : Perf decompression: put new data out, check the work
done by opensource-dev community on similar tests.

IMPEDIMENTS
* None


==Oz Linden==
PAST
* Pester Team Chopper about opening up autobuild
** Plan is to publish at the end of their current sprint (1.5 weeks)
* Pulled build changes to a viewer-development tree and built
** Testing - looks ready to integrate
* Got access and development briefing for web site changes
** (develop.secondlife.com, viewerdirectory.secondlife.com)

FUTURE
* Prep a budget proposal for open build service & code review system
* Start updating develop.secondlife.com

IMPEDIMENTS
* none


=== Q Linden===
PAST
* HR (annual reviews) - mostly done (one left)
* Q4 / 2011 planning - not quite done (sigh)
* Process work (finishing today, I hope)

FUTURE
* Process work
* Unit test working

IMPEDIMENTS
* None


=== Esbee Linden
PAST
* VWR triage
* Q4+ planning
* Systems requirements research
* Reviewed versions, "viewer-development bug queue and viewer 2.2.0
Beta" and prioritized all bugs
* Finished end of year review paperwork

FUTURE
* VWR triage
* Viewer release process review
* Review Snowstorm Jira tickets
* Viewer roadmap/Q4 planning planning
* Systems requirements analysis

IMPEDIMENTS
* None


=== Paul ProductEngine===
PAST:
* STORM-211 Fade timer is reset for all toasts displayed in the
notifications channel
** Fixed

FUTURE:
* STORM-211 Fade timer is reset for all toasts displayed in the
notifications channel
** Carefully test fix

IMPEDIMENTS:
* none

=== Seth Productengine ===
PAST:
* BUG (STORM-289) Internal browser navigation bar disappears after
minimize/restore
** Fixed.

FUTURE:
* BUG (STORM-294) Selection goes out of Favorites overflow list if
scroll it by keyboard
** Estimated: 4-6 hours.

IMPEDIMENTS:
* none

=== Andrew Productengine ===
PAST:
* Major bug STORM-313 (Build parcel property is displayed incorrectly)
** Came across comment in code which led me to EXT-4610 ([BSI] parcel
settings icons do not match parcel settings) where decision to make
the icon the way it is now was made. So this bug seems to be expected
behaviour, but because it wasn't closed as such by Esbee and was
reported by Oz, asked Esbee a question in ticket and will either make
changes or close floater depending on answer.
* Bug  STORM-301 (Camera view remains on Edit Appearance mode after
undocked 'My Appearance' tab was minimized while being in 'Edit
Outfit' mode)
WIP, will finish on Monday. Estimate- 3 hours.
* The 2h+ downtime of grid today made the work a bit slower.

FUTURE:
* STORM-301

IMPEDIMENTS:
* Looked through STORM-182 (Uninstalling a beta client can result in
all chatlogs being deleted as well if logging is left to default
location)- it doesn't seem to be viewer issue- perhaps it should be on
some team that is working on installer, or if just behaviour (not
code) should be investigated and discussed, perhaps this issue is not
for devs.
* STORM-313

=== Vadim Productengine ===
*  OOO - Vacation. Will be back to office on Oct, 11th.

=== Andrey Productengine ===
PAST:
* smoke and regression testing of 2.2.0 Beta 3 on Windows and Mac, see
DRTVWR-9 for details
* verified tickets linked to DRTVWR-7 on Beta 3 build

FUTURE:
* return to viewer-development builds testing

IMPEDIMENTS:
* none

=== Grumpity ProductEngine ===
PAST
* crashhunters, another monday
* getting access for QA

FUTURE:
* QA synch notes & followup
* take STORM-315 from Esbee and split it.
* crashhunters
* STORM - 313
* STORM- 182
* etherpad for updates?

IMPEDIMENTS:
* none
___
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] SHH-277

[Ponzu]

Merov said...
* SH-277 (Attachments are visible in mouselook mode): Found a 1 liner
fix in the nick on time on Friday evening! Emailed opensource-dev to
get folks to test if that really fixed the issue but didn't get
anything useful.

Lee says...

It looks like the right fix to me.  I also looked at the code a little bit.
There is other email about that.
___
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] Remaining build issues for 64bit linux standalone out-of-source (without unit tests)

[Boroondas Gupte]

 On 10/11/2010 03:05 PM, Oz Linden (Scott Lawrence) wrote:
>>
>> VWR-23296 : missing
>> LL_TEST conditions (i.e. SNOW-651
>>  *+* SNOW-654
>> )
>>
>> * The ability to turn off building and executing of /all/ unit
>>   tests is needed to work around other issues (which we'll have
>>   to fix later)
>> * Fixed at http://bitbucket.org/boroondas/vwr-23296
>> * Should be easy to review (but note there are several changesets)
>>
>
> I'm hesitant to move this to the main development branch, because I'd
> rather not make it easy to not do tests.  If they're broken, we should
> instead invest in fixing them (or the means of running them).
As I've already stated in a jira comment
,
I don't think this is a question of either-or. As long as we /have/ the
LL_TESTS option (and I haven't introduced it, it was already there), it
should do what its name suggests. *This shouldn't stop us from fixing
the tests.* In fact, my plan for the time after having gotten all build
fixes I need with LL_TESTS set to FALSE into viewer-development (which I
hope will be soon) was to set LL_TESTS back on TRUE and hunt down the
change(s) needed to build like that. (We already had these fixes in
Snowglobe 2. I hope nothing new got broken regarding unit tests, since
then.)

Even once the tests can be run on all platforms, we /might/ want to keep
the LL_TESTS option around for the following cases:

* Developer A breaks a tests, but this only manifests on Developer
  B's platform (thus A didn't catch it during his/her own builds).
  Developer B isn't able to fix A's mistake (not B's area of
  expertise), but would like to continue his/her own development
  based on the newest code and of course test whether it at least
  builds (and maybe test new or fixed functionality). B would file a
  bug about the broken test (probably to be fixed by A), set
  LL_TESTS to FALSE and continue development. Hopefully, the broken
  test gets fixed before B's development is ready for integration,
  so B can then set LL_TESTS back to TRUE for a final test before
  his/her stuff ends up in viewer-development. If the test can't be
  fixed in time, the test-breaking commit should probably be backed out.
* Developer C has a slow machine and is working on something of
  which he/she assumes that it isn't unit tested anyway, yet, or
  that his/her change is easy and save enough to be very unlikely to
  break any tests. During development, C does several builds with
  LL_TESTS set to FALSE to get shorter build times. Only before
  requesting integration, C does a final build with LL_TESTS turned
  back on.

Of course, for the first scenario, it would be good to be able to only
disable the offending test and keep the other tests in place. But for
now, the all-or-nothing LL_TESTS is what we have. (Short of editing
CMake scripts.)

> I'd like to hear more discussion on this... specifically, what are the
> problems that are causeing the tests not to be useful?
They would be useful if the system for running them wasn't broken. When
I set LL_TESTS to TRUE, I currently get errors like this:

[ 10%] Generating PROJECT_llmath_TEST_llbboxlocal_ok.txt
LD_LIBRARY_PATH += ['/usr/lib']
LD_LIBRARY_PATH = '/usr/lib'
Running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal 
--touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt 
--sourcedir=${SRC_DIR}/indra/llmath
${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal: error while loading 
shared libraries: libllcommon.so: cannot open shared object file: No such file 
or directory
Failure running: ${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal 
--touch=${BUILD_DIR}/llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt 
--sourcedir=${SRC_DIR}/indra/llmath
Error: 127
make[2]: *** [llmath/PROJECT_llmath_TEST_llbboxlocal_ok.txt] Error 127
make[1]: *** [llmath/CMakeFiles/llmath_tests.dir/all] Error 2
make: *** [all] Error 2

I.e., LD_LIBRARY_PATH is missing some entry. When building parallel, I
see equivalent errors about other unit tests.

Why should we fix VWR-23296
 first and the unit test
execution later? Simple: As long as unit test execution is broken, it's
easier to tell whether we've fixed VWR-23296 completely (i.e. have
wrapped ALL adding of test targets into LL_TESTS conditions). Not that
grepping for "\o/" would be difficult, but yeah ... you get the idea.

Cheers,
Boroondas
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before post

Re: [opensource-dev] Jira Issue Resolution Issue

[Bryon Ruxton]

Thanks Q

>reopening because you don't like a decision is a waste of everyone's time, and
will result in temporary or permanent loss of JIRA access.
Sounds good to me.

On 10/11/10 7:44 AM, "Kent Quirk (Q Linden)"  wrote:

> So we've modified the JIRA system again to allow residents to reopen issues in
> VWR and STORM.
> 
> But with power comes responsibility -- we aren't going to tolerate edit wars,
> and we're not going to let JIRA be a place to vent your frustrations with us
> or with each other. Please keep it polite. Reopening because of a mistake or a
> misunderstanding is reasonable, especially when accompanied by a good
> explanation. But reopening because you don't like a decision is a waste of
> everyone's time, and will result in temporary or permanent loss of JIRA
> access.
> 
> I should note that on the Snowstorm team we're trying to aggressively prune
> down JIRA to actionable issues.
> 
> "FIX LAG" is not a useful JIRA to us, even if you don't think we've fixed it,
> because it's too broad and unactionable. A summary JIRA with 3 separate
> problems doesn't help us track it, especially when 2 of them have been fixed.
> So we may close these, and we'll try to explain why. If the reason is that we
> can't use the issue the way it's written, then please don't reopen it, write a
> new and better one.
> 
> Thanks for your help on this.
> Q

___
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] Jira Issue Resolution Issue

[Gigs]

On 10/11/2010 12:44 PM, Robert Martin wrote:
> 3 "WorkingOnIt Linden"* should only have an issue assigned for maybe
> two weeks since a lot of times WorkingOnIt Linden means BlowingItOff
> Linden is actually NOT working on it.


Workingonit Linden should have never been created.  "Working on it" 
should be represented as a workflow status, not as a fake account.

-Jason
___
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] opensource-dev Digest, Vol 9, Issue 27

[Richard Nelson]

Just create a combo_box like this:

  
 
 
 
 
 
   

and put it in the proper spot in floater_tools.xml and everything should  
just work.

FWIW, I recommend doing development of XUI in your OS-equivalent  
Application Data directory:

on Windows 7, for example, copy floater_tools.xml to  
c:\users\your_account\application  
data\roaming\secondlife\skins\default\xui\en\ and edit in place.

Enjoy.

R.


On Wed, 06 Oct 2010 20:25:30 -0700, Kent Quirk (Q Linden)  
 wrote:

> That sort of thing is more involved, I'm afraid; you have to change the  
> control. I don't know offhand if the XUI commit binding mechanism can be  
> made to work with only XUI change -- I kind of doubt it. If not, you'll  
> have to  change the c++ event handlers from 4 individual event handlers  
> to one that does all 4 things on change of the combo_box.
>
> It's probably worth some spelunking through XUI to see if there's an  
> example of binding the combo box; if not, I bet one of the devs around  
> here would help you write the C++ changes to make it work.
>
> Q
>
> On Oct 6, 2010, at 11:04 PM, SuezanneC Baskerville wrote:
>
>> Thanks, Kent, I'm glad I asked.
>>
>> The keystroke, by the way,  appears to be Control Shift T, not Control  
>> Alt T,  on my XP system running the Development Viewer.
>>
>> I'd like to replace the Focus, Move, Edit, Create, and Land buttons  
>> with a list, I suppose a combo_box, to save horizontal space.  How does  
>> one do that?
>>
>>
>> --
>>
>> Message: 7
>> Date: Wed, 6 Oct 2010 22:30:51 -0400
>> From: "Kent Quirk (Q Linden)" 
>> Subject: Re: [opensource-dev] How is the XUI part of the interface
>>designed?
>>
>> There's no GUI editor. However, there is a nice little assistance tool.  
>> From the login screen ONLY, you can invoke the GUI Preview tool by  
>> hitting alt-ctrl-T (or cmd-ctrl-T on a Mac). It will bring up a dialog  
>> that you can use to display any of our dialog boxes, in two languages  
>> at once if you want. If you configure it, you can also have it open the  
>> dialog file in your text editor, and the "show rectangles" checkbox  
>> makes it easy to see which parts of the dialog have which names.
>>
>> If you edit a dialog, you can show and hide it, and it will reload. So  
>> you should be able to experiment with a layout rather easily; it's not  
>> a live graphical editor, but it makes it pretty easy to edit. Just  
>> realize the dialogs are not "live", and so sometimes things won't look  
>> right, or may have overlapping fields because only one of them is  
>> visible at any given time.
>>
>>Q
>>
>> ___
>> 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
>


-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/
___
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] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests))

[Boroondas Gupte]

 On 10/11/2010 10:12 PM, Boroondas Gupte wrote:
> In fact, my plan for the time after having gotten all build fixes I
> need with LL_TESTS set to FALSE into viewer-development (which I hope
> will be soon) was to set LL_TESTS back on TRUE and hunt down the
> change(s) needed to build like that. (We already had these fixes in
> Snowglobe 2. I hope nothing new got broken regarding unit tests, since
> then.)
Looks like Aleric's patch from SNOW-756

(which still applies  :-) ) is all that's needed, so I moved that to
VWR-23385  and will
daggify that fix ASAP.
With this change, all tests succeed on my machine.


  YAY!! \o/

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] LL_TESTS for standalone out-of-source builds (was: Remaining build issues for 64bit linux standalone out-of-source (without unit tests))

[CG Linden]

Yay \o/ for "daggifying" :)
--
cg

On Mon, Oct 11, 2010 at 3:10 PM, Boroondas Gupte  wrote:

>  On 10/11/2010 10:12 PM, Boroondas Gupte wrote:
>
> In fact, my plan for the time after having gotten all build fixes I need
> with LL_TESTS set to FALSE into viewer-development (which I hope will be
> soon) was to set LL_TESTS back on TRUE and hunt down the change(s) needed
> to build like that. (We already had these fixes in Snowglobe 2. I hope
> nothing new got broken regarding unit tests, since then.)
>
> Looks like Aleric's patch from 
> SNOW-756(which
>  still applies :-) )
> is all that's needed, so I moved that to 
> VWR-23385and will daggify that 
> fix ASAP.
> With this change, all tests succeed on my machine.
>  YAY!! \o/ 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
>
___
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] tos acceptance issues

[Anya Kanevsky]

Erin,
Is there a JIRA that details which builds and which versions of 2.x
presented this problem? Repro steps? Which accounts were and were not
allowed to accept TOS?

Thank you,
Anya

2010/10/8 Erin Mallory :
> As a user, it would be nice if the 2.x versions of SL would allow ALL
> accounts to accept the new terms of service instead of denying that option
> to all/some of them.
> Depending on the build, some versions of 2.x do not allow any accounts to
> accept tos even after cancel and reattempt.  Some allow only some accounts
> to do so.  this is like the third time this bug has resurfaced.  can we
> please fix it so everyone can log in?
>
> ___
> 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] simconsole is available for experimentation

[Andrew Meadows]

As mentioned in my office hours, and Oskar Linden's office hours last
week:

Thanks to Brad and Falcon Linden the SL simulator will soon support a
very simple command line interface (CLI) console we're calling "simconsole".
The motivation for it was primarily for debug and prototyping, and
the list of commands available is currently very short, but we'll add
some more soon and maybe it will become a useful tool for intrepid
Residents.

The simulator support is currently on the beta grid (aditi).  It was just
promoted to the "Second Life Beta Server" channel today so is on most of
the regions there.  It was previously on just four regions using the
"andrew-maint-server" channel.

In order to play around with the simconsole you need viewer UI support.
I've just created a bitbucket clone of lindenlab/viewer-development with
the simconsole UI added for those who want to build and play around with
it.  Clone or pull from here:

http://bitbucket.org/andrew_linden/viewer-development

To open the console type:  CTRL + SHIFT + `  (CTRL + SHIFT + backtick)

I think there is a "help" command, but otherwise there isn't any
documentation yet.

You'll have to be an LL admin or estate manager to run any of the
commands that change anything.

- Andrew
___
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] LL_TESTS for standalone out-of-source builds

[Boroondas Gupte]

 On 10/12/2010 12:21 AM, CG Linden wrote:
> Yay \o/ for "daggifying" :)
Done: http://bitbucket.org/boroondas/vwr-23385
Ready for review.

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] Translate hotkey?

[miss c]

Is there a translate hotkey, command or setting in the viewer that will 
translate note cards into your viewer language?

Thanks,

Miss



  ___
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] tos acceptance issues

[Erin Mallory]

theres already jiras about it yes. I do not have the numbers on hand, though i 
think somone else might have already mentioned the jira numbers.

> From: akanev...@productengine.com
> Date: Mon, 11 Oct 2010 15:57:22 -0700
> Subject: Re: [opensource-dev] tos acceptance issues
> To: angel_of_crim...@hotmail.com
> CC: opensource-dev@lists.secondlife.com
> 
> Erin,
> Is there a JIRA that details which builds and which versions of 2.x
> presented this problem? Repro steps? Which accounts were and were not
> allowed to accept TOS?
> 
> Thank you,
> Anya
> 
> 2010/10/8 Erin Mallory :
> > As a user, it would be nice if the 2.x versions of SL would allow ALL
> > accounts to accept the new terms of service instead of denying that option
> > to all/some of them.
> > Depending on the build, some versions of 2.x do not allow any accounts to
> > accept tos even after cancel and reattempt.  Some allow only some accounts
> > to do so.  this is like the third time this bug has resurfaced.  can we
> > please fix it so everyone can log in?
> >
> > ___
> > 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] Corrupted OpenGL & Hard Crash

[Stickman]

> Has anyone else run across anything remotely similar?  I've done a
> cursory search of the JIRA, but nothing seemed to match for me.

Only time I've seen stuff like this was during GPU overheating,
usually when a fan fails. It wasn't quite like this, however. More
random data rather than rearranged data. But maybe a Mac handles it
differently. And maybe it's not overheating at all.

First thing I'd do, however, was check temperatures and make sure you
don't have a cooling failure somewhere.

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