profile
viewpoint
If you are wondering where the data of this site comes from, please visit https://api.github.com/users/rtfeldman/events. GitMemory does not store any data, but only uses NGINX to cache data for a period of time. The idea behind GitMemory is simply to give users a better reading experience.

puffnfresh/roy 821

Small functional language that compiles to JavaScript.

backstopmedia/bleeding-edge-sample-app 678

A sample app for a Bleeding Edge Press book.

elm-community/elm-webpack-loader 534

Webpack loader for the Elm programming language.

elm-community/elm-test 353

moved to elm-explorations/test

elm/browser 292

Create Elm programs that run in browsers!

elm-explorations/test 204

Write unit and fuzz tests for Elm code.

evancz/react-angular-ember-elm-performance-comparison 90

Comparing performance of Elm, React, Angular, and Ember

eeue56/elm-html-test 67

Test elm-html in Elm!

jessitron/elm-sydron 53

a first elm app. Hits the github API for events for a hard-coded repository.

elm-community/maybe-extra 44

Convenience functions for working with Maybe.

push eventrtfeldman/dotfiles

Richard Feldman

commit sha 4a40c542348d781b39bd8fca782d8e84e56f3cfa

Use git autosetupmerge = true

view details

push time in a day

push eventrtfeldman/rbt

Brian Hicks

commit sha 31b1373ab3601053abd36694a5da2ddaa64b0257

add the dynamic dependencies ADR

view details

Brian Hicks

commit sha 97f85e4b42a5f33fdb6d1556d7ba5f8eb3550192

separate problems and solutions

view details

Brian Hicks

commit sha ce3c62c79dc4f816bda8f4040d973231cd2b1b78

fix markdown table rendering

view details

Richard Feldman

commit sha 28a56b9c92c1979eb6423467c1e7d317520e1e4c

Merge pull request #18 from BrianHicks/dynamic-deps add the dynamic dependencies ADR

view details

push time in 3 days

PR merged rtfeldman/rbt

add the dynamic dependencies ADR
+170 -0

0 comment

1 changed file

BrianHicks

pr closed time in 3 days

PullRequestReviewEvent
PullRequestReviewEvent

Pull request review commentrtfeldman/rbt

add the dynamic dependencies ADR

+# ADR 005: Dynamic Dependencies++## Decision++For now, rbt will allow both static (read: known at compile time) and dynamic (read: discovered at runtime) dependencies.++Static dependencies will be a list of strings (or equivalent.)++Dynamic dependencies will be discovered via Roc scripts running on a custom platform that limits I/O.+(Read on for more details.)++## How We Got Here++The big question here: should rbt require that the files in the build graph be completely specified ahead of time, or should we allow dependencies to be generated dynamically?+This is at odds with a goal of having quick builds, since any level of dynamic dependencies requires having a dependency discovery process, and that eats up time before we can actually start running build commands.+That said, it turns out that dynamic dependencies are at least often useful, and apparently sometimes absolutely essential (e.g. building Fortran?)++I know of four ways to slice this:++1. Discover dependencies while walking the build graph (like Shake and Redo)+   These implementations tend to have the build API which can declare additional dependencies and run commands in the same job.++2. Pause for discovery while building (like Make and Ninja)+   The process here looks like: when you get to a dynamic dependency, run a script and then pretend like you had that knowledge all along.+   On the next run, examine the dependencies of the dependency script to decide whether or not to re-run it.+   (Make does some magical/hard-to-explain things here!)++3. Discover dependencies and build in separate phases.+   I couldn't find any existing systems that do this!++4. Don't allow dynamic dependencies (Buck, Bazel, and kinda Nix and Meson.)+   These implementations have long lists of dependency files.+   Sometimes they allow globs or directories as inputs, sometimes they don't.++Ok, so let's try rule some of these out:++- We already decided (outside of ADRs) to avoid #1 because doing that means we give up having a statically-inspectable build graph.+- We can rule out #2 for the same reason, although we may want to borrow the caching mechanism!+- We'd prefer to avoid #4, purely for ease of use: it can be annoying to have to specify an import in both your source code and build system.++That means we're left with #3, but nobody chooses that for some reason.+So let's try and discover why that is.+If there's a reason to avoid it, let's avoid it, but otherwise it seems promising!

