odd behavior on connection to dev MUCK

[Deleted user]

Programmer Error.  Please tell Keeper what you typed, and the following message.
con-recordhost.muf(#90), line 9; ADDPROP: Non-string argument (3)
System stack backtrace:
  0) con-recordhost.muf(#90) line 9, in recordhost(:
  9:    me @ "@/lasthost" rot 0 addprop
*done*

This is something done on connection, as it occurs, right after the look for what room you're in, but before anything else.
Then about a minute later or so (I just logged in so this happened as i was typing this) without any particular input from me

Programmer Error.  Please tell Keeper what you typed, and the following message.
cmd-watchfor.muf(#80), line 86; ARRAY_NINTERSECT: Argument not an array.
System stack backtrace:
  0) cmd-watchfor.muf(#80) line 86, in announce(who=#166, action="connected":
 86:         who @ prop_showlist array_get_reflist array_intersect  ( arrToNotify )
  1) cmd-watchfor.muf(#80) line 314, in do-event(discon?=0:
314: ;
  2) cmd-watchfor.muf(#80) line 326, in main(:
326:     command @ "Queued Event." stringcmp not if do-event exit then  ( str -- )
*done*

This is new, but I'm not sure what this is from.

Oh... there's more. I tried ws.

ws
Programmer Error.  Please tell Keeper what you typed, and the following message.
cmd-whospecies.muf(#86), line 396; ARRAY_SETITEM: Argument not an array. (2)
System stack backtrace:
  0) cmd-whospecies.muf(#86) line 396, in main(:
396:         'rtn-data-bright swap "awakecolor" array_setitem
*done*

Is it possible all MUF is broken for some reason?

[Deleted user]

Ah, it can't be all MUF, since WHO is working and WHO is MUF on advancedb

[Deleted user]

pose nya
Sava 

and

say nya
Programmer Error.  Please tell Keeper what you typed, and the following message.
cmd-say.muf(#67), line 116; FMTSTRING: Top argument must be a string.
System stack backtrace:
  0) cmd-say.muf(#67) line 116, in do-say(:
116:     overb @ swap fmtstring  ( str" )
  1) cmd-say.muf(#67) line 207, in main(:
207:     3 pick not if pop pop pop do-say exit then
*done*

edit:
these are the advancedb MUF versions, of course

[tanabi]

So the macrofile got trashed somehow. This is disturbing as there's no clear reason for why this happened.

For now, I will take this opportunity to script a MUCK DB rebuild, and I will add a backup to the MUCK auto-restart / auto-rebuild script. @wyld-sw let's leave this open til the dev MUCK is back up again. Any theories as to why the macrofile got trashed are also welcome :D

[tanabi]

@wyld-sw @Nyanster The demo MUCK will be unavailable shortly as I rebuild the DB. I am writing a python script to re-do the basic setup. I will check this script into the python repo so we can easily alter it.

[tanabi]

@wyld-sw From a fresh advancedb install, con-recordhost is crashing (you can connect to the demo MUCK now as One potrzebie to see it ...) I am going to try this on a totally clean checkout of fuzzball and see if I get the same result.

[tanabi]

@wyld-sw On a totally clean install on another Linux machine (my workstation) I get the exact same problem. There's something toxic in the current fuzzball head.

[tanabi]

@wyld-sw I did a code review of your macro work and I don't see anything that screams at me as incorrect. Might have to step through it with the debugger. I'm pretty wore out so I don't think I'll get to it tonight. We can do rock/paper/scissors and see who does it tomorrow :)

[tanabi]

Found it. This line:

(void)insert_macro(line, file_line(f), getref(f));

on my gcc compiled code, for whatever reason, its running getref before file_line, which is causing the code to be atol'd (turns it to 0) and then file_line gets the next line (which will be "1").

Because gcc is different from clang, this is why it works on @wyld-sw 's mac and not my Linux machines.

[tanabi]

As it turns out, C compilers are NOT required to honor the order of the parameters when it comes to function calls. Also, older GCC compiles this "correctly" while newer GCC does not. Must be some optimization. However, because C is not required to honor the order of parameters by design, we must fix this so the order of execution does not matter.

[wyld-sw]

Very nice detective work. Thank you!

[tanabi]

Fixed in #419

[tanabi]

This is fixed, and my MUCK rebuild script worked as well. You'll have to re-create your character though cause I blew away the DB. @Nyanster @wyld-sw You can close this ticket now.

[Deleted user]

Found it. This line:

(void)insert_macro(line, file_line(f), getref(f));

on my gcc compiled code, for whatever reason, its running getref before file_line, which is causing the code to be atol'd (turns it to 0) and then file_line gets the next line (which will be "1").

Because gcc is different from clang, this is why it works on @wyld-sw 's mac and not my Linux machines.

Hah! I use clang too. Super interesting stuff, it's neat you found that.