SASS Syntax Error: Properties aren't allowed at the root of a document - sass

I am using SASS and it has been working, but now I get this...
Syntax error on line 1: Properties aren't allowed at the root of a document.
My file is using variables in the SASS format.
$blue-muted: #222244
$red-muted: #442222
$green-muted: #224422
When I remove the variables (and replace the values with the actual colors), it compiles fine. What is wrong here?
EDIT: My confusion stemmed from having installed HAML 3.0, but getting behavior consistent with an early 2.0 version. It turned out that I had a SASS command line tool from an old version in my path and it was running instead of the current version.

Looks like you are using the new SCSS syntax which should look like:
$blue-muted: #222244;
if you want to use sass, the colors should be declared as:
!blue-muted = #222244

Related

Sublime Text 3: How to configure rubocop.yml path in sublime settings?

I have installed rubocop package for sublime text 3. I am trying to set custom rubocop configuration by providing rubocop.yml path to Rubocop.sublime-settings. Please find my configuration-snippet
"rubocop_config_file": "./.rubocop.yml"
However rubocop does not work when I give this configuration. It only works for
"rubocop_config_file": ""
How can i fix this and provide the path of my rubocop.yml to rubocop?
After some prodding, I found this :
By default, the linter plugin looks for a config file called
.rubocop.yml in the current directory and its parents
- https://github.com/SublimeLinter/SublimeLinter-rubocop
Even though I am not using the linter-plugin, I figured rubocop does the same. So by placing the .rubocop.yml in the current directory or any of its parents, I was able to get my .rubcop.yml file to be picked by rubocop. On a side note, I did not update configuration of the rubocop package, it automatically picks the .rubocop.yml.
Other settings in this Rubocop.sublime-settings seem to use a complete path.
So instead of using the dot to start at the folder where the Rubocop.sublime-settings file is located use a full path like the examples for other Rubocop.sublime-settings configurations.
Hope this helps

Warning thrown by script

I have written a script to update a table by passing the parameters to the script. It appears to run just fine but throws the following warnings upon execution :
*** Warning:
Problem resolving parameter "ORACLE_CLIENT_VERSION" of "/abinitio/apps30/ste-uat/CitiTech/stdenv/.project.pset":
Parameter:`ORACLE_CLIENT_VERSION' referenced before being defined in pset:`/abinitio/apps30/ste-uat/CitiTech/stdenv/.sandbox.pset'.
Can anyone tell me why these warnings are displayed or how to suppress/hide these warnings ??
I'm not sure but such a variable ("ORACLE_CLIENT_VERSION") is defined in ruby apps. For example, look here at the config.rb file.
If I were you, I would make just a search in your project for such a config file, and define the ORACLE_CLIENT_VERSION there.

Custom templates with phpDocumentor 2

I've been trying to get a custom template to work with PHPDocumentor (2) without much luck. The documentation on their site is incomplete and I'm kind of stumped.
What I've done is downloaded a copy of a complete template and reference it in my command, like so:
php phpdoc.php
--template=/path/to/customtemplate/
-d /path/to/php/source/files
-t /path/to/generated/content/
The command runs fine: it generates the documentation correctly but appears to be ignoring the --template option - at least, any changes I make to the template files in the /customtemplate folder are ignored.
Anyone have any idea?
(Thanks in advance!)
Ben
Instead of declaring the template command on the CLI you might try changing your phpdoc.dist.xml configuration file so that it pulls the template name or path from there directly.

symfony2 assetics yui compressor on windows (path syntax)

