Re: [sage-devel] ERROR [transfer|run:135]: [Errno 404] Not Found when downloading cython-3.0.11.tar.gz

[Michael Orlitzky]

On Thu, 2024-10-03 at 06:13 -0700, Sébastien Labbé wrote:
> After a long period using an old version of Sage, I tried to update my 
> version of Sage yesterday to the latest development version, but the `make` 
> gets stuck while trying to download cython and maxima. See excerpt of log 
> below. I have never seen such a problem before, so I post my issue here.
> 

This never works. Try ./configure --enable-download-from-upstream-url

-- 
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/01bb041bc51663abf697eb374b0264722dda49b5.camel%40orlitzky.com.

Re: [sage-devel] view command

[Michael Orlitzky]

On 2024-09-27 23:45:58, Anne Schilling wrote:
> Dear All,
> 
> I see that there were some problems recently with the view command which 
> seem to have been fixed. However, compared to older versions of SageMath, 
> there still seems to be some odd behaviors. For example, the commands...

If you are on macOS, I would guess that your problem is fixed by

  https://github.com/sagemath/sage/pull/38339

which (among other things) adds the "-W" flag to the "open" command to
prevent a race condition on macOS.

-- 
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/ZviVfB4XvdSwdW36%40stitch.

Re: [sage-devel] Re: Package upgrade PRs waiting for review

[Michael Orlitzky]

On 2024-09-25 11:55:36, Matthias Koeppe wrote:
> On Monday, September 23, 2024 at 5:34:26 AM UTC-7 Michael Orlitzky wrote:
> 
> On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel 
> wrote: 
> > Matthias claims these 
> > are needed for the system-site-package feature. 
> 
> --enable-system-site-packages doesn't care about pyproject.toml
> 
> No, Michael, that's no longer true.
> 
> Since Tobias's PR https://github.com/sagemath/sage/pull/36982, at 
> bootstrapping time, some of the version_requirements.txt files are 
> generated from the src/pyproject.toml file. 

It still doesn't care what's in pyproject.toml. If pyproject.toml is
used to put inaccurate constraints in version_requirements.txt, that's
a separate issue. My opinion on this will be pretty consistent: the
version_requirements.txt for the sage distribution should contain the
version requirements for the sage distribution. That's what they're
for, and having accurate dependency information makes life better for
end users.

-- 
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/ZvTAmKi7BqZkQ2rN%40stitch.

Re: [sage-devel] Re: Package upgrade PRs waiting for review

[Michael Orlitzky]

On Sun, 2024-09-22 at 20:05 -0700, 'tobia...@gmx.de' via sage-devel
wrote:
> Michael, to make things short: The discussion is around these changes to 
> the `pyproject.toml` file 
> https://github.com/sagemath/sage/pull/38227/files#diff-0acbedc0b174ebec342997fdca9442a5486917ab04644da866213e97d2543604
>  
> which he claims harmonize the constraints with scipy (although scipy 
> actually declares a different numpy constraint). I'd argue that these are 
> incorrect as build-time requirements of scipy should not influence what 
> build-time requirements we declare for sage-the-lib. Matthias claims these 
> are needed for the system-site-package feature.
> 

--enable-system-site-packages doesn't care about pyproject.toml

As I probably argued when it was introduced, I think the pyproject.toml
for sagelib should contain the actual dependencies for sagelib, because
that's what it's for and that's what everyone expects and it makes life
easier for end users and packagers.

-- 
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/a33ae92c8d1639cf3553be2cebe22674223e1aa0.camel%40orlitzky.com.

Re: [sage-devel] Re: Package upgrade PRs waiting for review

[Michael Orlitzky]

