flint-1.5.0.p5's extraneous #includes break typedef ulong in sys/types.h

[dimpase]

flint-1.5.0.p5 does not build on a recent Cygwin (1.7.9)
due to Cygwin having ulong defined as type in
/usr/include/sys/types.h. This results in

gcc -std=c99 -I/home/dima/sage-4.7.alpha5/local/include/ -I/home/dima/sage-4.7.a
lpha5/local/include  -fPIC -funroll-loops   -O2 -c ZmodF_mul.c -o ZmodF_mul.o
ZmodF_mul.c:1: warning: -fPIC ignored for target (all code is position independe
nt)
In file included from /usr/include/stdio.h:46,
                 from ZmodF_poly.h:40,
                 from ZmodF_mul.c:34:
/usr/include/sys/types.h:101: error: duplicate `unsigned'
make[2]: *** [ZmodF_mul.o] Error 1

note that
/usr/include/sys/types.h:101
is

typedef unsigned long   ulong;          /* System V compatibility */

ulong is a macro in flint, defined in two places, for some reason:
in flint.h and in profiler.h

Cause:

The header inclusion order in ZmodF_mul.c
does #include ZmodF_poly.h (which includes stdio.h, which in turn
includes sys/types.h containing the typedef for ulong)
after ZmodF.h, which includes flint.h containing #define ulong
Thus the typedef is nuked, and there is no way around it with the
given header order.

The 1st bug is in ZmodF_mul.c, which does not need to include ZmodF.h
at all,
as it is included in ZmodF_poly.h

The 2nd bug like this is in mpn_extras.h, where the inclusion of
flint.h is not needed
---and this nukes ZmodF_mul-tuning.c

The 3rd bug like this is in ZmodF_poly.c, which needs to include
neither flint.h nor memory-manager.h

See http://groups.google.com/group/sage-windows/browse_thread/thread/294895626ba6faf1

New spkg: http://boxen.math.washington.edu/home/jdemeyer/spkg/flint-1.5.0.p7.spkg

CC: @sagetrac-drkirkby @nexttime

Component: packages: standard

Author: Dima Pasechnik, Jeroen Demeyer

Reviewer: Karl-Dieter Crisman, Leif Leonhardy

Merged: sage-4.7.2.alpha0

Issue created by migration from https://trac.sagemath.org/ticket/11246

[wbhart]

comment:2

FLINT_ASSERT is defined in flint.h and flint_heap_alloc is defined in memory-manager.h.

I think the given fix compiles only because the headers are picked up via other inclusions.

A fix that seems to work for me is to guard the inclusion of system headers as follows:

#undef ulong
#include <stdlib.h>
#define ulong unsigned long

Note that the flint-1.6 release notes say:

• Better Cygwin support

though I don't know if this particular issue is fixed or not. It may be only be an issue with more recent Cygwin than what I tested with.

[dimpase]

comment:3

Replying to @wbhart:

FLINT_ASSERT is defined in flint.h and flint_heap_alloc is defined in memory-manager.h.

I think the given fix compiles only because the headers are picked up via other inclusions.

A fix that seems to work for me is to guard the inclusion of system headers as follows:

#undef ulong
#include <stdlib.h>
#define ulong unsigned long

I tried this and it did not work.

Another option would be to add double inclusion guards.

Note that the flint-1.6 release notes say:

• Better Cygwin support

though I don't know if this particular issue is fixed or not. It may be only be an issue with more recent Cygwin than what I tested with.

Indeed, it's recent.

[sagetrac-drkirkby]

comment:4

It would really help if flint did not use "ulong" and switched to using "unsigned long". The use of "ulong" is likely to cause many problems - it is even a reserved word in C#. Just Google "ulong" and you will find other systems using this, so using "ulong" is likely to cause issues.

Dave

[dimpase]

comment:5

Replying to @dimpase:

I tried this and it did not work.

PS. I must have missed an #include somewhere when I tried this. Taking special precautions before doing an #include<std*.h> appears to be a last resort...

Anyhow, the patch I have here works, and it removes unneeded
duplicate inclusions from the code, rather than adds more lines. What are objections to it?

[dimpase]

comment:6

Replying to @sagetrac-drkirkby:

It would really help if flint did not use "ulong" and switched to using "unsigned long". The use of "ulong" is likely to cause many problems - it is even a reserved word in C#. Just Google "ulong" and you will find other systems using this, so using "ulong" is likely to cause issues.

One would rather rename ulong to Ulong. (or even to oolong :-))

I'd rather ask why a preprocessor macro is used in place of a typedef, which ought to be preferred over #define whenever possible, IMHO.

[dimpase]

comment:7

Replying to @wbhart:

Note that the flint-1.6 release notes say:

• Better Cygwin support

though I don't know if this particular issue is fixed or not. It may be only be an issue with more recent Cygwin than what I tested with.

1.6 suffers from the same issue:

...
cc -std=c99 -I -I   -g -O2 -c ZmodF_mul.c -o ZmodF_mul.o
In file included from /usr/include/stdio.h:46,
                 from ZmodF_poly.h:40,
                 from ZmodF_mul.c:34:
/usr/include/sys/types.h:101: error: duplicate `unsigned'
make: *** [ZmodF_mul.o] Error 1

