ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

> > UTF-8 support should be there, and should be driven from the LANG /
> > LC_* / locale.  It's a non-trivial amount of work to get this to work
> > of course.
>
> I could contribute this.  I have working code for Camomile.  But, it
> requires small C code to call ISO-C functions.  What do you think,
> N(i)colas?

That's little troublesome.
Even if we have only one C little file, the installation, compilation --- 
for a lot of different kind of systems --- is troublesome.
Oh ! just's got a good idea.
If we have to add a C part, then what we should do is a C emulator.
How does it works ?
- it's a C program that can resolve and call dynlinked C functions
- it can also manipulate basic C data structures (convert from and to OCaml
data, and also "raw" access , a little like Obj module)
- it can alloc and free some C memory
Then when we need to add some C parts, we just need to write some Caml code
that will use Emu-C, and which will handle the system particularities... at
runtime.

exemple (far from being correct, just give an idea) :

let strstr = EmuC.resolve "libc" "strstr" in
let found = EmuC.call strstr ["my_string";"_s"] in
if found = EmuC.null then
    None
else
    Some (EmuC.alloc_string found)

> Windows (proper) supports all ISO-C functions?  and (for the future
> reference) how about strcol?

I don't know about that. There is strcoll ANSI compatible function. ( and
wcscoll for Unicode strings )

> In addition, I'm thinking of UTF-16 support (for Windows and Java)  A
> major problem is lack of 16-bit interger array in OCaml.  We could use
> a string and do type-cast when it is passed to C functions.  This
> would  involve detecting endianness in installtion time and providing
> some C-macros.
>
> Alternatively, we could use Bigarray, but Bigarray is not efficient.
>
> I'm interested in other people's opinions.

Use (future) EmuC :-)

let block = EmuC.alloc size in
and then EmuC.setw / EmuC.getw to access 16-bits values into block.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

[Yamagata Y. <yor...@mb...>]

From: Richard Jones <ri...@an...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 10:20:16 +0000

> UTF-8 support should be there, and should be driven from the LANG /
> LC_* / locale.  It's a non-trivial amount of work to get this to work
> of course.

I could contribute this.  I have working code for Camomile.  But, it
requires small C code to call ISO-C functions.  What do you think,
Nocolas?

Windows (proper) supports all ISO-C functions?  and (for the future
reference) how about strcol?

In addition, I'm thinking of UTF-16 support (for Windows and Java)  A
major problem is lack of 16-bit interger array in OCaml.  We could use
a string and do type-cast when it is passed to C functions.  This
would  involve detecting endianness in installtion time and providing
some C-macros.

Alternatively, we could use Bigarray, but Bigarray is not efficient.

I'm interested in other people's opinions.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Future of ExtLib

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 11:15:45 +0100

> Shawn Wagner actually have a library known has ExtLib.
> He contacted me directly when we first released "our" ExtLib in order to ask
> if we were planing to change the name. I answered no. The reason was that :
> - no announcement of his library have been made on the official caml list
> - it was not registered in the Humps
> The first info I found concerning Shawn ExtLib was on 6 Jul 2003, at this
> time we were actively working to release 1.0.
> I'm not sure that the first released hold the name (or tomorrow I'll feel
> like releasing some "Longhorn" software !-)
> IMHO, there is nothing to change, having a name conflict is okay as long as
> the people can make the difference, and I think we have more user than other
> Extlib. But if most of people here agree to change the name, then let's do
> so...

OK.  I follow your decision.  However, there is still issue of name
collision of modules.  I'd like to propose doing optionally -pack the
module for a name chosen by a user.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] Future of ExtLib

[Yamagata Y. <yor...@mb...>]

From: "Nicolas Cannasse" <war...@fr...>
Subject: Re: [Ocaml-lib-devel] Future of ExtLib
Date: Sat, 20 Mar 2004 11:20:18 +0100

> It's not an easy jump, and I'm little concerned
> about the problems that extlib incompabilities (such as different exception
> policy) will show in 3rd party librairies that the user will not be able to
> modify in order to use with ExtLib...

Perhaps many people would want to stay with old stdlib because of
the stability issue, and just because it is easier.

Concerning libraries, I want my library depend to Extlib.  But if a
user have to switch to new stdlib just for using my library, then I
feel it is too much to ask.

