On 01/14/2013 11:37 AM, Joe Armstrong wrote:I am glad it not only works on my own devices. :-)
This is amazing - works like a charm - fantastic.
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.
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 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.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.
First thoughts/questions:
- The download is rather large - I'm sure this could be made a *lot smaller
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.
- Need Erlang APIs to the camera, GPS, .... etc.
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?
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?
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
Yes, that is what happens.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 -
Wow, this must be abused without hesitation.
_______________________________________________
erlang-questions mailing list
erlang-q...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
Wow, this must be abused without hesitation.
On 01/18/2013 04:25 PM, Björn Gustavsson wrote:
<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 !!!!Yes, that is what happens.
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 -
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
Dialyzer will complain if the function is undefined. It also breaks expectations, what's the type going in? Out?
You shouldn't use it.
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.virding@erlang-solutions.com>> wrote:
Isn't that the best reason NOT to implement it. Kill -extends()
instead, it sucks.
Robert
------------------------------------------------------------------------<mailto:bgust...@gmail.com>> <mailto:n.o...@gmail.com>>
*From:*"Björn Gustavsson" <bgust...@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] Erlang4AndroidRamine<n.o...@gmail.com <mailto:n.o...@gmail.com>>wrote:
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
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
http://erlang.org/mailman/listinfo/erlang-questions
_______________________________________________
erlang-questions mailing list
"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
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
--
*Erik.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:
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
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.