I really like this framing! 😃

BrianHicks

comment created time in 3 days

Pull request review commentrtfeldman/rbt

add some ADRs with the start of a Roc API for RBT

+# ADR 005: What's a Job?++We want to be able to specify builds in Roc (I mean, it's right there in the name!)++To do that, we need to have a good idea about the kinds of data we're working with and how they relate to one another.++## Jobs++A **job** defines the basic unit of work in an rbt build.+It specifies the set of inputs that trigger a rebuild and, in most cases, produces new outputs.++### Commands++Commands are the only truly required part of a job.+Without them, nothing else makes sense!+A simple job might look like this:++```roc+hello : Job+hello =+    job { command: exec echo [ "Hello, World!" ] }+```++The first argument `echo` here is a `Tool` (see below for how to define those.)+The second argument is an array of arguments which will be passed to the tool when it executes.++Of course, since Roc is a full programming language, you can define your own helpers easily:++```roc+execShellScript : String -> Command+execShellScript = \script ->+    exec sh [ "-c", script ]+```++(n.b. I'll be using the `execShellScript` helper throughout this document to make the examples a little bit more focused!)++- [ ] TBD whether it makes sense for rbt to export a small standard library including things like `sh` or `bash`.+      As of this writing, I'm learning "no".++- [ ] Is "exec" or "run" a better name?++### Environment++Of course, commands often need environment variables to work properly, so you can specify those:++```roc+hello : Job+hello =+  job+      {+          command: execShellScript "echo $GREETING",+          environment: {:+            "GREETING" => "Hello, World!",+          :},+      }+```++### Inputs++Jobs must specify their complete set of inputs, and a job will be rebuilt any time any of its inputs change.+Jobs will not be able to see any files outside the inputs they specify (see [ADR #1](./001-job-isolation-targets.md).)++There are two types of inputs:++- Files from the filesystem (*only* files, not globs or directories.+  However, a future ADR will describe a way to automatically discover files.)+- The outputs of other jobs.++You might specify a job with file inputs like this:++```roc+app : Job+app =+    job+        {+           command: exec elm [ "make", "--output=app.js", "src/Main.elm" ],+           inputFiles: [ "elm.json", "src/Main.elm" ],+           outputFiles: [ "app.js" ],+        }+```++And one which builds on another job like this:++```+uglifiedApp : Job+uglifiedApp =+    job+        {+            tools: [ uglifyjs ],+            command: execShellScript "uglifyjs app.js --compress | uglifyjs --mangle --output app.min.js",+            inputJobs: [ app ],+            outputFiles: [ "app.min.js" ],+        }+```++- [ ] I'm not happy with `inputFiles` vs `inputJobs`, but I'm similarly unhappy with calling them `roots` vs `inputs` or something similar!+      Needs more thought.++Note: caches (described in [ADR #6](./006-caches.md)) are also *technically* inputs, but we expect that an empty cache will not cause a build to fail and a cache changing will not trigger a rebuild.++### Outputs++Only outputs that jobs explicitly specify will be visible after the job is finished.+Unlike inputs, outputs can be directories as well as single files.++You might specify a job with an output like this:++```roc+hello : Job+hello =+    job+        {+            command: execShellScript "echo Hello World > hello",+            outputs: [ "hello" ],+        }+```++Some commands (linters, tests) don't output anything.+That's totally fine—there just won't be any outputs available for other jobs to depend on.++#### Output Caching++rbt will keep track of job output in an internal way, but will expose a way for a programmer to see the outputs (think `rbt outputs jobname` or similar)++#### Output Persistence++Builds sometimes need to put files back into source directories.+(For example, a job could generate an API client, the files of which would be necessary for editor tooling to provide autocompletion or typechecking.)+So, in addition to specifying outputs, jobs will be able to specify where their outputs will be persisted.++You might use persistence like this:++```roc+hello : Job+hello =+    job+        {+            tools: [ openapiGenerator ]+            command: exec "openapi-generator-cli" [ "generate", "-i", "spec.json", "-o", "api-client", "-t", "elm" ],+            outputs: [ "api-client" ],+            persistAt: [ "/src/api-client" ],+        }+```++### Tools++A tool is just a binary that rbt knows about.+We add specified toosl to the `PATH` of the build environment so jobs can use them.
We add specified tools to the `PATH` of the build environment so jobs can use them.
BrianHicks

