ma-ilsi / sophie Goto Github PK
View Code? Open in Web Editor NEWA Sophisticated Copyright Linter
License: Apache License 2.0
A Sophisticated Copyright Linter
License: Apache License 2.0
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.
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.
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.
Blueprint to resolve or implement.
A top level test_dir
that has multiple directories corresponding to the version number, n,: test_dir_Vn
.
Each test version directory has multiple mock_repo_n
directories, where:
Within these directories we need mock repositories with a top-level sophie.config
to test Sophie on.
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.
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.
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-filter
s 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.
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
.
Blueprint to resolve or implement.
[ ]
(definitions) to refine a previous definition.filecabinet:
net_code["pattern="net_.*\.[ch]$";][size="+1k";]
...
net_code["pattern="net_.*\.sh$";]
[ ]
that represents resetting or emptying the previous definition.filecabinet:
net_code[ ]
additive refinements
(think OR operation), and subtractive refinements
(think ADD operation).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.
Documentation fixes, recommendations, and plans
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).
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.
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.
Blueprint to resolve or implement.
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.config
s 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
touch
, mkdir
, etc.Every single feature/filter of a release should be tested.
For V1, we need:
filecabinet
tested.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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.