Re: [sage-devel] Re: lcalc code quality
On Apr 2, 2011, at 06:20 , Bill Hart wrote: > > > On Mar 31, 8:41 pm, Jason Grout wrote: >> On 3/31/11 2:09 PM, kcrisman wrote: > >> +1 to everything you said. Also, I'd like to point out that since many >> upstream developers lurk on this and other Sage lists, our "colloquial" >> conversations actually are heard by many upstream developers. Even if a >> particular upstream developer is not subscribed, many other upstream >> developers see how we behave as a group and that will probably influence >> their opinion of Sage. > There's a fine line between critiquing/refereeing/improving code and > ridiculing it. 1++ -- Justin C. Walker, Curmudgeon at Large Director Institute for the Enhancement of the Director's Income --- Nobody knows the trouble I've been --- -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Unexpected failure on a test with znpoly
I've built Sage tons of time on OpenSolaris as a 32-bit application, and rarely had any problems for the last 6 months or so. In fact, I've built sage-4.7.alpha3 several times without issue. znpoly is a slightly unusual .spkg in Sage, in that it runs a minimal test suite irrespective of the setting of SAGE_CHECK. If SAGE_CHECK is set to "yes" then it runs a more comprehensive set of tests. But today with the sage-4.7.alpha3 I got a totally unexpected failure. gcc -g -g -fPIC -O3 -L. -I/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/include -I./include -DDEBUG -o test/support-DEBUG.o -c test/support.c gcc -g -o test/test src/array-DEBUG.o src/invert-DEBUG.o src/ks_support-DEBUG.o src/mulmid-DEBUG.o src/mulmid_ks-DEBUG.o src/misc-DEBUG.o src/mpn_mulmid-DEBUG.o src/mul-DEBUG.o src/mul_fft-DEBUG.o src/mul_fft_dft-DEBUG.o src/mul_ks-DEBUG.o src/nuss-DEBUG.o src/pack-DEBUG.o src/pmf-DEBUG.o src/pmfvec_fft-DEBUG.o src/tuning-DEBUG.o src/zn_mod-DEBUG.o test/test-DEBUG.o test/ref_mul-DEBUG.o test/invert-test-DEBUG.o test/pmfvec_fft-test-DEBUG.o test/mulmid_ks-test-DEBUG.o test/mpn_mulmid-test-DEBUG.o test/mul_fft-test-DEBUG.o test/mul_ks-test-DEBUG.o test/nuss-test-DEBUG.o test/pack-test-DEBUG.o test/support-DEBUG.o -L/export/home/drkirkby/newdocs/sage-4.7.alpha3/local/lib -lgmp -lm test/test -quick all mpn_smp_basecase()... ok mpn_smp_kara()... make[2]: *** [check] Segmentation Fault (core dumped) make[2]: Leaving directory `/export/home/drkirkby/newdocs/sage-4.7.alpha3/spkg/build/zn_poly-0.9.p5/src' Error running zn_poly's quick test suite (make check). real5m41.143s user1m8.034s sys 0m5.595s sage: An error occurred while installing zn_poly-0.9.p5 After I typed "make again" I see: Successfully installed zn_poly-0.9.p5 So for some unknown reason, znpoly has failed to pass the self-tests, when I've probably built it 100 times before and it passed each time. As usual, I checked the system log and see nothing to indicate the system had a problem like a memory error, disk error, lack of swap space etc. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Proposal to remove the spkg/base repository
On 04/ 3/11 05:39 AM, Dr. David Kirkby wrote: Now there is a repository for the root of Sage, so files like README.txt are now under revision control drkirkby@hawk:~/sage-4.7.alpha3$ hg status drkirkby@hawk:~/sage-4.7.alpha3$ John Palmieri has suggested that the spkg/base repository be removed. This seems a sensible idea to me. Just merge the file from that repository to the new one. Having lots of repositories just make life more complicated. What do others think? John's ticket for this is http://trac.sagemath.org/sage_trac/ticket/11073 -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Proposal to remove the spkg/base repository
Now there is a repository for the root of Sage, so files like README.txt are now under revision control drkirkby@hawk:~/sage-4.7.alpha3$ hg status drkirkby@hawk:~/sage-4.7.alpha3$ John Palmieri has suggested that the spkg/base repository be removed. This seems a sensible idea to me. Just merge the file from that repository to the new one. Having lots of repositories just make life more complicated. What do others think? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
On 04/ 2/11 11:47 PM, Jason Grout wrote: On 4/2/11 4:33 AM, Dr. David Kirkby wrote: With a slightly hacked version of 4.7.alpha3, I get the following doctest failures: ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 180: sage: s[:2] Expected: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture229'] Got: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture178'] ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 196: sage: s[:2]+s[2][:3]+s[3][:3] Expected: ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] Got: ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] ** I doubt these are anything to do with the fact R is not building (#9040) or the fact there's some initilisiion problems reguarding Pynac (#6). These look too much like "almost right" but not quite right. Anyone got any ideas? The texture numbers come from this code in texture.py: if id is None: global uniq_c uniq_c += 1 id = "texture%s" % uniq_c So just having differing texture numbers won't change the plot. The texturexxx names are just to uniquely identify the textures when writing out the file. Jason Thank you Jason. I just realised that the textture.py code is actually causing a seg fault: drkirkby@hawk:~/try/sage-4.7.alpha2$ ./sage -t ./devel/sage-main/sage/plot/plot3d/texture.py Detected SAGE64 flag Building Sage on Solaris in 64-bit mode sage -t "devel/sage-main/sage/plot/plot3d/texture.py" The doctested process was killed by signal 11 [28.8 s] -- The following tests failed: sage -t "devel/sage-main/sage/plot/plot3d/texture.py" # Killed/crashed Total time for all tests: 28.8 seconds so that probably explains why the texture numbers are not as in the doctest. I'll look at what's going on in textture.py first. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Specify patches and dependencies in description
Yup, this is a great idea. You were working on this during sage days 29, right? Any progress? -Keshav On Mar 24, 3:14 am, koffie wrote: > Since we have a highly configurable bug tracking system, why not add > some custom fields? > > http://trac.edgewall.org/wiki/TracTicketsCustomFields > > On Mar 22, 2:51 pm, Jason Grout wrote: > > > > > > > > > On 3/22/11 4:28 PM, Jeroen Demeyer wrote: > > > > I would obviously prefer that the patchbot also only looks at the ticket > > > description to force people not to use comments for this. > > > That sounds reasonable. +1. > > > Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Patch submitting procedures
Indeed. Mercurial's workflow is not really supposed to be carried out by sending patches to people (the encouraged behavior is to use `hg pull` from other people's repositories), so the default patch / export format only includes a subset of the total information so that it can be backwards compatible with ancient diff formats. Adding "[diff]\ngit = true" to your ~/.hgrc is really necessary in order to make your patches accurately reflect your changes (if using mq) or commits (if not). Besides binary files, this also exports information about file permission changes, for example. -Keshav On Mar 31, 4:00 pm, Ivan Andrus wrote: > On Mar 28, 2011, at 11:36 AM, Jeroen Demeyer wrote: > > > 2) Patches should be made using *hg export tip*, and not hg diff. > > Don't forget that you need to use --git if you have touched any binary files. > It may be best to add this to your .hgrc (I think this was mentioned in > another thread recently). > > -Ivan -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
On 4/2/11 4:20 PM, Francois Bissey wrote: > With a slightly hacked version of 4.7.alpha3, I get the following doctest > failures: > > ** > File > "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para > metric_surface.pyx", line 180: > sage: s[:2] > Expected: > ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', > 'texture229'] Got: > ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', > 'texture178'] > ** > File > "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para > metric_surface.pyx", line 196: > sage: s[:2]+s[2][:3]+s[3][:3] > Expected: > ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 > 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 > 44 43'] Got: > ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 > 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 > 44 43'] > ** > > > I doubt these are anything to do with the fact R is not building (#9040) or > the fact there's some initilisiion problems reguarding Pynac (#6). > These look too much like "almost right" but not quite right. > > Anyone got any ideas? I am reminded of some similar messages in roughly the same spot being due to an upgrade of matplotlib. So my gut feeling is something, possibly arch specific, in matplotlib. That's the stuff I remember: https://github.com/cschwan/sage-on-gentoo/issues/closed#issue/19 I'd still look in matplotlib. Good memory, but in this case, I'm pretty sure matplotlib isn't involved at all. This is entirely from custom Sage 3d plotting code. The issue you point out was a situation where we upgraded matplotlib (for 2d plotting), and the upgraded matplotlib had a different number of colors), IIRC. Thanks, Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
On 4/2/11 4:33 AM, Dr. David Kirkby wrote: With a slightly hacked version of 4.7.alpha3, I get the following doctest failures: ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 180: sage: s[:2] Expected: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture229'] Got: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture178'] ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 196: sage: s[:2]+s[2][:3]+s[3][:3] Expected: ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] Got: ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] ** I doubt these are anything to do with the fact R is not building (#9040) or the fact there's some initilisiion problems reguarding Pynac (#6). These look too much like "almost right" but not quite right. Anyone got any ideas? The texture numbers come from this code in texture.py: if id is None: global uniq_c uniq_c += 1 id = "texture%s" % uniq_c So just having differing texture numbers won't change the plot. The texturexxx names are just to uniquely identify the textures when writing out the file. Jason -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
On 2 April 2011 22:20, Francois Bissey wrote: >> With a slightly hacked version of 4.7.alpha3, I get the following doctest >> failures: >> >> ** >> File >> >> "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para >> metric_surface.pyx", line 180: >> sage: s[:2] >> Expected: >> ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', >> 'texture229'] Got: >> ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', >> 'texture178'] >> ** >> File >> >> "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para >> metric_surface.pyx", line 196: >> sage: s[:2]+s[2][:3]+s[3][:3] >> Expected: >> ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 >> 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 >> 44 43'] Got: >> ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 >> 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 >> 44 43'] >> ** >> >> >> I doubt these are anything to do with the fact R is not building (#9040) >> or >> the fact there's some initilisiion problems reguarding Pynac (#6). >> These look too much like "almost right" but not quite right. >> >> Anyone got any ideas? > > I am reminded of some similar messages in roughly the same spot being due > to an upgrade of matplotlib. So my gut feeling is something, possibly arch > specific, in matplotlib. > That's the stuff I remember: > https://github.com/cschwan/sage-on-gentoo/issues/closed#issue/19 > I'd still look in matplotlib. > > Francois Thank you. I'm a bit of a loss how to resolve this, as I have no idea what this code does, who wrote it, or any justification for it. I've search on trac for texture229 and texture230 and can find neither. This does not exactly make debugging it easy! Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
> With a slightly hacked version of 4.7.alpha3, I get the following doctest > failures: > > ** > File > "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para > metric_surface.pyx", line 180: > sage: s[:2] > Expected: > ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', > 'texture229'] Got: > ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', > 'texture178'] > ** > File > "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/para > metric_surface.pyx", line 196: > sage: s[:2]+s[2][:3]+s[3][:3] > Expected: > ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 > 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 > 44 43'] Got: > ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 > 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 > 44 43'] > ** > > > I doubt these are anything to do with the fact R is not building (#9040) or > the fact there's some initilisiion problems reguarding Pynac (#6). > These look too much like "almost right" but not quite right. > > Anyone got any ideas? I am reminded of some similar messages in roughly the same spot being due to an upgrade of matplotlib. So my gut feeling is something, possibly arch specific, in matplotlib. That's the stuff I remember: https://github.com/cschwan/sage-on-gentoo/issues/closed#issue/19 I'd still look in matplotlib. Francois This email may be confidential and subject to legal privilege, it may not reflect the views of the University of Canterbury, and it is not guaranteed to be virus free. If you are not an intended recipient, please notify the sender immediately and erase all copies of the message and any attachments. Please refer to http://www.canterbury.ac.nz/emaildisclaimer for more information. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: lcalc code quality
On Saturday, April 2, 2011 1:08:51 PM UTC-4, robertwb wrote: > > I think the key point is that there are several metrics for judging > code. > While there certainly is some artistic quality to what constitutes "beautiful code", surely we can agree that code that relies on implementation details of the system headers or any other unspecified behavior of the compiler is bad. This is not up to discussion; if you rely on unspecified behaviour then you will sometimes obtain wrong (and sometimes only subtly wrong / lowered precision) results. Which is particularly dangerous in floating-point computations where you can't test all bits of the result against some theoretical prediction. -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Spam tickets on Trac
On 1 April 2011 17:07, William Stein wrote: > On Thu, Mar 31, 2011 at 9:00 PM, Minh Nguyen wrote: >> On Fri, Apr 1, 2011 at 1:20 PM, kcrisman wrote: >>> See (or don't) #11102 and #11103. Now they're creating new tickets, >>> not just comments. Hopefully someone can get rid of them. >> >> They're closed as invalid and the corresponding accounts deleted. >> >> >>> But it >>> would be bad to go back to the "email William for an account" days... >> >> We need a better recaptcha plugin. The current one seems to be broken >> somehow. I have been dealing with spam accounts on a daily basis for >> months now, but it was only recently that I found myself dealing with >> more spam tickets than usual. > > It sounds like it might be less work for you if we switch to "email > Minh for an account"? Or how about setting up something which copies the mail to those with admin rights on trac, so it does not rely on any one individual? > Anyway, no matter how good the recaptcha plugin is, a human spammer > can still trivially get an account. > > -- William Yes, though it does put a bit of a barrier in the way. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: lcalc code quality
On Sat, Apr 2, 2011 at 8:18 AM, David Kirkby wrote: > On 2 April 2011 14:20, Bill Hart wrote: > >> Please also bear in mind that many "upstream" developers have put >> years of their life into research, development of algorithms and >> coding. Many of them are professional mathematicians, not computer >> scientists or professional programmers. They live and die by theorems, >> grants, teaching, publications, etc., not language standards and may >> only care if their code works for them and their immediate friends! >> They very often do not have time to maintain it to the high standard >> they might prefer, and their donation of their code is made on that >> understanding. > > > Fair enough, but I would hope the quality control in Sage would > prevent poor code being merged in the first place. That does not seem > to have been so, though I think the situation is improving somewhat. I think the key point is that there are several metrics for judging code. Some judge code by how many compiler warnings it produces, or how standard-abiding it is. Others judge code by clarity of the expressed algorithm(s). Yet others judge code by whether it works correctly for their domain, or the sophistication of the algorithm, or its speed. All of us weight these factors differently, and I don't think anyone would consider any of these criteria bad, but we shouldn't say code is bad because it doesn't satisfy only our choice of metric. > I would not expect to see code written by pilots controlling aircraft > or code written by medical staff controlling medical equipment. > > OK, these are extreme cases, but happen to be two industries I have > worked in (aeronautical and medical), though I have never had to write > safety-critical software for either industry. > >> There's a fine line between critiquing/refereeing/improving code and >> ridiculing it. +1 - Robert -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: [sage-release] sage-4.7.alpha3 released
On 04/ 2/11 12:57 PM, Minh Nguyen wrote:
Hi David,
On Sat, Apr 2, 2011 at 10:35 PM, Dr. David Kirkby
wrote:
Agreed, though that is obvious from the release schedule.
But may not be obvious from the standard documentation that one reads.
How many and which type of people actually closely follow the release
schedule?
So does this mean the copyright has already expired then, since we are in
April 2011?
It doesn't mean copyright immediately expires once you stop updating
the copyright year on your project's official documentation. Copyright
laws are vastly different depending on the country you're in. But what
it does mean is that, as I said above, we care enough to keep a note
of the current year we are active within the Sage project. I'm not
saying we need to update the copyright year for every standard
documentation ever released by the Sage project. Rather, let the year
in which Sage x.y.z is released be in sync with the copyright year as
seen on the Sage standard documentation.
I'm not a lawyer, but I doubt this is legally necessary. I just did a search
of the GCC source tree and find 34235 copyright notices that do not include
the year 2011. Clearly the FSF don't seem to take this matter seriously.
Legally or not, ask yourself: Do the companies that develop
Mathematica, Maple, and Matlab care enough about copyright to actually
keep the latest copyright year in sync with the year in which the
latest versions are released? See for yourself at
http://reference.wolfram.com/mathematica/guide/Mathematica.html
http://www.maplesoft.com/documentation_center/
http://www.mathworks.com/help/techdoc/
and the various downloadable documentation.
I initially thought you were saying in all the source files, which I thought was
excessive, but I can see you are talking of a few files, in which case I don't
see it as a big drain on resources.
I did a search in some of the packages in Mathematica. Clearly Wolfram Research
don't see the need to update these files unless they have changed.
drkirkby@hawk:/usr/local/Wolfram/Mathematica/7.0.1/AddOns/Packages$ find . -name
'*.m' -exec grep -i copyright {} \;
(* :Copyright: Copyright 2004-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2000-2007 Wolfram Research, Inc *)
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.*)
(* :Copyright: Copyright 2000-2007 by Sriram V. Pemmaraju and Steven S. Skiena
copyright notice must accompany all copies.
(* :Copyright: Copyright 1993-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1991-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1993-2007 by Wolfram Research, Inc. *)
(*:Copyright: Copyright 1993-2007, Wolfram Research, Inc. *)
(*:Copyright: Copyright 1997-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1993-2007 by Wolfram Research, Inc. *)
(* :Copyright: Copyright 1991-2007, Wolfram Research, Inc.*)
(* :Copyright: Copyright 1997-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1993-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1993-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1991-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1990-2007 by Wolfram Research, Inc. *)
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(*:Copyright: Copyright 1992-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1991-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1990-2008, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2001-2007 Wolfram Research, Inc *)
(*:Copyright: Copyright 1993-2007, Wolfram Research, Inc.*)
(* :Copyright: Copyright 1997-2007, Wolfram Research, Inc. *)
(*:Copyright: Copyright 1990-2007, Wolfram Research, Inc. *)
(*:Copyright: Copyright 1990-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1988-2008, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 1994-2007, Wolfram Research, Inc.
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2004, Wolfram Research, Inc. *)
(* :Copyright: Copyright 2002-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1987-2007, Wolfram Research, Inc. *)
(* :Copyright: Copyright 1990-2007, Wolfram Research, Inc. *)
(* :Copyri
Re: [sage-devel] Re: lcalc code quality
On 2 April 2011 14:20, Bill Hart wrote: > Please also bear in mind that many "upstream" developers have put > years of their life into research, development of algorithms and > coding. Many of them are professional mathematicians, not computer > scientists or professional programmers. They live and die by theorems, > grants, teaching, publications, etc., not language standards and may > only care if their code works for them and their immediate friends! > They very often do not have time to maintain it to the high standard > they might prefer, and their donation of their code is made on that > understanding. Fair enough, but I would hope the quality control in Sage would prevent poor code being merged in the first place. That does not seem to have been so, though I think the situation is improving somewhat. I would not expect to see code written by pilots controlling aircraft or code written by medical staff controlling medical equipment. OK, these are extreme cases, but happen to be two industries I have worked in (aeronautical and medical), though I have never had to write safety-critical software for either industry. > There's a fine line between critiquing/refereeing/improving code and > ridiculing it. Very true, but the fact it is in Sage, does cause frustration. I suspect it was frustration which was the provocation for the initial rather harsh comments on this thread. There are bits of code in Sage, which even a cursory glance at the source code, or a look at the compiler warnings, should have in my opinion stopped it being in Sage before it was cleaned up. If the code was thought to be very useful (like Sympow), but of dubious quality (you yourself once wrote Sympow was "virtually obfuscated") https://groups.google.com/group/sage-devel/msg/d7aef307c15de2e6?hl=en then perhaps it should have remained experimental. Or perhaps it should have never been put in Sage, but people used it external to Sage. Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] M4RIE & 4.7
Hi, since 4.7 is about adding SPKGs I'm wondering if that could motivate someone to finish the review of http://trac.sagemath.org/sage_trac/ticket/9562 which is about fast linear algebra over small extensions of GF(2). It was agreed ages ago that M4RIE (the new library which implements this functionality, started at a Sage Days workshop) should go in and as far as I know it builds on all platforms. As for the performance: multiplying two 1,000 x 1,000 matrices over GF(2^8) Sage 4.6.2 80.35 s NTL 5.4.2 127.43s # not sure why this is so slow Magma 2.15 1.68 s LinBox over F2511.25 s M4RIE 0.53 s #9562 Btw. for those who are curious, I gave a talk about M4RI & M4RIE last week in LORIA, Nancy: http://martinralbrecht.wordpress.com/2011/03/30/talk-about-m4ri-and-m4rie/ Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://martinralbrecht.wordpress.com/ _jab: martinralbre...@jabber.ccc.de -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: lcalc code quality
On Mar 31, 8:41 pm, Jason Grout wrote: > On 3/31/11 2:09 PM, kcrisman wrote: > +1 to everything you said. Also, I'd like to point out that since many > upstream developers lurk on this and other Sage lists, our "colloquial" > conversations actually are heard by many upstream developers. Even if a > particular upstream developer is not subscribed, many other upstream > developers see how we behave as a group and that will probably influence > their opinion of Sage. Correct. Please also bear in mind that many "upstream" developers have put years of their life into research, development of algorithms and coding. Many of them are professional mathematicians, not computer scientists or professional programmers. They live and die by theorems, grants, teaching, publications, etc., not language standards and may only care if their code works for them and their immediate friends! They very often do not have time to maintain it to the high standard they might prefer, and their donation of their code is made on that understanding. There's a fine line between critiquing/refereeing/improving code and ridiculing it. If you want to ridicule code which does not conform to the standard, take your best shot: http://stackoverflow.com/questions/4568645/printing-1-to-1000-without-loop-or-conditionals/4583502#4583502 -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: [sage-release] sage-4.7.alpha3 released
Hi David, On Sat, Apr 2, 2011 at 10:35 PM, Dr. David Kirkby wrote: > Agreed, though that is obvious from the release schedule. But may not be obvious from the standard documentation that one reads. How many and which type of people actually closely follow the release schedule? > So does this mean the copyright has already expired then, since we are in > April 2011? It doesn't mean copyright immediately expires once you stop updating the copyright year on your project's official documentation. Copyright laws are vastly different depending on the country you're in. But what it does mean is that, as I said above, we care enough to keep a note of the current year we are active within the Sage project. I'm not saying we need to update the copyright year for every standard documentation ever released by the Sage project. Rather, let the year in which Sage x.y.z is released be in sync with the copyright year as seen on the Sage standard documentation. > I'm not a lawyer, but I doubt this is legally necessary. I just did a search > of the GCC source tree and find 34235 copyright notices that do not include > the year 2011. Clearly the FSF don't seem to take this matter seriously. Legally or not, ask yourself: Do the companies that develop Mathematica, Maple, and Matlab care enough about copyright to actually keep the latest copyright year in sync with the year in which the latest versions are released? See for yourself at http://reference.wolfram.com/mathematica/guide/Mathematica.html http://www.maplesoft.com/documentation_center/ http://www.mathworks.com/help/techdoc/ and the various downloadable documentation. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Re: [sage-release] sage-4.7.alpha3 released
On 04/ 2/11 11:06 AM, Minh Nguyen wrote: Hi David, On Sat, Apr 2, 2011 at 6:36 PM, Dr. David Kirkby wrote: Is this really necessary? Would it not be better to have just put a start date? Yes. It shows that a project is still active Agreed, though that is obvious from the release schedule. and we care about the copyright. The Sage project claims copyright on the Sage standard documentation for each year the project is active. So does this mean the copyright has already expired then, since we are in April 2011? I'm not a lawyer, but I doubt this is legally necessary. I just did a search of the GCC source tree and find 34235 copyright notices that do not include the year 2011. Clearly the FSF don't seem to take this matter seriously. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
[sage-devel] Doctest failure with sage/plot/plot3d/parametric_surface.pyx on OpenSolaris 64-bit
With a slightly hacked version of 4.7.alpha3, I get the following doctest failures: ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 180: sage: s[:2] Expected: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture229'] Got: ['TRI V0 -2 -2 0 V1 -2 -1.89744 0.399737 V2 -1.89744 -1.89744 0', 'texture178'] ** File "/export/home/drkirkby/try/sage-4.7.alpha2/devel/sage/sage/plot/plot3d/parametric_surface.pyx", line 196: sage: s[:2]+s[2][:3]+s[3][:3] Expected: ['g obj_1', 'usemtl texture230', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] Got: ['g obj_1', 'usemtl texture179', 'v -2 -2 0', 'v -2 -1.89744 0.399737', 'v -2 -1.79487 0.778435', 'f 1 2 42 41', 'f 2 3 43 42', 'f 3 4 44 43'] ** I doubt these are anything to do with the fact R is not building (#9040) or the fact there's some initilisiion problems reguarding Pynac (#6). These look too much like "almost right" but not quite right. Anyone got any ideas? -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Debugging some cython code / Pynac
On 04/ 1/11 11:46 PM, Burcin Erocal wrote: On Fri, 01 Apr 2011 17:20:57 +0100 "Dr. David Kirkby" wrote: On 04/ 1/11 12:54 PM, Burcin Erocal wrote: On Fri, 01 Apr 2011 00:37:46 +0100 "Dr. David Kirkby" wrote: I've built Sage 64-bit on OpenSolaris but it crashes at startup. I've run gdb and find the bit of code that's causing the crash is this. It seems that cones.py looks for posets.py, which needs the graphs module, which initializes the graph_editor. The graph editor tries to see if it's in the notebook or the command line, but sagenb imports SR and Expression from sage.symbolic.all (line 563 of sagenb/misc/support.py). This tries to initialize the functions (integrate in this case) before pynac is initialized... We need a better solution for making sure modules are initialized properly before anything is imported from them. I thought putting an __init__.py file in sage/symbolic/ with "import pynac" would solve the problem. However, it seems that python just ignores that file. Any suggestions on how to solve the general problem properly? BTW, telling people to import from .all if they are outside the current module is just asking for trouble. We can't put initialization code in all.py, since it would just get imported to the main namespace. Cheers, Burcin This issue is now http://trac.sagemath.org/sage_trac/ticket/6 -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? Dave -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
Re: [sage-devel] Re: Make check fails for sage 4.6.2 build
On 04/ 1/11 11:02 PM, jonha...@gmail.com wrote: Dear Dave, That's weird. Now the test seems to pass. I had tried it several times before I wrote, but now it consistently passes. I'm now a little worried about the stability of my system... Any ideas about what can cause these problems (and tests I can run to detect them)? Thanks, -Jon =) P.S. /proc/version tells me: Linux version 2.6.18-164.6.1.el5 (mockbuild@ls20- bc2-14.build.redhat.com) (gcc version 4.1.2 20080704 (Red Hat 4.1.2-46)) #1 SMP Tue Oct 27 11:28:30 EDT 2009 Could you check your system logs and see if there were any error messages. Running out of swap space, memory errors etc. I know if one tests Sage in parallel, with $ make ptestlong or $ make ptest then there can sometimes be failures which are not reproducible due to the fact one test could write over files created by another test. But "make check" does not do parallel testing, so that's not the issue here. You could create a shell script like this: #!/bin/sh while [ 1 ] ; do ./sage -t devel/sage/sage/misc/preparser.py >> preparser-tests.log done and put that in the top-level sage directory. It will run the test for as many times as you feel you want to dedicate CPU time to. Then grep the file preparser-tests.log and see if there are failures. The test is taking 6.0 seconds on my machine, so it should be possible to get 1000 tests done in reasonably manageable time. Some time ago I did test Sage 100 or more times for a few days, and did get some odd failures, though I think most could be explained by the fact that the testing framework for Sage was quite poor. But I think that's been improved somewhat since then. Do you have an account on trac? If not, it would be worth creating a ticket. Put as much information about your machine as possible Make and model. RAM CPU Operating system and version Whether it's 32-bit or 64-bit operating system. Version of Sage Version of gcc used The original failure, the fact it failed several times, then it passes several times. Whether you have a record of the system logs at the time the tests were run, which show no problems (out of swap space, memory errors etc). How many failures you got with my little test program etc. I assume since that machine is a Sun, it will have error corrected RAM anyway. -- A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? A: Top-posting. Q: What is the most annoying thing in e-mail? -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
