Re: [opensource-dev] viewer-release vs The Penguins

[Nicky D.]

On Thu, Feb 6, 2020 at 11:51 PM monty  wrote:

> On 2/6/2020 6:05, Nicky D. wrote:
>
> > The main reason why this happened is LL not wanting to have their own
> > Linux viewer depend on many 3Ps but rather use as much standalone
> > that you can find on a Linux system. That led to either snap, flatpak or
> > AppImage.
>
> I'm certainly interested in what you discover in containerizing the
> viewer.  Distribution size, edge cases where things go wrong.  Dropping
> it into a wsl2 instance on windows to see what happens...
>
>
This is not really the scope of this viewer. It should provide an option to
run the "official"
viewer on Linux. For example FS support often asks if someone tried to
reproduce  their
issue on the official viewer. To test if it's a problem specific to
Firestorm or a generic one.

Speaking about docker or WSL2 in general, both are not made for GUI
application. And while\
you could do something by using a remote  display, performance won't be
something you have
fun with. If the viewer starts at all and can use that display.

Cheers,
  Nicky
___
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] viewer-release vs The Penguins

[Nicky D.]

On Thu, Feb 6, 2020 at 11:45 AM Henri Beauchamp  wrote:

> On Tue, 4 Feb 2020 22:28:53 +0100, Nicky D. wrote:
>
> > it has been a while since LL released their last Linux capable viewer. To
> > get things started
> > again I brought 6.3.6 up to Linux support:
> > https://bitbucket.org/NickyD/viewer-linux
> > https://bitbucket.org/NickyD/viewer-flatpak   (for the flatpak build
> > scripts)
> >
> > As I know the chances to see a penguin fly are bigger than get a release
> > from LL, I also created a flatpak that users can install and run
> > (instructions below).
>
> I fail to see the advantage of a flatpak, when the current distribution
> method (i.e. bundling libraries that are likely to lack on the user's
> system, or that have been patched) do work nicely... Flatpaks are huge
> and bloated with stuff that the viewer won't really need (but are just
> non-essential dependencies to some libraries it uses).
>
> The main reason why this happened is LL not wanting to have their own
Linux viewer depend on many 3Ps but rather use as much standalone
that you can find on a Linux system. That led to either snap, flatpak or
AppImage.

Of course then due to time constraints they never picked it up. But that's
the reason behind the current format. It is based on what I did for LL.


> > - Uses GTK3 instead of GTK2, again to not have to compile the old GTK
> > version.
>
> I solved the GTK dependency a looong while ago... By removing it
> entirely !
>
>
I know. I already looked at it for Firestorm. But LL won't let you
contribute this
as we know due to their CA standards.
I'd really like to get rid of the GTK dependency. Even if only for
Firestorm.

As long as we're speaking about a viewer LL might want to integrate
(debatable
if it ever happens), taking contributions of others is out of the question.
Taking
contribution from others without CA is completely unthinkable.


> > - It's obviously unsupported.
>
> I provided and kept up to date the sources for a Linux-compatible Dullahan
> since November 2015 on my site... That could count as "support", I think...
> :-D
>
>
Hehe I meant the viewer is unsupported. Everyone but LL has dullahan for
Linux since ages. Then again LL has no Linux viewer since ages either.


> Another thing you might want to look at is getting rid of the deprecated,
> unsupported and utterly buggy dbus-glib dependency. I solved this a long
> time ago by coding DBus support based on glib-gio (see llappviewerlinux.cpp
> in my viewer sources): it's very clean and small code, that also does
> properly work (dbus-glib got a timeout bug, unless you use a very old
> version that no distro would provide any more nowadays, anyway).
>
>
>
I'm going to look at that. Thank you for the input. Again though likely
going to
look at it for Firestorm.
___
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] viewer-release vs The Penguins

[Nicky D.]

it has been a while since LL released their last Linux capable viewer. To
get things started
again I brought 6.3.6 up to Linux support:
https://bitbucket.org/NickyD/viewer-linux
https://bitbucket.org/NickyD/viewer-flatpak   (for the flatpak build
scripts)

As I know the chances to see a penguin fly are bigger than get a release
from
LL, I also created a flatpak that users can install and run (instructions
below).
I'm still pondering to make an AppImage from it, but that's something for
another day.

Differences in the Linux version:
- Uses SDL2 rather than SDL (so the "OS" version can be used).
- Uses GTK3 instead of GTK2, again to not have to compile the old GTK
version.
- OpenAL instead of FMODEX, there's no way to download FMODEX anymore. Once
FMOD Studio gets into the viewer I add it to the Linux release.
- No KDU. I obviously don't have access to LLs version of KDU and won't use
the one I have for Firestorm.
- GStreamer 1.0 instead of VLC. GStreamer being part of the OS it gets
updated by the OS (Flatpak in this case) rather than shipping some ancient
VLC version.
- dullahan/CEF is added. So it got the usual web browser as Windows/OSX got.
- It's obviously unsupported.

