d4hines

(ns rectangles.core
  (:require [reagent.core :as reagent :refer [atom]]
            [datascript.core :as d]))

(def schema
  {:rectangle/left {:db/valueType :db.type/ref}
   :rectangle/right {:db/valueType :db.type/ref}
   :rectangle/top {:db/valueType :db.type/ref}
   :rectangle/bottom {:db/valueType :db.type/ref}

d4hines

;; Panel attributes
;; Top, Left, Bottom, and Right
;; Each of these is a ref to an Edge.
{:db/ident :panel/top
 :db/valueType :db.type/ref
 :db/cardinality :db.cardinality/one}
{:db/ident :panel/left
 :db/valueType :db.type/ref
 :db/cardinality :db.cardinality/one}
{:db/ident :panel/bottom

d4hines

Spira Test Workflow
  # This is a custom component I'll make that will display Spira in an IFrame.
  Open Spira Test Component 
    # Detecting this may be tricky. We need a way to start the "loop", but it's totally user driven.
    navigate to test set -> Begin Next Test
  Begin Next Test   
    # API calls. Much easier thanks to Glenn's prior art. Need to differentiate between workspaces and other attachments
    # Glenn wants us to display previous results of the same test. The API calls aren't trivial (several joins involved)
    # however, he's worked it all out in some Python code he linked me.
    Check Spira for Workspace Attachment

d4hines

Workspace A is loaded
  user requests to load B-> Switch Requested
Switch Requested
  any window responds as NOT_READY -> Workspace A is loaded
  all windows respond as READY -> Switch In Progress
Switch In Progress
  any window fails to close -> Empty Workspace is loaded
  all windows close -> Workspace B is loaded
Empty Workspace is loaded
Workspace B is loaded

d4hines

d4hines

% fluent win(W), where W is a window name, e.g "w".
% fluent position(W, P), where W is a window, and P is a possible position, e.g "p1"
% Note: position is really a total function: every window has one and only one position. position is not injective, i.e windows can occupy the same position.

% add(W, P) causes window(W).
window(W, T + 1) :- occurs(add(W, P), T).
% add(W, P) causes position(W, P).
position(W, T + 1) :- occurs(add(W, P), T).
% remove(W) causes -window(W).
-window(W, T + 1) :- occurs(remove(W), T).

d4hines

#const n = 4.
step(0..n).

% Actions can affect state.
% Actions always produce a single new model.
state(Val, I + 1) :- occurs(action(Val), I).

% Inertia for state.
state(Val, I + 1) :- state(Val, I), not occurs(action(_), I), I < n.

d4hines

I'm trying to convert ALM to DDLog. I've come up with a contrived example that still models a lot of ALM's features.

The domain is this: we have rectangle objects on some Cartesian plane. Users can move the rectangles around the plane. Some rectangles are "magic rectangles". Normally, each magic rectangle is blue. However, when the user moves a magic rectangle to a particular area of the plane, the rectangle turns red.

Below is:

• A small intro to ALM
• The full ALM program

d4hines

// Role-Based Access Control in ALM
// This document includes 3 ALM modules
// that encode the core and hierachical
// components of the RBAC challenge.
// Link to official description: https://www3.cs.stonybrook.edu/~liu/papers/RBACchallenge-LPOP18.pdf

// Several entities are added and removed
// dynamically. We'll model there behavior
// as a separate module.
module dynamic_entity

d4hines

# Edit this configuration file to define what should be installed on
# your system.  Help is available in the configuration.nix(5) man page
# and in the NixOS manual (accessible by running ‘nixos-help’).

{ config, pkgs, ... }:

{
  imports =
    [ # Include the results of the hardware scan.
      ./hardware-configuration.nix