ocaml-lib-devel — Developer's mailing list

[Ocaml-lib-devel] =?GB2312?B?1cXPyMn6?=

[<les...@16...>]

1/C+tLXEuPe5q8u+o6izp7zSo6nE+rrDo7oNCiAgICC7qrfhyrXStdPQz965q8u+yse+rbmkycy+
1teisuG1x7zHvK/KtdK10+vDs9LXzqrSu8zltPPQzdfbus/G89K1oaPP1tLyw7/Uwr34z+69z7bg
zeqzybK7wcvP+srbtu62yKGiz9bT0Lj3tdi499K1y7DGsb/J08W73bbUzeK0+sDto6zP6s+4y7DC
yr/JuPm+3b3wtu6089ChwLTJzMzWtePK/aGjuavLvrG+18W5y7/N1sHJz9fa1ryjrL/Jz8i/qr7f
y7DGsbj4ufO5q8u+o6y0/cnPzfjR6daku/K1vcuwzvG+1tHp1qS689TZuLa/7qOhDQogICAgyPS5
87mry76jqLOnvNKjqdTatMvP7tK1zvHJz9PQ0OjSqrvy09DSycLHtcS7ttOtwLS159fJ0a+jrLmy
yNm3otW5o6G08sjF1q60pqOsvrTH68HCveKjoQ0KwarPtcjLOtXFz8jJ+g0KwarPtbXnu7A6KDAp
MTM5IDI2NTMzIDEzOSAgIFFROjYwNTYwNjYxNg0KTVNOOnN6X2h1YWZlbmdAaG90bWFpbC5jb20g
DQpFLW1haWw6aHVhZmVuZzY4ODhAMTI2LmNvbQ==

Re: [Ocaml-lib-devel] Bug report

[Janne H. <jjh...@gm...>]

Hi Pascal,

Thanks for reporting the bug!  There's a fix for this in the CVS now.
I've also added your test case as a regression test in Extlib's
testing suite so that it doesn't resurrect itself in the future.

The bug indeed was in BitSet.enum.  I completely rewrote it.  The new
implementation is somewhat longer but IMO easier to read.

Old one (excuse my re-indentation):

let enum t =
  let rec make n =
    let cur = ref n in
    let rec next() =
      let pos = !cur lsr log_int_size and delta = !cur land int_size in
      if pos >= t.len then raise Enum.No_more_elements;
      let x = bget t.data pos in
      let rec loop i =
        if i = 8 then
          next()
        else if x land (1 lsl i) = 0 then begin
          incr cur;
          loop (i+1)
        end else
          !cur
      in
      let b = loop delta in
      incr cur;
      b
    in
    Enum.make
      ~next
      ~count:(fun () -> partial_count t !cur)
      ~clone:(fun () -> make !cur)
  in
  make 0

New one:

(* Find the first set bit in the bit array *)
let find_first_set b n =
  (* TODO there are many ways to speed this up.  Lookup table would be
     one way to speed this up. *)
  let find_lsb b =
    assert (b <> 0);
    let rec loop n =
      if b land (1 lsl n) <> 0 then n else loop (n+1) in
    loop 0 in

  let buf = b.data in
  let rec find_bit byte_ndx bit_offs =
    if byte_ndx >= b.len then
      None
    else
      let byte = (bget buf byte_ndx) lsr bit_offs in
      if byte = 0 then
        find_bit (byte_ndx + 1) 0
      else
        Some ((find_lsb byte) + (byte_ndx lsl log_int_size) + bit_offs) in
  find_bit (n lsr log_int_size) (n land int_size)

let enum t =
  let rec make n =
    let cur = ref n in
    let rec next () =
      match find_first_set t !cur with
        Some elem ->
          cur := (elem+1);
          elem
      | None ->
          raise Enum.No_more_elements in
    Enum.make
      ~next
      ~count:(fun () -> partial_count t !cur)
      ~clone:(fun () -> make !cur)
  in
  make 0

Performance of the new implementation should be pretty much the same
speed as the old one.

