peterchase / conway Goto Github PK

When the board is bigger than the display "window", allow keypresses to adjust the position of the "window". If possible, use the cursor keys, otherwise something like a-d-w-x

Create a new ASP.Net Core Web project in the solution. The server-side code for this should run Conway games and the client-side code should display the board and controls like refresh rate, board size etc. To avoid horrible "polling", updates could occur via SignalR.

Currently, the initial state is always random. We would like the option to specify the initial state in a file. Two formats should be supported. The first is a "dense" format where the file contains an alive/dead value for every cell. The second is a "sparse" format where the file contains co-ordinates of all alive cells; other cells are assumed to be dead.

Currently, the cell colour represents the number of neighbours (0-8) of the cell. It would be interesting to colour them by the number of turns for which the cell has been alive (its age).

The cell age is not currently available in the Board, so you will need to think how to make it so.

Bear in mind that the cell age can be any integer from 0 upwards and there aren't an infinite number of console colours.

Consider whether the way of colouring the cells could be configurable via the command line. See #4 . For instance, you could specify --colourByAge for colouring by age and --colourByNeighbours for the current behaviour.

The easiest would be something completely stateless where the caller submits the current state of the board and gets the next state back.

A better service would connect to perhaps a database so that the current state could be retrieved from there rather than sent across each time.

Currently, board size is limited by how big of a board can be displayed. We would like to be able to use much larger boards for our simulations. In this situation, the display should show just a part of the board. The displayed part should be configurable - this may be easier to achieve after other issues related to configuration have been worked on, such as #4

The current implementation is single-threaded, so only uses one processor core. However, Conway's Game of Life algorithm is very susceptible to parallel processing, as the next states of cells only depend on the current states of cells. For instance, we could calculate rows in parallel.

Once we allow really big boards, performance will become important. This issue requests that the performance of the algorithm implementation be maximised for speed and memory use.

Depends on #56 - this creates a test project that is able to verify that Web services work correctly.

Currently, the simulation will run until interrupted by the user. But simulations often reach situations where the next state of the board is either the same as the current state, or is a state that has been seen before in the same simulation. At this point, the simulation should stop.

Detection of previously-seen states should be done in a way that is performant and memory-efficient. It will not be acceptable to store all previously-seen board states in full.

This project is set up to use .Net 5.0 because GitHub Actions (used to check each PR, compiling the code and running the tests) did not support .Net 6.0 automatically when the project was created.

This Issue suggests: -

• First of all, check whether .Net 6 is now supported
• If it isn't, how hard is it to add the necessary configuration to make it work?

If we do switch to .Net 6, consider the following: -

• Various files in the solution, such as .json and .csproj, mention net5 or net5.0. These would need to change to net6 or net6.0
• Should we make use of additional language features available in C# 10?

Currently, when S is pressed, the board state is saved to a GUID-named JSON file in the user's My Documents. This Issue asks for the user to be prompted to enter a file path.

• Console.ReadLine() is your friend here
• If the user enters blank (or whitespace) then save to GUID-named JSON file in My Documents, as it does now. Look at string.IsNullOrWhitespace().
• Check that the directory that the user has asked to save to exists - possibly give them the option to create if it doesn't. Look at Directory.Exists()
• Check whether the file that the user has asked to save exists - ask if they want to overwrite if it does. Look at File.Exists()
• Ensure that the file extension is ".json" - if they entered no extension, make it ".json". Look at Path.ChangeExtension()

For #70 , a new appsettings.json was added for the database and web service configuration. This included the database connection string, which is machine-specific. In a real production system, this could also contain private data that definitely should not go on public GitHub.

We should add a new way of configuring the database connection string and should remove this setting from appsettings.json

Note that, in real industry, we might have to go through Git an expunge all references to this private information, even in the history. So it is generally important to avoid ever committing privacy/security data like that.

As well as monitoring the arrow keys, also look for presses of the "S" key. When this is pressed, save the current board state.

Depending on when this issue gets developed, saving can be either just to file, or optionally to file or database via the Web API.

