From geir.noklebye at dayturn.com Wed Feb 1 12:24:47 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Wed, 1 Feb 2017 21:24:47 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: 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 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? Event: GPU Reset Date/Time: Wed Feb 1 21:17:26 2017 Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2017-02-01-211726.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.12.3 (Build 16D32) Graphics Hardware: NVIDIA GeForce GTX 660M NVDA(Graphics): Channel exception! Exception type = 0x1f Access Violation Error (MMU Error 2) Channel Info: [44, 0x14, 0x12, 0x136555] Version Info: [com.apple.GeForce, 10.1.4, 0x7d780b0a, 18894120, 355.10.05.15f03, 1] MMU Error: FAULT_PTE at 0x5063c0000 This crash happens in Cool VL Viewer, Singularity, Alchemy, Firestorm, Kokua, SecondLife release and all dev versions including Second Life Project Alex Ivy You probably never get it reported because the Google Breakpad reports don?t catch it. From dahliatrimble at gmail.com Wed Feb 1 12:33:57 2017 From: dahliatrimble at gmail.com (Dahlia Trimble) Date: Wed, 1 Feb 2017 12:33:57 -0800 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: Message-ID: 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 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 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? > > Event: GPU Reset > Date/Time: Wed Feb 1 21:17:26 2017 > > Tailspin: /Library/Logs/DiagnosticReports/ > gpuRestart2017-02-01-211726.tailspin > GPUSubmission Trace ID: 0 > OS Version: Mac OS X Version 10.12.3 (Build 16D32) > Graphics Hardware: NVIDIA GeForce GTX 660M > > > NVDA(Graphics): Channel exception! Exception type = 0x1f Access Violation > Error (MMU Error 2) > Channel Info: [44, 0x14, 0x12, 0x136555] > Version Info: [com.apple.GeForce, 10.1.4, 0x7d780b0a, 18894120, > 355.10.05.15f03, 1] > MMU Error: FAULT_PTE at 0x5063c0000 > > > This crash happens in Cool VL Viewer, Singularity, Alchemy, Firestorm, > Kokua, SecondLife release and all dev versions including Second Life > Project Alex Ivy > You probably never get it reported because the Google Breakpad reports > don?t catch it. > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170201/4bcaa075/attachment.htm From cinder at alchemyviewer.org Wed Feb 1 12:54:36 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Wed, 1 Feb 2017 20:54:36 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: Message-ID: <01000159fb7527ce-75077cb8-eb26-4ced-bfb0-2a67c80947a4-000000@email.amazonses.com> On February 1, 2017 at 2:24:56 PM, Geir N?klebye (geir.noklebye at 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 of the macOS version of the viewer(s). Deprecated code all over. Umm, the viewer does ship with its own OpenSSL which is exactly what Apple recommends. 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? The viewer doesn?t ever call GL_ARB_occlusion_query2 on OSX. Event: GPU Reset Date/Time: Wed Feb 1 21:17:26 2017 Tailspin: /Library/Logs/DiagnosticReports/gpuRestart2017-02-01-211726.tailspin GPUSubmission Trace ID: 0 OS Version: Mac OS X Version 10.12.3 (Build 16D32) Graphics Hardware: NVIDIA GeForce GTX 660M NVDA(Graphics): Channel exception! Exception type = 0x1f Access Violation Error (MMU Error 2) Channel Info: [44, 0x14, 0x12, 0x136555] Version Info: [com.apple.GeForce, 10.1.4, 0x7d780b0a, 18894120, 355.10.05.15f03, 1] MMU Error: FAULT_PTE at 0x5063c0000 This crash happens in Cool VL Viewer, Singularity, Alchemy, Firestorm, Kokua, SecondLife release and all dev versions including Second Life Project Alex Ivy You probably never get it reported because the Google Breakpad reports don?t catch it. That has been reported and the crash reporter doesn?t catch it because it?s a driver crash not the viewer. 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.) --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170201/e03ba16d/attachment.htm From oz at lindenlab.com Wed Feb 1 13:15:52 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 1 Feb 2017 16:15:52 -0500 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: Message-ID: 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 got a fix, we'd love to see it. -- OZ LINDEN | Engineering Director, Second Life email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170201/9184ce8b/attachment.htm From kirstiemc555 at hotmail.co.uk Wed Feb 1 17:53:34 2017 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Thu, 2 Feb 2017 01:53:34 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: , Message-ID: As Cinder said, that crash appears to be caused by a problem with the Apple Nvidia drivers shipped with El Capitan & Sierra. Switching over to using the Nvidia web drivers fixes the frequent crashing but some systems suffer poorer viewer performance with the Nvidia web drivers. The LL bug report for this crash is https://jira.secondlife.com/browse/BUG-10302 Firestorm bug report: http://jira.phoenixviewer.com/browse/FIRE-16821 [FIRE-16821] [BUG-10302] [Mac El Capitan] Firestorm crash ... jira.phoenixviewer.com Firestorm; FIRE-16821 [BUG-10302] [Mac El Capitan] Firestorm crash/incompatibility with Mac OS 10.11 Beta (15A234d), 15A282a - GM release & 10.11.0 full release. ________________________________ From: opensource-dev-bounces at lists.secondlife.com on behalf of Oz Linden (Scott Lawrence) Sent: 01 February 2017 21:15 To: opensource-dev at 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 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 got a fix, we'd love to see it. -- OZ LINDEN | Engineering Director, Second Life email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170202/6aacbc21/attachment-0001.htm From geir.noklebye at dayturn.com Wed Feb 1 22:09:30 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 07:09:30 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <510CC462-9BCA-4908-B65E-C7DD29D96A3A@dayturn.com> 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: Couldn't initialize GL_ARB_occlusion_query2 There is no code path that that will handle this extension missing apart from logging it, so the viewer crash in the lloctree portion of the code where this extension is used, specifically in the LLOcclusionCullingGroup. You will often see it accompanied with the EARLY-FAIL occlusion state (defined in llvieweroctree.h) The viewers logs other missing extensions too, which we have fixed in Kokua. From geir.noklebye at dayturn.com Wed Feb 1 22:25:06 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 07:25:06 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: 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 crashes will happen but it is in status ?will not fix? because this is expected behavior. (I have this as an open acknowledged Radar) in llopenglview-objc.mm there is a NSOpenGLPixelFormatAttribute attrs[] statement where there is a comment in the code that 10.7 and 10.8 don?t care about defining a profile or not. But from 10.11 it cares A LOT! Unless you define a profile of NSOpenGLProfileVersion3_2Core the system will force you to the NSOpenGLProfileVersionLegacy, which will not give you access to extensions such as GL_ARB_occlusion_query2. Before 10.11 you could work around it by going directly to the hardware address of the extension (which the current viewer code does), but from 10.11 there is NO WAY of getting to it unless you have used NSOpenGLProfileVersion3_2Core and rewritten the renderer for it. The reason for this that from 10.11 Apple started compositing the macOS desktop with Metal, and this change made it necessary to very tightly control access to the GPU without disaster striking. Already at the WWDC where 10.10 was introduced Apple strongly urged developers to rewrite their code to use the NSOpenGLProfileVersion3_2Core profile. If you use this profile, the viewer will not compile. From geir.noklebye at dayturn.com Wed Feb 1 22:32:05 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 07:32:05 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <903AA6E4-B341-491D-AFF2-36763A4A393A@dayturn.com> 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 of the extension, but this viewer does not support Metal, which is why you see reduced system performance at a typical loss of 7-10 fps at a minimum (what you actually see is performance loss in compositing the desktop that the viewer runs windowed in.) Also this driver is made for the Mac Pro (trash can models) and they just ?happen to work? for the time being. From geir.noklebye at dayturn.com Wed Feb 1 23:14:21 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 08:14:21 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <47EC0B84-5982-44FC-8D2C-93ABC7747BA7@dayturn.com> 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 within 30 secs to 2 minutes in many scenes to 10+ minutes to not happening at all in the same scenes. This was done through a series of steps: 1. The simplest and most surprising was adding an Apple OpenGL header to llglshaderheaders.h namely 2. Enabling all extensions the viewer logged as not available except GL_ARB_occlusion_query2 which we can?t get to 3. Not include llerror.h in llwindow 4. Eliminate all autoreleasepool statements from the code (which you have to do to compile the viewer with Xcode 8 anyway) 5. Advice users with NVIDIA cards and 512 Mb or less graphics memory to lower the texture memory setting in graphics preferences to 384 Mb. (this extends the delay before crash some in many scenes.) 6. Fixed the gamme used by the system from 1.8 to 2.2 which has been the system default since macOS 10.6 7. Cleaned up font loading and use the Menlo system font as fixed width font. 8. Deployment target of 10.9 and now 10.10. - Which reminds me that some of the libraries for the 64.bit viewer builds have a 10.11 deployment target while the viewer has 10.9. This is NOT good! The viewer still crash in the occlusion code, but not as often as without these changes. From sldev at free.fr Thu Feb 2 04:42:50 2017 From: sldev at free.fr (Henri Beauchamp) Date: Thu, 2 Feb 2017 13:42:50 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <47EC0B84-5982-44FC-8D2C-93ABC7747BA7@dayturn.com> References: <47EC0B84-5982-44FC-8D2C-93ABC7747BA7@dayturn.com> Message-ID: <20170202134250.6ba62e6f877b476e61b78cc7@free.fr> 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 ? Henri. From geir.noklebye at dayturn.com Thu Feb 2 05:15:07 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 14:15:07 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <21CE813F-F600-459B-941A-EEF720812151@dayturn.com> 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 + 3345260 1 com.apple.GeForceGLDriver 0x905a9c99 gldGetQueryInfo + 77 2 GLEngine 0x981decd0 glGetQueryObject_Core + 311 3 GLEngine 0x981deda2 glGetQueryObjectuiv_Exec + 47 4 libGL.dylib 0x97590a00 glGetQueryObjectuivARB + 29 5 org.kokuaviewer.KokuaOS 0x01342ef7 LLOcclusionCullingGroup::checkOcclusion() + 2071 6 org.kokuaviewer.KokuaOS 0x015d3cf3 LLPipeline::stateSort(LLCamera&, LLCullResult&) + 1539 7 org.kokuaviewer.KokuaOS 0x015f85f1 LLPipeline::renderShadow(glh::ns_float::matrix4&, glh::ns_float::matrix4&, LLCamera&, LLCullResult&, bool, bool, unsigned int) + 705 8 org.kokuaviewer.KokuaOS 0x015ff3e6 LLPipeline::generateSunShadow(LLCamera&) + 17350 9 org.kokuaviewer.KokuaOS 0x011bf1c0 display(int, float, int, int) + 12304 10 org.kokuaviewer.KokuaOS 0x003055b3 LLAppViewer::mainLoop() + 9523 11 org.kokuaviewer.KokuaOS 0x00347edb runMainLoop() + 43 12 org.kokuaviewer.KokuaOS 0x002b4543 -[LLAppDelegate mainLoop] + 19 13 com.apple.Foundation 0x95e11796 __NSFireTimer + 97 14 com.apple.CoreFoundation 0x946bacc6 __CFRUNLOOP_IS_CALLING_OUT_TO_A_TIMER_CALLBACK_FUNCTION__ + 22 15 com.apple.CoreFoundation 0x946ba7dd __CFRunLoopDoTimer + 1213 16 com.apple.CoreFoundation 0x946ba27e __CFRunLoopDoTimers + 350 17 com.apple.CoreFoundation 0x946b1de0 __CFRunLoopRun + 2192 18 com.apple.CoreFoundation 0x946b12ea CFRunLoopRunSpecific + 506 19 com.apple.CoreFoundation 0x946b10db CFRunLoopRunInMode + 123 20 com.apple.HIToolbox 0x93db0d36 RunCurrentEventLoopInMode + 268 21 com.apple.HIToolbox 0x93db0b22 ReceiveNextEventCommon + 494 22 com.apple.HIToolbox 0x93db091b _BlockUntilNextEventMatchingListInModeWithFilter + 83 23 com.apple.AppKit 0x9257bfed _DPSNextEvent + 1227 24 com.apple.AppKit 0x92ce0274 -[NSApplication(NSEvent) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 1742 25 com.apple.AppKit 0x92cdfb9e -[NSApplication(NSEvent) nextEventMatchingMask:untilDate:inMode:dequeue:] + 132 26 com.apple.AppKit 0x92570c88 -[NSApplication run] + 943 27 com.apple.AppKit 0x9253dc26 NSApplicationMain + 1368 28 libdyld.dylib 0x9f7883b5 start + 1 I forgot to mention I always build with RelWithDebInfo and -O3 optimization to get Apple?s crash reports. I have turned off as much of Breakpad as possible without ripping it completely out. To debug macOS applications without Xcode debugging and the system generated crash reports is almost impossible. From kirstiemc555 at hotmail.co.uk Thu Feb 2 06:38:16 2017 From: kirstiemc555 at hotmail.co.uk (Whirly Fizzle) Date: Thu, 2 Feb 2017 14:38:16 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <20170202134250.6ba62e6f877b476e61b78cc7@free.fr> References: <47EC0B84-5982-44FC-8D2C-93ABC7747BA7@dayturn.com>, <20170202134250.6ba62e6f877b476e61b78cc7@free.fr> Message-ID: We already tried getting Firestorm users to disable Object-Object occlusion. This didn't affect the frequency of the crashes at all. As Geir said, lowering the texture memory does seem to lessen the frequency of the crashes, but this causes increased texture thrashing so it is not really a good workaround, though I guess increased texture thrashing is preferable to crashing all the time. The only "good" workaround found so far is switching to using the Nvidia web drivers. This is not always possible though, for example the guy on https://jira.secondlife.com/browse/BUG-40674 is stuffed because there are no web drivers available for his card. His only option is to roll back to Mavericks to fix the crashes. ________________________________ From: opensource-dev-bounces at lists.secondlife.com on behalf of Henri Beauchamp Sent: 02 February 2017 12:42 To: opensource-dev at 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 actually didn't fix anything... Stupid question: what happens if you disable the Objects occlusion setting in the graphics preferences ? Henri. _______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/OpenSource-Dev OpenSource-Dev - Second Life Wiki wiki.secondlife.com Posting Policies and Guidelines. The opensource-dev mailing list is for development issue related to Second Life open source code. The following policies ... Please read the policies before posting to keep unmoderated posting privileges -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170202/f9d19007/attachment-0001.htm From geir.noklebye at dayturn.com Thu Feb 2 07:08:34 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 16:08:34 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: <731FE9A2-F425-4B22-BAF0-F03EF980CA02@dayturn.com> 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 issues are ?real? fixes, as it is both deprecated and won't even compile on Xcode 8. If you turn off shadows but with Ambient Occlusion turned on, with the latest KokuaOS builds I can stay in a scene even for hours. Other viewers will crash after a few minutes with only Ambient Occlusion turned on. With Shadows turned on in addition I can use the viewer for extended periods in some scenes (more than 10 minutes) that before would crash it within 2 minutes. Latest Cool VL will crash within 30 seconds of turning on shadows. ? InstaCrash? For the user it is immaterial of you crash after 30 seconds of 2 minutes, the viewer is for all practical purposes useless. I have SL users who have been on the brink on reverting to macOS 10.10, but can stay in SecondLife with the KokuaOS builds. If you turn off Objects occlusion it does not make any difference. It is Ambient occlusion and shadows that is the big killer (see the crash signature I posted before.) We have also made some adjustments to the NSOpenGLPixelFormatAttribute attrs[] statement such as turning on supersampling as that will help on Retina displays in particular as the scene will be rendered at much higher resolution and then downsampled to the screen resolution in the desktop compositing phase. From cinder at alchemyviewer.org Thu Feb 2 07:32:33 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 2 Feb 2017 15:32:33 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: <731FE9A2-F425-4B22-BAF0-F03EF980CA02@dayturn.com> References: <731FE9A2-F425-4B22-BAF0-F03EF980CA02@dayturn.com> Message-ID: <01000159ff74ad9d-0fd86e14-e389-454e-8c1b-baf5c1dc04ae-000000@email.amazonses.com> On February 2, 2017 at 9:08:44 AM, Geir N?klebye (geir.noklebye at 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 cause of the problem is not fixed, no. It put some bandaids on it to reduce the crash frequency. The autoreleasepool issues are ?real? fixes, as it is both deprecated and won't even compile on Xcode 8. It actually isn?t, as was already discussed on this list several months ago at length? but keep sipping that koolaid from the company who can?t even implement fork() properly and removes features from its own OS because it crashes their 3D driver. --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170202/ddc09383/attachment.htm From geir.noklebye at dayturn.com Thu Feb 2 12:57:07 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Thu, 2 Feb 2017 21:57:07 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: @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 not launch in macOS Sierra. Developers should use Automatic Reference Counting (ARC) or manual retain/release for memory management instead. (20589595) https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html This was enforced in the Xcode 8 beta program, but was eased at release, but I believe it will be reintroduced in the forthcoming 8.3 release as it again appears in the 8.3 beta release notes. Referring to Apple developer notes on deprecations and changes as koolaid pretty much says it all. From cinder at alchemyviewer.org Thu Feb 2 13:10:31 2017 From: cinder at alchemyviewer.org (=?UTF-8?Q?Cinder_Roxley?=) Date: Thu, 2 Feb 2017 21:10:31 +0000 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries In-Reply-To: References: Message-ID: <0100015a00aa1598-5d1d7869-0c82-421c-8945-3fc237aad773-000000@email.amazonses.com> On February 2, 2017 at 2:57:13 PM, Geir N?klebye (geir.noklebye at 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 garbage collection runtime. Applications or features that depend upon garbage collection may not function properly or will not launch in macOS Sierra. Developers should use Automatic Reference Counting (ARC) or manual retain/release for memory management instead. (20589595)? https://developer.apple.com/library/content/releasenotes/DeveloperTools/RN-Xcode/Introduction.html? This was enforced in the Xcode 8 beta program, but was eased at release, but I believe it will be reintroduced in the forthcoming 8.3 release as it again appears in the 8.3 beta release notes.? Referring to Apple developer notes on deprecations and changes as koolaid pretty much says it all.? Please see last July when you were already banging this drum and it was explained multiple times that the viewer never used GC so your claim was misinformed and the deprecation irrelevant to sl viewer: https://lists.secondlife.com/pipermail/opensource-dev/2016-July/thread.html#10248 I won?t waste any further time on this. Enjoy spamming the list and pulling our changes. :) --? Cinder Roxley Sent with Airmail -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170202/3ca9ac93/attachment.htm From geir.noklebye at dayturn.com Fri Feb 3 13:06:52 2017 From: geir.noklebye at dayturn.com (=?utf-8?Q?Geir_N=C3=B8klebye?=) Date: Fri, 3 Feb 2017 22:06:52 +0100 Subject: [opensource-dev] Mac viewer and Apple maintained opensource libraries Message-ID: 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 alternative viewers even being a possibility, and all the work they share on a daily basis. You don?t have to worry about spamming. Early next week I?m heading for the hospital for major surgery and by the time I need a viewer again (if ever), I hope I have learned so much from exploring the code over the last year, that I can start to make some real contributions. From flats_fixed at flatsfixedbicycles.com Sat Feb 11 08:55:45 2017 From: flats_fixed at flatsfixedbicycles.com (Brent Racobs) Date: Sat, 11 Feb 2017 10:55:45 -0600 Subject: [opensource-dev] opensource-dev Digest, Vol 78, Issue 26 In-Reply-To: References: Message-ID: On Jan 31, 2017 2:00 PM, wrote: > Send opensource-dev mailing list submissions to > opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/openso > urce-dev > or, via email, send a message with subject or body 'help' to > opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > 1. Re: Linux (Oz Linden (Scott Lawrence)) > 2. Mac viewer and Apple maintained opensource libraries > (Geir N?klebye) > 3. Re: Mac viewer and Apple maintained opensource libraries > (Cinder Roxley) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Mon, 30 Jan 2017 18:37:49 -0500 > From: "Oz Linden (Scott Lawrence)" > Subject: Re: [opensource-dev] Linux > To: "Nicky D." > Cc: "opensource-dev at lists.secondlife.com" > , Nat Goodspeed > > Message-ID: <4a74f4d6-835b-70fe-f31f-5de197cf37f9 at lindenlab.com> > Content-Type: text/plain; charset="utf-8" > > On 2017-01-30 12:41 , Nicky D. wrote: > >> 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? > No, we're going to leapfrog to Jessie for this. > > >> 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 > > Well, if it was easy it wouldn't be any fun, would it? > > -- > OZ LINDEN | Engineering Director, Second Life > email or hangouts: oz at lindenlab.com | Real > Life: Scott Lawrence > LINDEN LAB | Create Virtual Experiences > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > ents/20170130/73d930ef/attachment.html > > ------------------------------ > > Message: 2 > Date: Tue, 31 Jan 2017 11:55:13 +0100 > From: Geir N?klebye > Subject: [opensource-dev] Mac viewer and Apple maintained opensource > libraries > To: opensource-dev at lists.secondlife.com > Message-ID: <197E8CC4-417C-439E-AEE4-0231243277C4 at dayturn.com> > Content-Type: text/plain; charset="utf-8" > > 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 (a lot of) effort on maintaining them for > macOS on your own. > > Opensource that is included in every version of macOS is listed on > https://opensource.apple.com with code to > be downloaded. > > > In addition there are the system framework image handling dylibs in > /System/Library/Frameworks/ApplicationServices.framework/Fra > meworks/ImageIO.framework/Resources/ > > Cheers, > Geir N?klebye aka Gavin Hird > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > ents/20170131/62ebbe35/attachment-0001.htm > > ------------------------------ > > Message: 3 > Date: Tue, 31 Jan 2017 12:05:53 +0000 > From: Cinder Roxley > Subject: Re: [opensource-dev] Mac viewer and Apple maintained > opensource libraries > To: opensource-dev at lists.secondlife.com > > Message-ID: > <01000159f46abe46-afa83f5f-857c-4ac7-a983-2e4f55ee2dbb-00000 > 0 at email.amazonses.com> > > Content-Type: text/plain; charset="utf-8" > > On January 31, 2017 at 4:55:26 AM, Geir N?klebye ( > geir.noklebye at 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, hunspell and openssl. > Most of which are woefully out of date. > > --? > Cinder Roxley > Sent with Airmail > > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > ents/20170131/db2fcc4e/attachment-0001.htm > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 78, Issue 26 > ********************************************** > This has been the largest waist of Linden Lab's money in development I have ever had a chance to watch. the x86 cpu is an ancient devices. The thought of looking at all the commits on scripts for "ARCH" is insane. As many of us have watched this OZ we pretty much watched you single handed steal money from linden lab's for unnecessary work. Windows 7 is no longer supported by windows on 99 percent of the machines Vivox makes a 64 bit plugin for you. Fact OZ your wonderful Autobuild I do like has become a joke. ARMS 32 cpu will be fazed out soon the viewer has no use for it. Just take the work Imprudence did in 2009 and stop ripping off Linden Lab's ok. Mac is now only supporting 64 bit since last year. Windows 10 is the same. At this point your team has pretty much become worthless writing commits for ARCH This is real simple stuff in the opensource community. To create a build system that requires scripts to build 32 and 64 bit when there is no need to do this. And to think Linden Labs is this blind to watch you rip them off is nut's. build your 64 bit lib's and build the viewer. Fix the code in the client like we all have been doing for years so it compiles stop ripping off Linden Labs. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170211/63b7113a/attachment.htm From darien.caldwell at gmail.com Sat Feb 11 09:59:29 2017 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sat, 11 Feb 2017 09:59:29 -0800 Subject: [opensource-dev] opensource-dev Digest, Vol 78, Issue 26 In-Reply-To: References: Message-ID: On Sat, Feb 11, 2017 at 8:55 AM, Brent Racobs < flats_fixed at flatsfixedbicycles.com> wrote: > >> This has been the largest waist of Linden Lab's money in development I > have ever had a chance to watch. > the x86 cpu is an ancient devices. > The thought of looking at all the commits on scripts for "ARCH" is insane. > As many of us have watched this OZ we pretty much watched you single > handed steal money from linden lab's > for unnecessary work. Windows 7 is no longer supported by windows on 99 > percent of the machines Vivox makes a 64 bit > plugin for you. > Fact OZ your wonderful Autobuild I do like has become a joke. ARMS 32 cpu > will be fazed out soon the viewer has no use for it. > Just take the work Imprudence did in 2009 and stop ripping off Linden > Lab's ok. > Mac is now only supporting 64 bit since last year. Windows 10 is the same. > At this point your team has pretty much become worthless writing commits > for ARCH > > This is real simple stuff in the opensource community. > To create a build system that requires scripts to build 32 and 64 bit when > there is no need to > do this. > And to think Linden Labs is this blind to watch you rip them off is nut's. > build your 64 bit lib's and build the viewer. Fix the code in the client > like we all have been doing > for years so it compiles stop ripping off Linden Labs. > > > It's not 'stealing money', it's their job. I'll be honest I barely follow what you're trying to say, but I do see of factual inaccuracies. - Windows 7 is still being run on 40% of machines worldwide; whether Microsoft continues to support it officially or not is irrelevant. - Windows 10 *does* support 32 bit, both as an O/S version, and as the ability to run 32 bit executables. 32 bit isn't going away. And since some key libraries such as Havok only have 32 bit versions, a 32 bit Viewer will always be required. - The whole point of LL having an Open Source program is to share the viewer code with the community. Nobody is "Ripping LL off", LL does what they do to share the fruits of their labor with the community. In short they *want* the community to use their work. Otherwise they wouldn't publish anything. And in turn the community supplies them with code as well (which they are choosy about accepting, as is their right). As for Apple, IMHO it can DIAF, but trying to support it certainly isn't a waste if a large enough % of users use that O/S. I'm pretty sure LL is in a far better position to judge what is and isn't a waste of their resources than you are. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170211/e43a956e/attachment-0001.htm From flats_fixed at flatsfixedbicycles.com Sun Feb 12 15:01:53 2017 From: flats_fixed at flatsfixedbicycles.com (Brent Racobs) Date: Sun, 12 Feb 2017 17:01:53 -0600 Subject: [opensource-dev] opensource-dev Digest, Vol 79, Issue 7 In-Reply-To: References: Message-ID: OH well some one gets paid to complicate stuff. To me it is a rip off to linden labs. the 64 bit viewer was done a long time ago rest is stroking some scripts. No respect for the wheel I see. On Sat, Feb 11, 2017 at 11:59 AM, < opensource-dev-request at lists.secondlife.com> wrote: > Send opensource-dev mailing list submissions to > opensource-dev at lists.secondlife.com > > To subscribe or unsubscribe via the World Wide Web, visit > https://lists.secondlife.com/cgi-bin/mailman/listinfo/ > opensource-dev > or, via email, send a message with subject or body 'help' to > opensource-dev-request at lists.secondlife.com > > You can reach the person managing the list at > opensource-dev-owner at lists.secondlife.com > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of opensource-dev digest..." > > > Today's Topics: > > 1. Re: opensource-dev Digest, Vol 78, Issue 26 (Brent Racobs) > 2. Re: opensource-dev Digest, Vol 78, Issue 26 (Darien Caldwell) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Sat, 11 Feb 2017 10:55:45 -0600 > From: Brent Racobs > Subject: Re: [opensource-dev] opensource-dev Digest, Vol 78, Issue 26 > To: opensource-dev at lists.secondlife.com > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Jan 31, 2017 2:00 PM, > wrote: > > > Send opensource-dev mailing list submissions to > > opensource-dev at lists.secondlife.com > > > > To subscribe or unsubscribe via the World Wide Web, visit > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/openso > > urce-dev > > or, via email, send a message with subject or body 'help' to > > opensource-dev-request at lists.secondlife.com > > > > You can reach the person managing the list at > > opensource-dev-owner at lists.secondlife.com > > > > When replying, please edit your Subject line so it is more specific > > than "Re: Contents of opensource-dev digest..." > > > > > > Today's Topics: > > > > 1. Re: Linux (Oz Linden (Scott Lawrence)) > > 2. Mac viewer and Apple maintained opensource libraries > > (Geir N?klebye) > > 3. Re: Mac viewer and Apple maintained opensource libraries > > (Cinder Roxley) > > > > > > ---------------------------------------------------------------------- > > > > Message: 1 > > Date: Mon, 30 Jan 2017 18:37:49 -0500 > > From: "Oz Linden (Scott Lawrence)" > > Subject: Re: [opensource-dev] Linux > > To: "Nicky D." > > Cc: "opensource-dev at lists.secondlife.com" > > , Nat Goodspeed > > > > Message-ID: <4a74f4d6-835b-70fe-f31f-5de197cf37f9 at lindenlab.com> > > Content-Type: text/plain; charset="utf-8" > > > > On 2017-01-30 12:41 , Nicky D. wrote: > > >> 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? > > No, we're going to leapfrog to Jessie for this. > > > > >> 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 > > > > Well, if it was easy it wouldn't be any fun, would it? > > > > -- > > OZ LINDEN | Engineering Director, Second Life > > email or hangouts: oz at lindenlab.com | Real > > Life: Scott Lawrence > > LINDEN LAB | Create Virtual Experiences > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > > ents/20170130/73d930ef/attachment.html > > > > ------------------------------ > > > > Message: 2 > > Date: Tue, 31 Jan 2017 11:55:13 +0100 > > From: Geir N?klebye > > Subject: [opensource-dev] Mac viewer and Apple maintained opensource > > libraries > > To: opensource-dev at lists.secondlife.com > > Message-ID: <197E8CC4-417C-439E-AEE4-0231243277C4 at dayturn.com> > > Content-Type: text/plain; charset="utf-8" > > > > 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 (a lot of) effort on maintaining them for > > macOS on your own. > > > > Opensource that is included in every version of macOS is listed on > > https://opensource.apple.com with code > to > > be downloaded. > > > > > > In addition there are the system framework image handling dylibs in > > /System/Library/Frameworks/ApplicationServices.framework/Fra > > meworks/ImageIO.framework/Resources/ > > > > Cheers, > > Geir N?klebye aka Gavin Hird > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > > ents/20170131/62ebbe35/attachment-0001.htm > > > > ------------------------------ > > > > Message: 3 > > Date: Tue, 31 Jan 2017 12:05:53 +0000 > > From: Cinder Roxley > > Subject: Re: [opensource-dev] Mac viewer and Apple maintained > > opensource libraries > > To: opensource-dev at lists.secondlife.com > > > > Message-ID: > > <01000159f46abe46-afa83f5f-857c-4ac7-a983-2e4f55ee2dbb-00000 > > 0 at email.amazonses.com> > > > > Content-Type: text/plain; charset="utf-8" > > > > On January 31, 2017 at 4:55:26 AM, Geir N?klebye ( > > geir.noklebye at 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, hunspell and openssl. > > Most of which are woefully out of date. > > > > --? > > Cinder Roxley > > Sent with Airmail > > > > -------------- next part -------------- > > An HTML attachment was scrubbed... > > URL: http://lists.secondlife.com/pipermail/opensource-dev/attachm > > ents/20170131/db2fcc4e/attachment-0001.htm > > > > ------------------------------ > > > > _______________________________________________ > > opensource-dev mailing list > > opensource-dev at lists.secondlife.com > > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > > > > End of opensource-dev Digest, Vol 78, Issue 26 > > ********************************************** > > > This has been the largest waist of Linden Lab's money in development I have > ever had a chance to watch. > the x86 cpu is an ancient devices. > The thought of looking at all the commits on scripts for "ARCH" is insane. > As many of us have watched this OZ we pretty much watched you single handed > steal money from linden lab's > for unnecessary work. Windows 7 is no longer supported by windows on 99 > percent of the machines Vivox makes a 64 bit > plugin for you. > Fact OZ your wonderful Autobuild I do like has become a joke. ARMS 32 cpu > will be fazed out soon the viewer has no use for it. > Just take the work Imprudence did in 2009 and stop ripping off Linden Lab's > ok. > Mac is now only supporting 64 bit since last year. Windows 10 is the same. > At this point your team has pretty much become worthless writing commits > for ARCH > > This is real simple stuff in the opensource community. > To create a build system that requires scripts to build 32 and 64 bit when > there is no need to > do this. > And to think Linden Labs is this blind to watch you rip them off is nut's. > build your 64 bit lib's and build the viewer. Fix the code in the client > like we all have been doing > for years so it compiles stop ripping off Linden Labs. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/ > attachments/20170211/63b7113a/attachment-0001.htm > > ------------------------------ > > Message: 2 > Date: Sat, 11 Feb 2017 09:59:29 -0800 > From: Darien Caldwell > Subject: Re: [opensource-dev] opensource-dev Digest, Vol 78, Issue 26 > To: "opensource-dev at lists.secondlife.com" > > Message-ID: > gmail.com> > Content-Type: text/plain; charset="utf-8" > > On Sat, Feb 11, 2017 at 8:55 AM, Brent Racobs < > flats_fixed at flatsfixedbicycles.com> wrote: > > > > >> This has been the largest waist of Linden Lab's money in development I > > have ever had a chance to watch. > > the x86 cpu is an ancient devices. > > The thought of looking at all the commits on scripts for "ARCH" is > insane. > > As many of us have watched this OZ we pretty much watched you single > > handed steal money from linden lab's > > for unnecessary work. Windows 7 is no longer supported by windows on 99 > > percent of the machines Vivox makes a 64 bit > > plugin for you. > > Fact OZ your wonderful Autobuild I do like has become a joke. ARMS 32 cpu > > will be fazed out soon the viewer has no use for it. > > Just take the work Imprudence did in 2009 and stop ripping off Linden > > Lab's ok. > > Mac is now only supporting 64 bit since last year. Windows 10 is the > same. > > At this point your team has pretty much become worthless writing commits > > for ARCH > > > > This is real simple stuff in the opensource community. > > To create a build system that requires scripts to build 32 and 64 bit > when > > there is no need to > > do this. > > And to think Linden Labs is this blind to watch you rip them off is > nut's. > > build your 64 bit lib's and build the viewer. Fix the code in the > client > > like we all have been doing > > for years so it compiles stop ripping off Linden Labs. > > > > > > It's not 'stealing money', it's their job. I'll be honest I barely follow > what you're trying to say, but I do see of factual inaccuracies. > - Windows 7 is still being run on 40% of machines worldwide; whether > Microsoft continues to support it officially or not is irrelevant. > - Windows 10 *does* support 32 bit, both as an O/S version, and as the > ability to run 32 bit executables. 32 bit isn't going away. And since some > key libraries such as Havok only have 32 bit versions, a 32 bit Viewer will > always be required. > - The whole point of LL having an Open Source program is to share the > viewer code with the community. Nobody is "Ripping LL off", LL does what > they do to share the fruits of their labor with the community. In short > they *want* the community to use their work. Otherwise they wouldn't > publish anything. And in turn the community supplies them with code as well > (which they are choosy about accepting, as is their right). > > As for Apple, IMHO it can DIAF, but trying to support it certainly isn't a > waste if a large enough % of users use that O/S. I'm pretty sure LL is in > a far better position to judge what is and isn't a waste of their resources > than you are. > -------------- next part -------------- > An HTML attachment was scrubbed... > URL: http://lists.secondlife.com/pipermail/opensource-dev/ > attachments/20170211/e43a956e/attachment.htm > > ------------------------------ > > _______________________________________________ > opensource-dev mailing list > opensource-dev at lists.secondlife.com > https://lists.secondlife.com/cgi-bin/mailman/listinfo/opensource-dev > > > End of opensource-dev Digest, Vol 79, Issue 7 > ********************************************* > -- FLATS FIXED Emergency repairs flatsfixedbicycles.com This message has been sent by the most powerful bleeding edge operating system known to man SLACKWARE64-CURRENT We Get The Slack Back. It is free. Try it you will never go back just keep the slack. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170212/01c7c4d5/attachment-0001.htm From nickyperian at gmail.com Sat Feb 18 10:33:55 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 18 Feb 2017 12:33:55 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: Any idea why autobuild the looks in the wrong location for installed-packages.xml? ========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ========== metadata file name: autobuild-package.xml built Second Life Viewer version 5.1.0.41141 installed files in installed-packages.xml no installed files found (C:\Users\Bill\P64\Kokua-SL-64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml) On Fri, Jan 13, 2017 at 4:53 PM, Nicky Perian wrote: > > and more... > >>You might have to specify "autobuild uninstall --address-size 64 xxxxx" > (or -A 64) for the autobuild uninstall command to >>select the correct > build directory. > > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild --address-size 32 > uninstall openjpeg > usage: autobuild [-V] [-h [HELP]] [-n] [-q] [-v] [-d] [-p PLATFORM] > [-A {32,64}] > {} ... > autobuild: error: invalid choice: 'uninstall' (choose from ) > > and more ....... > (autobuild-1.1) C:\Users\Bill\P64\Kokua-SL-64>autobuild uninstall > --address-size 32 openjpeg > Traceback (most recent call last): > File "C:\Users\Bill\Envs\autobuild-1.1\Scripts\autobuild-script.py", > line 11, in > load_entry_point('autobuild==1.1.3', 'console_scripts', 'autobuild')() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 263, in main > sys.exit(Autobuild().main(sys.argv[1:])) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\autobuild_main.py", > line 250, in main > tool_to_run.run(args) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 151, in run > uninstall_packages(args, installed_filename, args.package, > args.dry_run) > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\ > autobuild\autobuild_tool_uninstall.py", line 71, in uninstall_packages > installed_file.save() > File "c:\users\bill\envs\autobuild-1.1\lib\site-packages\autobuild\configfile.py", > line 366, in save > file(self.path, 'wb').write(llsd.format_pretty_xml(dict_ > representation)) > IOError: [Errno 2] No such file or directory: 'C:\\Users\\Bill\\P64\\Kokua- > SL-64\\build-vc120-$AUTOBUILD_ADDRSIZE\\packages\\installed-packages.xml' > > On Fri, Jan 13, 2017 at 4:25 PM, Nat Goodspeed wrote: > >> On Fri, Jan 13, 2017 at 5:01 PM, Nicky Perian >> wrote: >> >> Does "autobuild uninstall xxxxx" work for autobuild-1.1? >>> >> >> You might have to specify "autobuild uninstall --address-size 64 xxxxx" >> (or -A 64) for the autobuild uninstall command to select the correct build >> directory. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170218/1ae390d7/attachment.htm From nat at lindenlab.com Sat Feb 18 13:11:50 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Sat, 18 Feb 2017 16:11:50 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: On Feb 18, 2017 1:33 PM, "Nicky Perian" wrote: Any idea why autobuild the looks in the wrong location for installed-packages.xml? ========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped ========== metadata file name: autobuild-package.xml built Second Life Viewer version 5.1.0.41141 installed files in installed-packages.xml no installed files found (C:\Users\Bill\P64\Kokua-SL- 64\build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml) The autobuild feature that implicitly expands environment variables such as $AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and we probably haven't yet covered all the cases where that should happen. The initial implementation expanded variables right at the point when autobuild.xml is read, so the expansions applied EVERYWHERE. That turned out to be the wrong approach, since a number of autobuild commands rewrite autobuild.xml. We found, to our dismay, that after any such command, all the variables had been replaced with the specific value at that moment - making the parameterization useless. So now we expand variables in specific subcommands. I'm sure we don't yet do that everywhere we should. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170218/5616ee33/attachment.htm From nickyperian at gmail.com Tue Feb 21 06:36:28 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Tue, 21 Feb 2017 08:36:28 -0600 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: >>The autobuild feature that implicitly expands environment variables such as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent, and we probably haven't yet covered all the cases where that >>should happen. As far as i can tell this happens only on 32 bit builds. On Sat, Feb 18, 2017 at 3:11 PM, Nat Goodspeed wrote: > On Feb 18, 2017 1:33 PM, "Nicky Perian" wrote: > > Any idea why autobuild the looks in the wrong location for > installed-packages.xml? > > ========== Build: 5 succeeded, 0 failed, 29 up-to-date, 2 skipped > ========== > metadata file name: autobuild-package.xml > built Second Life Viewer version 5.1.0.41141 > installed files in installed-packages.xml > no installed files found (C:\Users\Bill\P64\Kokua-SL-64 > \build-vc120-$AUTOBUILD_ADDRSIZE\packages\installed-packages.xml) > > > The autobuild feature that implicitly expands environment variables such > as $AUTOBUILD_ADDRSIZE appearing in autobuild.xml is relatively recent, and > we probably haven't yet covered all the cases where that should happen. > > The initial implementation expanded variables right at the point when > autobuild.xml is read, so the expansions applied EVERYWHERE. That turned > out to be the wrong approach, since a number of autobuild commands rewrite > autobuild.xml. We found, to our dismay, that after any such command, all > the variables had been replaced with the specific value at that moment - > making the parameterization useless. > > So now we expand variables in specific subcommands. I'm sure we don't yet > do that everywhere we should. > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170221/ddafdf85/attachment.htm From nat at lindenlab.com Tue Feb 21 08:45:32 2017 From: nat at lindenlab.com (Nat Goodspeed) Date: Tue, 21 Feb 2017 11:45:32 -0500 Subject: [opensource-dev] 64 bit viewers build instructions In-Reply-To: References: <5a816f91-eb4f-185d-402e-52bfce23097c@lindenlab.com> <20161209111141.aeb9f636e48404c15d186243@free.fr> <7c5a0de4-69ed-681e-f98f-76dae5155585@lindenlab.com> Message-ID: On Tue, Feb 21, 2017 at 9:36 AM, Nicky Perian wrote: >>The autobuild feature that implicitly expands environment variables such > as $AUTOBUILD_ADDRSIZE >>appearing in autobuild.xml is relatively recent, > and we probably haven't yet covered all the cases where that >>should > happen. > > As far as i can tell this happens only on 32 bit builds. > Um. That's somewhat surprising, as I would expect that either we always fail to expand $AUTOBUILD_ADDRSIZE regardless of the value of that variable, or we always expand $AUTOBUILD_ADDRSIZE regardless of the value of that variable. But any specific use case -- "With this specific autobuild.xml and this version of autobuild, I issued this specific autobuild command and got the following result" -- would be helpful in diagnosing the problem. In fact, if it goes into a Jira instead of this email thread, it's less likely to get lost. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170221/1d763068/attachment.htm From oz at lindenlab.com Wed Feb 22 14:19:08 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Wed, 22 Feb 2017 17:19:08 -0500 Subject: [opensource-dev] 64bit builds ... new autobuild Message-ID: <190f5f15-d9e5-c0e4-783a-4d2dd9134baf@lindenlab.com> If you're doing builds based on our lindenlab/viewer64, you'll want to update your copy of autobuild to version 1.1.4 (or later, if there is one when you get to this). That new autobuild constructs the default revision number in a way that fits in a 32bit integer, which at least for the time being is what we need.... don't ask.... -- OZ LINDEN | Engineering Director, Second Life email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170222/f9f3b0f1/attachment.htm From pgloor at gmail.com Sat Feb 25 03:38:47 2017 From: pgloor at gmail.com (Peter Gloor) Date: Sat, 25 Feb 2017 12:38:47 +0100 Subject: [opensource-dev] How to deal with FMODEX? Message-ID: Following current instructions I've been trying to build an 'open' 32-bit viewer. After I failed building viewer-release with a bunch of errors I tried to build kokua-os, kokua-sl and phoenix-firestorm-lgpl. Except with Linden Labs viewer-release I succeeded when I configured autobuild for no FMODEX. I understand that for licencing reasons the FmodEx package cannot be distributed by Linden Lab and I have to manually do what Linden Lab does in the 3p-fmodex package to create my own package for FmodEx. The problem I have is that FmodEx is no longer actively supported and does no longer appear anywhere on the download pages at http://www.fmod.org. Any idea how to best deal with this problem? Is there another FMOD product I can pick the missing parts from? Or is there an alternative I'm not aware of? Any hints are welcome. Thanks in advance. Peter P.S. I'll take a look into and sort out the other problems I encountered with viewer-release after I've solved the FmodEx part. I successfully custom built Linden Lab viewers and Firestorm in the past (> 2 years ago). -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170225/890de75f/attachment.htm From nickyperian at gmail.com Sat Feb 25 07:56:30 2017 From: nickyperian at gmail.com (Nicky Perian) Date: Sat, 25 Feb 2017 09:56:30 -0600 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: References: Message-ID: Which platform are you using? You may want to use a non-commercial license of FmodEx. Then, send an email to FMOD support explaining your use of non-commercial provisions of their license and that you need access of FmodEx archives. It may take time for them to respond as there isn't any money involved. However, I the folks at FMOD are friendly and usually accommodating. Nicky On Sat, Feb 25, 2017 at 5:38 AM, Peter Gloor wrote: > Following current instructions I've been trying to build an 'open' 32-bit > viewer. After I failed building viewer-release with a bunch of errors I > tried to build kokua-os, kokua-sl and phoenix-firestorm-lgpl. Except with > Linden Labs viewer-release I succeeded when I configured autobuild for no > FMODEX. > > I understand that for licencing reasons the FmodEx package cannot be > distributed by Linden Lab and I have to manually do what Linden Lab does in > the 3p-fmodex package to create my own package for FmodEx. > > The problem I have is that FmodEx is no longer actively supported and does > no longer appear anywhere on the download pages at http://www.fmod.org. > > Any idea how to best deal with this problem? Is there another FMOD product > I can pick the missing parts from? Or is there an alternative I'm not aware > of? Any hints are welcome. > > Thanks in advance. > > Peter > > P.S. I'll take a look into and sort out the other problems I encountered > with viewer-release after I've solved the FmodEx part. I successfully > custom built Linden Lab viewers and Firestorm in the past (> 2 years ago). > > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170225/1e4bd3b9/attachment.htm From pgloor at gmail.com Sat Feb 25 09:21:08 2017 From: pgloor at gmail.com (Peter Gloor) Date: Sat, 25 Feb 2017 18:21:08 +0100 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: References: Message-ID: The platform I'm building on is Windows. Thanks for the hint, I'll send them an eMail. Maybe I'm lucky and find an archive on one of the backups I made on my old computer. Peter 2017-02-25 16:56 GMT+01:00 Nicky Perian : > Which platform are you using? > > You may want to use a non-commercial license of FmodEx. Then, send an > email to FMOD support explaining your use of non-commercial provisions of > their license and that you need access of FmodEx archives. > > It may take time for them to respond as there isn't any money involved. > > However, I the folks at FMOD are friendly and usually accommodating. > > > Nicky > > On Sat, Feb 25, 2017 at 5:38 AM, Peter Gloor wrote: > >> Following current instructions I've been trying to build an 'open' 32-bit >> viewer. After I failed building viewer-release with a bunch of errors I >> tried to build kokua-os, kokua-sl and phoenix-firestorm-lgpl. Except with >> Linden Labs viewer-release I succeeded when I configured autobuild for no >> FMODEX. >> >> I understand that for licencing reasons the FmodEx package cannot be >> distributed by Linden Lab and I have to manually do what Linden Lab does in >> the 3p-fmodex package to create my own package for FmodEx. >> >> The problem I have is that FmodEx is no longer actively supported and >> does no longer appear anywhere on the download pages at >> http://www.fmod.org. >> >> Any idea how to best deal with this problem? Is there another FMOD >> product I can pick the missing parts from? Or is there an alternative I'm >> not aware of? Any hints are welcome. >> >> Thanks in advance. >> >> Peter >> >> P.S. I'll take a look into and sort out the other problems I encountered >> with viewer-release after I've solved the FmodEx part. I successfully >> custom built Linden Lab viewers and Firestorm in the past (> 2 years ago). >> >> _______________________________________________ >> 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 >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170225/35ca5f0a/attachment.htm From sldev at free.fr Sat Feb 25 10:20:53 2017 From: sldev at free.fr (Henri Beauchamp) Date: Sat, 25 Feb 2017 19:20:53 +0100 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: References: Message-ID: <20170225192053.f8edef7a60500b7c7e7a9444@free.fr> On Sat, 25 Feb 2017 09:56:30 -0600, Nicky Perian wrote: > Which platform are you using? > > You may want to use a non-commercial license of FmodEx. Then, send an email > to FMOD support explaining your use of non-commercial provisions of their > license and that you need access of FmodEx archives. > > It may take time for them to respond as there isn't any money involved. I asked them access on Sat, 13 Aug 2016, and they enabled access on my account and replied with an email on Mon, 15 Aug 2016. They would hardly have been able to reply faster. :-D Henri. From darien.caldwell at gmail.com Sat Feb 25 15:28:26 2017 From: darien.caldwell at gmail.com (Darien Caldwell) Date: Sat, 25 Feb 2017 15:28:26 -0800 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: <20170225192053.f8edef7a60500b7c7e7a9444@free.fr> References: <20170225192053.f8edef7a60500b7c7e7a9444@free.fr> Message-ID: You don't even have to send an email. Just make an account on their site and you automatically have download access to the libraries. That's how I did it. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170225/42230548/attachment.htm From sldev at free.fr Sun Feb 26 02:34:13 2017 From: sldev at free.fr (Henri Beauchamp) Date: Sun, 26 Feb 2017 11:34:13 +0100 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: References: <20170225192053.f8edef7a60500b7c7e7a9444@free.fr> Message-ID: <20170226113413.b08584639a4c269d8b4c55c0@free.fr> On Sat, 25 Feb 2017 15:28:26 -0800, Darien Caldwell wrote: > You don't even have to send an email. Just make an account on their site > and you automatically have download access to the libraries. That's how I > did it. This is not what happened for me: the downloads page for the legacy products (which FMOD Ex now is) became inaccessible in August 2016 from my account and I had to request access again... Now, *perhaps* brand new accounts are since being granted access by default... Henri. From pgloor at gmail.com Sun Feb 26 03:11:00 2017 From: pgloor at gmail.com (Peter Gloor) Date: Sun, 26 Feb 2017 12:11:00 +0100 Subject: [opensource-dev] How to deal with FMODEX? In-Reply-To: <20170226113413.b08584639a4c269d8b4c55c0@free.fr> References: <20170225192053.f8edef7a60500b7c7e7a9444@free.fr> <20170226113413.b08584639a4c269d8b4c55c0@free.fr> Message-ID: Thank you, folks. I already had an account, but no access to FmodEx. However, support at Firelight Technologies was very responsive and provided access to FmodEx within a few hours. 2017-02-26 11:34 GMT+01:00 Henri Beauchamp : > On Sat, 25 Feb 2017 15:28:26 -0800, Darien Caldwell wrote: > > > You don't even have to send an email. Just make an account on their site > > and you automatically have download access to the libraries. That's how I > > did it. > > This is not what happened for me: the downloads page for the legacy > products > (which FMOD Ex now is) became inaccessible in August 2016 from my account > and > I had to request access again... Now, *perhaps* brand new accounts are > since > being granted access by default... > > Henri. > _______________________________________________ > 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 > -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170226/5f6b0b32/attachment.htm From oz at lindenlab.com Mon Feb 27 11:11:04 2017 From: oz at lindenlab.com (Oz Linden (Scott Lawrence)) Date: Mon, 27 Feb 2017 14:11:04 -0500 Subject: [opensource-dev] Fix for sending Snapshot emails from RC regions Message-ID: <4724647c-7fb1-aa16-b834-7472985b1d13@lindenlab.com> Linden Lab has been making changes to further protect personally identifying and other sensitive user information. As part of those changes, we no longer send the full correct email address to the viewer (an obfuscated form of the address is sent instead). This change was deployed recently to some of the simulator RC channels. At one time, the user's email address was used to initialize the From address when using the Send Snapshot as Email (postcard) feature of the viewer. For some time, the server has not been using the value sent from the viewer for this (because it might have been set incorrectly by the viewer), and the official viewer has not allowed modifying it, yet the code to initialize and return it to the simulator was still there. The viewer also had code to validate any value in that field (which, in older versions, might have been edited by the user); this validation code (correctly) fails when checking the obfuscated value sent by the simulator in these new Release Candidate. This was reported as BUG-41443 ; the effect is that sending the snapshot fails (or, on any TPV that still allows modifying the address, they will have to replace the obfuscated form with a valid address, but the simulator will not use that value when sending the email - it will use the address we have for that user in the database). So that open source viewers can quickly release updates that are compatible with the new email handling in the simulator, we have made availablea standalone repository with the appropriate viewer change . -- OZ LINDEN | Engineering Director, Second Life email or hangouts: oz at lindenlab.com | Real Life: Scott Lawrence LINDEN LAB | Create Virtual Experiences -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.secondlife.com/pipermail/opensource-dev/attachments/20170227/05783181/attachment.htm