[erlang-questions] Erlang4Android

[Erik Reitsma]

Hi all,

I have put my port of Erlang to Android on Google Code: http://code.google.com/p/erlang4android/

To install it on your Android device, you should allow applications from unknown sources, because the app is not delivered through Google Play (yet). The Android device does *not* have to be rooted.

It depends on Scripting Layer for Android (SL4A). So in order to use it, you should first install SL4A r6 from here: http://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r6.apk Then install the APK for Erlang, this one: http://code.google.com/p/erlang4android/downloads/detail?name=ErlangForAndroid.apk
This app is just the installer. Run it to actually install Erlang/OTP. I have included as much of OTP as might be remotely useful, so the download is 36.5 MB. Of course you want to use the megaco and orber applications on your phone!

You can use the SL4A API through the module android that I have added. I have added a very simple example, to show you how you can make a small gui and respond to events. Study the SL4A API to do other Android things.

You can run some Erlang code by putting your source in the SL4A scripts directory on the Android device, which is /sdcard/sl4a/scripts/. The .erl file should contain and export a function main/0, which will be called when the script is run. The .erl file will be compiled to a .beam file automatically, only if the .beam file does not exist. A minor inconvenience now is, that if the .erl file is modified, it will not be recompiled unless the .beam file is removed. The scripts directory will be in the code path, so if you put other .beam files there, they will be found, and .erl files there will be compiled too, if necessary.

Enjoy!

*Erik.

[Vivek Ayer]

Erik,

This is awesome! I just tried it out. I've been waiting for something
like this! Keep up the good work!

Vivek

> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

[Joe Armstrong]

This is amazing - works like a charm - fantastic.

Quick comment -

    It would be very nice to make the client and server in fac_example.zip run "out of the box"
client.erl is a *must read* file. server.erl does not export main/0 and should be changed to
spawn the server - otherwise you don't get control in the shell ...

First thoughts/questions:

  - The download is rather large - I'm sure this could be made a *lot smaller
  - Need Erlang APIs to the camera, GPS, .... etc.
  - The client.erl example shows I can make an application *without* eclipse
     it would be very nice top abstract the details of the layout() function
     so as not to see the XML :-)

Cheers

/Joe

  

[Alessandro Sivieri]

Hi,

great work! Question: are you planning on distributing also the patches for the Erlang distribution? I saw in the wiki page of the project the description of the modifications, but in the "sources" section there are only the app sources (or maybe I missed them?)...

--
Sivieri Alessandro
alessandr...@gmail.com
http://sivieri.wordpress.com/

[Erik Reitsma]

On 01/14/2013 11:37 AM, Joe Armstrong wrote:
> This is amazing - works like a charm - fantastic.
>

I am glad it not only works on my own devices. :-)

> Quick comment -
>
> It would be very nice to make the client and server in
> fac_example.zip run "out of the box"
> client.erl is a *must read* file. server.erl does not export main/0
> and should be changed to
> spawn the server - otherwise you don't get control in the shell ...
>

The server was intended to be run on some server, not on the Android
device. Only the client should run on the device. Of course, the server
could easily be adapted to run on the same device, or another device, as
well.
The example was mainly intended for people familiar with Erlang, who
want to try their Erlang skills on Android. A different example may be
required for Android programmers who do not yet know Erlang.

> First thoughts/questions:
>
> - The download is rather large - I'm sure this could be made a *lot
> smaller

Definitely. As I wrote, I put in as much as I could, mainly to show that
all those libraries could run on the device. I intend to make a minimal
installation too. The current download includes almost everything from
OTP, including things like epmd (which also works, but you will need to
start Erlang from a shell, probably with root permissions). I think I
can probably remove the corba applications, the megaco application,
ASN.1 and many others. I will see if I can make it possible to make your
own selection of OTP applications, and perhaps even allow other
repositories with non-OTP-applications.

> - Need Erlang APIs to the camera, GPS, .... etc.

For now the easiest way to do this is write wrappers around the SL4A
APIs. Have you looked at those and found them lacking? You can find all
available functions here:
http://code.google.com/p/android-scripting/wiki/ApiReference I have
actually only tried a view of them myself.
All functionality from SL4A is available through the module android. I
have implemented this using a dirty trick: I have modified
error_handler.erl such that for an undefined function android:F(Args),
the function android:rpc([Args]) will be called. So I only implemented
android:rpc/1, which will be called for any other function android:F/N.
Dirty, but if there is a new function in SL4A, it will be supported
automagically. This is similar to the implementation for Python4Android.

> - The client.erl example shows I can make an application *without*
> eclipse
> it would be very nice top abstract the details of the layout()
> function
> so as not to see the XML :-)
>

Yes. :-) SL4A does not provide an API to dynamically create gui
elements, so this is a limitation with the current approach. It would be
possible to write Erlang code that transforms something erlangy into the
required XML. I would have to look at how generic that could be made,
because I may be too lazy to specifically implement all possibilities
for the layout XML. I think it would be possible to make some simple
XML-generation from lists of tuples records. I will give it some thought.

Regards,

[Erik Reitsma]

I have put the sources in a tgz file in the downloads section, for now.
I am not sure if the license of the source is compatible with the
requirements from Google Code, because the EPL was not an option. So I
may move the source to Github, perhaps by cloning the otp repository.

> alessandr...@gmail.com <mailto:alessandr...@gmail.com>
> http://sivieri.wordpress.com/

[Joe Armstrong]

On Mon, Jan 14, 2013 at 9:04 PM, Erik Reitsma <erl...@ernovation.com> wrote:

On 01/14/2013 11:37 AM, Joe Armstrong wrote:

This is amazing - works like a charm - fantastic.

I am glad it not only works on my own devices. :-)

Quick comment -

    It would be very nice to make the client and server in fac_example.zip run "out of the box"
client.erl is a *must read* file. server.erl does not export main/0 and should be changed to
spawn the server - otherwise you don't get control in the shell ...

The server was intended to be run on some server, not on the Android device. Only the client should run on the device. Of course, the server could easily be adapted to run on the same device, or another device, as well.
The example was mainly intended for people familiar with Erlang, who want to try their Erlang skills on Android. A different example may be required for Android programmers who do not yet know Erlang.

First thoughts/questions:

  - The download is rather large - I'm sure this could be made a *lot smaller

Definitely. As I wrote, I put in as much as I could, mainly to show that all those libraries could run on the device. I intend to make a minimal installation too. The current download includes almost everything from OTP, including things like epmd (which also works, but you will need to start Erlang from a shell, probably with root permissions). I think I can probably remove the corba applications, the megaco application, ASN.1 and many others. I will see if I can make it possible to make your own selection of OTP applications, and perhaps even allow other repositories with non-OTP-applications.

  - Need Erlang APIs to the camera, GPS, .... etc.

