See https://trac.sagemath.org/ticket/24337 for actually doing this.
--
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 sage-devel+unsubscr...@googlegroups.com.
To pos
Hi Simon,
On Monday, October 30, 2017 at 5:18:27 PM UTC, Simon King wrote:
>
> Hi Jeroen,
>
> On 2017-10-30, Jeroen Demeyer >
> wrote:
> > Another very relevant question: are pickles supposed to be
> > hardware/OS-independent? In other words: can I take a pickle from one
> > machine and unpic
Hi Jeroen,
On 2017-10-30, Jeroen Demeyer wrote:
> On 2017-10-30 08:41, Simon King wrote:
>> would you rather have no test at all than a
>> superficial consistency test on a wide range of objects, versions and
>> machines?
>
> Yes. A test which doesn't actually test anything is worse than no test.
Hi Jeroen,
On 2017-10-30, Jeroen Demeyer wrote:
> Another very relevant question: are pickles supposed to be
> hardware/OS-independent? In other words: can I take a pickle from one
> machine and unpickle it on a different machine (assuming that the
> software version is the same)?
Should be,
On Mon, Oct 30, 2017 at 4:33 PM, Jeroen Demeyer wrote:
> On 2017-10-30 16:28, William Stein wrote:
>>
>> Not necessarily.Pickle is *the* canonical extensible object
>> serialization system for Python. It’s of course very extensible in
>> that users can define how objects pickle, eg by defini
On 2017-10-30 16:28, William Stein wrote:
Not necessarily.Pickle is *the* canonical extensible object
serialization system for Python. It’s of course very extensible in
that users can define how objects pickle, eg by defining a dunder reduce
method. As such they can of course make that met
On Mon, Oct 30, 2017 at 8:17 AM Jeroen Demeyer
wrote:
> Another very relevant question: are pickles supposed to be
> hardware/OS-independent? In other words: can I take a pickle from one
> machine and unpickle it on a different machine (assuming that the
> software version is the same)?
Not ne
Another very relevant question: are pickles supposed to be
hardware/OS-independent? In other words: can I take a pickle from one
machine and unpickle it on a different machine (assuming that the
software version is the same)?
--
You received this message because you are subscribed to the Googl
On Mon, Oct 30, 2017 at 3:35 PM, Jeroen Demeyer wrote:
> On 2017-10-30 15:12, Erik Bray wrote:
>>
>> My point, however, is baked directly into the file format--the pickle
>> format is very Python version-dependent (there are I think 5 different
>> pickle formats now)
>
>
> It's true that the forma
On 2017-10-30 15:12, Erik Bray wrote:
My point, however, is baked directly into the file format--the pickle
format is very Python version-dependent (there are I think 5 different
pickle formats now)
It's true that the format has changed, but always in a
backward-compatible way. For basic Pytho
On 2017-10-29 23:14, Travis Scrimshaw wrote:
What about any object that does a TestSuite(foo).run()? This guarantees
that it pickles (assuming it is not skipping that test) and is an object
that someone would create.
Sounds like a good idea to me. We could have TestSuite(foo).run() create
a sp
On 2017-10-29 20:22, Simon King wrote:
The m*n-fold pickle jar should not pollute the SageMath sources.
In that way, a new pickle jar version wouldn't result in a new
to-be-merged git commit. Instead, the jar should only be stored
on some SageMath servers.
I don't like this part. It should be e
On 2017-10-30 08:41, Simon King wrote:
would you rather have no test at all than a
superficial consistency test on a wide range of objects, versions and
machines?
Yes. A test which doesn't actually test anything is worse than no test.
That's exactly the situation that we currently have with th
On Sun, Oct 29, 2017 at 10:04 AM, Simon King wrote:
> Hi Erik,
>
> On 2017-10-27, Erik Bray wrote:
>> Plus, while pickling has many valid runtime use-cases, particularly
>> for IPC, and short-term preservation of objects between interpreter
>> sessions, it was *never* intended for long-term data
On 2017-10-29, Volker Braun wrote:
> Thats still only addressing that objects can be unpickled
No, it is also addressing that "the same" objects unpickled from
different SageMath versions and different machines evaluate equal.
> ; You'd also have
> to run the entire testsuite with the unpickled
Thats still only addressing that objects can be unpickled; You'd also have
to run the entire testsuite with the unpickled objets if you want to have
any reasonable guarantee that they are actually working. Put differently,
how likely do you think it is that some old pickle unpickles and passes
I think tying it in with TestSuite(foo).run() is a good idea, but we
probably don't want to store pickles for every one (since test suites can
be run for multiple elements of the same type). Maybe check to see if a
pickle has already been created for a given class, and if not, create one?
David
O
On Monday, October 30, 2017 at 5:46:49 AM UTC+10, Jeroen Demeyer wrote:
>
> On 2017-10-29 20:22, Simon King wrote:
> > As part of the release process of a new version of SageMath,
> > a new version of the pickle jar is created by some patchbots
> > on m different machines and replaces the m ol
On Sun, Oct 29, 2017 at 12:46 PM Jeroen Demeyer
wrote:
> On 2017-10-29 20:22, Simon King wrote:
> > As part of the release process of a new version of SageMath,
> > a new version of the pickle jar is created by some patchbots
> > on m different machines and replaces the m oldest versions of
> > t
On 2017-10-29 20:22, Simon King wrote:
As part of the release process of a new version of SageMath,
a new version of the pickle jar is created by some patchbots
on m different machines and replaces the m oldest versions of
the pickle jar.
That's the easy part. The hard part is deciding what to
On 2017-10-29, David Roe wrote:
> I agree that removing pickles from 6+ years ago is a good idea.
>
> I do think, however, that the idea of being able to save objects between
> versions of Sage is valuable. And we need some way to test it. Maybe we
> could move to some sort of rolling pickle jar
On Sun, Oct 29, 2017 at 7:58 AM Dima Pasechnik wrote:
> The conventional wisdom is to avoid pickles in favour of JSON (the latter
> is a platform-independent human-parseable text, the former is some
> Python-only binary stuff).
Whether this is a good idea depends a lot on the domain. E.g., try
The conventional wisdom is to avoid pickles in favour of JSON (the latter is a
platform-independent human-parseable text, the former is some Python-only
binary stuff).
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this gro
I agree that removing pickles from 6+ years ago is a good idea.
I do think, however, that the idea of being able to save objects between
versions of Sage is valuable. And we need some way to test it. Maybe we
could move to some sort of rolling pickle jar, where we allow deprecations
after a cert
Hi Erik,
On 2017-10-27, Erik Bray wrote:
> Plus, while pickling has many valid runtime use-cases, particularly
> for IPC, and short-term preservation of objects between interpreter
> sessions, it was *never* intended for long-term data storage,
Seriously? Said who?
I always thought of pickles a
Hi,
Le vendredi 27 octobre 2017 10:42:53 UTC+2, Jeroen Demeyer a écrit :
>
> Since the pickle jar doesn't do what it is meant to do, I suggest to be
> pragmatic and remove it completely.
>
>
+1
Eric.
--
You received this message because you are subscribed to the Google Groups
"sage-devel" gr
Remove it.
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send email to sage-devel@googlegroups.co
27 matches
Mail list logo
