GithubHelp home page GithubHelp logo

sophie's Introduction

libpic

sophie's People

Stargazers

 avatar  avatar

Watchers

 avatar

Forkers

lyubomirt

sophie's Issues

SE: fix spacing in `sophie.sh`

Background

Motivation for a problem or that which needs to be built.

The newlines, spacing, and indentation within code & comments seems erratic to most people. It's just a product of my unorthodox (possibly temporary) editing environment, right now. The spacing needs to get fixed so it reads and looks better for everyone involved.

Proposal

Blueprint to resolve or implement.

  • I'd prefer tabs for the indentations to be honest. Spaces for alignment. But I feel like many people out there will not get it/will be using spaces so I'm OK with spaces to reduce friction, right now.

  • A single space between the comments and the # that starts the comment.

  • No newline between a comment and the line of code after it.

  • Extra non-necessary newlines that are separating sequential lines, should be removed

In general, just make it look good to a programmer.

SE: add mock repositories for testing

Background

Motivation for a problem or that which needs to be built.

Sophie aims to be portable and UNIX-conforming. The only sensible way to make sure this rule is never broken is to sit down and get the drudge-work, that is setting up testing, out of the way. This will also help merge pull requests easier and faster, along with improving the collaborative process of pull-requests.

Proposal

Blueprint to resolve or implement.

A top level test_dir that has multiple directories corresponding to the version number, n,: test_dir_Vn.

Mock Repositories

Each test version directory has multiple mock_repo_n directories, where:

  • n = 0 if no directories exist.
  • n is a natural number.
  • n is exactly 1 more than the largest n postfix that already exists in this directory.

Within these directories we need mock repositories with a top-level sophie.config to test Sophie on.

  • These mock repositories should vary considerably in the structure of their maintenance and style so as to match the variants of open source repository structures seen in the wild.
  • In order to achieve the previous goal well, consider theming each repository and giving a brief on its (possible multiple) copyright holders, notices, and file structure.
  • Each repository should test various features and filters without worry.

Once a major version of Sophie releases, we take a snapshot of these repositories and freeze them in their version directory such that they will not be changed after the final test passes. This ensures we don't break any old tests when making new improvements. And gives sane dividers between breaking (major change, incompatible) versions.

For the development of the next release version we clone the previous-most test_dir_Vn and build off of that.

A release is not complete until the test_dir_Vn corresponding to the release tests/touches on all of it's new AND old features.

  • At least 2 mock repositories made for V1.

SE: multi-filters for `filecabinet` and `notices`

Background

Motivation for a problem or that which needs to be built.

As part of Road to V1...

Multi-filters were part of the program's initial ideation. They are communicated on the scribbles that span random sheets in attempts to describe a sophisticated copyright linter. They are commented as TODOs in the initial commit. Thus, the linter is incomplete and mostly useless without them.

Proposal

Blueprint to resolve or implement.

filter refers to the idea of a filecabinet identifier being defined as a group of files filtered out from the entire project after imposing some conditions on the properties of the files of the entire project; or a notices identifier being described as a group of characters, making up a notice, filtered out from the set of all notices (after imposing conditions on properties of characters), essentially describing a copyright notice. It's meaning in `compliance1 is irrelevant here.

Thus, multi-filters is the program's ability to allow identifiers to be defined with multiple conditions imposed on different properties, instead of the current single filters we have. The program is incomplete without this feature because it's linting capabilities do not meet any useful requirements of testing legal standards of project.

The next filters to be implemented for filecabinet are:

  • size: accepts a condition to filter a file by size.
  • modified: accepts a condition to filter based on modification date.

The next filters to be implemented for notices are:

  • location: accepts a condition to describe the placement of a notice in a file; distinguishing it from notices placed anywhere else.
  • pattern: accepts a condition to select notices that only match this pattern.

Any other filters can also be implemented. These are the minimum necessary for V1.

SE: `refinements` for redefining identifiers

Background

Motivation for a problem or that which needs to be built.

From the flexibility sketched in the early drafts of Sophie was the idea of "refining" a notice or filecabinet identifier's definition to take represent a different set of files later in the config than what may have been the definition earlier in the config. This can mean adding files to the previous group of files, or refining them with stricter conditions, thereby resulting in a fewer number than the original definition. In the context of notices, the idea is similar an identifier can redefine it's location or generalise its pattern.

This opens the door to dynamic re-definitions of identifiers, removes noise, makes config files concise, dense, meaningful. It will later play a huge role in conditional effects/compliance checks (if ever implemented).

This scheme is now called refinements.

Proposal

Blueprint to resolve or implement.

  • Implement chaining multiple [ ] (definitions) to refine a previous definition.
filecabinet:
    net_code["pattern="net_.*\.[ch]$";][size="+1k";]
    ...
    net_code["pattern="net_.*\.sh$";]
  • Implement special empty [ ] that represents resetting or emptying the previous definition.
filecabinet:
    net_code[ ]
  • Add syntax to represent additive refinements (think OR operation), and subtractive refinements (think ADD operation).

Docs: make documentation using GitHub Pages

Background

Where do we currently stand in documentation efforts? What is the problem?

We have no documentation. Without documentation, end users won't know how to use Sophie. Contributors won't be able to contribute efficiently, either.

Proposal

Documentation fixes, recommendations, and plans

GitHub Pages

After some internal (in my head, since no one else is here right now) debating between choosing GitHub Wiki on this repository or GitHub Pages, I've decided to use GitHub Pages. The Wiki lacks customisation and that makes it hard to enjoy mantaining. I also think I'll learn more using Pages and it opens up more opportunities for people to help (workflows, etc). Probably Jekyll, less time, supported out of the box (but suggestions are welcome).

Diátaxis

We'll be following the diátaxis methodology of maintaining documentation (with a few exceptions where needed).
This gives some clear rules on how to write and how to structure the docs. It's also easy to point contributors to the source so they know what our documentation is founded upon.

SE: add unit tests

Background

Motivation for a problem or that which needs to be built.

Sophie aims to be portable and UNIX-conforming. The only sensible way to make sure this rule is never broken is to sit down and get the drudge-work, that is setting up testing, out of the way. This will also help merge pull requests easier and faster, along with improving the collaborative process of pull-requests.

Proposal

Blueprint to resolve or implement.

Unit Tests

Previous information in #4 Mock Repositories is a reading prerequisite to this section.

Within each test_dir_Vn there needs to be a single unit_test directory.

This directory that has multiple sophie_unit_n.configs that test for single filter/feature success, where n is a natural, increasing number, starting from 0.

The configs are tested one by one, using a script, sophie_unit_tester, to control both Sophie and control initialization of the directory for each test (in order to test filters like size by writing to files, and mtime by modifying files, etc).

Each unit test consists of

  • writing a directory structure to the controlling script using commands like touch, mkdir, etc.
  • specifying a file to run Sophie with, writing the output to file.
  • testing the output file for passing or failing values to determine if the unit test passed or failed.
  • outputting unit test success/failure.

Every single feature/filter of a release should be tested.

For V1, we need:

  • All filters of filecabinet tested.
  • All filters of notices tested.
  • compliance test for in preposition.
  • refinements tested.

As a guideline, if something is completely unconformant to our usage and documentation, we don't test it.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.