why does the statement:
v8::Isolate* isolate = v8::Isolate::New(create_params);
take 27 seconds to run?
This is from the "hello-world.cc" example from the V8 source.
I actually just got an answer from the Chromium team regarding this. The long bootstrapping of an isolate is an intended behavior in debug mode. To fix this, you can apparently either:
Build and link in release mode.
Use a snapshot to move the bootstrapping process from runtime to build time.
Related
I used to use Cypress 9 on previous projects.
By default, when running cypress open or cypress open --browser chrome used to run all tests for all React components.
However I installed Cypress 10 for the first time on a project that didn't have e2e tests yet. I added test specs, but I don't see any option to run all tests altogether.
It seems I have to run the tests one by one, clicking on each of them.
Can anyone please suggest how do I run all the tests automatically?
It's been removed in Cypress v10, here are the change notes related
During cypress open, the ability to "Run all specs" and "Run filtered specs" has been removed. Please leave feedback around the removal of this feature here. Your feedback will help us make product decisions around the future of this feature.
The feedback page to register your displeasure is here
You can create a "barrel" spec to run multiple imported specs.
I can't vouch for it working the same as v9 "Run all tests", but can't see any reason why not.
// all.spec.cy.js
import './test1.spec.cy.js' // relative paths
import './test2.spec.cy.js'
...
As #Constance says, reinstated in v11.20.
But still a very handy technique if you want to run a pre-defined subset of your tests.
In Cypress version 11.2.0 the Run All button has been reinstated.
You need to set experimentalRunAllSpecs to true in cypress.config.js.
Please see Configuration - End-to-End Testing
If Cypress Test Runner is not a must, I suggest to utilize the CLI/Node Cmd approach
You can trigger all the test(s) by npx cypress run(Still the video recording & screenshot on failed steps would be saved in the respective folders) to run all or with any other cypress flags to filter out specific spec files, or browser etc.
As per the feedback discussion there is a workaround the same as #Fody's answer that will achieve the same result as v9. Also worth noting though is the section on Continuous Integration and the Update 1 that includes a fix for preventing this workaround creating issues with the cypress run command.
Are there any current workarounds?
Yes. If you are impacted by the omission of this feature, it is possible to achieve the same level of parity as 9.x with a workaround Gleb Bahmutov explains here: https://glebbahmutov.com/blog/run-all-specs-cypress-v10/
This will still inherit the same problems as the previous implementation (which is why it was removed) but it will work in certain cases where the previous implementation was not problematic for your use case
https://github.com/cypress-io/cypress/discussions/21628#discussion-4098510
It was removed because people used it wrong.
The Test Runner is for debugging single tests. But by running all tests, then performance will quickly become a problem and crash the entire suite.
Running all tests should only be performed from the CLI.
Sources
https://github.com/cypress-io/cypress/issues/681
https://github.com/cypress-io/cypress/discussions/21628
Im having a Golang code which I create from it binary for mac via go build
like:
build darwin amd64 myapp
Currently Im able to run the binary and see the logs.
Now I want to debug it , is there a way to debug the binary with Goland or Intellij or VSCode ? regular debug with delve is working from all the IDE's above but now I want to attach it to the binary process which I was able to run,Any idea if it possible?
If you use GoLand 2018.1+ you should be able to use the Run | Attach to Local Process feature and it will allow you to debug a running binary.
I suggest that you compile the binary with all the optimizations turned off and compiled with Go 1.10+ in order to get the best debugging experience.
Furthermore, the IDE can launch the binary and debug it in a single click, removing the need to perform multiple steps.
One last issue that I can mention is that you currently will not be able to correctly debug Go apps via Delve, so regardless of which editor you use, due to a bug introduced by Apple in the latest developer tools. For more information please see the issue on our tracker: https://youtrack.jetbrains.com/issue/GO-5527 and on Delve's tracker: https://github.com/derekparker/delve/issues/1165
Edit:
The issue mentioned above was resolved in GoLand 2018.1.1.
right now we are in a situation of having build times 2 minutes 30 seconds for very simple change. This (compared to ANT) is amazingly slow and is killing the productivity of the whole team.
I am using Android Studio and using the "Use local gradle distribution".
I've tried to give more memory to gradle:
org.gradle.jvmargs=-Xmx6096m -XX:MaxPermSize=2048m -XX:+HeapDumpOnOutOfMemoryError -Dfile.encoding=UTF-8
A lot more memory. AND IT IS STILL GIVING ERRORS FOR MEMORY from time to time.
Exception in thread "pool-1-thread-1" java.lang.OutOfMemoryError: GC overhead limit exceeded
Amazing. I am using the parallel option and daemon:
org.gradle.parallel=true
org.gradle.daemon=true
It doesn't really help.
I've put the aforementioned parameters in ~/.gradle/gradle.properties (and I even doubted that Android studio is ignoring that, so I tested - it is not ignoring it).
Still from terminal I get 1:30 build time vs 2:30 in Android Studio, so not sure what is wrong there. 1:30 is STILL CRAZY compared to Ant. If you know what Android Studio is doing (or ignoring, or rewriting as gradle config), I'd be grateful to know.
So just CMD + B (simple compile) is super fast after changes, like 7 seconds.
But when it comes to running the app, it starts the task dexXxxDebug, which is just killing us.
I've tried putting
dexOptions {
preDexLibraries = false
}
Doesn't help.
I understand that gradle is probably still not ready for production environments, but I'm starting to regret our decision to move so early to it.
We have lots of modules, which is probably part of the problem, but that was not an issue with Ant.
Any help appreciated,
Dan
Some more information about execution times:
Description Duration
Total Build Time 1m36.57s
Startup 0.544s
Settings and BuildSrc 0.026s
Loading Projects 0.027s
Configuring Projects 0.889s
Task Execution 1m36.70s
The time eater:
:app:dexDebug 1m16.46s
I'm not quite sure why Android Studio is slower than the command line, but you can speed up your builds by turning on incremental dexing. In your module's build file, add this option to your android block:
dexOptions {
incremental true
}
In that dexOptions block you can also specify the heap size for the dex process, for example:
dexOptions {
incremental true
javaMaxHeapSize "4g"
}
These options are taken from a thread on the adt-dev mailing list (https://groups.google.com/forum/#!topic/adt-dev/r4p-sBLl7DQ) which has a little more context.
Our team was facing the same issue.
Our project exceeds the method limit for dex(>65k).
So, in out library project we put below options in build.gradle:
dexOptions {
jumboMode = true
preDexLibraries = false
}
In our project build.gradle:
dexOptions {
jumboMode = true
// incremental true
}
previously we had incremental true. after commenting it its taking around 20s to run as compared to 2mins 30 seconds.
I don't know this may solve your problem. but it can help to others. :)
Disclaimer: This isn't a solution - it's a statement that there is no solution with relevant link sources to prove it.
Since all answers here do not solve a problem that has been lingering since 2014, I'm gonna go ahead and post a couple of links which describe a very simillar problem and present OS-specific tweaks that might or might not help, since OP did not seem to specify it, and solutions vary a lot across them.
First is the actual AOSP bug-tracker issue referring to parallelization, with a lot of relevant stuff, still open and still with a lot of people complaining as off version 2.2.1. I like the guy who notes the issue (a high-priotity one at that) id including "666" not being a coincidence. The way most people describe music programs and mouse movement stuttering during builds feels like looking into a mirror...
You should note people report good stuff with process lasso for Windows, while I see none really reporting anything good with renice'ing or cpu-limiting in *nix variants.
This guy (who states he doesn't use gradle) actually presents some very nice stuff in Ask Ubuntu, that unfortunately doesn't work in my case.
Here is another alternative that limits threads of gradle execution, but that didn't really improve in my scenario probably due to what somebody says on another link about studio spawning multiple gradle instances (while the parameter only affects one instance's parallelism).
Note that this all goes back to the original "666", high-priority issue...
Personally I couldn't test many of the solutions because I work on a managed (no root privs) Ubuntu machine and can't apt-get/renice, but I can tell you I have an i7-4770, 8GB RAM and a hybrid SSD, and I have this problem even after a lot of memory and gradle tweaks over the years. It is a tantalizing issue, and I can't understand how Google hasn't committed the necessary human resources to the gradle project to fix something that is at the core of development for the most important platform they build.
One thing to note on my environment is: I work in a multi-dependency studio project, with about 10 subprojects, all of them building on their own and filling up the gradle pipeline.
When passing a value, you can append the letter 'k' to indicate kilobytes, 'm' to indicate megabytes, or 'g' to indicate gigabytes.
'--offline' solved my problem.
I'm developing with Play 2.1.1-RC1 in ~run mode.
Is there a way to avoid checking of all the dependencies each time I update my classes?
For example excluding org.hibernate.javax.persistence, be.objectify.deadbolt-core and others would cut compilation time from 14 to 3 secs for me.
ADDITION:
I've found that it's possible to add "offline := true" to Build.scala and plugins.sbt. With this option it stops resolving from remote repos, but still it takes around 10 secons to resolve from local one. I'm looking for a way to disable resolving completely. My goal is to minimize compilation time as much as possible.
Use run instead of ~run.
Check out the play console instructions: http://www.playframework.com/documentation/2.0/PlayConsole
I wanted to know is there any way in IDEA putting debuggers' breakpoint to previous row where debugger has just passed and re-run that scenario again. Because when debugging a loop, it's a bit tedious going to a UI doing desired action for handling that case again. I think such feature is available in Visual Studio. I've tried to google it but unfortunately I could not found anything about it.
I've submitted an issue on IDEA's bug tracker but its status changed to won't fix with this comment:
This functionality is not supported by the JVM. It's not possible to
implement it in IntelliJ IDEA without JVM support.
http://youtrack.jetbrains.com/issue/IDEA-84257?projectKey=IDEA