comment created time in 7 days

Pull request review commentrtfeldman/rbt

add some ADRs with the start of a Roc API for RBT

+# ADR 005: What's a Job?++We want to be able to specify builds in Roc (I mean, it's right there in the name!)++To do that, we need to have a good idea about the kinds of data we're working with and how they relate to one another.++## Jobs++A **job** defines the basic unit of work in an rbt build.+It specifies the set of inputs that trigger a rebuild and, in most cases, produces new outputs.++### Commands++Commands are the only truly required part of a job.+Without them, nothing else makes sense!+A simple job might look like this:++```roc+hello : Job+hello =+    job { command: exec echo [ "Hello, World!" ] }+```++The first argument `echo` here is a `Tool` (see below for how to define those.)+The second argument is an array of arguments which will be passed to the tool when it executes.++Of course, since Roc is a full programming language, you can define your own helpers easily:++```roc+execShellScript : String -> Command+execShellScript = \script ->+    exec sh [ "-c", script ]+```++(n.b. I'll be using the `execShellScript` helper throughout this document to make the examples a little bit more focused!)++- [ ] TBD whether it makes sense for rbt to export a small standard library including things like `sh` or `bash`.+      As of this writing, I'm learning "no".++- [ ] Is "exec" or "run" a better name?++### Environment++Of course, commands often need environment variables to work properly, so you can specify those:++```roc+hello : Job+hello =+  job+      {+          command: execShellScript "echo $GREETING",+          environment: {:+            "GREETING" => "Hello, World!",+          :},+      }+```++### Inputs++Jobs must specify their complete set of inputs, and a job will be rebuilt any time any of its inputs change.+Jobs will not be able to see any files outside the inputs they specify (see [ADR #1](./001-job-isolation-targets.md).)++There are two types of inputs:++- Files from the filesystem (*only* files, not globs or directories.+  However, a future ADR will describe a way to automatically discover files.)+- The outputs of other jobs.++You might specify a job with file inputs like this:++```roc+app : Job+app =+    job+        {+           command: exec elm [ "make", "--output=app.js", "src/Main.elm" ],+           inputFiles: [ "elm.json", "src/Main.elm" ],+           outputFiles: [ "app.js" ],+        }+```++And one which builds on another job like this:++```+uglifiedApp : Job+uglifiedApp =+    job+        {+            tools: [ uglifyjs ],+            command: execShellScript "uglifyjs app.js --compress | uglifyjs --mangle --output app.min.js",+            inputJobs: [ app ],+            outputFiles: [ "app.min.js" ],+        }+```++- [ ] I'm not happy with `inputFiles` vs `inputJobs`, but I'm similarly unhappy with calling them `roots` vs `inputs` or something similar!+      Needs more thought.++Note: caches (described in [ADR #6](./006-caches.md)) are also *technically* inputs, but we expect that an empty cache will not cause a build to fail and a cache changing will not trigger a rebuild.++### Outputs++Only outputs that jobs explicitly specify will be visible after the job is finished.+Unlike inputs, outputs can be directories as well as single files.++You might specify a job with an output like this:++```roc+hello : Job+hello =+    job+        {+            command: execShellScript "echo Hello World > hello",+            outputs: [ "hello" ],+        }+```++Some commands (linters, tests) don't output anything.+That's totally fine—there just won't be any outputs available for other jobs to depend on.++#### Output Caching++rbt will keep track of job output in an internal way, but will expose a way for a programmer to see the outputs (think `rbt outputs jobname` or similar)++#### Output Persistence++Builds sometimes need to put files back into source directories.+(For example, a job could generate an API client, the files of which would be necessary for editor tooling to provide autocompletion or typechecking.)+So, in addition to specifying outputs, jobs will be able to specify where their outputs will be persisted.++You might use persistence like this:++```roc+hello : Job+hello =+    job+        {+            tools: [ openapiGenerator ]+            command: exec "openapi-generator-cli" [ "generate", "-i", "spec.json", "-o", "api-client", "-t", "elm" ],+            outputs: [ "api-client" ],+            persistAt: [ "/src/api-client" ],+        }+```++### Tools++A tool is just a binary that rbt knows about.+We add specified toosl to the `PATH` of the build environment so jobs can use them.++There are a couple of ways to source tools.+The simplest is to assume the tool already exists on the system:++```roc+gunzip : Tool+gunzip = systemTool "gunzip"+```++This would search through the host system's `PATH` to find a `gunzip` binary.++You can also use tools to source other tools:++```roc+nixShell : Tool+nixShell = systemTool "nix-shell"+++curlBinary : Job+curlBinary =+  job+      {+          tools: [ nixShell ],+          command: exec "nix-shell" [ "-p", "curl", "--run", "ln -s $(which curl) curl" ],+          outputs: [ "curl" ],+      }+++curl : Tool+curl = +  tool curlBinary "curl"+```++(Note that we may want to eventually make an easier way to source tools from large package ecosystems like Nix or Homebrew, but for now we can use jobs to do whatever we want!)++And, of course, we can also source tools from the internet:++```roc+elm : Tool+elm =+  job+      {+          tools: [ curl, gunzip ],+          command: execShellScript "curl -L https://github.com/elm/compiler/releases/download/0.19.1/\(filename) | gunzip > elm && chmod +x elm",+          outputs: [ "elm" ],+      }+      |> tool "elm"+```++(Note that eventually we should have built-in way to download things that does checksumming and more caching.+That's for a future ADR!)

