[sage-devel] Re: help menu in jupyter notebook

[Kwankyu Lee]

On Saturday, April 27, 2024 at 2:30:00 PM UTC+9 Kwankyu Lee wrote:

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)


This motivates me to open #37878.


Exactly, https://github.com/sagemath/sage/pull/37878

-- 
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/30a2a84d-2939-4506-a5f9-95b18b8ef92dn%40googlegroups.com.

[sage-devel] Re: help menu in jupyter notebook

[Kwankyu Lee]

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)


This motivates me to open #37878.
 

-- 
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/5960a0a3-7bc4-4050-9198-5813898d1038n%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Yes, I was only talking about really just running Sage locally.

- Marc.

On Friday, April 26, 2024 at 7:54:38 PM UTC-5 Nils Bruin wrote:

> On Friday 26 April 2024 at 15:44:22 UTC-7 marc@gmail.com wrote:
>
> I don't see what difference the choice of port makes to a user.  It is not 
> possible to guarantee that the same port will always be used, since ports 
> are assigned on a first-come first-served basis.  Consequently it is not 
> possible to "bookmark" the address of either a jupyter server or a 
> cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
> address is always 127.0.0.1 in either case, by necessity.
>
>
> The port number that jupyter tries to use is configurable and there can be 
> reasons why you'd want to care about it. For instance, if you have a beefy 
> linux server that students in various locations want to use from windows 
> workstations. Ideally you'd run jupyterhub on it, but it's a complete 
> headache to figure out authentication and file system access and probably 
> impossible to find sysadmins capable and willing to make that setup secure.
>
> Instead, one could just assign a port number to each individual so that 
> they can set up a script to start their jupyter server on the right port on 
> localhost. They then just need to learn to use ssh (via PuTTY, for 
> instance) to tunnel the particular port from their desktop to the server 
> and then they can point the browser *on their own machine* to the right 
> address. It gets around the problem of getting people to install jupyter on 
> a windows box and it shows them an environment in which they could graduate 
> to useful work on the server themselves. And mainly, it gets around the 
> very real problem of getting a JupyterHub server set up. The price you pay, 
> of course, is that the port number is now very well-defined and actually 
> quite important. In that setup, it would be nice if the documentation were 
> served through the web server that jupyter is already running, because 
> that's the only port that's tunnelled. Or if the documentation just lives 
> on the internet; that's fine too (because if one weren't in an 
> internet-facing environment, setting up JupyterHub would at least be less 
> problematic from a security point of view).
>
> So, yes, if you're really just running it locally, the port number isn't 
> so important, but if any port forwarding comes into play, it becomes very 
> important to know the port number! 
>

-- 
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/7c9fbecb-6df0-41b4-9c46-5672e4f26149n%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 15:44:22 UTC-7 marc@gmail.com wrote:

I don't see what difference the choice of port makes to a user.  It is not 
possible to guarantee that the same port will always be used, since ports 
are assigned on a first-come first-served basis.  Consequently it is not 
possible to "bookmark" the address of either a jupyter server or a 
cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
address is always 127.0.0.1 in either case, by necessity.


The port number that jupyter tries to use is configurable and there can be 
reasons why you'd want to care about it. For instance, if you have a beefy 
linux server that students in various locations want to use from windows 
workstations. Ideally you'd run jupyterhub on it, but it's a complete 
headache to figure out authentication and file system access and probably 
impossible to find sysadmins capable and willing to make that setup secure.

Instead, one could just assign a port number to each individual so that 
they can set up a script to start their jupyter server on the right port on 
localhost. They then just need to learn to use ssh (via PuTTY, for 
instance) to tunnel the particular port from their desktop to the server 
and then they can point the browser *on their own machine* to the right 
address. It gets around the problem of getting people to install jupyter on 
a windows box and it shows them an environment in which they could graduate 
to useful work on the server themselves. And mainly, it gets around the 
very real problem of getting a JupyterHub server set up. The price you pay, 
of course, is that the port number is now very well-defined and actually 
quite important. In that setup, it would be nice if the documentation were 
served through the web server that jupyter is already running, because 
that's the only port that's tunnelled. Or if the documentation just lives 
on the internet; that's fine too (because if one weren't in an 
internet-facing environment, setting up JupyterHub would at least be less 
problematic from a security point of view).

