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