Dependency test

.github/workflows/deploy.yml

@@ -0,0 +1,23 @@
+name: Deploy to GitHub Pages
+
+on:
+  push:
+    branches: [main]
+  workflow_dispatch:
+
+jobs:
+  build-and-deploy:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v3
+      - uses: actions/setup-node@v3
+        with:
+          node-version: 16
+          cache: 'npm'
+      - run: npm ci
+      - run: npm run build
+      - name: Deploy to GitHub Pages
+        uses: JamesIves/github-pages-deploy-action@v4
+        with:
+          folder: docs
+          branch: gh-pages

.gitignore

@@ -1,7 +1,5 @@
 node_modules
 package-lock.json
 dist
-docs
 .svelte-kit/
-.svelte-kit/ambient.d.ts
-meeting_notes
+.svelte-kit/ambient.d.ts

developer.md

@@ -45,41 +45,36 @@ npm run dev
 The project is organized into the following main directories and files:
 
 ```plaintext
-root/
-├── src/                            # Source code directory
-│   ├── assets/                     # Static assets like images, fonts, etc.
-│   ├── components/                 # UI components
-│   ├── routes/                     # Application routes (UI-related)
-│   ├── viz/                        # CORE functionality
-│   │   ├── plotUtils/              # APIs for other visualization libraries
-│   │   │   └── oplotUtils.ts       # Visualization utility file
-│   │   ├── task_graph/             # Task graph logic
-│   │   │   └── task_graph.ts       # Task graph core functionality
-│   │   ├── uapi/                   # Unified API-related functionality
-│   │   │   └── mgg.ts              # Unified API core file
-│   │   ├── canvas.ts               # Canvas rendering logic
-│   │   ├── constraint.ts           # PK and FK constraint management logic
-│   │   ├── db.ts                   # Database interaction utilities
-│   │   ├── duckdb.ts               # DuckDB-specific logic
-│   │   ├── eventemitter.ts         # Event emitter implementation
-│   │   ├── id.ts                   # Contains sql expr to generate ids
-│   │   ├── mark.ts                 # previous version of Mark
-│   │   ├── markUtils.ts            # old versions of mark utility functions
-│   │   ├── nest.ts                 # contains RootNest and MarkNest logic
-│   │   ├── newMark.ts              # The actual implementation of Mark class (CORE)
-│   │   ├── newScale.ts             # New scale definitions for visualizations
-│   │   ├── ref.ts                  # Layout algorithms
-│   │   ├── scale.ts                # previous versions of scales
-│   │   ├── schema.ts               # Contains schema class, which is used inside Table objects
-│   │   ├── table.ts                # Contains functions that generate sql queries
-│   │   └── util.ts                 # General-purpose utility functions
-│   ├── static/                     # Static files (e.g., CSV data and .py files)
-│   └── index.js                    # Entry point of the application
-├── package.json                    # NPM configuration file
-└── .gitignore                      # Specifies files ignored by Git
-```
-
-The most important file in all this is newMark.ts because that contains the main workflow for rendering Marks
+├── common              //classes/functions at different stages
+│   ├── canvas.ts
+│   ├── constraint.ts
+│   ├── db.ts
+│   ├── id.ts
+│   ├── nest.ts
+│   ├── scale.ts
+│   ├── schema.ts
+│   ├── table.ts
+│   └── types.ts
+├── core                    //core logic. split into query, layout, render and cleanup
+│   ├── cleanup.ts
+│   ├── curve.ts
+│   ├── layout.ts
+│   ├── layoutAlgorithms.ts
+│   ├── mark.ts
+│   ├── markUtils.ts
+│   ├── query.ts
+│   └── render.ts
+├── duckdb                  //duckdb stuff
+│   ├── duckdb.ts
+│   ├── eventemitter.ts
+│   └── util.ts
+├── plotUtils               //information about oplot marks
+│   └── oplotUtils.ts
+├── task_graph              //task graph to control rendering
+│   └── task_graph.ts
+└── uapi
+    └── dvl.ts              //user facing stuff (WIP)
+```
 
 ## Adding Marks
 
@@ -212,7 +207,7 @@ Note that the first argument to the get function is a column in "T".
 
 The same (intuitive?) logic applies to the other three mappings (ie. y1, x2, y2).
 
-The get function is defined in newMark.ts.
+The get function is defined in mark.ts.
 
 ```code
     get(usrSearchkeys: String | String[], usrVattr: String | String[], callback?): {othermark, searchkeys, othervattr, callback} {
@@ -281,9 +276,11 @@ Given a dot mark and a rect mark, and that we want to nest the dot within the re
 let rects = c.rect("T",{...})
 let dots = c.dot("A",{...})
 c.nest(dots, rects)
+
+//rects.nest(dots) is also supported
 ```
 
-c.nest(dots, rects) tells MGG that we want to nest dots within rects. Note that MGG will automatically infer we want to nest dots within rects using A.tid = T.tid
+rects.nest(dots) tells MGG that we want to nest dots within rects. Note that MGG will automatically infer we want to nest dots within rects using A.tid = T.tid
 
 As such, we don't need to specify a predicate like a get function in the previous section.