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.
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:
> >
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
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
>
> 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...
>
>
> 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
>
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
>
>
>
> 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,
> 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.
>
> 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
>
> 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
>
> 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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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,
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
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
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.
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
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
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:
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
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
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
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
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
[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
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
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
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
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
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
43 matches
Mail list logo
