Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread John Cremona
On 2 January 2014 07:51, Jason Grout  wrote:
> On 1/1/14, 11:34 PM, Volker Braun wrote:
>>
>> The solution (I'd call it "Volker's solution" except that its really
>> what everybody else does, so I can't take credit for it) is to tell
>> every reviewer that he is responsible for every commit that is not
>> already reviewed. Its an extremely simple rule. And if its too much work
>> to also review the commits from the dependencies then just start at the
>> dependency. Easy as pie.
>
>
> Which is exactly why I think we should have a view that shows what commits
> and changes on a ticket have not been reviewed yet.  For example, if ticket
> 2 depends on ticket 1, and someone goes and reviews ticket 1, it would be
> fantastic if on trac we can see a list of changes and/or a total diff that
> exists in ticket 2 without seeing the positively-reviewed changes from
> ticket 1 (even if ticket 1 has not been merged).

It is rather frequent that some commit gets a positive review (e.g.
from me) only to be reverted to "needs work" by someone else (e.g. one
of our excellent release managers ;)).  If the list of commits coming
from dependencies of ticket 2 could be shown with tags showing their
review status, that would  be nice, though not very well-defined since
ticket 1 might have had a series of serveral commits and only the
complete set of changes they represent has the positive review, not
the individual component commits.

Personally, at least until everyone is used to this new system (which
I do like using a lot so far, despite some teething troubles) I will
avoid reviewing tickets with unreviewed dependencies, whic his the
simple version of "Volker's solution".

John

>
> Thanks,
>
> Jason
>
>
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Simon King
Hi Volker,

On 2014-01-02, Volker Braun  wrote:
> Checking for problems is the easy part, this is not what I'm talking about. 
> By *safe*, I mean in a way such that the reviewer, at the time of the 
> review, is actually seeing all the changes that he is reviewing.
>
> Whatever proposal you come up with work in the following scenario where 
> there are three commits  A -> B -> C and
>   * ticket 1: Commit: B
>   * ticket 2 depends on 1, Commit: C
> Now you look *only* at commit C and set ticket 2 to positive review. Then 
> somebody else changes ticket one to "Commit: A". Finally, ticket 1 is 
> reviewed. The result is that B is never reviewed but merged into Sage 
> without either reviewer noticing.

And that's what I have repeatedly named a "git artefact".

In the hg workflow (I'd say: in any reasonable trac workflow), B would simply
not be merged, since it does not belong to any positively reviewed ticket.

But you try to convince us that with git there is no such notion as "ticket to
which a commit belongs". And since git is good (that's an axiom) we have to
accept that the reviewer of ticket 2 has to review commit A, and we also
have to accept that a positive review of ticket 2 should qualify commit A for
being merged, even though the reviewer of ticket 1 (who supposedly is more
expert for the topic of ticket 1 than the reviewer of ticket 2!!) says that
commit A can't be accepted.

But it keeps looking wrong to me: In the scenario you describe, commit B clearly
belongs to the original version of ticket 1; it does *not* belong to ticket 2
and *not* to the positively reviewed version of ticket 1. And so there
is no reason to merge commit B.

If git suggests to merge B, then it's a bad flaw, and we need to do
something about it: We need to implement a work-around in our workflow.

That said, the fact that a dependency for ticket 2 has changed means
that ticket 2 needs someone to check that things still work. This has to
hold in any workflow.

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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Simon King
Hi John,

On 2014-01-02, John Cremona  wrote:
> It is rather frequent that some commit gets a positive review (e.g.
> from me) only to be reverted to "needs work" by someone else (e.g. one
> of our excellent release managers ;)).  If the list of commits coming
> from dependencies of ticket 2 could be shown with tags showing their
> review status, that would  be nice, though not very well-defined since
> ticket 1 might have had a series of serveral commits and only the
> complete set of changes they represent has the positive review, not
> the individual component commits.

Additional problem: According to Volker there is no ticket to which a
specific commit belongs.

To me, the punch line seems to be that git is orthogonal to trac. I
thought that Sage's bugs are dealt with on trac. Hence, we need a trac
workflow, not a workflow that relies on notions (namely: commits) that
are orthogonal to the notions relevant to trac (namely: tickets).

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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Simon King
On 2014-01-02, Simon King  wrote:
> But you try to convince us that with git there is no such notion as "ticket to
> which a commit belongs". And since git is good (that's an axiom) we have to
> accept that the reviewer of ticket 2 has to review commit A, and we also
> have to accept that a positive review of ticket 2 should qualify commit A for
> being merged, even though the reviewer of ticket 1 (who supposedly is more
> expert for the topic of ticket 1 than the reviewer of ticket 2!!) says that
> commit A can't be accepted.

