[sage-devel] Re: review requests

Hi Martin, I would review (the simple) 15672. Since it is my first review in Sagemath, I have to find out how to review first and how to check, that your patch is indeed correct. Jakob Am Montag, 4. August 2014 19:26:44 UTC+2 schrieb Martin Albrecht: > > Hi all, > > anyone up for reviewing:

Re: [sage-devel] Re: review requests

ow if > you > need any help. > > Cheers, > Martin > > On Wednesday 06 Aug 2014 01:12:55 Jakob Kroeker wrote: > > Hi Martin, > > > > > > I would review (the simple) 15672. > > Since it is my first review in Sagemath, I have to find out how to

[sage-devel] patchbot/build issues ?

Hello, when I try to run *patchbot* on machine 'A' I observe several errors, e.g. Getting ticket list... fatal: Invalid revision range 389fbf0cd408302c14635d7979f39297c1f6a2b2..patchbot/base Resolving sage.math.washington.edu... 128.208.160.197 Connecting to sage.math.washington.edu

[sage-devel] failing doctest for sage/structure/sage_object.pyx

Hello, a doctest fails on an system I'm interested in (I want to run patchbot on that system) File "src/sage/structure/sage_object.pyx", line 1411, in sage.structure.sage_object.unpickle_allFailed example: sage.structure.sage_object.unpickle_all() # (4s on sage.math, 2011

Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx

y strange one. > > And, by the way, what is the system you are interested in? Might be > useful to know for debugging... > > Vincent > > 2014-08-26 22:06 UTC+02:00, Jakob Kroeker >: > > > > Hello, > > > > a doctest fails on an system I'm

Re: [sage-devel] failing doctest for sage/structure/sage_object.pyx

octest under strace -ff and > see which processes are being run. > > > On Tuesday, August 26, 2014 11:44:47 PM UTC+1, Jakob Kroeker wrote: >> >> OS: >> openSUSE 12.3 (x86_64) >> VERSION = 12.3 >> CODENAME = Dartmouth >> >> >tar --version >&

[sage-devel] Re: review requests

Hi Martin, I will even review the 16585 or at least major parts of it, but i'm currently on vacation so it will not happen before the 15th september. Jakob Am Montag, 4. August 2014 19:26:44 UTC+2 schrieb Martin Albrecht: > > Hi all, > > anyone up for reviewing: > > 1) > > http://trac.s

[sage-devel] upgrade to singular 4.0 in sage?

Hello, in the meantime the fourth patch of Singular release 4.0 is available at http://www.mathematik.uni-kl.de/ftp/pub/Math/Singular/SOURCES/4-0-0/ (please ignore the offered 3.1.7 version on their homepage; I don't really know why they promote v3.7) Among the re-factoring v4.0 contains a lot

Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)

> > Bill Hart:: > ... There is a lack of documentation on what algorithms are implemented, > what their complexities are, or references. Some projects are not > threadsafe. Testing is lacking and quite a bit of stuff just doesn't work > and never did. And there is a general lack of credit given

Re: [sage-devel] Re: [sage-release] You don't really think that Sage has failed, do you? (a comment about it)

and GAP I would go with GAP. Jakob Am Freitag, 29. August 2014 16:30:43 UTC+2 schrieb Bill Hart: > > > > On Friday, 29 August 2014 15:12:05 UTC+2, Jakob Kroeker wrote: >> >> Bill Hart:: >>> ... There is a lack of documentation on what algorithms are implemented,

[sage-devel] Re: sparse linear algebra in sage

