[Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Berke Durak]

Hello,

I'm doing some ``real-time'' video processing experiments with Ocaml
(such as simple motion detection). I'm using the module Graphics for
displaying grayscale images captured from a video camera. The program
spends a significant amount of time in Graphics.make_image, which, for
every RGB value, looks up its pixel in a color cache.

First the color cache in otherlibs/graph/color.c is too small (512
entries). So if I overlay my image with, say, red and blue zones,
totaling more than 512 colors, make_image gets terribly slow (I spent
an entire evening tracking out this mysterious slowdown). As a fix I
set it to 4096 entries which corrected the slowdown (until I buy a
color camera, that is).

Second, it would be really nice to have an efficient interface between
Bigarray and Graphics : a procedure for (quickly) converting either
a m x n x 3 RGB byte array or a m x n byte array with a given palette
into an image.

Third, I find that the coordinate convention (increasing y coordinates
get you higher in the screen) is counter to current practice (CRTs
scan from top to bottom ; matrices are also written from top to
bottom). Further, it is contradictory with the semantics of
make_image, since the higher the row number is, the lower you get on
the screen. I personally use (row,column) semantics, which is also
contrary to current (column,row) semantics, but I find it more
mathematical. A minor point.

Fourth, Bigarray syntax does not work with Camlp4 ; a pity since streams
are much faster with Camlp4.

Fifth, and most important point (since I can't hack it myself) : I'd
really like to see access to Bigarrays optimized. Currently, they are
not (library call for each access). As a palliative a function for
inter-converting portions of Bigarrays and strings would be welcome,
as access to strings is much faster.

Thanks for bringing us Ocaml and keep up the good work !
--
Berke
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

[Caml-list] Re: Some suggested improvements to the Graphics and Bigarray modules

[Christopher Quinn]

>  As a palliative a function for
> inter-converting portions of Bigarrays and strings would be welcome,
> as access to strings is much faster.
> 

If you don't mind giving up a bit of safety the following may help. 

Chris Q.

module UnsafeStringOps = struct
  (* Warning: No bounds checking!!!! Coredump grade hack *)

  let ba2str : ('a,'b,'c) Bigarray.Array1.t -> string =
    fun arr -> Obj.obj (Obj.field (Obj.repr arr) 1)

(* Or more properly:
external ba2str: ('a,'b,'c) Bigarray.Array1.t -> string ="ba2str"

where from C you put:
#include <bigarray.h>
value ba2str(value arr){ return Data_bigarray_val(arr); }
*)

  let blit = String.unsafe_blit
  let fill = String.unsafe_fill
  let set = String.unsafe_set
  let get = String.unsafe_get
end
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

RE: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Jeff Henrikson]

> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).

Sounds like you need some vanilla blitting functionality rather than the high level graphics library.  I hacked lablgtk to have a
function that took a bigarray representing 32 bits per pixel (8 are padding) and blit it to the screen using the GDK call
gdk_rgb_32_image.  I also wrote one C function to do a special case of alpha composting bigarrays together in ARGB format.  (The
wrappers for the so called "rgb" functions of GDK are not included in GTK.)  Unfortunately, this makes lablgtk depend on bigarray,
so it's probably not fit to include in the distribution.

Anyway, they run at not a large constant factor from memcpy speed, I can make a patch if you'd like.  You'll probably have to add a
little C code onto what I did to make it do the thing that you wanted exactly.  But it sounds like not a big learning curve since
you presumably already wrote C code to talk to your camera.


Jeff Henrikson



> -----Original Message-----
> From: owner-caml-list@pauillac.inria.fr
> [mailto:owner-caml-list@pauillac.inria.fr]On Behalf Of Berke Durak
> Sent: Tuesday, October 09, 2001 5:32 PM
> To: caml-list@inria.fr
> Subject: [Caml-list] Some suggested improvements to the Graphics and
> Bigarray modules
>
>
> Hello,
>
> I'm doing some ``real-time'' video processing experiments with Ocaml
> (such as simple motion detection). I'm using the module Graphics for
> displaying grayscale images captured from a video camera. The program
> spends a significant amount of time in Graphics.make_image, which, for
> every RGB value, looks up its pixel in a color cache.
>
> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).
>
> Second, it would be really nice to have an efficient interface between
> Bigarray and Graphics : a procedure for (quickly) converting either
> a m x n x 3 RGB byte array or a m x n byte array with a given palette
> into an image.
>
> Third, I find that the coordinate convention (increasing y coordinates
> get you higher in the screen) is counter to current practice (CRTs
> scan from top to bottom ; matrices are also written from top to
> bottom). Further, it is contradictory with the semantics of
> make_image, since the higher the row number is, the lower you get on
> the screen. I personally use (row,column) semantics, which is also
> contrary to current (column,row) semantics, but I find it more
> mathematical. A minor point.
>
> Fourth, Bigarray syntax does not work with Camlp4 ; a pity since streams
> are much faster with Camlp4.
>
> Fifth, and most important point (since I can't hack it myself) : I'd
> really like to see access to Bigarrays optimized. Currently, they are
> not (library call for each access). As a palliative a function for
> inter-converting portions of Bigarrays and strings would be welcome,
> as access to strings is much faster.
>
> Thanks for bringing us Ocaml and keep up the good work !
> --
> Berke
> -------------------
> Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
> To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr
>

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

RE: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Chris Hecker]

