Eliot Miranda uploaded a new version of VMMaker to project VM Maker: http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.108.mcz ==================== Summary ==================== Name: VMMaker.oscog-eem.108 Author: eem Time: 21 July 2011, 1:45:28 am UUID: 06af30e4-7c67-4259-88dc-8ee2a10499c4 Ancestors: VMMaker.oscog-eem.107 Nuke ReentrantFFIPlugin in favour of ThreadedFFIPlugin, using cppIf: COGMTVM to select threading-specific code. This so that there only needs to be one SqueakFFIPrims.c for the reentrant (non-threaded) and threaded FFI plugins. This is a much easier fix than somehow allowing the two files to exist side-by-side in the file system. |
On 22 July 2011 02:04, <[hidden email]> wrote: > > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: > http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.108.mcz > > ==================== Summary ==================== > > Name: VMMaker.oscog-eem.108 > Author: eem > Time: 21 July 2011, 1:45:28 am > UUID: 06af30e4-7c67-4259-88dc-8ee2a10499c4 > Ancestors: VMMaker.oscog-eem.107 > > Nuke ReentrantFFIPlugin in favour of ThreadedFFIPlugin, using > cppIf: COGMTVM to select threading-specific code. This so that > there only needs to be one SqueakFFIPrims.c for the reentrant > (non-threaded) and threaded FFI plugins. This is a much easier > fix than somehow allowing the two files to exist side-by-side in > the file system. > > :) in cmake configs we dealt with this by simply including proper plugin class. But indeed there's a lot of XyZFFIPlugins out there.. -- Best regards, Igor Stasenko AKA sig. |
On Thu, Jul 21, 2011 at 3:29 PM, Igor Stasenko <[hidden email]> wrote:
You may have missed the point. Both of these plugins emit a source file called src/vm/plugins/SqueakFFIPrims/SqueakFFIPrims.c sicne they are both different versions of the FFI plugin, one for a non-threaded VM, one for a threaded VM. If I were to generate both of them at the same time one would overwrite the other. If I were to change the name of one of them then all the builds would be affected and have to be modified to choose a different source depending on whether COGMTVM=1 or COGMTVM=0. [Note it was difficult enough to get the builds to choose either cointerp.c cointerpmt.c gcc3x-cointerp.c or gcc3x-cointerpmt.c]. So the easiest way to be able to select these different variants is to collapse them into one class and use cppIf: to choose between non-threaded and threaded code based on COGMTVM.
HTH -- -- best, Eliot |
On 22 July 2011 01:33, Eliot Miranda <[hidden email]> wrote: > > > > On Thu, Jul 21, 2011 at 3:29 PM, Igor Stasenko <[hidden email]> wrote: >> >> On 22 July 2011 02:04, <[hidden email]> wrote: >> > >> > Eliot Miranda uploaded a new version of VMMaker to project VM Maker: >> > http://www.squeaksource.com/VMMaker/VMMaker.oscog-eem.108.mcz >> > >> > ==================== Summary ==================== >> > >> > Name: VMMaker.oscog-eem.108 >> > Author: eem >> > Time: 21 July 2011, 1:45:28 am >> > UUID: 06af30e4-7c67-4259-88dc-8ee2a10499c4 >> > Ancestors: VMMaker.oscog-eem.107 >> > >> > Nuke ReentrantFFIPlugin in favour of ThreadedFFIPlugin, using >> > cppIf: COGMTVM to select threading-specific code. This so that >> > there only needs to be one SqueakFFIPrims.c for the reentrant >> > (non-threaded) and threaded FFI plugins. This is a much easier >> > fix than somehow allowing the two files to exist side-by-side in >> > the file system. >> > >> > >> >> :) >> in cmake configs we dealt with this by simply including proper plugin class. >> But indeed there's a lot of XyZFFIPlugins out there.. > > You may have missed the point. Both of these plugins emit a source file called src/vm/plugins/SqueakFFIPrims/SqueakFFIPrims.c sicne they are both different versions of the FFI plugin, one for a non-threaded VM, one for a threaded VM. If I were to generate both of them at the same time one would overwrite the other. Exactly. That's why i making sure to include only right plugin :) > If I were to change the name of one of them then all the builds would be affected and have to be modified to choose a different source depending on whether COGMTVM=1 or COGMTVM=0. [Note it was difficult enough to get the builds to choose either cointerp.c cointerpmt.c gcc3x-cointerp.c or gcc3x-cointerpmt.c]. So the easiest way to be able to select these different variants is to collapse them into one class and use cppIf: to choose between non-threaded and threaded code based on COGMTVM. I know. But its a pity that nice and elegant inheritance scheme has to be broken to serve pervasive needs of C :) > HTH >> >> -- >> Best regards, >> Igor Stasenko AKA sig. > > > > -- > best, > Eliot > > -- Best regards, Igor Stasenko AKA sig. |
On Thu, Jul 21, 2011 at 3:43 PM, Igor Stasenko <[hidden email]> wrote:
except that inheritance only gives you one axis of change. For example I have inheritance giving me the axis from less sophisticated to more sophisticated code generator in Cogit SimpleStackBasedCogit StackToRegisterMappingCogit Sista StackToRegisterMappingCogit. But in adding Newspeak I needed another axis. Mixins and/or traits would have worked, but I'm not ready to trust the traits system, and we don't have mixins. For that reason and the file collision issue I used cppIf: :(
-- best, Eliot |
Free forum by Nabble | Edit this page |