Merge branch 'trunk' into typos_ci

This commit is contained in:
Anton-4 2021-06-07 15:01:55 +02:00 committed by GitHub
commit 47f606d588
No known key found for this signature in database
GPG key ID: 4AEE18F83AFDEB23
3 changed files with 7 additions and 5 deletions

View file

@ -63,9 +63,9 @@ pub fn generate(filenames: Vec<PathBuf>, std_lib: StdLib, build_dir: &Path) {
// Write each package's module docs html file // Write each package's module docs html file
for (docs_by_id, interns) in package.modules.iter_mut() { for (docs_by_id, interns) in package.modules.iter_mut() {
for module in docs_by_id.values_mut() { for module in docs_by_id.values_mut() {
let module_dir = build_dir.join(module.name.as_str()); let module_dir = build_dir.join(module.name.replace(".", "/").as_str());
fs::create_dir(&module_dir) fs::create_dir_all(&module_dir)
.expect("TODO gracefully handle not being able to create the module dir"); .expect("TODO gracefully handle not being able to create the module dir");
let rendered_module = template_html let rendered_module = template_html

View file

@ -6,9 +6,9 @@
<!-- <title>TODO populate this based on the module's name, e.g. "Parser - roc/parser"</title> --> <!-- <title>TODO populate this based on the module's name, e.g. "Parser - roc/parser"</title> -->
<!-- <meta name="description" content="TODO populate this based on the module's description"> --> <!-- <meta name="description" content="TODO populate this based on the module's description"> -->
<meta name="viewport" content="width=device-width"> <meta name="viewport" content="width=device-width">
<link rel="icon" href="favicon.svg"> <link rel="icon" href="/favicon.svg">
<script type="text/javascript" src="search.js" defer></script> <script type="text/javascript" src="/search.js" defer></script>
<link rel="stylesheet" href="styles.css"> <link rel="stylesheet" href="/styles.css">
</head> </head>
<body> <body>

View file

@ -39,9 +39,11 @@ Nice collection of research on innovative editors, [link](https://futureofcoding
* [godbolt.org Compiler Explorer](https://godbolt.org/) * [godbolt.org Compiler Explorer](https://godbolt.org/)
* [whitebox debug visualization](https://vimeo.com/483795097) * [whitebox debug visualization](https://vimeo.com/483795097)
* [Hest](https://ivanish.ca/hest-time-travel/) tool for making highly interactive simulations. * [Hest](https://ivanish.ca/hest-time-travel/) tool for making highly interactive simulations.
* [replit](https://replit.com/) collaborative browser based IDE.
* Say you have a failing test that used to work, it would be very valuable to see all code that was changed that was used only by that test. * Say you have a failing test that used to work, it would be very valuable to see all code that was changed that was used only by that test.
e.g. you have a test `calculate_sum_test` that only uses the function `add`, when the test fails you should be able to see a diff showing only what changed for the function `add`. It would also be great to have a diff of [expression values](https://homepages.cwi.nl/~storm/livelit/images/bret.png) Bret Victor style. An ambitious project would be to suggest or automatically try fixes based on these diffs. e.g. you have a test `calculate_sum_test` that only uses the function `add`, when the test fails you should be able to see a diff showing only what changed for the function `add`. It would also be great to have a diff of [expression values](https://homepages.cwi.nl/~storm/livelit/images/bret.png) Bret Victor style. An ambitious project would be to suggest or automatically try fixes based on these diffs.
* I think it could be possible to create a minimal reproduction of a program / block of code / code used by a single test. So for a failing unit test I would expect it to extract imports, the platform, types and functions that are necessary to run only that unit test and put them in a standalone roc project. This would be useful for sharing bugs with library+application authors and colleagues, for profiling or debugging with all "clutter" removed. * I think it could be possible to create a minimal reproduction of a program / block of code / code used by a single test. So for a failing unit test I would expect it to extract imports, the platform, types and functions that are necessary to run only that unit test and put them in a standalone roc project. This would be useful for sharing bugs with library+application authors and colleagues, for profiling or debugging with all "clutter" removed.
* Ability to share program state at a breakpoint with someone else.
### Cool regular editors ### Cool regular editors