For now the easiest way to do this is write wrappers around the SL4A APIs. Have you looked at those and found them lacking? You can find all available functions here: http://code.google.com/p/android-scripting/wiki/ApiReference I have actually only tried a view of them myself.
All functionality from SL4A is available through the module android. I have implemented this using a dirty trick: I have modified error_handler.erl such that for an undefined function android:F(Args), the function android:rpc([Args]) will be called. So I only implemented android:rpc/1, which will be called for any other function android:F/N. Dirty, but if there is a new function in SL4A, it will be supported automagically. This is similar to the implementation for Python4Android.

Golly - I read the code - you modified error_handler.erl !!!!

So what happens is ...

   I call android:fooBar(Args) - fooBar is not defined in android.erl
   so it's caught in error_handler and then android:rpc(fooBar, [...]) is called
   and this ends up as a Json call to a socket -

   (aside) I'm not sure I'm totally happy with modifying the error_handler for this,
   what's wrong with calling android:rpc(Func, Args) in your code and not
   changing the error handler?
   (/aside)


   It appears that SL4A is interfaced via a socket carrying JSON encode terms - is that correct?

   I Googled a bit to see if I could find where the protocol is defined - but found nothing.
   Where, for example, is the handshake that you perform in android:init *specified*
 
   If I want to call an andoid function I need to create a JSON argument list from erlang -
what are the calling conventions?

   This is all very interesting stuff - I'd really like some documentation though, how the
heck did you figure out how the interface works? - did you have to sniff the socket? - is there an architectural description somewhere?

Cheers

/Joe





 

[Erik Reitsma]

On 01/15/2013 10:41 AM, Joe Armstrong wrote:

Golly - I read the code - you modified error_handler.erl !!!!

So what happens is ...

   I call android:fooBar(Args) - fooBar is not defined in android.erl
   so it's caught in error_handler and then android:rpc(fooBar, [...]) is called
   and this ends up as a Json call to a socket -

Yes, that is what happens.

   (aside) I'm not sure I'm totally happy with modifying the error_handler for this,
   what's wrong with calling android:rpc(Func, Args) in your code and not
   changing the error handler?
   (/aside)

I think calling android:Func(Args) is prettier. The fact that it is an rpc call is hidden in this way. Python4android provides a similar api. Python has a supported way of handling missing functions, Erlang has not (as far as I know). Have a look at the android api in python4android: http://code.google.com/p/android-scripting/source/browse/python/ase/android.py
If I interpret "error_handler" as "missing_function_handler", my conscience can survive this hack.

Note that I also implemented dynamic code compilation (as Python does) by modifying error_handler.

   It appears that SL4A is interfaced via a socket carrying JSON encode terms - is that correct?

Yes, that is correct.

   I Googled a bit to see if I could find where the protocol is defined - but found nothing.

I believe Python's android module was my main source of information, together with http://code.google.com/p/android-scripting/wiki/InterpreterDeveloperGuide

   Where, for example, is the handshake that you perform in android:init *specified*
 

It is specified at the bottom of this page, under RPC Authentication: http://code.google.com/p/android-scripting/wiki/InterpreterDeveloperGuide

   If I want to call an andoid function I need to create a JSON argument list from erlang -
what are the calling conventions?

I included json2.erl from yaws, by A2Z Development USA, Inc. So, from that source:

%%% This module translates JSON types into the following Erlang types:
%%%
%%%     JSON                    Erlang
%%%     ----                    ------
%%%     number                  number
%%%     string                  string
%%%     array                   {array, ElementList}
%%%     object                  tagged proplist with string keys (i.e. {struct, PropList} )
%%%     true, false, null       atoms 'true', 'false', and 'null'
%%%
%%% Character Sets: the external representation, and the internal
%%% representation of strings, are lists of UTF-8 code units.
%%%
%%% Numbers: Thanks to Erlang's bignums, JSON-encoded integers of any
%%% size can be parsed.  Conversely, extremely large integers may
%%% be JSON-encoded.  This may cause problems for interoperability
%%% with JSON parsers which can't handle arbitrary-sized integers.
%%% Erlang's floats are of fixed precision and limited range, so
%%% syntactically valid JSON floating-point numbers could silently
%%% lose precision or noisily cause an overflow.  However, most
%%% other JSON libraries are likely to behave in the same way.
%%%
%%% Strings: If we represented JSON string data as Erlang binaries,
%%% we would have to choose a particular unicode format.  Instead,
%%% we use lists of UTF-16 code units, which applications may then
%%% change to binaries in their application-preferred manner.
%%%
%%% Arrays: Because of the string decision above, and Erlang's
%%% lack of a distinguished string datatype, JSON arrays map
%%% to {array, ArrayElementList}, where ArrayElementList -> list.
%%%
%%% Objects: Though not explicitly stated in the JSON "spec",
%%% JSON's JavaScript heritage mandates that member names must
%%% be unique within an object.  The object/tuple ambiguity is
%%% not a problem, since the atom 'struct' is not an
%%% allowable value.  Object keys may be atoms or strings on
%%% encoding but are always decoded as strings.
%%%

   This is all very interesting stuff - I'd really like some documentation though, how the
heck did you figure out how the interface works? - did you have to sniff the socket? - is there an architectural description somewhere?

I read the source for the android module for python4android.

Regards,
*Erik.

[Erik Reitsma]

On 01/15/2013 10:41 AM, Joe Armstrong wrote:

   This is all very interesting stuff - I'd really like some documentation though, how the
heck did you figure out how the interface works? - did you have to sniff the socket? - is there an architectural description somewhere?

Note that you can create a server on the Android device, to which you can connect from some other device (e.g. a desktop pc). You can then run Erlang on your pc, and call android functions on the device through the json rpc. Read all about it here: http://code.google.com/p/android-scripting/wiki/RemoteControl

Regards,

*Erik.

P.S.: you will need the android.erl and json2.erl from the source on Google Code, and fix android.erl, because there is an obvious typing mistake in the handling of servers other than 127.0.0.1, which I just found out when I tried this feature.

[David Mercer]

Am I the only one whose email reader (Outlook 2010) does not distinguish well between who is saying what in this email message?  Not just this one—others too—but often they are Joe’s.  Anyone else using Outlook and had this problem and then tweaked some setting somewhere and the problem went away?  Please advise.  Thank-you.

 

Cheers,

 

DBM

[Erik Reitsma]

I have just stripped the erlang_r15b03.1.zip to a much smaller file
(erlang_r15b03.2.zip), including only the basic applications. The new
file can be installed using a new installer APK,
http://erlang4android.googlecode.com/files/ErlangForAndroid_small.apk
If you have installed Erlang on the Android device, and you want to try
the light version instead, use the original installer to uninstall
Erlang. Then install the new installer APK (which should replace the old
installer), and use it to install Erlang again.