So, yes, if you're really just running it locally, the port number isn't so 
important, but if any port forwarding comes into play, it becomes very 
important to know the port number! 

-- 
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/d96f03ed-51a8-464b-9412-7af5825507acn%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

The jupyter server operates on the loopback interface which has IP address 
127.0.0.1 and IP name localhost.  The cocoserver uses that same interface.  
Jupyter tries to get port  and if that is busy it hunts for a nearby 
port that is not in use.   The cocoserver uses an arbitrary system-assigned 
available port in the public range (above 1000).

I don't see what difference the choice of port makes to a user.  It is not 
possible to guarantee that the same port will always be used, since ports 
are assigned on a first-come first-served basis.  Consequently it is not 
possible to "bookmark" the address of either a jupyter server or a 
cocoserver.  The port should be viewed as arbitrary and unpredictable.  The 
address is always 127.0.0.1 in either case, by necessity.

- Marc

On Friday, April 26, 2024 at 4:05:12 PM UTC-5 Nils Bruin wrote:

> On Friday 26 April 2024 at 12:29:14 UTC-7 marc@gmail.com wrote:
>
> There are other issues with viewing local documentation files in a 
> browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is 
> not allowed to read a file:// url which is not in the user's home 
> directory.  As long as sage is installed in the user's home directory this 
> is not an issue.  But if the documentation is elsewhere then Firefox and 
> Chrome will refuse to show it.  Using the cocoserver works around this 
> because it is allowed to use a url with the loopback interface as the host 
> address.  (I think it is safer to use 127.0.0.1 instead of localhost 
> because, in principle, a rogue DNS server would be able to provide any IP 
> address as an A record for localhost). 
>
>
> The most flexible would be to serve it from would be whatever address the 
> jupyter server is serving on. That's why it might be easier to get this to 
> behave properly as a jupyter extension, because it could even serve it on 
> the same port in that case. I guess the OSX app has hardcoded that it 
> serves on 127.0.0.1 then? How do you work around port availability there? 
> Does coco listen on a separate port from the jupyter server?
>
>

-- 
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/a0cc2634-605d-4479-be1b-a7dc4171050an%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 12:29:14 UTC-7 marc@gmail.com wrote:

There are other issues with viewing local documentation files in a 
browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is 
not allowed to read a file:// url which is not in the user's home 
directory.  As long as sage is installed in the user's home directory this 
is not an issue.  But if the documentation is elsewhere then Firefox and 
Chrome will refuse to show it.  Using the cocoserver works around this 
because it is allowed to use a url with the loopback interface as the host 
address.  (I think it is safer to use 127.0.0.1 instead of localhost 
because, in principle, a rogue DNS server would be able to provide any IP 
address as an A record for localhost). 


The most flexible would be to serve it from would be whatever address the 
jupyter server is serving on. That's why it might be easier to get this to 
behave properly as a jupyter extension, because it could even serve it on 
the same port in that case. I guess the OSX app has hardcoded that it 
serves on 127.0.0.1 then? How do you work around port availability there? 
Does coco listen on a separate port from the jupyter server?

-- 
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/cdd187bb-4387-4b4d-8bab-44c3c3770775n%40googlegroups.com.

