Recent changes.
Locked
 
|
Dear all a small summary of some latest issues. 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. Hence, I guarded the change[1] to Pharo only. 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. This could have been done via $ git checkout -b eliot-B3D-fixes Cog and then committing and pushing to this branch (commit would still be `git commit` or `scripts/gitci` for that matter, push would be `git push origin eliot-B3D-fixes`) That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. Since I needed a working windows VM with the fixes for (1.), I have gone forward and 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? I added it hence[4]. Best regards -Tobias [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be |
|
|
Hi Tobias, first, apologies. > On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: > > > Dear all > > a small summary of some latest issues. > > 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. > Hence, I guarded the change[1] to Pharo only. > > 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. > This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. > However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. > This could have been done via > > $ git checkout -b eliot-B3D-fixes Cog > > and then committing and pushing to this branch > (commit would still be `git commit` or `scripts/gitci` for that matter, > push would be `git push origin eliot-B3D-fixes`) > > That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. I promise not to do this again. I have to practice the branching to make it a habit. Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) > > Since I needed a working windows VM with the fixes for (1.), I have gone forward and > > 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? The intent is to have one copy of the logging code in platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. > > 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? > I added it hence[4]. > > Best regards > -Tobias > > > [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa > [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 > [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be > [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be |
|
|
> On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: > > > Hi Tobias, > > first, apologies. > No need. > >> On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: >> >> >> Dear all >> >> a small summary of some latest issues. >> >> 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. >> Hence, I guarded the change[1] to Pharo only. >> >> 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. >> This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. >> However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. >> This could have been done via >> >> $ git checkout -b eliot-B3D-fixes Cog >> >> and then committing and pushing to this branch >> (commit would still be `git commit` or `scripts/gitci` for that matter, >> push would be `git push origin eliot-B3D-fixes`) >> >> That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. > > I promise not to do this again. I have to practice the branching to make it a habit. Yeah, I can understand. I also still need to practice for that habit. I > Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) > ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. > >> >> Since I needed a working windows VM with the fixes for (1.), I have gone forward and >> >> 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? > > The intent is to have one copy of the logging code in > > platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… (That's why the verbosity-flag had not gl attached before, I presume) It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. Does that make sense? Best regards -Tobias > >> >> 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? >> I added it hence[4]. >> >> Best regards >> -Tobias >> >> >> [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa >> [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 >> [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be >> [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be |
|
|
B3D plugin is still broken for me :(
|
|
|
> On 04.05.2017, at 16:33, Esteban Lorenzano <[hidden email]> wrote: > > B3D plugin is still broken for me :( win32? Well, I just made it compile, to be frank. Maybe we should disable again for the time being? Best regards -Tobias > > >> On 3 May 2017, at 19:08, Tobias Pape <[hidden email]> wrote: >> >> >> >>> On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: >>> >>> >>> Hi Tobias, >>> >>> first, apologies. >>> >> >> No need. >> >>> >>>> On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: >>>> >>>> >>>> Dear all >>>> >>>> a small summary of some latest issues. >>>> >>>> 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. >>>> Hence, I guarded the change[1] to Pharo only. >>>> >>>> 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. >>>> This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. >>>> However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. >>>> This could have been done via >>>> >>>> $ git checkout -b eliot-B3D-fixes Cog >>>> >>>> and then committing and pushing to this branch >>>> (commit would still be `git commit` or `scripts/gitci` for that matter, >>>> push would be `git push origin eliot-B3D-fixes`) >>>> >>>> That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. >>> >>> I promise not to do this again. I have to practice the branching to make it a habit. >> >> Yeah, I can understand. I also still need to practice for that habit. I >> >>> Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) >>> >> >> ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. >> >>> >>>> >>>> Since I needed a working windows VM with the fixes for (1.), I have gone forward and >>>> >>>> 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? >>> >>> The intent is to have one copy of the logging code in >>> >>> platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. >> >> It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. >> By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… >> (That's why the verbosity-flag had not gl attached before, I presume) >> It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. >> Does that make sense? >> >> Best regards >> -Tobias >> >>> >>>> >>>> 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? >>>> I added it hence[4]. >>>> >>>> Best regards >>>> -Tobias >>>> >>>> >>>> [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa >>>> [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 >>>> [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be >>>> [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be > |
|
|
> On 4 May 2017, at 16:36, Tobias Pape <[hidden email]> wrote: > > > >> On 04.05.2017, at 16:33, Esteban Lorenzano <[hidden email]> wrote: >> >> B3D plugin is still broken for me :( > > win32? > Well, I just made it compile, to be frank. > Maybe we should disable again for the time being? no, for macOS. I just pulled latest changes from osvm into pharo and… boom! Esteban > > Best regards > -Tobias > >> >> >>> On 3 May 2017, at 19:08, Tobias Pape <[hidden email]> wrote: >>> >>> >>> >>>> On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: >>>> >>>> >>>> Hi Tobias, >>>> >>>> first, apologies. >>>> >>> >>> No need. >>> >>>> >>>>> On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: >>>>> >>>>> >>>>> Dear all >>>>> >>>>> a small summary of some latest issues. >>>>> >>>>> 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. >>>>> Hence, I guarded the change[1] to Pharo only. >>>>> >>>>> 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. >>>>> This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. >>>>> However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. >>>>> This could have been done via >>>>> >>>>> $ git checkout -b eliot-B3D-fixes Cog >>>>> >>>>> and then committing and pushing to this branch >>>>> (commit would still be `git commit` or `scripts/gitci` for that matter, >>>>> push would be `git push origin eliot-B3D-fixes`) >>>>> >>>>> That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. >>>> >>>> I promise not to do this again. I have to practice the branching to make it a habit. >>> >>> Yeah, I can understand. I also still need to practice for that habit. I >>> >>>> Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) >>>> >>> >>> ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. >>> >>>> >>>>> >>>>> Since I needed a working windows VM with the fixes for (1.), I have gone forward and >>>>> >>>>> 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? >>>> >>>> The intent is to have one copy of the logging code in >>>> >>>> platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. >>> >>> It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. >>> By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… >>> (That's why the verbosity-flag had not gl attached before, I presume) >>> It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. >>> Does that make sense? >>> >>> Best regards >>> -Tobias >>> >>>> >>>>> >>>>> 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? >>>>> I added it hence[4]. >>>>> >>>>> Best regards >>>>> -Tobias >>>>> >>>>> >>>>> [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa >>>>> [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 >>>>> [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be >>>>> [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be >> > |
|
|
> On 04.05.2017, at 16:37, Esteban Lorenzano <[hidden email]> wrote: > > > >> On 4 May 2017, at 16:36, Tobias Pape <[hidden email]> wrote: >> >> >> >>> On 04.05.2017, at 16:33, Esteban Lorenzano <[hidden email]> wrote: >>> >>> B3D plugin is still broken for me :( >> >> win32? >> Well, I just made it compile, to be frank. >> Maybe we should disable again for the time being? > > no, for macOS. > I just pulled latest changes from osvm into pharo and… boom! > Best regards -Tobias > Esteban > >> >> Best regards >> -Tobias >> >>> >>> >>>> On 3 May 2017, at 19:08, Tobias Pape <[hidden email]> wrote: >>>> >>>> >>>> >>>>> On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: >>>>> >>>>> >>>>> Hi Tobias, >>>>> >>>>> first, apologies. >>>>> >>>> >>>> No need. >>>> >>>>> >>>>>> On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: >>>>>> >>>>>> >>>>>> Dear all >>>>>> >>>>>> a small summary of some latest issues. >>>>>> >>>>>> 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. >>>>>> Hence, I guarded the change[1] to Pharo only. >>>>>> >>>>>> 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. >>>>>> This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. >>>>>> However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. >>>>>> This could have been done via >>>>>> >>>>>> $ git checkout -b eliot-B3D-fixes Cog >>>>>> >>>>>> and then committing and pushing to this branch >>>>>> (commit would still be `git commit` or `scripts/gitci` for that matter, >>>>>> push would be `git push origin eliot-B3D-fixes`) >>>>>> >>>>>> That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. >>>>> >>>>> I promise not to do this again. I have to practice the branching to make it a habit. >>>> >>>> Yeah, I can understand. I also still need to practice for that habit. I >>>> >>>>> Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) >>>>> >>>> >>>> ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. >>>> >>>>> >>>>>> >>>>>> Since I needed a working windows VM with the fixes for (1.), I have gone forward and >>>>>> >>>>>> 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? >>>>> >>>>> The intent is to have one copy of the logging code in >>>>> >>>>> platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. >>>> >>>> It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. >>>> By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… >>>> (That's why the verbosity-flag had not gl attached before, I presume) >>>> It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. >>>> Does that make sense? >>>> >>>> Best regards >>>> -Tobias >>>> >>>>> >>>>>> >>>>>> 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? >>>>>> I added it hence[4]. >>>>>> >>>>>> Best regards >>>>>> -Tobias >>>>>> >>>>>> >>>>>> [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa >>>>>> [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 >>>>>> [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be >>>>>> [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be >>> >> > |
|
|
I got it. B3D plugin Makefile asumes it will be building a bundle while Pharo does not use them. I need to rewrite it as this: # The current version of B3DAcceleratorPlugin (the OpenGL interface) uses # FindWindow, GetWindowGreatestAreaDevice & GetWindowPort which are Carbon & # 32-bit only. So include the Carbon frameworks. Until this can be rewritten # this implies no 64-bit OpenGL on Mac OS X :-(. INCDIRS:=../../platforms/Cross/plugins/FilePlugin \ ../../platforms/unix/vm INCDIRS:=../../platforms/unix/vm ifeq ($(VM),Pharo) EXTRALIBSFLAGS:=-undefined dynamic_lookup else # These three are imported from the VM. Use this explicit list instead of # -undefined dynamic_lookup to get errors for any other missing imports. EXTRABFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) EXTRADYFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) endif EXTRALIBS:=$(EXTRALIBSFLAGS) -framework CoreFoundation -framework Carbon -framework OpenGL -framework AGL include ../common/Makefile.plugin (yes, we need the -undefined flag :( ) I will be submitting the fix tomorrow. Esteban
|
|
|
Oh, is this Balloon3D ? Phil On Thu, May 4, 2017 at 9:08 PM, Esteban Lorenzano <[hidden email]> wrote: > > > On 4 May 2017, at 16:48, Tobias Pape <[hidden email]> wrote: > > > > On 04.05.2017, at 16:37, Esteban Lorenzano <[hidden email]> wrote: > > > > On 4 May 2017, at 16:36, Tobias Pape <[hidden email]> wrote: > > > > On 04.05.2017, at 16:33, Esteban Lorenzano <[hidden email]> wrote: > > B3D plugin is still broken for me :( > > > win32? > Well, I just made it compile, to be frank. > Maybe we should disable again for the time being? > > > no, for macOS. > I just pulled latest changes from osvm into pharo and… boom! > > Well… I haven't touched this… eliot? > > > I got it. B3D plugin Makefile asumes it will be building a bundle while Pharo does not use them. > I need to rewrite it as this: > > # The current version of B3DAcceleratorPlugin (the OpenGL interface) uses > # FindWindow, GetWindowGreatestAreaDevice & GetWindowPort which are Carbon & > # 32-bit only. So include the Carbon frameworks. Until this can be rewritten > # this implies no 64-bit OpenGL on Mac OS X :-(. > > INCDIRS:=../../platforms/Cross/plugins/FilePlugin \ > ../../platforms/unix/vm > INCDIRS:=../../platforms/unix/vm > > > ifeq ($(VM),Pharo) > EXTRALIBSFLAGS:=-undefined dynamic_lookup > else > # These three are imported from the VM. Use this explicit list instead of > # -undefined dynamic_lookup to get errors for any other missing imports. > EXTRABFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) > EXTRADYFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) > endif > EXTRALIBS:=$(EXTRALIBSFLAGS) -framework CoreFoundation -framework Carbon -framework OpenGL -framework AGL > > include ../common/Makefile.plugin > > (yes, we need the -undefined flag :( ) > > I will be submitting the fix tomorrow. > > Esteban > > > Best regards > -Tobias > > Esteban > > > Best regards > -Tobias > > > > On 3 May 2017, at 19:08, Tobias Pape <[hidden email]> wrote: > > > > On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: > > > Hi Tobias, > > first, apologies. > > > No need. > > > On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: > > > Dear all > > a small summary of some latest issues. > > 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. > Hence, I guarded the change[1] to Pharo only. > > 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. > This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. > However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. > This could have been done via > > $ git checkout -b eliot-B3D-fixes Cog > > and then committing and pushing to this branch > (commit would still be `git commit` or `scripts/gitci` for that matter, > push would be `git push origin eliot-B3D-fixes`) > > That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. > > > I promise not to do this again. I have to practice the branching to make it a habit. > > > Yeah, I can understand. I also still need to practice for that habit. I > > Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) > > > ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. > > > > Since I needed a working windows VM with the fixes for (1.), I have gone forward and > > 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? > > > The intent is to have one copy of the logging code in > > platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. > > > It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. > By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… > (That's why the verbosity-flag had not gl attached before, I presume) > It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. > Does that make sense? > > Best regards > -Tobias > > > > 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? > I added it hence[4]. > > Best regards > -Tobias > > > [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa > [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 > [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be > [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be > > > |
|
|
> On May 4, 2017, at 1:14 PM, "[hidden email]" <[hidden email]> wrote: > > > Oh, is this Balloon3D ? Yes. It has not worked for a long time and I'm trying my to get it to work again so that Terf can run on Spur. > > Phil > >> On Thu, May 4, 2017 at 9:08 PM, Esteban Lorenzano <[hidden email]> wrote: >> >> >> On 4 May 2017, at 16:48, Tobias Pape <[hidden email]> wrote: >> >> >> >> On 04.05.2017, at 16:37, Esteban Lorenzano <[hidden email]> wrote: >> >> >> >> On 4 May 2017, at 16:36, Tobias Pape <[hidden email]> wrote: >> >> >> >> On 04.05.2017, at 16:33, Esteban Lorenzano <[hidden email]> wrote: >> >> B3D plugin is still broken for me :( >> >> >> win32? >> Well, I just made it compile, to be frank. >> Maybe we should disable again for the time being? >> >> >> no, for macOS. >> I just pulled latest changes from osvm into pharo and… boom! >> >> Well… I haven't touched this… eliot? >> >> >> I got it. B3D plugin Makefile asumes it will be building a bundle while Pharo does not use them. >> I need to rewrite it as this: >> >> # The current version of B3DAcceleratorPlugin (the OpenGL interface) uses >> # FindWindow, GetWindowGreatestAreaDevice & GetWindowPort which are Carbon & >> # 32-bit only. So include the Carbon frameworks. Until this can be rewritten >> # this implies no 64-bit OpenGL on Mac OS X :-(. >> >> INCDIRS:=../../platforms/Cross/plugins/FilePlugin \ >> ../../platforms/unix/vm >> INCDIRS:=../../platforms/unix/vm >> >> >> ifeq ($(VM),Pharo) >> EXTRALIBSFLAGS:=-undefined dynamic_lookup >> else >> # These three are imported from the VM. Use this explicit list instead of >> # -undefined dynamic_lookup to get errors for any other missing imports. >> EXTRABFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) >> EXTRADYFLAGS=-Wl,-bundle_loader,$(VMDIR)/$(VM) >> endif >> EXTRALIBS:=$(EXTRALIBSFLAGS) -framework CoreFoundation -framework Carbon -framework OpenGL -framework AGL >> >> include ../common/Makefile.plugin >> >> (yes, we need the -undefined flag :( ) >> >> I will be submitting the fix tomorrow. >> >> Esteban >> >> >> Best regards >> -Tobias >> >> Esteban >> >> >> Best regards >> -Tobias >> >> >> >> On 3 May 2017, at 19:08, Tobias Pape <[hidden email]> wrote: >> >> >> >> On 03.05.2017, at 17:51, Eliot Miranda <[hidden email]> wrote: >> >> >> Hi Tobias, >> >> first, apologies. >> >> >> No need. >> >> >> On May 3, 2017, at 8:17 AM, Tobias Pape <[hidden email]> wrote: >> >> >> Dear all >> >> a small summary of some latest issues. >> >> 1. With the pulling of the Pharo sources (see PR #55), there was one unguarded change that messed up ctrl-... keystrokes for Squeak. Since the input event handling in Pharo is now completely different from Squeak's, this change probably makes sense for Pharo. >> Hence, I guarded the change[1] to Pharo only. >> >> 2. I put that into the repo. Meanwhile, Eliot has worked on B3D. >> This changes broke the build for windows. Yes, this was also mentioned in a commit comment[2]. >> However, since this work looks decidedly in-progress and not-windows-centered (which is totally fine), I would have recommended to put such work in a dedicated branch. >> This could have been done via >> >> $ git checkout -b eliot-B3D-fixes Cog >> >> and then committing and pushing to this branch >> (commit would still be `git commit` or `scripts/gitci` for that matter, >> push would be `git push origin eliot-B3D-fixes`) >> >> That way, all the changes and the (decidedly) broken parts would have been isolated to that branch. >> >> >> I promise not to do this again. I have to practice the branching to make it a habit. >> >> >> Yeah, I can understand. I also still need to practice for that habit. I >> >> Some times I fool myself into thinking that I can get away with a fee commits because I'm in the timezone I'm in. Must stop doing this ;-) >> >> >> ;) Well, Just see If I'm on Skype or so and ask away, sometimes it could just work. >> >> >> >> Since I needed a working windows VM with the fixes for (1.), I have gone forward and >> >> 3. I added back the logging stuff for B3D/DirectX[3]. Eliot, I hope this is matches your intentions? >> >> >> The intent is to have one copy of the logging code in >> >> platforms/Cross/plugins/B3DPluginAccelerator/sqOpenGLRenderer.c/.h, not several copies in every platform. Let's please make the win32 platform work like this too. >> >> >> It wont do. Because we have a separate Direct3D renderer that does not include the .h or link to the .c file. >> By default, the win32 build operates in dual-mode where the OpenGL/Direct3D-selection is made at runtime, but can also operate completely without OpenGL. In this case, none of that stuff would be there… >> (That's why the verbosity-flag had not gl attached before, I presume) >> It's now done in a way that tries to use the sqOpenGLRenderer debugging stuff if present, else provides its own. >> Does that make sense? >> >> Best regards >> -Tobias >> >> >> >> 4. Eliot's B3D Debugging code relies on getImageName which is defined in sq.h. Yet it seems to have always been missing on Win32? >> I added it hence[4]. >> >> Best regards >> -Tobias >> >> >> [1]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/d1f88876025e437eaeb480658cd72b2112dff7aa >> [2]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/c94ebce7b49e657839c0923ba52d801ba5101826 >> [3]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/e23c5aaae39540e7dc32e240f820f8cd433955be >> [4]: https://github.com/OpenSmalltalk/opensmalltalk-vm/commit/aa9503fd8c372b38c086d2daf7d3d2cf9e0453be >> >> >> |
|
|
In reply to this post by EstebanLM
Hi Esteban,
If you want to fix the Pharo build in the short term simply remove B3DAcceleratorPlugin from plugins.ext. I expect that the correct fix will be to change Makefile.plugin so that it respects the values set in the B3DAcceleratorPlugin/Makefile when building a Pharo-style dylib plugin.
|
«
Return to Squeak VM
|
1 view|%1 views
| Free forum by Nabble | Edit this page |