[Vm-dev] Recent changes.
Eliot Miranda
eliot.miranda at gmail.com
Fri May 5 00:44:54 UTC 2017
Hi Esteban,
> On May 4, 2017, at 12:08 PM, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>
>
>>> On 4 May 2017, at 16:48, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>
>>>
>>>
>>> On 04.05.2017, at 16:37, Esteban Lorenzano <estebanlm at gmail.com> wrote:
>>>
>>>
>>>
>>>> On 4 May 2017, at 16:36, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>>
>>>>
>>>>
>>>>> On 04.05.2017, at 16:33, Esteban Lorenzano <estebanlm at gmail.com> 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.
Let's talk this over. Please don't change this. I'm working on getting the Squeak bundle to work. I now have it compiling and loading and a bit more (runs without error only in gdb's because at full speed it trips over itself; but there is still no visible output).
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.
>
> Esteban
>
>>
>> Best regards
>> -Tobias
>>
>>> Esteban
>>>
>>>>
>>>> Best regards
>>>> -Tobias
>>>>
>>>>>
>>>>>
>>>>>> On 3 May 2017, at 19:08, Tobias Pape <Das.Linux at gmx.de> wrote:
>>>>>>
>>>>>>
>>>>>>
>>>>>>> On 03.05.2017, at 17:51, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>>>>>>>
>>>>>>>
>>>>>>> Hi Tobias,
>>>>>>>
>>>>>>> first, apologies.
>>>>>>>
>>>>>>
>>>>>> No need.
>>>>>>
>>>>>>>
>>>>>>>> On May 3, 2017, at 8:17 AM, Tobias Pape <Das.Linux at gmx.de> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20170504/8b6abc6a/attachment-0001.html>
More information about the Vm-dev
mailing list