Love it! 💯

BrianHicks

comment created time in 7 days

Pull request review commentrtfeldman/rbt

add some ADRs with the start of a Roc API for RBT

+# ADR 005: What's a Job?++We want to be able to specify builds in Roc (I mean, it's right there in the name!)++To do that, we need to have a good idea about the kinds of data we're working with and how they relate to one another.++## Jobs++A **job** defines the basic unit of work in an rbt build.+It specifies the set of inputs that trigger a rebuild and, in most cases, produces new outputs.++### Commands++Commands are the only truly required part of a job.+Without them, nothing else makes sense!+A simple job might look like this:++```roc+hello : Job+hello =+    job { command: exec echo [ "Hello, World!" ] }+```++The first argument `echo` here is a `Tool` (see below for how to define those.)+The second argument is an array of arguments which will be passed to the tool when it executes.++Of course, since Roc is a full programming language, you can define your own helpers easily:++```roc+execShellScript : String -> Command+execShellScript = \script ->+    exec sh [ "-c", script ]+```++(n.b. I'll be using the `execShellScript` helper throughout this document to make the examples a little bit more focused!)++- [ ] TBD whether it makes sense for rbt to export a small standard library including things like `sh` or `bash`.+      As of this writing, I'm learning "no".++- [ ] Is "exec" or "run" a better name?

I like exec - it suggests we're actually running a separate process!

BrianHicks

comment created time in 13 days

Pull request review commentrtfeldman/rbt

add some ADRs with the start of a Roc API for RBT