The flatpak is hosted by The Phoenix Firestorm Project Inc. (
https://www.firestormviewer.org/about/) but could easily hosted by any
webserver or say AWS/S3.

Installation:
flatpak is needed and must be installed via the distros usual ways (
https://flatpak.org/setup/)
Then the viewer can be installed either system or user specific:

Add Flatpak repo

   - Systemwide:
   - flatpak remote-add viewer-builds
  https://flatpak.firestormviewer.org/viewer.flatpakrepo
  - User install
   - flatpak remote-add --user viewer-builds
  https://flatpak.firestormviewer.org/viewer.flatpakrepo

Install viewer (it will give the option which branch, stable has the
advantage that it can be updated as new released get added):

   - Systemwide:
   - flatpak install viewer-builds viewer-release
  - User install
   - flatpak install --user viewer-builds viewer-release

Run the viewer

   - flatpak run org.lindenlab.viewer-release


Cheers,
   Nicky
___
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 ReleaseOS build unable to load textures

[Nicky D.]

Try with an openjpeg version build from this repository:
https://bitbucket.org/NickyD/p64_3p-openjpeg

https://bitbucket.org/NickyD/p64_3p-openjpeg/commits/9c2e80ac43f67040ee8870a92ac9f05ee00c2020

Is probably fixing your issue

On Mon, Feb 11, 2019 at 11:15 AM Kadah  wrote:

> I'm working on a thing (some of you know what) and I've run in to a
> rather annoying issue that's sunk most of the day as it was starting to
> make testing difficult.
>
> None of my ReleaseOS viewer-release builds are able to load textures.
> I've found that it's fine if I patch in KDU. While that is a workaround,
> it would be nice to know what I'm doing that makes OpenJPEG fail,
> assuming it does work at all.
>
> Every texture request is generating the following on a clean build of
> viewer-release:
> WARNING   LLViewerFetchedTexture::updateFetch : oversize, setting as
> missing
> WARNING   LLViewerFetchedTexture::setIsMissingAsset :
> dc60d326-ba27-db3a-103a-e378d6dd2530: Marking image as missing
>
> To get at least something more, I added a debug output from FS to
> updateFetch (). Output was such:
>
>   INFO   LLViewerFetchedTexture::updateFetch : Discarding oversized
> texture, width= 4096, height= 4096
>   WARNING   LLViewerFetchedTexture::updateFetch : oversize, setting as
> missing
>   WARNING   LLViewerFetchedTexture::setIsMissingAsset :
> dc60d326-ba27-db3a-103a-e378d6dd2530: Marking image as missing
>   INFO   LLViewerFetchedTexture::updateFetch : Discarding oversized
> texture, width= 16384, height= 16384
>   WARNING   LLViewerFetchedTexture::updateFetch : oversize, setting as
> missing
>   WARNING   LLViewerFetchedTexture::setIsMissingAsset :
> 2aa5fd81-464f-3b76-40a7-f498a1561b76: Marking image as missing
>   INFO   LLViewerFetchedTexture::updateFetch : Discarding oversized
> texture, width= 2048, height= 8192
>   WARNING   LLViewerFetchedTexture::updateFetch : oversize, setting as
> missing
>   WARNING   LLViewerFetchedTexture::setIsMissingAsset :
> 2c007a7c-11c1-5748-e1a8-a77806efa9e3: Marking image as missing
>   INFO   LLViewerFetchedTexture::updateFetch : Discarding oversized
> texture, width= 1024, height= 4096
>   WARNING   LLViewerFetchedTexture::updateFetch : oversize, setting as
> missing
>   WARNING   LLViewerFetchedTexture::setIsMissingAsset :
> 50a3b5d7-f32f-41ce-ff7a-450a4bbf1e8f: Marking image as missing
>
> All but the 16384 ones appear sane.
>
> Autobuild config invocation:
> setx AUTOBUILD_VARIABLES_FILE
> "C:\Users\Kadah\Desktop\Dev\viewer-build-variables\variables"
> autobuild configure -c ReleaseOS -A 64
>
>
> Full viewer logs:
> https://pastebin.com/yzswgNnm
> https://pastebin.com/WeiYf2G7
>
> Viewer about:
> Within build VM: https://pastebin.com/Q1tKdw2U
> Installed on host: https://pastebin.com/PeyLBEiN
>
> Any help would be appreciated.
> ___
> 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] Linux

[Nicky D.]

>
> For the time being, we expect that it will be based on the current system,
> modified to use system libraries rather than autobuild packages that build a
> static executable (some packages will be used in our builds for proprietary
> components).  I'm not sure that answers your question...
>

This is the old Squeeze based Debian?

> Granted, *.deb is a much used package manager for debian and derived
> distros. Will any other distro package managers be developed? I assume the
> answer is no so, will OS developer submissions of other package manager
> formats be accepted?
>
> Let's worry about getting one to work... if we're wildly successful with
> that and there's a good reason to do something else, we'll discuss it.

I'm not sure yet what to make out of this change, as we possible need
to see a deb to see
about some of the consequences. Just a few thoughts:

- Standalone is afaik broken since a long time, for example there is
missing FindXXX.cmake
files for various packages.

- As far as I know are there no system packages for (at least) glod,
colladadom, breakpad and cef.

- Some distributions only ship openjpeg2, not 1.4 or 1.5 (for example
I cannot find anything older than 2
for Debian Wheezy). Possibly this can be worked around with non
standard deb repositories in apt.conf.

- Compiling the deb eg on Squeeze and trying to install it on
something Wheezy based could lead to
interesting results, due to the dependent packages from the Squeeze
system being recorded in the deb.
(Or compiling on Wheezy and installing on Jessie and so on).

- VLC: Henri pointed out a few times, that the VLC api is not exactly
stable between releases.

- Boost will be interesting
___
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] 64 bit viewers build instructions

[Nicky D.]

>
> set (ENV{LL_BUILD} $ENV{LL_BUILD_WINDOWS_RELEASE})
> #message(STATUS "LL_BUILD = '$ENV{LL_BUILD}'")
> if ("$ENV{LL_BUILD}" STREQUAL "")
>   message(FATAL_ERROR "Environment variable LL_BUILD must be set")
> endif ()
>
> Above allows configure to complete, but I would like a better place or
> better yet some autobuild involvement to set LL_BUILD based to the chosen
> Release, RelWithDebugInfo, Debug build.
>
>
>
Autobuild tries to do this by some machinery in source environment, but it
fails because you use ReleaseOS. I did encounter the same problem just a
few minutes ago
with ReleaseFS and had to edit the file variables in the build-variables
repository.
Once I added a variable for the configuration, LL_BUILD will be set as
desired.

https://bitbucket.org/NickyD/viewer-build-variables/commits/cfab877696c6a35af1d80e5d17ea7acfffa6c762
___
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 build issues

[Nicky D.]

You do not
need 
-DFS_UPGRADECODES=e9d0370c-6823-4d10-986b-84e2fccf8789,bac88ff0-1a28-4fd4-aa0b-9f1e3eb8269b
anymore, but this is harmless.

I noticed you use:
autobuild ... -- *"*...*"*

Does it make a difference if you do not use " after -- and at the end of
the line? I never tried to quote everything after the --, but can see how
this could cause issues.

On Wed, Jan 4, 2017 at 10:20 PM, Lance Corrimal 
wrote:

