I'm building a site with Nanoc and have one file (with it's own layout file) that reads all other files metadata, does some magic and saves the file. Unfortunately, this process takes a long time and developing other views with autocompile is taking ages. Is it possible to add some files to ignore list that won't be enqueued to compilation (and during compilation to production remove them from ignores)? Or are there other methods to achieve this?
To the best of my knowledge, nanoc will always read all data from your contents directory. You can remove files from further processing by implementing a preprocess method which removes some generated items entries... e.g. in Rules:
preprocess do
skip_unimportant_items
end
In a .rb file in lib/:
def skip_unimportant_items
#items.delete_if { |i| !i[:important] }
end
This will remove all items which have no important element (or the element set to false) in their respective metadata.
Did you tried the Nanoc Doc recommendation:
ignore '/assets/layouts/your_files/*/'
http://nanoc.ws/doc/rules/
Related
I am working on a game and am trying to output the names of save files from their directory using Dir.glob (if there's a better way to do this, I'm absolutely not attached to that particular function)
I tried using information from various answers on here, but it still isn't outputting any file names to the console.
The file name generator
file = File.new("Saves\\" + "#{char.name}" + ".sav", 'w')
that's working fine, just wanted to have it in case it has something to do with the file extension.
and the current iteration of the output writer.
Dir.glob("/Saves/*") do |file|
puts file.basename()
end
I'm not sure if it should be working per say, but I've tried several different versions that, in theory should be outputting a list.
It outputs a blank line (which also end the program at the moment) even though there are 3 files currently in the directory.
per a comment (but not answer) from cremno, changing the "/Saves/" to simply "Saves/" fixed it.
Given an HTML page, is there a way to automatically insert <script> and <style> tags into it from a directory? I'm basically trying to build a 'style guide' of sorts, and the main HTML page needs to dynamically reference every JS/CSS file that developers will add to a directory, and there will be many.
To put it quite bluntly, I'm looking for a gem equivalent of the node grunt-include-source module. This is because I've already got a Rakefile invoking certain gems, I'd like to keep it consistent if possible/reasonable.
You can look up the names of each file in a directory with a foreach function and put them in an array(for example x). then in another foreach function for as many strings in the array and do
include: x[I]
then you do
I++
so you will get the next string in the array.
Like this the foreach function will include every file in the directory.
I know it isnt the best way but it worked for me.
I'be been trying to write a bit of code that iterates through every excel file in one directory, and convert excel workbooks to individual sheets to CSV files. I'm quite new to both ruby and coding in general, so I've no idea if my solution is the best method. The problem I am having is the Dir.foreach doesn't seem to iterate correctly, instead returning "C:\gernericfolder\." This then causes the next win32ole code block a whole tonne of problems.
This is my code:
require 'rubygems'
require 'iconv'
require 'win32ole'
require 'csv'
require 'roo'
begin
puts("=================================================================================================================================")
inputFolder = ARGV[0]
outputFolder = ARGV[1]
#Check if the file actually exists + UI Feedback
if File.exists?(inputFolder) == false
puts("IGM: DIRECTORY NOT FOUND. Please check your path exists\n")
Process.exit
end
Dir.foreach(inputFolder) { |nextFile|
#Form the file path and open the file
filePath = "#{inputFolder}\\#{nextFile}"
puts("Next file = #{filePath}")
xl = WIN32OLE.new('excel.application')
book = xl.workbooks.open(filePath)
xl.displayalerts = false
end
end
I've been getting one showstopper problem using EXCEL via win32ole with Ruby 1.9.3/WATIR Classic: I get an intermittent Security error - "Watir::Exception::FrameAccessDeniedException IE will not allow access to this frame for security reasons. You can work around this with browser.goto(frame.src)".
The control this often happens with, but not all the time, is a IFRAME JavaScript link under Internet Explorer 10. I found a work-around that eliminates the issue if I assign the page URL to the list of trusted sites. But because I had to uncheck the HTTPS: checkbox to allow HTTP: URLs, it is unacceptable security practices and I got my wrist virtually slapped.
Our architect says it should be consistent if it's really a Security error. He ran tests which convinced him that the issue is not with Security but rather with using EXCEL and some related process: He eliminated EXCEL, which I was using to pass different UserIDs and Passwords to the Watir script. Once he eliminated EXCEL from the picture, the error no longer happened. Here's how he did it: He ran the first iteration of the script over and over in a batch file that clicked on the frame/link in question the same number of times that the EXCEL table was driving it, and the problem no longer happened. Now I have to use EXCEL some other way beside the win32ole, or go to using .CSV files, which I don't really look forward to because I lose track of how many commas I'm counting.
One solution to your problem, however primitive, is to manually copy and paste the EXCEL data into the .CSV tables.
Another possibility is a suggestion from a colleague: Use EXCEL via the "Ruby Gem Spreadsheet". She is using that and has not had any issues, although I'm pretty sure she isn't using IFRAMES with JavaScript hyperlinks on web pages written in .NET C#. Her app is written in JAVA. But I will look into that option.
Dir.foreach iterates through directory entries, not exactly files. That means, it returns such entries as . (this directory) and .. (parent directory) among others. That's what you get: your nextFile is ..
The best way to quickly solve is is probably to switch from Dir.foreach to Dir.glob or Dir[]. That is, replace
Dir.foreach(inputFolder) { |nextFile|
#Form the file path and open the file
filePath = "#{inputFolder}\\#{nextFile}"
puts("Next file = #{filePath}")
with
Dir.glob(inputFolder+'\**') { |filePath|
puts("Next file = #{filePath}")
I am rebuilding a site with docpad and it's very liberating to form a folders structure that makes sense with my workflow of content-creation, but I'm running into a problem with docpad's hard-division of content-to-be-rendered vs 'static'-content.
Docpad recommends that you put things like images in /files instead of /documents, and the documentation makes it sound as if otherwise there will be some processing overhead incurred.
First, I'd like an explanation if anyone has it of why a file with a
single extension (therefore no rendering) and no YAML front-matter,
such as a .jpg, would impact site-regeneration time when placed
within /documents.
Second, the real issue: is there a way, if it does indeed create a
performance hit, to mitigate it? For example, to specify an 'ignore'
list with regex, etc...
My use case
I would like to do this for posts and their associated images to make authoring a post more natural. I can easily see the images I have to work with and all the related files are in one place.
I also am doing this for an artwork I am displaying. In this case it's an even stronger use case, as the only data in my html.eco file is yaml front matter of various meta data, my layout automatically generates the gallery from all the attached images located in a folder of the same-name as the post. I can match the relative output path folder in my /files directory but it's error prone, because you're in one folder (src/files/artworks/) when creating the folder of images and another (src/documents/artworks/) when creating the html file -- typos are far more likely (as you can't ever see the folder and the html file side by side)...
Even without justifying a use case I can't see why docpad should be putting forth such a hard division. A performance consideration should not be passed on to the end user like that if it can be avoided in any way; since with docpad I am likely to be managing my blog through the file system I ought to have full control over that structure and certainly don't want my content divided up based on some framework limitation or performance concern instead of based on logical content divisions.
I think the key is the line about "metadata".Even though a file does NOT have a double extension, it can still have metadata at the top of the file which needs to be scanned and read. The double extension really just tells docpad to convert the file from one format and output it as another. If I create a straight html file in the document folder I can still include the metadata header in the form:
---
tags: ['tag1','tag2','tag3']
title: 'Some title'
---
When the file is copied to the out directory, this metadata will be removed. If I do the same thing to a html file in the files directory, the file will be copied to the out directory with the metadata header intact. So, the answer to your question is that even though your file has a single extension and is not "rendered" as such, it still needs to be opened and processed.
The point you make, however, is a good one. Keeping images and documents together. I can see a good argument for excluding certain file extensions (like image files) from being processed. Or perhaps, only including certain file extensions.
I'm developing a plugin in Jekyll that inserts a new Liquid Tag (a block tag) named latex. It's purpose is to insert a block of LaTeX source code inside a post source file this way:
... post file contents ...
{% latex density=300 usepackages=pstricks-all, %}
\pspicture(5,5)
\psframe(0,0)(5,5) \psline(0,0)(5,5) \psline(0,5)(5,0)
\endpspicture
{% endlatex %}
... post file contents ...
The output post will contain a <img> tag instead of the Liquid Tag block once compiled and the LaTeX source will be compiled by a chained execution of latex, dvips, convert. So it will depend on external programs (TexLive and ImageMagick).
I've not found any issue with the explained so far. I can take the block of LaTeX, put it in a temporary file, and finally compile it to PNG. The rendered files must be put in the same folder of the post.
But just there I'm stuck: I want to put the generated PNG image to this folder inside the destination output folder. No problem defining a site-config variable to define the folder (in fact, I do that), nor put a file there. The problem is simple: I can write to the source folder, but the generated files will not be copied to the destination folder.
I know the reason: Jekyll generates first and renders afterwards. The copy process happens before the render part, so the generated files will not be copied.
I've found this SO entry: "How to generate files from Liquid blocks in Jekyll?", but the answer doesn't feel right: You must make a two-pass build for the files to be copied.
Also found "Generate file inside _site with Jekyll plugin", but this is not applicable because I don't want to render documents by templates.
The solution I've been planning is this:
Keep a folder with all the generated files and some index strategy for their final placement.
Implement a Sitewide method for the final placement procedure, something like:
class Site
def generate_latex_adds
// Code that copies the generated files to destination folders
end
end
Add self.generate_latex_adds calling that method inside the site_process.rb script just before the self.cleanup and self.write calls.
This will probably solve the problem, but I feel wrong to modify the site_process.rb. I'm considering pull this Liquid Tag to the community as a GitHub project, and as such, I must document this manual edit of site_process.rb to the users of this plugin. I know it's probably a common situation and a common solution, but I wonder if there is a better way to pospone the copy of the generated files without modifying core files. I'd like to keep the plugin simple: just copy the plugin file to the _plugins directory.
Any ideas?
EDIT: I'm more interested in the reasoning that on the actual code. I want to learn, not asking for a code solution.
As anyone has answered my question up to now, and I had kept investigating the issue. Finally I've got an elegant solution: use the Jekyll::StaticFile class. I have missed that class (sidenote: Read more carefully the docs).
When you add one object of this class to the site.static_files array, you are marking this file as pending for copy after the render process is completed. In fact, the copy of such files is done in the site.write process. Take a look at the site_process.rb file in your Jekyll installation.
The usage of this class is easy. When you need to mark a file for future copy, you simply execute a code like this:
site.static_files << Jekyll::StaticFile.new(site, site.source, path, filename)
Where path and filename depends on the location of your file in the src folder.
And that's all: You generate the files in the src folder, mark them as pending for copy and let Jekyll do the rest. No modification of site_process.rb at all!
You can take a look at the resulting LaTeX -> PNG liquid tag code at GitHub: https://github.com/fgalindo/jekyll-liquid-latex-plugin
I've also implemented a cleanup method there to eliminate orphaned generated files from posts that have been modified and rebuilt.