Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder wrote: > Enjoy spamming the list and pulling our changes. :) Elephant in the china store much? Of over 38000 commits in your own viewer your contribution is 680. So where are you pulling the rest of your changes from? We all owe a massive Thank You! to Linden Lab for these alternati

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On February 2, 2017 at 2:57:13 PM, Geir Nøklebye (geir.nokle...@dayturn.com ) wrote: @Cinder  With reference to Xcode 8 release notes, section Deprecations it reads:  OS X 10.11 was the last major release of macOS that supported the previously deprecated ga

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

@Cinder With reference to Xcode 8 release notes, section Deprecations it reads: OS X 10.11 was the last major release of macOS that supported the previously deprecated garbage collection runtime. Applications or features that depend upon garbage collection may not function properly or will n

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On February 2, 2017 at 9:08:44 AM, Geir Nøklebye (geir.nokle...@dayturn.com ) wrote: Henri said: > Meaning you actually didn't fix anything... > Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences ? The root

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Henri said: > Meaning you actually didn't fix anything... > Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences ? The root cause of the problem is not fixed, no. It put some bandaids on it to reduce the crash frequency. The autoreleasepool issu

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries On Thu, 2 Feb 2017 08:14:21 +0100, Geir Nøklebye wrote: > The viewer still crash in the occlusion code, but not as often as > without these changes. Meaning you actuall

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

This is the typical anatomy of the crash that accompanies the GPU reset. It also crash even if you turn of shadows and ambient occlusion, but then with much lower frequency, Thread 0 Crashed:: Dispatch queue: com.apple.main-thread 0 com.apple.GeForceGLDriver 0x906aeb6c 0x9037e000

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On Thu, 2 Feb 2017 08:14:21 +0100, Geir Nøklebye wrote: > The viewer still crash in the occlusion code, but not as often as > without these changes. Meaning you actually didn't fix anything... Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Oz Linden said: > If you've got a fix, we'd love to see it. There is no quick fix except rewriting the renderer to use the NSOpenGLProfileVersion3_2Core profile or even Metal (which would also be a first step to also run on iOS). In Kokua we have managed to delay the crash from happening withi

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Whirly Fizzle said: > Switching over to using the Nvidia web drivers fixes the frequent crashing > but some systems suffer poorer viewer performance with the Nvidia web drivers. You can use the so called NVIDIA web driver as it gives the current viewer code access to the direct hardware address

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder said > It's not a viewer bug, it?s an issue with Apple's Nvidia driver. (also note, > that it doesn?t happen with Radeon or Nvidia?s own driver, just Apple?s and > happens to hundreds upon hundreds of games available on Steam.) Apple Software Engineering has acknowledged that such crashe

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Dahlia Trimble said: > It's probably considered bad practice for code to use an ARB extension > without first checking to see if it's available. All the viewers already detect and log this, and you will find it at asa log entry like: 2017-02-01T08:08:30Z INFO: #RenderInitinitExtensions: Could

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

2017 21:15 To: opensource-dev@lists.secondlife.com Subject: Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries On 2017-02-01 15:24 , Geir Nøklebye wrote: When will be see the crash in the occlusion code being fixed due to the fact that GL_ARB_occlusion_query2 is not av

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On 2017-02-01 15:24 , Geir Nøklebye wrote: When will be see the crash in the occlusion code being fixed due to the fact that GL_ARB_occlusion_query2 is not available in the OpenGL Legacy Profile the renderer currently is forced to when the viewer is running on macOS 10.11 or higher? If you've

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On February 1, 2017 at 2:24:56 PM, Geir Nøklebye (geir.nokle...@dayturn.com ) wrote: Cinder said >For what it?s worth, Apple did warn developers to stop using it and switch to >Cocoa?s crypto frameworks or ship their own. …and that is the core of the state

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

It's probably considered bad practice for code to use an ARB extension without first checking to see if it's available. On Wed, Feb 1, 2017 at 12:24 PM, Geir Nøklebye wrote: > Cinder said > > >For what it?s worth, Apple did warn developers to stop using it and > switch to Cocoa?s crypto framewor

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Cinder said >For what it?s worth, Apple did warn developers to stop using it and switch to >Cocoa?s crypto frameworks or ship their own. …and that is the core of the state of the macOS version of the viewer(s). Deprecated code all over. When will be see the crash in the occlusion code being

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On January 31, 2017 at 2:40:44 PM, Monty Brandenberg (mo...@lindenlab.com ) wrote: On 1/31/2017 3:24 PM, Cinder Roxley wrote: > ~ % otool -L /usr/lib/libssl.dylib > > /usr/lib/libssl.dylib: > > /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current > vers

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On 1/31/2017 3:24 PM, Cinder Roxley wrote: > ~ % otool -L /usr/lib/libssl.dylib > > /usr/lib/libssl.dylib: > > /usr/lib/libssl.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) > > /usr/lib/libcrypto.0.9.8.dylib (compatibility version 0.9.8, current > version 0.9.8) Ouch. I was

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On January 31, 2017 at 2:12:24 PM, Geir Nøklebye (geir.nokle...@dayturn.com ) wrote: Some are outdated and some are more up to date than the current viewer libraries.  They usually get serious amount of public flack if security issues are not fixed, meaning t

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

Some are outdated and some are more up to date than the current viewer libraries. They usually get serious amount of public flack if security issues are not fixed, meaning they are automatically patched when users upgrade their systems. • The other thing is they are all compiled both 32 and

Re: [opensource-dev] Mac viewer and Apple maintained opensource libraries

On January 31, 2017 at 4:55:26 AM, Geir Nøklebye (geir.nokle...@dayturn.com ) wrote: Are you all aware of the Apple maintained opensource libraries already included in macOS that you also maintain and use in the viewer?  Examples are libexpat, pcre, openAL, h

[opensource-dev] Mac viewer and Apple maintained opensource libraries

Are you all aware of the Apple maintained opensource libraries already included in macOS that you also maintain and use in the viewer? Examples are libexpat, pcre, openAL, hunspell and openssl. It might be easier to build the macOS version of the viewer with these libraries, rather than spend