@Bill suggested swapping the two lines: min=. nmm rounddown min max=. nmm roundup max
…wherever they occur in jzplot.ijs. I find them in: getticpos_jzplot_ and gettplog_jzplot_ This works just fine for all the examples I've tried so far. Plus it cures my original problem, so I no longer need (dbr 1) to get Plot to work at all in j807. BTW… I wrote: > I wondered about infinities in the data. This was nonsense. Re-reading Bill's replies I now realise that infinities in (buf) didn't arise from infinities in my own data. They arose out of matrix operations performed by the Plot package when I executed: (pd 'show'). They presumably also arose when I executed (pd 'pdf <filepath>'). Although the call into the dylib didn't then actually crash, it didn't draw any lines in the chart. But now it does. Thank you, @Bill. In case Bill's fix doesn't always work to eliminate infinities in (buf), I've edited jzplot.ijs as follows: trapbuf=: 3 : 'assert. 0' NB. IAC qt_gpapply=: 3 : 0 if. +./_ __ e. ,buf do. trapbuf buf end. NB. IAC rc=. glcmds`glcmds_jglc_@.(Poutput=iQTC) buf assert. 0=rc [ 'glcmds buf' buf=: $0 ) This allows me to quickly override (trapbuf) to take effective action if infinities reappear in (buf). On Sun, 20 Jan 2019 at 11:47, Ian Clark <[email protected]> wrote: > Thanks for all that, @Bill. > > I wondered about infinities in the data. There's (very old) code in my app > (TABULA) to eliminate infinite y-coordinates. > > But I had convinced myself it couldn't happen because I was only plotting > sine-waves. Nevertheless an infinity is creeping in. > > Maybe I shall trap it at the point it causes trouble, viz. > qt_gpapply_jzplot_. I'm quite happy to run with a patch that clips buf to > eliminate _ __ . And I'm only using (pd), not (plot) itself. > > But when there's time I will run through the procedures you suggest. I > always learn a lot by it. > > On Sun, 20 Jan 2019 at 11:25, bill lam <[email protected]> wrote: > >> I checked and it should be nonavx libj.dylib problem, >> you can try a temporary workaround by edit the jzplot.ijs >> look for the block (2 occurrences) >> >> if. max ~: min do. >> nmm=. 10 ^ <. <: 10 ^. max - min >> min=. nmm rounddown min >> max=. nmm roundup max >> end. >> >> and change to order of 2 lines to >> >> if. max ~: min do. >> nmm=. 10 ^ <. <: 10 ^. max - min >> max=. nmm roundup max >> min=. nmm rounddown min >> end. >> >> This is just a quick-and-dirty hack. >> >> Sun, 20 Jan 2019, bill lam написал(а): >> > I think the real issue is somehow infinity is evaluated. same as in case >> > that Joey had reported, where the tFm matrix contained both _ and __ , >> so >> > the matrix inner prodct may contain items such as >> > _ + __ which is NaN. >> > >> > On Sun, Jan 20, 2019, 10:26 AM bill lam <[email protected] wrote: >> > >> > > Ian, I just took a quick look at your data, >> > > >> > > iQTC=. 3!:2 fread '~/iQTC.bin' >> > > iQTC >> > > 6 >> > > Poutput=. 3!:2 fread '~/Poutput.bin' >> > > Poutput >> > > 5 >> > > buf=. 3!:2 fread '~/buf.bin' >> > > $buf >> > > 4435 >> > > 3!:0 buf >> > > 8 >> > > _ e. buf >> > > 1 >> > > __ e. buf >> > > 0 >> > > >> > > So the bug is not Qt Console output related. >> > > the cd error occur because buf contained _ so that >> > > it can't be coerced to integer. I think the problem is >> > > inside plot or changes in J Engine that an infinity >> > > is evaluated during generate data for plot. >> > > >> > > if you run on jqt, try force a exception whenever _ >> > > is encountered. Inside jzplot.ijs >> > > >> > > qt_gpbuf=: 3 : 0 >> > > assert. 2 > #$y >> > > if. _ e. ,y do. [:0 end. NB. add this line to force error >> > > buf=: buf,y >> > > ) >> > > >> > > Then examine the calling stack to trace where it had >> > > happened. >> > > >> > > If you are using the gui debugger, no need to add extra dbr 1. >> > > >> > > On the other hand, if you are not using gui debugger, then >> > > needs to start a debug session using dbr 1 >> > > When it enter suspension mode, type >> > > dbctx'' >> > > to see where it occurred, and then check the variable content. >> > > dbstk'' >> > > to examine calling stack >> > > dbret'' >> > > to cut stack and let it returns to the place that calling >> > > qt_gpbuf and then can examine values there. >> > > >> > > type dbhelp will give a brief summary of commands. >> > > >> > > >> > > Sat, 19 Jan 2019, Ian Clark написал(а): >> > > > @Bill I've copied you (…pm) in case the attached zipfile gets >> stripped >> > > off >> > > > the forum copy. >> > > > >> > > > When I reported that (dbr 1) cures my Plot problems with j807, I >> was too >> > > > hasty. I conjectured that there was a second bug that wasn't cured >> by >> > > (dbr >> > > > 1). >> > > > I've now isolated this "second bug". The attached script plus bin >> files >> > > > reproduces it in j807. >> > > > >> > > > 1. Unzip repro.zip and install in ~/ … >> > > > ~/repro.ijs >> > > > ~/buf.bin >> > > > ~/iQTC.bin >> > > > ~/Poutput.bin >> > > > >> > > > 2. Launch j807 jqt and ENTER… >> > > > load '~/repro.ijs' >> > > > [see: domain error: cd] >> > > > rc=_1 cder: 6 0 >> > > > >> > > > 3. repeat 2 but set debugging on first… >> > > > dbr 1 >> > > > load '~/repro.ijs' >> > > > [still error -but thanks to: dbr 1 a debug session is entered >> before the >> > > > script can finish.] >> > > > >> > > > HOWEVER... if repro.ijs can't do anything but fail, then it's not a >> good >> > > > demo of the bug I'm encountering in my (elaborate) app. >> > > > So let us show the error doesn't occur with an earlier version of J. >> > > > >> > > > 4. Launch j805 jqt (I haven't got j806 installed so I haven't tried >> it) >> > > and >> > > > ENTER… >> > > > load '~/repro.ijs' >> > > > rc=0 cder: 0 0 >> > > > >> > > > Sometimes 4 fails with >> > > > |domain error: chkgl2 >> > > > This is because chkgl2 gets the argument 1 instead of 0 for "ok". >> > > > The purpose of chkgl2 seems to be to convert an integer return-code >> from >> > > > the dylib into a J-error. >> > > > I haven't worked out why yet - normally the dylib returns 0 here, >> but >> > > when >> > > > my startup is disabled it returns 1. >> > > > But the main thing is that, inside glcmds, the (cd) call itself >> succeeds, >> > > > giving (0 0 -: cder''). >> > > > >> > > > But step 3. doesn't matter, except as proof that my example >> (sometimes) >> > > > gives no error in an earlier release of jqt. >> > > > What matters is the (cd) call failing in step 2. And, as step 3 >> shows, it >> > > > is not cured by (dbr 1) as I originally thought. >> > > > >> > > > Ian Clark >> > > > >> > > > >> > > > On Fri, 18 Jan 2019 at 07:16, bill lam <[email protected]> wrote: >> > > > >> > > > > It helps if your can tell the followings >> > > > > >> > > > > 3!:0 buf >> > > > > Poutput >> > > > > iQTC >> > > > > cder'' >> > > > > >> > > > > during suspension. >> > > > > >> > > > > Fri, 18 Jan 2019, Ian Clark написал(а): >> > > > > > I was too sanguine when I said that: >> > > > > > dbr 1 >> > > > > > made all my plot-nonavx problems go away. It doesn't. >> > > > > > >> > > > > > I'm getting this message from a complex app I'm working on, with >> > > certain >> > > > > > sorts of line chart: >> > > > > > >> > > > > > |domain error: cd >> > > > > > | rc=. glcmds`glcmds_jglc_@.(Poutput=iQTC)buf >> > > > > > >> > > > > > which arises within the verb: qt_gpapply_jzplot_ seemingly the >> > > result of >> > > > > a >> > > > > > bad call into the libjqt.dylib >> > > > > > >> > > > > > However it doesn't stop the app showing a correct Plot window. >> > > > > > >> > > > > > I gather there will be fixes for connected problems soon. If >> they >> > > don't >> > > > > > make the above error go away, I'll probe deeper, to replicate >> the >> > > error >> > > > > > with a simpler example. For now, it's just great to have Plot >> working >> > > > > (more >> > > > > > or less) with j807/j64nonavx/darwin. >> > > > > > >> > > > > > BTW the app works just fine with j805. >> > > > > > >> > > > > > On Fri, 18 Jan 2019 at 05:09, bill lam <[email protected]> >> wrote: >> > > > > > >> > > > > > > Thank you Joey. Ian had already sent me the files >> > > > > > > and I can reproduce the bug. I'll also forward >> > > > > > > that to Eric and Henry. >> > > > > > > >> > > > > > > I think the bug exists in all platforms but somehow >> > > > > > > only Darwin nonavx can produce the random data >> > > > > > > for NaN failure. >> > > > > > > >> > > > > > > Thu, 17 Jan 2019, Joey K Tuttle написал(а): >> > > > > > > > Bill, >> > > > > > > > >> > > > > > > > OK, edited project as requested - ran failing plot and then: >> > > > > > > > >> > > > > > > > MBpro:bin jkt$ ls -l ~/*bin >> > > > > > > > -rw-r--r-- 1 jkt staff 176 Jan 17 20:47 >> /Users/jkt/Tfm.bin >> > > > > > > > -rw-r--r-- 1 jkt staff 240048 Jan 17 20:47 >> /Users/jkt/y.bin >> > > > > > > > MBpro:bin jkt$ zip forBillLam.zip ~/*bin >> > > > > > > > adding: Users/jkt/Tfm.bin (deflated 56%) >> > > > > > > > adding: Users/jkt/y.bin (deflated 62%) >> > > > > > > > >> > > > > > > > will send the resulting zip file (forBillLam.zip) to >> > > > > [email protected] >> > > > > > > . >> > > > > > > > >> > > > > > > > Again, doing dbr 1 and running again - the graph was >> produced >> > > > > correctly >> > > > > > > with no errors, but I'll send, along with the above, file >> > > > > forBillLam2.zip >> > > > > > > comprising the same two files (that are a little different). >> > > > > > > > >> > > > > > > > Thanks for chasing this. >> > > > > > > > >> > > > > > > > - joey >> > > > > > > > >> > > > > > > > > On 2019Jan 17, at 20:04, bill lam <[email protected]> >> wrote: >> > > > > > > > > >> > > > > > > > > Please edit file addons/graphics/plot/jzplot.ijs >> > > > > > > > > and add the 2 fwrite lines as shown below. >> > > > > > > > > >> > > > > > > > > run plot and let it raise NaN exception. >> > > > > > > > > send the 2 files to our email address >> > > > > > > > > to help us track it down. >> > > > > > > > > >> > > > > > > > > project=: 3 : 0 >> > > > > > > > > '~/y.bin' fwrite~ 3!:1 y >> > > > > > > > > '~/Tfm.bin' fwrite~ 3!:1 Tfm >> > > > > > > > > dat=. }:"1 (y,.1) mp Tfm >> > > > > > > > > dist=. ViewDist-{:"1 dat >> > > > > > > > > ((ViewDist*}:"1 dat)%dist),.dist >> > > > > > > > > ) >> > > > > > > > >> > > > > > > > >> > > > > >> ---------------------------------------------------------------------- >> > > > > > > > For information about J forums see >> > > > > http://www.jsoftware.com/forums.htm >> > > > > > > >> > > > > > > -- >> > > > > > > regards, >> > > > > > > ==================================================== >> > > > > > > GPG key 1024D/4434BAB3 2008-08-24 >> > > > > > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> > > > > > > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >> > > > > > > >> > > ---------------------------------------------------------------------- >> > > > > > > For information about J forums see >> > > http://www.jsoftware.com/forums.htm >> > > > > > >> > > ---------------------------------------------------------------------- >> > > > > > For information about J forums see >> > > http://www.jsoftware.com/forums.htm >> > > > > >> > > > > -- >> > > > > regards, >> > > > > ==================================================== >> > > > > GPG key 1024D/4434BAB3 2008-08-24 >> > > > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> > > > > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >> > > > > >> ---------------------------------------------------------------------- >> > > > > For information about J forums see >> http://www.jsoftware.com/forums.htm >> > > >> > > >> > > >> > > -- >> > > regards, >> > > ==================================================== >> > > GPG key 1024D/4434BAB3 2008-08-24 >> > > gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> > > gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >> > > >> >> -- >> regards, >> ==================================================== >> GPG key 1024D/4434BAB3 2008-08-24 >> gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3 >> gpg --keyserver subkeys.pgp.net --armor --export 4434BAB3 >> > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
