But maybe, I’ve not been pointing the right way. Sometimes I use harsh language, but when I do, I’d better know what I’m talking about. Obviously, I didn’t (in this instance).
I don’t know if it’s the pdf rendering software or the system that’s preventing the live update. If it’s the os, then we might actually write branches depending on that. Since they’d behave differently anyway, we might as well support different workflows. (Sorry for saying “we”. I’m not at all involved in writing the plot module’s code.) Anyone using J in both contexts would then need to know about this difference rather than the difference of the system’s dealing with opened (locked/write-protected?) files. Am 11.11.20 um 23:45 schrieb Devon McCormick: > Both good points. > > On Wed, Nov 11, 2020 at 4:56 PM Hauke Rehr <[email protected]> wrote: > >> Others might want to see live updates, >> using software that can deal with it >> (other than Adobe junk). >> This would be a breaking change. >> Keep that new definition locally, >> if you need it, but don’t disrupt >> others’ workflows. >> >> Am 11.11.20 um 20:51 schrieb Devon McCormick: >>> I have often been annoyed by the behavior of plot when I try to plot >>> something but have previously plotted something so the 2nd plot fails >> with >>> this message: >>> Unable to write to file: ...plot.pdf >>> If the file is open in Adobe, close the file and try again. >>> >>> I changed this behavior by inserting this code into "pdf_write" in >>> "jzplot.ijs" and "pdfdraw.ijs": >>> wroteFile=. 1 >>> if. _1 -: dat flwrite file do. >>> file=. (":?1e3) (([ ,~ ] {.~ '.' i:~ ]) , ] }.~ '.' i:~ ]) file >>> wroteFile=. 0 >>> end. >>> if. -.wroteFile do. >>> ... >>> end. >>> >>> immediately preceding and encompassing the statement block starting >> "while. >>> _1 -: dat flwrite file do." in both jzplot and pdfdraw; I also made a >>> similar change for "OutputFile" in the function "write" in "publish.ijs". >>> >>> This changes the name of "plot.pdf" to "'plot',(":?1e3),'.pdf'" if the >>> initial write attempt fails but this name change is local to the writing >>> fns so I don't know what side-effects this has. >>> >>> It looks like the name "~temp/plot.pdf" is assigned to the global >>> "PDF_DEFFILE" in jzplot. The only place I see this global used is inside >>> "pdf_getparms" which is used in "pdf_show" and "pdf_get" and these two >>> function names are assigned to the globals "pd_pdf" and "pd_pdfr" in >>> jzplot. I don't see any uses of these names other than this assignment. >>> >>> In any case, it would be nice to incorporate this into the J code base. >> If >>> not, I suppose I can continue to manually update the modules whenever I >>> upgrade. Maybe I will eventually encounter an unwanted side-effect. >>> Right now it looks like this change might clutter up my ~temp area with >>> random PDF files but I can live with that. >>> >> >> -- >> ---------------------- >> mail written using NEO >> neo-layout.org >> >> ---------------------------------------------------------------------- >> For information about J forums see http://www.jsoftware.com/forums.htm >> > > -- ---------------------- mail written using NEO neo-layout.org ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
