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
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'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 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
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
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
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
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 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
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
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
>
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
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,
>
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
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
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
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
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
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:
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
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
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
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,
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,
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
27 matches
Mail list logo
