Oh sorry, I had misread. Чт, 02 июн 2016, bill lam написал(а): > 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
-- 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