> and again: autobuild itself seems to work, at least it starts to work. it
> dies at the point where it tries to download the prebuild packages.
> here is the complete output of my problem:
>
> http://susepaste.org/33664691
>
>
>
>
>
> Am 04.01.2017 um 19:58 schrieb Nicky Perian:
>
> cd into local repo  firestorm, viewer-release are any other.
> From there enter autobuild --version  an absolute path should not be
> needed to reach autobuild.
> It should give the version, If not, your path is not set or you may need
> to set AUTOBUILD='pathtoautobuild/bin/autobuild' environment variable.
>
>
>
>
> On Wed, Jan 4, 2017 at 12:20 PM, Lance Corrimal  > wrote:
>
>> that's what i'm using. Like I said already, I had to reinstall my
>> computer, before that I had been building viewers all the time, 32bit and
>> 64bit, no problems whatsoever.
>>
>> Now, it doesn't work with some error that looks like autobuild isn't
>> downloading the prebuilts.
>>
>>
>> Any ideas?
>>
>>
>>
>> Am 04.01.2017 um 19:15 schrieb Whirly Fizzle:
>>
>> If you are building Firestorm 64bit, you must use Nicky Dasmijn's
>> autobuild: https://bitbucket.org/NickyD/autobuild-1.0
>> NickyD / autobuild-1.0 
>> bitbucket.org
>> Hg repository hosted by Bitbucket.
>>
>>
>>
>> --
>> *From:* opensource-dev-boun...@lists.secondlife.com
>> 
>>  on behalf of Lance
>> Corrimal  
>> *Sent:* 04 January 2017 14:12
>> *To:* Oz Linden (Scott Lawrence); opensource-dev@lists.secondlife.com
>> *Subject:* Re: [opensource-dev] windows build issues
>>
>>
>> actually I'm building the firestorm developer version, and that used to
>> work just fine until I reinstalled my PC yesterday ;_;
>>
>> Am 04.01.2017 um 15:01 schrieb Oz Linden (Scott Lawrence):
>>
>> On 2017-01-04 08:15 , Lance Corrimal wrote:
>>
>> d:\Users\lemmy\Build\autobuild-1.0>autobuild --version
>> autobuild 1.0
>>
>>
>> d:\Users\lemmy\Build\autobuild-1.0>which autobuild
>> /cygdrive/d/Users/lemmy/Build/autobuild-1.0/bin/autobuild
>> 64bit here.. using your autobuild, which used to work just fine before I
>> reinstalled my PC...
>>
>> If you're trying to build viewer64 you should be aware that it's still a
>> Work In Progress and has some limitations... Also, building that repository
>> requires using autobuild-1.1 (https://bitbucket.org/lindenl
>> ab/autobuild-1.1). All this will be updated on the wiki once this
>> project has reached the Release Candidate stage.
>> lindenlab / autobuild-1.1 
>> bitbucket.org
>> Hg repository hosted by Bitbucket.
>>
>> --
>> OZ LINDEN | Engineering Director, Second Life email or hangouts:
>> o...@lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual
>> Experiences 
>>
>> ___
>> 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/wik
>> i/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] Replacement for QuickTime media plugin - a straw man proposal

[Nicky D.]

>
>
>
> I can confirm that it does build properly and results in a functional
> CEF3 plugin with MP4 & Co support (tested in a private build of the
> Cool VL Viewer, with the mime_types.xml file edited to replace all
> plugins with the CEF3 plugin): no more "You have requested a file
> download, which is not supported within the viewer." issue...
>
>
Same here. I can confirm the 2623 (Chromium 49) branch builds fine at least
with Ubuntu 14.04
as 32 and 64 bit. the 32 bit executable is Debian Wheezy compatible, the
x64 not.
i have to try to rebuild that on Wheezy x64 and then go for Windows.

Regarding VLC: Note that the project Viewer LL made already uses VLC for
Linux.
___
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] Firewall block of media files

[Nicky D.]

> At one time we could play individual media files on both parcel media and
> MOAP such as mov avi wmv that were stored on services such as Dropbox.
> I noticed will testing viewer-release-vlc that it these are not allowed.
>
> There is a notice that these files cannot be downloaded to SecondLife.
>
> Are you sure the files get correctly handled by the new vlc plugin rather
than media_plugin_cef? That sounds a bit like the cef popup
which informs the user file downloads are not allowed.
___
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] Replacement for QuickTime media plugin - a straw man proposal

[Nicky D.]

>
> Yep, that's a concern - I believe we used QuickTime to play MP3s too so
> that would be even more wasteful.
>
>
The Quicktime plugin is used for a lot of content. And yes, you are correct
it is used to MP3 when it is used as MOAP.



> The answer might be to do this anyway so we enable videos embedded in web
> content, play video URLs with the LibVLC plugin and come up with a
> lightweight solution (FMODEx??) for MP3s.
>


I am in favor of enabling those codecs for CEF, for the sake of being able
to play a lot more (HTML5) content inside CEF than we can do now.
If resources for the whole media change so scarce that that the question
would be CEF or mostly no MOAP at all, then CEF would
be a solution. Mind you not the best one, but at least better than nothing.
Otherwise I prefer using gstreamer or VLC for MOAP and the codecs in CEF
just so they work in the browser.
I know there is demand for those, there is also two Jiras for that, so TVs
can use HTML5. I can dig those two Jira up (or ask Whirly)
if people are interested in the tickets.
___
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] Replacement for QuickTime media plugin - a straw man proposal

[Nicky D.]

>
> The two technologies that seemed like they might work were identified as
> GStreamer and LibVLC. The former was an attractive option since that was
> already used in the Linux viewer. The existing GStreamer media plugin code
> was somewhat complex and unknown to me whereas playback of a stream in
> LibVLC seemed very straightforward and I had toyed with it in the past.
>
>
The complexity IMO comes from two sources:
A) The original author did opt do resolve all the gstreamer functions via
dso loading and getting the needed symbols out of the dll/so/dylib at
runtime. This adds a lot of boilerplate code.
B) Implementing a gstreamer video plugin. I am not sure why this was done.
You should be able to get the same result with an appsink and probably a
videoscale filter.

Getting rid of B makes porting to gstreamer 1.0 almost trivial. I played
with that a good while ago, but I did not bother to add the videoscale
filter, so the result was not correct.

Taking it to Windows from there should be mostly trivial, but the devil
might be in the details there.

Regarding VLC, afaik some parts (some plugins for example) are still GPL? I
am not sure about the implications of that.

