Author Topic: Fluffos w/add_action  (Read 3358 times)

Offline Larnen

  • Acquaintance
  • *
  • Posts: 9
    • View Profile
Fluffos w/add_action
« on: May 18, 2007, 05:10:33 PM »
Hi all,
First of all great work with FluffOS. We may have a couple of patches to send your way for crashers from our own fork of MudOS, but looking at what you've been up to you've probably already got them all!

I decided to try compiling up FluffOS 2.6, but with add_action support as this is still used extensively on our mud. Yes, I want it to go away, but thats a job for another day  ;)

However, I get the following error:
Quote
gcc -D__USE_FIXED_PROTOTYPES__ -rdynamic -O2 -fstrength-reduce -o obj/add_action.o -c add_action.c
add_action.c: In function `add_action':
add_action.c:472: warning: passing arg 1 of `is_static' discards qualifiers from pointer target type
add_action.c: In function `f_add_action':
add_action.c:587: warning: passing arg 2 of `add_action' discards qualifiers from pointer target type
add_action.c:592: warning: passing arg 2 of `add_action' discards qualifiers from pointer target type
add_action.c: In function `f_command':
add_action.c:616: error: `eval_cost' undeclared (first use in this function)
add_action.c:616: error: (Each undeclared identifier is reported only once
add_action.c:616: error: for each function it appears in.)
add_action.c: In function `f_find_living':
add_action.c:659: warning: passing arg 1 of `find_living_object' discards qualifiers from pointer target type
add_action.c: In function `f_find_player':
add_action.c:675: warning: passing arg 1 of `find_living_object' discards qualifiers from pointer target type
add_action.c: In function `f_remove_action':
add_action.c:739: warning: passing arg 1 of `remove_action' discards qualifiers from pointer target type
add_action.c:739: warning: passing arg 2 of `remove_action' discards qualifiers from pointer target type
add_action.c: In function `f_set_living_name':
add_action.c:749: warning: passing arg 2 of `set_living_name' discards qualifiers from pointer target type
make[1]: *** [obj/add_action.o] Error 1
make[1]: Leaving directory `/home/mud/src/fluffos-2.6'
make: *** [main_build] Error 2

The warnings arent perhaps so serious, but it looks as if references to eval_cost have been removed from backend.c among other places, even with add_actions defined. Can you confirm if this is the case, and whether there is a method to compile with add_action support?

Thanks,
Larnen

Offline sojan

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: Fluffos w/add_action
« Reply #1 on: May 19, 2007, 03:04:03 AM »
Yes,  eval_cost has been removed but there is a function now called get_eval() which does the job.  When I did the original patches for fluffos to get DS to run I made a few changes there and the patch below should fix the issue.  I believe Wodan has incorporated this patch into the next release and also posted a bunch of patches on the MXP support thread that include this one and will probably help you get it up and running depending on what options you used.

J

Patch for add_action ..

Quote
diff -urw fluffos-2.6/add_action.c fluffos-ds/add_action.c
--- fluffos-2.6/add_action.c    2006-08-30 11:12:07.000000000 +0100
+++ fluffos-ds/add_action.c     2007-04-24 10:57:44.000000000 +0100
@@ -324,7 +324,7 @@

        if (!(s->flags & V_FUNCTION))
            debug(d_flag, ("Local command %s on /%s",
-                          s->function.s, s->ob->name));
+                          s->function.s, s->ob->obname));

        if (s->flags & V_NOSPACE) {
            int l1 = strlen(s->verb);
@@ -613,7 +613,7 @@
     if (current_object && !(current_object->flags & O_DESTRUCTED))
     {
        char buff[1000];
-       int save_eval_cost = eval_cost;
+       int save_eval_cost = get_eval();

        if (SVALUE_STRLEN(sp) > sizeof(buff) - 1)
            error("Too long command.\n");
@@ -622,7 +622,7 @@
        buff[sizeof(buff) - 1] = 0;

        if (parse_command(buff, current_object))
-           rc = save_eval_cost - eval_cost;
+           rc = save_eval_cost - get_eval();
     }

     free_string_svalue(sp);

Offline Larnen

  • Acquaintance
  • *
  • Posts: 9
    • View Profile
Re: Fluffos w/add_action
« Reply #2 on: May 19, 2007, 10:02:25 AM »
Thanks for the reply :) It feels all strange getting near realtime discussion on a Mudos topic - its been so long!  ;D

I found the patch late last night and as you rightly say it fixes this issue. If it can get weaved into the standard dist that would be fantastic! Using this I've got my mud (Elephant Mud, www.elephant.org) to compile under FluffOS and can log in successfully after a little tinkering. I found a few other oddities that I'd like to share with the community and hopefully we can tweak these too:

Compression Support
Had some problems with this. Ive got zlibc and zlib1-dev installed (debian, sarge), but its not finding gzeof etc. Does this need an addition -l to the linker added in make? Also if you disable compression support the telnet negotiation fails to compile, as there is no #ifdef around comm.c line 899.

PRAGMA_OPTIMIZE
Used this without much issue on v22.1b13, but on fluffos (and I suspect v22.2 in general) this causes some strange crashers. I can generate some examples of this if we'd like to look in more detail, but it may be that PRAGMA_OPTIMIZE is dead and should be removed. I notice that DS has it off by default.

Trying to put string into int
And other similar errors. This is a new error added post v22.1 and while I whole heartedly approve, on very old libs (ele is 14 years), there can be a lot of these scattered around. Can we have an option to either ignore or, preferably, convert to a warning not an error, so these can be fixed as time allows?

Line numbers in errors
I found these to sometimes not match the errors. Sometimes Id see 'line 366' in a 300 line file, or an error in funcA with a line number from funcB. Not quite sure whats afoot here - could it be counting #include lines etc too? Anyone else seen this?

TRACE
Interpret.c fails to compile with this on. In particular I believe line 5607 has references to current_object->name that should be current_object->obname.

Apart from those minor issues though its looking fantastic. Great work!

Many thanks,
Larnen

Offline sojan

  • Acquaintance
  • *
  • Posts: 35
    • View Profile
Re: Fluffos w/add_action
« Reply #3 on: May 19, 2007, 12:59:21 PM »
I've often found when compiling fluffos that I've needed to add -lz to the system libs file - this has never seemed to be constant to me and has varied from server to server and distro to distro.  If anyone can explain it I'd love to know.  The comm.c stuff fails due to the MCCP support IIRC which isn't controlled by a compile time option, this and a lot of the other stuff you list Wodan is building in to the next formal release but it's not quite there yet.  I don't know about the line numbers in errors stuff since they work fine on DWlib so are probably related to the way the info is passed to the error handler.

Generally speaking if you're using a fluffos option that DWLib uses then the DW team will be on top of it - if you discover things like the obname in trace.c that you need to make your particular lib work if you could create a patch and send them to wodan at wodan@wodan.pressanykey.nl he can merge them into the core source.

J

Offline wodan

  • BFF
  • ***
  • Posts: 434
  • Drink and code, you know you want to!
    • View Profile
Re: Fluffos w/add_action
« Reply #4 on: May 21, 2007, 06:42:34 AM »
Quote
PRAGMA_OPTIMIZE
Used this without much issue on v22.1b13, but on fluffos (and I suspect v22.2 in general) this causes some strange crashers. I can generate some examples of this if we'd like to look in more detail, but it may be that PRAGMA_OPTIMIZE is dead and should be removed. I notice that DS has it off by default.
The optimizer in v22.2 makes some assumptions that are just not true, I'll probably remove it completely in the future.

Quote
Trying to put string into int
And other similar errors. This is a new error added post v22.1 and while I whole heartedly approve, on very old libs (ele is 14 years), there can be a lot of these scattered around. Can we have an option to either ignore or, preferably, convert to a warning not an error, so these can be fixed as time allows?
should be ok with the last patch in the mxp thread if you turn off pragma strict types

Quote
Line numbers in errors
I found these to sometimes not match the errors. Sometimes Id see 'line 366' in a 300 line file, or an error in funcA with a line number from funcB. Not quite sure whats afoot here - could it be counting #include lines etc too? Anyone else seen this?

Not sure what the problem is there, I remember we had wrong line numbers on DW at some point though.. I'll try to find out what we did to fix it :)