ocaml-lib-devel — Developer's mailing list

[Ocaml-lib-devel] Re: Install .mli files?

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

Bardur Arantsson wrote:
> Bardur Arantsson wrote:
> 
>> Hi again,
>>
>> Is there any particular reason that the ExtLib .mli files aren't
>> installed by 'make install'?
>>
>> It would sometimes be handy to have them installed for reference, so if
>> nobody objects within a few days, I'll add code to the Makefile and
>> install.ml to install them.
>> Cheers,
>>
> 
> I'll apply and commit the attached patch later today.
> 
> (Here's to hoping that posting to gmane also sends to the list. :))
> 

committed.

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- Who says staring isn't exciting?
               World Staring Championship Commentator, 'Big Train'

Re: [Ocaml-lib-devel] Re: Extlib.DynArray unstable

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

> extlib-1.3 is the latest release, but unfortunately the DynArray 
> implementation contained some serious bugs.

To be exact, there was a bug in ocaml runtime, not in DynArray ;)

> > Or are you saying I need to download ocaml from CVS?   I have their
> > 3.08.1 tarball.
> > 
> 
> I shouldn't think you need a newer OCaml. Just getting ExtLib from CVS 
> should be sufficient.

Since the bug have been corrected on ocaml cvs, both are ok.

Nicolas

[Ocaml-lib-devel] Re: Extlib.DynArray unstable

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

Nicolas Cannasse wrote:
> Looks like you're using an old version of ExtLib.
> There was a temporary fix in the "idup" function of DynArray which prevent
> this ocaml bug from happening ( there was a bug in Obj.dup implementation
> which must have been fixed on ocaml-cvs ).
> Maybe we could make a bug-fix release of extlib since several patches have
> been applied ?

I think we should, but I'll just commit the Makefile/install.ml changes 
to install .mli files first. I'll commit right after sending this...

