code assert

[DanGrayson]

Look here:

i16 : code assert
stdio:16:1:(3): error: couldn't find file /Users/dan/src/M2/M2.git/M2/Macaulay2/d/startup.m2.in

Too bad!

[mahrud]

Why is startup.m2 still hardcoded? I'm sure it takes little facility to read one string from one predetermined location. The location can be either guessed, specified in init.m2, or given via environment or arguments.

[DanGrayson]

Not sure what your question is. We do read one string from one location. That's what startup.c is about.

[mahrud]

M2 doesn't read startup.c, the compiler does, and it hardcodes it in the binary. I'm suggesting that the M2 binary read the startup.m2 file. This way you wouldn't need to recompile to change things in startup.m2.

[DanGrayson]

The code in the string contains the location where *.m2 files should be found in the layout of the OS currently in use, without which we can't find any code, as well as the code for reading it, and also things we need if the files are not there, such as the usage message and the copyright message.

[mahrud]

That's why I said "one predetermined location". We could check for startup.m2 in /etc and {/usr,/usr/local}/share/Macaulay2/Core, or store the address in ~/.Macaulay2/init.m2 or an argument/environment variable.

[mahrud]

In other words, instead of all of startup.m2 being hardcoded, we just hardcode the list of places to look for it.

[DanGrayson]

There's no predetermined location that we can be guaranteed to have access to.

[mahrud]

If we check a few predetermined locations and give an informative error if not found, what would be the problem? We could also check in ../share/Macaulay2/Core and ../../common/share/Macaulay2/Core/ to make it relocatable.

We already do this here: https://github.com/Macaulay2/M2/blob/1c397c460eeb76b5b7b58e402c8ea6360af559ae/M2/Macaulay2/d/startup.m2.in#L527-L532 And here: https://github.com/Macaulay2/M2/blob/1c397c460eeb76b5b7b58e402c8ea6360af559ae/M2/Macaulay2/d/startup.m2.in#L675-L688 I'm only suggesting doing this in M2libs.c instead, and loading startup.m2 dynamically.

[DanGrayson]

Both of the snippets of code you point to are concerned with locating our code in the source tree, not on the target machine. The problem with giving an error message is that you leave our poor users in the lurch.

[mahrud]

I understand what the code does, my point is that looking for the location of startup.m2 would be similar to this. Can you tell me a scenario where startup.m2 would not be found in any of the addresses I mentioned?

By the way, I am trying to addressed the issue that you opened, which is caused by startup.m2 not existing on our poor users' machine. The simple solution is not hardcoding startup.m2, or at least only hardcoding the absolutely necessary stuff like setting the path to find startup.m2.

[DanGrayson]

No, the original post is about trying to find the file startup.m2.in, which is part of the source code repository, and could also be distributed, but it's not. The contents of startup.m2, by contrast, are in the binary image, so it can be found by our code, but the user doesn't get to see it, to discover, for example, the definition of "assert".

The location of a source file depends on the linux hierarchy of the system we're on. Every linux variant gets to specify its own hierarchy, and there's no way to have a list of possibilities that includes all future variants. That's why the configure script is careful to use the variables provided for layout purposes, libdir, libexecdir, and so on, so the layout can be controlled with suitable configure script options.

[mahrud]

Unless I'm mistaken, this is fixed now.

[DanGrayson]

Yes, probably thanks to @d-torrance