> Concerning diet set/map, I'm not sure I understand for what kind of general
> purpose they're useful ?

Diet uses less memory for sets which contain large intervals, but I
agree that it may not be especially useful for the general use.

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] BitSet

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

On Sat, 20 Mar 2004, Nicolas Cannasse wrote:

> GMP is C, ExtLib is OCaml
> If you want to provide a 3rd party library having very efficient bitsets and
> big ints based on GMP, then I think it's nice idea. But since we agreed in
> the beginning that ExtLib will not have C parts (since with that comes a lot
> of compability, compilation, and installation problems) then I can't see
> that being put into ExtLib. Current bitsets are useful and enough efficient
> for the average user.
> 

A point I had forgotten- my apologies.

Also, thinking on it for a bit, gmp has development problems on Windows- 
I'm unsure of how well it plays with Microsoft's compiler.

You're right- it belongs in it's own optional library.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Re: [Ocaml-lib-devel] BitSet

[Prakash C. <Pra...@im...>]

Nicolas Cannasse wrote:
> Thanks,

You're welcome :)

> The CVS have been updated with your changes. To answer more precisely
> to your questions :
> - we could actualy use ints as 16 bits values if we add the API to 
> extract them from strings, but we don't :)

Why not to add this API ? It might also be useful in to improve other 
data structures. And why only 16 bits and not 32 ?

> - I disabled the "deprecated" on "clone", having both copy and clone
> is okay.

Doesn't matter, it was only a suggestion to avoid too much duplicate 
functions.

> - we can't use Pervasives.compare because bitsets might be of
> different sizes but are actually the same integer

I didn't want to say that Pervasives.compare should be used directly. I 
suggested something like that :

(************************************************************)
let extend t old_size new_size =
   let b = bcreate new_size in
   bblit !t 0 b 0 old_size;
   bfill b old_size (new_size - old_size) 0;
   b

let compare t1 t2 =
   let size1 , size2 = blen !t1 , blen !t2 in
   if size1 < size2 then
     Pervasives.compare (extend t1 size1 size2) !t2
   else if size1 > size2 then
     Pervasives.compare !t1 (extend t2 size2 size1)
   else
     Pervasives.compare !t1 !t2
(************************************************************)

And the function 'extend' can be used in both 'set' and 'toggle' :

(************************************************************)
let set t x =
   if x < 0 then error "set";
   let pos , delta = x lsr log_int_size , x land int_size in
   let size = blen !t in
   if pos >= size then t := extend t size (pos+1);
   bset !t pos ((bget !t pos) lor (1 lsl delta))

let toggle t x =
   if x < 0 then error "toggle";
   let pos , delta = x lsr log_int_size , x land int_size in
   let size = blen !t in
   if pos >= size then t := extend t size (pos+1);
   bset !t pos ((bget !t pos) lxor (1 lsl delta))
(************************************************************)


Bye,

-- 
Prakash

Re: [Ocaml-lib-devel] BitSet

[Nicolas C. <war...@fr...>]

> > Concerning the usage of int, OCaml runtime representation is 31 bits.
They
> > are unboxed and shifted by 1 and the lowest bit is set to 1 so it can't
be
> > mistaken with an address since all addresses are always aligned on 2
bytes
> > (even 4 on most of 32-bits architectures) . So we could use ints as 31
bits
> > but we would then need to div/mod to get the correct integer. Another
nice
> > thing about strings is that their contents are not scanned by the GC
while
> > Array of ints are.
> >
>
> Having looked at implementing bitset myself, I came to the following
> conclusions:
>
> 1) bitset and big int support should be combined, much like an int can be
> viewed both as a small integer and as a small bitset, depending.
>
> 2) Both should be built on top of gmp.
>
> 3) GMP doesn't do everything I want bitset to be able to do yet.  Most
> everything, but not everything (bitblit doesn't exist).
>
> 4) I'm on-again off-again trying to get gmp to accept patches to let it
> do what I want it to, but I'm getting push-back.
>
> I'm tempted to just provide the wrappers for the existing gmp
> functionality, and support the rest when it shows up.  Thoughts?

