On 09 Jan 2014, at 21:48, Nicolai Hess <nicolaihess@web.de> wrote:
How are merge conflicts handled?
Someone (the author or someone else), needs to load the SLICE, fix the conflict and then save a new version.
If you look at issue 7542 there is a merge conflict with the current version and SLICE-Issue-7542-NB-system-example-IgorStasenko.2 The current version usess Smalltalk compiler new ... and igors version uses Smalltalk compiler ...
Smalltalk compiler new doesn't work, as Smalltalk compiler is alread an instance of OpalCompiler
Yes, it is "Smalltalk compilerâ. In the past there was just #compilerClass. I added #compiler because this allows us to very easily parametrize this object. For that of course I changed all the old users of #compilerClass to use #compiler instead, and added the API that was on the class side of Compiler to the instance side, too. (most calls of #compilerClass already called #new, thought). This now is quite nice, I think. e.g. on the class side of instruction stream, we now have compiler "The JIT compiler needs to trap all reads to instance variables of contexts. As this check is costly, it is only done in the long form of the bytecodes, which are not used often. In this hierarchy we force the compiler to alwasy generate long bytecodes" ^super compiler options: #(+ optionLongIvarAccessBytecodes) making it explicit that the whole hierarchy is compiled differently. Marcus