search

GaloisInc / daedalus

The Daedalus data description language
BSD 3-Clause "New" or "Revised" License
65 stars 11 forks source link

Audit for stdout printing in lieu of stderr #297

Open jtdaugherty opened 1 year ago

jtdaugherty commented 1 year ago

Related to https://github.com/GaloisInc/daedalus/pull/294, @yav mentioned that warnings (and possibly other things?) might get printed to stdout in place rather than being collected and returned or printed to stderr instead. This issue is a reminder to do an audit to see if there are spots that should get updated to print to stderr or whether warnings should be gathered up and printed by the daedalus tool.

One possible issue with warning-gathering that comes to mind is that if the warnings are only meaningful when interleaved with other existing console output, it might be best to keep printing them in place. But if it's okay to summarize all of the warnings after the tool has completed running, then it would be best to gather them all up and print them after everything else is done.

jtdaugherty commented 1 year ago

@yav - what do you think about the interleaving question I raised above? Is that something we need to be concerned about? Just from running the tool lately, it looks like the warnings are all that get emitted during processing, so my hunch is that it would be fine to gather them up.

jtdaugherty commented 1 year ago

Looking into this a little bit, I found that exe/Main.hs already gathers warnings and prints them all at once when generating C++ code,

generateCPP ... =
    let (hpp,cpp,warns) = C.cProgram ccfg prog
    mapM_ (\w -> ddlPrint ("[WARNING]" <+> w)) warns

but for the Haskell generation code path, warnings get emitted directly by Daedalus.Driver.tcModule.

jtdaugherty commented 1 year ago

Also, I did take a look around for print and putStrLn and didn't see a lot of evidence that there is any other printing going on that we would need to worry about.