[sage-devel] Re: (cy)PARI in Parallel, Heisenbugs, and Merging Policy

[dwb...@gmail.com]

A bit more information: as far as we know there are problems only on Linux: 
the logs badlog, badlog1, badlog2 and badlog3 are made by one machine (a 
Xeon box running Ubuntu 18.04) and badlog-match is another machne (an i7 
also running Ubuntu 18.04).
In all the logs except badlog, there is a segmentation fault.
In badlog3, gdb attaches the running process and produces a backtrace.
We are currently not seeing crashes on MacOS.

Daniel Bump
On Saturday, May 14, 2022 at 8:06:18 PM UTC-7 Travis Scrimshaw wrote:

> Hi everyone,
>On ticket #30423 , Dan, 
> Willie, and I have been working on a parallel-computation based 
> implementation for computing F-matrices that are used in math physics. 
> However, we have been seeing some doctest failures sporadically that 
> involve segfaults and linked-list corruption from (cy)PARI. Here are the 
> logs from testing with the first and the last having full tracebacks.
>
> http://sporadic.stanford.edu/badlog-match
> http://sporadic.stanford.edu/badlog
> http://sporadic.stanford.edu/badlog1
> http://sporadic.stanford.edu/badlog2
> http://sporadic.stanford.edu/badlog3
>
> The first question would be if anyone has an idea about what is causing 
> this. I have this impression that PARI is thread-safe, but I am wondering 
> if cypari is also thread/parallel-safe or if there are any specific things 
> that we should be careful about. (We’ve already had to work around a 
> pickling issue with polynomials IIRC.)
>
> Second question is that because this is a Heisenbug and I suspect it is 
> something upstream (and so far, nobody has been able to reproducing it 
> during an interactive version of Sage), I was wondering what the policy 
> would be for merging the ticket. I recall in the past that we have merged 
> tickets with Heisenbugs with followup tickets noting the behavior, but I am 
> not 100% sure about that (and I wouldn’t necessarily know how to find any 
> explicit examples). I was wondering if we could merge the ticket in an 
> early beta version so that many people/systems can test it to see if it 
> becomes more reproducible; of course this is assuming that the build bots 
> are not consistent in reproducing this. Should we just mark any offending 
> test(s) as “# known bug” and is there some general policy about this?
>
> Thanks,
> Travis
>
>
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/ed1a0c3a-ed0e-41c3-825a-153b738a7afcn%40googlegroups.com.

[sage-devel] Segmentation Fault

[dwb...@gmail.com]

I was shown the following way of getting a segmentation fault in Sage.

sage: var("q A")
sage: p = A*(1+1/A)-A-1
sage: (q^p).full_simplify()

This consistently causes a crash. The person who found it was doing some 
actual work, got a crash, and boiled it down to a minimal example.

Daniel Bump

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/657f8f91-d2c0-4a7c-8a4a-509368c6d6d5n%40googlegroups.com.

[sage-devel] Re: Unable to build develop branch

[dwb...@gmail.com]

Thanks!

But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
<https://trac.sagemath.org/git-merger/470ffac111a769b3f2b02631e5174ff6fa483f2b> 
fails 
in numpy and
doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
into
the scipy-big-sur branch and that fails to build in scipy again.

Dan

On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:

> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
> Merging that into the develop branch works for me.
>
> -- 
> John
>
>
> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com wrote:
>
>> I'm unable to build the develop branch since upgrading my iMac to Big 
>> Sur. I have python3 and scipy installed through homebrew. In /usr/local/bin 
>> I have a symbolic link from python to python3.
>>
>> Although I have scipy through homebrew, Sage insists on installing the 
>> spkg. In previous build attempts (in late December) the build failed in 
>> numpy.
>>
>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>
>> Thank you,
>> Daniel Bump
>>
>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/610ee06f-6d9d-4091-bd52-46f212ff8be7n%40googlegroups.com.

[sage-devel] Re: Unable to build develop branch

[dwb...@gmail.com]

Contrary to my previous message, Ticket 31183 does fix the problem and I 
can now build sage.

Thanks,
Dan
On Friday, January 22, 2021 at 3:21:10 PM UTC-8 John H Palmieri wrote:

