Assert

Assert

[Ohad Rodeh]

List,
    I still cannot figure out why the assert instruction
does not return the line number at which the exception occures.
The characters are no good to me in debugging. I suppose they make
sense from the compiler's point of view, but they are no use to me. 

Suppose one has a LARGE ocaml file, with several "assert" instructions. 
When an assert exception occures, it is not an easy task to figure out
where it came from. 

  Can someone enlighten me on this point?

	Ohad.

Re: Assert

[Chris Hecker]

>Suppose one has a LARGE ocaml file, with several "assert" instructions. 
>When an assert exception occures, it is not an easy task to figure out
>where it came from. 

M-x goto-char

:)

Chris

Re: Assert

[Nicolas barnier]

Ohad Rodeh wrote:
> 
> The characters are no good to me in debugging. I suppose they make
> sense from the compiler's point of view, but they are no use to me.

Under Emacs or XEmacs : '->' or C-f move forward one character, and
C-u n repeat a command n times. So C-u n '->' where n is the location
returned by the assert failure and when done at the beginning of the
specified file will point you at the right piece of code.

-- Nicolas

Re: Assert

[Xavier Leroy]

> List,
>     I still cannot figure out why the assert instruction
> does not return the line number at which the exception occures.

Basically, it's because the compiler uses character numbers
internally; line numbers are computed only when printing an error message.

> The characters are no good to me in debugging. I suppose they make
> sense from the compiler's point of view, but they are no use to me. 

With Emacs, it's as easy to jump to a character number (M-x goto-char)
than to jump to a line number (M-x goto-line).  Since we (the OCaml
developers) are Emacs fans, we didn't think that character numbers
might be a problem for some users.

- Xavier Leroy

Re: Assert

[Stefan Monnier]

>>>>> "Chris" == Chris Hecker <checker@d6.com> writes:
>> Suppose one has a LARGE ocaml file, with several "assert" instructions.
>> When an assert exception occures, it is not an easy task to figure out
>> where it came from.
> M-x goto-char

M-x next-error could also be made to work.


        Stefan

Re: Assert

[Hendrik Tews]

Hi,

Xavier Leroy writes:
   From: Xavier Leroy <Xavier.Leroy@inria.fr>
   Date: Fri, 3 Nov 2000 11:37:52 +0100
   Subject: Re: Assert
   
   > List,
   >     I still cannot figure out why the assert instruction
   > does not return the line number at which the exception occures.
   
   Basically, it's because the compiler uses character numbers
   internally; line numbers are computed only when printing an error message.
   
>From what I can see from the sources, for every error and warning
message the whole source file is parsed again with a special
lexer to determine the line number (parsing/linenum.mll). Could
anybody comment on this approach to printing error messages? (It
seems very very very strange to me.)


Besides that I have another suggestion for the 
this discussion thread about escaping assertions:

Would it be possible to reserve a keyword (or a standard library
symbol) "current_line_number" that, by magic, expands to its
location (a tuple or triple of integers) in the source file? This
way the magic of assert would be available for us users, one
could write

try ....
with 
  ...
  | a -> prerr_endline( "Exception " ^ (Printexc.to_string a) ^ 
                        " escaping at " ^ 
                        ( ... current_line_number))


Bye,

Hendrik

Re: Assert

[Xavier Leroy]

> From what I can see from the sources, for every error and warning
> message the whole source file is parsed again with a special
> lexer to determine the line number (parsing/linenum.mll). Could
> anybody comment on this approach to printing error messages? (It
> seems very very very strange to me.)

Well, keeping track of character numbers during lexing is trivial,
while keeping track of line numbers requires a bit more work
(especially with the # lineno construct).  So, the idea was to lex and
parse source files at full speed when there is no error, and pay the
price of computing line numbers only when an error needs to be
reported.

Also, this separates concerns between the two lexers: one deals with
the language proper, the other with line numbers.  Call it
aspect-oriented programming if you wish :-)

This said, it's one of those ideas that look nice at first sight, but
have some practical drawbacks, e.g. no line numbers are printed for
Match_failure and Assert_failure exceptions, and the debugger has
problems coping with # lineno "filename" directives.  We've been
considering going back to a more traditional approach, with line and
column numbers computed during lexing and stored in the abstract
syntax tree.

- Xavier Leroy

Re: Assert

[John Max Skaller]

Nicolas barnier wrote:
> 
> Ohad Rodeh wrote:
> >
> > I have a problem with the assert solution. It does not
> > indicate the line number in the source code. For example, running the
> > program:
> >
> >   Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
> >   496)
> 
> >From the users manual :
> 
> exception Assert_failure of (string * int * int)
> 
>      Exception raised when an assertion fails. The arguments are the
> location of
> the pattern-matching in the source code (file name, position of first
> character,
>                                                     ^^^^^^^^^^^^^^^^^^^^^^^^^^^
> position of last character).
> ^^^^^^^^^^^^^^^^^^^^^^^^^^

This information is fairly useless to me. I use 'vi', which has
no way to move to the n'th character of a file: in particular,
n forward movements do not count line end characters. This information
is also not what the compiler reports; namely line/column numbers,
which is much more useful. IMHO.


-- 
John (Max) Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia voice: 61-2-9660-0850
checkout Vyper http://Vyper.sourceforge.net
download Interscript http://Interscript.sourceforge.net

Re: Assert

[Damien Doligez]

>From: Ohad Rodeh <orodeh@cs.huji.ac.il>

>Suppose one has a LARGE ocaml file, with several "assert" instructions. 
>When an assert exception occures, it is not an easy task to figure out
>where it came from. 

Open the file in emacs.  Go to the beginning of the file.  Type
<ESC> <number-of-characters> control-F.  It works even if there are
several assert expressions in the same line.  The compiler doesn't
keep track of the line number, so it cannot include it in the
exception.

-- Damien

Re: Assert

[Nicolas barnier]

Ohad Rodeh wrote:
> 
> I have a problem with the assert solution. It does not
> indicate the line number in the source code. For example, running the
> program:
>
>   Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
>   496)

>From the users manual :

exception Assert_failure of (string * int * int)

     Exception raised when an assertion fails. The arguments are the
location of 
the pattern-matching in the source code (file name, position of first
character,
						    ^^^^^^^^^^^^^^^^^^^^^^^^^^^
position of last character).
^^^^^^^^^^^^^^^^^^^^^^^^^^

-- Nicolas

Assert

[Ohad Rodeh]

I have a problem with the assert solution. It does not
indicate the line number in the source code. For example, running the
program:

let _ = 
  try 
    raise Not_found
  with _ -> assert false

Results in: 
  Fatal error: uncaught exception Pervasives.Assert_failure("xx.ml", 484,
  496)

	Ohad. 

On Tue, 31 Oct 2000, Mattias Waldau wrote:

> Nice idea with 'with Not_found -> assert false'.
> 
> 1. But why can't the assert-information be available for all raise? wouldn't
> that be the same?
> 
> 2. If the we cannot include this in 'raise', how can I automate it, so that
> I get the assert-behaviourif I keep the asserts, and the normal behaviour
> otherwise. I normally don't deliver code with assert enabled.
> 
> /mattias
> 
>