A long time ago I did numerical eigenvalue computations using SLEPC ( see http://www.grycap.upv.es/slepc/ ) There is also Trilinos/Anazazi (I did't use it) But I was only interested in a part of the spectrum (smallest /largest), Do you need to compute all eigenvalues? Maybe (as William said) you

[sage-devel] patchbot: do not ask interactive questions by default?

Hello, I'm running several patchbots. Sometimes I get Failing tests in your install: TestsFailed. Continue anyways? [y/N] 1. I find that this question should not be asked and the default should be 'No' 2. If the patchbot says 'Failing tests in your install..', which branch is meant? ' ('

[sage-devel] try to rebuild sage documentation once in case of an error?

Sometimes the build of the documentation fails with Error building the documentation. Note: incremental documentation builds sometimes cause spurious error messages. To be certain that these are real errors, run "make doc-clean" first and try again. Now I'm questioning if it is a good idea to d

Re: [sage-devel] patchbot: do not ask interactive questions by default?

#x27;No' >> > Agreed. > Should I open a ticket or are no further actions required? Jakob Am Dienstag, 16. September 2014 23:24:55 UTC+2 schrieb Robert Bradshaw: > > On Tue, Sep 16, 2014 at 7:07 AM, Jakob Kroeker > wrote: > >> Hello, >> >> >> I'm

[sage-devel] weird(?) patchbot build failures for patchbot 'groebner'

It seems that my patchbot 'groebner' hits (at least in the past) too many build failures, while other patchbots succeeds for the same tickets. So I suspect something is/was fishy. A typical log did look like http://patchbot.sagemath.org/log/16878/debian/wheezy/sid/x86_64/3.8.0-29-generic/groe

[sage-devel] Re: weird(?) patchbot build failures for patchbot 'groebner'

ized/sage/calculus/riemann.c:348:31: fatal error: > numpy/arrayobject.h: No such file or directory > > How are the directories /tmp/tmpUOouim-sage-git-temp and > /home/jkroeker/Projects/sage-patchbot supposed to be related, is there a > symlink or something? > > > > O

[sage-devel] Re: Tell me how the design of the Poset class is not flawed

Dima wrote > this is one of the realities of the research software - one has to do new > things > in academia (e.g. one cannot tell an MSc student that his project will be > to fix > Sage bugs - he has to do something new!). > But how to deal with this problem? I predict that if the Sage

Re: [sage-devel] Re: Tell me how the design of the Poset class is not flawed

I looked at the ticket #12536 and came to the following conclusion: It is likely (I do not understand much about the changes and the #14019 issue) that indeed 'relabel()' is based on existing code, which is probably buggy, so the bug #14019 is only a subsequent error. At the same time I concl

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

> > The fact that it is possible to do it in principle is the important bit, > Mandatory, but of course not sufficient. Just recall the recently discovered bash shell bug which was lurking in the source for more than 10 years. The important bit is that one can go and check. > I'm doing this:

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

was fun to read that the day after reading that M-ma gets some > small integer determinants wrong! > > John > > On 24 October 2014 17:16, Jori Mantysalo > > wrote: > > On Fri, 24 Oct 2014, Jakob Kroeker wrote: > > > >> Does Sage warn somehow the user

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

> > "Can We Trust Computer Algebra Systems?" > If anyone bothers of my opinion: no. Jakob Am Freitag, 24. Oktober 2014 18:45:39 UTC+2 schrieb Jakob Kroeker: > > > It was fun to read that the day after reading that M-ma gets some >> small integer determinants

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

got fixed. There is work in progress by Adi Popescu and Anne Frühbis-Krueger) ) Jakob Am Freitag, 24. Oktober 2014 19:01:58 UTC+2 schrieb William: > > On Fri, Oct 24, 2014 at 9:16 AM, Jori Mantysalo > wrote: > > On Fri, 24 Oct 2014, Jakob Kroeker wrote: > > > >>

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

h, 29. Oktober 2014 11:28:01 UTC+1 schrieb Jeroen Demeyer: > > On 2014-10-24 18:09, Jakob Kroeker wrote: > > I suggest Sage to pay QA staff for actively hunting bugs. > With which money? > > -- You received this message because you are subscribed to the Google Groups &quo

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