+# ADR 005: What's a Job?++We want to be able to specify builds in Roc (I mean, it's right there in the name!)++To do that, we need to have a good idea about the kinds of data we're working with and how they relate to one another.++## Jobs++A **job** defines the basic unit of work in an rbt build.+It specifies the set of inputs that trigger a rebuild and, in most cases, produces new outputs.++### Commands++Commands are the only truly required part of a job.+Without them, nothing else makes sense!+A simple job might look like this:++```roc+hello : Job+hello =+    job { command: exec echo [ "Hello, World!" ] }+```++The first argument `echo` here is a `Tool` (see below for how to define those.)+The second argument is an array of arguments which will be passed to the tool when it executes.++Of course, since Roc is a full programming language, you can define your own helpers easily:++```roc+execShellScript : String -> Command+execShellScript = \script ->+    exec sh [ "-c", script ]+```++(n.b. I'll be using the `execShellScript` helper throughout this document to make the examples a little bit more focused!)++- [ ] TBD whether it makes sense for rbt to export a small standard library including things like `sh` or `bash`.+      As of this writing, I'm learning "no".++- [ ] Is "exec" or "run" a better name?++### Environment++Of course, commands often need environment variables to work properly, so you can specify those:++```roc+hello : Job+hello =+  job+      {+          command: execShellScript "echo $GREETING",+          environment: {:+            "GREETING" => "Hello, World!",+          :},+      }+```++### Inputs++Jobs must specify their complete set of inputs, and a job will be rebuilt any time any of its inputs change.+Jobs will not be able to see any files outside the inputs they specify (see [ADR #1](./001-job-isolation-targets.md).)++There are two types of inputs:++- Files from the filesystem (*only* files, not globs or directories.+  However, a future ADR will describe a way to automatically discover files.)+- The outputs of other jobs.++You might specify a job with file inputs like this:++```roc+app : Job+app =+    job+        {+           command: exec elm [ "make", "--output=app.js", "src/Main.elm" ],+           inputFiles: [ "elm.json", "src/Main.elm" ],+           outputFiles: [ "app.js" ],+        }+```++And one which builds on another job like this:++```+uglifiedApp : Job+uglifiedApp =+    job+        {+            tools: [ uglifyjs ],+            command: execShellScript "uglifyjs app.js --compress | uglifyjs --mangle --output app.min.js",+            inputJobs: [ app ],+            outputFiles: [ "app.min.js" ],+        }+```++- [ ] I'm not happy with `inputFiles` vs `inputJobs`, but I'm similarly unhappy with calling them `roots` vs `inputs` or something similar!+      Needs more thought.++Note: caches (described in [ADR #6](./006-caches.md)) are also *technically* inputs, but we expect that an empty cache will not cause a build to fail and a cache changing will not trigger a rebuild.++### Outputs++Only outputs that jobs explicitly specify will be visible after the job is finished.+Unlike inputs, outputs can be directories as well as single files.++You might specify a job with an output like this:++```roc+hello : Job+hello =+    job+        {+            command: execShellScript "echo Hello World > hello",+            outputs: [ "hello" ],+        }+```++Some commands (linters, tests) don't output anything.+That's totally fine—there just won't be any outputs available for other jobs to depend on.++#### Output Caching++rbt will keep track of job output in an internal way, but will expose a way for a programmer to see the outputs (think `rbt outputs jobname` or similar)++#### Output Persistence++Builds sometimes need to put files back into source directories.+(For example, a job could generate an API client, the files of which would be necessary for editor tooling to provide autocompletion or typechecking.)+So, in addition to specifying outputs, jobs will be able to specify where their outputs will be persisted.++You might use persistence like this:++```roc+hello : Job+hello =+    job+        {+            tools: [ openapiGenerator ]+            command: exec "openapi-generator-cli" [ "generate", "-i", "spec.json", "-o", "api-client", "-t", "elm" ],+            outputs: [ "api-client" ],+            persistAt: [ "/src/api-client" ],+        }+```++### Tools++A tool is just a binary that rbt knows about.+We add specified toosl to the `PATH` of the build environment so jobs can use them.++There are a couple of ways to source tools.+The simplest is to assume the tool already exists on the system:++```roc+gunzip : Tool+gunzip = systemTool "gunzip"+```++This would search through the host system's `PATH` to find a `gunzip` binary.++You can also use tools to source other tools:++```roc+nixShell : Tool+nixShell = systemTool "nix-shell"+++curlBinary : Job+curlBinary =+  job+      {+          tools: [ nixShell ],+          command: exec "nix-shell" [ "-p", "curl", "--run", "ln -s $(which curl) curl" ],+          outputs: [ "curl" ],+      }+++curl : Tool+curl = +  tool curlBinary "curl"+```++(Note that we may want to eventually make an easier way to source tools from large package ecosystems like Nix or Homebrew, but for now we can use jobs to do whatever we want!)++And, of course, we can also source tools from the internet:++```roc+elm : Tool+elm =+  job+      {+          tools: [ curl, gunzip ],+          command: execShellScript "curl -L https://github.com/elm/compiler/releases/download/0.19.1/\(filename) | gunzip > elm && chmod +x elm",+          outputs: [ "elm" ],+      }+      |> tool "elm"+```++(Note that eventually we should have built-in way to download things that does checksumming and more caching.+That's for a future ADR!)++Finally, we provide a way to wrap binaries in the environment they need so they can be used in jobs without any further wrapping:++```roc+npm : Tool+npm = systemTool "npm" +++node : Tool+node = systemTool "node"+++nodeModules : Job+nodeModules =+    job+        {+            command: exec npm [ "install" ],+            inputs: [ "package.json", "package-lock.json" ],+            outputs: [ "node_modules" ],+        }+++uglifyjs : Tool+uglifyjs+    customTool+        {+            path: "\(nodeModules.outputs)/node_modules/.bin/uglifyjs",+            tools: [ node ],+            environment: {:+                "NODE_PATH" => "\(nodeModules.outputs)/node_modules"+            :}+        }+```++- [ ] Surely there is a better way to do this.+      Needs more thought.++### CPU Hinting++rbt uses job parameters to jobs to construct a build graph, which it will then walk in parallel wherever possible.+This means that we can do a better job scheduling tasks when the tasks themselves are smaller—think compressing a single image instead of a whole directory of them.++However, many compilers (like Zig, Rust/Cargo, Elm, Haskell, and Roc itself) have a monolithic compilation process where they take an entrypoint and manage compiling all the dependencies themselves.+This is great both for programmers and compiler authors: it unlocks optimization opportunities and in many cases does away with the need for a separate build tool.++Unfortunately, it's harder for a generic build tool like rbt to deal with those kinds of processes in a build step.+The big question here: should we schedule work on other cores while the big process is running?+We don't want to cause the CPU to do too much context switching!++To fix this, jobs can give rbt enough information to do the right thing by specifying **CPU Hints**.+A job can either say it takes a single core or that it will saturate all available cores.++A future ADR (or just the implementation) will determine how we deal with CPU hints, but one possibility is to avoid starting new work when there's a saturating job running.+Another would be to use some concept of CPU reservation to avoid starting a saturating job before it held the lock on all cores (of course, we'd have to be careful to avoid creating deadlocks here!)++Anyway, here's how you might use this:++```roc+binary : Job+binary =+    job+        {+            tools: [ cargo ],+            command: exec "cargo" [ "build", "--release" ],+            outputs: [ "target/release/binary-name" ],+            cpuHint: SaturatesCpus,+        }+```++### Fixers++Code formatters and some linters can automatically fix problems in source code.+Jobs can specify a flag to make this explicitly OK.+It might look like this:++```roc+elmFormat : Job+elmFormat =+    job+        {+            tools: [ elmFormat ],+            command: exec "elm-format" [ "--yes" ],+            inputs: [ "src/Main.elm", "src/OtherModule.elm" ],+            modifiesInputs: True,

