Giter VIP home page Giter VIP logo

olp's Introduction

LFE

Build Status Hex.pm version Hex.pm downloads Hex.pm weekly downloads Hex.pm daily downloads

LFE, Lisp Flavoured Erlang, is a lisp syntax front-end to the Erlang compiler. Code produced with it is compatible with "normal" Erlang code. An LFE evaluator and shell is also included.

Building

To compile LFE, simple clone it and compile:

$ git clone https://github.com/lfe/lfe.git
$ cd lfe
$ make compile

LFE requires Erlang be installed on the system and that the erl binary is in $PATH.

Running the Tests

To run the full suite of tests for LFE, simply use the following:

make tests

Installation

Should you wish to have LFE available system-wide, you can run the following make target:

$ make install

By default this will create the programs lfe, lfec, lfedoc and lfescript in /usr/local/bin. This can be changed by defining the make variable PREFIX to point to the desired parent directory.

Note that the install target will also install the LFE man pages in the appropriate $(PREFIX)/share/man/man* directories. This can be changed by defining the make variable MANINSTDIR to point to the desired top man directory.

So:

$ make install PREFIX=/Users/rv/ MANINSTDIR=/Users/rv/man

will put the programs in /Users/rv/bin and the man pages in the /Users/rv/man/man* directories.

REPL

If you're running LFE from a git clone working dir, you can start the REPL like so after compiling:

$ ./bin/lfe
Erlang/OTP 26 [erts-14.0.2] [source] [64-bit] [smp:10:10] [ds:10:10:10] [async-threads:1] [jit] [dtrace]

   ..-~.~_~---..
  (      \\     )    |   A Lisp-2+ on the Erlang VM
  |`-.._/_\\_.-':    |   Type (help) for usage info.
  |         g |_ \   |
  |        n    | |  |   Docs: http://docs.lfe.io/
  |       a    / /   |   Source: http://github.com/lfe/lfe
   \     l    |_/    |
    \   r     /      |   LFE v2.1.4 (abort with ^G)
     `-E___.-'

lfe>

If you have installed LFE, then you may start the REPL from any location:

$ lfe

Likewise, you may run an LFE shell script in the same style as shell scripts with:

$ ./bin/lfe script-name script-arg-1 ...

or

$ lfe script-name script-arg-1 ...

Usage

The docs site has several places to explore that will show you how to start using LFE. However, here's a quick taste:

  • start up an LFE REPL as demonstrated above
  • then, do something like this:
