I have the following code.
getCallStub.returns(new Promise((resolve)=>{
resolve([item]);
}));
But there has to be an easier way so I look at the Sinon docs and see something like getCallStub.resolve([item]); should work but I get...
TypeError: getCallStub.resolve is not a function
I also tried getCallStub.usingPromise(Promise).resolve([item]); and got the same...
TypeError: getCallStub.usingPromise(...).resolve is not a function
I double checked the node_modules and I am at a version greater than 2 (6.3.5) so why can't I use the resolve function?
From the docs:
stub.resolves(value);
Seems you just forgot an s and your code should be
getCallStub.resolves([item]);
Related
I'm trying to use relay-runtime with freshjs by importing it with these strings in my import map:
"react-relay": "https://esm.sh/react-relay#14.1.0?alias=react:preact/compat,react-dom:preact/compat,#types/react:preact/compat",
"relay-runtime": "https://esm.sh/relay-runtime#14.1.0?alias=react:preact/compat,react-dom:preact/compat,#types/react:preact/compat",
and when doing so, I get this error:
error: Uncaught (in promise) TypeError: Jl is not a function
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:4933
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:1389
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:7965
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:1389
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:3:82513
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:1389
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:3:85815
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:2:1389
at https://esm.sh/v94/relay-runtime#14.1.0/deno/relay-runtime.js:3:85832
I tried to import type declarations from https://esm.sh/v94/#types/relay-runtime#14.1.0/index.d.ts but am still having this issue. I had also tried to use v14.0.0 but then I get this error:
error: Uncaught (in promise) Error: Minified exception occurred; use the non-minified dev environment for the full error message and additional helpful warnings.
at V (https://esm.sh/v96/invariant#2.2.4/deno/invariant.js:2:612)
at sv (https://esm.sh/v96/relay-runtime#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/relay-runtime.js:2:45152)
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:3114
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:2662
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:70288
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:2662
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:71428
at https://esm.sh/v96/react-relay#14.0.0/X-YS9yZWFjdDpwcmVhY3QvY29tcGF0/deno/react-relay.js:2:2662
Any help is appreciated. Thank you. I also tried importing initially without the query string
I am just trying out Clojure CLR a bit and I am stumped about how to make what seems as if it should be a pretty simple call work.
Version is Clojure 1.10.0-master-SNAPSHOT
In the REPL I do this:
(import 'System.IO.FileSystem)
(FileSystem/Directory/GetCurrentDirectory)
I get the following response:
Syntax error (InvalidOperationException) compiling at (REPL:1:2).
Unable to find static field: GetCurrentDirectory in
Everything I can find about "Unable to find static field:" would seem to indicate that I've got the assembly name wrong but that doesn't seem to be it.
I also tried this:
(. FileSystem/Directory GetCurrentDirectory)
and I get
Syntax error (InvalidOperationException) compiling at (REPL:1:2).
Unable to find static field: Directory in System.IO.FileSystem
Also tried this:
(FileSystem/Directory/GetCurrentDirectory [])
And I get this error:
Syntax error (InvalidOperationException) compiling at (REPL:1:2).
Unable to find static field: GetCurrentDirectory in
Can someone please tell me what it is that I've gotten wrong here?
Under Core 3.1 and Net 5.0, System.IO.FileSystem does not contain GetCurrenDirectory or Directory. (You can check this quickly by evaling ((map #(.Name %) (concat (.GetMethods System.IO.FileSystem) (.GetProperties System.IO.FileSystem)) to see what's available.)
There is a System.IO.Directory class with a GetCurrentDirectory method. Try
(System.IO.Directory/GetCurrentDirectory)
or if you prefer to import the class
(import 'System.IO.Directory)
(Directory/GetCurrentDirectory)
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 creating an application with Google Closure Library and its Compiler. To debug values I use console.log(). Compiling this will throw the following exception JSC_UNDEFINED_VARIABLE. variable console is undeclared at .... To solve this error, I just had to use window.console.log() instead.
I also want to measure the time that a function takes. Firebug has two nice functions console.time(name) and console.timeEnd(name) to do that very easily. Unfortunately the Closure Compiler does not support these functions throwing the following warning JSC_INEXISTENT_PROPERTY. Property time never defined on Window.prototype.console at .... Unfortunately you cannot solve this warning with prepending window.
I also had a look at the library, but goog.debug.Console has not the function that I need.
Another solution I have used before was something like the following
var start = new Date();
// do something
var end = new Date();
// do some calculation to get the ms for both start and end
var startMS = ....;
var endMS = .....;
// get the difference and print it
var difference = (endMS - startMS) / 1000;
console.log('Time taken for something: ' + difference);
This is a little bit too much code, if you use it very often, and the version with the two functions would be great:
window.console.time("timeTaken");
// do something
window.console.timeEnd("timeTaken");
This prints out the MS between start and end. But as mentioned above, this doesn't work with the closure compiler. Does anyone have a solution for this, how I can use these two functions window.console.time() and window.console.timeEnd()? Or maybe another solution that goog.closure provides, but I haven't found?
You just need to added them to the externs you are using.
If you don't want to/can't use externs, you can easily reference "undeclared" objects with the string-based properties:
window['console']['log']('Hello Console!');
window['console']['time']('timeTaken');
...
But you have to be careful, because the second line might throw an error if the time property does not exist or it's not a function.