+++ /dev/null
-#!/usr/bin/env bash
-
-# The build environment.
-#
-env_error=false
-if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
- echo "env_build:: This script must be sourced, not executed."
- env_error=true
-fi
-if [ -z "$ENV_DEV" ]; then
- echo "env_build:: script can only be run from the developer environment"
- env_error=true
-fi
-if [ "$env_error" = true ]; then
- return 1
-fi
-
-export JAVA_HOME="$REPO_HOME/tool/jdk-11"
-export GROOVY_HOME="$REPO_HOME/tool/groovy-4.0.9"
-
-export PATH=\
-"$REPO_HOME"/developer/shell\
-:"$JAVA_HOME"/bin\
-:"$GROOVY_HOME"/bin\
-:"$PATH"
-
-export CLASSPATH=\
-"$REPO_HOME"/developer/jvm\
-:"$REPO_HOME"/developer/jvm/Ariadne.jar\
-:"$JAVA_HOME"/lib\
-:"$GROOVY_HOME"/lib\
-:"$CLASSPATH"
-
-export ENV_DEV_BUILD=true
-echo "${BASH_SOURCE[0]}" "complete"
+++ /dev/null
-#!/bin/env bash
-
-if [ -z "$ENV_DEV" ]; then
- echo "make.sh:: script can only be run from the developer environment"
- return 1
-fi
-
-# Ensure we are in the right directory
-cd "$REPO_HOME"/developer
-
-# Clean the scratch_pad and jvm directories
-echo "Cleaning scratch_pad and jvm directories..."
-rm -rf scratch_pad/*
-rm -rf jvm/*
-
-# Compile all files
-echo "Compiling files..."
-javac javac/*.java -d scratch_pad
-
-if [ $? -ne 0 ]; then
- echo "Compilation failed."
- exit 1
-fi
-
-# Create a JAR file from the compiled class files
-echo "Creating JAR file..."
-mkdir -p jvm
-jar cf jvm/Ariadne.jar -C scratch_pad .
-
-if [ $? -eq 0 ]; then
- echo "JAR file created successfully: jvm/Ariadne.jar"
-else
- echo "Failed to create JAR file."
- exit 1
-fi
+++ /dev/null
-#!/usr/bin/env groovy
-
-// Access the environment variable REPO_HOME
-def repo_home = System.getenv('REPO_HOME')
-def env_dev_build = System.getenv('ENV_DEV_BUILD')
-def arg_error = false
-if (!repo_home) {
- println "release:: REPO_HOME is not set."
- arg_error = true
-}
-if (!env_dev_build) {
- println "release:: ENV_DEV_BUILD is not set."
- arg_error = true
-}
-if (arg_error) {
- System.exit(1)
-}
-
-def release_dir = "${repo_home}/release_candidate"
-def release_dir_file = new File(release_dir)
-if (!release_dir_file.exists()) {
- release_dir_file.mkdirs()
-}
-
-// Function to use 'install' command for copying and setting permissions
-def install_file(source_fp, target_dp, perms) {
- def target_file = "${target_dp}/${new File(source_fp).name}"
- try {
- def cmd = ["install", "-m", perms, source_fp, target_file]
- def process = cmd.execute()
- process.waitFor()
- if (process.exitValue() != 0) {
- println "Error: Failed to install ${new File(source_fp).name} to ${target_dp}"
- println process.err.text
- System.exit(1)
- }
- println "Installed ${new File(source_fp).name} to ${target_dp} with permissions ${perms}"
- } catch (Exception e) {
- println "Error: ${e.message}"
- System.exit(1)
- }
-}
-
-println "Starting release process..."
-
-def build_fp = "${repo_home}/developer/groovy/build"
-def ariadne_class_files = new File("${repo_home}/developer/groovyc").listFiles().findAll {
- it.name.startsWith("AriadneGraph") && it.name.endsWith(".class")
-}
-
-// Install the build script
-install_file(build_fp, release_dir, "ug+r,ug+x")
-
-// Install all matching class files
-ariadne_class_files.each { class_file ->
- install_file(class_file.absolutePath, release_dir, "ug+r")
-}
-
-println "Release process completed successfully."
+++ /dev/null
-#!/bin/env bash
-
-# get this from the project management level exector directory
-"$REPO_HOME"/executor/version
\ No newline at end of file
+import com.ReasoningTechnology.Ariadna.*;
+
public class PaintItBlack {
public static void main(String[] args) {
System.out.println("Paint it black.");
--- /dev/null
+#!/usr/bin/env bash
+
+# The build environment.
+#
+env_error=false
+if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
+ echo "env_build:: This script must be sourced, not executed."
+ env_error=true
+fi
+if [ -z "$ENV_DEV" ]; then
+ echo "env_build:: script can only be run from the developer environment"
+ env_error=true
+fi
+if [ "$env_error" = true ]; then
+ return 1
+fi
+
+export JAVA_HOME="$REPO_HOME/tool/jdk-11"
+export GROOVY_HOME="$REPO_HOME/tool/groovy-4.0.9"
+
+export PATH=\
+"$REPO_HOME"/developer/shell\
+:"$JAVA_HOME"/bin\
+:"$GROOVY_HOME"/bin\
+:"$PATH"
+
+export CLASSPATH=\
+"$REPO_HOME"/developer/jvm\
+:"$REPO_HOME"/developer/jvm/Ariadne.jar\
+:"$JAVA_HOME"/lib\
+:"$GROOVY_HOME"/lib\
+:"$CLASSPATH"
+
+export ENV_DEV_BUILD=true
+echo "${BASH_SOURCE[0]}" "complete"
--- /dev/null
+#!/bin/env bash
+
+if [ -z "$ENV_DEV" ]; then
+ echo "make.sh:: script can only be run from the developer environment"
+ return 1
+fi
+
+# Ensure we are in the right directory
+cd "$REPO_HOME"/developer
+
+# Clean the scratch_pad and jvm directories
+echo "Cleaning scratch_pad and jvm directories..."
+rm -rf scratch_pad/*
+rm -rf jvm/*
+
+# Compile all files
+echo "Compiling files..."
+javac javac/*.java -d scratch_pad
+
+if [ $? -ne 0 ]; then
+ echo "Compilation failed."
+ exit 1
+fi
+
+# Create a JAR file from the compiled class files
+echo "Creating JAR file..."
+mkdir -p jvm
+jar cf jvm/Ariadne.jar -C scratch_pad .
+
+if [ $? -eq 0 ]; then
+ echo "JAR file created successfully: jvm/Ariadne.jar"
+else
+ echo "Failed to create JAR file."
+ exit 1
+fi
--- /dev/null
+#!/usr/bin/env groovy
+
+// Access the environment variable REPO_HOME
+def repo_home = System.getenv('REPO_HOME')
+def env_dev_build = System.getenv('ENV_DEV_BUILD')
+def arg_error = false
+if (!repo_home) {
+ println "release:: REPO_HOME is not set."
+ arg_error = true
+}
+if (!env_dev_build) {
+ println "release:: ENV_DEV_BUILD is not set."
+ arg_error = true
+}
+if (arg_error) {
+ System.exit(1)
+}
+
+def release_dir = "${repo_home}/release_candidate"
+def release_dir_file = new File(release_dir)
+if (!release_dir_file.exists()) {
+ release_dir_file.mkdirs()
+}
+
+// Function to use 'install' command for copying and setting permissions
+def install_file(source_fp, target_dp, perms) {
+ def target_file = "${target_dp}/${new File(source_fp).name}"
+ try {
+ def cmd = ["install", "-m", perms, source_fp, target_file]
+ def process = cmd.execute()
+ process.waitFor()
+ if (process.exitValue() != 0) {
+ println "Error: Failed to install ${new File(source_fp).name} to ${target_dp}"
+ println process.err.text
+ System.exit(1)
+ }
+ println "Installed ${new File(source_fp).name} to ${target_dp} with permissions ${perms}"
+ } catch (Exception e) {
+ println "Error: ${e.message}"
+ System.exit(1)
+ }
+}
+
+println "Starting release process..."
+
+def build_fp = "${repo_home}/developer/shell/build"
+def ariadne_jar_fp = "${repo_home}/developer/jvm/AriadneGraph.jar"
+
+// Install the build script
+install_file(build_fp, release_dir, "ug+r")
+
+// Install the JAR file
+install_file(ariadne_jar_fp, release_dir, "ug+r")
+
+println "Release process completed successfully."
--- /dev/null
+#!/bin/env bash
+
+# get this from the project management level exector directory
+"$REPO_HOME"/executor/version
\ No newline at end of file
+++ /dev/null
-
-Directories Naming Convention
------------------------------
-
-Property based file organization
-
- I am experimenting with a file system where instead of having directories, we
- have collections of files that have property in common.
-
- In this distribution the project is on a conventional file system, but we still
- have the directory names. These following properties have been used, in
- order of preference:
-
- 1. Who the file is for. This is typically a role of a contributor
- to the project, or the name of a program.
-
- 2. The role that the file plays in the project. This is more general than
- saying a file is for a specific program, or even kind of program. As an
- example, the 'tool' directory.
-
- 3. A role that the directory plays. As an example, 'scratch_pad'. Another
- example is 'deprecated' which is a short term archived file.
-
- In this third category the file property is imposed upon the file,
- rather than being a description of the file's contents.
-
- One side effect of grouping files based on a shared property is that
- the directory name, coming from the property name, is often singular.
-
-Who the file is for
-
- These file groups fit the model well: developer, tester, user. Also in the
- developer directory, directories named after programs work well, as examples,
- python, groovy, cc, linker, javac, etc.
-
-Generalization of who the file is for, e.g. executor
-
- Sometimes multiple related actors operate on the files in a directory. In
- which case we give the directory a more general name that describes the
- actors as a group.
-
- So if we had a directory that held a mix of files for various compilers we might
- name the directory 'compiler_input' or even 'compiler'. If the files are
- interpreted and multiple interpreters are involved, then 'interpreter_input'.
-
- A such generalization you will see in this project is 'executor'. An executor
- is any program that runs another program; examples include shells that
- interpret shell scripts; various language interpreter; and most famously the
- machine loader, which will load an instruction sequence into memory and point
- the program counter at it.
-
-document
-
- What role do people play when reading documents? That this question does not
- have an obvious direct answer says something about our values, and this in
- turn might explain why so few people actually read the documents.
-
- An author will call the person reading his work 'the reader', perhaps even
- addressing a reader directly, 'Dear Reader'. However, the are a large number
- of reader programs and devices, such as Adobe Reader and a bar card reader.
- Unlike toolsmith, developer, and tester, being a 'reader' is not a job
- title that a person is going to be addressed by.
-
- A person might reach for latin and use the word, 'lector'. However it is
- a stretch to get the meaning from this one. Perhaps we move to Greek, and
- imagine the role 'projectologist'. lol. Perhaps shortened to 'ologist'?
-
- Actually, there is a word for a person who studies books, articles, and
- documents, a 'student'. It is actually a fairly accurate description of the
- role a person plays while trying to learn about the project. The only drawback
- is that it is not a professional role title. Perhaps it is not much of a
- stretch to say someone is still in the student phase learning about a project.
- I tried this label out for a while, but it did not really fit.
-
- There is a clear property choice. Each file in the document directory has the
- property of being a document, hence, the directory name is 'document'. The
- document directory at the top level is for the project manager, while the
- document directory in the developer's directory is about the code being
- developed and hold to build it.
-
-
-Purpose - tool, temporary, deprecated
-
- For some other directories it is even more of a stretch to try and say
- they are for an actor.
-
- Ancient man would make up spirits in such situations. Perhaps then files in a
- temporary directory are for the 'tanuki', a real animal in Japan who that has
- taken on mythical proportions causing things to disappear or playing tricks. A
- directory of deprecated files could said to be for 'Lethe', the river that
- carries away the memories of those who are reincarnated - which reminds me of
- the rivers in so many places that carry away trash. I tried these names
- out. It was good entertainment, but when trying to explain them I met with
- blank expressions.
-
- Since in these cases we can not answer the question of who the files are for,
- we instead choose another common property shared by each and every file in the
- directory. Hence we end up with 'tool' for the directory with tools, instead
- of saying they are for the tool smith, or even for Hephaestus, besides tool
- smiths such as Hephaestus create tools, and the tool directory is full of
- tools that were already created.
-
-Top level directory
-
- The top level of a github project is of course named after the project. Here
- to us programmers have appealed to mythology to find actors. Just look at all
- the mythical animals on the covers of the O'Reilley manuals.
-
- The top level directory of our git project is reserved for project manager to
- use. The 'project manager', in this context, builds the directory structure,
- initializes the repository, installs tools that will be needed, and generally
- administers the project.
-
- In the environment, the top level directory is located at `$REPO_HOME`
-
-developer
-
- The developer's directory is located at `$REPO_HOME/developer`.
-
- This directory contains the developer's workspace. Developers are free to
- organize it in any manner they see fit, though they should continue to follow
- the convention of naming directories after properties when it is practical to
- do so.
-
- As examples,
-
- - Files for the **C compiler** are placed in the `cc` directory, since they
- are "for" the C compiler.
-
- - Files for the **Java compiler** (javac) are stored in the `javac` directory.
-
- - Similar naming conventions are followed for other tools. For instance, if
- the project involves files for another tool or compiler, the directory is
- named after that tool.
-
-scratch_pad
-
- This is a temporary directory used by programs. Files in this directory are
- typically removed by the program that placed the file, or by a `clean` script.
- There is no reason a developer can not manually add a file, but scripts such
- as `make clean`, might delete it. Directories with this name should be git
- ignored.
-
-deprecated
-
- As a developer I often have files that I set aside just in case I want to look
- at them again. Sometimes I plan to bring them back later. Unlike temporary files,
- they are not deleted by any clean script or any program that is using them as
- intermediate files. This directory is similar in intent to `git stash` or
- using to and going back to look at old versions. The contents of this directory
- do end up in the repo.
-
-LocalWords: projectologist
--- /dev/null
+<!DOCTYPE html>
+<html lang="en">
+<head>
+ <meta charset="UTF-8">
+ <meta name="viewport" content="width=device-width, initial-scale=1.0">
+ <title>Directory Structure Description</title>
+ <style>
+ body {
+ background-color: hsl(0, 0%, 0%);
+ color: hsl(42, 100%, 80%);
+ font-family: monospace;
+ padding: 20px;
+ margin: 0;
+ }
+ .page {
+ padding: 20px;
+ margin: 20px auto;
+ max-width: 800px;
+ background-color: hsl(0, 0%, 10%);
+ box-shadow: 0 0 10px hsl(42, 100%, 50%);
+ }
+ ul, li {
+ list-style-type: none;
+ }
+ li::before {
+ content: "📁 ";
+ margin-right: 5px;
+ }
+ li {
+ margin-bottom: 5px;
+ }
+ .description {
+ margin-left: 10px;
+ color: hsl(42, 100%, 60%);
+ }
+ h1 {
+ text-align: center;
+ color: hsl(42, 100%, 80%);
+ text-transform: uppercase;
+ margin-bottom: 20px;
+ }
+ h2 {
+ color: hsl(42, 100%, 80%);
+ text-transform: uppercase;
+ margin-top: 40px;
+ }
+ p {
+ color: hsl(42, 100%, 70%);
+ margin-bottom: 20px;
+ }
+ </style>
+</head>
+<body>
+
+ <div class="page">
+ <h1>Directory Structure Description</h1>
+
+ <h2>Reference</h2>
+
+ <ul>
+ <li>/var/user_data/Thomas-developer/Ariadne</li>
+ <ul>
+ <li>developer/ <span class="description">The workspace for developers to organize source code, build scripts, and development-specific tools.</span></li>
+ <ul>
+ <li>deprecated/ <span class="description">Archived files and older versions no longer in active use.</span></li>
+ <li>document/ <span class="description">Developer-level documentation for building and understanding the project.</span></li>
+ <li>javac/ <span class="description">Java source files prepared for compilation.</span></li>
+ <li>jvm/ <span class="description">Compiled Java bytecode files for the project.</span></li>
+ <li>scratch_pad/ <span class="description">Temporary storage for intermediate files during development.</span></li>
+ <li>shell/ <span class="description">Shell scripts intended to be part of the project release or build automation.</span></li>
+ <li>tool/ <span class="description">Developer-specific tools used for building or managing development tasks.</span></li>
+ </ul>
+ <li>document/ <span class="description">Top-level project documentation for project managers or contributors.</span></li>
+ <li>release_candidate/ <span class="description">Builds and packages ready for testing and release preparation.</span></li>
+ <li>scratch_pad/ <span class="description">Temporary storage for project management tasks.</span></li>
+ <li>tester/ <span class="description">Files and tools for managing and running test environments.</span></li>
+ <ul>
+ <li>document/ <span class="description">Test-specific documentation for procedures and setups.</span></li>
+ <li>test0/ <span class="description">Test case 0 environment and associated scripts.</span></li>
+ <li>test1/ <span class="description">Test case 1 environment and associated scripts.</span></li>
+ <li>test2/ <span class="description">Test case 2 environment and associated scripts.</span></li>
+ <li>tool/ <span class="description">Tools needed for testing and managing the test environment.</span></li>
+ </ul>
+ <li>tool/ <span class="description">Project management/administration specific tools.</span></li>
+ <li>tool_shared/ <span class="description">Tools shared across project roles.</span></li>
+ <ul>
+ <li>bespoke/ <span class="description">Tools developed specifically for this project.</span></li>
+ <li>customized/ <span class="description">Modified versions of third-party tools adapted for the project.</span></li>
+ <li>document/ <span class="description">Documentation related to shared tools and setup.</span></li>
+ <li>third_party/ <span class="description">Tools sourced from third-party vendors or open-source projects.</span></li>
+ </ul>
+ <li>LICENSE.txt <span class="description">The project license detailing usage and distribution terms.</span></li>
+ <li>README.md <span class="description">A general overview and introduction to the project.</span></li>
+ </ul>
+ </ul>
+
+
+ <h2>Name origin and rationale</h2>
+
+ <p>Typically, developers and project administrators do not employ a semantic
+ system for naming directories, but more commonly use conventional
+ placeholder names. The intended purpose of files in a directory with a
+ placeholder name then must be inferred from experience or inspection of
+ the files, or learned from other people or from documents.</p>
+
+ <p>For example, a directory named 'exe/' probably derives its name from the
+ fact that the contained files have their executable permission bit set;
+ however, such a directory will not contain all such files. There might
+ even be some files in an `exe/` directory that do not have their
+ executable permission bit set. The two concepts being an `exe/` file
+ (i.e. being a file in an `exe/` directory) and being an executable file
+ are not identical. The actual intended meaning of being an `exe/` file
+ will sometimes be that the contained files are applications available to a
+ user, or that they are tools available for use in a project.
+ </p>
+
+ <p>The directory names in this project resulted from an exploration of a
+ property-based file system. In such a system a number of files and
+ agents are defined. Then we can ask questions about their relationships.
+ Files with a relationship to the developer are collected, and this
+ becomes the `developer/` directory. In a similar manner we get the
+ directories, `tester/', and `javac/`. In this latter case the
+ agent is a compiler rather than a role.
+ </p>
+
+ <p>However, when attempting this it became apparent that the recognition of
+ relationships was insufficient. Consider the directories `deprecated` and
+ `scratch_pad`. There is no 'Mr. Deprecated' or 'Mr. Scratch_Pad' who the
+ contained files are for. (And this conclusion is not for the lack of
+ trying. Even mythological beings did not suffice as agents.) Rather than
+ saying a file has a relationship with an agent, these properties
+ (directory names) are states imposed by decree by an agent on a file.
+ Perhaps the developer, has decreed that a file is now deprecated, or a
+ build script has decreed that it is a scratch_pad file. Such decrees are
+ typically more dynamic than the relationship properties. Also, these
+ properties are also disconnected from the contents of the file. When, for
+ example, we say a file is for the java compiler we can surmise something
+ about its contents. However when we say a file is `deprecated` we can
+ surmise nothing about its contents.
+ </p>
+
+ <p>To understand a directory name within this system, one can imagine
+ reading said name as part of a sentence that integrates the
+ property. Consider two property names: 'is-a' and 'is-for'. For example,
+ "Each file in the <code>document/</code> directory is a document," or
+ "Each file in the <code>developer/</code> directory is for the developer."
+ Although the property name is not carried over to the conventional file
+ system, we can typically infer what it must be. It is beyond the scope of
+ discussion here, but in actuality, our collections are defined by
+ predicates that are given a file's properties and relationships as
+ arguments, where the predicate resolves to true if and only if the file
+ belongs to the collection. Now wouldn't that be interesting if we
+ instead derived a probability?
+ </p>
+
+ <p>It is uncommon for a property value to be plural. While it is not
+ disallowed, it rarely occurs in practice. This is true independent of
+ whether we are discussing a relationship property or a state
+ property. Hence when we make a file collection based on a shared property,
+ then carry that over as a directory name in a conventional file system,
+ the resulting directory name will often be singular. This pattern can be
+ observed in the case of the `document/` directory, as shown in the prior
+ paragraph.
+ </p>
+
+ </div>
+
+</body>
+</html>
+++ /dev/null
-#!/usr/bin/env bash
-
-# Ensure the script is sourced
-if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
- echo "This script must be sourced, not executed. Exiting."
- return 1
-fi
-
-# These are things set by the `repo` command found in the `resource` project,
-# but if you don't have that, then source this into the environment.
-
-script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
-export REPO_HOME="${script_path%/*}"
-export PROJECT=$(basename "$REPO_HOME")
-
-PPS1="\n[$PROJECT]\n\u@\h§$(pwd)§\n> "
-PPS2=">> "
-
-echo REPO_HOME "$REPO_HOME"
-echo PROJECT "$PROJECT"
-echo "${BASH_SOURCE[0]}" "complete"
-
-export ENV_BASE=true
+++ /dev/null
-#!/usr/bin/env bash
-
-# Ensure the script is sourced
-if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
- echo "This script must be sourced, not executed. Exiting."
- return 1
-fi
-
-if [ -z "$ENV_BASE" ]; then
- script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
- source "${script_path}/env_base"
-fi
-
-export PATH="$REPO_HOME/developer/executable":"$PATH"
-
-# so the .gitignore files can be seen:
-alias ls="ls -a"
-
-cd "$REPO_HOME/developer"
-
-export ENV_DEV=true
-source "$REPO_HOME"/developer/executable/env_build
-echo "${BASH_SOURCE[0]}" "complete"
-
-
-
+++ /dev/null
-#!/usr/bin/env bash
-
-# Ensure the script is sourced
-if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
- echo "This script must be sourced, not executed. Exiting."
- return 1
-fi
-
-if [ -z "$ENV_BASE" ]; then
- script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
- source "${script_path}/env_base"
-fi
-
-ENV_PM=true
-
-PROJECT="$PROJECT"_PM
-
-export PATH=\
-"$REPO_HOME"/executor\
-:"$PATH"
-
-# no sneaky hidden files
-alias ls="ls -a"
-
-
-export ENV_PM=true
-echo "${BASH_SOURCE[0]}" "complete"
+++ /dev/null
-#!/usr/bin/env bash
-
-# Ensure the script is sourced
-if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
- echo "This script must be sourced, not executed. Exiting."
- return 1
-fi
-
-# Check if REPO_HOME is set, if not source env_base
-if [ -z "$ENV_BASE" ]; then
- script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
- source "${script_path}/env_base"
-fi
-
-PROJECT="$PROJECT"_TESTER
-
-export PATH=\
-"$REPO_HOME"/tester/executor\
-:"$PATH"
-
-cd "$REPO_HOME"/tester
-
-
-export ENV_TESTER=true
-source executor/env_tester
-echo "${BASH_SOURCE[0]}" "complete"
+++ /dev/null
-#!/bin/env bash
-
-echo 0.1
-
+++ /dev/null
-#!/bin/env bash
-
-# Ensure the script is sourced
-if [ -z "$ENV_TESTER" ]; then
- echo "env_build:: script can only be run in the tester environment"
- return 1
-fi
-
-cd "$REPO_HOME"/tester/test0
-groovyc TestGraph.groovy
+++ /dev/null
-#!/usr/bin/env bash
-# environment common to all tests
-# each test directory also has an environment
-
-export JAVA_HOME="$REPO_HOME/tool/jdk-11"
-export GROOVY_HOME="$REPO_HOME/tool/groovy-4.0.9"
-
-export PATH=\
-"$REPO_HOME"/release_candidate\
-:"$JAVA_HOME"/bin\
-:"$GROOVY_HOME"/bin\
-:"$PATH"
+++ /dev/null
-#!/bin/env bash
-
-if [ -z "$ENV_TESTER" ]; then
- echo "make.sh:: script can only be run in the tester environment"
- env_error=true
-fi
-
-set -x
-
-groovyc TestGraph.groovy
--- /dev/null
+#!/bin/env bash
+
+# Ensure the script is sourced
+if [ -z "$ENV_TESTER" ]; then
+ echo "env_build:: script can only be run in the tester environment"
+ return 1
+fi
+
+cd "$REPO_HOME"/tester/test0
+groovyc TestGraph.groovy
--- /dev/null
+#!/usr/bin/env bash
+# environment common to all tests
+# each test directory also has an environment
+
+export JAVA_HOME="$REPO_HOME/tool/jdk-11"
+export GROOVY_HOME="$REPO_HOME/tool/groovy-4.0.9"
+
+export PATH=\
+"$REPO_HOME"/release_candidate\
+:"$JAVA_HOME"/bin\
+:"$GROOVY_HOME"/bin\
+:"$PATH"
--- /dev/null
+#!/bin/env bash
+
+if [ -z "$ENV_TESTER" ]; then
+ echo "make.sh:: script can only be run in the tester environment"
+ env_error=true
+fi
+
+set -x
+
+groovyc TestGraph.groovy
+++ /dev/null
-*
-!/.gitignore
-!/document
-# upstream has a .gitignore file in it
-!/upstream
--- /dev/null
+#!/usr/bin/env bash
+
+# Ensure the script is sourced
+if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
+ echo "This script must be sourced, not executed. Exiting."
+ return 1
+fi
+
+# These are things set by the `repo` command found in the `resource` project,
+# but if you don't have that, then source this into the environment.
+
+script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
+export REPO_HOME="${script_path%/*}"
+export PROJECT=$(basename "$REPO_HOME")
+
+PPS1="\n[$PROJECT]\n\u@\h§$(pwd)§\n> "
+PPS2=">> "
+
+echo REPO_HOME "$REPO_HOME"
+echo PROJECT "$PROJECT"
+echo "${BASH_SOURCE[0]}" "complete"
+
+export ENV_BASE=true
--- /dev/null
+#!/usr/bin/env bash
+
+# Ensure the script is sourced
+if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
+ echo "This script must be sourced, not executed. Exiting."
+ return 1
+fi
+
+if [ -z "$ENV_BASE" ]; then
+ script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
+ source "${script_path}/env_base"
+fi
+
+export PATH="$REPO_HOME/developer/executable":"$PATH"
+
+# so the .gitignore files can be seen:
+alias ls="ls -a"
+
+cd "$REPO_HOME/developer"
+
+export ENV_DEV=true
+source "$REPO_HOME"/developer/executable/env_build
+echo "${BASH_SOURCE[0]}" "complete"
+
+
+
--- /dev/null
+#!/usr/bin/env bash
+
+# Ensure the script is sourced
+if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
+ echo "This script must be sourced, not executed. Exiting."
+ return 1
+fi
+
+if [ -z "$ENV_BASE" ]; then
+ script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
+ source "${script_path}/env_base"
+fi
+
+ENV_PM=true
+
+PROJECT="$PROJECT"_PM
+
+export PATH=\
+"$REPO_HOME"/executor\
+:"$PATH"
+
+# no sneaky hidden files
+alias ls="ls -a"
+
+
+export ENV_PM=true
+echo "${BASH_SOURCE[0]}" "complete"
--- /dev/null
+#!/usr/bin/env bash
+
+# Ensure the script is sourced
+if [[ "${BASH_SOURCE[0]}" == "$0" ]]; then
+ echo "This script must be sourced, not executed. Exiting."
+ return 1
+fi
+
+# Check if REPO_HOME is set, if not source env_base
+if [ -z "$ENV_BASE" ]; then
+ script_path="$(dirname "$(realpath "${BASH_SOURCE[0]}")")"
+ source "${script_path}/env_base"
+fi
+
+PROJECT="$PROJECT"_TESTER
+
+export PATH=\
+"$REPO_HOME"/tester/executor\
+:"$PATH"
+
+cd "$REPO_HOME"/tester
+
+
+export ENV_TESTER=true
+source executor/env_tester
+echo "${BASH_SOURCE[0]}" "complete"
+++ /dev/null
-*
-!/.gitignore
--- /dev/null
+#!/bin/env bash
+
+echo 0.1
+
--- /dev/null
+
+#1. downlaod
+
+cd "$REPO_HOME/tool/upstream"
+curl -C - -o OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.16+8/OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz
+
+#2. extract
+
+cd "$REPO_HOME/tool"
+mkdir -p jdk-11
+tar -xzf "$REPO_HOME/tool/upstream/OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz" -C jdk-11 --strip-components 1
--- /dev/null
+
+1. Docs
+ https://groovy-lang.org/documentation.html
+
+2. Install from source
+
+ # 1.1 Download
+
+ # https://dlcdn.apache.org/groovy/
+
+ cd $REPO_HOME/toolsmith/upstream
+ wget https://dlcdn.apache.org/groovy/4.0.23/sources/apache-groovy-src-4.0.23.zip
+
+ # 1.2 then build them ;-)
+
+2. Install binaries
+
+ #!/usr/bin/env bash
+
+ # Define version of Groovy to be installed
+ version="4.0.9"
+
+ # 2.1 Download using curl
+ cd "$REPO_HOME/toolsmith/upstream"
+ curl -o apache-groovy-binary-${version}.zip https://groovy.jfrog.io/artifactory/dist-release-local/groovy-zips/apache-groovy-binary-${version}.zip
+
+ # 2.2 Extract
+ cd "$REPO_HOME/tools"
+ unzip "$REPO_HOME/tools/upstream/apache-groovy-binary-${version}.zip" -d .
--- /dev/null
+
+#1. downlaod
+
+cd "$REPO_HOME/tool/upstream"
+curl -C - -o OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz https://github.com/adoptium/temurin11-binaries/releases/download/jdk-11.0.16+8/OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz
+
+#2. extract
+
+cd "$REPO_HOME/tool"
+mkdir jdk-11
+tar -xzf "$REPO_HOME/tool/upstream/OpenJDK11U-jdk_x64_linux_hotspot_11.0.16_8.tar.gz" -C jdk-11 --strip-components 1
--- /dev/null
+*
+!/.gitignore
+# upstream has a .gitignore file in it, edit to keep anything precious
+!/upstream
--- /dev/null
+*
+!/.gitignore
projects / Ariadne / commitdiff