If the lawyers are okay with libvlc / gstreamer, what about enabling
proprietary in CEF in addition. Not to use CEF as the media plugin, but to
allowed it to play embedded media.
___
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] Quicktime

[Nicky D.]

>
> So it's not an obstacle but merely a limitaion. Note also that the CEF
> plugin will be faced with the *exact same* patent issues if it is to be
> used in place of the QuickTime plugin to play video and audio media files
> (which, like I explained and what you agreed with, is just "YUCK !" :-D ).
>
> This is correct and the reason why CEF when using the prebuild version
does not
include the proprietary codecs.

But when we're already on the topic of codecs and licenses, I think fmodex
might fall into the same category. It can decode MP3 and does not come
with a license for it: http://www.fmod.org/mp3license/

Also if, and I am speaking purely hypothetical here, LL would ban Quicktime
and with that MP4 from their viewer and not have a alternate solution, I
guess
the whole point is moot anyway. I suppose shipping those codecs and being
able to play those streams would be a shared experience violation then.

Cheers,
   Nicky
___
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] Current viewer-release source does not build, linker fails inside lltest

[Nicky D.]

You have three choices:

1) Use GCC 4.6, which seems out of the question of Suse.
2) Use ld.gold instead of gnu.ld.
3) Compile your own boost (and colladadom)