Issues to consider: -

• How do you choose the file name (or description in the database)?
• How do you make sure the board is not in the middle of being updated while you save it?

Due to the simulation height being to large to display in the console, the characters in the window jump up and down during the simulation. A possible fix may be to reduce the default height to Console.Height - 2 instead of Console.Height - 1.

Currently, the command-line options are interpreted simply by the order in which they appear. This is unclear. Also it means that one cannot choose to supply only, say, the fourth option - one would have to supply the first, second and third as well.

Instead, the command-line should accept switches in the usual format, such as --width 80 --height 25 etc.

Rather than a fixed default size, the default board size should be chosen according to the size of the console window in which the program is running.

Particularly when the board is large, the refresh frequency is slower than specified on the command line. For instance, if 200ms is specified it does not quite manage 5 refreshes per second.

This is presumably because a delay of the specified time is added after drawing the board but that drawing itself takes some time

This issues does not include doing any work to speed up the calculations or display. Just don’t wait too long at the end of each refresh

Currently, the console cursor can be seen in arbitrary positions, while the board is drawn. The console cursor should not be visible. However, it is important that the console cursor is not hidden after the program terminates.

Add an additional project to the solution. The new project should be a WPF application and should show the board graphically. It should also provide WPF controls for things like board size and speed of update. The WPF window should be a "viewport" onto the whole board, so where the board is bigger than the window, scroll bars should allow viewing different parts of the board.

Create a database that can store boards with

• Size of board (width, height)
• Some sort of name
• Alive/dead cell information

Add a serialisation facility from Board to JSON in the format implied by the already-created GameState type. For this Story, the serialisation need not be integrated into the conwayconsole application; instead, it should just have a decent set of unit-tests in conwaylibtests

Tea is a vital part of British Society. It is currently unacceptable that nothing on the subject of tea exists in this program.

We are putting the previous hashes into a HashSet, which has the capability to look up in O(1) i.e. lookup does not get slower when there are more items in the set. However, we are not using HashSet.Contains() to lookup, we are using LINQ Any() method, which will linear-scan the HashSet, which is O(N) i.e. the time for lookup is proportional to the number of items in the set.

We should make sure that we use HashSet.Contains(). But it won't work as-is, because byte arrays do not have a built-in by-value comparison. Instead, it would compare on the memory address of the byte arrays, which will definitely always be different.

Suggestion is that we create an implementation of IEqualityComparer<byte[]> and pass it to the constructor of the HashSet. If the equality comparer does equality and hash code by value, then the HashSet.Contains() will then lookup by value (quickly)

Currently, the initial state is random and different every time. It would be nice to be able to specify a random "seed" so that the same random state can be repeated. Where the random seed is not specified, a different-every-time seed should be used; this should be included as part of the display, so that interesting simulations can be repeated later.

The program class should have some more methods such as for loading, and in future, saving to the database.

Add a line of output above the board that shows the board size, window size and window position

(1000x500) (50x20) (2, 5)

This can overwrite the top-left part of the board.

When the D key is pressed, call the Web service to POST the board state to the Web service and hence save to the database.

When the --windowWidth and/or --windowHeight are not specified, they should default to the console width/height. Currently, they default to the whole board width/height, which is a bit silly when the board is large.

Careful not to set the window bigger than the board, though!

Works like the --file option, but instead takes the ID of a Board to retrieve from the database via the Web service

Run a configured number of repeated simulations, each with a different random starting state. Run each one until it repeats its state (see issue #8). Record which one runs the longest without repeating. Save the initial state of that run in a file (for the file format, see #11).

It is suggested that, when doing this, the display no longer shows every state, as this will slow down computation. Perhaps it should show every N states. Or perhaps we do not display the board at all, but just some running progress information of how many runs have been done and what is the current longest-running one.

Rather than change the existing ConwayConsole program to have this behaviour, it might be better to add a separate program to the solution.

Add a new project that will implement an ASP.Net Core Web service. It should just support some noddy fixed behaviour, nothing to do with Conway yet, just to prove it can serve up data.