Janne

On 2/26/07, Pascal Zimmer <pas...@gm...> wrote:
> I think this does qualify as a bug:
>
> # let b = BitSet.empty ();;
> val b : BitSet.t = <abstr>
> # BitSet.set b 8;;
> - : unit = ()
> # BitSet.set b 9;;
> - : unit = ()
> # let e = BitSet.enum b;;
> val e : int Enum.t = <abstr>
> # Enum.get e;;
> - : int option = Some 8
> # Enum.get e;;
> - : int option = None
>
> It seems to get triggered when consecutive numbers are stored and
> retrieved from the bitset, although not every pair of numbers works. I
> did not look into the details of BitSet.enum, but the bug is likely to
> be there.
>
> Pascal
>
> -------------------------------------------------------------------------
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
> _______________________________________________
> ocaml-lib-devel mailing list
> oca...@li...
> https://lists.sourceforge.net/lists/listinfo/ocaml-lib-devel
>

[Ocaml-lib-devel] Bug report

[Pascal Z. <pas...@gm...>]

I think this does qualify as a bug:

# let b = BitSet.empty ();;
val b : BitSet.t = <abstr>
# BitSet.set b 8;;
- : unit = ()
# BitSet.set b 9;;
- : unit = ()
# let e = BitSet.enum b;;
val e : int Enum.t = <abstr>
# Enum.get e;;
- : int option = Some 8
# Enum.get e;;
- : int option = None

It seems to get triggered when consecutive numbers are stored and 
retrieved from the bitset, although not every pair of numbers works. I 
did not look into the details of BitSet.enum, but the bug is likely to 
be there.

Pascal

Re: [Ocaml-lib-devel] Feature request: ?cmp parameter for PMap.find

[Martin J. <mar...@em...>]

On Fri, 17 Nov 2006, Denis Bueno wrote:

> On 11/17/06, Martin Jambon <mar...@em...> wrote:
> > Maybe I am missing something, but you already give a comparison function
> > when you create the map (PMap.create). This is where you would pass your
> > custom comparison function rather than Pervasives.compare. You can't
> > change it later.
>
> I have never used that function. I always insert elements into
> existing maps, starting with a PMap.empty.

Well, start with (PMap.create your_compare) then.


Martin

--
Martin Jambon, PhD
http://martin.jambon.free.fr

Re: [Ocaml-lib-devel] Feature request: ?cmp parameter for PMap.find

[Denis B. <db...@gm...>]

On 11/17/06, Martin Jambon <mar...@em...> wrote:
> Maybe I am missing something, but you already give a comparison function
> when you create the map (PMap.create). This is where you would pass your
> custom comparison function rather than Pervasives.compare. You can't
> change it later.

I have never used that function. I always insert elements into
existing maps, starting with a PMap.empty.

-Denis

Re: [Ocaml-lib-devel] Feature request: ?cmp parameter for PMap.find

[Martin J. <mar...@em...>]

On Thu, 16 Nov 2006, Denis Bueno wrote:

> Would it be possible to have PMap.find take an optional comparison
> parameter? I was just using PMap in some OCaml code and discovered
> that, since my keys contain Big_int.big_ints, I need to have a custom
> comparator for the one find that I do. It would have been nice to have
> that feature built-in.

Maybe I am missing something, but you already give a comparison function
when you create the map (PMap.create). This is where you would pass your
custom comparison function rather than Pervasives.compare. You can't
change it later.


Martin

--
Martin Jambon, PhD
http://martin.jambon.free.fr

Re: [Ocaml-lib-devel] Feature request: ?cmp parameter for PMap.find

[Brian H. <bh...@sp...>]

On Thu, 16 Nov 2006, Denis Bueno wrote:

> Would it be possible to have PMap.find take an optional comparison
> parameter? I was just using PMap in some OCaml code and discovered
> that, since my keys contain Big_int.big_ints, I need to have a custom
> comparator for the one find that I do. It would have been nice to have
> that feature built-in.

In this case, why not just use the standard library map?