Oops, in your example it was B (not A) that reviewer 2 gives an implicit
review, even though reviewer 1 gives it a negative review.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Conversions without mathematical sense between polynomial rings

2014-01-02 Thread Peter Bruin
Hi Nils,
 

> Given how few properties a "conversion map" is actually guaranteed to 
> have, wouldn't it be sufficient to  just have a callable represent the 
> conversion and not demand it's a map?
>

This sounds like a good idea if conversion remain the low-level things it 
is (i.e. possibly without any mathematical interpretation).  If at some 
point it is decided that conversions should have some nice properties (e.g. 
being actual maps with some mathematical meaning, or (partial) sections of 
them), then it would make more sense to make them some map-like type, but 
that wouldn't really be the concept that is now called conversion.

I don't think we really need domain and codomain anyway. It also means that 
> in a lot of cases, one could simply store to codomain rather than a map 
> wrapping a call to the codomain.
>

Except that currently (if A is the codomain) A.__call__() looks for a 
conversion and calls it, where the default conversion consists of calling 
A._element_constructor_(), so just letting the conversion f be the callable 
A itself instead would create a circularity (A(x) = A.__call__(x) = f(x) = 
A(x) = ...).  To implement your proposal, one could return "lambda x: 
return A._element_constructor_(x)" as the conversion.

Peter

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: error building from source with git clone

2014-01-02 Thread Niles Johnson
Do you have the developer tools (Xcode) installed?  This prerequisite is 
sort of buried in the middle of the instructions at 

http://www.sagemath.org/doc/installation/source.html

-Niles


On Saturday, December 21, 2013 1:25:29 AM UTC-5, Theron Hitchman wrote:
>
> I just tried cloning the git repository and building sage from that 
> source. This is new for me, and I got an error! 
>
> Actually, I got two errors. The first was about getting MacPorts out of 
> the way. I found info and navigated around that one.
>
> Now I have trouble and the error is about building gcc.  
>
> I am working on a macbook pro running OSX 10.9.1. Here is the "relevant 
> part of the log file" that the error message asked me to send. 
> --
> Setting up build directory for gcc-4.7.3.p1
> Finished set up
> 
> Host system:
> Darwin cns-theron-lap-2.local 13.0.0 Darwin Kernel Version 13.0.0: Thu Sep 
> 19 22:22:27 PDT 2013; root:xnu-2422.1.72~6/RELEASE_X86_64 x86_64
> 
> C compiler: /usr/bin/clang
> C compiler version:
> Apple LLVM version 5.0 (clang-500.2.79) (based on LLVM 3.3svn)
> Target: x86_64-apple-darwin13.0.0
> Thread model: posix
> 
> sed: /usr/include/sys/cdefs.h: No such file or directory
>
> real0m0.022s
> user0m0.013s
> sys0m0.015s
> 
> Error installing package gcc-4.7.3.p1
> 
>
> 
> I am traveling the next few days, so I won't respond to this very quickly, 
> I am afraid.
>
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Conversions without mathematical sense between polynomial rings

2014-01-02 Thread Nils Bruin
On Thursday, January 2, 2014 2:42:13 AM UTC-8, Peter Bruin wrote:
>
> Except that currently (if A is the codomain) A.__call__() looks for a 
> conversion and calls it, where the default conversion consists of calling 
> A._element_constructor_(), so just letting the conversion f be the callable 
> A itself instead would create a circularity (A(x) = A.__call__(x) = f(x) = 
> A(x) = ...).  To implement your proposal, one could return "lambda x: 
> return A._element_constructor_(x)" as the conversion.
>
No, it could simply be (a weak reference to) A._element_constructor_, (yes, 
bound methods turn out to allow weak references!). A benefit would be that 
we do not need superfluous wrappers.

This brings up another point:I think the mail reason for reifying a 
"conversion" in the first place is because we want them cached for 
efficiency reasons. If they're going to be _element_constructor_ all the 
time anyway, I'm not so sure we need to cache them.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Jason Grout

On 1/2/14, 2:38 AM, John Cremona wrote:

Personally, at least until everyone is used to this new system (which
I do like using a lot so far, despite some teething troubles)


Thanks; that is a very prudent philosophy.  This is my biggest 
take-away---I'll use the system and hold my further suggestions until 
I'm more used to the new workflow.


Thanks,

Jason


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] error building from source with git clone