Re: [sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Yes, I meant MB.  Thanks.

There are other issues with viewing local documentation files in a
browser.  On Ubuntu, Chrome and Firefox are packaged as snaps.  A snap is
not allowed to read a file:// url which is not in the user's home
directory.  As long as sage is installed in the user's home directory this
is not an issue.  But if the documentation is elsewhere then Firefox and
Chrome will refuse to show it.  Using the cocoserver works around this
because it is allowed to use a url with the loopback interface as the host
address.  (I think it is safer to use 127.0.0.1 instead of localhost
because, in principle, a rogue DNS server would be able to provide any IP
address as an A record for localhost).  I don't know if there is a jupyter
extension that provides access to local files on the loopback interface.

- Marc

On Fri, Apr 26, 2024 at 2:12 PM Nils Bruin  wrote:

> On Friday 26 April 2024 at 06:53:28 UTC-7 marc@gmail.com wrote:
>
> I have a suggestion to improve the situation, which is to do what the
> Sage_macOS app does.
>
> The app provides access to a local copy of the documentation stored inside
> the application bundle.  The files are reorganized slightly to remove
> duplication and then compressed with gzip.  The app views the files using
> cocoserver , which provides a
> slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior
> of that server is modified so that it adds a gzip header to any file named
> *.gz.  The browser automatically decompresses gzipped files served with
> such a header.  ("Coco" stands for "compressed content".)
>
>
> Yes, I was thinking in that direction too. Is there perhaps already a
> jupyter server extension that can serve files in a local directory? I bet
> we can instruct jupyterlab to point at a "localhost" url rather than at "
> doc.sagemath.org"
>
>
> Compressing the documentation reduces the size (of the English
> documentation) from about 600 GB to about 100 GB.
>
>
> You meant MB probably?
>
>
> --
> You received this message because you are subscribed to a topic in the
> Google Groups "sage-devel" group.
> To unsubscribe from this topic, visit
> https://groups.google.com/d/topic/sage-devel/kzSWB8ps7VA/unsubscribe.
> To unsubscribe from this group and all its topics, 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/4e33bc5d-ba8e-419d-92a3-87977765ad86n%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/CALcZXRGFwTqZWkf%3DDkp6se_Gqo2z-BfwEK_eXiF0_kB1qDM%2BcQ%40mail.gmail.com.

[sage-devel] Re: help menu in jupyter notebook

[Nils Bruin]

On Friday 26 April 2024 at 06:53:28 UTC-7 marc@gmail.com wrote:

I have a suggestion to improve the situation, which is to do what the 
Sage_macOS app does.

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)


Yes, I was thinking in that direction too. Is there perhaps already a 
jupyter server extension that can serve files in a local directory? I bet 
we can instruct jupyterlab to point at a "localhost" url rather than at 
"doc.sagemath.org"
 

Compressing the documentation reduces the size (of the English 
documentation) from about 600 GB to about 100 GB.


You meant MB probably?
 

-- 
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/4e33bc5d-ba8e-419d-92a3-87977765ad86n%40googlegroups.com.

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

[Dima Pasechnik]

On Fri, Apr 26, 2024 at 2:24 PM Georgi Guninski  wrote:
>
> On Thu, Feb 15, 2024 at 2:27 AM Dima Pasechnik  wrote:
> >
> > I've filed https://sourceforge.net/p/maxima/bugs/4262/
> >
>
> Is maxima supported?
> There is no progress on their bug system for more than 2 months.

not many people are involved, and some bugs stay open for years there.


> SEGV is not pleasant, but incorrect symbolic result casts doubts about
> all symbolic sage computations, especially those that can't be
> verified numerically.
>
> --
> 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/CAGUWgD_MWht0_wBwXXsH-c%3DpKGSXUCgNBEbKq4PyLRc3g5k%3D_Q%40mail.gmail.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/CAAWYfq0mzJCU2MOhgGFKZCfwNtMU0J3cuOmddWxGY6dEqqi9PA%40mail.gmail.com.

Re: [sage-devel] Re: Question: why does /usr/bin/gcc get called during Sage startup?

[Marc Culler]

Here 
 
is a blog post which appears to corroborate my hypothesis that the 
duplicate libraries are being generated by XCode 15 and not by Sage's build 
system.

