Im using google Closure Compiler to compress my js, anyhow I get the following error message:
JSC_TRAILING_COMMA: Parse error. Internet Explorer has a non-standard intepretation of trailing commas. Arrays will have the wrong length and objects will not parse at all. at line 8698 character 5 in post-login.js
];
The error is in the first line of this code, but I could not figure out whats wrong with it...
var plot = $.jqplot('usst_points_last_10_days', [data], {
title: '<h3 class="startGrafHeadline">' + global_language['discriptive']['usst']['visits_in_detail'] + '</h3>',
seriesColors: ["#00FF00"],
series: [{renderer:$.jqplot.BarRenderer}],
axesDefaults: {
tickRenderer: $.jqplot.CanvasAxisTickRenderer ,
tickOptions: {
angle: -30,
fontSize: '10pt'
}
},
axes: {
xaxis: {
renderer: $.jqplot.CategoryAxisRenderer
}
}
});
Try looking at the line just before the line that the compiler is complaining about. This will be the last line is some other file, perhaps.
If you examine your command line or build script, that will lead you to the answer. It seems likely that you are compiling multiple files or are pre-concatenating many files before compilation. What closure compiler is telling you is to look at line 8698.
If you have some logical explanation about why you think the error is contained in this code, please let us know your reasoning.
If you post more information, I may be able to improve this answer.
There is a handy tool for using closure-compiler through a web UI that may help you convince yourself that you have not found the offending line:
http://closure-compiler.appspot.com
Related
I have a simple Chapel program to test the NetCDF module:
use NetCDF;
use NetCDF.C_NetCDF;
var f: int = ncopen("ppt2020_08_20.nc", NC_WRITE);
var status: int = nc_close(f);
and when I compile with:
chpl -I/usr/include -L/usr/lib/x86_64-linux-gnu -lnetcdf hello.chpl
it produces a list of errors about SysCTypes:
$CHPL_HOME/modules/packages/NetCDF.chpl:57: error: 'c_int' undeclared (first use this function)
$CHPL_HOME/modules/packages/NetCDF.chpl:77: error: 'c_char' undeclared (first use this function)
...
Would anyone see what my error is? I tried adding use SysCTypes; to my program, but that didn't seem to have an effect.
Sorry for the delayed response and for this bad behavior. This is a bug that's crept into the NetCDF module which seems not to have been caught by Chapel's nightly testing. To work around it, edit $CHPL_HOME/modules/packages/NetCDF.chpl, adding the line:
public use SysCTypes, SysBasic;
within the declaration of the C_NetCDF module (around line 50 in my copy of the sources). If you would consider filing this bug as an issue on the Chapel GitHub issue tracker, that would be great as well, though we'll try to get this fixed in the next release in any case.
With that change, your program almost compiles for me, except that nc_close() takes a c_int argument rather than a Chapel int. You could either lean on Chapel's type inference to cause this to happen:
var f = ncopen("ppt2020_08_20.nc", NC_WRITE);
or explicitly declare f to be of type c_int:
var f: c_int = ncopen("ppt2020_08_20.nc", NC_WRITE);
And then as one final note, I believe you should be able to drop the -lnetcdf from your chpl command-line as using the NetCDF module should cause this requirement to automatically be added.
Thanks for bringing this bug to our attention!
If I use a built-in Sass function that returns an error, it will display the path of where it is used.
Using a built-in Sass function:
Code from _test.scss.
.foo {
color: darken(blue, s);
}
Will result in:
error _test.scss (Line 2: $amount: "s" is not a number for `darken')
Now, if I use a custom function that returns an error, it will display the path of where it is defined instead of where it is used.
Using a custom function:
Code from _test.scss.
.foo {
color: example(string);
}
Code from _functions.scss.
#function example($string) {
#error 'error message';
}
Will result in:
error core/utils/_functions.scss (Line 2: error message)
Is there any solution for solving this "issue"?
Your examples are similar only visually, underlying logic is completely different:
For built-in function Sass throws error by itself because code is not valid from Sass point of view.
Into second example you're throwing error because code is not valid from your point of view. Code itself if valid from Sass point of view in this case.
In both cases Sass displays same information about error location - a point into your codebase where error occurs. But in a case of your own, intentional error throwing actual point where error occurs actually matches a place where you're generating this error - exactly at a place where you have your #error directive. So there is no mistake into Sass behavior because it knows nothing about reasons why did you decide to throw an error.
You can always analyze stack trace that is displayed (at least by node-sass) along with error message to decide where did you get to point of error from. You can also use #debug to display context that may be useful for error analysis.
I'm getting the following error when trying to use Sass Maps (which look like object variables):
Invalid CSS after " primary": expected ")", was ": #3097D1,"
(in /Users/.../app/assets/stylesheets/new_design.scss:19)
I reproduced the error by using the following minimal example:
$theme-colors: (
primary: #3097D1,
secondary: black
);
#each $key, $val in $theme-colors {
.foo.#{$key} {
color: $val;
}
}
Expected:
.foo.primary {
color: #3097D1;
}
.foo.secondary {
color: black;
}
But getting the error mentioned.
sass-rails, ~> 5.0.0 seems to be installed according to the Gemfile:
gem 'sass-rails', '~> 5.0.0'
I'd assume that loads one of the latest sass versions which should support object variables.
I have the feeling the current version I have is not recognizing this syntax.
How can I make sure I have the right sass version? Is there anything else I have to do to compile this syntax successfully?
bundle show sass-rails shows 5.0.6, which seems recent.
as discussed in the comments there is a stackoverflow discussion about a similar issue with the map sass syntax
The discussion refers to Github Issue 1088
I quote
There's a number of issues with the indented syntax, and Sass maintainers aren't going to fix them. :( They say, the .sass parser is weird and hard to refactor.
I find Sass syntax to be quicker to type and easier to read. It is deprived of the visual noise:
indented_vs_bracketed
It's also much easier to do copy-pasting.
So Sass maintainers, PLEASE don't let the indented syntax fall behind!
Probably by digging down in the discussion we will be able to find the solution. Now I am quoting the solution from the owner of the post Ionică Bizău:
wrapping the values between quotes, saving, reloading in browser without any errors, and then removing the quotes back and reloading the page in browser solved the problem. Maybe it was something cached somewhere... but I can't understand where. I didn't restart rake or ran any bundle command... Thanks! :)
I'm having a strange issue I haven't seen occur. I am trying to do some basic addition to some variables like this:
#screen-break-sm: 768px;
#screen-break-md: 992px;
#screen-max-mobile: #screen-break-sm;
#screen-min-desktop: #screen-break-sm + 1;
Then, those values are being used in some media queries. When it is compiled using gulp-less (version ~3.0.0 in package.json) via Gulp, the output ends up being something like:
#media (min-width:768px + 1) {
// CSS
}
I'm expecting:
#media (min-width:769px) {
// CSS
}
I have tried doing the addition as both #screen-break-sm + 1 and also screen-break-sm + 1px. I've also tried removing the px part of the original values and doing the add and appending the px afterwards, but that doesn't add either.
In case it is relevant, this is one of the gulp scripts that builds a section where I first ran into this issue:
module.exports = function (build) {
return function () {
var pagesPath = build.options.styles.buildPath + '/pages/';
return build.gulp.src('./resources/assets/less/pages/**/*')
.pipe(build.plugins.less({
paths: [ build.plugins.path.join(__dirname, 'less', 'vendor', 'theme', 'bootstrap') ]
})).on('error', build.errorHandler)
.pipe(build.plugins.minifyCss()).on('error', build.errorHandler)
.pipe(build.plugins.extReplace('.min.css')).on('error', build.errorHandler)
.pipe(build.gulp.dest(pagesPath));
};
};
Any ideas why LESS is concatenating/appending instead of performing addition?
[EDIT]
While the solution is the same as the other question that was identified as a possible duplicate, that question does not discuss the problem that users will encounter directly, and therefore I think this question is much better suited for searching purposes. I never found that solution after an hour of Googling and only after getting the answer and the "strict math" verbiage did that other question show up.
Look at strict math option which default value is OFF. Are you sure that for some reason you don't have it set to ON?
lessc -sm=on
lessc --strict-math=on
The digital clock in KDE Plasma 5.4.0 does not allow you to specify a custom format. I'm attempted to hack the plasmoid, which is just a QML file. However, I've been unsuccessful. There is a conditional branch, which allows you select from one of the following strings.
return Qt.SystemLocaleLongDate;
return Qt.ISODate;
return Qt.SystemLocaleShortDate;
I attempted to modify it to the following, but it's not working. Presumably I just have the syntax wrong.
return QDate::currentDate().toString("dd.MM.yyyy");
How can I modify the plasmoid to show a custom date format?
EDIT
I suspect that I might be changing the wrong line. The source code for the plasmoid I'm trying to hack is here. After decompressing the file, it's specifically at applets/digital-clock/package/. (When installed, this directory is moved to /usr/share/plasma/plasmoids/org.kde.plasma.digitalclock/.) I attempted changing line 43 of contents/ui/DigitalClock.qml.
I attempted changing the line to return "foo";, but this had no effect. Again, I'm not sure if I have the syntax correct.
As stated in the comments, the line returning this value isn't a reference to the date itself, but merely specifies the format. I'm unsure of the syntax to hack the code here, but instead, you can change the code that references this property later.
--- DigitalClock.qml.orig 2015-08-22 20:45:40.000000000 +1000
+++ DigitalClock.qml 2015-09-01 09:32:35.417197582 +1000
## -515,7 +515,7 ##
if (main.showDate) {
if (main.tooSmall) {
- dateLabelLeft.text = Qt.formatDate(main.currentTime, main.dateFormat);
+ dateLabelLeft.text = Qt.formatDate(main.currentTime, "dd.MM.yyyy");
} else {
dateLabel.text = Qt.formatDate(main.currentTime, main.dateFormat);
}