diff --git a/exercises/practice/bottle-song/.meta/config.json b/exercises/practice/bottle-song/.meta/config.json index 9b5bf69b0..d153fa587 100644 --- a/exercises/practice/bottle-song/.meta/config.json +++ b/exercises/practice/bottle-song/.meta/config.json @@ -11,6 +11,9 @@ ], "example": [ ".meta/src/reference/java/BottleSong.java" + ], + "invalidator": [ + "build.gradle" ] }, "blurb": "Produce the lyrics to the popular children's repetitive song: Ten Green Bottles.", diff --git a/exercises/practice/high-scores/.meta/config.json b/exercises/practice/high-scores/.meta/config.json index 57278fb53..a17e42823 100644 --- a/exercises/practice/high-scores/.meta/config.json +++ b/exercises/practice/high-scores/.meta/config.json @@ -9,6 +9,9 @@ ], "example": [ ".meta/src/reference/java/HighScores.java" + ], + "invalidator": [ + "build.gradle" ] }, "blurb": "Manage a player's High Score list.", diff --git a/exercises/practice/meetup/.docs/instructions.md b/exercises/practice/meetup/.docs/instructions.md index fe1a9c2a6..0694ef583 100644 --- a/exercises/practice/meetup/.docs/instructions.md +++ b/exercises/practice/meetup/.docs/instructions.md @@ -1,27 +1,51 @@ # Instructions -Calculate the date of meetups. +Recurring monthly meetups are generally scheduled on the given weekday of a given week each month. +In this exercise you will be given the recurring schedule, along with a month and year, and then asked to find the exact date of the meetup. -Typically meetups happen on the same day of the week. In this exercise, you -will take a description of a meetup date, and return the actual meetup date. +For example a meetup might be scheduled on the _first Monday_ of every month. +You might then be asked to find the date that this meetup will happen in January 2018. +In other words, you need to determine the date of the first Monday of January 2018. -Examples of general descriptions are: +Similarly, you might be asked to find: -- The first Monday of January 2017 -- The third Tuesday of January 2017 -- The wednesteenth of January 2017 -- The last Thursday of January 2017 +- the third Tuesday of August 2019 (August 20, 2019) +- the teenth Wednesday of May 2020 (May 13, 2020) +- the fourth Sunday of July 2021 (July 25, 2021) +- the last Thursday of November 2022 (November 24, 2022) -The descriptors you are expected to parse are: -first, second, third, fourth, fifth, last, monteenth, tuesteenth, wednesteenth, -thursteenth, friteenth, saturteenth, sunteenth +The descriptors you are expected to process are: `first`, `second`, `third`, `fourth`, `last`, `teenth`. -Note that "monteenth", "tuesteenth", etc are all made up words. There was a -meetup whose members realized that there are exactly 7 numbered days in a month -that end in '-teenth'. Therefore, one is guaranteed that each day of the week -(Monday, Tuesday, ...) will have exactly one date that is named with '-teenth' -in every month. +Note that descriptor `teenth` is a made-up word. -Given examples of a meetup dates, each containing a month, day, year, and -descriptor calculate the date of the actual meetup. For example, if given -"The first Monday of January 2017", the correct meetup date is 2017/1/2. +It refers to the seven numbers that end in '-teen' in English: 13, 14, 15, 16, 17, 18, and 19. +But general descriptions of dates use ordinal numbers, e.g. the _first_ Monday, the _third_ Tuesday. + +For the numbers ending in '-teen', that becomes: + +- 13th (thirteenth) +- 14th (fourteenth) +- 15th (fifteenth) +- 16th (sixteenth) +- 17th (seventeenth) +- 18th (eighteenth) +- 19th (nineteenth) + +So there are seven numbers ending in '-teen'. +And there are also seven weekdays (Monday, Tuesday, Wednesday, Thursday, Friday, Saturday, Sunday). +Therefore, it is guaranteed that each day of the week (Monday, Tuesday, ...) will have exactly one numbered day ending with "teen" each month. + +If asked to find the teenth Saturday of August, 1953 (or, alternately the "Saturteenth" of August, 1953), we need to look at the calendar for August 1953: + +```plaintext + August 1953 +Su Mo Tu We Th Fr Sa + 1 + 2 3 4 5 6 7 8 + 9 10 11 12 13 14 15 +16 17 18 19 20 21 22 +23 24 25 26 27 28 29 +30 31 +``` + +The Saturday that has a number ending in '-teen' is August 15, 1953. diff --git a/exercises/practice/phone-number/.docs/instructions.md b/exercises/practice/phone-number/.docs/instructions.md index 6b86bbac9..62ba48e96 100644 --- a/exercises/practice/phone-number/.docs/instructions.md +++ b/exercises/practice/phone-number/.docs/instructions.md @@ -11,12 +11,14 @@ The first three digits of the local number represent the _exchange code_, follow The format is usually represented as ```text -(NXX)-NXX-XXXX +NXX NXX-XXXX ``` where `N` is any digit from 2 through 9 and `X` is any digit from 0 through 9. -Your task is to clean up differently formatted telephone numbers by removing punctuation and the country code (1) if present. +Sometimes they also have the country code (represented as `1` or `+1`) prefixed. + +Your task is to clean up differently formatted telephone numbers by removing punctuation and the country code if present. For example, the inputs diff --git a/exercises/practice/sgf-parsing/.docs/instructions.md b/exercises/practice/sgf-parsing/.docs/instructions.md index cffc012fd..edc8d6b18 100644 --- a/exercises/practice/sgf-parsing/.docs/instructions.md +++ b/exercises/practice/sgf-parsing/.docs/instructions.md @@ -2,12 +2,14 @@ Parsing a Smart Game Format string. -[SGF](https://en.wikipedia.org/wiki/Smart_Game_Format) is a standard format for -storing board game files, in particular go. +[SGF][sgf] is a standard format for storing board game files, in particular go. -SGF is a fairly simple format. -An SGF file usually contains a single tree of nodes where each node is a property list. -The property list contains key value pairs, each key can only occur once but may have multiple values. +SGF is a fairly simple format. An SGF file usually contains a single +tree of nodes where each node is a property list. The property list +contains key value pairs, each key can only occur once but may have +multiple values. + +The exercise will have you parse an SGF string and return a tree structure of properties. An SGF file may look like this: @@ -17,24 +19,32 @@ An SGF file may look like this: This is a tree with three nodes: -- The top level node has three properties: FF\[4\] (key = "FF", value = "4"), C\[root\](key = "C", value = "root") and SZ\[19\] (key = "SZ", value = "19"). - (FF indicates the version of SGF, C is a comment and SZ is the size of the board.) - - The top level node has a single child which has a single property: B\[aa\]. - (Black plays on the point encoded as "aa", which is the 1-1 point). - - The B\[aa\] node has a single child which has a single property: W\[ab\]. +- The top level node has three properties: FF\[4\] (key = "FF", value + = "4"), C\[root\](key = "C", value = "root") and SZ\[19\] (key = + "SZ", value = "19"). (FF indicates the version of SGF, C is a + comment and SZ is the size of the board.) + - The top level node has a single child which has a single property: + B\[aa\]. (Black plays on the point encoded as "aa", which is the + 1-1 point). + - The B\[aa\] node has a single child which has a single property: + W\[ab\]. -As you can imagine an SGF file contains a lot of nodes with a single child, which is why there's a shorthand for it. +As you can imagine an SGF file contains a lot of nodes with a single +child, which is why there's a shorthand for it. -SGF can encode variations of play. Go players do a lot of backtracking in their reviews (let's try this, doesn't work, let's try that) and SGF supports variations of play sequences. -For example: +SGF can encode variations of play. Go players do a lot of backtracking +in their reviews (let's try this, doesn't work, let's try that) and SGF +supports variations of play sequences. For example: ```text (;FF[4](;B[aa];W[ab])(;B[dd];W[ee])) ``` -Here the root node has two variations. -The first (which by convention indicates what's actually played) is where black plays on 1-1. -Black was sent this file by his teacher who pointed out a more sensible play in the second child of the root node: `B[dd]` (4-4 point, a very standard opening to take the corner). +Here the root node has two variations. The first (which by convention +indicates what's actually played) is where black plays on 1-1. Black was +sent this file by his teacher who pointed out a more sensible play in +the second child of the root node: `B[dd]` (4-4 point, a very standard +opening to take the corner). A key can have multiple values associated with it. For example: @@ -44,9 +54,30 @@ A key can have multiple values associated with it. For example: Here `AB` (add black) is used to add three black stones to the board. -There are a few more complexities to SGF (and parsing in general), which you can mostly ignore. -You should assume that the input is encoded in UTF-8, the tests won't contain a charset property, so don't worry about that. -Furthermore you may assume that all newlines are unix style (`\n`, no `\r` or `\r\n` will be in the tests) and that no optional whitespace between properties, nodes, etc will be in the tests. +All property values will be the [SGF Text type][sgf-text]. +You don't need to implement any other value type. +Although you can read the [full documentation of the Text type][sgf-text], a summary of the important points is below: + +- Newlines are removed if they come immediately after a `\`, otherwise they remain as newlines. +- All whitespace characters other than newline are converted to spaces. +- `\` is the escape character. + Any non-whitespace character after `\` is inserted as-is. + Any whitespace character after `\` follows the above rules. + Note that SGF does **not** have escape sequences for whitespace characters such as `\t` or `\n`. + +Be careful not to get confused between: + +- The string as it is represented in a string literal in the tests +- The string that is passed to the SGF parser + +Escape sequences in the string literals may have already been processed by the programming language's parser before they are passed to the SGF parser. + +There are a few more complexities to SGF (and parsing in general), which +you can mostly ignore. You should assume that the input is encoded in +UTF-8, the tests won't contain a charset property, so don't worry about +that. Furthermore you may assume that all newlines are unix style (`\n`, +no `\r` or `\r\n` will be in the tests) and that no optional whitespace +between properties, nodes, etc will be in the tests. -The exercise will have you parse an SGF string and return a tree structure of properties. -You do not need to encode knowledge about the data types of properties, just use the rules for the [text](http://www.red-bean.com/sgf/sgf4.html#text) type everywhere. +[sgf]: https://en.wikipedia.org/wiki/Smart_Game_Format +[sgf-text]: https://www.red-bean.com/sgf/sgf4.html#text