[Jprogramming] Bring out yer bugs
Henry Rich
henryhrich at gmail.com
Wed Jun 1 18:23:24 UTC 2016
If there are no lines in the definition (after removing blanks &
comments), you get domain error when the verb starts execution. (It is
treated as a missing valence)
If there are lines, but no B-block line is executed, you get i. 0 0.
That's how it's implemented.
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 <bbill.lam at gmail.com>
>> To: programming at jsoftware.com
>> 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" <henryhrich at gmail.com> 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
More information about the Programming
mailing list