ocaml-lib-devel — Developer's mailing list

Re: [Ocaml-lib-devel] Xarray : resizeable arrays (first cut)

[Brian H. <bri...@ql...>]

On Fri, 25 Apr 2003, John Max Skaller wrote:

> By best you mean 'fastest'. 

Fastest in the most common cases, to be precise.  With "reasonable" (for
suitably lose definitions of reasonable) space wastage.  With doubling you
never waste more than about 75% of the space, and rarely waste 50%.  This
is actually not bad, compared to other data structures, if you consider
the wasted space "infrastructure overhead".  Consider a binary tree, where
the data is stored only at the leaves. You will have about as many branch
nodes as you have leaf nodes.  Suddenly have the memory used in branch 
nodes are references to other branch nodes, not references to data- 
"wasted" space.

Increasing the muliple decreases the number of copies you need to make, at 
the cost of greatly increasing the "wasted space" on average.  Plus, 
powers of two are generally easier to allocate than powers of anything 
else.

> > Hmm.  Could be done with a reference.  But this is a very non-ML sort of 
> > concept.
> 
> I agree: loss of reentrancy .. BUT provided the store is atomic
> it only affects performance not semantics if the variable is
> changed at random even by multiple threads. Setting a strategy
> for a whole program depending on what phase of execution it is up
> to is fairly useful.

I was just thinking not-functional.  Not in that it wouldn't work, but in 
that it's not how most functional programming flows, if that makes sense.

> -------------------------------------------------------- 
> one thing I found: I needed 3 arguments not 2:
> 
> current slots, current used slots, required size

The inputs xarray has to give the resizer algorithm are:

- the current number of slots the array has

- the current number of slots the array needs

Note that if I'm increasing or decreasing the array size, I adjust the 
number of slots needed before passing it into the resizer.  What the 
resizer returns should be the number of slots the array should have.

Once the resizer calculates what size the array should be, the xarray code 
actually deals with allocating a new array and copying data over (if 
needed), etc.

Maybe these parameters should have a better name.

> Conceptually, the reason is: the ideal size
> may be influenced by the allocated size for example:
> 

Always.  You need to return the current size if you don't want to 
reallocate the array.

> 
> The extra argument is necessary for asymmetric growth/shrinkage
> algorithms, so I recommend you add it: at present you cannot
> take 'unused space' into account since it cannot be computed.
> 

Hmm.  Consider the following case.  You have an array, using the doubling 
algorithm, with a size of 16 and a length (number of used elements) of 10.  
Now, you add an enumeration with 100 elements in it.