GMP is C, ExtLib is OCaml
If you want to provide a 3rd party library having very efficient bitsets and
big ints based on GMP, then I think it's nice idea. But since we agreed in
the beginning that ExtLib will not have C parts (since with that comes a lot
of compability, compilation, and installation problems) then I can't see
that being put into ExtLib. Current bitsets are useful and enough efficient
for the average user.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

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

On Fri, Mar 19, 2004 at 01:37:14PM -0600, Brian Hurt wrote:
> 1) Unicode or no unicode?  It's not that converting to/from unicode into 
> one of the utf- formats is so hard, it's just that now a stream of 
> characters is a different concept than a stream of bytes, with different 
> filters working on different types streams.  And a conversion object stuck 
> in between.  All pipes would now be at least three objects deep 
> (formatter, unicode conversion, source/sink), instead of just two.

UTF-8 support should be there, and should be driven from the LANG /
LC_* / locale.  It's a non-trivial amount of work to get this to work
of course.

Rich.

-- 
Richard Jones. http://www.annexia.org/ http://www.j-london.com/
Merjis Ltd. http://www.merjis.com/ - improving website return on investment
PTHRLIB is a library for writing small, efficient and fast servers in C.
HTTP, CGI, DBI, lightweight threads: http://www.annexia.org/freeware/pthrlib/

Re: [Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

> I'm not clear about what you want to do.  But if you mean, say, we
> provide List module in extlib, so that override List of the stdlib,
> then I think it is definitely a bad idea. In addition to forcing to
> use the new stdlib in order to access some module in extlib, it will
> cause incomprehensive "inconsistent assumption" error if modules using
> old stdlib and using new stdlib are mixed up.  If we use -pack option,
> then the change would be more bearable, but I prefer to split extlib
> to several packages, one for replacing stdlib, another for providing
> new features.  Maybe we could split the packages for their purpose,
> like providing new data structure, I/O, etc, too.

I don't agree on this "inconsistent assumption" since the user, when
actually "switching" to ExtLib, will only have to compile its codebase using
ExtLib instead of stdlib. It's not an easy jump, and I'm little concerned
about the problems that extlib incompabilities (such as different exception
policy) will show in 3rd party librairies that the user will not be able to
modify in order to use with ExtLib...

> > Concerning additionnals modules here's what's on my wish-list (which is
> > somehow also on my current todo-list) :
> > - base64 encode/decode
> > - abstract high level I/O with support for C basic types ( read_i16 ,
> > write_f16 ..... )
> > - zlib deflate/inflate written in pure OCaml.
>
> Do you interested in diet set and map? (set and map over integer,
> internally represented as sets and maps over intervals.)  I could
> contribute them.  Also, I'd like to change install.ml so that it
> ignores findlib if the destination directory is explicitly given by
> the arguments.

Don't hesitate to change install.ml.
Concerning diet set/map, I'm not sure I understand for what kind of general
purpose they're useful ?

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

> Before anything, I'd like to mention the recent exchange about another
> "extlib" in the caml-list and others.  I'm little embarrassed in the
> current situation.  If I remember correctly, another "extlib" is older
> than ours, so, in my opinion, we have to change the name.  Whatever
> reasons there are, we have to give a due credit to the previous work.
> If we are going to change the nature of our library, then it is a good
> opportunity to change the name.

I'll answer this one separatly.
Shawn Wagner actually have a library known has ExtLib.
He contacted me directly when we first released "our" ExtLib in order to ask
if we were planing to change the name. I answered no. The reason was that :
- no announcement of his library have been made on the official caml list
- it was not registered in the Humps
The first info I found concerning Shawn ExtLib was on 6 Jul 2003, at this
time we were actively working to release 1.0.
I'm not sure that the first released hold the name (or tomorrow I'll feel
like releasing some "Longhorn" software !-)
IMHO, there is nothing to change, having a name conflict is okay as long as
the people can make the difference, and I think we have more user than other
Extlib. But if most of people here agree to change the name, then let's do
so...

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

[<syl...@po...>]

Hello,

On Sat, Mar 20, 2004 at 12:33:07PM +0900, Yamagata Yoriyuki wrote:
> Before anything, I'd like to mention the recent exchange about another
> "extlib" in the caml-list and others.  I'm little embarrassed in the
> current situation.  If I remember correctly, another "extlib" is older
> than ours, so, in my opinion, we have to change the name.  Whatever
> reasons there are, we have to give a due credit to the previous work.
> If we are going to change the nature of our library, then it is a good
> opportunity to change the name.
> 

