[sage-devel] Re: Getting rid of the pickle jar
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. > That's exactly the situation that we currently have with the pickle jar. The current pickle jar tests that the pickles unpickle. My proposition is: Test that pickles of the same object created under different circumstances (1) unpickle, (2) evaluate equal and (3) pass TestSuite.run(). That'd be a progress, compared with the current pickle jar, and would indeed a nontrivial test, since it should be easy to create a custom pickle format that simply dumps a bit pattern and would behave differently on a big endian or little endian machine. Or (which is the case for MeatAxe matrices) you can store data in a memory chunk of size m*sizeof(long), even when the actual data doesn't fill all bytes of the last long in the memory chunk; whether or not it is used for specific data may depend on sizeof(long). In order to make pickling machine independent (which it *should* be, IMHO), you need to dump only the bytes that are actually used. Regards, Simon -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Getting rid of the pickle jar
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, and would be tested with the scheme that I proposed for the future pickle jars. Cheers, Simon -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 defining a dunder reduce >> method. As such they can of course make that method store output in any >> binary format they want. > > > The question is not what is possible, but what is the recommended way of > doing things. Are we supposed to make our pickles hardware-independent or is > that hopeless anyway? I guess it depends on what you mean by "supposed to". I believe that the pickle formats for built-in types are hardware-independent. E.g. int values are stored as little-endian and loaded as little-endian in a hardware-independent manner. So that at least appears to be the intent. But I don't know if there's any *requirement* that a pickle be hardware-independent when it comes to custom types, though in general it's probably better that they are. But for custom code that, say, targets only one hardware platform anyways then that's up to the developer -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 16:51, Erik Bray wrote: Thanks to some request/response dumps Jeroen sent me, I think I can take a guess at the problem. His university has set up a forward proxy to cache static HTTP resources, and so while his /login request comes from his machine, or whatever NAT router it's behind, requests for static resources on the site come from the proxy, which is forwarding headers but is not at the same IP address. So the check_ip setting in the Trac config fails and invalidates his trac_auth cookie. Thanks for the analysis and fix! -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On Mon, Oct 30, 2017 at 4:32 PM, Jori Mäntysalo wrote: > On Mon, 30 Oct 2017, Erik Bray wrote: > >>> OK, the common source of problems might be my university network. > > >> Hard to imagine--maybe the university network has a proxy that is >> stripping/corrupting some request and/or response headers? > > > Not at all that strange to me. Just three weeks ago we changed some routes, > and then about 10 percent of students could not anymore upload files bigger > than about 100 kilobytes to some of our servers. Somehow a "university > router" (big one) and "department router" (small one) did not like each > other. > > Still I do not know what exactly happened. Maybe some tcp fragmentation > thing, timings, or some other things. Thanks to some request/response dumps Jeroen sent me, I think I can take a guess at the problem. His university has set up a forward proxy to cache static HTTP resources, and so while his /login request comes from his machine, or whatever NAT router it's behind, requests for static resources on the site come from the proxy, which is forwarding headers but is not at the same IP address. So the check_ip setting in the Trac config fails and invalidates his trac_auth cookie. I'm just going to disable the check_ip setting. It doesn't really offer any value security-wise, especially not for an internet-facing site. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 method store output in any binary format they want. The question is not what is possible, but what is the recommended way of doing things. Are we supposed to make our pickles hardware-independent or is that hopeless anyway? -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On Mon, 30 Oct 2017, Erik Bray wrote: OK, the common source of problems might be my university network. Hard to imagine--maybe the university network has a proxy that is stripping/corrupting some request and/or response headers? Not at all that strange to me. Just three weeks ago we changed some routes, and then about 10 percent of students could not anymore upload files bigger than about 100 kilobytes to some of our servers. Somehow a "university router" (big one) and "department router" (small one) did not like each other. Still I do not know what exactly happened. Maybe some tcp fragmentation thing, timings, or some other things. -- Jori Mäntysalo
Re: [sage-devel] Re: Getting rid of the pickle jar
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 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 method store output in any binary format they want. Example: look at some of the cython matrix code I mentioned above. I hope it is architecture neutral as written, but I’m sure you could easily imagine how to write something similar that isn’t. - William > > -- > 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.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. > -- -- William Stein -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 15:50, Erik Bray wrote: Is it possible you're using Tor or some other sort VPN that uses a different IP address on each request? Personally, I'm not doing that. But it could be that my university is doing something funny. As I said, the problem seems to be with my university wifi, not my computer. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 format has changed, but always in a backward-compatible > way. For basic Python objects (lists, numbers, strings, ...) I'm pretty sure > that old pickles can still be unpickled correctly. The issue is with > user-defined classes. Right, I could have been more clear about that. But for Sage it's exactly those user-defined classes that matter most. It would be good to have some serious thought/discussion about portable serialization options for Sage objects. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On Mon, Oct 30, 2017 at 3:23 PM, Erik Bray wrote: > On Mon, Oct 30, 2017 at 11:12 AM, Jeroen Demeyer > wrote: >> On 2017-10-30 11:07, Jeroen Demeyer wrote: >>> >>> I just tried with my phone and the problem also occurs there! What is >>> wrong with me if I'm the only person having this problem? >> >> >> OK, the common source of problems might be my university network. I disabled >> wifi on my phone and now it seems to work... >> >> Still, the question remains: what could my network be doing which breaks >> logins to Trac? > > Hard to imagine--maybe the university network has a proxy that is > stripping/corrupting some request and/or response headers? > > Is there an easy way you could capture and send me a capture of those > headers when you login e.g. using your browser's developer tools? > Might be helpful to look at for comparison's sake. On second thought, one thing I just remembered: We have a setting enabled that ties Trac cookies to an IP address: If you connect with an existing cookie from a different IP address from when it was created, that cookie is treated as invalid and should be forced to expire, thus forcing you to re-login. Is it possible you're using Tor or some other sort VPN that uses a different IP address on each request? This has been a problem for some people before. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 Python objects (lists, numbers, strings, ...) I'm pretty sure that old pickles can still be unpickled correctly. The issue is with user-defined classes. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On Mon, Oct 30, 2017 at 11:12 AM, Jeroen Demeyer wrote: > On 2017-10-30 11:07, Jeroen Demeyer wrote: >> >> I just tried with my phone and the problem also occurs there! What is >> wrong with me if I'm the only person having this problem? > > > OK, the common source of problems might be my university network. I disabled > wifi on my phone and now it seems to work... > > Still, the question remains: what could my network be doing which breaks > logins to Trac? Hard to imagine--maybe the university network has a proxy that is stripping/corrupting some request and/or response headers? Is there an easy way you could capture and send me a capture of those headers when you login e.g. using your browser's developer tools? Might be helpful to look at for comparison's sake. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 special pickle which also stores how TestSuite.run() was called. Then we could re-run the TestSuite when testing the pickle jar. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 easily available to users for testing. Maybe make it an optional package and mark the test "# optional - pickle_jar". -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 the pickle jar. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Getting rid of the pickle jar
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 storage, > > Seriously? Said who? > > I always thought of pickles as the default way to store the results > of long computations, for later (potentially MUCH later) use. Of course, > it always is possible to say "install an old software version to unpickle > the results" or "write a routine that allows to read the old pickle in > a new software version", but as part of user-friendliness, I would > recommend that SageMath-developers keep considering it as their duty to > make unpickling backward-compatible, to a reasonable extent. I'll see if I can find an "authoritative" source making this claim, but I believe it is conventional wisdom (along the lines of "goto considered evil"--it's not as if there aren't valid uses for it but it should be avoided unless you know what you're doing). 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) and the way non-trivial objects are pickled is highly tied to the version of the source code at which that pickled object was saved. It depends on the module layout, class names, implementation of that object's __reduce__ at the time the pickle was made, etc. So while you can use pickle for long-term storage, it's implicit in the format that if you want to unpickle an object saved at a given time, you may need to be running the same version of the software at which the pickle was created (it might be nice if there were somehow a way to mark this explicitly when pickling Sage objects, e.g. with the current git hash). Anyways, as I wrote for short-term storage (e.g. results of long computations that will be reused later in the same software) it's fine. For long-term you want a more transparent, more interoperable serialization format. JSON isn't sufficient for all uses cases, but there are other alternatives as well, even for binary data. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Re: Proposal : a branch for OpenSSL-less Sage
On Sat, Oct 28, 2017 at 4:24 PM, Maarten Derickx wrote: > > On Friday, 27 October 2017 16:19:30 UTC+2, Emmanuel Charpentier wrote: >> >> Dear Marteen, >> >> Le vendredi 27 octobre 2017 16:02:03 UTC+2, Maarten Derickx a écrit : >>> >>> Why a separate git branch and not make it something configurable, like >>> building sage with gmp vs mpir? >> >> >> Because those are not the same cases : >> > > Well, yes there clearly are differences between to the two scenarios. But > your arguments are all either just a) pointing out differences between the > mpir vs OpenSSL situation or b) arguments against the usefulness of being > able to build sage without OpenSSL and this is not what I was asking for. > What I actually was looking for were arguments for why having a branch is a > better idea then making it something configurable. I think the choice > between a branch and something configurable is something that is just a > technical difference on how to achieve the wished end result (make it > possible to compile sage without OpenSSL). So here some reasons why I think > a separate branch is a worse idea then making the instalalation of OpenSSL > configurable: > 1) A separate branch creates way more maintenance work then making it > configurable since now something needs to be done each release, instead of > potentially doing something when R is updated. > 2) Because a separate branch it is quite a far fetched solution compared to > using configure and make and maybe some environment variables which are the > standard tools for deciding how and what to build. > 3) It deviates from the way sage currently behaves with respect configuring > which packages to install, requiring the user to learn something new. Making > the sage the distribution experience feel less coherent. > >> >> a) there is no currently (to the best of my limited knowledge) , strong >> reasons to choose one over the other, >> b) they give (modulo my limited knoiwledge, again) roughly the same >> possibilities to Sage, >> c) there are people able, and *volunteering*, to maintaint this >> alternative. >> >> In the case of OpenSSL not having OpenSSL: >> >> a) doesn't give us anything but the ability to do without a package deemed >> "GPL incompatible" (in the sense that we currently cannot ship it with >> Sage) > > > Which is a useful ability to have considering the bad experience almost al > sage-devs on OS X had getting this to work. > >> >> b) deprives R and pip users of an useful ability (deemed mandatory by R >> authors) > > > Or worded differently: gives people the option to have a working sage > installation missing just two of its many features instead of no sage > installation at all if getting sage to work with OpenSSL turns out to be too > difficult. This is what Jeroen meant with his Koan about that an R that > builds without OpenSSL can be very usefull for people not using R, since it > means they can forget about the non trivial step (on some platforms) of > getting OpenSSL to work. > >> >> c) forces us to maintain a patch that is of no use to what I think a >> majority of Sage users. > > > Well I think the statement "this patch is of no use to what I think a > majority of Sage users" is a very important statement since the answer to > the key question: "Do we wish to support building sage without OpenSSL?" > hinges on wether you consider c) to be true. Several people (including me, > but also other sage developers I talked to at some sage days) have had > serious trouble getting sage to build with OpenSSL so having an option to > avoid these troubles at the cost of a less functional R and pip is certainly > something useful for at least a significant minority of the Sage users. > > Additionally I think demanding something to be useful to a majority is a way > to strong criterion for when to support something in sage or not, otherwise > we could also probably also say: R in sage is not used by the majority of > Sage users so we might as well not ship it. > > Now wether "this patch is of no use to what I think a majority of Sage > users" is true also very much depends on how difficult it is to get sage to > work with OpenSSL, if this is trivial then of course the patch is of no use. > But I think at least in the current sage it is not trivial on all platforms. > For this reason I am for anything that is working in the direction of making > it easier to get sage to work with OpenSSL, however the proposed changes > have not been implemented/let alone be battle tested. And requiring OpenSSL > to build sage is a change of the status quo. Personally I certainly believe > that in the long term we should just require OpenSSL, but at this moment > right now I think it is also important to provide a clean migration path. > Right now requiring OpenSSL is actually doing two things at once: > > 1) change the default from building without OpenSSL support to building with > OpenSSL support. > 2) remove the possibility of falling back to the old default
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 11:07, Jeroen Demeyer wrote: I just tried with my phone and the problem also occurs there! What is wrong with me if I'm the only person having this problem? OK, the common source of problems might be my university network. I disabled wifi on my phone and now it seems to work... Still, the question remains: what could my network be doing which breaks logins to Trac? -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Trac: getting logged out instantly
On 2017-10-30, Jeroen Demeyer wrote: > On 2017-10-30 10:09, Jeroen Demeyer wrote: >> It seems to work if I make an edit very quickly after logging in. So it >> looks as if I'm being automatically logged out 5 minutes after I log in >> or so. > > It's actually much less than 5 minutes, more like a few seconds. Often, > when I log in and then refresh the page, I see that I'm no longer logged > in. But this doesn't happen every time, there is a short interval of > time where I am still logged in. I have no idea what is happening here... That's an annoyance that I have suffered from repeatedly in the past few months. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
I just tried with my phone and the problem also occurs there! What is wrong with me if I'm the only person having this problem? -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 10:39, John Cremona wrote: Have you changed browser of cookie settings? I just tried another browser (Chromium instead of Firefox) and the problem persists. So I think that we can exclude the browser as source of problems. I have no idea what is going on... -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 30 October 2017 at 09:34, Jeroen Demeyer wrote: > On 2017-10-30 10:28, julien.puydt via sage-devel wrote: >> >> Clock issue? I would check the hours on the affected computers... > > > As far as I know, my clock is correct. It is being synchronized via NTP. > Current time on my machine is > > Mon Oct 30 10:34:36 CET 2017 > > It's true that my computer changed from UTC+2 to UTC+1 this weekend because > of the end of daylight saving time. Still, I would be surprised if that > would cause problems. It's working OK for me, on a machine which was switched off over the weekend and came back up with the new time correct. After 10 minutes I refresh a browser tab on which I am logged in to trac, and am still logged in. Have you changed browser of cookie settings? John > > > -- > 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.com. > Visit this group at https://groups.google.com/group/sage-devel. > For more options, visit https://groups.google.com/d/optout. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 10:28, julien.puydt via sage-devel wrote: Clock issue? I would check the hours on the affected computers... As far as I know, my clock is correct. It is being synchronized via NTP. Current time on my machine is Mon Oct 30 10:34:36 CET 2017 It's true that my computer changed from UTC+2 to UTC+1 this weekend because of the end of daylight saving time. Still, I would be surprised if that would cause problems. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
Clock issue? I would check the hours on the affected computers... -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Some sparse matrices cleanup and question on parallelism
On 2017-10-30 01:39, Travis Scrimshaw wrote: How difficult is it to parallelize Cython code? Cython supports OpenMP: http://cython.readthedocs.io/en/latest/src/userguide/parallelism.html Note that OpenMP may not be supported on all systems. This is something we will need to check. cysignals is a problem though. I haven't yet made that work with multi-threading. But this problem is getting more and more urgent... -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
Re: [sage-devel] Trac: getting logged out instantly
On 2017-10-30 10:09, Jeroen Demeyer wrote: It seems to work if I make an edit very quickly after logging in. So it looks as if I'm being automatically logged out 5 minutes after I log in or so. It's actually much less than 5 minutes, more like a few seconds. Often, when I log in and then refresh the page, I see that I'm no longer logged in. But this doesn't happen every time, there is a short interval of time where I am still logged in. I have no idea what is happening here... -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Trac: getting logged out instantly
Hello, this morning I'm having strange problems with Trac. I can log in to Trac and the page shows that I'm logged in. But whenever I try to make a change I get a permission error saying that I'm not logged in. It seems to work if I make an edit very quickly after logging in. So it looks as if I'm being automatically logged out 5 minutes after I log in or so. I don't think I changed anything to my browser, so I'm guessing it is a server problem. -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Some sparse matrices cleanup and question on parallelism
> > > Onto some paraellization questions, as I can take advantage of multiple > cores. Does anyone know of a good parallel linear algebra library we could > include in Sage (hopefully it would work with my field)? How difficult is > it to parallelize Cython code? At least in the classical echelonize > algorithm, we can parallelize setting the entries below the pivot to 0 > since each row can be handled independently (once we set the pivot). > Some other things that could be easily parallelized: the elementary row operations (perhaps even feeding these things off to the GPU? Could this be possible with Cython?). Best, Travis -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Some sparse matrices cleanup and question on parallelism
On Monday, October 30, 2017 at 5:47:10 PM UTC+10, Simon King wrote: > > Hi Travis, > > On 2017-10-30, Travis Scrimshaw > wrote: > > My first question is that the method _strassen_default_echelon_cutoff > seems > > to return -1 and never be overwritten. This means that by default, the > > echelonize will always use the classical in-place, making having a > default > > algorithm that automatically chosen a la XKCD. Does anyone use this? > Should > > we keep it, actually make it work, or get rid of the entire thing? > > If I recall correctly (though I didn't look it up) I use the > infrastructure > for Strassen multiplication in matrix_gfpn_dense. I am not sure, though. > it could be that the choice of multiplication algorithm is ultimately done > in the backend (i.e., MeatAxe, in the case of matrix_gfpn_dense). > There are different methods for deciding to use Strassen for echelon forms and multiplication. So the multiplication code would not be affected by removing the one for echelon forms. Best, Travis -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Some sparse matrices cleanup and question on parallelism
Hi Travis, On 2017-10-30, Travis Scrimshaw wrote: > My first question is that the method _strassen_default_echelon_cutoff seems > to return -1 and never be overwritten. This means that by default, the > echelonize will always use the classical in-place, making having a default > algorithm that automatically chosen a la XKCD. Does anyone use this? Should > we keep it, actually make it work, or get rid of the entire thing? If I recall correctly (though I didn't look it up) I use the infrastructure for Strassen multiplication in matrix_gfpn_dense. I am not sure, though. it could be that the choice of multiplication algorithm is ultimately done in the backend (i.e., MeatAxe, in the case of matrix_gfpn_dense). Best regards, Simon -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: Getting rid of the pickle jar
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 objets if you want to have > any reasonable guarantee that they are actually working. Sure, why not? After all, it was suggested in another posting that objects should be automatically put into the pickle jar if they are subject to a TestSuite.run() test. > Put differently, > how likely do you think it is that some old pickle unpickles and passes > superficial tests, but gives a mathematically incorrect answer if you call > some specialized method? Put differently, would you rather have no test at all than a superficial consistency test on a wide range of objects, versions and machines? -- 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.com. Visit this group at https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
