[Jprogramming] Bring out yer bugs
'Pascal Jasmin' via Programming
programming at jsoftware.com
Wed Jun 1 02:26:11 UTC 2016
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
More information about the Programming
mailing list