Usage of luna/enso for downstream #61

Open
opened 2020-03-06 10:12:44 +01:00 by Kreyren · 2 comments
Kreyren commented 2020-03-06 10:12:44 +01:00 (Migrated from github.com)

Transfer from https://github.com/gitpod-io/gitpod/issues/1295

Luna/Enso is a visual programming language meaning that we can write a program using GUI only.

This currently requires a special IDE which is planned to be fully web-based -> we can host that on gitpod in theory same as Theia.

Expectations for luna/enso

meta lang == Meta programming language determined during the build process since this project supports all programming languages where only the one that is the most efficient for expected runtime is determined to be used

We are expecting luna/enso to be used for downstream management by calling a custom functions written in meta lang which are defined in phases that are executed in sandboxed environment simplified as:

  1. Fetch
  • Fetch and cache the package on the system
  • Perform checksum to verify that the archive is expected
  • Perform a virus scan using virustotal API (optional)
  • If the package is a binary then download it and skip to install phase
  1. Prepare
  • Apply distro specific patches to the source
  1. Configure
  • Configure the package to accept our file hierarchy and system
  • These are all installed in IMAGE directory which is used for metadata tracking
  1. Compile
  • Fetch required toolchain
  • Compile package if needed
  1. Install
  • Install package on the system

These are simplified phases where end-user is expected to have the ability to inject it's code in these phases if needed. Custom phases are also an option.

We are expecting luna/enso to be able to handle the logic for these actions meaning being able to:

  1. Logic statements (if,case)
  2. Arrays
  3. Loops (for, while loops)
  4. Functions and ability to source functions from a different file
  5. Ability to use custom functions in non-luna/enso language

Our usecase

RXT0112/Zernit's abstract is currently to provide a package manager with

  1. binary downstream
  2. source downstream
  3. Custom FSH and toolchain management to allow multiple versions on the same system
  4. Custom implementation of kreyrock (bedrock fork that allows sandboxing other distribution to be acesible from one terminal)
Transfer from https://github.com/gitpod-io/gitpod/issues/1295 Luna/Enso is a visual programming language meaning that we can write a program using GUI only. This currently requires a special IDE which is planned to be fully web-based -> we can host that on gitpod in theory same as [Theia](https://theia-ide.org/). ### Expectations for luna/enso meta lang == Meta programming language determined during the build process since this project supports all programming languages where only the one that is the most efficient for expected runtime is determined to be used We are expecting luna/enso to be used for downstream management by calling a custom functions written in meta lang which are defined in phases that are executed in sandboxed environment simplified as: 1. **Fetch** - Fetch and cache the package on the system - Perform checksum to verify that the archive is expected - Perform a virus scan using virustotal API (optional) - If the package is a binary then download it and skip to `install` phase 2. **Prepare** - Apply distro specific patches to the source 3. **Configure** - Configure the package to accept our file hierarchy and system - These are all installed in IMAGE directory which is used for metadata tracking 4. **Compile** - Fetch required toolchain - Compile package if needed 5. **Install** - Install package on the system These are simplified phases where end-user is expected to have the ability to inject it's code in these phases if needed. Custom phases are also an option. We are expecting luna/enso to be able to handle the logic for these actions meaning being able to: 1. Logic statements (if,case) 2. Arrays 3. Loops (for, while loops) 4. Functions and ability to source functions from a different file 5. Ability to use custom functions in non-luna/enso language ### Our usecase RXT0112/Zernit's abstract is currently to provide a package manager with 1. binary downstream 2. source downstream 3. Custom FSH and toolchain management to allow multiple versions on the same system 4. Custom implementation of kreyrock (bedrock fork that allows sandboxing other distribution to be acesible from one terminal)
Kreyren commented 2020-03-06 10:15:55 +01:00 (Migrated from github.com)

@wdanilo Expectations for luna/enso is relevant.

I tried to make it as short as possible, but this project's abstract is still being developed so i can't provide better documentation.

@wdanilo **Expectations for luna/enso** is relevant. I tried to make it as short as possible, but this project's abstract is still being developed so i can't provide better documentation.
github-actions[bot] commented 2020-05-18 02:02:41 +02:00 (Migrated from github.com)
FIXME: Stale issue message (https://github.com/RXT0112/Zernit/edit/master/.github/workflows/stale.yml)
Sign in to join this conversation.
No Label
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: kreyren/Zernit#61