ligo-segments issueshttps://git.ligo.org/lscsoft/ligo-segments/-/issues2022-01-20T13:39:47Zhttps://git.ligo.org/lscsoft/ligo-segments/-/issues/15debian/* not updated for 1.4.02022-01-20T13:39:47ZSteffen Grunewalddebian/* not updated for 1.4.0While the `.spec` file has been updated to reflect the version 1.4.0, `debian/changelog` still has 1.3.0 (which apparently never made it to SCCB) as the most recent release.While the `.spec` file has been updated to reflect the version 1.4.0, `debian/changelog` still has 1.3.0 (which apparently never made it to SCCB) as the most recent release.https://git.ligo.org/lscsoft/ligo-segments/-/issues/12tp_print removed in python3.92021-01-06T06:25:33ZDuncan Macleodduncan.macleod@ligo.orgtp_print removed in python3.9Building ligo-segments is failing on python3.9 since `tp_print` has been removed, see https://docs.python.org/3.9/whatsnew/3.9.html#id3. Since python2.7 is dead, perhaps the [relevant line](https://git.ligo.org/lscsoft/ligo-segments/-/bl...Building ligo-segments is failing on python3.9 since `tp_print` has been removed, see https://docs.python.org/3.9/whatsnew/3.9.html#id3. Since python2.7 is dead, perhaps the [relevant line](https://git.ligo.org/lscsoft/ligo-segments/-/blob/845aa21041c9f47bff7d37600eb5c4c3f12bab2a/src/segments.c#L119) can just be removed?https://git.ligo.org/lscsoft/ligo-segments/-/issues/10No tag for version 1.2.02020-08-06T00:14:32ZLeo P. SingerNo tag for version 1.2.0There is no tag in this repository for the most recently released version, which is 1.2.0. Would you please add a tag?There is no tag in this repository for the most recently released version, which is 1.2.0. Would you please add a tag?https://git.ligo.org/lscsoft/ligo-segments/-/issues/9copying a segmentlist returns a list in python 32020-07-23T22:45:20ZPatrick Godwincopying a segmentlist returns a list in python 3Minimal example:
```
Python 3.6.8 (default, Apr 1 2020, 10:29:41)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ligo.segments import segmentlist
>>> s ...Minimal example:
```
Python 3.6.8 (default, Apr 1 2020, 10:29:41)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> from ligo.segments import segmentlist
>>> s = segmentlist([])
>>> type(s)
<class 'ligo.segments.__segments.segmentlist'>
>>> type(s.copy())
<class 'list'>
```
Note that `copy()` isn't defined for python 2:
```
Python 2.7.5 (default, Apr 1 2020, 10:09:19)
[GCC 4.8.5 20150623 (Red Hat 4.8.5-39)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> from ligo.segments import segmentlist
>>> s = segmentlist([])
>>> type(s)
<type 'ligo.segments.__segments.segmentlist'>
>>> type(s.copy())
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: 'ligo.segments.__segments.segmentlist' object has no attribute 'copy'
```https://git.ligo.org/lscsoft/ligo-segments/-/issues/8fix dependency on python-lal2020-08-06T00:13:41ZAdam Mercerfix dependency on python-lal`ligo-segments` is still depending on the deprecated `lal-python{,3}` packages, can the dependencies be fixed to depend on `python{,3}-lal`?`ligo-segments` is still depending on the deprecated `lal-python{,3}` packages, can the dependencies be fixed to depend on `python{,3}-lal`?https://git.ligo.org/lscsoft/ligo-segments/-/issues/7Windows build fails because or min max name clash (I think)2020-08-08T18:47:46ZDuncan Macleodduncan.macleod@ligo.orgWindows build fails because or min max name clash (I think)[Builds on windows](https://ci.appveyor.com/project/conda-forge/ligo-segments-feedstock/builds/22094223/job/k0llu8rsek7b0mki#L709) are failing because (I think) the names `min` and `max` are already defined, at least, if I rename those f...[Builds on windows](https://ci.appveyor.com/project/conda-forge/ligo-segments-feedstock/builds/22094223/job/k0llu8rsek7b0mki#L709) are failing because (I think) the names `min` and `max` are already defined, at least, if I rename those functions then the builds pass again.
Can we just rename these functions to not clash? I can't actually find a definitive reference that confirms that this is indeed the problem, but have found a bunch of references to a macro `NOMINMAX` that might disable those definitions, but I haven't been able to get it to work.https://git.ligo.org/lscsoft/ligo-segments/-/issues/6please test for new release2019-01-30T19:25:09ZKipp Cannonplease test for new releaseI am ready for a 1.2.0 release. Please confirm that the removal of ligo-common from setup.py has had the effect you wish. Also I have reworded the C module initialization code to not require six.h (won't compile on Windows). Could you...I am ready for a 1.2.0 release. Please confirm that the removal of ligo-common from setup.py has had the effect you wish. Also I have reworded the C module initialization code to not require six.h (won't compile on Windows). Could you test that it still builds in your Python 3 environment? Thanks.Leo P. SingerLeo P. Singerhttps://git.ligo.org/lscsoft/ligo-segments/-/issues/5ligo-common dependency breaks `python setup.py test` for other projects that ...2018-12-21T03:10:23ZLeo P. Singerligo-common dependency breaks `python setup.py test` for other projects that include namespace packagesSince version 1.1.0, ligo-segments has required ligo-common, which provides a [`pkg_resources`-style namespace package](https://packaging.python.org/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages) but fails t...Since version 1.1.0, ligo-segments has required ligo-common, which provides a [`pkg_resources`-style namespace package](https://packaging.python.org/guides/packaging-namespace-packages/#pkg-resources-style-namespace-packages) but fails to declare it in setup.py in `namespace_packages`. For other projects that include subpackages of the `ligo` namespace package, this breaks the ability to run `python setup.py test` without first installing. This interferes with CI testing.
Please drop the dependency ligo-common. As a workaround, I am requiring ligo-segments<1.1.0 in my projects (see lscsoft/ligo.skymap!62.https://git.ligo.org/lscsoft/ligo-segments/-/issues/4segment logic appears to be broken on the clusters2018-08-03T13:42:02ZReed Essickreed.essick@ligo.orgsegment logic appears to be broken on the clustersA few basic segment manipulations seem to be broken. Not only do they not produce the correct result, they depend on the order in which objects are specified in a non-intuitive way.
```
>>> from ligo import segments
>>> a = segments.seg...A few basic segment manipulations seem to be broken. Not only do they not produce the correct result, they depend on the order in which objects are specified in a non-intuitive way.
```
>>> from ligo import segments
>>> a = segments.segmentlist([segments.segment(30, 510)])
>>> b = segments.segmentlist([segments.segment(400, 600)])
>>> a and b ### should be the intersection -> [segment(400, 510)]
[segment(400, 600)]
>>> b and a
[segment(30, 510)]
>>> a or b ### should be the union -> [segment(30, 600)]
[segment(30, 510)]
>>> b or a
[segment(400, 600)]
```
It looks like the manipulations are just returning the first object specified instead of actually computing anything. I'm working at LHO with "version 1.0.0", if that helps.
/cc @duncanmmacleod @kipp.cannonhttps://git.ligo.org/lscsoft/ligo-segments/-/issues/3Does not create __init__.py for ligo package or does not depend on package th...2018-12-20T15:30:04ZAlex NitzDoes not create __init__.py for ligo package or does not depend on package that willThis package cannot be currently installed, at least as tested on python2.7. It doesn't create the __init__ package or depend on one that does it seems. This is causing issues as lalsuite just added a dependency on this package which now...This package cannot be currently installed, at least as tested on python2.7. It doesn't create the __init__ package or depend on one that does it seems. This is causing issues as lalsuite just added a dependency on this package which now fails to import.
Downstream this causes the pycbc tutorials to fail, see
https://github.com/gwastro/pycbc/issues/2250https://git.ligo.org/lscsoft/ligo-segments/-/issues/2Test suite doesn't actually test python implementation2019-01-31T08:10:27ZDuncan Macleodduncan.macleod@ligo.orgTest suite doesn't actually test python implementationThe `test/segments_verify.py` script doesn't test the Python implementation as designed, just the C implementation twice.
This is because there is no way to import the Python objects independently of the C objects.The `test/segments_verify.py` script doesn't test the Python implementation as designed, just the C implementation twice.
This is because there is no way to import the Python objects independently of the C objects.https://git.ligo.org/lscsoft/ligo-segments/-/issues/1Build failure on windows, no 'inline' keyword2019-02-05T10:15:57ZDuncan Macleodduncan.macleod@ligo.orgBuild failure on windows, no 'inline' keyword`ligo-segments` fails to build on windows using visual studio:
```
creating build\temp.win32-2.7\Release\src
C:\Users\appveyor\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox /MD /W3...`ligo-segments` fails to build on windows using visual studio:
```
creating build\temp.win32-2.7\Release\src
C:\Users\appveyor\AppData\Local\Programs\Common\Microsoft\Visual C++ for Python\9.0\VC\Bin\cl.exe /c /nologo /Ox /MD /W3 /GS- /DNDEBUG -Isrc -IC:\Python27\include -IC:\Python27\PC /Tcsrc/segments.c /Fobuild\temp.win32-2.7\Release\src/segments.obj
segments.c
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(51) : error C2054: expected '(' to follow 'inline'
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(52) : error C2085: 'PyModule_Create' : not in formal parameter list
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(52) : error C2143: syntax error : missing ';' before '{'
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(64) : error C2054: expected '(' to follow 'inline'
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(65) : error C2085: 'PyModule_Create2' : not in formal parameter list
c:\users\appveyor\appdata\local\temp\1\pip-req-build-aienan\src\six.h(65) : error C2143: syntax error : missing ';' before '{'
src/segments.c(72) : warning C4013: 'PyModule_Create' undefined; assuming extern returning int
src/segments.c(72) : warning C4047: '=' : 'PyObject *' differs in levels of indirection from 'int'
error: command 'C:\\Users\\appveyor\\AppData\\Local\\Programs\\Common\\Microsoft\\Visual C++ for Python\\9.0\\VC\\Bin\\cl.exe' failed with exit status 2
```
The solution (I think) is to add something like this to `segments.h`:
```diff
diff --git a/src/segments.h b/src/segments.h
index 2b2b1ad..0f3558e 100644
--- a/src/segments.h
+++ b/src/segments.h
@@ -36,6 +36,26 @@
#define MODULE_NAME "ligo.__segments"
+#ifdef _MSC_VER
+ #define inline __inline
+ #ifndef NAN
+ static const unsigned long __nan[2] = {0xffffffff, 0x7fffffff};
+ #define NAN (*(const double *) __nan)
+ #endif
+ #ifndef INFINITY
+ static const unsigned long __infinity[2] = {0x00000000, 0x7ff00000};
+ #define INFINITY (*(const double *) __infinity)
+ #endif
+#else
+ #ifndef INFINITY
+ #define INFINITY (1.0/0.0)
+ #endif
+ #ifndef NAN
+ #define NAN (INFINITY-INFINITY)
+ #endif
+#endif
+
+
/*
* ============================================================================
*
```
(and similarly to `six.h`). @kipp.cannon, does that make sense to you?
Or, should we just forgo building the C extensions on windows and provide only the pure-python version?