Hi Christoph, Hmm, there must have been some confusion on my side. I've tried to carefully review the remaining contributions in the inbox. To my understanding Kernel-ct.1383 fixes more simulation cases than Kernel-ct.1382. Since - the tests simulating primitives 83, 84 & 100 were failing, - and that a more recent inbox contribution was trying to fix that, I thought that merging this contribution was a good idea. It apparently was fixing two tests out of three after trial.
Also, to my experience, generating a warning when we simulate primitiveIndex >= 85 and: [primitiveIndex <= 88] "control primitives"]) is super annoying! It always happens when running some kernel tests and forces me to switch warning off altogether. But switching warning off is not a good solution (and it makes some more tests fail !). Kernel-ct.1383 being more recent, I thought that the removal of warnings was intentional...
I saw later that you removed <primitive: 19> from newProcess... SHould we?
My understanding now is that you need this warning in some specific context. Is that it? We can't fix one usage by breaking another. We have to find a solution that fits both purposes.
Le ven. 16 avr. 2021 à 15:40, Marcel Taeumel marcel.taeumel@hpi.de a écrit :
Hi Christoph,
the commit message in Kernel-nice.1386 reads: "[...] Note that Kernel-ct.1383 supersedes Kernel-ct.1382 and removes the annoying warning. [...]"
I think the problem was that both ct.1382 and ct.1382 change the same method but do not actually consider each other. With our current tools, sub-method merging is rather tricky and hence the author should take care that this does not happen. :-)
Please review the current state of Context >> #doPrimitive:method:receiver:args: and upload the missing lines again into the inbox if necessary.
Best, Marcel
Am 16.04.2021 15:16:18 schrieb Christoph Thiede christoph.thiede@student.hpi.uni-potsdam.de:
PS: I also see that you touched the simulation of criticalSection primitives (primitiveIndex = 186 ...) again. Again, was this intended or an incident? :-)
(OT: We are really treading on each other's toes in this method ... What can we learn from this? Is it too large and should be split up? Or should we improve our tooling support for resolving merge conflicts?)
Best, Christoph
Carpe Squeak!
Sent from: http://forum.world.st/Squeak-Dev-f45488.html