lfe> (* 2 (+ 1 2 3 4 5 6))
42
lfe> (* 2 (lists:foldl #'+/2 0 (lists:seq 1 6)))
42

Docker Support

LFE now supports Docker. To get started, simply do the following, once you have Docker set up on your machine:

$ docker pull lfex/lfe

Alternatively, you could build the image yourself:

$ cd lfe
$ docker build .

To bring up the LFE REPL:

$ docker run -it lfex/lfe

Documentation

Files with more technical details:

If you would like to make changes to the LFE documentation and then regenerate the docs, you'll want to read the instructions here:

Join the Community

LFE on Slack, join by requesting an invite here

LFE Forum - Erlang Forums

Maintainers

Cutting Releases

Steps:

  1. Update the version in src/lfe.app.src
  2. Create the release tags
  3. Create a release on Github
  4. Publish to hex.pm

Once the app.src has been updated with the version for the release, you can create and push the tags (to Github) with the following:

make tags

That will create the number-only version as well as the "v"-prefixed version.

For now, the process of creating a release on Github is manual:

  1. Go to https://github.com/lfe/lfe/releases
  2. Click "Draft new release"
  3. Select the correct tag from the drop-down "Choose a tag"
  4. Click "Generate release notes"
  5. Click "Publish release"

Lastly, to publish LFE to hex.pm, you need to have rebar3 installed on our system and an entry for the hex plugin in your system rebar.config file. With that in place, publish a new release to hex.pm requires only the following:

make hex-publish

olp's People

Contributors

oubiwann avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar

olp's Issues

Esnure that appropriate olp binaries are created

Tasks:

  • Create an lfe binary that's in the release bin directory - #14
  • Create an lfescript binary that's in the release bin directory - #17
  • Ensure that when running the lfe binary, all libs are accessible - #15
  • Don't create an olp binary, if possible - #18

Part of epic #9

Examine OTP and Follow as Example

Tasks:

  • Place LFE binaries in an analogous place to where OTP places it's erl and other binaries
  • Model the placement of LFE /OLP HTML docs files after where OTP puts HTML docs

Part of release #1

Generalize install code to be reusable by all install methods

OLP installs can make users' lives a bit easier:

  • update PATH to point to LFE/OLP binaries
  • update PATH to point to erl, erlc, etc., in the erts release dir
  • start lfe and erl with the -boot parameter, pointing to the correct boot file

Right now, the only place we're installing OTP is in the experimental/testing Docker image (to /opt/olp on the guest OS). As such, we've got some custom setup in the Dockerfile -- this needs to be broken out, generalized for use by all install methods, and with the appropriate bits made optional, etc.

Tasks:

  • Create bash profile inclusion for OLP installation - #42
  • Update the Docker build to use this
  • Create additional files as neccessary
  • Update other install methods to use the same files

Part of epic #37

Bundle the rebar binary with the release

We need to:

  • figure out the best/common way for OTP/OLP releases to include escripts, executables, etc., in a release, and then
  • include rebar3 in the release, thus allowing end users to run it (directly or indirectly)

Part of feature #23

Create an OLP Release

Epics:

  • Create Supporting Infrastructure - #2
  • Examine OTP and Follow as Example - #8
  • Create an Initial Build - #9
  • Examine Release Use Cases - #36
  • Standardize Release Testing - #20
  • Standardize Release Documentation - #28
  • Support Multiple Releases - #35
  • Provide Multuple Means of OLP Installation - #37

Provide Multuple Means of OLP Installation

Features:

  • Generalize work done so far to be reusable by all install methods - #38
  • Default install to /opt/olp - #39
  • Custom install to OLP_PREFIX (e,g., /usr/local/lib, ~/.local, etc.) - #40
  • Install to Docker image - #41

Part of release #1

Determine a standard way of generating LFE docs for release inclusion

Tasks:

  • Generate docs in standard output format
    • before or after the release is generated?
    • probably before ...
    • how do you ensure that docs are generated with relx ... when calling rebar3 release?
  • Place the generated docs in the release hierarchy ... or keep them in each project?
  • Place the index file in the release hierarchy (in fact, this might be the only doc file that gets put at the olp level)
    Part of epic #28

Standardize Release Documentation

This includes a wide-ranging set of features:

  • Define a standard output format for all release docs - #29
  • Determine a standard way of generating LFE docs for release inclusion - #30
  • Determine a standard way of generating lib docs for release inclusion - #31
  • Provide an index / summary interface for easy access to LFE and library docs - #32
  • Provide a unified look for all LFE and library docs - #33
  • Include any scripts/executables necessary to support viewing of docs by release users - #34

Part of release #1

Create an Initial Build

Features:

  • Create a rebar.config file that has relx configuration info in it - #10
  • Run the build to generate a release - #11
  • Ensure that the appropriate dependencies are included - #19
  • Esnure that appropriate olp binaries are created - #16
  • Ensure that a targzball is created - #12
  • Test the release in a clean environment to ensure working - #13

Part of release #1

Create Supporting Infrastructure

Features for the epic:

  • Create a repository - #3
  • Establish a means of pulling in source code - #4
  • Determine tooling for build process - #5
  • Document setup, build, and installation - #6
  • Setup automated building on Travis CI - #7

Part of release #1

Devise a means for end users to run checks/tests against a downloaded release

This would not be a task for developers, but rather for end users. As such, the mechanism selected for testing should not depend upon the development toolchain. We should only rely upon what is actually in the release itself.

As such, the following tasks might be appropriate:

  • Bundle the rebar binary with the release - #24
  • Ensure that the LFE tests can be run from LFE or Erlang (or use LFE/Erlang executables, e.g., ct) - #25
  • Determine how to run rebar3 from "inside" the release when testing as an end user - #26
  • Provide a single means of running all tests "within" the release - #27

Part of epic #20

Examine Release Use Cases

In order to make sure that OLP is built in a manner useful for all sorts of sitiations, we need to examine the anticipated use cases (and then test OLP with those, possibly making changes during this process of discovery).

Use Cases:

  • Using OLP and it's executables (lfe, lfescript, erl, erlscript) on a system with no Erlang installed
  • Using OLP on a system that has Erlang installed
  • Using OLP (on Erlang-less system) to develop and build LFE applications
  • Using OLP (on Erlang-less system) to deploy/run one or more custom LFE applications
  • Using OLP to generate a custom release that contains all of OLP but also libraries of a user's choosing

Part of release #1

Support multiple releases

Features:

  • Support an LFE-only (no libs) release
  • Support an LFE-essentials (just a few libs) release
  • Support an LFE-web (web dev libs) release
  • Support an LFE-dev (all libs) release

Part of release #1

Standardize Release Testing

Features:

  • Devise a means for developers to test before building a release - #21
  • Devise a means for developers to test a release once it has been created - #22
  • Devise a means for end users to run checks/tests against a downloaded release - #23

Part of release #1

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    ๐Ÿ–– Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. ๐Ÿ“Š๐Ÿ“ˆ๐ŸŽ‰

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google โค๏ธ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.