Of course. I agree. It is a very minor issue. On Tue, Feb 12, 2013 at 12:47 PM, Raul Miller <[email protected]> wrote:
> Personally, I would not place much priority on the visual aesthetics > of error reports. I sympathize, but I have not thought through the > issues so I am not even able to comment on whether this is a > reasonable suggestion. > > And, it's not like I do not have enough other things to deal with. > > That said: if you were having complex problems in the past, it might > have been a consequence of the error latent expression being set in > your context. > > -- > Raul > > On Tue, Feb 12, 2013 at 2:16 PM, Don Guinn <[email protected]> wrote: > > Went back and played with debug with try. and they seem to be working as > > one would expect. When try. first came out I had a lot of trouble with > > debug on definitions using try. so I have avoided debug on definitions > with > > try. in them. Seems that whatever was going on was fixed or I had just > > messed up and blamed it on try. with debug. > > > > On the other point about wanting a new signal error. Let me explain. I > have > > always felt that (13!:8) didn't work properly. But fixing it may break > > something else, so I suggested a new signal error. Here is a silly verb > to > > illustrate my concern: > > > > f=:4 : 0 > > > > try. > > > > a=.i.#x > > > > b=.x+a+y > > > > c=.>:b > > > > catch. > > > > m=.(13!:11)'' > > > > ('Hey dummy, ',>(<:m){(9!:8)'') (13!:8) m > > > > end. > > > > ) > > > > > > 1 2 f 1 2 3 > > > > Error Number: 9 > > > > |Hey dummy, length error > > > > | ('Hey dummy, ',>(<:m){(9!:8)'') (13!:8)m > > > > > > The last line is useless. It would be better if the error was displayed > as: > > > > > > 1 2 f 1 2 3 > > > > Error Number: 9 > > > > |Hey dummy, length error > > > > | 1 2 f 1 2 3 > > > > > > That would look more like how errors are displayed for primitives: > > > > > > 1 2 + 1 2 3 > > > > |length error > > > > | 1 2 +1 2 3 > > > > > > I really don't care to see the line that generates the error message, I > > would rather see the line which caused the error. Just like in primitives > > errors. > > > > > > > > On Mon, Feb 11, 2013 at 10:08 AM, Raul Miller <[email protected]> > wrote: > > > >> Are you saying 13!:0+1 introduces problems with try. and error display? > If > >> so, could you give some examples? > >> > >> Thanks, > >> > >> -- > >> Raul > >> > >> On Monday, February 11, 2013, Don Guinn <[email protected]> wrote: > >> > I've done that, but then when errors occur the output gets really > messy. > >> > And I get confused when using try. . > >> > > >> > On Mon, Feb 11, 2013 at 9:03 AM, Raul Miller <[email protected]> > >> wrote: > >> > > >> >> Or, make debug be active? > >> >> > >> >> -- > >> >> Rau > >> >> > >> >> On Mon, Feb 11, 2013 at 11:01 AM, Don Guinn <[email protected]> > wrote: > >> >> > Yes, I agree. not really pretty. Mostly I have wanted this when > >> handling > >> >> > errors. Another way would be to have 13!:13'' work when debug is > not > >> >> > active. All the information should be in the stack to produce the > >> table. > >> >> Or > >> >> > does turning on debug cause additional information to be put in the > >> >> stack? > >> >> > > >> >> > And another thing that would be nice would be to have another 13!:? > >> >> signal > >> >> > showing the error on the caller's line, like 13!:8 but not show the > >> line > >> >> in > >> >> > error of the current definition. Make the output look like an error > >> >> > encountered in a primitive. > >> >> > > >> >> > On Mon, Feb 11, 2013 at 8:24 AM, Raul Miller < > [email protected]> > >> >> wrote: > >> >> > > >> >> >> While this (x__1_) could be done, it would also violate some > current > >> >> >> locality guarantees -- code using it would become difficult to > >> >> >> understand. > >> >> >> > >> >> >> A more robust approach would be to define a nested block mechanism > >> for > >> >> >> J, but even that needs a clear definition of why it's useful (but > >> it's > >> >> >> most useful where clarity is remote). > >> >> >> > >> >> >> -- > >> >> >> Raul > >> >> >> > >> >> >> > >> >> > > ---------------------------------------------------------------------- > >> >> > For information about J forums see > >> http://www.jsoftware.com/forums.htm > >> >> > ---------------------------------------------------------------------- > >> >> For information about J forums see > http://www.jsoftware.com/forums.htm > >> >> > >> > ---------------------------------------------------------------------- > >> > For information about J forums see > http://www.jsoftware.com/forums.htm > >> > > >> ---------------------------------------------------------------------- > >> For information about J forums see http://www.jsoftware.com/forums.htm > >> > > ---------------------------------------------------------------------- > > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm > ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
