This is now ready for review at https://trac.sagemath.org/ticket/33851
On Monday, August 22, 2022 at 6:22:26 PM UTC-7 Matthias Koeppe wrote:
> On Monday, August 22, 2022 at 6:00:08 PM UTC-7 Matthias Koeppe wrote:
>
>> On Monday, August 22, 2022 at 5:52:43 PM UTC-7 Nils Bruin wrote:
>>
>>>
>>>
Best to merge the current development branch into this branch and rebuild
On Monday, August 22, 2022 at 7:18:53 PM UTC-7 gcha...@vols.utk.edu wrote:
> Hello,
>
> I am running MacOS with M1 chip. I have compiled Sage a number of times
> successfully in the past after working on code changes. I
On Monday, August 22, 2022 at 6:27:05 PM UTC-7 Nils Bruin wrote:
> On Monday, 22 August 2022 at 18:00:08 UTC-7 Matthias Koeppe wrote:
>
>>
>> Please help by suggesting a better phrasing of step 4 that you may have
>> understood better.
>>
>
> "Before Sagemath 9.7beta5, the following packages
On Monday, 22 August 2022 at 18:00:08 UTC-7 Matthias Koeppe wrote:
>
> Please help by suggesting a better phrasing of step 4 that you may have
> understood better.
>
"Before Sagemath 9.7beta5, the following packages were only necessary if
you planned to work with ticket branches that make
On Monday, August 22, 2022 at 6:00:08 PM UTC-7 Matthias Koeppe wrote:
> On Monday, August 22, 2022 at 5:52:43 PM UTC-7 Nils Bruin wrote:
>
>>
>> but I think the last time I installed sage I followed one that is posted
>> in a much more authoritative location:
>>
>>
>>
On Monday, August 22, 2022 at 5:52:43 PM UTC-7 Nils Bruin wrote:
> On Monday, 22 August 2022 at 17:04:34 UTC-7 Matthias Koeppe wrote:
>
>> On Monday, August 22, 2022 at 4:50:42 PM UTC-7 Nils Bruin wrote:
>>
>>>
>>> It's only affecting developers who skipped step 4 in
>>
On Monday, August 22, 2022 at 5:52:43 PM UTC-7 Nils Bruin wrote:
> (and it should really suggest "dnf" there):
>
You've mentioned this before but we still support centos-7, which only has
yum but not dnf; whereas all systems that have dnf also have yum.
--
You received this message because
On Monday, 22 August 2022 at 17:04:34 UTC-7 Matthias Koeppe wrote:
> On Monday, August 22, 2022 at 4:50:42 PM UTC-7 Nils Bruin wrote:
>
>> it's https://trac.sagemath.org/ticket/29549 that broke bootstrap on
>> platforms where it previously ran without problem.
>>
>
> Actually the only thing
On Tue, 23 Aug 2022, 01:11 John H Palmieri, wrote:
>
>
> On Monday, August 22, 2022 at 4:02:05 PM UTC-7 dim...@gmail.com wrote:
>
>>
>>
>> On Mon, 22 Aug 2022, 23:47 John H Palmieri, wrote:
>>
>>> What is the purpose of
>>>
>>> - $HOME/.sage/gap
>>> - $HOME/.sage/pexpect_logs
>>> -
On Monday, August 22, 2022 at 4:02:05 PM UTC-7 dim...@gmail.com wrote:
>
>
> On Mon, 22 Aug 2022, 23:47 John H Palmieri, wrote:
>
>> What is the purpose of
>>
>> - $HOME/.sage/gap
>> - $HOME/.sage/pexpect_logs
>> - $HOME/.sage/cache
>>
>> ?
>>
>> The first one currently takes 1.5GB on my
On Tue, 23 Aug 2022, 00:50 Nils Bruin, wrote:
>
>
> On Monday, 22 August 2022 at 16:16:04 UTC-7 Matthias Koeppe wrote:
>
>>
>> Dima should have said "gettext-devel", not "gettext".
>> See
>> https://doc.sagemath.org/html/en/reference/spkg/_bootstrap.html#spkg-bootstrap
>>
>> Thanks. That works.
On Monday, August 22, 2022 at 4:50:42 PM UTC-7 Nils Bruin wrote:
> it's https://trac.sagemath.org/ticket/29549 that broke bootstrap on
> platforms where it previously ran without problem.
>
Actually the only thing that it broke is the automatic fallback from
"bootstrap" to "bootstrap -D"
On Monday, August 22, 2022 at 4:50:42 PM UTC-7 Nils Bruin wrote:
> On Monday, 22 August 2022 at 16:16:04 UTC-7 Matthias Koeppe wrote:
>
>>
>> Dima should have said "gettext-devel", not "gettext".
>> See
>> https://doc.sagemath.org/html/en/reference/spkg/_bootstrap.html#spkg-bootstrap
>>
>>
On Monday, 22 August 2022 at 16:16:04 UTC-7 Matthias Koeppe wrote:
>
> Dima should have said "gettext-devel", not "gettext".
> See
> https://doc.sagemath.org/html/en/reference/spkg/_bootstrap.html#spkg-bootstrap
>
> Thanks. That works. So we need to urgently include gettext-devel in the
On Tue, 23 Aug 2022, 00:12 Nils Bruin, wrote:
> On Monday, 22 August 2022 at 15:58:19 UTC-7 dim...@gmail.com wrote:
>
>>
>> The root cause of this is the idiotic gnulib state of affairs - gnulib
>> does not provide an install target, it did not have any releases for years,
>> although it is
On Monday, August 22, 2022 at 4:12:22 PM UTC-7 Nils Bruin wrote:
> On Monday, 22 August 2022 at 15:58:19 UTC-7 dim...@gmail.com wrote:
>
>>
>> hmm, no, you mist probably don't have gettext installed.
>>
>> Seeing that mentioned I did:
> $ sudo dnf install gettext
> Last metadata expiration check:
On Monday, 22 August 2022 at 15:58:19 UTC-7 dim...@gmail.com wrote:
>
> The root cause of this is the idiotic gnulib state of affairs - gnulib
> does not provide an install target, it did not have any releases for years,
> although it is actively updated - it literally wants users to vendor
On Mon, 22 Aug 2022, 23:47 John H Palmieri, wrote:
> What is the purpose of
>
> - $HOME/.sage/gap
> - $HOME/.sage/pexpect_logs
> - $HOME/.sage/cache
>
> ?
>
> The first one currently takes 1.5GB on my machine, and it has a README.txt
> file that says "It is OK to delete all these cache files.
On Monday, August 22, 2022 at 3:10:12 PM UTC-7 Nils Bruin wrote:
> So, if a change is found to break building under normal circumstances, *back
> it out* and only re-merge it once it's solved!
>
Thanks for the advice. Well, I had a trivial and complete working fix ready
for review on the day
It's Buridan's ass situation with
https://trac.sagemath.org/ticket/34152
- we have two competing solutions there, and cannot move with any of these.
Other reviewers of this ticket somehow think it will solve itself.
The root cause of this is the idiotic gnulib state of affairs - gnulib does
not
What is the purpose of
- $HOME/.sage/gap
- $HOME/.sage/pexpect_logs
- $HOME/.sage/cache
?
The first one currently takes 1.5GB on my machine, and it has a README.txt
file that says "It is OK to delete all these cache files. They will be
recreated as needed." So why do we keep them at all?
For other people who may run into this, it seems that `./bootstrap -D`
avoids this bug. I have no idea what it does -- nor what the original
problem is, but it was mentioned somewhere in another thread where someone
expressed their exasperation with another break in the build-system.
For
Thanks. So, what's the recommended course of action? Wait a month or so
until this ticket has been merged? [reality is: the work will then probably
be pushed back to January due to the term kicking in]
On Monday, 22 August 2022 at 14:17:19 UTC-7 Matthias Koeppe wrote:
> This is
This is https://trac.sagemath.org/ticket/34152
On Monday, August 22, 2022 at 2:13:47 PM UTC-7 Nils Bruin wrote:
> The error actually already occurs with a
>
> make distclean
> ./bootstrap
>
> I get:
>
> ...
> m4/sage_spkg_configures.m4:608: the top level
The error actually already occurs with a
make distclean
./bootstrap
I get:
...
m4/sage_spkg_configures.m4:608: the top level
configure.ac:52: error: possibly undefined macro: AC_LIB_RPATH
If this token and others are legitimate, please use
Maybe try some combination of `./bootstrap` and/or `make configure`,
followed by `./configure && make build`?
--
John
On Monday, August 22, 2022 at 1:05:07 PM UTC-7 Nils Bruin wrote:
> I get a failure when I do
> git checkout tags/9.7.beta8
> make build
>
> I get
> configure.ac:52: error:
I get a failure when I do
git checkout tags/9.7.beta8
make build
I get
configure.ac:52: error: possibly undefined macro: AC_LIB_RPATH
If this token and others are legitimate, please use m4_pattern_allow.
See the Autoconf documentation.
configure:26328: error: possibly undefined macro:
> let me take the opportunity to promote the use of the get_systems
> function from sage.misc.citation which allows to see and acknowledge
> which upstream packages were used by Sage for some computation, e.g.
>
>
+1
--
You received this message because you are subscribed to the Google
The docstring of iterator_fast says that the weights should be weakly
decreasing.
It seems to me that the code actually works for any composition, or am I
missing something?
Martin
def iterator_fast(n, l):
"""
Iterate over all ``l`` weighted integer vectors with total weight ``n``.
Travis's answer works for line3d objects consisting of a single segment.
Here is a more general version for any line3d object.
If you haven't already, install more-itertools:
```
sage: %pip install more-itertools
```
Then define this length function:
```
def line3d_euclidean_length(L):
30 matches
Mail list logo
