RE: [NeoStats-Devel] Core CTCP event handling

Hi,
Its working now. Cheers.

Onto the next "challenge" then, how will we support other clients sending
the CTCP request and process the replies to all "interested" modules?

Your welcome to have a look at the code path, I was trying to keep all the
perl specific calls (ie perl library calls) contained in perl.c, otherwise
your stepping into header hell, with lots of standard c functions redefined
by perl! (hence that PERLDEFINES directive in perl.c/h)

Also, if your going to look into this, then I also have a "question".

Right now, Perl Modules can attach to other module (bots etc, like adding
commands to SecureServ) after last nights commits (not fully tested yet
though). For SecureServ's perl dat support, I had originally planned to have
the perl dat file as just a "module" in NeoStats, but it would be *nice* if
we could have perl Modules and perl extensions. Perl Extensions would just
be associated directly with that module (via mod->pm for that module) and
the module can provide any "additional" perl API's needed to access that
modules specific data (eg, for SecureServ, we can say, only kick of a scan
of a user if they pass the standard dat file checks, so we don't waste
resources on calling perl for a already killed user).

What I was thinking of doing was (using the event subsystem as a example):
In the event subsystem, adding any perl events to the module->pm struct (eg,
mod->pm->ModuleEvent), and have the event subsystem check if module->pm is
valid for each module, and if so, run though the events for the perl
"Extension" (could also be done for straight perl modules).

Timers, commands (and possible the set interface) would appear to operate ok
without any changes. The event subsystem branches off because I had to also
be able to specify the name of the perl function to call via execute_perl
(module_ptr->event_list[evt]->pe->callback) as well as the C API to the
callback (perl_event_cb)

So, if your looking into the code paths, maybe you can think how can we have
one module both as a C module as well as a Perl Extension? In turn, I can
easily add to the perl code a simple API to export "module data" to perl
extensions as well.

Finally, did you ever get perl compiled on your system. If not, send me your
config.log and src/Makefile. Perl supplies the CCFLAGS and LDFLAGS via a
built in perl extension, so either my configure check isn't working with
your setup, or your perl installation is lying about its installation! (from
your previous post, its working for CCFLAGS, but not LDFLAGS)

Thanks



> -----Original Message-----
> From: M [mailto:[email protected]] 
> Sent: Wednesday, August 31, 2005 6:42 AM
> To: [email protected]
> Subject: RE: [NeoStats-Devel] Core CTCP event handling
> 
> 
> I have made changes to the code path which should fix the 
> issue. Please test
> the latest revision to ensure it addresses it.
> 
> It does make more pertinent a concern I have had since the 
> perl support was
> added and that is the multiple code paths generated. I think 
> there is a
> stong case to remove the number of #ifdef PERL directives to 
> avoid issues
> like this one appearing that are limited to one or the other 
> code path. I
> would have looked into this eventually anyway but will make 
> the reduction of
> PERL define dependencies a higher priority now.
> 
> Mark.
>  
> 
> > -----Original Message-----
> > From: M [mailto:[email protected]] 
> > Sent: 30 August 2005 16:50
> > To: [email protected]
> > Subject: RE: [NeoStats-Devel] Core CTCP event handling
> > 
> > From a quick look all the potential skipping of the call is missing.
> > Therefore, IS_STD_MOD( module_ptr ) relies on some value 
> > being set and without Perl, always returns true which is why 
> > I have never seen the issue and it has not been reported "in 
> > the wild". With perl enabled, this macro fails for the core 
> > psuedo module since no attempt has been made to set up the 
> > value and the event is skipped. Probably lots of other little 
> > bugs will appear as well for the same reason.
> > 
> > 
> > Mark.
> > 
> > > -----Original Message-----
> > > From: Justin Hammond [mailto:justin-kLev/[email protected]]
> > > Sent: 30 August 2005 14:05
> > > To: [email protected]
> > > Subject: RE: [NeoStats-Devel] Core CTCP event handling
> > > 
> > > Attached is the debug.log file with NeoStats and 
> SecureServ loaded.
> > > 
> > > 
> > > 
> > > > -----Original Message-----
> > > > From: Justin Hammond [mailto:justin-kLev/[email protected]]
> > > > Sent: Monday, August 29, 2005 11:09 PM
> > > > To: [email protected]
> > > > Subject: RE: [NeoStats-Devel] Core CTCP event handling
> > > > 
> > > > 
> > > > I'll try to run this tomorrow, sorry, been sidetracked by a
> > > few other
> > > > tasks this last week or so.
> > > > 
> > > > > -----Original Message-----
> > > > > From: M [mailto:[email protected]]
> > > > > Sent: Wednesday, August 17, 2005 3:43 AM
> > > > > To: [email protected]
> > > > > Subject: [NeoStats-Devel] Core CTCP event handling
> > > > > 
> > > > > 
> > > > > I have added a great number of sanity checks and debug
> > > information
> > > > > to the event subsystem now so it should pretty much
> > > document itself
> > > > > as it processes an event in debug text. Anyone suffering
> > > the problem
> > > > > of the core failing to process CTCP events should 
> update to the 
> > > > > current SVN
> > > > version then run
> > > > > neostats with -fd10 and provide me with the debug.log
> > > file so I can
> > > > > try to work out where the process is failing.
> > > > > 
> > > > > Mark.
> > > > > 
> > > > > 
> > > > > 
> > > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > > To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> > > > > For additional commands, e-mail: [email protected]
> > > > > 
> > > > > 
> > > > 
> > > > 
> > > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > > To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> > > > For additional commands, e-mail: [email protected]
> > > > 
> > > > 
> > > 
> > 
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> > For additional commands, e-mail: [email protected]
> > 
> > 
> 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: devel-unsubscribe-wool9L35kifE9wlyV4mCnKxOck334EZe@public.gmane.org
> For additional commands, e-mail: [email protected]
> 
>