2014-01-02 Thread Jeroen Demeyer

On 2013-12-21 07:25, Theron Hitchman wrote:

sed: /usr/include/sys/cdefs.h: No such file or directory


You need that file. If it's not there, this means that Xcode is not 
fully installed.


--
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread John Cremona
On 2 January 2014 16:04, Jason Grout  wrote:
> On 1/2/14, 2:38 AM, John Cremona wrote:
>>
>> Personally, at least until everyone is used to this new system (which
>> I do like using a lot so far, despite some teething troubles)
>
>
> Thanks; that is a very prudent philosophy.  This is my biggest
> take-away---I'll use the system and hold my further suggestions until I'm
> more used to the new workflow.
>
>
> Thanks,

You're welcome!

If someone could point me to a place which explains how to install and
use ccache, that would be helpful, since I may not get away with using
MAKE='make -j 60' for ever (and even then it takes a couple of minutes
to switch branches and re-make).

John

>
> Jason
>
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Nils Bruin
On Thursday, January 2, 2014 8:55:37 AM UTC-8, John Cremona wrote:

> If someone could point me to a place which explains how to install and 
> use ccache, that would be helpful, since I may not get away with using 
> MAKE='make -j 60' for ever (and even then it takes a couple of minutes 
> to switch branches and re-make). 
>
 
 It may be as simple as "yum install ccache" or "apt-get install ccache". 
In fact, when I looked into it on fedora it turned out to be already 
installed.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread John Cremona
On 2 January 2014 17:08, Nils Bruin  wrote:
> On Thursday, January 2, 2014 8:55:37 AM UTC-8, John Cremona wrote:
>>
>> If someone could point me to a place which explains how to install and
>> use ccache, that would be helpful, since I may not get away with using
>> MAKE='make -j 60' for ever (and even then it takes a couple of minutes
>> to switch branches and re-make).
>
>
>  It may be as simple as "yum install ccache" or "apt-get install ccache". In
> fact, when I looked into it on fedora it turned out to be already installed.

Thanks -- just installed it.  But surely I have to do something to get
Sage to use it?

John

>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Nils Bruin
On Thursday, January 2, 2014 9:29:59 AM UTC-8, John Cremona wrote:
>
> Thanks -- just installed it.  But surely I have to do something to get 
> Sage to use it? 
>
> Not necessarily. If you're using the system gcc then installing ccache on 
your system probably also takes care of putting the appropriate wrappers in 
place of gcc etc. You might want to look at "ccache -s" and see if the 
cache gets any use. If you have plenty disk space you may want to try 
upping the space that ccache has available too. 

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread John Cremona
On 2 January 2014 17:47, Nils Bruin  wrote:
> On Thursday, January 2, 2014 9:29:59 AM UTC-8, John Cremona wrote:
>>
>> Thanks -- just installed it.  But surely I have to do something to get
>> Sage to use it?
>>
> Not necessarily. If you're using the system gcc then installing ccache on
> your system probably also takes care of putting the appropriate wrappers in
> place of gcc etc. You might want to look at "ccache -s" and see if the cache
> gets any use. If you have plenty disk space you may want to try upping the
> space that ccache has available too.

"probably?"   but my gcc is /usr/bin/gcc which is a symlink to
/usr/bin/gcc-4.6 which is dated Apr 16 2012 (and is a binary).  I get

jec@atkin:~$ ccache -s
cache directory /home/jec/.ccache
cache hit (direct)  9406
cache hit (preprocessed) 811
cache miss  4236
called for link 9542
called for preprocessing 153
compile failed33
preprocessor error 7
bad compiler arguments22
autoconf compile/link459
no input file   2593
files in cache  8077
cache size   1.9 Gbytes
max cache size   4.0 Gbytes

and have plenty of disk space:

jec@atkin:~$ df -h ~
Filesystem  Size  Used Avail Use% Mounted on
/dev/mapper/atkin-root  1.7T  122G  1.5T   8% /

John
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-devel" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-devel+unsubscr...@googlegroups.com.
> To post to this group, send email to sage-devel@googlegroups.com.
> Visit this group at http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Robert Bradshaw
On Thu, Jan 2, 2014 at 8:55 AM, John Cremona  wrote:
> On 2 January 2014 16:04, Jason Grout  wrote:
>> On 1/2/14, 2:38 AM, John Cremona wrote:
>>>
>>> Personally, at least until everyone is used to this new system (which
>>> I do like using a lot so far, despite some teething troubles)
>>
>>
>> Thanks; that is a very prudent philosophy.  This is my biggest
>> take-away---I'll use the system and hold my further suggestions until I'm
>> more used to the new workflow.
>>
>>
>> Thanks,
>
> You're welcome!
>
> If someone could point me to a place which explains how to install and
> use ccache, that would be helpful, since I may not get away with using
> MAKE='make -j 60' for ever (and even then it takes a couple of minutes
> to switch branches and re-make).