Currently, the resizer function is called with a currsize of 16 (the 
current number of spaces in the array when it's called) and a length of 
110 (how many elements need to fit into the array).  Exponential_resizer 
then keeps doubling 16 until it gets a long enough array size- 128 in this 
case.  It returns 128.

If I understand you correctly, in this example you also want 10 (call it
'oldlength')  passed in as well.  Certainly not difficult.  I just don't 
see what you get out of it.  I suppose you could keep the same percentage 
of free space, and return 176 instead of just 128.

If resizer returns anything except the current array size, a new array is
allocated and the data copied over (hmm.  Must remember to null out the
old array after copying everything over).  Should having a small amount of 
data make the algorithm more inclined to copy data over?

Brian

Re: [Ocaml-lib-devel] Xarray : resizeable arrays (first cut)

[John M. S. <sk...@oz...>]

Brian Hurt wrote:


> The doubling algorithm is the overall generally best algorithm that I can
> think of.  Basically, adding and subtracting elements is O(1)- making the 
> construction and use of large xarrays not implausible.


By best you mean 'fastest'. This is clearly not the only requirement.
For example it would be a disaster on a prime number generator
in which minimisation of storage use is more important. Here the time
to copy is irrelevant compared to the time computing primes, where the
need to fit large numbers in storage is dominant.

Obviously, doubling is less efficient speed wise than tripling.
My experiments showed that, as you claim, a factor of 2 is close
to optimal: multiplying by 10 is faster, but not much. OTOH a factor
of 1.8 begins to slow the system down... on the tests I ran anyhow.


> Hmm.  Could be done with a reference.  But this is a very non-ML sort of 
> concept.


I agree: loss of reentrancy .. BUT provided the store is atomic
it only affects performance not semantics if the variable is
changed at random even by multiple threads. Setting a strategy
for a whole program depending on what phase of execution it is up
to is fairly useful.

 
>>(5) a method for changing the strategy for any individual array
>>
> 
> I only allow new strategies on allocating new arrays.  This include 
> 'implicit' allocations like of_enum and copy.  Although I suppose this 
> could be added.


It can also be left out until someone needs it (if unsure

of utility LEAVE IT OUT :-)

-------------------------------------------------------- 
one thing I found: I needed 3 arguments not 2:


current slots, current used slots, required size


Conceptually, the reason is: the ideal size
may be influenced by the allocated size for example:

Double when necessary, only shrink if the desired size
is zero.

The extra argument is necessary for asymmetric growth/shrinkage
algorithms, so I recommend you add it: at present you cannot
take 'unused space' into account since it cannot be computed.

-- 
John Max Skaller, mailto:sk...@oz...
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850

Re: [Ocaml-lib-devel] Xarray : resizeable arrays (first cut)

[Brian H. <bri...@ql...>]

On Fri, 25 Apr 2003, John Max Skaller wrote:

> Brian Hurt wrote:
> 
> > On Mon, 14 Apr 2003, John Max Skaller wrote:
> 
> > I'm not sure Hysteresis is the best algorithm.
> 
> 
> [snip]
> 
> > You preventing thrashing by letting shrinkage go longer before shrinking.  
> 
> 
> Must be some misunderstanding here.

Yes there was.  I was misunderstanding you.  My apologies.

The good news was that in the current version of Xarray in the libraries, 
every time I allocate a new array I allow the caller to pass in what 
reallocation strategy to use.  Neither of the two I have defined are what 
you are talking about- but new strategies can easily be added.

I tried to document in xarray.mli how to write a resizer function.  If the 
comments are clear, please let me know and I'll improve them.

> And the real point is: there is no single optimal
> strategy, it depends on the use to which the array
> is being put. Hence, allowing the user to specify
> the strategy allows for the user to tune performance
> in a way reasonably well separated from the
> overall program logic.

I fully agree.  I can even envision application-specific resizer 
functions, which "know" the behavior of the algorithm being used and can 
behave differently as the algorithm changes it's allocation behavior.  Or 
implements heuristics to try and predict the algorithm.  Etc.

The doubling algorithm is the overall generally best algorithm that I can
think of.  Basically, adding and subtracting elements is O(1)- making the 
construction and use of large xarrays not implausible.


> In my system I had:
> 
> (1) a standard strategy (chunks of 16 elements)

I'm using doubling.  See above.

> (2) a global variable which was initialised to the standard
> strategy but which could be changed

Hmm.  Could be done with a reference.  But this is a very non-ML sort of 
concept.

> (3) a default constructor using the global strategy

Got it.

> (4) a constructor accepting a strategy argument

Got it.

> (5) a method for changing the strategy for any individual array

I only allow new strategies on allocating new arrays.  This include 
'implicit' allocations like of_enum and copy.  Although I suppose this 
could be added.

> 
> In addition, my stratgies were objects which had some
> data, which could also be changed (eg: chunk strategy
> was parameterised by chunk size).

Partial evaluation takes care of this.  

> 
> The cost is a function pointer in each array,
> and some overhead calling it when necessary.
> 

Already paying it.  I call the resizer function (which tells me what size 
the array should be) every time I add or remove an element from the array.

Brian

Re: [Ocaml-lib-devel] Xarray : resizeable arrays (first cut)

[John M. S. <sk...@oz...>]

Brian Hurt wrote:

> On Mon, 14 Apr 2003, John Max Skaller wrote:

> I'm not sure Hysteresis is the best algorithm.


[snip]

> You preventing thrashing by letting shrinkage go longer before shrinking.  


Must be some misunderstanding here.

Hysteresis doesn't imply adding a fixed chunk on growing, nor
removing one on shrinking. It simply implies the threshholds for
growth or shrinkage are not the same, but separated somehow so that
a requirement for 1 more slot which causes an allocation, when followed
by a requirement for 1 less slot, does NOT cause a reduction.

The idea applies no matter whether growth is a constant chunk,
or a fractional increase, or some other calculation:
arrays grow when they must, but don't
shrink until they waste a certain amount of space (which is
more than the amount wasted after an allocation).

This is what you described for the doubling routine:
if you allow 25% wastage before shrinking, and you remove
only 15% of the unused space when you do shrink, then small
vibrations don't cause either allocations or deallocations.

Anyhow, the point is not to use a naive routine where the
growth and shrinkage triggers are the same, since a loop
which adds an element and then removes one repeatedly would
cause violent and unacceptable thrashing.

And the real point is: there is no single optimal
strategy, it depends on the use to which the array
is being put. Hence, allowing the user to specify
the strategy allows for the user to tune performance
in a way reasonably well separated from the
overall program logic.

In my system I had:

(1) a standard strategy (chunks of 16 elements)
(2) a global variable which was initialised to the standard
strategy but which could be changed
(3) a default constructor using the global strategy
(4) a constructor accepting a strategy argument
(5) a method for changing the strategy for any individual array

In addition, my stratgies were objects which had some
data, which could also be changed (eg: chunk strategy
was parameterised by chunk size).

The cost is a function pointer in each array,
and some overhead calling it when necessary.

-- 
John Max Skaller, mailto:sk...@oz...
snail:10/1 Toxteth Rd, Glebe, NSW 2037, Australia.
voice:61-2-9660-0850

Re: [Ocaml-lib-devel] XML Light

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

> Here's another solution for reading XML : that's the xml lexer
> included in the LablGTK sources. It's an ocamllex lexer and you can
> parse the stream with a camlp4 parser.

The new Xml Light is based on the same lexer, since some talks with Jacques
Garrigue on what is best for Xml parsing, he give me the right to use the
sources. But it doesn't need camlp4.

Nicolas Cannasse

Re: [Ocaml-lib-devel] XML Light

[Olivier A. <ol...@us...>]

 Nicolas Cannasse [Wednesday 23 April 2003] :
 > > If you want my real opinion, after reading some of the Tim Bray
 > > discussions recently on the pros and cons of working with XML
 > >
 > > http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
 > >
 > > I was looking forward to messing around with a regex style XML
 > > processor.  It looks much easier than any of the event, push,
 > > pull models of working with XML.
 > >
 > > Getting a Ocaml version of this would be cool and be a new
 > > direction in processing XML.
 > 
 > The OCaml pattern matching is enough for that, don't you think ?

 > OCaml :
 > 
 > let process = function
 >     | Elements ("meta",_,_) -> ()
 >     | Elements ("h1",_,_) | Elements ("h2",_,_) | Elements ("h3",_,_) |
 > Elements ("h4",_,_)  -> divert := "head"
 >     | Elements ("img",attr,_) as x -> proc_jpeg (Xml.attrib x "src")
 >     | ... (* and so on *)
 > in
 > let rec walk = function
 >     | PCData _ -> ()
 >     | Elements (_,_,children) as x ->
 >         process x;
 >         List.iter walk children
 > in
 > walk (Xml.parse_in stdin)

Here's another solution for reading XML : that's the xml lexer
included in the LablGTK sources. It's an ocamllex lexer and you can
parse the stream with a camlp4 parser.

-- 
   Olivier

Re: [Ocaml-lib-devel] XML Light

[Maas-Maarten Z. <ma...@wa...>]

>
>
>>I'm currently rewriting my Xml-Light library which is a minimal Xml
>>parser/printer and adding DTD support to it.
>>    
>>
>
> Is it? Is it _really_ a minimal XML parser/printer?
> I fear it is just a parser/printer for a minimal _subset_ of XML!
> (e.g. Does it supports UNICODE characters? What about Entities?
>  What about Notation? Is it 100% fully compliant with the spec?)
>
> We do not need yet another standard for documents. Either it is
> fully XML compliant (and there is already PXP - native ocaml -
> or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.
>
>  
>
There is also an ocaml wrapper for expat.

Maas

Re: [Ocaml-lib-devel] XML Light

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

> > resulting library binary won't exceed few KB.
> > PXP have to go its own way, there is really enough space and need for
one
> > library like Xml Light, don't you think ?
>
> If you want my real opinion, after reading some of the Tim Bray
> discussions recently on the pros and cons of working with XML
>
> http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog
>
> I was looking forward to messing around with a regex style XML
> processor.  It looks much easier than any of the event, push,
> pull models of working with XML.
>
> Getting a Ocaml version of this would be cool and be a new
> direction in processing XML.

The OCaml pattern matching is enough for that, don't you think ?

while (<STDIN>) {
  next if (X<meta>X);
  if    (X<h1>|<h2>|<h3>|<h4>X)
  { $divert = 'head'; }
  elsif (X<img src="/^(.*\.jpg)$/i>X)
  { &proc_jpeg($1); }
  # and so on...
}


OCaml :

let process = function
    | Elements ("meta",_,_) -> ()
    | Elements ("h1",_,_) | Elements ("h2",_,_) | Elements ("h3",_,_) |
Elements ("h4",_,_)  -> divert := "head"
    | Elements ("img",attr,_) as x -> proc_jpeg (Xml.attrib x "src")
    | ... (* and so on *)
in
let rec walk = function
    | PCData _ -> ()
    | Elements (_,_,children) as x ->
        process x;
        List.iter walk children
in
walk (Xml.parse_in stdin)

Of course, this version is first reading all stdin and parsing it as a Xml
tree before processing, but I'm thinking right now of adding Lazy xml
processing to Xml Light so you parse only what you need. Others things
possible are to generate a MLI file from an DTD which will provide all types
and conversion functions from and to XML.

Nicolas Cannasse

Re: [Ocaml-lib-devel] XML Light

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> resulting library binary won't exceed few KB.
> PXP have to go its own way, there is really enough space and need for one
> library like Xml Light, don't you think ?

If you want my real opinion, after reading some of the Tim Bray
discussions recently on the pros and cons of working with XML

http://www.tbray.org/ongoing/When/200x/2003/03/16/XML-Prog

I was looking forward to messing around with a regex style XML
processor.  It looks much easier than any of the event, push,
pull models of working with XML.

Getting a Ocaml version of this would be cool and be a new
direction in processing XML.

Did you see the XML is too hard thread recently?  Check out

http://www.google.com/search?q=xml+too+hard

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] XML Light

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

> > PXP is huge, complex, didn't managed to compiled it under Win32 in one
day,
> > but quite complete : this library is for "professionnal" XML users. Let
me
> > explain my thoughts... As far as I know, there is a lot of differents
ways
> > of using XML, and I'm pretty sure that about 85% of the usages are for
> > configuration files and import/export of XML data. Theses usages needs
only
> > the _subset_ of all the XML specs that Xml Light will support, I have no
> > ambition of rewriting a PXP, but I think it will be good for the OCaml
> > community to have such a small thing available. Of course, I would like
to
> > be as much compliant with the spec, so please review the code once
released.
> >
> > So I don't think its unuseful since I already had several users enjoying
the
> > previous version of Xml Light which was not even supporting CDATA et
PCDATA
> > ! And I don't think it's threatening either since with the help of the
> > community we will stick to a given subset of the specs.
>
> What about putting an easy to use wrapper around PXP then?  How about
> helping PXP run on Windows then?
>
> I'm sure I'm talking to a programmer here who, like me, would like to
> write new code rather than use existing code :)

I can't deny I am :-)
But I have also good arguments for it, for example the code size of the
resulting library binary won't exceed few KB.
PXP have to go its own way, there is really enough space and need for one
library like Xml Light, don't you think ?

Nicolas Cannasse

Re: [Ocaml-lib-devel] XML Light

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> PXP is huge, complex, didn't managed to compiled it under Win32 in one day,
> but quite complete : this library is for "professionnal" XML users. Let me
> explain my thoughts... As far as I know, there is a lot of differents ways
> of using XML, and I'm pretty sure that about 85% of the usages are for
> configuration files and import/export of XML data. Theses usages needs only
> the _subset_ of all the XML specs that Xml Light will support, I have no
> ambition of rewriting a PXP, but I think it will be good for the OCaml
> community to have such a small thing available. Of course, I would like to
> be as much compliant with the spec, so please review the code once released.
> 
> So I don't think its unuseful since I already had several users enjoying the
> previous version of Xml Light which was not even supporting CDATA et PCDATA
> ! And I don't think it's threatening either since with the help of the
> community we will stick to a given subset of the specs.

What about putting an easy to use wrapper around PXP then?  How about
helping PXP run on Windows then?

I'm sure I'm talking to a programmer here who, like me, would like to
write new code rather than use existing code :)

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] XML Light

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