Brian

[Ocaml-lib-devel] Feature request: ?cmp parameter for PMap.find

[Denis B. <db...@gm...>]

Would it be possible to have PMap.find take an optional comparison
parameter? I was just using PMap in some OCaml code and discovered
that, since my keys contain Big_int.big_ints, I need to have a custom
comparator for the one find that I do. It would have been nice to have
that feature built-in.

-Denis

[Ocaml-lib-devel] ppc package script

[Pietro A. <Pie...@an...>]

Hi all,

I've modified the script used to generate the ocaml max package to
generate a macosx package for extlib. It should play well with the pkg
from the inria website. I've also done something similar for findlib and
I'm going to submit the patch very soon. Can we include this script in
the distribution ? It's very mac specific, I know, but I would be handy
to have it there... 

Asking to provide the mac binary package from sourceforge would be too
much, uh ?

I'm not a mac user ... so if you have a mac around (with developer tools
installed) have a play with it... It requires findlib to be installed as
I piggyback onto the makefile written by AF.

patch is attached.

:)
p

-- 
++ Blog: http://blog.rsise.anu.edu.au/?q=pietro
++ 
++ "All great truths begin as blasphemies." -George Bernard Shaw
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Ocaml-lib-devel] Proposal: ExtArray.Array.iter

[<sp...@sc...>]

Bárður Árantsson wrote:
> Denis Bueno wrote:
>> I've been building a compiler front-end (lex -> parse -> IR) in OCaml
>> and frequently have to make use of List.iter2 --- and I find it
>> annoying that there is no counterpart for arrays. Hasn't anyone needed
>> this before?
>>
>> It's not hard to write. In fact, even better, it's written [1]. I'll
>> spruce it up if it doesn't meet the ExtLib standards.
>>
>> -Denis
>>
>> [1]
>>   (** Like {!List.iter2}, but for arrays.
>>
>>       @raise Invalid_argument if the length of [a1] does not equal the
>> length of [a2]. *)
>>   let iter2 f a1 a2 =
>>     if Array.length a1 <> Array.length a2
>>     then raise (Invalid_argument "Array.iter2");
>>
>>     for i = 0 to Array.length a1 do
>                     ^^^^^^^^^^^^^^^
> 
> That's missing a -1, isn't it? (I never use for loops :))
> 
>>       f a1.(i) a2.(i);
>>     done;;
>>
> 
> Apart from that this looks fine, and I think it's relevant.  (I haven't 
> ever needed it, but more uniformity among the standard data structure 
> modules is good as far as I'm concerned).
> 
> I'll add it to CVS if there are no objections.
> 

Added to CVS w/the above fix and a more explicit documentation comment.

Cheers,

-- 
Bardur Arantsson
<bar...@TH...>

If you don't believe in Jesus, then just try to move your little
finger.
                                      Iasson @ http://kuro5hin.org

Re: [Ocaml-lib-devel] Proposal: ExtArray.Array.iter

[<sp...@sc...>]

Denis Bueno wrote:
> I've been building a compiler front-end (lex -> parse -> IR) in OCaml
> and frequently have to make use of List.iter2 --- and I find it
> annoying that there is no counterpart for arrays. Hasn't anyone needed
> this before?
> 
> It's not hard to write. In fact, even better, it's written [1]. I'll
> spruce it up if it doesn't meet the ExtLib standards.
> 
> -Denis
> 
> [1]
>   (** Like {!List.iter2}, but for arrays.
> 
>       @raise Invalid_argument if the length of [a1] does not equal the
> length of [a2]. *)
>   let iter2 f a1 a2 =
>     if Array.length a1 <> Array.length a2
>     then raise (Invalid_argument "Array.iter2");
> 
>     for i = 0 to Array.length a1 do
                    ^^^^^^^^^^^^^^^

That's missing a -1, isn't it? (I never use for loops :))

>       f a1.(i) a2.(i);
>     done;;
> 

