Timeline for Generating figures over remote connection (using terminal)
Current License: CC BY-SA 3.0
9 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| May 3, 2012 at 21:11 | history | edited | Jens | CC BY-SA 3.0 | typo |
| May 3, 2012 at 20:31 | history | edited | Jens | CC BY-SA 3.0 | Comment on local Kernel session |
| May 3, 2012 at 19:11 | comment | added | Jens | Agreed. E.g., to make movies one uses render farms where the frames are generated and post-processed in background jobs. Since MMA is already quite slow at complex graphics, having no way to offload to background jobs is terrible. I'm surprised they did that. | |
| May 3, 2012 at 18:34 | comment | added | jmlopez | I really thought that this would be more efficient since the kernel will be running in a faster machine but it seems as if the graphics are being generated in my machine over an internet connection and this just makes the whole process way slower. What a bunch of bull... | |
| May 3, 2012 at 14:37 | comment | added | Pillsy | It also evidently makes the output of batch jobs dependent on the actual X setup on your server, which adds a kind of fun and excitement to bacth workflows that I would just as happily do without. | |
| May 3, 2012 at 14:19 | comment | added | Jens | Yes, it cripples any workflow that relied on batch jobs to generate figures. It's bad. | |
| May 3, 2012 at 8:55 | comment | added | celtschk | I wonder what drove Wolfram to this, err, interesting choice. There's nothing inherent in exporting graphics which couldn't be done on a kernel (and even more so, if you don't need to display anything on screen, a connection to a screen should not be required). | |
| May 2, 2012 at 23:46 | vote | accept | jmlopez | ||
| May 2, 2012 at 23:29 | history | answered | Jens | CC BY-SA 3.0 |