Re: [Bug-apl] Bug in function editing
Hi, thanks for reporting this, fixed in SVN 181. /// Jürgen On 03/31/2014 05:59 PM, Kacper Gutowski wrote: On 2014-03-31 10:15:23, Blake McBride wrote: I still think there is a small bug, however. Seeing the message 'problem 'Nabla.cc:444' would make anyone think there was an internal problem. APL had a standard message when that type of event occurred. GNU APL should display the standard error message when that type of user error occurred. This type of error can sometimes occur even by an experienced APL programmer (as I was). If the system displayed a message that looked more like user error, it would help. You could just look at the error message that the other APL's display (since I don't remember what the normal response was to that user error). I agree, and most importantly I think Jürgen will also agree, that this behaviour is not correct. >From what I see in the source, )SI stack is checked and useful message “function could not be edited, since it is used on the )SI stack.” is initially written to the )MORE buffer but then it's lost when Nabla::throw_edit_error() displays “DEFN ERROR” (without “+”) and overwrites )MORE message with “Nabla.cc:444”. The part where it prints “bad editor command” before “DEFN ERROR” seems to be just a leftover after some debugging hack as it essentially will give the line in source where error was encountered while parsing ∇-line. For most of user errors, a caret showing location in input where error occurred should be enough, and others (like this one) should be described with )MORE. -k
Re: [Bug-apl] Bug in function editing
On 2014-03-31 10:15:23, Blake McBride wrote: > I still think there is a small bug, however. Seeing the message 'problem > 'Nabla.cc:444' would make anyone think there was an internal problem. APL > had > a standard message when that type of event occurred. GNU APL should display > the standard error message when that type of user error occurred. This type > of > error can sometimes occur even by an experienced APL programmer (as I was). > If > the system displayed a message that looked more like user error, it would > help. > You could just look at the error message that the other APL's display (since > I > don't remember what the normal response was to that user error). I agree, and most importantly I think Jürgen will also agree, that this behaviour is not correct. >From what I see in the source, )SI stack is checked and useful message “function could not be edited, since it is used on the )SI stack.” is initially written to the )MORE buffer but then it's lost when Nabla::throw_edit_error() displays “DEFN ERROR” (without “+”) and overwrites )MORE message with “Nabla.cc:444”. The part where it prints “bad editor command” before “DEFN ERROR” seems to be just a leftover after some debugging hack as it essentially will give the line in source where error was encountered while parsing ∇-line. For most of user errors, a caret showing location in input where error occurred should be enough, and others (like this one) should be described with )MORE. -k
Re: [Bug-apl] Bug in function editing
Thank you for your reply. I was trying to correct a typo when I encountered the problem. Yes, the problem is that I have a SI. It has been so long, I forgot about that. I still think there is a small bug, however. Seeing the message 'problem 'Nabla.cc:444' would make anyone think there was an internal problem. APL had a standard message when that type of event occurred. GNU APL should display the standard error message when that type of user error occurred. This type of error can sometimes occur even by an experienced APL programmer (as I was). If the system displayed a message that looked more like user error, it would help. You could just look at the error message that the other APL's display (since I don't remember what the normal response was to that user error). Cool system though!! I am look forward to your answers to my other email. Thanks! On Mon, Mar 31, 2014 at 2:49 AM, Kacper Gutowski wrote: > On 2014-03-31 15:37:45, Elias Mårtenson wrote: > > Are you sure it's a bug? You seem to be taking the value of "r" when it > has no > > value. > > I think the problem is that you can't edit a function that is currently > on SI stack, not that Parse erred. > > -k >
Re: [Bug-apl] Bug in function editing
On 2014-03-31 15:37:45, Elias Mårtenson wrote: > Are you sure it's a bug? You seem to be taking the value of "r" when it has no > value. I think the problem is that you can't edit a function that is currently on SI stack, not that Parse erred. -k
Re: [Bug-apl] Bug in function editing
Are you sure it's a bug? You seem to be taking the value of "r" when it has no value. Also, I think your "x" should be "×". Regards, Elias On 31 March 2014 13:19, Blake McBride wrote: > ∇r←c Parse a > [1] r←(((0≠⍴a)x⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴a)-0,r←r/⍳⍴a)\(~r←r∈c)/a←,a > [2] ∇ > ',' Parse 'Hello,there,how are you' > VALUE ERROR > Parse[1] > r←(((0≠⍴a)x⍴r),⌈/r)⍴(,r∘.≥⍳⌈/r←¯1+(r,1+⍴a)-0,r←r/⍳⍴a)\(∼r←r∈c)/a←,a > ^ > ∇Parse > bad editor command '∇Parse' : problem 'Nabla.cc:444' > DEFN ERROR > ∇Parse >^ > >
