Google code: copy of the Sage source repository

[William Stein]

Hi,

Just for fun, I created this page:

http://code.google.com/p/sagemath/

It has the Sage source code repo, so you can browse the history of Sage:

http://code.google.com/p/sagemath/source/list

and files:

http://code.google.com/p/sagemath/source/browse/

It's interesting because it's a completely different view of the HG
repo history of Sage than that provided by HG's own web frontend,
since Google wrote their own new web frontend (and also storage
backend) for HG.

It might also at some point be worth playing around with the code
review tools that are integrated into this.

-- William

--
William Stein
Professor of Mathematics
University of Washington
http://wstein.org

[François Bissey]

> Hi,
>
> Just for fun, I created this page:
>
> http://code.google.com/p/sagemath/
>
> It has the Sage source code repo, so you can browse the history of Sage:
>
> http://code.google.com/p/sagemath/source/list
>

I actually installed hgview to inspect changes on my machine and it looks a
bit like that.

Francois

[leif]

On 26 Okt., 01:02, William Stein <wst...@gmail.com> wrote:
> Just for fun, I created this page:
>
>    http://code.google.com/p/sagemath/
>
> It has the Sage source code repo, so you can browse the history of Sage:
>
>    http://code.google.com/p/sagemath/source/list

Nice. One more reason to provide more than one-line commit messages
(i.e., in addition a summary like our spkg changelog entries below the
short description on the first line). ;-)

IIRC the description of that in the Developer's Guide isn't very
clear.

Also, I like the "affected files" which I remember (for me) being hard
to find some time ago.


-Leif

[John Cremona]

Leif,

Browsing the link led me to
http://code.google.com/p/sagemath/source/detail?r=bc2913bfc76dd758bc4bd87554df6fb3b2b5050c
and some comments of yours about (I think) whether mwrank/eclib/etc
require the pari library. They do! They only use it in a small way
(for factoring integers) but they do use it.

John

> --
> To post to this group, send an email to sage-...@googlegroups.com
> To unsubscribe from this group, send an email to sage-devel+...@googlegroups.com
> For more options, visit this group at http://groups.google.com/group/sage-devel
> URL: http://www.sagemath.org
>

[leif]

On 26 Okt., 21:34, leif <not.rea...@online.de> wrote:
> On 26 Okt., 01:02, William Stein <wst...@gmail.com> wrote:
>
> > Just for fun, I created this page:
>
> >    http://code.google.com/p/sagemath/
>
> > It has the Sage source code repo, so you can browse the history of Sage:
>
> >    http://code.google.com/p/sagemath/source/list
>
> Nice. One more reason to provide more than one-line commit messages
> (i.e., in addition a summary like our spkg changelog entries below the
> short description on the first line). ;-)
>
> IIRC the description of that in the Developer's Guide isn't very
> clear.

Yes,

http://www.sagemath.org/doc/developer/walk_through.html#submitting-a-change

does not even mention one can use longer commit messages. ("hg log"
only shows the first line, while "hg log -v" shows the full commit
message, along with the files modified by a changeset.)

[leif]

On 26 Okt., 21:47, John Cremona <john.crem...@gmail.com> wrote:
> Leif,
>

> Browsing the link led me to http://code.google.com/p/sagemath/source/detail?r=bc2913bfc76dd758bc4...

> and some comments of yours about (I think) whether mwrank/eclib/etc
> require the pari library.

So it appears to be quite useful. :-)

> They do!  They only use it in a small way
> (for factoring integers) but they do use it.

The question was rather if we have to specify the PARI library in the
extension modules' library lists, as they only use PARI *indirectly*
through the other libs specified (e.g. "curvesntl", "g0nntl", "jcntl",
"rankntl").

At least on Linux this is not the case.

(The dependency on PARI is already recorded in those libraries
directly using it. "readelf -d local/lib/libcurvesntl.so" e.g. shows:
...
0x0000000000000001 (NEEDED) Shared library: [libntl.so]
0x0000000000000001 (NEEDED) Shared library: [libgmp.so.3]
0x0000000000000001 (NEEDED) Shared library: [libpari-
gmp-2.4.so.3]
0x0000000000000001 (NEEDED) Shared library: [libjcntl.so]
0x0000000000000001 (NEEDED) Shared library: [libstdc++.so.
6]
0x0000000000000001 (NEEDED) Shared library: [libm.so.6]
0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.
1]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
...)

(Though PARI is also unnecessarily linked to /some/ of the libraries
provided by ECLIB, i.e. ECLIB's Makefile(s) could be "simplified" or
improved as well to not link PARI to all of them, cf. #9914 [1].)


-Leif

[1] http://trac.sagemath.org/sage_trac/ticket/9914#comment:5 ff.

[John Cremona]

OK, I understand. If you had CC'd me into the discussion at #9914 I
could have helped (not all external spkgs' authors are Sage developers
too, but some are!).

The only functions which directly call libpari are in my base lib
called libjc. all the other code calls functions in libjc. But I
always thought that I had to link in libpari as well to get workable
binaries. Is that wrong?

Incidentally there is a linear dependence lbjc <-- libqcurves <--
librank <-- libg0n. I could reorganise things so that there was a
single library, but that would require changing habits of around 15
years....

John

[leif]

On 26 Okt., 22:51, John Cremona <john.crem...@gmail.com> wrote:
> OK, I understand.  If you had CC'd me into the discussion at #9914 I
> could have helped (not all external spkgs' authors are Sage developers
> too, but some are!).

Ok, I don't remember, perhaps I didn't want to bother you with
that... :)

