| View previous topic :: View next topic |
| Author |
Message |
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
 Posted: Sun May 15, 2005 10:18 pm Post subject: |
 |
|
| NoZparker wrote: | | it is worth looking in the help file in your mirc script |
 mIRC help? Nothing to do with eggdrop, TCL or any language that makes any sense.
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
 |
Sir_Fz
Revered One
Joined: 27 Apr 2003
Posts: 3793
Location: Lebanon
|
| Posted: Mon May 16, 2005 5:34 am Post subject: |
|
|
I guess he meant that the same way you look into the mirc help files, you should look in the eggdrop help files. 
_________________
Follow me on GitHub
- Opposing
Public Tcl scripts |
|
| Back to top |
|
|
NoZparker
Voice
Joined: 16 Feb 2004
Posts: 34
|
| Posted: Mon May 16, 2005 7:09 am Post subject: self defence |
|
|
the meaning was ... eg
How do I get the bot to set differant types of bans
answer
pushmode <channel> <mode> [arg]
the [arg] can be found in mirc as in nick!ident@host or any combination thereof
_________________
It's times like this I wished I had listened to What my dad used to say. Can't say what it was I never listened. |
|
| Back to top |
|
|
Alchera
Revered One
Joined: 11 Aug 2003
Posts: 3344
Location: Ballarat Victoria, Australia
|
| Posted: Mon May 16, 2005 10:19 am Post subject: |
|
|
| NoZparker wrote: | | the [arg] can be found in mirc as in nick!ident@host or any combination thereof |
Ok but, not an analogy I would have used myself as not all use mIRC or Windows. Some of us Windows users prefer XChat (which uses TCL). 
Mask Types ... by Hobbit is an excellent resource. 
_________________
Add [SOLVED] to the thread title if your issue has been.
Search | FAQ | RTM |
|
| Back to top |
|
|
Sir_Fz
Revered One
Joined: 27 Apr 2003
Posts: 3793
Location: Lebanon
|
| Posted: Wed May 18, 2005 4:37 pm Post subject: |
|
|
If you want to search for an element in a list you can user lsearch. for example, suppose you have the following list:
| Code: | | set mylist [list "element1" "others" "yet another"] |
Now $mylist returns:
| Quote: | | element1 others {yet another} |
If you want to find 'others' in this list, try:
| Code: | | lsearch -exact $mylist others |
This will return 'other's position in the list, which is 1 (the 2nd element). you can also search for 'yet another' using the same method (yes, this is a single element in $mylist and not 2 elements)
You can also search using wildcards by using the -glob switch. example:
| Code: | | lsearch -glob $mylist yet* |
which will return 2 since it'll match the third element which is 'yet another'
NOTE: There are several other switches that can be used for lsearch, you might want to check them out at the link to lsearch (above).
_________________
Follow me on GitHub
- Opposing
Public Tcl scripts |
|
| Back to top |
|
|
Linux
Halfop
Joined: 04 Apr 2004
Posts: 71
Location: Under The Sky
|
| Posted: Fri May 20, 2005 12:01 pm Post subject: |
|
|
ERROR: invalid command name "}"
You have probably commented out a line that ends with an open curly brace.
ERROR: missing close-brace
Your braces aren't balanced. Again, one likely, though perhaps non-obvious, reason is improperly commented lines.
EXAMPLE
Sometimes people find that TCL behaves differently than they expect. for example, you have an if statement that tests a certain condition, but you want to try testing a different condition. You comment out the old condition and type a new if statement. This code will cause an error that there is a missing close-brace:
| Code: | ## WRONG CODE
if { $newflag } {
# if { $oldflag } {
puts hello
} |
Here, you have to balance the braces, for example:
| Code: | ## CORRECT CODE
if { $newflag } {
# if { $oldflag } {
puts hello
# }
} |
Another interesting point about comments in TCL is that the line continuation mechanism still applies, so:
| Code: | # This is a comment line that ends with a backslash \
and this line is still part of the comment |
(NOTE: once upon a time someone help me with this error, so... same i do copy/paste from my Logs.)
-REGARDS-
_________________
I'm an idiot, At least this one [bug] took about 5 minutes to find... |
|
| Back to top |
|
|
Sir_Fz
Revered One
Joined: 27 Apr 2003
Posts: 3793
Location: Lebanon
|
| Posted: Sun May 22, 2005 4:51 am Post subject: |
|
|
You can use the tclsh (or tclsh<version>) shell command to test your procs or to try testing some tcl-commands (not eggdrop tcl-commands though). For example, you want to learn more about regexp, so you need to do some tests to see things clearer.
| Quote: | :~$ tclsh8.4
% regexp -all a thisaaa
3
% regexp a thisaaa
1 |
for example.
_________________
Follow me on GitHub
- Opposing
Public Tcl scripts |
|
| Back to top |
|
|
demond
Revered One
Joined: 12 Jun 2004
Posts: 3073
Location: San Francisco, CA
|
| Posted: Sun May 29, 2005 3:39 pm Post subject: |
|
|
a neat one (courtesy of user) for inlining a proc to [bind] when you don't need the arguments:
| Code: |
bind time - * {putlog "hi goober";#}
|
|
|
| Back to top |
|
|
sKy
Op
Joined: 14 Apr 2005
Posts: 194
Location: Germany
|
| Posted: Tue Jun 07, 2005 8:02 pm Post subject: |
|
|
Many timers/utimers/afters will cause a high cpu usage. An really easy 'trick' to reduce it:
| Code: | if { ! [info exists ::allready_started_minute_loop] } {
set ::allready_started_minute_loop 1
call:every:minute
}
proc call:every:minute { } {
name_of_your_proc ?variables?
timer 1 [list call:every:minute]
} |
If you don`t use to many procs which you call often then you won`t need this really. I hope it`s useful here anyway.
BTW: nice theard ;) |
|
| Back to top |
|
|
demond
Revered One
Joined: 12 Jun 2004
Posts: 3073
Location: San Francisco, CA
|
| Posted: Wed Jun 08, 2005 2:45 pm Post subject: |
|
|
| I fail to see how your code reduces CPU usage - care to explain the 'trick'?; besides, using repetitively [timer] given that you have [bind time] is pointless |
|
| Back to top |
|
|
sKy
Op
Joined: 14 Apr 2005
Posts: 194
Location: Germany
|
| Posted: Wed Jun 08, 2005 9:57 pm Post subject: |
|
|
ok, that was a really bad example, many bind times don`t cause a high cpu usage fast and for 1 minute that isn`t a problem.
a extreme example:
| Code: |
proc myqueue:clearqueue { } {
# some code here
after 200 myqueue:clearqueue
}
proc my:second:queue:clearqueue { } {
# some code here
after 200 my:second:queue:clearqueue
}
|
something like that will cause a cpu usage about ~5% after 24 hour or nearly ~10% after 2 dayes botuptime!
If you have many endless loops with short repeating times you can save some cpu usage.
--
In my opinion still usefull is moretools.tcl by MC_8
http://mc.purehype.net/
and alltools.tcl which comes with the eggdrop.
I might add some 2 nice procs:
| Code: |
proc lremove { list what } {
while { [set pos [lsearch -exact $list $what]] != -1 } {
set list [lreplace $list $pos $pos]
}
return $list
}
# example:
# set list "aa bb cc"
# set list [lremove $list "bb"] will set list to "aa cc"
|
| Code: |
# Sendftp v1.01 (12/6/97) by Ernst <ernst@studbox.uni-stuttgart.de> ; # Ernst's eggdrop page: http://www.sodre.net/ernst/eggdrop/ (defunct)
# modified by soroh: only removed pingcheck portion, and changed the proc name ; in case users already had sendftp.tcl loaded, as well as aligned the code.
proc pisg_sendftp { localfile server user pass remotefile } {
if { ! [file exist $localfile] } {
putlog "pisg_sendftp: File $localfile does not exist."
return 0
}
set noftp [catch { set ftpprog [exec which ftd] } ]
if { $noftp } {
if { [file executable /usr/bin/ftp] } {
set ftpprog /usr/bin/ftp
set noftp 0
}
if { [file executable /bin/ftp] } {
set ftpprog /bin/ftp
set noftp 0
}
}
if { $noftp } {
putlog "pisg_sendftp: You don't seem to have the 'ftp' tool"
return 0
}
set pipe [open "|$ftpprog -n $server" w]
puts $pipe "user $user $pass"
puts $pipe "bin"
puts $pipe "put $localfile $remotefile"
puts $pipe "quit"
close $pipe
# putlog "pisg_sendftp: file send without error"
return 1
}
# this is a part of psig.tcl which can be found in egghelp.org script archive.
# i changed just the return code, 1 if file send sucess, otherwise 0
|
If you have other nice "tcl-webtools" let me know ;). |
|
| Back to top |
|
|
demond
Revered One
Joined: 12 Jun 2004
Posts: 3073
Location: San Francisco, CA
|
| Posted: Wed Jun 08, 2005 10:41 pm Post subject: |
|
|
| I can't imagine a situation with eggdrop where you'd want to run a proc 5 times a second ([after 200]); typical eggdrop use doesn't require such frequency, and you really shouldn't use eggdrop for millisecond precision control - eggdrop is merely an IRC bot, not a real-time OS (I still fail to grasp your rationale... where did you get those numbers?) |
|
| Back to top |
|
|
demond
Revered One
Joined: 12 Jun 2004
Posts: 3073
Location: San Francisco, CA
|
| Posted: Fri Jun 24, 2005 2:02 am Post subject: |
|
|
appending one list's elements to another:
| Code: |
eval lappend thislist $thatlist
|
However, beware of double substitution!
From Tcl's wiki:
| Quote: |
This is a short note to describe a deep "gotcha" with TCL and the standard way to handle it. Up front, TCL seems pretty straight-forward and easy to use. However, trying out some complex things will expose you to the gotcha, which is referred to as "quoting hell", "unexpected evaluation", or "just what is a TCL list?". These problems, which many very smart people have had, are indications that programmer's mental model of the TCL evaluator is incorrect. The point of this note is to sketch out the basic model, the gotcha, and the right way to think (and program) around it.
THE BASIC MODEL (courtesy of John O.)
Almost all problems can be explained with three simple rules:
- Exactly one level of substitution and/or evaluation occurs in each pass through the Tcl interpreter, no more and no less.
- Each character is scanned exactly once in each pass through the interpreter.
- Any well-formed list is also a well-formed command; if evaluated, each element of the list will become exactly one word of the command with no further substitutions.
For example, consider the following four one-line scripts:
| Code: |
set a $b
eval {set a $b}
eval "set a $b"
eval [list set a $b]
|
In the first script the set command passes through the interpreter once. It is chopped into three words, "set", "a", and the value of variable "b". No further substitutions are performed on the value of b: spaces inside b are not treated as word breaks in the "set" command, dollar-signs in the value of b don't cause variable substitution, etc.
In the second script the "set" command passes through the interpreter twice: once while parsing the "eval" command and again when "eval" passes its argument back to the Tcl interpreter for evaluation. However, the braces around the set command prevent the dollar-sign from inducing variable substitution: the argument to eval is "set a $b". So, when this command is evaluated it produces exactly the same effect as the first script.
In the third script double quotes are used instead of braces, so variable substitution occurs in the argument to eval, and this could cause unwanted effects when eval evaluates its argument. For example, if b contains the string "x y z" then the argument to eval will be "set a x y z"; when this is evaluated as a Tcl script it results in a "set" command with five words, which causes an error. The problem occurs because $b is first substituted and then re-evaluated. This double-evaluation can sometimes be used to produce interesting effects. For example, if the value of $b were "$c", then the script would set variable a to the value of variable c (i.e. indirection).
The fourth script is safe again. While parsing the "eval" command, command substitution occurs, which causes the result of the "list" command to be the second word of the "eval" command. The result of the list command will be a proper Tcl list with three elements: "set", "a", and the contents of variable b (all as one element). For example, if $b is "x y z" then the result of the "list" command will be "set a {x y z}". This is passed to "eval" as its argument, and when eval re-evaluates it the "set" command will be well-formed: by rule #3 above each element of the list becomes exactly one word of the command. Thus the fourth script produces the same effect as the first and second ones.
THE GOTCHA (observations by Brent Welch)
The basic theme to the problem is that you have an arbitrary string and want to protect it from evaluation while passing it around through scripts and perhaps in and out of C code you write. The short answer is that you must use the list command to protect the string if it originates in a TCL script, or you must use the Tcl_Merge library procedure if the string originiates in your C code. Also, avoid double quotes and use list instead so you can keep a grip on things.
|
What does this mean to eggdrop? Many scripts use [timer] and [utimer], which pass their argument to the Tcl interpreter for evaluation (albeit delayed), just like [eval] does. So if you are careless enough to write something like this:
| Code: |
utimer 10 "putkick $chan $nick $reason"
|
and someone with the nick [die] triggers it, your bot will die before even getting to kick the offender (example courtesy of spock); so, always use [list] to protect from double substitution:
| Code: |
utimer 10 [list putkick $chan $nick $reason]
|
|
|
| Back to top |
|
|
NoZparker
Voice
Joined: 16 Feb 2004
Posts: 34
|
| Posted: Thu Jun 30, 2005 7:59 am Post subject: getting out of hand |
|
|
Whilst most of these tips are damn good info and some i have used myself, they appear to be getting out of hand. and becoming so technical they are hard to follow. Can ya keep it short and sweet and an email address for more info if needed.
Now there's a tip for ya!
_________________
It's times like this I wished I had listened to What my dad used to say. Can't say what it was I never listened. |
|
| Back to top |
|
|
demond
Revered One
Joined: 12 Jun 2004
Posts: 3073
Location: San Francisco, CA
|
| Posted: Fri Jul 01, 2005 9:36 pm Post subject: |
|
|
| well maybe there should be a forum dedicated to this topic |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