If the warnings are causing test failures it would probably be best to 
suppress them for now and somehow remember to re-enable them once the XCode 
bug gets fixed.

I still do not understand why adding -Wl,-ld_classic to LDFLAGS in sage-env 
does not cause the old linker to be used when building some spkgs.  
Apparently the LDFLAGS environment variable is not used in those cases, but 
I don't know why not.

- Marc

On Thursday, April 25, 2024 at 11:30:52 PM UTC-5 Marc Culler wrote:

> This looks pretty complicated.
>
> I used XCode 15.0.1 to build the macOS SageMath-10-3 app for Arm and XCode 
> 13.4 for Intel.  I got "duplicate rpaths" and "duplicate libraries" 
> warnings with 15.0.1 but not with 13.4. I pasted typical gcc commands (from 
> cvxopt) below.  You can see that:
> (1) Both commands contain duplicate rpath specifications but XCode 13.4 
> does not warn about them
> (2) duplicate libraries and invalid library search paths only occur with 
> XCode 15.01.
> (3) With 15.0.1 the gcc command does not include the linker option 
> -ld_classic, so the code in sage-env is not actually succeeding in using 
> the  old linker.  (But the build works anyway.)
>
> It is not clear to me that Sage is responsible for the duplicates, since 
> it seems to depend on the XCode version, and it is not clear to me that the 
> code in sage-env that aims to use the old linker has any effect, on spkgs 
> anyway.
>  
> - Marc
>
> XCode 15.0.1 on Arm:
> ---
> gcc -bundle -undefined dynamic_lookup 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/macOSX.sdk/usr/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib
>  
> -L. -Wl,-rpath,. -L/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,11.0,11.1 
> -L/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib -O2 
> -mmacosx-version-min=11.0 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/base.o 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/dense.o 
> build/temp.macosx-11.0-arm64-cpython-311/src/C/sparse.o 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib 
> -lm -lopenblas -lopenblas -o build/lib.macosx-11.0-arm64-cpython-311/cvxopt/
> base.cpython-311-darwin.so
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: duplicate -rpath 
> '/private/var/tmp/sage-10.3-current/local/lib' ignored
>   ld: warning: ignoring duplicate libraries: '-lopenblas'
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: search path 
> '/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk/usr/lib' not found
>   ld: warning: duplicate LC_RPATH are deprecated 
> ('/private/var/tmp/sage-10.3-current/local/lib')
>
> XCode 13.4 on Intel:
> 
> gcc -bundle -undefined dynamic_lookup 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-platform_version,macos,10.9,11.3 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/var/lib/sage/venv-python3.11.1/lib
>  
> -L. -Wl,-rpath,. -L/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/sage-10.3-current/local/lib 
> -L/private/var/tmp/sage-10.3-current/local/lib 
> -Wl,-rpath,/private/var/tmp/s

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Marc Culler]

On Fri, Apr 26, 2024 at 8:02 AM Dima Pasechnik  wrote:

> On Thu, Apr 25, 2024 at 4:36 PM  wrote:
>
> you might also like to know that in 2000 I asked whether we can have
> libgap :P
>
> https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html
> It
>

Thank you!  It is a struggle to convince people to make software reusable.
We are still struggling, but I do think there has been progress since the
turn of the century.

- Marc

-- 
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/CALcZXRGL%3DJdfU4zcvW%3D8Wsez4DB0QVHVG7vNepk0yjOh2zwA%2BQ%40mail.gmail.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Matthias Koeppe]

On Thursday, April 25, 2024 at 12:17:31 AM UTC-7 Martin R wrote:

On Thursday 25 April 2024 at 05:13:37 UTC+2 Matthias Koeppe wrote:

On Wednesday, April 24, 2024 at 1:07:44 AM UTC-7 Martin R wrote:

You mentioned several times, that discoverability is an important aspect.  
Do you have any evidence to support that?


I mentioned "discoverability" in the context of how I have *named* the 
distributions.


