null | 2 Sep 2005 05:27

[NeoStats-Devel] [Commits] r95 - branches/3.0

Author: DNB
Date: Fri Sep  2 11:26:56 2005
New Revision: 95

Modified:
   branches/3.0/TriviaQues.c
Log:
fix more memory problems

Modified: branches/3.0/TriviaQues.c
==============================================================================
--- branches/3.0/TriviaQues.c	(original)
+++ branches/3.0/TriviaQues.c	Fri Sep  2 11:26:56 2005
 <at>  <at>  -628,7 +628,7  <at>  <at> 
 {
 	char *out, *tmpcolour, *tmpunseen, *tmpstr;
 	Questions *qe;
-	int random, i;
+	int random, i, qlen, charcount=0, tucount, tccount;

 	if (tc->curquest == NULL) 
 	{
 <at>  <at>  -658,10 +658,14  <at>  <at> 
 		strlcat(tmpunseen, "0", BUFSIZE);
 	ircsnprintf(tmpstr, BUFSIZE, "%d", tc->background);
 	strlcat(tmpunseen, tmpstr, BUFSIZE);
-	/* obscure question using definded channel colours, and send to channel */
+	/* obscure question using defined channel colours, and send to channel */
 	out = ns_calloc (BUFSIZE+1);
+	tucount = (int)strlen(tmpunseen);
(Continue reading)

M | 2 Sep 2005 21:26

RE: [NeoStats-Devel] Core CTCP event handling

Justin Hammond wrote:
> Its working now. Cheers.

Cool.

> 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)

My plan is mainly to try and remove as much of the conditional compilation
as possible from the core code so that perl.c is the only portion where we
end up with the conditional compilation. This means that the main code path
has to peform the same regardless of whether perl is enabled or not (e.g. my
change last night made the module type system apply to the core regardless
of perl support).

> 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 
(Continue reading)

null | 2 Sep 2005 22:21

[NeoStats-Devel] [Commits] r2787 - in trunk: . include modules/statserv src

Author: Mark
Date: Sat Sep  3 04:21:10 2005
New Revision: 2787

Modified:
   trunk/ChangeLog
   trunk/include/events.h
   trunk/include/neostats.h
   trunk/include/servers.h
   trunk/modules/statserv/statserv.c
   trunk/modules/statserv/version.c
   trunk/modules/statserv/version.h
   trunk/src/ctcp.c
   trunk/src/nsevents.c
   trunk/src/servers.c
   trunk/src/services.c
   trunk/src/users.c
Log:
Add broadcast forms of CTCP events

Modified: trunk/ChangeLog
==============================================================================
--- trunk/ChangeLog	(original)
+++ trunk/ChangeLog	Sat Sep  3 04:21:10 2005
 <at>  <at>  -4,6 +4,8  <at>  <at> 
 Fish (F), Mark (M), DeadNotBuried (D)
 ===============================================================================
 * NeoStats * Version 3.0.a3-dev
+ - Add broadcast forms of CTCP events so that modules can watch just their own 
+   CTCP transactions or all CTCP transactions on the network. (M)
(Continue reading)

null | 2 Sep 2005 22:25

[NeoStats-Devel] [Commits] r2788 - trunk/src

Author: Mark
Date: Sat Sep  3 04:25:37 2005
New Revision: 2788

Modified:
   trunk/src/servers.c
Log:
update server debug output to match users and channels

Modified: trunk/src/servers.c
==============================================================================
--- trunk/src/servers.c	(original)
+++ trunk/src/servers.c	Sat Sep  3 04:25:37 2005
 <at>  <at>  -249,9 +249,12  <at>  <at> 

 static int dumpserver( Client *s, void *v )
 {
-	/* Calculate uptime as uptime from server plus uptime of NeoStats */
-	time_t uptime = s->server->uptime  + ( me.now - me.ts_boot );
+	CmdParams *cmdparams;
+	time_t uptime;

+	/* Calculate uptime as uptime from server plus uptime of NeoStats */
+	uptime = s->server->uptime  + ( me.now - me.ts_boot );
+	cmdparams = ( CmdParams * ) v;
 	if( ircd_srv.protocol & PROTOCOL_B64SERVER )
 		irc_prefmsg( ns_botptr, cmdparams->source, _( "Server: %s (%s)" ), s->name, s->name64 );
 	else
null | 2 Sep 2005 22:26

[NeoStats-Devel] [Commits] r370 - branches/3.0

Author: Mark
Date: Sat Sep  3 04:26:26 2005
New Revision: 370

Modified:
   branches/3.0/SecureServ.c
Log:
changeover to broadcast form of CTCP events

Modified: branches/3.0/SecureServ.c
==============================================================================
--- branches/3.0/SecureServ.c	(original)
+++ branches/3.0/SecureServ.c	Sat Sep  3 04:26:26 2005
 <at>  <at>  -304,7 +304,7  <at>  <at> 
 	{ EVENT_CPRIVATE, 		ss_event_channelmessage},
 	{ EVENT_CNOTICE, 		ss_event_channelmessage},
 	{ EVENT_BOTKILL, 		ss_event_botkill},
-	{ EVENT_CTCPVERSIONRPL, ss_event_versionreply},	
+	{ EVENT_CTCPVERSIONRPLBC, ss_event_versionreply},	
 	{ EVENT_CTCPVERSIONREQ, ss_event_versionrequest},	
 	{ EVENT_NULL, 			NULL}
 };
Justin Hammond | 5 Sep 2005 16:46

Re: [NeoStats-Devel] Core CTCP event handling


On 03 Sep 2005, at 3:26 AM, M wrote:

> Justin Hammond wrote:
>
>> Its working now. Cheers.
>>
>
> Cool.
>
>
>> 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)
>>
>
> My plan is mainly to try and remove as much of the conditional  
> compilation
> as possible from the core code so that perl.c is the only portion  
> where we
> end up with the conditional compilation. This means that the main  
> code path
> has to peform the same regardless of whether perl is enabled or not  
> (e.g. my
(Continue reading)

M | 5 Sep 2005 22:23

RE: [NeoStats-Devel] Core CTCP event handling

Justin Hammond wrote:
> On 03 Sep 2005, at 3:26 AM, M wrote:
> > Justin Hammond wrote:
> > I don't really follow what you mean and cannot see anything in a 
> > recent commit that explains what the difference between a perl 
> > extension and a perl module is from a coding point of view
> or how one
> > is loaded and setup.
> >
> 
> Reason is that I havnt committed any code yet that makes any 
> difference between them,

I was going from your comment "Right now, Perl Modules can attach to other
module (bots etc, like adding commands to SecureServ) after last nights
commits" which I assume meant something had been committed.

> but if you follow that code path,
> you would see thats its impossible for a perl "interpreter" 
> to live inside a real module (because of the IS_STD_MOD or IS_PERL_MOD 
> macros etc.
> 
> My post above was how I was thinking about tackling the problems. My 
> question was do you see any problems, or a better way to do this?
> 
> 
> > If you just want to raise an event from NeoStats to both 
> modules and 
> > perl, then it is a trivial change to the if contructs used to issue 
> > the event in SendModuleEvent.
(Continue reading)

null | 5 Sep 2005 23:18

[NeoStats-Devel] [Commits] r371 - branches/3.0

Author: Mark
Date: Tue Sep  6 05:18:38 2005
New Revision: 371

Modified:
   branches/3.0/SecureServ.c
Log:
introduce CTCP master bot system

Modified: branches/3.0/SecureServ.c
==============================================================================
--- branches/3.0/SecureServ.c	(original)
+++ branches/3.0/SecureServ.c	Tue Sep  6 05:18:38 2005
 <at>  <at>  -128,7 +128,7  <at>  <at> 
 	"TS",
 	BOT_COMMON_HOST, 
 	"Trojan Scanning Bot",
-	BOT_FLAG_SERVICEBOT|BOT_FLAG_DEAF, 
+	BOT_FLAG_SERVICEBOT|BOT_FLAG_DEAF|BOT_FLAG_CTCPVERSIONMASTER, 
 	ss_commands, 
 	ss_settings,
 };
null | 5 Sep 2005 23:21

[NeoStats-Devel] [Commits] r2789 - in trunk: . include src

Author: Mark
Date: Tue Sep  6 05:21:52 2005
New Revision: 2789

Modified:
   trunk/ChangeLog
   trunk/include/auth.h
   trunk/include/bans.h
   trunk/include/channels.h
   trunk/include/ctcp.h
   trunk/include/modules.h
   trunk/include/neostats.h
   trunk/include/servers.h
   trunk/include/users.h
   trunk/src/auth.c
   trunk/src/bans.c
   trunk/src/bots.c
   trunk/src/channels.c
   trunk/src/ctcp.c
   trunk/src/modes.c
   trunk/src/modules.c
   trunk/src/servers.c
   trunk/src/services.c
   trunk/src/users.c
Log:
introduce CTCP master bot system and debug report tidy ups

Modified: trunk/ChangeLog
==============================================================================
--- trunk/ChangeLog	(original)
(Continue reading)

M | 6 Sep 2005 00:14

RE: [NeoStats-Devel] Core CTCP event handling

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

I have extended the event system to support a broadcast CTCP event in
addition to the standard CTCP event. The standard events will thus work as
designed and as all other client to client PRIVMSG/NOTICE processing in that
only the appropriate module will receive the event. If a module wishes to
spy on CTCP events for other processes it hooks the broadcast version. 

For the sending of the request, we need to establish a "master" bot who is
responsible for sending the request. Currently, this is the root NeoStats
bot and in a default installation where no alternative master is desirable,
this can remain the case. This would suggest the need for a module to
override the master status for issuing of version requests. To this end, a
new bot flag has been added (BOT_FLAG_CTCPVERSIONMASTER). If specified in a
botinfo structure, this bot will be used by the core as the source of ctcp
version requests during client connects.

Current commits represent a proof of concept. I will post later about the
options available to polish the process and the issues that still remain.

Mark.

Gmane