Link for repository of fluffos-2

[silenus]

Here is a link to the fluffos-2 repository that I have patched up to bring back compatibility with OS X and FreeBSD. It has some additional fixes including compiling now with a C++ compiler so that one can in principle incorporate C++ code into the driver.

https://github.com/cartercheng/fluffos-2

For now I will go on occasionally maintaining this and perhaps cleaning up some of the old code. I will also try to port over features from FallenTrees 3.0 repo if someone feels they are improvements over the old code and don't break compatibility.

[quixadhal]

Just a quick bug report.  In trying to boot the ancient discworld mudlib, I get an "undefined function stringp" while loading the sefun object.

Code: [Select]

/secure/simul_efun/add_a.c line 40: Undefined function stringp before )
No error handler for error: *Error in loading object '/secure/simul_efun/add_a'
program: (none), object: (none), file: (none)
The simul_efun (/secure/simul_efun) and master (/secure/master) objects must be loadable.

The local options file used:

http://wileymud.i3.themud.org/~quixadhal/local_options.txt

and the runtime config file:

http://wileymud.i3.themud.org/~quixadhal/dw.cfg.txt

The same options and config files worked on my older version of fluffos 2.x, so there's that.

[silenus]

I just fixed this. Apparently I merged in a unfully tested dev branch into the main branch where the efuns weren't being linked in. Should work now.

[silenus]

The repository is updated to include local_options.dw and local_options.lima which should work with the respective libraries on the download page.

[quixadhal]

Almost there!

Compiles fine, boots up, connects to I3, I can log in, however every command now shows up as a "queued command" and never actually executes.

I vaguely remember this being commented on elsewhere, perhaps in the discworld section of the forums even.  I'll try to poke around a bit later and see if I can find it, if you don't beat me to it.

[silenus]

This might be more an issue with the dw release version than an issue with the driver. Perhaps someone needs to hack the lib to get this working? I really don't know enough about the discworld library to know where to start looking.

[quixadhal]

It's a change in the driver behavior... for good or bad, I don't judge.  However, I'm using the exact same mudlib on your driver that I'm using on the old 2.27.2 driver.  What Discworld uses to do its "queued command" logic, I don't know... but whatever it is, the driver is acting differently.

[silenus]

I might be misunderstanding the old post but there wasn't a fix posted. I think it said that the problem is fixed in newer versions of the lib.

[quixadhal]

The post I found said they fixed their problem but never elaborated on HOW they fixed it.

There may well be a workaround in the LPC code, but I assumed you were aiming for the driver to be a drop-in replacement for the older C version.

For my test case, I unpacked the discworld lib, compiled the driver from my own git repository (version 2.27.2), and verified that it worked, connected to I3, and I could walk around and do a few basic things.  Then I compiled the newer C++ version of the driver using the same local_options files and booted the same mudlib, in place, with that newer driver.  The result is that it boots, connects to I3, but logging in results in "Command Queued" no matter what you type.

Since the mudlib code has not changed, and the configuration has not changed, this must be a change in the driver's code, somewhere.  Since it has to do with delays, my initial guess is that it might be related to the posix timer stuff, but that's just a guess.

[FallenTree]

@quixadhal, are you talking about the latest fluffOS-3.0.20170907 version ?

It's definitely not about posix_timers because all that does is for max_eval.  If you see anything in /log/debug.log  that might be more useful.  I may give it a try in next few weeks to see how to make it work.

[silenus]

Well from the old post it looks like the mudlib didnt work properly b4.

[quixadhal]

I'm not sure how much more clearly I can possibly state this.

Code: [Select]

tar xvf dw_fluffos_v3.tar.bz2
cd dw_fluffos_v3
git clone git@github.com:quixadhal/fluffos.git fluffos_quix
git clone git@github.com:cartercheng/fluffos-2.git fluffos_carter
cd fluffos_quix/src
... adjust local_options to work for discworld ...
./build.FluffOS
make
make install
cd ../../bin
... adjust dw.cfg ...
cp -p ../fluffos_quix/bin/driver .
cp -p ../fluffos_quix/bin/addr_server .
cp -p ../fluffos_quix/bin/portbind .
cd ../lib
... adjust a couple of well-known issues in the mudlib LPC files ...
cd ../bin
./addr_server 4999 &
./driver dw.cfg &
... telnet to game, verify that commands work and I3 connects, chat on I3, shutdown game ...
... kill addr_server process ...
cd ../fluffos_carter/src
cp -p ../../fluffos_quix/src/local_options .
./build.FluffOS
make
make install
cd ../../bin
mv driver driver.quix
mv addr_server addr_server.quix
mv portbind portbind.quix
cp -p ../fluffos_carter/bin/driver .
cp -p ../fluffos_carter/bin/addr_server .
cp -p ../fluffos_carter/bin/portbind .
./addr_server 4999 &
./driver dw.cfg &
... telnet to game, notice that I3 connects, but all commands are queued ...
... kill driver and addr_server processes ...

You see what I'm getting at here?  ZERO CHANGES to the mudlib.  ZERO CHANGES to the local_options file.  CLEAN BUILDS of the C and C++ versions.  C version works, C++ one does not.

Now, if you want to leave fixing it as an exercise to the reader, that's perfectly fine.  I'm simply trying my best to report that this is a bug, a change in behavior, between the C version of the driver and the C++ one.  If this isn't clear enough to convince you that I'm not an idiot and did indeed plug the power cord into the wall, I don't know what else to do.

[silenus]

Hi Quix,

That is really odd since there haven't been any changes to the code. I just changed fluffos to compile with a C++ compiler. I am wondering if you have checked the options to make sure they are exactly the same. I am uncertain why one would cause problems over the other. Care the speculate as to what dw does differently? I am unfamiliar with the lib.

[silenus]

I probably need to test the dw build more thoroughly- I managed to get lima to work without problems though. Or at least I can walk around the mud. I am actually quite unfamiliar with the dw lib so if you have some leads for me I would appreciate it.