(I was certainly aware you are also listed as one of the ECLIB spkg
maintainers, but the extension modules were written or changed by a
couple of people.)

> The only functions which directly call libpari are in my base lib
> called libjc.  all the other code calls functions in libjc.  But I
> always thought that I had to link in libpari as well to get workable
> binaries.  Is that wrong?

Only if you build the libraries that *directly* use PARI, or
*statically* linked executables (which are "self-contained").

Georg Weber said on Windows one also has to specify *all* libraries
that a DLL directly *or indirectly* depends on (i.e. the "transitive
closure") when building a DLL (Windows shared library), but this seems
to not be the case for extension modules on Cygwin, as there
apparently are counter-examples in the current module_list.py.
(sage.libs.cremona.mat is one of them IIRC.)

(Also, at least the GNU linker has an option "--as-needed" (for at
least ELF), which causes the linker to only record those libraries
specified on the command line that are actually used, and omits
superfluous ones.)

For Linux, Fedora 13 just recently introduced the requirement to at
all specify directly used (shared) libraries even if some other
library linked against already has it as a dependency, which is of
course much cleaner and more robust. (The same applies to Makefile
rules; there are sometimes less obvious [direct] dependencies only
fulfilled by indirect ones, which potentially causes trouble when the
dependencies of direct or indirect prerequisites change.)


Sorry for further abusing the thread, perhaps we should continue at
#9914 if needed.


-Leif

[leif]

Minh Nguyen wrote:
> Hi Leif,

>
> On Wed, Oct 27, 2010 at 6:57 AM, leif <not.r...@online.de> wrote:
>> http://www.sagemath.org/doc/developer/walk_through.html#submitting-a-change
>>
>> does not even mention one can use longer commit messages. ("hg log"
>> only shows the first line, while "hg log -v" shows the full commit
>> message, along with the files modified by a changeset.)
>

> I envision the walk-through to be a first required reading for any
> (new) Sage contributor. This means that one should be able to read
> through it in about an hour (more or less) and absorb the important
> information. A new contributor should not be exposed to too much
> information or details about Mercurial, Sage development guidelines,
> coding guidelines, etc. on a first or second reading of the
> walk-through. That's the job of the other chapters following the
> walk-through. For further explanatory information, the walk-through
> should provide links to other chapters or sections in the Developer's
> Guide that contain that related information. For example, for advanced
> Mercurial tips/tricks on working with the Sage library, there could be
> a section outside of the walk-through devoted to this. If you open a
> ticket and upload something along this line, I promise to review it
> this weekend. Otherwise, I could write something and upload a patch
> during this weekend.

Yes. It's just that it currently sounds like "one *must not* use commit
messages exceeding one line".

Of course the first line should be a brief summary (and shouldn't be
[much] longer than 80 characters), but we could add a note there that
longer descriptions *below* are welcome.

Cheers,

-Leif

[leif]

On 27 Okt., 05:56, leif <not.rea...@online.de> wrote:
> Minh Nguyen wrote:
> > Hi Leif,
>

> > On Wed, Oct 27, 2010 at 6:57 AM, leif <not.rea...@online.de> wrote:
> >>http://www.sagemath.org/doc/developer/walk_through.html#submitting-a-...

>
> >> does not even mention one can use longer commit messages. ("hg log"
> >> only shows the first line, while "hg log -v" shows the full commit
> >> message, along with the files modified by a changeset.)
>
> > I envision the walk-through to be a first required reading for any
> > (new) Sage contributor. This means that one should be able to read
> > through it in about an hour (more or less) and absorb the important
> > information. A new contributor should not be exposed to too much
> > information or details about Mercurial, Sage development guidelines,
> > coding guidelines, etc. on a first or second reading of the
> > walk-through. That's the job of the other chapters following the
> > walk-through. For further explanatory information, the walk-through
> > should provide links to other chapters or sections in the Developer's
> > Guide that contain that related information. For example, for advanced
> > Mercurial tips/tricks on working with the Sage library, there could be
> > a section outside of the walk-through devoted to this. If you open a
> > ticket and upload something along this line, I promise to review it
> > this weekend. Otherwise, I could write something and upload a patch
> > during this weekend.
>
> Yes. It's just that it currently sounds like "one *must not* use commit
> messages exceeding one line".
>
> Of course the first line should be a brief summary (and shouldn't be
> [much] longer than 80 characters), but we could add a note there that
> longer descriptions *below* are welcome.

P.S.: Perhaps also add an example of how to change the editor to
the .hgrc template, since 'vi[m]' seems to be the default on many
systems, but apparently many people aren't familiar with such an
editor.

(Karl-Dieter said he was quite confused by that, and "always [has] to
remember to first press 'i', type the message, then <Esc> and ':wq' ".
I understand that's uncommon to people used to GUI editors.)


-Leif