Apart from that this looks fine, and I think it's relevant.  (I haven't 
ever needed it, but more uniformity among the standard data structure 
modules is good as far as I'm concerned).

I'll add it to CVS if there are no objections.

-- 
Bardur Arantsson
<bar...@TH...>

- Do you take sugar?
- No, thank you, Turkish. I'm sweet enough.
                                    Turkish and Brick Top / Snatch

Re: [Ocaml-lib-devel] Timeout function.

[Bruno De F. <Bru...@vu...>]

Hello,

On 05 Oct 2006, at 17:50, Koprowski, A. wrote:
>   Any ideas how to fix that? Or maybe there is a simpler solution  
> to my goal?
Have you considered the Unix signal sigalrm?
See: http://alan.petitepomme.net/cwn/2006.01.03.html#2

Best,
Bruno

-- 
Bruno De Fraine
Vrije Universiteit Brussel
Faculty of Applied Sciences, INFO - SSEL
Room 4K208, Pleinlaan 2, B-1050 Brussels
tel: +32 (0)2 629 29 75
fax: +32 (0)2 629 28 70
e-mail: Bru...@vu...

[Ocaml-lib-devel] Timeout function.

[Koprowski, A. <A.K...@tu...>]

  Hello everybody,

 I'm seeking some help. I'd like to write a function:

val timeout: fn: (unit -> 'a) -> tout: float -> 'a option

 such that 'timeout' will try evaluate the 'fn' function and outputs:

-) 'Some res', if the evaluation of 'fn' was finished before 'tout'
seconds (note that 'fn' should be able to start other threads or use the
'Unix.system' call), or

-) None, if the evaluation took more than 'tout' second (in which case
it should be stopped at that point).

  Now I had the idea that it should be pretty simple to write it using
Ocaml threads library by simply starting two threads: one that will
simply wait for 'tout' seconds and then communicate (using Events
library) the fact that the timeout has occurred and the other one that
will evaluate the 'fn' function and communicate back its results. The
problem is that upon receiving result from one of the threads the other
one should be terminated. At that point I discovered, to my
disappointment, that if try to use the 'Threads.kill' routine I get an
exception informing that it's not implemented. Now, letting the clock
thread continue is acceptable but the computation expensive thread
struggling with 'fn' function should absolutely stop after the timeout.=20

  Any ideas how to fix that? Or maybe there is a simpler solution to my
goal?=20

  Would such function be interesting for ExtLib?

=20

    Thank you in advance for any help,

     Adam Koprowski

=20

--

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

 Adam Koprowski, (A.K...@tu..., http://www.win.tue.nl/~akoprows)

 Department of Mathematics and Computer Science

 Eindhoven University of Technology (TU/e)

 The difference between impossible and possible lies in determination

      Tommy Lasorda=20

=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=
=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D

=20

=20

[Ocaml-lib-devel] Proposal: ExtArray.Array.iter

[Denis B. <db...@gm...>]

I've been building a compiler front-end (lex -> parse -> IR) in OCaml
and frequently have to make use of List.iter2 --- and I find it
annoying that there is no counterpart for arrays. Hasn't anyone needed
this before?

It's not hard to write. In fact, even better, it's written [1]. I'll
spruce it up if it doesn't meet the ExtLib standards.

-Denis

[1]
  (** Like {!List.iter2}, but for arrays.

      @raise Invalid_argument if the length of [a1] does not equal the
length of [a2]. *)
  let iter2 f a1 a2 =
    if Array.length a1 <> Array.length a2
    then raise (Invalid_argument "Array.iter2");

    for i = 0 to Array.length a1 do
      f a1.(i) a2.(i);
    done;;

Re: [Ocaml-lib-devel] Proposal: List.map_reduce

[Florian H. <ha...@bi...>]

B=E1r=F0ur =C1rantsson wrote:
> Google seems to like the name ;)

You might also want to look at this:

http://lambda-the-ultimate.org/node/1669

Yours, Florian

Re: [Ocaml-lib-devel] Proposal: List.map_reduce

[<sp...@sc...>]

