arxcis / adventofcode2018 Goto Github PK

Problem when trying to do simple cargo run --release

 cargo run --release
   Compiling advent_of_code_2018_day_01 v0.1.0 (/Users/jonasjso/git/github/arxcis/adventofcode2018/day01-chronal-calibration/rust)
error: Edition 2018 is unstable and only available for nightly builds of rustc.

versions

$ cargo -V
cargo 1.30.0
$ rustc --version
rustc 1.30.0

Finishes in 8 minutes on my machine

  ✔ day06-chronal-coordinates › test › main.bash (8m 18.4s)
    ℹ 3909 === 3909 1 of 2
    ℹ 36238 === 36238 2 of 2

Would be interesting to investigate if something can be done to improve performance.

I am not qualified yet, as I have not completed the task in any other language. But I will be ready to discuss as soon as I get there.

running any of the npm commands i get:

> ava --verbose


  ✖ Couldn't find any files to test

npm ERR! code ELIFECYCLE
npm ERR! errno 1
npm ERR! adventofcode2018@ all: `ava --verbose`
npm ERR! Exit status 1
npm ERR! 
npm ERR! Failed at the adventofcode2018@ all script.
npm ERR! This is probably not a problem with npm. There is likely additional logging output above.

Build #17: https://travis-ci.org/Arxcis/adventofcode2018/builds/462595626
Especially installing Rust takes a long time

I think there is a way to cache parts of the build process. To be researched

When I call npm run generate && npm run bash day03-no-matter-how-you-slice-it/ I get this:

tholok:~/code/forked$ npm run generate && npm run bash day03-no-matter-how-you-slice-it/

> adventofcode2018@ generate /home/tholok/code/forked
> node generate.js

Generated day01-chronal-calibration/test.js
Generated day02-inventory-management-system/test.js
Generated day03-no-matter-how-you-slice-it/test.js
Generated day04-respose-record/test.js
Generated day05-alchemical-reduction/test.js

> adventofcode2018@ bash /home/tholok/code/forked
> ava --verbose --match='*.bash' "day03-no-matter-how-you-slice-it/"


  ✔ test › main.bash (59.4s)

...and then it hangs forever.

It gives the right output, so I suspect there is something wrong with the tests. @Arxcis any idea what could be causing this?

Versions:

tholok:~$ node --version
v11.2.0
tholok:~$ npm --version
6.4.1

At the latest pulled down commit at the time of writing.

I'll let it run for a while and see how long it takes

Day 3 requires the input to be read line-by-line. Doing ./main.bash $(cat input) gives the input as a long array of strings for me, the newlines disappear. Doing ./main.bash "$(cat input)" however does retain the newlines.

How do the other languages behave here? Is it Bash's fault, or does $(cat input) without quotes expand to a sequence of strings for you as well?

This is code I'm testing with:

CLAIMS="$@"

while read -r line; do
    echo "... $line ..."
done <<< "$CLAIMS"

./main.bash $(cat input) gives ... #1 @ 1,3: 4x4 #2 @ 3,1: 4x4 #3 @ 5,5: 2x2 ...

./main.bash "$(cat input) gives

... #1 @ 1,3: 4x4 ...
... #2 @ 3,1: 4x4 ...
... #3 @ 5,5: 2x2 ...

For now I'll solve using the quoted version. Passing input this way in AoC is new to me so I might be misunderstanding something here 😋

I'm not sure what the etiquette on suggested improvements is in the repo, please let me know any opinions around that. Could be appropriate to discuss in the README as well.

In day01-chronal-calibration/main.cpp a std::map is used to store seen frequencies. Wouldn't a std::set be more idiomatic, since the value stored for each element (1) is never used? The change would mostly be for readability. I'm not sure about the performance differences, but a quick google says they basically have the same lookup and insert times.

The Bash and Golang solutions use maps as well, but they don't have built-in sets to take advantage of.

Languages which is going to be prioritized so far

• Bash
• C#
• C++
• Clojure
• Go
• Kotlin
• Nodejs
• Perl
• Python3
• R
• Rust
• Swift

cause I keep forgetting :p

Good to have for newcomers as well.

Cargo is rust package manager, that wraps the compiler. Since rust has the idea that the std only gives you the most common tools to make good libraries.
Also you now do not have to do a compile and then a run of the executable. cargo run does that all for you. It will also download, and compile all your dependencies. In my life i have only used rustc once. This is also necessary so that editors recognize all the code. Thinking of using grabinput for grabbing all the input. as the code is redundant and the logic is not interesting.

