Hello,

in our project we have a lot of modules. Now, we need to include
camlimages to create jpeg-files. But now, we got a namespace conflict,
because our own modules share the same namespace with camlimages,
example: bmp, color and so on.

We need camlimages only to save a jpeg-file

There are any workaround to avoid namespace conflict without renaming
all our modules? Is it possible to decide between "local" modules within
actual dir (our project) and external ocaml dirs...

Could you help?

With best regards

Andreas
--
Andreas Romeyke
- Abteilung Blindenschrift -
Deutsche Zentralbücherei für Blinde zu Leipzig (DZB)
Gustav-Adolf-Straße 7, 04105 Leipzig
Tel: +49 341 7113-..., Fax: +49 341 7113-125
Internet: www.dzb.de
E-Mail: andreas.romeyke <at> dzb.de

[Non-text portions of this message have been removed]

• New Members 3

On Wed, Feb 01, 2012 at 02:47:43PM +0100, Andreas Romeyke wrote:
> Hello,
>
> in our project we have a lot of modules. Now, we need to include
> camlimages to create jpeg-files. But now, we got a namespace conflict,
> because our own modules share the same namespace with camlimages,
> example: bmp, color and so on.
>
> We need camlimages only to save a jpeg-file
>
> There are any workaround to avoid namespace conflict without renaming
> all our modules? Is it possible to decide between "local" modules within
> actual dir (our project) and external ocaml dirs...
>
> Could you help?
>
> With best regards
>
> Andreas

sure, don't use :

open Camlimages

and call :

Camlimages.write_jpeg

(module and function name are prob. wrong, just for the sake of the
example). Still linking with camlimages, of course.

You may also find yourself needing to open some module, i.e.:

open Complex

to use some data structure in your code like {re=x; im=y} while avoiding
a lot of typing, but get stuck later in the same problem as yours with using
for example sqrt.

in that case, do :

module P = Pervasives

and call :

P.sqrt

for a non-complex square root.

--
Philippe Strauss
http://www.philou.ch

• New Members 3

Hello,

Am Mittwoch, den 01.02.2012, 14:57 +0100 schrieb Philippe Strauss:

> sure, don't use :
>
> open Camlimages
>
> and call :
>
> Camlimages.write_jpeg

The problem must have another reason. The interface for our color.ml
will be searched in /usr/lib/ocaml/camlimages first, instead using them
from local path.

By compiling we got now:

ocamlbuild.native -verbose 10 -ocamlrun ocamlrun.opt -ocamlc ocamlc.opt
-ocamlopt ocamlopt.opt -j 4 -tags annot -tags thread -tags debug
-no-links -cflags "-w Aez -I,+dynlink -I /usr/lib/ocaml/bolt -I +threads
-I +lablgtk2 -I +extlib -I +pcre -I +netsys -I +netstring -I +json-wheel
-I +num -I +nums -I +dynlink -I +sexplib -I +zip
-I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I +equeue
-I +netclient -I /home/andreas/projekte/leibniz/trunk/core/_build "
-lflags "-I,+dynlink -I /usr/lib/ocaml/bolt -I +num -I +nums -I +dynlink
-I +sexplib -I +threads -I +lablgtk2 -I +extlib -I +pcre -I +netsys -I
+netstring -I +json-wheel -I +num -I +nums -I +dynlink -I +sexplib -I
+zip -I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I
+equeue -I +netclient
-I /home/andreas/projekte/leibniz/trunk/core/_build " -libs
"unix,pcre,bigarray,netsys_oothr,netsys,netstring,equeue,netclient,jsonwheel,str,dynlink,bolt,extLib,nums,sexplib,zip,camlimages_core,camlimages_all,xml-light,xmlrpc-light" -I helper -I io -I img -I preprocessing -I dictionary -I ocr -I glyphs -I bbox -I segment -I structure -I form -I composite -I pdf -I test -I examples -pp "camlp4o /usr/lib/ocaml/bolt/bolt_pp.cmo -logger 'leibnizcored.native' -level DEBUG -- -I /usr/lib/ocaml/sexplib -I /usr/lib/ocaml/type-conv pa_type_conv.cma pa_sexp_conv.cma pa_macro.cmo -DNEWSEXP" leibnizcored.native
+ ocamlopt.opt -c -w Aez -I +dynlink -I /usr/lib/ocaml/bolt -I +threads
-I +lablgtk2 -I +extlib -I +pcre -I +netsys -I +netstring -I +json-wheel
-I +num -I +nums -I +dynlink -I +sexplib -I +zip
-I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I +equeue
-I +netclient -I /home/andreas/projekte/leibniz/trunk/core/_build -g
-annot -thread -pp 'camlp4o /usr/lib/ocaml/bolt/bolt_pp.cmo -logger
'\''leibnizcored.native'\'' -level DEBUG -- -I /usr/lib/ocaml/sexplib
-I /usr/lib/ocaml/type-conv pa_type_conv.cma pa_sexp_conv.cma
pa_macro.cmo -DNEWSEXP' -I img -I bbox -I ocr -I examples -I io -I test
-I dictionary -I structure -I segment -I preprocessing -I pdf -I
composite -I helper -I glyphs -I form -o img/color.cmx img/color.ml
File "img/color.ml", line 1, characters 0-1:
Error: The implementation img/color.ml
does not match the interface /usr/lib/ocaml/camlimages/color.cmi:
The field `colormap_parse' is required but not provided
The field `color_parse' is required but not provided
The field `brightness' is required but not provided
The field `minus' is required but not provided
The field `plus' is required but not provided
The field `rgb_square_distance' is required but not provided
The field `cmyk' is required but not provided
The field `Cmyk' is required but not provided
The field `rgba' is required but not provided
The field `Rgba' is required but not provided
The field `rgb' is required but not provided
The field `Rgb' is required but not provided
The field `copy' is required but not provided
The field `add_colors' is required but not provided
The field `add_color' is required but not provided
The field `find_exact' is required but not provided
The field `size' is required but not provided
The field `map' is required but not provided
The field `Too_many_colors' is required but not provided
Command exited with code 2.

Any additional hints?

Bye Andreas

--
Andreas Romeyke
- Abteilung Blindenschrift -
Deutsche Zentralbücherei für Blinde zu Leipzig (DZB)
Gustav-Adolf-Straße 7, 04105 Leipzig
Tel: +49 341 7113-..., Fax: +49 341 7113-125
Internet: www.dzb.de
E-Mail: andreas.romeyke <at> dzb.de

[Non-text portions of this message have been removed]

• New Members 3

Hi Andreas,

If I understood correctly, you ran into a quite common problem, which is
tedious to handle with caml. Indeed, if you link with camlimages, the
namespace is occupied with module names Bmp, Blend, Camlimages etc ... and
you can't use these names in your application. The usual workaround *for
the library developper* is to prefix module names with something, here it
should have been Camlimages_bmp, Camlimages_blend etc ... while in the
Camlimages modules you'd have definitions like

module Bmp = Camlimages_bmp
module Blender = Camlimages_blender
etc ...

To my knowledge you only have two choices:
- repackage camlimages with a less agressive namespace consumption (that
maybe complicated because of how camlimages adapts to available C libraries)
- rename your own modules (but I understand this is inconvenient due to the
size of your codebase).

Maybe someone here on the main list has a more satisfactory idea?
ph.

2012/2/1 Andreas Romeyke <andreas.romeyke <at> dzb.de>

> Hello,
>
> Am Mittwoch, den 01.02.2012, 14:57 +0100 schrieb Philippe Strauss:
>
> > sure, don't use :
> >
> > open Camlimages
> >
> > and call :
> >
> > Camlimages.write_jpeg
>
> The problem must have another reason. The interface for our color.ml
> will be searched in /usr/lib/ocaml/camlimages first, instead using them
> from local path.
>
> By compiling we got now:
>
> ocamlbuild.native -verbose 10 -ocamlrun ocamlrun.opt -ocamlc ocamlc.opt
> -ocamlopt ocamlopt.opt -j 4 -tags annot -tags thread -tags debug
> -no-links -cflags "-w Aez -I,+dynlink -I /usr/lib/ocaml/bolt -I +threads
> -I +lablgtk2 -I +extlib -I +pcre -I +netsys -I +netstring -I +json-wheel
> -I +num -I +nums -I +dynlink -I +sexplib -I +zip
> -I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I +equeue
> -I +netclient -I /home/andreas/projekte/leibniz/trunk/core/_build "
> -lflags "-I,+dynlink -I /usr/lib/ocaml/bolt -I +num -I +nums -I +dynlink
> -I +sexplib -I +threads -I +lablgtk2 -I +extlib -I +pcre -I +netsys -I
> +netstring -I +json-wheel -I +num -I +nums -I +dynlink -I +sexplib -I
> +zip -I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I
> +equeue -I +netclient
> -I /home/andreas/projekte/leibniz/trunk/core/_build " -libs
> "unix,pcre,bigarray,netsys_oothr,netsys,netstring,equeue,netclient,jsonwheel,str,dynlink,bolt,extLib,nums,sexplib,zip,camlimages_core,camlimages_all,xml-light,xmlrpc-light"
> -I helper -I io -I img -I preprocessing -I dictionary -I ocr -I glyphs -I
> bbox -I segment -I structure -I form -I composite -I pdf -I test -I
> examples -pp "camlp4o /usr/lib/ocaml/bolt/bolt_pp.cmo -logger
> 'leibnizcored.native' -level DEBUG -- -I /usr/lib/ocaml/sexplib -I
> /usr/lib/ocaml/type-conv pa_type_conv.cma pa_sexp_conv.cma pa_macro.cmo
> -DNEWSEXP" leibnizcored.native
> + ocamlopt.opt -c -w Aez -I +dynlink -I /usr/lib/ocaml/bolt -I +threads
> -I +lablgtk2 -I +extlib -I +pcre -I +netsys -I +netstring -I +json-wheel
> -I +num -I +nums -I +dynlink -I +sexplib -I +zip
> -I /usr/lib/ocaml/camlimages -I +xml-light -I +xmlrpc-light -I +equeue
> -I +netclient -I /home/andreas/projekte/leibniz/trunk/core/_build -g
> -annot -thread -pp 'camlp4o /usr/lib/ocaml/bolt/bolt_pp.cmo -logger
> '\''leibnizcored.native'\'' -level DEBUG -- -I /usr/lib/ocaml/sexplib
> -I /usr/lib/ocaml/type-conv pa_type_conv.cma pa_sexp_conv.cma
> pa_macro.cmo -DNEWSEXP' -I img -I bbox -I ocr -I examples -I io -I test
> -I dictionary -I structure -I segment -I preprocessing -I pdf -I
> composite -I helper -I glyphs -I form -o img/color.cmx img/color.ml
> File "img/color.ml", line 1, characters 0-1:
> Error: The implementation img/color.ml
> does not match the interface /usr/lib/ocaml/camlimages/color.cmi:
> The field `colormap_parse' is required but not provided
> The field `color_parse' is required but not provided
> The field `brightness' is required but not provided
> The field `minus' is required but not provided
> The field `plus' is required but not provided
> The field `rgb_square_distance' is required but not provided
> The field `cmyk' is required but not provided
> The field `Cmyk' is required but not provided
> The field `rgba' is required but not provided
> The field `Rgba' is required but not provided
> The field `rgb' is required but not provided
> The field `Rgb' is required but not provided
> The field `copy' is required but not provided
> The field `add_colors' is required but not provided
> The field `add_color' is required but not provided
> The field `find_exact' is required but not provided
> The field `size' is required but not provided
> The field `map' is required but not provided
> The field `Too_many_colors' is required but not provided
> Command exited with code 2.
>
> Any additional hints?
>
> Bye Andreas
>
> --
> Andreas Romeyke
> - Abteilung Blindenschrift -
> Deutsche Zentralbücherei für Blinde zu Leipzig (DZB)
> Gustav-Adolf-Straße 7, 04105 Leipzig
> Tel: +49 341 7113-..., Fax: +49 341 7113-125
> Internet: www.dzb.de
> E-Mail: andreas.romeyke <at> dzb.de
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Archives up to December 31, 2010 are also downloadable at
> http://www.connettivo.net/cntprojects/ocaml_beginners
> The archives of the very official ocaml list (the seniors' one) can be
> found at http://caml.inria.fr
> Attachments are banned and you're asked to be polite, avoid flames
> etc.Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

• New Members 3

Hello,

according to the manual, the BatArray module can be used to override the
Array module. Also, the notation Array.<function> is used in the manual.
However, I have to use the notation BatArray.<function> instead as the
module is named BatArray. Is this a flaw in the manual or is there a way
to use the Array.<function> notation?
--
Best regards,
Boris

• New Members 5

Hi Boris,

you can use the notation Array.<function> once you

open Batteries

the Batteries module is essentially composed of definitions like
module Array = BatArray
module List = BatList
etc ...

hth,
ph.

2012/2/5 Boris Hollas <hollas <at> informatik.htw-dresden.de>

> Hello,
>
> according to the manual, the BatArray module can be used to override the
> Array module. Also, the notation Array.<function> is used in the manual.
> However, I have to use the notation BatArray.<function> instead as the
> module is named BatArray. Is this a flaw in the manual or is there a way
> to use the Array.<function> notation?
> --
> Best regards,
> Boris
>
>
>
> ------------------------------------
>
> Archives up to December 31, 2011 are also downloadable at
> http://www.connettivo.net/cntprojects/ocaml_beginners
> The archives of the very official ocaml list (the seniors' one) can be
> found at http://caml.inria.fr
> Attachments are banned and you're asked to be polite, avoid flames
> etc.Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

• New Members 5

Hello Philippe,

> open Batteries

now the compiler complains that no implementation is provided for module
Batteries.

I use ocamlfind ocamlopt -package sdl,batteries -linkpkg to compile and
ocamlfind -list shows batteries.

Also, if I have open Bigarray after open Batteries, does the former then
refer to BatBigarray?

--
Best regards,
Boris

• New Members 5

2012/2/5 Boris Hollas <hollas <at> informatik.htw-dresden.de>

> Hello Philippe,
>
> > open Batteries
>
> now the compiler complains that no implementation is provided for module
> Batteries.
>
Please double-check what I'm going to say, but this comes from a dependency
of batteries on threads. However, the error message is buggy, but I never
went on to see why. You should either

open Batteries_uni

insteand of Batteries (so that you don't have a dependency on threads
anymore) or modify your compilation command to add threads (basically with
-thread and -package threads)

>
> I use ocamlfind ocamlopt -package sdl,batteries -linkpkg to compile and
> ocamlfind -list shows batteries.
>
> Also, if I have open Bigarray after open Batteries, does the former then
> refer to BatBigarray?
>
Yes, exactly.

>
> --
> Best regards,
> Boris
>
>
>
> ------------------------------------
>
> Archives up to December 31, 2011 are also downloadable at
> http://www.connettivo.net/cntprojects/ocaml_beginners
> The archives of the very official ocaml list (the seniors' one) can be
> found at http://caml.inria.fr
> Attachments are banned and you're asked to be polite, avoid flames
> etc.Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

• New Members 5

On Sun, 2012-02-05 at 11:44 +0100, Philippe Veber wrote:

> open Batteries_uni

alright, this works. Quite confusing, though.

--
Best regards,
Boris

[Non-text portions of this message have been removed]

• New Members 5

The next version of batteries will remove Batteries_uni and use Batteries
instead (hopefully only BatteriesThread would depend on threading). This is
all explained in the "usage documentation" (linked from the README):

https://github.com/ocaml-batteries-team/batteries-included/wiki/Getting-started

On Sun, Feb 5, 2012 at 12:06 PM, Boris Hollas <
hollas <at> informatik.htw-dresden.de> wrote:

> On Sun, 2012-02-05 at 11:44 +0100, Philippe Veber wrote:
>
> > open Batteries_uni
>
>
> alright, this works. Quite confusing, though.
>
> --
> Best regards,
> Boris
>
>
> [Non-text portions of this message have been removed]
>
>
>
> ------------------------------------
>
> Archives up to December 31, 2011 are also downloadable at
> http://www.connettivo.net/cntprojects/ocaml_beginners
> The archives of the very official ocaml list (the seniors' one) can be
> found at http://caml.inria.fr
> Attachments are banned and you're asked to be polite, avoid flames
> etc.Yahoo! Groups Links
>
>
>
>

[Non-text portions of this message have been removed]

• New Members 5