> > I'm currently rewriting my Xml-Light library which is a minimal Xml
> > parser/printer and adding DTD support to it.
>
>  Is it? Is it _really_ a minimal XML parser/printer?
>  I fear it is just a parser/printer for a minimal _subset_ of XML!

Yes it is.

>  (e.g. Does it supports UNICODE characters? What about Entities?
>   What about Notation? Is it 100% fully compliant with the spec?)

No, no, no, and no :-)

>  We do not need yet another standard for documents. Either it is
>  fully XML compliant (and there is already PXP - native ocaml -
>  or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.

Why do you think then I am "loosing" my time writing it then ?

PXP is huge, complex, didn't managed to compiled it under Win32 in one day,
but quite complete : this library is for "professionnal" XML users. Let me
explain my thoughts... As far as I know, there is a lot of differents ways
of using XML, and I'm pretty sure that about 85% of the usages are for
configuration files and import/export of XML data. Theses usages needs only
the _subset_ of all the XML specs that Xml Light will support, I have no
ambition of rewriting a PXP, but I think it will be good for the OCaml
community to have such a small thing available. Of course, I would like to
be as much compliant with the spec, so please review the code once released.

So I don't think its unuseful since I already had several users enjoying the
previous version of Xml Light which was not even supporting CDATA et PCDATA
! And I don't think it's threatening either since with the help of the
community we will stick to a given subset of the specs.

Nicolas Cannasse

[Ocaml-lib-devel] Added reversed enumerations to xarray

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

Enumerations that count down instead of up.  I realized that in arrays I 
can decrement as easily as increment.

Brian

Re: [Ocaml-lib-devel] function application operator?

[Brian H. <bri...@ql...>]

While we're at it:

let curry f = fun a b -> f (a, b)

let uncurry f = fun (a, b) -> f a b

Brian

[Ocaml-lib-devel] function application operator?

[Brian H. <bri...@ql...>]

I was reading the Haskell wiki page (via Lambda the Ultimate) and came 
across this page:
http://www.haskell.org/hawiki/PipeliningFunctions

I don't think Ocaml has a function application operator- not that one is 
hard to write:
let ( $ ) : ('a -> 'b) -> 'a -> 'b = fun f x -> f x

or even more simply:

let ( $ ) f x = f x

Likewise, functional composition is fairly trivial to implement:

let ( $. ) f g x = f (g x)

I'm not 100% sure I see the purpose of having these operators- I'd just 
use parens, and instead of writting:
    foo $. bar $. bang $ x
I'd write
    foo (bar (bang x))
which does the same bleeding thing.  But I thought I'd throw the idea out 
to the listmind to see if we wanted to make things friendlier for any 
Haskel programmers who come our way?

Brian

Re: [Ocaml-lib-devel] Indentation

[Blair Z. <bl...@or...>]

Nicolas Cannasse wrote:
> 
> > Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> > preference is for spaces, but I'll work with tabs.
> 
> I know that the 4-chars-tabs I'm using are not so good, but it's quite
> difficult for me to start using spaces, since my MSVC editior doesn't allow
> the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
> can still sed files later one finalized for a clean source release.

I vote for spaces.

Maybe you could run that sed command before any commits?

Best,
Blair

-- 
Blair Zajac <bl...@or...>
Plots of your system's performance - http://www.orcaware.com/orca/

Re: [Ocaml-lib-devel] email notices on cvs commits

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

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > > > At work, our cvs is set up to email notices out to a mailing list when
> > > > commits happen.  Any chance of setting up our cvs server to do that?
> > >
> > > I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> > > Since like this you can have a quick look at all modified files.
> >
> > I have added the following to /CVSROOT/loginfo file, but it doesn't seems
> to
> > work :
> >
> > ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log
> 
> Okay, I added the "commit.log" file to CVSROOT and now I get :
> 
> sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied
> 
> when committing a file.
> This seems like a sourceforge-specific problem.
> I will disable it.
> 
> Nicolas Cannasse
> 

CVS commits now return:
sh: /usr/local/bin/cvs-commitmail: No such file or directory
cvs [server aborted]: received broken pipe signal
cvs commit: saving log message in /tmp/cvsaxoz6C

Something's not quite there yet.

Brian

Re: [Ocaml-lib-devel] Indentation

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

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> > preference is for spaces, but I'll work with tabs.
> 
> I know that the 4-chars-tabs I'm using are not so good, but it's quite
> difficult for me to start using spaces, since my MSVC editior doesn't allow
> the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
> can still sed files later one finalized for a clean source release.

I'll handle tabs.  And tabs have the advantage that we don't need to fight 
over what level of indentation to use- set tabstops to whatever the heck 
you like.

It's *mixing* tabs and spaces which is the problem.  Even worse, as
microsoft and unix have different philosphies on how tabs work.  A tab in
unix moves you to the next column to the right whose number is a multiple
of tabstop, while in windows it moves you right tabstop columns.  So if 
you have the sequence "\t \t" at the begining of a line, with a tabstop of 
4, in unix you are in column 8 (the second tab only moves you three 
columns, not 4), while in windows you are in column 9.

If you have several people editing the file, some in unix and some in 
windows, some using tabs and some using spaces, and (of course) everyone 
using different tabstops, indenting become a nightmare.

Brian

Re: [Ocaml-lib-devel] XML Light

[Claudio S. C. <sac...@cs...>]

> I'm currently rewriting my Xml-Light library which is a minimal Xml
> parser/printer and adding DTD support to it.

 Is it? Is it _really_ a minimal XML parser/printer?
 I fear it is just a parser/printer for a minimal _subset_ of XML!
 (e.g. Does it supports UNICODE characters? What about Entities?
  What about Notation? Is it 100% fully compliant with the spec?)

 We do not need yet another standard for documents. Either it is
 fully XML compliant (and there is already PXP - native ocaml -
 or gdome2-ocaml - binding to libgdome) or it is unuseful/threatening.

 					Friendly,
					C.S.C.

-- 
----------------------------------------------------------------
Real name: Claudio Sacerdoti Coen
PhD Student in Computer Science at University of Bologna
E-mail: sac...@cs...
http://www.cs.unibo.it/~sacerdot
----------------------------------------------------------------

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> > > At work, our cvs is set up to email notices out to a mailing list when
> > > commits happen.  Any chance of setting up our cvs server to do that?
> >
> > I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> > Since like this you can have a quick look at all modified files.
>
> I have added the following to /CVSROOT/loginfo file, but it doesn't seems
to
> work :
>
> ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log

Okay, I added the "commit.log" file to CVSROOT and now I get :

sh: /cvsroot/ocaml-lib/CVSROOT/commit.log: Permission denied

when committing a file.
This seems like a sourceforge-specific problem.
I will disable it.

Nicolas Cannasse

Re: [Ocaml-lib-devel] Indentation

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

> Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My
> preference is for spaces, but I'll work with tabs.

I know that the 4-chars-tabs I'm using are not so good, but it's quite
difficult for me to start using spaces, since my MSVC editior doesn't allow
the tab-as-spaces key. so right now I'ld prefer that we stick to tabs :-) We
can still sed files later one finalized for a clean source release.

Nicolas Cannasse

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> > At work, our cvs is set up to email notices out to a mailing list when
> > commits happen.  Any chance of setting up our cvs server to do that?
>
> I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
> Since like this you can have a quick look at all modified files.

I have added the following to /CVSROOT/loginfo file, but it doesn't seems to
work :

ALL (echo ""; id; echo %s; date; cat) >> $CVSROOT/CVSROOT/commit.log


BTW, perhaps sourceforge CVS server is delaying some changes.
If there is any CVS expert around...

Nicolas Cannasse

[Ocaml-lib-devel] Indentation

[Brian H. <bri...@ql...>]

Mixed spaces and tabs are bad.  Let us pick one, and stick with it.  My 
preference is for spaces, but I'll work with tabs.

Brian

Re: [Ocaml-lib-devel] email notices on cvs commits

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

> At work, our cvs is set up to email notices out to a mailing list when 
> commits happen.  Any chance of setting up our cvs server to do that?

I can do it, but I would prefer a "commitlog" file in /CVSROOT/commitlog
Since like this you can have a quick look at all modified files.

Nicolas

Re: [Ocaml-lib-devel] Names for xarray: I propose dynarray

[Brian H. <bri...@ql...>]

On Tue, 22 Apr 2003, Nicolas Cannasse wrote:

> > According to the NIST, what I've implemented is a dynamic array:
> > http://www.nist.gov/dads/HTML/dynamicarray.html
> >
> > I hereby propose we rename it dynarray then.  I'm not worried about losing
> > revision control history- if I hadn't checked it in, we wouldn't have had
> > any to lose :-).
> 
> It would be perhaps nice to have then then same name-prefix for both
> "mutable" list and "mutable" array.
> RefList / RefArray ( this one make sense since the type Xarray.t contains a
> mutable 'array field )
> or
> DynList / DynArray
> 

No insult, but reflist confuses me.  With a few exceptions, it looks like 
it's just a ref to a list, and the functions just dereference the ref and 
call the appropriate list function.  I suppose I'm saying that I'm seeing 
enough meat on the bone here to make it a worthwhile library.

In any case, I don't think both it and xarray (whatever it gets renamed 
to) should have the same prefix.  Arrays in ocaml are already mutable- 
that's implicit.  But their size is immutable once created.  So we're 
adding the feature of being able to resize the array.  Likewise, in 
reflist, we're adding the feature of being able to mutably change the head 
of a list.

For dynlist I'd say it should be fully dynamic, like dynarray is.  Append 
and prepend and insert into the middle.  I need to play with how this 
should work a little.

Hmm.  Playing around a little bit, I notice that:

# let x = [| 1; 2; 3 |];;
val x : int array = [|1; 2; 3|]
# x. (1);;
- : int = 2
# x . (3);;
Exception: Invalid_argument "Array.get".
# x.3;;
Syntax error
# x. 3;;
Syntax error
# let ( %. ) = Array.get ;;
val ( %. ) : 'a array -> int -> 'a = <fun>
# x%.(3);;
Exception: Invalid_argument "Array.get".
# x%.(2);;
- : int = 3
# (3);;
- : int = 3
# x %. 2;;
- : int = 3
# 

Of course, %. looks like a floating point operator.  But this does open 
some possibilities for an accessor operator mostly like .().

Brian