You can also do sage -i ccache. I would be all for making this a
standard, on-by-default option if it can be done conservatively
enough.

- Robert

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Robert Bradshaw
On Thu, Jan 2, 2014 at 1:49 AM, Simon King  wrote:
> Hi John,
>
> On 2014-01-02, John Cremona  wrote:
>> It is rather frequent that some commit gets a positive review (e.g.
>> from me) only to be reverted to "needs work" by someone else (e.g. one
>> of our excellent release managers ;)).  If the list of commits coming
>> from dependencies of ticket 2 could be shown with tags showing their
>> review status, that would  be nice, though not very well-defined since
>> ticket 1 might have had a series of serveral commits and only the
>> complete set of changes they represent has the positive review, not
>> the individual component commits.
>
> Additional problem: According to Volker there is no ticket to which a
> specific commit belongs.
>
> To me, the punch line seems to be that git is orthogonal to trac. I
> thought that Sage's bugs are dealt with on trac. Hence, we need a trac
> workflow, not a workflow that relies on notions (namely: commits) that
> are orthogonal to the notions relevant to trac (namely: tickets).

Correct, git and trac aren't entirely orthogonal, but you're right
there's a discrepancy. My preference would be to move even further
away from forcing a trac-based workflow 'cause with git you're not
forced into using one workflow/set of tools and the skills are
transferable (in and out) and there's a lot more resources out there.

So I would propose that every *commit* that goes into Sage needs to be
positively reviewed. Tickets are (possibly changing, typically
monotonically) sets of commits, excluding the commits of dependencies.
Setting a ticket to positive review marks the current set of commits
as positively reviewed; if this set changes (due to changes in
dependencies or further work) this positive review is automatically
set back, but the commits that were previously reviewed are still
marked as such.

- Robert

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Conversions without mathematical sense between polynomial rings

2014-01-02 Thread Robert Bradshaw
On Thu, Jan 2, 2014 at 8:01 AM, Nils Bruin  wrote:
> On Thursday, January 2, 2014 2:42:13 AM UTC-8, Peter Bruin wrote:
>>
>> Except that currently (if A is the codomain) A.__call__() looks for a
>> conversion and calls it, where the default conversion consists of calling
>> A._element_constructor_(), so just letting the conversion f be the callable
>> A itself instead would create a circularity (A(x) = A.__call__(x) = f(x) =
>> A(x) = ...).  To implement your proposal, one could return "lambda x: return
>> A._element_constructor_(x)" as the conversion.
>
> No, it could simply be (a weak reference to) A._element_constructor_, (yes,
> bound methods turn out to allow weak references!). A benefit would be that
> we do not need superfluous wrappers.
>
> This brings up another point:I think the mail reason for reifying a
> "conversion" in the first place is because we want them cached for
> efficiency reasons. If they're going to be _element_constructor_ all the
> time anyway, I'm not so sure we need to cache them.

They're not always _element_constructor_, in particular, when it
exists, they should be the (partial) inverses of coercion maps (which
is automatically detected). It is unfortunate that conversions
encapsulate everything from section like Z/nZ -> Z and canonical
partial maps Q -> GF(p) to non-map constructors like list/dict -> Z[x]
to nonsense like GF(p) -> GF(q).

- Robert

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Nils Bruin
On Thursday, January 2, 2014 10:39:13 AM UTC-8, Robert Bradshaw wrote:
>
> So I would propose that every *commit* that goes into Sage needs to be 
> positively reviewed. 


In which case we'd want a lot more history discarding/rewriting to happen 
before a commit gets positive review. Wouldn't we be back at the hg 
workflow with patches, with patches replaced by git commits?

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Robert Bradshaw
On Thu, Jan 2, 2014 at 8:08 PM, Nils Bruin  wrote:
> On Thursday, January 2, 2014 10:39:13 AM UTC-8, Robert Bradshaw wrote:
>>
>> So I would propose that every *commit* that goes into Sage needs to be
>> positively reviewed.
>
> In which case we'd want a lot more history discarding/rewriting to happen
> before a commit gets positive review. Wouldn't we be back at the hg workflow
> with patches, with patches replaced by git commits?

