Re: folder naming conventions and installed version identifier, was: Maxima searching all "binary" directories: conflicts & performance degradation

Hi Robert,

Thanks for the feedback.

I completely agree regarding the 5.nnnpost version identifiers — that’s an
excellent point, and it absolutely complicates both bug reporting and the
file search logic. However, I have practically no knowledge of that part of
the Maxima codebase (like configure.ac or the build scripts), so it would
be much better if someone else could tackle that specific issue.

Regarding the directory structure for the binary files, your feedback
brings up two technical hurdles we need to consider:

*1. Do users actually need $USER_DIR/**/*.fasl?*

Currently, $file_search_lisp includes the wildcard entry
$USER_DIR/**/*.fasl (where
$USER_DIR is the user's Maxima user directory and .fasl can be different
for other Lisps). My question for you and the list is: do users really
expect to be able to drop their own compiled Lisp files (.fasl) *anywhere*
in their user directory (not inside binary) and have Maxima find them?

If we can agree that the answer is "no, they shouldn't," then this whole
problem becomes incredibly simple to solve. We can just remove that
wildcard and only add the correct binary directory to the search path.

If the answer is "yes, they do expect that," then keeping the binary folder
inside the top-level user maxima directory becomes tricky. That wildcard
will inevitably sweep through and find all the old, incompatible .fasl
files that we are explicitly trying to avoid. We would have to write
explicit exclusion logic: *If a matched file is located somewhere within
the binary folder, explicitly check that its path matches the current
version/Lisp combination; otherwise, reject it.* This adds messy logic,
which was my primary motivation for thinking about a separate folder like
maxima-internal.

*2. The OS Distinction & Flattening the Directory*

Regarding baking in the OS name: I understand the concern, but adding the
OS is essentially a one-line code change that shouldn't introduce new
points of failure. A simple distinction between Windows, UNIX and unknown
can be achieved by looking at common *feature* members.

To address the concern about messy folders and deep nesting, what if we
flattened the structure instead of nesting it? Rather than having
binary/5_47post/sbcl/2_6_3/win32, we could merge the identifiers into a
single directory name: binary-5_47post-sbcl-2.6.3-windows. This keeps the
directory tree shallow, completely prevents cross-platform/version
interference, and requires very little effort to implement.

As a related side note, I actually suspect that the bug Wolfgang recently
ran into <https://sourceforge.net/p/maxima/bugs/4713/> may be related to
his cross-OS workflow. It is just a suspicion as of now — we haven't found
the root of the issue yet — but it does highlight why having a built-in OS
separation might actually save us from tricky edge-case bugs.

Let me know what you think about the user expectation regarding .fasl files
— that seems to be the biggest technical blocker to keeping the binary
files inside the standard user directory.

Best regards
David

Am Sa., 18. Apr. 2026 um 18:54 Uhr schrieb Robert Dodier <
[email protected]>:

> David, thanks for working on this stuff. I agree it's a good idea to
> solve it somehow.
>
> About searching only the binary folder for the current version -- agreed.
>
> About creating another top-level folder -- I'm against it, I think the
> binary folder should go inside the top-level per-user maxima folder
> (same as it is now).
>
> About baking the OS name into the binary path -- I'm against it, I
> don't think it's common enough to justify the effort, which is mostly
> going to be trying to fix bugs after the fact when users report it's
> not working for them.
>
> It's a mess to have multiple folders for different combinations of
> Maxima + Lisp versions, but I don't think Maxima should try to clean
> that up; I think we should leave it for the users to deal with. I
> expect the vast majority of users are going to have one Maxima + Lisp
> combination for each installed version -- I think that's tolerable.
>
> You didn't mention it, but I've come to the conclusion that installed
> versions of Maxima should only identify themselves via
> version-specific identifiers, as it is now with uninstalled versions
> (e.g. branch_5_49_base_392_g85c1954 as it is right now); identifying
> itself as "5.nnnpost", e.g. 5.49post, makes it impossible to
> distinguish different installed versions. That is a serious
> consequence for bug reporting, and also for the file search problem. I
> guess we would have to modify configure.ac or something to fix that.
>
> All the best,
>
> Robert
>

_______________________________________________
Maxima-discuss mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/maxima-discuss