I don't agree with your point of view. The so called "older" version of
extlib is only "older" because before it was named "stew". And one day,
the upstream decided to recall it extlib. I see no reason to change the
name of extlib because one guy thinks it was a prettier name.

It is a personnal point of view, but i keep considering that extlib is
"tm" to sf library ( and not the other one ).

Regard
Sylvain Le Gall

Re: [Ocaml-lib-devel] BitSet

[Nicolas C. <war...@fr...>]

>    I made a few changes on the files bitSet.ml and bitSet.mli (see
> attachements). I :
>
> 1 - corrected a few orthograph mistakes (I hope I didn't added new ones)
> 2 - corrected an "lsl" -> "lsr" (the size of a BitSet was 8 times bigger
>      instead of 8 times smaller)
> 3 - suggested the name "copy" which is more usual than "clone"
> 4 - used "blit_string" and "fill_string" for more efficiency
> 5 - added some functions on sets
>
> I hope there are no more mistakes. I have got a question : isn't it
> possible to use the 32 bits of an int (or 64 bits, depending on the
> architecture) for efficients BitSets ? The String functions seem to work
> on 8 bits only.

Thanks,
The CVS have been updated with your changes.
To answer more precisely to your questions :
- we could actualy use ints as 16 bits values if we add the API to extract
them from strings, but we don't :)
- we can't use Pervasives.compare because bitsets might be of different
sizes but are actually the same integer
- I disabled the "deprecated" on "clone", having both copy and clone is
okay.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

> > - base64 encode/decode
> > - abstract high level I/O with support for C basic types ( read_i16 ,
> > write_f16 ..... )
> > - zlib deflate/inflate written in pure OCaml.
>
> One of the things I've been nooddling around with is a radicaly new I/O
> arhitecture.  The basic idea is to make i/o more like java and less like
> C.  The core idea is that there would be four classes of objects:
[...]

Hi Brian,
What we need is an high-level IO abstraction that will offer a wide API for
most of the common usages.
The IO module I posted earlier on this list was a beginning of answer to
this. It didn't made his way to the CVS because I lacked time, but looks
like there was no people against it.
In this IO module, I made the following choices regarding polymorphism :

(quoting myself)

For efficiency reason each input/output have two ways of reading/writing
data : for example a channel input can write char by char or directly
strings. it's then a (char,string) input. An ouput takes a third parameter
which is the value returned by a call to close.


(end-of-quote)

So we have here :
    * ('a,'b) input  : an input to a file is a (char,string) input
    * ('a,'b,'c) output : an output to a buffer is a (char,string,string)
output since "closing" the buffer returns the total string written into
we can provide several conversion "parsers" functions such as
    * val in_ord : (char,string) input -> (int,int list) input
    * val in_chr : (int,int list) input -> (char,string) input
or "filters" such as :
    * val in_b64 : (char,string) input -> (char,string) input
    * val out_zlib : (char,string,'a) output -> (char,string,'a) output

Concerning the "Directories", I think its even more high level and should be
handled in a different module that will be built on top of IO. Please
remember that the "file" concept have no meaning in an abstract IO.
Concerning Unicode, adding a filter to handle this looks okay (not by
default). For the "polymorphism" of formatters, this is not really possible
in the OCaml type system. One choice is to use printf/scanf on an output :
that's exactly what's I'm doing in IO module.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] Future of ExtLib

[Yamagata Y. <yor...@mb...>]

Before anything, I'd like to mention the recent exchange about another
"extlib" in the caml-list and others.  I'm little embarrassed in the
current situation.  If I remember correctly, another "extlib" is older
than ours, so, in my opinion, we have to change the name.  Whatever
reasons there are, we have to give a due credit to the previous work.
If we are going to change the nature of our library, then it is a good
opportunity to change the name.

From: "Nicolas Cannasse" <war...@fr...>
Subject: [Ocaml-lib-devel] Future of ExtLib
Date: Fri, 19 Mar 2004 09:29:01 +0100

> That's convenient, but in fact since we're keeping 99% compability
> with stdlib, having the user to port the small parts of his code and
> then he can use all extensions provided as if he was using stdlib
> seems to be a fair trade.  Of course this means some changes to
> current project, and that's why I would like to get your comments
> and advices about this - I'm especialy interested in current
> ExtLib's contributors opinions.

I'm not clear about what you want to do.  But if you mean, say, we
provide List module in extlib, so that override List of the stdlib,
then I think it is definitely a bad idea. In addition to forcing to
use the new stdlib in order to access some module in extlib, it will
cause incomprehensive "inconsistent assumption" error if modules using
old stdlib and using new stdlib are mixed up.  If we use -pack option,
then the change would be more bearable, but I prefer to split extlib
to several packages, one for replacing stdlib, another for providing
new features.  Maybe we could split the packages for their purpose,
like providing new data structure, I/O, etc, too.

From: "Nicolas Cannasse" <war...@fr...>
Subject: [Ocaml-lib-devel] Future of ExtLib
Date: Fri, 19 Mar 2004 09:29:01 +0100

> Concerning additionnals modules here's what's on my wish-list (which is
> somehow also on my current todo-list) :
> - base64 encode/decode
> - abstract high level I/O with support for C basic types ( read_i16 ,
> write_f16 ..... )
> - zlib deflate/inflate written in pure OCaml.

Do you interested in diet set and map? (set and map over integer,
internally represented as sets and maps over intervals.)  I could
contribute them.  Also, I'd like to change install.ml so that it
ignores findlib if the destination directory is explicitly given by
the arguments. 

--
Yamagata Yoriyuki

Re: [Ocaml-lib-devel] BitSet

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

On Fri, 19 Mar 2004, Nicolas Cannasse wrote:

> Concerning the usage of int, OCaml runtime representation is 31 bits. They
> are unboxed and shifted by 1 and the lowest bit is set to 1 so it can't be
> mistaken with an address since all addresses are always aligned on 2 bytes
> (even 4 on most of 32-bits architectures) . So we could use ints as 31 bits
> but we would then need to div/mod to get the correct integer. Another nice
> thing about strings is that their contents are not scanned by the GC while
> Array of ints are.
> 

Having looked at implementing bitset myself, I came to the following 
conclusions:

1) bitset and big int support should be combined, much like an int can be 
viewed both as a small integer and as a small bitset, depending.

2) Both should be built on top of gmp.

