- The is_acyclic_q function is designed to detect cycles in a dependency graph using a depth-first search (DFS) algorithm. It starts from a list of root node labels and traverses the graph to ensure that there are no cycles. If a cycle is detected, the function marks the nodes involved and continues to explore other parts of the graph. -

Key Concepts

Functions

1. is_acyclic_q

- Purpose: To determine if the dependency graph is acyclic (i.e., contains no cycles). -

2. is_acyclic_q_descend

- Purpose: To perform the actual DFS traversal and cycle detection for a given path. -

Usage

- The is_acyclic_q function is used to ensure that the dependency graph defined in the build file is free of cycles. This is crucial for preventing infinite loops and ensuring that the build process can proceed smoothly. -

Directory Naming

- -

Reference

- -

Mosaic/aka REPO_HOME, top level owned by the project administrator.

developer/ Workspace for the developer. Has the source code, build scripts, and development-specific tools.

deprecated/ Files and older versions being viewed, perhaps part of a refactoring effort.
document/ Documentation on developing and building the project.
javac/ Java source files for compilation.
jvm/ Compiled Java bytecode files for the project, typically a jar for a Java project.
scratchpad/ Temporary storage typically for intermediate files created during build.
shell/ Shell scripts intended to be part of the project release. (These are not tools.)
tool/ Tools created by the developer, used for development tasks.

document/ General documentation about the project.
release/ Release candidate for testing. Becomes the release on the release branch.
scratchpad/ Temporary storage for project administration tasks.
tester/ Workspace for the tester. Has the test bench, tests, and test scripts.

document/ Test-specific documentation.
javac/ The tests of the test bench sources.
tool/ Tools needed for testing and managing the test environment.

tool/ Project administration specific tools.
tool_shared/ Tools shared across project roles.

bespoke/ Shared tools developed within this project.
customized/ Modified versions of third-party tools adapted for the project.
document/ Documentation related to shared tools and setup.
third_party/ Shared tools sourced from third-party vendors or open-source projects. These have their own independent licenses,

LICENSE.txt The project license detailing usage and distribution terms.
README.md A general overview and introduction to the project.

- -

Name origin and rationale

- -

Developers and project administrators typically 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 documents or other people.

- -

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. -

- -

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. -

- -

When attempting to apply the is-for property in practice it - became apparent that using this sole property was insufficient. Consider - the directories deprecated/ and scratchpad/. There is no - Mr. Deprecated or Mr. Scratchpad 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 being for an - agent, the files collected in such a directory have in common a state of - being that was imposed upon them by decree. Perhaps the developer, has - decreed that a file is now deprecated, or a build script has decreed that - it is a scratchpad file. Such decrees are typically more dynamic than the - relationship properties. Also, these properties are disconnected from the - contents of the file. When, for example, a file has the property of being - for the java compiler, we gain some information about its contents. In the - universe of possible messages sent through a file, such a file will - contain text that is proposed to be java syntax conforming. In contrast, - when we learn that a file is deprecated/ we gain no - information about the contents of the file, because any file can - be deprecated, independent of its contents. -

- -

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 document/ directory is-a document," or "Each - file in the developer/ directory is-for the - developer." Although the property name is not carried over from the - property based file system to the conventional file system, we can - typically infer what it must have been. (It is beyond the scope of - discussion here, but in actuality, property based file system collections - are defined by predicates. Each predicate is given a file's properties and - relationships as arguments, then 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?) -

- -

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. -

- -

Cycle Detection in Dependency Graph

Overview