2010-10-21 10 views
19

Tengo bastante código escrito en Erlang, que quiero incluir en aplicaciones escritas en Objective-C, por ejemplo, en el iPad. Idealmente, me gustaría tener un objeto que encapsule el tiempo de ejecución de Erlang; esto podría accederse a continuación, al igual que el estándar de Erlang cáscara, algo a lo largo de las líneas de:Erlang como un sistema integrado dentro de una aplicación?

ErlangRT *runtime = [[ErlangRT alloc] init]; 
ErlangValue *retval = [runtime execute:@"io:format(\"hello world~n\")"]; 

no me importa demasiado sobre el rendimiento, etc; Puedo ver cómo podría funcionar, pero como no sé demasiado sobre la forma en que se implementa la VM Erlang, no tengo ni idea de lo fácil o difícil que es hacerlo, o si alguien ya ha hecho algo similar. Sé que hay otras formas de interconexión entre Objective-C y Erlang, pero parecen suponer un sistema Erlang instalado independientemente en la máquina de destino. Preferiría que fuera como una biblioteca a la que simplemente vincula con la aplicación.

Entonces mi pregunta es: ¿esto es comparativamente fácil de hacer, y/o alguien ya ha trabajado en esto?

+2

The trap here is the "máquina virtual". Si bien la regla sobre herramientas ha sido relajada, el requisito de vincular estáticamente el código no. Cualquier tipo de JITing/compilación/VM - ERL, Flash, .NET/Mono o de otro modo está mal visto. Aunque estoy seguro de que es "factible" dado el tiempo/dinero suficiente para crear una versión integrada de ERL y el tiempo de ejecución que se dirige a iOS desde la fuente de Erlang, no se le podría permitir nada en la AppStore que genere código de forma dinámica. Con eso como desincentivo, dudo que alguien haya emprendido la tarea de portarlo. – stephbu

+0

Hmm Me comeré un poco mis palabras, parece que http://sourceforge.net/projects/erlandstaticlib/ está en ese camino ... No estoy seguro en qué estado se encuentra. Las reglas todavía soportan que aparezca en la tienda de aplicaciones que solo puede ser un código estático vinculado. – stephbu

+2

Según tengo entendido, el código de generación o descarga dinámica está fuera de los límites, mientras que la interpretación del código incrustado existente (es decir, verificado por AppStore) es correcto. –

Respuesta

Cuestiones relacionadas