Timeline for Configuration to limit time spent on formatting output
Current License: CC BY-SA 3.0
14 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 17, 2017 at 17:33 | vote | accept | kjo | ||
| Oct 14, 2017 at 15:23 | history | bounty awarded | jjc385 | ||
| Oct 12, 2017 at 19:36 | history | edited | Chris Chiasson | CC BY-SA 3.0 | changed example per request |
| Oct 12, 2017 at 16:52 | comment | added | jjc385 | Perhaps a better (if dumb) example: Graphics[{RGBColor @@ RandomReal[1, 3], Disk[RandomReal[{-5, 5}, 2], RandomReal[]]} & /@ Range[100], ImageSize -> 40*{5, 5}] & /@ Range[1000]. It takes about half a second to evaluate and on the order of 10 seconds to display. | |
| Oct 12, 2017 at 16:51 | comment | added | jjc385 | @ChrisChiasson I'm not sure this is the best example. Trace[xpr /. x -> y, TraceOriginal -> True] evaluates and displays more or less instantly (without modifying MakeBoxes). Rasterize take significantly longer both to evaluate (~10 seconds) and display (a few seconds). | |
| Oct 11, 2017 at 18:36 | history | edited | Chris Chiasson | CC BY-SA 3.0 | code tags for new version |
| Oct 11, 2017 at 16:42 | comment | added | jjc385 | @ChrisChiasson Do you have any suggestions for a minimal example? It's been a while since I've encountered this problem -- I mostly remember it being extremely frustrating. (Btw, this is a great idea. I only wish we had a better metric than ByteCount.) If you don't have an example, I might find some time to dig through old projects to try to find something. | |
| Oct 9, 2017 at 21:25 | comment | added | kjo | Sorry, I posted this issue 6 months ago, but I no longer have access to Mathematica (which I got through my employer then), so unfortunately I can't provide a minimal example. | |
| Oct 9, 2017 at 17:58 | comment | added | kjo | (Unfortunately, I don't have access to Mathematica at the moment, so I can't test these things.) | |
| Oct 9, 2017 at 17:54 | comment | added | kjo | The idea of monkey-patching MakeBoxes is an interesting one, though. What's needed is a way to implement an asynchronous time-out on it. | |
| Oct 9, 2017 at 17:49 | comment | added | kjo | The main problems I have with this solution are: 1) it's not a setting one can make once and forget about it (though maybe this can be fixed); 2) it relies on ByteCount as a proxy for rendering time, and, as I argue in my post, size seems to be a very poor indicator of rendering time. | |
| Oct 9, 2017 at 17:43 | history | edited | kjo | CC BY-SA 3.0 | added 58 characters in body |
| Oct 9, 2017 at 17:15 | comment | added | kjo | IF is suspect a problem beforehand, there is no problem: I simply add ; at the end of the expression, and that's the end of it. The problem only arises, precisely, when I do not suspect a problem beforehand, and end up stuck with an effectively frozen front end. Also, the implementation of the front end could easily build a time-out into the rendering step. This does not strike me as a technically difficult feature. | |
| Oct 9, 2017 at 17:00 | history | answered | Chris Chiasson | CC BY-SA 3.0 |