> I literally meant "merge that [the branch from #31183] into the develop 
> branch" (or vice versa), not just use the branch from #31183. The develop 
> branch has some crucial pieces for building Sage in Big Sur.
>
>   John
>
> On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com wrote:
>
>> Thanks!
>>
>> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
>> <https://trac.sagemath.org/git-merger/470ffac111a769b3f2b02631e5174ff6fa483f2b>
>>  fails 
>> in numpy and
>> doesn't get to scipy. So I merged the change in #31166 (addressing numpy) 
>> into
>> the scipy-big-sur branch and that fails to build in scipy again.
>>
>> Dan
>>
>> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>>
>>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix that. 
>>> Merging that into the develop branch works for me.
>>>
>>> -- 
>>> John
>>>
>>>
>>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com 
>>> wrote:
>>>
>>>> I'm unable to build the develop branch since upgrading my iMac to Big 
>>>> Sur. I have python3 and scipy installed through homebrew. In 
>>>> /usr/local/bin 
>>>> I have a symbolic link from python to python3.
>>>>
>>>> Although I have scipy through homebrew, Sage insists on installing the 
>>>> spkg. In previous build attempts (in late December) the build failed in 
>>>> numpy.
>>>>
>>>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>>>
>>>> Thank you,
>>>> Daniel Bump
>>>>
>>>>
>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b21c55f5-3f02-44da-9a7c-b2e1a4810e99n%40googlegroups.com.

[sage-devel] Re: Unable to build develop branch

[dwb...@gmail.com]

I cannot build the documentation. It actually crashes python. I'm attaching 
my
docbuild log.

I have another problem which is that 'sage -b' does not work. It gives me 
the error
"This Makefile needs to be invoked by 'build/make/install'". If I set the 
parameter
SAGEPKGCONFIG then it works, but I shouldn't need to do that.

Dan

On Friday, January 22, 2021 at 5:16:28 PM UTC-8 John H Palmieri wrote:

