From c391d94da91b67b19b78caa045491cd0b511c7e3 Mon Sep 17 00:00:00 2001 From: John Bampton Date: Tue, 26 Apr 2022 13:48:05 +1000 Subject: [PATCH] docs: fix grammar and spelling --- doc/guides/gc-arena-howto.md | 8 ++++---- doc/guides/mrbgems.md | 2 +- doc/mruby3.0.md | 4 ++-- doc/mruby3.1.md | 2 +- 4 files changed, 8 insertions(+), 8 deletions(-) diff --git a/doc/guides/gc-arena-howto.md b/doc/guides/gc-arena-howto.md index 2c1cdc1fb..1fff624df 100644 --- a/doc/guides/gc-arena-howto.md +++ b/doc/guides/gc-arena-howto.md @@ -14,7 +14,7 @@ GC (garbage collector) must ensure that object is "alive", in other words, that it is referenced by somewhere from the program. This can be determined by checking if the object can be directly or indirectly referenced by root. The local variables, global variables and -constants etc are root. +constants etc. are root. If program execution is performed inside mruby VM, there is nothing to worry about because GC can access all roots owned by the VM. @@ -29,7 +29,7 @@ This can be a fatal bug if the GC tries to collect a live object. In CRuby, we scan C stack area, and use C variable as root to check whether object is alive or not. Of course, because we are accessing C stack just as memory region, we never know it is an integer or a -pointer. We workaround this by assuming that if it looks like a +pointer. We work around this by assuming that if it looks like a pointer, then assume it as a pointer. We call it "conservative". By the way, CRuby's "conservative GC" has some problems. @@ -65,14 +65,14 @@ objects (See `MRB_GC_FIXED_ARENA` and `MRB_GC_ARENA_SIZE` in doc/guides/mrbconf.md). If you create many objects in C functions, memory usage will increase, since -GC never kick in. This memory usage may look like memory leak, but will also +GC never kicks in. This memory usage may look like memory leaks, but will also make execution slower as more memory will need to be allocated. With the build time configuration, you can limit the maximum size of arena (e.g., 100). Then if you create many objects, arena overflows, thus you will get an "arena overflow error". -To workaround these problems, we have `mrb_gc_arena_save()` and +To work around these problems, we have `mrb_gc_arena_save()` and `mrb_gc_arena_restore()` functions. `int mrb_gc_arena_save(mrb)` returns the current position of the stack diff --git a/doc/guides/mrbgems.md b/doc/guides/mrbgems.md index 68d0560c2..9cd28c5fa 100644 --- a/doc/guides/mrbgems.md +++ b/doc/guides/mrbgems.md @@ -111,7 +111,7 @@ conf.gembox 'custom' This will cause the `custom` GemBox to be read in during the build process, adding `mruby-time` and `mrbgems-example` to the build. -If you want, you can put GemBox outside of mruby directory. In that case you must +If you want, you can put GemBox outside the mruby directory. In that case you must specify an absolute path like below. ```ruby diff --git a/doc/mruby3.0.md b/doc/mruby3.0.md index 09d2c4af9..359d82c7b 100644 --- a/doc/mruby3.0.md +++ b/doc/mruby3.0.md @@ -75,7 +75,7 @@ to be default `mrb_value` representation. Now the default is ## `MRB_WORD_BOXING` Pack `mrb_value` in an `intptr_t` integer. Consumes less -memory compared to `MRB_NO_BOXING` especially on 32 bit +memory compared to `MRB_NO_BOXING` especially on 32-bit platforms. `Fixnum` size is 31 bits so some integer values does not fit in `Fixnum` integers. @@ -116,7 +116,7 @@ Instructions that access pool[i]/syms[i] where i>255. * `OP_STRING16` * `OP_LOADSYM16` -Instructions that load a 32 bit integer. +Instructions that load a 32-bit integer. * `OP_LOADI32` diff --git a/doc/mruby3.1.md b/doc/mruby3.1.md index 5588ae24d..c99bdc542 100644 --- a/doc/mruby3.1.md +++ b/doc/mruby3.1.md @@ -119,7 +119,7 @@ If the size of `mrb_float` and `mrb_int` are same, the last 2 bits in the `mrb_f Previous NaN boxing packs values in NaN representation, but pointer retrievals are far more frequent than floating point number references. So we add constant offset to NaN representation to clear higher bits of pointer representation. This representation is called "Favor Pointer" NaN Boxing. -Also, previous NaN boxing limit the size of `mrb_int` to 4 bytes (32 bits) to fit in NaN values. Now we allocates integer values in the heap, if the value does not fit in the 32 bit range, just like we did in Word Boxing. +Also, previous NaN boxing limit the size of `mrb_int` to 4 bytes (32 bits) to fit in NaN values. Now we allocate integer values in the heap, if the value does not fit in the 32 bit range, just like we did in Word Boxing. ## Constant Folding