| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
| |
Previously it wouldn't print the input file format but would only
print the default $*USAGE.
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
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'.
|
| | |
|
| | |
|
| |
|
|
| |
This makes it easier to understand.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| | |
|
| |
|
|
|
| |
If we don't find any neighbors then we shouldn't have to recompute
this result.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
| |
I had entered 2020 everywhere out of habit, changed them all to 2021!
|
| | |
|
| | |
|
| |
|
|
|
|
| |
README was re-generated from README.org
New feature was documented.
|
| | |
|
| |
|
|
|
|
| |
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.
|
| |
|
|
|
| |
Octans found 10 solutions to this puzzle:
https://mastodon.art/@Algot/105413312119416356
|
| | |
|
| |
|
|
| |
bin/octans calls lib/Octans/CLI.rakumod which has the MAIN subroutine.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| | |
|
| | |
|
| | |
|
| |
|