Hi,

I think doNotGenerate goes beyond simulation. It can be used in debugging only code, or in code used to generate other code.  It's just a detail though.

On Thu, Nov 1, 2018 at 2:17 PM Ben Coman <btc@openinworld.com> wrote:
 
On Thu, 1 Nov 2018 at 01:34, <commits@source.squeak.org> wrote:
 
Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2480.mcz

==================== Summary ====================

Name: VMMaker.oscog-eem.2480
Author: eem
Time: 31 October 2018, 10:33:03.858395 am
UUID: bb3ffda7-8241-4dea-b886-d656e474b6c1
Ancestors: VMMaker.oscog-eem.2479

Simulator:
Provide simulation stubs for the B3DAcceleratorPlugin C api.

Item was added:
+ ----- Method: B3DAcceleratorPlugin>>b3dDrawArrays:_:_:_: (in category 'simulation') -----
+ b3dDrawArrays: handle _: mode _: minIdx _: maxIdx
+       "int b3dDrawArrays(int handle, int mode, int minIdx, int maxIdx)"
+       <doNotGenerate>
+       ^false!

Not actually a request to change anything since <doNotGenerate> is a well established convention,  but just sharing a thought that occurs to me because I like to understand conventions rather than take them for granted.

For someone naively looking through the code for the first time, 
<doNotGenerate> indicates what it "doesn't" but not what it "does"
and <simulation> might be more intuitive for newcomers to understand.

Its a question of which is better to be explicit and which implicit. Two sides of the same coin...
<doNotGenerate> - explicit about code generation, implicit about simulation
<simulation> - explicit about simulation, implicit about code generation.

anyway...
cheers -ben


--
Clément Béra
https://clementbera.github.io/