On Wed, 2024-09-18 at 16:23 -0700, Matthias Koeppe wrote:
> 
> I would appreciate feedback from the developers working on this feature 
> (Dima?, Michael?) regarding how to specify these constraints now that 
> sage-lib defines its own constraints in pyproject.toml.
> 
> The change is purely syntactic -- that's all that your PR (and the 
> subsequent fixups of it) did. There has been no semantic change whatsoever. 
> Previously all version constraints were set centrally in the 
> build/pkgs/*/install-requires.txt files (recently renamed to 
> version_requirements.txt), now some are set in src/pyproject.toml. That's 
> all.

I don't know what happened, but a lot of the messages that I receive
from sage-devel now have no quoting. (One of the paragraphs above is
NOT mkoeppe). The quoting is there in HTML, but not in the plain-text
version that I read.

If I am failing to respond to questions, it's because I secretly have
no idea what's going on in 75% of these conversations any more.

-- 
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/06a3679246082c37fc1c73aec64ae8da84165f0b.camel%40orlitzky.com.

Re: [sage-devel] Python security: PyPI hijack exposes 22K+ packages to takeover attacks

[Michael Orlitzky]

On 2024-09-09 12:43:12, Georgi Guninski wrote:
>
> The DevOps and security firm estimates there are around 22,000
> packages in PyPI vulnerable to a revive hijack attack, and the
> researchers noted they've already spotted the technique being used in
> the wild to infect the pingdomv3 package.

Solved 30 years ago. Pip is not a package manager, only a fool would
install anything from pypi, npm, crates, etc, etc. Use only distro
packages. Downloading executables from strangers cannot be made safe.

-- 
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/Zt7MXoo-dBfGf-4L%40stitch.

Re: [sage-devel] Automatic beta release

[Michael Orlitzky]

On Fri, 2024-08-30 at 20:26 -0700, Kwankyu Lee wrote:
> 
> What do you think?


Why not do what everyone else does, and let developers merge PRs into
the "develop" branch when they're approved? Waiting only causes merge
conflicts. The release manager could still cherry-pick commits for
betas, release candidates, and actual releases. But having a release
process for the git repo is a quirk of an old development model that
doesn't make sense any more.

-- 
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/abd309596f3f26db6752dc239fe73832a8f3d102.camel%40orlitzky.com.

Re: [sage-devel] Proposal: Demote jupyter-jsmol and tachyon to optional

[Michael Orlitzky]

Playwright (via Chromium) would add another non-portable component to
sage, which incidentally downloads several hundred megabytes of
untrusted executable code from god-knows-where.

As a distro package, tachyon is mildly annoying, but all that it really
needs is a sane build system. The existing one is a case study in what
happens when you try to recreate autotools in undocumented Makefile
fragments. Ultimately it's not a complicated program to build.

The author doesn't have a bug tracking / PR system in place or an
obvious way to accept contributions. Has anyone tried contacting him?
If we spent a day collectively writing configure.ac and Makefile.am, it
seems to me that we could solve all of the problems shared by Sage,
Debian, Arch, Gentoo, etc.

-- 
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/8b4d66ea0ff827f97bf565d3a1f8b62f86074806.camel%40orlitzky.com.

Re: [sage-devel] Proposal: Policy for standard packages from binary wheels

[Michael Orlitzky]

On Wed, 2024-08-07 at 06:41 +0700, Bagas Sanjaya wrote:
> 
> In Windows, that's quite common for people to have antivirus installed.
> But for people on Linux, they usually don't install one.
> 

On Linux, people aren't usually dumb enough to download exes from
strangers. Yet here we are.

-- 
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/b9f075140f7244c8149a185633a2f5e51cc65743.camel%40orlitzky.com.

Re: [sage-devel] Sage-10.4 fails to build

[Michael Orlitzky]

On Fri, 2024-08-02 at 07:09 -0700, Niranjana K M wrote:
> At first I had flint-3.1.0 from Gentoo portage. Got same errors and build 
> failed. The I uninstalled flint and its dependents from Gentoo and let the 
> Sage choose its flint spkg. Again it also failed with same errors.
> 

These errors,

> local/include/flint/nmod_mpoly_factor.h:366:49: error: expected ')' before 
> '__extension__'

arise from flint's use of the variable name "I" in a few places. C99
technically forbids that IIRC. Our flint-3.1.3_p1 package (but no
earlier versions) contain a patch from Dima to fix the issue.

We were expecting people to hit this with gcc-14 which is still
unstable, but I guess some of the patches that have been backported to
your 13.3.1_p20240614 trigger it. I've filed a stabilization request
for flint-3.1.3_p1 to get ahead of the problem.


-- 
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/eac41aa05c052b7c16233bc5753e767f700ebaf2.camel%40orlitzky.com.

Re: [sage-devel] Sage-10.4 fails to build

[Michael Orlitzky]

On 2024-08-02 15:19:03, Niranjana K M wrote:
> Dear Sage developers,
> Sage-10.4 fails to build on my computer running with Gentoo Linux.
> It uses gcc-13.3.1 and python-3.12.3.
> Sagemath is the master branch from git.
> It fails to build sagelib-10.4. If i search for errors in log i could find
> lines related to flint.

Install sci-mathematics/flint-3.1.3_p1, re-run ./configure, and try again?

-- 
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/ZqzPuJX_i6fF3qRD%40stitch.

Re: [sage-devel] eclib version checking

[Michael Orlitzky]

On Wed, 2024-06-26 at 15:26 +0100, John Cremona wrote:
> In build/pkgs/eclib/spkg-configure.m4 tere is code to check whether an
> already installed version of eclib is new enough.  It use to check that the
> version agreed exactly, but now it uses [ge] ("greater or equal") to do
> this.
> 

Did you update spkg-configure.m4 yourself? The one I have (develop
branch) is still using equality:

  m4_pushdef([SAGE_ECLIB_VER],["20231212"])
  PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],
  ...

In any case, after changing it, you have to re-run ./bootstrap.

-- 
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/bba6a9f8ad088d3233fd70abce379bc250bd8ae3.camel%40orlitzky.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Michael Orlitzky]

On Mon, 2024-06-03 at 12:54 -0700, Matthias Koeppe wrote:
> 
> Could you share details regarding this? I'm not sure who "we" is in what 
> you write, but in the last Jupyter PR that I prepared, I had to use some 
> older versions of some packages to avoid pulling in the Rust dependency at 
> this point.

The one I have in mind is: I am peacefully using borgbackup, a python
program, to back up our servers.

Borg depends on pkgconfig (python). Pkgconfig uses poetry (python) as
its build system. But poetry has a dependency on jsonschema (python),
and one day, the jsonschema package adds a dependency on rpds (rust).
Now I need to rebuild rust packages every time I update my system in
order to use my python backup program. This requires a rust compiler,
ABI unstable, so not only do I have to update the packages that have
changed but pretty much every rust package on the system during every
upgrade.

Poetry is a popular build system so this impacted many casual users of
python programs. It was a major PITA on Gentoo in particular because
python runs on more architectures than rust. Lots of end user packages
"broke" when the rust dependency was introduced because on certain
arches those dependencies "disappeared."

Anyway, poetry eventually replaced jsonschema with fastjsonschema to
avoid cursing its own users:

  https://github.com/python-poetry/poetry-core/pull/642

-- 
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/7f7b2ddd34b4144b6f51a1762093e4e3e45e1bf8.camel%40orlitzky.com.

Re: [sage-devel] Re: Current status of possibility of integrating libraries written in Rust into Sage

[Michael Orlitzky]

On Sat, 2024-06-01 at 10:02 -0700, Matthias Koeppe wrote:
> Unlikely that we would add a package to the Sage distribution that builds a 
> Rust library from source. 
> 
> Not so long ago we added support for installing Python packages from 
> platform-independent wheels. We did this to sidestep the concern of 
> shipping more and more of Javascript (Node.js) infrastructure that is 
> needed for building JupyterLab components.
> 
> Likewise, we will soon add support for installing Python packages from 
> platform-dependent wheels. This is needed for updating some Jupyter 
> components that have started to use Rust (https://github.com/crate-py/rpds, 
> a dependency of jsonschema).

The jsonschema package was being replaced by fastjsonschema in its
consumers the last time we ran in to this problem.

Rust is not nearly as portable as C, and has an unstable ABI that makes
shipping compatible versions of packages from multiple sources nearly
impossible. Will Sage's wheel packages be compatible with the wheels
built by the Gentoo package manager? Even for a single source, more
labor is involved -- instead of rebuilding each package once when it
changes, you wind up rebuilding all of its consumers, and then all of
their consumers, and... so on recursively.

We're already drowning in this regard and incorporating rust in any way
will make it a lot worse.

-- 
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/4cbea3e620e0481d4d2849fec72b6e4c2d4e5dcc.camel%40orlitzky.com.

Re: [sage-devel] Unreasonably slow piecewise function

[Michael Orlitzky]

On Thu, 2024-05-02 at 02:13 -0700, Kwankyu Lee wrote:
> Moreover,  this case seems to spur the need to introduce timing tests to 
> watch out regressions in code performance without a failure.
> 

Shameless plug:

  https://github.com/sagemath/sage/pull/36226

I see these regressions (old hardware), but AFAIK nobody else does.
This is largely due to the test suite reporting wall time. On fast
hardware, you won't notice if a test gets 2x slower because it's still
fast.

-- 
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/53088c660ccb846dfdb291f25ccf13f99f712ceb.camel%40orlitzky.com.

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

[Michael Orlitzky]

On 2024-04-20 15:33:51, Matthias Koeppe wrote:
> Michael, I think you may be using too much jargon to get your point across 
> to the general readership of this list. 
> 
> Let's maybe use this opportunity to make this as concrete as possible and 
> explain it in the most plain terms.
> What entanglement are you concerned about?

For example, we have several tickets that are disputed because they
will use ./bootstrap and data from the sage distribution (build/pkgs)
to generate the pyproject.toml files for the modular components. This
ensures that the components cannot truly be separated, not only from
the other components, but from the mini-distro in build/pkgs that a
large chunk of us hate.

Contrast with some other parts of sage that have been modularized:

 * pplpy
 * memory-allocator
 * cypari
 * cysignals
 * primecountpy

These have been successfully disentangled from both the sage library
and the sage distribution and I don't think anyone has complaints
about them. They've been moved to separate repositories which, while
not strictly necessary, is certainly proof that they are in fact
disentangled. We can typically depend on stable versions of them and
install/test them independently. They do not depend on nonstandard or
bleeding-edge features of the python ecosystem.

-- 
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/ZiWKZlNHnBxOvBXm%40stitch.

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

[Michael Orlitzky]

On Sat, 2024-04-20 at 15:01 -0700, kcrisman wrote:
> 
> Can someone who is not Dima or Matthias explain to us how it is possible 
> that they both are claiming to represent the normal Python way of doing 
> things?  There have been numerous statements by both of them about this, 
> which makes it sound like there are two pieces to it (modularization but 
> also "de-vendoring"), and I can only assume that it would be possible for 
> both to occur simultaneously.

It is, but in its current incarnation, the modularization relies
heavily on the sage distribution vendoring. Conflict arises because the
modularization is cited as a blocker whenever someone wants to pare
down or disentangle some aspect of the sage distribution. It's not the
modularization per se that we object to. Personally, I would like it to
succeed, but not at the expense of everything else.

-- 
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/df724126d0521bf9eb1275ba961bc1b5355b3af7.camel%40orlitzky.com.

Re: [sage-devel] On backdooring open source projects

[Michael Orlitzky]

On Sat, 2024-04-20 at 12:53 -0700, Emmanuel Charpentier wrote:
> 
> Do we have the manpower necessary to such development ? .

Linux distributions (or e.g. Conda) already do it for us.

What we don't have is the manpower to do what we currently do, but
*correctly*. The sage distribution sucks. Lots of packages are
outdated. Our ./configure detection system doesn't understand complex
requirements. It can't do dependency resolution (can't tell if a
package is needed or not). System and SPKG packages can't be mixed. We
can't pass ./configure options to the packages we build. We don't have
different classes of (build, runtime, test) dependencies. Our build
scripts are random collections of shell code. Our tests don't pass. We
can't rebuild for ABI breakage. We don't support multiple versions of
packages. The standard/optional system is inconsistent. We can't push
security fixes to users. In fact, we don't even bother to look for
security issues in the first place.

Everything's easy if you do a bad enough job at it.

-- 
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/c88dc1d64531e0d5a703c528af8442816a0c8662.camel%40orlitzky.com.

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

[Michael Orlitzky]

On Sat, 2024-04-20 at 10:07 +0100, Dima Pasechnik wrote:
> 
> Apart from Lisp, there is GAP (with the corresponding effort stalled).
> 
> That's what is much more urgent than attempting to slice up the maths 
> functionality of sagelib.
> 

Also the ancient copy of ginac/pynac we bundle.

-- 
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/1bdc2256d9219edd8932684c382b67b7e3b2ab35.camel%40orlitzky.com.

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

[Michael Orlitzky]

On Sat, 2024-04-20 at 02:22 -0700, Volker Braun wrote:
> Yes in a perfect world, but then you don't get a gold star for satisfying 
> some purity test. We should just do the minimal amount of work to get us 
> where we want to be. Lets focus on the direction to go and not too much on 
> the process.

We don't know where we want to be. To figure that out, we should hold
some kind of vote or something.

-- 
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/0af0f7b84ecf841a5a034725bdf903721fecf4cf.camel%40orlitzky.com.

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

[Michael Orlitzky]

On Fri, 2024-04-19 at 09:46 -0700, Matthias Koeppe wrote:
> 
> Michael, note that in my message I asked for a vote on that dependency 
> https://github.com/sagemath/sage/pull/36676.
> 

Even if 36676 gets approval, 36964 must be reverted. It was not
meaningfully voted upon.

-- 
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/f1e270d25dbbb709bc5de43f6e4586502551b587.camel%40orlitzky.com.

Re: [sage-devel] On backdooring open source projects

[Michael Orlitzky]

On 2024-04-18 16:04:43, Lorenz Panny wrote:
> > 
> > It's also 214 software packages which might, for all we know, at any
> > time be hijacked by The Bad Guys to run arbitrarily malicious code on
> > every Sage user's machine.
> > 
> > This is terrifying.

276 now

-- 
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/ZiJZBm_dH6BOxaOM%40stitch.

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

[Michael Orlitzky]

On 2024-04-18 14:18:37, Matthias Koeppe wrote:
> Dear all:
> 
> As an alternative to the proposal to back out the 
> PR https://github.com/sagemath/sage/pull/36964 whose *disputed dependency 
> PR https://github.com/sagemath/sage/pull/36676 which had not reached the 
> required 2:1 supermajority *of the dispute-resolution process *(it 
> currently only has a simple majority of 7 votes in favor, 5 votes against)* 
> --- I am asking for your votes on that dependency PR 
> https://github.com/sagemath/sage/pull/36676 to heal the process. This will 
> avoid further delays and disruptions.

This doesn't circumvent the issue. Voting on PRs with disputed
dependencies is nonsensical and counterproductive. We were told they
wouldn't be merged. I have no idea what 36964 is about and if I'm for
or against it because it's a waste of time until its dependencies are
accepted/rejected. Only then (after another two weeks or whatever) can
the vote on 36964 be considered meaningful.

-- 
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/ZiJLyed2j5zM1xfp%40stitch.

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

[Michael Orlitzky]

On Thu, 2024-04-18 at 11:54 -0400, David Roe wrote:
> I am therefore asking you to vote (+1 means merge #37796
>  in order to revert #36964
> ).

+1

-- 
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/f000412ee798040a72f7b86cce332529f8121993.camel%40orlitzky.com.

Re: [sage-devel] Re: Proposal (redo): Make python_build (and its dependency pyproject_hooks) a standard package

[Michael Orlitzky]

On 2024-04-15 04:20:59, kcrisman wrote:
>
> The real question is about *users* in this case, not developers.

The solution for users is pretty simple. You should be able to install
a sage that works and will remain working with one command using
homebrew, conda, guix, etc. The reason you can't is because Sage is,
and has always been, hostile to it.

We (not just Sage, but you and I!) have been discussing this for
almost 15 years. Based on that number you would think that packaging
involves some deep question in software architecture, but it
doesn't. I package hundreds of other programs. They're all easy to
install and work great. Sage is the _one_ project that is a PITA. If
you want to use GAP or Octave, no problem. No way to prevent this,
says only country where this regularly happens.

SageMath has several other long-term contributors who also package
software. We're all roughly on the same page about what it would take
to fix the sage installation for end users. Eventually it might make
sense to listen to the people who have succeeded at the task before.


>  We need something approximating this sort of summit now to resolve these 
> issues - and I certainly do think there is an acceptable solution out there.

The solution to this social problem is once again quite simple. The
people who want to work on the sage distribution should be allowed to
work on the sage distribution, and the people who don't should be
allowed not to. But so far, every attempt to disentangle the
library/distribution to enable this division of labor has been met
with resistance by essentially one person.

-- 
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/Zh0XiN1zHQrhfGZN%40stitch.

Re: [sage-devel] Re: xz/liblzma has been compromised

[Michael Orlitzky]

On 2024-03-30 07:08:45, Marc Culler wrote:
> > Potentially, any tarfile we host may contain an exploit. 
> 
> Potentially, any file may contain an exploit.
> 
> This hack specifically targeted ssh.  When used by ssh to verify keys, the 
> hacked liblzma would validate certain invalid keys, allowing a "back door" 
> for a particular bad actor to login to the system.

The backdoor that was _found_ targeted SSH. The person who put it
there had commit access to the project for a long time.

I've seen many people assume that if they aren't running a patched
sshd, then they're safe by downgrading to an earlier version free of
the sshd hack. If your earlier version was maintained by the same
malicious person, I wouldn't be so sure. This was a coordinated attack
starting in 2021 or earlier.

None of that invalidates your point of course: bundling (or not) is
irrelevant if the person writing your code is untrusted. On the other
hand, this wouldn't be "our code" if we didn't run our own distro.

-- 
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/Zggi-KQ_gsPs4RTf%40stitch.

Re: [sage-devel] No MathJax display in Sage 10.3.beta notebooks when offline

[Michael Orlitzky]

On Thu, 2024-02-15 at 13:13 -0800, Nils Bruin wrote:
> According to the jupyter notebook documentation:
> 
> https://jupyterbook.org/en/stable/content/math.html
> 
> it should be possible to switch jupyter from using mathjax 2 to mathjax 3 
> by some configuration option (no clue where those configuration options 
> would go, and no indication is given in the tip either).

The notebook release process minifies all of its javascript code. The
bit that sets the MathJax options is in there somewhere but good luck
finding it.

-- 
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/47eb509cbbc8aee21f317760f02c09a11d3a8733.camel%40orlitzky.com.

Re: [sage-devel] One year of Sage development on GitHub

[Michael Orlitzky]

On Thu, 2024-02-08 at 11:30 +, Dima Pasechnik wrote:
> 
> We should not try to compete, in effect, with Conda etc, yet we do. This is
> the primary reason for slowness.
> 

My personal stats for the year 2023-02-08 through 2024-02-08:

  Commits: 423
  Reviews: 38

Zero of those have anything to do with mathematics.

-- 
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/665f0fd945ca6301e75489e1922fb03462cda021.camel%40orlitzky.com.

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

[Michael Orlitzky]

On Sat, 2024-01-13 at 14:54 +0530, Niranjana K M wrote:
> 
> I thought the installation would replace the previous builds when new
> system packages are available. It is preferring old local spkg installs, if
> already present, than new versions in system. But if it is spkg only it is
> going for update.
> 
> Is it needed to be fixed or is it usual?

Both.

It should have used the newer packages, but I can't say I'm surprised
that something went wrong. The reason I `git clean -x -f -d` before
every build is because I used to hit these strange issues too often.

FWIW we're about to get GAP in Gentoo:

  https://github.com/gentoo/gentoo/pull/34472

And then the only system packages that are missing are PALP and a few
databases. Everything else can be detected and used by Sage, and that
should speed up a clean build by a lot. I would still recommend the
"develop" branch to keep up with the latest changes until Sage itself
finds its way into Gentoo.

-- 
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/8a8e173f9545c6ddb7b4d9e6d75479dff0b0d97f.camel%40orlitzky.com.

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

[Michael Orlitzky]

On Fri, 2024-01-12 at 09:25 -0800, Niranjana K M wrote:
> Should I have had started by cleaning the previous builds? It may be still 
> using old Cython spkg, built when it was sage 10.0 release. Because in venv 
> site-packages, it still says  
> sage/venv/lib64/python3.11/site-packages/Cython-0.29.32.dist-info.

Very possibly.


> What are the right sequence of commands to update an existing sagemath git 
> installation? I just did:

Personally I run `git clean -x -f -d` before ./bootstrap to remove
absolutely everything that isn't part of the repository.

-- 
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/799606af358fb48cff6eeeca999a877c3e323ff3.camel%40orlitzky.com.

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

[Michael Orlitzky]

On Fri, 2024-01-12 at 08:33 -0500, Michael Orlitzky wrote:
> 
> One thing I noticed is that you said "master" branch. Please try the
> "develop" branch instead -- that's where the actual development takes
> place. Both Sage and Gentoo are fast-moving and you'll have better luck
> with the latest code.

I tried with "master" and did not hit this issue. Our systems are
otherwise very similar so that is discouraging, but doesn't necessarily
mean that "develop" won't work for you. I'll continue to poke at it.


-- 
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/41211b7e8a717b12d253299103bb18e0d2f7e438.camel%40orlitzky.com.

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

[Michael Orlitzky]

On Fri, 2024-01-12 at 18:24 +0530, Niranjana K M wrote:
> It is attached in the previous mail.
> 

Indeed, sorry, it was my first email of the day. I have to get warmed
up first.

One thing I noticed is that you said "master" branch. Please try the
"develop" branch instead -- that's where the actual development takes
place. Both Sage and Gentoo are fast-moving and you'll have better luck
with the latest code.

(Does anyone actually use the master branch? Someone who wants to check
out a release could just, like, check out the release. They're tagged.
It's a silly pitfall.)

-- 
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/85fc5dee1e753b9a70eb3ffdda58cec1f4e35c8c.camel%40orlitzky.com.

Re: [sage-devel] Error compiling sagelib-10.2 with --enable-system-site-packages

[Michael Orlitzky]

On Thu, 2024-01-11 at 20:56 -0800, Niranjana K M wrote:
> 
> I am running on Gentoo Linux and sagemath is from git master branch.
> I am having system cython-3.0.6 built on python-3.11.7.
> 
> Please help me to resolve it.
> 

Can you post your config.log?

-- 
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/c5cf266528f33850d3f1f4eac10e3c2e76c211b1.camel%40orlitzky.com.

Re: [sage-devel] Disputed Pull Requests / Role Sage-Abuse and the Code of Conduct

[Michael Orlitzky]

On Wed, 2024-01-10 at 06:49 -0800, William Stein wrote:
> Dear Sage Developers,
> 
> 1. There are over 20 pull requests labeled as "disputed" [1].  To
> resolve these pull requests, we will be appointing an editor with no
> direct involvement in the pull request to make a judgement call on
> that particular pull request.   We will then fully support the
> decision of this editor. If you have the time to be the (possibly
> anonymous) editor for a disputed pull request, please email us
> (wst...@gmail.com, vbraun.n...@gmail.com) and we'll  add your name to
> our list.
> 

Many of these are disputed for the same underlying reasons. Appointing
a different editor for each PR is not likely to help. If you pick an
editor from Camp A, he or she will always rule in favor of Camp A; pick
an editor from Camp B...

I foresee several problems resulting:

  1. We'll wind up with disputes about how the editor was chosen in
 place of disputed PRs.

  2. The editor is essentially ruling in favor of a development 
 philosophy, and it would make little sense to rule against
 the opinion of the majority of sage developers (if there is
 such a thing).

  3. It often doesn't make sense to rule in favor of Camp A for
 one PR and Camp B for another.

  4. It enables editor shopping and PR ping pong. Rule against me
 the first time? I can try again in two weeks and hope for a
 different editor.

Different journal editors can accept competing publications without
much harm, but here that's not the case.

-- 
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/8d3dbe043ffe7bc6f6e60d2994c67abaebf97796.camel%40orlitzky.com.

Re: [sage-devel] Unable to compile JuPiMake

[Michael Orlitzky]

On Wed, 2023-12-20 at 16:42 +0100, Salvatore Stella wrote:
> > Did you build polymake with USE=libpolymake?
> 
> I did, before I did not and sage build system refused to use my system's 
> polymake.
> 

Hm, my next guess is then

  https://github.com/sebasguts/JuPyMake/issues/4

since I think that's also on Gentoo. I can be more certain in a few
hours after polymake builds.

-- 
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/a85baa43475e440ed214189230a344156d074790.camel%40orlitzky.com.

Re: [sage-devel] Unable to compile JuPiMake

[Michael Orlitzky]

On Wed, 2023-12-20 at 16:13 +0100, Salvatore Stella wrote:
> 
> I have polymake 4.11 installed through my system package manager (gentoo) and 
> I am using gcc 13.2.1. The same issue happens if I try to install JuPiMake 
> though the sage build system, using pip through PyPi in a virtualenv, and 
> from sources.
> 

Did you build polymake with USE=libpolymake?

I think the important part is missing from the error message, but it
failed during linking, so maybe -lpolymake is what doesn't work.


-- 
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/403216dfba3aa6da8b2f126c2379562abeaf31fb.camel%40orlitzky.com.

[sage-devel] Removing Cygwin support

[Michael Orlitzky]

We dropped Cygwin support in September 2022,

  https://github.com/sagemath/sage/wiki/Sage-9.7-Release-Tour

but that was mainly a documentation change reflecting the fact that
Cygwin support had bit-rotted.

Anyone could have fixed it at that point -- or in the meantime -- but
no one has done so. I think it's time to admit that Cygwin is a dead
platform for us. WSL is a much easier replacement these days if your
goal is to get Sage running on Windows.

The issue was made relevant again by PR #36129 which reintroduces the
psutil package as standard. The meat of psutil is platform-specific C
code that does not work on Cygwin, and it's not something we can
realistically fix.

If it's never coming back, I'd like to start removing the old Cygwin
workarounds from sage. This is your heads up in case there are still
users out there.


-- 
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/6e797b162a0501b3646be9bfca2e0fe3ed7ab6b6.camel%40orlitzky.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Michael Orlitzky]

On Fri, 2023-11-17 at 10:49 -0800, Marc Culler wrote:
> I expect to receive lots of flak for saying this, but I support making 
> libjpeg be a standard spkg using the source code from 
> https://libjpeg.sourceforge.net.  I just built version jpeg-9e on Ubuntu 
> 18.04 and macOS 10.13.  The standard ./configure ; make install method 
> works flawlessly - not even any warnings.  The build is fast and the 
> package is small.  Installing it in sage/local/lib will be simpler, faster 
> and more reliable than guessing where it might be found on any of the 
> zillion systems that Sage runs on.  Also, unlike  the turbo alternatives, 
> it does not depend on fancy features of Intel hardware which will not be 
> available on old Intel CPUs or recent Arm CPUs.

I was vague about this because I didn't want to go digging...

We had to drop this from Gentoo a few years ago for several reasons.
The first is simply that it's not actively maintained. There are
roughly two years between versions, which isn't good enough when a new
clang is released every few months. Where's the bug tracker? Mailing
list? People can't quietly accept security issues or build failures for
that long. We could work around it by backporting enough patches, but
do we really want to maintain a sage fork of libjpeg for two years at a
time? (Are we going to write the patches ourselves if the other distros
quit doing it? Is any distro still shipping the IJG libjpeg?)

The second is that it's no longer compatible with libjpeg-turbo, and
that's what most people target. Chromium and Qt, for example, only
build against libjpeg-turbo -- or at least did, back when we removed
libjpeg. Thus if you have to pick only one and ship it to your users,
the choice is obvious. You can't have both because they provide the
same API. This might not be a huge problem so long as pillow and every
other sage component support them both, but who knows what the future
holds.

The libjpeg-turbo features degrade gracefully by the way. I'm certain
to have the oldest intel computer here, and I've been using libjpeg-
turbo for 9+ years, as far back as my git history goes.

I'm not against adding jpeg support to sage per se, I just think it's
going to be a pain to add it to sage-the-distribution. I'm using my
system's copy of pillow that uses my system's copy of libjpeg-turbo,
nicely avoiding the entire problem, but only as a user.

-- 
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/ac6c18b60d4998d84bcb581c9b62cf89023fab2a.camel%40orlitzky.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Michael Orlitzky]

On Fri, 2023-11-17 at 17:26 +, Dima Pasechnik wrote:
> 
> Why can't Features be set up by ./configure ? You'll tell me that
> (some) distributions don't run ./configure, but this is beside the
> point.
> They have ways to know what's installed and what's not installed.
> 

I think the problem is that ./configure is in the wrong place. Sagelib
needs its own build system that can detect libraries, run tests, and
determine paths, so that things still work when we build only sagelib.

That's one of the reason's I'm so happy that Tobias is working on the
meson build. In theory it would let us eliminate most of the top-level
./configure, sage-conf, and all of the runtime feature testing -- to be
replaced with something simple, predictable, and standard.


-- 
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/d943b9c6a37d63df0b356448d027c421dc081a2b.camel%40orlitzky.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Michael Orlitzky]

On Fri, 2023-11-17 at 02:33 -0800, Eric Gourgoulhon wrote:
> On 17 November 2023 04:35:53 GMT, Matthias Koeppe  
> wrote: 
> > Or we just let pillow use a system libjpeg if it finds one.
> 
> This would probably be the easiest solution: I cannot imagine a system 
> without libjpeg...

I don't know how common it is, but it's pretty easy to build a headless
server without libjpeg.

-- 
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/9b95589015ab0262dcee259efd8e67637594b6c5.camel%40orlitzky.com.

Re: [sage-devel] Pillow built without jpeg support in Sage 10.2.rc3

[Michael Orlitzky]

On Thu, 2023-11-16 at 06:48 -0800, Eric Gourgoulhon wrote:
> 
> If we agree to restore jpeg support in Pillow, I have prepared a branch 
> that does this for Sage 10.2 (simply suppressing the option "jpeg=disable"):
> https://github.com/egourgoulhon/sage/tree/pillow_jpeg
> and I am happy to submit a PR for this.
> 

That makes pillow link to libjpeg, so we'd also need to package some
incarnation of libjpeg, make it a standard package, write the spkg-
configure script, etc.

AFAIK the "best" libjpeg is https://libjpeg-turbo.org/, but then we
would also need to package an assembler (nasm or yasm) to build it...

-- 
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/a5f2d0a90ca2521d0882ac4c1b42f33b2ea36c19.camel%40orlitzky.com.

Re: [sage-devel] eclib dependencies

[Michael Orlitzky]

On 2023-11-16 09:23:15, John Cremona wrote:
> 
> If no-one has any reason to keep things as they are I will make a PR with
> the relevant changes to build/pkgs/eclib.

>From a packaging standpoint, fewer dependencies is better. For
example, upgrading flint would become a tiny bit easier if we didn't
have to worry about it breaking eclib. And on Gentoo we have a lot of
people who simply prefer to turn every optional feature off. So I
think it's a nice idea.


> Also, looking at eclib's spkg-configure.m4 I see (and recall) that we put
> in a check for an exact eclib version (currently 20230424), which seems
> unnecessarily restrictive.  I would welcome suggestions for how to either
> check for a certain version *or later*, and/or check that the library has
> certain functions which we know that Sage wil need.

The version restrictions are usually about the tests passing and not
about what works. For example if foo-1.0 prints "1 + 2" and foo-2.0
prints "2 + 1", that can cause the tests to fail until we update them
to accept both outputs. In the meantime we would probably reject
foo-2.0 even though it too gives correct answers. (This will get
better as fewer people rely on sage-the-distribution for exact
versions.)

Anyway, in this case, there are two autoconf tests that need to be
changed from equality to greater-than-or-equality:

  PKG_CHECK_MODULES([ECLIB], [eclib = SAGE_ECLIB_VER],...
  AX_COMPARE_VERSION([$mwrank_version], [eq], [SAGE_ECLIB_VER],..

-- 
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/ZVYH-QiUAXLbkkx-%40stitch.

Re: [sage-devel] Re: Cython errors when building p_group_cohomology

[Michael Orlitzky]

On 2023-11-16 00:51:12, Dima Pasechnik wrote:
> This package produces mathematically incorrect results, as was shown
> on a trac ticket a couple of years ago, and no movement then. Demote
> to experimental?

There's not much distinction at this point, but if we're going by the
"builds on supported platforms" criteria, then it makes sense.

What would make even more sense is to give it a meson.build file (to
locate singular and gap), stick it on pypi, and then delete it from
the sage repo because at that point it could be installed with pip.

-- 
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/ZVVqg4lq6tia3Rcw%40stitch.

Re: [sage-devel] Re: Question about make dependencies

[Michael Orlitzky]

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 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/ZVQJLHJ08qXQ2I2r%40stitch.

Re: [sage-devel] Re: Question about make dependencies

[Michael Orlitzky]

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 was successful and the package was installed.

I think most of us have the system copy of gmp detected by ./configure,
so there could very well be a bug that we haven't noticed. But ideally
you should also be using the system copy of gmp.

Does ./configure say why the system copy is unsuitable?

-- 
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/25eeaa1d9b467afe24e61994e324a4f120c49b75.camel%40orlitzky.com.

Re: [sage-devel] Fedora sagemath package maintainer

[Michael Orlitzky]

On Sat, 2023-09-30 at 14:36 -0700, enriqu...@gmail.com wrote:
> I have learnt that at this momente there is no Fedora sagemath package 
> maintainer. I am a Fedora user but I do not use the rpm package; more 
> relevant, I do not have the skills for this maintenance.
> Would anyone take the task?
> Best regards, Enrique.

It's a lot easier for a fedora developer to become interested in sage
than it is for someone interested in sage to become a fedora developer.
You might have better luck on the fedora mailing lists?

-- 
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/eaf34d3b4b06f53053b722f5046b8af35b1bdea4.camel%40orlitzky.com.

Re: [sage-devel] Poll: deprecate backslash operator

[Michael Orlitzky]

On Sat, 2023-09-30 at 14:47 -0700, John H Palmieri wrote:
> 
> This is not used much: for matrices, matroids, and a tiny bit (at least in 
> the Sage library) for binary trees. Should we deprecate it?

Deprecate it, it's a big WTF for most people.

-- 
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/1f8eb23d9c89b6debe62ebd2d9faec3965008236.camel%40orlitzky.com.

Re: [sage-devel] Discussion and poll: should Sage Integers have a backslash operator?

[Michael Orlitzky]

On Wed, 2023-09-27 at 14:44 -0700, Nils Bruin wrote:

> Searching the codebase currently only shows "_backslash_" implemented on 
> matroid, matrix, and binary_tree, so extinguishing it should be doable. We 
> should definitely not entrench its use further.
> 
> If you want to write your denominator first, you can already do ~2 * 3 . I 
> think that's already sufficiently perverse that we don't need another way 
> to spell that.

To keep the flamebait to a minimum, I will just say: +1.

-- 
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/a4d3e780ff4ba16eb2f11cc096b81816b72914aa.camel%40orlitzky.com.

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

[Michael Orlitzky]

On 2023-09-16 14:09:04, Dima Pasechnik wrote:
> 
> Anyhow, if this is the only problem with upgrading to Sphinx 7.1+ (or 8)
> it ought to be fixed, so that we can move on on Sphinx update.
> (see https://github.com/sagemath/sage/pull/35658)

My vote would be to replace the weird sageism with the standard python
construct, but that would silently break a lot of plots. A deprecation
warning would be nice, but if there's no workaround for sphinx, then
letting our sphinx get N+1 years out-of-date is not very attractive
either. Maybe there's a middle ground that warns people who are
actually using the implicit options to migrate and inspect their
plots.

-- 
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/ZQXw5Wu_nzeEKzjd%40stitch.

Re: [sage-devel] @options() decorators in sagemath library code and Sphinx 7.1+

[Michael Orlitzky]

On Sat, 2023-09-16 at 13:16 +0100, Dima Pasechnik wrote:
> Isn't it true that the above may be simplified, removing foo=bar from
> @options() and putting this in the function definition, i.e.
> 

AFAIK it's just dictionary unpacking that happens by default. You can
already create your own options list for functions that take keyword
arguments,

  sage: def foo(x=None, y=None):
  : print(x, y)
  : 
  sage: foo_options = {"x": "hello,", "y": "world!"}
  sage: 
  sage: foo(**foo_options)
  hello, world!

but you have to remember to pass the options yourself whenever you call
foo().

-- 
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/d2a5ce1d8edbd0b971bf048f6d5afffef5f72250.camel%40orlitzky.com.

Re: [sage-devel] pull requests recently updated

[Michael Orlitzky]

On Wed, 2023-08-23 at 01:36 -0700, 'Martin R' via sage-devel wrote:
> 
> Is there a way to fix this?
> 

Now's an OK time to stop adding meaningless milestones to every open
ticket.

-- 
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/621ae92ed3bdcae2bd5e3b32af71614db7dee35d.camel%40orlitzky.com.

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

[Michael Orlitzky]

On Tue, 2023-08-15 at 08:09 -0700, 'Nasser M. Abbasi' via sage-devel
wrote:
> Here is the basic flow of the script: (this is not the real script but
> a stripped down version)
> 

For now at least, initializing the sage library creates one directory
under /tmp where all of sage's other temporary files live. That
directory is removed when the process exits. Is your loop allowing the
processes to exit? The integration routine is not using any additional
directories.

In any case, I would suggest that you use the @parallel decorator for
this instead of writing your own multiprocessing code:

https://doc.sagemath.org/html/en/reference/parallel/sage/parallel/decorate.html

I think its "fork" iterator will work a lot better for you, and it
takes a "timeout" parameter.

-- 
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/4e75ca707ee9b320b244f18ea622431ec708bf04.camel%40orlitzky.com.

Re: [sage-devel] why sagemath creates so many file in TMPDIR and how to prevent this?

[Michael Orlitzky]

On Tue, 2023-08-15 at 03:33 -0700, 'Nasser M. Abbasi' via sage-devel
wrote:
> Each time I run a sagemath script, I see 10's of thousands of files created 
> in my TMPDIR which I have to keep manually deleting.

There aren't too many parts of sage that use temporary files. What's
the script doing?

-- 
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/b9a93c92b31257d3ca44dad3b1b47dfb1decdc9c.camel%40orlitzky.com.

Re: [sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

[Michael Orlitzky]

On 2023-07-15 19:05:42, 'Nasser M. Abbasi' via sage-devel wrote:
> Maxima uses  SBCL lisp:
> 
> >maxima
> Maxima 5.47.0 https://maxima.sourceforge.io
> using Lisp SBCL 2.3.3
> 
> Are there any step-by-step instructions then how to make sagemath 10.1 use 
> maxima 4.7?  
> 

Not really. You need the tests in build/pkgs/maxima/spkg-configure.m4 to pass;
that's the authoritative list.

  1.  "maxima" has to be on your PATH
  2.  maxima has to be built with --enable-ecl
  3.  ECL needs to be able to find maxima.fas

The last one is the hardest. There's probably a secret "library path"
environment variable you can override with the path to your
maxima.fas, but I don't know how to do it off the top of my head.

If you're willing/able to write to ECL's built-in library directory,
you can accomplish (3) by installing maxima.fas to whatever is output
by,

  ecl -eval "(princ (SI:GET-LIBRARY-PATHNAME))" -eval "(quit)"

-- 
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/ZLPeAVEkfZnhJckf%40stitch.

Re: [sage-devel] Re: How to use maxima 5.47 with sagemath 10.1 beta?

[Michael Orlitzky]

On 2023-07-15 18:56:09, Nils Bruin wrote:
> It must be maxima running on ECL and there must be a 
> maxima.fas lisp package for ecl (which isn't built in the vanilla maxima 
> build).

That part is finally upstream in maxima-5.47.

-- 
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/ZLPZ0u1EgGPjqkud%40stitch.

Re: [sage-devel] Memory leak (quite bad)

[Michael Orlitzky]

On 2023-07-06 09:16:46, Nils Bruin wrote:
> > On Wednesday, 5 July 2023 at 08:29:44 UTC-7 Edgar Costa wrote:
> > 
> > Hi Gonzalo,
> > 
> > I highly recommend using https://github.com/rfjakob/earlyoom instead of 
> > waiting for OOM to kick in.
> 
> Wouldn't setting ulimit with -m (memory) or -v (virtual memory) for the 
> process that is liable to exceed its memory quota be a more sensible thing?

If you don't need a portable solution, then on linux, cgroups are the
most flexible way to leave yourself juuust enough RAM to be able to
move your mouse over the X.

-- 
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/ZKdiwaZ8lg3aCw3K%40stitch.

Re: [sage-devel] Question about reading Sage documentation

[Michael Orlitzky]

On 2023-06-29 20:50:11, Marc Culler wrote:
> I was asking a very specific question about SageMath on Ubuntu 22.04: Are
> Ubuntu 22.04 users who install the sagemath-doc package able to read those
> (Sage 9.5) docs with Firefox?

If you use pip, or ./configure && make && make install to /usr/local,
then no. Also no to you if you want to use firefox as your SVG viewer
and something (sage) launches it on /tmp/Crz9uCphJ1.svg. Or if you
want to launch firefox to read an HTML email attachment. It's a larger
and pretty well-known problem.

-- 
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/ZJ63NskOToFId4nk%40stitch.

Re: [sage-devel] Question about reading Sage documentation

[Michael Orlitzky]

On 2023-06-29 14:46:00, Marc Culler wrote:
> During our recent release of SnapPy we ran across an issue which is likely 
> relevant to whether Sage's documentation is viewable on newer Ubuntu 
> systems (such as 22.04).  The issue is that these newer Ubuntu systems ship 
> Firefox as a snap.  A snap runs in a sandbox which restricts which files 
> the snap can read.  Specifically, the Firefox snap can only read files in 
> the user's home directory.
>
> ...
> 
> Have people run into this?
> 

Alternate headline: multi-millionaire does stupid thing with
billionaire's product; how can math teachers fix it for free?

This is a combination of two problems,

  1. Mozilla has been going out of their way for a long time to make
 traditional firefox/thunderbird packages hard to maintain.

  2. Snaps are stupid (but low effort).

Despite a long-standing and fully independent hatred of Snaps, I can't
really blame Ubuntu for saying fuck it and taking the easy way out;
the firefox experience was going to be degraded in one way or another.

There aren't any great solutions because the only other mainstream
browser is managed by a spyware company and is also increasingly
difficult to package (for slightly different reasons). For second-tier
browsers, there's Falkon (Qt) and Epiphany (Gtk), which can still be
sanely packaged, but that are also missing features that most users
won't give up. Everything else is basically a Chrome theme these days
and inherits Chrome problems.

To summarize where I'm at personally,

  * Man/info pages are the standard and still work great
  * A fallback browser is nice to have around
  * There's always LaTeX/PDF
  * Not everything can be my problem

This is more of an answer to "have people run into this?" than an
actual answer, but there it is.

-- 
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/ZJ4YTZcllgov1v6m%40stitch.

Re: [sage-devel] Graphics files in Sage documentation

[Michael Orlitzky]

On 2023-06-29 23:30:57, Dima Pasechnik wrote:
> On Thu, Jun 29, 2023 at 3:24 AM Michael Orlitzky  wrote:
> >
> > On 2023-06-28 23:27:22, Dima Pasechnik wrote:
> > > One can always start a web server on localhost, instead of using file:/// 
> > > :P
> > >
> >
> > I know you're mostly joking, but that's not as easy as it sounds.
> 
> no, why? If you run ./sage -n you'll see something like
> 

Oh, sorry then. You could probably guess that if I run sage -n,
nothing happens, because I don't have the notebook installed. First
I'd have to re./configure sage and pull down a few hundred megabytes
of random crap from pypi.

Once you have all that installed, Jupyter uses a custom web server
with token-based authentication to solve the permission problem. But
in trade,

  * Every user needs to run his own server;

  * You've upped the ante from "read my files" to "execute
arbitrary code" if there's a bug in Jupyter.

Given all that I'd still say it's more complicated than "just launch a
local web server" makes it sound.

-- 
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/ZJ4MPqCbuxDFe52r%40stitch.

Re: [sage-devel] Graphics files in Sage documentation

[Michael Orlitzky]

On 2023-06-28 23:27:22, Dima Pasechnik wrote:
> One can always start a web server on localhost, instead of using file:/// :P
>

I know you're mostly joking, but that's not as easy as it sounds. To
start the local web server as a non-root user, you have to run it on
an unprivileged (i.e. not the default of 80) port. Then you have to
teach it about mime types and gzip, and probably add a line or two
about image/svg+xml and the svgz extension.

Then you have to secure it somehow. Other local users can hit that TCP
port, and it will be running with your desktop user's privileges, so
it can see all of your files. Your server might support path
restrictions, but does it protect against the past 30 years' worth of
path traversal hacks and stupid symlink tricks? Maybe if you're using
apache or nginx, but if you're using "python -m http.server", I
wouldn't count on it.

-- 
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/ZJzrXxtT1lnmuywr%40stitch.

Re: [sage-devel] Graphics files in Sage documentation

[Michael Orlitzky]

On Wed, 2023-06-28 at 13:50 -0400, Michael Orlitzky wrote:
> 
>   * gzipped SVG doesn't work over the file:/// protocol in my firefox.
> This hasn't been a big enough problem for me yet to diagnose it,
> so I can't say how serious a problem it is. (I'll play around later
> today.)

Firefox bug opened 23 years ago:

  https://bugzilla.mozilla.org/show_bug.cgi?id=52282



If they were going to fix it, it'd be fixed, so I'd suggest doing the
comparison uncompressed. A lot of people (statistics all made up) read
the docs locally with firefox.

-- 
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/28b1bd234f8a344062c0bd103dd53760ff24c693.camel%40orlitzky.com.

Re: [sage-devel] Graphics files in Sage documentation

[Michael Orlitzky]

On Wed, 2023-06-28 at 10:07 -0700, Marc Culler wrote:
> 
> BOTTOM LINE: we get more than a 90% reduction in size simply by choosing to 
> use the .svg extension when saving the plot instead of the .png extension.
> 

SVG is the right choice for most graphics, but there are some practical
problems:

  * The documentation needs to know how big to display an SVG graphic.
With a PNG, the default is to use the image's height/width in 
pixels, but with SVG, there's no such obvious default.

  * gzipped SVG doesn't work over the file:/// protocol in my firefox.
This hasn't been a big enough problem for me yet to diagnose it,
so I can't say how serious a problem it is. (I'll play around later
today.)

  * Browser support in firefox/chrome alternatives still isn't great,
although I think webkit is getting a new SVG renderer "soon." This
is actually relevant more today than it was ten years ago, because 
adding rust to firefox made it less portable, meaning you're
more likely to be stuck with one of those alternatives.

  * Somebody's got to go through and look at 100MB of images to make 
sure they still look right if we change 'em.

-- 
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/06e3ac75a976ab63a9dddfcfa2a62920e9ba4715.camel%40orlitzky.com.

Re: [sage-devel] Modularization project: I. The goals

[Michael Orlitzky]

On Thu, 2023-06-22 at 14:41 -0700, William Stein wrote:
> 
> WebAssembly is not an experimental linux distribution, and it has very
> little overlap with linux distributions.  The WebAssembly ecosystem is
> built from the ground up, primarily on the LLVM (and Rust) toolchain, and
> an ecosystem of free software that is much more liberally licensed (and
> smaller) than what is typically in Linux distributions.WebAssembly
> is neither better nor worse than Linux distributions; instead it is a
> different thing that solves different problems.

Yes, I know what WebAssembly is. The phrase "pip installability" is a
essentially euphemism for running a binary linux distribution on pypi
using pip as the package manager. On top of the many architecture and
libc-specific binaries that we'll have to build and ship and secure
forever, you're also suggesting that we maintain LLVM/Rust
infrastructure that allows us to ship pre-built WebAssembly targets for
all of those packages as well.

In addition to the usual sage distribution, and now the pypi
distribution, that would mean also maintaining our own LLVM/Rust-based
webassembly distribution. It's recreating exactly what Conda, Nix,
Guix, etc. all do, except with a more experimental toolchain. That's
the main problem: we don't have time to maintain our one existing
distribution, and the installation process is already too complicated
and confusing. With three, it's going to get more complicated, more
confusing, and more bitrotten as we all start to drown under the
increased maintenance burden.

The second issue is that WebAssembly doesn't actually solve the
problems we have, it only pushes them one layer of abstraction up. You
can run an entire OS in WebAssembly in a browser sandbox in docker in a
virtual machine. So what? Now you have two computers to maintain. To
avoid duplicating work, you start to move more and more things into
that browser. Eventually, you're right back where you started; things
conflict, etc. Except now everything doesn't work at half the speed
that it originally didn't work at. There's no way to sweep these
problems under the rug, they're fundamental. And instead of focusing on
them we keep getting distracted by squirrels.

-- 
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/281e65d5ebeb2884b7638a340233db5855d43285.camel%40orlitzky.com.

Re: [sage-devel] Modularization project: I. The goals

[Michael Orlitzky]

On Thu, 2023-06-22 at 13:56 -0700, William Stein wrote:
> 
> (5) provide a WebAssembly option
> 
> WebAssembly is typically about half the speed as native code (at best), but
> it is highly cross platform and self contained.   WebAssembly is difficult
> mainly when you have to deal with the OS somehow (e.g., filesystem,
> networking, etc.), and fortunately, a lot of the code in Sage is math
> libraries that support a non-threaded mode, so are particularly easy to
> port to WebAssembly.  A good example is Pari, which is one of "sage's
> non-Python dependencies".
> 

We always wind up back here. Are we building mathematics software, or
signing on to run the world's most experimental linux distribution?

-- 
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/946471c7ee79a97351641fcd1f088a7a0c0a8ebd.camel%40orlitzky.com.

Re: [sage-devel] Modularization project: I. The goals

[Michael Orlitzky]

>
On 2023-06-15 18:08:35, 'Travis Scrimshaw' via sage-devel wrote:
> 
> That is simply not true right now. The # optional sage.* doctests as a 
> user-visible change.
> 

These tags aren't essential to the modularization itself. They're an
artifact of bad tests:

  * doctests are in general just a bad way to test functionality (I
mean TESTS here, not EXAMPLES). Among their many other problems,
they force us to set up a full interactive sage environment, using
more parts of the sage library than would otherwise be necessary
for the test in question.

  * For 20 years nobody has cared about writing tests that only test
the thing they're supposed to test. If the tests in (for example)
sage.categories tested only the code in sage.categories, then the
module could be split without any #optional tags. But since those
tests actually use code from all over the place, we have two options:

  1) Stop and rewrite all of those tests
  2) Declare them optional

We should still rewrite the bad tests eventually, even with the
#optional tags. For that reason, I read them as "#TODO: rewrite
this bad test", which makes me hate them less.

Regardless, I am also sympathetic that this is yet another massive
complicated project that we've started without resolving any of the
other ongoing massive complicated projects. One definitely gets the
feeling that nothing ever gets easier around here. If we rewrote the
bad tests BEFORE modularization, that would ensure that our situation
was monotonically improving, without the local regression from the
introduction of the #optional tags.

-- 
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/ZIwKdrM86Sbm_Esr%40stitch.

Re: [sage-devel] Modularization project: I. The goals

[Michael Orlitzky]

On Thu, 2023-06-08 at 14:09 -0700, Matthias Koeppe wrote:
> 
> *D. *As a consequence of B and C, it was *impossible to build or run parts 
> of the Sage library.* And it is *impossible to install the whole Sage 
> library using Python infrastructure* (pip). (Yes, I know that conda exists.)
> 

Of itself, modularization is a noble goal. But in the implementation,
please be wary of focusing on users we don't have at the expense of the
users we do have. The amount of additional complexity and maintenance
this entails is daunting, and your tentative plans for pip packaging
sometimes conflict with common-sense improvements for existing users
and developers, as I've been trying to argue (for the second time) on
issue #32242.

Pip isn't a real build system or package manager. Most egregiously, it
can't do anything with the non-python software on which sage subsists.
To make sage-via-pip work, we'll have to maintain a new pseudo-
distribution on pypi that either ships people pre-built wheels or wraps
autotools/cmake/etc in python. As was made clear in recent threads,
many developers don't want to be maintaining the *first* sage
distribution, much less a second one.

I think we're all happy to modularize so long as it doesn't create work
elsewhere. (At the very least, modularization improves build times.)
But given that you may be the only person who has pip-installablity as
a goal, I think you have to be more sensitive to the complaints when
that goal conflicts with others. Complexity is our biggest problem
right now, and uncompromising modularization is only adding to it.

-- 
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/f6cc06ddf559985a33303529d45b1eaaf9b1cf98.camel%40orlitzky.com.

Re: [sage-devel] ping - please cast you vote: VOTE: Follow NEP 29: Recommended Python version

[Michael Orlitzky]

On Tue, 2023-05-30 at 10:15 +0100, Dima Pasechnik wrote:
> So far we only had very few votes cast.
> 

We probably should have started with the discussion and then voted
afterwards. FWIW I'm still not sure.

I basically agree with Matthias's points. If (for example) supporting
python-3.8 costs us very little, then having a policy that forces us to
drop it would be worse than having a policy that allows us to weigh the
pros and cons and make our own decision.

On the other hand, no one is ever going to agree on the weights
assigned to those pros and cons. We've had this same discussion a few
times already, and this time around it's pretty clear that we're
keeping old versions around for too long.

We COULD just try to be less conservative when dropping support for
older versions, as opposed to adopting a policy that mandates it. But
do we really want to have this same fight every three months? I'm
leaning towards voting yes for that reason.

-- 
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/d892f23266943b59af1ceac7c0080d4ba36c9b01.camel%40orlitzky.com.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Michael Orlitzky]

On 2023-05-28 16:20:02, Dima Pasechnik wrote:
>
> indeed, https://github.com/sagemath/sage/issues/29023 is the meta-ticket to
> oversee this process. Needless to say this needs more effort.

I'm sure it's out of date for boring reasons, but the branch from
29665 worked great:

https://github.com/sagemath/sagetrac-mirror/compare/develop...u/mjo/ticket/29665

There were the usual packaging snafus but I don't recall any looming
conceptual problems.

-- 
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/ZHP4_vLsqEtsTnAc%40stitch.

Re: [sage-devel] Re: VOTE: Follow NEP 29: Recommended Python version

[Michael Orlitzky]

On Fri, 2023-05-26 at 18:15 +0100, Oscar Benjamin wrote:
> 
> What is wrong with Sage just saying that an older version of an
> operating system only works with an older version of Sage?

Matthias alluded to this when he mentioned that we only have one
release branch of sage. Our version numbers are not really meaningful,
and bug fixes and features are released simultaneously. So the only way
to get fixes for critical bugs is to upgrade, but the upgrades come
with new features, and those new features can have new requirements.

That said, I still share your sentiment when there is a good reason (a
term best left undefined) to break compatibility.

-- 
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/5128635b3e20e95ac427986ac656db8789b62e80.camel%40orlitzky.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

[Michael Orlitzky]

On Mon, 2023-05-22 at 12:50 -0700, Matthias Koeppe wrote:
> 
> On Saturday, April 29, 2023 at 1:45:31 PM UTC-7 TB wrote:
> 
> Should `sage -i pandoc`, at least in an interactive session, first 
> recommend to install it from the distro, and not default to conda? 
> 

Eventually I think the "sage" script should be relieved of the
responsibility to install distro/conda packages (both processes are
well-documented), but suggesting the distro package first seems like
the best approach for the time being. It may suggest packages that
can't be used, but that's no different than what ./configure does.

-- 
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/5c905ebc0be34c016545d9e3d5fcd37bb5bfe79b.camel%40orlitzky.com.

Re: [sage-devel] Meson Build System

[Michael Orlitzky]

On Tue, 2023-05-02 at 10:35 -0700, Volker Weißmann wrote:
> Hello,
> 
> I'm a developer that worked quite a bit with the meson build system and 
> looked at   sagemath for a few days. I thought that redoing the build 
> system with meson instead of autoconf would be quite a bit of work, but 
> would
> 
> 1. Be far, far more readable.
> 2. Result in far faster incremental builds if very little has changed since 
> the last build.
> 
> What do you think? Is this a good idea? Would you appreciate (and merge) 
> such an endeavour?
> 

Meson is my second favorite build system, but there are a few obstacles
to a rewrite:

 * Autotools is nicer for end users, because all you need to run it is 
   a posix shell. The tradeoff is that writing autotools sucks for 
   developers. It is however already written.

 * Related to the first item, meson has bootstrapping issues because 
   it's written in python (which we use autotools to detect), and 
   because meson sometimes introduces new features. If we use those
   new features then users need newer versions of meson which need 
   newer versions of python... This is offset somewhat by the fact 
   that we already have a set of bootstrap dependencies but it would  
   be one more thing we'd have to worry about. (There is also a C99
   implementation of meson called muon.)

 * The ./configure && make process is "standard" and familiar to 
   everyone while meson is less so. This could change in a few years.

 * The sage build system is perpetually in flux and it would be very 
   hard to coordinate a rewrite.

And the big one:

 * You probably haven't looked hard enough at the existing build 
   system. We've got mountains of highly unusual autoconf code and 
   hand-written Makefiles that all interact in weird ways with
   sage's own package manager. Meson makes the standard build tasks
   simple, but a lot of what we're doing is non-standard. Trying to
   rewrite those bits in meson might only make things worse.

So I commend your bravery but I think you would waste a lot of time
before eventually giving up. And IMO the benefits would be dubious.

Some day we may reach a point where the sage library is an independent
package with its own standard ./configure script that just looks for
headers and libraries and substitutes strings into files. At that point
this would be a less crazy idea.

-- 
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/ed316ef889ca2e785bf6b0c33202fa95d49ddeed.camel%40orlitzky.com.

Re: [sage-devel] What was/is/will be the purpose of maintaining the Sage distribution?

[Michael Orlitzky]

On Sat, 2023-04-29 at 13:10 -0700, Matthias Koeppe wrote:
> 
> This drops platform support for 32-bit Linux (see 
> https://github.com/sagemath/sage/wiki/Sage-9.8-Release-Tour#availability-of-sage-98-and-installation-help)
>  
> for these optional packages. We will need a decision if this OK.
> 

GNU info and Valgrind can be installed with the package manager on any
32-bit distro so there's no practical difference for those two.

-- 
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/8cb146d13b9687f1a9b8f3c42cd8c7d8e736c8d3.camel%40orlitzky.com.

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

[Michael Orlitzky]

On Fri, 2023-04-28 at 18:06 +0100, Dr. David Kirkby wrote:
> 
> To me at least, it would be unwise not run the test suite.
> 
> If you are choosing to use 15-20 year old hardware, you can not reasonably
> to handle a large modern program like Sagemath. More modern machines than
> that get thrown in skips. 😂
> 

I have ~1,000 other modern packages built from source on these machines
and hack on many of them. The hardware is as fast as the day I bought
it. The issue is not that sage is modern, rather that it's still built
like a pet project from 2005.

The test suite is an entirely different topic where your criticism is
more valid. There are a few different issues there, all pretty
irrelevant to this discussion:

  * We have many redundant tests
  * Doctests inherently require redundancy and are relatively slow
  * We have tests for bugs that were fixed in upstream projects
and are already checked by the upstream test suite
  * The "too long" warning is outrageously high
  * The "too long" warning uses "wall time", which is meaningless
as an objective measure of how much computation is done. Someone 
with newer hardware can easily introduce a "fast" test that 
takes over a minute for me to run.

Beyond that, whatever time it takes to run the test suite is necessary
and I'm not complaining about it. It's the unnecessary bit that's
annoying.

-- 
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/2e79d3741ff8b5ac98dff01373c6c4ff53f7f42c.camel%40orlitzky.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[Michael Orlitzky]

On Thu, 2023-04-27 at 12:37 -0700, Matthias Koeppe wrote:
> A problem only arises when you try to build a bleeding-edge sage on an older 
> stable distro -- an undertaking unsupported by most projects.
> 
> Is it? I would say that Sage is very special in this regard because of its 
> extreme number of complicated dependencies; and because of its 
> long-standing goals of empowering the members of the user community to 
> become contributors.

"Unsupported" was too strong, but a lot of large projects expect a
higher level of sophistication from developers than users. For example,
you're expected to have the latest GNUlib or autotools installed, or
perhaps the latest LLVM, and a concoction of obscure test-suite
dependencies. Gentoo stable is still on openssl-1.1, and I've had to
put 3.x in /usr/local a few times to build projects that got tired of
adding #ifdefs.

This does... interact... with the goal of making it easy to contribute.
But the complexity of the sage distribution and build system also makes
it harder to use and develop sage.


> But this creates a serious barrier: If Sage development can only be done on 
> bleeding-edge distributions, new Sage developers need to abandon their 
> current distribution. That's really bad.

I agree, and "unsupported" carried the wrong connotation. You can
certainly develop on those distros, but you're responsible for
obtaining the dependencies. You can find them in a third-party rpm/deb
repo, or build them in /usr/local, or install them with Nix/Conda/Guix.

How difficult this is depends on how deeply the dependency is embedded
in the tree. You know this, but for the sake of the list: you can't
build only a local copy of PARI, you have to build local copies of
anything else that will be linked to both PARI and sage. Otherwise
it'll crash when you load both PARIs into the same process. In
contrast, a python package at the edge of the graph can be installed
locally with only a "pip install".

We should take that into account when deciding how important backwards-
compatibility is for a given package; there's no silver bullet.


> Anyone bothered by this can of course send us patches that extend 
> compatibility to older PARI.
> 
> Would we welcome such patches? When we upgrade a package such as PARI, 
> typically very experienced Sage developers have already assessed how easy 
> it would be to keep the old version supported. When it is decided to drop 
> support, it is often not because we don't know how to support both but 
> rather because we do not want to have more complicated code in Sage.

We would have to take into account that breaking compatibility will
force people on old distros to build local copies of not only pari, but
also lcalc, giac, eclib, etc. Cleaning out the sage test suite will
help some, but we will inevitably spend more time on compatibility than
we do now.

I think it's a better use of our time though. We'll be spending time
making sure it works out of the box, rather than spending time on the
fallback that we have to use because it doesn't work out of the box.

-- 
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/3e81f21d8b1723cf8ad6b0d632cae9393dab5c40.camel%40orlitzky.com.

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

[Michael Orlitzky]

On Thu, 2023-04-27 at 05:49 -0700, William Stein wrote:
> Hi,
> 
> To what extent does or could Conda with a little more work solve most
> of these problems?   There are some notes below from me poking around,
> and I'm very optimistic.

This isn't the first time the idea has come up. Burcin got pretty far
with it using Gentoo Prefix in place of Conda:

  https://groups.google.com/g/sage-devel/c/XFJn3jGVBG8

Nix could also work. All three serve roughly the same purpose.

-- 
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/0a85f27c909f8d8f185801af2228e6331bcad544.camel%40orlitzky.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[Michael Orlitzky]

On Thu, 2023-04-27 at 08:38 -0700, Nils Bruin wrote:
> 
> But another problem before was that the different packages would not 
> develop in lockstep. Some components might need one specific version of 
> prerequisites and others another. So one could run into genuine version 
> conflicts.

In theory this is a problem with every package. But in practice, we've
got 20,000 of them and few major conflicts. Solving this is what a
linux distribution does, and it's OK to punt the problem to them.

Personally I'm not getting out of any work here, since I'm also working
on the distro packages. Making Sage more lenient would however be a
valuable use of my time, in contrast with the current approach.


-- 
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/ef9b21e64fcfe5db98b4b438e282170443b097f2.camel%40orlitzky.com.

Re: [sage-devel] Re: What was/is/will be the purpose of maintaining the Sage distribution?

[Michael Orlitzky]

On Thu, 2023-04-27 at 05:12 -0700, kcrisman wrote:
> 
> As an example, how old of a Windows computer could one install the current 
> Sage on? ...
> 
> In any case, it would be very helpful for people who may be actively using 
> Sge in less-resourced environment to chime in here.
> 

My desktop is 19 years old and my laptop is now 15. Switching between
branches can cause 20 hours of recompile time. If I'm lucky and don't
need to use the result, I can cut that in half with -O0. If this were
spent doing something useful, it would be more tolerable, but it's
spent fetching, compiling, and installing packages that are already on
my system. The test suite can take another full day to run -- some of
that is useful, but a lot is not. This is the biggest impediment to the
use and development of sage on an old system.

Upgrading (say) OpenSSL on the system is a sunk cost because it happens
anyway. The only question is whether or not I *also* have to repeatedly
rebuild some highly specific version that sage wants. The problem is
not only the SPKGs, but the way sagelib is designed around them;
eliminating the sage distribution would force us to address those
indirect inefficiencies in addition to immediately eliminating the
direct ones.

(I'm planning upgrades in the next year or two, but it will be to
relatively low power RISC-V hardware. There are moral, legal,
environmental, and other non-financial reasons why people use "old"
hardware. But of course the financial reasons are very real too.)

-- 
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/592557b3cb7efaa5bac7f0cec8781c11ad093a17.camel%40orlitzky.com.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[Michael Orlitzky]

On 2023-04-26 19:59:01, Matthias Koeppe wrote:
> On Wednesday, April 26, 2023 at 7:37:17 PM UTC-7 Michael Orlitzky wrote:
> 
> Just as a data point, eliminating the spkg and only supporting system PARI 
> 2.15.x would have the effect to eliminate support of:
> - all versions of Ubuntu except for 23.04 (lunar); 
> - all openSUSE Leap versions, leaving only the rolling distro (Tumbleweed).
> Source: https://repology.org/project/pari/versions

It would be better if we could support the last minor version of PARI
as well, but I'm not volunteering anyone else's time to do it. If we
adopt a more flexible approach in sagelib, we'll sometimes get lucky:
there just won't be any breakage between minor versions, or it will be
trivial to support both. But yes, there will eventually be some change
that forces us to say "upgrade your PARI, or use an older version of
sage."

It's not the end of the world if users on a distro with old
dependencies have to stick to an older version of sage. Ideally, they
would be getting sage from their distro in the first place. A problem
only arises when you try to build a bleeding-edge sage on an older
stable distro -- an undertaking unsupported by most projects. Anyone
bothered by this can of course send us patches that extend
compatibility to older PARI. The burden of universal support would
however be transferred from the sage developers to the distros where
it rightfully lies.


> All this sounds very reasonable, of course.
> 
> A problem that remains is how we would manage user expectations when they 
> report a bug to us that turns out to be an upstream bug in a package that 
> we no longer carry as an spkg: We would no longer be able to say "it's 
> fixed in Sage 10.7" but instead would have to say "not the fault of Sage; 
> just go upgrade your Linux distro to the unstable release / ask your distro 
> to backport the bugfix / compile the package yourself from source".

That exact response is standard. It's a bit less friendly but a lot
more sensible.

-- 
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/ZEpVhx-yoz9piJF3%40stitch.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[Michael Orlitzky]

On 2023-04-26 18:38:32, Matthias Koeppe wrote:
> Michael, do you happen to have a suggestion what version range of PARI the 
> Sage library should be supporting?

PARI doesn't strictly follow semver, so whatever I say here, PARI will
eventually make a fool of me. Still, I think a fair goal is to support
the latest "point" release series, currently 2.15.x.

My comment is about the approach we take to version compatibility
moreso than a hard rule to be followed. For example,

  * We should not be outlawing minor versions of packages for bugs
that have been fixed upstream,
  * We should not be reproducing in sagelib any tests that are part
of an upstream package,
  * We should avoid string equality where possible in sagelib tests,

In other words,

  * We should not be going out of our way to break compatibility.

That alone will go quite far, and whatever it gets us is acceptable.

-- 
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/ZEnf0r0OuI3dso7L%40stitch.

Re: [sage-devel] Re: [sage-release] Sage 10.0.rc0 released

[Michael Orlitzky]

On Wed, 2023-04-26 at 13:06 -0700, Matthias Koeppe wrote:
> 
> 2. I'm not in favor of chipping away 1 package at a time in the name
> of unsubstantiated, vague notions that a package is "ballast slowing
> down Sage's progress".
> 

There's a ticket open to update PARI within Sage. First, upstream had
to release the new version. So far, at least three sage developers have
worked on it. The update includes a backported patch, a test for the
patch, and configure checks for the patch. So, once the update makes
its way into sage, every distribution maintainer is going to have to
backport the same patch into their version of PARI. Except the sage
patch doesn't include the fix to the test suite. So the source based
distributions are also going to have to separately backport the fix for
the test suites. There are 12 distros listed in build/pari/distros, so
at least 12 people this will affect.

How many people will it take how many hours to complete this trivial
upgrade? These are not vague notions.

Dropping one package at a time has two major benefits:

 1. Not all sage packages are available in all distros. Eliminating 
the easy ones like gcc and python makes it possible to focus on 
the ones that pose real problems.

 2. The sage library and test suites are coupled much too tightly to 
dependencies like PARI and maxima. Piggybacking off the earlier
example, distroless Sage cannot continue to test for patches that
exist only in upstream git head. We should also endeavour to make
our tests independent of the particular string representation that
e.g. maxima uses. There are lots of tests that work only with one
specific version of maxima because the answers look different,
rather than because they are fundamentally unequal. Fixing all of 
these issues will take a lot of time and work. It will only be
feasible to fix them if we do it a little bit at a time. We should 
fix them anyway because updating the tests every time a new maxima 
is released is a waste of time. But we must fix them if we expect 
the distro maxima to work.

-- 
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/29a6ceea545aaea4406dc7ce294e1c87943b5d1b.camel%40orlitzky.com.

Re: Re: [sage-devel] ChatGPT is an expert in SageMath too

[Michael Orlitzky]

On Fri, 2023-04-21 at 08:22 +0100, Dima Pasechnik wrote:
> > 
> > 
> > Sadly it's not. The American legal system isn't built for this. The
> > fact that they're clearly doing something illegal and that it's hurting
> > people isn't grounds for a third-party lawsuit. The victims can file
> > suits, but like Microsoft's lawyers said, the victims have to be able
> > to demonstrate injury.
> 
> Copilot makes money which does not go to the producers of the content it
> sells. How is it not injury?
> Copyright is copyright, it is violated here.
> 

There's injury, but only the people who are actually injured can file
suit.

Suppose copilot is willing to reproduce the source code of block_ldlt()
but without the GPL. What's the dollar amount that I'm harmed by that?
I can sue for damages, or I can sue for the portion of the profits
attributable to the infringement. Microsoft's lawyers are going to
claim that both numbers are zero. How much will it cost me in legal
fees to fight that, and for what potential benefit?

It's a losing proposition for me, and by extension, for almost everyone
writing free software.

-- 
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/e4be1149c4a3de2b69301a4d4215cf88fd6f364d.camel%40orlitzky.com.

Re: Re: [sage-devel] ChatGPT is an expert in SageMath too

[Michael Orlitzky]

On Thu, 2023-04-20 at 20:37 +0100, Dima Pasechnik wrote:
> > 
> > https://www.theverge.com/2023/1/28/23575919/microsoft-openai-github-dismiss-copilot-ai-copyright-lawsuit
> 
> 
> A cursory reading of this wish to dismiss the case sounds to me as the
> usual M$ chutzpah.
> Of course they want it gone, as it hurts their profits.
> 

Sadly it's not. The American legal system isn't built for this. The
fact that they're clearly doing something illegal and that it's hurting
people isn't grounds for a third-party lawsuit. The victims can file
suits, but like Microsoft's lawyers said, the victims have to be able
to demonstrate injury. Then for a suit to be worthwhile, that injury
has to outweigh your legal fees. In practice this makes it legal for a
corporation to steal $1 from each of a billion people. See also: online
privacy violations; spam email.

Adding onto the pile in this scenario is how difficult it would be to
prove that *your* code was copied, considering that they've assimilated
most of the available copyrighted material on Earth and that the AI are
black boxes.

-- 
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/d30406f886ce7cc61742b5947af01ae1b4985301.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 19:46 -0700, aw wrote:
>  
> Unbelievable. 
> This is failing a basic consistency check: if x==y, then we should have 
> f(x)==f(y) for any function f.
> 
> The problem here is that float literals are being mishandled. The string 
> "0.5" should be interpreted as 1/2, unless the user overrides that.
> 
> Can you post the other "permabugs" you know of that involve float literals?
> 

They're all variations on a theme. Floating point sucks, and Sage
inherits that:

  sage: (0.1 + 0.2) + 0.3 == 0.1 + (0.2 + 0.3)
  False

Whenever you perform an operation with two different types of "number,"
Sage essentially picks the worst of the two and performs the operation
there. Every example is basically,

  1. Something returns a float where you don't expect it
  2. You use that result with some other object
  3. Now the other object is made of float
  4. Nothing works in floating point

The conversion to float is consistent with all of the other intelligent
coercions that Sage can do (embedding ZZ into QQ, for example), so it
goes off silently. But floating point is a uniquely bad base ring for
most of Sage.

-- 
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/44b14f57528ac06463e2294fa52cf3a661cc2cc0.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 12:47 +0100, Dima Pasechnik wrote:
> 
> perhaps the preparser should have an option to convert the floating
> point input into rationals.

We should try ZZ first, but yeah, something like that. If Sage thinks
QQ(x) == float(x), then the former should be preferred. Or maybe it
only needs to kick in when an exact value would be coerced to an
inexact one (with the goal of avoiding that). I don't think it would be
easy; there would be lots of fine-tuning and unintended consequences,
but none of that makes the complaint invalid.

-- 
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/ab099fea5d0bae4b4b70d4d58dd29ec240ca1813.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sun, 2023-04-16 at 10:50 -0700, Nils Bruin wrote:
>  
> That's a facetious example that sticks to values that can be exactly 
> represented in binary floats. These identities don't hold generally:
> 
> sage: 49*(1.0/49) == ZZ(1)
> False
> 
> (it depends on your working precision if rounding makes this come out as an 
> exact match or not, but at 53 bits this one fails to give equality. In all 
> cases, there are values where this breaks; necessarily)

I didn't make that example up to make a point, it's a real problem I
reported ~15 years ago in undergrad. And the fact that it's an easy
case only makes it *more* surprising that sage doesn't handle it.

We don't need a perfect solution to get it right most of the time. How
often does someone type 1/49 = 0.02040816326530612... into a matrix?
But Sage actually knows that number too:

  $ sage -python
  Python 3.11.2 (main, Mar 16 2023, 15:12:59) [GCC 12.2.1 20230121] on 
  linux
  Type "help", "copyright", "credits" or "license" for more 
  information.
  >>> from sage.all import *
  >>> QQ(0.02040816326530612)
  1/49


-- 
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/b2e128ee0d91cc0f8f05fd160e07d23da1f0714f.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sat, 2023-04-15 at 19:11 -0700, Nils Bruin wrote:
>  
> I fail to see what the reasonable expectations are here. As soon as you 
> multiply by "0.5" you now have an "imprecise" result. When people learn to 
> use a scientific calculator properly they are very quickly confronted with 
> the reality that "dots in numbers" lead to arithmetic that isn't quite what 
> we learn in the lower grades of primary school.

It's reasonable to expect that multiplying by one won't cause a viable
alternative to Mathematica et al. to go bonkers. I haven't declared a
float variable, and I haven't type-cast anything to float. The
expression "0.5" is, a priori, quite equal to 1/2. Mathematica knows
it, my old Casio calculator knows it, and in fact, Sage knows it:

  sage: 2 * 0.5 == ZZ(1)
  True

We're pre-parsing the user's input, so there is an opportunity to do
the right thing. But instead, we silently convert 2*0.5 to float, and
then silently convert the entire matrix to a float matrix, on which
half the methods in sage are completely meaningless.


> Do you think we should have "B == A" return false? ...
> A more reasonably solution might be to have B.rank() return an error

Yes, ultimately, I think it would be better to have a class hierarchy
that can distinguish between inexact rings where these operations are
meaningful and those where they're not. But these are Sage library
issues and that's not my main complaint.

If you're writing python code, you should expect 2*0.5 to return a
float. But if you're learning linear algebra for the first time and
typing a matrix into the Sage notebook, typing 0.5 instead of 1/2
should not ruin the entire assignment without so much as a warning.

-- 
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/caa19202f0a1dc1eef92dbab1df231efb1f2741c.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sat, 2023-04-15 at 16:56 -0700, William Stein wrote:
> 
> I agree with you that it's best to assume that the original poster "aw" does
> understand the semantics of floating point numbers in Sage, and just doesn't
> like them.  I think you also understand the semantics of floating point in
> Sage as well, and you also don't like them.

This misses the point. The semantics are fine when you're expecting
them, but the expectation is key.

-- 
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/b82bf91db9e700d05be9c831777b71f7784c48c8.camel%40orlitzky.com.

Re: [sage-devel] RealField isn't doing it right

[Michael Orlitzky]

On Sat, 2023-04-15 at 18:20 -0400, David Roe wrote:
> I agree with William that you should refrain from insulting the Sage
> developers, especially when the underlying problem comes from your
> misunderstanding of how floating point arithmetic works.

I was given this response many times, and I think it's condescending
(no offense). My favorite permabug:

  sage: A = matrix([[-3, 2, 1 ],
  : [ 2,-4, 4 ],
  : [ 1, 2,-5 ]])
  sage: B = (2 * 0.5 * A)
  sage: B == A
  True
  sage: B.rank() == A.rank()
  False

I promise you that I know what a floating point number is, and that
they aren't the problem. The problem is that reasonable expectations
are not met by the Sage user interface. It shouldn't be that easy to
get the computer to lie to me. An explanation is of course possible,
but only after the fact, and only with a level of knowledge about the
preprocessor that is beyond most users.

-- 
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/c8531f5211ebfe590ed2b38390b33ef26df1d1eb.camel%40orlitzky.com.

Re: [sage-devel] FlintQS upstream

[Michael Orlitzky]

On Thu, 2023-03-23 at 22:05 +, Dima Pasechnik wrote:
> 
> I promoted you to a maintainer of this repo.
> 

I updated the README to say that FlintQS is obsolete, and there's a PR
at https://github.com/sagemath/sage/pull/35419 to replace it within
Sage. I also filed a CVE for the /tmp issues to make sure distros clean
it up eventually.

I would also suggest archiving the GH repo at this point if someone is
able to do that.

-- 
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/e8212ce1b3a3eef4f407a0f778c1170d2aee655d.camel%40orlitzky.com.

Re: Private message regarding: [sage-devel] external libraries - is Rust allowed?

[Michael Orlitzky]

On Thu, 2023-03-30 at 23:11 -0400, Curran McConnell wrote:
> Thanks so much for breaking that down!
> I will take a closer look at the distinction between the different
> kinds of
> "package". There is a good likelihood I won't ever need this to be a
> "standard" package, but either way that is a helpful way to frame the
> problem.
> 
> Also, I didn't mean to start a private conversation--I haven't used a
> Google group before, I think I might have misused the interface
> slightly.
> Should we repost this thread to the main chat in case other people
> have
> this question in future?
> 

No problem. I only interact with the group via email, but I'll CC this
message to the list (sage-devel@googlegroups.com) so that the quoted
conversation below shows up.




> Best,
> 
> Curran
> 
> On Thu, Mar 30, 2023 at 4:23 PM Michael Orlitzky
> 
> wrote:
> 
> > On 2023-03-30 12:43:45, Curran McConnell wrote:
> > > Hi Michael, thanks for your explanation. I have a followup
> > > question.
> > > 
> > > You distinguish between creating a Sage interface to an external
> > > library
> > vs
> > > writing a standard piece of Sage in Rust.
> > > If my package exported a native Python extension module
> > > (https://docs.python.org/3/extending/extending.html), packaged
> > > via
> > wheels
> > > so the user never has to run the Rust toolchain themselves, would
> > > that
> > fall
> > > into the "interface to an external library" category, from your
> > > point of
> > > view?
> > 
> > The devil is in the details but I'd bet that it does.
> > 
> > The two things that would cause problems are,
> > 
> >   1. Adding an *.rs file directly to sage.git.
> >   2. Creating a type=standard package that needs to compile an *.rs
> > file.
> > 
> > Sage is slowly modularizing, and if you look in build/pkgs, you'll
> > see
> > a list of separate "packages" that can be installed. The
> > terminology
> > is a bit confusing nowadays, but if you look in (for example)
> > build/pkgs/flint/type, you'll see "standard". A standard package is
> > one that is essentially a part of sage itself. Those packages
> > should
> > also not be written in rust, at least for now, since everyone needs
> > to
> > be able to build them from source.
> > 
> > In your case you probably just want people to be able to `pip
> > install`
> > your package and to have it show up in their Sage interface. That's
> > possible without an entry in build/pkgs at all, and you can
> > implement
> > it however you want. So long as it's not shipped with and an
> > essential
> > part of sage itself, an independent python module/extension has a
> > lot
> > of freedom.
> > 

-- 
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/f5ee21ebea936f0fe886d6b4a0e573a84cdf2b4d.camel%40orlitzky.com.

Re: [sage-devel] external libraries - is Rust allowed?

[Michael Orlitzky]

On 2023-03-30 10:50:32, Curran McConnell wrote:
> Hi folks!
> 
> I am scoping out a project to write an algebra/combinatorics package. It 
> would be a shame if the project was a success, and then there was 
> difficulty integrating with Sage if people wanted to redistribute the 
> routines there. Are Rust additions to the Sage ecosystem welcomed?
> 

It depends on what you mean by an addition to the ecosystem. You can
pretty easily write an external library or program in rust, and then
create a Sage interface to that using Cython or popen. In that
scenario the language used to implement your package is irrelevant.

If instead you want to write a standard piece of Sage in rust, that
would be more of a problem. Sage is built from source and ships its
own miniature linux distribution down to the compilers. It would have
to be an extemely compelling package to justify adding the whole rust
toolchain to the mix. I'd go farther and say that there are serious
maturity problems in the rust ecosystem that make it impossible in the
near future. Even if sage was willing to use system packages in this
case, there are, for those same reasons, no distributions attempting
to correctly package rust software right now.

-- 
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/ZCXdywyRyIr91vI0%40stitch.

Re: [sage-devel] FlintQS upstream

[Michael Orlitzky]

On Thu, 2023-03-23 at 22:05 +, Dima Pasechnik wrote:
> On Thu, Mar 23, 2023 at 9:14 PM Michael Orlitzky  wrote:
> > 
> > Does someone have access to https://github.com/sagemath/FlintQS ?
> > 
> > The build is broken with clang-16 and there's an open pull request to
> > fix it. A new release would be helpful.
> 
> I promoted you to a maintainer of this repo.
> 

Thanks. After spending some time with the code, I'd rather replace it.
There are unreported security issues with its use of /tmp,
and it's just generally pretty fragile. It also looks like a more
reliable (but often slower) implementation has been added to flint in
the meantime, as qsieve_factor().

On the examples I've tried, FlintQS is usually capable of factoring a
product of two primes, and relatively quickly. Switching the
implementation to qsieve_factor() slows it down a bit (2s to 3s, for
example). However, in cases like

  qsieve(329884789374968270239373010571299817801707558079749117449)

which is a product of THREE primes, FlintQS gives you the wrong answer
in four seconds whereas qsieve_factor() takes six to get it right.

Number theorists, please speak up if you prefer to get less reliable
answers more quickly in some scenario that I haven't imagined.

-- 
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/7a04728a6fbe3b8fc739ada6e2589e2bb7acde1a.camel%40orlitzky.com.

[sage-devel] FlintQS upstream

[Michael Orlitzky]

Does someone have access to https://github.com/sagemath/FlintQS ?

The build is broken with clang-16 and there's an open pull request to
fix it. A new release would be helpful.


-- 
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/0e8f6be3967696c2001a14f7407394dba80fd17e.camel%40orlitzky.com.

Re: [sage-devel] Can I easily prove a contradiction of the form 0=1 in sage?

[Michael Orlitzky]

On Sat, 2023-02-11 at 13:13 +0200, Georgi Guninski wrote:
> Without doubts, sage and its library have bugs.
> 
> Are the bugs "powerful enough" to prove contradiction of the form 0=1?
> 

In addition to all the good reasons why this might happen: Sage
includes all of python, and python DGAF.

-- 
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/6bb4779042fe05843753b2cca01df07e93e08f3b.camel%40orlitzky.com.

Re: [sage-devel] Re: VOTE: move Sage development to Github

[Michael Orlitzky]

-1

Proprietary platforms are against the spirit of free software,
science, and mathematics. It is also a step backwards from what we
have now. Microsoft is one of the oldest, most resourceful, and most
consistent enemies of open software and standards. Letting them
control the platform is especially foolish.

An emergency plan to migrate away from Github is less than worthless
because it presumes cooperation from Github. You're planning for a
very special type of disaster that is bad enough to make us want to
leave, but in which all of the data-retrieval APIs (and the data
themselves) remain freely available.

-- 
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/YzXrCOO8bfickGps%40stitch.

Re: [sage-devel] Temporary files problems

[Michael Orlitzky]

On Tue, 2022-09-27 at 18:10 +0100, Dima Pasechnik wrote:
> Basically, we should deprecate and remove tmp_dir() and tmp_filename()
> from Sage.
> Does Sagecell use them? It should not, Python3 has perfectly good
> replacements...
> 

That was always the plan. From #33213:

> Afterward, the custom functions tmp_dir() and tmp_filename() can be
> deprecated in favor of tempfile.TemporaryDirectory() and 
> tempfile.NamedTemporaryFile().

That solves the problem.

-- 
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/92ac8ece46b1c27c78f76447bbf74b62e0e5fc5c.camel%40orlitzky.com.

Re: [sage-devel] trailing sage-ipython processes in patchbots

[Michael Orlitzky]

On 2022-07-17 17:42:34, Dima Pasechnik wrote:
> On Sun, Jul 17, 2022 at 5:08 PM Thierry  
> wrote:
> > while running a patchbot client, i see a lot of unfinished processes
> > whose command is "python3 /home/sagemath/sage/src/bin/sage-ipython -i"
> > at various dates, indicating that something is not killed properly. The
> > phenomenon is not new. Any hint on how to fix that ?
> 
> this might have gotten broken in https://trac.sagemath.org/ticket/8784
> 
> Namely, in this chunk:
> 
> ...
> 
> Maybe the author  could say more.
> 

I hope not. Before that ticket, the user was supposed to call
quit_sage() to e.g. properly free memory and terminate lingering
pexpect processes before leaving sage. When using sage interactively,
ipython made the call. But when using sage as a library, approximately
no one knew to call quit_sage() at the end of their code.

To address that, the ticket took everything that was in quit_sage()
and made it happen automatically when the process exits, so the user
is no longer responsible for calling quit_sage(), regardless of how
sage is being used. As a result, neither ipython nor the user should
need to call quit_sage().

But who knows. If that change caused it, it caused it.

-- 
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/Ytf5iN4SCAdZOJrN%40stitch.

Re: [sage-devel] 2 basic questions on sagemath programming with external CAS systems

[Michael Orlitzky]

On Thu, 2022-05-12 at 20:28 -0700, 'Nasser M. Abbasi' via sage-devel
wrote:
> 
> 
> And with maxima it does not even time out. It hanged
> 

Integrating with maxima doesn't use the pexpect interface. There *is* a
pexpect interface to maxima, but there is also a library interface that
is faster. Some things have been ported to the faster interface while
others have not. Integration has.

-- 
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/ace7a7f769e6f705665f800b3425daa09f979c74.camel%40orlitzky.com.

Re: [sage-devel] 2 basic questions on sagemath programming with external CAS systems

[Michael Orlitzky]

On Thu, 2022-05-12 at 03:32 -0700, 'Nasser M. Abbasi' via sage-devel
wrote:
> 1)  I just want to confirm if this is what happens ( I could find 
> information on this googling).
> 
> If from sagemath, one makes a call to an external CAS, does sagemath create 
> a subprocess, starts the external CAS executable in it, makes the call, and 
> when the call is over, that subprocess is then killed? Or does the 
> subprocess remain running until sagemath itself is closed?
> 

There are a few different ways that sage interacts with other programs.
When the external program doesn't provide a library interface and we
have to interact with it by pretending to be a user, we typically use
pexpect for that. And in that case, the subprocess remains running.

You can confirm by running `ps aux` in another terminal.


> 
> 2) does sagemath 9.6 have now a way to timeout a call? For example, I'd 
> like to do something like this (using Maple syntax for illustration)
>  
>  try
>   timelimit(60, integrate(cos(x),x,algorithm="giac"))
>  catch timeout:
>   print("timed out");
> end try;
> 

This is a little tricky since the thing you want to timeout isn't
running within the sage process. The aforementioned pexpect interface
does support a timeout, but it isn't really exposed to the user. The
following seems to work:

  sage: giac(2)  # start the subprocess
  2
  sage: giac._expect.timeout = 0.001
  sage: integrate(cos(x),x,algorithm="giac")
  ...
  TIMEOUT: Giac with PID 15246 running /usr/bin/giac --sage
  sage: giac.quit()

More generally, you can do anything in sage that you can do in python.
In situations where you don't have to ensure that some external
interface is consistent, whatever Google turns up for "python timeout"
should work fine.

-- 
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/2d3ce55931420ccb3485979cbb02eb621a983453.camel%40orlitzky.com.

Re: [sage-devel] Factoring for Fun and Profit

[Michael Orlitzky]

On Tue, 2022-05-10 at 09:54 -0700, John H Palmieri wrote:
> Regarding the very last question: the decision many years ago was that the 
> startup scripts for Sage should be shell scripts, because using Python 
> scripts seemed to add to the startup time. If anyone wants to change this, 
> they need to do some careful evaluations and comparisons regarding startup 
> times.
> > > > > 

Keep in mind also the recent thread about "make build". Many people
still believe that "sage -i" should be able to install python for them.

-- 
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/298a04c7a9808fd8f61a0588ce1ae014e4a53db7.camel%40orlitzky.com.