>I also wrote one C function to do a special case of alpha composting bigarrays together in ARGB format.

Did you try writing this in caml?  I'd think you could get pretty close, speedwise, and it'd be interesting to find out.

Chris

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

RE: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Jeff Henrikson]

> >I also wrote one C function to do a special case of alpha composting bigarrays together in ARGB format.
>
> Did you try writing this in caml?  I'd think you could get pretty close, speedwise, and it'd be interesting to find out.

No, I didn't try.  I would have had I felt it was easier to get correct on caml, but frankly, the code is so small that I didn't
feel it was an advantage.

Besides, C is pretty darn expressive when all you are doing is pushing bits.  I still can't remember all the lsl lsr asr lor
operations, (along with their fixity and precidence convention) by memory.  And never mind that those names are all renamed
randomly for int32s.  They are made prefix rather than infix and the convention of the word "logical" is reversed:

lsl (the l is for "logical")  left_shift
lsr (the l is for "logical")  right_shift_logical
asr (the a is for "arithmetic"?) shift_right
lor                              logor

On the other hand I can remember >> << ~ | and &.

Also, I find the caml for loop's lack of functionality annoying.  I really should learn camlp4 so I can write a real C-style for
loop.  (with break and continue, though it's not pertinent here.)  Somebody doesn't have such things convieniently lying around do
they?

On performance, the conventional encoding of alpha uses all 8 bits.  Since caml ints are only 31 bits, this means using int32s.
Though I keep hearing stuff about int32s not being that slow, I have a hard time believing just from a machine op count point of
view that using int32s could really compete in such an innermost loop as a pixel operation.

The caml int32 vs C benchmark would be interesting, but I'm not sure interesting enough to overcome my threshold of laziness for me
to go back and rewrite something that works.

Oh, and then there's also the bytecode/asmcode interoperability problem, which is another vote for C.


Jeff Henrikson




> -----Original Message-----
> From: Chris Hecker [mailto:checker@d6.com]
> Sent: Wednesday, October 10, 2001 3:05 AM
> To: Jeff Henrikson; Berke Durak
> Cc: caml-list@inria.fr
> Subject: RE: [Caml-list] Some suggested improvements to the Graphics and
> Bigarray modules
>
>
>
> >I also wrote one C function to do a special case of alpha composting bigarrays together in ARGB format.
>
> Did you try writing this in caml?  I'd think you could get pretty close, speedwise, and it'd be interesting to find out.
>
> Chris
>

-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[John Prevost]

>>>>> "jh" == Jeff Henrikson <jehenrik@yahoo.com> writes:

    jh> Also, I find the caml for loop's lack of functionality
    jh> annoying.  I really should learn camlp4 so I can write a real
    jh> C-style for loop.  (with break and continue, though it's not
    jh> pertinent here.)  Somebody doesn't have such things
    jh> convieniently lying around do they?

Personally, I use tail loops for this sort of thing.  You could also
use a while loop, but that is less efficient than a for loop or a tail
loop in O'Caml (since you'd have to use refs and break the write
barrier.)  Here's an example:


C code:

int i;
int j;
int count;

/* what does this loop do?  I don't know... */
for ( i = 0, count = 0; i < I_MAX; i++ ) {
    for ( j = 0; j < J_MAX; j++ ) {
        if ( i == j ) continue;
        if ( (i + j) == count ) break;
        count++;
    }
}
return count;

Caml code:

let rec loop_1 i count =
   let rec loop_2 j count =
     if i = j then               loop_2 (succ j) count
     else if i + j = count then  loop_1 (succ i) count
     else                        loop_2 (succ j) (succ count)
   in loop_2 0 count
in loop_1 0 0


The caml code is certainly less clear in this case--but I think that's
partialyl because the computation was created just to make a point.
:) One might be able to use a ref for count to make it more clear how
count is "updated".  But it leads to even messier code, and worse
runtime performance.  A "real" loop example would also provide a way
to define better names for the functions than "loop_1" and "loop_2".

The tail calling to continue or break loops makes it easy to duplicate
effects that would be created in C with gotos, since you can only
break or continue the inner loop in C.

With some experience, tail-call loops will come to mind naturally.  I
practically never use the for or while loop constructs in O'Caml.

John.
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Jun P. FURUSE]

Hello,

> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).

The color query of Graphics library in X11 is quite slow, 
even with the caml color => pixel value cache, since
to obtain the pixel value of a caml color, it calls XAllocColor
function. That is, for each color query, Caml Graphics applications
must communicate with the X server. This transaction slows down
make_image function if images have too many colors.
The cache works well for images like gif (less than 256 colors),
but not for photos and still video images which may have thousands of
colors.

I just have written a small patch for this color conversion without 
communication between X server. This speeds up make_image pretty well
and the color cache is no more required. 
The hack works only for TrueColor and DirectColor visuals, but
nowadays it is difficult to find running X servers with other color
models like Pseudo (=256 colors) and Monochrome.

This change is still not commited to CVS, because I have not checked
it in many environments. (At least it works well in my computer...)

-----------------------------------------------------------------------
Jun P. Furuse 					 Jun.Furuse@inria.fr

Index: color.c
===================================================================
RCS file: /net/pauillac/caml/repository/csl/otherlibs/graph/color.c,v
retrieving revision 1.13
diff -c -r1.13 color.c
*** color.c	2000/06/07 16:32:49	1.13
--- color.c	2001/09/21 21:23:43
***************
*** 13,18 ****
--- 13,19 ----
  /* $Id: color.c,v 1.13 2000/06/07 16:32:49 furuse Exp $ */
  
  #include "libgraph.h"
+ #include <X11/Xatom.h>
  
  /* Cache to speed up the translation rgb -> pixel value. */
  
***************
*** 30,39 ****
  
  static int num_overflows = 0;
  
  Bool direct_rgb = False;