(I'll hold off on the {input,output}_file_descr thingy...)

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- It's just like the story of the grasshopper and the octopus.
All year long, the grasshopper kept burying acorns for the
winter, while the octopus mooched off his girlfriend and watched
TV. But then the winter came, and the grasshopper died, and the
octopus ate all his acorns. And also he got a racecar. Is any of
this getting through to you?
                                                   Fry, 'Futurama'

[Ocaml-lib-devel] Re: Extlib.DynArray unstable

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

HENRIKSON, JEFFREY wrote:
>>Looks like you're using an old version of ExtLib.
>>There was a temporary fix in the "idup" function of DynArray 
>>which prevent this ocaml bug from happening ( there was a bug 
>>in Obj.dup implementation which must have been fixed on 
>>ocaml-cvs ). Maybe we could make a bug-fix release of extlib 
>>since several patches have been applied ?
> 
> 
> I downloaded a tarball from sourceforge called
> 
> extlib-1.3.tgz
> 
> Is this old?  I don't see a newer one posted.
>

extlib-1.3 is the latest release, but unfortunately the DynArray 
implementation contained some serious bugs.

> Or are you saying I need to download ocaml from CVS?   I have their
> 3.08.1 tarball.
> 

I shouldn't think you need a newer OCaml. Just getting ExtLib from CVS 
should be sufficient.

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

If a tree falls in the forest, and kills a mime, does anyone
care?
                                                       Gary Larson

Re: [Ocaml-lib-devel] Extlib.DynArray unstable

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

> I downloaded a tarball from sourceforge called
>
> extlib-1.3.tgz
>
> Is this old?  I don't see a newer one posted.

Yes. the bug was reported after 1.3 release

> Or are you saying I need to download ocaml from CVS?  I have their
> 3.08.1 tarball.

I think one of the two following will fix the bug : update ocaml from cvs OR
update extlib from CVS.
The bug itself comes from ocaml and extlib-cvs have a patch for a workaround
before the bug is fixed ( should be in ocaml-3.08.3  ).

Nicolas

RE: [Ocaml-lib-devel] Extlib.DynArray unstable

[HENRIKSON, J. <JE...@SA...>]

> Looks like you're using an old version of ExtLib.
> There was a temporary fix in the "idup" function of DynArray=20
> which prevent this ocaml bug from happening ( there was a bug=20
> in Obj.dup implementation which must have been fixed on=20
> ocaml-cvs ). Maybe we could make a bug-fix release of extlib=20
> since several patches have been applied ?

I downloaded a tarball from sourceforge called

extlib-1.3.tgz

Is this old?  I don't see a newer one posted.

Or are you saying I need to download ocaml from CVS?  I have their
3.08.1 tarball.


Jeff




> -----Original Message-----
> From: Nicolas Cannasse [mailto:war...@fr...]=20
> Sent: Wednesday, March 02, 2005 11:21 AM
> To: HENRIKSON, JEFFREY
> Subject: Re: [Ocaml-lib-devel] Extlib.DynArray unstable
>=20
>=20
> Looks like you're using an old version of ExtLib.
> There was a temporary fix in the "idup" function of DynArray=20
> which prevent this ocaml bug from happening ( there was a bug=20
> in Obj.dup implementation which must have been fixed on=20
> ocaml-cvs ). Maybe we could make a bug-fix release of extlib=20
> since several patches have been applied ?
>=20
> Nicolas
>=20
> ----- Original Message -----=20
> From: "HENRIKSON, JEFFREY" <JE...@SA...>
> To: <oca...@li...>
> Sent: Wednesday, March 02, 2005 7:55 PM
> Subject: [Ocaml-lib-devel] Extlib.DynArray unstable
>=20
>=20
> Hello,
>=20
> I find DynArray very unstable on my machine, and will have to=20
> revert my code back to Markus Mottl's Res library for the time being.
>=20
> Just calling (of_array [||]) several times will cause a segfault on my
> machine:
>=20
>         Objective Caml version 3.08.1
>=20
> # # #directory "+site-lib/extlib";;
> # #load "extLib.cma";;
> # open ExtLib;;
> # DynArray.of_array [||];;
> - : '_a DynArray.t =3D <abstr>
> # DynArray.of_array [||];;
> - : '_a DynArray.t =3D <abstr>
> # DynArray.of_array [||];;
> - : '_a DynArray.t =3D <abstr>
> # DynArray.of_array [||];;
> - : '_a DynArray.t =3D <abstr>
> # DynArray.of_array [||];;
>=20
> Process caml-toplevel segmentation fault
>=20
> It's not completely deterministic.  It can require varying=20
> number of calls to get the segfault but usually less than 10.=20
>  This test was performed on Linux.  I can provide more=20
> details about the configuration if you have trouble=20
> reproducing the problem.
>=20
> Regards,
>=20
>=20
> Jeff Henrikson
>=20
>=20

Re: [Ocaml-lib-devel] Extlib.DynArray unstable

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

Looks like you're using an old version of ExtLib.
There was a temporary fix in the "idup" function of DynArray which prevent
this ocaml bug from happening ( there was a bug in Obj.dup implementation
which must have been fixed on ocaml-cvs ).
Maybe we could make a bug-fix release of extlib since several patches have
been applied ?

Nicolas

----- Original Message ----- 
From: "HENRIKSON, JEFFREY" <JE...@SA...>
To: <oca...@li...>
Sent: Wednesday, March 02, 2005 7:55 PM
Subject: [Ocaml-lib-devel] Extlib.DynArray unstable


Hello,

I find DynArray very unstable on my machine, and will have to revert my
code back to Markus Mottl's Res library for the time being.

Just calling (of_array [||]) several times will cause a segfault on my
machine:

        Objective Caml version 3.08.1

# # #directory "+site-lib/extlib";;
# #load "extLib.cma";;
# open ExtLib;;
# DynArray.of_array [||];;
- : '_a DynArray.t = <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t = <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t = <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t = <abstr>
# DynArray.of_array [||];;

Process caml-toplevel segmentation fault

It's not completely deterministic.  It can require varying number of
calls to get the segfault but usually less than 10.  This test was
performed on Linux.  I can provide more details about the configuration
if you have trouble reproducing the problem.

Regards,


Jeff Henrikson

[Ocaml-lib-devel] re: Extlib.DynArray unstable

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

> I find DynArray very unstable on my machine, and will have to revert my
> code back to Markus Mottl's Res library for the time being.
>
> Just calling (of_array [||]) several times will cause a segfault on my
> machine:

I couldn't reproduce this with the CVS version.  I tried running this
(added into the test suite) and it doesn't crash:

<snip>
let test_regr_1 () =
  for i = 0 to 30 do
    ignore (DynArray.of_array [||])
  done
</snip>

Maybe it's time for a bugfix release of ExtLib soon?

Best regards,
Janne

[Ocaml-lib-devel] Extlib.DynArray unstable

[HENRIKSON, J. <JE...@SA...>]

Hello,

I find DynArray very unstable on my machine, and will have to revert my
code back to Markus Mottl's Res library for the time being.

Just calling (of_array [||]) several times will cause a segfault on my
machine:

        Objective Caml version 3.08.1

# # #directory "+site-lib/extlib";;
# #load "extLib.cma";;
# open ExtLib;;
# DynArray.of_array [||];;
- : '_a DynArray.t =3D <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t =3D <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t =3D <abstr>
# DynArray.of_array [||];;
- : '_a DynArray.t =3D <abstr>
# DynArray.of_array [||];;

Process caml-toplevel segmentation fault

It's not completely deterministic.  It can require varying number of
calls to get the segfault but usually less than 10.  This test was
performed on Linux.  I can provide more details about the configuration
if you have trouble reproducing the problem.

Regards,


Jeff Henrikson

[Ocaml-lib-devel] Re: Install .mli files?

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

Bardur Arantsson wrote:
> Hi again,
> 
> Is there any particular reason that the ExtLib .mli files aren't
> installed by 'make install'?
> 
> It would sometimes be handy to have them installed for reference, so if
> nobody objects within a few days, I'll add code to the Makefile and
> install.ml to install them. 
> 
> Cheers,
> 

I'll apply and commit the attached patch later today.

(Here's to hoping that posting to gmane also sends to the list. :))

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

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

Re: [Ocaml-lib-devel] Adding file_descr support to IO?

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

(CC'd to the mailing list, I hope you don't mind)

On Mon, Feb 28, 2005 at 09:27:03PM +0200, Janne Hellsten wrote:

> Comments on the module:

> 1. When you call Unix.write, you don't do any error translation into
> ExtLib IO exceptions. I never use ExtLib's IO, but shouldn't the
> O'Camls Unix errors be converted into something more ExtLib?

IMHO, any translation will just obscure real problems -- and to be able
to give the caller enough exception information, any "new" exceptions
would be almost identical to the Unix ones. Better to have a shallow
interface, IMHO. Besides, the caller *knows* that Unix.{write,read,...}
will be used, so they should know which exceptions can be raised from
those.

> What if "Unix.write" returns something else than the number of bytes in
> the buffer?  You just silently ignore that.

Unix.write *will* actually always write the number of bytes given to it
(see the doc) unless the is an error. If any error occurs, an exception
is raised by the Unix module. So this is a non-issue.

> 2. I guess you know already, but perhaps you meant extUnix and not
> extunix for the filenames?

I'm not sure I follow... are you talking about the attachments? In my MUA
the names are shown as "extUnix.ml" and "extUnit.mli".

> 3. How about the Makefiles then?  I gather this would need additional
> libraries in order to be able to link this separately from the rest of
> ExtLib.

Hmm... I *think* this is all taken care of by the linker; it shouldn't
link in Unix unless functions which require it are called from the
program being linked. (Otherwise, using one ExtLib module would seem to
imply that the code for all of them is automatically included... which I
hope isn't the case).

AFAIK the Unix module is available on all platforms, so from an
avaiability perspective it shouldn't be an issue.

> I anticipate that ExtUnix module would also some day need C files as
> well, since it's pretty low-level stuff.  I wonder if the rule against
> C files should be relaxed w.r.t this module?

My opinion is that ExtLib should be limited to pure OCaml code, but this
is mostly from a practical perspective... supporting C code on lots of
platforms (different versions of different OS'es, architectures, etc.)
can be extremely time-consuming... add to this the fact that the
semantics of system calls may differ subtly between platforms and you
have a recipe for disaster, IMHO.

Cheers,

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- Good... Bad... I'm the guy with the gun.
                                           Ash | Army of Darkness

Re: [Ocaml-lib-devel] Adding file_descr support to IO?

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

Hi,

As promised, here's the ExtUnix module (attached). Please let me know if
you can spot any (potential) problems.

I'll add and commit in a few days if no problems are reported.

Cheers,

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

The wages of sin is death, but so is the salary of virtue, and at
least the evil get to go home early on Fridays.
                                 Terry Pratchett | Witches Abroad

[Ocaml-lib-devel] Install .mli files?

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

Hi again,

Is there any particular reason that the ExtLib .mli files aren't
installed by 'make install'?

It would sometimes be handy to have them installed for reference, so if
nobody objects within a few days, I'll add code to the Makefile and
install.ml to install them. 

Cheers,

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- Leela, save me! And yourself I guess... and my banjo... and
Fry!
                                                Bender | Futurama

Re: [Ocaml-lib-devel] Adding file_descr support to IO?

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

On Mon, Feb 28, 2005 at 07:51:29AM +0100, Nicolas Cannasse wrote:

> > Hi all,

> > I was just wondering if anyone would mind me adding a couple of functions
> > with signatures

> >      val input_file_descr : Unix.file_descr -> IO.input;
> >      val output_file_descr : Unix.file_descr -> unit IO.output;

> > to the IO module? The idea is to use

> >     Unix.read
> >     Unix.single_write
> >     Unix.close

> > to read/write directly to/from the file descriptor. There shouldn't
> > really be any platform-specific issues since these functions of the Unix
> > module are supported on all platforms.

> > Any objections?

> Yes.
> It creates a dependency on Unix module, which force the user using IO to
> link with unix.cma / cmxa.
> I would prefer theses to go into an ExtUnix module.

Ok, no problem. I'll post an ExtUnix module for review in
a little while. :)

Cheers,

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- Me, me, me... and me!
                               Agent Smith | The Matrix: Reloaded

Re: [Ocaml-lib-devel] Adding file_descr support to IO?

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

> Hi all,
>
> I was just wondering if anyone would mind me adding a couple of functions
> with signatures
>
>      val input_file_descr : Unix.file_descr -> IO.input;
>      val output_file_descr : Unix.file_descr -> unit IO.output;
>
> to the IO module? The idea is to use
>
>     Unix.read
>     Unix.single_write
>     Unix.close
>
> to read/write directly to/from the file descriptor. There shouldn't
> really be any platform-specific issues since these functions of the Unix
> module are supported on all platforms.
>
> Any objections?

Yes.
It creates a dependency on Unix module, which force the user using IO to
link with unix.cma / cmxa.
I would prefer theses to go into an ExtUnix module.

Regards,
Nicolas Cannasse

[Ocaml-lib-devel] Adding file_descr support to IO?

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

Hi all,

I was just wondering if anyone would mind me adding a couple of functions
with signatures

     val input_file_descr : Unix.file_descr -> IO.input;
     val output_file_descr : Unix.file_descr -> unit IO.output;

to the IO module? The idea is to use

    Unix.read
    Unix.single_write
    Unix.close

to read/write directly to/from the file descriptor. There shouldn't
really be any platform-specific issues since these functions of the Unix
module are supported on all platforms.

Any objections?

-- 
Bardur Arantsson
<ba...@im...>
<ba...@sc...>

- This is the worst kind of discrimination. The kind against me!
                                                Bender | Futurama

Re: [Ocaml-lib-devel] Dbi in ocaml-lib again

[Richard W. M. J. <ri...@me...>]

On Thu, Feb 10, 2005 at 11:24:41AM +0100, Nicolas Cannasse wrote:
> Would you consider the following :  making your Dbi drivers implementations
> dependent of ExtLib, and keep the Dbi module only in ExtLib ? If not, I
> agree with Dbi removal there it's obviously a problem to have it in two
> libraries.

I have, for now, removed Dbi from Extlib.

I'm not sure it really fits there for aesthetic reasons apart from
anything else.  Extlib currently has data structures (DynArray) and
extensions to the basic library (ExtList).  How does Dbi fit with
this?

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] Constructing lists

[skaller <sk...@us...>]

On Fri, 2005-02-18 at 10:47, Richard Jones wrote:
> A common pattern, one which I use frequently anyway, is to write a
> pair of functions like this:
> 
>   let add_elem, get_elems =
>     let elems = ref [] in
>     let add_elem r = elems := r :: !elems in
>     let get_elems () = List.rev !elems in
>     add_elem, get_elems;;
> 
> followed by imperative-style code to add elements to the list, and
> finally return the list with get_elems ().

I do this often, but I don't really think it warrants
inclusion in the library, I doubt I'd remember the
name of the function, also, often I prefer to get
the list reversed. In addition, it fixes the list
to start empty, sometimes I need a starting list,
and it also hides the list during construction,
whereas I sometimes need to pattern match on it
or other things. OTOH the actual idiom

	let elems = ref [] in
	..
	elems := .. :: !elems
	..

is fairly simple and only requires one name to be invented,
instead of two. The library code does provide some
abstraction, but not enough I think.

Of more interest to me, and also probably not worth
having in the library is:

	let direction_t = [`f | `r]
	let 'a d_list_t = private { d: direction_t; l: 'a list }

	mkfwd l
	mkrev l
	getfwd l
	getrev l
	getlst l
	isfwd l

which keeps track of the direction of a list: at present I
use lots of multi-pass algorithms and find it so hard to
track the direction of a list, I've adopted the convention
they're always forward, sometimes writing

	l .. (* in reverse order *)
	let l = rev l in (* enforce convention *)
	..
	let l = rev (x:: (rev l))

to append an element .. when the list was naturally
in reverse order anyhow.

The wrapper I suggest uses 'getfwd' and 'getrev' to get
the list in a particular order, but now I can write
routines that pass d_list_t about, and note that any
order independent processing can be done efficiently,
and order dependent processing is self-optimising.

But I doubt this is generally useful enough to put in
a library .. and the encoding is quite simple.

Note your suggestion and mine are related messily,
I sometimes build lists imperatively and sometimes
functionally, and it is a mess. I also sometimes
destroy list with a tail recursion, sometimes
with an imperative structure and a loop and sometimes
using an HOF... I think it is probably better to leave
this mess exposed, and NOT to abstract it, so it is
easier to refactor. This is also why I use lots
of algebraic data types instead of abstractions,
even when the latter seems appropriate -- abstractions
break with design changes and refactorings.

-- 
John Skaller, mailto:sk...@us...
voice: 061-2-9660-0850, 
snail: PO BOX 401 Glebe NSW 2037 Australia
Checkout the Felix programming language http://felix.sf.net

[Ocaml-lib-devel] Constructing lists

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

A common pattern, one which I use frequently anyway, is to write a
pair of functions like this:

  let add_elem, get_elems =
    let elems = ref [] in
    let add_elem r = elems := r :: !elems in
    let get_elems () = List.rev !elems in
    add_elem, get_elems;;

followed by imperative-style code to add elements to the list, and
finally return the list with get_elems ().

Could ExtList contain such a "list building" function?  ie. It would
be a function which returned a pair of functions as above, something
like:

  let add, get = ExtList.List.build ()

where build would be defined as:

  let build () =
    let xs = ref [] in
    let add x = xs := x :: !xs in
    let get () = List.rev !xs in
    add, get

Thoughts?

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] Re: [Caml-list] String to list to string

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