> > Factoring is the hard one, there have been lots of factoring bugs in > Sage coming from Singular (and there still is #17251 in Singular-3-1-7). > And as correctly noticed, the #17251 is not in Singular 4.0.1 Martin Lee, the former coauthor of 'Singular/factory' is meanwhile very familiar w

Re: [sage-devel] Re: When/by who/how was the "code of conduct" initiated ?

Am Mittwoch, 26. November 2014 14:47:29 UTC+1 schrieb Viviane Pons: I would be in favour of this: having "guidelines" and not an enforced code. > ++ ...that would require another voting which invalidates the previous one... Jakob -- You received this message because you are subscribed to

Re: [sage-devel] Re: proposed amendment to code of conduct

As already mentioned by others, the bad thing (at least from my point of view) is that the 'code of conduct' splits the community. To reduce the dissonance among us we could agree on something with broader support. Otherwise I hope that this discussion will end at some point, and I will try to f

[sage-devel] slow doctest number_field_element.pyx on my machine

on my machine (fedora 23, 32 Bit) the test sage -t --long --warn-long 127.3 src/sage/rings/number_field/ number_field_element.pyx takes 1397.8 seconds (10 times more) And thus the patchbot test run for sage 7.4.beta6 fails I have aIntel(R) Core(TM)2 Duo CPU E8200 @ 2.66GHz ; it shou

Re: [sage-devel] Re: slow doctest number_field_element.pyx on my machine

: > > I've seen that time out often on the buildbot, too. Please, somebody > > replace the test in there by something more reasonable. > > Just to be sure, are you confident that this is not pointing some issue ? > > Ciao, > Thierry > > > > >

[sage-devel] a 7(!) year old (Singular) overflow issue still holds

https://trac.sagemath.org/ticket/6472 even for recent singular upgrade https://trac.sagemath.org/ticket/17254 and it was not(?) reported to upstream... -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this grou

[sage-devel] Re: slow doctest number_field_element.pyx on my machine

sday, October 4, 2016 at 9:53:13 PM UTC+2, Jakob Kroeker wrote: >> >> on my machine (fedora 23, 32 Bit) the test >> >> sage -t --long --warn-long 127.3 src/sage/rings/number_field/ >> number_field_element.pyx >> >> >> >> takes 1397.8 secon

[sage-devel] Re: Testing corner cases

@Jori Mäntysalo So you have a mind of a tester? That's good to know. In general I think it would be good to have a random testing framework together with a testbot in sage. I'm working on that in Singular and Macaulay2 and already catche

[sage-devel] Re: Singular "share" files

Will we have to repackage Singular each time we want to upgrade/get the recent patched release? I think we should stop repackaging Singular. If there are some general issues with packaging, we should solve them upstream. Jakob Am Mittwoch, 2. November 2016 16:19:47 UTC+1 schrieb Jean-Pierre

Re: [sage-devel] Re: Testing corner cases

ey are improperly coded. But probably you should not do that, you may get unpleasantly surprised... Am Montag, 31. Oktober 2016 10:31:56 UTC+1 schrieb Jori Mäntysalo: > > On Mon, 31 Oct 2016, Jakob Kroeker wrote: > > > So you have a mind of a tester? That's good to know.

[sage-devel] Re: GSoC 2017 kickoff

I have an idea for a project but no time this year for mentoring (maybe next one) The idea boils down to develop a random testing framework to find (in some way minimal) failing examples (wrong answers or crashes) using bots (like running patchbot to test sage). So if someone is willing, able

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

as far as I know, limiting to 16 bit exponents for _input_ was introduced to prevent undetected overflows; it must be one of the tickets https://www.singular.uni-kl.de:8005/trac/ticket/630 https://www.singular.uni-kl.de:8005/trac/ticket/631 https://www.singular.uni-kl.de:8005/trac/ticket/696 http

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

>If someone who knows what they are talking about [...] to give a precise answer to the question on https://ask.sagemath.org/

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

> > By default, Singular uses 16 bit exponents. But it is perfectly capable of > working with exponents up to 64 bits. That will be slower of course. > How to change this? Is it runtime or compile-time? Is it transparent for overflow detection? I guess it isn't easy for Sage to change the rele

[sage-devel] Re: Timeouts on patchbots

> > It is my subjective observation that timeouts on patchbots have become > more > frequent. For instance, for ticket > https://patchbot.sagemath.org/ticket/22340/ > two patchbots failed due to timeout, > If I recall correctly, I did hit similar issues when testing sage. Parallelis

[sage-devel] Re: imaginary unit I is smaller than 1

In my opinion not this only particular case but the current bool() design in sage is a tremendous failure. This was already discussed on sage-devel several times. Here is one of that threads: https://groups.google.com/d/msg/sage-devel/vNxnHSeRBW4/UkaBOPGYT0QJ Jakob Am Sonntag, 19. Februar 2017

[sage-devel] Re: a 7(!) year old (Singular) overflow issue still holds

th different exponent sizes than 16 bit? Am Montag, 13. Februar 2017 21:40:03 UTC+1 schrieb Bill Hart: > > I can only answer one of your questions. > > On Saturday, 11 February 2017 17:16:29 UTC+1, Jakob Kroeker wrote: >> >> By default, Singular uses 16 bit exponents. But it is pe

[sage-devel] Re: The end of stopgaps

At least a user could look at the list of bugs silently producing wrong answers: http://trac.sagemath.org/report/79 I updated the list by manually looking at open tickets from #1 to #13345 and adding a stopgap marker 'todo' if required. Remaining task (I will do that): check open tickets #133

Re: [sage-devel] Re: Is the glass half-full or half-empty ? Pick a standard.

> > I think backward compatibility is a strong argument to keep returning True. > well, there is also the option to deprecate the is_connected() function for the empty graph and then change the behaviour after a year. By the way, what about defining that the empty graph is connected AND discon

Re: [sage-devel] Should RR coerce into RIF?

the ticket https://trac.sagemath.org/ticket/15114 seems orphan now... Am Donnerstag, 20. März 2014 12:58:30 UTC+1 schrieb Marco Streng: > > Thanks for all the replies. It seems that everybody here agrees to > disallow coercions from RR to RIF, which is all that ticket > http://trac.sagemath.org/

[sage-devel] classifying trac tickets as silently incorrect results

Hello, today in my spare free time I continued looking for tickets with describes issues where sage silently returns a wrong answer and stopped at https://trac.sagemath.org/ticket/15325 For the following tickets I'm not sure, if they should be classified as 'silently incorrect result' or not

[sage-devel] Re: classifying trac tickets as silently incorrect results

> > Please don't. That field is suppose to be used for tickets which implement > the stopgap when it is applicable Unfortunately stopgaps for all the silent wrong results will hardly be accepted. I already experienced heavy opposition as I created some and was not able to create them in full

Re: [sage-devel] Re: classifying trac tickets as silently incorrect results

Sonntag, 10. Juli 2016 00:32:57 UTC+2 schrieb vdelecroix: > > On 09/07/16 18:17, Jakob Kroeker wrote: > > > >> > >> Please don't. That field is suppose to be used for tickets which > implement > >> the stopgap when it is applicable > > >

Re: [sage-devel] Re: Place for "internal" documentation of a class

> > * Document the why, not the how > Does the 'why' implicate documentation for an abstract description of the implementation design (if not obvious) and the (reference to) underlying algorithms? I just looked at the sage review checklist and did not find and advice to check for appropriate

Re: [sage-devel] Re: Place for "internal" documentation of a class

f course we cannot put everything on the checklist. In case it turns out mandatory to put on the checklist that the people should breath, I probably would give up and move away ;-) Am Montag, 5. Januar 2015 16:00:54 UTC+1 schrieb Volker Braun: > > On Monday, January 5, 2015 3:15:07 PM U

