The help text for require-atomic-updates talks exclusively about statements that both set and consume the same variable.
I have some old† code that looks something like this (I think I've included everything that is relevant):
var someFunction = async function someFunction () {
switch(someVariable) {
case 0:
if (maybe) {
await doSomething();
}
break;
case 1:
//similar to above
}
someVariable = 0; // Error detected on this line
return
}
var someVariable = 0;
someFunction is invoked during some event processing later, while someVariable can be adjusted by multiple code paths
As far as I can tell, the line on which the error is reported is an atomic update, it doesn't read the value or set the new value based on anything else.
I can't understand why eslint thinks there is a possible race-condition here?
The code has been functional for a long time now, so I'm happy to just disable the rule on this line to stop it complaining. But I'd like to understand the reason that eslint highlighted it.
† The original code was written long ago, but has been adjusted more recently to be async
If you upgraded to eslint 6.0.1 like I just did, you're encountering a recently introduced bug.
There are several open github issues referencing this bug, but the gist of it is that require-atomic-updates is currently broken.
I recommend downgrading eslint or disabling the rule as a workaround.
Bug reports on the issue here:
https://github.com/eslint/eslint/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+require-atomic-updates
Related
I have an F# Azure Function that is failing, in a bizarre way, and don't know how to approach fixing the issue. I created a minimum repro of the actual case below. The test function is manually triggered and uses FSharp.Compiler.Service as a dependency, as specified in the project.json below:
{
"frameworks": {
"net46":{
"dependencies": {
"FSharp.Compiler.Service": "11.0.6"
}
}
}
}
The run.fsx file looks like this:
open System
open Microsoft.FSharp.Compiler
open Microsoft.FSharp.Compiler.Ast
open Microsoft.FSharp.Compiler.Interactive.Shell
let Run(input: string, log: TraceWriter) =
// code here that uses FsiEvaluationSession
// and runs just fine
log.Info "I RAN"
So far, so good. The part that baffles me is that if I add the following function above Run,
// same dependencies as before
open Microsoft.FSharp.Compiler.Interactive.Shell
let foo (longIdent:LongIdent) =
// version 1
// "FOO"
// version 2
// longIdent.ToString ()
// version 3
longIdent |> List.map string
let Run(input: string, log: TraceWriter) =
// same as before
Uncommenting section 1 alone works fine, uncommenting section 2 alone works fine, uncommenting section 3 causes hell to break loose. The function compiles, but running it causes the following exception:
Exception while executing function: Functions.fsc-1. mscorlib: Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.
... which is puzzling to me, because
foo isn't even called anywhere
the signature and the 2nd version both use LongIdent, so this type doesn't seem to be the source of the problem.
Any suggestion on how to approach the problem, and what the problem itself might be, would be very appreciated - I don't even know where to start, and the same code runs perfectly fine in a local script.
I believe the reason for this is that Azure Functions SDK depend on FSharp.Compiler.Service (FCS) version 9.0.1. This means that when you try to load a different version of FCS, you will get the already loaded version 9.0.1.
This works as long as the public API of the FCS version you are using matches the public API of version 9.0.1, but when there are differences, it will crash, because your code assumes that the public API looks different. I suppose this might be triggering the issue here, although I'm not 100% sure how (possibly, LongIdent is now a different thing than it was in version 9.0.1?)
The very same issue used to happen with FAKE, which also bundles FCS and prevented loading of different versions. One of the options is to rename the assembly to avoid the clash.
I also got the same error, I solved it by doing the following workaround, please refer if it works for you also.
Right-click on the Project and select properties.
Goto Debug tab and create a profile with the reference to the below
screenshot.
Note: Replace UserName with your username.
I am debugging a Node Server written in typescript in WebStorm 10.0.4 and when stepping through the code, the code execution path completely changes. A variable assignment appears to break and reference a different (incorrect) object and break my code.
I have a class CustomerRoutes.ts which contains different methods to handle POST requests. I register the endpoint:
app.post('/Contacts', jsonParser, CustomerRoutes.postContact);
CustomerRoutes.postContact is a public static function which is defined as:
public static postContact(request, response) {
if(request.body.$type == 'Person') {
CustomerRoutes.postIndividual(request, response);
} else if(request.body.$type == 'Organization') {
CustomerRoutes.postOrganization(request, response);
}
}
CustomerRoutes.postIndividual and CustomerRoutes.postOrganization are both public static functions as well. So when the server is in non-debug mode the code executes as expected and the branching statements are executed. However when stepping through the code the variable CustomerRoutes global variable gets reassigned to the contents of request within the scope of CustomerRoutes.postContact
As you can see in the Variables window of the debugger the variable CustomerRoutes has been redefined twice to the values of request and response. So now when stepping through the code and the functions postIndividual and postOrganization are called, CustomerRoutes does not contain those function and POST fails with an exception and error 500.
I do not believe this is any sort of race/timing condition so it must be a bug in the debugger environment. My hunch is that the typescript variable mappings are not working correctly with the debugger but I am not certain. Has anyone seen an issue like this or an idea on a fix? I have never seen anything like it. I am happy to post more information as requested.
My hunch is that the typescript variable mappings are not working correctly with the debugger but I am not certain.
TypeScript doesn't have proper variable mapping in sourcemaps at the moment. Follow this issue : https://github.com/Microsoft/TypeScript/issues/2859 (also answered it here once : Chrome Typescript debugging references wrong 'this')
Has anyone seen an issue like this or an idea on a fix?
Disable sourcemaps to see what is actually going on in the raw JavaScript.
For diagnostic purposes I sometimes need to store the call stack that lead to a given state transition (such as granting a lock, committing a transaction, etc.) so that when something goes wrong later I can find out who originally triggered the state transition.
Currently, the only way I am aware of to retrieve the call stack looks like the following code snippet, which I consider terribly ugly:
StackTraceElement[] cause;
try {
throw new Exception();
} catch (Exception e) {
cause = e.getStackTrace();
}
Does somebody know of a better way to accomplish this?
I think you can get the same thing with:
StackTraceElement[] cause = Thread.currentThread().getStackTrace();
Well, you can improve it slightly by not actually throwing the exception.
Exception ex = new Exception();
ex.fillInStackTrace();
StackTraceElement[] cause = ex.getStackTrace();
Actually, I just checked: the constructor calls fillInStackTrace() already. So you can simplify it to:
StackTraceElement[] cause = new Exception().getStackTrace();
This is actually what Thread.getStackTrace() does if it's called on the current thread, so you might prefer using it instead.
If you want it as a String and use Apache Commons:
org.apache.commons.lang.exception.ExceptionUtils.getFullStackTrace(new Throwable())
There's a new option since JDK 9: StackWalker
It isn't as expensive as Thread.currentThread().getStackTrace().
see also How Expensive is Thread.getStackTrace()?
I decided to start a new project to get into hacklang, and after fixing some if the problems I initially ran into transitioning from php habits, I ran into the following errors:
Unbound name: str_replace
Unbound name: empty
Doing some research I found that this is due to using 'legacy' php which isn't typechecked, and will error with //strict.
That's fine and all, empty() was easy enough to replace, however str_replace() is a bit more difficult.
Is there an equivalent function that will work with //strict? Or at least something similar.
I'm aware that I could use //decl but I feel like that defeats the purpose in my case.
Is there at least any way to tell which functions are implemented in hack and which are not in the documentation as I couldn't find one?
For reference (though it isn't too relevant to the question itself), here is the code:
<?hh //strict
class HackMarkdown {
public function parse(string $content) : string {
if($content===null){
throw new RuntimeException('Empty Content');
}
$prepared = $this->prepare($content);
}
private function prepare(string $contentpre) : Vector<string>{
$contentpre = str_replace(array("\r\n","\r"),"\n",$contentpre);
//probably need more in here
$prepared = Vector::fromArray(explode($contentpre,"\n"));
//and here
return $prepared;
}
}
You don't need to change your code at all. You just need to tell the Hack tools about all the inbuilt PHP functions.
The easiest way to do this is to download this folder and put it somewhere in your project. I put it in a hhi folder in the base of my project. The files in there tell Hack about all the inbuilt PHP functions.
Most of them don't have type hints, which can lead to Hack thinking the return type of everything is mixed instead of the actual return, that is actually correct in most cases as, for example, str_replace can return either a string or a bool. However, it does stop the "unbound name" errors, which is the main reason for adding them.
I used this:
Local<Value> argv[argc] = { String::New("hello world") };
But now I see the example on node.js website:
Local<Value> argv[argc] = { Local<Value>::New(String::New("hello world")) };
What does it mean? What's difference, when an dwhy I should use Local<Value> in addition to String::New()
Apparently, the node.js example in this case was wrong/inefficient.
https://github.com/joyent/node/commit/98aad77f466d9c36947f2cbb6d07b75009795ed2#commitcomment-5532648
jnardone added a note 2 hours ago
Was this just one of those things that was always wrong, or was there
an underlying v8 change that meant that this should change? The
additional Local::New always looked odd but I can't tell if something
buried inside v8 required this additional wrapper or not.
bnoordhuis added a note 7 minutes ago
It's cleanup. Creating a Local out of a Local is not
actively harmful but it's superfluous and slightly inefficient.
So, your first format is fine.