Tests will never try to free an unallocated pointer (at least in Python).

Test cases don't cover case when after releasing memory we have two adjacent blocks. All three blocks have to be merged to one block, and then test should check it. Something like this:

const mem = new MemoryManager(new Array(80));
const pointer1 = mem.allocate(16);
const pointer2 = mem.allocate(16);
const pointer3 = mem.allocate(16);
const pointer4 = mem.allocate(16);
const pointer5 = mem.allocate(16);

mem.release(pointer2); // release left block
mem.release(pointer4); // release right block
mem.release(pointer3); // release center block

mem.allocate(48); // try allocate size = 3 * 16

My code doesn't cover this case but still passed all tests!

Loved the Kata, interpereters are always fun, but I was able to brute force the random tests with a bit of good RNG.

Now I gotta find something else to do......

I'm getting this error:

Cannot read properties of undefined (reading 'replace')

My code does pass the example tests fine; the issue is on the random tests. That said, I don't have a .replace in my code, so I'm not sure if this is my mistake or not. If it is, then the error message should be improved.

Please review: TypeScript Translation

This kata is a subject to deduplication process here: https://github.com/codewars/content-issues/issues/200.
Please join the discussion to help us identify duplicate kata and retire them.

tests like:

create_mem(64)
allocate(16)
allocate(16)
allocate(16)
allocate(16)

assume that we allocated the first block at index 0, the next at index 16, then 32 and 48. This is not necessarily how real memory allocation systems work, as there are many different algorithms.

This means that there is one implicit allocation scheme that has to be followed, unless one is to write much more complex code to handle memory (de)-fragmentation or non-contiguous blocks.

I feel like the description should clarify this, either by specifying the required scheme, or by stating that we have to optimize memory layout.

(This does not clash with the requirement that there be no memory overhead : lack of overhead can be tested by allocating and freeing blocks of size 1 and checking that all of the memory is available).

The EBNF grammar definition in the kata is a little off. query includes join as [ ws, join ], but it's also included in the definition of from: [ { ws, join } ]. Seeing as the examples include a query with multiple joins, I believe the inclusion in query's definition is in error and should be removed.

It would benefit the kata if it was testing for malformed inputs too, getting the whitespace 100% correct with optional JOINs and WHERE in Parsec was surprisingly tricky (or maybe I was just tired).

no sample tests... (JS at least)

There are no random tests.

Haskell random test queries are way more liberal on whitespace than the grammar (whitespace at beggining/end of query, arbitrary whitespace instead of a single space after "SELECT", "FROM" etc.).

I would consider these bugs in the description rather than the test cases.

runTestCase can be overwritten, so...

createInstructions is not defined in the sample tests.

Input object is vulnerable to input modification. Emptying them passes the tests.