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
7542there 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