Im using latest version of Guard and Guard-Haml. I have 7 maps in my root dir where i store Haml files in two different directories. One is in /templates/haml and one is in /haml. The total sum of the haml files is less than 10.
In the other 5 maps I have about 17 000 files. I have configured guard to only watch in the /haml and /templates/haml maps for change. It works fine just after I started with bundle exec guard, but after a while it gets slow as hell. About 30 seconds from where I make a change to a file does it take it to recompile the file.
This is my Guardfile
require 'haml/helpers'
require 'haml/filters'
require 'haml/filters/php'
guard :haml, input: 'www/templates/haml', output: 'www/templates', :haml_options => { :escape_attrs => false } do
watch %r{^www/templates/haml/.+(\.haml)$}
end
guard :haml, input: 'www/haml', output: 'www/', :haml_options => { :escape_attrs => false } do
watch %r{^www/haml/.+(\.haml)$}
end
Is there anything I can do to speed this up because its really slowing my dev. down.
I found out that I could use the ignore command and ignore out all directories I didn't want guard to look at.
Example:
ignore([%r{^node_modules/*}])
Link to more details about this
You can only watch those two folders when you start guard:
bundle exec guard --watchdir www/templates/haml www/haml
Related
I'm experiencing an issue wherein awesome_print is not displaying output in it's gorgeous colorized multiline format. What I find most curious is that while the gem is installed:
$ gem install awesome_print
Successfully installed awesome_print-1.6.1
1 gem installed
It returns a false upon require in IRB:
>> require 'awesome_print'
false
Any idea as to what may be causing this? I am not quite sure how to tackle this since gem installation seems to work fine and I can even use ap "test" in IRB with no error, except there is no colorization or proper printing with multiple lines and seems to simply fall back to some other method for printing.
No ~/.aprc changes evoke any changes either.
Pass the options ap object, options = {:plain => false, :multiline => true} or you can add it to the config file.
create an ~/.irbc file with the following content
require "awesome_print"
AwesomePrint.irb!
:multiline => true, # Display in multiple lines.
:plain => false
I had the same error,although require was returning false but awesome print was working, try to print something using awesome_print(ap), like
ap data = {foo: "bar"}
Is guard-haml still in development and use? The last commit seems to have been 5 months ago (not including updates to the README). I'm trying to get a simple input / output configuration working. However, the input directory always gets prefixed to the output location.
Ie "resources/templ/documents/one.haml" gets compiled to "resources/public/resources/templ/documents/one.html". But all I really want is "resources/public/one.html". So for example, this configuration...
guard :haml, input: 'resources/templ/documents/' , output: 'resources/public/' do
watch(%r{resources/templ/documents/.+\.(haml)$})
end
produces the incorrect output.
07:30:28 - INFO - Successfully compiled haml to html!
> [#] # resources/templ/documents/one.haml -> resources/public/resources/templ/documents/one.html
And these configurations produce nothing.
guard :haml do
watch(/^.+(\.html\.haml)$/)
end
guard :haml, input: 'resources/templ/documents/' , output: 'resources/public/' do
watch(/^resources\/templ\/documents\/+(\.html\.haml)$/)
end
group :main do
guard :haml, input: 'resources/templ/documents/' , output: 'resources/public/' do
watch(/^resources\/templ\/documents\/+(\.html\.haml)$/)
end
end
Am I missing a proper configuration? Or is guard-haml (Using guard-haml (1.1.0)) just buggy? Any insights appreciated.
FYI. I just solved this by having a simple one line configuration, without watchers. The watchers must be screwing things up.
guard 'haml', :input => 'resources/templ/documents', :output => 'resources/public'
Hth
Ruby noob - I need to have guard running in my rake tasks but I can't find a way to have it run in the background. It needs to run 2nd last, therefore having the guard > shell waiting for commands is preventing the final task from running, so calling sh bundle exec guard in the rake file is not an option. According to the documentation this should work:
##
desc "Watch files"
##
task :watcher do
Guard.setup
Guard::Dsl.evaluate_guardfile(:guardfile => 'Guardfile', :group => ['Frontend'])
Guard.guards('copy').run_all
end
#end watch files
https://github.com/guard/guard/wiki/Use-Guard-programmatically-cookbook
Here is my Guardfile, in full, (in same dir as Rakefile)
# Any files created or modified in the 'source' directory
# will be copied to the 'target' directory. Update the
# guard as appropriate for your needs.
guard :copy, :from => 'src', :to => 'dist',
:mkpath => true, :verbose => true
But rake watcher returns an error:
07:02:31 - INFO - Using Guardfile at Guardfile.
07:02:31 - ERROR - Guard::Copy - cannot copy, no valid :to directories
rake aborted!
uncaught throw :task_has_failed
I have tried different hacks, too many to mention here, but all have returned the above Guard::copy - cannot copy, no valid :to directories. The dist directory definitely exists. Also if I call guard from the shell, inside rake or on cmd line, then it runs perfect, but leaves me with the guard > shell. Think my issue maybe a syntax error in the rake file? any help appreciated ;)
Guard Copy does some initialization in the #start method, so you need to start the Guard before you can run it:
task :watcher do
Guard.setup
copy = Guard.guards('copy')
copy.start
copy.run_all
end
In addition there's no need to call Guard::Dsl.evaluate_guardfile anymore, that info on the wiki is outdated.
Edit 1: Keep watching
When you want to watch the dir, then you need to start Guard:
task :watcher do
Guard.start
copy = Guard.guards('copy')
copy.start
copy.run_all
end
Note: If you setup Guard and start it afterwards, then Guard fails with Hook with name 'load_guard_rc'
Edit 2: Really keep watching
Guard starts Listen in non blocking mode, so in order to make the call blocking, you need to wait for it:
task :watcher do
Guard.start
copy = Guard.guards('copy')
copy.start
copy.run_all
while ::Guard.running do
sleep 0.5
end
end
If you also want to disable interactions, you can pass the no_interactions option:
Guard.start({ no_interactions: true })
The API is absolutely not optimal and I'll improve it for Guard 2 when we remove Ruby 1.8.7 support and some deprecated stuff.
I've one file, main.rb with the following content:
require "tokenizer.rb"
The tokenizer.rb file is in the same directory and its content is:
class Tokenizer
def self.tokenize(string)
return string.split(" ")
end
end
If i try to run main.rb I get the following error:
C:\Documents and Settings\my\src\folder>ruby main.rb
C:/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require': cannot load such file -- tokenizer.rb (LoadError)
from C:/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `require '
from main.rb:1:in `<main>'
I just noticed that if I use load instead of require everything works fine. What may the problem be here?
I just tried and it works with require "./tokenizer".
Just do this:
require_relative 'tokenizer'
If you put this in a Ruby file that is in the same directory as tokenizer.rb, it will work fine no matter what your current working directory (CWD) is.
Explanation of why this is the best way
The other answers claim you should use require './tokenizer', but that is the wrong answer, because it will only work if you run your Ruby process in the same directory that tokenizer.rb is in. Pretty much the only reason to consider using require like that would be if you need to support Ruby 1.8, which doesn't have require_relative.
The require './tokenizer' answer might work for you today, but it unnecessarily limits the ways in which you can run your Ruby code. Tomorrow, if you want to move your files to a different directory, or just want to start your Ruby process from a different directory, you'll have to rethink all of those require statements.
Using require to access files that are on the load path is a fine thing and Ruby gems do it all the time. But you shouldn't start the argument to require with a . unless you are doing something very special and know what you are doing.
When you write code that makes assumptions about its environment, you should think carefully about what assumptions to make. In this case, there are up to three different ways to require the tokenizer file, and each makes a different assumption:
require_relative 'path/to/tokenizer': Assumes that the relative path between the two Ruby source files will stay the same.
require 'path/to/tokenizer': Assumes that path/to/tokenizer is inside one of the directories on the load path ($LOAD_PATH). This generally requires extra setup, since you have to add something to the load path.
require './path/to/tokenizer': Assumes that the relative path from the Ruby process's current working directory to tokenizer.rb is going to stay the same.
I think that for most people and most situations, the assumptions made in options #1 and #2 are more likely to hold true over time.
Ruby 1.9 has removed the current directory from the load path, and so you will need to do a relative require on this file, as David Grayson says:
require_relative 'tokenizer'
There's no need to suffix it with .rb, as Ruby's smart enough to know that's what you mean anyway.
require loads a file from the $LOAD_PATH. If you want to require a file relative to the currently executing file instead of from the $LOAD_PATH, use require_relative.
I would recommend,
load './tokenizer.rb'
Given, that you know the file is in the same working directory.
If you're trying to require it relative to the file, you can use
require_relative 'tokenizer'
I hope this helps.
Another nice little method is to include the current directory in your load path with
$:.unshift('.')
You could push it onto the $: ($LOAD_PATH) array but unshift will force it to load your current working directory before the rest of the load path.
Once you've added your current directory in your load path you don't need to keep specifying
require './tokenizer'
and can just go back to using
require 'tokenizer'
This will work nicely if it is in a gem lib directory and this is the tokenizer.rb
require_relative 'tokenizer/main'
For those who are absolutely sure their relative path is correct, my problem was that my files did not have the .rb extension! (Even though I used RubyMine to create the files and selected that they were Ruby files on creation.)
Double check the file extensions on your file!
What about including the current directory in the search path?
ruby -I. main.rb
I used jruby-1.7.4 to compile my ruby code.
require 'roman-numerals.rb'
is the code which threw the below error.
LoadError: no such file to load -- roman-numerals
require at org/jruby/RubyKernel.java:1054
require at /Users/amanoharan/.rvm/rubies/jruby-1.7.4/lib/ruby/shared/rubygems/custom_require.rb:36
(root) at /Users/amanoharan/Documents/Aptana Studio 3 Workspace/RubyApplication/RubyApplication1/Ruby2.rb:2
I removed rb from require and gave
require 'roman-numerals'
It worked fine.
The problem is that require does not load from the current directory. This is what I thought, too but then I found this thread. For example I tried the following code:
irb> f = File.new('blabla.rb')
=> #<File:blabla.rb>
irb> f.read
=> "class Tokenizer\n def self.tokenize(string)\n return string.split(
\" \")\n end\nend\n"
irb> require f
LoadError: cannot load such file -- blabla.rb
from D:/dev/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `req
uire'
from D:/dev/Ruby193/lib/ruby/1.9.1/rubygems/custom_require.rb:36:in `req
uire'
from (irb):24
from D:/dev/Ruby193/bin/irb:12:in `<main>'
As it can be seen it read the file ok, but I could not require it (the path was not recognized). and here goes code that works:
irb f = File.new('D://blabla.rb')
=> #<File:D://blabla.rb>
irb f.read
=> "class Tokenizer\n def self.tokenize(string)\n return string.split(
\" \")\n end\nend\n"
irb> require f
=> true
As you can see if you specify the full path the file loads correctly.
First :
$ sudo gem install colored2
And,you should input your password
Then :
$ sudo gem update --system
Appear
Updating rubygems-update
ERROR: While executing gem ... (OpenSSL::SSL::SSLError)
hostname "gems.ruby-china.org" does not match the server certificate
Then:
$ rvm -v
$ rvm get head
Last
What language do you want to use?? [ Swift / ObjC ]
ObjC
Would you like to include a demo application with your library? [ Yes / No ]
Yes
Which testing frameworks will you use? [ Specta / Kiwi / None ]
None
Would you like to do view based testing? [ Yes / No ]
No
What is your class prefix?
XMG
Running pod install on your new library.
you need to give the path.
Atleast you should give the path from the current directory. It will work for sure.
./filename
I'd like to split my seeds.rb file into multiple sections for ease of maintenance; seed all the A's in a.rb, the B's in b.rb, etc. The separate files are located in the db/ directory with seeds.rb. Each file consists of a bunch of "A.create" or "B.create" calls and I want to call those files from seeds.rb.
I've tried:
include 'a'
include 'b'
and
load 'a.rb'
load 'b.rb'
in my seeds.rb but they don't seem to be processed when I call "rake db:seed". This is probably more of a straight ruby question than a rails question but for completeness I'm using Ruby 1.9.2 and Rails 3 on a Mac.
In ./db/seeds/my_module.rb:
module MyModule
puts "In my_module.rb"
# add code here
end
In ./db/seeds.rb:
require File.expand_path('../seeds/my_module', __FILE__) # the ../ just removes `seeds.rb` filename from the path which is given by __FILE__
p "In seeds.rb"
# add code here
I would propose to create a new db/seeds/ directory where you can place your various seeds file:
db/seeds/01_stuff_that_comes_for_first.rb
db/seeds/02_stuff_that_comes_for_second.rb
...
And then edit your db/seeds.rb file with:
Dir[File.join(Rails.root, 'db', 'seeds', '*.rb')].sort.each { |seed| load seed }
So, you can load your seeds even in the order you prefer - that is often something requested.
This solution was originally proposed by nathanvda in this "duplicated" question.