Regards,

[Björn Gustavsson]

On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma <erl...@ernovation.com> wrote:

On 01/15/2013 10:41 AM, Joe Armstrong wrote:

Golly - I read the code - you modified error_handler.erl !!!!

So what happens is ...

   I call android:fooBar(Args) - fooBar is not defined in android.erl
   so it's caught in error_handler and then android:rpc(fooBar, [...]) is called
   and this ends up as a Json call to a socket -

Yes, that is what happens.

It might interest you to know, that in R16, you can have a handler for

undefined functions in each module. (We needed that to implement the parse

transformation for parameterized modules.)

This new feature has just been merged to the master branch:

 https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d

/Bjorn

[Tony Rogvall]

Wow, this must be abused without hesitation.

Really nice !

/Tony

_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

"Installing applications can lead to corruption over time. Applications gradually write over each other's libraries, partial upgrades occur, user and system errors happen, and minute changes may be unnoticeable and difficult to fix"

[Anthony Ramine]

Out of curiosity, why?

-- 

Anthony Ramine

[Björn-Egil Dahlberg]

On 2013-01-18 16:32, Tony Rogvall wrote:

Wow, this must be abused without hesitation.

Oh, good god.

Tony, when you put your brainpower into abusing Erlang code, Erlang maintainers run scared. =)

// Björn-Egil

[Loïc Hoguin]

Dialyzer will complain if the function is undefined. It also breaks
expectations, what's the type going in? Out?

You shouldn't use it.

On 01/18/2013 04:32 PM, Tony Rogvall wrote:
> Wow, this must be abused without hesitation.
>
> Really nice !
>
> /Tony
>
> On 18 jan 2013, at 16:25, Björn Gustavsson <bgust...@gmail.com

> <mailto:bgust...@gmail.com>> wrote:
>
>>
>>
>>
>> On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma <erl...@ernovation.com
>> <mailto:erl...@ernovation.com>> wrote:
>>
>> On 01/15/2013 10:41 AM, Joe Armstrong wrote:
>>> Golly - I read the code - you modified error_handler.erl !!!!
>>>
>>> So what happens is ...
>>>
>>> I call android:fooBar(Args) - fooBar is not defined in android.erl
>>> so it's caught in error_handler and then android:rpc(fooBar,
>>> [...]) is called
>>> and this ends up as a Json call to a socket -
>>>
>> Yes, that is what happens.
>>>
>> It might interest you to know, that in R16, you can have a handler for
>> undefined functions in each module. (We needed that to implement the parse
>> transformation for parameterized modules.)
>>
>> This new feature has just been merged to the master branch:
>>
>> https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d
>>
>> /Bjorn
>>
>> _______________________________________________
>> erlang-questions mailing list

>> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

>> http://erlang.org/mailman/listinfo/erlang-questions
>
> "Installing applications can lead to corruption over time. Applications
> gradually write over each other's libraries, partial upgrades occur,
> user and system errors happen, and minute changes may be unnoticeable
> and difficult to fix"
>
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Loïc Hoguin]

This sounds like a temporary workaround with potentially very bad uses.
Why was it documented?

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Björn Gustavsson]

To implement the -extends() attribute that allows the

implementation of a module to be extended by

inheritance. That used to be implemented in the

error_handler. I have removed that code in the same

commit that implements $handle-undefined-function.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB

[Anthony Ramine]

Why is it documented? Isn't -extends unsupported? Shouldn't this disappear in the future too?

-- 

Anthony Ramine

[Björn Gustavsson]

Parameterized modules were not documented, but that

did not prevent people from using them.

Nowadays we generally prefer to document everything,

but add warnings in the documentation if we think

it could be abused. We might add such warnings to

the documentation of $handle_undefined_function.

Although other languages may give the programmer

more rope to hang himself, Erlang already provides

plenty of rope, for instance parse_transforms, NIFs,

and the error_handler module. Using

$handle_undefined_function is safer than modfying

error_handler, since it can be done locally to a single

module. So we have shortened the rope. :-)

On Fri, Jan 18, 2013 at 4:53 PM, Loïc Hoguin <es...@ninenines.eu> wrote:

On 01/18/2013 04:25 PM, Björn Gustavsson wrote:

On Tue, Jan 15, 2013 at 1:33 PM, Erik Reitsma <erl...@ernovation.com

<mailto:erl...@ernovation.com>> wrote:

    On 01/15/2013 10:41 AM, Joe Armstrong wrote:

    Golly - I read the code - you modified error_handler.erl !!!!

    So what happens is ...

       I call android:fooBar(Args) - fooBar is not defined in android.erl
       so it's caught in error_handler and then android:rpc(fooBar,
    [...]) is called
       and this ends up as a Json call to a socket -

    Yes, that is what happens.

It might interest you to know, that in R16, you can have a handler for
undefined functions in each module. (We needed that to implement the parse
transformation for parameterized modules.)

This new feature has just been merged to the master branch:

https://github.com/erlang/otp/commit/209a479080214ab901116d48b90e91d6c056278d

This sounds like a temporary workaround with potentially very bad uses. Why was it documented?

--
Loďc Hoguin

Erlang Cowboy
Nine Nines
http://ninenines.eu

[Erik Reitsma]

On 01/18/2013 04:25 PM, Björn Gustavsson wrote:

That's interesting. I will use it to implement this feature.

I modified the error_handler also to look for the source if a compiled module was not found. I will probably remove that feature and only compile the module to be run. I can do that in my android module, so I will be able to leave error_handler.erl unmodified. Quite a relief for everybody, I am sure. :-)

*Erik.

[Tony Rogvall]

On 18 jan 2013, at 16:50, Loïc Hoguin <es...@ninenines.eu> wrote:

Dialyzer will complain if the function is undefined. It also breaks expectations, what's the type going in? Out?

You shouldn't use it.

I did not see a smiley, serious man.

Of course you must use it, it is there!

For example:

- I am currently building a version system for Erlang modules and can use this feature

to implement proof of concept. The function can be used as dispatcher to different versions,

one small component in the implementation of the POC.

- Implement curry of functions with a little help of a simple parse_transform.

-module(curry).

-export([add/2]).

add(X,Y) -> X + Y.

foo(X,Y,Z) -> X+Y-Z.

%% some parse_transform magic may generate this

'$handle_undefined_function'(add, [X]) -> fun(Y) -> add(X,Y) end;

'$handle_undefined_function'(foo, [X]) -> fun(Y) -> fun(Z) -> foo(X,Y,Z) end end;

'$handle_undefined_function'(foo, [X,Y]) -> fun(Z) -> foo(X,Y,Z) end;

