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 fly
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 thi
>
> 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...
>
T
>
> 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
> be
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 every
>
>
>
> 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, wh
> 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 e
>
>
> Technical, maybe. As pointed out by Nicky, the main annoyances with
> gstreamer are: 1. the amount of additional libraries that would have
> to be bundled together with the viewer, and: 2. the runtime symbol
> resolution and DSO loading which complicates the plugin code, but
> since that plug
>
> 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
wrote:
> Hi,
>
> I'm trying to build the current viewer-release source, and I get a
> fa
>
>
> 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
>
>
> 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
>
> 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
>
>
> > 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 unde
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 stan
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
wrote:
> Hi,
>
>
> Whenever I'm building the current development sou
On Wed, Aug 8, 2012 at 1:45 AM, Oz Linden (Scott Lawrence)
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) llc
On Sun, Jun 3, 2012 at 9:47 PM, Nicky Perian 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 b
> 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.
F
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 genera
On Thu, Apr 19, 2012 at 12:04 PM, Henri Beauchamp 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
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 pre
> 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 wit
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 i
>
> 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
>
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 break
> 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 Contributi
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
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 spe
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 th
>
> 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
> thes
> We have a suggestion that the term 'STANDALONE' in the build processes
> is misleading and should be changed to something that is more accurately
> descriptive of what it really does.
>
>
> So... should this be changed? and if so, to what?
>
I am fine with changing it to whatever gets the most
> [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/
>
> 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
> 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 wh
>
> 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 happe
On Wed, Dec 29, 2010 at 9:30 PM, Monty Brandenberg 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
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.
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
___
Hello Erin,
> 2010-11-03T01:06:56Z INFO: windows_post_minidump_callback: generated
> minidump: (pathway deleted for privacy)
> SecondLife\logs\83ea59e2-2ca0-49b2-82be-f816fc1af143.dmp
>
And could you upload this file? A minidump is basically a file that records
the state of the application at cr
46 matches
Mail list logo
