Re: [Cocci] A few build failures with OCaml 4.12.0

[Richard W.M. Jones]

On Tue, Mar 02, 2021 at 03:52:21PM +0100, Julia Lawall wrote:
> This problem is fixed now in the github version.

Yup, can confirm it now works with git @ 3dc5d027b448

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Checking evolution according to version 1.1.0

[Richard W.M. Jones]

On Sun, Feb 28, 2021 at 09:01:54PM +0100, Markus Elfring wrote:
> > A new version 1.1.0 has been released.
> 
> Thanks.
> 
> I have dared to activate also a current OCaml version by the command
> “opam switch create 4.12.0”.
> I have tried to rebuild your software accordingly.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205> make distclean && git checkout 
> master && git pull && ./autogen && ./configure && echo "$(./version.sh)" && 
> grep VERSION=1 Makefile.config
> 
> 
> Now I stumble on the following error message.
> 
> elfring@Sonne:~/Projekte/Coccinelle/20160205> LANG=C make world
> make -C bundles/stdcompat all
> make[1]: Entering directory 
> '/home/elfring/Projekte/Coccinelle/20160205/bundles/stdcompat'
> cd stdcompat-current; make && cp *.mli *.cmi *.cmx *.cma *.cmxa *.a *.h ..
> make[2]: Entering directory 
> '/home/elfring/Projekte/Coccinelle/20160205/bundles/stdcompat/stdcompat-current'
> make  all-am
> make[3]: Entering directory 
> '/home/elfring/Projekte/Coccinelle/20160205/bundles/stdcompat/stdcompat-current'
> ocamlfind ocamlopt -c -package seq -package uchar -bin-annot -no-alias-deps 
> -I . -alert -deprecated stdcompat__arg_s.mli -o stdcompat__arg_s.cmi
> File "stdcompat__arg_s.mli", lines 3-17, characters 0-38:
>  3 | type spec = Arg.spec =
>  4 |   | Unit of (unit -> unit)
>  5 |   | Bool of (bool -> unit)
>  6 |   | Set of bool ref
>  7 |   | Clear of bool ref
> ...
> 14 |   | Tuple of spec list
> 15 |   | Symbol of string list * (string -> unit)
> 16 |   | Rest of (string -> unit)
> 17 |   | Expand of (string -> string array).
> Error: This variant or record definition does not match that of type Arg.spec
>Constructors number 14 have different names, Rest_all and Expand.
> make[3]: *** [Makefile:1612: stdcompat__arg_s.cmi] Error 2
> …
> 
> 
> Would you like to point any corresponding adjustments out?

This patch will make it work, although it's a hack:

https://src.fedoraproject.org/rpms/coccinelle/tree/rawhide

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] A few build failures with OCaml 4.12.0

[Richard W.M. Jones]

ocamlfind ocamlopt -c -package result -package seq -bin-annot -no-alias-deps -I 
. -alert -deprecated stdcompat__arg_s.mli -o stdcompat__arg_s.cmi
File "stdcompat__arg_s.mli", lines 3-17, characters 0-38:
 3 | type spec = Arg.spec =
 4 |   | Unit of (unit -> unit) 
 5 |   | Bool of (bool -> unit) 
 6 |   | Set of bool ref 
 7 |   | Clear of bool ref 
...
14 |   | Tuple of spec list 
15 |   | Symbol of string list * (string -> unit) 
16 |   | Rest of (string -> unit) 
17 |   | Expand of (string -> string array).
Error: This variant or record definition does not match that of type Arg.spec
   Constructors number 14 have different names, Rest_all and Expand.

There is a new Rest_all constructor:

https://github.com/ocaml/ocaml/blob/500d8dc8296d09305b5413f140c63ffee1de111d/stdlib/arg.mli#L92

--

ocamlfind ocamlopt -c -package result -package seq -bin-annot -no-alias-deps -I 
. -alert -deprecated stdcompat__spacetime_s.mli -o stdcompat__spacetime_s.cmi
File "stdcompat__spacetime_s.mli", line 3, characters 16-32:
3 | module Series = Spacetime.Series

Error: Unbound module Spacetime

This module was removed in OCaml commit
540996d21ee3793a1cecce252c81fb76a6b9fd61.

--