On Tue, Feb 15, 2005 at 08:34:03AM -0500, Eric C. Cooper wrote:
> On Tue, Feb 15, 2005 at 10:33:16AM +0000, Richard Jones wrote:
> > If you can suggest suitable fold_left and fold_right functions, then
> > they can be added to ExtLib.
> 
> Here's what I use:
> 
> val string_fold_left : ('a -> char -> 'a) -> 'a -> string -> 'a
> val string_fold_right : (char -> 'a -> 'a) -> 'a -> string -> 'a
> 
> let string_fold_left f init str =
>   let n = String.length str in
>   let rec loop i result =
>     if i = n then result
>     else loop (i + 1) (f result str.[i])
>   in
>   loop 0 init
> 
> let string_fold_right f init str =
>   let n = String.length str in
>   let rec loop i result =
>     if i = 0 then result
>     else
>       let i' = i - 1 in
>       loop i' (f str.[i'] result)
>   in
>   loop n init

No one had any objections, so I added these and implode/explode to
ExtString.

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] Re: [Caml-list] String to list to string

[Eric C. C. <ec...@cm...>]

On Tue, Feb 15, 2005 at 10:33:16AM +0000, Richard Jones wrote:
> If you can suggest suitable fold_left and fold_right functions, then
> they can be added to ExtLib.