Also you probably want to run cargo run --release to get the optimised version. Atleast one of the AOC is going to require some computation.

• All tests are almost identical, and there is a lot of repetition from folder to folder. This makes generating tests very simple.

• The generator would generate a test.js in each folder.

• We could have a npm build test, npm run test and npm remove test

Example from day01

import test from 'ava'
import {
    testGo,
    testCpp,
    testBash,
    testRust,
} from '../test-util'

const dirpath = __dirname
test('main.go', async t => await testGo(t, dirpath))
test('main.cpp', async t => await testCpp(t, dirpath))
test('main.bash', async t => await testBash(t, dirpath))
test.skip('main.py', async t => await testPython(t, dirpath))
test.skip('main.rs', async t => await testRust(t, dirpath))

Travis has an Environment variable TRAVIS_PULL_REQUEST_BRANCH

if people name their branches in a strict manner, we can use it to conditionally test only one language-day-pair:

• Branch day01-js -> npm run js day01/
• Branch day01-rs -> npm run rs day01/
• Branch day02-py -> npm run py day02/

else npm run all

My current Bash solution for day 3 part 1 is estimated to take 2 hours. I'm hoping this is my fault and not Bash, since then I can at least improve upon it, but if it turns out some languages will just be this slow, how do we handle this in automated testing?

One solution would be for Travis to do a git diff to figure out what files are changed, and only test those. Normally this is a nono, but since the files are all independant programs that are not affected by each other I'd say it's excusable.

Would be a shame to block certain languages from entering.

The style guide: https://google.github.io/styleguide/shell.xml#Naming_Conventions.

I can do this myself of course, posting it here for reference later.

I've used uppercase for variables (except for loop variables for some reason) in the Bash solutions. I want to change it to follow the Google style guide that uses lower case for normal variables and upper case for constants (revolutionary idea! :o). Constants in Bash can be made with readonly and declare -r btw, never knew.

During the solve in Bash for day6 I think made a false assumption about the area to search while looking for answers to part 1. It happened to work out with the input I had, so I did not prioritize fixing it at the time. I think I know a way to fix it, but my fix seems a little dirty, so I'd love to get input on what other people did 😋

(My solution is also very slow.. #38)

Spoilers below!

The mistake I made

When looking for locations that could count towards the area of locations that is closest to a finite coordinate I search in a square from the left-most x and y of any coordinate to the right-most x and y of any seen coordinate. So given three coordinates A, B and C (and some excluded ones below that make C finite) the search area could look like this:

0: not searched
x: search area

0 0 0 0 0 0 0 0 0
0 A x x x x x B 0
0 x x x x x x x 0
0 x x x C x x x 0
...(more coordinates below)

My solution would see A and B, and determine that the only area it needs to search for locations closest to C is the area marked as x. 0 means the location is never looked at. This works out fine in this example, but here is an example that does not work with my solution:

0 0 0 0 0 0 ! 0 0 0 0 0 0
0 A x x x x x x x x x C 0
0 x x x x x C x x x x x 0
...(more coordinates below)

In this example the location marked as "!" is closest to C, so it should be counted towards it's area for the solution of part 1. My code only looks at the area marked as x though, so it would get the answer wrong here.

A fix

A solution would be for the code to search through the area in a diamond shape like this:

0 0 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 0 x 0 0 0 0 0 0
0 0 0 0 0 x x x 0 0 0 0 0
0 0 0 0 x x x x x 0 0 0 0
0 0 0 x x x x x x x 0 0 0
0 0 x x x x x x x x 0 0 0
0 A x x x x x x x x x C 0
0 x x x x x C x x x x x 0
...(more coordinates below)

This would catch the example above, and (I think) it would catch any other such edge cases. This fix seems a little dirty though, and would require over double the area to be searched...

Let me know if anything is unclear. Any input is awesome. Guessing someone found a smarter way of searching :)

Are solutions to only one part of a day "innafor" (😋), or do you think we should finish both before adding.

If there is a short and clear way to mark that a day has only been solved for part 1 or 2 in the table it could work out well 😋

Something like:

Got my Bash day 3 part 1 down to 2 minutes (from 2 hours), so would love to add it.