! int byte_order;
! int bitmap_unit;
! int bits_per_pixel;
  
  void gr_init_color_cache(void)
  {
--- 31,129 ----
  
  static int num_overflows = 0;
  
+ /* rgb -> pixel conversion *without* display connection */
+ 
  Bool direct_rgb = False;
! int red_l, red_r;
! int green_l, green_r;
! int blue_l, blue_r;
! unsigned long red_vals[256];
! unsigned long green_vals[256];
! unsigned long blue_vals[256];
! 
! void get_shifts( unsigned long mask, int *lsl, int *lsr )
! {
!   int l = 0;
!   int r = 0;
!   int bit = 1;
!   if ( mask == 0 ){ *lsl = -1; *lsr = -1; return; }
! 
!   for( l = 0; l < 32; l++ ){
!     if( bit & mask ){ break; }
!     bit = bit << 1;
!   }
!   for( r = l; r < 32; r++ ){
!     if( ! (bit & mask) ){ break; }
!     bit = bit << 1;
!   }
!   /* fix r */
!   if ( r == 32 ) { r = 31; }
!   *lsl = l;
!   *lsr = 16 - (r - l);
! }
! 
! 
! void gr_init_direct_rgb_to_pixel(void)
! {
!   Visual *visual;
!   int i;
!  
!   visual = DefaultVisual(grdisplay,grscreen);
!   
!   if ( visual->class == TrueColor || visual->class == DirectColor ){
!     int lsl, lsr;
! #ifdef QUICKCOLORDEBUG
!     fprintf(stderr, "visual %lx %lx %lx\n", 
! 	    visual->red_mask, 
! 	    visual->green_mask, 
! 	    visual->blue_mask);
! #endif
! 
!     get_shifts(visual->red_mask, &red_l, &red_r); 
! #ifdef QUICKCOLORDEBUG
!     fprintf(stderr, "red %d %d\n", red_l, red_r);
! #endif
!     for(i=0; i<256; i++){
!       red_vals[i] = (((i << 8) + i) >> red_r) << red_l;
!     }
! 
!     get_shifts(visual->green_mask, &green_l, &green_r); 
! #ifdef QUICKCOLORDEBUG
!     fprintf(stderr, "green %d %d\n", green_l, green_r);
! #endif
!     for(i=0; i<256; i++){
!       green_vals[i] = (((i << 8) + i) >> green_r) << green_l;
!     }
! 
!     get_shifts(visual->blue_mask, &blue_l, &blue_r); 
! #ifdef QUICKCOLORDEBUG
!     fprintf(stderr, "blue %d %d\n", blue_l, blue_r);
! #endif
!     for(i=0; i<256; i++){
!       blue_vals[i] = (((i << 8) + i) >> blue_r) << blue_l;
!     }
!     
!     if( red_l < 0 || red_r < 0 || 
! 	green_l < 0 || green_r < 0 || 
! 	blue_l < 0 || blue_r < 0 ){
! #ifdef QUICKCOLORDEBUG
!       fprintf(stderr, "Damn, boost failed\n");
! #endif
!       direct_rgb = False;
!     } else {
! #ifdef QUICKCOLORDEBUG
!       fprintf(stderr, "Boost ok\n");
! #endif
!       direct_rgb = True;
!     }
!   } else {
!     /* we cannot use direct_rgb_to_pixel */
! #ifdef QUICKCOLORDEBUG
!     fprintf(stderr, "No boost!\n");
! #endif
!     direct_rgb = False;
!   }
! }
  
  void gr_init_color_cache(void)
  {
***************
*** 59,71 ****
    b = rgb & 0xFF;
  
    if (direct_rgb){
!     switch ( bits_per_pixel ){
!     case 16:
!         tmp = ((r >> 3) << 11) + ((g >> 2) << 5) + ((b >> 3) << 0);
!         return (unsigned long) tmp;
!     case 32:
!       return (r << 16) + (g << 8) + (b << 0);
!     }
    }
  
    h = Hash_rgb(r, g, b);
--- 149,155 ----
    b = rgb & 0xFF;
  
    if (direct_rgb){
!     return red_vals[r] | green_vals[g] | blue_vals[b];
    }
  
    h = Hash_rgb(r, g, b);
Index: make_img.c
===================================================================
RCS file: /net/pauillac/caml/repository/csl/otherlibs/graph/make_img.c,v
retrieving revision 1.10
diff -c -r1.10 make_img.c
*** make_img.c	2000/04/05 18:30:17	1.10
--- make_img.c	2001/08/30 17:39:47
***************
*** 42,62 ****
                   ZPixmap, 0, NULL, width, height,
                   BitmapPad(grdisplay), 0);
  
-   /* To optimize RGB => color id calculation */
-   if( !direct_rgb ){
-     /* they are declared in color.c */
-     byte_order = idata->byte_order;
-     bitmap_unit = idata->bitmap_unit;
-     bits_per_pixel = idata->bits_per_pixel;
- #ifdef DIRECT_RGB_DEBUG
-     fprintf(stderr, "Byte_order: %d = %s\n", byte_order,
-             byte_order ? "LSBFirst" : "MSBFirst");
-     fprintf(stderr, "Bitmp_unit: %d\n", bitmap_unit);
-     fprintf(stderr, "Bits per pixel: %d\n", idata->bits_per_pixel);
- #endif
-     direct_rgb = True;
-   }
- 
    bdata = (char *) stat_alloc(height * idata->bytes_per_line);
    idata->data = bdata;
    has_transp = False;
--- 42,47 ----
Index: open.c
===================================================================
RCS file: /net/pauillac/caml/repository/csl/otherlibs/graph/open.c,v
retrieving revision 1.26
diff -c -r1.26 open.c
*** open.c	2001/07/31 13:15:36	1.26
--- open.c	2001/10/12 13:58:26
***************
*** 192,197 ****
--- 192,198 ----
    gry = 0;
    /* Reset the color cache */
    gr_init_color_cache();
+   gr_init_direct_rgb_to_pixel();
    return Val_unit;
  }
  