Here's what I use:

val string_fold_left : ('a -> char -> 'a) -> 'a -> string -> 'a
val string_fold_right : (char -> 'a -> 'a) -> 'a -> string -> 'a

let string_fold_left f init str =
  let n = String.length str in
  let rec loop i result =
    if i = n then result
    else loop (i + 1) (f result str.[i])
  in
  loop 0 init

let string_fold_right f init str =
  let n = String.length str in
  let rec loop i result =
    if i = 0 then result
    else
      let i' = i - 1 in
      loop i' (f str.[i'] result)
  in
  loop n init

-- 
Eric C. Cooper          e c c @ c m u . e d u

[Ocaml-lib-devel] Re: [Caml-list] String to list to string

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

On Mon, Feb 14, 2005 at 08:16:51PM -0500, Aaron Bohannon wrote:
> Instead of adding one of these functions, I would much rather see a=20
> "fold" function on strings in the String module.  The Array module has=20
> both "iter" and "fold" functions.  Why, then, would the String module=20
> provide an "iter" but no "fold"--in a functional language??  The=20
> addition of a fold function would very often eliminate the need to=20
> convert a string to a char list or to introduce imperative-style=20
> programming into an otherwise purely functional section of code (not to=
=20
> mention that writing "char_list_of_string" would become trivial if it=20
> ever were necessary to do so).
>=20
> I acknowledge the fact that I can write my own fold function, but I just=
=20
> wanted to point out that this seems to be the most logical addition to=20
> the String module.