🤔 I wonder if Bool might not be granular enough for modifiesInputs - e.g. for something like eslint, there's an input of the eslint config, which should not be modified, along with the source files...

one idea: modifiesInputs could take a tag union of the type [ All, AllExcept (List Str), None ]

BrianHicks

comment created time in 7 days

Pull request review commentrtfeldman/rbt

add some ADRs with the start of a Roc API for RBT

+# ADR 005: What's a Job?++We want to be able to specify builds in Roc (I mean, it's right there in the name!)++To do that, we need to have a good idea about the kinds of data we're working with and how they relate to one another.++## Jobs++A **job** defines the basic unit of work in an rbt build.+It specifies the set of inputs that trigger a rebuild and, in most cases, produces new outputs.++### Commands++Commands are the only truly required part of a job.+Without them, nothing else makes sense!+A simple job might look like this:++```roc+hello : Job+hello =+    job { command: exec echo [ "Hello, World!" ] }+```++The first argument `echo` here is a `Tool` (see below for how to define those.)+The second argument is an array of arguments which will be passed to the tool when it executes.++Of course, since Roc is a full programming language, you can define your own helpers easily:++```roc+execShellScript : String -> Command+execShellScript = \script ->+    exec sh [ "-c", script ]+```++(n.b. I'll be using the `execShellScript` helper throughout this document to make the examples a little bit more focused!)++- [ ] TBD whether it makes sense for rbt to export a small standard library including things like `sh` or `bash`.+      As of this writing, I'm learning "no".++- [ ] Is "exec" or "run" a better name?++### Environment++Of course, commands often need environment variables to work properly, so you can specify those:++```roc+hello : Job+hello =+  job+      {+          command: execShellScript "echo $GREETING",+          environment: {:+            "GREETING" => "Hello, World!",+          :},+      }+```++### Inputs++Jobs must specify their complete set of inputs, and a job will be rebuilt any time any of its inputs change.+Jobs will not be able to see any files outside the inputs they specify (see [ADR #1](./001-job-isolation-targets.md).)++There are two types of inputs:++- Files from the filesystem (*only* files, not globs or directories.+  However, a future ADR will describe a way to automatically discover files.)+- The outputs of other jobs.++You might specify a job with file inputs like this:++```roc+app : Job+app =+    job+        {+           command: exec elm [ "make", "--output=app.js", "src/Main.elm" ],+           inputFiles: [ "elm.json", "src/Main.elm" ],+           outputFiles: [ "app.js" ],+        }+```++And one which builds on another job like this:

