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,
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.
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
>
> 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
> 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
>
> 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
> [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/
> 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
>
> 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
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
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
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
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
> 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
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
>
> 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,
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
> 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
> 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,
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
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
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
> 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
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
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
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
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
>
>
> > 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
>
> 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
>
>
> 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
>
>
> 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
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
>
> 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
>
> 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
>
>
> 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
>
> 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
> 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.
>
>
>
> 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
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
>
> 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
>
> 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
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
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
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:
> >
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.
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
