Eve RAD Workbench

What the Workbench does

• an editor with tabs and syntax colors for Eve, SQL, JSON, XML and HTML;
• a command window for the commands of a machine and for direct SQL, with results shown as a table;
• a database object tree: connections, tables, columns in Eve types, views, indexes;
• a file dialog to open, upload and import files;
• a job scheduler and browser similar to Jenkins, with the knowledge of Eve: aspects, checkpoints, error codes;
• a log inspector for the run logs of the drivers;
• a debugger: run step by step, breakpoints, variable inspector, watch window, call stack;
• logins to remote machines with single sign-on, remembered in the keyring of the computer; registration and admin pages for the users of a machine;
• Help and About dialogs; About shows the version of the Workbench and of each machine.

The Final Test of Eve

The Workbench is written in Eve on purpose: a real application, used every day, is the hardest test a language can get. It needs every level of Eve at once, so it is the acceptance test of level 7 and a stress test of the virtual machine:

The stress goals: ten remote machines connected at once, twenty browser tabs following live logs, a query of a million rows read page by page, answers under 100 ms on the local computer, and eight hours of use with flat memory. When the Workbench fails, the question is first about Eve: the fix goes into the language or the virtual machine, never around it.

Architecture

The Workbench never runs the user's code itself. Every action on a machine is a command sent to that machine, the same command a person types at the prompt eve:> or sends with eve -c. So the Workbench can do exactly what the machine allows: a remote machine that refuses debug mode refuses it in the Workbench too.

+------------------------+  HTTP    +---------------------------+  4042, TLS  +-------------------+
| Browser                |  JSON    | Local Eve machine         |  login      | Remote machine    |
|  index.html, css/, js/ | -------> |  serve, localhost:8042    | ----------> |  prod             |
|  menu, editor, panels  | <------- |  eveux project, in Eve    | ----------> |  etl2             |
+------------------------+          |  keyring of the computer  |             +-------------------+
                                    +---------------------------+

The answers of the Workbench are routes of a service, as on the page Server. A sketch:

# eveux API
service eveux_api is
  from "lib" use (machines, grid);

  route command(req: Request, @res: Response) on post "/api/machines/{m}/command" is
    new answer := machines.send!(req.params["m"], req.json()["command"]);
    let res.body := answer.json();
  end command;

  route post "/api/machines/{m}/sql" apply run_sql;
  route get "/api/machines/{m}/jobs" apply list_jobs;
  route post "/api/machines/{m}/login" apply login;

  initialize
    machines.open($EVE_HOME);
end eveux_api;

Everything that is not Eve code, such as serving HTTP, live updates, connections to other machines, logins and the keyring, is a feature of the virtual machine, so every Eve program gets it, not only the Workbench.

The screen

+---------------------------------------------------------------------------------------+
| Eve Workbench  File  Edit  View  Run  Debug  Database  Jobs  Machines  Admin  Help    |
+-----------------+------------------------------------------------+--------------------+
| EXPLORER        | sales_load.eve x | orders.sql | eve.cfg        | VARIABLES          |
|  v machine dev1 |  1 # sales load                                |  v globals         |
|    v project    |  2 driver sales_load is                        |     total 1240.50  |
|      sales.eve  |  3   process main is                           |  v locals (main)   |
|    v databases  |* 4     new total := 0.0;          <- current   |     r  {id: 7 ...} |
|      v eve      |  5     for r in rows do                        | WATCH              |
|        > tables |  6       let total += r.amount;                |   total > 1000 yes |
|  > machine prod +------------------------------------------------+ CALL STACK         |
|  # machine etl2 | COMMAND | OUTPUT | RESULTS | PROBLEMS | LOG    |   main  line 4     |
|                 | eve:> run sales_load.eve                       |                    |
|                 | sql test> select region, sum(amount) from ...  |                    |
+-----------------+------------------------------------------------+--------------------+
| dev1 localhost:4042 connected | Eve 0.6.0 | Ln 4, Col 7 | eve | LF | ana (SSO)        |
+---------------------------------------------------------------------------------------+

