<jimjimovich>
thanks ... don't remember including that in older projects
jugglinmike has joined #nanoc
muma has joined #nanoc
jimjimovich has quit [Quit: Leaving.]
muma has quit [Quit: leaving]
* ddfreyne
upvotes darix' answer
<ddfreyne>
Ah wait, this isn't Reddit
muma has joined #nanoc
muma has quit [Quit: leaving]
mbeyer has joined #nanoc
alerante has joined #nanoc
ddfreyne has quit [Excess Flood]
ddfreyne has joined #nanoc
mbeyer has quit [Quit: leaving]
mbeyer has joined #nanoc
mbeyer is now known as musicmatze
bitslip has quit [Quit: leaving]
<ddfreyne>
Alright, what should I work on this weekend for nanoc? Bug fixes for 3.6.3? Fixing musicmatze’s site? New exciting architectural changes for 4.0?
<ddfreyne>
Prepare for Poker Night tomorrow? :D
<tbm>
bug fixes would be great
musicmatze has quit [Quit: leaving]
mbeyer has joined #nanoc
mbeyer is now known as musicmatze
alerante has quit [Remote host closed the connection]
<ddfreyne>
set some breakpoints or print statements etc
<tbm>
ddfreyne: I tried adding 'warn' statements in the code but they were not always printed, so I wonder if it's a threading issue. anyway, I'm new ro ruby so cannot debug further
<ddfreyne>
ok :)
<darix>
debugging multithreaded code via print seems like asking for pain
<ddfreyne>
I need to find a better way to do this (threadless)
<ddfreyne>
The reason why it runs in a thread because diff generation is something that should happen simultaneously with the rest…
alerante has joined #nanoc
<ddfreyne>
Not that I want to boast, but my nanoc --verison
<ddfreyne>
Not that I want to boast, but my nanoc --version returns
<ddfreyne>
Basically, the listeners were started, but never stopped. Stopping the listeners is necessary, otherwise nanoc terminates before the diff threads have finished
<ddfreyne>
Stopping the diff generation listener makes it wait until all the diff threads have finished
<ddfreyne>
Now, as for how to test this… seems hard.
<ddfreyne>
I remember writing this on the train and having to catch another train… maybe I lost my concentration there and that’s why this stuff sucks!
<ddfreyne>
It should also have been code reviewed.
<ddfreyne>
New issue: all compiled items appear double
<ddfreyne>
update [0.11s] output/index.html
<ddfreyne>
update [0.16s] output/index.html
<ddfreyne>
(The numbers are even wrong. How is that possible?)
<tbm>
ddfreyne: cool, thanks for looking into this!
<musicmatze>
ddfreyne: I hope you are not sulky: I started thinking about writing my own ssg/ssc and I started to create a project-setup (planning-phase currently)
<musicmatze>
But anyway, I will try to help you (and others) with nanoc as good as I can!
<musicmatze>
and I know, it can take a long time until something works, so it isn't a rival product to nanoc at all...
<ddfreyne>
musicmatze: I understand. A single product is never able to cover all cases all the time, but I’ll nonetheless fix the issues that you are struggling with
<ddfreyne>
musicmatze: Writing a good static site generator is surprisingly hard, especially if you want to make it generally applicable
<musicmatze>
Thank you. I hope you are not cross with me now. I really like nanoc and the community around it.
<ddfreyne>
musicmatze: Not at all… you’ve been more patient than I would be, I think :)
<musicmatze>
Well, yeah. I will try to write one. If it does not work... no problem. I can use nanoc! :D
<musicmatze>
ddfreyne: That's because I know it is really hard to write such stuff, and I tried to read some of the code. It's really hard for me to understand what the code actually does, so full comprehension from me!
<musicmatze>
Maybe my project will teach me about how to build a compiler. Party, because I will use libs, too (discount, to name at least one important). But the infrastructure I have to build around it is also compiler-like!
<ddfreyne>
musicmatze: Well, in any case, nanoc is not a simple static site generator. It’s over 25k lines of code (includes tests, comments and blank lines)
<musicmatze>
That's much. That's really much! Especially for Ruby!
<ddfreyne>
5k for the core (without tests)
<musicmatze>
my largest project has about 4000 lines, and it is written in C (counted with "cloc", which is not really reliable, I think).
<ddfreyne>
musicmatze: With tests, nanoc is 13488 as counted by cloc
<ddfreyne>
5887 for the code (without tests)
<musicmatze>
still really, really much! Also because it is Ruby!
<ddfreyne>
2346 for core :)
<ddfreyne>
Wait, that’s in the 4.0 branch
<ddfreyne>
Which is significantly less code than 3.x
<musicmatze>
lol
<ddfreyne>
I <3 deleting code
<musicmatze>
6778 in lib/* counted with cloc on release-3.6.x !
<ddfreyne>
I already deleted quite a bit, eh :)
<ddfreyne>
Let me delete some more…
<musicmatze>
:D
<ddfreyne>
The minimum requirement for nanoc 4.x will be Ruby 1.9
<ddfreyne>
So, that means getting rid of OrderedHash and Enumerable#group_by
<musicmatze>
That's nice. I'm running Ruby 2.0.0 here, since some days. It seems to be a huge bit faster than 1.9.3, which I used before.
<ddfreyne>
yeah, Ruby 2.0 is pretty cool!
<musicmatze>
Not as fast as I want it to be.
<ddfreyne>
Well, it’s still Ruby of course…
<ddfreyne>
musicmatze: What language are you going to use for your static site generator?
<musicmatze>
But I think in future, Ruby will be much much faster!
<musicmatze>
C.
<ddfreyne>
heh, thought so :)
<musicmatze>
And yeah, I know... C is really low-level and so on.
<musicmatze>
But I'm going to build up a module-infrastructure.
<ddfreyne>
C is pretty cool… I can’t say I am really great at it, but I like it because you have a VERY good idea of what is going on
<bobthecow>
musicmatze: you know, you could build one in ruby then implement the slowest bits as C.
<musicmatze>
The core will be able to load modules (for different purposes) and not more.
<bobthecow>
and have the best of both worlds.
<musicmatze>
bobthecow: Yes, I know this.
<musicmatze>
because of this I will write the core module in C.
<musicmatze>
And every other module can implement an interface to $LANGUAGE.
<musicmatze>
So, the Compiler-core can be in Ruby, the loader-core can be done in Python, and so on.
<musicmatze>
That's the Idea.
<ddfreyne>
bobthecow: I had that as a possibility for nanoc too, but I always kept on optimising the Ruby stuff instead
<musicmatze>
And the whole thing can be configured by one single config file.
<bobthecow>
ddfreyne: ruby can go really really fast provided you don't do anything dumb with it.
<bobthecow>
:)
<ddfreyne>
musicmatze: I think I asked Skyr before, but what does int a[4]; printf("%p\n", &x+1); print? :D
<ddfreyne>
bobthecow: Yes
<musicmatze>
So in config there must be which module should be loaded for compiling, and this module has to do the compiling. The core does not care about this.
<bobthecow>
in fact, i'd say the major optimizations that can be made to nanoc are mostly algorithmic.
<bobthecow>
i didn't think several of those cleared the method cache.
hakunin has quit [Ping timeout: 256 seconds]
<guardian>
is there still an rvm vs rbenv debate? or did one of the two win?
<guardian>
ddfreyne: what did you mean by "So, that means getting rid of OrderedHash and Enumerable#group_by" I'm using group_by in my helpers here and there, why don't you like them
pavelkunc has quit [Quit: Leaving.]
Keltia has joined #nanoc
<Keltia>
hello
<bobthecow>
rbenv won for me and my company :)
<bobthecow>
hey Keltia.
<bobthecow>
welcome to the #nanoc
* Keltia
loves rbenv
<darix>
bobthecow: i just build me proper packages from the gems. ;)
<guardian>
i was about to populate created_at and updated_at with git
<guardian>
gut sometimes you fix a typo etc and you don't want updated_at to move
<guardian>
s/gut/but
<Keltia>
I mostly use "hg push" to move things into production, not "nanoc deploy", is there any specific issue I should watch for (apart from having a complete copy of the repo in production of course)?
<ddfreyne>
Keltia: Hmm, I’d say that disallowing access to .hg would be a requirement
<ddfreyne>
Although, that may not be a problem if you don’t consider the output/ directory itself a separate repository
pavelkunc has joined #nanoc
<Keltia>
ddfreyne: output/ is not a repo and .hg is above anyway. docroot for nginx is set to output/ so I am safe
<ddfreyne>
Keltia: alright
<Keltia>
and nothing inside output/ is controlled by hg and I use prune: true :)
<ddfreyne>
Looks good :)
<Keltia>
ddfreyne: I figured how to make robots.txt "binary" so it gets copied
<ddfreyne>
Keltia: You don’t need to make it binary per se
<Keltia>
ddfreyne: well, it was generating robots/index.html
<ddfreyne>
Keltia: If you have “txt” in your list of text_extensions, you can have route '/robots/' ; '/robots.txt' ; end, as well as compile '/robots/' ; end
<ddfreyne>
(assuming you have content/robots.txt)
<Keltia>
and I didn't felt like be an erb file
pavelkunc has quit [Client Quit]
<Keltia>
ddfreyne: good point
<Keltia>
ddfreyne: while I'm here, how to make "nanoc create-item foo" generate foo.md and not foo.html?
<ddfreyne>
Keltia: You can’t, unless you define your own command
<ddfreyne>
Keltia: I never use create-item or create-layout… I just create the files manually, much easier
<Keltia>
ddfreyne: not worth creating a new command, I agree. I create and "hg add" directly
<ddfreyne>
Keltia: create-item and create-layout didn’t make the cut to nanoc 4.0 in any case ;)
<Keltia>
ddfreyne: arf
<Keltia>
ddfreyne: I looked at jekyll & middleman as well, any opinion? (I choose nanoc obviously)
<Keltia>
middleman seemed too complicated at first
<ddfreyne>
Keltia: Basically, you shouldn’t access anything outside nanoc (e.g. open files, do Dir[] calls, etc) while inside nanoc
<ddfreyne>
Keltia: Otherwise, nanoc won’t be able to track dependencies correctly
<ddfreyne>
Keltia: Do you have a /programs/ item? If so, @item['/program/'].children.each do |i|
<Keltia>
no specific /programs/ item, just a directory with .md files
<ddfreyne>
Keltia: The @items.select stuff will work fine (and unless your site has more than a few hundred pages, I wouldn’t worry about performance)
<Keltia>
ddfreyne: and show-data does not show a specific /programs/ item
<Keltia>
ddfreyne: thanks
<Keltia>
ddfreyne: is all this documented? I must have missed that
<ddfreyne>
Keltia: @items is an Array of Nanoc::Item instances, and the #select stuff comes from Array… and Nanoc::Item has a method called #identifier
<Keltia>
ddfreyne: my previous site was built with radiantcms+pgsql and I didn't have the courage to set it up again after my main machine crashed, so nanoc it is now