Menu
▾
▴
#102 Outdated way of constructing a string
Recently, we ran into an issue in sagemath: https://trac.sagemath.org/ticket/31553 where we found that maxima's grind/displa rendering system can sometimes typeset | | as "\ ", whereas the intent is that it's a plain space here:
It looks a little outdated to be using symbols to typeset a string. I don't know how you feel about updating cade that isn't strictly speaking broken (the issue we ran into did occur in an "off-label" application), but it would help us if that | | there were actually just a " ". It seems a little perverse to make a symbol with name a space when you really just need it as a string.
Nils,
That repository is not the "official" Maxima repository, which is on
sourceforge.
That code that you point to is for
imaxima, an emacs-based front-endthat uses latex to typeset maxima's output. That is why | | is typeset
as "\ ".
(As an aside, I don't think there is anything outdated about using
symbols this way, btw.)
Perhaps you can give us more details about how the behaviour is
elicited, e.g. a minimum failing example.
Leo
Nils, after looking at the sagemath ticket, I think the attached patch
fixes your problem. I don't think Sage's patch of `retrieve' is needed.
Can you confirm this fixes the problem?
Leo
Yes, that would solve the problem for us! We still need to (monkey)patch retrieve because we need it to raise an error rather than to ask a question: when we use maxima as a library, the STDIN/STDOUT aren't actually connected to a terminal on which a user can answer. That's a problem that is ours, though. However, it would save us going through the "msg" replacing | | with " " after the fact.
If you'd be OK with pushing this change then we'll happily throw out our postprocessing once we upgrade to an amended maxima.
I'm puzzled why under normal circumstances Maxima/ECL seems to print these spaces just fine, but not when stdout is redirected to a string.
(one reason I'd be a little hesitant to use symbols for text content: unicode. I'd expect there to be a lot of lisp implementations that are going to be quite picky for what characters they accept in symbols, but not for strings. So if you know you're only going to need a name as a string and not all the other bells and whistles that come with symbols (bindings, function bindings, attributes), then using strings communicates intent much better. That's mainly for new code, though. Little reason to go a patch up old code unless it gets in the way)
@l_butler the proposed askp.lisp.patch looks good to me.
Couple of random comments -- just tangential at this point.
@nbruin my advice is to be careful about which repo you and other Sage developers are referring to -- the only one we maintain is on Sourceforge. Any other isn't guaranteed to be up to date. I know it's a small thing, but I feel like it's important that we refer to the same repo.
About strings and symbols, I think it's problematic to use symbols to represent strings. Symbols are strings plus some associated metadata, and symbols have properties over and above what strings have. So introducing a symbol where only a string is needed has the potential to introduce unnecessary complications.
All the best, Robert.
@robert_dodier indeed. Is there a mirror of the Maxima repo somewhere that is easily linked to? The sagemath repo is also not primarily on github, but it's mirrored there and it is a much lower bar to search and refer to than cloning a repo. In this case, I knew the code in question was ancient and hadn't changed in decades, so I figured having any reference would do. The reference was really about file+lineno. This is definitely not the repo that sagemath pulls its "maxima" from! However, once maxima is built the source is thrown away in the build, so there wasn't an easy way for me to refer to it.
EDIT: Nevermind. I found it: https://sourceforge.net/p/maxima/code/ci/master/tree/src/macsys.lisp#l347 . It looks like github has a better search and blame interface, but it has the obvious drawback that it's not libre. But well .. Good to know that maxima code is also fully browseable online.
It looks like all these askp queries are constructed from symbols rather than strings, and they are clearly meant as string constants. So if you really feel strongly about using strings where strings are needed, I think there is a bit of a project here.
Last edit: Nils Bruin 2021-10-02
Hmm, wouldn't https://sourceforge.net/p/maxima/code/ci/5.45.1/tree/interfaces/emacs/imaxima/imaxima.lisp for example, to link to imaxima.lisp in a specific version (whatever Sage is working with, I guess) ? It seems to lack the capability to link to specific lines, but it would be easy enough to "line 496 at the above link" or whatever.
About strings and symbols, yeah, Maxima is full of historical oddities ... it would be a big project to update all of that.
Fixed in commit 798d29dc0.
Closed per Leo's commit.
@nbruin Maxima is on SF not because we chose that over Github, but rather that Github didn't exist when the Maxima became a collaborative project circa 2001. The possibility of migrating to another platform has been raised a couple of times, but moving the mailing list and bug tracker would be substantial tasks which nobody has volunteered to take on, aside from the confusion it would cause for everyone involved.
Is there a good way to mirror sf Repos on GitHub nowadays? That might be better than moving the complete project ...
I would think mirroring would consist of a cronjob (every day or so?) consisting of
git pull sf master
git push github master
where "sf" is set up as the sourceforge remote and "github" is set up as the github remote. That's not a two-way mirror of course: all development would still go through the sourceforge repo. But you'd have a pretty up-to-date, github mirror of the current state of the maxima master branch. If you want a full mirror there are some more options to take care of, but those are widely discussed on the web by people who know more about git than I do.
Sourceforge does have code browsing and linking to line numbers. It was just my ignorance. So I'm not sure that github really has a "killer" feature that makes having a github mirror essential.
The reality nowadays is that there are a lot more people familiar with github and it gets indexed very well by search engines, so a mirror makes you more visible and accessible.
Sagemath has experimented with mirroring in the other direction too, where development on github can make it back to sage's trac server. I don't think that caught on (and perhaps didn't work well).