On Thu, May 21, 2015 at 11:14 AM, Lance Corrimal lance.corri...@eregion.de
wrote:

 Hi,

 I'm trying to build the current viewer-release source, and I get a
 failure during linking:

 [ 1971s] Linking CXX executable lltest
 [ 1973s]
 `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev'
 referenced in section
 `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED1Ev]'
 of
 /home/abuild/rpmbuild/BUILD/viewer-release/build-linux-i686/packages/lib/release/libboost_regex-mt.a(instances.o):
 defined in discarded section
 `.text._ZN5boost16exception_detail19error_info_injectorISt11logic_errorED2Ev[_ZN5boost16exception_detail19error_info_injectorISt11logic_errorED5Ev]'
 of
 /home/abuild/rpmbuild/BUILD/viewer-release/build-linux-i686/packages/lib/release/libboost_regex-mt.a(instances.o)
 [ 1973s] collect2: error: ld returned 1 exit status

 Looks to me as if the libboost does not match... what can I do?


 cheers
 LC


 ___
 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] Viewer Tools Upgrades - with a call for help

[Nicky D.]

 Autobuild is installed into Python27/scripts -- can this be moved out
 of that package's tree?


You can try to install it into its own virtual-env. I do that with llbase.
autobuild itself I run just
from a bitbucket clone.
So I did not try to put it into a virtual-env, but that should too.

Nicky
___
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] Replacement class for LLDynamicArray

[Nicky D.]

  I notice operator[](i) is used in the interesting,

 With std::vector, you could also use array.at(i), which is equivalent.


vector::at will do a runtime check if the index is out of bounds, in that
case it throws
an exception.

vector::operator[] will not do this check, causing undefined behavior when
accessing
elements out of bounds.

Nicky
___
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] Replacement class for LLDynamicArray

[Nicky D.]

 True, but on the other hand, you'd never call array[i] with i out of
 array bound (it would be a bug, and throwing an exception via the use
 of at(i) is no better than undefined behaviour

that will also lead to a crash in the end).


Wrong. See Heartbleed.  It depends on if the page behind the last element
is valid and how you use the memory. That's why it is undefined. Because
no one can say.
The exception at least would have terminated the buggy code and not sent
private sessions keys to someone else.
It's buggy no matter what, agreed to that. But at at least in one case it
goes
down right away without happily processing whatever data first.

The fact that array[i] doesn't check the upper
 bound also makes it faster than array.at(i): competent programmers who
 do check for bounds where actually needed will therefore prefer
 array[i] to array.at(i), esspecially when used in a loop !


Agreed.

Nicky
___
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] Replacement class for LLDynamicArray

[Nicky D.]

 Slight tweak: [] on out of bounds members is undefined, but specific
 implementations may still check.

 Most (maybe even all) STL implementations support bounds checking with a
 compile flag. If anyone's eager to experiment, it would be nice to add that
 to the debug build flags and see if debugging performance is still
 tolerable on all platforms.


Visual Studio controls this in various forms via
_ITERATOR_DEBUG_LEVEL/_SECURE_SCL and _HAS_ITERATOR_DEBUGGING. To my
knowledge is this enabled for any Windows debug build.

Nicky
___
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] STANDALONE - USESYSTEMLIBS

[Nicky D.]

No matter if you compile the viewer standalone or not, there is always a
huge set of system libraries it will be used.
For example on Windows: opengl32.dll, kernel32.dll, ntdll.dll and many many
more.

USESYSTEMLIBS is due to that IMO even worse and more ambiguous.

Also keep in mind 'building standalone' is a well established term and it
will stick for at least another good while. I can only see this adding
potential confusion rather than solving any pressing issues.

So yeah, STANDALONE might not be the best of terms. But every project has
some terms you have to accept. Just 2 examples:
 -LLSD: what, Linden LSD, they do drugs?
 - autobuild: gnu autoconf/autobuild

(Also in many years of talking to people who had problems compiling the
viewer, they had all kind of crazy issues, but there was none that confused
by the term STANDALONE)



On Thu, Mar 20, 2014 at 3:47 PM, Oz Linden (Scott Lawrence) 
o...@lindenlab.com wrote:


 The subject of how confusing the name of the STANDALONE switch is came up
 yet again at one of my meetings the other day, and I've just decided to
 kill this problem once and for all.

 I've prepped a repo with it changed to USESYSTEMLIBS (and the
 corresponding C preprocessor symbol changed to LL_USESYSTEMLIBS):


 https://bitbucket.org/oz_linden/open-199/commits/79fbe57a728a8e619d8d85b756061b50fb36152f

 I'd appreciate it if anyone who normally builds using that set to ON (I
 never do) would check that it works as well as it did before.

 Unless I hear strong objections soon, that will be in the next Snowstorm
 release candidate (no, I don't have a prediction when that will be).

 --
  *Scott Lawrence* | *Director of Open Development*
 Skype ozlinden | Second Life Oz Lindenhttps://my.secondlife.com/oz.linden
 Linden Lab | Makers of Shared Creative Spaces http://lindenlab.com/
 Check out what we're working on! http://lindenlab.com/products


 ___
 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] gcc 4.7.1: lotsa warnings about boost

[Nicky D.]

Try this and see if it helps
http://hg.phoenixviewer.com/phoenix-firestorm-lgpl/rev/4fa73607d364

(skip the parts about FAA/FAD as you do not have those headers)

Cheers,
   Nicky


On Sun, Jan 6, 2013 at 11:56 AM, Lance Corrimal
lance.corri...@eregion.dewrote:

 Hi,


 Whenever I'm building the current development source on openSUSE 12.2
 (read:
 with gcc 4.7.1) I get lots of warnings about boost-related things. Some of
 them I've been able to correct myself, others I'm stumped... the causes
 seem
 to be in 3p-boost itself, and i'd rather build with exactly the same libs
 as
 the lab...

 here's one of many examples:

 http://paste.opensuse.org/77018665  (it's way too long and unreadable for
 email)

 any ideas / tips / hints for me? google results seem to suggest something
 or
 the other about namespaces...


 cheers,

 LC

 ___
 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] ok this may sound dumb but what is the llphysicsextention package

[Nicky D.]

On Wed, Aug 8, 2012 at 1:45 AM, Oz Linden (Scott Lawrence)
o...@lindenlab.com wrote:
 On 2012-08-07 16:09 , Angel Dreams wrote:
 its something i saw i never seen that package before is it new or
 something?

 It is the wrapper around the Havok functionality in the viewer.  It
 replaces (and incorporates) llconvexdecomposition.

 For open source, there is a stub version.

This is in fact old news and was mentioned a few times on the ML
already. It might have
been better to bring up a request to keep the functionality split back then.

Under https://bitbucket.org/NickyD/ndphysicsstub you will find a stub for your
pathfinding and mesh upload pleasure. I updated it today to match the
latest PF shiny
and incorporated it into Firestorm with not much fuss.

It's not based on LLs pathing or physics files, so there is no license
from LL attached.

Whoever based their mesh upload on a fork of my original mesh upload
package, might
have to wait until the fork is updated, obviously.

Cheers,
   Nicky
___
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] Anyone else having this issue uploading meshes?

[Nicky D.]

On Sun, Jun 3, 2012 at 9:47 PM, Nicky Perian nickyper...@yahoo.com wrote:
 I have an unproven theory. It is Sunday with lots of stau on the inet. Now
 to my theory. Let's you have your data *.dae files on a network drive or
 worse yet in dropbox folder. The write back of the *.slm file is now taking
 a bit longer because of inet traffic and the normal latency for obtaining
 file locks and the LAN overhead involved of obtaining exclusive control of
 the file open, lock, write, unlock and close processes.


It does not matter if your file is on DropBox, your HDD or a floppy disk.
The dae loading takes places long before even any communication with the
server takes places. Writing the slm is done before the hulls etc are uploaded.
Even if the slm writing has higher latency in some cases, it won't influence
neither decoding nor upload.

For the real cause, and to know why sometimes client and server disagree
if a convex decomposition is valid we would need to have access to the server
(logs). Sometimes I am sure won't happen anytime soon :)

Regards,
   Nicky
___
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] Fix for SH-2941 breaks HACD-k ?

[Nicky D.]

Hello,

I played a bit with that yesterday.Uploaded a few files, calculated a
few fees and all worked
well.
But I did not use the packages from NickyP, but instead the code that
was forked into that
a while ago. Not sure if there's any changes in his repo that can make
such a difference.

In general is the Mesh upload sensitive to model and the steps you did
before you upload.
Maybe you can elaborate a bit on more what you tried to upload and
which buttons you
pressed in what order.

 what we need first is HACD in the official opensource viewer. The CR sits on
 ship it for weeks now, for crying out loud.

That won't make much sense right now. Pathfinding will change the
packaging a bit, then
the havok lib will include mesh upload and pathfinding functionality.

This will affect the OS Mesh upload too, as
LLConvexDecomposition.cmake got removed. Instead
the new kid in town will be LLPhysicsExtensions.cmake.

This of course brings a few other changes, as then the OS Mesh upload
package needs to include
either the pathfinding functionality (navmesh decoderdisplay, A* [or
something] path finding) or
at least a stub for the latter.

Nicky
___
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] Fix for SH-2941 breaks HACD-k ?

[Nicky D.]

 I am not receiving any fee errors today. No errors at all using either the
 OpenMP present version 178 hacd-k or the original version 162 hacd-k
 libraries. It appears that the fee errors were triggered from having the dae
 files in a dropbox folder and that bogged the fee calculation down.

Fee calculation comes long after the file has been read from the DAE.
Dropbox will not influence any of that (upload, calculation, analyze) at
all.

Nicky
___
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] master_message_template.msg

[Nicky D.]

On Thu, Apr 19, 2012 at 12:04 PM, Henri Beauchamp sl...@free.fr wrote:
 On Thu, 19 Apr 2012 11:50:26 +0200, Lance Corrimal wrote:

 Am Donnerstag, 19. April 2012, 10:10:55 schrieb Henri Beauchamp:

  Could someone at the Lab update the master_message_template.msg, please
  (http://secondlife.com/app/message_template/master_message_template.msg)
  It has not been updated in ages (probably over a year)...


 isn't the current message template on bitbucket?
 https://bitbucket.org/lindenlab/master-message-
 template/raw/tip/message_template.msg

 This is not the version which is checked against while compiling...

Lance is correct. That was changed a good while ago:
https://bitbucket.org/lindenlab/viewer-release/changeset/92aff170d95e
___
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-1793 1) Treat all mini-map altitudes above 1020 m as the same height 2) Improve z-level accuracy

[Nicky D.]

Or you could as well make a new message, then alternate it with the current one.
Eg. instead of sending CoarseLocation update every x (lets say 5 )
seconds,you send
 0 - CoarseLocation
 5 - CoarseLocationNew
10 - CoarseLocation
15 - CoarseLocationNew

And so on.

- Old clients would lose update precision. But not be broken.

- New clients would use both messages and get X/Y updates at the same
interval as today.
For Z they could interpolate if the old message send an 'out of
range'-Z value. Or just live with
the lower Z update frequency. Both would still be vastly better than
what we have now.

- The amount of message the simulator has to send would not increase.

Phase out the old message by reducing its frequency after a few month, then stop
sending it at all. Whoever did not update their code by that time
could be considered
badly outdated.
___
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] linux build errors

[Nicky D.]

 anyone else receiving this and is there a workaround?

It had been once discussed on the mailinglist. That code is really a bit
hackerish and would need some love.

One of the (still hacked) workarounds can be found here
https://bitbucket.org/NickyD/viewer-development/changeset/0c2cb53f7

Cheers,
   Nicky
___
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] Mesh viewers and tcmalloc issues

[Nicky D.]

 in GooglePerfTools.cmake:
 set(TCMALLOC_FLAG -ULL_USE_TCMALLOC=1)
 and in llcommon property pages
 Undefine Preprocessor Definitions: LL_USE_TCMALLOC=1
 So it would appear, at least by default, that tcmalloc is not enabled.   Am
 I understanding this wrong?  Or does LL build their viewer with it defined
 and sending the viewer out the opensource world with it disabled?


That define is really only used for some statics code in
llallocator.cpp. It does
not influence if tcmalloc is used or not.
___
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] Viewer development 2.8.1 and a few new bugs

[Nicky D.]

Hello,

I looked into that strange color problem the last few days. It happens
because there is a
union with a point in LLColor4U. This makes the whole thing blow up
when compiled with
64 Bit pointers.

For anyone interested I attached a patch that fixes the issue and
handles the color
conversion in a portable way.

Cheers,
   Nicky


viewer-development-fd2c604fd35b.diff
Description: Binary data
___
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] ok wtf is this?

[Nicky D.]

 Even if the size of the memory pool allocated was impacted by the total
 available RAM on the machine, which I'm not sure it is, I can see them
 having more memory on their test machines than I do on my laptop, which
 has only 6G but I've twice that on my gaming rig and I saw the issue on
 both.

As strange as this might sound, 6/12 GB might be too much.

There are a lot of casts down to U32. There might be a hidden overflow there,
turning some counter into a very small number.
___
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] ok wtf is this?

[Nicky D.]

Hello,


 With the latest build I keep getting an alert box for memory pool low,
 some sl functions disabled to avoid crash and sure enough I crash a
 couple minutes later..   but memory pool low?  I've usually got over 2g
 of physical memory free when it hits, and the machine isnt even breaking
 a sweat. I dont see a ramp up in memory use that might indicate a leak,
 I look at the logs and I see the latest ERROR level entry is a bad
 memory allocation for a texture. Somebody who's more current with the
 code tell me where I should look to narrow this thing down enough to
 file a JIRA...

There is a memory pool that got enabled 4 days ago. Which could cause
this problem aswell.

The change is here:
https://bitbucket.org/lindenlab/viewer-development/changeset/298722ecdb2e

Maybe there is a bug in the Memory pool that is causing  You could try
disabling it
in your settings and see if the error still persists.

Cheers,
   Nicky
___
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] Mesh decomposition using hacd

[Nicky D.]

 I would love to test this out and see how functional it is. Please use the
 above listed repositories to fork off of and make the needed changes and
 keep in mind how this is having to be done and where it will hopefully end
 up.


To make a long story short: I did not sign the SLV Contribution Agreement.

So obviously making this compatible with a submission that cannot happen
anyway is pretty low on my list of things to do.
___
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] Mesh decomposition using hacd

[Nicky D.]

Good morning everyone,

after getting GLOD in shape I continued playing with HACD and using it
for mesh uploading.

The current status looks promising so far. I had been able to upload a few
meshes using it.

For anyone interested the code for the lib can be found here:
https://bitbucket.org/NickyD/convexdecompositionhacd

I only used it under Linux so far. So when it comes to compiling Windows user
are a bit on their own right now.

For Linux you can use the following few steps after cloning and being
in the convexdecompositionhacd directory.

- mkdir build  cd build
- cmake .. -DCMAKE_INSTALL_PREFIX=/tmp/install
- make
- make install

Now you will end up with two libs in /tmp/install/lib (and
llconvexdecomposition.h
in /tmp/install/include).

Copy those libs where the linker can find them.

Now you want two other changesets applied to your viewer souces:

1) https://bitbucket.org/NickyD/viewer-development/changeset/cf82fc1a6683
This one will just pull the correct libs into your linker settings,

2) https://bitbucket.org/NickyD/viewer-development/changeset/1f9086200bbc

That's a tricky one, because I am yet not sure if it is the correct
way to solve things.
The idea behind it is the viewer detecting if it is linked against
HACD, if yes then
it will always passed Meshes with triangles into it.

HACD always wants to have triangles and vertices before it even considers
computing anything. This little workaround seems to work well, but I am not sure
if it is always safe to do it this way.

Cheers,
   Nicky
___
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] Uploading mesh, errors in GLOD

[Nicky D.]

Good morning everyone,


 All I ever get is:
 Warning: Cannot normalize 0 vector!
 Warning: Cannot normalize 0 vector!
 Warning: Cannot normalize 0 vector!
 Warning: Cannot normalize 0 vector!
 Warning: Cannot normalize 0 vector!
 Warning: Cannot normalize 0 vector!
 GLOD: Patch of the specified doesn't exist. (0x).


As suspected by me did this turn out as a GLOD error under x64 build.
After patching it up the
preview floater works as expected and shows the preview mode.

Cheers,
   Nicky
___
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] Uploading mesh, errors in GLOD

[Nicky D.]

Hello,

I've been playing with llconvexdecomposition today and made a version
that is linked against HACD. So far, so good. I think I've
the most critical methods implemented and wanted to test what I have by now.

But I seem to run into a major roadblocker here, no matter what I try,
I always get errors from GLOD. There seems to
be no model at all that will load.

So far I tried the Street_Lamp.zip and doric_column.zip from the
samples page. As well did I try some very basic samples
I found elsewhere. But to no avail.

All I ever get is:
Warning: Cannot normalize 0 vector!
Warning: Cannot normalize 0 vector!
Warning: Cannot normalize 0 vector!
Warning: Cannot normalize 0 vector!
Warning: Cannot normalize 0 vector!
Warning: Cannot normalize 0 vector!
GLOD: Patch of the specified doesn't exist. (0x).

And then:

2011-08-29T19:59:28Z newview/llfloatermodelpreview.cpp(3964) : error
2011-08-29T19:59:28Z ERROR: LLViewerTexture::genLODs: Invalid face
generated during LOD generation.

And that's it, assertion and crash.

Some models do not show the 'Warning: Cannot normalize 0 vector!', but
the crash is all the same.

The whole thing happens on Linux, 64 Bit. Standalone build. The viewer
synced to change a95b822cf2c2, llglod is synced
to the tip.

Any pointers are greatly appreciated.

Cheers,
Nicky
___
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] Viewer development 2.8.1 and a few new bugs

[Nicky D.]

Hello everyone,

 - Invisiprims don't render well, they are completely black UNLESS they
 are set to fullbright (no matter whether deferred shading is on or
 off)
 - Alpha doesn't render well either, once again unless fullbright is
 on. Full strands of hair disappear, it's really ugly

Over the weekend, I pulled the latest sources and build a new viewer.
In short: I have those issues as well.

It looks really odd.
- I see 'shades' of attachments other people have hidden.
- My HUD (Magical Compass) has buttons who are half hidden, the background
of the HUD seems to be some texture with alpha. On some logins I see the back-
ground, then on the next login everything is fine again. (The
background is supposed
to be invisible).
- Issue with colours being black, same here. Sometimes zooming in
fixes it, sometimes
it just worsens it.
- Some colours are really, really odd. They show like some rainbowish
colour gradient, or
maybe more like oil/fuel when poured in water. Again zooming can heal
it at times, zooming
out worsens it again.

Right now I have no real clue what causes it. I tried the alpha
switches on and off, no help.
Playing with the advanced gfx settings (vbo buffers) and such did not
help either. Disabling
shaders is another thing that did not improve it much.

I think I saw that problem with the textures crop up when mesh landed
in viewer-development,
but than did not have the time to investigate any more.

And I have a ATI card, maybe that one helps too as info?

Any ideas what do try would be really appreciated.

 - And the /me bug has now migrated to the chat history itself. It
 works on the chat floater, but if I say /me smiles, I'll see Marine
 KelleyMarine Kelley smiles on the history.

Noticed that too.

Cheers,
   Nicky
___
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] Mesh branch merged to viewer-development

[Nicky D.]

 Some of the changes may cause problems with using the Debug (and
 DebugOS) configurations.  If you have problems, please bring them up on
 the list.  Don't file a jira yet unless you believe you have diagnosed a
 specific issue well enough that a fix is possible.  If it turns out that
 these configurations are not working well, getting them fixed will be a
 high priority this week.

I pulled and merged yesterday.

Got a viewer running and working as a 64 bit binary compiled under Linux.
I obviously had to roll my own fix for SH-1616. Other than that is seems to
work mostly ok.

The only other issue I have is with textures. Some seem to have something
like a rainbow effect on them. For some the alpha seems to be bad. Some
use the wrong colors when far away, zooming closer changes to color to a better
value. Zooming even closer changes to worse colors again.

Not really sure what this is. For sure it looks a bit odd and annoying :)

Cheers,
   Nicky
___
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] autobuild on linux

[Nicky D.]

 when i run autobuild configure -c OpenSourceRelWithDebInfo I still get
 'autobuild.common.AutobuildError: invalid 'pathcheck' setting for 'boto'
   looking in common.py, the pathcheck for boto is 'lib/python2.5/boto'

 Anyone have any hints to help me get further?


As normal user try the following
(  cd /var/tmp/`whoami`/install.cache  wget
http://s3.amazonaws.com/viewer-source-downloads/install_pkgs/boto-1.9b-common-20100414.tar.bz2
)

Then try again.
Looks like boto is a prereg that needs to be downloaded, but for
downloading you need boto. Or something like this :)
autobuild should really be happy if there is a system wide boto and use this.
For now you need to populate install.cache with the package, than
autobuild will unpack it for you and continue from there.

Cheers,
  Nicky
___
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] Linux build error: missing binary operator before token ( (was: Hacking up to Visual Studio 2010 ...)

[Nicky D.]

 [19:13:30]: LogScan (1s)
 [19:13:30]: [LogScan] from /usr/include/c++/4.1.3/cmath:53,
 [19:13:30]: [LogScan] from
 /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/llcommon/linden_common.h:48,
 [19:13:30]: [LogScan] from
 /var/opt/teamcity/checkout/L-oz_viewer-autobuild2010/latest/indra/newview/tests/lldateutil_test.cpp:26:
 [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:28:18: error: missing
 binary operator before token (
 [19:13:30]: [LogScan] /usr/include/bits/huge_val.h:30:20: error: missing
 binary operator before token (

 With build in the second command instead of configure, I'm getting the
 same error, though not just for /usr/include/bits/huge_val.h but many more
 system headers, too.


Tried it today, getting that too. Huge slew of errors.

Even though this looks intimidating, the reason is really simple.

In OZ's version of json there is a file features.h in
../include/json/. Metaphorical
speaking there he laid the bomb.
It is then trigged in cmake/JsonCpp.cmake and newview/CMakeList.txt

JsonCpp.cmake  sets JSONCPP_INCLUDE_DIRS to ${LIBS_PREBUILD_DIR)/include/json.
newview/CMakeList.txt adds JSONCPP_INCLUDE_DIRS to the system include dirs.

Now the the problem with gcc is, that adding include dirs with -I
makes them be searched
before the system include dirs.
And there our little bomb goes off. Because now the compiler findes
the features.h file
first in ../include/json. When it fact it needs the system one from
/usr/include/features.h.

One solution might be to use the -I- switch or -iquote for new gcc
versions. But lucky
enough there is a trivially simple fix, just use
${LIBS_PREBUILD_DIR)/include for
JSONCPP_INCLUDE_DIRS.

I attached a patch that does just this. Standalone builds might need
some extra hackery,
I did not try one of those yet.

Cheers,
   Nicky
# HG changeset patch
# User Nicky nickyd...@yahoo.com
# Date 1298143658 -3600
# Node ID ab363082f660e186ce0bfef8bf455b6d932c2663
# Parent  07163388fcb99b292843648c6256946cc622976f
Do not add jsonpath/include/json as an include director. Instead use jsonpath/include.
Otherwise include/json/features.h will mask /usr/include/features.

diff -r 07163388fcb9 -r ab363082f660 indra/cmake/JsonCpp.cmake
--- a/indra/cmake/JsonCpp.cmake	Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/cmake/JsonCpp.cmake	Sat Feb 19 20:27:38 2011 +0100
@@ -18,5 +18,5 @@
   elseif (LINUX)
 set(JSONCPP_LIBRARIES libjson_linux-gcc-4.3.2_libmt)
   endif (WINDOWS)
-  set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include/json)
+  set(JSONCPP_INCLUDE_DIRS ${LIBS_PREBUILT_DIR}/include)
 endif (STANDALONE)
diff -r 07163388fcb9 -r ab363082f660 indra/newview/lltranslate.cpp
--- a/indra/newview/lltranslate.cpp	Fri Feb 18 12:50:16 2011 -0500
+++ b/indra/newview/lltranslate.cpp	Sat Feb 19 20:27:38 2011 +0100
@@ -33,7 +33,7 @@
 #include llversioninfo.h
 #include llviewercontrol.h
 
-#include reader.h
+#include json/reader.h
 
 // These two are concatenated with the language specifiers to form a complete Google Translate URL
 const char* LLTranslate::m_GoogleURL = http://ajax.googleapis.com/ajax/services/language/translate?v=1.0q=;;
___
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] Debugging Snowstorm under Linux x64 with GDB locks the whole X session

[Nicky D.]

Hello,

did anyone ever have the following problem? I start snowstorm directly
under gdb, run it. Then after a while (mostly after SL login) my
machine GUI locks up.

I cannot use any X programs anymore, if I run mplayer it will stop
playing music. Neither can I kill the X server or switch session. But
I can ssh into the
machine. There I see the snowstorm binary taking all CPU time. Once I
kill snowstorm and gdb via this ssh login everything will be good
again.

I get a hunch that this has to do with the threads snowstorm creates.
As the last thing I usually see in the gdb output is a line 'Thread
 created'. Of course
this could be a coincidence.

This is a very annoying issue, as it makes debugging Snowstorm
(actually it seems to affect all V2 based viewers) nearly impossible.

The GDB version I use is 'GNU gdb (Gentoo 7.2 p1) 7.2'. Kernel is
2.6.36-gentoo-r3. Snowstorm is synced to the latest changes.

For snowstorm and kernel I already tried different versions. It did
not help at all. I even tried Phoenix-Firestorm, same result.

Has anyone ever seen something like this, or got a slight idea what I might try?
Can the threads in snowstorm be temporarily disabled to make sure they
are either causing or not causing this?

Cheers,
   Nicky
___
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] Debugging Snowstorm under Linux x64 with GDB locks the whole X session

[Nicky D.]

On Wed, Dec 29, 2010 at 9:30 PM, Monty Brandenberg mo...@lindenlab.com wrote:
 On 12/29/2010 1:19 PM, Aleric Inglewood wrote:

 yes, this is a known problem: the viewer sometimes locks the X display,
 if then you halt it in the debugger you're toast.

 I only have creaky old Debians at hand but wondered if those with
 more modern distros with updated GTKs can work around it by
 changing the 'gtk_debug_flags'.  There's now a GTK_DEBUG_NOGRABS
 flag (1  12, I think).  Set that and play a bit.  No guarantees,
 you'll need very recent libs and I don't know at what point in
 execution you'll need to set that flag.  (The --gtk-debug and
 --gdk-debug cmd options also drive this.)  But there it is...


Thank you two for you replies. I will try the gtk debug env later.

Just to refine my original mail. I would understand if I hit a
breakpoint and there is some
graphics stuff going on.

But I just *run* snowstorm under gdb by setting LL_WRAPPER. I have not
one breakpoint
set, neither do I interrupt the program at all.
I just use the viewer and it will just lock up the whole X display
sooner or later.

When I use the viewer without gdb all is fine, no crashes, hang, all good.

Cheers,
   Nicky

P.S. I am not NickyP :) Not that I minded it Aleric, just to avoid confusion.
or later.
___
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] Debugging Snowstorm under Linux x64 with GDB locks the whole X session

[Nicky D.]

 That is not normal... My X display did lock up too.. until I replaced
 my videocard ;)

I know :) And I even had those 'nice' GFX card problems once on another PC. But
those are a lot nastier :D

 If you just let it run, then there is no reason for it to hang X imho :/.
 But if it only happens when you run gdb and not otherwise... I don't know.
 Sounds like a software problem then though.

Yeah.

I investigated this further. My suspicion that it has to do with
threads seem to be correct. If
I forcefully stop gdb from using libthread_db to debug threads all will be good.

If gdb hooks threads, it seems to muck in a way with them that seems
to cause freezes from
time to time.

I am not sure if this is a very strange bug in SL, a bug in
gdb/libthread_db, or a combination
of the two+ati driver.

We might never find out, as for obvious reasons I cannot debug it :/

Hopefully this will help someone else having the same problem: Just
prevent threads from
being debugged.

Cheers,
   Nicky
___
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...

[Nicky D.]

 phenomenon's been occurring at least once a day.  Sometimes they're ??? at
 login, sometimes they show properly at first and then flip to ??? on their
 own.  Sometimes the ???'s remain throughout the session, and sometimes they
 flip back to show the correct names.  It happens regardless of whether the
 user has a Display Name set or not.

What irks me the most, is that changing from a good name(!) to ??? all
of sudden.

And whoever thought using ??? was a good idea should really take a few
considerations
what this means for logs, IMs and so on if suddenly everyone is ???

I can understand that it is a problem if the name cannot be resolved.
But why not at
least take the safe route and use the old one (if there was already
one) and try again
instead of overwriting a good cache entry with ???.

There should be a few fallback strategies like:
a) Try to keep the old cache entry.
b) Use the normal user name.
c) Maybe even use the UUID.

But just showing everyone (in the worst case) as ??? really screws
things up IMO.

Cheers,
   Nicky
___
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] Any hope of STORM-727 getting a little love?

[Nicky D.]

It's pesky, isn't it? :) Incidentally it bit me as well this week.
Patch attached.
Not sure if it is really the 100% golden way, but it works good for
me. Maybe someone
can make good use of the patch.

Cheers,
   Nicky


storm-727
Description: Binary data
___
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