Keeps running forever for a specific file

[vemv]

Hi there,

here's the last issue of today's batch.

For a specific file (not sure yet which), zprint keeps running forever. If I ctrl+\ to obtain a stacktrace, every time I hit that, I see zprint doing something different (e.g. calling some or other method from rewrite-clj or clojure.core etc).

So it appears it's not exactly "stuck" in a single line of code.

I will try to isolate this (with the caveat that this codebase is closed-source).

Anyway before deep-diving much - is this something you've seen much before? Are there steps I can follow to debug (or trace / log) this more quickly?

I reckon that the simplest thing I can do is give you a problematic file, but perhaps you have a recipe I can follow first.

Thanks - V

[kkinnear]

I have never seen this happen. At all. I can think of several things you could do:

1. You could try running w/out :style :sall and see if it still has this problem. That would tell me something useful.
2. You could try running with :parallel?/ false, which would almost certainly slow it down a bit, but would also tell me something about where to begin to look for the problem.
3. You could run with :dbg? true, which will produce vast reams of output. And I mean vast. You could send me a good bit of the end of the output, which might allow me to figure out what was going on. That is what I would (will) do to debug something like this. There is a lot (and I mean a lot) of debugging built in. It usually only gets used with simple and short tests and examples of problems, and even then it is a lot to wade through. But this would be something to try. If you did this, little bits of the code would show in the debugging, but if you just sent me a good bit of the end of the output, the only things I would see would be the little bit of code that is causing zprint to loop, which I can't imagine would be of any use to anyone.
4. Note that a file for zprint doesn't have to "work", so if you find the file which is a problem, if you can cut some it down some by just deleting the first or last bits (or whatever), the resulting file (which still needs to fail, of course) would probably not be considered useful in any realistic sense. You might be able to change names and things with an editor so that it is obfuscated sufficiently that even people that know what it is supposed to do in your company wouldn't recognize it, which might make it something that has no value to anyone but someone trying to debug zprint (i.e., me). To be clear, I'm not asking you to do something that people you work for wouldn't approve, just thinking about how to turn a closed source file into something that has no value other than for debugging zprint. My email is available on GitHub, so you could email it to me, and when I was finished, I would certainly delete the file. That way it isn't immortalized on GitHub for anyone to look at over time.

Generally, I do the "binary search" thing by deleting the first half of a file and seeing if it still fails, and then switch it around and try deleting the last half and check it, and then keep doing that until I have something small enough to work with.

Anyway, I'm very, very interesting in finding out what you have that is tripping up zprint, since this isn't something that has ever come up. Thanks!

[kkinnear]

In thinking about this some more, even if you can't find the file yet, if you have the codebase that loops forever, you might try turning off these two things (ideally, one at a time):

              :binding {:justify? false}
              :pair {:justify? true}

since with justification there is code that tries to justify something and if it doesn't "work", it goes back and does it w/out justification. It might be related to that. I don't think people use justification much, so if there is some ugly bug lurking in there somewhere, it might not have been noticed.

[kkinnear]

I noticed that you generally run with :parallel? false, which is fine. For the purposes of debugging this problem, if you are running with :dbg? true, you must have :parallel? false, otherwise the debugging logging is hopelessly garbled. So your standard setup is fine, but if you change anything, do not have :parallel? true if you also are doing dbg? true!!

[kkinnear]

For what it is worth, I ran the whole zprint codebase through with your particular mix of options, and it all ran to completion with no problem, more than 18K lines of code. Which is nice, but it doesn't help me debug this problem.

[kkinnear]

I also tried all of the *.clj files in clojure.core (though not a recent fork at all). No problems there either, using your options.

[vemv]

Thanks much for the suggestions and improvements!

Will leave feedback asap.

[kkinnear]

I just pushed a new branch, semantic3. I ran into some problems with semantic2 because I changed from master to main, and some things rolled downhill and messed up how semantic2 related to main on GitHub and locally. So I just pushed a new branch, semantic3. Your options map is still in guide.cljc, and is now called semantic3. This branch has the :fn-style enhancements I mentioned in the discussion on regexes just now. So the example in the discussion should work in the semantic3 branch. There have been several other changes and bug fixes, but nothing that you probably particularly care about. All of this is just FYI. I've been both busy and away from my desk for much of the last few weeks (and will continue to be so for a week or two more). For what that's worth.

[vemv]

. Your options map is still in guide.cljc, and is now called semantic3.

Thanks for the heads up!

I've been both busy and away from my desk for much of the last few weeks (and will continue to be so for a week or two more).

About the same here. Will be very happy to give what I hope will be our last (substantial) iterations, very soon.