Jonathan Roewen wrote:
>> fold_reduce? Do you mean fold? If not, then what does the fold_reduce
>> you're thinking of look like?
> 
> Oops, sorry. fold is reduce :-) And I meant no, I don't think it's too
> specialised.
> 

Ah, ok.

> I'm not sure about the name, as it's a fold that filters & maps
> elements in a single step.

Google seems to like the name ;)

    http://labs.google.com/papers/mapreduce.html

Well, alright, it's not _exactly_ the same thing...

> 
> And in terms of readability and thinking about it some more, I don't
> see why something like the following aren't suitable:
> 
> let a_total = List.fold_left (fun acc -> function `A x -> acc + x | _
> -> acc) 0 list;;
> let c_max = List.fold_left (fun acc -> function `C x -> max acc x | _
> -> acc) min_int list;;
> let b = List.fold_left (fun acc -> function `B x -> acc || x | _ ->
> acc) false list;;
> 
> They all convey exactly what they're trying to achieve. Perhaps there

To me this seems like "overspecifying the solution" since fold_left 
_must_ by definition work in a particular way, and you're also 
(implicitly) specifying the associativity of the operator, you have an 
explicit accumulator adding noise, etc. I wanted the "map_reduce" name 
to convey that I don't _care_ how the solution is arrived at, I just 
want the solution ;)

In particular, when reading the code above the reader may think that it 
is crucial that the operations happen in exactly the right order when it 
actually doesn't. (Of course, I'm generalizing to complex operators and 
mapping functions since pretty much everyone knows the properties of || 
and max)

> are more complicated cases in real life programming, but imo, I think
> they're a little nicer, and probably more efficient than your
> implementation.
> 
>> There is also precedent
>> for this kind of thing -- see ExtList.filter_map.
> 
> I think this is different, as the naive approach of filtering, then
> mapping can be considerably slower than combining the two.

That's true.

-- 
Bardur Arantsson
<bar...@TH...>

- Women... can't live with 'em... can't shoot 'em.
                                  Al Bundy / Married With Children

Re: [Ocaml-lib-devel] Proposal: List.map_reduce

[Jonathan R. <jon...@gm...>]

> fold_reduce? Do you mean fold? If not, then what does the fold_reduce
> you're thinking of look like?

Oops, sorry. fold is reduce :-) And I meant no, I don't think it's too
specialised.

I'm not sure about the name, as it's a fold that filters & maps
elements in a single step.

And in terms of readability and thinking about it some more, I don't
see why something like the following aren't suitable:

let a_total = List.fold_left (fun acc -> function `A x -> acc + x | _
-> acc) 0 list;;
let c_max = List.fold_left (fun acc -> function `C x -> max acc x | _
-> acc) min_int list;;
let b = List.fold_left (fun acc -> function `B x -> acc || x | _ ->
acc) false list;;

They all convey exactly what they're trying to achieve. Perhaps there
are more complicated cases in real life programming, but imo, I think
they're a little nicer, and probably more efficient than your
implementation.

> There is also precedent
> for this kind of thing -- see ExtList.filter_map.

I think this is different, as the naive approach of filtering, then
mapping can be considerably slower than combining the two.

Jonathan

Re: [Ocaml-lib-devel] Proposal: List.map_reduce

[<sp...@sc...>]

Jonathan Roewen wrote:
>> Do you think this should be added to ExtLib.ExtList, or is it too
>> "specialized"?
> 
> I don't think so. fold_reduce is a more general case of map_reduce.
> 

fold_reduce? Do you mean fold? If not, then what does the fold_reduce 
you're thinking of look like?

Anyway, I'm well aware that the reduce is a just special case of fold 
(where you assume that the folded function is "fully associative" by not 
specifying a fold "direction"). That's not the point, though.

The point is that combining the map with a reduce you get lighter syntax 
all the _usage sites_ where you can use the idiom and that it is 
slightly better efficiency-wise for huge lists. There is also precedent 
for this kind of thing -- see ExtList.filter_map.

Cheers,