If you can suggest suitable fold_left and fold_right functions, then
they can be added to ExtLib.

Rich.

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

Re: [Ocaml-lib-devel] [PATCH] dllist.ml promote/demote bug

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

> If a Dllist has only two nodes, it breaks when one uses
> the demote and promote functions.
>
> The patch is trivial.  If a node's next and prev fields point to the
> same node, don't do anything.  A patch follows in the body of this
> email.

Thanks this is now fixed on CVS.

Nicolas

[Ocaml-lib-devel] SourceForge and bug tracking

[Christopher W. <crw...@gm...>]

  Apparently, Sourceforge mailing lists don't like random posts from
Hotmail accounts...

  Anyway,  re Bardur Arantsson's post, the page,
(http://sourceforge.net/docman/display_doc.php?docid=14041&group_id=1#tracker),
gives instructions on how to remove the trackers from the Summary
page.  Also, one of the projects admins can follow the link
(https://sourceforge.net/project/admin/preferred_support.php?group_id=74666)
to set the project's "Preferred Support Mechanism".

-
Christopher R. Wedman

[Ocaml-lib-devel] [PATCH] dllist.ml promote/demote bug

[Christopher W. <crw...@gm...>]

If a Dllist has only two nodes, it breaks when one uses
the demote and promote functions.

(* Example code: *)

let lst = Dllist.create 1 ;;
Dllist.append lst 2 ;;
Dllist.demote lst ;;
Dllist.length lst ;; (* <-- hangs here *)

let lst = Dllist.create 1 ;;
Dllist.append lst 2 ;;
Dllist.promote lst ;;
Dllist.length lst ;; (* <-- returns 1, but should be 2 *)

(* End code *)


The patch is trivial.  If a node's next and prev fields point to the
same node, don't do anything.  A patch follows in the body of this
email.

-
Christopher R. Wedman


Index: dllist.ml
===================================================================
RCS file: /cvsroot/ocaml-lib/extlib-dev/dllist.ml,v
retrieving revision 1.1
diff -u -r1.1 dllist.ml
--- dllist.ml	20 Sep 2004 04:44:38 -0000	1.1
+++ dllist.ml	12 Feb 2005 19:58:41 -0000
@@ -62,22 +62,28 @@
 let promote node =
 	let next = node.next in
 	let prev = node.prev in
-	next.next.prev <- node;
-	node.next <- next.next;
-	node.prev <- next;
-	next.next <- node;
-	next.prev <- prev;
-	prev.next <- next
+  if not (next == prev) then
+	begin
+		next.next.prev <- node;
+		node.next <- next.next;
+		node.prev <- next;
+		next.next <- node;
+		next.prev <- prev;
+		prev.next <- next
+	end
 
 let demote node =
 	let next = node.next in
 	let prev = node.prev in
-	prev.prev.next <- node;
-	node.prev <- prev.prev;
-	node.next <- prev;
-	prev.prev <- node;
-	prev.next <- next;
-	next.prev <- prev
+  if not (next == prev) then
+	begin
+		prev.prev.next <- node;
+		node.prev <- prev.prev;
+		node.next <- prev;
+		prev.prev <- node;
+		prev.next <- next;
+		next.prev <- prev
+	end
 
 let remove node =
 	let next = node.next in