<div dir="ltr"><div>Ah yes, i could only compile in Release mode (-DNDEBUG).<br></div>The message is really unhelpfull, I&#39;d rather see how the macros are extended, but running the preprocessor phase is just boring in this IDE.<br></div><div class="gmail_extra"><br><div class="gmail_quote">2016-07-25 17:45 GMT+02:00  <span dir="ltr">&lt;<a href="mailto:commits@source.squeak.org" target="_blank">commits@source.squeak.org</a>&gt;</span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Tobias Pape uploaded a new version of VMMaker to project VM Maker:<br>
<a href="http://source.squeak.org/VMMaker/VMMaker.oscog-topa.1910.mcz" rel="noreferrer" target="_blank">http://source.squeak.org/VMMaker/VMMaker.oscog-topa.1910.mcz</a><br>
<br>
==================== Summary ====================<br>
<br>
Name: VMMaker.oscog-topa.1910<br>
Author: topa<br>
Time: 25 July 2016, 5:44:48.328562 pm<br>
UUID: d582738f-7126-49ca-9679-36e6995e6f2d<br>
Ancestors: VMMaker.oscog-topa.1909<br>
<br>
MSVC has a problem with the macro-expansion trickery involving asseert (vis ||), GIV and macro indirections. Using the getter (And the translated code from that) works fine, tho.<br>
<br>
=============== Diff against VMMaker.oscog-topa.1909 ===============<br>
<br>
Item was changed:<br>
  ----- Method: SpurGenerationScavenger&gt;&gt;newSpaceStart:newSpaceBytes:edenBytes: (in category &#39;initialization&#39;) -----<br>
  newSpaceStart: startAddress newSpaceBytes: totalBytes edenBytes: requestedEdenBytes<br>
        | actualEdenBytes survivorBytes |<br>
<br>
        actualEdenBytes := requestedEdenBytes.<br>
        survivorBytes := totalBytes - actualEdenBytes // 2 truncateTo: manager allocationUnit.<br>
        actualEdenBytes := totalBytes - survivorBytes - survivorBytes truncateTo: manager allocationUnit.<br>
        self assert: totalBytes - actualEdenBytes - survivorBytes - survivorBytes &lt; manager allocationUnit.<br>
<br>
        &quot;for tenuring we require older objects below younger objects.  since allocation<br>
         grows up this means that the survivor spaces must precede eden.&quot;<br>
<br>
        pastSpace start: startAddress; limit: startAddress + survivorBytes.<br>
        futureSpace start: pastSpace limit; limit: pastSpace limit + survivorBytes.<br>
        eden start: futureSpace limit; limit: futureSpace limit + actualEdenBytes.<br>
<br>
+       self assert: self futureSpace limit &lt;= (startAddress + totalBytes).<br>
+       self assert: self eden start \\ manager allocationUnit<br>
+                               + (self eden limit \\ manager allocationUnit) = 0.<br>
+       self assert: self pastSpace start \\ manager allocationUnit<br>
+                               + (self pastSpace limit \\ manager allocationUnit) = 0.<br>
+       self assert: self futureSpace start \\ manager allocationUnit<br>
+                               + (self futureSpace limit \\ manager allocationUnit) = 0.<br>
-       self assert: futureSpace limit &lt;= (startAddress + totalBytes).<br>
-       self assert: eden start \\ manager allocationUnit<br>
-                               + (eden limit \\ manager allocationUnit) = 0.<br>
-       self assert: pastSpace start \\ manager allocationUnit<br>
-                               + (pastSpace limit \\ manager allocationUnit) = 0.<br>
-       self assert: futureSpace start \\ manager allocationUnit<br>
-                               + (futureSpace limit \\ manager allocationUnit) = 0.<br>
<br>
        self initFutureSpaceStart.<br>
        manager initSpaceForAllocationCheck: (self addressOf: eden) limit: eden limit.<br>
<br>
        tenuringProportion := 0.9!<br>
<br>
</blockquote></div><br></div>