Author Topic: Parsing the function-pointer type, i.e. (: :)  (Read 2732 times)

Offline SoundOfEmotion

  • Acquaintance
  • *
  • Posts: 6
    • View Profile
Parsing the function-pointer type, i.e. (: :)
« on: June 03, 2011, 02:07:47 PM »
I'm in the process of bringing an older mud back to life. The mud was originally running on MudOS, like v13 or something ancient. The lib itself is based off the NMII mudlib, but has been heavily modified.

My problem is handling function-pointers. It seems that the way rooms were made was for an older style driver which accepted function-pointers as strings, like the following:
Code: [Select]
set_search( "table", (: this_object(), "search_table" :) );
or even sometimes just as simple as:
Code: [Select]
set_search( "table", (: "search_table" :) );
But the setup I'm using now (Driver: FluffOS v2.9-ds2.08, Mudlib: Nightmare vDR1.0 3.2.2) requires that function-pointers be declared as follows:
Code: [Select]
set_search( "table", (: this_object(), search_table() );
To summarize the difference, this_object() is no longer implied, but is required, and the function name cannot be a string, it needs to be a function.

We're talking about thousands of rooms written in the old style, and I'm contemplating doing a massive find/replace, but before I go that route I wanted to see if anyone knew of a way to inspect the contents between (: :) programmatically. That way I can determine:

1) if !arg2, arg1 = arg2, arg1 = this_object()
2) if stringp(arg2), function arg2 = (*arg2)(), or something similar.

I just don't want to have to massively modify these files if I don't have to.
« Last Edit: June 03, 2011, 02:13:36 PM by SoundOfEmotion »

Offline SoundOfEmotion

  • Acquaintance
  • *
  • Posts: 6
    • View Profile
Re: Parsing the function-pointer type, i.e. (: :)
« Reply #1 on: June 03, 2011, 05:12:47 PM »
I was searching through the FluffOS ChangeLog and came across mention of NEW_FUNCTIONS. I've #undef'd NEW_FUNCTIONS and recompiled but it doesn't seem to have fixed my problem. I grep'd the source directory and the only occurances of NEW_FUNCTIONS was in ChangeLog, so I don't think there are checks in the source code. But this is basically what I need to switch.

Code: [Select]

    --- file: ChangeLog, line: 1916 ---

    * COMPAT BUSTER: support for this_object function pointers  
    ( i.e. (: "foo" :) ) has been removed with NEW_FUNCTIONS  
    defined.  Use (: foo :) instead.  (: "foo" :) is now a
    function which returns "foo" (see below).


... Upon further investigation, apparently "#undef NEW_FUNCTIONS" was pulled out in the v21.1a5 check in:
Code: [Select]

Fri Feb 24 23:48:38 EST 1995 (tim@handel.princeton.edu (Beek))
        * raised patchlevel to v21.1a5
        * brought up to date with respect to v21b15
        * removed support for RUNTIME_LOADING
        * removed support for #undef NEW_FUNCTIONS
        * in addition to the above, call_other pointers are gone.
          (: x, y :) should be converted to (: call_other, x, y :)
          the functionality remains unchanged, since that's all they really
          did ...
        * function pointers reorganized to use less memory (the size is
          now variable based on the ammount of space needed, so a lfun
          pointer can be significantly smaller)


I apologize for the burst of messages, but I just wanted to update here with my latest findings.

Crat, I know you're against modifying original posts, and just assuming they're set in stone. I'll follow-up if I find anything significant, in hopes that this information will prove useful to anyone encountering the same issue in the future.

- Cheers!
« Last Edit: June 03, 2011, 05:22:47 PM by SoundOfEmotion »

Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: Parsing the function-pointer type, i.e. (: :)
« Reply #2 on: June 03, 2011, 07:16:50 PM »
I've had some problems with functionals like this in the past myself, see here.

You are probably going to have to change every instance of:
Code: [Select]
(: this_object(), "search_table" :)
to:
Code: [Select]
(: this_object(), search_table :)
OR
Code: [Select]
(: search_table :)

Either way, search_table() must be defined or prototyped before the line where you are referencing it.

The only alternative would be to hack fluffos so that you can do it the other way. Good luck to you on either path.

Offline SoundOfEmotion

  • Acquaintance
  • *
  • Posts: 6
    • View Profile
Re: Parsing the function-pointer type, i.e. (: :)
« Reply #3 on: June 03, 2011, 07:44:04 PM »
Thanks Nulvect, I came across those conclusions earlier today and like you say, neither one is going to be fun.

The NEW_FUNCTIONS flag seems like it would have solved all of my problems but recent versions of FluffOS have deprecated that flag. :'(

I've looked at the appropriate parts of the driver that handle function pointers but am certainly not confident in my ability to patch it. So failing that, it looks like my only option is to update the lib.

Honestly, modernizing the lib seems like the most viable option. It just happens to be the option that requires the most amount of work.

And it's actually:
Code: [Select]
(: this_object(), search_table() :)(note: parens after function pointer required)

Because I tried:
Code: [Select]
(: this_object(), search_table :)but that doesn't work.

For reference, here's the context:

Code: [Select]

#include <std.h>
inherit ROOM;

void create(){
    set_short("A Test Room");
    set_long(this_object()->query_property("short")+"\n"
        "You are standing in a small room. There is a table nearby."
    );
    //set_search( ({"table", "desk"}), (: this_object(), "search_table" :) ); // Outdated
    set_search( ({"table", "desk"}), (: this_object(), search_table() :) ); // Required format
}

void search_table(){
    write("You find a treat!");
}


Offline Nulvect

  • BFF
  • ***
  • Posts: 127
    • View Profile
Re: Parsing the function-pointer type, i.e. (: :)
« Reply #4 on: June 04, 2011, 12:42:42 AM »
You are correct, it turns out if you are specifying the object, you must have parens at the end of the function name. You also must specify arguments here if the function takes any.

You can leave out the object entirely if it's this_object() though, and this:
Code: [Select]
set_hit( (: weapon_hit :) );
definitely works on FluffOS 2.22, as I just tested it.

Not only is this less typing, but our lib is set up to automatically send an argument - in this case, the living thing being hit with the weapon - to the function specified. This wouldn't work if we had to specify the argument ahead of time, and in fact changing it to
Code: [Select]
set_hit( (: this_object(), weapon_hit() :) );
errors with a "wrong number of args".

Offline SoundOfEmotion

  • Acquaintance
  • *
  • Posts: 6
    • View Profile
Re: Parsing the function-pointer type, i.e. (: :)
« Reply #5 on: June 18, 2011, 02:33:11 PM »
Just to tidy up here, I ended up having to update the thousands of files which used the outdated function pointers to the new method. It was a lot of work, but worth it in the end because the mudlib is now more current.

Thanks for your help, Nulvect!