I'm trying to get assetics running with the yui compressor and, if this is running, sass. Right now, both don't work. When removing all filters from config.yml and the twig template, it works and php app/console assetic:dump does copy the css and js files.
Now I want to add the yui compressor and my config.yml looks like this:
assetic:
debug: %kernel.debug%
use_controller: false
filters:
yui_js:
jar: %kernel.root_dir%/Resources/java/yuicompressor-2.4.6.jar
Adding the filter to the template and running assetic:dump again ends in the following error (translation of message by me):
[RuntimeException]
The syntax for filename, directory name or drive name is wrong
I found an article telling me to specify the path to java.exe, so I add this to config.yml:
assetic:
..
java: C:/Program Files (x86)/Java/jre6/bin/java.exe
..
Now assetic:dump tells me:
[RuntimeException]
The COMMAND "C:/Program" is either written wrong or
I tried playing around with both variables (using \ or \ instead of /, adding single or double quotes, working with short alias Progra~1 or Progra~2) in the config, but I didn't get anywhere. The both errors comming up all the time. Maybe someone can point me in the right direction.
Ok, I figured it out. Man, this one was brutal.
Let's start with the easy stuff. A working version of the config.yml can look like this:
assetic:
debug: false
use_controller: false
java: C:\Program Files (x86)\Java\jre6\bin\java.exe
sass: C:\Program Files (x86)\Ruby192\bin\sass.bat
filters:
scss: ~
yui_js:
jar: %kernel.root_dir%\Resources\java\yuicompressor-2.4.6.jar
For some reason, assetic is always importing a whole directory for scss, so I had to make a combine.scss which imports the other scss files in the correct order.
And now it gets ugly, as one have to change the assetics core in order to get this working. The developers of assetic know this bug and I think it is fixed in some development trunk/branch but not the stable one.
The Assetic\Util\ProcessBuilder has to be changed on line 95
if (defined('PHP_WINDOWS_VERSION_MAJOR')) {
,line 103
$script .= ' '.implode(' ', array_map('escapeshellarg', $args));
and line 110
return new Process($script, $this->cwd, null, $this->stdin, $this->timeout, $options);
I hope this bug get fixed soon and till then anybody trying to get it working finds this thread... Took me like 8 hours of debuging, reading and trying different approaches.
Answer by Boo Nov 19 at 22:53 did work for me by changing everything he mentioned in Assetic\Util\ProcessBuilder (I ignored line 95 as it looks the same as in my file)
Now it works on windows. Thanks!
Just to confirm. Im using Symfony 2.0.7 and yuicompressor-2.4.7
For other users who use window server 2008 r2 :
Maybe you should change the C:\windows\Temp folder property to 777 (read/write) for the IIS user / or the machine's normal user
please unpack the ruby.7z from rubyinstaller.org , and go to C:\_ruby193\bin , in this unpack position you should exec the CMD prompt , type :
ruby -S gem install sass
so that you will get the sass.bat in that position
It's time to use Boo's best answer , and please notice that in symfony2 dev env maybe it's not necessary to change the use_controller to false (in the config.yml) , because there's another use_controller in the config_dev.yml (set to true) , and in routing_dev.yml there's also a _assetic router , they're perhaps associated.

phpDocumentor on legacy code

Can phpDocumentor be used to generate HTML docs for some legacy code that does not necessarily conform to its standard?
I'd like to generate some preliminary documentation for an old code tree and later on start improving my comments and add the appropriate # tags as I get fluent with phpDocumentor. I've never used this piece of software before and the examples I've found focus on how to write new code that conforms to its syntax and generate HTML file by file with the -f parameter.
I've installed latest phpDocumentor through the PEAR command line installer and tried this little *.bat file on Windows XP:
#echo off
phpdoc ^
--directory "\\server\project\trunk" ^
--target "C:\tests\project-doc"
... but this is all I get:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
directory: '' not found
I've also tried mapping the UNC path to a drive letter:
#echo off
phpdoc ^
--directory "I:\" ^
--target "C:\tests\project-doc"
... but:
PHP Version 5.3.5
phpDocumentor version 1.4.3
Parsing configuration file phpDocumentor.ini...
(found in C:\Archivos de programa\PHP\pear\data/PhpDocumentor/)...
done
Maximum memory usage set at 256M after considering php.ini...
using tokenizer Parser
a target directory must be specified
try phpdoc -h
This error message is the same if I create "C:\tests\project-doc" before.
What's exactly wrong in my syntax?
phpDocumentor can indeed run against "undocumented" code. It builds its docs based on the code itself, and uses the docblocks as additional info (and additional organization, in the case of #package and #subpackage tags).
I'd suggest starting with phpDocumentor against your existing code, and work towards clearing out the warnings you see in the errors.html file that results -- this file is generated in the top level of your output docs, but there isn't any link to it from the output docs.
Once you have those cleared, you can start running phpDocumentor with the -ue argument (--undocumentedelements), which will add new warnings to errors.html, highlighting (in much greater detail) things that still need to be documented in docblocks.
Now, as for the issue you're having trying to run the program against code on a shared drive, I'm not sure what's wrong there. The script is clearly able to execute PHP and find the phpDocumentor code itself. You might try putting the arguments in the same line, rather than using the ^ as a line-feed escape character, and perhaps remove the quotes around the paths (since no spaces exist in the paths).
I think I've found what the issue is. The parameter parser is very picky and it doesn't like neither UNC paths nor bare root directories. If I replace this:
--directory "I:\"
... with this:
--directory "I:\."
... it finally starts running.
I suppose it's a bug. Their bug tracker doesn't seem to be public so I don't know if it's a known issue.

Resources