***************
*** 257,262 ****
--- 258,264 ----
      XFlush(grdisplay);
    }
    gr_init_color_cache();
+   gr_init_direct_rgb_to_pixel();
    return Val_unit;
  }
  
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Xavier Leroy]

> I'm doing some ``real-time'' video processing experiments with Ocaml
> (such as simple motion detection). I'm using the module Graphics for
> displaying grayscale images captured from a video camera. 

As others mentioned, it might be more reasonable to build on a
lower-level, more efficient library for manipulating bitmaps and pixmaps.
The original purpose of the Graphics library was for teaching: provide
simple line and text drawing primitives that would be portable across
X Windows, Windows, and the Macintosh.  It's not intended for maximum
performance, nor for generality.  (Although some users do wonderful
things with it, e.g. http://pauillac.inria.fr/activedvi/ .)

> The program
> spends a significant amount of time in Graphics.make_image, which, for
> every RGB value, looks up its pixel in a color cache.
> 
> First the color cache in otherlibs/graph/color.c is too small (512
> entries). So if I overlay my image with, say, red and blue zones,
> totaling more than 512 colors, make_image gets terribly slow (I spent
> an entire evening tracking out this mysterious slowdown). As a fix I
> set it to 4096 entries which corrected the slowdown (until I buy a
> color camera, that is).

Yes, this color cache machinery should be reworked.  We did a patch to
bypass it entirely in case of "true color" displays, but in general
the cache should grow dynamically.

> Second, it would be really nice to have an efficient interface between
> Bigarray and Graphics : a procedure for (quickly) converting either
> a m x n x 3 RGB byte array or a m x n byte array with a given palette
> into an image.

Yes, now that we have "true" integer matrices in Bigarray, it would
make sense to use them for Graphics' images.  One issue with Graphics
is that there are 3 different implementations (X Windows, Windows and
MacOS) that need to be changed simultaneously.  Needless to say, that
doesn't encourage us to extend the Graphics API :-)

> Third, I find that the coordinate convention (increasing y coordinates
> get you higher in the screen) is counter to current practice (CRTs
> scan from top to bottom ; matrices are also written from top to
> bottom).

We chose this convention to be consistent with mathematical practice.
This is a big plus for teaching...

> Fifth, and most important point (since I can't hack it myself) : I'd
> really like to see access to Bigarrays optimized. Currently, they are
> not (library call for each access).

Not quite.  With the native-code compiler ocamlopt, accesses to 1-, 2-
and 3-dimensional big arrays are expanded in line, *provided the
complete type of the big array is known*.  I.e.

    let f a x y = 1 + a.{x,y}

has a polymorphic type (int, 'a, 'b) Bigarray.Array2.t -> int -> int -> int
and compiles down to a library function call.  However,

    open Bigarray
    let f (a : (int, int_elt, c_layout) Array2.t) x y = 1 + a.{x,y}

is monomorphic and will be compiled much more efficiently by ocamlopt.

- Xavier Leroy
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Berke Durak]

On Fri, Oct 12, 2001 at 05:02:00PM +0200, Xavier Leroy wrote:

> As others mentioned, it might be more reasonable to build on a
> lower-level, more efficient library for manipulating bitmaps and pixmaps.

Care must be taken so that it doesn't degenerate into yet another GUI
toolkit. Personally, I think that being able to display an array of
pixels in a window is more than adequate for teaching and
basic displays.

> Yes, this color cache machinery should be reworked.  We did a patch to
> bypass it entirely in case of "true color" displays, but in general
> the cache should grow dynamically.

Thanks, I'll try that.

> > Fifth, and most important point (since I can't hack it myself) : I'd
> > really like to see access to Bigarrays optimized. Currently, they are
> > not (library call for each access).
> 
> Not quite.  With the native-code compiler ocamlopt, accesses to 1-, 2-
> and 3-dimensional big arrays are expanded in line, *provided the
> complete type of the big array is known*.

I didn't notice that ! That's great, could you mention it in the
documentation ?

Thanks for the detailed reply. But what about the point number four,
namely that Bigarray syntax isn't handled by Camlp4 ?
--
Berke



-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Daniel de Rauglaudre]

On Fri, Oct 12, 2001 at 05:38:24PM +0200, Berke Durak wrote:

> Thanks for the detailed reply. But what about the point number four,
> namely that Bigarray syntax isn't handled by Camlp4 ?

This is fixed.

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Berke Durak]