Sorry that my question was not clear enough.  Do you have evidence, that 
this naming enhances discoverability, and that this enhanced 
discoverability would be worthwhile, since it comes with a cost (as 
outlined above)?


What are you talking about? This naming, in contrast to **what other 
naming**, or in contrast to **what else**? 
What cost have you outlined, and where?

-- 
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/8014994e-4339-4310-890e-86fe1f32d45fn%40googlegroups.com.

[sage-devel] Re: help menu in jupyter notebook

[Marc Culler]

Another drawback of linking to online documentation is that the online 
documentation is always for the current release version of Sage, not the 
Sage that the user happens to be running,.

I have a suggestion to improve the situation, which is to do what the 
Sage_macOS app does.

The app provides access to a local copy of the documentation stored inside 
the application bundle.  The files are reorganized slightly to remove 
duplication and then compressed with gzip.  The app views the files using 
cocoserver , which provides a 
slightly modfiied subclass of Python's ThreadingHTTPServer.  The behavior 
of that server is modified so that it adds a gzip header to any file named 
*.gz.  The browser automatically decompresses gzipped files served with 
such a header.  ("Coco" stands for "compressed content".)

Compressing the documentation reduces the size (of the English 
documentation) from about 600 GB to about 100 GB.

The app also makes some small changes to the files __main__.py and 
kernel.py in sage/repl/ipython_kernel to make jupyter add options to  its 
Help menu for viewing the Sage documentation.

- Marc

On Tuesday, April 9, 2024 at 4:52:23 PM UTC-5 Kwankyu Lee wrote:

> On Wednesday, April 10, 2024 at 1:30:21 AM UTC+9 Denis wrote:
>
> At some point the help menu in jupyter notebooks started pointing to 
> doc.sagemath.org instead of the locally built documentation. I wouldn't 
> mind having a configuration option not to build the documentation, in which 
> case, of course, this would be expected. However, because the documentation 
> is still built by default, it looks more like a bug than a feature. Any 
> thoughts?
>
>
> That was done because jupyterlab help menu does not support loading local 
> documentation. 
>
> See https://github.com/sagemath/sage/pull/36246
>
> Any idea to improve the situation? 
>

-- 
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/cee02859-39d1-473d-8ae3-f2c9984b8652n%40googlegroups.com.

Re: [sage-devel] Incorrect result for `sum(1/factorial(n**2),n,1,oo)`

[Georgi Guninski]

On Thu, Feb 15, 2024 at 2:27 AM Dima Pasechnik  wrote:
>
> I've filed https://sourceforge.net/p/maxima/bugs/4262/
>

Is maxima supported?
There is no progress on their bug system for more than 2 months.
SEGV is not pleasant, but incorrect symbolic result casts doubts about
all symbolic sage computations, especially those that can't be
verified numerically.

-- 
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/CAGUWgD_MWht0_wBwXXsH-c%3DpKGSXUCgNBEbKq4PyLRc3g5k%3D_Q%40mail.gmail.com.

[sage-devel] Re: help menu in jupyter notebook

[Denis]

Only to put a note in the installation instructions somewhere, along the 
lines:

If the URL in your browser reads /foo/bar/notebooks/whatever.ipynb, then 
/foo/bar/kernelspecs/sagemath/doc/html/en/index.html will take you to the 
local documentation.

I have bookmarked a few such links, which is good enough for me, the only 
problem was figuring out the url.

Also maybe one could point out how to skip building the documentation.

Denis

On Tuesday, April 9, 2024 at 11:52:23 PM UTC+2 Kwankyu Lee wrote:

> On Wednesday, April 10, 2024 at 1:30:21 AM UTC+9 Denis wrote:
>
> At some point the help menu in jupyter notebooks started pointing to 
> doc.sagemath.org instead of the locally built documentation. I wouldn't 
> mind having a configuration option not to build the documentation, in which 
> case, of course, this would be expected. However, because the documentation 
> is still built by default, it looks more like a bug than a feature. Any 
> thoughts?
>
>
> That was done because jupyterlab help menu does not support loading local 
> documentation. 
>
> See https://github.com/sagemath/sage/pull/36246
>
> Any idea to improve the situation? 
>

