On Monday, September 22, 2014 11:37:13 PM UTC-7, Clemens Heuberger wrote:
>
> the problem is that the labels of a state could be any hashable Sage
> object.
> Thus preprocessing this single case of Frac(QQ[x]) would be quite ugly
> IMHO and
> would not address the underlying problem.
>
The Fr
On 2014-09-23 18:36, John Cremona wrote:
Well done.Surely if all those hunderds of lines now look good,
that counts for a large number of tests that Volker did it right? If
so, I think you can give the ticket a positive review...
I'm not so sure. For example, the last version of the patch ac
I guess there are two or three solutions:
1) don't use sets
2) put big, red warnings in the documentation of your functions
3) have an optional argument to your functions that switches between sets
and safer (but slower) data structures. The documentation should be clear
about the implications.
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?
The tmp directory has gone. To my knowledge there is only a
(patchbot-)symlink
/tmp/tmpUOouim-sage-git-temp/upstream ->
/home/jkroeker/Pro
On 23 September 2014 17:23, Jeroen Demeyer wrote:
> On 2014-09-23 14:54, John Cremona wrote:
>>
>> I took a quick look and was daunted by the large number of changes,
>> many in files I never normally look at.
>
>
> As I already said on the ticket, I checked those many changes and they are
> ok. W
On 2014-09-23 14:54, John Cremona wrote:
I took a quick look and was daunted by the large number of changes,
many in files I never normally look at.
As I already said on the ticket, I checked those many changes and they
are ok. What I have not checked is the actual code related to the
display
Trust me, I know what I'm doing ;-)
The big piece is commit b579b92... which is mostly auto-generated changes
to the existing doctests for the new output format. Its long but not really
that exciting. You can see it with
git show b579b92
The main work was done before that, to switch the docte
I took a quick look and was daunted by the large number of changes,
many in files I never normally look at. What's the best strategy --
apart from trusting you completely?
Divide up the files and get a few people to look at them instead of just one?
John
On 23 September 2014 13:36, Volker Braun
bump
On Thursday, September 18, 2014 9:27:18 PM UTC+1, Jeroen Demeyer wrote:
>
> On 2014-09-18 20:30, Volker Braun wrote:
> > I would like to merge the ticket asap
> > and then release the next beta. So please review ;-)
> I'm not convinced that you should postpone the next beta for this. If
>
On 09/23/2014 12:23 PM, Clemens Heuberger wrote:
My $HOME/.sage is a symbolic link with a trailing slash:
~ $ ls -ld .sage
lrwxrwxrwx 1 cheuberg lsci 11 Sep 23 10:25 .sage -> /tmp/.sage/
When running make ptestlong (sage 6.4.beta3) with this configuration, I get
quite a number of failing doctes
My $HOME/.sage is a symbolic link with a trailing slash:
~ $ ls -ld .sage
lrwxrwxrwx 1 cheuberg lsci 11 Sep 23 10:25 .sage -> /tmp/.sage/
When running make ptestlong (sage 6.4.beta3) with this configuration, I get
quite a number of failing doctests (see below for details) and several files are
cr
IMHO we don't need to wait for somebody to test optional interfaces with
all combinations of OS and Maple. Read the code! He proposed an obvious
improvement over what we have, using some of the maple command line
switches to simplify output. Should have been merged a year ago...
On Tuesday, Sep
See http://trac.sagemath.org/ticket/12295 - esp. if someone is on Mac. It
seems to work fine, just can't have the author be the reviewer :)
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe from this group and stop receiving emails
13 matches
Mail list logo