• the menu bar on top;
• the Explorer at the left: machines, project files, databases, jobs and logs in one tree; a machine that is not logged in is locked (#), a click opens its login;
• the editor in the center, one tab per file;
• the bottom panel: Command, Output, Results, Problems, Log;
• the debug side bar at the right while debugging: Variables, Watch, Call stack, Breakpoints;
• the status bar: machine, connection, version, cursor, language, line ending, and the user on the active machine with the way they logged in.

Panels are resized by dragging their borders; the layout is kept per user. A dark and a light theme are chosen in the View menu.

Menus

Every menu item also has a shortcut: F5 run, F9 breakpoint, F10 step over, F11 step into, Shift+F11 step out, Ctrl+Enter run the SQL under the cursor, Ctrl+Shift+P the command palette.

Login and Users

People log in to machines, not to the Workbench. Users, passwords and roles belong to each remote machine; the local machine keeps one login per remote machine. The Workbench itself opens with a one-time link that the local machine prints when it starts, so another user of the same computer can't use it.

Login form

The first time a remote machine is opened, its login form offers:

• Single sign-on: a button "Sign in with <provider>". The browser shows the page of the identity provider of the company, the person signs in there, with its second factor, and the remote machine receives a proof of identity, never the password;
• or the user name and password of an account of that machine, for a machine without single sign-on;
• Remember on this computer: the credentials that the remote machine gives back are kept in the keyring of the operating system, the Credential Manager of Windows or the Secret Service of Linux. The next time, the connection opens without a form.

Log out ends the session on the machine and deletes the stored credentials; Forget credentials deletes them only from the keyring. The same logins work without the Workbench, at the prompt of the local machine:

eve:> login prod        ** first time: the single sign-on page opens in the browser
eve:> whoami prod       ** ana, developer, single sign-on
eve:> send prod "report"
eve:> logout prod       ** the session ends, the keyring forgets it

Registration and the first admin

The first admin of a machine is created on its own console, when the machine is set up; nothing else can create it. Each machine then chooses how other people get an account:

Roles

Each machine keeps its own roles, so a person may be developer on dev1 and viewer on prod. With single sign-on, a machine can give roles from the groups of the identity provider. The admin pages of the Workbench (users, registration, sessions, audit log) are commands of the machine, so an admin can do the same with eve -c.

Database Object Tree

The Explorer shows each machine with its project folder, its databases, its jobs and its logs. A node loads its children when it is opened:

machine dev1 (localhost:4042)
  project            eve.cfg, *.eve, asp/, lib/, web/, data/, out/
  databases
    eve              the Eve database of the machine (SQLite)
      tables
        orders       id: Integer, customer: String, amount: Decimal, created: Instant
      views
      checkpoints
    test             evedb://localhost:8044/eve_test
  jobs
  logs
machine prod (etl1.example.com:4042)   ana, single sign-on
machine etl2 (etl2.example.com:4042)   locked: log in

Columns are shown in Eve types, the same types a program reads (see Databases). The context menu of a table selects the first rows, counts them, describes the table, generates the Eve record class of the table, and imports or exports a file.

Editor and Syntax Colors

The editor is written in plain JavaScript: a text area that holds the text, laid over a block that shows the same text in colors. The browser does the typing, the selection and the undo; the editor does the colors, the line numbers, the breakpoints in the gutter, find and replace, go to line and toggle comment. The errors of check are underlined and listed in the Problems tab.

One colorizer serves five languages, each described by a table of rules:

Command Window and Direct SQL

The Command tab is the prompt of the active machine inside the browser, with history and completion. It has two modes:

eve:> check sales_load.eve            ** a command of the machine
eve:> run sales_load.eve --region EU   ** run a script, its output streams below
eve:> sql test                         ** enter SQL mode on the connection "test"
sql test> select region, sum(amount) as total from orders group by region;
sql test> exit                         ** back to the commands of the machine

Direct SQL answers in the Results tab as a grid, the way the data will look in a report: column names with their Eve types, numbers aligned to the right, null in grey, dates in ISO form. The grid sorts and filters, pages through large results, copies cells, and exports CSV, JSON or an Eve DataSet. A statement that changes data runs inside a transaction, and the Results tab shows Commit and Rollback, so nothing changes by accident.

Job Scheduler and Browser

A machine that listens can run drivers on a schedule (see Server). The job browser shows the schedules and the runs of every machine the user is logged in to. It borrows the ideas of Jenkins and adds what Eve knows about its own programs:

A new job is a form: the driver, its parameters, when it runs, how many times it retries and after how long. The form writes the schedule into the configuration of the machine, and the machine applies it without a restart:

schedule "sales_load"  at "02:00" every day
schedule "orders_sync" every 15min

The pages are a dashboard of all jobs (last status, last success, last failure, duration, next run), the job page with the stage view of the last runs, the run page with its live log, and a calendar that shows when two heavy loads collide.

Log inspector

The log inspector reads the run logs of a machine: a list filtered by driver, date and status; a viewer that loads big files by parts and follows a growing file; levels in colors and a filter by text. An error line file:line: error <code>: message becomes two links: one to the line in the editor, one to the meaning of the code (see Exceptions). Two runs of the same job can be shown side by side to find what changed.

Debugger

The debugger of the Workbench is a face of the debugger of the machine (see EVE VM): debug mode, halt in the code, and the commands of the prompt. The Workbench adds the gutter, the side bar and the shortcuts:

• The variable inspector shows the globals of the driver and the locals of the selected frame; records, lists and maps open as trees;
• The watch window keeps expressions that are evaluated again at every stop; a value that changed is highlighted;
• A breakpoint set in the gutter is not written in the file, unlike halt; a forgotten breakpoint never reaches production;
• Debugging works on the local machine; a remote machine refuses it unless its configuration allows it, and then the Debug menu is grey and says why.

The commands marked "proposed" belong to the machine, not to the Workbench, so that the prompt and eve -c get them too. They wait for a decision of the author.

Files and Import

The file dialog has two sources: the folders of a machine (project, data/, out/, web/), with a filter by type, and the computer of the user, with a drop zone and a Browse button that upload the files to the machine.

Import data is a wizard on top of the dialog: choose a CSV or JSON file, see the first rows, choose the connection and the table, map the columns to Eve types (guessed from the data), choose append, replace or upsert, and run. An import is a run of the machine, so it appears in the job history with its log.

Help and About

Help opens the help topics of the Workbench, the list of shortcuts and links to this tutorial; F1 on a keyword in the editor opens its tutorial page. About shows the versions:

Eve RAD Workbench    eveux 0.1.0   (on Eve 0.6.0, the local machine)
Machine prod         Eve 0.6.0
Databases            SQLite 3.54.0, evedb 0.2 / DuckDB 1.5.6
(c) 2026 Sage-Code Laboratory, Elucian Moise

Security

• Local only: the Workbench is served by the local machine on localhost and opens with a one-time link; a team shares remote machines, not a Workbench;
• Credentials stay with the local machine, in the keyring of the computer; they never reach the browser and never go into a file of the project;
• Passwords are never stored: the keyring holds what the remote machine gave back after the login, and single sign-on never shows the password to Eve at all;
• Every value that comes from a machine, a file or a database is shown as text, never as HTML;
• Rights are checked by each remote machine, which also keeps the audit log: logins, role changes, runs, SQL that changed data and uploads.

Versions

The Workbench is built during version 0.6 of Eve. Each part can start as soon as the features it needs pass their tests, and each part tests them:

Read next: Compiler