ocamlfind ocamlc -c -package result -package seq -bin-annot -no-alias-deps -I . 
-alert -deprecated stdcompat__ephemeron.ml -o stdcompat__ephemeron.cmo
File "stdcompat__ephemeron.ml", line 1:
Error: The implementation stdcompat__ephemeron.ml
   does not match the interface stdcompat__ephemeron.cmi:
   ...
   At position module type S = 
   Type declarations do not match:
 type 'a t
   is not included in
 type !'a t
   Their variances do not agree.
   File "hashtbl.mli", line 335, characters 4-14: Expected declaration
   File "stdcompat__ephemeron_s.mli", line 6, characters 4-13:
 Actual declaration

Not sure about this one but AFAICT cocci doesn't use this module.

--

I made a patch to workaround the issues in Fedora, but it's a pure hack:

  https://src.fedoraproject.org/rpms/coccinelle/tree/rawhide

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Python 3.10 again: _Py_fopen deprecated

[Richard W.M. Jones]

On Sat, Jan 09, 2021 at 12:10:18AM +0100, Thierry Martinez wrote:
> Hi, Richard.
> 
> Thank you very much for your two successive reports about
> incompatibilities between pyml and Python 3.10. They should have been
> fixed now.
> 
> Richard:
> >> What I don't understand from the pyxml code is why we use these
> >> internal Python functions at all, instead of calling regular C
> >> functions like fopen etc.  In fact it seems like for Python 2 we did
> >> call fopen ...
> 
> Indeed, for Python 2, there is a fallback to fopen since Py_fopen is not
> available.  When Py_fopen or Py_wfopen are available, we prefer to use
> them because they handle the Windows special case.

Oh I see, that makes sense.

Rich.

> Best regards.
> -- 
> Thierry.
> 
> Julia Lawall :
> > On Tue, 5 Jan 2021, Richard W.M. Jones wrote:
> >
> >> Firstly a gentle reminder that there's a patch waiting to be applied:
> >> https://systeme.lip6.fr/pipermail/cocci/2020-November/thread.html#8398
> >>
> >> Different from that patch, but still related to Python 3.10, we've got
> >> another bug report here:
> >> https://bugzilla.redhat.com/show_bug.cgi?id=1912931
> >>
> >> This time _Py_fopen has been deprecated, replaced by _Py_wfopen or
> >> _Py_fopen_obj.  It's unclear which is better.  The two functions are
> >> documented here:
> >> https://github.com/python/cpython/blob/master/Python/fileutils.c#L1418
> >>
> >> What I don't understand from the pyxml code is why we use these
> >> internal Python functions at all, instead of calling regular C
> >> functions like fopen etc.  In fact it seems like for Python 2 we did
> >> call fopen ...
> >
> > Everything should be up to date now on github.  Thanks for your help.
> > Thierry will contact you directly about the choice of fopen.
> >
> > julia
> >
> >>
> >> Rich.
> >>
> >> --
> >> Richard Jones, Virtualization Group, Red Hat 
> >> http://people.redhat.com/~rjones
> >> Read my programming and virtualization blog: http://rwmj.wordpress.com
> >> Fedora Windows cross-compiler. Compile Windows programs, test, and
> >> build Windows installers. Over 100 libraries supported.
> >> http://fedoraproject.org/wiki/MinGW
> >>
> >> ___
> >> Cocci mailing list
> >> Cocci@systeme.lip6.fr
> >> https://systeme.lip6.fr/mailman/listinfo/cocci
> >>
> > ___
> > Cocci mailing list
> > Cocci@systeme.lip6.fr
> > https://systeme.lip6.fr/mailman/listinfo/cocci

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Python 3.10 again: _Py_fopen deprecated

[Richard W.M. Jones]

Firstly a gentle reminder that there's a patch waiting to be applied:
https://systeme.lip6.fr/pipermail/cocci/2020-November/thread.html#8398

Different from that patch, but still related to Python 3.10, we've got
another bug report here:
https://bugzilla.redhat.com/show_bug.cgi?id=1912931

This time _Py_fopen has been deprecated, replaced by _Py_wfopen or
_Py_fopen_obj.  It's unclear which is better.  The two functions are
documented here:
https://github.com/python/cpython/blob/master/Python/fileutils.c#L1418

What I don't understand from the pyxml code is why we use these
internal Python functions at all, instead of calling regular C
functions like fopen etc.  In fact it seems like for Python 2 we did
call fopen ...

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] [PATCH Python 10] bundles/pyml: Remove bindings for PyObject_As(Char|Read|Write)Buffer

[Richard W.M. Jones]

On Tue, Nov 10, 2020 at 03:10:57PM +, Richard W.M. Jones wrote:
> Some more functions were deprecated/removed in Python 10,
> breaking Coccinelle compiles.  It was reported by Fedora's
> Python team here:
> 
> https://bugzilla.redhat.com/show_bug.cgi?id=1896393
> 
> I have fixed it by chopping out bindings for these
> functions from the bundled pyml, and it compiles fine
> for me with Python 10 now.

Erm, Python 3.10, not Python 10 obviously :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] [PATCH Python 10] bundles/pyml: Remove bindings for PyObject_As(Char|Read|Write)Buffer

[Richard W.M. Jones]

Some more functions were deprecated/removed in Python 10,
breaking Coccinelle compiles.  It was reported by Fedora's
Python team here:

https://bugzilla.redhat.com/show_bug.cgi?id=1896393

I have fixed it by chopping out bindings for these
functions from the bundled pyml, and it compiles fine
for me with Python 10 now.

Rich.


___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] [PATCH Python 10] bundles/pyml: Remove bindings for PyObject_As(Char|Read|Write)Buffer

[Richard W.M. Jones]

These have been removed in Python 3.10.

Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1896393
Signed-off-by: Richard W.M. Jones 
---
 bundles/pyml/pyml-current/py.ml| 12 
 bundles/pyml/pyml-current/py.mli   | 12 
 bundles/pyml/pyml-current/pycaml.ml|  6 --
 bundles/pyml/pyml-current/pycaml.mli   |  3 ---
 bundles/pyml/pyml-current/pyml_stubs.c | 12 
 5 files changed, 45 deletions(-)

diff --git a/bundles/pyml/pyml-current/py.ml b/bundles/pyml/pyml-current/py.ml
index fc49bc42..d33dcf77 100644
--- a/bundles/pyml/pyml-current/py.ml
+++ b/bundles/pyml/pyml-current/py.ml
@@ -36,12 +36,6 @@ external pyerr_fetch_internal: unit -> pyobject * pyobject * 
pyobject
 = "PyErr_Fetch_wrapper"
 external pystring_asstringandsize: pyobject -> string option
 = "PyString_AsStringAndSize_wrapper"
-external pyobject_ascharbuffer: pyobject -> string option
-= "PyObject_AsCharBuffer_wrapper"
-external pyobject_asreadbuffer: pyobject -> string option
-= "PyObject_AsReadBuffer_wrapper"
-external pyobject_aswritebuffer: pyobject -> string option
-= "PyObject_AsWriteBuffer_wrapper"
 external pylong_fromstring: string -> int -> pyobject * int
 = "PyLong_FromString_wrapper"
 external pycapsule_isvalid: Pytypes.pyobject -> string -> int
@@ -1429,12 +1423,6 @@ module Object = struct
 
   let to_string item = String.to_string (str item)
 
-  let as_char_buffer obj = check_some (pyobject_ascharbuffer obj)
-
-  let as_read_buffer obj = check_some (pyobject_asreadbuffer obj)
-
-  let as_write_buffer obj = check_some (pyobject_aswritebuffer obj)
-
   external reference_count: pyobject -> int = "pyrefcount"
 
   let repr_or_string repr v =
diff --git a/bundles/pyml/pyml-current/py.mli b/bundles/pyml/pyml-current/py.mli
index 19a4599e..df509a02 100644
--- a/bundles/pyml/pyml-current/py.mli
+++ b/bundles/pyml/pyml-current/py.mli
@@ -239,18 +239,6 @@ module Object: sig
   We have
   [Py.Object.to_string o = Py.String.to_string (Py.Object.str o)]. *)
 
-  val as_char_buffer: t -> string
-  (** Wrapper for
-  
{{:https://docs.python.org/3/c-api/objbuffer.html#c.PyObject_AsCharBuffer} 
PyObject_AsCharBuffer} *)
-
-  val as_read_buffer: t -> string
-  (** Wrapper for
-  
{{:https://docs.python.org/3/c-api/objbuffer.html#c.PyObject_AsReadBuffer} 
PyObject_AsReadBuffer} *)
-
-  val as_write_buffer: t -> string
-  (** Wrapper for
-  
{{:https://docs.python.org/3/c-api/objbuffer.html#c.PyObject_AsWriteBuffer} 
PyObject_AsWriteBuffer} *)
-
   val reference_count: t -> int
   (** [reference_count o] returns the number of references to the Python
   object [o]. *)
diff --git a/bundles/pyml/pyml-current/pycaml.ml 
b/bundles/pyml/pyml-current/pycaml.ml
index 8c93cf4a..13b16aa8 100644
--- a/bundles/pyml/pyml-current/pycaml.ml
+++ b/bundles/pyml/pyml-current/pycaml.ml
@@ -347,12 +347,6 @@ let pyunicode_asunicode = Py.String.to_unicode
 
 let pyunicode_getsize = Py.String.length
 
-let pyobject_ascharbuffer = Py.Object.as_char_buffer
-
-let pyobject_asreadbuffer = Py.Object.as_read_buffer
-
-let pyobject_aswritebuffer = Py.Object.as_write_buffer
-
 let python () =
   Py.Run.interactive ();
   0
diff --git a/bundles/pyml/pyml-current/pycaml.mli 
b/bundles/pyml/pyml-current/pycaml.mli
index 85b5f83c..da800bac 100644
--- a/bundles/pyml/pyml-current/pycaml.mli
+++ b/bundles/pyml/pyml-current/pycaml.mli
@@ -758,9 +758,6 @@ val pyobject_size : pyobject -> int
 val pyobject_getitem : pyobject * pyobject -> pyobject
 val pyobject_setitem : pyobject * pyobject * pyobject -> int
 val pyobject_delitem : pyobject * pyobject -> int
-val pyobject_ascharbuffer : pyobject -> string
-val pyobject_asreadbuffer : pyobject -> string
-val pyobject_aswritebuffer : pyobject -> string
 
 val pynumber_check : pyobject -> int
 val pynumber_add : pyobject * pyobject -> pyobject
diff --git a/bundles/pyml/pyml-current/pyml_stubs.c 
b/bundles/pyml/pyml-current/pyml_stubs.c
index 5158a0e4..cc10e821 100644
--- a/bundles/pyml/pyml-current/pyml_stubs.c
+++ b/bundles/pyml/pyml-current/pyml_stubs.c
@@ -195,12 +195,6 @@ static PyObject *Python__Py_FalseStruct;
 /* Buffer and size */
 static int (*Python_PyString_AsStringAndSize)
 (PyObject *, char **, Py_ssize_t *);
-static int (*Python_PyObject_AsCharBuffer)
-(PyObject *, const char **, Py_ssize_t *);
-static int (*Python_PyObject_AsReadBuffer)
-(PyObject *, const void **, Py_ssize_t *);
-static int (*Python_PyObject_AsWriteBuffer)
-(PyObject *, void **, Py_ssize_t *);
 
 /* Length argument */
 static PyObject *(*Python_PyLong_FromString)(const char *, const char **, int);
@@ -684,9 +678,6 @@ py_load_library(value filename_ocaml, value 
debug_build_ocaml)
 resolve("PyObject_CallMethodObjArgs");
 Python_PyErr_Fetch = resolve("PyErr_Fetch");
 Python_PyErr_No

[Cocci] FYI failures reported with Python 3.9 with PyImport_Cleanup

[Richard W.M. Jones]

https://bugzilla.redhat.com/show_bug.cgi?id=1791765

  Py.find_library: unable to find the Python library 
[/lib64/libpython3.9.so.1.0 returned Cannot resolve PyImport_Cleanup.

The documentation for this function says:

  void PyImport_Cleanup()
  Empty the module table. For internal use only.

I guess that is code for "don't use this function" :-)

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Compiling with OCaml 4.08

[Richard W.M. Jones]

On Wed, Sep 18, 2019 at 09:11:46PM +0200, Julia Lawall wrote:
> The version in github should now compile with 4.08.  If I don't hear any
> complaints by Friday, I will make a release.

Thanks Julia, I can confirm it builds here with OCaml 4.08.1.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Compiling with OCaml 4.08

[Richard W.M. Jones]

On Wed, Sep 18, 2019 at 12:56:30PM +0200, Markus Elfring wrote:
> > https://bugzilla.redhat.com/show_bug.cgi?id=1734855#c12
> 
> Would you like to achieve the contribution of additional
> software development resources so that more improvements
> would become possible by easier ways?

I have tried to do it myself twice and failed both times, and I don't
know anyone with the skills (and certainly not anyone who works for
me).  I and the company I work for put in a vast amount of money and
effort supporting open source software, so we know how the system
works.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Compiling with OCaml 4.08

[Richard W.M. Jones]

On Thu, Jul 11, 2019 at 04:21:16PM +0100, Richard W.M. Jones wrote:
> Has anyone attempted to port coccinelle to OCaml 4.08?  It seems
> to require multiple complex changes.

I wonder if anyone has done the port yet?  It is apparently causing
trouble for Fedora:

https://bugzilla.redhat.com/show_bug.cgi?id=1734855#c12

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Compiling with OCaml 4.08

[Richard W.M. Jones]

Has anyone attempted to port coccinelle to OCaml 4.08?  It seems
to require multiple complex changes.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Compiling with OCaml 4.06 / safe-string

[Richard W.M. Jones]

I'm trying to compile coccinelle with OCaml 4.06, where the default
for strings has been switched to -safe-string.

It currently fails to build in the bundled parmap library:

/usr/bin/ocamlc.opt -unsafe -I parmap.1.0-rc7.1 -custom -cclib -lparmap_stubs   
-c parmap.1.0-rc7.1/bytearray.ml -o parmap.1.0-rc7.1/bytearray.cmo
File "parmap.1.0-rc7.1/bytearray.ml", line 38, characters 0-118:
Warning 3: deprecated: [@@noalloc] should be used instead of "noalloc"
File "parmap.1.0-rc7.1/bytearray.ml", line 41, characters 0-116:
Warning 3: deprecated: [@@noalloc] should be used instead of "noalloc"
File "parmap.1.0-rc7.1/bytearray.ml", line 47, characters 10-23:
Warning 3: deprecated: String.create
Use Bytes.create instead.
File "parmap.1.0-rc7.1/bytearray.ml", line 48, characters 28-29:
Error: This expression has type bytes but an expression was expected of type
 string

I tried fixing this, but the library is doing a bunch of stuff with
actually overwriting strings, and I'm not clear how safe that is with
-safe-string.  Anyway, a fix isn't trivial.  Upstream parmap doesn't
have a fix that I could see.

Obviously I could switch to -unsafe-string, but has anyone fixed this?

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Selecting Python 3 at configure time

[Richard W.M. Jones]

This bug was filed against the Fedora package:
https://bugzilla.redhat.com/show_bug.cgi?id=1416323

I looked at configure.ac and the Makefiles, but I cannot work out how
you tell ./configure to use /usr/bin/python3 instead of
/usr/bin/python, if indeed that is possible at all - it's not clear
that it is.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-top is 'top' for virtual machines.  Tiny program with many
powerful monitoring features, net stats, disk stats, logging, etc.
http://people.redhat.com/~rjones/virt-top
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] version 1.0.4 released

[Richard W.M. Jones]

On Tue, Jul 19, 2016 at 12:07:42PM +0200, Julia Lawall wrote:
> 
> 
> On Tue, 19 Jul 2016, Richard W.M. Jones wrote:
> 
> > On Wed, Oct 28, 2015 at 11:06:34PM +0100, Julia Lawall wrote:
> > > Version 1.0.4 is released.  This removes the make of spgen when making
> > > spatch, removes the pre-generated menhir file when menhir is available,
> > > and adds the ability to reason about the lengths of statement lists.
> >
> > This problem has reoccured in 1.0.5.  The generated files must
> > be removed first, if compiling with external menhir.
> 
> OK.  I think this problem has been fixed, but we need to make a new
> release.  Maybe you should just wait for 1.0.6, if it is causing a
> problem.  Thanks for the report.

It's no problem - I have added a workaround in the RPM build.

I was just noting that the workaround was necessary.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] version 1.0.4 released

[Richard W.M. Jones]

On Wed, Oct 28, 2015 at 11:06:34PM +0100, Julia Lawall wrote:
> Version 1.0.4 is released.  This removes the make of spgen when making 
> spatch, removes the pre-generated menhir file when menhir is available, 
> and adds the ability to reason about the lengths of statement lists.

This problem has reoccured in 1.0.5.  The generated files must
be removed first, if compiling with external menhir.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

[Richard W.M. Jones]

On Wed, Jan 13, 2016 at 05:02:21PM +0100, Julia Lawall wrote:
> Here is a patch that should avoid the problem.

Yes this fixes it for me.

I'm attaching the actual patch as applied/rebased by me since the
patch you sent didn't apply cleanly on top of the coccinelle github
repo.

Thanks,

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
>From 511a9641f1d124fdaf8de7852f61549693065cbf Mon Sep 17 00:00:00 2001
From: Julia Lawall 
Date: Wed, 13 Jan 2016 17:02:21 +0100
Subject: [PATCH] Build failure on ppc64le: Failure("dump: impossible tag
 (1002)")

Here is a patch that should avoid the problem.

julia
---
 parsing_cocci/iso_compile.ml | 39 +--
 1 file changed, 33 insertions(+), 6 deletions(-)

diff --git a/parsing_cocci/iso_compile.ml b/parsing_cocci/iso_compile.ml
index 53845d1..6fb9fdd 100644
--- a/parsing_cocci/iso_compile.ml
+++ b/parsing_cocci/iso_compile.ml
@@ -14,17 +14,44 @@ isomorphism.  This is allowed if all elements of an 
isomorphism have only
 one token or if we can somehow match up equal tokens of all of the
 isomorphic variants. *)
 
+type mcodeinfo =
+MetaName of Ast.meta_name
+  | Str of string
+  | Cst of Ast.constant
+  | SAOp of Ast0.simpleAssignOp
+  | FixOp of Ast.fixOp
+  | UnOp of Ast.unaryOp
+  | ArOp of Ast.arithOp
+  | LogOp of Ast.logicalOp
+  | CV of Ast.const_vol
+  | Sign of Ast.sign
+  | Struct of Ast.structUnion
+  | Store of Ast.storage
+  | Inc of Ast.inc_file
+
 let sequence_tokens =
-  let mcode x =
-(* sort of unpleasant to convert the token representation to a string
-   but we can't make a list of mcodes otherwise because the types are all
-   different *)
-[(Dumper.dump (Ast0.unwrap_mcode x),Ast0.get_pos_ref x)] in
+  let mcode f x =
+(* have to convert the mcodes to a common type so that we can make a list
+   out of them *)
+[(f x,Ast0.get_pos_ref x)] in
   let donothing r k e = k e in
   let bind x y = x @ y in
   let option_default = [] in
   V0.flat_combiner bind option_default
-mcode mcode mcode mcode mcode mcode mcode mcode mcode mcode mcode mcode 
mcode mcode
+(mcode (function x -> MetaName (Ast0.unwrap_mcode x)))
+(mcode (function x -> Str (Ast0.unwrap_mcode x)))
+(mcode (function x -> Cst (Ast0.unwrap_mcode x)))
+(mcode (function x -> SAOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> ArOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> FixOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> UnOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> ArOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> LogOp (Ast0.unwrap_mcode x)))
+(mcode (function x -> CV (Ast0.unwrap_mcode x)))
+(mcode (function x -> Sign (Ast0.unwrap_mcode x)))
+(mcode (function x -> Struct (Ast0.unwrap_mcode x)))
+(mcode (function x -> Store (Ast0.unwrap_mcode x)))
+(mcode (function x -> Inc (Ast0.unwrap_mcode x)))
 donothing donothing donothing donothing donothing donothing donothing
 donothing donothing donothing donothing donothing
 donothing donothing donothing donothing donothing donothing donothing
-- 
2.5.0

___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

[Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

[Richard W.M. Jones]

https://bugzilla.redhat.com/show_bug.cgi?id=1297855
Build log:
http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/345/3060345/build.log

In brief the build fails at:

+ /builddir/build/BUILDROOT/coccinelle-1.0.4-2.fc24.ppc64le/usr/bin/spatch 
-sp_file demos/simple.cocci demos/simple.c
init_defs_builtins: 
/builddir/build/BUILDROOT/coccinelle-1.0.4-2.fc24.ppc64le/usr/lib64/coccinelle/standard.h
Fatal error: exception Failure("dump: impossible tag (1002)")

When thinking about this bug, don't exclude the possibility that there
could be a problem in the OCaml compiler.  In Fedora we currently use
a non-upstream ppc64le code generator, although we are planning to
replace it soon(-ish) with the new upstream POWER code generator that
Xavier wrote last year.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

[Richard W.M. Jones]

On Wed, Jan 13, 2016 at 03:26:50PM +0100, Julia Lawall wrote:
> 
> 
> On Wed, 13 Jan 2016, Richard W.M. Jones wrote:
> 
> > On Wed, Jan 13, 2016 at 03:17:36PM +0100, Julia Lawall wrote:
> > >
> > >
> > > On Wed, 13 Jan 2016, Richard W.M. Jones wrote:
> > >
> > > >
> > > > https://bugzilla.redhat.com/show_bug.cgi?id=1297855
> > > > Build log:
> > > > http://ppc.koji.fedoraproject.org/kojifiles/work/tasks/345/3060345/build.log
> > > >
> > > > In brief the build fails at:
> > > >
> > > > + 
> > > > /builddir/build/BUILDROOT/coccinelle-1.0.4-2.fc24.ppc64le/usr/bin/spatch
> > > >  -sp_file demos/simple.cocci demos/simple.c
> > > > init_defs_builtins: 
> > > > /builddir/build/BUILDROOT/coccinelle-1.0.4-2.fc24.ppc64le/usr/lib64/coccinelle/standard.h
> > > > Fatal error: exception Failure("dump: impossible tag (1002)")
> > > >
> > > > When thinking about this bug, don't exclude the possibility that there
> > > > could be a problem in the OCaml compiler.  In Fedora we currently use
> > > > a non-upstream ppc64le code generator, although we are planning to
> > > > replace it soon(-ish) with the new upstream POWER code generator that
> > > > Xavier wrote last year.
> > >
> > > It is actually your code that is crashing :)
> > >
> > > (* Dump an OCaml value into a printable string.
> > >  * By Richard W.M. Jones (r...@annexia.org).
> > >  * dumper.ml 1.2 2005/02/06 12:38:21 rich Exp
> > >  *)
> > >
> > > Maybe you could send the output of man Obj in your version of Ocaml?
> >
> > Not sure I understand - we don't change the Obj man page at all.
> >
> > The implementation of OCaml objects (as in the object header and so
> > on) should also be the same, AFAIK.  Certainly the ppc64le backend
> > doesn't make any changes inside the OCaml compiler core, eg. to the GC
> > or libraries.  It's a 64 bit LE platform, so AFAIK the memory
> > structures ought to be identical to x86-64.
> 
> Actually, I'm not sure to understand which version of OCaml you are using?

4.02.3

The sources (including the non-upstream backend) is:

  https://git.fedorahosted.org/cgit/fedora-ocaml.git/log/?h=fedora-24-4.02

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-builder quickly builds VMs from scratch
http://libguestfs.org/virt-builder.1.html
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

[Richard W.M. Jones]

But note I'm not saying this is not a compiler bug.  We've
had a few.

Is there a test case you could send me?  I will run it on
our ppc64le machine.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] Build failure on ppc64le: Failure("dump: impossible tag (1002)")

[Richard W.M. Jones]

On Wed, Jan 13, 2016 at 03:54:36PM +0100, SF Markus Elfring wrote:
> > But note I'm not saying this is not a compiler bug.
> > We've had a few.
> 
> Interesting …
> 
> How do you think about to share any more information
> about the last working system configuration
> for your special build environment?

I'm not sure that it has ever worked on ppc64le.  Looking at our POWER
build systems status:

http://ppc.koji.fedoraproject.org/koji/packageinfo?packageID=919

it looks like it has not built successfully for 3 years, and the last
time it was building that was only on ppc32.

> > Is there a test case you could send me?
> 
> In which kind of test scripts are you interested in?

Anything that would narrow down or potentially reproduce this
particular error, I guess.  Basically if you need me to run any
diagnostic tests, I can.

We also (in partnership with IBM) have a public rack of POWER systems
that anyone can provision (but you have to agree to some legal stuff):

http://research.redhat.com/powerlinux-openpower-development-hosting/

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-df lists disk usage of guests without needing to install any
software inside the virtual machine.  Supports Linux and Windows.
http://people.redhat.com/~rjones/virt-df/
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] version 1.0.3 released

[Richard W.M. Jones]

On Wed, Oct 28, 2015 at 08:08:15AM +0100, Julia Lawall wrote:
> On Tue, 27 Oct 2015, Richard W.M. Jones wrote:
> 
> > On Tue, Oct 27, 2015 at 01:37:48PM +0100, Sébastien Hinderer wrote:
> > > Hi again Richard and all,
> > > 
> > > Richard W.M. Jones (2015/10/27 11:57 +):
> > > > BTW the 'spgen' program is installed, but it's broken.  It's built as
> > > > a bytecode program using 'ocamlc -custom', RPM strips it (removing the
> > > > bytecode), and consequently the binary won't function on Fedora.  It
> > > > should have been built as a native program since I requested 'make
> > > > world'.
> > > 
> > > A new release of coccinelle fixing this issue will be published soon
> > > (hopefully tomorrow).
> > 
> > So this means I shouldn't be distributing spgen in our binary package?
> > 
> > I was a bit confused about what this program does - there didn't seem
> > to be much documentation for it :-(
> 
> It is used to make a semntic patche acceptable for inclusion in the Linux 
> kernel.  There is actually a very nice documentation for it in the 
> spgen/documentation directory.  But don't worry about distributing it now.  
> We will try to make it available in a better manner for the next release 
> (not the one planned for today, but after that).

Ah got it.  For some reason I was only looking in the
tools/spgen/source directory and overlooked the documentation and
examples directories completely.

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] version 1.0.3 released

[Richard W.M. Jones]

This version seems to be incompatible with the latest menhir.  In
Fedora we have ocaml-menhir-20151012-1.fc24.x86_64, and I get
this error when compiling:

/usr/bin/ocamlc.opt -unsafe -I ../commons -I ../commons/ocamlextra -I 
../globals -I /usr/lib64/ocaml/menhirLib -c parser_cocci_menhir.mli
/usr/bin/ocamlopt.opt -unsafe -I ../commons -I ../commons/ocamlextra -I 
../globals -I /usr/lib64/ocaml/menhirLib -c parser_cocci_menhir.ml
File "parser_cocci_menhir.ml", line 1855, characters 15-48:
Error: Unbound constructor MenhirLib.TableInterpreter.Accept
Makefile:90: recipe for target 'parser_cocci_menhir.cmx' failed
make[6]: *** [parser_cocci_menhir.cmx] Error 2

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] version 1.0.3 released

[Richard W.M. Jones]

On Tue, Oct 27, 2015 at 01:37:48PM +0100, Sébastien Hinderer wrote:
> Hi again Richard and all,
> 
> Richard W.M. Jones (2015/10/27 11:57 +):
> > BTW the 'spgen' program is installed, but it's broken.  It's built as
> > a bytecode program using 'ocamlc -custom', RPM strips it (removing the
> > bytecode), and consequently the binary won't function on Fedora.  It
> > should have been built as a native program since I requested 'make
> > world'.
> 
> A new release of coccinelle fixing this issue will be published soon
> (hopefully tomorrow).

So this means I shouldn't be distributing spgen in our binary package?

I was a bit confused about what this program does - there didn't seem
to be much documentation for it :-(

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
virt-p2v converts physical machines to virtual machines.  Boot with a
live CD or over the network (PXE) and turn machines into KVM guests.
http://libguestfs.org/virt-v2v
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci

Re: [Cocci] junk output

[Richard W.M. Jones]

On Fri, Apr 26, 2013 at 04:52:17PM +0300, Artem Bityutskiy wrote:
 Hi Julia, Richard,
 
 not sure if this was already reported, but the latest Fedora 18
 coccinelle produces a lot of junk. Just an example using the linux
 kernel scripts:
 
 $ spatch -sp_file ./scripts/coccinelle/free/clk_put.cocci 
 drivers/gpio/gpio-sch.c
 
 init_defs_builtins: /usr/share/coccinelle/standard.h
 HANDLING: drivers/gpio/gpio-sch.c
 No matches found for clk_get clk_put
 Skipping:drivers/gpio/gpio-sch.c
 left
 left
 left
[...]

I can confirm this happens.  I have filed a bug:

https://bugzilla.redhat.com/show_bug.cgi?id=957169

Rich.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines.  Supports shell scripting,
bindings from many languages.  http://libguestfs.org
___
Cocci mailing list
Cocci@systeme.lip6.fr
https://systeme.lip6.fr/mailman/listinfo/cocci