3) GMP doesn't do everything I want bitset to be able to do yet.  Most 
everything, but not everything (bitblit doesn't exist).

4) I'm on-again off-again trying to get gmp to accept patches to let it 
do what I want it to, but I'm getting push-back.

I'm tempted to just provide the wrappers for the existing gmp 
functionality, and support the rest when it shows up.  Thoughts?

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Re: [Ocaml-lib-devel] Future of ExtLib

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

On Fri, 19 Mar 2004, Nicolas Cannasse wrote:

> - base64 encode/decode
> - abstract high level I/O with support for C basic types ( read_i16 ,
> write_f16 ..... )
> - zlib deflate/inflate written in pure OCaml.

One of the things I've been nooddling around with is a radicaly new I/O 
arhitecture.  The basic idea is to make i/o more like java and less like 
C.  The core idea is that there would be four classes of objects:

1) sinks and sources.  These would be the fundamental sources/destinations 
of the data- files, sockets, and strings would all be sinks and/or 
sources.  Most likely these will be built on top of the old-style Ocaml 
I/O routines.

2) filters.  These look like a sink or source, but wrap either a 
sink/source or another filter.  Examples of filters would 
compression/decompression, encryption/decryption, mime or uu 
encode/decode, eoln conversion, etc.  Also, a filter might just collect 
statistics on the stuff as it goes by, not changing the data- so line 
counters, word counters, and check summers would be filters.

3) formatters and parsers.  Formatters take the fundamental datatypes of
ocaml (int, float, etc) and convert them into strings and write the
strings to a filter or source/sink.  Parsers take strings and parse them 
back into the fundamental types of ocaml.

4) Directories- collections of one or more sources or sinks or
subdirectories.  This is so we can deal with "multi-file" streams, like
tar or zip files.  This might also be a way to generically handle file 
system issues.  This might also be the way to deal with file forks on 
MacOS.

The questions I haven't answered yet are:

1) Unicode or no unicode?  It's not that converting to/from unicode into 
one of the utf- formats is so hard, it's just that now a stream of 
characters is a different concept than a stream of bytes, with different 
filters working on different types streams.  And a conversion object stuck 
in between.  All pipes would now be at least three objects deep 
(formatter, unicode conversion, source/sink), instead of just two.

