I am trying to understand the rationale behind this change in naming.
In particular as most (all?) distributions, apart from Conda, that
ship lcalc, use
include/Lfunction rather than include/libLfunction.
In particular this makes unvendoring lcalc unnecessary complicated, as both
naming schemes ha
Mon 2019-09-02 10:57:11 UTC, Dima Pasechnik:
>
> I am trying to understand the rationale behind this change in naming.
> In particular as most (all?) distributions, apart from Conda, that
> ship lcalc, use
> include/Lfunction rather than include/libLfunction.
>
> In particular this makes unve
On 2019-09-02, Simon King wrote:
> Strangely, when I read the pickle as a string
>open('path/to/file.sobj').read()
> then it fails with a (different?) UnicodeError in Python-3.
That's not the problem. However, I am not able to track down the problem
myself. So, I'd appreciate help.
I think I
Hello Simon,
As discussed in
https://groups.google.com/forum/#!topic/sage-devel/JuKzzgxDlmA
Pickling/unpickling is not supposed to work accross Sage versions
(including the Python version you use).
Is this what you are trying to make work?
Vincent
Le 02/09/2019 à 02:25, Simon King a écrit :
On 2019-09-02, Vincent Delecroix <20100.delecr...@gmail.com> wrote:
> As discussed in
>
> https://groups.google.com/forum/#!topic/sage-devel/JuKzzgxDlmA
>
> Pickling/unpickling is not supposed to work accross Sage versions
> (including the Python version you use).
>
> Is this what you are trying
I've uploaded a new version of NTL. Details on changes are
here: https://www.shoup.net/ntl/doc/tour-changes.html
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
PGFFT is a "pretty good FFT" for double-precision complex numbers, written
in C++. It's main selling points are (1) it's not too slow, and (2) it's
available under a BSD license. Details here: https://www.shoup.net/PGFFT/
--
You received this message because you are subscribed to the Google G
A clarification and a question...
NTL's config system does not use a pre-built ibtool script. Rather, it
builds a customized libtool by running a configure script on the host
machine, so it should, in principle, be using a libtool script that is
properly configured for the host machine.
The c
On Mon, Sep 2, 2019 at 11:37 PM Victor Shoup wrote:
>
> A clarification and a question...
>
> NTL's config system does not use a pre-built ibtool script. Rather, it
> builds a customized libtool by running a configure script on the host
> machine, so it should, in principle, be using a libtool
On Monday, September 2, 2019 at 6:22:24 PM UTC+2, Simon King wrote:
>
> Also, if I understand the error message "UnicodeDecodeError: 'ascii'
> codec can't decode byte 0x80 in position 0: ordinal not in range(128)"
> correctly, it is an error in unpickling a string. And this, I believe,
> can and
OK. So this is really a bug in libtool.
It seems to me that even if I used autotools for everything, the same
problem would persist
without a patch to ltmain.sh.
Is that right?
On Monday, September 2, 2019 at 4:42:44 PM UTC-4, Dima Pasechnik wrote:
>
> On Mon, Sep 2, 2019 at 11:37 PM Victor
On Tue, Sep 3, 2019 at 1:05 AM Victor Shoup wrote:
>
> OK. So this is really a bug in libtool.
it's a feature :-)
It's not hard to explicitly pass extra libraries to link to libtool,
and thus it's still like this.
> It seems to me that even if I used autotools for everything, the same problem
>
Hi,
Le 02/09/2019 à 22:43, Simon King a écrit :
> AFAIK, what I need to unpickle my old data is a way to tell Python-3
> that it shall (at least temporarily) unpickle all strings as bytes, in
> the sense that the pickled string '\x80\x1f' should be understood as
> b'\x80\x1f'. Is there a way?
I t
Hi!
On 2019-09-02, Simon King wrote:
> The problem apparently boils down to the following:
> - Pickle the string '\x80\x1f' in Python-2
> - Try to load that pickle in Python-3 (it fails).
>
> Bummer!
Nils Bruin pointed me to
https://stackoverflow.com/questions/28218466/unpickling-a-python-2-obj
PS:
On 2019-09-03, Simon King wrote:
> - Without `encoding='bytes'`, Python-3 can in general not unpickle any
> pickle created with Python-2 that contains strings.
Stated differently:
Ostensibly, Python-2 str corresponds to Python-3 bytes, and Python-2
unicode corresponds to Python-3 str. But
15 matches
Mail list logo
