<prxq_>
I would like to use an additional filter (relativize_paths) but have not the slightest clue as to where I could put it.
<prxq_>
Help!? 8^)
terinjokes has quit [Read error: Operation timed out]
terinjokes has joined #nanoc
<bobthecow>
prxq_: what do you mean?
jugglinmike has joined #nanoc
<prxq_>
well, I solved it. I just didn't know where to write filter :relativize_paths
<prxq_>
right now it is working. But it took me some guessing
<bobthecow>
oh, write it wherever you want it applied :)
<bobthecow>
you can have as many layout and filter calls as you want.
<bobthecow>
a rule is just a list of transformations to apply to an item.
<prxq_>
bobthecow: I didn't realize that something like "filter :something" is in fact a statement, and that you can put a few of these below each other
* prxq_
is new to ruby
<bobthecow>
oh, wow. both the "tutorial" and "basics" sections of the docs don't show an example of multiple filters or multiple layouts.
<bobthecow>
did
<bobthecow>
did you check either of those?
VitamineD has joined #nanoc
louquillio_ has quit [Remote host closed the connection]
VitamineD has quit [Ping timeout: 245 seconds]
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Changing host]
FunkyPenguin has quit [Ping timeout: 272 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Ping timeout: 245 seconds]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Changing host]
FunkyPenguin has joined #nanoc
FunkyPenguin has quit [Excess Flood]
FunkyPenguin has joined #nanoc
<prxq_>
bobthecow: yes
<prxq_>
bobthecow: in this day and age of stackexchange fueled copy-and-paste rampage you actually have to stop and think! Shocking! :-)
<bobthecow>
:)
<bobthecow>
but it should still be mentioned in the tutorial.
<bobthecow>
or at least hinted at.
* prxq_
heads to pastebin.ca
<bobthecow>
if any of those examples had two layouts or two filters you prolly would have figured it out a lot faster, right?
<prxq_>
oh 1 min, baby business
<bobthecow>
mind opening an issue so that gets fixed?
<prxq_>
ok, I will do that later today
<prxq_>
but yes, if the examples had had a case of doing that, I would have spent less time on this.
<prxq_>
The multilingual site write up is a very nice example. It is possible to learn a lot from it
alerante has quit [Remote host closed the connection]
louquillio__ has joined #nanoc
louquillio__ has quit [Client Quit]
<bobthecow>
ddfreyne: why not split the difference?
<bobthecow>
keep all existing filters in 3.x, but any new filters go in nanoc-foo repos?
<ddfreyne>
bobthecow: I'm not keen on creating inconsistencies though. But it's possible.
<bobthecow>
i feel like it's acceptable to have grandfathered cases, as long as it's clear what the policy going forward is.
<ddfreyne>
bobthecow: I'm kinda torn about what I want to do with nanoc 4.0 btw.
<bobthecow>
how so?
<bobthecow>
rewrite it in golang ;)
<ddfreyne>
bobthecow: From a user's perspective, nanoc 4.0 will not bring much new stuff. Yet, from a developer's perspective, it is rather different from 3.x.
<ddfreyne>
bobthecow: Additionally, finishing nanoc 4.0 will take quite a while (a few more months).
<ddfreyne>
bobthecow: Finally, the main goal of nanoc 4 (streaming data sources, i.e. not keeping all items in memory) is surprisingly hard to attain.
<ddfreyne>
All of these factors are demotivating me and I am not sure whether what I am doing is the right thing.
<ddfreyne>
Perhaps, and I think this is a better approach, is to polish nanoc 3.x a bit more, document its limitations and continue working with that.
<ddfreyne>
Every piece of software is going to have limitations and nanoc 4.0 will have, too… perhaps I will have misjudged and nanoc 4.0 will have drawbacks that 3.x currently does not have.
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<ddfreyne>
The #1 complaint with nanoc 3.x is, if I am not mistaken, the odd handling of identifiers when it comes to two files that only differ in extension. Maybe there are ways to work around that in a more or less elegant way.
<bobthecow>
maybe pull a PHP and release what exists of nanoc 4.x and accept that you're not going to accomplish everything you wanted with it?
<bobthecow>
if all 4.x solved was identifier -> filename and splitting out all the filters, it would be worth upgrading to.
<bobthecow>
throw in nanoc.rb config file for fun.
<bobthecow>
and you've got a major release.
<bobthecow>
:)
<ddfreyne>
Yeah, perhaps the entire idea of having streaming data sources is simply not something that is achievable (at least not in 4.0, maybe in a later release)
<bobthecow>
what's the current state of the 4.x branch?
<ddfreyne>
I've done quite a bit of refactoring already, and some stuff is broken (e.g. the preprocessor fails because everything is immutable already).
<bobthecow>
oh, with the identifier -> filesystem stuff, we should make sure globbing works like globbing everywhere.
<ddfreyne>
It's quite a bit cleaner than 3.x. Better separation of concerns, proper "dumb" entity classes, view/proxy/wrapper classes that prevent users from doing stupid thing (like @item.attributes[:blah] and circumventing the dependency tracker by accident)
<ddfreyne>
bobthecow: That is the case in 4.0 already
<ddfreyne>
I'm inclined to revert some commits related to streaming data sources and just forgetting about this. It's causing me serious headaches
<ddfreyne>
(The main reason why I didn't want to implement streaming data sources in 3.x is because the architecture absolutely wasn't up to it)
<bobthecow>
then i'd cherry pick the streaming stuff out of it into a branch, just so you have it.
<bobthecow>
and revert the changes.
<bobthecow>
honestly, streaming could be 4.1 if it's an optional API for data sources.
<bobthecow>
or it could be 5.0
<ddfreyne>
I don't really know whether streaming data sources are really part of the main use case of nanoc anyway
<bobthecow>
that's really just about speeding up huge sites, right?
<ddfreyne>
Yeah. 1000+ pages
<ddfreyne>
And allowing very large sites (10 000+ pages) to be compiled with nanoc
<bobthecow>
yeah.
<ddfreyne>
Those currently fail (depending on the amount of RAM)
<bobthecow>
true.
<ddfreyne>
But… that really is a niche.
<bobthecow>
honestly, it shouldn't slow down making things better for everyone else.
<ddfreyne>
Ohh, btw: It seems tup (http://gittup.org/tup/index.html) monitors file access of spawned processes, so this could be quite useful for figuring out dependencies
<ddfreyne>
(because external processes have free roam over the filesystem and don't need to report their dependencies to nanoc, sadly)
<bobthecow>
i started working on the v3.0 release of Genghis in July 2013. i finally merged the feature branch into develop a couple of weeks ago.
<bobthecow>
that doesn't mean release is imminent, just that it's now far enough along that i'd rather hotfix problems in the stable branch rather than keep rebasing the 3.0 development.
<ddfreyne>
When executed, the command's file accesses are monitored by tup to ensure that they conform to these rules. Any files opened for reading that were generated from another command but not specfied as inputs are reported as errors. Similarly, any files opened for writing that are not specified as outputs are reported as errors.
<bobthecow>
at this rate, i should finish 3.0 some time in 2015 :P
<ddfreyne>
heh
<ddfreyne>
I know the feeling
tlevine has quit [Quit: leaving]
tlevine has joined #nanoc
<ddfreyne>
Oh huh, tup requires FUSE
<bobthecow>
oh, ugh.
<ddfreyne>
The idea is following: tup creates a fuse filesystem and mounts it to your /SOURCES/.tup/mnt, the fact that it is a fuse filesystem you can see by running "mount" tool from console.
<ddfreyne>
Inside /SOURCES/.tup/mnt tup creates @tupjob-XXX folder for every tup job. This /SOURCES/.tup/mnt/@tupjob-XXX is a loopback filesystem that maps your root directory. Thus an access to /SOURCES/.tup/mnt/@tupjob-XXX/tmp passed to kernel, then to fuse module then to tup filesystem implementation (fuse_fs.c). fuse_fs.c peels the leading part " /SOURCES/.tup/mnt/@tupjob-XXX/" and makes access to the "real" file /tmp.
<ddfreyne>
That is pretty smart.
<ddfreyne>
Actually, I've had something like that in mind as well
<ddfreyne>
But dismissed it because it was too wacky.
<ddfreyne>
It's pretty neat though... you can record what a process does (open files, but also read directory contents) and then create dependencies that way
<ddfreyne>
New file created, but is not part of a directory listign that was required before -> do not compile
<ddfreyne>
New file created, but was part of a dir listing -> compile