...

Now we can call:

(currry:add(1))(2)

- implement varadic functions also with a little help of parse_transform

-module(m).

sum(Xs) -> lists:sum(Xs).

 %% some parse_transform magic may generate this

'$handle_undefined_function'(sum, Xs) -> sum(Xs).

Now we can call

m:sum(1),

m:sum(1,2,3,4).

- a flavour of the above is to make simple proxy modules, trace, debug...

And ... well the list can be extended with some creativity.

/Tony

[Robert Virding]

Isn't that the best reason NOT to implement it. Kill -extends() instead, it sucks.

Robert

---

[Loïc Hoguin]

+1

On 01/20/2013 12:16 AM, Robert Virding wrote:
> Isn't that the best reason NOT to implement it. Kill -extends() instead,
> it sucks.
>
> Robert
>

> ------------------------------------------------------------------------
>
> *From: *"Björn Gustavsson" <bgust...@gmail.com>
> *To: *"Anthony Ramine" <n.o...@gmail.com>
> *Cc: *"Erlang-questions" <erlang-q...@erlang.org>
> *Sent: *Friday, 18 January, 2013 4:57:14 PM
> *Subject: *Re: [erlang-questions] Erlang4Android

>
> To implement the -extends() attribute that allows the
> implementation of a module to be extended by
> inheritance. That used to be implemented in the
> error_handler. I have removed that code in the same
> commit that implements $handle-undefined-function.
>
>
> On Fri, Jan 18, 2013 at 4:36 PM, Anthony Ramine <n.o...@gmail.com
> <mailto:n.o...@gmail.com>> wrote:
>
> Out of curiosity, why?
>
> --
> Anthony Ramine
>
> Le 18 janv. 2013 à 16:25, Björn Gustavsson a écrit :
>
> We needed that to implement the parse
> transformation for parameterized modules
>
>
>
>
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>

--
Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Tony Rogvall]

I have never used parametrized modules, so I have no clue what you talk about,

but I think $handle_undefined-function may be very useful.

I vote for it. :-)

/Tony

[Evan Miller]

If folks don't like pmods, -extends(), and error_handler, than ban them from your organization. Why is it so important to people to prevent other developers from using them? I love Erlang, but sometimes I feel oppressed by zealous Puritanism in the community. If you don't like dancing, gambling, and pmods, then don't do them... but that shouldn't stop the rest of us from having a good time.

I've found that Pmods are great for writing callback modules where you want some arguments always passed in implicitly. -extends() is great if you have a lot of related callback modules and want to override functionality in some cases but not in others. It's just a way to manage code complexity, and I won't apologize for making use of it. Security and predictability are not the only desiderata in development projects. Sometimes productivity, simplicity, and manageability are more important. It all depends on the situation.

I personally look forward to playing around with error_handler to GREATLY simplify code generation in BossDB. I consider it a boon to my productivity, and I think people who don't like it should just look the other way and go about their own business.

Evan

--
Evan Miller
http://www.evanmiller.org/

[Loïc Hoguin]

You are talking about simplicity, but also saying Pmods are great
because of arguments passed implicitly. Isn't implicitness the opposite
of simplicity? It requires a lot more knowledge and care to get it
working properly.

The more implicit things you have in a project, the more its complexity
increases, because you have to look around all the time, or remember
many things to understand how it works. It makes it harder for newcomers
of course, but also for you, because the range of things you can mess up
increases.

In the case of this catchall function, for example, you increase
complexity because you will have to also make sure to handle the calls
that you don't want. Before you had one problem: writing proper exported
functions. Now you have this additional problem: make sure other calls
result in an expected error. Because you have two problems now, that
means you can't really pattern match the arguments directly, if the
pattern match fails you'll end up throwing an undefined function error
when you instead wanted a badarg. And that's just the tip of the iceberg.

How does increasing the range in which you can make mistakes improve
your productivity? If there's more chances for bugs to happen, then you
will have more bugs. How is that more maintainable? You maintain it
more, for sure, but I don't think that's the intended effect. The most
maintainable code is the one you never need to look at again.

Call it puritanism if you want. I call it pragmatism.

> <mailto:robert....@erlang-solutions.com>> wrote:
>
>> Isn't that the best reason NOT to implement it. Kill -extends()
>> instead, it sucks.
>>
>> Robert
>>

>> ------------------------------------------------------------------------
>>
>> *From:*"Björn Gustavsson" <bgust...@gmail.com

>> <mailto:bgust...@gmail.com>>

>> *To:*"Anthony Ramine" <n.o...@gmail.com

>> <mailto:n.o...@gmail.com>>
>> *Cc:*"Erlang-questions" <erlang-q...@erlang.org
>> <mailto:erlang-q...@erlang.org>>
>> *Sent:*Friday, 18 January, 2013 4:57:14 PM
>> *Subject:*Re: [erlang-questions] Erlang4Android

>>
>> To implement the -extends() attribute that allows the
>> implementation of a module to be extended by
>> inheritance. That used to be implemented in the
>> error_handler. I have removed that code in the same
>> commit that implements $handle-undefined-function.
>>
>>
>> On Fri, Jan 18, 2013 at 4:36 PM, Anthony

>> Ramine<n.o...@gmail.com <mailto:n.o...@gmail.com>>wrote:

>>
>> Out of curiosity, why?
>>
>> --
>> Anthony Ramine
>>
>> Le 18 janv. 2013 à 16:25, Björn Gustavsson a écrit :
>>
>> We needed that to implement the parse
>> transformation for parameterized modules
>>
>>
>>
>>
>>
>> --
>> Björn Gustavsson, Erlang/OTP, Ericsson AB
>>
>> _______________________________________________
>> erlang-questions mailing list

>> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

>> http://erlang.org/mailman/listinfo/erlang-questions
>>
>>
>> _______________________________________________
>> erlang-questions mailing list

>> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

>> http://erlang.org/mailman/listinfo/erlang-questions
>
> "Installing applications can lead to corruption over time.
> Applications gradually write over each other's libraries, partial
> upgrades occur, user and system errors happen, and minute changes
> may be unnoticeable and difficult to fix"
>
>
>
>
> _______________________________________________
> erlang-questions mailing list

> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>

> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
>
> --
> Evan Miller
> http://www.evanmiller.org/
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
>


--

Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Garrett Smith]

Wouldn't it be simpler to just dunk Evan under water and see if he's
*actually* a child of Satan?

[Evan Miller]

On Sat, Jan 19, 2013 at 7:21 PM, Loïc Hoguin <es...@ninenines.eu> wrote:

You are talking about simplicity, but also saying Pmods are great because of arguments passed implicitly. Isn't implicitness the opposite of simplicity? It requires a lot more knowledge and care to get it working properly.

