I have downloaded eclipse 3.4 (java version) for MacOSX (carbon). I have tried to 'update' to the erlide, but see many (duplicated) options (many erlide, options that say 'only for erl SDK updates', etc.) Sometimes I get 403 errors when attempting to access http://erlide.org/update and http://erlide.sourceforge.net/update.
Finally, when I get some set of options installed, I either get errors like :
Loading of /Users/kevindtimm/Documents/eclipse-java-ganymede-SR2-macosx-carbon/eclipse/plugins/org.erlide.kernel.common_0.8.1.201005250801/ebin/erlide_kernel_common.beam failed: badfile
(hello_world#ktmac)1>
=ERROR REPORT==== 24-Nov-2010::19:17:32 ===
beam/beam_load.c(1768): Error loading function erlide_kernel_common:monitor/0: op put_string u u x:
please re-compile this module with an R14B compiler
or, when I've done different installations of erlide, I get no response in the console to :
hello:hello().
Does anybody have a good reference for how to load this plug-in and which items I should install?
-module(hello).
-export([hello/0]).
hello() -> io:write("Hello World\n").
[edit]
I have installed eclipse 3.6 (c++) as requested below, and the following code still can't find hello:hello().
%%file_comment
-module(hello).
%%
%% Include files
%%
%%
%% Exported Functions
%%
-export([hello/0]).
%%
%% API Functions
%%
%%
%% Local Functions
%%
hello() -> io:write("Hello World\n").
[/edit]
It might be a little late for you, but maybe for others my set up might avoid some frustrations.
I have OSX 10.6.5, 64-bit and Erlang R14B installed.
After several false starts, I found the following worked:
Download the C++ version of Eclipse (I use the latest Helios, 64-bit, OSX)
Once extracted, start Eclipse
Open Help | Eclipse Marketplace (wait whilst it fetches data)
Type erlide into the search field and click Go
Proceed to install by following the instructions
Restart Eclipse after installing plugins (always a good idea)
Next, define an Erlang runtime, because this is not picked up automatically:
Open Eclipse preferences
Expand the Erlang entry shown on the left-hand side (do not select Erlang)
In the expanded list click on the Installed Runtimes entry
Define your runtime as appropriate
Restart Eclipse
Failure to do the above steps first, (i.e. opening a different Erlang preferences pane) causes an internal UI error inside Eclipse, that prevents you from closing the dialog. Thus, forcing you to kill Eclipse.
Finally, it is necessary to define a launch configuration before you can run your Erlang code inside Eclipse:
Open Run | Run Configurations
Select Erlang application
Add new launch configuration
Enter a name for the application
On the Erlang tab:
Check required project
On the Runtimes tab:
Make sure node is defined as erlide
Check "Start the Erlang node if not already running
Click apply
Anyway, I hope it helps somebody out there.
Related
I wish to use an erlang client library to communicate with an mqtt broker for one of my projects. So I've started an application using rebar3's built-in templates and added emqttc as a dependency. Since erlang/otp 21 does not have support for gen_logger(emqttc depends on gen_logger) and the tuple_calls compiler options do not suffice, I had to downgrade to erlang#20 according to this post.
Now the issue with downgrading erlang is that, none of rebar3's commands(clean/compile/shell/report etc) work as expected and my previous projects built with rebar3 do not compile, I get to see this error message:
=ERROR REPORT==== 21-Aug-2018::12:54:29 === Loading of /usr/local/bin/rebar3/rebar/ebin/rebar3.beam failed: badfile escript:
exception error: undefined function rebar3:main/1 in function
escript:run/2 (escript.erl, line 759) in call from escript:start/1
(escript.erl, line 277) in call from init:start_em/1 in call from
init:do_boot/3
=ERROR REPORT==== 21-Aug-2018::12:54:29 === beam/beam_load.c(1863): Error loading module rebar3: This BEAM file was compiled for a later
version of the run-time system than 20. To fix this, please
recompile this module with an 20 compiler. (Use of opcode 160; this
emulator supports only up to 159.)
I've uninstalled and reinstalled rebar3, looked up on the web for this but nothing's clear and specific to rebar. Any help on this would be appreciated.
This may not be the exact answer for your question. But it may give you and idea.
What about using Docker. Its an easy way to keep your environment clean and neat.
If you use docker, you just have to include your new erlang version in Dockerfile as an environment variable.
ENV OTP_VERSION="20.3.6"
Check your _build/prod/rel/YOURAPPNAME/ directory. Most probably it has a release which doesn't match your erlang version. You can safely delete this directory and rebuild using rebar3 compile
The problem
Most of the articles and books about Erlang I could find focus on creating long running server-like applications, leaving the process of command line tools creation not covered.
I have a multi-app rebar3 project consisting of 3 applications:
myweb - a Cowboy-based web service;
mycli - a command line tool to prepare assets for myweb;
mylib - a library used by both myweb and mycli, depends on a NIF.
As a result of the build I want to get such artifacts:
an executable for the web part that is going to serve HTTP requests;
an executable command line tool for the assets preparation;
a set of libraries used by the above.
Requirements
CLI should behave like a sane non-interactive command line tool: handle arguments, deal with stdin/stdout, return non-zero exit code on error, etc;
both server and CLI should be able to use NIFs;
it should be easy to package the artifacts as a set of deb/rpm packages, so both server and CLI should reuse common dependencies.
Things tried so far
Building an escript
One of the ways I've seen in the wild is to create a self-contained escript file. At least rebar3 and relx do so. So I gave it a try.
Pros:
has support for command line arguments;
in case of errors, it returns non-zero exit code.
Cons:
embeds all the dependencies in a single file making it impossible to reuse mylib;
since *.so files get embedded into the resulting escript file, they cannot be loaded at runtime, thus NIFs don't work (see erlang rebar escriptize & nifs);
rebar3 escriptize doesn't handle dependencies well (see bug 1139).
Unknowns:
Should the CLI app become a proper OTP application?
Should it have a supervision tree?
Should it be started at all?
If so, how do I stop it when the assets have been processed?
Building a release
Another way to build a command line tool was described in a How I start: Erlang article by Fred Hebert.
Pros:
Each of the dependency applications get into their own directory, making it easy to share and package them.
Cons:
there's no defined entry point like escript's main/1;
as a consequence both command line arguments and exit code must be handled manually.
Unknowns:
How to model the CLI OTP app in a non-interactive way?
How to stop the app when the assets have been processed?
Neither of the approaches above seem to work for me.
It would be nice to get the best of both worlds: get the infrastructure that is provided by escript such as main/1 entry point, command line parameters, and exit code handling while still having a nice directory structure that is easy to package and which doesn't hinder the use of NIFs.
Regardless if you are starting a long-running daemon-like application in Erlang, or a CLI command, you always need the following:
erts application - the VM and kernel in a particular version
Erlang OTP applications
Your applications' dependencies
CLI entry point
Then in either case the CLI entry point has to start the Erlang VM and execute the code that it supposed to execute in a given situation. Then it will either exit or continue running - the later for a long-running application.
The CLI entry point can be anything that starts an Erlang VM, e.g. an escript script, sh, bash, etc. The obvious advantage of escript over generic shell is that escript is already being executed in the context of an Erlang VM, so no need to handle starting/stopping the VM.
You can start Erlang VM in two ways:
Use system-wide Erlang VM
Use an embedded Erlang release
In the first case you don't supply erts nor any OTP application with your package, you only make a particular Erlang version a dependency for your application. In the second case you supply erts and all required OTP applications along with your application's dependencies in your package.
In the second case you also need to handle setting the code root properly when starting the VM. But this is quite easy, see the erl script that Erlang uses to start the system-wide VM:
# location: /usr/local/lib/erlang/bin/erl
ROOTDIR="/usr/local/lib/erlang"
BINDIR=$ROOTDIR/erts-7.2.1/bin
EMU=beam
PROGNAME=`echo $0 | sed 's/.*\///'`
export EMU
export ROOTDIR
export BINDIR
export PROGNAME
exec "$BINDIR/erlexec" ${1+"$#"}
This can be handled by scripts, for example the node_package tool that Basho uses to package their Riak database for all major operating systems. I am maintaining my own fork of it which I am using with my own build tool called builderl. I just say that so you know that if I managed to customize it you will well be able to do that as well :)
Once the Erlang VM is started, your application should be able to load and start any application, either supplied with Erlang or with your application (and that includes the mylib library that you mentioned). Here are some examples how this could be achieved:
escript example
See this builderl.esh example how I handle loading other Erlang applications from builderl. That escript script assumes that the Erlang installation is relative to the folder from which it's executed. When it's a part of another application, like for example humbundee, the load_builderl.hrl include file compiles and loads bld_load, which in turn loads all remaining modules with bld_load:boot/3. Notice how I can use standard OTP applications without specifying where they are - builderl is being executed by escript and so all the applications are loaded from where they were installed (/usr/local/lib/erlang/lib/ on my system). If libraries used by your application, e.g. mylib, are installed somewhere else, all you need to do is add that location to the Erlang path, e.g. with code:add_path. Erlang will automatically load modules used in the code from folders added to the code path list.
embedded Erlang
However, the same would hold if the application was a proper OTP release installed independently from the system-wide Erlang installation. That's because in that case the script is executed by escript belonging to that embedded Erlang release rather than the system-wide version (even if it's installed). So it knows the location of all applications belonging to that release (including your applications). For example riak does exactly that - in their package they supply an embedded Erlang release that contains its own erts and all dependent Erlang applications. That way riak can be started without Erlang being even installed on the host operating system. This is an excerpt from a riak package on FreeBSD:
% tar -tf riak2-2.1.1_1.txz
/usr/local/sbin/riak
/usr/local/lib/riak/releases/start_erl.data
/usr/local/lib/riak/releases/2.1.0/riak.rel
/usr/local/lib/riak/releases/RELEASES
/usr/local/lib/riak/erts-5.10.3/bin/erl
/usr/local/lib/riak/erts-5.10.3/bin/beam
/usr/local/lib/riak/erts-5.10.3/bin/erlc
/usr/local/lib/riak/lib/stdlib-1.19.3/ebin/re.beam
/usr/local/lib/riak/lib/ssl-5.3.1/ebin/tls_v1.beam
/usr/local/lib/riak/lib/crypto-3.1/ebin/crypto.beam
/usr/local/lib/riak/lib/inets-5.9.6/ebin/inets.beam
/usr/local/lib/riak/lib/bitcask-1.7.0/ebin/bitcask.app
/usr/local/lib/riak/lib/bitcask-1.7.0/ebin/bitcask.beam
(...)
sh/bash
This doesn't differ much in principle from the above apart from having to explicitly call the function that you want to execute when starting the Erlang VM (the entry point or the main function as you called it).
Consider this script that builderl generates to start an Erlang application just to execute a specified task (generate the RELEASES file), after which the node shuts down:
#!/bin/sh
START_ERL=`cat releases/start_erl.data`
APP_VSN=${START_ERL#* }
run_erl -daemon ../hbd/shell/ ../hbd/log "exec erl ../hbd releases releases/start_erl.data -config releases/$APP_VSN/hbd.config -args_file ../hbd/etc/vm.args -boot releases/$APP_VSN/humbundee -noshell -noinput -eval \"{ok, Cwd} = file:get_cwd(), release_handler:create_RELEASES(Cwd, \\\"releases\\\", \\\"releases/$APP_VSN/humbundee.rel\\\", []), init:stop()\""
This is a similar script but doesn't start any specific code or application. Instead, it starts a proper OTP release, so which applications are started and in what order depends on the release (specified by the -boot option).
#!/bin/sh
START_ERL=`cat releases/start_erl.data`
APP_VSN=${START_ERL#* }
run_erl -daemon ../hbd/shell/ ../hbd/log "exec erl ../hbd releases releases/start_erl.data -config releases/$APP_VSN/hbd.config -args_file ../hbd/etc/vm.args -boot releases/$APP_VSN/humbundee"
In the vm.args file you can provide additional paths to your applications if required, e.g.:
-pa lib/humbundee/ebin lib/yolf/ebin deps/goldrush/ebin deps/lager/ebin deps/yajler/ebin
In this example these are relative, but could be absolute if your application is installed into a standard well-known location. Also, this would be only required if you are using the system-wide Erlang installation and need to add the additional paths to locate your Erlang applications, or if your Erlang applications are located in non-standard location (e.g. not in lib folder, as Erlang OTP requires). In a proper embedded Erlang release, where the applications are located in the code root/lib folder, Erlang is able to load those applications without specifying any additional paths.
Summing up and other considerations
The deployment of Erlang applications doesn't differ much from other projects written in scripting languages, e.g. ruby or python projects. All those projects have to deal with similar issues and I believe each operating system's package management deals with them one way or another:
Get to know how your operating system deals with packaging projects that have run-time dependencies.
See how other Erlang applications are packaged for your operating system, there are plenty of them that are usually distributed by all major systems: RabbitMQ, Ejabberd, Riak among others. Just download the package and unpack it to a folder, then you will see where all the files are placed.
EDIT - reference the requirements
Coming back to your requirements, you have the following choices:
Install Erlang as an OTP release system-wide, as an embedded Erlang, or as a bag with applications in some random folders (sorry Rebar)
You can have multiple entry points in the form of sh or escript scripts executing a selection of applications from the installed release. Both will work as long as you configured the code root and paths to those applications correctly (as outlined above).
Then each of your applications: myweb and mycli, would need to be executed in its own new context, e.g. start a new VM instance and execute the required application (from the same Erlang release). In case of myweb the entry point can be a sh scripts that starts a new node according to the release (similar to Riak). In case of mycli the entry point can be an escript, which finishes executing once the task is completed.
But it's entirely possible to create a short-running task that exits the VM even if it's started from sh - see the example above. In that case mycli would require separate release files - the script and boot to boot the VM. And of course it's also possible to start a long-running Erlang VM from escript.
I provided an example project that uses all these methods at once, humbundee. Once it's compiled it provides three access points:
The cmd release.
The humbundee release.
The builder.esh escript.
The first one is used to start the node for installation and then shut it down. The second is used to start a long-running Erlang application. The third is a build tool to install/configure the node. This is how the project looks like once the release has been created:
$:~/work/humbundee/tmp/rel % ls | tr " " "\n"
bin
erts-7.3
etc
lib
releases
$:~/work/humbundee/tmp/rel % ls bin | tr " " "\n"
builderl.esh
cmd.boot
humbundee.boot
epmd
erl
escript
run_erl
to_erl
(...)
$:~/work/humbundee/tmp/rel % ls lib | tr " " "\n"
builderl-0.2.7
compiler-6.0.3
deploy-0.0.1
goldrush-0.1.7
humbundee-0.0.1
kernel-4.2
lager-3.0.1
mnesia-4.13.3
sasl-2.7
stdlib-2.8
syntax_tools-1.7
yajler-0.0.1
yolf-0.1.1
$:~/work/humbundee/tmp/rel % ls releases/hbd-0.0.1 | tr " " "\n"
builderl.config
cmd.boot
cmd.rel
cmd.script
humbundee.boot
humbundee.rel
humbundee.script
sys.config.src
The cmd entry point will use application deploy-0.0.1 and builderl-0.2.7 as well as release files cmd.boot, cmd.script, and some OTP applications. The standard humbundee entry point will use all applications apart from builderl and deploy. Then the builderl.esh escript will use application deploy-0.0.1 and builderl-0.2.7. All from the same embedded Erlang OTP installation.
A small escript that then goes into code from 'conventional' modules could be a solution.
As an example, Concuerror is expected to be used as a command line tool and uses an escript as its entry point. It handles command-line arguments via getopt. All the main code is in regular Erlang modules, which are included in the path with simple arguments to the escript.
As far as I understand, NIFs can then be loaded with regular -onload attributes (Concuerror does not use NIFs).
I am trying to run HermesJMS from soapUI 5.2.1 on Windows7 x64
The preferences and path to hermes config are set correctly.
The problem is that I cannot write to C: drive. So I had to install SOAPUI and Hermes in alternative places. I have changed hermes_home, java_home and hermes_config to my actual paths. Paths do not contain whitespaces etc. When I run hermes.bat from command prompt, it starts correctly.
However, when I try SoapUI -> Project -> right click -> start HermesJMS - nothing happens. Things are as bad that I even couldn't find anything useful neither in soapui nor in hermes logs.
File structure is as follows:
hermes_home = ...\SoapUI-5.2.1\hermesJMS
hermes_config = ...\SoapUI-5.2.1\hermesJMS\cfg
Does anyone have an idea what could be going on? Or for a start where can i find stdout and stderr of a script which starts hermes from SoapUI?
Here are the steps to configure SoapUI with HermesJMS:
Preferences: In SoapUI tool, go to File -> Preferences -> Tools and set the path for HermesJMS, which is mentioned here in the documentation. Then, save the preferences.
Start HermesJMS: Now, select your soapui project. Right click -> Start HermesJMS. At this point, a dialog will be shown requesting user to choose for the hermes configuration directory where it looks for the file called hermes-config.xml. Default location it looks for is under {user.home}\.hermes.
You already mentioned hermesJMS is already configured to connect with TIBCO EMS, so you will be having that file on your system.
Configuring JMS: I believe this may not really applicable for you. But, in case if someone is needed, here are the detailed steps provided, citing the documentation.
-- Here for activemq from the official site.
-- Here for TIBCO EMS. And here, there. Also find some information relevant to EMS connection issues here.
Permissions Issue on C Drive:
There is no constraint from SmartBear that SoapUI needs to be installed in a specific drive on the computer. So, you are free to install the software on your machine where you have the rights to do so.
Does anyone have an idea what could be going on? Or for a start where can i find stdout and stderr of a script which starts hermes from SoapUI?
Best thing you could do is to go the logs to find what is going on. You can find lot of useful information from the logs when the situation requires. SoapUI logs can be found under {user.home} when you invoked it from windows -> start menu. If you start SoapUI from command line (go to SOAPUI_HOME\bin) using soapui.bat script, then you should be able so the log on the console itself also log files can be found in the same directory where you invoked.
This time the above instruction should resolve your issue.
I have created MSI package using advanced Installer. It contains App Config to which i have to pass the siteURL which varies depending on location. I need to pass the siteurl to app config when msi is installed . Please help me with it. I am new to Advanced Installer
You can check the online user guide for Advanced Installer, it has a lot of useful info. For example the article on importing and editing XML config files.
Or how to add a custom dialog and write in the system the values captured from the end users.
EDIT: additional answer regarding command line
You can run the installation silently from the command line but you will still see the message box saying the package is built with a trial. You will not see the standard MSI dialogs. And the trial messages will be gone once you purchase license for Advanced Installer.
Please note that your command prompt window (cmd.exe) must be launched as administrator, if your installation is installing per-machine (i.e. you write in Program Files or HKLM registry hive). Otherwise the installation will fail silently and you will not know why, because on silent installation the OS will not show an error message.
Here is a command line example:
msiexec.exe /i C:\setup\installer.msi /qn ID="235424" SiteURL="www.example.com"
Please note that it is not recommended to use private properties, i.e. properties with lower case letters in their name, we recommend public properties, for example: SITE_URL.
I am starting out Erlang in Win 7 64 bit box and I was able to use Erlang IDE just fine and since I am used to Eclipse I wanted to use Erlide with Eclipse. I am following running project document on erlide I was able to follow along. (Except step 41, Where it is talking about adding something to 'Main tab' and in my case it shows as 'Erlang', but options they are same) When I run the 'new configuration' on the HelloWorld example it runs and stuck at 57%.
I did install Erlang on my PC and installed it in a directory without space and it does shows up on my installed runtime in Eclipse.
When I run I do not see 'Eclipse IDE' like I saw when I was running Scala IDE in eclipse.
I did enter a dummy cookie name just in case if that is the problem
I tried running 'erl -name foo' to make sure node is able to run and it did.
Is there anything I need to check?
Thanks
Try first this:
* delete the configuration you created
* open a file in your project, right-click in it and choose Run as -> Erlang application
This will create a configuration that should work. You should see a console opening, where you can interact with the Erlang node.
If that is not happening, please go to window->preferences->erlang->report problem and create a report. Attach it to an issue at https://github.com/erlide/erlide/issues or send it to erlide_bugs#lists.sourceforge.net
I have the same problem on Win 7 - 64bit.
Problem: After some very first times build and run successfully, then eclipse couldnt run anymore. Restart Eclipse won't help.
Solution: Restarting the computer, and plz remember to Build Project before running it.