Re: [sage-devel] Re: Place for "internal" documentation of a class

urces. And because in history predictors or carriers of bad news were burned, I will shut up now on that topic. Jakob Am Montag, 5. Januar 2015 22:41:32 UTC+1 schrieb Volker Braun: > > On Monday, January 5, 2015 5:45:21 PM UTC+1, Jakob Kroeker wrote: > >> class diagrams, sta

Re: [sage-devel] "Can We Trust Computer Algebra Systems?"

I wrote > I'm aware of this("stopgame" framework); it is a good start. AFAIK it does > not support 'stopgame' at function level, only at package level. > This statement was of course completely wrong. @William why did you not blame me for that? You can see 52 tickets involving it here: > >

[sage-devel] how to explicitly recompile the python part of sage (no pkgs)

Hello, I'm currently working on ticket #17254 and sometimes I introduce issues such that even if I fix them after a failed build trial, the relevant part gets not rebuild and I'm only be able to recover with a `make distclean` question: - how to recompile only the python and cython part (no

[sage-devel] singular 4.0.1 upgrade: cython compile for 'plural' peeks wrong lib

I'm getting a strange cython behaviour when compiling u/jakobkroeker/ticket.17254.squashed , cython tries to pick -lsingular instead of -lSingular when compiling plur

[sage-devel] Re: singular 4.0.1 upgrade: cython compile for 'plural' peeks wrong lib

ar 2015 13:38:34 UTC+1 schrieb Jakob Kroeker: > > I'm getting a strange cython behaviour when compiling > u/jakobkroeker/ticket.17254.squashed , > <http://git.sagemath.org/sage.git/diff/?id2=d27f8497dcd19d70ec08155888e6fec9c74b839a&id=6384b9b8d22905e7dcc72b84df33effae9

[sage-devel] Re: how to explicitly recompile the python part of sage (no pkgs)

ar 2015 16:15:36 UTC+1 schrieb Volker Braun: > > On Monday, February 2, 2015 at 10:13:39 AM UTC-5, Jakob Kroeker wrote: >> >> - how to recompile only the python and cython part (no pkgs) ? >> > > sage -b > > >> - in case that sage is in a broken state, h

Re: [sage-devel] Is CMake OK for a standard spkg?

>Anyway, as mentioned before, according to this thread: > http://groups.google.com/group/sage-devel/browse_thread/thread/e91a204a2902afd/ccbdaa4792872282?lnk=gst&q=Heads+up#ccbdaa4792872282 >singular is migrating to CMake. For good or bad, Singular did not migrate to CMake. There was too muc

[sage-devel] sage trac hangs when posting a comment with specific wording

Recently I hit a very weird issue on sage trac: It was for me not possible to post a comment with a specific wording, (see attached ASCII file), neither did the trac preview work: it just hangs. When I change the text to some extent, the issue goes away It does not matter on which ticket one t

[sage-devel] Re: open blockers

> #17679 would need rebasing. done > Also the proposed stopgaps are probably a bit too broad... is the testsuite passing with factorization disabled? I'm new to sage; will the stopgaps break the testsuite? (checking...) > Also the proposed stopgaps are probably a bit too broad Factory is not

Re: [sage-devel] Re: open blockers

> Is there bugs where user gets wrong results? Yes. Am Freitag, 13. Februar 2015 12:09:03 UTC+1 schrieb Jori Mantysalo: > > On Fri, 13 Feb 2015, Jakob Kroeker wrote: > > > Factory is notoriusly buggy; it improved over time, but it is still > > buggy. There are more

Re: [sage-devel] Re: open blockers

Am Freitag, 13. Februar 2015 12:09:03 UTC+1 schrieb Jori Mantysalo: > > On Fri, 13 Feb 2015, Jakob Kroeker wrote: > > > Factory is notoriusly buggy; it improved over time, but it is still > > buggy. There are more than 20 bugs in factory which are fixed in 4.0.1 > >

[sage-devel] Re: open blockers

ets to needs review after working more on it? > > Maybe we should add a boolean flag factorize(proof=None) and optionally > check the result depending on the base ring, isn't that much cheaper than > computing the factorization anyways? > > > On Friday, February 13, 2015

[sage-devel] Re: open blockers

n't that much cheaper than > computing the factorization anyways? > > > On Friday, February 13, 2015 at 12:02:06 PM UTC+1, Jakob Kroeker wrote: >> >> Factory is notoriusly buggy; it improved over time, but it is still >> buggy. There are more than 20 bugs in factory w

[sage-devel] Re: Several bugs

>If you want >to use different term orderings or a localisation, you should construct >a "multivariate polynomial ring with a single variable" (I know, this it >sounds silly and is not obvious). @Simon As state above, the ordering is _silently_ ignored. Thus it is a bug from my point of view.

Re: [sage-devel] Re: should bool(x > 0) be False or an exception?

>I changed the code to return an exception if the truth value is unknown and ran `sage -testall`. Did you upload the patch to somewhere? Where this change has to be made? > I might be willing to fix these tests when I have time. It seems that nothing happens for more than a year, so maybe som

[sage-devel] running multiple patchbots on a cluster

Hello, I just tried to run several patchbots in local tmp folder on different machines and something did not work as expected, see http://patchbot.sagemath.org/ticket/7298/ ;-) What went wrong? Jakob -- You received this message because you are subscribed to the Google Groups "sage-devel"

[sage-devel] Re: running multiple patchbots on a cluster

298 in a loop. any idea why? will a 'make disctlean' help? Jakob Am Samstag, 7. März 2015 07:45:16 UTC+1 schrieb Ralf Stephan: > > On Friday, March 6, 2015 at 9:06:41 PM UTC+1, Jakob Kroeker wrote: >> >> Hello, >> >> I just tried to run several patchbots in

[sage-devel] Re: running multiple patchbots on a cluster

> Before I even look closer: are you using git master of patchbot? the advertised one. I must admit that for me it worked best to select the tickets by hand http://patchbot.sagemath.org/?machine=Ubuntu:12.04:x86_64:3.8.0-29-generic:groebner&status=needs_review ;-) In case a patchbot state was su

[sage-devel] Re: arando patchbot spam

Ticket 15056 is also interesting - try run it explicitly and one will get: Switched to branch 'patchbot/base' Already on 'patchbot/base' fatal: 'None' does not appear to be a git repository fatal: The remote end hung up unexpectedly Is that connected to the fact that in ticket 15056 the 'git_bran

[sage-devel] Re: dimension() broken for ideals?

> > It is definitely a bug in the dimension method. > could you open a ticket and post the link here? Am Sonntag, 3. Mai 2015 15:25:13 UTC+2 schrieb mmarco: > > It is definitely a bug in the dimension method. > > If singular can handle the ring, sage asks singular to compute the > dimension, wh

Re: [sage-devel] Re: max(sin(x),cos(x)) = sin(x)

>We cannot be satisfied with returning wrong answers in the meantime, however. I support Nathann's position. > Returning 'Unknown' instead of nonsense would be a good first step. I disagree. That Unknown class/object should not be comparable/convertible to True/False, especially if not

Re: [sage-devel] Re: max(sin(x),cos(x)) = sin(x)

h, 13. Mai 2015 13:40:37 UTC+2 schrieb Samuel Lelievre: > > > > 2015-05-12 21:03:27 UTC+2, Jakob Kroeker: > > > > > Its just behaving as specified, False means "cannot decide" > > > I find, this was a pretty unfortunate specification. > > I thi

Re: [sage-devel] Re: SIngular version

Hello, I think I can finish the update to Singular 4.0.2 The problem is that I'm currently busy with writing a Macaulay2 package (together with H-C v. Bothmer) for the MEGA 2015 conference in Italy (June 15-19, 2015). I'm also kind of involved in releasing Macaulay2 version 1.8 So I can't pr

Re: [sage-devel] please review #18320

>In either case, this isn't a good solution to the long-standing patches-arent- >being-reviewed-in-a-timely- >manner problem to which I have no solution except >yet another attempt at an IRC "sage hour" a week where we all review/triage >stuff. What is about occasional time-limited (to preven

[sage-devel] Re: Online "Bug report" form: is it dead?

where do the sagenb reports end? here? https://docs.google.com/spreadsheets/d/1GF_-hM-3DP0YcViieBWIhsign3JHegTlj32cs8ymPZE/pub Am Freitag, 5. Juni 2015 12:52:06 UTC+2 schrieb Nathann Cohen: > > Hello everybody, > > It is apparently possible to report bugs through an online form on > Sage's

[sage-devel] Re: Various packages no longer exist

> > kash and macaulay2 are hugely obsolete > which is the last commit with the interface to macaulay2? Am Donnerstag, 27. August 2015 22:21:42 UTC+2 schrieb Dima Pasechnik: > > > > On Thursday, 27 August 2015 12:48:03 UTC-7, Jeroen Demeyer wrote: >> >> Some more packages are documented in Sage b