Implicitness is not the opposite of simplicity.

"Lust conquered shame, audacity fear, madness reason" -Cicero

The verb is implicit in the last two clauses of that sentence, but there is no confusion as to the sentence's meaning, and its style is the epitome of simplicity. Removing the unnecessary verbs enhances one's understanding of the sentence's parallel structure. In a similar way, the parameter list of a pmod reinforces the concept that the module's functions are executed in a similar context. When used with intention, it imparts understanding.

The more implicit things you have in a project, the more its complexity increases, because you have to look around all the time, or remember many things to understand how it works. It makes it harder for newcomers of course, but also for you, because the range of things you can mess up increases.

How do you know this is true 100% of the time? It's not true in my experience, and a Pmod design can make life considerably easier for newcomers in some circumstances. I don't know how you can be confident about sweeping generalizations like these.

 

In the case of this catchall function, for example, you increase complexity because you will have to also make sure to handle the calls that you don't want. Before you had one problem: writing proper exported functions. Now you have this additional problem: make sure other calls result in an expected error. Because you have two problems now, that means you can't really pattern match the arguments directly, if the pattern match fails you'll end up throwing an undefined function error when you instead wanted a badarg. And that's just the tip of the iceberg.

Ok, well they're MY problems, and let me deal with them. I am absolutely certain that I can find applications where the catchall function will let me produce more functionality in less time with fewer bugs. Why do you care if I use something that you consider to be bad style? Why can't I decide for myself if a technique's benefits outweigh the costs?

 

How does increasing the range in which you can make mistakes improve your productivity? If there's more chances for bugs to happen, then you will have more bugs. How is that more maintainable? You maintain it more, for sure, but I don't think that's the intended effect. The most maintainable code is the one you never need to look at again.

The elimination of bugs is not the sole purpose of programming. The purpose is to provide functionality with an acceptable defect rate. My productivity increases because I can provide more functionality in less time by trading security for flexibility. For some projects I use Erlang, for others C, for others Perl. Sometimes maintainability is important, sometimes it's not. Sometimes I'm writing code just for fun and I plan to throw it away! I like having a lot of options, and it's important to me to have the liberty to choose what I think are appropriate design decisions in a given situation.

 

Call it puritanism if you want. I call it pragmatism.

What's pragmatic for you is not necessarily pragmatic for me.

Evan

 

    <robert.virding@erlang-solutions.com

    <mailto:robert.virding@erlang-solutions.com>> wrote:

    Isn't that the best reason NOT to implement it. Kill -extends()
    instead, it sucks.

    Robert

    ------------------------------------------------------------------------

        *From:*"Björn Gustavsson" <bgust...@gmail.com

        <mailto:bgust...@gmail.com>>

        *To:*"Anthony Ramine" <n.o...@gmail.com

        <mailto:n.o...@gmail.com>>
        *Cc:*"Erlang-questions" <erlang-q...@erlang.org

        <mailto:erlang-questions@erlang.org>>

        *Sent:*Friday, 18 January, 2013 4:57:14 PM
        *Subject:*Re: [erlang-questions] Erlang4Android

        To implement the -extends() attribute that allows the
        implementation of a module to be extended by
        inheritance. That used to be implemented in the
        error_handler. I have removed that code in the same
        commit that implements $handle-undefined-function.


        On Fri, Jan 18, 2013 at 4:36 PM, Anthony

        Ramine<n.o...@gmail.com <mailto:n.o...@gmail.com>>wrote:

            Out of curiosity, why?

            --
            Anthony Ramine

            Le 18 janv. 2013 à 16:25, Björn Gustavsson a écrit :

                We needed that to implement the parse
                transformation for parameterized modules





        --
        Björn Gustavsson, Erlang/OTP, Ericsson AB

        _______________________________________________
        erlang-questions mailing list

        erlang-q...@erlang.org <mailto:erlang-questions@erlang.org>

        http://erlang.org/mailman/listinfo/erlang-questions


    _______________________________________________
    erlang-questions mailing list

    erlang-q...@erlang.org <mailto:erlang-questions@erlang.org>
    http://erlang.org/mailman/listinfo/erlang-questions

    "Installing applications can lead to corruption over time.
    Applications gradually write over each other's libraries, partial
    upgrades occur, user and system errors happen, and minute changes
    may be unnoticeable and difficult to fix"




    _______________________________________________
    erlang-questions mailing list

    erlang-q...@erlang.org <mailto:erlang-questions@erlang.org>

    http://erlang.org/mailman/listinfo/erlang-questions




--
Evan Miller
http://www.evanmiller.org/


_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions

--

Loïc Hoguin
Erlang Cowboy
Nine Nines
http://ninenines.eu

[Garrett Smith]

Apologies, this reference isn't universal and some have asked:

http://en.wikipedia.org/wiki/Dunking

For the record, and as a Puritan, Evan is not a witch and actually
makes an excellent point.

Though it would still be fun to dunk him.

[Jachym Holecek]

# Tony Rogvall 2013-01-19:

> And ... well the list can be extended with some creativity.

Oh yes, creativity... because fixing issues in live systems composed of say
50-100kLOC just isn't enough fun when all you've got to work with is some
monitoring data and business logic expressed in fairly straightforward code.
Let's make life more interesting right now, pretty please! The more layers
of indirection: the better! Or here's a truly creative one: why not divorce
apparent structure of source code from its meaning altogether?

;-)

BR,
-- Jachym

[Ulf Wiger]

So... the error_handler is central in the implementation of a much-lauded (albeit not unique) function in Erlang - on-demand code loading. People have been asked not to mess with it, since (a) it's subtle, and (b) it has global scope. Now we have a chance to address (b).

The behavior of this function can aready be tweaked, using the -mode parameter. Are we content that this covers all worthy uses?

BR,

Ulf W

Whether Evan is or is not a witch, the practice of burning them at the stake has long since been abandoned. ;-)

Ulf Wiger, Feuerlabs, Inc.

http://www.feuerlabs.com

[Loïc Hoguin]

On 01/20/2013 03:01 AM, Evan Miller wrote:
> On Sat, Jan 19, 2013 at 7:21 PM, Loïc Hoguin <es...@ninenines.eu
> <mailto:es...@ninenines.eu>> wrote:
>
> You are talking about simplicity, but also saying Pmods are great
> because of arguments passed implicitly. Isn't implicitness the
> opposite of simplicity? It requires a lot more knowledge and care to
> get it working properly.
>
>
> Implicitness is not the opposite of simplicity.
>
> "Lust conquered shame, audacity fear, madness reason" -Cicero
>
> The verb is implicit in the last two clauses of that sentence, but there
> is no confusion as to the sentence's meaning, and its style is the
> epitome of simplicity. Removing the unnecessary verbs enhances one's
> understanding of the sentence's parallel structure. In a similar way,
> the parameter list of a pmod reinforces the concept that the module's
> functions are executed in a similar context. When used with intention,
> it imparts understanding.

