I begin to use yeoman to make web pages. I finished almost. And I typed 'grunt' not 'grunt serve' to make up-loadable files.
terminal said errors below.But Cords work.
what should I fix.
app/scripts/main.js
2:3 error Strings must use singlequote quotes
2:3 error Expected indentation of 4 space characters but found 2 indent
5:7 error "slideqty" is defined but never used no-unused-vars
50:5 error "map" is defined but never used no-unused-vars
52:1 error Expected indentation of 2 space characters but found 0 indent
55:17 error "google" is not defined no-undef
58:13 error "google" is not defined no-undef
62:1 error "google" is not defined no-undef
62:1 error Expected indentation of 2 space characters but found 0 indent
✖ 22 problems (22 errors, 0 warnings)
Warning: Task "eslint:target" failed. Use --force to continue.
Aborted due to warnings.
Related
I have a problem with electron-builder since upgrading to Electron 10.1.2. My build now fails at rebuild for keyboard-layout. The rebuild only fails for Windows, not Mac. I don't know where to open this issue so I am asking here :).
My setup:
angular: 9.0.7
electron: 10.1.2
electron-builder: 22.8.x
The problem started when I updated electron from 9.0.0 to 10.1.2. Nothing else changed.
The problem:
When calling electron-builder with command electron-builder.cmd --x64 -p always -w rebuild of keyboard-layout is called as one of the steps as:
> keyboard-layout#2.0.16 install C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout
> node-gyp rebuild
That fails with:
...
win_delay_load_hook.cc
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager-windows.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): error C2220: warning treated as error - no 'object' file generated (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
c:\users\<me>\.electron-gyp\10.1.2\include\node\v8.h(5378): warning C4309: 'static_cast': truncation of constant value (compiling source file ..\src\keyboard-layout-manager.cc) [C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj]
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\keyboard-layout-manager.vcxproj" (default targets) -- FAILED.
Done Building Project "C:\Users\<me>\<dir1>\<dir2>\dist\node_modules\keyboard-layout\build\binding.sln" (default targets) -- FAILED.
Build FAILED.
...
What I have tried that DID NOT help:
Change binding.gyp in node_modules/keyboard-layout to (chnages marked with <---):
['OS=="win"', {
"sources": [
"src/keyboard-layout-manager-windows.cc",
],
'msvs_settings': {
'VCCLCompilerTool': {
'ExceptionHandling': 1, # /EHsc
'WarnAsError': 'false', # <--- I chnaged this from true to false
},
},
'msvs_disabled_warnings': [
4018, # signed/unsigned mismatch
2220, # <--- I added this
4244, # conversion from 'type1' to 'type2', possible loss of data
4267, # conversion from 'size_t' to 'type', possible loss of data
4302, # 'type cast': truncation from 'HKL' to 'UINT'
4311, # 'type cast': pointer truncation from 'HKL' to 'UINT'
4530, # C++ exception handler used, but unwind semantics are not enabled
4506, # no definition for inline function
4577, # 'noexcept' used with no exception handling mode specified
4996, # function was declared deprecated
],
}], # OS=="win"
What I have tried that DID help:
Electron 10.x.y updated v8 to 8.5 (Electron 10.0.0 release notes) and looking at line that causes the error (...\.electron-gyp\10.1.2\include\node\v8.h(5378)) I see this:
static constexpr size_t kMaxLength =
internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: static_cast<size_t>(uint64_t{1} << 32); <--- Line 5378
When I compare v8.h files from ...\.electron-gyp\10.1.2\include\node\v8.h and ...\.electron-gyp\9.0.0\include\node\v8.h, there is a change in this exact line.
Same line in old version:
static constexpr size_t kMaxLength = internal::kApiSystemPointerSize == 4
? internal::kSmiMaxValue
: 0xFFFFFFFF;
If I chnage static_cast<size_t>(uint64_t{1} << 32) to 0xFFFFFFFF, build succeedes.
My understanding ends here.
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
What can I do to fix this issue and what could be the reason for this change?
Why is this problem only on Windows?
What I have tried that DID NOT help:
'WarnAsError': 'false' should do the trick; however the error was reported for two different files (..\src\keyboard-layout-manager.cc and ..\src\keyboard-layout-manager-windows.cc) so you'd have to modify the build rules for both of them.
Disabling the warning should help too, but it'd have to be warning 4309 (not 2220) that you need to disable. Again, you'd have to do that for both files (or just for the entire compilation).
Are the old and new lines not theoretically the same? One shifted for 32 bits results in 0xFFFFFFFF?
No, 1 << 32 == 0x100000000 == 0xFFFFFFFF + 1).
What can I do to fix this issue?
turning off 'WarnAsError' should help
turning off warning 4309 should help
reverting that one line in your local checkout should help
using Clang instead of MSVC should help
possibly using a different (newer?) version of MSVC would also help
and what could be the reason for this change?
V8 now allows TypedArrays with up to 2**32 elements, which is one more element than before.
Why is this problem only on Windows?
Because warnings are compiler-specific, and MSVC is only used on Windows.
The weird part is that you're seeing this error in the first place. You compile with --x64; if that does what it sounds like, you should be compiling a 64-bit build, where internal::kApiSystemPointerSize == 8 and size_t has 64 bits just like uint64_t, so in the expression static_cast<size_t>(uint64_t{1} << 32); nothing gets truncated.
Even if for whatever reason this build tried to create a 32-bit build of V8, then the other branch should be taken (internal::kApiSystemPointerSize == 4) and the compiler should be smart enough not to warn about a branch that's statically dead anyway.
At any rate, this seems like a compiler bug/limitation. So appropriate workarounds are to either update your compiler, or disable the erroneous warning.
I was configuring SublimeText 3, and I think I've done some pretty bad mistake.
When I try to open SublimeText I get this message:
Error trying to parse settings: unexpected character,
expected a comma or closing bracket in
packages\user\preferences.sublime-settings:8:2
I tried to open the documents, run as admin everything.
Question:
Any idea about a solution for this?
I want to run a (python3) process from my (yap) prolog script and read its output formatted as a list of integers, e.g. [1,2,3,4,5,6].
This is what I do:
process_create(path(python3),
['my_script.py', MyParam],
[stdout(pipe(Out))]),
read(Out, OutputList),
close(Out).
However, it fails at read/2 predicate with the error:
PL_unify_term: PL_int64 not supported
Exception ignored in: <_io.TextIOWrapper name='<stdout>' mode='w' encoding='UTF-8'>
BrokenPipeError: [Errno 32] Broken pipe
I am sure that I can run the process correctly because with [stdout(std)] parameter given to process_create the program outputs [1,2,3,4,5,6] as expected.
Weird thing is that when I change the process to output some constant term (as constant_term) it still gives the same PL_int64 error. Appending a dot to the process' output ([1,2,3,4,5,6].) doesn't solve the error. Using read_term/3 gives the same error. read_string/3 is undefined in YAP-Prolog.
How can I solve this problem?
After asking at the yap-users mailing list I got the solution.
Re-compiled YAP Prolog 6.2.2 with libGMP option and now it works. It may also occur in 32-bit YAP.
I made a small change in my server code not related to formatting numbers and now the dart library number_format.dart won't compile giving me 12 errors and two warnings. number_format is in intl as noted in the comments and the first error is at line 106. Some or most of the other errors appear to cascade from a first error.
Does anyone know how I may resolve this? I presume I need to edit something in my yaml file.
EDIT
If I choose Tools-> Pub Upgrade then I get the pre-build Problems below This weekend I could choose Tools->Pub Build - Debug but at the moment this does not work. Deleting .pub and following Günter Zöchbauer's suggestion allowed me to do a build Sunday - I hope is still does.
Pre-build Problems output:
Errors:
Line 106: Expected an identifier
Line 106: Expected to find ':'
Line 106: Unexpected token '?'
Line 131: Unexpected token '?'
Line 132: Expected an identifier
Line 132: Expected to find ':'
Line 233: Expected an identifier
Line 233: Expected to find ':'
Line 233: Unexpected token '?'
Line 545: Expected an identifier
Line 545: Expected to find ':'
Line 545: Unexpected token '?'
Warnings:
Line 106: Conditions must have a static type of 'bool'
Line 545: Conditions must have a static type of 'bool'
Hint:
Line 425: When compiled to JS, this test might return true when the left hand side is an int
Thanks
I'm using these files in my gaming server, and every time I add a new player model, I get
[ERROR] lua/autorun/server/fastdlskins.lua:938: '<eof>' expected near 'end'
1. unknown - lua/autorun/server/fastdlskins.lua:0
I also get a similar error when I add an add-on to a different file
[ERROR] lua/autorun/server/workshopitems.lua:55: '<eof>' expected near 'end'
1. unknown - lua/autorun/server/workshopitems.lua:0
I usually just have to put an 'end' after the code, but I don't see what else I'm required to do. I don't have any loops running (I think), so I'm not closing any of those out. Not sure what to do.
As Egor said, remove the extra end at the end of the files.
end is only used to close blocks for functions and loops, like } in C-like languages. The end at the file is not closing anything, and is thus invalid syntax.