"Program not compilable" error lacks useful detail
Closed this issue · 21 comments
"Program not compilable. Cannot run."
This error message does not indicate which program failed to compile or why. In this instance, it's also failing to write the relevant details to the muf-errors log. As a result, we have an issue on SPR where everyone logging in gets the above error message, with no clue as to why.
I think adding more detail to that message is a good idea. I’d recommend looking through the main _connect queue and trying to compile each of those programs to see where the issue lies. I can be on hand at SPR shortly. If it’s a problem with FB7, wel’ll fix it.
Just was on SPR and it may look like it has been resolved (let us know if that's not the case!). If it is something that we should fix on the server side, please let us know.
Keeping this issue open so we can improve that message and consider writing compilation errors to that log.
Thanks again, @wyld-sw.
Yeah, that is a really weird message to get -- I remember when I was new to FB I found it awful confusing until I figured out you could compile the program manually and see what error it was throwing. When it happens in a propqueue it is super annoying to track down.
@wyld-sw Propose we put this in 7.2 (unless @f0x1de has an immediate need, in which case we can tackle it sooner). My finger in the wind on this one is that it will be easy-ish ... the code around where this happens is somewhat tricky as I recall and not quite a "sneak it in" kind of issue. Though if SPR needs it ASAP then that makes it a higher priority.
No complaints here.
Not here either.
I'm receiving this message for every program I try to run on the newly compiled test MUCK I just made. Many of the programs are giving me this error, among them include: WHO, 3who, laston, ansi, meetme, cp, lsedit, watchfor, @shout, @exits, @stats, @view, page, pose, say, whereare, etc.
You might not have the actual MUF files installed in the right location. The files in dbs/starterdb/muf/ should also be copied to the installation’s game/muf .
This might be something to clarify in the documentation.
Hmm.. okay, I did that, the files are there.
~/fuzzball/game/muf$ ls
10.m 13.m 17.m 23.m 29.m 34.m 40.m 48.m 54.m 60.m 68.m 73.m 8.m 87.m 93.m README
101.m 14.m 18.m 25.m 3.m 36.m 42.m 5.m 56.m 62.m 7.m 75.m 81.m 89.m 95.m macros
103.m 15.m 19.m 27.m 30.m 38.m 44.m 50.m 58.m 64.m 70.m 77.m 83.m 9.m 97.m
11.m 16.m 21.m 28.m 32.m 4.m 46.m 52.m 6.m 66.m 71.m 79.m 85.m 91.m 99.m
Then I hit @restart in-world, then $ sudo /usr/local/sbin/fb-restart in SSH, got the server running, but still cannot run the programs.
Something I noticed while examining one of the broken commands:
ex #101
cmd-page(#101FVM3) Owner: Keeper
Type: PROGRAM Flags: MUCKER3 VIEWABLE
A scroll containing a spell called cmd-page
Created: Tue Dec 8 01:37:06 2020 UTC
Modified: Tue Dec 8 02:41:24 2020 UTC
Lastused: Tue Dec 8 02:41:24 2020 UTC
Usecount: 11 Instances: 0
[ Use 'examine <object>=/' to list root properties. ]
Memory used: 323 bytes
Program not compiled.
Location: Keeper(#2PWQBM2)
Notice it says "Program not compiled"?
Hmm, for that to happen for all of the files makes me think they're still not in the right place. You could check by using @edit #101 and checking if a command to list lines (1 99 l) shows anything.
After exiting the editor with q and completely shutting down the MUCK, could you try copying that MUCK folder to /usr/local/game/muf and seeing if that helps?
@TogarUshindi just FYI -- the MUCK "just in time" compiles programs so it is normal for them to say Program not compiled. Fuzzball doesn't save "binaries", it just saves the program code, so the program is compiled on the fly the first time it is run and it is kept compiled in memory for awhile.
But Wyld is probably right, this looks like a path problem. If you can't figure it out on your own, feel free to reach out to me and we can either do like a skype screenshare thing or you can give me a temporary shell password to your server (if accessible) so that I can fuss with it. It's likely something pretty easy.
@edit #101
Entering editor for cmd-page(#101FVM3).
Line not available for display.
I copied the ~/fuzzball/game/muf files to /usr/local/game/muf/ and the programs are working now. The editor still says Line not available for display. though.
Question: What are the contents of ~/fuzzball/* for and what are the /usr/local/* contents for? If the program was compiled and installed as super-user, wouldn't/shouldn't all contents be installed to and be called from the /usr/local location?
But Wyld is probably right, this looks like a path problem. If you can't figure it out on your own, feel free to reach out to me and we can either do like a skype screenshare thing or you can give me a temporary shell password to your server (if accessible) so that I can fuss with it. It's likely something pretty easy.
Wyld was mentioning he was interested in making a Discord Server for muckymuck stuff, so I'd love to tallk to you all there whenever that gets running!
That's good to hear.
It does appear that the editor still says "Line not available for display." when you first open a program for editing - somewhere along the way this broke, so I think this is a good candidate for a bug fix!
The fuzzball distribution does come with the starterdb, but it does need to be copied to the /usr/local/game location (or a prefix you set) to be used. Both the source files and the database are kept in case there's a need to re-compile (version updates, etc) or revert. I hope that made sense.
You had mentioned in another thread that you had experience with WinFuzz. That comes pre-compiled, since not everyone has the tools available to compile for Windows.
We'll discuss the Discord server idea (or IRC, or Telegram) and let you know. Thanks for the idea!
Matrix! One protocol to link them all...
I could register it on furnet instead, if that's preferred. I'm fine with either.
Hey @conws are you around? We're in the freednode channel.