Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > alt.lang.intercal > #1 > unrolled thread

E129 and E633 confusion in C-INTERCAL 0.29

Back to article view | Back to alt.lang.intercal

Contents

  E129 and E633 confusion in C-INTERCAL 0.29 Marius Gavrilescu <marius@ieval.ro> - 2016-07-08 11:56 +0300
    Re: E129 and E633 confusion in C-INTERCAL 0.29 Claudio Calvelli <c.news@w42.org.invalid> - 2016-07-12 10:10 +0000
      Re: E129 and E633 confusion in C-INTERCAL 0.29 ais523 <ais523@nethack4.org> - 2016-07-12 16:16 +0000
        Re: E129 and E633 confusion in C-INTERCAL 0.29 Claudio Calvelli <c.news@w42.org.invalid> - 2016-07-12 21:49 +0000

#1 — E129 and E633 confusion in C-INTERCAL 0.29

Hello,

I am a newcomer to INTERCAL and I am confused about ick's behaviour
towards programs that do not end with DO GIVE UP.

According to the manual <http://catb.org/esr/intercal/ick.htm#Errors>:
* E129 is a compile-time error triggered when a NEXT statement points to
  a non-existent label
* E633 is a runtime error triggered when execution runs off the end of
  the program

Consider the following one-line program:

  DO READ OUT #1

When compiled, it gives no error. When run, it outputs the following on
stderr:

  ICL129I PROGRAM HAS GOTTEN LOST
          ON THE WAY TO WHO KNOWS WHERE
          CORRECT SOURCE AND RESUBNIT

This seems inconsistent with the manual -- shouldn't it be E633 instead?
Am I missing something obvious or is this a bug?

It should be mentioned that a program where a NEXT statement points to
a non-existent label does correctly give E129 during compilation.

This is C-INTERCAL 0.29 from the Gentoo repos.

Thank you,
-- 
Marius Gavrilescu

[toc] | [next] | [standalone]

#3

On 2016-07-08, Marius Gavrilescu <marius@ieval.ro> wrote:
> Consider the following one-line program:
>
>   DO READ OUT #1
>
> When compiled, it gives no error. When run, it outputs the following on
> stderr:
>
>   ICL129I PROGRAM HAS GOTTEN LOST
>           ON THE WAY TO WHO KNOWS WHERE
>           CORRECT SOURCE AND RESUBNIT

I thought ais523 would have answered by now...  but nobody said anything, so
I decided to have a look myself.

I can certainly reproduce this:

# emerge dev-lang/c-intercal
$ echo 'DO READ OUT #1' > test.i
$ ick test.i
$ ./test
 
I
ICL129I PROGRAM HAS GOTTEN LOST
        ON THE WAY TO WHO KNOWS WHERE
        CORRECT SOURCE AND RESUBNIT

and I personally would have expected this output:

I
ICL633I PROGRAM FELL OFF THE EDGE
        ON THE WAY TO THE NEW WORLD
        CORRECT SOURCE AND RESUBNIT

this is what CLC-INTERCAL produces (well, it produces a *633 although the
message looks different) (and also except that you need to find some older
version of perl to use CLC-INTERCAL as there hasn't been any recent update)
(and yes I know, one of these years there may be a new CLC-INTERCAL; it
has been in the works for long enough) (sorry this paragraph starts looking
like LISP, PLEASE DON'T TRY THAT).

> This seems inconsistent with the manual -- shouldn't it be E633 instead?
> Am I missing something obvious or is this a bug?

I would think of it as a bug.

> It should be mentioned that a program where a NEXT statement points to
> a non-existent label does correctly give E129 during compilation.
>
> This is C-INTERCAL 0.29 from the Gentoo repos.

C

[toc] | [prev] | [next] | [standalone]

#4

Claudio Calvelli wrote:
> On 2016-07-08, Marius Gavrilescu <marius@ieval.ro> wrote:
>> Consider the following one-line program:
>>
>>   DO READ OUT #1
>>
> I thought ais523 would have answered by now...  but nobody said anything, so
> I decided to have a look myself.

I saw this yesterday (I don't check Usenet every day) but was too tired
to reply then. Looks like you beat me by a few hours.

> I can certainly reproduce this:

Strangely enough, when I try this I get the expected output, rather than
the output that you and the OP give. It's the same output you expected:
>
> I
> ICL633I PROGRAM FELL OFF THE EDGE
>         ON THE WAY TO THE NEW WORLD
>         CORRECT SOURCE AND RESUBNIT

Looking at the source repository, the problem seems to have been fixed
in the following commit:

commit 3bdb50343967f0c756c6d4e4acbb5c6dde2d728b
Author: Alex Smith <ais523@nethack4.org>
Date:   Wed Apr 22 00:32:57 2015 +0100

    Handle falling off the end of the program correctly
    
    This must have been broken for ages, but nobody noticed because you
    don't do that intentionally, and all the times it happened by
    accident, syslib was there to print its own error message.
    
    Also add a regression test for the situation.

I guess the commit hasn't made its way to gentoo yet. (I'm not entirely
sure where the C-INTERCAL repository is, at the moment; git lists three
remotes but none of them are accessible. If nobody can find it, let me
know and I'll throw up another mirror somewhere using my local copy as
the source.)

-- 
ais523

[toc] | [prev] | [next] | [standalone]

#5

On 2016-07-12, ais523 wrote:
> I guess the commit hasn't made its way to gentoo yet. (I'm not entirely
> sure where the C-INTERCAL repository is, at the moment; git lists three
> remotes but none of them are accessible. If nobody can find it, let me
> know and I'll throw up another mirror somewhere using my local copy as
> the source.)

Well, guess what?  Gentoo lists my server as source...  but I don't
remember having received an update in a long time (the most recent I
have is dated April 1, 2011).  Please feel free to send the most recent
version to me (just remove the ".invalid" from the "From" line of this
post).

Since this sounds like a bug with the Gentoo ebuild, we can fix that by
opening a bug report with them (either listing the current repositories,
or by telling them there's an update available).

C

[toc] | [prev] | [standalone]

Back to top | Article view | alt.lang.intercal

csiph-web