On Fri, Oct 12, 2001 at 07:15:34PM +0200, Daniel de Rauglaudre wrote:
> On Fri, Oct 12, 2001 at 05:38:24PM +0200, Berke Durak wrote:
> 
> > Thanks for the detailed reply. But what about the point number four,
> > namely that Bigarray syntax isn't handled by Camlp4 ?
> 
> This is fixed.

Erm, I couldn't use both Bigarrays and Streams under 3.03 ALPHA. Tried
'-pp camlp4o'. Grepped 'bigarray' in ocaml-3.03-alpha/camlp4,
unsuccessfully. Am I missing something ?
--
Berke


-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr

Re: [Caml-list] Some suggested improvements to the Graphics and Bigarray modules

[Daniel de Rauglaudre]

Hi,

On Sun, Oct 14, 2001 at 01:16:25AM +0200, Berke Durak wrote:

> Erm, I couldn't use both Bigarrays and Streams under 3.03 ALPHA. Tried
> '-pp camlp4o'. Grepped 'bigarray' in ocaml-3.03-alpha/camlp4,
> unsuccessfully. Am I missing something ?

Sorry, I meant it is fixed in the CVS version. Here is the patch:



Index: camlp4/etc/pa_o.ml
===================================================================
diff -c -r1.12 -r1.13
*** camlp4/etc/pa_o.ml	2001/10/09 16:39:04	1.12
--- camlp4/etc/pa_o.ml	2001/10/12 15:35:41	1.13
***************
*** 10,16 ****
  (*                                                                     *)
  (***********************************************************************)
  
! (* $Id: pa_o.ml,v 1.12 2001/10/09 16:39:04 ddr Exp $ *)
  
  open Stdpp;
  open Pcaml;
--- 10,16 ----
  (*                                                                     *)
  (***********************************************************************)
  
! (* $Id: pa_o.ml,v 1.13 2001/10/12 15:35:41 ddr Exp $ *)
  
  open Stdpp;
  open Pcaml;
***************
*** 292,297 ****
--- 292,323 ----
    | _ -> None ]
  ;
  
