about summary refs log tree commit diff stats
Commit message (Collapse)AuthorAgeFilesLines
* Don't print time takenAndinus2021-03-031-11/+2
| | | | | | | | It was misleading because the time printed was not the time taken to find that specific word, it was the time taken to find all the words upto that word. It would reset for each starting position. It's better to just remove the whole thing.
* Change subroutine declaration styleAndinus2021-03-035-13/+7
| | | | | | | | From: sub t () {} To: sub t() {}
* Make class Puzzle, remove fancy chars, make module for get-puzzleAndinus2021-03-034-89/+70
| | | | | | - Puzzle is a class that provides the grids & gray-squares. - Fancy chars were removed for ASCII characters. - get-puzzle is now in its own module.
* Re-structure codeAndinus2021-03-022-18/+21
| | | | These changes should make it easier to read the code.
* Print default USAGE, remove shorthand for verbose optionAndinus2021-03-021-24/+10
| | | | The input file format can be explained in the documentation.
* Add .gitattributesAndinus2021-02-281-0/+2
| | | | | GitHub now recognises .rakumod so this is not necessary but I'll add it anyways.
* Print complete helpAndinus2021-02-281-1/+1
| | | | | Previously it wouldn't print the input file format but would only print the default $*USAGE.
* Remove sample puzzleAndinus2021-02-281-36/+19
|
* Fix the sample puzzle errorAndinus2021-02-191-4/+6
| | | | | | | | | | It would error out when the user runs sample puzzle because we're using $path.IO.f but that wasn't passed. It prints this error: Invocant of method 'f' must be an object instance of type 'IO::Path', not a type object of type 'IO::Path'.
* Structural changes in READMEAndinus2021-02-192-23/+6
|
* 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