<ddfreyne>
I wish I could manipulate the order of compilation for testing purposes. At the moment, it is completely random...
<guardian>
how do I +1 on a pull request?
<ddfreyne>
guardian: add a comment :+1:
<ddfreyne>
It will turn in a thumbs up!
<guardian>
oh I thought most people hate doing that in pull requests and keep asking github to implement a voting system :)
<guardian>
well I have 2 questions before +1
<ddfreyne>
Shoot
<guardian>
1) it seems to me you can't request a specific rep with content_for
<guardian>
does it mean the content is captured by rep?
<ddfreyne>
1) Yeah, because captures are tied to items, not item reps.
<guardian>
ok I see
<ddfreyne>
I haven't actually thought about this, but I guess it makes sense to have it on item level... although it also makes sense to have it on item rep level.
<guardian>
so all reps will have the same :summary (if I take the example given in the doc)
<ddfreyne>
Yes
<guardian>
well yeah not sure how you would do otherwise, doing it by rep may somehow mean hairy coupling between Rules and item's content
<guardian>
2) I'm always surprised by raise Nanoc::Errors::UnmetDependency
<guardian>
since I don't know nanoc's internals well, I'm always wondering "is this exception abuse to achieve control flow?"
<guardian>
---
<guardian>
beside that, :+1:
<ddfreyne>
UnmetDependency means that the item that is currently being compiled has a dependency on another item that has not yet been compiled. Maybe it is a bit of control flow after all...
<guardian>
you say it's hacky but imho it's less hacky to set proper dependency rather than kicking the compiler yourself
<ddfreyne>
Yeah. The hacky part is "resetting" the item rep and assigning it the default content...
<ddfreyne>
The capturing helper doesn't really fit in well with the nanoc workflow, tbh. I need to rethink this for nanoc 4.0
<ddfreyne>
Technical debt ;)
<guardian>
UnmetDependency is per rep?
<ddfreyne>
Compilation happens on a rep basis. Item reps are compiled, items are not
<ddfreyne>
guardian: Can you leave a :+1: on the PR?
<ddfreyne>
I think I'm fine the way this is too
<stbuehler>
in which case would a exception not be abused to achieve control flow? (ok, yes - if you don't catch them. but then you could just have called abort() )
pavelkunc has quit [Quit: Leaving.]
<ddfreyne>
stbuehler: I was thinking about that too. I'm not sure whether this case is "control flow" or not... I think it is a bit of both. The compile_rep method expects an ideal situation (the current item has no dependencies on anything else) so given the assumptions of #compile_rep, it makes sese to think of the UnmetDependency exception as an exception situation
<ddfreyne>
stbuehler: I also think it would be (very) hard to implement this without exceptions. The dependency could be discovered while deep in Haml internals... how would you deal with that then? You need a way to break out of everything and do something else first.
<stbuehler>
i think "unmet dependencies" could be solved by a coroutine pattern :)
<ddfreyne>
(something else first == compile the other rep)
<ddfreyne>
stbuehler: That also crossed my mind.
<ddfreyne>
stbuehler: It is a possibility, but one of the first goals before tryign to use coroutines would be to make everything as stateless as possible
<ddfreyne>
Compilation is not stateless at the moment, otherwise ther would be no need to "reset" the item rep (which is pretty horrible)
<guardian>
ddfreyne: I dont't get why you need to reset the item rep and reassign default content actually
<stbuehler>
yes; any loop iterating over a container while you start a coroutine will break if you modify the container
<guardian>
item1 calls content_for(item2) <— isn't that enough to create a depencency?
<stbuehler>
so it might actually be better to stop compiling the current item, and do the dependencies first, then restart the item
<ddfreyne>
guardian: Conceptually, #compile_rep takes content[:last] and continually applies filters to it, while assigning to content[:last] on every step. So, when you compile again, it will take content[:last] but that will already be the already compiled content, instead of the raw content
<ddfreyne>
stbuehler: the exception approach is also the most readable one IMO.
<stbuehler>
yes. although i probably did never think about exception handling in any of my filters
<ddfreyne>
stbuehler: There are two things the compiler does. First, select an item to be compiled. Secondly, compile the item. With exceptions, these two things can be cleanly separated.
<ddfreyne>
An ItemRepSelector that chooses the next item rep to compile is on the nanoc 4.0 to-do list :)
<guardian>
ddfreyne: is content_for supposed to work only on the same item?
<ddfreyne>
guardian: You can use it everywhere
<guardian>
ddfreyne: like you can only call content_for(@item, :foo)?
<ddfreyne>
guardian: No, you can give any item
<guardian>
ddfreyne: ok well the item given, is there a way to figure out whether it has been compiled?
<guardian>
ddfreyne: if already compiled -> go on and get content from store, if not —> unmet dep
<ddfreyne>
guardian: The capturing helper uses if !@site.captures_store_compiled_items.include? item
<ddfreyne>
which is also a bit icky, sadly
<guardian>
can't @site.captures_store_compiled_items << item be executed inside the "set content" part of content_for
<guardian>
?
<ddfreyne>
guardian: There are two definitions of "already compiled". It could either mean that the item was not modified and the cached content was used, but in this case the captured content would not be filled in, or it could mean it was actually compiled.
<guardian>
and why the captured content isn't cached in the first place then? :) because there a third man? the capture store?
<guardian>
maybe captured content could be attached to items instead?
<ddfreyne>
guardian: Ideally, nanoc would allow one item to have multiple content parts. There would be the main content, which is the content as it exists now, but there would also be other content parts which the capturing helper could use.
<guardian>
as I said, I think I don't know nanoc's internals enough. But it seems to me that as long as you have the double definition of "already compiled" then you're obliged to reset item's reps —> which likely translates to whatever works now works —> :+1:
<ddfreyne>
That adds quite a bit of complexity though...
<ddfreyne>
yeah, the PR will remain hacky. There's no way to clean this up without breaking backwards compatibility...
<ddfreyne>
Alright
<ddfreyne>
Two things fixed in the upcoming 3.6.6 already :D
<ddfreyne>
Gemfiles will be much nicer in nanoc 4.x!
louquillio has joined #nanoc
louquillio has quit [Client Quit]
alerante has quit [Remote host closed the connection]
pavelkunc has quit [Quit: Leaving.]
pavelkunc has joined #nanoc
Ohga has joined #nanoc
<Ohga>
hello, anyone around?
louquillio has joined #nanoc
<jachymko>
Ohga, yep
<Ohga>
great. now, I'm updating my ruby install to the latest available for windows and in that process I'm trying to install the therubyracer gem in order to use less
<jachymko>
you realize this is #nanoc, right? perhaps #ruby would be a better place. i know little about ruby in general and nothing about ruby on windows :(
<Ohga>
absolutely, but it is related to the operation of nanoc so...
<Ohga>
the filter for less is in the nanoc source
<jachymko>
that's true. still, v8 on windows has little to do with nanoc, and there doesnt seem to be anyone else here right now
<Ohga>
if I check the code in taht builder.rb file I find:
<Ohga>
unless system 'which python2 2>&1 > /dev/null'
<Ohga>
fail "libv8 requires python 2 to be installed in order to build, but it is currently #{python_version}"
<Ohga>
end
<jachymko>
looks like it will build v8 itself
<jachymko>
only needs to have python2 on %PATH%
<Ohga>
two things here, of which one I just realized. which is not a command on windows. I have python on the path, but the interpretter is python.exe, not python2
<jachymko>
and question is, what will it use to build v8?
<jachymko>
you think the script is intelligent enough to use visual c++? beacuse there's no c++ compiler on vanilla windows
<Ohga>
well, currently nothing since it isn't finding python..
<jachymko>
actually, even the /dev/null redirection will fail under cmd
<Ohga>
it should use the ruby devkit for windows which I have installed, but that's just a should..
<Ohga>
yeah, you're right..
<Ohga>
so that lends the next question, why doesn't that older therubyracer-0.11.0beta1 work now..?
<jachymko>
maybe the C interface changed between ruby 1.9.x and 2.x?
<jachymko>
how is it not working?
<Ohga>
installing from that .gem file works, and then I copy the dll files to ruby/bin but when I do a nanoc compile on my site I get: http://pastebin.com/56tPzqEu
<jachymko>
it tries to load v8/init.so
<jachymko>
which would probably be called v8/init.dll
<jachymko>
on windows
<Ohga>
you think it's that simple?
<jachymko>
well, is there such dll/
<jachymko>
?
<Ohga>
no, and copying it and renaming didn't work
<Ohga>
there is a init.so though
<jachymko>
oh
<jachymko>
interesting
<jachymko>
in the C:/Ruby200/lib/ruby/gems/2.0.0/gems/therubyracer-0.11.0beta1-x86-mingw32/lib/v8 directory?
<jachymko>
doees that binary start with an MZ?
<Ohga>
yes
<Ohga>
so that's a windows compilation?
<jachymko>
yep, that's a windows dll, altough with a linux-style filename
<Ohga>
that may be of no consequence depending on how the files are found and loaded..
<jachymko>
yeah, windows shouldnt really care about the extension
<Ohga>
the psych gem have also produced a psych.so
<jachymko>
and perhaps also why it fails, if the path is correct
<Ohga>
ok.. alot of stuff in that list..
<Ohga>
(procmon)
<Ohga>
how do I filter out the cmd process?
<Ohga>
or.. where?
<jachymko>
filter for ruby, not cmd
<Ohga>
process name?
pavelkunc1 has joined #nanoc
<jachymko>
yep
<Ohga>
nothing happens for neither ruby nor nanoc
<Ohga>
ah, "begins with" worked much better
pavelkunc has quit [Ping timeout: 256 seconds]
pavelkunc has joined #nanoc
pavelkunc1 has quit [Ping timeout: 245 seconds]
<Ohga>
jachymko: after a lot of wading through the lines I can see that the init.so is accessed and opened successfully...
<jachymko>
hmm.. something else must be failing then
<jachymko>
some dependency of the init.so?
<Ohga>
mm, how can I check for that with this program?
<jachymko>
i would filter for any errors in the process that loads init.so
<Ohga>
what entry should I filter on?
<Ohga>
no, type I mean..
<Ohga>
property name.. I hope you see what I mean
<jachymko>
Result is not SUCCESs
<Ohga>
hm.. wait.. the load error is The specified module could not be found. - C:/Ruby200/lib/ruby/gems/2.0.0/gems/therubyracer-0.11.0beta1-x86-mingw32/lib/v8/init.so
<Ohga>
what if it finds init.so, but it is something missing inside init.so....
<jachymko>
yep, that's what i meant by the init.so's dependency
<jachymko>
"The specified module could not be found." is a windows message imo, so the error should be there somewhere
<Ohga>
nope, can't find that string
<jachymko>
i wouldn't search for that string, i'd press ctrl+L, select "result" in the first combo, "is" in the second, "SUCCESS" in the third, and "exclude" in the last one
<jachymko>
then run it again
<jachymko>
there has to be some file not found error
pavelkunc has quit [Quit: Leaving.]
<Ohga>
problem is, there is too many.. ruby search for the correct files and produce a bunch of file not found in the progress
<jachymko>
and if you restrict it to the therubyracer directory and perhaps the ruby/bin directory, where the strange v8.a files are?
<jachymko>
and try highlight anything that matches *.so, if the init library has a linux-style name, chances are it's dependencies have them too
<Ohga>
the filter system works against me here...
<jachymko>
:(
<Ohga>
and the app seems to have memory leaks...
<jachymko>
procmon?
<Ohga>
actualy, I found the problem. one have to disable capturing to stop filling the memory :-P
<jachymko>
:))))
<Ohga>
there is this msvcrt-ruby191.dll that it tries to find right after finding v8.dll and winmm.dll
<Ohga>
now, that one is from the ruby 1.9.3 install which is no longer on the path...
<Ohga>
not that it helped.. it finds it but fails with the same failure message
<jachymko>
:(
<jachymko>
i guess i'm out of ideas
<jachymko>
probably the easiest thing would be to install linux or freebsd into a virtualbox and be done with it
<Ohga>
well, I'm giving up for now
<jachymko>
ruby + v8 + windows = lots of moving parts :/