Hello I am currently making a website that uses PUG and every time I called a python script by using child_process and it will restart the express server which causes my environment to be gone. Is there a way to fix this?
Related
I installed NuxtJS v2.15.3 on my windows 10 system using NPM. When I try to run it using npm run dev using the integrated terminal of VSCode (also VSCodium), it just opens the nuxt.js file instead of running the server using the file.
I do not have any specific code to show here since it is just the default code we have as we run npm i nuxt. I found no way to tackle this as the same project ran perfectly on another Ubuntu machine. Any help is appreciated.
Main dependencies list:
nuxt: 2.15.3
bootstrap: 4.6.0
bootstrap-vue: 2.21.2
express: 4.17.1
I'm just getting back into trying some front end projects for the first time in a few years. Many npm-based javascript projects I try out end up taking a long time to start up in development mode even for Hello World-ish examples. In particular I'm trying out Nuxt.js.
Dev server startup takes about 100 seconds, and nothing seems to get cached so restarts (not hot reloads) take the same amount of time. My research into the project and known npm issues did not turn up any definitive root cause or ways to improve this yet.
I'm using emacs 26.1 in terminal mode on a 2018 13" MacBook Pro with a core i5, 8 GB of ram, and an SSD.
When I run npm run dev to startup the nuxt dev server I get repeated error in process filter: Args out of range: "\342", -1 errors related to some unusual characters they are using to try to make the output pretty. If I try the same thing in a vanilla Mac OS terminal the server startup goes 10x faster. Why do those errors occur, and why is it so much slower in an emacs terminal?
It turns out the repeated error in process filter issue may be caused by a bug in term mode that was recently fixed but might still be an issue in my version of emacs.
As a workaround, the following can get the nuxt dev server running in ~10s instead of ~100s in an emacs terminal on my mac by filtering out the repeated lines about the modules being built:
$ npm run dev | grep -v modules
Note that I tried using npm's options to adjust the log level but none seem to filter this output. If anyone knows a more "official" way of filtering this, or even better, if you know how to make it such that it doesn't try to rebuild the modules on every dev server start up, I'd be interested to know.
Edit: it might make sense to adjust the dev script command in the package.json file to include the grep filter, that way you can still just type npm run dev and get the workaround.
I use remote shh interpreter in PyCharm regularly, using the configured deployment. I often run remote programs from PyCharm GUI (using F5 key), that takes hours to complete (e.g. training a deep net). This unfortunately means that any network outage causes running script to exit and I have to run the script over again. Is there a way to detach the running script so it keeps running? In the sense similar to what screen or nohup is doing? I know I can run it in screen manually via ssh, but it is a bit inconvenient.
Ok. I found out that this feature is not implemented yet. There is however a suggested workaround
I've created my mule application, and i deploy it on mule ce 5.3.0 my question now is how to keep my server running which means even if i close my CMD (the window where my mule is running) my application keep running.
See here: https://developer.mulesoft.com/docs/display/current/Starting+and+Stopping+Mule+ESB#StartingandStoppingMuleESB-StartingandStoppingMuleViatheCommandLine
Starting In the Background
Use the cd command to navigate to the $MULE_HOME/bin directory.
Run the startup script according to the options below.
Unix: ./mule start
Windows: mule.bat start
To further add on to what Ryan said, you can also install Mule as a service if you're running on Windows. From then you can also configure your Mule server to start up every time your machine boots up.
You can do so using the following command:
mule install
I recently installed IBM MobileFirst CLI on my Mac, but I don't seem to be able to start the Server. See error below. I searched the internet and found that there is a bug in JDK which causes the JavaLaunchHelper error. I downloaded the beta version that supposedly fixes the issue from here - JDK Download Link
. But this doesn't help either. Any other help is appreciated.
Imayas-MBP:EmployeeDirectory imaya$ mfp start Initializing
MobileFirst Console. objc[18564]: Class JavaLaunchHelper is
implemented in both
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/bin/java
and
/Library/Java/JavaVirtualMachines/jdk1.7.0_80.jdk/Contents/Home/jre/lib/libinstrument.dylib.
One of the two will be used. Which one is undefined. Starting
server worklight. Server worklight start failed. Check server logs
for details.
/Users/imaya/.ibm/mobilefirst/6.3.0/server/wlp/bin/server: line 744:
18563 Abort trap: 6 "${JAVA_CMD}" "$#" > "${JAVA_CMD_LOG}"
2>&1 Error: The MobileFirst server failed to start. The port may be in
use by another instance of a running server, or the server may not
exist.
The JavaLaunchHelper error is not the problem here; Anyone using Java 7 will experience it, but things will work regardless.
The problem here is the second error:
The MobileFirst server failed to start. The port may be in use by
another instance of a running server, or the server may not exist.
Verify you do not have an already running server, that was started either by the CLI or by MFP Studio in an Eclipse installation.
In the command line, run mfp stop
In Eclipse, well, quit it
Make sure the Java process is not running
Then, start over. Using the CLI, create a new project and application and try to start the server. For example:
cd /Users/idanadar/Desktop
mfp create testProject
cd testProject
mfp add hybrid testApp
mfp start
mfp build
mfp deploy
mfp console
On OSX, you can locate and kill a process holding open a port using the following:
Run (assumes port 10080):
$ lsof -i :10080
Then if a process is shown, run the following using the shown Process ID:
$ kill -9 {PID}