+ value bigarray_get loc arr arg =
+   let coords =
+     match arg with
+     [ <:expr< ($list:el$) >> -> el
+     | _ -> [arg] ]
+   in
+   match coords with
+   [ [c1] -> <:expr< Bigarray.Array1.get $arr$ $c1$ >>
+   | [c1; c2] -> <:expr< Bigarray.Array2.get $arr$ $c1$ $c2$ >>
+   | [c1; c2; c3] -> <:expr< Bigarray.Array3.get $arr$ $c1$ $c2$ $c3$ >>
+   | coords -> <:expr< Bigarray.Genarray.get $arr$ [| $list:coords$ |] >> ]
+ ;
+ 
+ value bigarray_set loc var newval =
+   match var with
+   [ <:expr< Bigarray.Array1.get $arr$ $c1$ >> ->
+       Some <:expr< Bigarray.Array1.set $arr$ $c1$ $newval$ >>
+   | <:expr< Bigarray.Array2.get $arr$ $c1$ $c2$ >> ->
+       Some <:expr< Bigarray.Array2.set $arr$ $c1$ $c2$ $newval$ >>
+   | <:expr< Bigarray.Array3.get $arr$ $c1$ $c2$ $c3$ >> ->
+       Some <:expr< Bigarray.Array3.set $arr$ $c1$ $c2$ $c3$ $newval$ >>
+   | <:expr< Bigarray.Genarray.get $arr$ [| $list:coords$ |] >> ->
+       Some <:expr< Bigarray.Genarray.set $arr$ [| $list:coords$ |] $newval$ >>
+   | _ -> None ]
+ ;
+ 
  (* ...works bad...
  value rec sync cs =
    match cs with parser
***************
*** 498,504 ****
      | ":=" NONA
        [ e1 = SELF; ":="; e2 = expr LEVEL "expr1" ->
            <:expr< $e1$.val := $e2$ >>
!       | e1 = SELF; "<-"; e2 = expr LEVEL "expr1" -> <:expr< $e1$ := $e2$ >> ]
      | "||" RIGHTA
        [ e1 = SELF; "or"; e2 = SELF -> <:expr< $lid:"or"$ $e1$ $e2$ >>
        | e1 = SELF; "||"; e2 = SELF -> <:expr< $e1$ || $e2$ >> ]
--- 524,533 ----
      | ":=" NONA
        [ e1 = SELF; ":="; e2 = expr LEVEL "expr1" ->
            <:expr< $e1$.val := $e2$ >>
!       | e1 = SELF; "<-"; e2 = expr LEVEL "expr1" ->
!           match bigarray_set loc e1 e2 with
!           [ Some e -> e
!           | None -> <:expr< $e1$ := $e2$ >> ] ]
      | "||" RIGHTA
        [ e1 = SELF; "or"; e2 = SELF -> <:expr< $lid:"or"$ $e1$ $e2$ >>
        | e1 = SELF; "||"; e2 = SELF -> <:expr< $e1$ || $e2$ >> ]
***************
*** 570,575 ****
--- 599,605 ----
      | "simple" LEFTA
        [ e1 = SELF; "."; "("; e2 = SELF; ")" -> <:expr< $e1$ .( $e2$ ) >>
        | e1 = SELF; "."; "["; e2 = SELF; "]" -> <:expr< $e1$ .[ $e2$ ] >>
+       | e1 = SELF; "."; "{"; e2 = SELF; "}" -> bigarray_get loc e1 e2
        | e1 = SELF; "."; e2 = SELF -> <:expr< $e1$ . $e2$ >>
        | "!"; e = SELF -> <:expr< $e$ . val>>
        | f = [ op = "~-" -> op | op = "~-." -> op | op = prefixop -> op ];

-- 
Daniel de RAUGLAUDRE
daniel.de_rauglaudre@inria.fr
http://cristal.inria.fr/~ddr/
-------------------
Bug reports: http://caml.inria.fr/bin/caml-bugs  FAQ: http://caml.inria.fr/FAQ/
To unsubscribe, mail caml-list-request@inria.fr  Archives: http://caml.inria.fr