On 10 Jun., 02:37, Jason Grout wrote:
> Karl-Dieter just showed me how to get the OSX App built using sage -bdist:
>
> export SAGE_APP_BUNDLE=yes
> sage -bdist 4.4.2-app
>
> There are people I know that would *love* to have a clickable app on
> OSX. Why do we not have this as a download option
On 10 June 2010 03:22, John Hunter wrote:
> On Wed, Jun 9, 2010 at 9:15 PM, John Hunter wrote:
>
>> * sys.platform != 'darwin' on the box you are building on. In this
>> case you need to modify your patch to include sys.platform. This is
>> the most likely culprit as far as I can see.
>
> Sor
On Jun 9, 2010, at 12:53 PM, Sergey Bochkanov wrote:
Hello,
thanks to all who've replied to this discussion!
Taking into account what was said above, I've decided to target
pure
ANSI C, i.e. C without newer constructs like // comments and
other
stuff from newer standards. I don't want to u
On Wed, Jun 9, 2010 at 9:15 PM, John Hunter wrote:
> * sys.platform != 'darwin' on the box you are building on. In this
> case you need to modify your patch to include sys.platform. This is
> the most likely culprit as far as I can see.
Sorry, upon rereading your post, I see you are building
On Wed, Jun 9, 2010 at 2:08 PM, Dr. David Kirkby
wrote:
>> The mpl configure happens in setupext.py that lives next to setup.py.
>> It tries to use pkgconfig if it is available to find freetype, so you
>> may have luck setting your PKG_CONFIG_PATH if you are using it.
>
> I was not using PKG_CONF
> On 10 Jun., 00:06, Alex Ghitza wrote:
> > I am not convinced that testing only libs/singular/ and
> > interfaces/singular.py is sufficient to conclude this. Functionality
> > from various parts of Singular is used all over the Sage library. I
> > would be a bit more confident if a global "make
Karl-Dieter just showed me how to get the OSX App built using sage -bdist:
export SAGE_APP_BUNDLE=yes
sage -bdist 4.4.2-app
There are people I know that would *love* to have a clickable app on
OSX. Why do we not have this as a download option on the webpage?
Thanks,
Jason
--
To post to thi
On 8 Jun., 22:14, Robert Bradshaw
wrote:
> On Jun 8, 2010, at 11:05 AM, leif wrote:
> > On 8 Jun., 19:25, Bill Hart wrote:
> >> My recommendation would be to stick with ANSI C as much as
> >> possible. I
> >> doubt comments // will be a problem.
>
> > Though many compilers (and preprocessors) s
I think this is such good news, that even those on sage-devel will not mind too
much! Building packages in parallel seems to be working very well. That said,
wtih 128 hardware threads, still only a small fraction of 't2' is being used
effectively. I've found with multi-threaded coded, around 500
On 10 Jun., 00:06, Alex Ghitza wrote:
> I am not convinced that testing only libs/singular/ and
> interfaces/singular.py is sufficient to conclude this. Functionality
> from various parts of Singular is used all over the Sage library. I
> would be a bit more confident if a global "make testlong"
On Thu, 10 Jun 2010 08:20:58 +1200, François Bissey
wrote:
> I haven't tested your new spkg but I ran
> sage -t -long devel/sage/sage/lib/singular/
> as you did in your ticket after removing everything that happens
> after installing libsingular. My notes in my ebuild are saying:
> -
> On 9 Jun., 22:20, François Bissey wrote:
> > > On 9 Jun., 13:43, François Bissey wrote:
> > I haven't tested your new spkg but I ran
> > sage -t -long devel/sage/sage/lib/singular/
> > as you did in your ticket after removing everything that happens
> > after installing libsingular. My notes in
On Wed, Jun 9, 2010 at 1:32 PM, Dr. David Kirkby
wrote:
>Can someone please close #327
David,
You've done so much for the Sage project, so I've up'd your trac
permissions. Hopefully now you can close tickets (you now have
TICKET_ADMIN).
If there are other permissions you need to get stuff done
Hi all,
If someone has a bit of spare time, a patch to upgrade mpmath to version
0.15 is waiting for review here:
http://trac.sagemath.org/sage_trac/ticket/9152
There is an spkg, and a patch for the extension module in Sage (both must be
installed simultaneously).
Fredrik
--
To post to this gr
The dependencies (spkg/standard/deps) for the sagetex package are a
little broken right now: the only listed dependency is python, but if
you have SAGE_CHECK on, then sage is run to verify that the
installation has worked. If you're lucky, the sagetex package gets
installed after sage, but there i
On 06/ 9/10 08:39 PM, leif wrote:
On 9 Jun., 18:29, Robert Bradshaw
wrote:
On Jun 9, 2010, at 9:19 AM, Dr. David Kirkby wrote:
I thought it would be useful if there was a way to indicate to other
Sage developers what packages you are working on.
Perhaps it'd be worth a new field (spkg) and the
On 9 Jun., 22:20, François Bissey wrote:
> > On 9 Jun., 13:43, François Bissey wrote:
> I haven't tested your new spkg but I ran
> sage -t -long devel/sage/sage/lib/singular/
> as you did in your ticket after removing everything that happens
> after installing libsingular. My notes in my ebuild a
--
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
> On 9 Jun., 13:43, François Bissey wrote:
> > > It does take a long time to build compared to most other packages,
> > > which is probably due to the fact the package is large and so has a
> > > lot of source code.
> >
> > Well I am trying that now. Running the test against a lighter version
>
On Wed, Jun 9, 2010 at 12:53 PM, Sergey Bochkanov
wrote:
> Hello,
>
> thanks to all who've replied to this discussion!
>
> Taking into account what was said above, I've decided to target
> pure
> ANSI C, i.e. C without newer constructs like // comments and
> other
> stuff from newer standards.
Hello,
thanks to all who've replied to this discussion!
Taking into account what was said above, I've decided to target
pure
ANSI C, i.e. C without newer constructs like // comments and
other
stuff from newer standards. I don't want to use C99 because it
isn't
supported by MSVC (de facto stan
On 9 Jun., 18:29, Robert Bradshaw
wrote:
> On Jun 9, 2010, at 9:19 AM, Dr. David Kirkby wrote:
> >>> I thought it would be useful if there was a way to indicate to other
> >>> Sage developers what packages you are working on.
> Perhaps it'd be worth a new field (spkg) and then we could
> make a
On 9 Jun., 13:43, François Bissey wrote:
> > It does take a long time to build compared to most other packages, which
> > is probably due to the fact the package is large and so has a lot of
> > source code.
>
> Well I am trying that now. Running the test against a lighter version
> of singular w
On 06/ 9/10 07:04 PM, John Hunter wrote:
On Wed, Jun 9, 2010 at 9:25 AM, Dr. David Kirkby
wrote:
Thank you. I noticed on package (Singular) where CPPFLAGS was not set to
$SAGE_LOCAL/include, and doing so ensured the include files in Sage were
found. I've not tried this with Matplotlib, but it
There is also LattE for enumerating integral points in a convex
polytope: http://www.math.ucdavis.edu/~latte/
I need to efficiently find lattice points in a parallelopiped (of
arbitrary dimension) with potentially half-integer vertex points
(including some facets but not others), which would fit u
On Wed, Jun 9, 2010 at 9:25 AM, Dr. David Kirkby
wrote:
> Thank you. I noticed on package (Singular) where CPPFLAGS was not set to
> $SAGE_LOCAL/include, and doing so ensured the include files in Sage were
> found. I've not tried this with Matplotlib, but it might be a way to work
> around the pr
On Wed, Jun 9, 2010 at 10:02 AM, Dr. David Kirkby
wrote:
>> A failed upgrade can be worked on. I've had failed upgrades, and in
>> that case I fix them. Since I know Sage well, I can always fix them.
>
> The point is not to just fix the upgrade - that only helps you on that one
> occasion. But us
On 06/ 9/10 05:40 PM, William Stein wrote:
On Wed, Jun 9, 2010 at 9:11 AM, Dr. David Kirkby
wrote:
On 06/ 9/10 12:40 PM, Dima Pasechnik wrote:
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready
for prime time use.
Indeed, one needs to hav
On Jun 9, 2010, at 1:35 AM, David Kirkby wrote:
On 8 June 2010 21:14, Robert Bradshaw
wrote:
On Jun 8, 2010, at 11:05 AM, leif wrote:
Though many compilers (and preprocessors) support this, I would
avoid
them unless the code *is* C99 or C++.
Why?
There are several good reasons - wel
On Wed, Jun 9, 2010 at 9:11 AM, Dr. David Kirkby
wrote:
> On 06/ 9/10 12:40 PM, Dima Pasechnik wrote:
>>
>> Well, I saw upgrades fail repeatedly, and William was writing here
>> that -upgrade is basically not ready
>> for prime time use.
>>
>> Indeed, one needs to have at least an spkg dependencie
On Wed, Jun 9, 2010 at 9:29 AM, Robert Bradshaw
wrote:
> On Jun 9, 2010, at 9:19 AM, Dr. David Kirkby wrote:
>
>> On 06/ 9/10 04:58 PM, Robert Bradshaw wrote:
>>>
>>> On Jun 9, 2010, at 7:29 AM, Dr. David Kirkby wrote:
>>>
I often find it annoying to be updating a standard package, only to
>>
On Jun 9, 2010, at 9:19 AM, Dr. David Kirkby wrote:
On 06/ 9/10 04:58 PM, Robert Bradshaw wrote:
On Jun 9, 2010, at 7:29 AM, Dr. David Kirkby wrote:
I often find it annoying to be updating a standard package, only to
find someone else is working on the same package, and so two people
produce
On Jun 9, 2010, at 9:11 AM, Dr. David Kirkby wrote:
On 06/ 9/10 12:40 PM, Dima Pasechnik wrote:
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready
for prime time use.
Indeed, one needs to have at least an spkg dependencies mechanism in
place
On 06/ 9/10 04:58 PM, Robert Bradshaw wrote:
On Jun 9, 2010, at 7:29 AM, Dr. David Kirkby wrote:
I often find it annoying to be updating a standard package, only to
find someone else is working on the same package, and so two people
produce patches and two different spkg files with the same ver
On 06/ 9/10 12:40 PM, Dima Pasechnik wrote:
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready
for prime time use.
Indeed, one needs to have at least an spkg dependencies mechanism in
place, before -upgrade
can be done in a fool-proof way. At
On Jun 9, 2010, at 4:40 AM, Dima Pasechnik wrote:
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready for prime time use.
Well, the -upgrade warning is pretty foreboding.
Indeed, one needs to have at least an spkg dependencies mechanism in
On Jun 9, 2010, at 7:29 AM, Dr. David Kirkby wrote:
I often find it annoying to be updating a standard package, only to
find someone else is working on the same package, and so two people
produce patches and two different spkg files with the same version
number.
I thought it would be usef
On Wednesday, June 9, 2010, Dima Pasechnik wrote:
> Well, I saw upgrades fail repeatedly, and William was writing here
> that -upgrade is basically not ready
> for prime time use.
>
> Indeed, one needs to have at least an spkg dependencies mechanism in
> place, before -upgrade
> can be done in a f
On 06/ 9/10 03:16 PM, Ondrej Certik wrote:
On Mon, Jun 7, 2010 at 5:21 PM, Dr. David Kirkby
wrote:
When matplot lib builds on 't2', it says:
BUILDING MATPLOTLIB
matplotlib: 0.99.1
python: 2.6.4 (r264:75706, Jun 5 2010, 17:43:53) [GCC
4.4.1
The patch here
http://trac.sagemath.org/sage_trac/ticket/8965
only changes documentation, doctests, comments and whitespace, so it
should be easy to review. I believe the file that is changed was
written by William.
Thanks,
Dan
--
To post to this group, send an email to sage-devel@googlegr
I often find it annoying to be updating a standard package, only to find someone
else is working on the same package, and so two people produce patches and two
different spkg files with the same version number.
I thought it would be useful if there was a way to indicate to other Sage
developer
On Mon, Jun 7, 2010 at 5:21 PM, Dr. David Kirkby
wrote:
> When matplot lib builds on 't2', it says:
>
> BUILDING MATPLOTLIB
> matplotlib: 0.99.1
> python: 2.6.4 (r264:75706, Jun 5 2010, 17:43:53) [GCC
> 4.4.1]
> platform: sunos5
>
> R
On 06/ 9/10 10:26 AM, David Kirkby wrote:
On 6 June 2010 09:21, William Stein wrote:
On Sun, Jun 6, 2010 at 12:45 AM, Jason B Hill wrote:
Actually, make the account on http://demo.sagenb.org.
The Sage notebook http://sagenb.org just passed about 32000 accounts,
and I store the notebook user
> > Apart from moving to the latest upstream I think the singular spkg
> > is due for a spring clean. It build an enormous amount of targets
> > in a way that looks like a very careful choreography and apart
> > from libsingular and the singular binary there is no indication
> > sage uses any of th
Does not build on Fedora 13.
As described in tickets #8657 and #8658, the libgcrypt and opencdk
spkgs need to be patched. With these patches it builds fine.
Volker
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsubscribe from this group, send an email to
sage-devel
Well, I saw upgrades fail repeatedly, and William was writing here
that -upgrade is basically not ready
for prime time use.
Indeed, one needs to have at least an spkg dependencies mechanism in
place, before -upgrade
can be done in a fool-proof way. At the moment it is adhoc - an spkg
can be checki
On 6 June 2010 09:21, William Stein wrote:
> On Sun, Jun 6, 2010 at 12:45 AM, Jason B Hill
> wrote:
>
> Actually, make the account on http://demo.sagenb.org.
>
> The Sage notebook http://sagenb.org just passed about 32000 accounts,
> and I store the notebook user directories in a single directo
On 6 June 2010 11:47, François Bissey wrote:
>> On 06/ 6/10 10:53 AM, François Bissey wrote:
>> >>> You could also try
>> >>>
>> >>> sage -ba
>> >>>
>> >>> which will rebuild from scratch all Cython code.
>> >>
>> >> OK I will give it a go.
>> >
>> > No improvement. I am considering this upgra
On 8 June 2010 21:14, Robert Bradshaw wrote:
> On Jun 8, 2010, at 11:05 AM, leif wrote:
>> Though many compilers (and preprocessors) support this, I would avoid
>> them unless the code *is* C99 or C++.
>
> Why?
There are several good reasons - well, at least in my opinion good reasons.
1) It
49 matches
Mail list logo