> Great, I'm glad to hear it!
>
> Have you run doctests? If so, are there many failures?
>
>
> On Friday, January 22, 2021 at 4:45:59 PM UTC-8 dwb...@gmail.com wrote:
>
>>
>> Contrary to my previous message, Ticket 31183 does fix the problem and I 
>> can now build sage.
>>
>> Thanks,
>> Dan
>> On Friday, January 22, 2021 at 3:21:10 PM UTC-8 John H Palmieri wrote:
>>
>>> I literally meant "merge that [the branch from #31183] into the develop 
>>> branch" (or vice versa), not just use the branch from #31183. The develop 
>>> branch has some crucial pieces for building Sage in Big Sur.
>>>
>>>   John
>>>
>>> On Friday, January 22, 2021 at 11:30:57 AM UTC-8 dwb...@gmail.com wrote:
>>>
>>>> Thanks!
>>>>
>>>> But it didn't fix it for me. For me the u/jhpalmieri/scipy-big-sur 
>>>> <https://trac.sagemath.org/git-merger/470ffac111a769b3f2b02631e5174ff6fa483f2b>
>>>>  fails 
>>>> in numpy and
>>>> doesn't get to scipy. So I merged the change in #31166 (addressing 
>>>> numpy) into
>>>> the scipy-big-sur branch and that fails to build in scipy again.
>>>>
>>>> Dan
>>>>
>>>> On Thursday, January 21, 2021 at 8:09:14 PM UTC-8 John H Palmieri wrote:
>>>>
>>>>> Ticket 31183 (https://trac.sagemath.org/ticket/31183) should fix 
>>>>> that. Merging that into the develop branch works for me.
>>>>>
>>>>> -- 
>>>>> John
>>>>>
>>>>>
>>>>> On Thursday, January 21, 2021 at 8:03:55 PM UTC-8 dwb...@gmail.com 
>>>>> wrote:
>>>>>
>>>>>> I'm unable to build the develop branch since upgrading my iMac to Big 
>>>>>> Sur. I have python3 and scipy installed through homebrew. In 
>>>>>> /usr/local/bin 
>>>>>> I have a symbolic link from python to python3.
>>>>>>
>>>>>> Although I have scipy through homebrew, Sage insists on installing 
>>>>>> the spkg. In previous build attempts (in late December) the build failed 
>>>>>> in 
>>>>>> numpy.
>>>>>>
>>>>>> I'm attaching my scipy.1.5.4.log. I would appreciate any suggestions.
>>>>>>
>>>>>> Thank you,
>>>>>> Daniel Bump
>>>>>>
>>>>>>
>>>>>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/9fddb72c-8a69-4d53-b7c2-8071eb00708an%40googlegroups.com.

Building reference manual, first pass.

[reference] building [inventory]: targets for 1 source files that are out of 
date
[reference] updating environment: [new config] 1 added, 0 changed, 0 removed
[reference] The inventory files are in 
local/share/doc/sage/inventory/en/reference/references.
Build finished. The built documents can be found in 
/Users/bump/sagemath/sage/local/share/doc/sage/inventory/en/reference/references
[spkg ] building [inventory]: targets for 301 source files that are out of 
date
[spkg ] updating environment: [new config] 301 added, 0 changed, 0 removed
[spkg ] The inventory files are in 
local/share/doc/sage/inventory/en/reference/spkg.
Build finished. The built documents can be found in 
/Users/bump/sagemath/sage/local/share/doc/sage/inventory/en/reference/spkg
[manifolds] building [inventory]: targets for 79 source files that are out of 
date
[manifolds] updating environment: [new config] 79 added, 0 changed, 0 removed
[manifolds] The inventory files are in 
local/share/doc/sage/inventory/en/reference/manifolds.
Build finished. The built documents can be found in 
/Users/bump/sagemath/sage/local/share/doc/sage/inventory/en/reference/manifolds
[polynomia] building [inventory]: targets for 62 source files that are out of 
date
[polynomia] updating environment: [new config] 62 added, 0 changed, 0 removed
[polynomia]

Re: [sage-devel] Re: Problems with 9.3.beta6 + OS X Big Sur

[dwb...@gmail.com]

Even after applying the fix in #31344 I still get a similar crash building 
the documentation. I am attaching my dochtml.log.

Daniel Bump
On Friday, February 5, 2021 at 11:24:59 AM UTC-8 Matthias Koeppe wrote:

> Fixed in https://trac.sagemath.org/ticket/31344
>
> On Thursday, February 4, 2021 at 4:30:45 AM UTC-8 Dima Pasechnik wrote:
>
>> Probably https://bugs.python.org/issue19733 is still relevant?
>> Note messages
>>
>> test_image (tkinter.test.test_ttk.test_widgets.ButtonTest) ... skipped
>> 'crashes with Cocoa Tk (issue19733)'
>>
>> one gets by running
>>
>> python3 runtktests.py
>>
>> Even though 19733 was closed, it's not clear whether they tested on macOS 
>> 11.
>>
>>
>> in
>>
>> /usr/local/Cellar/python@3.9/3.9.1_7/Frameworks/Python.framework/Versions/3.9/lib/python3.9/tkinter/test/
>>
>> On Thu, Feb 4, 2021 at 4:32 AM Zachary Scherr  wrote:
>> >
>> > I found something possibly relevant at
>> >
>> > https://bugs.python.org/issue42691
>> >
>> > although there the complaint was that Homebrew built python against 
>> system tcl and the suggestion was that Homebrew use its own tcl-tk. It 
>> seems that Homebrew is correctly using its own tcl-tk
>> > since the line
>> >
>> > 5 libtcl8.6.dylib 0x00032998c72e AtForkPrepare + 38
>> >
>> > says that python is using tcl 8.6 and system tcl is 8.5. No idea what's 
>> going on, but it might be good to try to produce a minimal reproducible 
>> example to show to the python/tcl people.
>> > On Wednesday, February 3, 2021 at 12:11:54 PM UTC-5 dim...@gmail.com 
>> wrote:
>> >>
>> >>
>> >>
>> >> On Wed, 3 Feb 2021, 17:03 John H Palmieri,  
>> wrote:
>> >>>
>> >>> Right, thank you. Python 3.9 builds successfully.
>> >>>
>> >>> On Monday, February 1, 2021 at 7:14:29 PM UTC-8 zsc...@gmail.com 
>> wrote:
>> 
>>  For the --with-system-python3=no, I don't know what the problem is 
>> but I think it was fixed by upgrading to python 3.9 in 
>> https://trac.sagemath.org/ticket/30589
>> 
>>  On Monday, February 1, 2021 at 9:45:37 PM UTC-5 John H Palmieri 
>> wrote:
>> >
>> > On OS X Big Sur (intel), as of the most recent Xcode and homebrew, 
>> I am currently unable to build Sage with either homebrew's Python or with 
>> `./configure --with-system-python3=no`.
>> >
>> > - With homebrew's Python, actually Sage builds but the 
>> documentation does not (similar problems on both Big Sur and Catalina), 
>> ending with
>> >>
>> >>
>> >> yes, I see this too. (with latest Homebrew python 3.9.)
>> >>
>> >> What exactly is broken there?
>> >>
>> >>
>> >
>> >
>> > 
>> 
>> > 0 signals.cpython-39-darwin.so 0x00010cd40542 print_backtrace 
>> + 66
>> > 1 signals.cpython-39-darwin.so 0x00010cd44167 sigdie + 39
>> > 2 signals.cpython-39-darwin.so 0x00010cd4406a 
>> cysigs_signal_handler + 282
>> > 3 libsystem_platform.dylib 0x7fff203bcd7d _sigtramp + 29
>> > 4 ??? 0x003f 0x0 + 63
>> > 5 libtcl8.6.dylib 0x00032998c72e AtForkPrepare + 38
>> > 6 libsystem_pthread.dylib 0x7fff203781a3 
>> _pthread_atfork_prepare_handlers + 90
>> > 7 libSystem.B.dylib 0x7fff2a575934 libSystem_atfork_prepare + 11
>> > 8 libsystem_c.dylib 0x7fff2025bb1b fork + 12
>> > 9 _posixsubprocess.cpython-39-darwin. 0x00010b63db89 
>> subprocess_fork_exec + 1573
>> > 10 Python 0x00010af10904 cfunction_call + 127
>> > 11 Python 0x00010aedffa3 _PyObject_MakeTpCall + 266
>> > 12 Python 0x00010af88027 call_function + 455
>> > ...
>> > 157 Python 0x00010afcf10f Py_BytesMain + 42
>> > 158 libdyld.dylib 0x7fff20393621 start + 1
>> > 
>> 
>> > Unhandled SIGILL: An illegal instruction occurred.
>> > This probably occurred because a *compiled* module has a bug
>> > in it and is not properly wrapped with sig_on(), sig_off().
>> > Python will now terminate.
>> > 
>> 
>> > ...
>> > File 
>> "/Users/palmieri/Desktop/Sage/sage_builds/TESTING/sage-9.3.beta6/local/lib/python3.9/site-packages/sage_setup/docbuild/utils.py",
>>  
>> line 221, in reap_workers
>> > w = bring_out_yer_dead(w, task, exitcode)
>> > File 
>> "/Users/palmieri/Desktop/Sage/sage_builds/TESTING/sage-9.3.beta6/local/lib/python3.9/site-packages/sage_setup/docbuild/utils.py",
>>  
>> line 157, in bring_out_yer_dead
>> > raise WorkerDiedException(
>> > sage_setup.docbuild.utils.WorkerDiedException: worker for 
>> ('reference/misc', 'en', 'html', {}) died with non-zero exit code -4
>> >
>> > - With `./configure --with-system-python3=no`, Python fails to 
>> build (on Big Sur only; it succeeds on Catalina), saying
>> >
>> > ModuleNotFoundError: No module named 'readline'
>> >
>> > and
>> >
>> > ModuleNotFou

Re: [sage-devel] Re: Problems with 9.3.beta6 + OS X Big Sur

[dwb...@gmail.com]

With this, I can now build the documentation. (Thanks!)

On Sunday, February 7, 2021 at 1:16:38 PM UTC-8 Matthias Koeppe wrote:

> Please try the current branch on https://trac.sagemath.org/ticket/31344, 
> we have added another fix.
>
> On Sunday, February 7, 2021 at 6:11:55 AM UTC-8 dwb...@gmail.com wrote:
>
>>
>> Even after applying the fix in #31344 I still get a similar crash 
>> building the documentation. I am attaching my dochtml.log.
>>
>> Daniel Bump
>> On Friday, February 5, 2021 at 11:24:59 AM UTC-8 Matthias Koeppe wrote:
>>
>>> Fixed in https://trac.sagemath.org/ticket/31344
>>>
>>> On Thursday, February 4, 2021 at 4:30:45 AM UTC-8 Dima Pasechnik wrote:
>>>
>>>> Probably https://bugs.python.org/issue19733 is still relevant? 
>>>> Note messages 
>>>>
>>>> test_image (tkinter.test.test_ttk.test_widgets.ButtonTest) ... skipped 
>>>> 'crashes with Cocoa Tk (issue19733)' 
>>>>
>>>> one gets by running 
>>>>
>>>> python3 runtktests.py 
>>>>
>>>> Even though 19733 was closed, it's not clear whether they tested on 
>>>> macOS 11. 
>>>>
>>>>
>>>> in 
>>>> /usr/local/Cellar/python@3.9/3.9.1_7/Frameworks/Python.framework/Versions/3.9/lib/python3.9/tkinter/test/
>>>>  
>>>>
>>>>
>>>> On Thu, Feb 4, 2021 at 4:32 AM Zachary Scherr  
>>>> wrote: 
>>>> > 
>>>> > I found something possibly relevant at 
>>>> > 
>>>> > https://bugs.python.org/issue42691 
>>>> > 
>>>> > although there the complaint was that Homebrew built python against 
>>>> system tcl and the suggestion was that Homebrew use its own tcl-tk. It 
>>>> seems that Homebrew is correctly using its own tcl-tk 
>>>> > since the line 
>>>> > 
>>>> > 5 libtcl8.6.dylib 0x00032998c72e AtForkPrepare + 38 
>>>> > 
>>>> > says that python is using tcl 8.6 and system tcl is 8.5. No idea 
>>>> what's going on, but it might be good to try to produce a minimal 
>>>> reproducible example to show to the python/tcl people. 
>>>> > On Wednesday, February 3, 2021 at 12:11:54 PM UTC-5 dim...@gmail.com 
>>>> wrote: 
>>>> >> 
>>>> >> 
>>>> >> 
>>>> >> On Wed, 3 Feb 2021, 17:03 John H Palmieri,  
>>>> wrote: 
>>>> >>> 
>>>> >>> Right, thank you. Python 3.9 builds successfully. 
>>>> >>> 
>>>> >>> On Monday, February 1, 2021 at 7:14:29 PM UTC-8 zsc...@gmail.com 
>>>> wrote: 
>>>> >>>> 
>>>> >>>> For the --with-system-python3=no, I don't know what the problem is 
>>>> but I think it was fixed by upgrading to python 3.9 in 
>>>> https://trac.sagemath.org/ticket/30589 
>>>> >>>> 
>>>> >>>> On Monday, February 1, 2021 at 9:45:37 PM UTC-5 John H Palmieri 
>>>> wrote: 
>>>> >>>>> 
>>>> >>>>> On OS X Big Sur (intel), as of the most recent Xcode and 
>>>> homebrew, I am currently unable to build Sage with either homebrew's 
>>>> Python 
>>>> or with `./configure --with-system-python3=no`. 
>>>> >>>>> 
>>>> >>>>> - With homebrew's Python, actually Sage builds but the 
>>>> documentation does not (similar problems on both Big Sur and Catalina), 
>>>> ending with 
>>>> >> 
>>>> >> 
>>>> >> yes, I see this too. (with latest Homebrew python 3.9.) 
>>>> >> 
>>>> >> What exactly is broken there? 
>>>> >> 
>>>> >> 
>>>> >>>>> 
>>>> >>>>> 
>>>> >>>>> 
>>>>  
>>>> >>>>> 0 signals.cpython-39-darwin.so 0x00010cd40542 
>>>> print_backtrace + 66 
>>>> >>>>> 1 signals.cpython-39-darwin.so 0x00010cd44167 sigdie + 39 
>>>> >>>>> 2 signals.cpython-39-darwin.so 0x00010cd4406a 
>>>> cysigs_signal_handler + 282 
>>>> >>>>> 3 libsystem_platform.dylib 0x7fff203bcd7d _sigt

[sage-devel] Re: question about weyl_dimension

[dwb...@gmail.com]

It looks like Sage is constructing the wrong crystals for the two spin 
weights. D5 does have
two irreducible representations of dimensions 210 and 126 but their highest 
weights are not
the spin weights s1=(1/2,1/2,1/2,1/2,1/2) and s2=(1/2,1/2,1/2,1/2,-1/2) 
which are the two
fundamental weights. Instead the highest weights of the representations 
with these degrees
210 and 126 are s1+s2 and 2*s1.

This appears to me to be a bug in the crystal code.

Daniel Bump
On Thursday, February 11, 2021 at 9:30:15 AM UTC-8 axio...@yahoo.de wrote:

> I am confused about the following result:
>
> sage: ct = CartanType(["D", 5])
> sage: L = RootSystem(ct).weight_lattice()
> sage: La = L.fundamental_weights();
> sage: [L.weyl_dimension(wt) for wt in La]
> [10, 45, 120, 16, 16]
> sage: [crystals.HighestWeight(wt).q_dimension().subs(q=1) for wt in La]
> [10, 45, 120, 210, 126]
>
> Am I doing something wrong or is this a bug?  I would expect the former 
> dimensions, but I am not versed enough in the theory to be sure that I did 
> not make a mistake myself.  The discrepancy seems to occur only with type D.
>
> All the best,
>
> Martin
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/aab7c0f2-047e-46cd-9dde-887d597ea41fn%40googlegroups.com.

[sage-devel] Re: question about weyl_dimension

[dwb...@gmail.com]

You can construct the two spin crystals using crystals.SpinsMinus("D5") and 
crystals.SpinsPlus("D5").
If you want other spin weights, you can tensor these crystals with an 
orthogonal crystal. But
the method you tried should either work or fail gracefully instead of 
returning a wrong result.

Daniel Bump

On Friday, February 12, 2021 at 9:49:42 AM UTC-8 axio...@yahoo.de wrote:

> Thank you, that explains it to me!
>
> Currently, the code that translates dominant weights to crystals is (line 
> 174 of highest_weight_crystals.py)
>
> sh = sum([[i]*c for i,c in dominant_weight], [])
> sh = Partition(reversed(sh))
> return CrystalOfTableaux(cartan_type, shape=sh.conjugate())
>
> So I guess there might also be a less visible problem for type B, and in 
> the case of the spin weights we should rather be returning CrystalOfSpins, 
> CrystalOfSpinsPlus, CrystalOfSpinsMinus.
>
> So, maybe we should use dominant.to_ambient?
>
> Martin
> dwb...@gmail.com schrieb am Freitag, 12. Februar 2021 um 16:52:02 UTC+1:
>
>> It looks like Sage is constructing the wrong crystals for the two spin 
>> weights. D5 does have
>> two irreducible representations of dimensions 210 and 126 but their 
>> highest weights are not
>> the spin weights s1=(1/2,1/2,1/2,1/2,1/2) and s2=(1/2,1/2,1/2,1/2,-1/2) 
>> which are the two
>> fundamental weights. Instead the highest weights of the representations 
>> with these degrees
>> 210 and 126 are s1+s2 and 2*s1.
>>
>> This appears to me to be a bug in the crystal code.
>>
>> Daniel Bump
>> On Thursday, February 11, 2021 at 9:30:15 AM UTC-8 axio...@yahoo.de 
>> wrote:
>>
>>> I am confused about the following result:
>>>
>>> sage: ct = CartanType(["D", 5])
>>> sage: L = RootSystem(ct).weight_lattice()
>>> sage: La = L.fundamental_weights();
>>> sage: [L.weyl_dimension(wt) for wt in La]
>>> [10, 45, 120, 16, 16]
>>> sage: [crystals.HighestWeight(wt).q_dimension().subs(q=1) for wt in La]
>>> [10, 45, 120, 210, 126]
>>>
>>> Am I doing something wrong or is this a bug?  I would expect the former 
>>> dimensions, but I am not versed enough in the theory to be sure that I did 
>>> not make a mistake myself.  The discrepancy seems to occur only with type D.
>>>
>>> All the best,
>>>
>>> Martin
>>>
>>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/4a778405-61b6-465c-b062-d9c0fec576e1n%40googlegroups.com.

[sage-devel] Pynac problem with Big Sur

[dwb...@gmail.com]

Last week I was able to build sage, and the documentation on Big Sur (MacOS 
11.2.1) after the fixes in Trac tickets #31183 and #31344.

There was another update to Xcode last week. When I first went to rebuild 
sage, it failed building cython. I updated homebrew and then I was able to 
build cython but now it fails building pynac with the message unable to 
find gmp.h.

I do have gmp installed with homebrew.

I am attaching the pynac log.

Daniel Bump

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/b3b3d352-00fc-4356-93bf-b6232a113226n%40googlegroups.com.
Attempting to download package pynac-0.7.26.sage-2020-04-03.tar.bz2 from mirrors
http://files.sagemath.org/spkg/upstream/pynac/pynac-0.7.26.sage-2020-04-03.tar.bz2
[..]
pynac-0.7.26.sage-2020-04-03.p0

Setting up build directory for pynac-0.7.26.sage-2020-04-03.p0
Finished extraction
Applying patches from ../patches...
Applying ../patches/py_ssize_t_clean.patch
patching file ginac/function.cpp
patching file ginac/numeric.cpp

Host system:
Darwin meep3 20.3.0 Darwin Kernel Version 20.3.0: Thu Jan 21 00:07:06 PST 2021; 
root:xnu-7195.81.3~1/RELEASE_X86_64 x86_64

C compiler: gcc
C compiler version:
Configured with: --prefix=/Library/Developer/CommandLineTools/usr 
--with-gxx-include-dir=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/include/c++/4.2.1
Apple clang version 12.0.0 (clang-1200.0.32.29)
Target: x86_64-apple-darwin20.3.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin

Package 'pynac' is currently not installed
No legacy uninstaller found for 'pynac'; nothing to do
Starting build...
Running build_pynac...
Configuring pynac-0.7.26.sage-2020-04-03.p0
configure: WARNING: unrecognized options: --disable-maintainer-mode
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a thread-safe mkdir -p... ./install-sh -c -d
checking for gawk... no
checking for mawk... no
checking for nawk... no
checking for awk... awk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking whether python3 version is >= 2.7... yes
checking for python3 version... 3.9
checking for python3 platform... darwin
checking for python3 script directory... ${prefix}/lib/python3.9/site-packages
checking for python3 extension module directory... 
${exec_prefix}/lib/python3.9/site-packages
checking for Python preprocessor flags... 
-I/usr/local/Cellar/python@3.9/3.9.1_8/Frameworks/Python.framework/Versions/3.9/include/python3.9
 
-I/usr/local/Cellar/python@3.9/3.9.1_8/Frameworks/Python.framework/Versions/3.9/include/python3.9
 -Wno-unused-result -Wsign-compare -Wunreachable-code -fno-common -dynamic 
-DNDEBUG -g -fwrapv -O3 -Wall -isysroot 
/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk
checking for Python library flags... -bundle -undefined dynamic_lookup 
-isysroot /Library/Developer/CommandLineTools/SDKs/MacOSX.sdk 
-L/Users/bump/sagemath/sage/local/lib 
-Wl,-rpath,/Users/bump/sagemath/sage/local/lib -O2 -g -march=native
checking build system type... x86_64-apple-darwin20.3.0
checking host system type... x86_64-apple-darwin20.3.0
checking for Cygwin... 
checking whether make supports nested variables... (cached) yes
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables... 
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C++ compiler... yes
checking whether g++ -std=gnu++11 accepts -g... yes
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++ -std=gnu++11... none
checking how to run the C++ preprocessor... g++ -std=gnu++11 -E
checking how to print strings... printf
checking for gcc... gcc
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ISO C89... none needed
checking whether gcc understands -c and -o together... rm: conftest.dSYM: is a 
directory
yes
checking dependency style of gcc... none
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /Library/Developer/CommandLineTools/usr/bin/ld
checking if the linker (/Library

Re: [sage-devel] Pynac problem with Big Sur

[dwb...@gmail.com]

> source .homebrew-build-env 

Thank you, after that I was able to build sage.

Dan
On Saturday, February 13, 2021 at 9:30:57 AM UTC-8 dim...@gmail.com wrote:

> On Sat, Feb 13, 2021 at 1:35 PM dwb...@gmail.com  wrote:
> >
> > Last week I was able to build sage, and the documentation on Big Sur 
> (MacOS 11.2.1) after the fixes in Trac tickets #31183 and #31344.
> >
> > There was another update to Xcode last week. When I first went to 
> rebuild sage, it failed building cython. I updated homebrew and then I was 
> able to build cython but now it fails building pynac with the message 
> unable to find gmp.h.
>
> I am unable to reproduce this (on macOS 11.2.1 with latest xcode and 
> homebrew)
>
> Did you do
>
> source .homebrew-build-env
>
> before starting rebuild? (this command needs to be run once in each
> terminal session/tab)
>
> If yes, do you have /usr/local/include/gmp.h ?
>
> >
> > I do have gmp installed with homebrew.
> >
> > I am attaching the pynac log.
> >
> > Daniel Bump
> >
> > --
> > You received this message because you are subscribed to the Google 
> Groups "sage-devel" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> an email to sage-devel+...@googlegroups.com.
> > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/sage-devel/b3b3d352-00fc-4356-93bf-b6232a113226n%40googlegroups.com
> .
>

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to sage-devel+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/sage-devel/8117c852-d71c-437f-a762-47f73cb91916n%40googlegroups.com.