Hi All,
what's happened with deleting all of Ronies work on the OpenGL support in the B3DAcceleratorPlugin on Mac OS X? It has all been deleted. That work was necessary in reviving 3D support for Terf on Mac OS X. Can someone please explain what's going on here. Why are we regressing to something dating from 2003?
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On 31.01.2018, at 22:26, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
what's happened with deleting all of Ronies work on the OpenGL support in the B3DAcceleratorPlugin on Mac OS X? It has all been deleted. That work was necessary in reviving 3D support for Terf on Mac OS X. Can someone please explain what's going on here. Why are we regressing to something dating from 2003?
I've been sitting with Fabio over a Bug https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/178 we were not able to fix but by reverting Ronies commit: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/275eca83761d0a9aa3e...
To Quote: " This reverts commit bc6e34d and fixes #178.
The vm segfaulted on Travis (#178) because this commit introduced the use of shader and assumed that shader compilation always works (see [1]). As a matter of fact, it does fail on Travis and maybe other macOS systems.
@ronsaldo please provide an updated PR to address the above.
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/bc6e34d1b2998cb8f3b... "
The original commit did not have any commentary besides "The B3D plugin is now working again on Mac OS X."
The move from "traditional" OpenGL to doing everything with shaders is quite drastic and it would be really helpful to comment the commit a bit more extensive.
The File comment
// Changes: 2017-05-13 Ronie Salgado. Refactored to remove the fixed function pipeline. // Implemented a layering system to be used in cooperation by the B3DAccelerationPlugin. // Fixing some graphical glitches that appeared when enabling the double buffering.
Is indeed explanatory, but a lot of code was just commented out and assumptions just made and not checked for. Also, a fallback is missing for basic, shaderless usage.
-=-=-=-
Please keep in mind that the original issue is that our release-process was stalled; the commit effected SegFaults on Travis, hence making, not producing build artifacts. We cannot guarantee that those segfaults wont happen on user machines.
Best regards -Tobias
_,,,^..^,,,_ best, Eliot
Hi Tobias,
On Wed, Jan 31, 2018 at 1:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
Hi Eliot,
On 31.01.2018, at 22:26, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
what's happened with deleting all of Ronies work on the OpenGLsupport in the B3DAcceleratorPlugin on Mac OS X? It has all been deleted. That work was necessary in reviving 3D support for Terf on Mac OS X. Can someone please explain what's going on here. Why are we regressing to something dating from 2003?
I've been sitting with Fabio over a Bug https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/178 we were not able to fix but by reverting Ronies commit: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ 275eca83761d0a9aa3e689a7f0c33465c6f160e1
To Quote: " This reverts commit bc6e34d and fixes #178.
The vm segfaulted on Travis (#178) because this commit introduced the use of shader and assumed that shader compilation always works (see [1]). As a matter of fact, it does fail on Travis and maybe other macOS systems.
@ronsaldo please provide an updated PR to address the above.
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/ bc6e34d1b2998cb8f3b38a2ce0818eda35a25ce9?diff=unified#diff- 7c007173fcbc79b3e9984468210d3d11R369 "
The original commit did not have any commentary besides "The B3D plugin is now working again on Mac OS X."
The move from "traditional" OpenGL to doing everything with shaders is quite drastic and it would be really helpful to comment the commit a bit more extensive.
The File comment
// Changes: 2017-05-13 Ronie Salgado. Refactored to remove the fixed function pipeline. // Implemented a layering system to be used in cooperation by the B3DAccelerationPlugin. // Fixing some graphical glitches that appeared when enabling the double buffering.
Is indeed explanatory, but a lot of code was just commented out and assumptions just made and not checked for. Also, a fallback is missing for basic, shaderless usage.
-=-=-=-
Please keep in mind that the original issue is that our release-process was stalled; the commit effected SegFaults on Travis, hence making, not producing build artifacts. We cannot guarantee that those segfaults wont happen on user machines.
That's insufficient justification for me. User machines aren't headless build slaves; they're real machines with graphics. And Ronie's work fixed the broken B3DAccelleratorPlugin on those machines. Work that Ron Teitelbaum had paid him to do in order to port Terf forward to Spur Squeak and someone just trashed all that work. That's unacceptable. All that's been "achieved" is to break the newly fixed B3DAccelleratorPlugin.
A better fix would be to disable the loading of the plugin if the system is headless. Can we please implement this ASAP?
_,,,^..^,,,_ best, Eliot
Hi Eliot,
On Wed, Jan 31, 2018 at 10:47 PM Eliot Miranda eliot.miranda@gmail.com wrote:
Hi Tobias,
On Wed, Jan 31, 2018 at 1:41 PM, Tobias Pape Das.Linux@gmx.de wrote:
Hi Eliot,
On 31.01.2018, at 22:26, Eliot Miranda eliot.miranda@gmail.com wrote:
Hi All,
what's happened with deleting all of Ronies work on the OpenGLsupport in the B3DAcceleratorPlugin on Mac OS X? It has all been deleted. That work was necessary in reviving 3D support for Terf on Mac OS X. Can someone please explain what's going on here. Why are we regressing to something dating from 2003?
I've been sitting with Fabio over a Bug https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/178 we were not able to fix but by reverting Ronies commit:
https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/275eca83761d0a9aa3e...
To Quote: " This reverts commit bc6e34d and fixes #178.
The vm segfaulted on Travis (#178) because this commit introduced the use of shader and assumed that shader compilation always works (see [1]). As a matter of fact, it does fail on Travis and maybe other macOS systems.
@ronsaldo please provide an updated PR to address the above.
[1] https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/bc6e34d1b2998cb8f3b... "
The original commit did not have any commentary besides "The B3D plugin is now working again on Mac OS X."
The move from "traditional" OpenGL to doing everything with shaders is quite drastic and it would be really helpful to comment the commit a bit more extensive.
The File comment
// Changes: 2017-05-13 Ronie Salgado. Refactored to remove the fixed function pipeline. // Implemented a layering system to be used in cooperation by the B3DAccelerationPlugin. // Fixing some graphical glitches that appeared when enabling the double buffering.
Is indeed explanatory, but a lot of code was just commented out and assumptions just made and not checked for. Also, a fallback is missing for basic, shaderless usage.
-=-=-=-
Please keep in mind that the original issue is that our release-process was stalled; the commit effected SegFaults on Travis, hence making, not producing build artifacts. We cannot guarantee that those segfaults wont happen on user machines.
That's insufficient justification for me. User machines aren't headless build slaves; they're real machines with graphics. And Ronie's work fixed the broken B3DAccelleratorPlugin on those machines. Work that Ron Teitelbaum had paid him to do in order to port Terf forward to Spur Squeak and someone just trashed all that work. That's unacceptable. All that's been "achieved" is to break the newly fixed B3DAccelleratorPlugin.
That someone was me and I wouldn't call it "trashed". Everything is still persisted in the version history and can be re-applied with a single Git command. Also, we did reach out to Ronie.
I didn't just roll-back for fun. I did it because it was blocking Squeak trunk and more importantly because there are many projects out there testing against Squeak/Pharo trunk with the VMs on CI.
A better fix would be to disable the loading of the plugin if the system is headless. Can we please implement this ASAP?
That'd be great. Do we have to postpone the release because of this or would it be ok to have this ready with the next release (hopefully in a few weeks)?
Fabio
_,,,^..^,,,_ best, Eliot
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Fabio Niephaus -
Tobias Pape