2) What are the semantics of directories?  Do we want to include file 
system fun?

3) How to deal with the lack of polymorphism on formatters.  All of the 
implementations of this structure I've seen (ab)use polymorphism to 
implement the formatters- they have a print function which is overloaded 
for the specific types- print(int), print(float), etc.  Often they have an 
operator overloaded or defined as well.  I'd love to be able to have a 
print function with a signature filter -> 'a -> filter, but I can't think 
of how to do it.

-- 
"Usenet is like a herd of performing elephants with diarrhea -- massive,
difficult to redirect, awe-inspiring, entertaining, and a source of
mind-boggling amounts of excrement when you least expect it."
                                - Gene Spafford 
Brian

Re: [Ocaml-lib-devel] BitSet

[Nicolas C. <war...@fr...>]

>    Hello !
>
>    I made a few changes on the files bitSet.ml and bitSet.mli (see
> attachements). I :
>
> 1 - corrected a few orthograph mistakes (I hope I didn't added new ones)
> 2 - corrected an "lsl" -> "lsr" (the size of a BitSet was 8 times bigger
>      instead of 8 times smaller)
> 3 - suggested the name "copy" which is more usual than "clone"
> 4 - used "blit_string" and "fill_string" for more efficiency
> 5 - added some functions on sets
>
> I hope there are no more mistakes. I have got a question : isn't it
> possible to use the 32 bits of an int (or 64 bits, depending on the
> architecture) for efficients BitSets ? The String functions seem to work
> on 8 bits only.
>
> TIA for your answers,

Thanks, I'll review theses changes.
Concerning the usage of int, OCaml runtime representation is 31 bits. They
are unboxed and shifted by 1 and the lowest bit is set to 1 so it can't be
mistaken with an address since all addresses are always aligned on 2 bytes
(even 4 on most of 32-bits architectures) . So we could use ints as 31 bits
but we would then need to div/mod to get the correct integer. Another nice
thing about strings is that their contents are not scanned by the GC while
Array of ints are.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] BitSet

[Prakash C. <Pra...@im...>]

   Hello !

   I made a few changes on the files bitSet.ml and bitSet.mli (see 
attachements). I :

1 - corrected a few orthograph mistakes (I hope I didn't added new ones)
2 - corrected an "lsl" -> "lsr" (the size of a BitSet was 8 times bigger
     instead of 8 times smaller)
3 - suggested the name "copy" which is more usual than "clone"
4 - used "blit_string" and "fill_string" for more efficiency
5 - added some functions on sets

I hope there are no more mistakes. I have got a question : isn't it 
possible to use the 32 bits of an int (or 64 bits, depending on the 
architecture) for efficients BitSets ? The String functions seem to work 
on 8 bits only.

TIA for your answers,

Prakash

[Ocaml-lib-devel] Future of ExtLib

[Nicolas C. <war...@fr...>]

Hi list,

I'm pretty sure all of you have been reading the caml-list recently,

I had some private talks with Benjamin Geer concerning ExtLib. His point was
that if ExtLib was not just an extension to the ocaml stdlib but a full
replacement - including more modules and more functionality - then it will
fasten its spread and ease its usage. I kindof agree with him : currently
there is several ways of working with ExtLib, and you can have some part of
your project using stdlib while others parts are using ExtLib. That's
convenient, but in fact since we're keeping 99% compability with stdlib,
having the user to port the small parts of his code and then he can use all
extensions provided as if he was using stdlib seems to be a fair trade.
Of course this means some changes to current project, and that's why I would
like to get your comments and advices about this - I'm especialy interested
in current ExtLib's contributors opinions.
Concerning additionnals modules here's what's on my wish-list (which is
somehow also on my current todo-list) :
- base64 encode/decode
- abstract high level I/O with support for C basic types ( read_i16 ,
write_f16 ..... )
- zlib deflate/inflate written in pure OCaml.

Regards,
Nicolas Cannasse

Re: [Ocaml-lib-devel] compilation issues

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

Actually, you are right... I do all my development using 3.07 and I was
living under the wrong assumption that debian stable uses 3.06.

tnx to point it out.

p

On Tue, Feb 03, 2004 at 09:35:40AM +0000, Peter Jolly wrote:
> I know it sounds silly, but are you sure you're using version 3.06?  The
> reason I ask is that this problem would make perfect sense in 3.04,
> because the compare and t fields in the standard String library were not
> present in that version.  Also, Debian isn't distributing 3.06 at the
> moment - stable is 3.04, testing and unstable are 3.07.

-- 
++ It is not doing the thing we like to do, but liking the 
   thing we have to do, that makes life blessed. -- Goethe
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Ocaml-lib-devel] compilation issues

