barvinok?

[thisiscam]

I see that there's some work on barvinok support. How do I enable it?
If it's still under construction, I can also help on that.

[inducer]

Use this script (or some variant) to build:

https://github.com/inducer/islpy/blob/master/build-with-barvinok.sh

Doing so will (currently) give you islpy.Set.card(). I'd be happy to take patches exposing more of barvinok.

[thisiscam]

Thanks. I just tried the above script and got a bunch of linker problems.

Undefined symbols for architecture x86_64:
  "_PyArg_UnpackTuple", referenced from:
      _cffi_f_isl_access_info_add_source(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_alloc(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_set_restrict(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_coefficient_val(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_constant_num_si(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_constant_val(_object*, _object*) in islpy._isl_cffi.o
      ...
  "_PyErr_Occurred", referenced from:
      _cffi_f_isl_access_info_add_source(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_alloc(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_set_restrict(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_coefficient_val(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_constant_num_si(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add_dims(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_coefficient_sgn(_object*, _object*) in islpy._isl_cffi.o
      ...
  "_PyEval_RestoreThread", referenced from:
      _cffi_f_isl_access_info_add_source(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_alloc(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_compute_flow(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_free(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_get_ctx(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_set_restrict(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add(_object*, _object*) in islpy._isl_cffi.o
      ...
  "_PyEval_SaveThread", referenced from:
      _cffi_f_isl_access_info_add_source(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_alloc(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_compute_flow(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_free(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_get_ctx(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_access_info_set_restrict(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_add(_object*, _object*) in islpy._isl_cffi.o
      ...
  "_PyFloat_AsDouble", referenced from:
      _cffi_f_isl_printer_print_double(_object*, _object*) in islpy._isl_cffi.o
  "_PyFloat_FromDouble", referenced from:
      _cffi_f_isl_val_get_d(_object*, _object*) in islpy._isl_cffi.o
  "_PyImport_ImportModule", referenced from:
      _cffi_init(char const*, long, _cffi_type_context_s const*) in islpy._isl_cffi.o
  "_PyLong_FromLong", referenced from:
      _cffi_f_isl_aff_coefficient_sgn(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_dim(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_find_dim_by_name(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_get_hash(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_list_n_aff(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_expr_get_op_n_arg(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_expr_list_n_ast_expr(_object*, _object*) in islpy._isl_cffi.o
      ...
  "_PyLong_FromUnsignedLong", referenced from:
      _cffi_f_isl_ctx_get_max_operations(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_pw_qpolynomial_fold_size(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_val_n_abs_num_chunks(_object*, _object*) in islpy._isl_cffi.o
  "_PyLong_FromVoidPtr", referenced from:
      _cffi_init(char const*, long, _cffi_type_context_s const*) in islpy._isl_cffi.o
  "_PyObject_CallMethod", referenced from:
      _cffi_init(char const*, long, _cffi_type_context_s const*) in islpy._isl_cffi.o
  "__Py_Dealloc", referenced from:
      _cffi_init(char const*, long, _cffi_type_context_s const*) in islpy._isl_cffi.o
  "__Py_NoneStruct", referenced from:
      _cffi_f_isl_aff_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_aff_list_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_expr_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_expr_list_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_node_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_ast_node_list_dump(_object*, _object*) in islpy._isl_cffi.o
      _cffi_f_isl_basic_map_dump(_object*, _object*) in islpy._isl_cffi.o
      ...
ld: symbol(s) not found for architecture x86_64

any ideas?

[inducer]

Python headers not matching your Python executable?

[thisiscam]

I figured out the reason --- I think the current cffi build script is dynamically runtime resolving these symbols in g++ with the "-shared" flag. Thus it is not needing libpython during linking stage.

However, I'm using clang++, and "-shared" is not enough for dynamic resolution of these symbols. I need to do

clang++ -shared -undefined dynamic_lookup 

[inducer]

Happy to hear you figured it out, and thanks for sharing what you learned.

[lbang-hmc]

Hello, I would also really like to use isl.Set.card. I tried running the script above, but it dot not work for me. I get the following error:

checking for llvm-config... yes
checking for main in -lLLVM-6.0.0... yes
checking clang/Basic/SourceLocation.h usability... no
checking clang/Basic/SourceLocation.h presence... no
checking for clang/Basic/SourceLocation.h... no
configure: error: clang header file not found
configure: error: ./configure failed for pet

Any help or suggestions would be great! Thanks!

[inducer]

@lbang-hmc Try installing the development files for clang.

[inducer]

@lbang-hmc 8bcf87b

[lbang-hmc]

Just got back from vacation and tried this out. After a little fiddling with what I had already done and then using the updated scripts, it works!

Many thanks!

[thisiscam]

I know that this is an old issue. Is there any chance islpy can integrate barvinok into the pypi package? Potentially with something like:

pip install islpy[barvinok]

would be very neat!

What would be the main bottleneck till something like above can be supported? Is it the shipping of barvinok?

Ref. "extra_requires" in https://setuptools.readthedocs.io/en/latest/references/keywords.html

[inducer]

The main issue is that barvinok has fairly complex build dependencies, see the script. I don't think we can usefully package that complex of a C/C++ build operation into setuptools. It might be possible to ship a binary wheel (and I'd be happy to consider a PR for a CI job that does builds one).

[inducer]

FWIW: See the existing wheel-building job that @isuruf worked on recently. Note that I'm not sure I'd like the default wheels to have barvinok support, because it is GPL.

[isuruf]

For a binary wheel using something like islpy[barvinok], you'll need to separate the barvinok functions into a separate namespaced module which is a non-trivial refactoring of islpy.

[thisiscam]

@isuruf I don't see why that is necessary though? I'm imagining the current setup where we just have the Set.card() function from barvinok baked into islpy?

[isuruf]

As @inducer said, barvinok is GPL which makes the binary wheel GPL and any work using islpy would have to be GPL.

[thisiscam]

@inducer

I don't think we can usefully package that complex of a C/C++ build operation into setuptools.

How about we just let setup.py invoke build-with-barvinok.sh and assume all the configure dependencies exists? That way I think we'd be able to build wheels from setup.py.

[inducer]

How about we just let setup.py invoke build-with-barvinok.sh and assume all the configure dependencies exists? That way I think we'd be able to build wheels from setup.py.

build-with-barvinok.sh runs islpy's setup.py (with specific options), so that wouldn't work.

we'd be able to build wheels from setup.py.

I'm not sure what you mean. The main point of wheels is that they're binaries that are distributable through the package index.

[thisiscam]

As @inducer said, barvinok is GPL which makes the binary wheel GPL and any work using islpy would have to be GPL.

Wouldn't it be possible to only let the wheel which has barvinok baked-in to use a GPL license?
According to this explanation, this should be possible?

[inducer]

Yes. The licensing isn't the complicated part. It'll just never happen for the upstream islpy wheels, because those must remain under the MIT license that they are currently under.

If you'd like to ship separate islpy wheels (either through a separate pypi project, or as build variants if the package index supports such a thing) and you're volunteering to do the release engineering involved (and/or contribute that to islpy), you're more than welcome.

[kaushikcfd]

An alternative is to call conda install islpy barvinok. Thanks to conda-forge/islpy-feedstock#31.