I want to run my playN game in production mode as the development mode is too slow to test. I am not able to click and get the response for buttons and it updates very slow in dev mode. I have read that substituting the IP of the link with "localhost" will do. But even after i have done the same, It is too slow like before.
I need to run the html version only. How can I do this?
You should try running it having the test-html profile active. From PlayN's getting started page:
cd playn-samples/showcase
mvn clean package
mvn test -Ptest-html
Then just browse to http://localhost:8080/ once Jetty has started. I find it significantly faster than development mode. Just substitute the showcase with your own application.
Related
I am new to Clojure and not a pro in Javascript. I am watching the free part of the course on Reagent.
Following the instructions on the course's repo, after doing the git clone and the npm install, the author indicates running $ npm run dev. Everything seems to work fine. I can see the app on my http://localhost:3000/.
The favicon with the app's logo and its name is loaded on the corner of the browser's tab:
However, on the bottom of the web page, there is this error message from shadow-cljs:
shadow-cljs - Stale Output! Your loaded JS was not produced by the
running shadow-cljs instance. Is the watch for this build running?
Why is this happening? How should I fix it?
How to guarantee that the watch for this building is running?
Is there a simple command to run on terminal to check this?
Obs. 1: If this is relevant, my operational system is NixOS and this is my config file.
Obs. 2: I am not sure if this question is connected to my previous question on npm and Cider (Emacs IDE for Clojure) that happened while working with this same repo.
It is likely that this is due to you running npm run dev AND cider-jack-in.
I don't use emacs, so I'm not exactly sure what cider-jack-in does, but I believe it launches a new JVM. Since the npm run dev also did that you end up with two running JVMs, which also means two running shadow-cljs instances. That is not ideal and they will start interfering with each other leading to errors such as yours.
So, either you run npm run dev and use emacs to connect to that server. cider-connect or whatever is called should do that.
Or you don't run npm run dev at all and instead only cider-jack-in and then start the watch from the REPL.
Don't forget to first kill all java processes that might be running for that project. As long as there is more than one shadow-cljs process running for the project things will be weird.
This happens to me when I clicked on the build link BEFORE it has compiled. In which case, the link is displaying a previously compiled version, not the live version, and "watch" on code changes doesn't work either. Just wait for your terminal output to say "compiled" before clicking on the link.
I'm facing up a strange problem in Puppeteer with authentication.
I've written a script to take some screenshot of a website which required authentication.
In my local computer (windows), when running in command line as node.exe my_script.js; it's working fine (in headless moden which is the default mode).
I've written an upper Java program to manipulate it (dynamically set the path, the node modules path, run the process "nodex.exe my_script.js" every 30minutes, manage timeout of the process,...). It's still working directly running from Eclipse, in headless mode.
Then... I've built/packaged a JAR and running it in a cmd window: java -jar my_jar.jar... and then the script can't authentitcated on the website in headless mode (the answser page just write a message like "you need to be authenticated", which is managed by the http server).
To check what happen, I've just add an option in my nodejs script (so I do not modify my java upper program code) to run chrome in non headless mode; with option headless : false. And... it's working!
I let the option to run in non headless mode, and I create a Windows service to run my jar via a bat file, with the help of nssm... Just to test. I'm really happy to see that all is running fine without seeing any chrome GUI (maybe Windows disable GUI for service, don't know how).
Have I maybe missed something? Or is there a bug in Puppeteer or Chrome to manage authentication in headless mode?
Regards
Alex
I am just getting started with Packer, and have had several instances where my build is failing and I'd LOVE to log in to the box to investigate the cause. However, there doesn't seem to be a packer login or similar command to give me a shell. Instead, the run just terminates and tears down the box before I have a chance to investigate.
I know I can use the --debug flag to pause execution at each stage, but I'm curios if there is a way to just pause after a failed run (and prior to cleanup) and then runt he cleanup after my debugging is complete.
Thanks.
This was my top annoyance with packer. Thankfully, packer build now has an option -on-error that gives you options.
packer build -on-error=ask ... to the rescue.
From the packer build docs:
-on-error=cleanup (default), -on-error=abort, -on-error=ask - Selects what to do when the build fails. cleanup cleans up after the previous steps, deleting temporary files and virtual machines. abort exits without any cleanup, which might require the next build to use -force. ask presents a prompt and waits for you to decide to clean up, abort, or retry the failed step.
Having used Packer extensively, the --debug flag is most helpful. Once the process is paused you SSH to the box with the key (in the current dir) and figure out what is going on.
Yeah, the way I handle this is to put a long sleep in a script inline provisioner after the failing step, then I can ssh onto the box and see what's up. Certainly the debug flag is useful, but if you're running the packer build remotely (I do it on jenkins) you can't really sit there and hit the button.
I do try and run tests on all the stuff I'm packing outside of the build - using the Chef provisioner I've got kitchen tests all over everything before it gets packed. It's a royal pain to try and debug anything besides packer during a packer run.
While looking up info for this myself, I ran across numerous bug reports/feature requests for Packer.
Apparently, someone added new features to the virtualbox and vmware builders a year ago (https://github.com/mitchellh/packer/issues/409), but it hasn't gotten merged into main.
In another bug (https://github.com/mitchellh/packer/issues/1687), they were looking at adding additional features to --debug, but that seemed to stall out.
If a Packer build is failing, first check where the build process has got stuck, but do the check in this sequence:
Are the boot commands the appropriate ones?
Is the preseed config OK?
If 1. and 2. are OK, then it means box has booted and the next to check is the login: SSH keys, ports, ...
Finally any issues within the provisioning scripts
I have built a simple NaCl application. For running the application I use technique 2 described in Nacl Developer's guide, which means that instead of running a local server I load my application as unpacked extension to chrome. The application runs fine so far.
Now I want to experiment with nacl-gdb and attach my application to it at startup.
In the NaCl Developer's guide there are only instructions on how to attach nacl-gdb on an application that is run with local server(technique 1). I made a search to the internet and I ended up with the following approach in order to attach nacl-gdb for an application that is being ran with technique 2:
I enabled "Native Client GDB-based debugging" flag of Chrome.
I started chrome from a terminal like this: ./chrome "--nacl-gdb=gnome-terminal --
/media/sdb1/leonidasbo/AncientRoot/nacl_sdk/pepper_27/toolchain/linux_x86_glibc/bin/x86_64-nacl-gdb"
When Chrome launched, I navigated to my application.
With this approach, Chrome automatically started nacl-gdb when I opened my application.
However nacl-gdb tried to attach but with no success. The output was the following:
*This GDB was configured as "--host=x86_64-unknown-linux-gnu --target=x86_64-nacl".
Reading symbols from /opt/google/chrome/nacl_irt_x86_64.nexe...(no debugging symbols found)...done.
Don't know how to attach. Try "help target".
(gdb)*
It seems that gdb cannot attach to my application. I tried executing "target exec /path/to/my.nexe", but nothing changed.
Am I missing something here? Is there any other way to debug applications loaded as unpacked extensions with nacl-gdb?
My OS is Ubuntu 12.04 and I am using pepper_27 of nacl_sdk. Chrome version is 27.0.1453.93.
Thanks
I assume you were using this guide, which I was using earlier as well. It is out of date. These are the real instructions. It seems that the way you attach the debugger has completely changed, and it is no longer possible to use --nacl-gdb (that is planned for removal). You must manually attach the debugger by following these steps.
The full guide is here, but I'll summarize:
Launch Chrome with chrome --enable-nacl --enable-nacl-debug --no-sandbox --disable-hang-monitor.
Run <NACL_SDK_ROOT>/toolchain/win_x86_newlib/bin/x86_64-nacl-gdb (with no arguments).
Enter these commands into the gdb prompt:
(gdb) nacl-manifest <path-to-your-.nmf-file>
(gdb) nacl-irt <CHROME-DIR>/nacl_irt_x86_64.nexe
(gdb) target remote localhost:4014
Now you can use gdb as normal. (If you just want to run the application until it crashes, start by typing continue.)
I have a job in Hudson server A which builds an artifact and deploys it to Nexus. I have another job in a completely separate Hudson server B which needs to download the artifact and deploy it. This job is normally run manually, and the person running it needs to indicate which version of the artifact to deploy - they may not always want to deploy the latest version (e.g. to roll back to a previous known good version).
Currently, I achieve this by using a parameterized build, and require the user to pass in the artifact version number; the job then uses the Execute shell build step to run wget on a URL constructed using the parameter. This is error prone.
Ideally I'd like a plugin that lets the user browse the artifact versions in the Nexus repository and pick and choose the one to deploy, but I'm open to other suggestions. A plugin that also handles the download would be nice, but I can live without it as long as I can still get a string that I can use in shell commands.
I've looked through the available Hudson & Jenkins plugins around Maven style artifact repositories, but they all seem more concerned with pushing artifacts into repos rather than getting them back down.
I'm using Hudson's "Copy Artifact" in other jobs, to get artifacts from other Hudson jobs on the same server, but this doesn't work across different Hudson servers, which is why I've turned to Nexus (which we're already using anyway).
Does anyone have any suggestions?
I recommend using rundeck to execute your deployments.
There is a rundeck plugin for Nexus that enables rundeck to display a pull down menu of available versions in Nexus.
There is a rundeck plugin for Jenkins that can be used to invoke deployments using rundeck and kick-off post deployment jobs (like integration testing) inn Jenkins.