Ember-cli is building very slowly with ember server on windows.
Build successful - 13126ms.
Slowest Trees | Total
-------------------------------+----------------
TreeMerger (vendor) | 3154ms
TreeMerger (stylesAndVendor) | 2051ms
TreeMerger (appAndDependencies) | 1914ms
StaticCompiler | 1791ms
This is in contrast to the same project building in less that 1 second on a linux box.
There are two big culprits:
Real time file system scanning or protection
Realtime-protection from Windows Defender (also know as Microsoft Security Essentials in win7)
Windows Search Indexing
Antivirus scanning
Unused files in your bower_components folder
Real time Scanning
During a build numerous files are generate in the ./tmp folder of the ember project, both the indexer and the realtime-protection make additional reads of each file which adds a significant amount of additional file I/O operations.
The fix is to:
exclude node.exe and/or the ./tmp folder from realtime-protection, and
exclude the folder from indexing.
Disable real-time antivirus scanning
This should get your build time down to a couple seconds. Additional speed improvements for Windows are being investigated continuing to be investigated in relation to Broccoli's handling of the build process.
Managing unused bower files
Having lots of files in the bower_components is the biggest culprit.
I wrote up a script, clean-ember-cli.js, that deletes everything but ember-cli dependancies, and anything imported in the Brocfile.js. I'm getting back to around 5 second build times.
Update
Reports are that running console as admin also helps.
Official recommendation from ember-cli to improve its performance on windows
Install ember-cli-windows with node using the below command
npm install -g ember-cli-windows
Run the following command on your project root folder
ember-cli-windows
mind one important thing... and I didn`t found out in any forum... if you are working with a laptop and you are not connected with AC, windows may run in low performance mode to keep battery. This cause ember build proyects 4 times slower
Using ember-cli 1.13.13 with a command prompt running as an administrator fixed it for me
In addition to answers provided above run
ember s
in powershell in admin mode. This enables symlinks which are not enabled by default in windows. Having symlinks creates a flatter node_modules folder which results in faster running times.
(Source)
From build 20262 Windows 10 have WSL 2.
This is Linux on your machine and gives us performance as good as
on Linux.
Get last Ubuntu from Microsoft store.
Do not use /mnt/ folder for repo because of slow speed,
use ~ folder.
Connect with terminal on Ubuntu and clone your repository.
cd ~
git clone your-repo
install node version manager and node
Install ember-cli and start server.
npm install -g ember-cli
cd ~/your-repo
npm i
ember serve
In VSCode install plugin "Remote - WSL", open your repo and start development.
With Windows 7 I got a 50% improvement by turning off Encrypting File System (EFS) for the project's /tmp directory. (right-click Properties->Advanced->Encrypt contents...)
For later versions of Ember CLI running in admin mode as mentioned here and suggested by D-Go in his answer seems to be the way to go, assuming your company allows this.
If like me you are using GIT Bash to run Ember you may be interested in how to set it up to automatically run in admin mode here
Related
Goal
I've read many Electron tutorials about app bootstrapping and build pipeline and had assumed that you could have a single project to handle a cross-platform action.
But after numerous failures in the packaging and build process, I finally realized that maybe my assumption is wrong.
Problem
Here is my desired workflow based on electron-forge:
1. Create app skeleton on Windows
yarn create electron-app my-app
cd my-app
yarn add my-dependency
yarn start
yarn make
This all went well. Now onto macOS
2. Transfer project to macOS for a ride
On macOS, running the app will lead to an error
cd my-app
yarn start
The error looks like this
$ yarn start
yarn run v1.22.4
$ electron-forge start
✔ Checking your system
✔ Locating Application
✔ Preparing native dependencies: 1 / 1
✔ Launching Application
/path/to/my-app/node_modules/electron/dist/electron.exe: /path/to/my-app/node_modules/electron/dist/electron.exe: cannot execute binary file
error Command failed with exit code 126.
info Visit https://yarnpkg.com/en/docs/cli/run for documentation about this command.
So I blindly reinstall electron on macOS
yarn add electron
yarn start
yarn make
Things work fine on macOS.
Now back to Windows.
3. Travel back to Windows to double-check
This time. I got the similar problem as in Step #2. The Windows distribution now has the wrong Electron binary.
Findings
I found this file constantly getting overwritten even if I merge carefully when transferring project files between Windows and macOS.
my-app/node_modules/electron/path.txt
It contains a hardcoded path to Electron executable:
macOS
Electron.app/Contents/MacOS/Electron
Windows:
electron.exe
Workarounds
I could add pre-build steps against this by copying predefined metadata to the project folder depending on the current platform. But a hack like this sounds lame for a framework like Electron.
Question
So to me this metadata arrangement makes it difficult to share the same project between Windows and macOS. I can't imagine Electron developers working like this.
So What am I missing?
Basically, you shouldn't commit node_modules at all. Some post installation scripts may compile packages for a specific OS and the folder is usually huge.
Also, you shouldn't commit any result of a build, package or compile command. Typically, dist folders should be ignored.
Your repository should only contains code and configuration files.
The idea is that it makes no sense to commit these files and folders as you have all the required steps in order to reproduce the result on any machine: your windows computer, your macOS computer, your CI environment, etc. For example (these are pseudo-commands):
npm i or npm ci
npm run build
electron package
etc
So you should add all these folders to you .gitignore file:
# compiled output
/dist
/tmp
/out-tsc
/packages
# dependencies
/node_modules
So I am trying to use Qtcreator on ubuntu 18.04 and am starting to wonder if i should just return to visual studio. When I run QtCreator now it is changing permissions of various .Cpp files aswel as files in my .config folder. I assume it is not good practice to run QtCreator as superuser, so there must be some alternative solution. I have never experienced this on any other system where I setup QtCreator so Im wondering what has changed now? Any hints in the right direction are greatly appreciated. I've never had so many configuration problems with any IDE before, has something being 'upgraded' in recent versions of either Ubuntu or Qt??
Are you running QtCreator as root?
Then indeed, every time you save some files permissions will change.
If you are running the QtCreator shipped with the SDK, and not the one from the packages, I presume you installed it in /opt
Also, QtCreator stores its configuration inside one .config subdirectory, which will again be chowned to root if you run QtCreator as root.
My suggestion:
1 - chown the ~/.config dir recursively back to your user
2 - chown the sources
3 - run QtCreator without sudo / su
If you can't run QtCreator as your normal user, then maybe there's a problem with your SDK installation. To ensure you have rw access to the SDK you can run the SDK installer without sudo and install everything to a subdirectory of your home directory instead of /opt.
As a follow up to this question, the QtCreator seems to lock its config files when it is starting up, and if anything goes wrong on startup, these files are trapped in some locked state. Best course of action is to restart QtCreator exactly as normal, this will resolve the locking issue usually, but sometimes you have to restart the whole system, depending on the severity of the startup problem. Dont do as I did and try to chown/chmod the files, your only digging deeper.
I would like to build/launch the VSCode source code in the native Bash for Windows client. I have followed the steps outlined in the VSCode wiki on how to contribute, and everything is working as expected (All commands have been run on the WSL terminal following the Linux instructions)
After running yarn run watch, I try to launch VSCode by running DISPLAY=:0 ./scripts/code.sh from the source code directory, but nothing happens. I get two duplicate warnings:
[21496:1128/120229.392130:WARNING:audio_manager.cc(295)] Multiple instances of AudioManager detected
but I'm not sure if this is causing the problem. I have an X Server client running, and have used to to successfully launch native Windows applications through WSL (terminator, emacs, etc.)
Is what I'm trying to do possible? If so, how can I make it work?
Amazing that you asked this! I was attempting to do the exact same thing at (it seems) the exact same time. Here's my process.
Install XMing
Install the xfree apps
Set DISPLAY=:0
Run xeyes ==> Awesome googly eyes!
Attempt to build vscode from source. The build docs seem to be incomplete b/c I had to install a ton of libraries beyond those listed e.g.
yarn
gulp
gulp-cli
pkg-config
libx11-dev
libxkbfile-dev
libsecret-1-dev
libgtk2.0-dev
libxss-dev
gnome-dev
libgconf2-dev
libnss3-dev
libasound2-dev
Eventually get the yarn tasks to finish such that I could run code.sh
./scripts/code.sh
[20474:1128/153959.035267:ERROR:bus.cc(427)] Failed to connect to the bus: F
ailed to connect to socket /var/run/dbus/system_bus_socket: No such file or
directory
[20474:1128/153959.081986:WARNING:audio_manager.cc(295)] Multiple instances
of AudioManager detected
[20474:1128/153959.082101:WARNING:audio_manager.cc(254)] Multiple instances
of AudioManager detected
Looking at ps I see that the process was running.
Conjectures
It seems that building from source from WSL is not yet supported. Or maybe you can build the artifact, but you can't connect to the Windows display to show it. Based on the quality of the xeyes session, it looks like a very, very, very primitive experience e.g. still using WinXP-style minimize / maximize / close icons.
I was literally writing an Issue on their github page when I thought I'd do one last search and found this post. Much of vscode treats WSL as a second-class environment on Windows. Recent work seems to suggest that things are going to get better as driving to integration between Windows' two internal environments continues to improve (e.g. https://github.com/Microsoft/vscode/issues/39144)
Update 2017-11-30
Based on some pursuit via Github, it seems that this issue has been reported to the WSL team: https://github.com/Microsoft/WSL/issues/2293. It appears to be under active consideration by the WSL team. I've added some commentary about my use case there.
I'm having a hard time using assetics to load resources in my views (I work with Symfony2).
I was working on Linux (Ubuntu 10.4) and switched to Windows 7 a few days ago. I've always been having trouble (some images didn't load for example), but at least most images, and all styles and scripts were loading alright.
When I switched to Windows, some resources weren't loading, so I tried a php app/console assets:install web --symlink
I was quite surprised to see that it had deleted the whole public folder of the bundle I was working on. And there was no way to find the sources again (fortunately, I had saved some of them, and I was able to retrieve most of my work thanks to cached files).
After I've recovered my files (and backed them up), I tried to command again. Same result. I tried without the --symlink and it created some folders in the web/bundle folder, instead of files that were there before (supposedly, the symlinks).
Now the command doesn't even answer anymore (it has been erasing my sources even in some of my backup folders!!).
Bottom-line : is there a way to configure assetics on Windows 7 so that it doesn't eat my files and loads the resources (including images in css) correctly?
Thanks in advance!
Edit :
I just ran the command again and this time it worked (copied the files in web/bundle/...). I must say I don't really understand how or why it worked this time... If by chance anyone knows...
In order to run assets:install web --symlink on a PC you need an elevated command prompt (fancy word for cmd.exe in Administrator mode).
Symfony2 uses the PHP symlink function, according to the docs it should work for Windows Vista, Server 2008 or greater.
By default only Administrators can create symlinks in Windows. So you'll have to use an elevated prompt or give your user the SeCreateSymbolicLinkPrivilege privilege.
You can do it with windows console, but Git Bash is much nicer. Get it and download. Ps. If you never used git before this is the right time to start. :)
When you installed it search in windows programs for git bash and right click it to run as administrator. If you have Git bash opened from the right click in the current folder "git bash here" it wont work because it is not launched by default in administrator mode. If you done this you get this warning.
app/console assets:install web --symlink
Warnings. Hard copy where used instead of symlinks.
However if you play nice and do it as i said. (run as administrator.. you will get everything work nice and smooth.
app/console assets:install web --symlink
Symlinks where created! :) Now you don't need to assets:install every time you made changes to your css files.
Ps. git bash console is nicer then native windows console but... for example Unix system such as Ubuntu would look even better. Also Symfony on Windows with Xamp will run much slower than on Linux Ubuntu system. I am talking about 5x to 20x faster page response on Linux.
You can use configure the composer.json and use forever without any problems,puting in it --symlink.Here is how you can do it.
http://www.w3docs.com/snippets/symfony/how-to-keep-symlinks-in-web-bundles-after-composer-update.html
You can add this configuration option in your composer.json:
{
"extra": {
"symfony-assets-install" : "symlink",
}
}
Tonight I decided I'd try to build a simple Node.js application using Express on my Windows 7 machine. The installation went fairly smoothly, but Express refuses to cooperate. Here are the steps I've taken:
Installed Node.js using the MSI available at http://nodejs.org/dist/v0.6.9/node-v0.6.9.msi
Installed Express by running npm install express g from a command prompt.
Created a directory for the application c:\source\node> mkdir newapp.
Changed directory to the application directory c:\source\node> cd newapp.
Ran Express: c:\source\node\newapp> express --sessions --css stylus.
At this point the node.exe process fires up and runs endlessly at 25% CPU Time and continually uses more memory. After running for 20+ minutes the node.exe process uses 300+ MB of Memory. The express command never completes and the newapp directory remains unaltered.
If I run express --help I see the help output in the console. I've tried running the command prompt as and Administrator but still Express appears to hang.
Does anyone have a clue what's going on or what I'm doing wrong? Thanks in advance!
This is a bug in the Windows version of Node v0.6.9. Filesystem access is pretty much messed up. Rollback to v0.6.8 http://nodejs.org/dist/v0.6.8/node-v0.6.8.msi and you should be fine.
The Express.js command line on Windows doesn't quite work well either. I just tried with Node v0.6.8.
This works
express --sessions myapp
This doesn't work for me
express --sessions --css stylus myapp
Fortunately you can add stylus support manually in your generated app. Open up app.js and in the app.configure function, add:
app.use(require('stylus').middleware({src: __dirname + '/public'}));
Hope this helps!
Update:
Oh ya, don't forget your NPM commands. In your app directory, you may need to npm install jade and npm install stylus.