about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* Bump version to v0.1.4, document changes v0.1.4Andinus2021-02-193-28/+79
|
* Handle reading puzzle from file within Octans::CLI moduleAndinus2021-02-182-30/+30
| | | | This makes it easier to understand.
* Fix the regex for puzzleAndinus2021-02-071-6/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The older regex fails on [today's puzzle] & I didn't really understand what it did. The newer one is simpler & I understand how it works. [today's puzzle] https://mastodon.art/@Algot/105690195742318751 Thanks to guifa on #raku@freenode, they explained me how they would build regex for this problem. I'm pasting the logs here: |[...] |10:35 <guifa> Smallest element here is the letter. Lots of ways to | represent it, but I’d go with \S+ |10:35 <guifa> The next smallest is the group of letters |10:36 <guifa> Which is what you just got with spaces in between it |10:36 <guifa> so you get (\S+)+ % \h |10:36 <guifa> Next you want to grab individual lines with that | pattern in it so |10:37 <guifa> ( (\S+)+ % \h )+ \n |10:37 <guifa> And lastly, you want to start the pattern after a | double return |[...] |10:39 <guifa> \n \n ( (\S+)+ % \h )+ % \n |10:41 <guifa> The only problem here is that this technically does | match Hint. So to limit things more, you can either | be stricter about the inner bit (using \S \*? instead | of \S+), explicitly putting “Hint\n\n” in the regex | start, or requiring more than one inner match (\S+) | ** 2..* % \h |[...] |10:47 <guifa> But you might consider breaking things out into | tokens |[...] |10:54 <guifa> I think a lot of times people try to write regex left | to right, when they need to make it small to big |10:54 <guifa> That’s part of the reason you have the grammars in | Raku — it really pushes you to think of things that | way I asked guifa before including this, they were okay with it.
* Document the origin of neighbors subroutineAndinus2021-01-262-0/+6
|
* When computing neighbors, set it to an empty arrayAndinus2021-01-261-3/+6
| | | | | If we don't find any neighbors then we shouldn't have to recompute this result.
* Remove section numbers from README, document length optionAndinus2021-01-252-48/+55
|
* Bump version to v0.1.3, document changes v0.1.3Andinus2021-01-243-7/+17
|
* Add an option to specify minimum lengthAndinus2021-01-241-2/+3
|
* Bump version to v0.1.2 v0.1.2Andinus2021-01-201-1/+1
|
* Document new feature in READMEAndinus2021-01-202-4/+14
|
* Allow the input puzzle to be of any sizeAndinus2021-01-202-45/+34
| | | | | | | | | | | It should still be a 2d grid but can have any number of grids, not necessarily MxN. Even this is a valid input: a b c s d e r c This input should be valid even when parsing the url. It will certainly be valid when the input is a file.
* Fix dates in READMEAndinus2021-01-202-8/+8
| | | | I had entered 2020 everywhere out of habit, changed them all to 2021!
* Bump version to v0.1.1 v0.1.1Andinus2021-01-201-1/+1
|
* Add install instructions to READMEAndinus2021-01-202-7/+121
|
* Document new feature (reading puzzle from file), update READMEAndinus2021-01-202-7/+13
| | | | | | README was re-generated from README.org New feature was documented.
* Allow future versions of WWW module to be usedAndinus2021-01-201-1/+1
|
* Read from file if passed, modify USAGEAndinus2021-01-203-53/+86
| | | | | | Previouly, the only way of passing the puzzle was to enter a url. Now octans is able to read from files too. If the file exist & it's readable then octans will read the puzzle from there.
* Add latest demo linkAndinus2021-01-201-2/+5
| | | | | Octans found 10 solutions to this puzzle: https://mastodon.art/@Algot/105413312119416356
* Add v0.1.0 demo linksAndinus2021-01-201-2/+3
|
* Re-structure for CPAN upload, include a dictionary file v0.1.0Andinus2021-01-1910-82/+355273
| | | | bin/octans calls lib/Octans/CLI.rakumod which has the MAIN subroutine.
* Re-implement octans, move subroutines to respective modulesAndinus2021-01-198-218/+410
| | | | | | | | | | | | | | | Initially it went over the list of words & checked if they exist in the grid. This was very slow. Currently it walks the grid & checks if the current string exist in the dictionary. This is faster for these reasons: • The dictionary is sorted, we perform binary range search on the dictionary to return the list of all words that start with specific string. • Starting positions are limited. If the dictionary wasn't sorted then this probably would've been
* Document the implementationAndinus2021-01-141-1/+71
|
* Add links to website, source, githubAndinus2021-01-141-0/+4
|
* Add demo linksAndinus2021-01-141-4/+14
|
* Initial commitAndinus2021-01-143-0/+197