Escaping text with SASS? - sass

I'm running into an issue of which I think is due to the way SASS (SCSS in my case) compiles. I'm trying to get this code to compile: (it's a very hacky way to simulate :before and :after pseudo elements in IE6/7)
.x-tool-collapse-top {
*zoom: expression(
this.runtimeStyle.zoom="1",
this.appendChild( document.createElement("small") ).className="after",
this.insertBefore( document.createElement("small"), this.firstChild ).className="before"
);
}
.x-tool-collapse-top .after,
.x-tool-collapse-top:after {
#include extjsimagereplace;
content: '\e6be';
*zoom: expression(this.runtimeStyle['zoom'] = '1', this.innerHTML = '');
}
But it's choking. It's likely due to the , and ( which aren't valid, but I'm not finding anything to just say SASS: just leave this alone and don't try and compile it.

Related

Mocha test failing using babel and webpack

So I am using webpack, babel, and mocha here. When I have code like this:
import userImage from '../../images/user.png';
and I build with webpack, userImage results in a string to the path of the file since I am using the file loader for images (requirements call for me not to embed images) however when I try to run my mocha tests using:
./node_modules/.bin/babel-node ./node_modules/.bin/babel-istanbul cover ./node_modules/.bin/_mocha
I get a syntax error:
SyntaxError: /repositories/react-seed/web/app/images/user.png: Unexpected character '�' (1:0)
> 1 | �PNG
| ^
2 |
3 |
I also get this error when removing istanbul. So it seems like it is trying to load the actually image file however can parse it as JavaScript since it is not.
Anyone know a way around this issue?
You can use the --compilers option which allows you to customize the nodejs require system in order to let it understand png files. So :
mocha --compilers png:./mochacfg.js
Or create a file 'test/mocha.opts' containing (better for your needs):
--compilers png:./mochacfg.js
With ./mochacfg.js:
require.extensions['.png'] = function(){ return null; }
This ignores png files (should be ok if you do nothing special with them).
If you want to do something with the image data:
var fs = require('fs');
require.extensions['.png'] = function(module, filepath) {
var src = fs.readFileSync(filepath).toString ('base64');
return module._compile('module.exports = "data:image/png;base64,' + src + '";');
}
Its quite late to answer this question but just for knowledge sharing purpose, I am answering another approach to do this.
Create a test-config.js file and use it while running the mocha test cases.
var jsdom = require('jsdom').jsdom;
process.env.NODE_ENV = 'test';
// -------------------------------
// Disable webpack-specific features for tests since
// Mocha doesn't know what to do with them.
['.css', '.scss', '.png', '.jpg'].forEach(ext => {
require.extensions[ext] = () => null;
});
and inside package.json use this test command to run the test cases
"test": "mocha ./test/test-setup.js './test/**/*.spec.js' --compilers js:babel-core/register",
I hope it helps someone.

Docpad: confused about extending template data

I'm totally confused about adding mongo data to template data. I haven't even started trying to get the data from a database as I can't get my templates to see test data (see below). This is in docpad.coffee for the moment, but ultimately g will be the output of mongoDB.
events:
extendTemplateData: (opts) ->
# {templateData} = opts
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
opts.templateData["getGigsData"] = getGigsData
And I hope to access it with <%= #getGigsData().date %>
Thanks so much for some guidance
I should add that this design is based on wanting to make it easy for the band to add gigs, without letting them edit the page content itself as I fear they would mess up the markup - if there are other ways to achieve this goal, I'd be pleased to hear.
Tried this locally. And hit the issue:
debug: Emitting the event: extendTemplateData
→ [2014-02-14 01:38:50.030] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:1184] [DocPad.emitSerial]
error: Something went wrong with the action
→ [2014-02-14 01:38:50.037] [/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/interfaces/console.js:107] [ConsoleInterface.destroyWithError]
error: An error occured:
ReferenceError: getGigsData is not defined
at Object.docpadConfig.events.extendTemplateData (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/docpad.coffee:42:44)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:25:27)
at DocPad.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/out/lib/docpad.js:995:25)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at Task.<anonymous> (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/event-emitter-grouped/out/lib/event-emitter-grouped.js:45:23)
at ambi (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/ambi/out/lib/ambi.js:23:18)
at fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:163:25)
at b (domain.js:183:18)
at Domain.run (domain.js:123:23)
at Task.fire (/Users/balupton/Projects/docpad-extras/skeletons/so-21747504/node_modules/docpad/node_modules/taskgroup/out/lib/taskgroup.js:173:25)
at processImmediate [as _immediateCallback] (timers.js:330:15)
Which indicates that the error is actually inside our event handler, rather than inside our code. That for some reason getGigsData is not being set, despite our:
getGigsData: ->
g = { "date" : "3-4-2013", "location" : "Gent" }
return g
Examining the code, as a CoffeeScript user, I found the issue. As a non-coffeescript user, you can use the coffeescript compiler on the coffeescript website http://coffeescript.org to see the compiled javascript, which is:
({
events: {
extendTemplateData: function(opts) {
({
getGigsData: function() {
var g;
g = {
"date": "3-4-2013",
"location": "Gent"
};
return g;
}
});
return opts.templateData["getGigsData"] = getGigsData;
}
}
});
As we can see that is definitely not what we expected. We are just defining getGigsData inside an object, then doing nothing with it.
The issue is that we used a colon instead of an equals sign, so getGigsData: -> instead of getGigsData = ->. This is not a coffeescript thing, but you would have run into the same issue if this was javascript too, albeit javascript may be a bit more obvious due to the necessary squiggly braces around object definitions.
As a sidenote, if you prefer to use JavaScript with DocPad for whatever reason, that is totally supported. You could use a docpad.json or docpad.js file for your docpad configuration file. Another option, is to continue using CoffeeScript then just wrap JavaScript code within the backtick, see: http://coffeescript.org/#embedded

