I have machines I have been building Sage on (and using for development)
for 10 years or more, and they have several environment variables of the
form SAGE* which I set in my .bashrc script. I suspect that all or most of
these are redundant; some may even be harmful. Is there a list somewhere
of
Hi everybody,
I just accidentally pushed to the develop branch (instead of to a new
branch in my fork). I'm very sorry! I leave it to the release manager to
revert/fix it to not introduce more issues.
What confuses me, however, is how this was possible in first place?! I
thought we had branch
Hi,
I took the liberty to fix the develop branch by force-pushing 10.2.rc2
branch.
All should be in order now, and PRs can proceed.
A copy of the accidentally pushed to develop is here:
https://github.com/dimpase/sage/tree/develop_accidentally_pushed_to_
On Tue, Nov 14, 2023 at 9:43 AM Dima
On Tue, Nov 14, 2023 at 9:29 AM tobia...@gmx.de wrote:
>
> Hi everybody,
>
> I just accidentally pushed to the develop branch (instead of to a new branch
> in my fork). I'm very sorry! I leave it to the release manager to revert/fix
> it to not introduce more issues.
>
> What confuses me,
Thajd Dima, very helpful as always! I can't believe that after years of
using git I did not know about git grep (but I'm sure that you can believe
it).
Incidentally, setting SAGE_ATLAS_LIB was one of the early ways to help
developers by saying to use a system build of atlas which otherwise took
Of these listed, only SAGE_INSTALL_CCACHE and SAGE_MATPLOTLIB_GUI
are mentioned in Sage's source, as you can see by running
git grep SAGE_MATPLOTLIB_GUI
git grep foobar
etc
On Tue, Nov 14, 2023 at 2:33 PM John Cremona wrote:
>
> I have machines I have been building Sage on (and using for
Hi everyone,
I am collaborating with a colleague to somehow extend the class
SimplicialComplex to include functionalities of relative simplicial
complexes. We've started coding but seek your input before moving forward,
particularly on the initial design of the class.
Initially, we considered
The symengine package has apparently not been updated to be compatible with
cython 3.
This is what I see in the log (full log attached):
performance hint:
I don't think this happens in normal development. When this happens in your
setup, check the mtime of the timestamps in local/var/lib/sage/installed.
On Tuesday, November 14, 2023 at 9:37:09 AM UTC-8 Marc Culler wrote:
> For me, one of the most frustrating parts of building sage is that,
>
For me, one of the most frustrating parts of building sage is that,
whenever a build fails, the make system decides that gmp is out of date and
hence I have to wait for it to recompile gmp and all of its dependencies.
Is this intentional?
Does anyone know why it happens?
Is it avoidable?
Or
Of course I meant that I have to wait for everything that *depends on* gmp
to be recompiled. Also, this happens when there is nothing wrong with the
gmp build. The make system decides that it is out of date even though the
build was successful and the package was installed.
- Marc
On
On Tue, Nov 14, 2023 at 5:50 PM Michael Orlitzky wrote:
>
> On Tue, 2023-11-14 at 09:42 -0800, Marc Culler wrote:
> > Of course I meant that I have to wait for everything that *depends on* gmp
> > to be recompiled. Also, this happens when there is nothing wrong with the
> > gmp build. The make
Thanks, Matthias. I will try to remember to check the timestamps next time.
- Marc
On Tue, Nov 14, 2023 at 12:56 PM Matthias Koeppe
wrote:
> I don't think this happens in normal development. When this happens in
> your setup, check the mtime of the timestamps in
>
On Tue, Nov 14, 2023 at 5:37 PM Marc Culler wrote:
>
> For me, one of the most frustrating parts of building sage is that, whenever
> a build fails, the make system decides that gmp is out of date and hence I
> have to wait for it to recompile gmp and all of its dependencies.
>
> Is this
On Tue, Nov 14, 2023 at 5:18 PM Marc Culler wrote:
>
> The symengine package has apparently not been updated to be compatible with
> cython 3.
https://github.com/symengine/symengine.py/issues/456
>
> This is what I see in the log (full log attached):
>
> performance hint:
>
On Tue, 2023-11-14 at 09:42 -0800, Marc Culler wrote:
> Of course I meant that I have to wait for everything that *depends on* gmp
> to be recompiled. Also, this happens when there is nothing wrong with the
> gmp build. The make system decides that it is out of date even though the
> build
I was hesitant to send that message because I didn't want to have to go
through this again.
On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik wrote:
> > Does ./configure say why the system copy is unsuitable?
>
There is no system copy.
I imagine it might be an artifact of the design of Sage on
On Tue, Nov 14, 2023 at 7:22 PM Marc Culler wrote:
>
> I was hesitant to send that message because I didn't want to have to go
> through this again.
>
> On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik wrote:
>>
>> > Does ./configure say why the system copy is unsuitable?
>
>
> There is no
On 2023-11-14 23:44:50, Dima Pasechnik wrote:
> I have not invented the verb "to vendor"
Don't worry, you are in good company:
https://www.gocomics.com/calvinandhobbes/1993/01/25
--
You received this message because you are subscribed to the Google Groups
"sage-devel" group.
To unsubscribe
It's not on PyPI yet, as Isuru tells me there.
On Tue, 14 Nov 2023, 21:03 Marc Culler, wrote:
>
> I see your unanswered message "ping" on issue #456 from 5 days ago.
>
> But in the Releases section I see that v0.11.0 was released 2 days ago.
>
> - Marc
>
>
> On Tuesday, November 14, 2023 at
I have not invented the verb "to vendor", I merely picked it up from Python
docs and PEPs, e.g.
https://www.python.org/dev/peps/pep-0518/#configparser
(this one was written by native English speakers, I think)
You seem to prefer to pick on my supposedly broken English, rather than
read Python
I'm only worried that I know more English words than native speakers...
On Tue, 14 Nov 2023, 23:56 Michael Orlitzky, wrote:
> On 2023-11-14 23:44:50, Dima Pasechnik wrote:
> > I have not invented the verb "to vendor"
>
> Don't worry, you are in good company:
>
>
On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
On Tue, Nov 14, 2023 at 7:22 PM Marc Culler wrote:
> On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik wrote:
>> I imagine it might be an artifact of the design of Sage on Mac app
>> Marc is releasing:
>> vendor
I see your unanswered message "ping" on issue #456 from 5 days ago.
But in the Releases section I see that v0.11.0 was released 2 days ago.
- Marc
On Tuesday, November 14, 2023 at 11:50:55 AM UTC-6 Dima Pasechnik wrote:
> On Tue, Nov 14, 2023 at 5:18 PM Marc Culler wrote:
> >
> > The
On Tue, 14 Nov 2023, 20:39 Matthias Koeppe,
wrote:
> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>
> On Tue, Nov 14, 2023 at 7:22 PM Marc Culler wrote:
> > On Tue, Nov 14, 2023 at 11:58 AM Dima Pasechnik
> wrote:
> >> I imagine it might be an artifact of the design
Not all Americans like to verb things so profligately.
On Tuesday, November 14, 2023 at 1:15:07 PM UTC-8 Dima Pasechnik wrote:
>
>
> On Tue, 14 Nov 2023, 20:39 Matthias Koeppe, wrote:
>
>> On Tuesday, November 14, 2023 at 11:39:52 AM UTC-8 Dima Pasechnik wrote:
>>
>> On Tue, Nov 14, 2023 at
If I respond using "verb" as a verb, do you really think I'm seriously
criticizing you about using "vendor" as a verb? You're telling me to get a
life? Get a sense of humor.
On Tuesday, November 14, 2023 at 3:45:07 PM UTC-8 Dima Pasechnik wrote:
> I have not invented the verb "to vendor", I
27 matches
Mail list logo