-- 
Bardur Arantsson
<bar...@TH...>

Absolutely no one can sex a lobster without cutting it open.
                                       rusty @ http://kuro5hin.org

Re: [Ocaml-lib-devel] Proposal: List.map_reduce

[Jonathan R. <jon...@gm...>]

> Do you think this should be added to ExtLib.ExtList, or is it too
> "specialized"?

I don't think so. fold_reduce is a more general case of map_reduce.

Jonathan

[Ocaml-lib-devel] Proposal: List.map_reduce

[<sp...@sc...>]

Hi all,

I found myself working with lists containing polymorphic variants, and 
I've found the following simple function very useful for improving the 
readability of my code (examples are in revised syntax since I've 
forgotten the "old" syntax):

    value map_reduce op zero map_f list =
       (List.fold_left op zero (List.filter_map map_f list));

This may of course be defined slightly more efficiently as

   value map_reduce op zero map_f list =
         (List.fold_left
            (fun acc av ->
               (match map_f av with
                  [ Some x -> op acc x
                  | None -> acc ]))
            zero
            list);

which avoids the creation of a temporary list.

Here's an example of usage: Let's say I have a polymorphic variant

	type t = [= `A of int | `B of bool | `C of int ]

and I have a list containing values of type t, say

         lst = [ `A 5 ; `A 2 ; `B false ; `B true ; `C 3 ]