dima@SPMS-DIMA-W7 /tmp/flint-1.6

to get that far when compiling, I needed to remove quite a bit of
"error: redeclaration of `i' with no linkage" in QS/mp_linear_algebra.c and QS/mp_sieve.c

E.g:

QS/mp_linear_algebra.c: In function `insert_lp_relation':
QS/mp_linear_algebra.c:334: error: redeclaration of `i' with no linkage
QS/mp_linear_algebra.c:329: error: previous declaration of `i' was here

the reason for that is rather than writing

 for (unsigned long i = 0; ...

which restricts the scope of i to the for loop, you write

 unsigned long i;
 for (i = 0; ...

there, in many places. Well, maybe some weird compiler can accept this, but gcc does not...

[kcrisman]

comment:8

Dima, is that a Windows 7 problem only? I am trying on XP with Cygwin 1.7.3 and did not have any problems building flint.

[dimpase]

comment:9

Replying to @kcrisman:

Dima, is that a Windows 7 problem only? I am trying on XP with Cygwin 1.7.3 and did not have any problems building flint.

Hi,
you need a more recent Cygwin!
Dima

[kcrisman]

comment:10

I misunderstood - I thought you meant Cygwin 1.6, not flint 1.6. Ok.

[kcrisman]

Author: Dima Pasechnik

[kcrisman]

comment:11

Just a question about the changes - I think I understand getting rid of the files in patch and substituting the .patch files, but I don't see how makepatchfiles is ever used. Was that just a utility you cooked up to make all the patches? I don't know whether that belongs in the spkg or not - I guess it doesn't hurt, but maybe that should be more universal.

Anyway, I'm trying this out soon on W7.

[dimpase]

comment:12

Replying to @kcrisman:

Just a question about the changes - I think I understand getting rid of the files in patch and substituting the .patch files, but I don't see how makepatchfiles is ever used. Was that just a utility you cooked up to make all the patches? I don't know whether that belongs in the spkg or not - I guess it doesn't hurt, but maybe that should be more universal.

indeed, makepatchfiles is a script to create these files, and I use it manually whenever I update the spkg. I have such a
file in at least one more package (cvxopt).

[kcrisman]

Reviewer: Karl-Dieter Crisman

[kcrisman]

comment:13

This works on XP - Flint builds. Since for now we are only focusing on building :) then this just needs testing on a few other platforms, though it seems you have already done this. Still Solaris?

[kcrisman]

comment:14

Replying to @kcrisman:

This works on XP - Flint builds. Since for now we are only focusing on building :)

Sorry, I meant this builds on Windows 7 in addition to XP where this was not a problem.

[kcrisman]

comment:15

Replying to @kcrisman:

Replying to @kcrisman:

This works on XP - Flint builds. Since for now we are only focusing on building :)

Sorry, I meant this builds on Windows 7 in addition to XP where this was not a problem.

Because of an old Cygwin, presumably.

[kcrisman]

comment:16

I think this deserves positive review. Relevant tests pass on Mac and sage.math after this upgrade.

I am unable to test this on Solaris, so this is the only potential problem I see, but I don't see any reason it shouldn't work, if getting rid of a few ulong things is better.

[nexttime]

comment:18

I know the FLINT spkg is currently a mess anyway, but

• (in general) please add the ticket number to commit messages, and limit SPKG.txt lines to 80 columns;

• the patches are applied without any error checking.

[kcrisman]

comment:19

Replying to @nexttime:

I know the FLINT spkg is currently a mess anyway, but

• (in general) please add the ticket number to commit messages, and limit SPKG.txt lines to 80 columns;

Interestingly, I was just chewed out on another ticket for having cut some lines in that file down to size! It's true that the new lines are just a little over that, apparently.

• the patches are applied without any error checking.

You mean

+for j in `ls patches/*.patch` ; do  
+   patch -p0 < $j 
+done 

Do we ever do error checking for these? Most spkg-install files seem to have just "cp" or "patch". What should be added?

[dimpase]

comment:20

Replying to @kcrisman:

Replying to @nexttime:

I know the FLINT spkg is currently a mess anyway, but

• (in general) please add the ticket number to commit messages, and limit SPKG.txt lines to 80 columns;

Interestingly, I was just chewed out on another ticket for having cut some lines in that file down to size! It's true that the new lines are just a little over that, apparently.

• the patches are applied without any error checking.

You mean

+for j in `ls patches/*.patch` ; do  
+   patch -p0 < $j 
+done 

Do we ever do error checking for these? Most spkg-install files seem to have just "cp" or "patch". What should be added?

IMHO there is no need to check in spkg-install that patches apply correctly --- going this way, one woud also could start asking for a check that tar worked correctly, etc...

[nexttime]

comment:21

Replying to @dimpase:

Replying to @kcrisman:

Interestingly, I was just chewed out on another ticket for having cut some lines in that file down to size! It's true that the new lines are just a little over that, apparently.

Of course you shouldn't cut them, but reformat the text such that none of the lines will exceed 80 characters (same for longer, i.e. all but the first line of commit messages). ;-)

If doing so would dominate other, more important changes in the diff, you can still provide a separate patch for that. (There is no patch or spkg-diff for review attached to this ticket anyway.)

Dave, me, and others have reformatted any SPKG.txt we came across in the past in case it was necessary. Once overlong lines are eliminated, it's much more likely people will intuitively adhere without ever looking at their editor's status bar.

• the patches are applied without any error checking.

You mean

+for j in `ls patches/*.patch` ; do  
+   patch -p0 < $j 
+done 

Do we ever do error checking for these? Most spkg-install files seem to have just "cp" or "patch". What should be added?

IMHO there is no need to check in spkg-install that patches apply correctly --- going this way, one woud also could start asking for a check that tar worked correctly, etc...

We do of course check exit codes (or indirectly the success) of tar and other commands that can spectacularly fail...

Fortunately, we now use patch rather than cp, which at least spits out warning or error messages in case upstream and patches/* get out of sync (or someone made another mistake), but these messages are easily missed - even by a reviewer, which can lead to all kinds of obscure errors or misbehavior any time later, so we should IMHO check $? there.

bash's not Python, where we would (hopefully) get a nice, instructive traceback.

[nexttime]

comment:55

Replying to @jdemeyer:

There was a problem with Unix vs. DOS newlines in patches/mpn_extras.h.patch.

Sorry, missed that... ;-)

(Fortunately, we now check the exit code of patch. :-) )

[nexttime]

comment:56

P.S.: Latest p7 spkg now also really tested with Sage 4.7.1.alpha4 on Ubuntu 9.04 x86_64.

P.P.S.: The md5sum will (hopefully) change after the changes have been committed, so that's another argument...

[kcrisman]

comment:57

Replying to @nexttime:

Except for not having committed the changes (1 rubber point deduction), positive review from me.

As I mentioned, I'll make further changes on a follow-up for FLINT 1.5.2.

Can you take into account the (very minor) change for #11547 in that? The only substantive change is

if [ $UNAME = "CYGWIN" ]; then 
    <snip>
   CP -p libflint.so libflint.dll 

And this is necessary for Sage to start on Cygwin. I currently had that be p7, but that could be made p8 instead. I guess the point is that we would want this in any further FLINT upgrade, so that we don't have to keep making new spkgs.

[nexttime]

comment:58

Replying to @kcrisman:

Can you take into account the (very minor) change for #11547 in that? The only substantive change is

if [ $UNAME = "CYGWIN" ]; then 
    <snip>
   CP -p libflint.so libflint.dll 

Thanks for pointing me to that one. Of course I can include that (though either $CP or cp); I'll have to rebase the changes I made so far anyway.

Do you create a p8 that's based on the latest p7 here? If so, and if not on #11547, please cc me or let me know by other means.

[kcrisman]

comment:59

Do you create a p8 that's based on the latest p7 here? If so, and if not on #11547, please cc me or let me know by other means.

No, I haven't, but if I would, it would be on #11547, where you have added yourself.

[kcrisman]

comment:60

Thanks for pointing me to that one. Of course I can include that (though either $CP or cp);

Good point, but luckily the patch has $CP; I just cut and pasted it inaccurately here.

[jdemeyer]

comment:61

Replying to @nexttime:

Thanks for pointing me to that one. Of course I can include that (though either $CP or cp);

I prefer cp, I see no reason to use $CP. There was a similar discussion about $RM before in which it was decided that $RM would not be used anymore. Now $RM has been replaced by rm (or rm -f) everywhere.

[nexttime]

comment:62

Replying to @jdemeyer:

Replying to @nexttime:

Thanks for pointing me to that one. Of course I can include that (though either $CP or cp);

I prefer cp, I see no reason to use $CP.

Maybe some Cygwin -- more precisely Windoofs -- flavour... :D

There was a similar discussion about $RM before in which it was decided that $RM would not be used anymore. Now $RM has been replaced by rm (or rm -f) everywhere.

I know, a long lasting discussion. (And the main reason for unsetting it was just a change in autotools which caused some trivial trouble, otherwise using variables might not be necessary, but is always more flexible, since that way one doesn't have to set up special PATHs to build or use Sage. I'm btw. still in favour of supporting ~/.sagerc and perhaps SAGERC, not to mention using SAGE_CC, SAGE_CFLAGS etc. instead of CC, CFLAGS, since one never knows where the latter come from, meaning if they've intentionally been set [for Sage], and -- more important -- whether they've been set by the user or by some Sage script...)

[nexttime]

comment:63

Replying to @dimpase:

IMHO, this discussion just highlights a need to revamp the whole spkg system, for 99% of the standard spkgs, at least.
It would be much better if the whole non-building part of the spkg install is done in a uniform way, by hg, say,
rather than handwritten scripts...

The need for the current spkg system is dictated by the need of some optional parts of Sage, that demand, say, a distribution in an unmodified form. Yet, putting the spkg source under hg is not a modification. Sage can distribute spkg source with the hg tree, and Sage-needed patches as patches to be applied by an spkg-install.

If I understand you correctly (having the whole upstream tree under revision control), that would heavily increase their sizes.

I'd rather vote for splitting off the whole vanilla source trees (src/) and ship them as separate tarballs (perhaps just repackaged with tar and bzip2), along with cut-down Sage-source only .spkg files (preferably with a new extension, say .spi).

sage-spkg then could take care of the upstream packages, putting their appropriate, corresponding versions into place before calling spkg-install, i.e. extracting them into src/, such that we would not even have to change anything in the existing spkg-install and spkg-check files, the Sage part of spkgs.

That way, we could even have a single spkg (or "spi") repository, which would greatly ease working on spkgs and merging changes. Also, this would not only decrease the download size upon upgrades (assuming just Sage's patch level changed, which is often the case), but also the overall traffic when reviewing spkgs, and -- last but not least -- the "new" spkgs, which could then be ordinary Mercurial changesets to simply be applied to the spkg or "spi" repository, could be attached to the tickets and merged like any other changes to Sage, i.e. the library, scripts etc.).

Instead of e.g. foobar-x.y.z.pN.spkg, we would have foobar-x.y.z.tar.bz2 (vanilla upstream), perhaps in $SAGE_ROOT/spkg/standard/upstream, optionally but preferably a Mercurial repository in $SAGE_ROOT/spkg/standard (ignoring upstream/), and the stripped-down foobar-x.y.z.pN.spi files in $SAGE_ROOT/spkg/standard, or even just foobar-x.y.z.spi if they are under central revision control.

[dimpase]

comment:64

Replying to @nexttime:

Replying to @dimpase:

IMHO, this discussion just highlights a need to revamp the whole spkg system, for 99% of the standard spkgs, at least.
It would be much better if the whole non-building part of the spkg install is done in a uniform way, by hg, say,
rather than handwritten scripts...

The need for the current spkg system is dictated by the need of some optional parts of Sage, that demand, say, a distribution in an unmodified form. Yet, putting the spkg source under hg is not a modification. Sage can distribute spkg source with the hg tree, and Sage-needed patches as patches to be applied by an spkg-install.

If I understand you correctly (having the whole upstream tree under revision control), that would heavily increase their sizes.

Really? Why? If I look at my current $SAGEROOT/devel/sage/, I have 878Mb, while its .hg is 51Mb. And here the fact that this tree has a long history must be taken into account. A typical spkg tree would be started from a clean history, and keep it for most of the files. So it would be a pretty small increase.

[nexttime]

comment:65

Replying to @dimpase:

Replying to @nexttime:

If I understand you correctly (having the whole upstream tree under revision control), that would heavily increase their sizes.

Really? Why? If I look at my current $SAGEROOT/devel/sage/, I have 878Mb, while its .hg is 51Mb. And here the fact that this tree has a long history must be taken into account.

I don't know which files' sizes you've added up there, but, first of all, a [compressed] source tree with meta information will obviously always be larger than [a compressed] one without it (even when you check out the current versions before calling spkg-install rather than redundantly shipping them already checked out along with the repository), and second, presumably more important, you'd then in addition carry all the upstream history, which of course would grow the packages' sizes in comparison to what we have now.

[dimpase]

comment:66

Replying to @nexttime:

Replying to @dimpase:

Replying to @nexttime:

If I understand you correctly (having the whole upstream tree under revision control), that would heavily increase their sizes.

Really? Why? If I look at my current $SAGEROOT/devel/sage/, I have 878Mb, while its .hg is 51Mb. And here the fact that this tree has a long history must be taken into account.

I don't know which files' sizes you've added up there,

I just ran 'du' command on '$SAGEROOT/devel/sage/', and on '$SAGEROOT/devel/sage/.hg'.

but, first of all, a [compressed] source tree with meta information will obviously always be larger than [a compressed] one without it (even when you check out the current versions before calling spkg-install rather than redundantly shipping them already checked out along with the repository), and second, presumably more important, you'd then in addition carry all the upstream history, which of course would grow the packages' sizes in comparison to what we have now.

I am not talking about carrying around the whole upstream history, which may or may not be available. If upstream upgrades in a clean patch fashion, then it's easy to import their patches and carry them on. Otherwise we basically would throw the history away, just as we do presently, and start anew.

[nexttime]

comment:67

Replying to @dimpase:

Replying to @nexttime:

I don't know which files' sizes you've added up there,

I just ran 'du' command on '$SAGEROOT/devel/sage/', and on '$SAGEROOT/devel/sage/.hg'.

Well, then you've counted also all generated files (*.{pyc,pyo,o,so,whatever}, most of *.{c,cpp}), the complete build/ tree, and all of Sphinx's generated files beneath doc/. (Just take a look at .hgignore.)

Also, since Mercurial stores its files compressed, for a fair comparison you should have compared a compressed version of .hg/ to an equally compressed tarball or whatever of the plain / checked-out source files.

[nexttime]

comment:68

Replying to @dimpase:

I am not talking about carrying around the whole upstream history, which may or may not be available. If upstream upgrades in a clean patch fashion, then it's easy to import their patches and carry them on. Otherwise we basically would throw the history away, just as we do presently, and start anew.

Either you put src/ under revision control, or you don't. If you do, then copying a fresh, upgraded upstream tree into src/, Mercurial will record the changes relative to the previous version in Sage, whichever that was. And you'd have the same problems with possibly rebasing patches that Sage made to the previous upstream release.

Or did you mean putting src/ into a separate Mercurial repository, to be thrown away upon every upstream upgrade?

I cannot really see an advantage in either way.

[kcrisman]

comment:69

I suggest this discussion belongs on sage-devel :-) as I'm sure others have opinions as well.

[nexttime]

comment:70

Replying to @kcrisman:

I suggest this discussion belongs on sage-devel :-) as I'm sure others have opinions as well.

Just post a link to this ticket there. XD

(A BBS would IMHO be better for such discussions. The only advantage of G**gle groups over trac is that the former supports concurrent posting.)

[nexttime]

comment:71

Back on topic, for the record:

leif@portland:~/Sage/spkgs$ du -sch `find flint-1.5.0.p7/ -name .svn`
140K	flint-1.5.0.p7/src/zn_poly/test/.svn
432K	flint-1.5.0.p7/src/zn_poly/src/.svn
148K	flint-1.5.0.p7/src/zn_poly/include/.svn
76K	flint-1.5.0.p7/src/zn_poly/demo/bernoulli/.svn
44K	flint-1.5.0.p7/src/zn_poly/demo/.svn
96K	flint-1.5.0.p7/src/zn_poly/tune/.svn
140K	flint-1.5.0.p7/src/zn_poly/profile/.svn
48K	flint-1.5.0.p7/src/zn_poly/doc/.svn
1.1M	total
leif@portland:~/Sage/spkgs$ 

[nexttime]

comment:72

Again slightly off-topic, just as an example:

~/flint-1.5.0.p7$ mv src/ src-plain
~/flint-1.5.0.p7$ cp -pr src-plain/ src-hg
~/flint-1.5.0.p7$ diff -r src-plain/ src-hg/
~/flint-1.5.0.p7$ (cd src-hg/ && hg init && hg add >/dev/null && hg commit -m "initial revision")
~/flint-1.5.0.p7$ (cd src-hg/ && rm -rf *)
~/flint-1.5.0.p7$ for d in src-*; do echo -n "$d: "; tar cjf - $d | wc -c; done
src-hg: 1015130
src-plain: 754703

(With the .svn folders [still] included, which shouldn't matter here. FLINT is quite small compared to other spkgs anyway, so the absolute difference should be much? larger on average.)

[nexttime]

comment:73

P.S.: For all standard spkgs (327 MB), taking the ratio for FLINT (1.345), this would mean about +113 MB, which IMHO would be an unreasonable increase. (And that doesn't even take into account the history for changes made by Sage to upstream releases.)

[jdemeyer]

comment:74

New version with fully committed changes, same location: http://boxen.math.washington.edu/home/jdemeyer/spkg/flint-1.5.0.p7.spkg

You can use this to base a .p8 on.

[kcrisman]

comment:75

Unfortunately, because of the sage.math cluster failure, this is not currently accessible. Given that the actual relevant part of https://github.com/sagemath/sage/files/ticket11547/trac_11547-flint.diff.gz is

=== flint-1.5.0.p7 (Karl-Dieter Crisman, 28th June 2011) === 
 * Enable both libflint.dll and .so on Cygwin (see Trac 11547) 

and

-     # also name flint library correctly for MS Windows (an so won't work). 
-     mv libflint.so libflint.dll 
+    # make both kinds of dynamic libraries available for Windows 
+    $CP -p libflint.so libflint.dll

(where the $CP could change to cp)

then perhaps someone could be kind when this comes back online and make the p8 there. It would be very, very good to have all of the stuff at #6743 merged as soon as possible so we don't go backwards. I'm unfortunately about to go largely offline for about two weeks, so I will not be around when p7 becomes available (at least, I don't think I'm going to have good access).

[nexttime]

comment:76

Replying to @kcrisman:

Unfortunately, because of the sage.math cluster failure, this is not currently accessible. Given that the actual relevant part of https://github.com/sagemath/sage/files/ticket11547/trac_11547-flint.diff.gz is

=== flint-1.5.0.p7 (Karl-Dieter Crisman, 28th June 2011) === 
 * Enable both libflint.dll and .so on Cygwin (see Trac 11547) 

and

-     # also name flint library correctly for MS Windows (an so won't work). 
-     mv libflint.so libflint.dll 
+    # make both kinds of dynamic libraries available for Windows 
+    $CP -p libflint.so libflint.dll

(where the $CP could change to cp)

then perhaps someone could be kind when this comes back online and make the p8 there.

I've made a p8 with (only) these changes based on the latest p7 from here and uploaded it onto G**gle code. See #11547 for details in a few minutes; I'll also update #6743 accordingly.

It would be very, very good to have all of the stuff at #6743 merged as soon as possible so we don't go backwards. I'm unfortunately about to go largely offline for about two weeks, so I will not be around when p7 becomes available (at least, I don't think I'm going to have good access).

Well, being offline isn't always unfortunate. ;-)

Have a good time then.

[kcrisman]

comment:77

I've made a p8 with (only) these changes based on the latest p7 from here and uploaded it onto G**gle code. See #11547 for details in a few minutes; I'll also update #6743 accordingly.

Thanks, I appreciate that a lot. I keep all my spkgs on sage.math only, because I don't want to clutter up my computer, but maybe that was a bad decision this time around :) I also could use the spkg-upload code project more often, it's true...

By the way, what's up with the G**gle? Does this confuse them - and to what end? It's not like there aren't other references to said company on the Sage trac, and you are already quite good at covering your tracks - I can't find any references to you outside of Sage and a couple computer newsgroups and of course this site ;-)

Well, being offline isn't always unfortunate. ;-)

Good point. Besonders wenn man in die Heimat fliegt.

[nexttime]

comment:78

Replying to @kcrisman:

By the way, what's up with the G**gle? Does this confuse them - and to what end?

Don't know. I just can't spell it.

Well, being offline isn't always unfortunate. ;-)

Good point. Besonders wenn man in die Heimat fliegt.

Na denn guten Flug. Internet gibt's hier allerdings mancherorts. :-)

[jdemeyer]

Merged: sage-4.7.2.alpha0