Skip to content
This repository was archived by the owner on Jan 12, 2022. It is now read-only.
BranchesTags

Repository files navigation

CopyCurve

By ItJustWorksTM

Build dependencies

  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)

Build instructions

Checkout repository

git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve

Run build

cmake -P CMake/Scripts/DoBuild.cmake

Run testsuite

cmake -P CMake/Scripts/RunTestsuite.cmake

Git Workflow

  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>

from the latest version of master or whichever branch they wish to continue working towards.

  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.

  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.

Code Review Process

Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.

In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.

The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.

Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.

About

University project - algorithmic exercise aiming to match a human driver input commands

Resources

Readme
Apache-2.0 license

Code of conduct

Code of conduct
Activity
Custom properties

Stars

1 star

Watchers

0 watching

Forks

1 fork
Report repository

Releases

Packages

Contributors

Languages

, 'i'); if (__m === '*' || __re.test(location.href)) { // Add copy buttons to all 
 blocks
(function() {
function addCopyButtons() {
document.querySelectorAll('pre code').forEach(function(codeBlock) {
if (codeBlock.parentElement.hasAttribute('data-copy-added')) return;
codeBlock.parentElement.setAttribute('data-copy-added', 'true');
var btn = document.createElement('button');
btn.textContent = 'Copy';
btn.style.cssText = 'position:absolute;top:4px;right:4px;padding:2px 8px;font-size:11px;background:#4ecdc4;border:none;border-radius:4px;color:#1a1a2e;cursor:pointer;opacity:0.7;transition:opacity 0.2s;';
btn.onmouseover = function() { this.style.opacity = '1'; };
btn.onmouseout = function() { this.style.opacity = '0.7'; };
btn.onclick = function() {
navigator.clipboard.writeText(codeBlock.textContent).then(function() {
btn.textContent = 'Copied!';
setTimeout(function() { btn.textContent = 'Copy'; }, 1500);
});
};
codeBlock.parentElement.style.position = 'relative';
codeBlock.parentElement.appendChild(btn);
});
}
addCopyButtons();
// Re-run on dynamic content
var observer = new MutationObserver(addCopyButtons);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Add Copy Buttons to Code Blocks]', __e); }
})();
(function(){
try {
var __m = "github.com";
var __re = new RegExp('^' + "github\\.com" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Force GitHub README to respect dark mode
(function() {
var style = document.createElement('style');
style.textContent = '
.markdown-body {
color-scheme: dark light;
}
.markdown-body pre { background: #161b22 !important; }
.markdown-body code { background: rgba(110, 118, 129, 0.4) !important; }
.markdown-body table th, .markdown-body table td { border-color: #30363d !important; }
.markdown-body img { background: #0d1117; }
.markdown-body blockquote { border-left-color: #8b949e; }
.markdown-body hr { border-color: #30363d; }
';
document.head.appendChild(style);
})();
}
} catch(__e) { console.warn('[Userscript:GitHub Dark Mode README Fix]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Highlight search terms from Google/DuckDuckGo/Bing referrer
(function() {
var ref = document.referrer;
var terms = [];
if (ref.includes('google.com') || ref.includes('duckduckgo.com') || ref.includes('bing.com')) {
var url = new URL(ref);
var q = url.searchParams.get('q') || url.searchParams.get('p');
if (q) {
terms = q.split(/\s+/).filter(function(t) { return t.length > 2; });
}
}
if (terms.length === 0) return;
var style = document.createElement('style');
style.textContent = '.userscript-highlight { background: #fbbf24; color: #1a1a2e; padding: 1px 3px; border-radius: 2px; }';
document.head.appendChild(style);
function highlight(node) {
if (node.nodeType === 3) { // text node
var text = node.textContent;
var found = false;
terms.forEach(function(term) {
var regex = new RegExp('(' + term.replace(/[.*+?^${}()|[\]\\]/g, '\\') + ')', 'gi');
if (regex.test(text)) {
found = true;
var frag = document.createDocumentFragment();
var parts = text.split(regex);
parts.forEach(function(part, i) {
if (i % 2 === 0) {
frag.appendChild(document.createTextNode(part));
} else {
var span = document.createElement('span');
span.className = 'userscript-highlight';
span.textContent = part;
frag.appendChild(span);
}
});
node.parentNode.replaceChild(frag, node);
}
});
} else if (node.nodeType === 1 && node.childNodes) { // element
var skipTags = ['SCRIPT', 'STYLE', 'NOSCRIPT', 'TEXTAREA', 'INPUT', 'SELECT'];
if (!skipTags.includes(node.tagName)) {
Array.from(node.childNodes).forEach(highlight);
}
}
}
highlight(document.body);
// Re-highlight on dynamic content
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1 || node.nodeType === 3) highlight(node);
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Highlight Search Terms]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Strip utm_, fbclid, gclid, etc. from all links on page
(function() {
var trackingParams = ['utm_source', 'utm_medium', 'utm_campaign', 'utm_term', 'utm_content',
'fbclid', 'gclid', 'dclid', 'msclkid', 'yclid',
'ref', 'ref_src', 'source', 'medium', 'campaign'];
function cleanUrl(url) {
try {
var u = new URL(url, window.location.origin);
var changed = false;
trackingParams.forEach(function(p) {
if (u.searchParams.has(p)) {
u.searchParams.delete(p);
changed = true;
}
});
return changed ? u.toString() : url;
} catch (e) {
return url;
}
}
function cleanLinks() {
document.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
cleanLinks();
var observer = new MutationObserver(function(mutations) {
mutations.forEach(function(m) {
m.addedNodes.forEach(function(node) {
if (node.nodeType === 1) {
if (node.tagName === 'A') cleanLinks();
node.querySelectorAll('a[href]').forEach(function(a) {
var clean = cleanUrl(a.href);
if (clean !== a.href) a.href = clean;
});
}
});
});
});
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:Remove Tracking Parameters from Links]', __e); }
})();
(function(){
try {
var __m = "youtube.com";
var __re = new RegExp('^' + "youtube\\.com" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Auto-enable theater mode on YouTube
(function() {
function tryTheater() {
var btn = document.querySelector('button[aria-label="Theater mode"], ytd-player #player button[title="Theater mode"]');
if (btn && !btn.classList.contains('activated')) {
btn.click();
}
}
// Try immediately
tryTheater();
// Try after navigation (SPA)
var lastUrl = location.href;
setInterval(function() {
if (location.href !== lastUrl) {
lastUrl = location.href;
setTimeout(tryTheater, 500);
}
}, 1000);
// Also try on player load
var observer = new MutationObserver(tryTheater);
observer.observe(document.body, { childList: true, subtree: true });
})();
}
} catch(__e) { console.warn('[Userscript:YouTube Theater Mode Default]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Remove or un-stick sticky/fixed headers that block content
(function() {
function unstick() {
document.querySelectorAll('header, nav, [role="banner"], .header, .navbar, .sticky, .fixed-top, [style*="position: fixed"], [style*="position:sticky"]').forEach(function(el) {
if (el.style.position === 'fixed' || el.style.position === 'sticky' || getComputedStyle(el).position === 'fixed' || getComputedStyle(el).position === 'sticky') {
el.style.position = 'static';
el.style.top = 'auto';
el.style.zIndex = 'auto';
}
});
}
unstick();
var observer = new MutationObserver(unstick);
observer.observe(document.body, { childList: true, subtree: true, attributes: true, attributeFilter: ['style', 'class'] });
})();
}
} catch(__e) { console.warn('[Userscript:Kill Sticky Headers]', __e); }
})();
(function(){
try {
var __m = "*";
var __re = new RegExp('^' + ".*" + '
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages

, 'i');
if (__m === '*' || __re.test(location.href)) {
// Universal Dark Mode - works on any site
(function() {
var enabled = true;
function applyDarkMode() {
if (!enabled) return;
// Create style element if it doesn't exist
var style = document.getElementById('universal-dark-mode-style');
if (!style) {
style = document.createElement('style');
style.id = 'universal-dark-mode-style';
document.head.appendChild(style);
}
// Dark mode CSS - inverts colors but preserves images/video
style.textContent = '
/* Invert everything except media */
html {
filter: invert(1) hue-rotate(180deg) !important;
background: #1a1a2e !important;
}
/* Restore images, videos, iframes, canvas */
img, video, iframe, canvas, svg, picture, [style*="background-image"] {
filter: invert(1) hue-rotate(180deg) !important;
}
/* Preserve specific elements that should not be inverted */
.no-dark-mode, .no-dark-mode *,
[data-theme="light"], [data-theme="light"],
.ace_editor, .ace_editor *,
.CodeMirror, .CodeMirror *,
.monaco-editor, .monaco-editor *,
.markdown-body pre, .markdown-body pre *,
.highlight, .highlight *,
pre code, pre code * {
filter: none !important;
}
/* Fix common UI elements */
.modal, .popup, .dropdown-menu, .tooltip, .popover {
filter: invert(1) hue-rotate(180deg) !important;
background: #2d2d44 !important;
border-color: #444 !important;
}
/* Scrollbars */
::-webkit-scrollbar { background: #1a1a2e !important; }
::-webkit-scrollbar-thumb { background: #444 !important; }
::-webkit-scrollbar-thumb:hover { background: #555 !important; }
/* Selection */
::selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
::-moz-selection { background: #4ecdc4 !important; color: #1a1a2e !important; }
';
}
function removeDarkMode() {
var style = document.getElementById('universal-dark-mode-style');
if (style) style.remove();
}
// Toggle with Alt+Shift+D
document.addEventListener('keydown', function(e) {
if (e.altKey && e.shiftKey && e.key === 'D') {
e.preventDefault();
enabled = !enabled;
if (enabled) {
applyDarkMode();
console.log('[Universal Dark Mode] Enabled');
} else {
removeDarkMode();
console.log('[Universal Dark Mode] Disabled');
}
}
});
// Apply on load
applyDarkMode();
// Re-apply on dynamic content
var observer = new MutationObserver(function(mutations) {
if (enabled && !document.getElementById('universal-dark-mode-style')) {
applyDarkMode();
}
});
observer.observe(document.head, { childList: true });
console.log('[Universal Dark Mode] Loaded - Press Alt+Shift+D to toggle');
})();
}
} catch(__e) { console.warn('[Userscript:Universal Dark Mode]', __e); }
})();
})();
GitHub - ItJustWorksTM/CopyCurve: University project - algorithmic exercise aiming to match a human driver input commands · GitHub
Skip to content

This repository was archived by the owner on Jan 12, 2022. It is now read-only.

BranchesTags
Repository files navigation
CopyCurve
By ItJustWorksTM
Build dependencies
  • C++ compiler with support for C++11
  • CMake >= 3.17
  • Git
  • Valgrind (optional)
Build instructions
Checkout repository
git clone git@git.chalmers.se:courses/dit638/students/2021-group-09.git CopyCurve
cd CopyCurve
Run build
cmake -P CMake/Scripts/DoBuild.cmake
Run testsuite
cmake -P CMake/Scripts/RunTestsuite.cmake
Git Workflow
  1. Each team member will work on their assigned task within their own branch. Before beginning a new task, run the command:
git checkout -b <new_branch>
from the latest version of master or whichever branch they wish to continue working towards.
  1. All commit messages should follow the following format:
    [Tag] <descriptive commit message>
    
The tag helps define how the commit contributes to the project. For example, [CI], [Bug], [Feature], [Docs], [Tests], etc.
  2. After completing a feature/task/implementation, one should create a merge request for their own branch. A merge request must be approved by at least one reviewer and the CI must pass.
Code Review Process
Code review occurs mainly during merge requests and draft merge requests. At least one team member who has not committed to the merge request must review and approve the merge request in order for it to be merged. Draft merge requests are not ready to be merged, but the author would like to receive feedback on the work they have done up to that point. This is helpful for larger tasks where work is being done incrementally and regular feedback can help the author.
In the reviewing process, one must cover the correctness of the code, test coverage, functionality changes, and confirm that they follow the coding guides and best practices. The reviewer will point out obvious improvements, such as hard to understand code, unclear names, commented out code, untested code, or unhandled edge cases. The reviewer can also note maintainability observations, such as complex logic that could be simplified, improving test structure, removing duplicates, and other possible improvements.
The reviewer may ask open-ended questions and if something is unclear, they can ask for a clarification instead of a correction. Reviewers can also offer alternatives and possible workarounds that might work better for the situation without insisting those solutions are the best or only way to proceed. Code reviews can also be kind and unassuming, they applaud nice solutions and are all-round positive.
Reviewers must not merge merge requests while there are open-ended questions, even if it has been approved by another reviewer. If a comment or a question needs to be addressed by the author, there should be sufficient time given to make the changes or to resolve the comments/questions. For changes that are more urgent than others, reviewers try to make themselves available for quicker reviews.
About
University project - algorithmic exercise aiming to match a human driver input commands
Resources
Readme
Apache-2.0 license
Code of conduct
Code of conduct
Activity
Custom properties
Stars
1 star
Watchers
0 watching
Forks
1 fork
Report repository
Releases
Packages
Contributors
Languages