Perl module?

KevKev · Post by **KevKev** » Fri Dec 10, 2004 2:55 am

The case for perl is very simple.

CPAN

With CPAN somebody who knows nothing of SMTP can get a module to send email for them very simply and very easily through and objective or functional style interface.

DB Modules abound and there is a DB Abstraction module (several but one major one).

Modules to do basicly any basic task (and some not so basic).

This will make rolling scripts much faster and easier in Perl because the heavy lifting on the backend stuff is already done. You simply glue it into what you need it to do.

Post by **CrazyCat** » Fri Dec 10, 2004 4:33 am

Using perl is hard for begginners. I'd used perl to make some scripts for xchat, and I dislike it. TCL is more intuitive imho.

But I'm waiting for a VB-accepting eggdrop

Don't shot me, it was a *really bad* joke

KrzychuG · Post by **KrzychuG** » Fri Dec 10, 2004 5:47 am

Eh, i wanna corrent my mistake. Eggdrop 1.9/2.0 (if those version will be ever finished) will contain javascript module, not real java. I tried to compile new eggdrop last days (without success) and checked it this time :)

demond · Post by **demond** » Fri Dec 10, 2004 11:50 am

KevKev wrote:The case for perl is very simple.

yeah but not for the reason you think; they simply wanted to make eggdrop more scripting-language-neutral - which IMHO is unnecessary and will only make the bot more bloated; instead, they should be working on other features - say, making eggdrop a multiserver bot (my 2c only)

KevKev wrote: This will make rolling scripts much faster and easier in Perl because the heavy lifting on the backend stuff is already done. You simply glue it into what you need it to do.