[Peter J. <pe...@jo...>]

Pietro Abate wrote:
> Hi all,
> I want to distribute extlib with my project and to do so I added a
> Makefile to it. When compiling it on debian unstable (ocaml 3.07)
> everything it's ok. When I try to compile the same code, with the same
> makefile and ocaml 3.06 (debian woody) I get a complain about extString:
> 
> [...]
> ocamlc -c extString.mli
> ocamlc -c extString.ml
> The implementation extString.ml does not match the interface extString.cmi:
> Modules do not match:
>   sig
>     exception Invalid_string
>     external length : string -> int = "%string_length"
>     external get : string -> int -> char = "%string_safe_get"
>     external set : string -> int -> char -> unit = "%string_safe_set"
>     external create : int -> string = "create_string"
>     val make : int -> char -> string
>     val copy : string -> string
> 
> [...]
> 
>     val lowercase : string -> string
>     val capitalize : string -> string
>     val uncapitalize : string -> string
>     type t = string
>     val compare : t -> t -> int
>   end
> The field `compare' is required but not provided
> The field `t' is required but not provided
> make[1]: *** [extString.cmo] Error 2
> #> 
> 
> my naive solution was to add
> type t = string
> let compare = compare in the extString.ml file.
> 
> now it compiles with ocmal 3.06, but it complains with 3.07 because 
> there's a dup definition...

I know it sounds silly, but are you sure you're using version 3.06?  The
reason I ask is that this problem would make perfect sense in 3.04,
because the compare and t fields in the standard String library were not
present in that version.  Also, Debian isn't distributing 3.06 at the
moment - stable is 3.04, testing and unstable are 3.07.

At any rate, since you're using OCamlMakefile it's pretty easy to work
round this, if you're willing to use a non-standard ExtLib.  Add
conditional compilation directives from your preprocessor of choice
using some suitable conditional symbol around the definitions of t and
compare in extString.ml, and a (*pp foo *) directive at the top of that
file to invoke that preprocessor.  Then write a simple configure script
that tries to compile a test that depends on String.compare and sets
PPFLAGS to define that symbol if it fails.

HTH

Re: [Ocaml-lib-devel] compilation issues

[Nicolas C. <war...@fr...>]

> Hi all,
> I want to distribute extlib with my project and to do so I added a
> Makefile to it. When compiling it on debian unstable (ocaml 3.07)
> everything it's ok. When I try to compile the same code, with the same
> makefile and ocaml 3.06 (debian woody) I get a complain about extString:
[...]
> now it compiles with ocmal 3.06, but it complains with 3.07 because
> there's a dup definition...
>
> is it a known problem ? attached there's the makefile (using
> OCamlMakefile) and the META file that might be useful having in the
> extlib distribution...

I didn't know there was such a problem with 3.06.
Looks like it was a bug fixed in 3.07, I'm not sure it can be avoid in a
compatible way...
If you really need to have 3.06 support , please try to ask on the main caml
list.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] compilation issues

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

Hi all,
I want to distribute extlib with my project and to do so I added a
Makefile to it. When compiling it on debian unstable (ocaml 3.07)
everything it's ok. When I try to compile the same code, with the same
makefile and ocaml 3.06 (debian woody) I get a complain about extString:

[...]
ocamlc -c extString.mli
ocamlc -c extString.ml
The implementation extString.ml does not match the interface extString.cmi:
Modules do not match:
  sig
    exception Invalid_string
    external length : string -> int = "%string_length"
    external get : string -> int -> char = "%string_safe_get"
    external set : string -> int -> char -> unit = "%string_safe_set"
    external create : int -> string = "create_string"
    val make : int -> char -> string
    val copy : string -> string

