erlang-luerl 0.2015.12.10-5 source package in Ubuntu

Changelog

erlang-luerl (0.2015.12.10-5) unstable; urgency=medium

  * Set Maintainer: Ejabberd Packaging Team <email address hidden>
  * Set Uploaders: Philipp Huebner <email address hidden>
  * Updated Vcs-* fields in debian/control for salsa.debian.org
  * Updated years in debian/copyright
  * Updated Standards-Version: 4.1.3 (no changes needed)

 -- Philipp Huebner <email address hidden>  Thu, 04 Jan 2018 11:37:45 +0100

Upload details

Uploaded by:
Ejabberd Packaging Team
Uploaded to:
Sid
Original maintainer:
Ejabberd Packaging Team
Architectures:
any
Section:
misc
Urgency:
Medium Urgency

See full publishing history Publishing

Series Pocket Published Component Section
Bionic release universe misc

Downloads

File Size SHA-256 Checksum
erlang-luerl_0.2015.12.10-5.dsc 2.1 KiB 901cf405e4c2464f2e00bcc85cf05795f3aa375cd39043e891b873a54152e4f9
erlang-luerl_0.2015.12.10.orig.tar.bz2 83.2 KiB 7100b7d1c618e0a86d3b5652767066a3d92d4d7f398652bb08f47d78f9df7274
erlang-luerl_0.2015.12.10-5.debian.tar.xz 3.1 KiB 73e4654bb23ee473eb57e9411643495bba6012cf07b8b0892e6d13391a05f446

Available diffs

No changes file available.

Binary packages built by this source

erlang-luerl: implementation of Lua in Erlang

 An experimental implementation of Lua 5.2 written solely in pure Erlang
 .
 When to use Luerl:
 .
 Fast Language Switch: Luerl should allow you to switch between Erlang and Lua
 incredibly fast, introducing a way to use very small bits of logic programmed
 in Lua, inside an Erlang application, with good performance.
 .
 Multicore: Luerl provides a way to transparently utilize multicores. The
 underlying Erlang VM takes care of the distribution.
 .
 Microprocesses: It should give you a Lua environment that allows you to
 effortlessly run tens of thousands of Lua processes in parallel, leveraging
 the famed microprocesses implementation of the Erlang VM. The empty Luerl
 State footprint will be yet smaller than the C Lua State footprint.
 .
 Forking Up: Because of the immutable nature of the Luerl VM, it becomes a
 natural operation to use the same Lua State as a starting point for multiple
 parallel calculations.
 .
 However, Luerl will generally run slower than a reasonable native Lua
 implementation. This is mainly due the emulation of mutable data on top of an
 immutable world. There is really no way around this. An alternative would be
 to implement a special Lua memory outside of the normal Erlang, but this would
 defeat the purpose of Luerl. It would instead be then more logical to connect
 to a native Lua.
 .
 Some valid use cases for Luerl are:
  * Lua code will be run only occasionally and it wouldn't be worth managing
    an extra language implementation in the application;
  * the Lua code chunks are small so the slower speed is weighed up by Luerl's
    faster interface;
  * the Lua code calculates and reads variables more than changing them;
  * the same Lua State is repeatedly used to 'fork up' as a basis for
    massively many parallel calculations, based on the same state;
  * it is easy to run multiple instances of Luerl which could better utilise
    multicores.