No! It helps understanding only when you read the full sentence. If you
arrive in the middle of the sentence, you cannot understand anything
that is said. When reading code you rarely read the whole module, only
fragments, and if some of them are implicitly in other modules, or
implicitly handled by a catchall, then good luck understanding it.

> The more implicit things you have in a project, the more its
> complexity increases, because you have to look around all the time,
> or remember many things to understand how it works. It makes it
> harder for newcomers of course, but also for you, because the range
> of things you can mess up increases.
>
>
> How do you know this is true 100% of the time? It's not true in my
> experience, and a Pmod design can make life considerably easier for
> newcomers in some circumstances. I don't know how you can be confident
> about sweeping generalizations like these.

Pmods are confusing. They break expectations. First you learn that:

Module = my_module, Module:some_function().

will call my_module:some_function(). Pmods though:

Pmod = {my_module, blabla}, Pmod:some_function().

will call my_module:some_function({my_module, blabla}). WTF? How is that
supposed to be simple if a) it's completely different to your initial
expectations and b) is resolved dynamically, which can allow for errors
like:

Pmod = {ok, {my_module, blabla}}, Pmod:some_function().

and now you call ok:some_function({ok,...}) instead.

But this is more of an issue of tuple calls, not parameterized modules,
which I probably wouldn't mind if they didn't break expectations in this
way.

So perhaps this implementation of Pmods make the easy cases easier, but
they sure make harder things harder.

> In the case of this catchall function, for example, you increase
> complexity because you will have to also make sure to handle the
> calls that you don't want. Before you had one problem: writing
> proper exported functions. Now you have this additional problem:
> make sure other calls result in an expected error. Because you have
> two problems now, that means you can't really pattern match the
> arguments directly, if the pattern match fails you'll end up
> throwing an undefined function error when you instead wanted a
> badarg. And that's just the tip of the iceberg.
>
>
> Ok, well they're MY problems, and let me deal with them. I am absolutely
> certain that I can find applications where the catchall function will
> let me produce more functionality in less time with fewer bugs. Why do
> you care if I use something that you consider to be bad style? Why can't
> I decide for myself if a technique's benefits outweigh the costs?

It's not about you. It's about trying to prevent insane features from
getting into the language. And this above is some of the reasons why.

> How does increasing the range in which you can make mistakes improve
> your productivity? If there's more chances for bugs to happen, then
> you will have more bugs. How is that more maintainable? You maintain
> it more, for sure, but I don't think that's the intended effect. The
> most maintainable code is the one you never need to look at again.
>
>
> The elimination of bugs is not the sole purpose of programming. The
> purpose is to provide functionality with an acceptable defect rate. My
> productivity increases because I can provide more functionality in less
> time by trading security for flexibility. For some projects I use
> Erlang, for others C, for others Perl. Sometimes maintainability is
> important, sometimes it's not. Sometimes I'm writing code just for fun
> and I plan to throw it away! I like having a lot of options, and it's
> important to me to have the liberty to choose what I think are
> appropriate design decisions in a given situation.

The elimination of bugs isn't the sole purpose of programming, indeed.
But I'm pretty sure adding ways to hang yourself with isn't the purpose
of programming either. And again I'm not against this feature per se, I
only talked about the *implementation*. This implementation is bad,
IMHO. And I'm well allowed to say it.

> <mailto:to...@rogvall.se <mailto:to...@rogvall.se>>> wrote:
>
> I have never used parametrized modules, so I have no clue
> what you
> talk about,
> but I think $handle_undefined-function may be very useful.
>
> I vote for it. :-)
>
> /Tony
>
> On 20 jan 2013, at 00:16, Robert Virding

> <robert.virding@erlang-__solutions.com
> <mailto:robert....@erlang-solutions.com>
> <mailto:robert.virding@erlang-__solutions.com

> <mailto:robert....@erlang-solutions.com>>> wrote:
>
> Isn't that the best reason NOT to implement it. Kill
> -extends()
> instead, it sucks.
>
> Robert
>
>

> ------------------------------__------------------------------__------------

>
> *From:*"Björn Gustavsson" <bgust...@gmail.com
> <mailto:bgust...@gmail.com>

> <mailto:bgust...@gmail.com
> <mailto:bgust...@gmail.com>>__>

>
> *To:*"Anthony Ramine" <n.o...@gmail.com
> <mailto:n.o...@gmail.com>

> <mailto:n.o...@gmail.com <mailto:n.o...@gmail.com>>>
> *Cc:*"Erlang-questions"
> <erlang-q...@erlang.org
> <mailto:erlang-q...@erlang.org>
> <mailto:erlang-questions@__erlang.org
> <mailto:erlang-q...@erlang.org>>>

> *Sent:*Friday, 18 January, 2013 4:57:14 PM
> *Subject:*Re: [erlang-questions] Erlang4Android
>
>
> To implement the -extends() attribute that allows the
> implementation of a module to be extended by
> inheritance. That used to be implemented in the
> error_handler. I have removed that code in the same
> commit that implements $handle-undefined-function.
>
>
> On Fri, Jan 18, 2013 at 4:36 PM, Anthony
> Ramine<n.o...@gmail.com <mailto:n.o...@gmail.com>

> <mailto:n.o...@gmail.com <mailto:n.o...@gmail.com>>>__wrote:

>
>
> Out of curiosity, why?
>
> --
> Anthony Ramine
>
> Le 18 janv. 2013 à 16:25, Björn Gustavsson a
> écrit :
>
> We needed that to implement the parse
> transformation for parameterized modules
>
>
>
>
>
> --
> Björn Gustavsson, Erlang/OTP, Ericsson AB
>

> _________________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> <mailto:erlang-q...@erlang.org>
> <mailto:erlang-questions@__erlang.org
> <mailto:erlang-q...@erlang.org>>
>
> http://erlang.org/mailman/__listinfo/erlang-questions
> <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
> _________________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org
> <mailto:erlang-q...@erlang.org>
> <mailto:erlang-questions@__erlang.org
> <mailto:erlang-q...@erlang.org>>
> http://erlang.org/mailman/__listinfo/erlang-questions

> <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
> "Installing applications can lead to corruption over time.
> Applications gradually write over each other's libraries,
> partial
> upgrades occur, user and system errors happen, and minute
> changes
> may be unnoticeable and difficult to fix"
>
>
>
>

> _________________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
> <mailto:erlang-questions@__erlang.org
> <mailto:erlang-q...@erlang.org>>
>
> http://erlang.org/mailman/__listinfo/erlang-questions