-- 
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/3f6f305f-74e8-430b-a1e2-83614b2833ben%40googlegroups.com.

Re: [sage-devel] Re: Urgent and important: Please vote on disputed PR #36964 (next step of the modularization project)

[Dima Pasechnik]

On Thu, Apr 25, 2024 at 4:36 PM  wrote:
>
> On Thu, Apr 25, 2024 at 07:03:29AM -0700, Marc Culler wrote:
> > On Thursday, April 25, 2024 at 8:28:48 AM UTC-5 Dima Pasechnik wrote:
> >
> > Essential components of sagelib such as GAP, Singular, don't run on
> > native Windows
> >
> >
> > I was amused to find the following statement on the GAP forum
> >  from 2005:

you might also like to know that in 2000 I asked whether we can have libgap :P
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/using_GA.1/1.html

my 1st message to GAP Forum was sent in 1993:
https://www.gap-system.org/ForumArchive/Pasechni.1/Dmitrii.1/Re__brea.1/1.html


> >
> >   >  While porting GAP to use native Win32 calls is doable, basically
> > src/system.c is the only place
> >> that needs lots of changes, it is certainly a nontrivial and
> > time-consuming task. (and one needs
> >> to be a bit of an expert in programming to do this, IMHO)
> >
> > The author was someone from the Netherlands by the name of *Dima
> > Pasechnik.  :^)*
>
> It was me, yes. And I used to know from what end
> you have to approach a Windows machine. :-)
> But not to the point of knowing exactly how to change fork() and sbrk(),
> (and mmap()) into whatever functions with 15 arguments you have to use
> on Win32 as their replacements (they already have about 10 versions of
> spawn to use in place of fork).
>
> Note that since 2005 GAP has changed quite a bit, too.
> They made a go at making it multithreaded (HPC GAP), and that made code
> harder to deal with (HPC GAP is still beta).
> Instead of GAP's native GC (with its sbrk/mmap), HPC GAP uses Boehm GC, which 
> does run on native
> Windows. But it's a beta...
>
> Oh, and someone died porting GAP to Windows, some years ago.
>
> Dima
>
>
> >
> > - Marc
> >
> > --
> > 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/b0784b4b-ab38-4ff7-b5f7-d9cc47472b95n%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/CAAWYfq04q_KqiW_qEvPFRrqaHyC1Bf-a%3D1r1_bN3Lt0G61DqiA%40mail.gmail.com.

Re: [sage-devel] VOTE: Revert merged PR with unreviewed dependencies

[seb....@gmail.com]

Sure! But the fact was that reviewers objected to a commit in PR A that was 
approved in PR B, so their objection was simply ignored! Please don't 
understand me wrong. I'm not saying that it was your responsibility. It is 
still the responsibility of the reviewers to make sure that this does not 
happen. Probably this has become a bit harder since we moved to GitHub.

Volker Braun schrieb am Freitag, 26. April 2024 um 00:42:46 UTC+2:

> On Tuesday, April 23, 2024 at 6:24:51 PM UTC+2 seb@gmail.com wrote:
>
> The problem with this is: if there are commits on a branch that are 
> reviewed in more than one PR, the question is: does *positive review* 
> mean *all* or *some* PR's?
>
>
> The review is for a single PR, not for individual commits.
>
> The positively reviewed PR gets merged, and then you may or may not want 
> to rebase other PRs on the new develop branch. If you do, then the changes 
> that were merged disappear from the "files changed" tab of that other PR on 
> github. Either way, the commits from the positively reviewed PR are added 
> to the sage codebase.
>
>

-- 
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/51ae610f-7527-4581-93bb-dc092f8bfc4bn%40googlegroups.com.