not true (or, rather, that won't be the case); I don't want to start Perl vs. TCL advocacy wars here, but scripting in Perl is hardly faster & easier for most people (you may be a Perl guru and able to roll out your write-only stuff fast & easy, but that's not the case for most eggdrop users, who aren't coding geeks - and that's why TCL with its much more cleaner & leaner syntax is the obvious language of choice)

KrzychuG · Post by **KrzychuG** » Fri Dec 10, 2004 12:59 pm

Well, eggdrop will never support multiserver, shell providers doesn't like that. I think that new scripting modules are good step. You can always disable it during compilation or simply ignore don't load those modules.

Acutually there is bigger problem with eggdrop than new modules, multiserver etc. Eggdrop is developing really slow, it seems that Eggheads doesn't have time to finish current 1.7 version and work on 1.9 series.

demond · Post by **demond** » Fri Dec 10, 2004 5:44 pm

I can't imagine why would eggheads be influenced by shell providers, unless of course they have financial interests as shell providers themselves (which I very much doubt)

KrzychuG · Post by **KrzychuG** » Fri Dec 10, 2004 6:42 pm

Click

Can I connect a single Eggdrop to more than one IRC network/server?

No. Nor will such functionality be added to Eggdrop, because it creates a significant problem for commercial shell providers as well as administrators of private shells.

The number of IRC connections a bot has is a major factor in determining how taxing the process is on the provider. Additional IRC connections do two things - take up valuable I:lines on major IRC networks (which can prevent others on the same shell from connecting) and increase the risk of DoS attack against the shell by creating additional targets. Allowing a single process to have a single IRC connection keeps things manageable.

There is a bot, EnergyMech, which does have the ability to connect to multiple servers, but some shell providers have banned this bot because of this capability.

demond · Post by **demond** » Fri Dec 10, 2004 8:38 pm

well that is stated on this website, not on eggheads.org, so I'd assume it's more slennox's opinion rather than official position of eggdrop's development team; otherwise it's really pity that an open-source project needs to bow before commercial entities

demond · Post by **demond** » Fri Dec 10, 2004 9:33 pm

besides, the I:line argument doesn't hold much water... today it's trivial to limit the number of TCP connection per IP with any established firewall software (iptables, ipf, etc.)

KrzychuG · Post by **KrzychuG** » Sat Dec 11, 2004 9:05 am

I still think that multiserver feature would be a problem for providers, just ask some admins.

demond · Post by **demond** » Sat Dec 11, 2004 9:39 am

KrzychuG wrote:I still think that multiserver feature would be a problem for providers, just ask some admins.

no question about that, it's much easier to charge for processes than do proper traffic accounting, but why the f*ck should developers of free, open-source software care more about commercial providers than what users want??? (and what they'd want to implement themselves, if they really do, hehe - a multiserver eggdrop requires a *lot* of work)

anyhow, let us stop here... we're going off-topic

KrzychuG · Post by **KrzychuG** » Sat Dec 11, 2004 9:47 am

no question about that, it's much easier to charge for processes than do proper traffic accounting, but why the f*ck should developers of free, open-source software care more about commercial providers than what users want???

If they add such feature to Eggdrop, servers admin might prohibit to use it on their machines.

KevKev · Post by **KevKev** » Mon Dec 13, 2004 10:15 am

demond wrote:
KevKev wrote:The case for perl is very simple.
yeah but not for the reason you think; they simply wanted to make eggdrop more scripting-language-neutral - which IMHO is unnecessary and will only make the bot more bloated; instead, they should be working on other features - say, making eggdrop a multiserver bot (my 2c only)
KevKev wrote: This will make rolling scripts much faster and easier in Perl because the heavy lifting on the backend stuff is already done. You simply glue it into what you need it to do.
not true (or, rather, that won't be the case); I don't want to start Perl vs. TCL advocacy wars here, but scripting in Perl is hardly faster & easier for most people (you may be a Perl guru and able to roll out your write-only stuff fast & easy, but that's not the case for most eggdrop users, who aren't coding geeks - and that's why TCL with its much more cleaner & leaner syntax is the obvious language of choice)

So you think that writing a DB Abstraction layer for your own script is "Faster and Easier" than using a premade one?

Avoiding the advocacy issues. All i'm saying is that perl modules for various pices of what scripters may wish to do already exist. This will allow people to more easily create scripts for eggdrop.

in the time that it would take you to write an XML parser in TCL i can install one from CPAN and write a script to handle RSS news feeds. This makes it faster. Also can the average user write an HTTP or FTP or SFTP library for TCL? There are several of these available in CPAN. This will make developing complex scripts easier.

I know the actual goal was to make eggdrop language neutral and that is an excelent goal.

I also however think that many of you here fear the change. You have invested large amounts of time learning TCL and fear that this change could remove your status as an eggdrop scripting Guru of some sort.

I think that TCL was the best choice at the time that eggdrop was created. I do not believe that it is the best choice now. This is however a personal opinion. I am a better perl coder than TCL and i'm certain that has some bearing on my opinion.

In any case, I look forward to working with eggdrop in Perl.

demond · Post by **demond** » Mon Dec 13, 2004 10:41 am

KevKev wrote: in the time that it would take you to write an XML parser in TCL i can install one from CPAN and write a script to handle RSS news feeds. This makes it faster. Also can the average user write an HTTP or FTP or SFTP library for TCL? There are several of these available in CPAN. This will make developing complex scripts easier.

ever heard of tcllib, tclxml?

Code: Select all

#
# RSS news announcer by demond@demond.net
#
# works with either TclRSS by Tomoyasu Kobayashi (http://nul.jp/2003/tclrss),
# or rss package included with RSS Monitor by BDK, Blair Kitchen (http://wiki.tcl.tk/11184)
#
# configure it like this:  set feeds(#yourchan) {10 http://slashdot.org/slashdot.rss}
#

package require rss
package require http

namespace eval news {

variable version "rssnews 1.0"

bind time - * ::news::timer
bind pub - !read ::news::pub

putlog "$version by demond loaded"

proc timer {min hour day month year} {
	global feeds
	variable version
	if [info exists feeds] {
		foreach {chan feed} [array get feeds] {
			set chan [string tolower $chan]
			if {[lsearch -exact [string tolower [channels]] $chan] == -1} continue
			scan [join $feed] "%d %s" int feed
			if {$min != "00" && [string trimleft $min 0] % $int == 0} {
				process $chan [retrieve $feed]
			}
		}
	} else {
		putlog "$version: no configured feeds, exiting..."
		unbind time - * ::news::timer
	}
}

proc retrieve {feed} {
	set token [http::geturl $feed]
	set channel [rss::parse [http::data $token]]
	http::cleanup $token
	foreach item [$channel items] {
		set elem {}
		lappend elem [unixtime]
		lappend elem [$item title]
		lappend elem [$item link]
		lappend elem [$item description]
		lappend elem [md5 [$item description]]
		lappend res $elem
	}	
	return $res
}

proc process {chan data} {
	variable feedsdata
	set new 0
	set fetched [info exists feedsdata($chan)]
	foreach elem $data {
		if $fetched {
			set found 0
			foreach item $feedsdata($chan) {
				if {[lindex $elem 4] == [lindex $item 4]} {incr found}
			}
			if !$found {
				incr new; lappend feedsdata($chan) $elem
				if [botonchan $chan] {
					puthelp "privmsg $chan :($new) [lindex $elem 1]"
				}
			}
		} else {
			lappend feedsdata($chan) $elem
		}
	}
	if {$fetched && $new} {
		set feedsdata($chan) [lsort -decreasing -index 0 $feedsdata($chan)]
		set idx [expr [llength $feedsdata($chan)] - $new]
		set feedsdata($chan) [lreplace $feedsdata($chan) $idx end]
	}
}

proc pub {nick uhost hand chan text} {
	variable feedsdata
	if {$text == ""} {
		puthelp "notice $nick :usage: $::lastbind <#|all>"
		return
	}
	set chan [string tolower $chan]
	if [info exists feedsdata($chan)] {
		if [string equal -nocase $text "all"] {
			set num 0
			foreach item $feedsdata($chan) {
				incr num; show $nick $num $item 
			}
		} else {
			set num $text
			set len [llength $feedsdata($chan)]
			if {[string is integer $num] && ($num >= 1 && $num <= $len)} {
				show $nick $num [lindex $feedsdata($chan) [expr $num-1]]
			} else {
				puthelp "notice $nick :invalid index (must be >=1 and <=$len)"
			}
		}
	} else {
		puthelp "notice $nick :no feeds data for this channel"
	}
}

proc show {nick num item} {
	puthelp "notice $nick :title($num).........: [lindex $item 1]"
	puthelp "notice $nick :link($num)..........: [lindex $item 2]"
	puthelp "notice $nick :description($num)...: [lindex $item 3]"
}

}

KevKev · Post by **KevKev** » Thu Dec 16, 2004 5:48 am

demond wrote: ever heard of tcllib, tclxml?

I certianly have. and perhaps those weren't the best examples. I think that libtcl, tclxml, the MYSQL and Postgres module packages pale in compairison to the full volume of perl modules on cpan.

4 packages accounting for 20 or 30 various features/modules doesn't come close to the nearly 30000 modules that are housed at cpan. Perl also has the CPAN module that provides a simple and effective way to install any of them and all of thier dependancies effectively and automaticly. By my experience and by the looks of some of the questions regarding the mysql DB module, TCL takes some finageling where the libraries are concerned.