New issue

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

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

Already on GitHub? Sign in to your account

Add `each` to ConfigView? #705

Closed
gjtorikian opened this Issue Oct 18, 2015 · 3 comments

Comments

Projects
None yet
2 participants
@gjtorikian
Member

gjtorikian commented Oct 18, 2015

I was toying around with jumping from Nanoc3 to 4 and found that one of my preprocessors has stopped working. It depends on iterating over the existing config keys to set some other information up.

Would there be any interest in a PR that adds each to ConfigView?

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Oct 18, 2015

Member

Absolutely!

By the way, I started working on a branch to upgrade the GitHub developer site to Nanoc 4, but haven’t touched in a couple of months. (Opened as a PR on my own repo, rather than GitHub’s, so I can keep track of progress without creating noise.)

Member

ddfreyne commented Oct 18, 2015

Absolutely!

By the way, I started working on a branch to upgrade the GitHub developer site to Nanoc 4, but haven’t touched in a couple of months. (Opened as a PR on my own repo, rather than GitHub’s, so I can keep track of progress without creating noise.)

@gjtorikian

This comment has been minimized.

Show comment
Hide comment
@gjtorikian

gjtorikian Oct 18, 2015

Member

Ah, that's awesome!

By the way, it's look like I'll probably be porting our main <help.github.com> site to Nanoc, too. It's suffering under abysmal performance with Jekyll—about a minute build times locally and nearly ten minutes (!) in production. The problem is that I've monkey-patched the code (via plugins) so much to do what we need it to do that it's getting complicated to wrap my head around it. I just couldn't find a way to hook into key parts of the compilation. I only yesterday realized that porting over to Nanoc 4 makes much more sense. I love it! I can hook into the file system before files are read (which we need), I can do some preprocessing, and I can apply the same filters to the same bits of content.

That'll bring our two major sites ({help|developer}.github.com under the same engine. Hopefully I'll toss over more PRs to Nanoc4 if I find more issues.

Member

gjtorikian commented Oct 18, 2015

Ah, that's awesome!

By the way, it's look like I'll probably be porting our main <help.github.com> site to Nanoc, too. It's suffering under abysmal performance with Jekyll—about a minute build times locally and nearly ten minutes (!) in production. The problem is that I've monkey-patched the code (via plugins) so much to do what we need it to do that it's getting complicated to wrap my head around it. I just couldn't find a way to hook into key parts of the compilation. I only yesterday realized that porting over to Nanoc 4 makes much more sense. I love it! I can hook into the file system before files are read (which we need), I can do some preprocessing, and I can apply the same filters to the same bits of content.

That'll bring our two major sites ({help|developer}.github.com under the same engine. Hopefully I'll toss over more PRs to Nanoc4 if I find more issues.

@ddfreyne

This comment has been minimized.

Show comment
Hide comment
@ddfreyne

ddfreyne Oct 18, 2015

Member

Sounds exciting! :)

Nanoc 4.0 is in a feature freeze, but I think the wait until 4.1 won’t be that long. The 4.0 release will show all sorts of missing nice-to-have things that’ll end up in 4.1 quickly enough!

On one hand, Nanoc 4 (when using the new identifiers and new globs) will be slower than 3.x, but it also offers much more potential for optimisations, which will end up in later minor releases.

Member

ddfreyne commented Oct 18, 2015

Sounds exciting! :)

Nanoc 4.0 is in a feature freeze, but I think the wait until 4.1 won’t be that long. The 4.0 release will show all sorts of missing nice-to-have things that’ll end up in 4.1 quickly enough!

On one hand, Nanoc 4 (when using the new identifiers and new globs) will be slower than 3.x, but it also offers much more potential for optimisations, which will end up in later minor releases.

gjtorikian added a commit to gjtorikian/nanoc that referenced this issue Oct 19, 2015

@ddfreyne ddfreyne closed this in #706 Oct 19, 2015

@ddfreyne ddfreyne added this to the 4.1.0 milestone Oct 19, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment