Hi Bruno!
> Le 13 oct. 2018 à 18:11, Bruno Haible a écrit :
>
> Hi Akim,
>
>> Or we filter on the percentages.
>
> Yes, filtering on percentages is the way to go. The user doesn't
> care about contributions < 1% or < 0.5%. When people draw pie charts,
> such minimal contributions are usually c
Darshit Shah wrote:
+# If using Python 2, ensure that at least version 2.7 is used. Older versions
+# are not supported
+if not PYTHON3 or sys.version_info[1] < 7:
+print("Python version must be atleast 2.7. Exiting.")
Shouldn't this be:
if not PYTHON3 and sys.version_info[1] < 7:
--
--
Given that pygnulib aims to support on Python 3, maybe we should change this
patch slightly to also provide for a way to fallback if the python version
fails?
Any ideas on how it should be implemented?
* Darshit Shah [181013 22:03]:
> We at GNU Wget have been using the new Python implementation
That's good to hear! :-)
However in that case, let me point out that there is already a significant
amount of code and checks in there for Python 2 compatibility. Removing even
some of them might help with the overall maintainability of the codebase.
And for Wget2, we will change our base require
Well, I don't think there will be a Python 4 for a very long time. The major
version number changes only for a large backwards incompatibility. It's taken
them ~10 years and people still not on Python 3.
Anyways, I don't think this will break even with v4. Since the check is only
for ensuring the
Hi Darshit,
> gnulib-tool.py will currently crash immediately on start if the underlying
> Python version is 2.6 or lower.
It's intentional that it supports only Python 3. See
https://lists.gnu.org/archive/html/bug-gnulib/2017-09/msg00123.html
Bruno
On 13.10.18 21:28, Darshit Shah wrote:
> gnulib-tool.py will currently crash immediately on start if the underlying
> Python version is 2.6 or lower. The immediate crash that is seen occurs during
> the check for the Python version. The check uses a syntax which was only
> introduced in 2.7. I have
gnulib-tool.py will currently crash immediately on start if the underlying
Python version is 2.6 or lower. The immediate crash that is seen occurs during
the check for the Python version. The check uses a syntax which was only
introduced in 2.7. I haven't checked, but I believe that the rest of the
We at GNU Wget have been using the new Python implementation of gnulib-tool for
a while now and it has been working pretty smoothly. However, we always have to
patch the bootstrap script manually to enable use of the tool since there is
currently no way in gnulib to enable it. The attached patch ad
Hi Akim,
> we measure integral types, let’s stick with them.
> The less I use floating types, the happier I am.
Fine with me. I must have misunderstood you.
> It’s of course more precise when you have tons of utils (coreutils),
> or several libraries, etc.
Yes. Not every platform supports GNU l
> Le 13 oct. 2018 à 15:41, Bruno Haible a écrit :
>
> Hi Akim,
>
>> But it felt weird to use a double, the number of significant decimal digits
>> of a float (about 7) seems enough.
>
> This is the line I'm talking about:
>
> timer->wall += stop->wall - start->wall;
Sorry, I was unclear.
Hi Akim,
> But it felt weird to use a double, the number of significant decimal digits
> of a float (about 7) seems enough.
This is the line I'm talking about:
timer->wall += stop->wall - start->wall;
24 bits of precision might be sufficient for timer->wall; for a measured
time, the user won'
> Le 13 oct. 2018 à 08:43, Bruno Haible a écrit :
>
> Hi Akim,
>
>>> I don’t know how 'gettime' compares against 'gethrxtime'.
>>
>> gethrxtime is exactly what I need, thanks! It does use gettime as
>> a fallback, after having tried better (accuracy and monotony) options.
>
> Very nice!
>
13 matches
Mail list logo
