ERROR Failed to compile with 3 errors 1:46:21 PM
You may use special comments to disable some warnings.
Use // eslint-disable-next-line to ignore the next line.
Use /* eslint-disable */ to ignore all warnings in a file.
it is vuetify-material-dashboard-master template
Related
I get this error in my log files every time a cache file doesn't exist it seems. On the first page load, I always get this error
[message] => filemtime(): stat failed for [...]/runtime/cache/my/myapp03eab921185f7b68bbca50d8debc0dda.bin
[file] => [...]/vendor/yiisoft/yii2/caching/FileCache.php
[line] => 113
It doesn't happen anymore on next page loads but that one time is really annoying since the slack bot watcher is spamming our channel with this useless warning. Is there a way to avoid that, or is it a permission problem?
The "runtime", "cache" and "my" folders all have 775.
Update
Turns out the issue is that I'm using error_get_last() that is also getting warning-level errors. So it's a different issue entirely, not Yii-related
Make sure that you don't have enabled scream in your php.ini. Warnings from this filemtime() call should be suppressed by # operator, but scream setting can override this operator and generate warning anyway.
if (#filemtime($cacheFile) > time()) {
// ...
}
You must be getting this in PHP 7.1. try to run this with PHP 5.5 and see if you are getting the same error.
To reproduce you need to delete all files from runtime/cache directory
Then start app again(reload page) and look into runtime/cache. It is empty
Yii2 doesn't make cache again
Got same issue in Yii. The error was on the same string (FileCache.php:113)
if (#filemtime($cacheFile) > time()) {...
In my case reason was that my custom php error handler (heir
of the class yii\base\ErrorHandler) didn't check if
error type need to be handled according error_reporting().
Custom handlers allways gets every error, even muted by Error Control operator (#)
https://www.php.net/manual/en/function.set-error-handler.php
error_reporting() settings will have no effect and your error handler will be called regardless
I'm starting to work on an ongoing development with gulp and sass.
The workflow was set up for someone not avaialable at the momment and it has been working for people on the team.
Sass compiles on other people machines but not on mine.
I do compile sass on my machine in dozens of other projects without problem but not on this particular one.
I think I did initialize the project correctly but I suspect there is some version or configuration problem involved.
If I npm install everything and run gulp I get the following error:
Error: src/sass/utilities/mixins/_vendor-prefixes.scss
Error: Invalid CSS after "::-webkit-": expected "{", was "&-placeholder"
"&-placeholder" may only be used at the beginning of a compound selector.
on line 116 of src/sass/utilities/mixins/_vendor-prefixes.scss
I tried commenting the offending lines and running gulp again just to stumble with another error:
Error: src/sass/base/_base.scss
Error: "ul" failed to #extend "%reset-list".
The selector "%reset-list" was not found.
Use "#extend %reset-list !optional" if the extend should be able to fail.
on line 142 of src/sass/base/_base.scss
And so on:
Error: src/sass/utilities/_placeholders.scss
Error: You may not #extend an outer selector from within #media.
You may only #extend selectors within the same directive.
From "#extend %clearfix" on line 38 of src/sass/modules/_calendar.scss
on line 9 of src/sass/utilities/_placeholders.scss
This code works on other machines and all that advanced selector are being used on the development.
If I google for the particular errors I can find errors about them and people suggesting alternate selectors but I suspect that there is something else going on that I should fix.
I have updated my gulp to 3.9.1 and gulp-sass to 3.1.0 but I get the same errors.
How should I debug this?
Thanks!
EDIT: The errors are clearly stating that the code is not valid but the strange thing is that the same code is working on other peoples machines.
I'll post some code arround some of the errors just for reference anyway:
_vendor-prefixes.scss:116
// Placeholder focus text
#mixin placeholder-focus($color: $input-color-placeholder) {
&:focus::-webkit-&-placeholder { color:$color; }
&:focus:-moz-placeholder { color:$color; } /* FF 4-18 */
&:focus::-moz-placeholder { color:$color; } /* FF 19+ */
&:focus:-ms-input-placeholder { color:$color; }
}
_base.scss:142
// Unordered and Ordered lists
ul,
ol {
#extend %reset-list;
}
and the include on _placeholders.scss
// Reset List
%reset-list {
padding:0;
margin:0;
li {
list-style:none;
}
}
This had nothing to do with functionalities or versions.
As #rac pointed out the code is invalid.
The other developer was skiping the errors somehow and the compiled .css did not have the faulty lines or the faulty extends.
Removing all the faulty lines resulted in the same .css and a clean compile.
Thanks!
I wish to retrigger a Windows timer using a VCL6 TTimer object. I'm doing this by toggling the Enabled property, this of course can be confusing, but I added a comment about this. For Cppcheck I added a comment as well in its language:
m_pTimer->Enabled = false;
// die "doppelte Zuweisung" sorgt für einen Neustart des Timers
// cppcheck-suppress redundantAssignment
m_pTimer->Enabled = true;
...but it obviously doesn't help, I still see this style warning:
Variable 'Enabled' is reassigned a value before the old one has been used.
What am I doing wrong?
For the command line version inline suppressions must be enabled through the command line switch --inline-suppr. For details refer to the manual.
For the GUI version you have to activate inline suppressions through the preferences dialog (Menu Edit->Preferences, tab General, Enable inline suppressions).
I'm trying to use iojs with koa, what works well. But Webstorm doesn't accept the generator functions as valid.
/** gets marked as syntactically invalid code */
app.use(function *() {
this.body = 'Hello World';
});
My actual version is Webstorm 9.
Is there maybe a workaround? I couldn't find a matching option for it.
Go to the Preferences > Languages & Frameworks > JavaScript and chose ECMAScript 6 for JavaScript language version.
In regards to Error handling in PHP -- As far I know there are 3 styles:
die()or exit() style:
$con = mysql_connect("localhost","root","password");
if (!$con) {
die('Could not connect: ' . mysql_error());
}
throw Exception style:
if (!function_exists('curl_init')) {
throw new Exception('need the CURL PHP extension.
Recomplie PHP with curl');
}
trigger_error() style:
if(!is_array($config) && isset($config)) {
trigger_error('Error: config is not an array or is not set', E_USER_ERROR);
}
Now, in the PHP manual all three methods are used.
What I want to know is which style should I prefer & why?
Are these 3 drop in replacements of each other & therefore can be used interchangeably?
Slightly OT: Is it just me or everyone thinks PHP error handling options are just too many to the extent it confuses php developers?
The first one should never be used in production code, since it's transporting information irrelevant to end-users (a user can't do anything about "Cannot connect to database").
You throw Exceptions if you know that at a certain critical code point, your application can fail and you want your code to recover across multiple call-levels.
trigger_error() lets you fine-grain error reporting (by using different levels of error messages) and you can hide those errors from end-users (using set_error_handler()) but still have them be displayed to you during testing.
Also trigger_error() can produce non-fatal messages important during development that can be suppressed in production code using a custom error handler. You can produce fatal errors, too (E_USER_ERROR) but those aren't recoverable. If you trigger one of those, program execution stops at that point. This is why, for fatal errors, Exceptions should be used. This way, you'll have more control over your program's flow:
// Example (pseudo-code for db queries):
$db->query('START TRANSACTION');
try {
while ($row = gather_data()) {
$db->query('INSERT INTO `table` (`foo`,`bar`) VALUES(?,?)', ...);
}
$db->query('COMMIT');
} catch(Exception $e) {
$db->query('ROLLBACK');
}
Here, if gather_data() just plain croaked (using E_USER_ERROR or die()) there's a chance, previous INSERT statements would have made it into your database, even if not desired and you'd have no control over what's to happen next.
I usually use the first way for simple debugging in development code. It is not recommended for production. The best way is to throw an exception, which you can catch in other parts of the program and do some error handling on.
The three styles are not drop-in replacements for each other. The first one is not an error at all, but just a way to stop the script and output some debugging info for you to manually parse. The second one is not an error per se, but will be converted into an error if you don't catch it. The last one is triggering a real error in the PHP engine which will be handled according to the configuration of your PHP environment (in some cases shown to the user, in other cases just logged to a file or not saved at all).