> <http://erlang.org/mailman/listinfo/erlang-questions>
>
>
>
>
> --
> Evan Miller
> http://www.evanmiller.org/
>
>

> _________________________________________________
> erlang-questions mailing list
> erlang-q...@erlang.org <mailto:erlang-q...@erlang.org>
> http://erlang.org/mailman/__listinfo/erlang-questions

[Richard O'Keefe]

On 20/01/2013, at 1:30 PM, Evan Miller wrote:

> If folks don't like pmods, -extends(), and error_handler, than ban them from your organization.

How, exactly?

I'm reminded of what we used to be told about PL/I: sure it's a complicated language
with all sorts of traps for young players but if you don't use them they won't hurt
you. Problem is, you could use them by accident. Now parameterised modules could
not be used by accident, but the *implementation* of them could, and that hurts
everyone. -extends is pretty much a solution in search of a problem (there's not
much you can do that way you can't do with -include and a little thought); you can't
use it by accident, but that doesn't mean you can't run into the *implementation* of
it by accident. And again with the error handler: error handling machinery always
limits the freedom of compilers to transform your programs because they have to be
able to (re)construct the information the error handler is expecting to see.

If you can tell me the erlc command line switch that will banish
parameterised modules, extends, and explicit use of the error_handler,
I shall be very happy to use it.

> Why is it so important to people to prevent other developers from using them?

Because there is no feature that is not a limitation on something else.
TANSTAAFL.

> I love Erlang, but sometimes I feel oppressed by zealous Puritanism in the community.

It's not Puritanism. People distrust these things each for their own
feature-specific reasons, not simply because they are features.
Let me quote Oliver Cromwell: consider it *possible* that you *may* be wrong.
What *good* reasons might people who disagree with you about these features have?

Let's take one example from the past.

Way back when I was still at RMIT I was doing some work on trying to
derive properties of functions. Not a type system as such, but an
effects system. At that time, Erlang didn't have anonymous functions.
Then *pow*, suddenly it did. And all my work became so much junk.
Yes, anonymous functions are a very handy feature, BUT they were ALSO
a huge limitation on what I could easily discover. This was work that
*would* have allowed user-defined functions in guards.

If anyone had been interested in my opinion back then, I would have
pressed for an extended version of list comprehensions in preference
to anonymous functions, because I could have analysed that.

As for parameterised modules, I've wanted module parameters for a long
time for something else entirely: automatic logic-programming-style
configuration. Maybe nobody else wants that; my point is that we cannot
have BOTH. There is not feature that is not a limitation.

I have written enough OO code in enough languages to be painfully aware
that -extends, whatever its merits, makes code significantly less readable
and quite a bit harder to maintain. (See "Fragile base class problem.")

There comes a point where throwing new features at a language is a bad
idea and it's time to stop and redesign from the beginning, possibly
keeping the VM backwards compatible. Java is pretty much at the point
where there are enough good ideas to make a coherent usable language but
that language would not be Java.

[Richard O'Keefe]

On 19/01/2013, at 4:25 AM, Björn Gustavsson wrote:

> It might interest you to know, that in R16, you can have a handler for
> undefined functions in each module. (We needed that to implement the parse
> transformation for parameterized modules.)

Where is the semantics written up?

[Erik Reitsma]

Hi,

I am using this script to set environment variables, in order to use the Android Arm toolchain:

export TOOLCHAIN_ROOT=/home/user/android-ndk/toolchains/arm-linux-androideabi-4.7
export erl_xcomp_sysroot=${TOOLCHAIN_ROOT}/sysroot
export CROSS_COMPILE=arm-linux-androideabi-
export CC=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}gcc
export CXX=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}g++
export SHLIB_LD=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}gcc
export LD=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ld
export AR=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ar
export RANLIB=${TOOLCHAIN_ROOT}/bin/${CROSS_COMPILE}ranlib
export CFLAGS=
export LDFLAGS=""
export ERLANDROID_ROOT=`pwd`
export ERL_TOP=`pwd`/otp_src_R15B03

And then I configure using:
./configure --prefix=/tmp/arm_erlang --with-ssl=/home/user/openssl/openssl-android-master --without-java --disable-hipe --without-termcap --disable-smp-support --host=arm-linux-androideabi --build=i686-pc-linux-gnu

Note that I have compiled openssl for Android. If you do not need it, you can disable openssl by using --without-ssl

Then I compile using:

TARGET=arm-linux-androideabi make noboot -j12
TARGET=arm-linux-androideabi ./otp_build release -a ${ERLANDROID_ROOT}/arm_erlang_R15B03_rel

That gives me a directory arm_erlang_R15B03_rel with the compiled Erlang/OTP. This directory contains a script Install, which you should call with appropriate arguments. I call it like this:
./Install -cross -minimal /data/data/com.ernovation.erlangforandroid/files/erlang

Anyway, you are right that the cross compiler finds the Android NDK's lib/include from erl_xcomp_sysroot.

On 01/25/2013 07:05 PM, Dongsheng Wang wrote:

hi, Erik, 

I have been trying to cross compile erlang for Android as well. I am working on a Mac here. Question about the your configure script:

http://code.google.com/p/erlang4android/downloads/detail?name=otp_src_R15B03.android.tgz&can=2&q=

How does the cross compiler find the Android NDK's lib/include? I am guessing it is using 

erl_xcomp_sysroot=${TOOLCHAIN_ROOT}/sysroot

Some now, but could not figure out how. 

ds

*Erik.

[Dongsheng Wang]

I am sure I got all the environment variables right, then I am running this configure:

./configure --prefix=/tmp/arm_erlang --with-ssl=${ANDROID_OPENSSL} --without-java --disable-hipe --without-termcap --disable-smp-support --host=arm-linux-androideabi --build=i386-apple-darwin

and I got this error:

dongsheng@Dongshengs-MacBook-Pro ~/Playground/android/erlang4android $ ./configure 

/Users/dongsheng/Library/Android/ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc

/Users/dongsheng/Playground/android/Android-Couchbase-SourceBuild/build/deps/openssl/android-platform_external_openssl/

Ignoring the --cache-file argument since it can cause the system to be erroneously configured

Disabling caching

checking build system type... i386-apple-darwin

checking host system type... arm-unknown-linux-androideabi

checking for arm-linux-androideabi-gcc... /Users/dongsheng/Library/Android/ndk/toolchains/arm-linux-androideabi-4.7/prebuilt/darwin-x86/bin/arm-linux-androideabi-gcc

checking for C compiler default output file name... configure: error: C compiler cannot create executables