How to stop ImageMagick in Ruby (Rmagick) evaluating an # sign in text annotation

In an app I recently built for a client the following code resulted in the variable #nameText being evaluated, and then resulting in an error 'no text' (since the variable doesn't exist).
To get around this I used gsub, as per the example below. Is there a way to tell Magick not to evaluate the string at all?
require 'RMagick'
#image = Magick::Image.read( '/path/to/image.jpg' ).first
#nameText = '#SomeTwitterUser'
#text = Magick::Draw.new
#text.font_family = 'Futura'
#text.pointsize = 22
#text.font_weight = Magick::BoldWeight
# Causes error 'no text'...
# #text.annotate( #image, 0,0,200,54, #nameText )
#text.annotate( #image, 0,0,200,54, #nameText.gsub('#', '\#') )
This is the C code from RMagick that is returning the error:
// Translate & store in Draw structure
draw->info->text = InterpretImageProperties(NULL, image, StringValuePtr(text));
if (!draw->info->text)
{
rb_raise(rb_eArgError, "no text");
}
It is the call to InterpretImageProperties that is modifying the input text - but it is not Ruby, or a Ruby instance variable that it is trying to reference. The function is defined here in the Image Magick core library: http://www.imagemagick.org/api/MagickCore/property_8c_source.html#l02966
Look a bit further down, and you can see the code:
/* handle a '#' replace string from file */
if (*p == '#') {
p++;
if (*p != '-' && (IsPathAccessible(p) == MagickFalse) ) {
(void) ThrowMagickException(&image->exception,GetMagickModule(),
OptionError,"UnableToAccessPath","%s",p);
return((char *) NULL);
}
return(FileToString(p,~0,&image->exception));
}
In summary, this is a core library feature which will attempt to load text from file (named SomeTwitterUser in your case, I have confirmed this -try it!), and your work-around is probably the best you can do.
For efficiency, and minimal changes to input strings, you could rely on the selectivity of the library code and only modify the string if it starts with #:
#text.annotate( #image, 0,0,200,54, #name_string.gsub( /^#/, '\#') )

SASS: syntax errors when using shorthand syntax

My scss file is this:
#import "compass/typography/lists/bullets";
.view-content ul
+no-bullets
This gives me an error on the page:
Syntax error: Invalid css after " +no-bullets": expected "{", was ""
However, when the rule looks like this:
.view-content ul {
#include no-bullets;
}
then it's OK and bullets are gone.
But I like the shorthand notation, how to enable using it?
You're right, I found the related documentation.
I tried the following and it works.
Then, I tried your and it didn't work until I remove the trailing ; on the import instruction.
#import "compass/typography/lists/bullets"
.view-content ul
+no-bullets
The following works with Compass 0.12.2. Try removing the trailing ; on the import instruction.

GCC plugin: 'internal compiler error' in passes.c

I have been writing a GCC inter procedural plugin where I have to insert GIMPLE statements
at certain points in the program. After this I perform a data flow analysis on the complete
program. When I am done with my analysis I am removing those newly inserted GIMPLE statements.
My analysis is getting completed but just before exiting from it the following message is generated:
internal compiler error: in execute_ipa_pass_list, at passes.c:1817
This is surely because of the insertion of GIMPLE statements, if I don't do that I won't get this error message.
Could anyone help me out and explain what is the problem and how to fix it?
This usually happens when GCC code contains an assertion which turns out to be false.
The line 1817 in passes.c (which is part of the GCC sources, in the gcc sub-directory of the GCC source tree) has a piece of code which looks like:
gcc_assert (some_condition);
In your case, some_condition was false, but the compiler expects it to be always true (this is why the author of the code wrote the assertion in the first place).
You did something in your plugin which made it false, and you need to fix it.
What did you do wrong? It really depends. Open up passes.c and find that line, and see what it is checking. In my copy of GCC, the relevant function reads:
void
execute_ipa_pass_list (struct opt_pass *pass)
{
do
{
/* An assertion. */
gcc_assert (!current_function_decl);
/* Another assertion. */
gcc_assert (!cfun);
/* Another assertion. */
gcc_assert (pass->type == SIMPLE_IPA_PASS || pass->type == IPA_PASS);
if (execute_one_pass (pass) && pass->sub)
{
if (pass->sub->type == GIMPLE_PASS)
{
invoke_plugin_callbacks (PLUGIN_EARLY_GIMPLE_PASSES_START, NULL);
do_per_function_toporder ((void (*)(void *))execute_pass_list,
pass->sub);
invoke_plugin_callbacks (PLUGIN_EARLY_GIMPLE_PASSES_END, NULL);
}
else if (pass->sub->type == SIMPLE_IPA_PASS
|| pass->sub->type == IPA_PASS)
execute_ipa_pass_list (pass->sub);
else
gcc_unreachable ();
}
/* Another assertion. */
gcc_assert (!current_function_decl);
cgraph_process_new_functions ();
pass = pass->next;
}
while (pass);
}
There are four gcc_assert statements. Your plugin caused one of them to become false. i.e. you messed with one of the variables:
current_function_decl
cfun
pass->type
This is probably what's wrong.

Resources