Minor race condition in line order of compiler error output

[aramiscd]

I'm using Gren 0.6.3.

I have some code here that outputs the following error message:

Compiling (3)-- TYPE MISMATCH ---------------------------------------------- src/App/Cmd.gren

Something is off with the body of the `printLine` definition:

20|     Stream.write toStream
        ^^^^^^^^^^^^^^^^^^^^^
This `write` call produces:

    Stream.Writable (Stream.Writable Bytes)
    -> Task.Task Stream.Error (Stream.Writable (Stream.Writable Bytes))

But the type annotation on `printLine` says it should be:

    Cmd Msg

Detected problems in 1 module.

But when I repeatedly attempt the compilation, the message sometimes looks like this:

Compiling (3)-- TYPE MISMATCH ---------------------------------------------- src/App/Cmd.gren

Something is off with the body of the `printLine` definition:

20|     Stream.write toStream
        ^^^^^^^^^^^^^^^^^^^^^
This `write` call produces:

    Stream.Writable (Stream.Writable Bytes)
    -> Task.Task Stream.Error (Stream.Writable (Stream.Writable Bytes))

Detected problems in 1 module.
 the type annotation on `printLine` says it should be:

    Cmd Msg

The "Detected problems ..." line is out of place. No big deal, but I thought I'd mention it.

[gilramir]

One observation:
The "Detected problem" line is the only line printed to stdout.
All the other lines get printed to stderr.

@aramiscd - when this happens, are you typing the "green make" command on the command-line (or via some script which is invoked from the command line), or is there anything in-between your UI and "gren make" which might be capturing stdout/stderr and displaying it to you (like, an editor extension which runs the command for you, and then displays the output).

[gilramir]

Never mind my question about how you run gren. I think the problem is in the gren compiler front end; it is reading stdout and stderr from the Haskell backend part of the compiler, and copying stdout and stderr from the backend to the the frontend's stdout and stderr, in a Cmd.batch array.

From src/Main.gren:

257             CompilerInitialized { backendStreams, encodedCommand, headless } ->
258                 Cmd.batch
259                     [ if headless then
260                         Stream.write encodedCommand backendStreams.input
261                             |> Task.map (\_ -> {})
262                             |> Task.onError
263                                 (\e ->
264                                     Stream.Log.line model.stderr (Stream.errorToString e)
265                                         |> Task.andThen (\_ -> Node.exitWithCode 1)
266                                 )
267                             |> Task.execute
268                       else
269                         Stream.write encodedCommand backendStreams.input
270                             |> Task.map (\_ -> { source = model.stdin, target = backendStreams.input })
271                             |> Task.attempt RedirectTerminalIO
272                     , if headless then
273                         Cmd.none
274                       else
275                         Task.succeed { source = backendStreams.output, target = model.stdout }
276                             |> Task.attempt RedirectTerminalIO
277                     , Task.succeed { source = backendStreams.error, target = model.stderr }
278                         |> Task.attempt RedirectTerminalIO
279                     ]

The 2 Task.suceed |> Task.attempt RedirectTerminalIO's at the end (for stdout and stderr) are handled simultaneously by the node runtime. I assume that they are indeed running at the same time, and maybe the stderr redirection is interleaving with the stdout redirection.

I don't think there's much that can be done here as long as the frontend is consuming 2 streams from the backend like this.

However, if the frontend is merely redirecting the backend's stdout/stderr, why does the frontend need to be involved at all. If we let the backend process inherit the same stdout/stderr that the frontend has, then the frontend doesn't need to act as a middle-man, reading and re-writing the data. Then the user should see exactly what the backend wrote.

[robinheghan]

However, if the frontend is merely redirecting the backend's stdout/stderr, why does the frontend need to be involved at all.

This code is common for all invocations of the backend, and in the case where the user is running gren repl, we also have to handle input from the user.

This problem will go away in time, as the long-term goal is to rewrite everything in Gren, which will simplify stuff like this.

[gilramir]

Good. Thanks for the info!