Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

input to generator function seems to be missing trailing newlines #65

Open
tsheinen opened this issue Dec 4, 2020 · 6 comments
Open

Comments

@tsheinen
Copy link

tsheinen commented Dec 4, 2020

I ran into some trouble with today's (2020/day 4) problem because the generator was passing a truncated form of the input files sans any trailing newlines. I'm unclear as to why this happens because my functioning test case also uses include_str! but its replicable and happens to any number of trailing newlines. I'm using aoc-runner and aoc-runner-derive version 0.30 and cargo-aoc version 0.3.2.

@gobanos
Copy link
Owner

gobanos commented Dec 4, 2020

Hum, input is trimmed to ease parsing (for example, when parsing a number on each line) here :

ArcStr(Arc::from(f.trim_end_matches('\n')))

There is currently no way to turn it off :/

@tsheinen
Copy link
Author

tsheinen commented Dec 4, 2020

Oh okay, I missed that while I was looking through the source. It might be worth mentioning that in the readme (or adding a way to turn it off) since it threw me for a loop this morning. My parser depended on a trailing newline for each passport and although it was easy enough to fix I didn't realize I needed to do that.

@tsheinen
Copy link
Author

tsheinen commented Dec 4, 2020

What would be the use case for stripping the trailing newline? str::lines is probably the best way to split a string like this into lines and it gives the same result with and without a trailing newline.

@gobanos
Copy link
Owner

gobanos commented Dec 4, 2020

You're right, a flag to prevent trimming could be nice. After a glance at some old inputs, it still seems like a good default to me.

@aldanor
Copy link

aldanor commented Dec 6, 2020

I would go as far as saying it would make sense to not trim anything at all - because otherwise a solution that works without cargo-aoc may not work with it, and vice versa.

@dnlmlr
Copy link

dnlmlr commented Dec 4, 2022

So I'm pretty much zombifying this issue, but this behavior is absolutely unexpected and should not be the default imo.

Trimming the input in your solution or a generator function is literally one line, if you actually need it. Efficiently untrimming the input on the other hand is pretty much impossible without bad hacks.

This breaks for example a possible optimized solution with array_chunks::<4>() for aoc2022 day2. All lines consist of a structure like A X\n, which is exactly 4 bytes. When the trailing newline is trimmed, this skipps the last line and stops working.

# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants