ddfreyne changed the topic of #nanoc to: 3.6.7 (dec 9th) | web http://nanoc.ws/ | repo http://bit.ly/XE6e3G | issues http://bit.ly/VfXaSV | forum http://ho.io/n-discuss | irclog http://irclog.whitequark.org/nanoc
louquillio_ has joined #nanoc
prxq has quit [Ping timeout: 245 seconds]
prxq has joined #nanoc
jugglinmike has quit [Quit: Leaving.]
VitamineD has quit [Ping timeout: 265 seconds]
prxq_ has joined #nanoc
prxq has quit [Ping timeout: 248 seconds]
alerante has quit [Remote host closed the connection]
alerante has joined #nanoc
ics has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
ics has joined #nanoc
v101 has joined #nanoc
v101 has left #nanoc [#nanoc]
alerante has quit [Remote host closed the connection]
<guardian> morning
alerante has joined #nanoc
alerante has quit [Ping timeout: 252 seconds]
relix has joined #nanoc
ics has quit [Ping timeout: 260 seconds]
ics has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
VitamineD has joined #nanoc
aktau has joined #nanoc
<aktau> Hey guys!
<aktau> I'm trying to integrate an image_size filter
<aktau> Which basically reads out the size of an image and adds the appropiate width/height attributes
<aktau> Making later reflows unnecesary, thus speeding up rendering
<aktau> However, some of my images are actually thumbnails of bigger images
<aktau> Which are generated through a :thumbnailize fileter
<aktau> What happens is that by the time the :image_size filter runs, the thumbnails are not in the /output folder
<aktau> Because both filter happen in the compile step, while I assume the /output folder gets made in the routing step
<aktau> How would I solve this conundrum?
<VitamineD> aktau: thumbnail to a representation of the original item, then set width/height in the compile rule for those reps
alerante has joined #nanoc
<aktau> VitamineD: it is currently a representation, see my Rules file at https://github.com/aktau/aktau.github.com
<aktau> VitamineD: Unless I'm really misunderstanding
jugglinmike has joined #nanoc
VitamineD has quit [Quit: VitamineD]
VitamineD has joined #nanoc
<ddfreyne> aktau: I'd suggest creating an <%= image_link('/assets/images/blah/') %> helper that finds the item (using @items['/assets/…']), gets the default item rep (.rep_named(:default)), then passes that to some tool that can read the width/height, then finally output an <img> tag with the width/height set
<aktau> ddfreyne: I'd actually want the width/height of the :thumbnail rep
<aktau> ddfreyne: I really like the way it works right now, very unobstructively, I can just include the image in my markdown, it gets filtered to html, then in the imagesize filter it gets parsed out by nokogiri, which select every <img> tag and adds width/height
<aktau> ddfreyne: the only real problem being that the image does not exist in the /output directory yet
<aktau> ddfreyne: did you see the source of my page?
alerante has quit [Remote host closed the connection]
<bobthecow> prxq_: you can also get items out of @items by using their identifier as an index...
<bobthecow> prxq_: link_to @items['/foo/bar/']
<bobthecow> guardian: everything in your thing makes sense except the factory.
<bobthecow> why not put a 'common' submodule in the top level instead of factory...
<bobthecow> could have `common/content`, `common/rules`, `common/layouts`
<bobthecow> then make a datasource for that.
<bobthecow> and have a rules file in the top level that imports the common rules
<bobthecow> (would also mean you could override / extend rules in any given project as needed)
alerante has joined #nanoc
<guardian> bobthecow: I envision factory as a "nanoc framework" which rules, layouts, helpers, css and js won't change in isolation since the goal is to share a same visual design and behavior between products
<guardian> bobthecow: what you suggest is that each product has a its own nanoc site (in the doc/ subfolder) that reuses some common rules and layouts etc
<bobthecow> yeah. that makes a bit more sense to me.
<bobthecow> fwiw, you don't need your monkeypatch regardless.
<guardian> bobthecow: but that would mean copy/paste the part that reuses common/content, common/rules and common/layouts between projects
<bobthecow> just set up the relative directory in config.
<guardian> in the first place, monkey patching nanoc == something more robust than symlinks which don't play well with git
<guardian> I'm not sure it's a win to duplicate the part that imports common/content, common/rules, common/layouts, common/libs etc between products
<bobthecow> you don't need to monkeypatch nanoc.
<guardian> I thought that doing the way I suggests puts few people in control of the "nanoc framework" while others could focus on writing .md files in product1/doc/content/
<bobthecow> just tell it that its content directory isn't in factory/content
<bobthecow> that's a config option.
<guardian> that's a config option for the static data source only
<guardian> if I'm not mistaken
<bobthecow> oh, right. we never got around to fixing filesystem
<bobthecow> ugh.
<bobthecow> i think there's been an issue open for doing that for about two years.
<guardian> even if it's an option, our approachs still differ :)
<guardian> I appreciate the debate, I'll think more about what you suggest
<bobthecow> i'm not debating.
<bobthecow> i see the value of your approach. i was just saying that you shouldn't monkeypatch nanoc.
<bobthecow> it turns out that you have a valid reason, thanks to an inflexible data source.
<bobthecow> i'd extend the data source, personally, rather than monkeypatching.
<bobthecow> or send a pull request to make the content directory respect config :)
<guardian> ok let aside the part about patching or configuring or extending
<guardian> the approach you just suggested is still different
<bobthecow> i know.
<guardian> I see value: having specific rules per product
<guardian> I need to consider how much I need/want that
<guardian> compared to the approach I was about to take so far
<bobthecow> my approach would make it more like traditional inheritance... each project would have a docs site, which extends a base site's rules, layouts, etc.
<guardian> and I appreciate you took time to have a look at that pastebin and think about it :)
<bobthecow> and in most cases you wouldn't need to extend layouts... but in some cases you would :)
<bobthecow> i'm just thinking about the reality of every project i've ever worked on. someone always needs to hack on something.
<guardian> can an additional data source populate layouts? I didn't have the impression the static datasource could for instance
<bobthecow> yeah.
<bobthecow> it doesn't, but it can.
<guardian> I have the impression the static datasource can populate items only
<bobthecow> it's part of the datasource api.
<bobthecow> static doesn't.
<guardian> ok
<bobthecow> but if you make a common datasource, you could load your common content and layouts...
<guardian> sure, that common datasource could load content and layout from ../content and ../layout
<guardian> that would keep my approach
<guardian> and remove the patching
<bobthecow> as i see it, you'd have a rules file in each docs directory that just includes the common rules. a lib file in each docs directory that includes the common libs. and a config file that points at the common datasource.
<bobthecow> that way you could put a rule above that include to override, or a rule after that include to extend.
<guardian> could be handy indeed
<bobthecow> the more i code, the more boring i get. i like explicit includes and being able to trace everything that happens :)
<guardian> so practically, if I create a brand new site
<guardian> how do I make it use common/lib/ the way it uses lib/ ?
<guardian> you said "include" but I guess I need to code something that globs into common/lib and "include/evaluate" common helpers right?
<bobthecow> probably?
<guardian> that was a practical question :) I'm not enough fluent in nanoc/ruby to do so. Could you e.g. give me a pointer into nanoc's source? Where nanoc does it for the lib/ folder?
<guardian> found it I guess:
<bobthecow> yeah.
<bobthecow> hrm.
<bobthecow> you'd need to load code snippets.
<bobthecow> i wonder if a datasource can do that?
<guardian> would it be in the data source?
<bobthecow> (they're stored in code snippets to deal with dependency tracking)
<guardian> I guess lib/common.rb could do that
<guardian> if the directory structure is site/lib and site/common/lib then maybe site/lib/common.rb could load and execute snippets in site/common/lib/**/*.rb
<bobthecow> possibly. it looks like code snippets are fairly hardcoded... i'm not sure what implications that would have. you'd have to ask ddfreyne.
VitamineD has quit [Quit: VitamineD]
<guardian> yes please ddfreyne
VitamineD has joined #nanoc
<ddfreyne> aktau: Yeah
<ddfreyne> aktau: That is why I'd recommend having a tag that references the item identifier for the image instead
<ddfreyne> aktau: This way, you can tell nanoc to compile the image first (i.e. create it in the output directory)
<ddfreyne> aktau: Simply by referencing the raw_path, it will generate a dependency, but you still need to make sure th eimages are compiled first, by calling .depend_on(my_image_items) in the image_size filter
relix has quit [Ping timeout: 246 seconds]
relix has joined #nanoc
<guardian> re
<aktau> ddfreyne: from a high-level, I get what you mean, though I have no idea how to achieve this (I'm supposing the item identifier is just the path as seen from /content, don't know what "tag" means in this context)
<ddfreyne> aktau: sec
<ddfreyne> I have to apologise for not documenting that on the site properly. The dependency generation is not 100%.
<aktau> As they say, "gene stress"
<ddfreyne> Heh :)
<ddfreyne> Where are you from?
<aktau> Close to Antwerp
<guardian> ddfreyne: did you follow the end of my conversation with bobthecow? does it fly to have site/lib/common.rb that instantiates other code snippets found in site/common/lib/**/*.rb?
<ddfreyne> guardian: I haven't followed the conversation tbh, could you summarise?
<ddfreyne> aktau: I'm from Ghent originally, but I live in Berlin now
<guardian> ddfreyne: the idea is to have a nanoc site in site/ and have a git submodule in site/common that contains common stuff: items, layouts, rules and helpers
<guardian> ddfreyne: a custom datasource would populate items from site/common/content, site/Rules would "import" rules from site/common/Rules
<ddfreyne> guardian: Loading items/layouts from site/common is something you can do from a data source
<ddfreyne> Rules is also no problem
<guardian> ddfreyne: and site/lib/common.lib would instantiate code snippets from site/common/lib/**/*.rb
<ddfreyne> lib... is difficult
<ddfreyne> (dependency issues)
<ddfreyne> guardian: what about a submodule site/lib/common ?
<guardian> well the idea was: have a "nanoc framework" that is reused among different products: http://pastebin.com/YBtd7pB9
<guardian> and bobthecow mentioned another solution that would allow each product to customize Rules and helpers
<guardian> and having too many submodules will complicate things further
<guardian> ddfreyne: is there a way to have have site/lib/common.lib to "import/include/mix" what's in site/common/lib/**.*.rb or even site/common/lib/common.rb?
<guardian> ddfreyne: at first I thought about replicating what site.rb does: load and instantiate code snippets. But I clearly don't see the implications with dependency issues
<ddfreyne> guardian: Ahh, that also works, actually
<ddfreyne> (and handles dependencies well)
<guardian> good to know
<guardian> I'll play with this idea
<guardian> thx for listening and answering :)
<aktau> ddfreyne: looks nice, but I'd have to write my posts in .erb instead of .md, no?
<ddfreyne> aktau: You can combine both (have a filter for :erb, then a filter for markdown)
<guardian> ddfreyne: do we need both soft and hard dependencies?
<guardian> on my site I'm doing: raise Nanoc::Errors::UnmetDependency.new(rep) unless rep.compiled?
<guardian> but I wasn't aware of soft dependencies
<ddfreyne> guardian: A soft dependency from A on B means that if B changes, A should be recompiled
<ddfreyne> guardian: A hard dependency from A on B means that B needs to be compiled first
<guardian> ok
<guardian> I'm adding the soft thing to my helper right now
<ddfreyne> guardian: Soft dependencies are useful when an attribute changes in B that is used in A
<guardian> Nanoc::NotificationCenter.post(:visit_started, item)
<guardian> item is the image right?
<guardian> that is, item is B
<guardian> and A is the item using the helper
<guardian> do I get it right?
<aktau> ddfreyne: quite right, that could do it
<ddfreyne> guardian: yes
<aktau> ddfreyne: by the way, by accident I viewed a presentation of yours where you mentioned pygments.rb was faster than plain pygments. This did not seem obvious to me (why would a wrapper be faster) so I had never done it and was content to just use pygments and have one gem less
<aktau> ddfreyne: but since changing, my compiles have go from 10s to 0.5s, which makes all the difference in the world
<aktau> So thanks for that ;)
<ddfreyne> aktau: It is faster because pygments.rb invokes the Python interpreter directly as opposed to spinning up a Python instance every time
<ddfreyne> I don't know the detail about how it works though
<aktau> ddfreyne: yea, once changing I reasoned it must be something like that as well
<aktau> I think it might help to put that more prominently in the docs if it isn't already
<bobthecow> ddfreyne: it's really clever, actually.
<bobthecow> and fairly easy to follow. you should check out the source.
<guardian> I plan to add syntax highlighting to a future site. So you're discussing using pygments.rb gem? And then does nanoc have a builtin filter for that? Because I was looking into Kramdown's CodeRay support
<aktau> guardian: yes, it has a builtin filter
<aktau> guardian: for an example, you can look at my site for example: https://github.com/aktau/aktau.github.com
<guardian> bookmarked, thx!
<aktau> guardian: don't forget to bundle install the correct gems, and to also have pygments itself installed
<guardian> k
<bobthecow> basically, pygments.rb has a python script called mentos.py that wraps the pygments API.
<bobthecow> wraps it with something that speaks JSON over stdin/out
<bobthecow> then they spin that up and pipe things to it from ruby
<aktau> Right
<aktau> That explains it :)
<ddfreyne> Ahh, nice
<ddfreyne> http://stoneship.org/tmp/nanoc.pdf Playing around with asciidoc+dblatex
aktau has quit [Ping timeout: 245 seconds]
<guardian> why asciidoc?
<guardian> couldn't a pdf output be achieved with markdown?
aktau has joined #nanoc
VitamineD has quit [Remote host closed the connection]
VitamineD has joined #nanoc
VitamineD has quit [Ping timeout: 245 seconds]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
aktau has quit [Quit: leaving]