Debug.log and --optimize

Request Feedback
1

I finally got my photo album app to build with 0.19! :slight_smile:

Then, I tried to build it with --optimize and, as promised in the upgrade docs, it’s complaining that I’m using functions from Debug. :-/

I completely understand why we can’t make an optimized program that uses Debug.toString or Debug.todo. However, the reasoning for Debug.log is not so clear.

Maintaining Debugging Hooks in Code

I guess first off, I’m struggling with how to handle the maintenance issue: Those Debug.log function calls are (1) landmarks in the code that tell other devs “this bit is tricky” and (2) useful to have on hand when I drop out of --optimize and work on the next feature or tweak or whatever and discover that something that used to work has suddenly quit working. (I know comments are another way of doing #1, but Debug.log is like an “active” comment – it doesn’t just tell you it’s tricky “statically”, it helps you follow along as the program executes dynamically.)

My best idea right now is to keep a remove Debug.log calls commit in my git history that I can git revert when I need to. That’s much more automatic than manually commenting / uncommenting things, but of course it’s vulnerable to bitrot (conflicts).

Ways to Support Debug.log in --optimize

It’d be better of course if I could just leave those Debug.log calls in there all the time! :slight_smile: It seems that using an implementation like:

log : String -> a -> a
log _ value =
    value

… in --optimize mode would be just fine, no? If there are optimizations that wouldn’t work in the presence of such an implementation, I don’t know what they would be.

Of course there would be some cases where the string arg you’re passing in to log is produced with Debug.toString, so you’d have to comment those out before using --optimize. However, at least in my codebase, the vast majority (28 of 30) of Debug.log invocations are not reliant on Debug.toString to produce the string that they’re logging.

An even nicer --optimize variant would be:

log : String -> a -> a
log str value =
    {- some native magick to do 'console.log(str);' -}
    value

… in other words, dropping the implicit ++ Debug.toString value that gets tacked on the end would still be useful in a lot of cases.

2 Likes
2

Ah, I just thought of another, more maintainable way to keep the debugging hooks in place. I can make a DebugSupport module that wraps Debug.log, and then I only have one isolated place where i can switch between using Debug.log and my (\_ val -> val) substitute. Gonna give this a try now.

4 Likes
3

Yes, that looks like it worked great – here’s the commit. :slight_smile:

4

In JavaScript, it’s possible for any package you depend on to log to the console and complain about things which you often have no control over. I’ve seen this happen even when the package is trying to inspect the environment and avoid logging in production. Guaranteeing that there is no Debug.log in the package catalog is a great feature.

As for applications, though, that’s a bit trickier. I guess it’s to encourage using the time traveling debugger (locally), and a monitoring service (e.g. rollbar, sentry) in production.

1 Like
5

Ah, yes, I hadn’t thought about logging in dependencies. I agree it’s a nice feature to prevent that.

I was also going to try the debugger but ran into the Map.!: given key is not an element error. :frowning: I think in the past I’ve been unable to use that because my model contains functions.

6

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.