shouldn't it be a control error in verb f? On Jun 2, 2016 8:18 PM, "Henry Rich" <[email protected]> wrote:
> I have changed the explicit-definition code (cx.c) to give the following > results: > > > f =: 3 : 0 NB. last B sentence is not last sentence executed > > r =. y + 5 > > y + undefname > > if. 0: y -: 6 do. > > r =. r + 1 > > end. > > ) > > f 5 > > |noun result was required: f > > | y+undefname > > > > g =: 3 : 0 NB. last B sentence is last sentence executed > > y + undefname > > ) > > g 5 > > |noun result was required: g > > | y+undefname > > > > h =: 3 : 0 NB. T block producing non-noun > > r =. y + 1 > > if. y + undefname do. > > r =. r + 1 > > end. > > y > > ) > > h 5 > > |noun result was required: h > > | y+undefname > > > > j =: 3 : 0 NB. T-block error in try., caught > > r =. y + 1 > > try. > > if. y + undefname do. > > r =. r + 1 > > end. > > catch. > > y =. 'caught!' > > end. > > y > > ) > > j 5 > > caught! > > > In all cases, when there is an error the debugger points to the same line > that was shown in the error message (which may not be the last line that > was executed). > > > AFAICS this responds to all the suggestions. > > > Henry Rich > > > On 5/31/2016 10:40 PM, bill lam wrote: > >> t3 is not empty, >> t3 >> 3 : 'NB.' >> >> It seems my assumption that explicit verb being initialized to >> i.0 0 is incorrect, but >> >> t5=: 3 : 0 >> 99 >> if. 0 do. '' end. >> ) >> >> t5'' >> 99 >> This is expected, but from where does t4 get the i.0 0 ? >> >> Ср, 01 июн 2016, jprogramming написал(а): >> >>> 3 : '' >>> 3 : '' >>> >>> >>> could be an error at definition? t1 to t3 are all equivalent to that. >>> >>> Though t4 doesn't execute anything, it is not the same error. >>> >>> a reasonable alternative would be: >>> >>> (i.0 0)-: 3 : '' a: >>> 1 >>> >>> >>> (i.0 0)-: 3 : 'label_.' 1 >>> >>> 1 >>> >>> ----- Original Message ----- >>> From: bill lam <[email protected]> >>> To: [email protected] >>> Sent: Tuesday, May 31, 2016 10:16 PM >>> Subject: Re: [Jprogramming] Bring out yer bugs >>> >>> IIUC, result of explicit verb is initialized to i.0 0 >>> >>> but t1 t2 t3 all raise domain error. >>> furthermore t4 is ok and >>> (i.0 0)-: t4'' >>> 1 >>> >>> Any theory? >>> >>> t1=: 3 : 0 >>> ) >>> >>> t2=: 3 : 0 >>> >>> ) >>> >>> t3=: 3 : 0 >>> NB. >>> ) >>> >>> t4=: 3 : 0 >>> if. 0 do. '' end. >>> ) >>> >>> Вт, 31 май 2016, Henry Rich написал(а): >>> >>>> Well, that's a design question. The problem is, the JE doesn't know >>>> that >>>> the sentence (5 + undefname) causes a problem until the end of the >>>> definition is reached. By that time, many sentences (in T blocks) may >>>> have >>>> been executed. There are two issues that I see: >>>> >>>> 1. What should the debugger do? Should it stop on the (5 + undefname) >>>> line, >>>> as if that line had just failed on its own? That would be the most >>>> informative thing to do UNLESS the sentences executed later have >>>> changed the >>>> program state so much that it's hard to make sense of the (5 + >>>> undefname) >>>> line. >>>> >>>> 2. If debug is off, what should be reported? Here, I have no doubt >>>> that the >>>> best solution would be a 'non-noun result' on the (5 + undefname) line. >>>> >>>> Let us agree that in case 2 I will give a 'non-noun result' showing the >>>> line >>>> causing the problem. That will handle most of the real-life situations >>>> where this would come up. >>>> >>>> What about case 1? Should: >>>> >>>> 1. the debugger stop on the line which is not the last one executed; >>>> 2. the debugger stop after the execution of the verb, as it does now >>>> (with a >>>> syntax error); >>>> 3. like case 1, but with some indication in the stack that this weird >>>> situation has occurred >>>> >>>> Henry Rich >>>> >>>> >>>> >>>> On 5/31/2016 6:29 PM, bill lam wrote: >>>> >>>>> Ok, it sounds reasonable.But you said, >>>>> >>>>> " >>>>> + undefname >>>>> if. 0 do. end. >>>>> ) >>>>> >>>>> would not be caught" >>>>> >>>>> Shouldn't it also be a "non-noun result" error? >>>>> On Jun 1, 2016 3:13 AM, "Henry Rich" <[email protected]> wrote: >>>>> >>>>> I agree with your analysis but not your conclusion. >>>>>> >>>>>> f =: 3 : 0 >>>>>> 5 + y >>>>>> 111 + yy >>>>>> ) >>>>>> >>>>>> In the current system we have >>>>>> >>>>>> f 5 >>>>>> >>>>>> |syntax error: f >>>>>> >>>>>> | f 5 >>>>>> >>>>>> Wouldn't we be happier with >>>>>> >>>>>> f 5 >>>>>> |non-noun result: f >>>>>> |111 + yy >>>>>> >>>>>> >>>>>> In my J classes, this is the one error where I just have to find it >>>>>> for >>>>>> the students rather than explain it to them. >>>>>> >>>>>> >>>>>> I am suggesting this definition: a sentence that completes normally, >>>>>> but >>>>>> is in a context where a noun result is required (as the last sentence >>>>>> in a >>>>>> T-block or the last sentence before return. or end-of-definition), is >>>>>> flagged with the 'non-noun result' error if it does not produce a >>>>>> noun. >>>>>> >>>>>> >>>>>> Wouldn't that be better? >>>>>> >>>>>> >>>>>> This would include both errors in >>>>>> >>>>>> >>>>>> f =: 3 : 0 >>>>>> if. test y do. >>>>>> + >>>>>> else. >>>>>> - >>>>>> end. >>>>>> ) >>>>>> >>>>>> >>>>>> Henry Rich >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On 5/31/2016 12:16 PM, bill lam wrote: >>>>>> >>>>>> IMO the sentence >>>>>>> 5 + undefname >>>>>>> itself is not an error. The error is the verb v returning it as >>>>>>> a result. So I prefer leave it as is (both not caught inside v). >>>>>>> >>>>>>> Similar argument would also hold for B block, but since it is >>>>>>> difficult to debug, so that changing it will make us happier. >>>>>>> >>>>>>> >>>>>>> Вт, 31 май 2016, Henry Rich написал(а): >>>>>>> >>>>>>> Unquestionably, sentences producing non-noun are OK as long as they >>>>>>>> don't >>>>>>>> end a T-block or a verb. >>>>>>>> >>>>>>>> What I was proposing in (b) was that >>>>>>>> >>>>>>>> v =: 3 : 0 >>>>>>>> ... >>>>>>>> 5 + undefname >>>>>>>> ) >>>>>>>> >>>>>>>> would be caught before exiting the verb, so that in debug you would >>>>>>>> point to >>>>>>>> the bad sentence rather than the calling verb. >>>>>>>> >>>>>>>> In contrast, >>>>>>>> >>>>>>>> >>>>>>>> v =: 3 : 0 >>>>>>>> ... >>>>>>>> 5 + undefname >>>>>>>> if. 0 do. end. >>>>>>>> ) >>>>>>>> >>>>>>>> would not be caught. >>>>>>>> >>>>>>>> Henry Rich >>>>>>>> >>>>>>>> >>>>>>>> On 5/31/2016 11:38 AM, bill lam wrote: >>>>>>>> >>>>>>>> As the current behavior permit non-noun as the execution result >>>>>>>>> of a sentence in an explicit verb definition, so I prefer leave >>>>>>>>> as is (for B block). >>>>>>>>> >>>>>>>>> It the verb returns a non-noun, it will raise a syntax error >>>>>>>>> in current J behavior although "non-noun result" error message >>>>>>>>> would be easier to be understood by new comers. >>>>>>>>> >>>>>>>>> In contrast, the context of T block expected a noun, I prefer it >>>>>>>>> to be caught at the crime scene. >>>>>>>>> >>>>>>>>> Just for clarification, non-noun result in the middle of T block >>>>>>>>> is fine. >>>>>>>>> >>>>>>>>> t1=: 3 : 0 >>>>>>>>> if. >>>>>>>>> 1 >>>>>>>>> + >>>>>>>>> 2 >>>>>>>>> do. 3 else. 4 end. >>>>>>>>> ) >>>>>>>>> >>>>>>>>> Вт, 31 май 2016, Henry Rich написал(а): >>>>>>>>> >>>>>>>>> There are two different problems to consider. >>>>>>>>>> >>>>>>>>>> 1. A non-noun result at the end of a T block should be detected >>>>>>>>>> as an >>>>>>>>>> error >>>>>>>>>> on the do., and should trap or go to catch. like any other error. >>>>>>>>>> Both of >>>>>>>>>> your examples come under this heading. I will fix this. >>>>>>>>>> >>>>>>>>>> 2. A non-noun result at the end of a B block is different, because >>>>>>>>>> there >>>>>>>>>> more sentences may be executed: >>>>>>>>>> >>>>>>>>>> if. 1 do. >>>>>>>>>> + >>>>>>>>>> end. >>>>>>>>>> if. 0: SomeComplicatedVerb y do. >>>>>>>>>> 5 >>>>>>>>>> end. >>>>>>>>>> return. >>>>>>>>>> >>>>>>>>>> The + is going to cause an error, but not until after the later T >>>>>>>>>> block, >>>>>>>>>> including SomeComplicatedVerb, has been executed. >>>>>>>>>> >>>>>>>>>> I can think of solutions: >>>>>>>>>> a. leave as is >>>>>>>>>> b. if the non-noun sentence is the last sentence executed before >>>>>>>>>> leaving the >>>>>>>>>> verb, trap on it; otherwise continue as now >>>>>>>>>> c. always go back and trap on the non-noun sentence when it is >>>>>>>>>> discovered >>>>>>>>>> that it is generating the erroneous return value, even though >>>>>>>>>> other >>>>>>>>>> later >>>>>>>>>> sentences may have executed and completely changed the program >>>>>>>>>> state >>>>>>>>>> >>>>>>>>>> What solution is best? >>>>>>>>>> >>>>>>>>>> Henry >>>>>>>>>> >>>>>>>>>> On 5/28/2016 10:23 AM, bill lam wrote: >>>>>>>>>> >>>>>>>>>> Sorry I had not included an example, it is about debug >>>>>>>>>>> suspension stack. >>>>>>>>>>> >>>>>>>>>>> t1=: 3 : 0 >>>>>>>>>>> 1 >>>>>>>>>>> t2'' >>>>>>>>>>> 4 >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> t2=: 3 : 0 >>>>>>>>>>> 1 >>>>>>>>>>> 2 >>>>>>>>>>> 3 >>>>>>>>>>> if. 0-: notexist_base_ do. end. >>>>>>>>>>> 4 >>>>>>>>>>> 5 >>>>>>>>>>> 6 >>>>>>>>>>> ) >>>>>>>>>>> >>>>>>>>>>> dbr 1 >>>>>>>>>>> t1'' >>>>>>>>>>> |control error: t2 >>>>>>>>>>> |t2[3] >>>>>>>>>>> >>>>>>>>>>> NB. this seemed ok, but >>>>>>>>>>> >>>>>>>>>>> dbstack'' >>>>>>>>>>> +----+--+--+--+----+------+----+ >>>>>>>>>>> |name|en|ln|nc|args|locals|susp| >>>>>>>>>>> +----+--+--+--+----+------+----+ >>>>>>>>>>> |t1 |23|1 |3 |++ |+-++ |* | >>>>>>>>>>> | | | | ||| ||y|| | | >>>>>>>>>>> | | | | |++ |+-++ | | >>>>>>>>>>> +----+--+--+--+----+------+----+ >>>>>>>>>>> dbctx'' >>>>>>>>>>> @@ t1[1] *v @@ /home/bill/a1.ijs >>>>>>>>>>> 3 : 0 >>>>>>>>>>> [0] 1 >>>>>>>>>>> >>>>>>>>>>> [1] t2'' >>>>>>>>>>>> >>>>>>>>>>>> [2] 4 >>>>>>>>>>> >>>>>>>>>>> NB. the top of stack (13!:13) is not t2. >>>>>>>>>>> >>>>>>>>>>> Сб, 28 май 2016, Henry Rich написал(а): >>>>>>>>>>> >>>>>>>>>>> I can reproduce the problem, which seems to be that a T block >>>>>>>>>>>> that >>>>>>>>>>>> has a >>>>>>>>>>>> non-noun result doesn't go to the catch. >>>>>>>>>>>> >>>>>>>>>>>> I don't understand your second part: >>>>>>>>>>>> >>>>>>>>>>>> Also control error will can only be reported after exiting the >>>>>>>>>>>> explicit verb, not the lines of control block. >>>>>>>>>>>> >>>>>>>>>>>> Can you give an example of that? >>>>>>>>>>>> >>>>>>>>>>>> I will work on this right after we get all the current branches >>>>>>>>>>>> merged together. >>>>>>>>>>>> >>>>>>>>>>>> Henry Rich >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>>> On 5/27/2016 9:32 PM, bill lam wrote: >>>>>>>>>>>> >>>>>>>>>>>> The handling of control error I had report many years ago, >>>>>>>>>>>>> >>>>>>>>>>>>> http://www.jsoftware.com/pipermail/beta/2006-August/001776.html >>>>>>>>>>>>> >>>>>>>>>>>>> Also control error will can only be reported after exiting the >>>>>>>>>>>>> explicit verb, not the lines of control block. >>>>>>>>>>>>> >>>>>>>>>>>>> But Roger said it was the intended behavior. Can you take a >>>>>>>>>>>>> look? >>>>>>>>>>>>> >>>>>>>>>>>>> Вт, 17 май 2016, Henry Rich написал(а): >>>>>>>>>>>>> >>>>>>>>>>>>> The J Engine is being worked on again. The people working on >>>>>>>>>>>>>> it >>>>>>>>>>>>>> are not >>>>>>>>>>>>>> experts on it yet, but we have fixed quite a few of the >>>>>>>>>>>>>> long-standing bugs >>>>>>>>>>>>>> and have plans for improvements. >>>>>>>>>>>>>> >>>>>>>>>>>>>> There have long been Wiki pages for reporting bugs, pointed >>>>>>>>>>>>>> to by >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://code.jsoftware.com/wiki/System/Interpreter/Bugs >>>>>>>>>>>>>> >>>>>>>>>>>>>> especially >>>>>>>>>>>>>> >>>>>>>>>>>>>> http://code.jsoftware.com/wiki/System/Interpreter/Bugs/Crashes >>>>>>>>>>>>>> and >>>>>>>>>>>>>> http://code.jsoftware.com/wiki/System/Interpreter/Bugs/Errors >>>>>>>>>>>>>> >>>>>>>>>>>>>> Quite a few of these have been fixed. If you have other bugs >>>>>>>>>>>>>> that >>>>>>>>>>>>>> are not >>>>>>>>>>>>>> listed on those pages, please add an entry for them! The >>>>>>>>>>>>>> recent >>>>>>>>>>>>>> report of >>>>>>>>>>>>>> trouble with >>>>>>>>>>>>>> >>>>>>>>>>>>>> +.~1 2 1j_. 3 >>>>>>>>>>>>>> >>>>>>>>>>>>>> would be a model candidate. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Add an entry for your problem, and it'll get fixed. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Henry Rich >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> >>>>>>>>>>>>>> ---------------------------------------------------------------------- >>>>>>>>>>>>>> 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 >>>> >>> -- >>> 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 >>> >> > ---------------------------------------------------------------------- > For information about J forums see http://www.jsoftware.com/forums.htm ---------------------------------------------------------------------- For information about J forums see http://www.jsoftware.com/forums.htm
