In my quest to gather knowledge about how to use Velocity, I ran across a snippet that mentioned a shell variable to set the browser Velocity used to run Karma in PhantomJS as apposed to creating a Chrome window pop-up each time I run my app in DEV-mode. At the time I shrugged it off, but after having implemented some testing in two of my apps, I can say it's an annoying pain to have the tests running in a pop-up window.
Does someone know if how one might get the tests running such that they run in PhantomJS and not in a Chrome pop-up windows? I thought the variable was something like VELOCITY_BROWSER=PhantomJS, but that doesn't seem to work. Also, is there a way to setup Meteor so that it simply sets this as a default so I don't have to create the variable each time, like in a config or something?
I found the answer for those that find this and were also wondering how to prevent the Karma popup.
I am using the sanjo:jasmine test suite, which uses Karma for the client integration tests. You can set the default browser to PhantomJS by simply adding this to your environment when you run meteor:
JASMINE_BROWSER=PhantomJS
Or, if you just want to turn off client integration tests altogether simply adding this:
JASMINE_CLIENT_UNIT=0
So, for instance you can run your app like JASMINE_BROWSER=PhantomJS meteor, and you will not get the popup any longer. What I did was created a meteor.sh in my app root folder that I use to launch with environment variables like so:
#!/bin/sh
JASMINE_BROWSER=PhantomJS meteor
This is only for convenience so I wouldn't have to remember the variable to do this. This should work on any *nix-based OS. You could also make an alias if you wanted. It would look something like:
alias meteor=JASMINE_BROWSER=PhantomJS meteor
I may be slightly off in the syntax, but I think that should work.
To use PhantomJS you do need to have it installed, so run this in a terminal:
npm install -g phantomjs
Or, if you are on a Mac run (you will need brew installed):
brew install phantomjs
Hope this helps someone in the future.
In sanjo:jasmine 0.17.0 on Windows, PhantomJS has some issues with meteor's autoupdate feature. You may have problems with re-running tests when you change the app's code.
If you'd like to stick with Chrome window, it can be somewhat hid by using chrome's commandline options, but you'd need to update karma-chrome-launcher\index.js to include these:
return [
'--user-data-dir=' + this._tempDir,
'--no-default-browser-check',
'--no-first-run',
'--disable-default-apps',
'--disable-popup-blocking',
'--disable-translate',
'--window-position=-800,0', // <-- added
'--window-size=800,600' // <-- added
].concat(flags, [url])
The window will show up, but will be created off-screen, and somehow luckily doesn't even steal the keyboard focus.
Related
In my Android Things app, I need to use su from runtime. However, Android Things system is built as userdebug build, so I can only access it from adb. I tried to both replace su binaries with no luck. I tried to disable ro.secure by unpacking and repacking boot.img, however flashed system still returns getprop ro.secure 0. How can I achieve root in my Android Things device?
I had these scripts working on a quite early preview version, maybe 0.1 or 0.2. https://github.com/fmatosqg/androidthings_ndk/tree/master/app/src/main/script
Although I had to run it manually, there should be a place where I can add this script so it runs every boot, just like linux's /etc/rc.d
I don't remember how I got the script to work, but the idea is that one script simply exists to launch the other running as superuser, similar to what you would expect with sudo <insert command here>
Using atom-editor 1.13 with the love-ide package installed to run LOVE2d 10.2 games (windows 7)
Apparently if you create a conf.lua file in the same folder as your main.lua file you can add some configuations to main.lua. So, I've got these lines of code in my conf.lua to show console.
function love.conf(t)
t.console = true
end
But when I go back to my main.lua and type print("ballz"), all I see is a blank LOVE2d game screen with no extra console window. Not really sure if this is because I'm using atom editor or not. Everything seems to be PATH'ed correctly.
On a side note, whenever I run atom using the love-ide package it always tries to install some "dependecy files" like the hyperclick-love package, and the auto-complete-love package. These fail to install because I don't have git installed.. honestly I really don't know what git is, but neither it, hyperclick, or auto-complete seemed like requirements to run my game, so in the spirit of not installing unnecessary things onto my computer I never installed these things... annoying as it is to see this notification always pop up when I start atom. Anyone know if this is contributing to the issue, or know a way to remove these notifications or auto-download-attempts? My LOVE2d code still seems to run without these packages.
Have you set up the terminal emulator in your configuration?
(Windows only) Try using the lovec.exe executable instead of the normal love.exe. The first one attaches to the console that executed the game, the second one ignores it.
Lua has a buffered output, try adding io.stdout:setvbuf('no') to the top of main.lua
Mostly all of the testing lines printed to the console get in my way, especially when I'm just setting up a new project or trying to get this one code bit down that the testing framework isn't too helpful for. Any help is appreciated!
I was able to disable Velocity via
VELOCITY=0
Before running the server, so basically I ran
VELOCITY=0 meteor run
Keep in mind that creating a new Meteor project doesn't install Velocity or Mocha by default, so if you have them it's probably because they were manually installed or part of a boilerplate project that you're using.
Having said that, I think it's safe to remove these packages. More than likely, if you have Velocity and Mocha installed, you need to run the following:
meteor remove mike:mocha velocity:core
There might be other testing-related packages that need to remove. To find out what other packages are installed for your project, you can run the following:
meteor list
Then just remove individual packages as needed.
In addition to the VELOCITY=0 environment variable, I've found that pressing Ctrl+V in the client window will temporarily disable Velocity on that client, which will stop the tests from printing things in the console. Pressing it again will re-enable it.
I'm using webstorm for meteor dev.
I've configured a meteor project, and can run my app
however, making a change doesn't trigger the meteor server to restart or rebuild, as it does when running a normal server instance.
Looking at the command being run, they have inserted --once into the command line:
/usr/local/bin/meteor --once run --settings private/local.json
I've added the --settings option in the config dialog.
is there a way to remove that? I guess it will mean a lot of restarts with how webstorm works but so be it. the alternative - manually restarting the whole server all the time is not usable.
http://blog.jetbrains.com/webstorm/2014/09/meteor-support-in-webstorm-9/
When WebStorm runs Meteor it uses the -once which disables Meteor’s
auto reload feature. The reason for this is that the way it currently
works is incompatible with WebStorms autosave option. We are working
with the Meteor team/community to try and think of ways in which we
could provide this feature from within WebStorm. But that it still in
the works.
WebStorm's autosave feature is evil, and hundreds of people have complained about it.
WebStorm should run meteor without the --once parameter, which will enable you to save when you deem it's a good time to do so. To that effect, disable Appearance & Behavior -> System settings -> Save files on frame deactivation and Save files automatically if..., and assign a keyboard shortcut to File -> Save or File -> Save All.
UPDATE
Funny how this has -1 votes, when JetBrains has recognized the problem and fixed the issue in WebStorm.
I couldn't find a way to remove it but I was able to create a Bash script to run my server command instead of doing it in the console. I'm using PhpStorm I believe it should be the same.
The first thing you need to do is create a simple bash script which is essentially is the code you'd run in console. Below is my code:
#!/usr/bin/env bash
meteor --settings settings.json
Once the file is created, go to Run->Edit Configurations.
Under Defaults select Bash and click the plus sign at the top left of the modal.
Name your script. Name:
Reference your script. Script:
Select Run '[Script Name]' from the Run menu.
Hopefully this is helpful and helps a few people.
Does anyone know a good method to debug server side code?
I tried enable Node.js debug then use node-inspector but it does not show any of my code.
I end up using console.log but this is very inefficient.
Update: I found the following procedure works on my Linux machine:
When you run Meteor, it will spawn two processes
process1: /usr/lib/meteor/bin/node /usr/lib/meteor/app/meteor/meteor.js
process2: /usr/lib/meteor/bin/node /home/paul/codes/bbtest_code/bbtest02/.meteor/local/build/main.js --keepalive
You need to send kill -s USR1 on process2
Run node-inspector and you can see your server code
On my first try, I modify the last line on meteor startup script in /usr/lib/meteor/bin/meteor to
exec "$DEV_BUNDLE/bin/node" $NODE_DEBUG "$METEOR" "$#"
and run NODE_DEBUG=--debug meteor on command prompt. This only put --debug flag on process1 so I only see meteor files on node-inspector and could not find my code.
Can someone check this on Windows and Mac machine?
In Meteor 0.5.4 this has become a lot easier:
First run the following commands from the terminal:
npm install -g node-inspector
node-inspector &
export NODE_OPTIONS='--debug-brk'
meteor
And then open http://localhost:8080 in your browser to view the node-inspector console.
Update
Since Meteor 1.0 you can just type
meteor debug
which is essentially a shortcut for the above commands, and then launch node inspector in your browser as mentioned.
Update
In Meteor 1.0.2 a console or shell has been added. It may come in handy to output variables and run commands on the server:
meteor shell
Meteor apps are Node.js apps. When running a Meteor app with the meteor [run] command, you can configure the NODE_OPTIONS environment variable to start node in debug mode.
Examples of NODE_OPTIONS environment variable values:
--debug
--debug=47977 - specify a port
--debug-brk - break on the first statement
--debug-brk=5858 - specify a port and break on the first statement
If you export NODE_OPTIONS=--debug, all meteor command run from the same shell will inherit the environment variable. Alternatively, you can enable debugging just for one run, with NODE_OPTIONS="--debug=47977" meteor.
To debug, run node-inspector in a different shell, then go to http://localhost:8080/debug?port=<the port you specified in NODE_OPTIONS>, regardless of what node-inspector tells you to run.
To start node.js in debug mode, I did it this way:
open /usr/lib/meteor/app/meteor/run.js
before
nodeOptions.push(path.join(options.bundlePath, 'main.js'));
add
nodeOptions.push('--debug');
Here are additional practical steps for your to attach debugger eclipse:
use '--debug-brk' instead of '--debug' here, because it's easier for me to attach node.js using eclipse as debugger.
add 'debugger;' in the code where you want to debug.(I prefer this way personally)
run meteor in console
attach to node.js in eclipse(V8 tools, attach to localhost:5858)
run, wait for debugger to be hit
when you start meteor in your meteor app folder, you'll see that "debugger listening on port 5858" in console.
On Meteor 1.0.3.1 (update to Sergey.Simonchik answer)
Start your server with meteor run --debug-port=<port-number>
Point browser to http://localhost:6222/debug?port=<port-number>
Where <port-number> is a port you specify.
In your code add a debugger; where you want to set your break point.
Depending on where debugger; is invoked, it will either break on your client or server browser window with inspector opened.
I like to set breakpoints via a GUI. This way I don't have to remember to remove any debugging code from my app.
This is how I managed to do it server side for my local meteor app:
meteor debug
start your app this way.
Open Chrome to the address it gives you. You MAY need to install https://github.com/node-inspector/node-inspector (it might come bundled with Meteor now? not sure)
You'll see some weird internal meteor code (not the app code you wrote). Press play to run the code. This code simply starts up your server to listen for connections.
Only after you press play you'll see a new directory in your debugger folder structure called "app". In there are your meteor project files. Set a breakpoint in there one the line you want.
Open the local address of your app. This will run your server side code and you you should be able to hit your breakpoint!
Note: you have to reopen the inspector and go through this process again each time your app restarts!
As of Meteor 1.0.2 probably the best way for server-side debugging is directly via the new built-in shell: with running server run meteor shell. More info here: https://www.meteor.com/blog/2014/12/19/meteor-102-meteor-shell
I am not sure why it was not working for you.
I am able to use it by following steps on console (Mac).
$ ps
$ kill -s USR1 *meteor_node_process_id*
$ node-inspector &
Above steps are mentioned on https://github.com/dannycoates/node-inspector. It is for attaching node-inspector to running node process.
I wrote a small meteor package called meteor-inspector which simplifies the use of node-inspector to debug meteor apps. It internally manages the lifecycle of node-inspector and hence, the user does not need to restart the debugger manually after some files have changed.
For more details and concrete usage instructions take a look at https://github.com/broth-eu/meteor-inspector.
for meteor 1.3.5.2, run
meteor debug --debug-port 5858+n
n is a non-zero number, this will cause node-inspector use 8080+n as web port.
WebStorm, the powerful IDE free for open source developers, makes it much easier to debug server-side.
I've tested it on Windows, and the configuration was painless - see my answer.
A inspector that solve my issues is meteor server console. Here is the process I followed to install it:
In your project folder, add the smart package server-eval:
mrt add server-eval
For Meteor 1.0:
meteor add gandev:server-eval
Restart meteor.
Download crx Chrome extension file from here.
Open extensions page in Chrome and drag crx file to extensions page.
Restart Chrome.
Check the web inspector out to eval server side code:
In comparison with node-inspector, I have a clearer output.
If you prefer to use nodeJS' official debugger you can call NODE_OPTIONS='--debug' meteor and then (on a different shell) node debug localhost:5858.