On Tue, Sep 2, 2025 at 8:37 AM Marc Culler <marc.cul...@gmail.com> wrote:
>
>
>
> On Monday, September 1, 2025 at 11:18:36 PM UTC-5 Dima Pasechnik wrote:
>
> symlinking is flaky across VMs and filesystems. E.g. if you run Jupyter in a
> Windows browser (or in VSCode), with Sage running in WSL, then it seems to me
> one cannot avoid "jupyter kernelspec install".
> Well, yes, it's about 2.3Gb of data, but with the current capacity and cost
> of SSDs it's not something to worry about.
>
>
> I think most of this statement is highly questionable.
>
> Symlinking either works or does not work within a given context. If there
> were an example showing that it fails in this situation then that would be
> something to worry about.
Symlinks don't work on Windows filesystems. Your Appimage works in
this sense on Windows+WSL, but it's not via symlinks, but via a
built-in webserver.
Do all jupyter clients support these remote compressed docs?
> If not, then talk about "flakiness" is just talk.
>
> Also, 2.3GB is almost twice the size of the entire sage AppImage and is
> larger than the maximum size allowed for a release download in GitHub. The
> sage AppImage weighs in at 1.25GB, and occupies 1.25 GB on the user's disk,
> even though it contains the complete English documentation for sage.
>
> The way this works in the AppImage is that the html files stored in the
> AppImage are gzipped. The English documentation shrinks to only 120MB when
> redundant files are removed and the rest are gzipped. All browsers are able
> to decompress gzipped html files on the fly with no noticeable performance
> lag.
> So the AppImage provides its own webserver which delivers gzipped files when
> the reference() command or the jupyter notebook "Help" menu are used to view
> documentation.
OK, so the 2.3Gb issue goes away if we compress and prune the docs,
and only only then do
jupyter kernelspecs install
Is this what you are saying (because 120Mb is really not something to
worry about) ?
>
> Claiming that 2.3GB (or 10GB in the case of a full build of Sage) is not
> something to worry about is pretty crazy, even if there do exist some
> contexts where it is not an issue. There are other contexts where it is a
> serious issue.
I don't even see a noticeable delay while running "jupyter kernelspecs
install", assuming kernel and the target are on the same filesystem.
Perhaps spyware^H^H^H^H antivirus can slow this to a halt, almost, I
won't be surprised.
So there is no "if". It's just a way to do the job, without extra
built-in http servers, on the fly decompression, all these constantly
CPU-clogging things.
I don't know where 10Gb come from - pdf docs? Docs for all the
optional and standard packages?
Dima
>
> - Marc
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sage-release" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to sage-release+unsubscr...@googlegroups.com.
> To view this discussion visit
> https://groups.google.com/d/msgid/sage-release/6d8a678e-7b28-4d25-9c31-7a55f6596dd1n%40googlegroups.com.
--
You received this message because you are subscribed to the Google Groups
"sage-release" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sage-release+unsubscr...@googlegroups.com.
To view this discussion visit
https://groups.google.com/d/msgid/sage-release/CAAWYfq3%2BJKzLHkFev1wsvZKZJTrRGcbMdXbrwuzPu%3Dab%2BoJOQw%40mail.gmail.com.
