Perl Question - Returning values from parser
 

Is there a way to use a function in perl that refers to one in parser.cpp and have parser return a value to perl?

For example: quest::say(" I have $somestuff("1234")");

Have somestuff pass 1234 to a routine in parser, which does something with it and returns a value to perl, say "5678", and have perl then pass "I have 5678" to say?

One case like this is $itemcount, which I am told doesn't work. Also I was thinking it would be nice to have an $itemlink which would let you put a link to an item in a say/shout/me/emote....

I wont try to help with exposing functions, but i have not had any problems using $itemcount.

Re: Perl Question - Returning values from parser
 

None of the currently exported functions return values.

Not valid Perl. Functions aren't prefixed w/ $. Variables are never indexed w/ ().

I think that you're asking me how to write c code that you can call from perl embedded inside c code. My gut reaction is to tell you to rethink your strategy. Since you probably have some valid reason for investigating the possibility, though, I will also suggest that you look into xs. Be warned, though... writing xsubs is about as much fun as being repeatedly poked in the eye with a dirty finger.

First I've heard of it. $itemcount is just a hash (read - variable) that gets preloaded before an event_item message. Control flow doesn't change upon accessing its contents.

I can see how that could be useful. Since I'd rather be gored by 1000 flaming bulls than write xs, I'd probably look into hooking the sharedmem module directly from perl. I am under the impression that it is exactly the purpose that the sharedmem lib is meant for.

Actually, there is a better alternative. Please excuse me for taking a braindump here...

It would really pay to have a single xs method that flushes the command queue. At present when commands like say or emote or whatever are called in perl, they are stored in a command queue. When the event sub is done, the commands are executed and dequeued. Writing a single xsub to trigger the process of flushing the queue would save you from having to write a new xs for each future value-returning function in the future. To call a c function, you'd make a perl wrapper function (like the ones at the end of embparser.c) that also calls the xsub to flush the queue and passes a return value back to the caller if necessary. The code for emptying the queue is already extant in the sendcommands function, it just needs to be hooked by a xsub. As long as appropriate care is taken in handling the return values, the c function to be exported can even still be parsed in the parse_commands function, allowing it to also be used by the native parser.

Then again, maybe it isn't worth the effort. The only place I see a possible need for further functionality ATM is in DB access (possibly using eqsharedmem as a conduit). Due to bandwidth constraints, I can't run a high load server. Therefore, I can't really evaluate the efficiency of directly querying the db via a globally cached dbi::mysql conn. It is certainly possible to query/modify the db that way, though. SQL statements can even be precompiled and cached. This is certainly a workable arrangement for simple queries on low load zone servers. I can't say how well it would scale, though.

Now... back to the $itemlink thingy... I don't see why anything special needs to be done to support that. Decide the format of your function and then parse it out in sendcommands... i.e.. if(find(args.begin(), args.end(), "itemlink(")) -> do some stuff instead of passing it on to excommands.