update links to git.abbether.

master
Craig Oates 4 years ago
parent
commit
a62743fed3
  1. 6
      CLI-Validation-Overview.md
  2. 16
      Command-Methods-Overview.md
  3. 4
      Console-and-Library-Tests-Overview.md
  4. 4
      Creating-the-Input-Loop.md
  5. 4
      DeathSocket-Home.md
  6. 4
      DeathSocketCLI-Home.md
  7. 10
      DeathSockets-Main-Files-Overview.md
  8. 6
      Home.md
  9. 2
      ScratchPad-Overview.md
  10. 12
      The-CLIs-Flow.md
  11. 18
      Using-Death-Socket-in-Your-Project.md
  12. 12
      Using-the-Console-Program.md
  13. 4
      _Sidebar.md

6
CLI-Validation-Overview.md

@ -8,12 +8,12 @@ The reason why is because C.W. does the type checking automatically. So, it seem
If you would like to know more about how C.W. performs its validation checks, please use the following links:
- [Console.Waterworks -- Coercion Type List](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Coercion-Types-List)
- [Brittle Fish Wiki -- Writing Command-Methods in F#](https://gitlab.com/craig.oates/Brittle-Fish/wikis/Writing-Command-Methods-in-F%23) (provides specific information for F# projects)
- [Console.Waterworks -- Coercion Type List](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Coercion-Types-List)
- [Brittle Fish Wiki -- Writing Command-Methods in F#](https://git.abbether.net/craig.oates/Brittle-Fish/wikis/Writing-Command-Methods-in-F%23) (provides specific information for F# projects)
Instead of copying and pasting the code from "Validation.fs" into this page, I recommend reading the actual file yourself. You can view it using the following link:
- [Validation.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Validation.fs)
- [Validation.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Validation.fs)
As you work your way through the file, try keeping the relationship between "Validation.fs" and "ConsoleCommands.fs" in mind. Everything in "Validation.fs" aids "ConsoleCommands.fs" and nothing else.

16
Command-Methods-Overview.md

@ -1,6 +1,6 @@
Without going into too much detail, a "command-method" is a function within the `ConsoleCommands` module. The name "command-method" is inaccurate here but I have used it to remain consistent with Console.Waterworks' (C.W.) terminology. If you would like to know more about command-methods, I recommend you read the following wiki entry:
- [Console.Waterworks Wiki -- Writing Command-Methods](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Writing-Command-Methods)
- [Console.Waterworks Wiki -- Writing Command-Methods](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Writing-Command-Methods)
For command-methods to work properly, there are several things they need. Which are as follows:
@ -12,7 +12,7 @@ For command-methods to work properly, there are several things they need. Which
Please note, this list is not complete. But, the extra stuff is more to do with using C.W. in a C# project so it is not relevant here. If you would like to know more about using C.W. with F# and how it differs from using it with C#, checkout the following link:
- [Brittle Fish Repository](https://gitlab.com/craig.oates/Brittle-Fish)
- [Brittle Fish Repository](https://git.abbether.net/craig.oates/Brittle-Fish)
Having got the above out of the way, here is a couple of command-method examples to help you get a feel for how they look. (Each on includes the "help" attributes.)
@ -49,8 +49,8 @@ To help explain what the above code does, please consider the following image:
It is not essential to include the help attributes but they do provide help for the end-user and future developers. For more information about the help attributes, please use the following links:
- [Console.Waterworks Wiki -- Using the "Help Attributes"](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Using-the-%22Help-Attributes%22)
- [Brittle Fish Wiki](https://gitlab.com/craig.oates/Brittle-Fish/wikis/home)
- [Console.Waterworks Wiki -- Using the "Help Attributes"](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Using-the-%22Help-Attributes%22)
- [Brittle Fish Wiki](https://git.abbether.net/craig.oates/Brittle-Fish/wikis/home)
The name of the command-method is what the end-user must enter into the console. If the command-method requires input arguments, the end-user must provide them, as well. For example, please consider the following image:
@ -58,7 +58,7 @@ The name of the command-method is what the end-user must enter into the console.
If all has gone well, you should be able to work your way through "Commands.fs" and understand it. With that said, you will come across functions which appear to have no explanation for where/why they exist. If you dig around a little bit, you will notice these functions are either situated in "Validation.fs" or the .Net Standard library (I.E. "DeathSocket"). Use the following links for more information:
- [Commands.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- [Validation.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Validation.fs)
- [GridPainter.fs (DeathSocket)](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [Console(Commands) A.P.I. (As C.L.I. section)](https://gitlab.com/craig.oates/Death-Socket/wikis/Console-API)
- [Commands.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- [Validation.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Validation.fs)
- [GridPainter.fs (DeathSocket)](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [Console(Commands) A.P.I. (As C.L.I. section)](https://git.abbether.net/craig.oates/Death-Socket/wikis/Console-API)

4
Console-and-Library-Tests-Overview.md

@ -3,8 +3,8 @@ Instead of going through both of the main testing files
overview of how they work. If you want to make your way through the
source code you can do so by using the following links:
- [ConsoleTests.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/TestCentre/ConsoleTests.fs)
- [LibraryTests.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/TestCentre/LibraryTests.fs)
- [ConsoleTests.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/TestCentre/ConsoleTests.fs)
- [LibraryTests.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/TestCentre/LibraryTests.fs)
The general structure for these files are the same. Each one has three
modules called `TestingHelpers`, `PropertyTests` and `UnitTests`. It

4
Creating-the-Input-Loop.md

@ -14,11 +14,11 @@ That snippet of code is all what is in "Program.fs". Once you know what is happe
What is happening is a new `CW_Liaison` object is created and is told to `run`. This is where C.W. creates the input-loop which runs indefinitely until the end-user closes the console (or the program crashes). The first argument passed into `run` refers to the name-space of the `ConsoleCommands` module. In this case, it is `Commands`. The second one refers to the information displayed in the console when you run it. When set to `true`, the console displays information found in "AssemblyInfo.fs". If you use `false`, the only thing you will see is the prompt. You can check the code and the name-space of the `ConsoleCommands` module via the following link:
- ["Commands.fs"](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- ["Commands.fs"](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
How C.W. creates and manages the input-loop is out of this wiki's scope. Although, you can use learn about how it via the following link:
- [Console.Waterworks Wiki](https://gitlab.com/craig.oates/Console.Waterworks/wikis/The-Flow-of-the-System)
- [Console.Waterworks Wiki](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/The-Flow-of-the-System)
Here are examples of what is displayed at run-time when you pass `true` or `false` into the `liaison.Run` command, mentioned above.

4
DeathSocket-Home.md

@ -1,7 +1,7 @@
This section focuses on the source code within the project called "DeathSocket". This is the .Net Standard 2.0 library which provides users with a way to add a grid overlay onto images. If you would like to know more about the other projects, please use the following links:
- [DeathSocket](https://gitlab.com/craig.oates/Death-Socket/wikis/DeathSocket-Home) (console project)
- [TestCentre](https://gitlab.com/craig.oates/Death-Socket/wikis/Test-Centre-Home) (testing library)
- [DeathSocket](https://git.abbether.net/craig.oates/Death-Socket/wikis/DeathSocket-Home) (console project)
- [TestCentre](https://git.abbether.net/craig.oates/Death-Socket/wikis/Test-Centre-Home) (testing library)
## Table of Contents

4
DeathSocketCLI-Home.md

@ -1,7 +1,7 @@
This section focuses on the source code within the project called "DeathSocketCLI". This is the console project which provides users with a way to uses the features in "DeathSocket" without the need to write code. If you would like to know more about the other projects, please use the following links:
- [DeathSocket](https://gitlab.com/craig.oates/Death-Socket/wikis/DeathSocket-Home) (.Net Standard 2.0 library)
- [TestCentre](https://gitlab.com/craig.oates/Death-Socket/wikis/Test-Centre-Home) (testing library)
- [DeathSocket](https://git.abbether.net/craig.oates/Death-Socket/wikis/DeathSocket-Home) (.Net Standard 2.0 library)
- [TestCentre](https://git.abbether.net/craig.oates/Death-Socket/wikis/Test-Centre-Home) (testing library)
## Table of Contents

10
DeathSockets-Main-Files-Overview.md

@ -7,7 +7,7 @@ Instead of running through every line of code in the project, I will provide a s
This is the public facing part of the library, the API. When people add this project to theirs, they will call the functions in here. Which, in turn, will call the `internal` functions within the rest of the library. End-users will use this file and the types defined in "Domain.fs" extensively.
- [GridPainter.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [GridPainter.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
## ValidationServices.fs (internal)
@ -16,7 +16,7 @@ This is the public facing part of the library, the API. When people add this pro
The functions is this file perform validation checks -- as the name implies. File extension and path checks are examples of the types of checks found in here.
- [ValidationServices.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/ValidationServices.fs)
- [ValidationServices.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/ValidationServices.fs)
## ColourServices.fs (internal)
@ -36,7 +36,7 @@ It is, also, worth pointing out the .Net Framework provides a name-space called
If you're wondering, I decided to go with `System.Drawing`, instead of `system.media`, because is works better with Windows Presentation Foundation (W.P.F.).
- [ColourServices.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/ColourServices.fs)
- [ColourServices.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/ColourServices.fs)
## ImagePrep.fs
@ -45,7 +45,7 @@ If you're wondering, I decided to go with `System.Drawing`, instead of `system.m
This file provides functions which aids the functions in "ImageServices.fs". Within this file, you will find the *SkiaSharp* functions separated from the *System.Drawing* ones via comments. The functions not grouped together via those comments work with both libraries/name-spaces.
- [ImagePrep.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/ImagePrep.fs)
- [ImagePrep.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/ImagePrep.fs)
## ImageServices.fs (internal)
@ -60,4 +60,4 @@ If you are unsure what the `use` keyword does, please you the following link for
Like "ImagePrep.fs", this file separates the *System.Drawing* and *SkiaSharp* based functions with comments.
- [ImageServices.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/ImageServices.fs)
- [ImageServices.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/ImageServices.fs)

6
Home.md

@ -20,7 +20,7 @@ Before continuing, I recommend you are familiar with the following:
- [NuGet](https://www.nuget.org)
- [xUnit](https://xunit.net/)
- [FsCheck](https://fscheck.github.io/FsCheck/)
- [Console.Waterworks](https://gitlab.com/craig.oates/Console.Waterworks)
- [Console.Waterworks](https://git.abbether.net/craig.oates/Console.Waterworks)
- [SkiaSharp](https://github.com/mono/SkiaSharp)
- [System.Drawing](https://docs.microsoft.com/en-us/dotnet/api/system.drawing.graphics?view=netframework-4.8)
@ -93,7 +93,3 @@ Before continuing, I recommend you are familiar with the following:
- [NuGet Home](NuGet-Home)
- [Add NuGet to Your Project](Add-NuGet-to-Your-Project)
- [Using Death Socket in Your Project](Using-Death-Socket-in-Your-Project)
### Extra Resources
- [Code Snippets for Common Tasks](https://gitlab.com/craig.oates/Death-Socket/snippets)

2
ScratchPad-Overview.md

@ -1,6 +1,6 @@
The reason "ScratchPad.fsx" exists is to provide a way for you to interact with the code via F# Interactive (FSI). If you are new to the project, this is a good place to start. All the code within here has comments to help signify what it is doing or which part of the library it is using. So, I will avoid going through each line of code here and provide a link to the actual file for you. If you are unsure what F# Interactive is or how to use it, I have provided a link for that, also. They are as follows:
- [ScratchPad.fsx](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/ScratchPad.fsx)
- [ScratchPad.fsx](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/ScratchPad.fsx)
- [F# Interactive (FSI)](https://docs.microsoft.com/en-us/dotnet/fsharp/tutorials/fsharp-interactive/)
- [Scripting with F#](https://fsharpforfunandprofit.com/installing-and-using/) (it's a little dated but it contains enough information to get you going)

12
The-CLIs-Flow.md

@ -14,10 +14,10 @@ That's the simple version at least.
The reason the program runs this way is because I built it on top off C.W. I will not go into too much detail about how C.W. works here because it is out of scope for this wiki. Instead, I will provide links to its repository and wiki. Which are:
- [Console.Waterworks Repository](https://gitlab.com/craig.oates/Console.Waterworks)
- [Console.Waterworks Wiki](https://gitlab.com/craig.oates/Console.Waterworks/wikis/home)
- [Console.Waterworks.Core Repository](https://gitlab.com/craig.oates/Console.Waterworks.Core) (This is the .Net Core version.)
- [Console.Waterworks.Core Wiki](https://gitlab.com/craig.oates/Console.Waterworks.Core/wikis/home) (The .Net Core version operates the same way as the traditional .Net one. So, this wiki is not as comprehensive and mostly serves as a place to set-up the .Net Core version of C.W.)
- [Console.Waterworks Repository](https://git.abbether.net/craig.oates/Console.Waterworks)
- [Console.Waterworks Wiki](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/home)
- [Console.Waterworks.Core Repository](https://git.abbether.net/craig.oates/Console.Waterworks.Core) (This is the .Net Core version.)
- [Console.Waterworks.Core Wiki](https://git.abbether.net/craig.oates/Console.Waterworks.Core/wikis/home) (The .Net Core version operates the same way as the traditional .Net one. So, this wiki is not as comprehensive and mostly serves as a place to set-up the .Net Core version of C.W.)
At a basic level, C.W. is a NuGet package which helps you write console programs. **From a distance**, C.W. programs look **a bit like** Model-View-Controller (M.V.C.) programs. To help explain, here is a diagram of C.W's basic structure/flow.
@ -37,8 +37,8 @@ I wrote C.W. with C# and without F# in mind. (I did not know any F# at the time
If you would like to know more about utilising C.W. in an F#-only context, head over to another repository of mine. Its name is Brittle Fish and it is a tutorial/reference repository for F# developers wanting to use C.W.. One of its main strengths is it points out potential pitfalls you might run into when using C.W. with F#. This is useful because C.W. makes no reservations for F#. So, knowing where and why you might need to alter your idiomatic F# code should help reduce bugs and frustration levels. The links for Brittle Fish are as follows:
- [Brittle Fish Repository](https://gitlab.com/craig.oates/Brittle-Fish)
- [Brittle Fish Wiki](https://gitlab.com/craig.oates/Brittle-Fish/wikis/home)
- [Brittle Fish Repository](https://git.abbether.net/craig.oates/Brittle-Fish)
- [Brittle Fish Wiki](https://git.abbether.net/craig.oates/Brittle-Fish/wikis/home)
End of aside.

18
Using-Death-Socket-in-Your-Project.md

@ -18,11 +18,11 @@ Brush (buildSpec imgPath numRows numColumns pWidth colour newPath)
For a more real-world example (with extra cruft), please read the `add-grid` function in "Commands.fs". This file is part of the DeathSocketCLI project and the link for it is as follows:
- [ Add-Grid example in Commands.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- [Add-Grid example in Commands.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
**Note:** Most of the "add-grid" functions will (by default) save the gridded image for you (using the save location part of the image specification). If you prefer, D.S. can create a gridded image and not save it. When that happens, it will return it as an in-memory buffer. If you are not sure on which function does what, use Visual Studio's intellisense. It will help you identify those which saves the image for you and those which return an in-memory buffer. Having said that, you are free to read the source code for these functions with the following link:
- [GridPainter.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [GridPainter.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
## A Note about the Graphics Libraries Used by Death Socket (I.E. The System's Flow)
@ -52,8 +52,8 @@ The above image shows the flow of a typical code-base using D.S. Looking at this
To help you get started, I recommend you keep the following two files open when writing your code:
- [GridPainter.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [Domain.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/Domain.fs)
- [GridPainter.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [Domain.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/Domain.fs)
### Domain Module
@ -127,11 +127,9 @@ The purpose of this function is to determine the dimensions of the image at the
Instead of repeating all the code in "Domain.fs", I recommend you take a look at the file yourself. The link for that is as follows:
- [Domain.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/Domain.fs)
- [Domain.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/Domain.fs)
I have documented the code within the file using XML comments. So, you should get intellisense overlays when you use Visual Studio or Visual Studio Code. I have, also, provided templates/examples in the "Snippets" section. Feel free to use them as starting points for creating your own specifications. The link for the snippets section is as follows:
- [Creating Domain Types Examples Snippet](https://gitlab.com/craig.oates/Death-Socket/snippets/1868660)
I have documented the code within the file using XML comments. So, you should get intellisense overlays when you use Visual Studio or Visual Studio Code.
### GridPainter Module
@ -150,7 +148,7 @@ Within `GridPainter`, you will find ten functions, which are as follows:
Instead of repeating the code from that file here, I recommend you open up "GridPainter.fs" in a separate tab. Every function has XML comments explaining what they do. So, you should have intellisense in Visual Studio and Visual Studio Code. If you read "GridPainter.fs", you will notice I have marked out areas called "SkiaSharp Functions" and "System.Drawing Functions". This should help you denote which function use which graphics library. If you are unsure which function uses which library, you can refer back to the XML comments/intellisense. As a general rule, if a function has "SK" in its name, it uses *SkiaSharp*. If it does not, it uses *System.Drawing*. The link for GridPainter.fs is as follows:
- [GridPainter.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
- [GridPainter.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocket/GridPainter.fs)
In an attempt to get you up and running, I have provided the following table. It shows what graphics library is used by each function and should help alongside the Intellisense in Visual Studio.
@ -163,4 +161,4 @@ In an attempt to get you up and running, I have provided the following table. It
To help you get a sense of how to use these functions, I have provided some examples in the "Snippets" section. To view them, use the following link:
- [GridPainter Usage Examples Snippet](https://gitlab.com/craig.oates/Death-Socket/snippets/1868663)
- [GridPainter Usage Examples Snippet](https://git.abbether.net/craig.oates/Death-Socket/snippets/1868663)

12
Using-the-Console-Program.md

@ -20,13 +20,13 @@ detail here about C.W. Having said that, you can find out more about C.W. by
using the following links:
- [Console.Waterworks
Repository](https://gitlab.com/craig.oates/Console.Waterworks)
Repository](https://git.abbether.net/craig.oates/Console.Waterworks)
- [Console.Waterworks
Wiki](https://gitlab.com/craig.oates/Console.Waterworks/wikis/home)
Wiki](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/home)
- [Console.Waterworks.Core
Repository](https://gitlab.com/craig.oates/Console.Waterworks.Core)
Repository](https://git.abbether.net/craig.oates/Console.Waterworks.Core)
- [Console.Waterworks.Core
Wiki](https://gitlab.com/craig.oates/Console.Waterworks.Core/wikis/home)
Wiki](https://git.abbether.net/craig.oates/Console.Waterworks.Core/wikis/home)
When you start the console, you will see something similar to the following
image:
@ -54,7 +54,7 @@ the console should look like the following:
If you would like to view the source code of the commands or the program's A.P.I, you can
peruse through them both using the following links:
- [Commands.fs](https://gitlab.com/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- [Commands.fs](https://git.abbether.net/craig.oates/Death-Socket/blob/master/DeathSocketCLI/Commands.fs)
- [DeathSocketCLI A.P.I.](Console-API)
If you go through the “help” section, you will notice other commands have
@ -64,7 +64,7 @@ scope of this wiki. If you would like to know more about about these
limitations, please use the following link:
- [Coerce
List](https://gitlab.com/craig.oates/Console.Waterworks/wikis/Coercion-Types-List)
List](https://git.abbether.net/craig.oates/Console.Waterworks/wikis/Coercion-Types-List)
After a while, you should start to get proficient with DeathSocketCLI. When you
do, the command names might start feeling a little clunky and long-winded. If

4
_sidebar.md → _Sidebar.md

@ -49,7 +49,3 @@
- [NuGet Home](NuGet-Home)
- [Add NuGet to Your Project](Add-NuGet-to-Your-Project)
- [Using Death Socket in Your Project](Using-Death-Socket-in-Your-Project)
### Extra Resources
- [Code Snippets for Common Tasks](https://gitlab.com/craig.oates/Death-Socket/snippets)
Loading…
Cancel
Save