[sage-devel] Re: Problem with pari in 7.4beta6
Emmanuel Charpentier wrote: > This is now Trac#21622 <https://trac.sagemath.org/ticket/21622>, which I > have no idea how to fix. man perlrun You can for example call perl with '-I.', or put that into the environment variable PERL5OPT. -leif > Le dimanche 2 octobre 2016 01:07:33 UTC+2, Michael Orlitzky a écrit : > > On 10/01/2016 01:18 PM, Emmanuel Charpentier wrote: > > [ Erroneously reported first on sage-release. Apologies.. ] > > > > I can't build sage 7.4beta6 on Debian testing : PARI fails to > build on a > > (copy of) a (functional) Sage tree after distclean. See the > attached log. > > This happens either after (repeated) attempts at parallel build or > with a > > serial build. > > > > Cross-posted in -release, but this should be fixed in PARI. Debian has > removed "." from the perl include path by default. That's a Good Idea > (for the same reason "." isn't in $PATH), and is planned for upstream > Perl, too. Debian is just pushing it sooner. -- 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: openblas segfault?
Jonathan Bober wrote:
> I got around to trying the latest OpenBLAS as Jean-Pierre Flori
> suggested, and the segfaults went away. (And all tests pass.) I guess
> that from my perspective this means I should open an "update to OpenBLAS
> 0.2.19" ticket. Or maybe it should be an "Update OpenBLAS to some
> working version" ticket. I don't know much about OpenBLAS, so I don't
> really know if 2.19 will work for me but will be broken for someone else.
Probably not a bad idea.
For me, building R currently segfaults in Sage 7.4.beta6 (with OpenBLAS)
while the same builds [with ATLAS] in Sage 7.3, both on a Piledriver
with FSF GCC 6.2 (configured to generate native code by default; without
any *FLAGS set by me).
OpenBLAS' testsuite though passes, and I recall to have seen similar in
building R in the past (quite long ago), but OTOH have no idea how I
fixed or worked around that previously.
I also noticed Sage's OpenBLAS package ("again") uselessly depends on
Sage's Python. And OpenBLAS' "configure" step doesn't seem to report
anything useful...
-leif
> (OpenBLAS 2.15, the current version, is from 11 months ago.)
>
> On Tue, Sep 27, 2016 at 9:48 AM, Jean-Pierre Flori <jpfl...@gmail.com
> <mailto:jpfl...@gmail.com>> wrote:
>
>
>
> On Monday, September 26, 2016 at 11:23:49 PM UTC+2, Jonathan Bober
> wrote:
>
> On Mon, Sep 26, 2016 at 10:10 PM, Jean-Pierre Flori
> <jpf...@gmail.com> wrote:
>
> I suspect that perhaps the copy I have the works is
> working because I built it as sage 7.3 at some point
> with SAGE_ATLAS_LIB set and then rebuilt it on the
> develop branch, which didn't get rid of the atlas
> symlinks that were already setup. So maybe it isn't
> actually using openBLAS.
>
> SAGE_ATLAS_LIB is just used for ATLAS, not OpenBlas.
>
>
> 1. So does that mean that on a clean build of the current
> development branch (or a recent enough beta) SAGE_ATLAS_LIB has,
> by default, no effect?
>
> Yes.
>
>
> 2. Either way, I suspect that doesn't necessarily mean that
> nothing strange happens if I build Sage 7.3 (with SAGE_ATLAS_LIB
> set) and then do a 'git checkout develop', then build again
> without first doing a distclean.
>
> Yes.
> I'm not exactly in what situation you end up when going this way
> because:
> * at 7.3, you ran configure/make which set up Atlas as the blas
> provider, build it and link everything to it
> * when checking out develop openblas became the default but I'm not
> sure this actually changed anything if configure was not run again
> before make... the best way to now for sure is to see if libraries
> depending on blas got rebuilt (in particular atlas and openblas do
> not provide binary compatible libraries, you have to link to libs
> with different names)
> Maybe Jeroen or Volker have a better idea of what situation you end
> up in.
>
> But if you run "make distclean" then you can be sure that openblas
> will be built and linked to...
--
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: trouble compiling latest sage development version
Volker Braun wrote: > My suggestion would be to upgrade to xcode 10.11, and then to the newer > xcode that is available on osx 10.11 only. That linker should then > properly support AVX instructions. Thats also the only OS/compiler > version that we have a buildbot for (or receives updates from Apple for > that matter). Well, until then the spkg-install scripts (sh|c)ould catch this (Sage's GCC emitting instructions Apple's ancient assembler doesn't support). It's weird Givaro's 'configure' claims AVX, AVX2 and FMA3 supported, but neither BMI nor BMI2. (Haven't looked at the macros used though.) -leif -- 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: linbox 64-bit charpoly
Jonathan Bober wrote: > On Tue, Sep 27, 2016 at 8:34 PM, 'Bill Hart' via sage-devel > <sage-devel@googlegroups.com <mailto:sage-devel@googlegroups.com>> wrote: > > > > On Tuesday, 27 September 2016 20:53:28 UTC+2, Jonathan Bober wrote: > > On Tue, Sep 27, 2016 at 7:18 PM, 'Bill Hart' via sage-devel > <sage-...@googlegroups.com> wrote: > > I'm pretty sure the charpoly routine in Flint is much more > recent that 2 years. Are you referring to a Sage > implementation on top of Flint arithmetic or something? > > > It is just a problem with Sage. > > > Sure, I realised the problem was in Sage. I just wasn't sure if the > algorithm itself is implemented in Flint or Sage. > > > Sorry, I thought I was clear about that. I assume that no one > has been using the algorithm='flint' option in Sage in the last > two years, which makes sense, because most people aren't going > to bother changing the default. > > > The only timing that I can find right at the moment had us > about 5x faster than Sage. It's not in a released version of > Flint though, just in master. > > > That sounds really nice. On my laptop with current Sage, it > might be the other way around. With Sage 7.3 on my laptop, with > this particular matrix, I get > > > Yes, Sage/Linbox was about 2.5x times faster than the old charpoly > routine in Flint, I believe. The new one is quite recent and much > quicker. > > > sage: %time f = A.charpoly(algorithm='flint') > CPU times: user 1min 24s, sys: 24 ms, total: 1min 24s > Wall time: 1min 24s > > sage: %time f = A.charpoly(algorithm='linbox') > CPU times: user 13.3 s, sys: 4 ms, total: 13.3 s > Wall time: 13.3 s > > However, perhaps the average runtime with linbox is infinity. > (Also, this in an out of date Linbox.) > > I think that Linbox may be "cheating" in a way that Flint is > not. I'm pretty sure both implementations work mod p (or p^n?) > for a bunch of p and reconstruct. From my reading of the Flint > source code (actually, I didn't check the version in Sage) and > comments from Clement Pernet, I think that Flint uses an > explicit Hadamard bound to determine how many primes to use, > while Linbox just waits for the CRT'd polynomial to stabilize > for a few primes. > > > Ouch! > > Yes, in the new code we use an explicit proven bound. I can't quite > recall all the details now, but I recall it is multimodular. > > I would give it a good amount of testing before trusting it. We've > done quite a lot of serious testing of it and the test code is > nontrivial, but some real world tests are much more likely to shake > out any bugs, including the possibility I screwed up the > implementation of the bound. > > > Ah, yes, I'm wrong again, as the multimodular in Flint is pretty new. I > didn't look at what Sage has until now (flint 2.5.2, which looks likes > it uses a fairly simple O(n^4) algorithm). I had previously looked at > the source code of the version of flint that I've actually been using > myself, which is from June. As I now recall (after reading an email I > sent in June) I'm using a "non-released" version precisely for the > nmod_mat_charpoly() function, which doesn't exist in the most recent > release (which I guess might be 2.5.2, but flintlib.org > <http://flintlib.org> seems to be having problems at the moment). [OT:] flintlib.org (and mpir.org) is hosted at UW, where apparently some hardware damage (William said a UPS, affecting some switch) makes the connections at least that slow I cannot access anything there (e.g. also files.sagemath.org) since last Saturday. (See some later posts on the neighbour thread on trac not responding, although the latter is hosted on GCE.) -leif > I've actually done some fairly extensive real world semi-testing of > nmod_mat_charpoly() in the last few months (for almost the same reasons > that have lead me to investigate Sage/Linbox) but not > fmpz_mat_charpoly(). "semi" means that I haven't actually checked that > the answers are correct. I'm actually computing characteristic > polynomials of integer matrices, but writing down the integer matrices > is too expensive, so I'm computing the polynomials more efficiently mod > p and then CRTing. Also, I'm doing exactly what I think Linbox does, in > that I am just waiting for the polynomials to stabil
[sage-devel] Re: [sagemath-admins] trac not responding
William Stein wrote: > On Mon, Sep 26, 2016 at 3:10 PM, William Stein <wst...@gmail.com> wrote: >>> On Mon, Sep 26, 2016 at 6:22 AM, Volker Braun <vbraun.n...@gmail.com> wrote: >>>> Yes, both the file server files.sagemath.org and buildbot >>>> build.sagemath.org >>>> are down... >> >> I've done what I can and right now >> >>- files.sagemath.org >>- rsync.sagemath.org >> >> seem to respond to pings. And >> >>- build.sagemath.org doesn't. >> >> I have a brand new machine at UW running Ubuntu 16.04, with many >> cores and tons of RAM. Please >> >> SOMEBODY VOLUNTEER TO move files.sagemath.org, rsync.sagemath, and >> build.sagemath.org to run as **Docker containers** on this new >> machine. >> >> ** I will definitely power off everything except this one new machine >> one week from now. ** > > no volunteers to migrate files/build/rsync.sagemath.org... We should > just switch to GitHub. Repost with a subject more on topic? -leif -- 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: openblas segfault?
Jean-Pierre Flori wrote: > > > On Monday, September 26, 2016 at 11:47:00 AM UTC+2, Jonathan Bober wrote: > > On Mon, Sep 26, 2016 at 9:44 AM, Dima Pasechnik <dim...@gmail.com > > wrote: > > > > On Monday, September 26, 2016 at 2:22:51 AM UTC, Jonathan Bober > wrote: > > I recompiled with gcc 6.1.0, and get the same segfault. I > did a ./sage -i gdb to get a better crash report, which is > attached. I don't know if it is useful. Also, it mentions > some gcc 5.1.0 paths, which seems odd. I don't know if that > indicates that something is broken on my end. If in doubt, try building with '-mno-xop' in CFLAGS. AFAICT, *every* GCC version supporting Bulldozer+ is broken w.r.t. mixing AVX and XOP instructions (at higher optimization levels). (I haven't tried 6.x yet though IIRC; GMP-ECM 6.4 built with '-march=native -O3' was an example exposing this in the past, 7.x no longer does.) -leif > I am mostly guessing, but mentioning gcc 5.1.0 in the log does > sound to me as if your toolchain might be broken after update to > gcc 6.1 (perhaps it's debugging versions of libs...) > > > No, I think I was confused and used the wrong installation of sage > to produce that crash report. Maybe I typed sage instead of ./sage. > The correct crash report is attached now. > > The backtrace does not say much to me... > Maybe you could try to update openblas? our version is already outdated. > And hopefully this might have been fixed in a newer version (though I > did not find anything looking very related after a few google searches). > Just download the latest openblas tarball into upstream, edit > build/pkgs/openblas/package-version.txt to reflect the version change > and run sage --package fix-checksum openblas to update the checksum. -- 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: [sagemath-admins] trac not responding
Dima Pasechnik wrote: > > > On Monday, September 26, 2016 at 9:04:08 AM UTC, Volker Braun wrote: > > Somebody killed unauthorized git:// over the weekend... incorrect > firewall rule? > > > It was William, I suppose. > Actually, disabling anonymous git:// would perhaps help to reduce server > load, without > real functionality problems for development... Modulo having [the] keys on the machine you're currently trying to fetch from. Also, then anybody using git.sagemath.org will need a trac account. Not sure if the GitHub version is always up-to-date, including betas. -leif > On Monday, September 26, 2016 at 10:52:13 AM UTC+2, Harald Schilly > wrote: > > On Mon, Sep 26, 2016 at 10:16 AM, Dima Pasechnik > <dim...@gmail.com> wrote: > > this really has to be documented properly. > > just added to your ticket a comment, repeating it here: > it's not only the git-trac page, but also the "the hard way" page: > > http://doc.sagemath.org/html/en/developer/manual_git.html#the-trac-server > > <http://doc.sagemath.org/html/en/developer/manual_git.html#the-trac-server> > > where git:// is mentioned. > it's probably best to condense all this down to a single minimal > case > that covers the full development setup with ssh keys. > > -- h -- 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: [sagemath-admins] trac not responding
Dima Pasechnik wrote:
> On Mon, Sep 26, 2016 at 7:50 AM, Harald Schilly
> <harald.schi...@gmail.com> wrote:
>> On Mon, Sep 26, 2016 at 3:51 AM, Jonathan Bober <jwbo...@gmail.com> wrote:
>>> tracgit://trac.sagemath.org/sage.git (fetch)
>>> tracg...@trac.sagemath.org:sage.git (push)
>>
>> As a random idea, since several others were also asking me about this:
>> Did you try setting both trac remotes to
>> g...@trac.sagemath.org:sage.git
>
>
> Oh right, this is exactly the problem. The port for git protocol is blocked
> (as most other ports on GCE hosts) so one has to use ssh
> (i.e. git@... syntax rather than git://... syntax)
But that's new. E.g. 'git fetch' with git://{git,trac}...' worked for
me not that long ago. (I'm having other issues atm though.)
Orthogonal to that, I can no longer access files.sagemath.org etc.;
looks as if a bunch of IPs would get blocked since about Saturday (or
perhaps Friday), ping (ICMP) in contrast worked IIRC, doesn't either atm.
(And I did get timeouts for http[s]://trac.sagemath.org yesterday as
well, which is yet another issue but others apparently had as well. To
that time, there ICMP definitely worked.)
-leif
--
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: How about automatic install of all possible optional packages by a patchbot?
Jeroen Demeyer wrote: > I think it is far more important to do that on the release buildbot. The > patchbot is still an optional thing, which reviewers are free to ignore. Yes, but patch- and buildbots essentially do the same, with different configurations though. To me it seems this is not well-organized at the moment; as klee mentioned, it's not obvious which bot tests with which optional packages, and AFAIK the buildbots aren't integrated into trac at all -- they IMHO should (i.e., their results should at least be accessible from trac tickets in the same way the patchbots' are). -leif -- 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: How about automatic install of all possible optional packages by a patchbot?
Simon King wrote: > Hi! > > On 2016-09-12, Kwankyu Lee <ekwan...@gmail.com> wrote: >> This happened to me. My patch for a ticket passed the doctesting by a >> patchbot A but afterward failed by another patchbot B. The reason was that >> the patchbot B has an optional package installed, and hence ran the >> optional doctests for the installed package, and my patch failed some of >> the optional doctests. >> >> If it were not for the patchbot B, my patch might have been merged into >> Sage, and make those optional doctests potential failures. I was fortunate. > > It could have been the other way around as well: Your patch works *with* > some optional package that you happen to have and forgot for some > reason, but it doesn't work without. Yes, that's exactly what I /tried to/ say as well... -leif > Hence, it can not be the solution that *all* patchbot install *all* > optional packages. In an ideal world, all possible combinations of > optional packages would be tested, but I doubt that that would be > feasible. > > 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: How about automatic install of all possible optional packages by a patchbot?
Kwankyu Lee wrote: > This happened to me. My patch for a ticket passed the doctesting by a > patchbot A but afterward failed by another patchbot B. The reason was > that the patchbot B has an optional package installed, and hence ran the > optional doctests for the installed package, and my patch failed some of > the optional doctests. > > If it were not for the patchbot B, my patch might have been merged into > Sage, and make those optional doctests potential failures. I was fortunate. > > Was I fortunate or do we have any provision that as many as optional > doctests are run by patchbots? Perhaps the former is the case. > > My suggestion is that every owner of a patchbot should install as many > as optional packages into the system. Better than that, a patchbot > should make it sure that it automatically installs every working > optional packages into its base Sage before starting its work. Would > this be possible? Note that we'd have to do both, testing with *and* without (each) optional package. While for example the optional LiE package is completely broken even in the "stable" 7.3 release due to an unrelated patch where apparently nobody checked, there are tests that behave pretty different when an optional package *is* installed, meaning that /default/ Sage implementations are bypassed and hence not tested (in that context at least), which isn't always as obvious. For a while at least, William tried to install as many optional packages on SMC as possible, and regularly tested each beta IIRC. Not sure if that's still the case. -leif -- 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: Compilation error with linbox-1.4.2 during compilation of sage 7.4.beta4
Volker Braun wrote: > The error is in an optional part that isn't compiled by default; I guess > its the maple interface? The config contains > > checking for MAPLE >= 9.0... ./configure: line 18187: > /bin/maple.system.type: No such file or directory > found > > We should probably configure linbox with --with-maple=no ... or fix the build error. I'll post to #17635... -leif -- 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: Compilation error with linbox-1.4.2 during compilation of sage 7.4.beta4
David Coudert wrote: > Hello, > > I have the following error with linbox during the compilation of sage > 7.4.beta4. >> ./lb-domain-type.h:31:33: fatal error: linbox/field/givaro.h: No such > file or directory > > I was successfully able to compile 7.3, 7.4.beta1 and 7.4.beta2 on the > same computer. > I tried a `make distclean` but the problem remains. > Any help is more than welcome ! Presumably works if you temporarily hide your MAPLE. (I'll put a note onto the upgrade ticket [1]; you could *attach* ;-) your log there as well.) -leif [1] https://trac.sagemath.org/ticket/17635 > > You can find below the log of the linbox compilation.. > > David. > > > > Found local metadata for linbox-1.4.2 > Using cached file /home/dcoudert/sage-dev/sage/upstream/linbox-1.4.2.tar.gz > linbox-1.4.2 > > Setting up build directory for linbox-1.4.2 > Finished extraction > > Host system: > Linux musclotte 4.1..5-100.fc21.x86_64 #1 SMP Tue Aug 11 00:24:23 UTC > 2015 x86_64 x86_64 x86_64 GNU/Linux > > C compiler: gcc > C compiler version: > Using built-in specs. > COLLECT_GCC=/usr/bin/gcc > COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.9.2/lto-wrapper > Target: x86_64-redhat-linux > Configured with: ../configure --prefix=/usr --mandir=/usr/share/man > --infodir=/usr/share/info > --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap > --enable-shared --enable-threads=posix --enable-checking=release > --enable-multilib --with-system-zlib --enable-__cxa_atexit > --disable-libunwind-exceptions --enable-gnu-unique-object > --enable-linker-build-id --with-linker-hash-style=gnu > --enable-languages=c,c++,objc,obj-c++,fortran,ada,go,lto --enable-plugin > --enable-initfini-array --disable-libgcj > --with-isl=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/isl-install > --with-cloog=/builddir/build/BUILD/gcc-4.9.2-20150212/obj-x86_64-redhat-linux/cloog-install > --enable-gnu-indirect-function --with-tune=generic --with-arch_32=i686 > --build=x86_64-redhat-linux > Thread model: posix > gcc version 4.9.2 20150212 (Red Hat 4.9.2-6) (GCC) > > checking for a BSD-compatible install... /usr/bin/install -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... /usr/bin/mkdir -p > checking for gawk... gawk > checking whether make sets $(MAKE)... yes > checking whether make supports nested variables... yes > checking for rm... /usr/bin/rm > checking whether to enable maintainer-specific portions of Makefiles... no > --- > checking whether to enable debugging options in the library... no > checking whether to enable profiling everything in the library... no > checking whether to enable warnings when compiling the library... no > --- > checking whether the C++ compiler works... yes > checking for C++ compiler default output file name... a.out > checking for suffix of executables... > checking whether we are cross compiling... no > checking for suffix of object files... o > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking for family name of compiler... gcc (GCC) 4.9.2 20150212 (Red > Hat 4.9.2-6) > checking whether g++ supports C++11 features by default... no > checking whether g++ supports C++11 features with -std=gnu++11... yes > checking how to run the C++ preprocessor... g++ -E > checking for grep that handles long lines and -e... /usr/bin/grep > checking for egrep... /usr/bin/grep -E > checking for ANSI C header files... yes > checking build system type... x86_64-unknown-linux-gnu > checking host system type... x86_64-unknown-linux-gnu > checking how to print strings... printf > checking for gcc... gcc > checking whether we are using the GNU C compiler... yes > checking whether gcc accepts -g... yes > checking for gcc option to accept ISO C89... none needed > checking whether gcc understands -c and -o together... yes > checking for a sed that does not truncate output... /usr/bin/sed > checking for fgrep... /usr/bin/grep -F > checking for ld used by gcc... ld > checking if the linker (ld) is GNU ld... yes > checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B > checking the name lister (/usr/bin/nm -B) interface... BSD nm > checking whether ln -s works yes > checking the maximum length of command line arguments... 1572864 > checking whether the shell understan
[sage-devel] Re: sage -br rebuilds things that were not changed
Paul Masson wrote: >> But a Sage-installed ccache should also "just work". > > Jeroen, could you elaborate on this? How does one use ccache most simply > with Sage? ./sage -i ccache That's all, unless you want to configure it differently. (After installation, see local/etc/ccache.conf.) -leif -- 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: sage -br rebuilds things that were not changed
Johan S. H. Rosenkilde wrote: > I seriously think a lot of beginners are struggling with compilation > time when working with Sage, inadvertently jumping a lot between > releases. Apparently, my workflow is not popular, but could we still > add something to the Development manual to help people? Well, jumping between different tickets / switching branches too often is certainly not something for a beginner. They'll presumably though learn quickly what kind of changes are "dangerous" w.r.t. rebuild time... Interestingly, so far nobody mentioned what the patch/buildbots do. When Sage was "relocatable", it was much easier to maintain different Sage installations. For temporary / scratch installations just to test tickets and throw them away afterwards, without much rebuild effort, it's still possible to create tarballs of built vanilla releases (kind of your own bdists), but because of the hardcoded absolute paths, this (and other things) have become a headache. -leif -- 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: sage -br rebuilds things that were not changed
Johan S. H. Rosenkilde wrote: > > leif writes: >> Well, probably it's just me, but I always (also) review tickets on trac >> (i.e., via what git-o-lite gives); the whole branch, but also each >> individual commit. You just need a browser to do so. > > I use git-o-lite a lot too, but often switch back to my Emacs and git > log using Magit :-P > >> Having a Sage installation at hand, it's even more tedious to do so on >> the command line when the relevant commits are "out-of-order" / mixed >> with unrelated commits. > > I mostly take the commit id from trac. But yes, without git-o-lite it > can get difficult to find the commits you need. I'm sure there are "git > log" flags for it, but I'm not an expert. It just hasn't come up enough > for me to really try and find a solution. > >>> "whatever head" is always develop, so I'm always pulling into the newest >>> beta release. >> >> Well, that doesn't make much of a difference, unless the ticket is >> incidentally based on the same (which is rarely the case, since most >> tickets live longer than a single beta-release cycle). > > I just wanted to stress that it's not a random choice. Indeed, barring > the "history becomes difficult to read", I don't see any argument > against all devs always working on latest beta, in which case it would > always make sense to update all tickets to that. We could even > automatically upgrade all tickets to latest beta on releases. Though > based on this discussion, I'd guess many of you would get angry due to > "history becomes more difficult to read". > >> For trivial changes, you can also put inline patches onto trac the owner >> of the ticket / branch can easily apply, and for more complex changes, >> you can always create a new branch on trac *without* changing the >> ticket's branch to that. Then the owner of the original branch can >> cherry-pick from your branch, if it's based on something else. > > This is a good idea that would allow me to continue using my current > workflow, without annoying other devs. > >> (With different Sage installations, you could do similar locally of >> course, i.e., "backport" the changes you made on top of your develop to >> master+fetched original branch, say, and push the resulting branch. I >> personally often first make changes in some random Sage installation, >> then moving them around, later pushing to trac from a "suited" one.) > > Aha, sort of like what Daniel wrote, except that fetching the branch > into "random Sage installation" means you don't get the low compilation > time benefits. Well, making changes doesn't necessarily imply fetching branches, nor [immediate] (re)compilation. Also, occasionally I just "manually" grab changes, i.e., patches or even only hunks, and apply them temporarily, later creating a "clean" branch, probably elsewhere, in order to push or just properly do final testing. What would have to get rebuilt of course also varies broadly, depending on what you change (or what a fetched or pulled branch brings with it). >>> I don't see why all developers shouldn't always be on the latest beta. >> >> Time? Resources? >> >> Note that many, I guess, have Sage installations here and there, and >> most likely don't or cannot keep each of them always what you'd call >> "up-to-date", but rather at one of the previous "stable" releases, or >> something inbetween. > > > What time? What resources? My dev model needs only a single Sage > installation and no extra software to achieve overall very low > compilation time. The other suggestions I've heard need multiple Sages, > extra software and/or does not minimise compilation time. Checking out a > ticket takes a whopping extra 3 seconds (if it takes longer it's because > of merge errors which I would have to fix anyway). One Sage installation means one machine (you "always" have access to / can currently use), with a specific processor, operating system/distro version, and a single tool chain. > Note I have one extra Sage tree to ensure that I have a working Sage at > any time. It's on latest stable and I never develop on it. > >> [Random insertion: Wasn't it you who [had to] upgrade[d] to Ubuntu >> 16.04 just to get the next version of Emacs? ;-) ] > > Hmm, no. I've used Arch linux for 3 years now because Ubuntu has too old > software. But I've twice had major compilation issues due to Arch > upgrading to a new release of some dependency (e.g. ranlib or gcc) long > before any other distro. Then you know what "upgrades" /can/ br
[sage-devel] Re: sage -br rebuilds things that were not changed
Johan S. H. Rosenkilde wrote: > leif writes: >>> But if you want to actually make changes then this creates a new merge >>> commit which furthermore is against the conventional order (where the >>> feature branch is the first parent). So it makes the commit history harder >>> to understand. >> >> I'd rather say "impossible", or more precisely, to later review exactly >> the commits that belong to the ticket in question. > > I'd say that's a Git tools question. Without flags, git log will show > the individual commits in chronological order, but you can ask to do > topsort or something. Personally, it seldom comes up for me, and when it > has, I've been able to get by using the commit numbers given by Trac or > searching through the log. Sure, I probably have not been involved in > the most complicated tickets Sage has ever seen, though. Well, probably it's just me, but I always (also) review tickets on trac (i.e., via what git-o-lite gives); the whole branch, but also each individual commit. You just need a browser to do so. Having a Sage installation at hand, it's even more tedious to do so on the command line when the relevant commits are "out-of-order" / mixed with unrelated commits. >>> I've heard arguments against "gratuitously" merging the ticket to >>> newest release when e.g. just fixing a typo. But that seems to me to be >>> a rather theoretical complaint, since the ticket will be merged later on >>> anyway. >> >> Absolutely not, unless you're /creating/ a new / "the" branch on the >> ticket. If you're taking an already existing branch from a ticket and >> make changes to be pushed back later, you should *always* fetch, not >> pull into whatever head you currently have locally. >> >> But maybe I just misunderstood you. > > "whatever head" is always develop, so I'm always pulling into the newest > beta release. Well, that doesn't make much of a difference, unless the ticket is incidentally based on the same (which is rarely the case, since most tickets live longer than a single beta-release cycle). And as said, whether you pull or fetch is only relevant if you push back changes. I guess you review and test many more tickets than you actually push reviewer changes to. For trivial changes, you can also put inline patches onto trac the owner of the ticket / branch can easily apply, and for more complex changes, you can always create a new branch on trac *without* changing the ticket's branch to that. Then the owner of the original branch can cherry-pick from your branch, if it's based on something else. (With different Sage installations, you could do similar locally of course, i.e., "backport" the changes you made on top of your develop to master+fetched original branch, say, and push the resulting branch. I personally often first make changes in some random Sage installation, then moving them around, later pushing to trac from a "suited" one.) >> For new branches, I think it's best to base them on the last *stable* >> release (i.e., check out master before creating the new branch), unless >> you really need fixes from later betas, or it's clear (or likely) that >> you'd get merge conflicts with later betas if you base your branch on >> master. (But you'd notice that sooner or later when looking at the >> colour of the branch on the trac ticket -- unfortunately nobody ever >> gets notified when the colour changes after trac's develop has been >> updated to the next beta, something either trac or a patchbot could >> implement.) >> >> If you always base your branches on the latest *beta*, others will just >> get forced to pull and build the latter (with typically loads of >> completely unrelated changes), no matter whether they fetch or pull your >> branch. So in other words, you're (at least potentially) moving rebuild >> load to others. > > I don't see why all developers shouldn't always be on the latest beta. Time? Resources? Note that many, I guess, have Sage installations here and there, and most likely don't or cannot keep each of them always what you'd call "up-to-date", but rather at one of the previous "stable" releases, or something inbetween. > It's also the only version that would make sense to base *all* future > tickets on, though - as you say - many tickets might not care about the > diff between master and develop. So in the interest of minimising > compilation time for developers overall, I think we should base all > tickets on the latest beta. Otherwise, when you jump between > small-ticket-A and small-ticket-B, you might suddenly trigger a huge > recompile since B happened to need one o
[sage-devel] Re: sage -br rebuilds things that were not changed
Johan S. H. Rosenkilde wrote: > Volker Braun writes: > >> Thats ok for reviewing tickets, and implemented as "git trac try >> ". > > OK. I had a chat with Thierry Monteil and we agreed there were some > subtle differences I don't remember - but I'll take a look at "git trac > try". > >> But if you want to actually make changes then this creates a new merge >> commit which furthermore is against the conventional order (where the >> feature branch is the first parent). So it makes the commit history harder >> to understand. I'd rather say "impossible", or more precisely, to later review exactly the commits that belong to the ticket in question. > I've heard arguments against "gratuitously" merging the ticket to > newest release when e.g. just fixing a typo. But that seems to me to be > a rather theoretical complaint, since the ticket will be merged later on > anyway. Absolutely not, unless you're /creating/ a new / "the" branch on the ticket. If you're taking an already existing branch from a ticket and make changes to be pushed back later, you should *always* fetch, not pull into whatever head you currently have locally. But maybe I just misunderstood you. For new branches, I think it's best to base them on the last *stable* release (i.e., check out master before creating the new branch), unless you really need fixes from later betas, or it's clear (or likely) that you'd get merge conflicts with later betas if you base your branch on master. (But you'd notice that sooner or later when looking at the colour of the branch on the trac ticket -- unfortunately nobody ever gets notified when the colour changes after trac's develop has been updated to the next beta, something either trac or a patchbot could implement.) If you always base your branches on the latest *beta*, others will just get forced to pull and build the latter (with typically loads of completely unrelated changes), no matter whether they fetch or pull your branch. So in other words, you're (at least potentially) moving rebuild load to others. -leif > I agree with the problem with the merge order which can be annoying. I > don't know if there is an obscure Git command for changing that. But if > the alternative is to spend tons of time recompiling every time I'm > checking out a ticket, I'm not sure I'll do the trade ;-) > > Best, > Johan -- 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: sage -br rebuilds things that were not changed
Volker Braun wrote: > There is cycache, but its currently disabled in Sage as we ran into some > bugs. Well, since quite a while though, isn't it? Did anyone recently check whether the issue still exists, or could you give a pointer? -leif > On Saturday, September 10, 2016 at 12:20:54 AM UTC+2, William wrote: > > On Fri, Sep 9, 2016 at 3:08 PM, Volker Braun <vbrau...@gmail.com > > wrote: > > Whenever you switch to a branch with a different working set you > change > > timestamps of modified files. Git does not track timestamps. Updated > > timestamps cause recompilation. > > So... instead of using timestamps, maybe Cython should use file hashes > to determine whether or not to recompile code?My distant memory of > when we first wrote the cython dep code for Sage long long ago was > that I used timestamps, then Craig Citro or Robert Bradshaw wrote > something better using hashes, but I'm not sure. I'm cc'ing them in > case they have any thoughts. > > > -- > William (http://wstein.org) -- 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: 404 in Sage Installation Guide
Harald Schilly wrote:
> On Friday, September 9, 2016 at 12:16:36 AM UTC+2, leif wrote:
>
> The link to README..txt ("Be sure to read the file ..." [!])
>
> http://www.sagemath.org/mirror/win/README.txt
> <http://www.sagemath.org/mirror/win/README.txt>
>
> referenced in
>
>
> http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows
>
> <http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows>
>
>
> gives a 404, for whatever reason.
>
>
> What is a good solution here? I would suggest such a redirect from
> mirror/win/README.txt to the wiki page?
Well, or to (the analogue of)
http://files.sagemath.org/win/README.txt
or
http://files.sagemath.org/win/README-virtualbox.txt
which is the same file (or an identical copy of the former), as
mentioned in my previous post.
In Sage 7.4, we can just change the link in the Installation Guide to
directly lead to the wiki page, which IMHO at least currently makes more
sense.
-leif
--
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: PYTHONUSERBASE?
Volker Braun wrote: > I think this idea of installing stuff globally (either system-wide or in > ~/.local) is outdated. Really its always better to make a venv if you > need some sort of specialist package. Its just an all-around better > workflow. And Sage-the-distribution really is like a big venv. > > I'd rather spend 5 seconds installing my favorite package into Sage than > an hour debugging what in ~/.local makes Sage crash. > > And there are a lot of potential conflicts; for startes if you compile > Sage with SAGE_DEBUG=yes then the Python ABI will be incompatible with > any extension modules in ~/.local > > If anything I would document that you can opt-in to the account-wide > packages by running "PYTHONUSERBASE=~/.local sage" +1 As an alternative to the latter, we could also check for some user-provided "magic" file in $PYTHONUSERBASE/... such as OK_TO_BE_USED_BY_SAGE, say, and accept a user's setting iff that file is present. Same for IPYTHONDIR etc. by the way. That way, it is 100% clear that the user actively acts at his/her own risk (provided Sage itself *never* /creates/ that file of course). At startup, we could in addition briefly remind the user in case such "external" folders (settings and packages) are currently used as well. "Cross-forwarding" from debian-science-sagemath [1] since (I think) this fits nicely: On Tue, Aug 23, 2016 at 11:28 PM, Jerome BENOIT wrote: > Is Sage a distribution ? Hi, sorry to drop in on this as a lurker unannounced, but in my opinion, SageMath is definitely a distribution. It's not something that's used very widely, but for a narrow target of higher mathematics (of a certain kind) it is very useful. It setups a rather closed environment, where all components are tested to work well together and have a clear version number (that can be used in scientific publications). Drawback is, that all that is more like organically grown and detached from the "outside world". That's definitely a bad aspect, but hey, it still solves a lot of the tiny issues that arise, when you try to do computational mathematics in those areas. -- harald (Feel free to also read the replies which -- regarding the subject of the list -- naturally state a different point of view.) -leif [1] http://lists.alioth.debian.org/pipermail/debian-science-sagemath/Week-of-Mon-20160822/94.html > On Friday, September 9, 2016 at 5:38:58 PM UTC+2, William wrote: > > Hi, > > I personally disagree with trying to make Sage's python and the > general environment be as isolated as possibly from each other. We > should try to interoperate with the greater Python world as much as > possible, not change things to discourage that. If you want total > isolation, use Docker, don't mess with environment variables like > this... > > I realize that this might just get closed due to philosophical > differences. How about just document PYTHONUSERBASE in our FAQ or > something (like it is in python) and trust users to have a clue? > > I've made https://trac.sagemath.org/ticket/21456 > <https://trac.sagemath.org/ticket/21456> about this. However, > the authors of the new code in Sage that sets PYTHONUSERBASE if it > isn't set, might have a very different opinion, and for a good reason. > Thoughts? > > -- William > > > -- > William (http://wstein.org) -- 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: 404 in Sage Installation Guide
Paul Masson wrote:
> There does not appear to be a "README.txt" file for Windows installation
> in either the main SageMath repository or the website repository. If
> such a file ever existed, it's long gone. I even checked at archive.org
> for a backup copy, but since the robots.txt file has been blocking the
> /mirror/ directory since 2009 they don't have one either.
Well, there is http://files.sagemath.org/win/README.txt , which
(meanwhile I guess) just contains
"For more informaion on how to setup and run the Sage Virtual Machine,
please read
http://wiki.sagemath.org/SageAppliance;
besides http://files.sagemath.org/win/README-virtualbox.txt , which is
the same file (or an identical copy of the former).
> The simplest solution is to delete the link from the documentation,
> unless someone wants to create the file.
As is, we could short-cut to the wiki page, which isn't directly linked
to from the Installation Guide, at least not in that section.
-leif
> On Thursday, September 8, 2016 at 3:16:36 PM UTC-7, leif wrote:
>
> The link to README.txt ("Be sure to read the file ..." [!])
>
> http://www.sagemath.org/mirror/win/README.txt
> <http://www.sagemath.org/mirror/win/README.txt>
>
> referenced in
>
>
> http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows
>
> <http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows>
>
>
> gives a 404, for whatever reason.
>
>
> Besides that, the Sage wiki page [1] linked to from
> http://www.sagemath.org/download-windows.html
> <http://www.sagemath.org/download-windows.html> states:
>
> "This page is copied over from the instructions pages for Sage 5.x
> and 6.x.
>
> For SageMath 7.0 and higher, most steps should work but the final steps
> should be adapted to take into account the new default which is to use
> the Jupyter notebook.
>
> Somemeone please adapt the final steps."
>
>
> -leif
>
>
> [1] https://wiki.sagemath.org/SageAppliance/SageMath-7
> <https://wiki.sagemath.org/SageAppliance/SageMath-7>
--
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: PYTHONUSERBASE?
William Stein wrote: > Hi, > > I personally disagree with trying to make Sage's python and the > general environment be as isolated as possibly from each other. We > should try to interoperate with the greater Python world as much as > possible, not change things to discourage that. If you want total > isolation, use Docker, don't mess with environment variables like > this... > > I realize that this might just get closed due to philosophical > differences. How about just document PYTHONUSERBASE in our FAQ or > something (like it is in python) and trust users to have a clue? > > I've made https://trac.sagemath.org/ticket/21456 about this. However, > the authors of the new code in Sage that sets PYTHONUSERBASE if it > isn't set, might have a very different opinion, and for a good reason. > Thoughts? See also https://trac.sagemath.org/ticket/21430 for a very recent, related discussion. TL;DR: I'm against nannying people (i.e., forcing [Sage-]specific settings), but at the same time we should IMHO prevent users from any breakages caused by *unintentional* settings (probably even made by others, not knowing Sage). And as always, there are three important things: Documentation, documentation, and documentation. -leif -- 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: sage -br rebuilds things that were not changed
Jeroen Demeyer wrote: > On 2016-09-09 12:56, Marco Cognetta wrote: >> It has happened to me where I build sage, turn off my computer, turn it >> back on, and build it again. There were no changes made in the meantime >> and it still does the cythonizing step. > > Are you really sure that you remember this correctly? Turning off and on > your computer should have no effect (unless there is a problem with your > OS or hardware). And "turn off" hopefully means properly shutting down the system (maybe by pushing the soft-off button / closing the laptop, depending on your OS and settings). >> Also, I have had branches that >> are identical (except for a new file that does not have any dependencies >> to be rebuilt) which will also go through this cythonizing step (first >> when I switch to the branch, and then again when I switch back to master >> and try to build it again). > > Are these branches somewhere public? Then I could have a look. But right > now, I have too little information to know whether there is a real bug > or just something that you are doing wrongly. And are you sure these "identical" branches are based on the same commit? It for example makes a difference whether you fetch a branch, pull it into some betaX, or pull it into some betaY / other branch than (the same version of) develop, say. You may compare what 'git log' shows for both, i.e., the last commit that's not from you, such as "Updated SageMath version to 7.4.beta3". As mentioned, you can compare branches directly, or just specific files of your both branches in question. If you don't want to see the actual changes (but rather an overview of which files differ and by how much), you can use git diff --stat old_branch new_branch -- src/sage/... For the two branches which allegedly only differ by a newly created file, the above should give just a single line for exactly that file (plus a one-line summary on the last line). -leif -- 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: sage -br rebuilds things that were not changed
Jeroen Demeyer wrote: > On 2016-09-09 08:43, Marco Cognetta wrote: >> However, if I change to a >> new branch that has no changes which would necessitate recythonizing >> code, it will go through the cythonizing step again. > > What makes you think that there are no changes which would necessitate > recythonizing? > > Cython does dependency checking, so if it rebuilds something, there must > be a reason. In fact, the reason is explicitly stated when cythonizing > (with messages like building foo because it depends on bar). And in case you don't trust cython, you can compare files (or whole subtrees) yourself: git diff old_branch new_branch -- src/sage/... -leif -- 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: What is "do_system"?
Jeroen Demeyer wrote: > On 2016-09-09 08:23, Simon King wrote: >> Is there a cleaner/less costly way to remove a file? > > Obviously yes: > > #include > remove(const char *pathname); For files, unlink(). -leif -- 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: What is "do_system"?
leif wrote:
> Simon King wrote:
>> Hi Nils, hi Leif,
>>
>> On 2016-09-08, leif <not.rea...@online.de> wrote:
>>>> Googling suggests that this might be a part of glibc:
>>>>
>>>> https://github.com/lattera/glibc/blob/master/sysdeps/posix/system.c#L52
>>
>> Aha! Since I expected it to be related with (c)python, I duckduckwent
>> for "python do_system", but to no avail. Thanks for the hint.
>>
>>>> If that's indeed the do_system you're hitting then it would seem you're
>>>> profiling quite a bit of OS interaction.
>>>
>>> Presumably smth like system("pip list") from is_package_installed()... 8-)
>>
>> Is do_system perhaps related with writing/reading files? The code does that
>> a lot.
>
> No, it's presumably really (in) the C library function system() [1], in
> Python os.system(). (I doubt you abuse it to write to or read from files.)
>
> Or maybe not. But are you (intentionally) using R? libR.so does define
> a function of the same name as well, which on the other hand in turn is
> apparently just a wrapper for the former.
R's do_system() actually uses [R_]popen(), not system().
-leif
>
> Or it is a function of some optional package you have installed.
>
>
> -leif
>
> [1] man 3 system
--
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: What is "do_system"?
Simon King wrote:
> Hi Nils, hi Leif,
>
> On 2016-09-08, leif <not.rea...@online.de> wrote:
>>> Googling suggests that this might be a part of glibc:
>>>
>>> https://github.com/lattera/glibc/blob/master/sysdeps/posix/system.c#L52
>
> Aha! Since I expected it to be related with (c)python, I duckduckwent
> for "python do_system", but to no avail. Thanks for the hint.
>
>>> If that's indeed the do_system you're hitting then it would seem you're
>>> profiling quite a bit of OS interaction.
>>
>> Presumably smth like system("pip list") from is_package_installed()... 8-)
>
> Is do_system perhaps related with writing/reading files? The code does that
> a lot.
No, it's presumably really (in) the C library function system() [1], in
Python os.system(). (I doubt you abuse it to write to or read from files.)
Or maybe not. But are you (intentionally) using R? libR.so does define
a function of the same name as well, which on the other hand in turn is
apparently just a wrapper for the former.
Or it is a function of some optional package you have installed.
-leif
[1] man 3 system
--
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: What is "do_system"?
Nils Bruin wrote:
> On Thursday, September 8, 2016 at 12:52:47 PM UTC-7, Simon King wrote:
>
> Hi!
>
> Trying to profile some code with %crun, I get lots of hits in the
> function do_system. However, a function of that name does not appear in
> the code. So, what does do_system do, where is it from, and what is
> calling it?
>
>
> Googling suggests that this might be a part of glibc:
>
> https://github.com/lattera/glibc/blob/master/sysdeps/posix/system.c#L52
>
> If that's indeed the do_system you're hitting then it would seem you're
> profiling quite a bit of OS interaction.
Presumably smth like system("pip list") from is_package_installed()... 8-)
I'd take a look with the system monitor (or whatever it's called on your
system), with tree view of processes.
-leif
--
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] 404 in Sage Installation Guide
The link to README.txt ("Be sure to read the file ..." [!])
http://www.sagemath.org/mirror/win/README.txt
referenced in
http://doc.sagemath.org/html/en/installation/binary.html#microsoft-windows
gives a 404, for whatever reason.
Besides that, the Sage wiki page [1] linked to from
http://www.sagemath.org/download-windows.html states:
"This page is copied over from the instructions pages for Sage 5.x and 6.x.
For SageMath 7.0 and higher, most steps should work but the final steps
should be adapted to take into account the new default which is to use
the Jupyter notebook.
Somemeone please adapt the final steps."
-leif
[1] https://wiki.sagemath.org/SageAppliance/SageMath-7
--
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: segmentation fault in sage 7.3
Stan wrote: > Dear all, > > I am on debian jessy 64bit and after installing sage 7.3 Does that mean you took a pre-built binary, or did you build from source? -leif > I keep getting > segfault for the same worksheets that run smoothly in sage 6.8. I have > now managed to isolate a small example, which I uploaded to > cloud.sagemath, where it does not give a segfault message, but just runs > forever. To use locally, download this file: > > https://cloud.sagemath..com/projects/34b4b62a-2621-47c8-9bda-cde3a855f995/files/leaf_chamber_eqs_PM.sobj > > <https://cloud.sagemath.com/projects/34b4b62a-2621-47c8-9bda-cde3a855f995/files/leaf_chamber_eqs_PM.sobj> > > then run the following code in a sagenb notebook: > | > vdict =cdict.copy() > vdict[a_s]=1 > vdict[L_l]=0.07 > vdict[P_a]=101325 > vdict[P_wa]=20/1000*101325 > vdict[R_s]=400 > vdict[Re_c]=3000 > vdict[T_a]=273+30 > vdict[T_w]=vdict[T_a] > vdict[g_sw]=0.15/40 > vdict[v_w]=1. > vdict[nu_a]=eq_nua.rhs().subs(vdict) > printeq_Re.subs(vdict) > | > > Here are the error messages I get in the terminal: > > 2016-09-08T15:04:22+0200 [stdout#info] raise > NoFunctionNameInFrameError() > 2016-09-08T15:04:22+0200 [stdout#info] NoFunctionNameInFrameError: C > function name could not be determined in the current C stack frame > 2016-09-08T15:04:22+0200 [stdout#info] close failed in file object > destructor: > 2016-09-08T15:04:22+0200 [stdout#info] IOError: [Errno 9] Bad file > descriptor > 2016-09-08T15:04:22+0200 [stdout#info] > 2016-09-08T15:04:22+0200 [stdout#info] Saved trace to > .../.sage/crash_logs/crash_XdQCv0.log > 2016-09-08T15:04:22+0200 [stdout#info] > > 2016-09-08T15:04:22+0200 [stdout#info] Unhandled SIGABRT: An abort() > occurred. > 2016-09-08T15:04:22+0200 [stdout#info] This probably occurred because a > *compiled* module has a bug > 2016-09-08T15:04:22+0200 [stdout#info] in it and is not properly wrapped > with sig_on(), sig_off(). > 2016-09-08T15:04:22+0200 [stdout#info] Python will now terminate. > 2016-09-08T15:04:22+0200 [stdout#info] > > > I'm sure the example could be simplified much more, but I hope this > helps to track down the problem. The worksheet can also be found on > cloud.sagemath: > > https://cloud.sagemath.com/projects/34b4b62a-2621-47c8-9bda-cde3a855f995/files/sigsegv_7.3.sagews -- 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: ReST References in Sphinx and uniqueness
John H Palmieri wrote: > It also takes less time if you don't include plots: maybe 5 minutes for > me instead of 8. But sooner or later we'll have to split combinat I think, as you mentioned, since with N threads you're just waiting faster (or rather "in parallel") for the last part to finish, similar to building Sage from scratch, where I meanwhile always have to wait for just SciPy (although during the build, the number of threads actually used a couple of times already drops down to just one or two). Interestingly, AFAICT in (HTML) docbuilding I/O isn't an issue (perhaps unless your disk is very very slow, or the box is in addition swapping). -leif > On Monday, September 5, 2016 at 10:59:19 PM UTC-7, Johan S. R. Nielsen > wrote: > > > Regarding speed, there are two issues: > > > > 1. Building the documentation from scratch. I don't know if we > can expect > > this to go any faster. The PDF version of the documentation is > 3,474 pages > > long. No, wait, that's just the contribution from > references/combinat: the > > whole reference manual is 18,442 pages long. I can build this on > my machine > > in about 8 minutes, and this does not seem unreasonable. Am I > wrong about > > this? (It could be sped up a bit for parallel builds if the > largest pieces, > > e.g., reference/combinat, were broken into smaller pieces, but I > don't know > > how much speed increase we can hope for.) > > OK, this is good to know. It takes considerably longer on my > machine, so > there is something I'm really not doing right (possibly not having > parallel build enabled). I'll experiment with this. > > 8 minutes from a clean build is not impressive IMHO, but perhaps it's > then not the most important piece of the compilation process to > improve.. > > Best, > Johan -- 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: Upgrade to Singular 4.x
Grayson Jorgenson wrote: > Hi, > > I also think the new answer is likely still correct. The output in the > example is truncated to save space: > C.resolution_of_singularities(extend=True) returns a tuple with the > other elements giving maps between the patches and back to the original > curve. If those maps make sense and the curves defining the patches are > smooth the new output should be okay. > > Since the other resolution_of_singularities examples were not affected > maybe the change reflects some modification to the number field > functionality. The broken example is the only one that tests extending > the base field of the curve which needs things like the number field > embeddings and composite_field functions.. I looked at that (the full result) yesterday, here's now a diff of the full output (all three components): https://trac.sagemath.org/ticket/17254#comment:433 (AFAICS, just changed signs.) -leif > I was trying to test what happened, but ran into trouble building > #17254. I have a copy of sage at 7.4 beta1 and merged this ticket into a > test branch and ran make, but the build failed with errors complaining > about not being able to find the tarball for singular 4 at various > mirrors. Are there any extra steps needed to build this? I'm currently > trying again after make distclean; if that works I can investigate tomorrow. > > On Wednesday, September 7, 2016 at 5:16:04 PM UTC-4, Travis Scrimshaw wrote: > > Just posting with the code formatting to make it a bit more clear. > Old answer: > > | > sage:set_verbose(-1) > sage:K.=QuadraticField(3) > sage:A.<x,y>=AffineSpace(K,2) > sage:C =A.curve(x^4+2*x^2+a*y^3+1) > sage:C.resolution_of_singularities( > extend=True)[0]# long time (2 seconds) > (AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 24*x^2*ss1^3+24*ss1^3+(a0^3-8*a0), > AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 24*s1^2*ss0 +(a0^3-8*a0)*ss0^2+(6*a0^3)*s1, > AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 8*y^2*s0^4+(-4*a0^3)*y*s0^3-32*s0^2+(a0^3-8*a0)*y) > | > > The new answer: > > | > (AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 24*x^2*ss1^3+24*ss1^3+(a0^3-8*a0), > AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 24*s1^2*ss0 +(a0^3-8*a0)*ss0^2+(-6*a0^3)*s1, > ---^ > AffinePlaneCurveover NumberFieldina0 withdefining polynomial y^4 > -4*y^2+16definedby > 8*y^2*s0^4+(4*a0^3)*y*s0^3-32*s0^2+(a0^3-8*a0)*y) > ---^ > | -- 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: Add psutil as standard package
Jeroen Demeyer wrote: > On 2016-09-07 15:09, leif wrote: >>[x] Use it in other places as well >>(related to multiprocessing, such as >> doctesting, docbuilding, building the >> Sage library -- in the long run) > > It's not a multiprocessing package. It's more a replacement for typical > Unix command-line tools like "ps", "free", "killall", ... That's why I said "use it in places related to", not "replace multiprocessing by it". I.e., be smarter w.r.t. resource usage when doing multiprocessing. Also some messages could add relevant info obtained through psutil. -leif -- 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: Add psutil as standard package
Thierry wrote: > On Wed, Sep 07, 2016 at 02:28:31PM +0200, Jeroen Demeyer wrote: >> Hello, >> >> at https://trac.sagemath.org/ticket/21421 we propose to add the Python >> package "psutil" as standard package for Sage. The tarball is 308KB, >> installed it is about 624KB. The use case is replacing >> src/sage/misc/memory_info.py >> >> From https://pypi.python.org/pypi/psutil >> >> psutil is a cross-platform library for retrieving information on running >> processes and system utilization (CPU, memory, disks, network) in Python. >> >> >> [X] I agree, let's make psutil standard > > And contribute to the demiscification of Sage :P ROFL, I first read "descientification" (for whatever reason...) -leif -- 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: Upgrade to Singular 4.x
Jean-Pierre Flori wrote: > Hi all, > > It seems we are left with only one failing doctest, which just looks > like a different but potentially valid answer: > https://trac.sagemath.org/ticket/17254#comment:364 > > Does any one knows enough about resolution of singularities to validate > the new answer? The failing doctest is sage: set_verbose(-1) sage: K. = QuadraticField(3) sage: A.<x,y> = AffineSpace(K, 2) sage: C = A.curve(x^4 + 2*x^2 + a*y^3 + 1) sage: C.resolution_of_singularities(extend=True)[0] # long time (2 seconds) (Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 24*x^2*ss1^3 + 24*ss1^3 + (a0^3 - 8*a0), Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 24*s1^2*ss0 + (a0^3 - 8*a0)*ss0^2 + (6*a0^3)*s1, Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 8*y^2*s0^4 + (-4*a0^3)*y*s0^3 - 32*s0^2 + (a0^3 - 8*a0)*y) The new answer has changed signs in two cases (cf. diff in the comment JP links to above): (Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 24*x^2*ss1^3 + 24*ss1^3 + (a0^3 - 8*a0), Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 24*s1^2*ss0 + (a0^3 - 8*a0)*ss0^2 + (-6*a0^3)*s1, ---^ Affine Plane Curve over Number Field in a0 with defining polynomial y^4 - 4*y^2 + 16 defined by 8*y^2*s0^4 + (4*a0^3)*y*s0^3 - 32*s0^2 + (a0^3 - 8*a0)*y) ---^ -leif -- 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: Add psutil as standard package
leif wrote: > Jean-Pierre Flori wrote: >> [x] I agree, let's make psutil standard > > [x] I agree > > [x] Why is it that large? [x] Use it in other places as well (related to multiprocessing, such as doctesting, docbuilding, building the Sage library -- in the long run) -leif -- 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: Add psutil as standard package
Jean-Pierre Flori wrote: > [x] I agree, let's make psutil standard [x] I agree [x] Why is it that large? -leif -- 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: Suggestion for main configure script to give package names for Latex.
Samuel Lelievre wrote: > > > 2016-09-06 11:08:25 UTC+2, Dr. David Kirkby (Kirkby Microwave Ltd): > > > PS, I found this page > https://wiki.sagemath.org/devel/DebianSage > <https://wiki.sagemath.org/devel/DebianSage> > last updated in 2009. Unless someone is willing to update it, I > suggest it might be better removed. > > > Thanks for this suggestion. I updated the page. Positive review. ;-) -leif -- 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: Suggestion for main configure script to give package names for Latex.
Dima Pasechnik wrote: > Hi David, > > On Tuesday, September 6, 2016 at 9:08:25 AM UTC, Dr. David Kirkby > (Kirkby Microwave Ltd) wrote: > > I'm trying to migrate away from Solaris to Linux, given the takeover > by Oracle. I decided to install the latest Debian (8.5 == Jessie) , > and Sage. I have not succeeded yet, but some of the issues seem to > be ones where the installation could be made easier for popular > linux distributions. > > > with your Unix knowledge you'd feel Debian is a jail of sorts; I'd > recommend Arch. https://www.archlinux.org/ And as a proper desktop environment, MATE (continuation of GNOME 2; GNOME 3.x is broken and totally unusable for people like us... ;-) ): http://mate-desktop.org/ (FWIW, there's e.g. also Ubuntu MATE: https://ubuntu-mate.org/ ) -leif > First configure would not run, with some crpytic message about some > library not being sane. A Google found i needed to install g++. > > Next I got a warnings that Latex is not present. I know this is not > so important, but I thought I'd install a Debian package for latex. > Unfortunately a search on Latex brings up many tens (perhaps >100) > packages. It is far from clear what package(s) is necessary. > > > texlive-full with install most everything in one go. It's an overkill, > but unless you're really short on disk space it's OK. > > > > > It might be worth the configure script reporting how to install > Latex and perhaps other missing bits. Something like > > === > You can get the Latex source from http://www.where-latex-is.org > > > On Debian execute: # apt-get install $whatever_package > On Suse # $whatever_command_installs_latex > On Mint # $whatever_command_installs_latex > > > do this for the 5-10 most popular distributions, based on > distrowatch https://distrowatch.com/ or similar. > > I worked out how to use Mercurial when Sage used that, now I note it > has gone to git, I really don't have enough time to learn something > else. > > > the whole world has basically gone to git nowadays, not only Sage. > Besides it's not so different from hg. > > Cheers, > Dima > > > > > PS, I found this page > https://wiki.sagemath.org/devel/DebianSage > <https://wiki.sagemath.org/devel/DebianSage> > last updated in 2009. Unless someone is willing to update it, I > suggest it might be better removed. > > Dave -- 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: ReST References in Sphinx and uniqueness
Johan S. H. Rosenkilde wrote: > I just ran into a doc issue that has been bothering me for years: global > uniqueness of reference labels in Sphinx. For instance, in > sage.coding.code_construction, we have: > > > ... [HP] W. C. Huffman, V. Pless, Fundamentals of Error-Correcting >Codes, Cambridge Univ. Press, 2003. > > This means I cannot use [HP] as a reference label in another file, say > sage.coding.hamming_code. Writing "[HP]_" in doc-string globally in Sage > *should* generate a link to sage.coding.code_construction. It does in > fact give me a compilation error :-S Well, first of all it is stupid to use such a short abbreviation, even without a year. Presumably it was introduced when references were local, so we may create a (meta-)ticket to change all of such occurrences. > This seems to be the recommended way of doing it in Sphinx. Am I the > only one who thinks this is crazy? Can/should we do something about > this? > > On a related note, the Developer's manual doesn't mention this problem, > or the fact that people should use ReST references (i.e. remember the > underscore), and that REFERENCES blocks should be at the top of the > module (and not in individual methods/functions). A quick grep showed > lots of recent code violating this convention. > > Is this sort of mess the reason Sphinx is so terribly slow, I wonder... Well, not that long ago, docbuilding in parallel wasn't even possible (h/t mostly John Palmieri IIRC, with a few others); before, the whole reference manual had been one monolithic block. Of course the documentation keeps growing (and hence also Sphinx' memory footprint and runtime), but it was IMHO always double dog-slow. But especially building plot* gets slower and slower because people keep adding more and more "nice" things I guess. To me the most annoying thing is that "make doc" (which ptestlong for example for no reason depends on) meanwhile even takes ages when Sphinx does nothing, or almost nothing, because nothing changed. (My recent impression is though that some files accidentally get touched somehow, such that they to Sphinx look modified. I can't give any concrete example, just noticed.) -leif -- 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] Python 2.7: subprocess32 (=backport from Python 3.2)
Incidentally came across the following [1]: --- See also: POSIX users (Linux, BSD, etc.) are strongly encouraged to install and use the much more recent subprocess32 [2] module instead of the version included with python 2.7. It is a drop in replacement with better behavior in many situations. --- Did anyone try? May be worth until we finally switch to Python 3.x, although it presumably doesn't affect the multiprocessing module we mostly use, but perhaps our pexpect interfaces and a few other things that occasionally cause trouble. -leif [1] https://docs.python.org/2.7/library/subprocess.html#module-subprocess [2] https://pypi.python.org/pypi/subprocess32/ -- 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: Error building package: sagelib-7.4.beta2
leif wrote:
> Simon Brandhorst wrote:
>> [sagelib-7.4.beta2] Building interpreters for fast_callable
>> [sagelib-7.4.beta2] python -u setup.py install
>> [sagelib-7.4.beta2]
>>
>> [sagelib-7.4.beta2] Traceback (most recent call last):
>> [sagelib-7.4.beta2] File "setup.py", line 47, in
>> [sagelib-7.4.beta2] from module_list import ext_modules,
>> library_order, aliases
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/src/module_list.py", line 150, in
>> [sagelib-7.4.beta2] from sage_setup.optional_extension import
>> OptionalExtension
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/src/sage_setup/optional_extension.py",
>> line 24, in
>> [sagelib-7.4.beta2] all_packages = list_packages(local=True)
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 211,
>> in list_packages
>> [sagelib-7.4.beta2] installed = installed_packages()
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 293,
>> in installed_packages
>> [sagelib-7.4.beta2] installed.update(pip_installed_packages())
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 147,
>> in pip_installed_packages
>> [sagelib-7.4.beta2] proc = subprocess.Popen(["pip", "list"],
>> stdout=subprocess.PIPE)
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/local/lib/python/subprocess.py", line
>> 710, in __init__
>> [sagelib-7.4.beta2] errread, errwrite)
>> [sagelib-7.4.beta2] File
>> "/home/agag/sbrandhorst/sage/sage/local/lib/python/subprocess.py", line
>> 1335, in _execute_child
>> [sagelib-7.4.beta2] raise child_exception
>> [sagelib-7.4.beta2] OSError: [Errno 2] No such file or directory
>
> 'pip' is a Sage standard package, hence ${SAGE_LOCAL}/bin/pip should be
> there.
>
> Presumably a (newly introduced) race condition / missing dependency in
> the Makefile.
>
> 'make pip && make' /may/ work; './sage -i pip && make' is more likely to
> succeed I guess.
>
> Thanks for reporting.
>
> (Will indirectly get fixed by #21291 [1] as well, I think.)
Nope, it won't.
This is now https://trac.sagemath.org/ticket/21403 -- needs (trivial!)
review.
-leif
--
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: Error building package: sagelib-7.4.beta2
Simon Brandhorst wrote:
> Tried to build sage devel. Did not work.
> So here is the hardware and a log is attached. (hopefully the right one)
>
> Description:Ubuntu 14.04.4 LTS
>
> Architecture: x86_64
> CPU op-mode(s):32-bit, 64-bit
> Byte Order:Little Endian
> CPU(s):4
> On-line CPU(s) list: 0-3
> Thread(s) per core:2
> Core(s) per socket:2
> Socket(s): 1
> NUMA node(s): 1
> Vendor ID: AuthenticAMD
> CPU family:21
> Model: 48
> Stepping: 1
> CPU MHz: 2000.000
> BogoMIPS: 6787.38
> Virtualization:AMD-V
> L1d cache: 16K
> L1i cache: 96K
> L2 cache: 2048K
> NUMA node0 CPU(s): 0-3
>
>
>
>
> [sagelib-7.4.beta2] Building interpreters for fast_callable
> [sagelib-7.4.beta2] python -u setup.py install
> [sagelib-7.4.beta2]
>
> [sagelib-7.4.beta2] Traceback (most recent call last):
> [sagelib-7.4.beta2] File "setup.py", line 47, in
> [sagelib-7.4.beta2] from module_list import ext_modules,
> library_order, aliases
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/src/module_list.py", line 150, in
> [sagelib-7.4.beta2] from sage_setup.optional_extension import
> OptionalExtension
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/src/sage_setup/optional_extension.py",
> line 24, in
> [sagelib-7.4.beta2] all_packages = list_packages(local=True)
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 211,
> in list_packages
> [sagelib-7.4.beta2] installed = installed_packages()
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 293,
> in installed_packages
> [sagelib-7.4.beta2] installed.update(pip_installed_packages())
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/src/sage/misc/package.py", line 147,
> in pip_installed_packages
> [sagelib-7.4.beta2] proc = subprocess.Popen(["pip", "list"],
> stdout=subprocess.PIPE)
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/local/lib/python/subprocess.py", line
> 710, in __init__
> [sagelib-7.4.beta2] errread, errwrite)
> [sagelib-7.4.beta2] File
> "/home/agag/sbrandhorst/sage/sage/local/lib/python/subprocess.py", line
> 1335, in _execute_child
> [sagelib-7.4.beta2] raise child_exception
> [sagelib-7.4.beta2] OSError: [Errno 2] No such file or directory
'pip' is a Sage standard package, hence ${SAGE_LOCAL}/bin/pip should be
there.
Presumably a (newly introduced) race condition / missing dependency in
the Makefile.
'make pip && make' /may/ work; './sage -i pip && make' is more likely to
succeed I guess.
Thanks for reporting.
(Will indirectly get fixed by #21291 [1] as well, I think.)
-leif
[1] https://trac.sagemath.org/ticket/21291
> [sagelib-7.4.beta2]
>
> [sagelib-7.4.beta2] Error building the Sage library
> [sagelib-7.4.beta2]
>
> [sagelib-7.4.beta2] Please email sage-devel
> (http://groups.google.com/group/sage-devel)
> [sagelib-7.4.beta2] explaining the problem and including the relevant
> part of the log file
> [sagelib-7.4.beta2]
> /home/agag/sbrandhorst/sage/sage/logs/pkgs/sagelib-7.4.beta2.log
> [sagelib-7.4.beta2] Describe your computer, operating system, etc.
> [sagelib-7.4.beta2]
>
> [sagelib-7.4.beta2] make[3]: *** [sage] Error 1
> [sagelib-7.4.beta2] make[3]: Leaving directory
> `/home/agag/sbrandhorst/sage/sage/src'
> [sagelib-7.4.beta2]
> [sagelib-7.4.beta2] real0m27.900s
> [sagelib-7.4.beta2] user0m17.900s
> [sagelib-7.4.beta2] sys0m4.588s
> make[2]: *** [sagelib] Error 2
> make[2]: Leaving directory `/home/agag/sbrandhorst/sage/sage/build/make'
> make[1]: *** [all] Error 2
> make[1]: Leaving directory `/home/agag/sbrandhorst/sage/sage/build/make'
>
> real303m54.652s
> user113m57.245s
> sys23m9.735s
> ***
> Error building Sage.
>
> The following package(s) may have failed to build (not necessarily
> during this run of 'make all'):
>
> * package: sagelib-7.4.beta2
> log file: /home/agag/sbrandhorst/sage/sage/logs/pkgs/sagelib-7.4.beta2.log
> build d
[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"
leif wrote:
> Simon Brandhorst wrote:
>> I did it triple-safe.
>> Doesn't seem to work. Here is the log.
>
> As guessed, the sizeof(long) test fails due to a runtime linker error.
> (Singular's 'configure' uses all libs found so far even in unrelated
> tests, and you seem to have some libomalloc system-wide which it picks
> up.) sizeof(long) should be set to 8 now though.
>
> So where does the build fail now?
>
> Could you move your libomalloc.so out of the way such that Singular
> won't find and try to use that? (It's supposed to build its own.)
/In principle/ it should be sufficient to explicitly configure Singular
with '--enable-omalloc' (in build/pkgs/singular/spkg-install), but
AFAICS it still insists on (at least temporarily) picking up an existing
library, in your case in addition an apparently broken one.
If you still have trouble building Singular (and if that's related to
the above), you can put another dumb patch (attached) into
build/pkgs/singular/patches/, then either running 'make' or doing
'./sage -i -s singular', later continuing with 'make'.
By the way, Sage 7.4.beta3 has just been released, still with the old
Singular though.
-leif
--
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.
--- a/latest/configure
+++ b/latest/configure
@@ -1981,7 +1981,7 @@ int main() {
omTestAddr()
; return 0; }
EOF
-if { (eval echo configure:1985: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext}; then
+if { (eval echo configure:1985: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && false; then
rm -rf conftest*
eval "ac_cv_lib_$ac_lib_var=yes"
else
[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"
Simon Brandhorst wrote: > I did it triple-safe. > Doesn't seem to work. Here is the log. As guessed, the sizeof(long) test fails due to a runtime linker error. (Singular's 'configure' uses all libs found so far even in unrelated tests, and you seem to have some libomalloc system-wide which it picks up.) sizeof(long) should be set to 8 now though. So where does the build fail now? Could you move your libomalloc.so out of the way such that Singular won't find and try to use that? (It's supposed to build its own.) -leif > On Friday, September 2, 2016 at 1:48:46 AM UTC+2, leif wrote: > > leif wrote: > > leif wrote: > >> Simon Brandhorst wrote: > >>> Thank you leif. Sorry for taking so long to answer. I did not > bring my > >>> laptop to work - so I could not get the log until now. > >> > >> Never mind. Please post / attach > >> > > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log > > > > > Ok, that doesn't tell much, but at least a bit... > > > > Compilation seems to work, but running the conftest supposed to print > > sizeof(long) presumably fails, I guess due to a runtime linker error. > > (You seem to have libomalloc installed system-wide; unfortunately > stderr > > is redirected to /dev/null.) > > > > Looking closer at Singular's top-level 'configure', it's quite > > surprising that test (and others) didn't fail before, AFAIK. > > > > > >>> A workaround would be great. Then I can get started. > >> > >> I can't tell before I've seen the log above, but I guess it won't be > >> hard to at least get you past /that/ error... ;-) > > > > I made a patch that may enlighten us regarding the error, and should > > bring you past the error with sizeof(long)!=sizeof(void*) at least. > > > > Copy the attached patch into build/pkgs/singular/patches/, then do > > > > ../sage -i -s singular > > P.S.: If you want to go triple-safe, delete the old build directory > (or > at least config.cache there) before running './sage -i ...': > > rm -rf /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2 > > > -leif > > > > Even if that succeeded, please first again make a copy of the newly > > generated config.log from the temporary Singular build directory as > > before (and post it) before proceeding. > > > > In case installing the Singular package now worked, you can continue > > building Sage by simply typing 'make' again (or 'make -jN` with N > being > > the number of threads/jobs, but you'll presumably know). > > > > > > Good luck! > > > > > > -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
leif wrote: > leif wrote: >> Simon Brandhorst wrote: >>> Thank you leif. Sorry for taking so long to answer. I did not bring my >>> laptop to work - so I could not get the log until now. >> >> Never mind. Please post / attach >> /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log > > Ok, that doesn't tell much, but at least a bit... > > Compilation seems to work, but running the conftest supposed to print > sizeof(long) presumably fails, I guess due to a runtime linker error. > (You seem to have libomalloc installed system-wide; unfortunately stderr > is redirected to /dev/null.) Yep. From the new config.log: configure:2313: checking size of long configure:2332: gcc -o conftest -O2 -g -fPIC -I/home/simon/sage/local/include -I/home/simon/sage/local/include -L/home/simon/sage/local/lib -L/home/simon/sage/local/lib -Wl,-rpath,/home/simon/sage/local/lib conftest.c -lomalloc -lgmp -lnsl -lm 1>&5 configure:2323:1: warning: return type defaults to 'int' [-Wimplicit-int] main() ^~~~ configure: In function 'main': configure:2326:11: warning: implicit declaration of function 'exit' [-Wimplicit-function-declaration] if (!f) exit(1); ^~~~ configure:2326:11: warning: incompatible implicit declaration of built-in function 'exit' configure:2326:11: note: include '' or provide a declaration of 'exit' configure:2328:3: warning: incompatible implicit declaration of built-in function 'exit' exit(0); ^~~~ configure:2328:3: note: include '' or provide a declaration of 'exit' ./conftest: error while loading shared libraries: libomalloc-0.9.6.so: cannot open shared object file: No such file or directory -leif > Looking closer at Singular's top-level 'configure', it's quite > surprising that test (and others) didn't fail before, AFAIK. > > >>> A workaround would be great. Then I can get started. >> >> I can't tell before I've seen the log above, but I guess it won't be >> hard to at least get you past /that/ error... ;-) > > I made a patch that may enlighten us regarding the error, and should > bring you past the error with sizeof(long)!=sizeof(void*) at least. > > Copy the attached patch into build/pkgs/singular/patches/, then do > > ../sage -i -s singular > > Even if that succeeded, please first again make a copy of the newly > generated config.log from the temporary Singular build directory as > before (and post it) before proceeding. > > In case installing the Singular package now worked, you can continue > building Sage by simply typing 'make' again (or 'make -jN` with N being > the number of threads/jobs, but you'll presumably know). > > > Good luck! > > > -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
leif wrote: > leif wrote: >> Simon Brandhorst wrote: >>> Thank you leif. Sorry for taking so long to answer. I did not bring my >>> laptop to work - so I could not get the log until now. >> >> Never mind. Please post / attach >> /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log > > Ok, that doesn't tell much, but at least a bit... > > Compilation seems to work, but running the conftest supposed to print > sizeof(long) presumably fails, I guess due to a runtime linker error. > (You seem to have libomalloc installed system-wide; unfortunately stderr > is redirected to /dev/null.) > > Looking closer at Singular's top-level 'configure', it's quite > surprising that test (and others) didn't fail before, AFAIK. > > >>> A workaround would be great. Then I can get started. >> >> I can't tell before I've seen the log above, but I guess it won't be >> hard to at least get you past /that/ error... ;-) > > I made a patch that may enlighten us regarding the error, and should > bring you past the error with sizeof(long)!=sizeof(void*) at least. > > Copy the attached patch into build/pkgs/singular/patches/, then do > > ../sage -i -s singular P.S.: If you want to go triple-safe, delete the old build directory (or at least config.cache there) before running './sage -i ...': rm -rf /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2 -leif > Even if that succeeded, please first again make a copy of the newly > generated config.log from the temporary Singular build directory as > before (and post it) before proceeding. > > In case installing the Singular package now worked, you can continue > building Sage by simply typing 'make' again (or 'make -jN` with N being > the number of threads/jobs, but you'll presumably know). > > > Good luck! > > > -leif > -- 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: Error building sage source "error: need equal sizes for long and void*"
leif wrote:
> Simon Brandhorst wrote:
>> Thank you leif. Sorry for taking so long to answer. I did not bring my
>> laptop to work - so I could not get the log until now.
>
> Never mind. Please post / attach
> /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log
Ok, that doesn't tell much, but at least a bit...
Compilation seems to work, but running the conftest supposed to print
sizeof(long) presumably fails, I guess due to a runtime linker error.
(You seem to have libomalloc installed system-wide; unfortunately stderr
is redirected to /dev/null.)
Looking closer at Singular's top-level 'configure', it's quite
surprising that test (and others) didn't fail before, AFAIK.
>> A workaround would be great. Then I can get started.
>
> I can't tell before I've seen the log above, but I guess it won't be
> hard to at least get you past /that/ error... ;-)
I made a patch that may enlighten us regarding the error, and should
bring you past the error with sizeof(long)!=sizeof(void*) at least.
Copy the attached patch into build/pkgs/singular/patches/, then do
./sage -i -s singular
Even if that succeeded, please first again make a copy of the newly
generated config.log from the temporary Singular build directory as
before (and post it) before proceeding.
In case installing the Singular package now worked, you can continue
building Sage by simply typing 'make' again (or 'make -jN` with N being
the number of threads/jobs, but you'll presumably know).
Good luck!
-leif
--
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.
--- a/latest/configure
+++ b/latest/configure
@@ -2328,14 +2328,14 @@ main()
exit(0);
}
EOF
-if { (eval echo configure:2332: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>/dev/null
+if { (eval echo configure:2332: \"$ac_link\") 1>&5; (eval $ac_link) 2>&5; } && test -s conftest${ac_exeext} && (./conftest; exit) 2>&5
then
ac_cv_sizeof_long=`cat conftestval`
else
echo "configure: failed program was:" >&5
cat conftest.$ac_ext >&5
rm -fr conftest*
- ac_cv_sizeof_long=0
+ ac_cv_sizeof_long=8 # crude hack just to get you past the later error
fi
rm -fr conftest*
fi
[sage-devel] Re: Error building sage source "error: need equal sizes for long and void*"
leif wrote: > Simon Brandhorst wrote: >> Thank you leif. Sorry for taking so long to answer. I did not bring my >> laptop to work - so I could not get the log until now. > > Never mind. Please post / attach > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log Oooops, there hadn't been attachments when I replied -- I could swear! Right now noticed them, will take a look... -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
Simon Brandhorst wrote: > Thank you leif. Sorry for taking so long to answer. I did not bring my > laptop to work - so I could not get the log until now. Never mind. Please post / attach /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log . > A workaround would be great. Then I can get started. I can't tell before I've seen the log above, but I guess it won't be hard to at least get you past /that/ error... ;-) > Tried to build sage devel at work and got a different error. Should I > open a thread for that as well? In case it's a quite different error (or the system is different anyway, w.r.t. the distribution / compilers), yes. -leif -- 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: Categories catalog?
Simon King wrote: > On 2016-09-01, Johan S H Rosenkilde <santaph...@gmail.com> wrote: >> +1 to removing not-very-common categories from global namespace as well. > > I agree. Now, as we have the axiom framework, it is very easy to create > a specific category, and there is no need to have CommutativeRings() in > the global namespace when one can simply use Rings.Commutative() Deforestation FTW. People should just import what they need / are interested in when they want shortcuts in their global namespace. It's nice we now have the following in each and every (I think) Sage crash report: XD > --> 377 import sage.all # until sage's import hell is fixed -leif -- 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: giacpy depends (silently) on SageObject
Vincent Delecroix wrote: > On 01/09/16 04:34, Jeroen Demeyer wrote: >> On 2016-08-31 23:26, Vincent Delecroix wrote: >>> Hello, >>> >>> In the optional package giacpy there are some extension classes that >>> depend on SageObject. >> >> Does it really only need SageObject? I see no reason why giacpy would >> need to do that. So the easiest solution seems to make giacpy *not* >> depend on SageObject. > > We should not forbid inheriting from SageObect/Element, > Parent/CategoryObject in external packages. We should just provide a > simple way to automatize the recompilation. This is a step toward > modularization. Exactly. (See also my other reply.) It would be dumb and totally annoying if all such packages would get rebuilt upon *any* change to the Sage library, and just as bad as having to "manually" figure out /which/ packages might need rebuilding after a change to some specific part of the Sage library. -leif > Moreover, I think that we should fix at some moment a definite API for > all these base classes and coercion. Not now since there is some > cleaning going on at #21380. > > Cheers, > Vincent > -- 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: giacpy depends (silently) on SageObject
Vincent Delecroix wrote: > On 31/08/16 19:48, leif wrote: >> leif wrote: >>> leif wrote: >>>> Vincent Delecroix wrote: >>>>> Hello, >>>>> >>>>> In the optional package giacpy there are some extension classes that >>>>> depend on SageObject. Hence if I do some modification to SageObject >>>>> and >>>>> perform "make" the giacpy package is broken. Is there a solution to >>>>> rebuild external packages that depends on sagelib when doing "make"? >>>> >>>> Try adding $(SAGERUNTIME) to its dependencies file, *before* the '|'. >> >> Next suggestion (hopefully the last, and a working one): >> >> Instead of $(SAGERUNTIME), add >> >> $(SAGE_SRC)/build/cythonized/sage/structure/sage_object.c >> >> (again, *before* the pipe, but still put $(SAGERUNTIME) after it). > > This might not work. giacpy depends on Integer and Rational. Hence > indirectly from SageObject. Can I safely only set dependencies to > $(SAGE_SRC)/build/cythonized/sage/rings/integer.c and > $(SAGE_SRC)/build/cythonized/sage/rings/rational.c? Are these > necessarily regenerated if SageObject get changed? I guess integer.pyx and rational.pyx only depend on sage_object.pxd, so cython will only regenerate the C files of the latter if the former changed. But that seems to be what you intend. It's still a bit hackish, but only needed for developers anyway, as users upgrade the whole Sage library such that in most if not all cases "everything" will get rebuilt. While we may integrate giacpy into the Sage library as an optional extension (though somebody suggested to make giac standard IIRC), a more generic solution to let (optional) packages depend on specific parts of the Sage library would be good. [First step would perhaps again be to let cython generate Makefiles or Makefile snippets we could then "install" along with a package that uses Cython and depends on the Sage library. Then such packages could themselves "decide" when they need to get rebuilt. Although the latter is not much different to manually changing the dependencies file of a package, which after all belongs to it, not really Sage, it would be a bit more automated and hence less tedious and error-prone.] -leif -- 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: Categories catalog?
Jeroen Demeyer wrote: > Should we move all categories in a catalog, e.g. rename > > FiniteSemigroups > > to > > categories.FiniteSemigroups > > Even if you think that categories belong in the top-level namespace, I > think it would still be useful to have a catalog such that > TAB-completion can give a list of all named categories in Sage. > > For example, today I was looking for the category of additive abelian > groups and could not immediately find it. It turns out it is called > CommutativeAdditiveGroups. In such a catalog we could maybe add aliases > like AdditiveCommutativeGroups = CommutativeAdditiveGroups. ... while you don't need a catalog to create such an alias. Still, having a catalog wouldn't be bad. -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
Dima Pasechnik wrote: > not sure whether it's worth the trouble fighting with outdated Singular > package refusing to work with > gcc 6.1.1. Perhaps it might be easier to use the bleeding edge > https://trac.sagemath.org/ticket/17635 and > https://trac.sagemath.org/ticket/17254 Well, he was just *starting* developing Sage. Of course we want to get rid of Singular 3.x asap, but I'm not saying we should further fix it, and he's currently stuck in an early stage. It will IMHO be worth to at least *know* why it failed for him, since I've never seen that test failing, and similar may happen elsewhere, too. There's possibly some simple fix or work-around such that at least he personally can continue building his first development version... FWIW, Volker on Fedora had less issues with its GCC 6.1.1 and Singular than I had with vanilla GCC 6.1, but we fixed them before 7.3 was released. -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
leif wrote: > Simon Brandhorst wrote: >> So here are the logs. And a larger bit of the install.log > > Thanks, but we'd need the config.log files from Singular, not Sage's > top-level one, in your case: > > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log > > and since omalloc takes an allegedly cached value for sizeof(long) from > Singular's top-level 'configure', where the value indeed appears to be > already wrong, probably also: > > /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.cache Hmmm, I'd say there's a slight bug in Singular's top-level 'configure', as it doesn't really check for sizeof(long), but only cares whether it is 4 or not. If the test altogether fails, it doesn't bail out, but instead really sets the value (which is used later on) to 0. Simon, to figure out *why* the conftest failed, we still need the first file I mentioned above. -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
Simon Brandhorst wrote: > So here are the logs. And a larger bit of the install.log Thanks, but we'd need the config.log files from Singular, not Sage's top-level one, in your case: /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.log and since omalloc takes an allegedly cached value for sizeof(long) from Singular's top-level 'configure', where the value indeed appears to be already wrong, probably also: /home/simon/sage/local/var/tmp/sage/build/singular-3.1.7p1.p2/src/latest/config.cache -leif -- 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: tutte_polynomial tests
Francois Bissey wrote: > https://trac.sagemath.org/ticket/21355 > and > https://trac.sagemath.org/ticket/21289 > for the fix And you may consider subscribing to sage-release... ;-) -leif -- 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: giacpy depends (silently) on SageObject
leif wrote:
> leif wrote:
>> leif wrote:
>>> Vincent Delecroix wrote:
>>>> Hello,
>>>>
>>>> In the optional package giacpy there are some extension classes that
>>>> depend on SageObject. Hence if I do some modification to SageObject and
>>>> perform "make" the giacpy package is broken. Is there a solution to
>>>> rebuild external packages that depends on sagelib when doing "make"?
>>>
>>> Try adding $(SAGERUNTIME) to its dependencies file, *before* the '|'.
>
> Next suggestion (hopefully the last, and a working one):
>
> Instead of $(SAGERUNTIME), add
>
> $(SAGE_SRC)/build/cythonized/sage/structure/sage_object.c
>
> (again, *before* the pipe, but still put $(SAGERUNTIME) after it).
P.S.: (Sorry, forgot to mention:)
You obviously have to recreate Sage's Makefile after changing giacpy's
dependencies of course.
The probably easiest, but also the cleanest way is to bump giacpy's
(Sage) patch level (in its package-version.txt), i.e., append a '.p0' there.
I haven't tried with giacpy (as I don't want to spam my Sage
installations with further optional packages), but otherwise works for
me. If I touch src/build/cythonized/sage/structure/sage_object.c (which
will also happen in case you modify sage_object.{pxd,pyx}), running
'make build' rebuilds the extension module and afterwards the package to
whose dependencies I had added what I mentioned above.
-leif
--
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: giacpy depends (silently) on SageObject
leif wrote: > leif wrote: >> Vincent Delecroix wrote: >>> Hello, >>> >>> In the optional package giacpy there are some extension classes that >>> depend on SageObject. Hence if I do some modification to SageObject and >>> perform "make" the giacpy package is broken. Is there a solution to >>> rebuild external packages that depends on sagelib when doing "make"? >> >> Try adding $(SAGERUNTIME) to its dependencies file, *before* the '|'. Next suggestion (hopefully the last, and a working one): Instead of $(SAGERUNTIME), add $(SAGE_SRC)/build/cythonized/sage/structure/sage_object.c (again, *before* the pipe, but still put $(SAGERUNTIME) after it). -leif >> >> Unfortunately we don't have a file with a timestamp for the Sage library >> in local/var/lib/sage/installed/ that could be touched. > > And sagelib is a phony target, but you could abuse > local/var/lib/sage/installed/ipython-* since $(SAGERUNTIME) depends on that. > > Not sure what other (useless) rebuilds that would trigger though. > > The only other way I see at the moment is to actually add the Sage > sourcefile to giacpy's dependencies, but wait -- cysignals is already in > giacpy's dependencies, so you could abuse > local/var/lib/sage/installed/cysignals-* as well. > > > Better open a ticket... > > > -leif -- 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: giacpy depends (silently) on SageObject
leif wrote: > Vincent Delecroix wrote: >> Hello, >> >> In the optional package giacpy there are some extension classes that >> depend on SageObject. Hence if I do some modification to SageObject and >> perform "make" the giacpy package is broken. Is there a solution to >> rebuild external packages that depends on sagelib when doing "make"? > > Try adding $(SAGERUNTIME) to its dependencies file, *before* the '|'. > > Unfortunately we don't have a file with a timestamp for the Sage library > in local/var/lib/sage/installed/ that could be touched. And sagelib is a phony target, but you could abuse local/var/lib/sage/installed/ipython-* since $(SAGERUNTIME) depends on that. Not sure what other (useless) rebuilds that would trigger though. The only other way I see at the moment is to actually add the Sage sourcefile to giacpy's dependencies, but wait -- cysignals is already in giacpy's dependencies, so you could abuse local/var/lib/sage/installed/cysignals-* as well. Better open a ticket... -leif -- 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: giacpy depends (silently) on SageObject
Vincent Delecroix wrote: > Hello, > > In the optional package giacpy there are some extension classes that > depend on SageObject. Hence if I do some modification to SageObject and > perform "make" the giacpy package is broken. Is there a solution to > rebuild external packages that depends on sagelib when doing "make"? Try adding $(SAGERUNTIME) to its dependencies file, *before* the '|'. Unfortunately we don't have a file with a timestamp for the Sage library in local/var/lib/sage/installed/ that could be touched. -leif -- 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: Error building sage source "error: need equal sizes for long and void*"
Simon Brandhorst wrote: > So far I am using precompiled binaries. They work. Now I am thinking on > writing my own branch/contributing to sage so I followed the instructions on > > http://doc.sagemath.org/html/en/developer/walk_through.html > > to get a developer version of sage. > Basically I just typed > > git clone git://github.com/sagemath/sage.git > cd sage > git checkout develop > make > > And get an error Message: > [singular-3.1.7p1.p2] checking size of long... (cached) 0 > [singular-3.1.7p1.p2] checking size of void*... 8 > [singular-3.1.7p1.p2] checking size of double... 8 > [singular-3.1.7p1.p2] checking size of size_t... 8 > [singular-3.1.7p1.p2] configure: error: need equal sizes for long and void* > [singular-3.1.7p1.p2] configure: error: ./configure failed for omalloc > [singular-3.1.7p1.p2] Unable to configure Singular. > [singular-3.1.7p1.p2] Error building Singular (error in config). sizeof(long) is zero... Nice. > (the log is too big to attach) Well, the last lines should contain "The following packages may have failed to build:" along with paths to the temporary build directory of Singular and the log file created for that package. Since Singular's 'configure' already failed, we'd need the config.log file(s) from subfolders of the build directory mentioned. Also logs/pkgs/singular-3.1.7p1.p2.log shouldn't be that long; from that we could see /which/ 'configure' failed (presumably indeed that of omalloc), as Singular consists of a couple of components with their own 'configure' scripts. -leif -- 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: Bug in FreeQuadraticModule.discriminant()
John Cremona wrote:
> Indeed, that is a bug in line 371 of the file
> sage/modules/free_quadratic_module.py -- an easy fix.
... and more than 8 years old.
The check whether the rank is even or not is useless as well; '//' in
Python is integer division (taking the floor).
(And the docstrings don't use proper markup...)
> Perhaps someone ought to look through all occurrences of ^ in .py files
> outside of docstrings (where they are OK thanks to preparsing).
Well, there are a couple of valid xor uses in the Sage library as well.
-leif
> On 31 August 2016 at 13:44, Simon Brandhorst <sbrandho...@web.de
> <mailto:sbrandho...@web.de>> wrote:
>
>
> {
> sage: q=FreeQuadraticModule(ZZ,2,inner_product_matrix=1)
> sage: q
> Ambient free quadratic module of rank 2 over the principal ideal
> domain Integer Ring
> Inner product matrix:
> [1 0]
> [0 1]
> sage: q.determinant()
> 1
> sage: q.discriminant()
> -2
> }
> #The expected value here is -1
>
> The following example should clarity what is wrong.
> {
> sage: q=FreeQuadraticModule(QQ,2,inner_product_matrix=1)
> sage: q.determinant()
> 1
> sage: q.discriminant()
>
> ---
> RuntimeError Traceback (most recent
> call last)
> in ()
> > 1 q.discriminant()
>
>
> /usr/lib/sagemath/local/lib/python2.7/site-packages/sage/modules/free_quadratic_module.pyc
> in discriminant(self)
> 377 else:
> 378 r = (n-1)//2
> --> 379 return (-1)^r*self.gram_matrix().determinant()
> 380
> 381 def gram_matrix(self):
>
> sage/structure/element.pyx in sage.structure.element.Element.__xor__
> (/usr/lib/sagemath//src/build/cythonized/sage/structure/element.c:8229)()
>
> RuntimeError: Use ** for exponentiation, not '^', which means xor
> in Python, and has the wrong precedence.
> }
>
> This happened with sage 7.0 and 7.2 on two different machines.
> (Ubuntu 14.04.4 LTS, and fedora 24)
--
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: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?
leif wrote: > Erik Bray wrote: >> On Tue, Aug 30, 2016 at 10:12 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> >> wrote: >>> On 2016-08-30 19:44, leif wrote: >>>> >>>> Anyway, our current policy is that *only* the release manager is allowed >>>> to close tickets, so I wouldn't do without first asking. >>> >>> >>> I have the "power" to close tickets, but I don't do that because of this >>> reason. The only exceptions are tickets which are obviously mistakes or >>> spam. >> >> I think it' should be fine to close tickets so long as it's already >> been signed off on as close-able in some sense or another. > > Well, we once had release notes... > > where also tickets closed (but not merged) within the current > release cycle were listed. > > Since duplicate/invalid/wontfix is a *milestone* (!), it's not easy to > recover these when they've already been closed. In fact, also > duplicates were closed /after/ the other ticket(s) fixing an issue had > been merged and released. P.S.: I of course meant "duplicates" in the sense of being superseded by another ticket, not such reporting exactly the same issue. Still, also positively reviewed /true/ duplicates were closed by the release manager, after releasing the next "stable" release. -leif -- 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: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?
Erik Bray wrote: > On Tue, Aug 30, 2016 at 10:12 PM, Jeroen Demeyer <jdeme...@cage.ugent.be> > wrote: >> On 2016-08-30 19:44, leif wrote: >>> >>> Anyway, our current policy is that *only* the release manager is allowed >>> to close tickets, so I wouldn't do without first asking. >> >> >> I have the "power" to close tickets, but I don't do that because of this >> reason. The only exceptions are tickets which are obviously mistakes or >> spam. > > I think it' should be fine to close tickets so long as it's already > been signed off on as close-able in some sense or another. Well, we once had release notes... ... where also tickets closed (but not merged) within the current release cycle were listed. Since duplicate/invalid/wontfix is a *milestone* (!), it's not easy to recover these when they've already been closed. In fact, also duplicates were closed /after/ the other ticket(s) fixing an issue had been merged and released. -leif -- 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: missing emails from trac
Erik Bray wrote: > On Wed, Aug 31, 2016 at 1:02 AM, leif <not.rea...@online.de> wrote: >> leif wrote: >>> Dima Pasechnik wrote: >>>> >>>> On Tuesday, August 30, 2016 at 5:20:37 PM UTC, leif wrote: >>>> >>>> FWIW, I now have *significant* delay in (apparently) *all* >>>> notifications >>>> from trac, even between those for the same ticket where the comments >>>> were made within a few minutes. >>>> >>>> >>>> please post (or email me) headers in an example of your message. >>> >>> Thanks, but that was probably exceptional. (I noticed receiving >>> notifications for three consecutive comments with a delay of about 30, >>> 60, and 90 minutes, while they were made within 13 minutes.) >>> >>> I now received some further notifications (from different tickets and >>> not by me) "in time", so I'll wait and see how it behaves the next days. >> >> P.S.: Looking at the headers, the delay happened *within* sendgrid, so >> there's presumably nothing we can (or have to) do, other than perhaps >> changing the provider in case the situation worsens. > > I wonder if it has to do with the destination too though (albeit not > entirely either, since as you wrote it used to work fine for you). > Some combination of sendgrid and the destination then. I'd rather guess it depends (besides sysload and traffic of course) on the /content/ of the messages, I have no idea what filterfoo*.sendgrid.net does though. (The delayed trac messages seemed harmless, didn't even contain links other than those added by trac IIRC.) -leif -- 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: missing emails from trac
leif wrote: > Dima Pasechnik wrote: >> >> On Tuesday, August 30, 2016 at 5:20:37 PM UTC, leif wrote: >> >> FWIW, I now have *significant* delay in (apparently) *all* >> notifications >> from trac, even between those for the same ticket where the comments >> were made within a few minutes. >> >> >> please post (or email me) headers in an example of your message. > > Thanks, but that was probably exceptional. (I noticed receiving > notifications for three consecutive comments with a delay of about 30, > 60, and 90 minutes, while they were made within 13 minutes.) > > I now received some further notifications (from different tickets and > not by me) "in time", so I'll wait and see how it behaves the next days. P.S.: Looking at the headers, the delay happened *within* sendgrid, so there's presumably nothing we can (or have to) do, other than perhaps changing the provider in case the situation worsens. -leif -- 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: missing emails from trac
Dima Pasechnik wrote: > > On Tuesday, August 30, 2016 at 5:20:37 PM UTC, leif wrote: > > FWIW, I now have *significant* delay in (apparently) *all* > notifications > from trac, even between those for the same ticket where the comments > were made within a few minutes. > > > please post (or email me) headers in an example of your message. Thanks, but that was probably exceptional. (I noticed receiving notifications for three consecutive comments with a delay of about 30, 60, and 90 minutes, while they were made within 13 minutes.) I now received some further notifications (from different tickets and not by me) "in time", so I'll wait and see how it behaves the next days. (Before we switched to sendgrid, I received the notifications often before the trac page was reloaded... :-) ) -leif -- 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: Should we close all tickets with milestone "sage-duplicate/invalid/wontfix"?
Frédéric Chapoton wrote: > Hello, > > May *please* somebody close all the *69* positive-reviewed > duplicate/invalid/wontfix tickets ? > > if Volker has no time for that, maybe somebody else should be given the > power to do that ? Well, a couple do have the power, but the problem is that they get cc'ed to each and every ticket they batch-modify (hence the account vbraun_spam). In this case perhaps less of a problem, since there usually isn't much activity after such tickets have been closed. Anyway, our current policy is that *only* the release manager is allowed to close tickets, so I wouldn't do without first asking. (Although he probably doesn't have the time to answer either... ;-) ) -leif -- 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: [Yet again] Sage's R vs system's R
Emmanuel Charpentier wrote: > Well... Tha was ... instructive ... > > We see to have two consistent options to keep R a standard package : > > 1. Keep R as a standard package, including the binaries. This involves : > * make xz a standard package ; > * port the old-style pcre package as a new-style standard package ; > * make R depend on xz and pcre ; > 2. Keep an interface to R as a standard package. This involves : > * make a working system's R installation a a prerequisite of R ; > * possibly making this prerequisite (R's)-version-specific. > > The first solution guarantees that any existing code using R can still > be run (modulo R's evolution) but involves maintaining a not-so-small R > binary for an indefinite future... It also involves a duplication of R > packages libraries between system's and Sage's installations, which can > be a non-trivial amount (my *small* use of R packages amounts to about > 360 packages, 29 among them being "standard" R packages). This cvcan be > alleviated by using Sage's R as the system's R installation (I didn't do > that until now for fear of sage's problems : R is my daily bread and > butter...). > > The second one breaks this guarantee, and introduces the possibility of > version incompatibilities between R and Sage.. > > We could also make R an optional package, with (again) two options : > > * Maintain a R optional binary, depending on xz and pcre. > * Maintain an R optional interface. > > > Making R optional *will* break existing code. How do you come to that conclusion? Making R optional just means people using R (or the interface to it) would have to "manually" (=explicitly) install it then (or in the future, perhaps have to configure Sage '--with-R' or something like that). -leif > This boils down to : > > * R binary standard > * R interface standard > * R binary optional > * R interface optional > > My vote goes to R binary standard for now (dissecting the current > package to separate binary and interface and creating the required > Makefile modifications is not trivial) ; my second choice would be R > interface standard, if we can accept the possibility of R-induced > inconsistencies...) > > What are your choices ? -- 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: missing emails from trac
Dima Pasechnik wrote: > > On Sunday, August 28, 2016 at 6:13:18 PM UTC, Harald Schilly wrote: > > Hi, I've no idea, I've not setup that server and never did something > for DKIM before. > > > OK, I thought that is had something to do with you doing sendgrid-related > email authentication. > But it does not, it's merely a local quirk (a setting only needed for > running a "real" > smtp server, accepting messages from remote clients, etc - not our case). > > I ended up just disabling Milter in the postfix config file.. FWIW, I now have *significant* delay in (apparently) *all* notifications from trac, even between those for the same ticket where the comments were made within a few minutes. -leif > To me, it sounds like a configuration issue. Top hit > I got is this SE page, which is most likely what needs to be done: > > > http://unix.stackexchange.com/questions/74477/postfix-smtpd-warning-connect-to-milter-service-unix-var-run-opendkim-opendki > > <http://unix.stackexchange.com/questions/74477/postfix-smtpd-warning-connect-to-milter-service-unix-var-run-opendkim-opendki> > > > -- h > > > On Fri, Aug 26, 2016 at 10:54 PM, Dima Pasechnik <dim...@gmail.com > > wrote: > > This might be related to DKIM, some kind of misconfiguration delaying > > things: > > > > For each mail sent out I see in /var/log/mail.log a message like > > > > trac postfix/smtpd[12253]: warning: connect to Milter service > > inet:localhost:8891: Connection refused > > > > Harald, do you have an idea what this might be? > > > > Dima > > > > On Friday, August 26, 2016 at 9:34:49 PM UTC+1, Travis Scrimshaw > wrote: > >> > >> I get them, but with a significant lag time. > >> > >> 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: How to use Sage's doc builder off the source tree
Jeroen Demeyer wrote: > On 2016-08-28 18:59, Simon King wrote: >> Is it possible to use "sage -t" on such docs? > > I would guess that the doctesting is *not* affected by the formatting of > the surrounding documentation. AFAIK Sage's doctest parser doesn't care about markup (especially sections) in docstrings; it just looks for and extracts code examples, i.e., (properly indented) blocks of lines starting with a (Sage) prompt and eventual lines with output following it. -leif -- 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: How to check if package is up-to-date?
Simon King wrote: > Hi Leif, > > On 2016-08-28, leif <not.rea...@online.de> wrote: >> I have to admit I had to try whether this has changed "recently", but >> no, already installed optional / experimental packages still aren't >> reconsidered upon upgrading Sage, i.e., you currently have to explicitly >> "reinstall" them if there's a new version available. > > Seriously?? I thought that automatic upgrade of packages is one of the > reasons why one was supposed to do "make" after "git pull". Is there > consensus that installed packages *should* automatically be upgraded > to the latest available version, in order to avoid known breakages? It was always true for *standard* packages. But in my test I indeed made a mistake, and meanwhile also optional and experimental packages get reinstalled (hence upgraded) in case they had been installed previously. (They do get reinstalled *after* docbuilding, so I actually missed that, not wanting to wait, since docbuilding takes ages even if nothing changed / really happens.) Sorry for the noise. -leif -- 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: How to check if package is up-to-date?
Simon King wrote:
> Hi Leif,
>
> On 2016-08-28, leif <not.rea...@online.de> wrote:
>> Yes and no ;-) -- with "has installed" meaning the passive present form
>> (rather "the user somehow has an old version installed", where
>> "manually" doesn't really make sense though).
>
> I meant: The user did some effort in order to install a version that is
> not the latest version.
I was assuming you meant that.
>> The only way currently is to for example install an ("up-to-date"!)
>> optional or experimental package and afterwards upgrade Sage (without
>> installing the newer version of the optional/experimental package
>> although it is "available" for the new version of Sage).
>
> Is that currently possible? I thought that with new-style packages all
> installed optional/experimental packages will automatically be upgraded
> when Sage is upgraded, because the stuff in SAGE_ROOT/build/pkgs is under
> Sage's version control and defines what package version *should* be
> installed ("should" in the sense of "this is the current version and
> doctests pass with it").
I have to admit I had to try whether this has changed "recently", but
no, already installed optional / experimental packages still aren't
reconsidered upon upgrading Sage, i.e., you currently have to explicitly
"reinstall" them if there's a new version available. (Unless I made
some mistake; didn't inspect the build system for changes related to
this, but would probably have noticed such a while ago.)
Anyway, that's probably subject to change with one of the next major /
stable releases of Sage.
-leif
>> Unless he/she has been ("manually"?) messing around with
>> package-version.txt and checksums.ini of course (but then "up-to-date"
>> would simply depend on the perspective).
>
> Exactly. That's what I meant by "manually".
>
> 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.
[sage-devel] Re: How to check if package is up-to-date?
Simon King wrote:
> Hey!
>
> On 2016-08-19, leif <not.rea...@online.de> wrote:
>> Jeroen Demeyer wrote:
>>> What is the recommended way to check if the latest version of a given
>>> Sage package is installed? The function is_package_installed() only
>>> checks whether *some* version of the package is installed, which might
>>> not be the latest version.
>>
>> Note that the "latest" version of any package is always exactly the one
>> hardcoded into the "unified repo" for any given Sage version.
>
> Which means that is_package_installed() gives the desired answer,
> *unless* the user has somehow installed an old version manually, isn't
> it?
Yes and no ;-) -- with "has installed" meaning the passive present form
(rather "the user somehow has an old version installed", where
"manually" doesn't really make sense though).
The only way currently is to for example install an ("up-to-date"!)
optional or experimental package and afterwards upgrade Sage (without
installing the newer version of the optional/experimental package
although it is "available" for the new version of Sage).
Unless he/she has been ("manually"?) messing around with
package-version.txt and checksums.ini of course (but then "up-to-date"
would simply depend on the perspective).
[This refers to non-PIP packages; for PIP packages, the situation is
presumably different.]
-leif
--
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: How to use Sage's doc builder off the source tree
Volker Braun wrote: > On Sunday, August 28, 2016 at 2:30:27 PM UTC+2, Simon King wrote: > > Thus, the question remains: How to use the doc builder in order to > create in SAGE_ROOT/local/share/ the documentation of a pip-installable > module, > > > Unless you plan on eventually putting the code in Sage I wouldn't use > Sage docstring format. E.g google-style docstrings are a better syntax, > have better tooling (sphinx-napoleon), and nicer looking output. Is there any (probably long-term) plan to change Sage's docstrings (i.e., to a better format)? -leif -- 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: Comparison and logarithm on .py vs. interactive
Ralf Stephan wrote: > On Saturday, August 27, 2016 at 7:05:28 AM UTC+2, Jori Mäntysalo wrote: > > But shouldn't it work in any case? I.e. comparison of > log(a+b*c^2...) to > some number should work when a,b,c... are sage Integers. > > > log(integer) will not be expanded numerically except for log(0) and log(1). > If you want it expanded, either give a float argument, eg log(2.), or > append n(). N() wasn't the problem, but (also) rounding: (s is 12 here.) sage: n*log(n, 2) 24 sage: n*log(n, 2r) 8*log(8)/log(2) sage: N(n*log(n, 2r)) 24.0 sage: 2*s < n*log(n, 2) False sage: 2*s > n*log(n, 2) False sage: 2*s > n*log(n, 2r) 24 > 8*log(8)/log(2) sage: bool(2*s > n*log(n, 2r)) True sage: bool(2r*s > n*log(n, 2r)) True sage: bool(2r*s > n*log(n, 2)) False sage: 24 > N(n*log(n, 2r)) True -leif -- 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: missing emails from trac
Sébastien Labbé wrote: > Bonjour sage-devel, > > I am not receiving emails notification from new posted comments on trac > tickets I'm involved in. Or maybe there is a delay to receive them? FWIW, I occasionally get them out-of-order (even for the same ticket). It happened once (I noticed) I definitely didn't get a notification for an ordinary post on a ticket, but that was perhaps a couple of weeks ago. Closure notifications seem still to be a problem, I did get exactly /one/ for the tickets merged into 7.4.beta1, while I was cc'ed / participated in a couple. -leif -- 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: broken %attach and %debug ?
VulK wrote: >>and me too, this is really very annoying that %attach is broken.. > +1 > > A related question: why do we implement %attach in sage rather than making a > patch for upstream IPython? You mean submitting a patch upstream? (Otherwise repackagers won't be happy, but upstream would have to accept it of course. I'm not sure it would be suitable, as AFAIK we use our own Cython stuff to attach Cython files, i.e., extension modules.) -leif > * Frédéric Chapoton <fchapot...@gmail.com> [2016-08-26 06:01:23]: > >>and me too, this is really very annoying that %attach is broken.. >>Le dimanche 14 août 2016 02:14:44 UTC+2, Travis Scrimshaw a écrit : >> >>I would really like to have %attach back working. >>Best, >>Travis >>On Friday, August 12, 2016 at 12:50:23 PM UTC-5, Volker Braun wrote: >> >>Presumably attach (or, more generally, using the python inputhook) >>doesn't work since Ipython 5 now implements its own input handling. >>On Friday, August 12, 2016 at 2:22:51 PM UTC+2, Frédéric Chapoton >>wrote: >> >>is this only me, or the recent update to ipython 5.0 has broken severel >>things in 7.4.b0 ? >>it seems that somebody already complained about sage_mode and %lprun >>(see [1]https://trac.sagemath.org/ticket/21006) >>for me, %attach does not seem to reload the files that changed >>and using %debug doe snot quite work, because the special command r and >>n are still mapped to numerical and R interpreter inside the ipbd >>session >>Frederic >> >>-- >>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 [2]sage-devel+unsubscr...@googlegroups.com. >>To post to this group, send email to [3]sage-devel@googlegroups.com. >>Visit this group at [4]https://groups.google.com/group/sage-devel. >>For more options, visit [5]https://groups.google.com/d/optout. >> >> References >> >>1. https://trac.sagemath.org/ticket/21006 >>2. mailto:sage-devel+unsubscr...@googlegroups.com >>3. mailto:sage-devel@googlegroups.com >>4. https://groups.google.com/group/sage-devel >>5. 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.
[sage-devel] Re: dependency on packages typed 'pip'
Thierry wrote: > On Fri, Aug 26, 2016 at 02:43:05PM +0200, Jeroen Demeyer wrote: >> On 2016-08-26 14:40, Thierry wrote: >>> So, what is the usecase for package typed 'pip' ? >> >> It's only a convenient user interface: the user does not need to know >> whether a package is available using pip or as Sage package: "./sage -i >> PKGNAME" will work. > > Shall we flood the pkg directory just in case someone needs to install > trac or mercurial ? The list of potentially interesting packages is pretty > huge: https://www.scipy.org/topical-software.html > > Wouldn't it be better to advise the user that s·he can use 'sage -pip > install' when a package does not exist ? When a package does not exist, we shouldn't advise the user to (try to) install it. ;-) I agree though that type=='pip' is a bit useless at the moment, and doesn't fit the other "types". (See also comments from Erik and me on the neighbour thread on R regarding what package types we'd need...) -leif -- 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: Comparison and logarithm on .py vs. interactive
leif wrote: > Jori Mäntysalo wrote: >> On Fri, 26 Aug 2016, leif wrote: >> >>> Hmmm, does Posets.BooleanLattice() care whether you pass an int or an >>> Integer? (I.e., does the return type of its methods change?) >> >> No: >> >> sage: P = Posets.BooleanLattice(3) >> sage: Q = Posets.BooleanLattice(3r) >> sage: P == Q >> True >> sage: P is Q >> True > > I rather meant e.g. type(P.cardinality()), but since 'P is Q' holds, > they won't differ. > > No idea... For me, it /does/ make a difference (using Python vs. Sage literals): $ ./sage ┌┐ │ SageMath version 7.3, Release Date: 2016-08-04 │ │ Type "notebook()" for the browser-based notebook interface.│ │ Type "help()" for help.│ └┘ sage: from sage.combinat.posets.poset_examples import Posets sage: from sage.misc.functional import log sage: P = Posets.BooleanLattice(3); n = P.cardinality(); s = P._hasse_diagram.size() sage: if 2*s > n*log(n, 2): print "True" sage: from sage.combinat.posets.poset_examples import Posets sage: from sage.misc.functional import log sage: P = Posets.BooleanLattice(3r); n = P.cardinality(); s = P._hasse_diagram.size() sage: if 2r*s > n*log(n, 2r): print "True" True sage: And it's caused by this: sage: type(n*log(n, 2)) sage: type(n*log(n, 2r)) (FWIW, while .cardinality() returns Integer, ._hasse_diagram.size() returns int, but that doesn't matter here.) -leif -- 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: Comparison and logarithm on .py vs. interactive
Jori Mäntysalo wrote: > On Fri, 26 Aug 2016, leif wrote: > >> Hmmm, does Posets.BooleanLattice() care whether you pass an int or an >> Integer? (I.e., does the return type of its methods change?) > > No: > > sage: P = Posets.BooleanLattice(3) > sage: Q = Posets.BooleanLattice(3r) > sage: P == Q > True > sage: P is Q > True I rather meant e.g. type(P.cardinality()), but since 'P is Q' holds, they won't differ. No idea... -leif -- 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: Comparison and logarithm on .py vs. interactive
Jori Mäntysalo wrote: > On Fri, 26 Aug 2016, leif wrote: > >> Apparently log() behaves differently depending on whether it is called >> with Sage Integers or Python ints. (Not sure whether the other integer >> literal also matters here.) >> >> (You should get the same in the Sage session when using 2r instead of 2, >> or Integer(2) instead of 2 in the Python file.) > > Tested with 2r on Sage session, makes no difference. Hmmm, does Posets.BooleanLattice() care whether you pass an int or an Integer? (I.e., does the return type of its methods change?) -leif -- 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: Comparison and logarithm on .py vs. interactive
Jori Mäntysalo wrote: > sage: def foo(): > .: from sage.combinat.posets.poset_examples import Posets > .: from sage.misc.functional import log > .: P = Posets.BooleanLattice(3); n = P.cardinality(); s = > P._hasse_diagram.size() > .: if 2*s > n*log(n, 2): print "True" > .: > sage: foo() > sage: > > So, in this case the comparison is False. Now when I add exactly same > function on end of lattices.py and compile I got > > sage: sage.combinat.posets.lattices.foo() > True > sage: > > What's wrong? Somehow comparison and logaritms don't mix (again). Apparently log() behaves differently depending on whether it is called with Sage Integers or Python ints. (Not sure whether the other integer literal also matters here.) (You should get the same in the Sage session when using 2r instead of 2, or Integer(2) instead of 2 in the Python file.) -leif > > * * * > > Is there a function to get 2-based logarithm of integer in Sage? In > Python 3.3 there is, but we use Python 2.x. > -- 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: [Yet again] Sage's R vs system's R
kcrisman wrote: > > I think maybe even a better distinction than "sage-the-distro" is to > call it "SageMath, the Application". As far as users of the > application are concerned I agree the it should have the goal of being > a general purpose stack of mathematics software. For short I'll call > the application/distribution SageMath in (camel-case) and the Python > package "sage" since that's what the actual package is called. > > But treating that larger software stack, and the `sage` Python package > as one in the same makes development on the latter more difficult, and > probably ultimately the former as well. For example--continuing with > R as the test particle--say I'm a SageMath user who makes heavy use of > R for my statistics, and like being able to use R with sage. What > happens when a critical bug is fixed in R, and a new patch release > comes out (something Sage, by the way, doesn't even have but should). > How do I get that patch release? Well I have to wait for a new > version of sage (the package, and everything else that comes with it). > That might include a bunch of other new dependencies that I didn't > really think I needed. Possibly even API breakage elsewhere (though > fortunately sage itself is normally pretty good about that). > > > Yes, I agree that is a very significant issue and of course has been for > some time (with respect to many, many packages, I couldn't even list > them all for you). ... which was less of a problem with our "legacy" spkgs, as you in many cases could simply install an older or a more recent version when available /somewhere/, or even easily create your own, just replacing the upstream version in the src/ folder. More or less just out of curiosity, did we ever upgrade R because of bugs in R (besides build/installation issues) R-thru-Sage users complained about? Closer on topic, is there urgent need to upgrade our current version of R? (The 'configure' bug I reported upstream May last year is by the way still in 3.3.1, although the patch I submitted is pretty trivial.) -leif -- 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: [Yet again] Sage's R vs system's R
William Stein wrote: > On Tue, Aug 23, 2016 at 10:45 PM, Erik Bray <erik.m.b...@gmail.com> wrote: >> I think almost any dependency that Sage-the-Python-package can work >> without should be considered "optional" insofar as installing Sage is >> concerned. I think it's fine for it to be a stadard part of >> Sage-the-Distribution. >> >> But this gets almost off-topic and in to my preference that Sage >> development make a stronger distinction between those two things. End >> of the day though, I should be able to install Sage-the-Python-package >> with as few dependencies as possible in order to use it to build >> applications and code directly on Sage. Whereas Sage-the-Distribution >> is more of an end-user thing (in fact I think the OS packaging would >> do well to make this distinction as well--have a minimal Sage that >> works, but doesn't necessarily support *all* features, plus a >> sage-full that is more of a metapackage including all possible >> dependencies. > > Huge +1. I strongly agree with all of the above. A matter of introducing more package "types" (such as "mandatory", "shipped by default", "installed by default" etc.), and changing mainly some (build, release and dist) scripts accordingly. (In addition, portions of the Sage library would of course have to get adapted as well, but that's more or less copy-pasting from what we already have, although we might improve the existing code -- including doctests -- to become more generic.) Erik, have you opened some ticket (or thread, wiki page) regarding that? (Sage "repackagers" will certainly be interested in such as well.) -leif P.S.: Alternatively using system-provided packages for optional or mandatory components (and improving the build system w.r.t. version requirements) is related, but can IMHO be addressed independently. './configure ... && make download && make' should just work as one would perhaps expect, namely making sure all prerequisites (depending on the configuration) are present (modulo things like e.g. Xcode of course, but in some cases we could create 'sudo apt-get install ...' scripts for example). -- 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: [Yet again] Sage's R vs system's R
kcrisman wrote: > > Make R optional? (Nothing in Sage depends on it, except for the > interface to it, including Rpy2.) > > Gosh, R has been standard for*ever*, practically, Hört sich nach Schwäbischem Dreiklang an. > and is often heavily > advertised as a good reason to use Sage. There are certainly many who > have been using them together (as mentioned, obviously nowhere near the > number of "pure" R users, but still we definitely get queries about this > regularly) Well, I guess the ratio of R-thru-Sage users to Sage users is as "negligible" as that to pure R users. ;-) I know of exactly /one/ person who reported errors concerning R because he was using (or trying to use) R; all others just had build issues (some also doctest failures) with R, and just because it was/is a standard package. > and of course optional=untested=broken all too often. While that's true to some extent, I'd say you confuse cause and effect here. If hardly anybody is interested in a package, it will presumably rotten with time, orthogonal to what its type is (except that build and test issues with /standard/ packages bug every developer and user, no matter whether anybody actually uses them). What happened to the role of an spkg maintainer by the way? > Take > the Maple or Mathematica interfaces and their on-again, off-again > nature... If I'm not mistaken, Sage never shipped Maple nor Mathematica, nor have there ever been optional packages of them, unfortunately. (So we had no influence on which version was used either, besides that most developers and buildbots simply couldn't test, not to mention develop further.) Also, Rpy wasn't invented by Sage, and is developed independently by others. > Is this only a Cygwin problem, or on other platforms? I > couldn't see anything about other problems on this thread. Wait and see. The prerequisites R removed from its tarball certainly won't be present on every system. We'd at least have to make them explicit prerequisites for building Sage(!) if we keep R standard, despite (my impression being) that only few people at all need Sage's R. -leif -- 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: [Yet again] Sage's R vs system's R
Emmanuel Charpentier wrote: > I agree that losing a standard package for failing to build it on one > particular target would be bad. > > From Trac#20523 <https://trac.sagemath.org/ticket/20523> : > > Replying to [comment:11 embray]: > On Cygwin I needed to `apt-cyg install liblzma-devel` (if you have > `apt-cyg`, otherwise use setup as normal). Without the `-devel` package > it doesn't install the import library, so `-llzma` doesn't work > (`-llzma.dll` should though). > > Okay. I just checked on my (Linux) system : xz is not installed in the > $(SAGE_ROOT) tree, probably because I have it installed at system level > and the build script detects that somehow. (BTW : it is an /optional/ > package. > > Therefore, what is needed is : > a. ensure that xz /and its development files/ are installed, either in > the system or in the Sage package) ; > b. that this is done /before/ the R installation begins ; and > c. that R installation /depends/ on xz being somehow available. > > This can be simplified, at the expense of making xz a /standard/ > package, just by ensuring that xz is installed /before/ R compilation. I'm all for making xz standard, although for different reason. > I have little idea on how to proceed, since the Sage build system is > still a (large) bit obscure to me. What I need is a way to check in the > Makefile that xz and its development files are available, install xz if > not (can an optional package be installed before the compilation of > standard packages is finished ?), and make the R compilation dependent > on this target. > > Any ideas or advice ? Checking whether xz libs and headers are available (in other words, whether Sage's xz package needs to get installed) belongs to Sage's top-level 'configure'. (A probably simpler but dumb way I don't really like is to act in xz's spkg-install like we do -- for historical reasons -- in e.g. iconv's: Do nothing in some cases. This would still require making xz standard of course.) We still would have to deal with other stuff R no longer includes, OTOH at least libpcre. (And standard packages must not depend on optional ones, just saying.) -leif -- 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: Iterators and KeyboardInterrupt
VulK wrote:
> Dear All,
> in a ticket (#21254) I recently created with Dylan Rupel I need to explore a
> (possibly) infinite n-regular tree in a breath-first search.
Breath-first search = Search & pray? ;-)
(Possibly infinite apnoea can't be healthy.)
> The way it is
> implemented right now is via iterators. I am writing to you to ask if there
> is a preferred way to deal with user interaction and KeyboardInterrupt.
>
> At the moment the init function of :class:`ClusterAlgebra` calls
> :meth:`reset_exploring_iterator` that creates an instance of :meth:`seeds` and
> stores it in an internal var ``_sd_iter``. The methods that need to explore
> the tree just call ``next`` on this iterator till they get the data they are
> looking for. This process is potentially never ending. For this reason the
> user may specify a maximum depth at which to stop.
>
> Since this iterator is computationally intense, it easy to imagine that
> users will tend to start searching but change their mind in mid computation
> and send an interrupt. This, unfortunately, leaves ``_sd_iter`` in a
> corrupted state and all future calls to it will result in a StopIteration.
>
> At the moment we have a warning in the docstring of each method accessing
> _sd_iter to explain that after sending a KeyboardInterrupt the user needs to
> call :meth:`reset_exploring_iterator`. Do you think we should instead catch
> the interrupt, reset the iterator and then raise it again like this?
>
>
> @@ -1999,12 +1999,17 @@ class ClusterAlgebra(Parent):
> sage: len(A.g_vectors_so_far())
> 14
> """
> -while self._explored_depth <= depth:
> -try:
> -seed = next(self._sd_iter)
> -self._explored_depth = seed.depth()
> -except StopIteration:
> -break
> +try:
> +while self._explored_depth <= depth:
> +try:
> +seed = next(self._sd_iter)
> +self._explored_depth = seed.depth()
> +except StopIteration:
> +break
> +except KeyboardInterrupt:
> +print("Got a KeyboardInterrupt, cleaning up before returning.")
> +self.reset_exploring_iterator()
> +raise KeyboardInterrupt
>
> The advantage of this is that the user does not have to remember an extra
> (unnatural?) step. The drawback is that he/she looses any customization that
> may have been made by a previous call to :meth:`reset_exploring_iterator`.
>
>
> On a related topic. In the situation just described, the next exploration
> will have to begin from the root of the tree resulting in a lot of wasted
> effort. Is there any way around this? Sending a node of the tree back to the
> iterator does not seem useful because of the breath-first search.
Well, one usually implements checkpoints for such things (continually
saving state to optionally resume later if interrupted).
-leif
--
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-combinat-devel] Re: Multiple versions of SageMath's documentation online
Nicolas M. Thiery wrote: > On Thu, Aug 11, 2016 at 10:46:08PM +0200, Samuel Lelièvre wrote: >>(SNIP) >>In addition, it seems that the version of the documentation at >>[10]combinat.sagemath.org/doc corresponds to SageMath 6.3 >>, while SageMath is now at 7.3. >>Combinat people, >>- is there a use for hosting SageMath's documentation at >> [11]combinat.sagemath.org/doc and should it be updated to 7.3? >>- does this version have extra stuff from the combinat queue? >>- who is in charge? > > - This documentation is compiled with an old Sage with the patches > from the legacy Sage-Combinat queue applied. > > - It was occasionally useful, as there are some thematic tutorials > that have not yet been integrated into Sage. > > - The documentation cannot be updated to 7.3, as the patches don't > apply anymore. > > - It was hosted in the user directory of > combi...@combinat.sagemath.org; Anne, Florent and myself have the > ssh keys for that account. Is public.gmane.org at all still up? Samuel pointed me to [1] just yesterday. (Gmane's web interface has meanwhile gone, will perhaps return if others take over; luckily NNTP is still there.) -leif [1] https://lars.ingebrigtsen.no/2016/07/28/the-end-of-gmane/ > I see that combinat.sagemath.org/doc is now redirected to the main > Sage documentation. Given the issues the old doc was causing with > google searches, I guess that's fair enough. > > Cheers, > Nicolas > -- > Nicolas M. Thiéry "Isil" <nthi...@users.sf.net> > http://Nicolas.Thiery.name/ -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at https://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/d/optout.
[sage-devel] Re: [Yet again] Sage's R vs system's R
Emmanuel Charpentier wrote:
> From Trac#20523 <https://trac.sagemath.org/ticket/20523> :
>
> Replying to [comment:9 tscrim]:
>> I get a failure trying to install this on Cygwin32 with
>> {{{
>> checking for lzma_version_number in -llzma... no
>> configure: error: "liblzma library and headers are required"
>> Error configuring R.
>> }}}
>> which is the same failure I had on #20190.
>
> From the R 3.3.0 release notes
> <https://cran.r-project.org/doc/manuals/r-release/NEWS.html> :
> :
>
> The previously included versions of zlib, bzip2, xz and PCRE have
> been removed, so suitable external (usually system) versions are
> required (see the ‘R Installation and Administration’ manual).
>
>
> So it's either :
>
> * add xz-tools (né lzma-utils) to the list of prerequisites for Sage
> (i. e. relying on system's liblzma) ;
> * adding xz-tools (at least the lzma library) to sage (cluttering it
> with yet one more library to maintain) ;
> * or relying on system's R through an interface that remains to be
> written...
>
>
> Pick your poison...
Make R optional? (Nothing in Sage depends on it, except for the
interface to it, including Rpy2.)
xz is already an /optional/ Sage package; we'd also need PCRE (or make
it a prerequisite, just for R). (I'd personally make xz standard
anyway, and recompress our upstream tarballs with it, probably even
dropping bzip2.)
In case we made R optional, we could re-include some stuff (such as
PCRE) into the "upstream" tarball as well; not sure if we should do so
if we keep R standard.
My 2ct,
-leif
--
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: Problem retrieving a (positively reviewed) ticket
Volker Braun wrote: > This should be fixed now Yep, the refs are back (also with git://). -leif > On Sunday, August 21, 2016 at 12:15:05 AM UTC+2, Emmanuel Charpentier wrote: > > I am finding myself unable to fetch the positively reviewed ticket > TRAC#21135 : > > charpent@asus16-ec:/usr/local/sage-7$ git trac checkout 21135 > Loading ticket #21135... > Checking out Trac #21135 remote branch public/21135 -> local branch > t/21135/public/21135... > Traceback (most recent call last): > ... > File > "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py", > line 263, in _run > raise GitError(result) > git_trac.git_error.GitError: git returned with non-zero exit code > (128) when executing "git fetch trac public/21135" > STDERR: fatal: Couldn't find remote ref public/21135 -- 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: Problem retrieving a (positively reviewed) ticket
Travis Scrimshaw wrote: > I can both confirm the problem and Leif's workaround works (although it > required deleting the previous fingerprint key in the known_hosts). The weird thing is that git ls-remote git://trac.sagemath.org/sage.git doesn't give any error, it just gives no refs at all. So presumably rather some misconfiguration of git-daemon caused by an update... -leif -- 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: Problem retrieving a (positively reviewed) ticket
Dima Pasechnik wrote: > in syslog on trac I see something I cannot make sense of: here is a > connection from Ghent (Jeroen't machine, according to IP), although > there are more from other places: > > ug 21 07:39:25 trac git-daemon[27274]: Connection from > 157.193.230.60:46723Aug 21 07:39:25 trac git-daemon[27274]: Extended > attributes (24 bytes) exist
[sage-devel] Re: Problem retrieving a (positively reviewed) ticket
Paul Masson wrote: > Getting the same error for https://trac.sagemath.org/ticket/21299 Works for me as well (with plain git). Did you perhaps try while Dima was rebooting trac? (I think git.sagemath.org is the same machine, although I'm not sure.) -leif -- 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: [Yet again] Sage's R vs system's R
Jean-Pierre Flori wrote: > On Saturday, August 20, 2016 at 9:15:23 PM UTC+2, Emmanuel Charpentier > wrote: > Le samedi 20 août 2016 19:46:45 UTC+2, Jean-Pierre Flori a écrit : > On Saturday, August 20, 2016 at 7:44:15 PM UTC+2, Jean-Pierre > Flori wrote: > On Saturday, August 20, 2016 at 7:05:27 PM UTC+2, leif wrote: > > Emmanuel Charpentier wrote: > > While trying my hand > <https://trac.sagemath.org/ticket/20523 > <https://trac.sagemath.org/ticket/20523>> at porting > > R 3.3.1 to Sage (needs_review, by the way), I found > this in the > > current R Installation and Administration manual > > > > <https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Cygwin > > <https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Cygwin>> > : > > > >> C.8 Cygwin > >> > >> The 32-bit version has never worked well enough to > pass R’s make > > check, and residual support from > >> earlier experiments was removed in R 3.3.0. > > I wonder what the residual support was... > > >> > >> The 64-bit version is completely unsupported. > > I concur, but that was for bad reasons, or let's be fair, > one could say the lack of manpower maybe? > > > > > Maybe we should consider to have an interface to > system's R rather than > > our own version (and therefore make it an optional > package) > > +1 for making it an optional package. (It's by the way > not what I'd > call a small package, and also takes some time to build.) > > > > The Cygwin developers certainly have to say something > regarding support > as a standard package. (I don't think it would make > sense to upgrade > Sage's R version *and* keep it a standard package if it > does no longer > build on Cygwin. We could presumably still keep Rpy and > let it use the > system version of R, also on Windoze, if present and > suited.) g > > It's not my impression that The R folk really supported any > version of Cygwin recently. > I even got bashed out when proposing a simple and > non-intrusive patch for Cygwin64. > The point is that it seems hopeless to push patches upstream > which is a very bad point. > gwthat hard at all, one just needs a setup and a very little > bit of good will: > ftp://cygwin.com/pub/cygwin/x86_64/release/R/ > <ftp://cygwin.com/pub/cygwin/x86_64/release/R/> > So yes R still builds on Cygwin32/64. > > And frankly the set of patches shipped by Cygwin is really small... > > > Did you try to use the cygwin tarball as a source for Sage's R version ? > > BTW : could it be acceptable to have multiple tarballs as a source > for R on different platforms ? Or different set of patches ? > > That would be complicated. > > Another alternative : can the spkg-install script use only certain > patches (as a function of the platform he's running on) ? In that > case, a diff between the original tarball and the Cygwin-patced > tarball could be applied if and only if one is installing on cygwin. > > Very easy, I can try to do it. > > But the main point is that the Cygwyn's folk R patches only modify the > build system behavior when run on Cygwin. > If you apply the patches and build on Linux it would make no differences. Well, then if the Cygwin folks keep maintaining it, we could simply "import" their patch(es), not (significantly) upgrading R before they do. I'd still like R being an /optional/ package though... ;-) -leif > What do you think ? I do not understand the Sage build system well > enough to understand if this is possible, much less how... I need > your advice... > > > One would need to make a diplomatic move toward R folk. > > > I doubt it : the set of Sage's R users is probably fairly small > compared to the number of R users >
[sage-devel] Re: Problem retrieving a (positively reviewed) ticket
Emmanuel Charpentier wrote:
> I am finding myself unable to fetch the positively reviewed ticket
> TRAC#21135 :
>
> charpent@asus16-ec:/usr/local/sage-7$ git trac checkout 21135
> Loading ticket #21135...
> Checking out Trac #21135 remote branch public/21135 -> local branch
> t/21135/public/21135...
> Traceback (most recent call last):
> File "/usr/local/bin/git-trac", line 18, in
> cmdline.launch()
> File "/home/charpent/Dev/git-trac-command/git_trac/cmdline.py", line
> 215, in launch
> app.checkout(args.ticket_or_branch, args.branch_name)
> File "/home/charpent/Dev/git-trac-command/git_trac/app.py", line 116,
> in checkout
> self._checkout_ticket(int(ticket_or_branch), branch_name)
> File "/home/charpent/Dev/git-trac-command/git_trac/app.py", line 144,
> in _checkout_ticket
> self.repo.checkout_new_branch(ticket.branch, branch)
> File "/home/charpent/Dev/git-trac-command/git_trac/git_repository.py",
> line 136, in checkout_new_branch
> self.git.fetch('trac', remote)
> File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
> line 341, in meth
> return self.execute(git_cmd, *args, **kwds)
> File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
> line 328, in execute
> popen_stderr=subprocess.PIPE)
> File "/home/charpent/Dev/git-trac-command/git_trac/git_interface.py",
> line 263, in _run
> raise GitError(result)
> git_trac.git_error.GitError: git returned with non-zero exit code (128)
> when executing "git fetch trac public/21135"
> STDERR: fatal: Couldn't find remote ref public/21135
>
> I do not understand this error. This never happened to me before.
>
> Ideas ?
No. Works for me:
$ git fetch -v trac public/21135 && echo OK
remote: Counting objects: 2875, done.
remote: Compressing objects: 100% (1133/1133), done.
Receiving objects: 100% (2088/2088), 366.72 KiB, done.
remote: Total 2088 (delta 1770), reused 1219 (delta 943)
Resolving deltas: 100% (1770/1770), completed with 409 local objects.
>From trac.sagemath.org:sage
* branchpublic/21135 -> FETCH_HEAD
OK
And you can see the remote ref is there:
https://git.sagemath.org/sage.git/log/?h=public/21135
Did you perhaps bork your remote 'trac'?
-leif
--
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: [Yet again] Sage's R vs system's R
Emmanuel Charpentier wrote: > While trying my hand <https://trac.sagemath.org/ticket/20523> at porting > R 3.3.1 to Sage (needs_review, by the way), I found this in the > current R Installation and Administration manual > <https://cran.r-project.org/doc/manuals/r-release/R-admin.html#Cygwin> : > >> C.8 Cygwin >> >> The 32-bit version has never worked well enough to pass R’s make > check, and residual support from >> earlier experiments was removed in R 3.3.0. >> >> The 64-bit version is completely unsupported. > > Maybe we should consider to have an interface to system's R rather than > our own version (and therefore make it an optional package) +1 for making it an optional package. (It's by the way not what I'd call a small package, and also takes some time to build.) The Cygwin developers certainly have to say something regarding support as a standard package. (I don't think it would make sense to upgrade Sage's R version *and* keep it a standard package if it does no longer build on Cygwin. We could presumably still keep Rpy and let it use the system version of R, also on Windoze, if present and suited.) -leif > It would be more difficult (but not impossible) to offer the same kind > of access to an external R as to a tightly-knit R. I'm thinking > graphics, notebook(s) integration, etc... > > OTOH, the existence of a good R interface (Rpy2) could make things > easier. The largest problem that one can forecast is, of course, > backwards compatibility in existing programs. > > > On the third hand, what can be said if the future of a native Windows > port of Sage, which could do without Cygwin monkeying ? I understand > that a) it's not really easy and b) some significant advances have been > made recently... > > Ideas, suggestions, etc ? -- 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.
