Just landed on a Rails 3 app that uses haml. I am running Rspec tests and trying to print a value of a variable to console. On erb or in a any .rb file, you simply do:
p my_variable.inspect
or even string interpolation:
p "this is my variable #{my_variable}"
So when I run my Rspec tests I get a nice printout on the console evaluating my variables. So now, how you do that in Haml?
it's so annoying to "p" variables as for me, and then search their output. Use better
https://github.com/rweng/pry-rails and then in view just put
- binding.pry
and then in console you can debug variables and other stuff :)
So in Haml just use:
- p my_variable
Related
When defining a Bamboo plan variable, the page has this.
For task configuration fields, use the syntax
${bamboo.myvariablename}. For inline scripts, variables are exposed as
shell environment variables which can be accessed using the syntax
$BAMBOO_MY_VARIABLE_NAME (Linux/Mac OS X) or %BAMBOO_MY_VARIABLE_NAME%
(Windows).
However, that doesn't work in my Linux inline script. For example, I have the following defined a a plan variable
name: my_plan_var value: some_string
My inline script is simply...
PLAN_VAR=$BAMBOO_MY_PLAN_VAR
echo "Plan var: $PLAN_VAR"
and I just get a blank string.
I've tried this
PLAN_VAR=${bamboo.my_plan_var}
But I get
${bamboo.my_plan_var}: bad substitution
on the log viewer window.
Any pointers?
I tried the following and it works:
On the plan, I set my_plan_var to "it works" (w/o quotes)
In the inline script (don't forget the first line):
#/bin/sh
PLAN_VAR=$bamboo_my_plan_var
echo "testing: $PLAN_VAR"
And I got the expected result:
testing: it works
I also wanted to create a Bamboo variable and the only thing I've found to share it between scripts is with inject-variables like following:
Add to your bamboo-spec.yaml the following after your script that will create the variable:
Build:
tasks:
- script: create-bamboo-var.sh
- inject-variables:
file: bamboo-specs/vars.yaml
scope: RESULT
# namespace: plan
- script: echo ${bamboo.inject.GIT_VERSION} # just for testing
Note: Namespace defaults to inject.
In create-bamboo-var.sh create the file bamboo-specs/vars.yaml:
#!bin/bash
versionStr=$(git describe --tags --always --dirty --abbrev=4)
echo "GIT_VERSION: ${versionStr}" > ./bamboo-specs/vars.yaml
Or for multiple lines you can use:
SW_NUMBER_DIGITS=${1} # Passed as first parameter to build script
cat <<EOT > ./bamboo-specs/vars.yaml
GIT_VERSION: ${versionStr}
SW_NUMBER_APP: ${SW_NUMBER_DIGITS}
EOT
Scope can be local or result. Local means it's only available for current job and result means it can be used in subsequent stages of this plan and releases that are created from the result.
Namespace is just used to avoid naming collisions with other variables.
With the above you can use that variable in later scripts with ${bamboo.inject.GIT_VERSION}. The last script task is just to see that it is working in other scripts. You can also see the variables in the web app as build meta data.
I'm using the above script before the build (in my case compiling C-Code) takes place so I can also create a version.h file that can be used by the source code.
This is still a bit cumbersome but I'm happy with it and I hope it will help others to configure Bamboo. Bamboo documentation could be better. (Still a lot try and error)
I'm new in Go and trying to work on a project.
The structure of the code is like
handlers/
-time.go
-time_test.go
I've already tried go build, make (project) name
The thing is, I want to add some console output inside the code so that I know if a branch is covered or not (or for debugging). Right now, it doesn't work for me.
If I use:
go test -run test_file_path
If will just output
Pass 0.009s
Even I putt.Log("print log") or even fmt.Print("Say Hello") inside the test function.
If I just use go test -v test_file_path I would have undefined variables. The build & test would fail.
Any suggestions? Thanks!g
Just go test ./handlers -v. The handlers is the package path.
I am trying to get my CGI scripts running on my web host (which runs on FreeBSD). To debug why I keep getting the dreaded "premature end of script headers" error, their support recommended that I redirect all my output to stderr, rather than printing it. Looking up how to do this, I came across a very old RAMBO ticket about it, but it looks like it was never implemented.
Per some of the answers to this question, it seems like I should be able to do a call {echo Hello, world >&2} to achieve this, but it doesn't work.
How can I write to stderr in REBOL2?
For my CGI-specific scenario, I have a truly awful workaround. Since writing to stderr in Perl (with which I am entirely unfamiliar) is a one-liner, I'm currently calling the REBOL script from Perl and printing its output to stderr from there:
#!/usr/bin/perl
use strict;
use warnings;
use CGI;
# Note the backticks
my $the_string = `/home/public/rebol -csw test-reb.cgi`;
print STDERR $the_string;
This webpage has some suggestions http://www.liquidweb.com/kb/apache-error-premature-end-of-script-headers/
to solve your real problem. Perhaps you did not have the headers printed as first thing in your script, this must be the first thing to do. Maybe the rights are not sufficient, or the .r file type was not properly added in your .htaccess as cgi able file. Your (correct!) rebol core exe has not the correct rights. Or your script ends up in an endless loop?
Some hints to redirect errors for Rebol cgi script:
http://www.rebol.com/docs/core23/rebolcore-2.html#section-6.2
Better late than never... I've just implemented it for Rebol3 in my Rebol fork.
https://github.com/Oldes/Rebol-issues/issues/2468
The syntax will be probably changed a little bit, because I don't like that the system console port is named input, although it is not just for the input.
So far it is:
print 1 ;<- std_out
modify system/ports/input 'error on
print 2 ;<- std_err
modify system/ports/input 'error off
print 3 ;<- std_out
I had a script that was running locally, but it failed on Rally.
The reason it turns out is because the script contains the following line:
var regex = new RegExp("/Metrics/" + this.type + "/(\\d+)-(\\d+)");
This is so I can look for a particular string, based on this.type. Unfortunately something in the rake file changes the \\d expressions to \d, which breaks the script. This will probably break any script that relies on a double \ to escape stuff.
I was able to get around this by using [0-9] instead of \d, but it would be nice to get a more robust workaround to this nasty little gotcha.
This issue is fixed as of this commit. You can download the new rake file and rebuild your app.
This question is more out of curiosity than purpose. Can we change the output of Rspec command, where it shows dots and Fs. For example, here is an output from one of my projects:
.F.F.F.F
.....
........
Finished in 0.27137 seconds
8 examples, 4 failures
Can we get Pass Failed Pass Failed Pass Failed Pass Failed instead of .F.F.F.F
You indeed can, check out the rspec wiki or google 'rspec progressformatter' -- here's one that does something very close to what you want.
Color might help a bit - add the alias spec=spec --color --format specdoc to your ~/.bashrc file.