Might be worth noting that the reason inputJobs is benefitical compared to something like this...

inputFiles: List.append [ "elm.json", "src/Main.elm" ] (Job.inputFiles app)

...is that it lets us show in a dependency visualization that this job actually depends on the other job!

BrianHicks

comment created time in 7 days

PullRequestReviewEvent
PullRequestReviewEvent

startedAccessKit/accesskit

started time in 23 days

issue commentrtfeldman/elm-css

Empty style node emitted if no styles

Happy to accept a PR for this! 👍

arsduo

comment created time in a month

push eventrtfeldman/fptransforms

Richard Feldman

commit sha 0b4ca631972feb232b39f296ef0105cbed6e3fe1

Roc syntax uses `,` instead of `|` Can't believe I missed this one! 😆

view details

push time in a month

pull request commentsupermario/fptransforms

Fill in Roc syntax

The gray comment hack looks great! 💯

This looks ready to me!

rtfeldman

comment created time in a month

push eventrtfeldman/fptransforms

Richard Feldman

commit sha 18bc1d724b04048a3af9371b29d6c470aee6e8ad

Fix 4-space indentation

view details

push time in a month

pull request commentsupermario/fptransforms

Fill in Roc syntax

I noticed you adjusted the highlighter to coffeescript in some blocks – would it be better to have all roc syntax evaluated as coffeescript for the moment?

