[sage-devel] Re: libm4ri issues with non-GNU/x86 environments.
Hi David, I am working through my todo list and thus revisited this thread. Right now, I am not sure what I can do to help you to fix the problems you identified (due to lack of knowledge about the platforms in question) On the other hand, I am very interested in making M4RI truly cross-platform. I guess what I am saying is: if there is anything I should do to fix this, let me know and I will take a look. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _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: libm4ri issues with non-GNU/x86 environments.
On Oct 27, 11:34 am, Martin Albrecht m...@informatik.uni-bremen.de wrote: Hi David, I am working through my todo list and thus revisited this thread. Right now, I am not sure what I can do to help you to fix the problems you identified (due to lack of knowledge about the platforms in question) On the other hand, I am very interested in making M4RI truly cross-platform. I guess what I am saying is: if there is anything I should do to fix this, let me know and I will take a look. Cheers, Martin I think the test for cach size and number of CPUs should be removed from the configure script, for several reasons. From what I can gather from the autoconf list * Both macros, which you took from the auotconf macro archive, are badly written - not just in what they do, but in a very general sence. * Both will never work on non-x86 platforms. * I'm told from the autoconf developers that those macros will not even work properly on many x86 processors. I asume this is mainly the one for cache size, which relies on looking up the processor type in a list of processors. As new processors are introduced, that is going to be less and less useful. * Whilst I accept that most people build Sage to run on their own machines, not everyone does. Hence deterining this at compile-time is not the best place to do it. Instead the tests should be move to run-time. From what I gather from one of the autoconf developers, the 4MRI library uses OpenMP. There is code in OpenMP which can determine the number of processors at run- time. I've not looked at this in any detail, but a quick glace on an OpenMP tutorial https://computing.llnl.gov/tutorials/openMP/#OMP_SET_NUM_THREADS shows things like: ** #include omp.h int omp_get_num_procs(void) Returns the number of processors that are available to the program. ** I suspect the cache size will be more difficult to obtain, but findining cache size is the sort of task that computer science students do to find out the characteristics of the processors they are running on. Ultimatey, some run-time test is probably best. I do not know the details, but I can imagine that reading/writing randomlly to an array would slow dramatically once the size of the array exceeds the cache size. Either way, I would give the user the option to override an automatically determined value. In particular, you might want to consider limiting the number of processors used by default to some number such as 8. I made this point some time back, about a patch commited to Sage, which was later changed. My point is that if a machine has more than 8 CPUs, it is highly likely to be a shared system, and an individual should not be putting such a heavy load on the machine. Instead, limit the number of procesors used to 8, but give a user an option to set it to any number they want. If you can get some code together I can certainly try it on a number of multi-processor machines I have access to. I can give you access to the HP C3600 running HP-UX 11.11. But ultimatley, to make this cross platform, any lookup of processor types is going to be a nightmare as new CPUs are introduced. 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: libm4ri issues with non-GNU/x86 environments.
I think the test for cach size and number of CPUs should be removed from the configure script, for several reasons. From what I can gather from the autoconf list * Both macros, which you took from the auotconf macro archive, are badly written - not just in what they do, but in a very general sence. * Both will never work on non-x86 platforms. * I'm told from the autoconf developers that those macros will not even work properly on many x86 processors. I asume this is mainly the one for cache size, which relies on looking up the processor type in a list of processors. As new processors are introduced, that is going to be less and less useful. * Whilst I accept that most people build Sage to run on their own machines, not everyone does. Hence deterining this at compile-time is not the best place to do it. Instead the tests should be move to run-time. From what I gather from one of the autoconf developers, the 4MRI library uses OpenMP. There is code in OpenMP which can determine the number of processors at run- time. I've not looked at this in any detail, but a quick glace on an OpenMP tutorial https://computing.llnl.gov/tutorials/openMP/#OMP_SET_NUM_THREADS shows things like: *** *** #include omp.h int omp_get_num_procs(void) Returns the number of processors that are available to the program. *** *** I suspect the cache size will be more difficult to obtain, but findining cache size is the sort of task that computer science students do to find out the characteristics of the processors they are running on. Ultimatey, some run-time test is probably best. I do not know the details, but I can imagine that reading/writing randomlly to an array would slow dramatically once the size of the array exceeds the cache size. Either way, I would give the user the option to override an automatically determined value. In particular, you might want to consider limiting the number of processors used by default to some number such as 8. I made this point some time back, about a patch commited to Sage, which was later changed. My point is that if a machine has more than 8 CPUs, it is highly likely to be a shared system, and an individual should not be putting such a heavy load on the machine. Instead, limit the number of procesors used to 8, but give a user an option to set it to any number they want. If you can get some code together I can certainly try it on a number of multi-processor machines I have access to. I can give you access to the HP C3600 running HP-UX 11.11. But ultimatley, to make this cross platform, any lookup of processor types is going to be a nightmare as new CPUs are introduced. I tend to agree with your point when it comes to the number of CPUs, that probably should be run-time instead of compile time. Btw. I just checked, this information isn't even used! This is now: http://bitbucket.org/malb/m4ri/issue/16/remove-check-for-number-of-cpus-from- autoconf Wrt the cache size I am not convinced. I see the problems you point out, but having the values as compile time constants should be make a difference, I should double check this though. Also, running this check on every library load seems like overkill to me. I will implement something dynamic which can be used at compile time instead of the hardcoded checks which we use right now. http://bitbucket.org/malb/m4ri/issue/17/implement-dynamic-run-time-check-for- l1-and-l2-cache Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _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: libm4ri issues with non-GNU/x86 environments.
2009/10/27 Martin Albrecht m...@informatik.uni-bremen.de: I tend to agree with your point when it comes to the number of CPUs, that probably should be run-time instead of compile time. Btw. I just checked, this information isn't even used! This is now: http://bitbucket.org/malb/m4ri/issue/16/remove-check-for-number-of-cpus-from- autoconf Someone on the autoconf mailing list pointed out you did not actually use the number! But it looks as though getting the number of CPUs at runtime will be easy and will actually work. The autoconf does not work on my Solaris (SPARC processors ) or my HP-UX (PA-RISC processor). Wrt the cache size I am not convinced. I see the problems you point out, but having the values as compile time constants should be make a difference, I should double check this though. Also, running this check on every library load seems like overkill to me. Agreed. Perhaps it is possible to compile a library 4 times - say for 1, 2, 4 and 8 MB caches, then select the right one at run-time. An attempt to determine processor type will always be difficult, as new processors keep coming out. I will implement something dynamic which can be used at compile time instead of the hardcoded checks which we use right now. http://bitbucket.org/malb/m4ri/issue/17/implement-dynamic-run-time-check-for- l1-and-l2-cache Cheers, Martin Let me know when you have something. I'll give it a try on my SPARCs (single, dual and quad processor, and my OpenSolaris Xeon box (quad core, 8 threads). 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: libm4ri issues with non-GNU/x86 environments.
On Wednesday 14 October 2009, Dr. David Kirkby wrote: libm4ri has two issues that I am aware of as soon as one tries to use a non-GNU or non-86 environment. I believe the developers hang out here, so I'll put a bit of information here, on the hope they see it. 1) Despite the fact Sun's C compiler can compile thousands of lines of Sage without any problem, libm4ri's configure script says the compiler can't create executables: http://sagetrac.org/sage_trac/ticket/7037 This is clearly is a bug that needs fixing. Plenty of other configure scripts have checked the compiler and decides it works. I am the maintainer of this package and I am interested in fixing this. However, since I think the configure.in is quite standard I am not sure how. 2) On HP-UX, the configure script can't work out how many CPUs I have, what sort they are, but then tries to determine the cache size. This causes the configure script to break. The macro for determining the number of CPUs http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m 4/ax_count_cpus.m4 is clearly only designed to work on linux and Mac. So it will fail on other platforms, including Solaris which is supported, and HP-UX which is not. It should fail gracefully, doesn't it? The macro for determining cache sizes will only work on x86 CPUs. It should fail gracefully? It seems to me there are two issues here. 1) The code for checking the C compiler is broken. 2) Code for checking CPU-related things should only be done on platforms where the macros work. It would clearly be very difficult to rewrite the macros to work on every platform, but it should not be so hard to ensure the macros are only called on platforms where they will work. One way to do this would probably be to executed bits of code only if certain preprocessor items are defined. I believe there is an autoconf macro which will determine if for example __hpux__ is defined, in which case execute code for HP-UX. I don't mind having a go at refining the macro for computing the number of CPUs, so it at least work on Solaris, AIX and HP-UX. Great, that would be very much appreciated! Cache sizes is not something I want to get into. I think it would be sensible to just report 1 MB or something like that. We fix default values but only later in the code. We could report default values in configure as well. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _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: libm4ri issues with non-GNU/x86 environments.
Martin Albrecht wrote: On Wednesday 14 October 2009, Dr. David Kirkby wrote: libm4ri has two issues that I am aware of as soon as one tries to use a non-GNU or non-86 environment. I believe the developers hang out here, so I'll put a bit of information here, on the hope they see it. 1) Despite the fact Sun's C compiler can compile thousands of lines of Sage without any problem, libm4ri's configure script says the compiler can't create executables: http://sagetrac.org/sage_trac/ticket/7037 This is clearly is a bug that needs fixing. Plenty of other configure scripts have checked the compiler and decides it works. I am the maintainer of this package and I am interested in fixing this. However, since I think the configure.in is quite standard I am not sure how. I'll take a look. libm4ri is to my knowledge the only program which thinks the Sun compiler is broken. 2) On HP-UX, the configure script can't work out how many CPUs I have, what sort they are, but then tries to determine the cache size. This causes the configure script to break. The macro for determining the number of CPUs http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain;f=m 4/ax_count_cpus.m4 is clearly only designed to work on linux and Mac. So it will fail on other platforms, including Solaris which is supported, and HP-UX which is not. It should fail gracefully, doesn't it? The configure script does fail gracefully on HP-UX when it tries to determine the number of CPUs. checking the number of available CPUs... unable to detect (assuming 1) checking the number of available CPUs... unable to detect (assuming 1) It should not take too much effort to actually get a number, so it does not have to assume 1. There is a question about what do you want - is it physical processors, cores or hardware threads? I'm not really sure the best way to do this. On the Sun T5240 (t2.math), there are two physical processors, 16 cores and 128 threads. So what number do we want - 2, 16 or 128? I suspect cores is the most useful one, to have, but I'm not sure how to get that information. The macro for determining cache sizes will only work on x86 CPUs. It should fail gracefully? I agree it should fail gracefully, but it does not on HP-UX 11.11, as it appears to be multiplying 'unknown' by 1024. This machine does have 1 CPU. checking the number of available CPUs... unable to detect (assuming 1) checking the number of available CPUs... unable to detect (assuming 1) checking for x86 cpuid 0x0 output... unknown checking for the processor vendor... Unknown checking the L1 cache size... ./configure[12992]: unknown*1024: The specified number is not valid for this command. Make: No arguments or description file. Stop. Error building libm4ri real0m18.971s user0m10.570s sys 0m5.790s sage: An error occurred while installing libm4ri-20090617 On a dual processor machine running Solaris 10, the data is not gathered properly, but at least it does not exit. checking the number of available CPUs... unable to detect (assuming 1) checking the number of available CPUs... unable to detect (assuming 1) checking for x86 cpuid 0x0 output... unknown checking for the processor vendor... Unknown checking the L1 cache size... 0 Bytes checking the L2 cache size... 0 Bytes Why it should fail on HP-UX but not on Solaris I do not know. But the failure on HP-UX has highlighted the fact the code only works on x86, so we can address that. I don't mind having a go at refining the macro for computing the number of CPUs, so it at least work on Solaris, AIX and HP-UX. Great, that would be very much appreciated! Leave that bit with me. I've just asked on relevant newsgroups on how to get the data on AIX and HP-UX. Solaris I know anyway. Once I get that, I'll do it. I would add there is some pretty negative comments about that macro for determining the number of CPUs in the autoconf macro archive. Clearly it is badly written. I think the way to approach it will be me re-write it, then get some of the experts there to go over it. 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: libm4ri issues with non-GNU/x86 environments.
2) On HP-UX, the configure script can't work out how many CPUs I have, what sort they are, but then tries to determine the cache size. This causes the configure script to break. The macro for determining the number of CPUs http://git.savannah.gnu.org/gitweb/?p=autoconf-archive.git;a=blob_plain; f=m 4/ax_count_cpus.m4 is clearly only designed to work on linux and Mac. So it will fail on other platforms, including Solaris which is supported, and HP-UX which is not. It should fail gracefully, doesn't it? The configure script does fail gracefully on HP-UX when it tries to determine the number of CPUs. checking the number of available CPUs... unable to detect (assuming 1) checking the number of available CPUs... unable to detect (assuming 1) It should not take too much effort to actually get a number, so it does not have to assume 1. There is a question about what do you want - is it physical processors, cores or hardware threads? I'm not really sure the best way to do this. On the Sun T5240 (t2.math), there are two physical processors, 16 cores and 128 threads. So what number do we want - 2, 16 or 128? I suspect cores is the most useful one, to have, but I'm not sure how to get that information. I agree cores should be the most useful one for now. Basically, whatever has L1 cache should be returned. Its all about cache for M4RI. I would add there is some pretty negative comments about that macro for determining the number of CPUs in the autoconf macro archive. Clearly it is badly written. I think the way to approach it will be me re-write it, then get some of the experts there to go over it. I agree it is not a nice script, I just lack the proper autotools skills to make it really nice. Maybe those experts will help :) Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _otr: 47F43D1A 5D68C36F 468BAEBA 640E8856 D7951CCF _www: http://www.informatik.uni-bremen.de/~malb _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: libm4ri thinks the Sun C compiler is broken
Dr. David Kirkby wrote: Using * Solaris 10 update 7 on SPARC * sage-4.1.2.alpha2 * Sun Studio 12.1 * An updated configure script to allow the Sun compiler to be used http://sagetrac.org/sage_trac/ticket/7021 CC was set to the Sun C compiler. Despite thousands of lines of C code being built, libm4ri decides the Sun C compiler is broken: checking for style of include used by make... GNU checking for gcc... /opt/xxxsunstudio12.1/bin/cc checking for C compiler default output file name... configure: error: in `/export/home/drkirkby/sage/gcc32/sage-4.1.2.alpha2/spkg/build/libm4ri-20090617/src': configure: error: C compiler cannot create executables See `config.log' for more details. Error configuring libm4ri I forgot to add, this is http://sagetrac.org/sage_trac/ticket/7037 --~--~-~--~~~---~--~~ 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: libm4ri
I plan to upgrade png in 3.2.2 and will also attempt to do the upgrade to fplll 3.0.x. I guess if malb is ok with the rename we could also change the name next time he releases an updated version. I named it libm4ri because this naming scheme is consistent with what Debian does (usually these naming conventions are somewhat consistent across Linux distributions). I do agree that the inconsistency should be fixed, e.g. we have ntl...spkg but libm4ri...spkg. I would vote for renaming every C/C++ library to libNAME...spkg though. However, I don't really care deeply. Cheers, Martin -- name: Martin Albrecht _pgp: http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0x8EF0DC99 _www: http://www.informatik.uni-bremen.de/~malb _jab: [EMAIL PROTECTED] --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libm4ri
On Dec 1, 8:40 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I just noticed for m4ri the package is called libm4ri-*.spkg. Any reason this isn't m4ri-*.spkg? That is the name malb gave it initially and it just stuck. The same applies for libfplll.spkg, too. - Robert Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libm4ri
On Dec 1, 2008, at 8:42 PM, mabshoff wrote: On Dec 1, 8:40 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I just noticed for m4ri the package is called libm4ri-*.spkg. Any reason this isn't m4ri-*.spkg? That is the name malb gave it initially and it just stuck. The same applies for libfplll.spkg, too. Well, could I propose we change it? - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libm4ri
On Dec 1, 8:51 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Dec 1, 2008, at 8:42 PM, mabshoff wrote: On Dec 1, 8:40 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I just noticed for m4ri the package is called libm4ri-*.spkg. Any reason this isn't m4ri-*.spkg? That is the name malb gave it initially and it just stuck. The same applies for libfplll.spkg, too. Well, could I propose we change it? Fine by me, it could be done with a little magic to deps. But why would you want to do so? For m1ri I would guess? - Robert Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libm4ri
On Dec 1, 2008, at 8:54 PM, mabshoff wrote: On Dec 1, 8:51 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Dec 1, 2008, at 8:42 PM, mabshoff wrote: On Dec 1, 8:40 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I just noticed for m4ri the package is called libm4ri-*.spkg. Any reason this isn't m4ri-*.spkg? That is the name malb gave it initially and it just stuck. The same applies for libfplll.spkg, too. Well, could I propose we change it? Fine by me, it could be done with a little magic to deps. But why would you want to do so? For m1ri I would guess? Just for consistency. I actually had trouble finding it (first looked for m*, then unpacked linbox to see if it was in there...) - Robert --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
[sage-devel] Re: libm4ri
On Dec 1, 9:11 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Dec 1, 2008, at 8:54 PM, mabshoff wrote: On Dec 1, 8:51 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: On Dec 1, 2008, at 8:42 PM, mabshoff wrote: On Dec 1, 8:40 pm, Robert Bradshaw [EMAIL PROTECTED] wrote: I just noticed for m4ri the package is called libm4ri-*.spkg. Any reason this isn't m4ri-*.spkg? That is the name malb gave it initially and it just stuck. The same applies for libfplll.spkg, too. Well, could I propose we change it? Fine by me, it could be done with a little magic to deps. But why would you want to do so? For m1ri I would guess? Just for consistency. I actually had trouble finding it (first looked for m*, then unpacked linbox to see if it was in there...) Ok, currently we have the following in the tree: Sprocketer:~ michaelabshoff$ cd Desktop/sage-3.2.1.rc1-qf/spkg/ standard/ Sprocketer:standard michaelabshoff$ ls -al *lib* -rw-r--r--@ 1 michaelabshoff staff 272776 Nov 26 22:28 cddlib-094b.p3.spkg -rw-r--r--@ 1 michaelabshoff staff 1593104 Nov 26 22:28 eclib-20080310.p7.spkg -rw-r--r--@ 1 michaelabshoff staff 293382 Nov 26 22:28 libfplll-2.1.6-20071129.p5.spkg -rw-r--r--@ 1 michaelabshoff staff 970913 Nov 26 22:28 libgcrypt-1.4.0.p2.spkg -rw-r--r--@ 1 michaelabshoff staff 383786 Nov 26 22:28 libgpg_error-1.6.p0.spkg -rw-r--r--@ 1 michaelabshoff staff 713789 Nov 26 22:28 libm4ri-20080909.spkg -rw-r--r--@ 1 michaelabshoff staff 626176 Nov 26 22:28 libpng-1.2.22.p8.spkg -rw-r--r--@ 1 michaelabshoff staff 4832798 Nov 26 22:28 matplotlib-0.98.3.p3.spkg -rw-r--r--@ 1 michaelabshoff staff 436207 Nov 26 22:28 zlib-1.2.3.p4.spkg I plan to upgrade png in 3.2.2 and will also attempt to do the upgrade to fplll 3.0.x. I guess if malb is ok with the rename we could also change the name next time he releases an updated version. I think we can eliminate libgpg_error and libgcrypt since gnutls these days contains its own copy of those two libraries and builds them on demand when it does not detect them externally. Having the in tree versions is certainly a good thing since less can go wrong. So if we do this we can do some cleanup and reducing the number of spkgs is always a good thing IMHO. :) Does anybody else have an opinion? If we do this I can open tickets for the various tasks that need to be done. - Robert Cheers, Michael --~--~-~--~~~---~--~~ To post to this group, send email to sage-devel@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sage-devel URLs: http://www.sagemath.org -~--~~~~--~~--~--~---
