After creating an escript app:
$ rebar3 new escript hello
Can I run with with rebar3, instead of calling escriptize first?
I.e. something like this?
$ rebar3 run
One solution might be to add a "run" directive to your makefile instead - this way you can call make run which does the escriptize step and runs the result.
Depending on what you really want to achieve running ./rebar3 shell might help you - I do this sometimes so I can debug portions of code just by running the required functions.
Finally you could always write a rebar plugin that extends the escriptize step ;) - never done it myself for rebar3 but has to be easier than the old rebar...
Related
I currently have a build of an application that is set to run infinitely. It is designed to run on a Raspberry Pi as a service, so it will continuously be running.
Whenever I try to test it on Travis-CI, the infinite loop portion draws an error even though the file builds correctly since it is running infinitely. Is there any way to stop this error, or do I have to remove the ability to run the build from the .travis.yml?
language: cpp
compiler:
- clang
- g++
script:
- make
- cd main
- ./jsonWeatherPrediction
I would expect it to error, I'm just not sure of a current way to stop it without removing - ./jsonWeatherPrediction
I don't know if this will help, but the build is located at https://travis-ci.org/DMoore12/json-weather-prediction
Thanks in advance :)
In most any reasonable CI workflow, the job should have well-defined start and finish. Your software you are testing may run forever, but your tests should not. So, first, I suggest re-thinking how you run your build.
Looking at build such as https://travis-ci.org/DMoore12/json-weather-prediction/jobs/474719832, I see that you are simply running your command (which raises a different question: The command is printing the same output forever in a tight loop. Is this the desired behavior?).
For testing, you need a different kind of behavior, one that can be tested (e.g., take input from STDIN or a command-line flag, print, and terminate).
bazel run typically occupies the Bazel server, blocking other commands.
https://github.com/bazelbuild/bazel/blob/c484f19a2cf7427887d6e4c71c8534806e1ba83e/scripts/bazel-run.sh is a fantastic replacement
Question: what's a good way for end-users to get hold of that shell script and add to their path? Can we make that part of the bazel install?
I tried ls -R $(bazel info install_base) | grep bazel-run but no luck there.
Bazel run is a good replacement for end-user to run a Bazel command if you need to run interactively or multiple command (#2337). There has been no need for us to consider it as an installation script.
Please file an issue on Github to discuss the possibility of installing it along with Bazel.
I am looking for solution where I can set my javascripts with order and when each script would start it would be independent on previous scripts. So I can run just one script or group of them and it would be working same.
I find that I can create one script file and use #import keyword, something like this:
#import "AddStaticContentMissingName.js"
#import "AddStaticContent.js"
It's working and both scripts are running but second one starts where first one ends and that is what bothers me. I can set first one to end when the second one needs but I don't like it. I just one to script do what should test and then end. So is it possible to before each test restart application or something like that? I want to have UI testing automate as possible so what or you using? Or are you using another tool then UI Automation?
Bonus question: I was looking for solution how to run this from command line and/or with Xcode Server. I guess Xcode Server is problem but for command line there is a solution. Problem with solution which I found is that I isn't portable right? I don't have any way how can I add some script to my repository and if someone try use it there would be problems with paths. Example of command I found:
instruments \
-w your_ios_udid \
-t "/Applications/Xcode.app/Contents/Applications/Instruments.app/Contents/PlugIns/AutomationInstrument.bundle/Contents/Resources/Automation.tracetemplate" \
name_of_your_app \
-e UIASCRIPT absolute_path_to_the_test_file
If you want to reset the application between scripts, you need to do it yourself with a combination of app code and UIAutomation code. (Apple will be replacing Instruments with something that works better, but for now this is the only way.)
For example, if your application doesn't use the "shake" gesture for anything, you could use that to trigger a restart within your app (not closing it, just returning it to a known state). Then at the top of every UIAutomation script, you could just call the method for the shake gesture.
In the testing framework we wrote, we set up our own RPC channel to allow us to expose non-UI functionality (like resetting the app) to automation scripts. It really doesn't matter what system you use to make it happen, as long as you can reliably get the app to a known state.
I might be too late for this but it's totally possible to accomplish what you want. Basically, create a bash script (or any other script) and include the commands to run your two automation scripts:
#!/bin/bash
instruments -w <UDID> -t <template> <app> -e UIASCRIPT <script1>
instruments -w <UDID> -t <template> <app> -e UIASCRIPT <script2>
Run that and your app will restart after the first script creating a trace file per run.
I am trying to contribute more with couchdb code, but I have really no idea how it is done the right way.
I have cloned the source from apache git repository and built it with
./configure
make && sudo make install
Then I wanted to change a file from the source called couch_httpd_show.erl
Do I need to run make && sudo make install again for every change I make to the source code and want to see how it behaves?
I am sure there's a more practical way to do it, because this approach is a bit time and patience consuming right?
Yes, there is a shortcut.
./configure
make dev
./utils/run
This builds and runs CouchDB entirely in the current directory. Instead of running as a background daemon, CouchDB will run in the foreground and output log messages to the terminal. It uses some local directories to store stuff: ./tmp/log for logs, ./tmp/lib for databases, and (if I remember correctly) ./etc/couch/local_dev.ini for configuration.
If you run this instead:
./utils/run -i
then you will also have an interactive Erlang prompt, which you can use to help debug.
When I work on CouchDB, I run this in the shell:
make dev && ./utils/run -i
After I change some code, I press ^C, up-arrow, return.
When I joined Couchio, I was responsible for production CouchDB deployments. I asked Chris Anderson for advice about something and he said, "Sorry, ask Jan. I've been just using utils/run for years!"
You can rebuild that one file and drop the output beam in place and restart.
erlc <file.erl>
& then copy the .beam file into place. To restart couchdb use either init:restart(). in the erlang shell or POST /_restart to CouchDB.
Although you might want to consider using the commandline erlang & javascript test suite also to ensure you didn't break anything.
I have erlang application: *.app file and some *.erl files. I compile all of them. In terminal i start erl and there application:start(my_application)., all ok, but if i closed terminal application close too. How can i run application without terminal depending?
Thank you.
You likely want to use the -noshell option to erl. The syntax is
erl -noshell -s Module Function Arguments
So in your case, this might be
erl -noshell -s application start my_application
This should allow you (for example if you are on Unix/Linux) to start your application as a background process and leave it running.
One useful variation is to also call the stop/0 function of the init module so that the Erlang environment will stop when it has finished running your function. This comes in handy if you want to run a simple one-use function and pipe the output to some other process.
So, for example, to pipe to more you could do
erl -noshell -s mymodule myfunction -s init stop | more
Finally, you might also be able to use the escript command to run your Erlang code as scripts rather than compiled code if it makes sense for your situation.
Hope that helps.
The proper way to handle this situation, is building a release containing your app and running the system as so called embedded one.
This release is going to be completely independent (it will hold erts and all the libs like, kernel, std, mnesia etc.).
On start, the new process will not be connected to shell process.
It will be OS process, so you can attach to it with pipes. All script are included in OTP.
Here is some info: http://www.erlang.org/doc/design_principles/release_structure.html
It may seem to be complicated, but tools like rebar do everything for you.