Loading collection data...
Collections are a way for you to organize kata so that you can create your own training routines. Every collection you create is public and automatically sharable with other warriors. After you have added a few kata to a collection you and others can train on the kata contained within the collection.
Get started now by creating a new collection.
Python new test frameworks are required.
Missing mutable test cases for
takeWhile
.This comment is hidden because it contains spoiler information about the solution
The kata's description is horrendously lazy. And it leaves a lot of specs out of the table, even in the context of the linked Wikipedia article:
[A-Z# ]
, but this is really because the tests are too lazy.There are no tests that validate
stop
is handled correctly. Every test can be passed by processing every character except the last (and ignoringstop
altogether).Nice kata! There is a typo in the sample tests, at the
group by
section:query().select().from(persons).groupBy(profession, name).execute() [i.e., SELECT * FROM persons WHERE profession = "teacher" GROUPBY profession, name]
. There should be no 'WHERE' I asume.Python translation
Implemented random tests to match o2001's implementation as much as possible.
These edge cases should also be tested since they are present in example tests:
[1..9,12..15] -- invalid since one single range is allowed
[1,2..20,25] -- invalid since a range has to be the final item
[1,2,3..20] -- invalid since at most one inidivual element can be provided before a range
These edge cases should also be tested since they are present in example tests:
[1..9,12..15] -- invalid since one single range is allowed
[1,2..20,25] -- invalid since a range has to be the final item
[1,2,3..20] -- invalid since at most one inidivual element can be provided before a range
It seems a bit odd to me that
vowelSet.includes(A)
is required to throw an error when such problems are decidable (determining if a finite set is a subset of any other set). Should it really be required that the implementation fails when it doesn't have to?I'm failing exclusively on four "anti cheating memoization test"s (without cheating or using memoization), so either that test is misconfigured, or my solution is bad and some other "normal" tests (not related to cheating) are missing.
First off, thanks for putting this together, it's been a fun challenge. However, I seem to be running into an issue with my attempt. The first attempt, I passed all tests but the performance test. My second attempt, after some minor code cleanup, is now failing all of the "anti cheating" "edge case" tests, but I haven't functionally changed anything.
Any idea what the issue could be? I put a good amount of effort into my solution, so it's a bit frustrating to fail in a way that I cannot identify.
The JavaScript in the description and initial code is quite ancient.
Decorator
should be aclass
, and spread parameters should be used instead of usingFunction.prototype.call()
on thearguments
object.The
if outer observable never completes, then concatMap either
andif inner observable never completes, then concatMap either
tests are completely undecipherable.Please actually explain what are the expected behaviours of the 3 operators required to be implemented.
Starting from this part the kata stops resembling any kind of observable pattern. Observable pattern is push-based, not pull-based: downstream do not, and cannot control whether upstream starts pushing values; similarly, upstream do not have the concept of "knowing whether downstream want a values". That'd be a pull-based design like
Promise
.of
andinterval
does not make any sense in a push-based system. It would be acceptable if the tests are using it responsibly, but then there are increasingly more gratuitous misuse of this in later parts (#4, then #5) which requires pull-based behaviour in a supposedly push-based system, requiring completely insane programming.Loading more items...