The main reason for that one is that CoffeeScript uses # for comments, and things can get pretty weird if the syntax highlighter thinks something inside a comment is a non-comment - so I used CoffeeScript on all the ones that have comments. (I've also tried Elixir - sometimes that looks okay.) For the others I tried to stick to Elm highlighting since it gets the most right aside from the comments. 😄

rtfeldman

comment created time in a month

pull request commentsupermario/fptransforms

Fill in Roc syntax

@supermario ok I think this is finally ready for review! 😅

rtfeldman

comment created time in a month

push eventrtfeldman/fptransforms

Richard Feldman

commit sha 02d50a42318e3399d1f50fdf09f7c9b59eddca1a

Remove more horizontal scrollbars

view details

Richard Feldman

commit sha 19f08f775dd38b42077fa1f338889466d67b3f69

Try some different syntax highlighting

view details

Richard Feldman

commit sha f60dce70d03261c37fa66925c86986644d2025c5

4-space indentation

view details

push time in a month

push eventrtfeldman/fptransforms

Richard Feldman

commit sha fe57c46568261f71fa8435a732739b2bad35cf80

Fix Roc comment

view details

Richard Feldman

commit sha 6f67d249bb0dfdddbec25da4c5a56bebb02629e7

Remove some horizontal scrollbars

view details

Richard Feldman

commit sha 6dcc319c821539436c2269bfe8374be1c0104a03

Use more helpful syntax highlighting for Roc

view details

push time in a month

Pull request review commentsupermario/fptransforms

Fill in Roc syntax

 <h2>Modules</h2> import Maybe ( Maybe(..) )    -- Maybe, Just, Nothing  </code></pre> -<pre><code class="roc haskell">-TBC+<pre><code class="roc coffeescript">+interface MyModule+    exposes [ foo, blah ] # Roc does not have "expose everything" syntax+    imports+        [+            # Qualified imports+            List as L, # L.map, L.walk+            +            # Open imports (Roc does not have "expose everything" syntax)+            List.{ map, walk }+            +            # Imports the Result module and also the Result type+            Result.{ Result }

Yes - thanks!

rtfeldman

comment created time in a month

PullRequestReviewEvent

Pull request review commentsupermario/fptransforms

Fill in Roc syntax

 <h2>String interpolation</h2>   |]  </code></pre> -<pre><code class="roc haskell">-costOnSale money =+<pre><code class="roc coffeescript">+costOnSale = \money ->   euros = toEuros money+     "It cost \(euros) when on sale."

That's correct - string interpolation has to be just a variable name.

Could add a comment, although the let section already explains this. 🤷

rtfeldman

comment created time in a month

PullRequestReviewEvent

Pull request review commentsupermario/fptransforms

Fill in Roc syntax

 <h2>Type Annotations</h2>   sqrt (x^2 + y^2)  </code></pre> -<pre><code class="roc haskell">-answer : Int+<pre><code class="roc coffeescript">+answer : I32 answer =-  42+    42 -factorial : Int, Int+factorial : I32 -> I32 factorial = \n ->-  List.product (List.range 1 n)+    List.product (List.range 1 n) ----distance : { x : Float, y : Float }, Float-distance = \{x,y} ->-  sqrt (x^2 + y^2)+distance : { x : F64, y : F64 } -> F64+distance = \{ x, y} ->+    Num.sqrt (x ^ 2 + y ^ 2)

Oops, the I32, I32 is wrong - return type should always have a -> before it, and multiple args should always be separated by ,

Fixed in 4a6bb453f645c74f98981147cb0200b0af946723

rtfeldman

comment created time in a month

PullRequestReviewEvent

push eventrtfeldman/fptransforms

Richard Feldman

commit sha 4a6bb453f645c74f98981147cb0200b0af946723

Fix Roc function signature

view details

push time in a month

PullRequestReviewEvent