noax has quit [Ping timeout: 252 seconds]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
jugglinmike has quit [Quit: Leaving.]
jugglinmike has joined #nanoc
jugglinmike has quit [Quit: Leaving.]
jutah has quit [Quit: Connection closed for inactivity]
achal has joined #nanoc
relix has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
relix has joined #nanoc
VitamineD has quit [Quit: Leaving.]
VitamineD has joined #nanoc
jugglinmike has joined #nanoc
skroon has joined #nanoc
skroon has quit [Quit: Lost terminal]
skroon has joined #nanoc
<
skroon>
hi all, got disconnected :)
<
skroon>
against which version of ruby is nanoc tested?
<
number-six>
VitamineD: bobthecow (2 days ago): I'll check it out. I'm not sure I have the original anymore.
<
VitamineD>
oh nice :)
<
skroon>
VitamineD: thanks
<
skroon>
anyone here using nanoc with latest zurb-foundation?
<
francois2>
skroon, nope
<
francois2>
I use a specific sha1 on the zurb repository :/
VitamineD has quit [Ping timeout: 240 seconds]
VitamineD has joined #nanoc
VitamineD has quit [Quit: Leaving.]
noax has joined #nanoc
VitamineD has joined #nanoc
relix has joined #nanoc
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
noax has quit [Quit: Konversation terminated!]
relix has joined #nanoc
VitamineD has quit [Quit: Leaving.]
<
ddfreyne>
nanoc is compatible with 1.8.x, 1.9.x, 2.0.x and 2.1.x
<
ddfreyne>
nanoc 4.x will drop 1.8.x support
<
bobthecow>
way to take a stand.
<
bobthecow>
stopping supporting an 11 year old version :P
<
ddfreyne>
I am tempted to drop 1.9.x support too.
<
bobthecow>
yeah, osx ships with 2.0 now.
<
bobthecow>
windows is always a mess, so it's not worth losing sleep over what version they have to install.
<
bobthecow>
how's linux distro support for 2.x?
<
ddfreyne>
Not sure. Would have to investigate.
<
ddfreyne>
(I'd recommend using rvm/rbenv/chruby anyway though)
<
bobthecow>
right, but we still get a
*lot* of people who don't.
<
ddfreyne>
Yeah. I am not sure whether Ruby 2.0 really provides a lot of improvements over 1.9 that warrants Ruby 1.9.x support from being dropped
<
ddfreyne>
(kekyword arguments and laziness, mostly)
<
bobthecow>
i haven't really had reason to use either, personally.
<
bobthecow>
i'm running 2.0 for several things (including my startup) but mostly we're using it as a slightly faster 1.9 :)
<
ddfreyne>
SC uses 1.9.x mostly, and even though I'm keeping stuff compatible with 2.0 and 2.1 there is no real reason to upgrade
<
bobthecow>
our stuff ran a bit faster when we benchmarked it.
<
bobthecow>
that was good enough for me :)
<
ddfreyne>
File::FNM_EXTGLOB is nice to have in 2.0 :)
<
ddfreyne>
compile '/**/*.{md,mdown,markdown}' do … end
<
ddfreyne>
(Doesn't work in 1.9)
<
ddfreyne>
I like the idea of backporting that feature to 3.7 because it is quite small and it really helps people prepare for nanoc 4.0 packaging
<
ddfreyne>
I am not sure about the changes in bin/nanoc though. On one hand, I dislike the require 'bundler/setup' because it can cause havoc
<
ddfreyne>
OTOH, I would like only the necessary stuff to be done to implement that
<
bobthecow>
i don't really have a preference, because my rbenv binstubs handle all the bundler stuff for me :)
<
bobthecow>
agree, though, about not changing things you don't need to change.
<
bobthecow>
does require 'bundler/setup' break anything with the auto-requiring of plugins?
<
ddfreyne>
bobthecow: Not sure, probably not
<
ddfreyne>
My second-most starred repository on GitHub is something I have never finished and never released and is a big WIP.
<
ddfreyne>
Maybe I need to work on that.
<
ddfreyne>
(fast-aleck)
<
bobthecow>
i was just thinking the other day, we could totally emscripten that and make a fastaleck.js
<
bobthecow>
… i was thinking this because i have use for fastaleck.js :)
<
ddfreyne>
bobthecow: It uses a lot of pointer magic though
<
ddfreyne>
The only thing that remains to do is the -ing
<
travis-ci>
[travis-ci] nanoc/nanoc-core/master 407764a Denis Defreyne: The build passed.
VitamineD has joined #nanoc
achal has quit [Quit: Connection closed for inactivity]
VitamineD1 has joined #nanoc
VitamineD has quit [Ping timeout: 264 seconds]
relix has quit [Quit: My MacBook Pro has gone to sleep. ZZZzzz…]
<
ddfreyne>
bobthecow: Did some more work and implemented widon't
<
bobthecow>
awesome :)
<
ddfreyne>
bobthecow: Unfortunately it segfaults consistently, except in the debugger, where it consistently never segfaults
<
bobthecow>
hmm. that sucks.
<
bobthecow>
it's not very usable when it's segfaulting.
<
ddfreyne>
Before... <pre>In pre... <code>In code...</code> In pre...</pre> After...
<
ddfreyne>
expected: Before… <pre>In pre... <code>In code...</code> In pre...</pre> After…
<
ddfreyne>
actual: Before…<pre>In pre... <code>In code...</code> In pre...</pre> After…
<
ddfreyne>
interesting... hmmmm.
<
ddfreyne>
The space after the … is gone, which is sort of expected in my implementation (it's not very useful)
<
ddfreyne>
And... In pre might be okay too, I guess.
<
bobthecow>
mebbe... i kind of feel like pre is sacred though.
<
bobthecow>
ooh. you weren't kidding about the failing tests.
<
ddfreyne>
There are two reasons why the tests fail:
<
ddfreyne>
1) I haven't set proper expectations for the tokenization
<
ddfreyne>
2) works too well, heh
<
ddfreyne>
(I might disable ing selectively though)
<
bobthecow>
is the tokenization branch stable without nbsp?
<
ddfreyne>
bobthecow: Anyway, I'll deal with the segfaulting later. Maybe it works.
<
ddfreyne>
bobthecow: I merged it to master
<
ddfreyne>
So everything is master now
<
ddfreyne>
bobthecow: you can play around with this stuff. Maybe it doesn't crash for you!
<
ddfreyne>
anyway, sleep
<
bobthecow>
g'night.
<
ddfreyne>
(patcher welcome)
<
bobthecow>
i'll take a look at it when i get a minute.