and I want to extract and combine the values of the different variant 
values in different ways. Using both fold_left and filter_map this looks 
like

   let a_total = List.fold_left (\+) 0
  	(List.filter_map (fun [ `A x -> Some x | _ -> None ]) lst);
   let c_max = List.fold_left max 0
	(List.filter_map (fun [ `A x -> Some x | _ -> None ]) lst);
   let b = List.fold_left (\||) False
         (List.filter_map (fun [ `B x -> Some x | _ -> None ]) lst);

With map_reduce this becomes

   let a_total =
	map_reduce (\+) 0 (fun [ `A x -> Some x | _ -> None ]) lst;
   let c_max =
	map_reduce max 0 (fun [ `A x -> Some x | _ -> None ]) lst;
   let b =
	map_reduce (\||) False (fun [ `B x -> Some x | _ -> None ]) lst;

which I think is more readable since it removes noise (the extra 
parantheses and the "superfluous" call to a second function). If you 
want to get rid of the temporary list creations the version without 
map_reduce of course gets much, much uglier.

Do you think this should be added to ExtLib.ExtList, or is it too 
"specialized"?

-- 
Bardur Arantsson
<bar...@TH...>

There is no truth, only facts to be manipulated.
                                S.E. Corff, NSA Collection Manager

Re: [Ocaml-lib-devel] [Ocaml-i18n] ExtLib UTF8 not compatible with Camomile

[Richard J. <ri...@an...>]

On Thu, Aug 17, 2006 at 07:29:18AM +0900, Yoriyuki Yamagata wrote:
> I'm not sure what is your problem.  All Camomile modules are packed,
> so there should not be a name space issue.  (The versions < 0.7.0
> installed suprious cmi like UTF8.cmi.  This problem is fixed in 0.7.0)

Right, thanks, I've got it now.

I was using a somewhat archaic version of Camomile.  The version
installed by Ubuntu is 0.6.3 (< 0.7.0).

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

Re: [Ocaml-lib-devel] ExtLib UTF8 not compatible with Camomile

[Richard J. <ri...@an...>]

On Wed, Aug 16, 2006 at 09:24:21PM +0100, Peter Jolly wrote:
> I don't think there's any need to rename it, with all the consequent
> breakage of existing code; there's no namespace clash since (by default)
> Camomile's module is called Camomile.UTF8, not just UTF8, and it _is_
> supposed to emulate Camomile's module!  :)

Do I need to do something special to get this "packed" version of
Camomile?  Here is the error I'm experiencing:

$ ocaml -I +camomile -I +extlib
        Objective Caml version 3.09.1

# #load "unix.cma";;
# #load "bigarray.cma";;
# #load "extLib.cma";;
# #load "camomile.cma";;
# UTF8.first;;
The files /usr/lib/ocaml/3.09.1/extlib/extLib.cma
and /usr/lib/ocaml/3.09.1/camomile/uTF8.cmi make inconsistent assumptions
over interface UTF8

Rich.

-- 
Richard Jones, CTO Merjis Ltd.
Merjis - web marketing and technology - http://merjis.com
Team Notepad - intranets and extranets for business - http://team-notepad.com

[Ocaml-lib-devel] [Ocaml-i18n] ExtLib UTF8 not compatible with Camomile

[Yoriyuki Y. <yor...@gm...>]

(This is a repost, since I sent from the wrong address. Apologies if you
receive duplicated messages.)

Hi,

2006/8/17, Richard W.M. Jones <ri...@me...>:
> > I'm then against removing it from ExtLib. What are the compatibility
> > problem ? I think they can be addressed without causing a lot of
> > worries.
>
> The different, btw, is that my Camomile UTF8 contains UTF8.first
> function, which is not in Extlib UTF8.

I'm not sure what is your problem.  All Camomile modules are packed,
so there should not be a name space issue.  (The versions < 0.7.0
installed suprious cmi like UTF8.cmi.  This problem is fixed in 0.7.0)

UTF8.first doesn't make sense in Extlib context, since it always
returns 0.  It makes sense in Camomile context, however, since there
are other Unicode string types.
--
Yamagata Yoriyuki
http://yoriyuki.blogspot.com/


-- 
Yamagata Yoriyuki
http://yoriyuki.blogspot.com/

Re: [Ocaml-lib-devel] [Ocaml-i18n] ExtLib UTF8 not compatible with Camomile

[Yoriyuki Y. <yor...@gm...>]

Hi,

2006/8/17, Richard W.M. Jones <ri...@me...>:
> > I'm then against removing it from ExtLib. What are the compatibility
> > problem ? I think they can be addressed without causing a lot of
> > worries.
>
> The different, btw, is that my Camomile UTF8 contains UTF8.first
> function, which is not in Extlib UTF8.

I'm not sure what is your problem.  All Camomile modules are packed,
so there should not be a name space issue.  (The versions < 0.7.0
installed suprious cmi like UTF8.cmi.  This problem is fixed in 0.7.0)

UTF8.first doesn't make sense in Extlib context, since it always
returns 0.  It makes sense in Camomile context, however, since there
are other Unicode string types.
-- 
Yamagata Yoriyuki
http://yoriyuki.blogspot.com/

Re: [Ocaml-lib-devel] ExtLib UTF8 not compatible with Camomile

[Bardur A. <sp...@sc...>]

Peter Jolly wrote:
> Bardur Arantsson wrote:
>> Could we simply rename the UTF8 module to something like SimpleUTF8 to 
>> avoid confusion about whether it's supposed to 'emulate' Camomile's UTF8 
>> module?
> 
> I don't think there's any need to rename it, with all the consequent
> breakage of existing code; there's no namespace clash since (by default)
> Camomile's module is called Camomile.UTF8, not just UTF8, and it _is_
> supposed to emulate Camomile's module!  :)
> 

Fair enough. I honestly didn't know. :)

> Note that this incompatibility between ExtLib and Camomile's interfaces
> has not been caused by a recent change; if I'm reading the CVS logs
> correctly, Camomile.UTF8.first was added some two years ago, and the
> Camomile.UTF8 interface has not changed at all since then.  Keeping the
> two modules synchronised (or, more precisely, keeping ExtLib's UTF8
> module signature compatible with Camomile.UnicodeString.Type) should not
> be problematic now that it has been identified as a desirable thing.
> 

... but that would require a new release of ExtLib. (Hint hint ;)

-- 
Bardur Arantsson
<bar...@TH...>

- Morbo will now introduce our candidates: puny human number one,
puny human number two, and Morbo's good friend Richard Nixon.
                                                 Morbo, 'Futurama'