[...]

    val lowercase : string -> string
    val capitalize : string -> string
    val uncapitalize : string -> string
    type t = string
    val compare : t -> t -> int
  end
The field `compare' is required but not provided
The field `t' is required but not provided
make[1]: *** [extString.cmo] Error 2
#> 

my naive solution was to add
type t = string
let compare = compare in the extString.ml file.

now it compiles with ocmal 3.06, but it complains with 3.07 because 
there's a dup definition...

is it a known problem ? attached there's the makefile (using
OCamlMakefile) and the META file that might be useful having in the
extlib distribution...

p

-- 
++ Our capacity for understanding is inversely proportional to 
   how much we think we know. The more I know, the more I know 
   I don't know...
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

[Ocaml-lib-devel] compilation issues

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

Hi all,
I want to distribute extlib with my project and to do so I added a
Makefile to it. When compiling it on debian unstable (ocaml 3.07)
everything it's ok. When I try to compile the same code, with the same
makefile and ocaml 3.06 (debian woody) I get a complain about extString:

[...]
ocamlc -c extString.mli
ocamlc -c extString.ml
The implementation extString.ml does not match the interface extString.cmi:
Modules do not match:
  sig
    exception Invalid_string
    external length : string -> int = "%string_length"
    external get : string -> int -> char = "%string_safe_get"
    external set : string -> int -> char -> unit = "%string_safe_set"
    external create : int -> string = "create_string"
    val make : int -> char -> string
    val copy : string -> string

[...]

    val lowercase : string -> string
    val capitalize : string -> string
    val uncapitalize : string -> string
    type t = string
    val compare : t -> t -> int
  end
The field `compare' is required but not provided
The field `t' is required but not provided
make[1]: *** [extString.cmo] Error 2
#> 

my naive solution was to add
type t = string
let compare = compare in the extString.ml file.

now it compiles with ocmal 3.06, but it complains with 3.07 because 
there's a dup definition...

is it a known problem ? attached there's the makefile (using
OCamlMakefile) and the META file that might be useful having in the
extlib distribution...

p

-- 
++ Our capacity for understanding is inversely proportional to 
   how much we think we know. The more I know, the more I know 
   I don't know...
++ Please avoid sending me Word or PowerPoint attachments.
   See http://www.fsf.org/philosophy/no-word-attachments.html

Re: [Ocaml-lib-devel] Filename and file manipulation

[<syl...@po...>]

Hello,

On Sun, Feb 01, 2004 at 11:22:14AM +0100, Nicolas Cannasse wrote:
> Just a little additionnal suggestion about SysUtil :
> 
> SysUtil is heavily relying on the Unix module for its implementation, and
> that's ok. But only one feature ( the Match pattern to match the filename
> using a regexp) is using the Str module. In order to reduce dependencies, I
> think you should abstract the Match, using an user define regexp matching.
> For exemple :
> 
> in SysUtil.mli :
> ---
> 
> val configure_regexp : make:(string -> 'a) -> test:('a -> bool) -> unit
> 
> in SysUtil.ml :
> -----
> let regexp_make= ref (fun _ -> failwith "Regexp is not configured")
> let regexp_test = ref (fun x _ -> failwith "Regexp is not configured"; x =
> 0) (* we need to give a type here for ungeneralized variables *)
> 
> let configure_regexp ~make ~test =
>     regexp_make := Obj.magic make; (* we need to cast here because the type
> we need is slighty different *)
>     regexp_test := Obj.magic test
> 
> * and in testing Match :
>     let reg = !regexp_make str in
>     fun x -> !regexp_test reg x
> 
> Then the user could write :
> 
> SysUtil.configure_regexp Str.regexp Str.string_match
> before making any Match
> 
> ( we can also use only one function with currying trick :
>     SysUtil.configure_regexp (fun reg -> let reg = Str.regexp reg in
> (Str.String.match reg))
> but it's then less comprehensible for the user )
> 
> Regards,
> Nicolas Cannasse
> 
> 
> 

Ok, you are perfectly right. I will remove the Str test and replace it
by a user provided test... But i won't use obj.magic to cast regexp... I
prefer let the user do some more work to have something fully ocaml
compliant than using a clever trick that is not documented ( personnal
point of view on obj.magic ). 

Thank you for your remark.
Kind regard
Sylvain LE GALL