No. Given a history master -> A -> B -> C -> D -> E, where A+B
belongs to ticket 1 and C+D+E belongs to ticket 2, reviewing ticket 2
could involve looking at the diff B..E and calling it good (giving a
positive review to the sequence B -> C -> D -> E). Of course,
sometimes looking at C -> D and D -> E separately can be helpful too.
Also, if D -> E is a bunch of new doctests, someone could review that
without reviewing B -> D if they were short on time or expertise,
sharing the load.

I take back what I said about sets, every commit should be reviewed as
part of a sequence, so if B -> E is reviewed and the ticket gets
changed to B -> D, the positive review should no longer hold (though
if D -> E is small it should be pretty easy to re-review B -> D).
Every commit that goes into Sage needs to be positively reviewed,
either directly or indirectly as part of a series ending in a
positively reviewed commit.

- Robert

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Volker Braun
On Wednesday, January 1, 2014 11:42:23 PM UTC-10, Simon King wrote:
>
> And that's what I have repeatedly named a "git artefact". 
>

Its really a feature of any version control system that is more 
sophisticated than mailing patches around. Version control is all about 
recording history. And until the two tickets (branches) are folded into the 
next release, they are separate histories. By definition it is not possible 
to both keep their histories separate (=separate tickets) and combine their 
history (=share commits in both branches). Either review the two ticket 
separately, or close one and review the other.


-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread William Stein
On Thu, Jan 2, 2014 at 7:52 PM, Volker Braun  wrote:
> On Wednesday, January 1, 2014 11:42:23 PM UTC-10, Simon King wrote:
>> And that's what I have repeatedly named a "git artefact".
> Its really a feature of any version control system that is more

Volker -- Did you just land in Hawaii?

> sophisticated than mailing patches around. Version control is all about
> recording history. And until the two tickets (branches) are folded into the
> next release, they are separate histories. By definition it is not possible
> to both keep their histories separate (=separate tickets) and combine their
> history (=share commits in both branches). Either review the two ticket
> separately, or close one and review the other.
>
>
> --
> 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 http://groups.google.com/group/sage-devel.
> For more options, visit https://groups.google.com/groups/opt_out.



-- 
William Stein
Professor of Mathematics
University of Washington
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Volker Braun
No, my flight is delayed... I'm currently sitting in Kona airport (KOA). 
I'm scheduled to arrive around 10:30pm now. I know about Jamie's flight 
cancellation, for the record. 

On Thursday, January 2, 2014 7:56:36 PM UTC-10, William wrote:
>
> Volker -- Did you just land in Hawaii? 
>

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Volker Braun
On Thursday, January 2, 2014 6:08:59 PM UTC-10, Nils Bruin wrote:
>
> In which case we'd want a lot more history discarding/rewriting to happen 
> before a commit gets positive review. Wouldn't we be back at the hg 
> workflow with patches, with patches replaced by git commits?
>

No, the key is to send commit ranges for review. In other words, you squash 
the history for review *only*, but then go back and use the git merge for 
the original history.

One example of a review tool is Phabricator (from Facebook), there are 
others. Downside is that it is yet another complicated machine, with its 
own command line utilities.


-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


[sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Volker Braun
On Wednesday, January 1, 2014 11:49:55 PM UTC-10, Simon King wrote:
>
> To me, the punch line seems to be that git is orthogonal to trac.
>

I agree with that. IMHO:
* The bug tracking system is about goals and ideas.
* The revision control system tracks code changes.
The only point of contact is when you associate a particular commit (branch 
head) to a trac ticket to perform the change required to solve the ticket.
 

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.


Re: [sage-devel] Re: Reviewing without dependencies

2014-01-02 Thread Robert Bradshaw
On Thu, Jan 2, 2014 at 10:18 PM, Volker Braun  wrote:
> On Thursday, January 2, 2014 6:08:59 PM UTC-10, Nils Bruin wrote:
>>
>> In which case we'd want a lot more history discarding/rewriting to happen
>> before a commit gets positive review. Wouldn't we be back at the hg workflow
>> with patches, with patches replaced by git commits?
>
>
> No, the key is to send commit ranges for review. In other words, you squash
> the history for review *only*, but then go back and use the git merge for
> the original history.
>
> One example of a review tool is Phabricator (from Facebook), there are
> others. Downside is that it is yet another complicated machine, with its own
> command line utilities.

The advantage of specifying the review process in terms of git (e.g.
commits) is that people can use whatever tools they want.

- Robert

-- 
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 http://groups.google.com/group/sage-devel.
For more options, visit https://groups.google.com/groups/opt_out.