[Caml-list] Stop at exception
Magesh Kannan
I am debugging a large OCaml program and am stuck with an exception. The
exception is thrown by a utility function that is invoked several times in
the program. I want to know which invocation of the utility function
throws the exception. I cannot keep a breakpoint inside the utility
function because it is called several times in the program.
Is it possible to make the ocaml debugger stop at the invocation where the
exception is being thrown?
Are there other ways to accomplish the above objective?
Thanks,
Magesh
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
Xavier Leroy
> exception is thrown by a utility function that is invoked several times in
> the program. I want to know which invocation of the utility function
> throws the exception. I cannot keep a breakpoint inside the utility
> function because it is called several times in the program.
>
> Is it possible to make the ocaml debugger stop at the invocation where the
> exception is being thrown?
>
> Are there other ways to accomplish the above objective?
Easy: let the program run until it stops on the exception, then use the
"backstep" command to go back in time to the point where the exception
is raised; then do a "backtrace" command to see where you are.
In OCaml 3.04, you can also run the program outside of the debugger
and request a stack backtrace (set the OCAMLRUNPARAM environment
variable to "b").
- Xavier Leroy
Mattias Waldau
- Removed re-sharing of string literals, causes too many surprises with
in-place string modifications.
and therefor assumes that if I have a function like
let foo x =
"This is a string", x ;;
will foo create a new string each time foo is called?
Assume that I know that no one will in-place edit the string, I could
rewrite the code into the more efficient
let str = "This is a string";;
let foo x =
str, x ;;
and all calls to foo will get the same string.
Is this true?
If so, I wonder why not the standard strings of Ocaml are nonmutable?
It works fine for languages like Visual Basic, and Visual Basic has
great string performance compared to languages like C++.
The only thing important to make nonmutable strings efficient
is to make sure that the operation += (appending a string
to an old string, where the old string probably isn't needed
anymore) is efficient. (Look at a ASP/JSP-page and you will
understand why :-).
The reason I think nonmutable strings should be the default is that
Ocaml should try to prevent hard-to-find bugs, and allowing in-change
editing of strings is a typical case. (I can definitily live without
mutable strings, but mutable fields, ref, and arrays I cannot live
without.)
/mattias
P.s. Could phantom types be used to close (=make const) strings, arrays,
and maybe even mutable/ref, so that clients are not allowed to change
them?
YAMAGATA yoriyuki
Subject: [Caml-list] Non-mutable strings
Date: Sat, 5 Jan 2002 12:19:45 +0100
> If so, I wonder why not the standard strings of Ocaml are nonmutable?
> It works fine for languages like Visual Basic, and Visual Basic has
> great string performance compared to languages like C++.
<self_advertisement>
camomile (http://camomile.sourceforge.net) has an immutable string type for
ISO-UCS. For fast concatenation, camomile provides Ubuffer module
similar to Buffer module in standard libraries. Unlike Buffer.t, you
can access individual characters in Ubuffer.t by a cursor.
</self_advertisement>
--
YAMAGATA, yoriyuki (doctoral student)
Department of Mathematical Science, University of Tokyo.
Xavier Leroy
> - Removed re-sharing of string literals, causes too many surprises with
> in-place string modifications.
> and therefor assumes that if I have a function like
> let foo x =
> "This is a string", x ;;
> will foo create a new string each time foo is called?
No, the string is still shared. What was removed in 3.02 is a
posteriori re-sharing of identical string literals in a compilation
unit. Consider:
let f () = "foo"
let g () = "foo"
In ocamlopt pre 3.02, we had f() == g(). Now, f() != g(). But we
still have f() == f().
> Assume that I know that no one will in-place edit the string, I could
> rewrite the code into the more efficient
>
> let str = "This is a string";;
> let foo x =
> str, x ;;
> and all calls to foo will get the same string.
No need to do this.
> If so, I wonder why not the standard strings of Ocaml are nonmutable?
> It works fine for languages like Visual Basic, and Visual Basic has
> great string performance compared to languages like C++.
If we were to start again from scratch, I'd consider immutable strings
seriously. Having mutable strings is handy when they are used as
character buffers, e.g. by low-level I/O functions. But I agree there
are advantages to distinguish (immutable) strings and (mutable)
character buffers.
- Xavier Leroy
Patrick M Doane
> If we were to start again from scratch, I'd consider immutable strings
> seriously. Having mutable strings is handy when they are used as
> character buffers, e.g. by low-level I/O functions. But I agree there
> are advantages to distinguish (immutable) strings and (mutable)
> character buffers.
In some situations, I've been able to simply make an immutable replacement
for the String module:
module String = struct
let length = String.length
let get = String.get
let create = String.create
let copy = String.copy
let sub = String.sub
(* .. *)
end
# let s = "foo";;
val s : string = "foo"
# s.[0];;
- : char = 'f'
# s.[0] <- 'g';;
Toplevel input:
# s.[0] <- 'g';;
^^^^^^^^^^^^
Unbound value String.set
This only works if all the strings in the current context are immutable
though.
Patrick
Brian Rogoff
> On Thu, 10 Jan 2002, Xavier Leroy wrote:
>
> > If we were to start again from scratch, I'd consider immutable strings
> > seriously. Having mutable strings is handy when they are used as
> > character buffers, e.g. by low-level I/O functions. But I agree there
> > are advantages to distinguish (immutable) strings and (mutable)
> > character buffers.
>
> In some situations, I've been able to simply make an immutable replacement
> for the String module:
>
> module String = struct
> (* .. *)
> end
Sure, that works, but I think if the Caml community really wants immutable
strings (and it seems that quite a few people do) it might make sense to
try some alternative implementations, like ropes. It was mentioned on
this list that some older version of Caml used ropes; maybe they could be
resurrected?
-- Brian
Christophe Raffalli
f(double,double,double)
without packing and unpacking the double when using the native code
compiler ?
In other word, is the unboxing optimization of floats available to
external C function ?
another question, I use C because I want dynamic linking with native
compilation (I want the dynamically loaded code to be native too). Is it
possible to implement that for OCaml ?
--
Christophe Raffalli
Université de Savoie
Batiment Le Chablais, bureau 21
73376 Le Bourget-du-Lac Cedex
tél: (33) 4 79 75 81 03
fax: (33) 4 79 75 87 42
mail: Christoph...@univ-savoie.fr
www: http://www.lama.univ-savoie.fr/~RAFFALLI
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.f=
r/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.in=
ria.fr
David Mentre
> another question, I use C because I want dynamic linking with native
> compilation (I want the dynamically loaded code to be native too). Is it
> possible to implement that for OCaml ?
Yes, look at the Asmdynlink module in the Hump.
Best regards,
david
--
david....@wanadoo.fr
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
David Mentre
> Christophe Raffalli <raff...@univ-savoie.fr> writes:
>
> > another question, I use C because I want dynamic linking with native
> > compilation (I want the dynamically loaded code to be native too). Is it
> > possible to implement that for OCaml ?
>
> Yes, look at the Asmdynlink module in the Hump.
Sorry, I overlocked asmdynlink description. Here are the (supposed)
correct answers:
dl-runtime: a patch for using primitives from shared libraries with OCaml 3.00
http://www.eleves.ens.fr:8080/home/frisch/soft#dl-runtime
SCaml : A patch, against OCaml 3.04, making it possible to: create,
link against and dynamically load shared objects on i386 ELF platforms.
http://algol.prosalg.no/~malc/scaml/
Best regards,
d.
Nicolas George
> Sure, that works, but I think if the Caml community really wants immuta=
ble
> strings (and it seems that quite a few people do) it might make sense t=
o
> try some alternative implementations, like ropes. It was mentioned on
be
> resurrected?
I second that. Something that would be really nice would be to have tail
recursive appends as efficient as with the Buffer module. And from the
syntactic viewpoint, a rule similar to the one that allow strings tokens
to be seen as format could be the solution to implement that.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.f=
r/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.in=
ria.fr
Mattias Waldau
However, as Xavier says, maybe it is a bit late.
We have another string problem, namely handling non-ascii. As I understand
it, one of the points of of nML (http://ropas.kaist.ac.kr/n/), with is a new
ML language currently built using Ocaml, is that it handles asian
characters. Also, their was an entry recently into this group about asian
characters codings.
I don't think any language can continue to be pure-ascii for ever. One of
the reason of Ruby's success is that it handles non-ascii (I think it is
made by an japanese). However, even we Swedes have problems, only 2 of our 3
special characters are in the lower 7 bits and sorting is always wrong.
A unicode char is between 1 and 4 bytes, that means that str[i] doesn't work
(unless you do as NT or Java, store it as wide chars internally, which of
course Ocaml could do too). You always have to start at the beginning of the
string to find the i:th char.
Thus, introducing Unicode strings (or something similar, I heard that Asians
don't like Unicode at all) and introducing non-mutable strings should
preferrable be done simultaneously.
In order to have 8-bit chars strings and unicode strings simultaneously we
need something like 'u"', and maybe the possibility to say that all strings
are unicode. Can this be done using a module just like 'open Float'
redefines '+' to '+.'?
Or should Ocaml v 4 go the whole way and let all strings (also identifiers)
be Unicode?
/mattias
P.s. Microsoft NT, 2000, XP handles double byte chars everywhere, it is
called BSTR and in order to make string comparasion etc library-routines are
called all the time. However, since Unicode can be 4 byte, I don't know how
that is encoded into 2 bytes.
YAMAGATA yoriyuki
Subject: RE: [Caml-list] Non-mutable strings
Date: Wed, 16 Jan 2002 20:22:36 +0100
> Thus, introducing Unicode strings (or something similar, I heard that Asians
> don't like Unicode at all) and introducing non-mutable strings should
> preferrable be done simultaneously.
There is criticism to Unicode (Most of them goes to Han-unification,
which integrates all regional variants of ideographics to a single set
of character), but as far as I know, it is the only international
character set in which the standard ways of string matching,
comparison and sorting are defined. Pattern matching is important to
caml, so I think using Unicode is preferable.
> P.s. Microsoft NT, 2000, XP handles double byte chars everywhere, it is
> called BSTR and in order to make string comparasion etc library-routines are
> called all the time. However, since Unicode can be 4 byte, I don't know how
> that is encoded into 2 bytes.
Unicode standard requires handling an unicode character as one or two
16bits integers. If a characters is longer than 2 bytes, it is
represented as a pair of surrogate points (specially aligned 16 bits
integers for this purpose.) Surrogate pairs can only represent 3
bytes character, so Unicode as its narrow sense can only be 3 bytes.
I don't know whether Windows supports surrogates, but since MS is one
of the founding members of Unicode consortium, they will be supported
in the future, any ways.
However, Unicode, as customary called, has another standard, ISO-UCS.
ISO-UCS allows that characters becomes 31-bits long, and ISO seems to
recommend that all characters are represented as 32-bits integers.
Clearly, ISO approaches are more simple and allows fast indexing. On
the other hand, Unicode is more widely used and provide better
algorithm for case mapping, character classification etc.
For caml, in my really humble opinion, the language had better to hide
such difference (16-bits or 32-bits) and if it can not be hidden (like
case mapping), offer choice to users.
Regards
--
YAMAGATA, yoriyuki (doctoral student)
Department of Mathematical Science, University of Tokyo.
Jerome Vouillon
> A unicode char is between 1 and 4 bytes, that means that str[i] doesn't=
work
> (unless you do as NT or Java, store it as wide chars internally, which =
of
> course Ocaml could do too). You always have to start at the beginning o=
f the
> string to find the i:th char.
Is this really a problem? It seems to me that you very rarely need
to do this.
NT uses internally the UTF-16 encoding, where a unicode character
takes either 2 or 4 bytes, so you cannot easily find the i-th
character either.
Java is broken and only support Unicode characters that fit in two
bytes.
> Thus, introducing Unicode strings (or something similar, I heard that A=
sians
> don't like Unicode at all) and introducing non-mutable strings should
> preferrable be done simultaneously.
Yes, Unicode support seems to be a good opportunity to introduce
non-mutable strings.
> In order to have 8-bit chars strings and unicode strings simultaneously=
we
> need something like 'u"', and maybe the possibility to say that all str=
ings
> are unicode. Can this be done using a module just like 'open Float'
> redefines '+' to '+.'?
>
> Or should Ocaml v 4 go the whole way and let all strings (also identifi=
ers)
> be Unicode?
We can go a long way without specific support from the language. In
my opinion, we should first write a good Unicode library and only then
start to think about language support.
-- Jérôme
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.f=
r/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.in=
ria.fr
Xavier Leroy
> f(double,double,double)
> without packing and unpacking the double when using the native code
> compiler ?
Yes. Declare it as follows:
external f : float -> float -> float -> float = "f_wrapper" "f" "float"
"f_wrapper" should be the standard C wrapper function that takes three
values, unpacks the doubles, call f, packs the result. This wrapper
will be called by the bytecode interpreter.
"f" is just the base C function taking unboxed doubles and returning a
double. It will be called directly by the code generated by ocamlopt.
The "float" declaration at the end instructs ocamlopt to perform (and
optimize!) the unboxing of the arguments and the boxing of the result
itself, rather than relying on "f" to do it.
> In other word, is the unboxing optimization of floats available to
> external C function ?
Yes. The standard library uses it for most of the floating-point
functions defined in Pervasives.
- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.inria.fr
David Monniaux
> The "float" declaration at the end instructs ocamlopt to perform (and
> optimize!) the unboxing of the arguments and the boxing of the result
> itself, rather than relying on "f" to do it.
There are several such declarations ("noalloc", "float"...). Are they
documented somewhere? Is browsing the source code of the standard library
the only way to know about them? :-)
Regards,
David Monniaux http://www.di.ens.fr/~monniaux
Laboratoire d'informatique de l'École Normale Supérieure,
Paris, France
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs FAQ: http://caml.inria.f=
r/FAQ/
To unsubscribe, mail caml-lis...@inria.fr Archives: http://caml.in=
ria.fr