See `config.log' for more details.

It seems like it does not think it is doing a cross compilation somehow?

ds

[Dongsheng Wang]

Thanks for the quick, Erik!

Did you run autoconf to generate your configure script?

ds

On Fri, Jan 25, 2013 at 2:17 PM, Erik Reitsma <erl...@ernovation.com> wrote:

[Erik Reitsma]

Hi David and all,

I had not assumed that people would want to use Erlang on Android in distributed mode. However, now that there appears a "market" for this, I will try to get distribution working too. I think that there may be some issues with ownership of the cookie file, and the user id under which Erlang runs.

I intend to publish a new version as soon as R16B is out (which should be in a few days). I would prefer to try to get distribution working in that version.

I have also worked a bit on a new installer, which makes it possible to install the small version first, and add libraries later.

Regards,
*Erik.

On 02/25/2013 12:45 PM, Dávid Juhász wrote:

Hi Erik and all,

The work that has been done is awesome and I am happy to be able to run Erlang code on Android devices!

Unfortunately, I ran into a technical problem trying to run distributed Erlang programs on Android via SL4A. In root terminal, distributed mode works smoothly, but in that case I am unable to create GUI for the program. On the other hand, programs started via the scripting layer are running without root privileges which causes some trouble.

It seems unavoidable that distributed mode must be initialized programatically using net_kernel:start/1 as SL4A doesn't start Erlang in distributed mode. The first problem I encountered was the insufficient privilege to create a cookie file. Having one created manually, that part of initialization seems to be successful. The next problem seems to be that epmd isn't getting started. I can start epmd in daemon mode from the Erlang program using os:cmd/1, so the program and epmd run under the same user. But the same issue appears:

{error,{shutdown,{child,undefined,net_sup_dynamic,
                        {erl_distribution,start_link,[["no...@192.168.24.174"]]},
                        permanent,1000,supervisor,
                        [erl_distribution]}}}

Can someone give me any pointer how to overcome this issue of using GUI and distributed mode at the same time?

Thanks in advance for any help!

Best wishes,
David


2013. január 13., vasárnap 21:06:06 UTC+1 időpontban Erik Reitsma a következőt írta:

Hi all,

I have put my port of Erlang to Android on Google Code: http://code.google.com/p/erlang4android/

To install it on your Android device, you should allow applications from unknown sources, because the app is not delivered through Google Play (yet). The Android device does *not* have to be rooted.

It depends on Scripting Layer for Android (SL4A). So in order to use it, you should first install SL4A r6 from here: http://code.google.com/p/android-scripting/downloads/detail?name=sl4a_r6.apk Then install the APK for Erlang, this one: http://code.google.com/p/erlang4android/downloads/detail?name=ErlangForAndroid.apk
This app is just the installer. Run it to actually install Erlang/OTP. I have included as much of OTP as might be remotely useful, so the download is 36.5 MB. Of course you want to use the megaco and orber applications on your phone!

You can use the SL4A API through the module android that I have added. I have added a very simple example, to show you how you can make a small gui and respond to events. Study the SL4A API to do other Android things.

You can run some Erlang code by putting your source in the SL4A scripts directory on the Android device, which is /sdcard/sl4a/scripts/. The .erl file should contain and export a function main/0, which will be called when the script is run. The .erl file will be compiled to a .beam file automatically, only if the .beam file does not exist. A minor inconvenience now is, that if the .erl file is modified, it will not be recompiled unless the .beam file is removed. The scripts directory will be in the code path, so if you put other .beam files there, they will be found, and .erl files there will be compiled too, if necessary.

Enjoy!

*Erik.

[Juhász Dávid]

Erik,

thanks for the quick reply!

2013/2/25 Erik Reitsma <erl...@ernovation.com>:

> I had not assumed that people would want to use Erlang on Android in
> distributed mode. However, now that there appears a "market" for this, I
> will try to get distribution working too. I think that there may be some
> issues with ownership of the cookie file, and the user id under which Erlang
> runs.

The first problem is the cookie file, indeed. I had to create the file
/data/data/com.ernovation.erlangforandroid/files/erlang/.erlang.cookie,
set privileges to 700 and give it to the user belonging to SL4A
manually in order to overcome error messages pointing explicitly to
the cookie file. After that, there is no explicit sign of any error
(of course, distributed mode doesn't turn on in the background) unless
one checks the value of net_kernel:start/1, to which I referred in my
initial mail. However, I was able to reproduce such values in android
root terminal and even on my laptop when calling net_kernel:start/1
without running epmd. So I think the problem here is that epmd can't
be reached by the runtime, and that can't be helped with simply
starting epmd by the same user on android.

Hope that it gives you some pointer to solve the problem.

> I intend to publish a new version as soon as R16B is out (which should be in
> a few days). I would prefer to try to get distribution working in that
> version.

Of course, that would be fine. Thanks for your work!

Best regards,
David

[Erik Reitsma]

Hi David & others,

I intend to solve this by making it possible to provide extra command
line arguments to erl when Erlang is started from SL4A. Unfortunately I
cannot set this from SL4A, unless I modify SL4A, which I would very much
like to avoid. So, I have to set the command line arguments from the
Erlang installer. This means however, that all started shells will be
started with the same command line arguments. So, either all start with
distribution, or without, unless you change the command line arguments
between two starts. I have tried this, and I can start a shell with
arguments "-sname x -setcookie ssssssss" (no need for a cookie file this
way!).
Would this be an acceptable solution for you?

*Erik.

[Motiejus Jakštys]

On Tue, Feb 26, 2013 at 8:39 PM, Erik Reitsma <erl...@ernovation.com> wrote:
> Hi David & others,
>
> I intend to solve this by making it possible to provide extra command line
> arguments to erl when Erlang is started from SL4A. Unfortunately I cannot
> set this from SL4A, unless I modify SL4A, which I would very much like to
> avoid. So, I have to set the command line arguments from the Erlang
> installer. This means however, that all started shells will be started with
> the same command line arguments. So, either all start with distribution, or
> without, unless you change the command line arguments between two starts. I
> have tried this, and I can start a shell with arguments "-sname x -setcookie
> ssssssss" (no need for a cookie file this way!).
> Would this be an acceptable solution for you?
>

Maybe you can control environment variables instead? These are
equivalent to command-line arguments.
ERL_FLAGS, ERL_AFLAGS, ERL_ZFLAGS

If not, I would go for non-distributed approach, given that users can
"go distributed" by themselves.

$ erl
Erlang R15B02 (erts-5.9.2) [source] [smp:2:2] [async-threads:0]
[kernel-poll:false]

Eshell V5.9.2 (abort with ^G)
1> net_kernel:start(['t...@precise.local', longnames]).
{ok,<0.34.0>}
(t...@precise.local)2> erlang:set_cookie(node(), yadda).
true
(t...@precise.local)3>

Regards,
Motiejus