[EPIC] We need to start using the epic mailing list again
In the past few years, the use of this list has dwindled off to a small trickle, and I often don't want to disrupt the peaceful slumber of you all. So many of the conversations happen on irc, but of course not everybody is on irc at the same time so it's not optimal. I think I'm going to start encouraging people to use this mailing list more to discuss epic issues, rather than having all of these conversations on irc. I'm going to start discussions not only about epic features for which I need some guidance, but the epic website as well. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] im building an rpm for epic 5
greetings, Im working to bundle epic 5 into an RPM for Fedora Linux, and ive run across a few bugs. SMP Make does not work in the latest epic5 tar.gz source. Can this be corrected? Can you offer any advice or guidance as to how it does not work? Logfiles would be appreciated, make output, etc. Also the IP option is nonstandard for the makefile and should be DESTDIR I'm unsure how to respond to this. The IP option in the Makefile is set by --program-prefix, which was demanded by the Debian people, and isn't used for directories that I can see. I am generally unfamiliar with the DESTDIR option, although we do support --prefix and the full suite of --*dir configure options. Can you offer advise or guidance as to how DESTDIR should be supported; what configure option would set it, etc? Thanks a bunch! I look forward to being able to resolve these issues with you. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Reminder: iconv to be made mandatory now
I promised not to break anything until epic5-1.0 was released. Well now it's done, and it's time to make iconv() a mandatory dependancy. If you build epic binaries from source, you *_MUST_* have iconv() installed and if you are a package maintainer, epic *_MUST_* depend on iconv() support being installed somehow. Up until now iconv() has been an optional dependancy but this is going to change. This was all discussed and vetted on the mailing list, so there is no going back. Iconv() is critical to utf8 support, which will be the main impetus of epic5-1.2. Please let me know if you have any questions or concerns. It is expected that this cutover will happen 'real soon now'. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.9.0 released
I've released epic5-0.9.0 which is a stable candidate beta release for maybe what will become epic5-1.0. There has been a steady increase in people saying that the only thing that stops them from using epic5 is that we won't call it a production release, even though it always pretty much has been. So to make everybody happy, everyone seemed to be of one accord that we should just release what we have as production and then continue on with things. It's now available at the normal place: http://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.9.0.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.9.0.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.9.0.tar.bz2 ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.9.0.tar.gz I haven't decided what the parameters of the voting will be this time around since I assume there are a lot less epic users than there used to be, but maybe I'll be pleasantly surprised. Thanks to all who contributed their effort to get us to this point! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC5-0.9.0 released
* Jeremy Nelson [EMAIL PROTECTED] [2008-12-01 17:30]: I've released epic5-0.9.0 which is a stable candidate beta release for maybe what will become epic5-1.0. I searched the wiki, but couldn't find info about epic5 and UTF8. Does/will epic5 support UTF(8)? No -- EPIC5 does not support utf8 and won't for this release. I'm still looking for someone who has experience with utf8 support in C programs to give me help in identifying and converting all of the code that assumes that one byte == one column == one glyph to the new way of doing things in unicode. Alas, nobody has really shown any interest at all in helping, and so it awaits time for me to learn how to do it and accomplish it among all of the other things. I apologize if the tone of the previous statement seems impudent -- it's really more a sense of resignation that I have to do it all myself and people will keep asking me why it isn't done yet... Sorry... Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] I will be around North Carolina the week of Labor day...
I will be around NC the week of Labor Day, and am looking for anyone who lives around that area of the country who wants to talk about a gathering of some of us. There are no particulars yet, I'm still trying to figure out who might be interested. This is the 15th anniversary of EPIC so it might be nice to see what we can whip up. =) Thanks, Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Test #2 -- Please forgive test
Why is it every time I upgrade mailman it breaks? Why must it be so painful? Why must it have so many security problems and need updating so frequently? --J ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On reverse status bars and /set reverse_status_line
In EPIC4, we have /set reverse_status_line, which if ON prepends a ^V to your status format and if OFF does not. In EPIC5, we do not have /set reverse_status_line built in, and a ^V is unconditionally prepended to your status format. If you want a non-reverse status line, you need to start your status format with ^O, which cancels ^V. In EPIC5, we have a scripted /set reverse_status_line in 'builtins' which does the job fine, by prepending the ^O to the status format. But if the user changes their status format, the ^O might be eliminated, and then the status format goes back to reverse, and if the user /set's it ON, then the script will try to remove the ^O that isn't there. I am not in any way blaming the implementation for this problem, but I am rather conceding that perhaps this /set is more complicated than can be handled adequately by a script right now. What do people feel about restoring /set reverse_status_line as a hardcoded feature? It seemed like the right thing to do to remove it, but it's hard to get all the edge cases correct. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] New beta help files available
Many of you know about the new beta help file wiki nullie and I are setting up. He has been doing most of the editing, for which I am immensely thankful! This could not have been possible without his tireless efforts. http://epicsol.org/~help At some point the help files will be in good enough shape that we'll put them in production and they will take over http://epicsol.org/help. But for now, they're the best we have! The wiki is not editable via the web: all changes are done through cvs using a two-stage process to discourage vandalism. The cvs project is called 'wikihelp' and it's at the same CVSROOT. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Request for discussion: doubly quoted words
MAILING LIST BROKENNESS BTW, the mailing list seems to be broken since I upgraded mailman this morning, and you're receiving multiples. I apologize for this, and I'm trying to figure out what went wrong. MAILING LIST BROKENNESS Nullie write: [A modest proposal to be able to turn off support for words with spaces] It is my personal opinion (as a user, not as a coder) that support for words with spaces is important, and that it is undesirable for there not to be a single set of rules on when double quoted words are supported and when they are not. It is also unfortunate that there are some places you really wish you could turn off support for them, but you can't. Any changes we make as a part of this discussion would have to be at the language syntax level, because it's not practical to push down special flags that modify how commands interpret their argument list **yet**. But this is what got us into this problem in the first place. The need to distinguish between a string that contains deliberate double quoted words and strings that may accidentally contain them is on a per-string level, and we're talking about making global decisions. It's not practical to be able to track this kind of thing, alas. Perhaps all this is just another reason to switch to ruby. (All of these are just my opinions and are not official statements) Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] First call for defects in epic4-2.4
Since the release of epic4-2.4, only minor changes have occured: *) Fix crash when you do /nick unique-id on ircnet *) Compile time support for maildir instead of mbox *) Fix for broken file size in dcc handshakes on 64-bit sparc *) Fix build for hpux by supporting isfinite(3) alongside finite(3) These changes are minor in the big picture, but important enough to warrant a new maintainance release, which is scheduled to be epic4-2.6. I need to know if anyone else has anything that needs to be fixed in epic4-2.4 before a new release. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Epic5 and FreeBSD ports
I'm going to update the version of Epic5 in the FreeBSD ports tree to 0.2.0. I noticed that there doesn't seem to be help files available for 5. Should I include the 4.x help files or just not install anything at all? Yes. Use the epic4 help files. They are all we have for now. btw 4.2.4 has been submitted and is just waiting to be committed. Excellent. Thanks for being the maintainer! =) Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.0.7 available
It has been 6 months since the last announced release, epic5-0.0.5. This release is available at ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.7.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.7.tar.bz2 http://ftp.prbh.org/pub/epic/EPIC5-ALPHA/epic5-0.0.7.tar.gz http://ftp.prbh.org/pub/epic/EPIC5-ALPHA/epic5-0.0.7.tar.bz2 Any attempt to describe all the changes in the past 6 months would be woefully inefficient, so you should refer to the UPDATES file, and to the KNOWNBUGS file for the most gory details. Here is a (very) brief summary of the most noteworthy changes: Changes in 0.0.6: * New math parser now default, use /SET OLD_MATH_PARSER ON to go back * /SET -CREATE removed (use /addset) * /ON LEAVE changed to /ON PART * Nicknames rejections are handled by a script now * Server names without ports hunt for the first server, not port 6667 * Your startup script is loaded immediately at startup (as if you used -B) * A bunch of /set's have been re-implemented as scripts * /TIMER has been refactored and behaves more consistently. * Nickname fudging is now handled by a script * About 40 old (obsolete) scripts are removed * Case insensitive string compares now done in C way, not the irc way. * The === and !== operators in the new math parser do case sensitive compares. * /EXEC -OUT dumps to your current target (channel or query) and not just chan Changes in 0.0.7: * Asynchronous dns lookups for server connections. * A new set, /set display_mangle replaces 15 (removed) /sets * Removal of support for 7 bit only terminals (8 bit terminals required now) * All new unified string mangler/normalizer ($stripcrap(), /set display_mangle) * Automatic scrollback rebreaking when window size changes. * Highlight ignores now handled by a script * Experimental support for sending files 2gb over dcc. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] About gcc -O2 and alias safety
After doing some research, I have discovered (I think) the reason EPIC always
crashes at random if you compile it with gcc -O2. It has to do not with
bugs in epic, or bugs in gcc, but in assumptions gcc mades at -O2.
The gcc -O2 optimization level turns on strict alias optimizations. Alias
safety is a new c99 concept which essentially forbids the use of congruent
structs to write ad hoc object oriented code, which is permitted in C90. [1]
Perhaps forbid is too strong a term, but rather, the result of using these
techniques is now explicitly undefined behavior.
EPIC makes strong use of these object oriented techniques (specifically,
alists), and therefore forgoing them is not an option since they are
perfectly legitimite C90, but undefined C99. Gcc3 and 4 now seem to assume
c99 by default, unless you say otherwise, and -O2 seems to really put the
screws down to code that isn't alias safe (ie, epic).
Therefore, I propose making it official policy that epic is not compatable
with gcc -O2 because -O2 only works properly on code that conforms to C99's
rules about alias safety: epic is a c90 program and does not conform.
Comments, questions, discussion?
Jeremy
[1] Example of object oriented technique in C90, forbidden by C99:
struct s1 { int x,y; };
struct s2 { int x,y; float f };
int func (struct s2 *ptr) { ptr-x = 5; }
int main (void)
{
struct s1 *ptr;
struct s2 var;
var.x = 1;
ptr = (struct s1 *)var;
func(ptr);
printf(%d\n, var.x);
}
In C90, the results of the printf is 5. In C99, it is undefined (could be 1,
could be 5).
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
[EPIC] (important discussion) privmsg in response to a privmsg
Preface: Jm has wanted this change for a while, but has resisted my suggestions he should appeal this issue to the list (all of you). Since I do not support the request to change this, I must apologize in advance for any lack of impartiality I may have regarding this discussion. Anyone who disagrees with me, I beg and implore you to speak up now, because once the matter is settled, I want to keep it that way... - Since time immemorial, when you are inside of an /on caused by a privmsg (/on msg, /on public*, /on ctcp, etc) and you try to send a PRIVMSG (/msg, /ctcp, /redirect, etc), ircII has always (silently) changed it into a NOTICE. This behavior is implied by the wording of the irc protocol, but is not explicitly mandatory. There are various hackish ways around it, using /quote, /timer 0, etc. EPIC maintains backwards compatability with ircII in this regard, and changes your PRIVMSGs to NOTICEs because avoiding accidental message loops is one of the responsibilities a client has. Shall this feature be removed, and shall all restrictions on sending PRIVMSGs from any place for any reason be removed? I shall abide by the will of the consensus of those who participate in this discussion, and I will consider the matter closed once we reach that consensus. If there is no consensus, then I will not make any changes, but will continue to consider the matter open. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] About changing /exec -out to use /send instead of /say
So many of you know this, so bear with me: /SEND sends a message to the window's current target /SAYsends a message to the window's current channel. If you have a /query going in a window with a channel, the /query overrides the channel as the current target. This is the purpose of /say, to be able to msg a channel in a window where you have a /query going. Historically the /exec -out command has always used the /say command to redirect the output. Recently it has been requested that we switch to using /send so it can be possible to /exec -out to a query. This change will mean if you have a channel and a /query in the same window, then /exec -out will send to the query, and not the channel. This seems reasonable enough to me, but it is a break from backwards compatability, so it needs to be discussed and vetted in public. What do you all think? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On string comparisons and case insensitivity...
Historically ircII has always had two different contexts in which strings
were compared in a case insensitive way: Expressions, and wildcard patterns.
* In ircII expressions, strings are equal only if they are exactly identical,
except that case differences are forgiven:
[abc] == [ABC]
However, strings sort out case sensitively:
[BCD] [abc]
because 'B' (66) is less than 'a' (97).
* In ircII wildcard patterns, strings are handled the same way as expressions.
However, these do not take into account irc nicknames, which have their own
history. The server considers the characters [\] uppercase equivalents to
{|} by rule (rfc1459) and the characters ^ and ~ equivalent by
historical practice (but not by rule).
This means it was impossible to do string comparisons to see if some nickname
on irc was your nickname:
on ^ctcp * {
if ([$1] == N) {
}
}
But if your nickname contained any of [\]^{|}~, then the test would fail:
[foo~bar] and [foo^bar] are the same to the server, but different to ircII.
Similarly, $toupper() and $tolower() made no attempt to compensate for the
way servers do things.
--
So in EPIC3, the string comparisons were changed so they honored the server's
way of doing things. The /on ctcp above would work if your nickname contained
an unusual letter. But nothing else was changed -- particularly, regular
expressions, and $toupper() and $tolower() were not affected. This meant
you could not do this:
on ^ctcp '% $N *' {
}
if your nickname contained a weird character because only expression string
compare knew about the server way.
Today, some servers have de-supported the [\]^{|}~ characters, making them
different, rather than equivalent. This is indicated by CASEMAPPING=ascii
or similar. On these servers, [foo^bar] and [foo~bar] are DIFFERENT
nicknames, instead of the same nickname.
Why is this important? If someone with the nickname [foo^bar] is on a
channel and someone else with [foo~bar] joins the channel, epic is going to
get mighty confused doing userhost caching because those are the same nick.
-
So what to do? Should we just desupport the [\]^{|}~ characters in epic5,
because that is the way things are going, and it is easier? Should we make
some sort of half-hearted attempt to try to figure out whether [\]^ should
be the same as {|}~ or not, on the fly?
What about regular expressions? What about $toupper() and $tolower()?
I could use some advice and suggestions.
Jeremy
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Regarding curses, and mandatory dependancies
Are you going to continue support for EPIC4 for those that don't want and/or need a curses interface? EPIC4 is a finished project and only severe bug fixes will ever be made to it from this time forward. It will not be ported to curses. What sort of upgrade path would users have from EPIC5 - EPIC5 w/ curses? Reinstall or some other magic glue? If all goes well, the upgrade will only require re-running configure and everything will Just Work(tm). If you don't have a sysv curses installed (like ncurses), then configure won't work, and then you'd know you need to install ncurses to continue. I can always add a note to that effect in the configure script... Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Regarding curses, and mandatory dependancies
Well, I was going to have to bring this issue up at some point, and so it might as well be now. Up throughout its lifetime, epic has never had any mandatory dependancies, which just means another piece of software that absolutely must be installed before epic will build. EPIC has many optional dependancies (perl, tcl, socks, ssl, and so on), but you're not required to take them. But now I am at a place where it seems to really move forward with the interface, it is necessary to make epic a curses program, particularly to use libpanel[1]. This makes a dependance on sysv curses (ncurses) a mandatory dependance. This is a big step. How do you all feel about making curses a mandatory dependancy for epic5? System V Curses (ncurses) is a very widely deployed, but not necessarily universally available thing. Jeremy [1] libpanel is a library wrapper on top of sysv curses that implements a 3-dimensional multiple document interface (mdi). ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] [RFD] On loading startup scripts before connecting...
Historically, ircII clients have loaded your startup script (~/.ircrc) after you make your first connection to the server. This has been to permit you to change usermode, join channels, create windows, etc, in your startup script, all of which you can't really do before you connect. EPIC has the -B command line option which permits you to load your startup script at boot time, and not at connect time. If you want to do some action at connect time with the -B command line option, you use /on connect. In EPIC5, we have been scripting a great deal of functionality that used to be hardcoded into the client. Unless you use the -B command line option, these features are not available to you until you connect. This is become more of a problem. Thus, it is necessary to discuss whether the -B option should become the default (that ~/.ircrc always be loaded at boot time, rather than at connect time), and a new command line option be added to turn that off. Please share how you feel about this change. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.0.4 now available
EPIC5-0.0.4 is now available. This is the fourth alpha release of EPIC5, the day after it's 15th month birthday. ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic4-0.0.4.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic4-0.0.4.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic4-0.0.4.tar.gz http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic4-0.0.4.tar.bz2 In this release the following things are noteworthy: * ### IMPORTANT ### global is no longer loaded automatically if you have an ~/.epicrc or ~/.ircrc file (or you use the -l command line option, or set the IRCRC or EPICRC environment variable, or in any way have epic load a file at startup). You must make a one-time change by adding 'load global' to the stop of your startup script, if you want to continue to load global by default * Entirely rewritten i/o subsystem, which is generalized. To prove that I really mean it this time, there are implementations for select(), poll(), freebsd's kqueue(), and pthreads, all of which have been tested to some extent or another. This is controlled by a new configure option (./configure --with-multiplex=val). The default is always select() unless you choose another. * Each server automatically gets an alternate name when you create it. This first altname is what would appear in the status bar for the %S expando. The %S expando has been changed to use this first altname. This means if you change the altnames, you can change %S! * There is a 'save' script which implements /save. You can just do /load save, then /save is back! * Error messages in the I/O subsystem may generate multiple errors over multiple lines. Some of you will probably find this annoying, and you can suppress them with /on yell if you want to. There are other changes, documented in UPDATES, but these are the most important ones that are user-visible. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Review and housecleaning of default loaded scripts in epic5.
The default scripts that are loaded when you start up epic are specifically global, and your ~/.epicrc. You can do /WHICH filename to see where these files are if you don't know. Now global loads 2.8script basical builtins local These scripts have not changed much in the past 10 years, and I'm starting to get more and more push-back from scripters who say they are getting in the way, and from users who tell me some of the features are implemented badly. To start off this discussion, I have commented out a swath of oper-only stuff in the 2.8script script. This is stuff that I doubt anyone will notice or miss, because I seriously doubt it even works. What I would like from you all, is your patient review of the scripts that are loaded by epic, and comments upon what things you are quite sure are not worth keeping. Telling me that none of it is worth keeping is not the kind of helpful feedback I am hoping for. Something more along the lines of The handler for /on 210 is not useful because it assumes a format that hasn't been used since irc2.8.20. I also need to know which features that are in these scripts you are using on a regular basis. If nobody seems interested in these scripts, then many of these features may be revised, or excised, to reduce cruftiness. A lack of feedback will tell me that people don't really have a lot of emotional investment in these scripts, and that it will be ok for me to reduce cruft by eliminating features that probably don't work. Then the ball will be put back into your court to object about the changes after the fact. In absolutely no case will any of these changes be made to epic4. EPIC4 is done, finished, completed, end-of-lined, and will not be changed. This discussion is strictly for epic5. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5 testers requested
EPIC5 is getting rather stable, and EPIC5-0.0.3 is almost ready for release, so I could use a few hard core people who are interested in testing this before it goes out. I just added a $symbolctl(), so it would be useful if any scripters who wanted to play around with it would give me practical feedback (ie, is it actually useful?) before we get too far. The code is in CVS, so drop by either of the two #epic's (efnet, or the private irc.acronet.net server) if you want to discuss anything. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Need freebsd ports commiter to upgrade epic4 port
Because our previous freebsd epic4 maintainer [EMAIL PROTECTED] was cleared because the email address bounces, we don't have a maintainer, and Jeremy Chadwick has updated the port with ports/75707. If you are on this list and are a freebsd ports commiter, would you be willing to facilitate this pr for us? Thank you very much, Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-2.2 now available
I am happy to announce the release of the third production version of EPIC4, epic4-2.2, now available at the following locations: ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.2.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.2.tar.bz2 This is a maintainance release for epic4-2.0, from which you will probably want to upgrade only as your script requires it. The only end-user-visible changes are support for the 0 nickname on ircnet, and +e and +I channel modes (particularly for efnet). There are other user- visible changes, but they're mostly of interest to scripters, and are explained in the UPDATES and KNOWNBUGS file. This is (hopefully) the end of the line for epic4. Jeremy Nelson EPIC Software Labs ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-2.2 passes vote of confidence!
EPIC4-2.1.1 (as amended, nee epic4-2.1.3) has been accepted as a production release of epic4, to be released as epic4-2.2! There is a final 72 hour final countdown period during which you may try the very last cvs commit, and file any last minute objections. THIS IS YOUR ABSOLUTELY VERY LAST OPPORTUNITY TO TEST BEFORE RELEASE. IF YOU KNOW OF ANY BUGS TO BE FIXED, NOW IS THE TIME TO REPORT THEM. More updates as events warrant. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] New EPIC! Vote update
I have had a request for 5 material changes for epic4-2.1.3 ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.3.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.3.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.3.tar.gz http://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.3.tar.bz2 * Fix wording of default messages for 347 and 349 numerics. (Requested by blackjac -- 347 and 349 numerics are not bans, so do not say end of ban list) * Fix column alignment for /timer list. (Requested by blackjac -- /TIMER's list got messed up due to some brain damage on my part. * Fix add_to_window() to stop runaway recursion through /set output_rewrite. (Requested by Larne, who rules because he also wrote a patch to fix the problem! Go Larne! -- It's possible to trick /set output_rewrite into infinitely recursion, which crashes epic. It will try hard not to allow that now.) * Fix bug in expand_alias() -- all output must be privileged_yell()! (Found fixing the above bug, expand_alias() can do a put_it(), which can induce an infinite recursion problem in add_to_window(). All output in expand_alias() is required to be a privileged_yell(), so fix this.) * Change /on send_to_server so it can't be hooked recursively. (Requested by jm -- All of the other /on send_* hooks are non- recursive, meaning you don't have to worry about them infinitely recursing if you don't change the text enough to not match the same /on again. It's very dangerous for /on send_to_server to be used because of this, and changing it just makes more sense.) OF ALL OF THESE, the last one is the one that may be most noticed. If you want to object to anything, please let me know! The vote is currently 13-0. I'm not going to restart the vote for these 5 changes, because I think people would kill me. So if you voted yes, then please test, and change your vote if you don't like the new changes! Once the vote reaches 15-0, there will be an announcement to the list with further instructions. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] What is a space? And who is using a non-C locale?
So one of the things that has come up during the epic4 vote is how spaces are handled inconsistently throughout epic. I had originally intended to address this in epic5, but it looks like this is a real problem for /xdebug extractw users. In the C locale, characters 9 (^I), 10 (^J), 11 (^K), 12 (^L), 13 (^M), and 32 (space) are considered spaces. That means isspace(x) returns 1 for any x = one of those characters, and 0 for everything else. EPIC has three ways to determine spaces 1) Use the system's isspace(), which could be locale dependant. 2) Use epic's my_isspace() which behaves exactly the same as isspace() does in the C locale. 3) Just compare the character against character 32 (space). It would be best if we just had one way, because that would be less confusing. But this is a problem because in some places in epic, a tab is a space, and in other places, it isn't. So if I just switch everything to use isspace(), then some scripts might break in ways that I can't anticipate. I have two questions: *) Are any of you using tabs, newlines, carriage returns, etc, in any way that depends on them not being a space character in some context? If you are, you need to be a participant in this discussion! *) Are any of you using a non-C locale? (If you don't know, then you are not) Does your locale have a different set of space characters? Feedback for these two questions is greatly appreciated and may reduce near term pain and suffering. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-2.1.1 call for votes still 3-0
This is a periodic update on the status of the ongoing election as to whether epic4-2.1.1 should be accepted as a production release epic4-2.2. The current status is 3 votes in favor and 0 votes against. The election shall be open until it reaches 15-0, however long that takes. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC Release Candidate avialable
I have prepared an epic4 production release candidate. It is available at: ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.1.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-2.1.1.tar.bz2 Soon there will be a call for votes of confidence, and a formal vote will occur on whether to accept epic4-2.1.1 as the production release epic4-2.2. More details as we get further along in the process. Obviously, if you find any bugs or anything needing fixing in epic4-2.1.1, you would do well to report it immediately. Thanks Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC 10th annivesary party -- Sepetember 18th evening, Boston
Then we shall create MORE noise :) .. either way I havent been to kendal in ages. From the looks of the final confirmations, it looks like the party might be quite on the small side. So perhaps this Redbones place is fine. THIS IS THE TIME TO TELL ME IF YOU'RE GOING TO COME OR NOT. I need to get contact information so I can call people and we can make final plans. I'll post a summary of attendees, location, time, etc, when I get that information. If you would like to come but need transporation, let me know and I'll see if I can scare up someone coming form your direction. If anyone would like to come, but can't, and would like me to drop by and visit you during the week afterwards, EMAIL ME and I'll try to set up meetgreets with any interested persons. =) Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Request for comments: function name resolution change
This is a change that is proposed for epic5. Nothing will change for epic4 based on this discussion. Historically, if you have an alias with the same name as a builtin command, then: /fooruns your alias //foo runs the built in command If you have an alias with the same name as a built in function then: $foo() runs the built in function There is no way to run your alias. This means that your alias is hidden by the built in function. In EPIC5, if you have an alias with the same name as a built in function then: $:foo() runs your alias $::foo()runs the built in function. The question then is what shall $foo() do? Shall it run your alias, or shall it run the built in function? Presently, at this moment in time, for backwards compatability, it runs the built in function. However, it would seem more sensible to make it behave like commands do, and have it run your alias. HOWEVER, this breaks backwards compatability because some people have created aliases, by the same name as built in functions, with the expectation that their alias will never be called as a function! This will break scripts, but perhaps this is a good change. According to epic policy, no change like this can take place, no matter how good it is, without a vetting by the mailing list. So please make your opinion known! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC 10th annivesary party -- Sepetember 18th evening, Boston
There have been about 10 or 15 people who have expressed an interest in meeting together in the afternoon or evening of September 18th in Boston for a celebration of 10 years of epic. Now all we need is to pick a place and start making plans to be there. I need someone who is familiar with the boston area to tell me a real nice place to hold a gathering of this size, where a bunch of people coming from different directions have reasonable ability to get to, etc. Since it's only 3 saturdays away, we need to have time to get people the information. So I'm begging you Boston people, tell me where we should meet! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] What to load at startup?
There has been discussions going on about what things should be loaded by epic at startup. Traditionally, ircII has loaded 2.8script sets up a bunch of /ons for /trace, /links, and /stats, as well as a /topic and /invite alias. extensions creates the 'umode', 'dmesg', and 'dquery' aliases, and loads the 'newaway' script which implements a /set show_away_once work-alike version sets /set client_information local This is configurable by the user and optionally 'basical' but not by default EPIC loads builtins an epic4 compatability script that implements a bunch of aliases that were built in commands in epic4. 2.8script the smart join and smart leave alises, an /on send_public compat hook, the /trace, /links, and /stats handlers from ircII. Some compat stuff for efnet/ircnet stuff. local This is configurable by the user and basical This is a compat script with ircI, with a bunch of shorthand aliases that people just assume are part of epic. It also sets the first window's name to ircII, It also sets up some compat /on set's. There are three proposals that have been made: 1) Create a new command line option that supresses loading 'global' 2) Make the -q command line option suppress loading 'global' 3) Don't load 'basical' from 'global', because ircII doesn't do it And other proposals can probably be made. Which change should be made, or should no change be made? Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] [EPIC4] LAST CALL FOR BUG REPORTS IN EPIC4
THIS is your last opportunity to report bugs in epic4 and have them fixed before the release candidate. If you reported the bug to me on irc, that is not good enough -- i do not remember that. Please email me, and make sure you get an acknowledgement of your bug! If you test the release candidate and notice a bug is not fixed that I should know about, please report it at that time as well! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Send bug reports to jnelson@acronet.net
(Anyone who knows sendmail want to tell me how to make this machine send my email as [EMAIL PROTECTED] instead of [EMAIL PROTECTED]?) Send bug reports to [EMAIL PROTECTED] since sending email to zeus.acronet.net will be dropped by the firewall. doh! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Upcoming maintainance bug-fix EPIC4 release
According to the schedule which we have been following, a new EPIC4 production release is scheduled to be released after 6 months to fix any minor problems in epic4-2.0; or whenever a critical show-stopper bug is found; whichever comes first. The latter has not yet happened, but there have been several of the former. It's been 5 months, so that gives us a month to collect all of the nits we'd like to pick with epic4-2.0, submit them to me, and I'll try to fix whatever I can, and we'll start a new voting cycle. I would prefer that everybody be decent about this, and only report the things that are really minor problems. Things that are too big should really be handled as an epic5 project. Here are examples of things which have come up: * Crash using TOGGLE_STOP_SCREEN (^S) when hardware flow control is off. * $stripcrap(ALL,-BOLD) incorrectly mangles bold * Not able to bind the 255 character. * /SET INDENT fails when indentation level is 1/3 of the screen width there are other such things that are minor, that people have asked me to fix. If you know of any such problems, start collecting them, and forward them onto me. When I have everybody's REPORTED problems fixed, I'll submit a release candidate and issue a call for votes of confidence. When that vote passes, we'll have a production maintainance release. Jeremy P.S. Anyone who was foolish enough to participate in a betting pool on when the next production release would be was clearly not paying enough attention when I said 6 months or first critical bug, whichever comes first a zillion times :P ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Please forgive the test post
Apparantly my latest upgrade of mailman broke things (again) Anyone know of a decent mailing list software that doesn't break each time you upgrade? Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC 10th Anniversary Party Official Announcement
The exactly founding date of the EPIC Project is uncertain, for various reasons. However, I do recall quite clearly that it was founded near the beginning of the 1994-1995 school year. So for all intents and purposes, it's good enough to say September 1994. We approach the 10th anniversary. After having talked with many people, and having reviewed my own vacation plans, it seems that it should be possible to organize a 10th anniversary party for EPIC on Saturday, September 18th, 2004, in the Boston, MA area. The time of day (afternoon or evening), and exactly location are as yet undetermined. Suggestions are welcome. If you, or anyone you know, are interested in attending this party, maybe it would be best if we set up either a mailing list, or somehow formed a planning party to flesh out a few details. Everyone who is interested should consider themselves invited. I don't see any reason to have restrictions on who should be welcoem at this kind of a party. If you think you might be willing to attend, just drop me an email with how many people will be coming with you, and I'll use this to ballpark the crowd size. Planning for 10 is a lot different than planning for 25! ;-) Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC 10th Anniversary Party Official Announcement
Sorry -- email to me should go to [EMAIL PROTECTED] I realized that my email address was [EMAIL PROTECTED] which can't accept email directly. I apologize for this. I'll look into fixing this going forward. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC 10th anniversary party
There will be an EPIC 10th anniversary celebration in September in Boston. Tentatively for now, the date is penciled in as Saturday September 18th. If you are interested in being included in the planning of this event throughout the summer, let me know one of these weeks and everyone who wants can help figure out things like how people will get there, where everyone will stay, that sort of thing. I'll be flying in for the event, so you'll have to put up with me. :P Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Official position statement on further epic4-2.0.* releases
Because I am always rather vague and evasive when it comes down to people pressing me for particular details about new releases, (I don't like to commit to dates and features because people have a nasty habit of holding you to your promises... ;-) there has been some confusion about just when and what would be in an epic4-2.0.1 release. So this is my official position statement on the issue, and I don't suspect I'll change my mind going forward. I have always divided bug reports into one of three general categories, in increasing severity: 1) Bugs which can be worked around, either because the bug is caused by doing something that isn't sensible, or there are multiple ways to do some task and one of them is broken but the others work fine. 2) Bugs which cannot be worked around, because there's only one way to do some task and it's broken. 3) Bugs which cannot be worked around, because some external force which you do not have control over can cause a malfunction. EPIC4-2.0 has several type 1 malfunctions which have been reported. However, they can all be worked around, so nobody is really put out by their existance, although they do represent rough edges that people need to be careful about. There are no type 2 or type 3 malfunctions in epic4-2.0 that anyone has reported yet. Fixes for type 1 malfunctions will be made immediately to epic5 and not backported to epic4. EXCEPT -- if someone reports a type 2 or type 3 bug in epic4, then it will be necessary to release epic4-2.0.1 to fix that bug, and I'll probably include fixes for other (type 1) fixes at that time. You can feel free to report bugs in epic4, and I'll keep a list, but please do not expect me to release an epic4-2.0.1 unless a really super critical bug is found, and the bar for that is rather high. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.0.2 now available
EPIC5-0.0.2 is now available at: ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.3.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.3.tar.bz2 This release contains the following *significant* changes: * ALL CONNECT()S ARE NONBLOCKING. EVERY LAST ONE OF THEM. Yes, even DCC connections are nonblocking. Yes, even $connect() is nonblocking. This may require changes to your script. See UPDATES for more info. * AUTO-RECONNECT AND AUTO-REJOIN-ON-RECONNECT ARE GONE. It will be necessary for someone to write a standard script to implement the old behavior for us. At least for now, when you are disconnected from a server, you stay disconnected forever until you /reconnect. Your channels are never rejoined after a reconnection in any case, unless you write a script to do that for you. * YOU CAN NO LONGER BIND CHANNELS TO WINDOWS. Because the window bind feature was an implicit part of the auto-join-on-reconnect feature, and without that latter feature the former feature is pointless. * BUT YOU CAN NOW JOIN MULTIPLE CHANNELS IN A WINDOW SIMULTANEOUSLY, so this should make the loss of window bind extremely moot. * THE SERVER COMMAND HAS SIGNIFICANTLY CHANGED. See the UPDATES file for more info. Example: If you do /SERVER +, it stays within the server group instead of going to the next numbered server. * THE HELP COMMAND IS NO LONGER A BUILT IN COMMAND but is now handled by a script written by howl and is loaded automatically. If you do not load the standard epic scripts on startup, then you will want to /load help in your startup file to get the /help command. * /WINDOW QUERY HAS CHANGED AND YOU CAN HAVE MULTIPLE QUERIES PER WINDOW, but obviously only one of them is active at a time. There is a new key binding SWITCH_QUERY to switch between them. See the UPDATES file. And the following less significant changes: * There is a new /on server_status that notifies you when a server changes its connection state. This should be useful for tracking auto reconnects and auto rejoins and stuff for scripters. * You can use /xdebug server_connect to watch the client at work. * Internally, all wildcard patterns in /ON are converted to regexes, compiled, and then matched as regexes * Usermodes are now treated fully as strings instead of bit masks, so all usermodes supported by the server are supported by the client. * Your startup file (~/.epicrc or ~/.ircrc) is now loaded on the 001 numeric, and the client is much less picky about the layout of that numeric. This should help compatability with more unusual servers. * There is experimental support for FreeBSD's kqueue() system. * There are now 6 new USERnum levels for a total of 10. IE, USER5, USER6, USER7, USER8, USER9, and USER10. * All ctcp requests are hooked through /on ctcp_request, even the ones the client does not ordinarily know about. * You can bind the 255 character (ÿ), which will make our Russian friends very hapy. And there are many other changes that I have not mentioned here, please see the UPDATES file for all of the gory details! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Test #6 -- Please excuse test
This is just a test. I have upgraded mailman on epicsol. If you recieve this email, then everything is going well. If you try to send an email to the list in the future and it bounces or otherwise fails, then please let me know right away. Mailman is not my favorite piece of software... Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC ftp site reorganized and other news
Since epic4-2.0 seems to be a real winner, I have moved all of the old epic4 alpha and beta releases to the epic archive, and have symlinked EPIC4-BETA and EPIC4-ALPHA to the archive so things like the freebsd port will still continue to work. Those who are mirroring /pub/epic will notice a bunch of files have gone away. The FTP site is now only about 6 megs, which should be much less of a burden on you than before. Those of you who are responsible for ports or packages, should please feel free to upgrade your packages to epic4-2.0 as soon as practicable. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] I want to change CRAP to OTHER in epic5
So my proposal is when you do things like /window level you'll get *** Window level is OTHER PUBLIC MSGS NOTICES WALLS WALLOPS NOTES OPNOTES +SNOTES ACTIONS CTCP USERLOG1 USERLOG2 USERLOG3 USERLOG4 instead of *** Window level is CRAP PUBLIC MSGS NOTICES WALLS WALLOPS NOTES OPNOTES +SNOTES ACTIONS CTCP USERLOG1 USERLOG2 USERLOG3 USERLOG4 but you can still do /window level crap and it'll be supported for backwards compatability. It'll just show up as other on output. Objections? Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Users may now submit news to/via the epicsol website
People have suggested that it would be helpful to allow people to write content for the epicsol.org website, but that there is no obviously way to submit the content so it can show up on the home page. So Keerf has graciously created a submit news url where you can submit a news blurb, or a url to a script tutorial you wrote ;-) or whatever else you think should be made known on the epic home page. Now if something is missing or incorrect, you don't have to be unhappy that there is no way to fix it, now you can report the issue directly! The URL is: http://prbh.org/?page=submitnews Enjoy! ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC](no subject)
Greetings to the epic community. I am pleased to announce the immediately availability of EPIC4-2.0. It is currently available at the following locations: ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.0.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.0.tar.bz2 I wish to thank everybody who helped make this possible. If you wish to review the changes made to EPIC4 from the very beginning, use: http://www.epicsol.org/CHANGELOG User-visible changes are at: http://www.epicsol.org/UPDATES hop, Crazyed, wd, and keerf ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-2.0 now available
Sorry about the repost, I forgot to put on the subject line in the previous email and that was kind of an important detail. Greetings to the epic community. I am pleased to announce the immediately availability of EPIC4-2.0. It is currently available at the following locations: ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.0.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.0.tar.bz2 I wish to thank everybody who helped make this possible. If you wish to review the changes made to EPIC4 from the very beginning, use: http://www.epicsol.org/CHANGELOG User-visible changes are at: http://www.epicsol.org/UPDATES hop, Crazyed, wd, and keerf ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC Gathering, Thursday or Friday night?
Is there anyone in the chicagoland area thursday or friday night (2/19,2/20) would would be interested in gathering to celebrate the release of epic4-2.0? Depending on if anyone even /wants/ to do this, we'll try to figure out a time and a place. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] epic4-1.2.9 now available
The (hopefully) final beta release is now available. This release fixes all of the objections lodged against prior beta releases. The vote is currently 10-0 with three holds (holds are agreements I have reached with certain people not to release until they vote). Please test, and if you haven't voted, vote! ;-) ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.9.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.9.tar.bz2 Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Amendments to Release Candidate 1 available
|Rain| filed an objection to RC1 and his objection was upheld and his proposed changes were applied as amendments to RC1. I fixed a couple of other benign compiler warnings (ie, no program changes) since we made other changes. The whole thing is now available: ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.8.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.8.tar.bz2 (And this time I remembered to change $V. ;-) The vote is not going to restart -- all the votes already cast are still valid and will be considered to apply to these changes. Anyone who has voted who wishes to change their mind and vote NO is welcome to do so. The current election results are 4 votes aye and 1 vote nay. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]First Call for Votes of Confidence in EPIC4-2.0
* The candidate release was made available on January 19, 2004 * A request for a vote of confidence was made by archon on January 22, 2004 * The election will continue until completed, but in no case will it end before January 25, 2004. * The release will occur 2 days after the election ends, but in no case will it occur before January 27, 2004. *** ** OFFICIAL BALLOT *** Please read *all* of the instructions before submitting this ballot! BALLOTS CAST AFTER THE ELECTION IS OVER WILL BE DISCARDED. RATIONALE: -- It is a long standing practice of mine to avoid the appearance of despotism. Although I could ultimately claim authority to decide just when to make a production EPIC release, I do not choose to do so. Instead, I defer this decision to you, the user community. It is my distinct honor and privelege to be a steward of the EPIC software, and I am humbled by the number of people who choose to use EPIC. It is only through the use, testing, bug reporting, and feedback of you users that creates the EPIC community, the community that fosters and grows the EPIC software through its wishes and designs. I could not, and would not, do all this work without you all. From time to time, the EPIC software reaches a point where it appears to be substantially bug free, and it has all of the major features that people want, and a breaking point can be reached. After all of the I's have been dotted and T's have been crossed, I submit a candidate release and say to you, I think this is worthy of production use. Do you agree with me? I am generally unwilling to release a production version of EPIC without a clear and unambiguous mandate from the EPIC user community. This mandate is gauged through a Vote of Confidence. You now have the opportunity to tell me, and the world, that you feel that this candidate release is worthy of being called a production EPIC client, or that it is not worthy. It is not up to me, but up to you, to make that determination. If 15 of you agree with me that it is worthy, and if none of you disagree, then I am willing to stake the good reputation of the EPIC project on this. Because of the rarity of production releases of EPIC (this is the sixth one, the others being EPIC, EPIC2, EPIC3, EPIC3.004, and EPIC4-1.0), it is very important that our production releases really be of the highest quality and enduring usefulness. There is no better way for us to destroy the good name of EPIC than by shipping a shoddy production release. THEREFORE: -- Let it be known, that a candidate release of EPIC has been submitted by EPIC Software Labs for consideration by The EPIC Project for acceptance as the second production version of the ircII-EPIC4 software. Whereas the candidate release, being known as: EPIC4-1.2.7 and being made available at: ftp://ftp.epicsol.org/pub/epic/EPIC4/EPIC4-BETA/epic4-1.2.7.tar.gz shall be tested for satisfaction of the goals of The EPIC Project, as defined by the desires of its members. THEREFORE: - You are requested to test the above version of EPIC and to submit a vote of confidence, voting either yes or no as to whether or not you accept the above candidate release, possibly with modifications, as a production release of the ircII-EPIC software. VOTING PROCEDURES: -- Please fill out the following ballot, removing everything else in this email, and email the vote of confidence or official objection to: [EMAIL PROTECTED] * Please remember to include all of the required information so that your ballot will not be disqualified. * Disqualified ballots will be sent back to the originator for correction. * You are welcome to re-submit disqualified ballots once you fix them. * Fifteen votes of confidence are required to pass this election. * Zero official objections are required to pass this election. * You may change your vote by submitting a new ballot. Your last ballot will be considered your official ballot. * Official objections must be filed using this mechanism. Telling me about a bug you found on #epic on efnet is not sufficient. I need specific written documentation. * The purpose of this election is to gague user confidence in the software that I am preparing to release on behalf of the project (ie, you all). I am the final judge in all voting matters, with the stated prejudice that if there is any question of any problems, I err on the side of not releasing the software until all concerns have been addressed. * Nicknames are ok for the Name field, if you're absolutely set against giving your real name. BALLOT: --- All information is required. Ballots with missing information cannot be honored, sorry.
[EPIC] Release candidate 1 is now available
Release candidate 1 (for epic4-2.0) is now available at: ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.7.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.7.tar.bz2 This is the final version of the software (barring any last minute bug fixes), and this release, plus any amendments thereunto, will be the final epic4-2.0 release. You may now test this release candidate for any bugs. There will be a 72 hour waiting period after this release before a motion to hold a vote of confidence will be accepted. After the motion is made, a Poll of Vote of Confidence will be sent to this mailing list. In that poll, you will be asked whether or not you have personally tested the release candidate, and whether you have found it to be materially defect free as far as you know of. If you find any material defects, you are strongly urged to file an objection to the vote of confidence, and there will not be an epic4-2.0 release until you are satisfied. The vote of confidence will stay open until 15 people vote yes that the release candidate is defect free, and 0 people vote no, or until 72 hours pass, whichever takes longer. After that, there will be a 48 hour waiting period for people to get one last chance to test stuff. After that, epic4-2.0 will be released. If you have any questions, come drop by #epic on efnet or irc.acronet.net, or send me an email. Thanks. Jeremy Nelson ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-1.2.3 now available, details on the election.
ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.3.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-BETA/epic4-1.2.3.tar.bz2 In accordance with my stated intent to frequently release beta snapshots to give everyone the chance to stay current with changes in the release candidates, epic4-1.2.3 is now available. This version fixes the -o and -O command line options, fixes a small number of bugs, and adds a $numlines() function from fudd. THE ELECTION BEGINS ON MONDAY -- If there are no more changes between now and monday, then 1.2.3 will be the release candidate. If there are more changes, then 1.2.4 will be released on monday and that will be the elected candidate. Let me briefly run down the purpose and history of the election... As everyone knows, epic versions are released whenever i feel like it, and they are of whatever quality they are. But I do not want to be a dictator or tyrant, and the quality of formal production releases of epic reflects on everybody, not just on its maintainers. Because EPIC has had a prior history of rather low-quality releases, production releases are no longer a common occurrance, and the process for generating one is a long and painstaking process. We've been working for about 3 months now to get epic4-2.0 ready, and we're almost there. But before I am willing to stake all of our reptuations on the line releasing epic4-2.0, I want backup support. Specifically, I want a large number of people to publicly state before me and their peers that they tested epic and they do not know of any bugs. The definition of large number has changed over the years, from 5 to 15 people. If I cannot find a large number of people who are willing to make this proclamation of non-buggy, then I am entirely unwilling to make a production release. Even *one* bug will hold up the release. So each person gets veto power and any legitimite bug will either be fixed, addressed, or clearly disclosed and documented as a problem. I do not want to release epic4-2.0 if even one person has a serious problem with it. The purpose of the election is twofold -- it allows any epic user who wants to, to make a declaration that they have tested epic and they do not know of ANY problems that they think should be addressed; and it allows those who do have problems a way to formally assert those problems in a manner which is guaranteed to spur immediate action. The election will begin at least 24 hours after the last release candidate is made publicly available. This is expected to be 1200 (noon) UTC on Monday December 8, 2003. The election will last until 24 hours have passed after there are both 15 yes votes and 0 no votes. In no case will the election end before 72 hours. This gives everybody at least 4 days to test, and a full 24 hours after the election passes to lodge any objections. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]EPIC4-1.1.15 now available
We have been going through a recent project to identify and address any issues left in epic4-1.1.*, with a mind towards a feature freeze and then a stabilization and then a certification and production release. ftp://ftp.epicsol.org/pub/epic/EPIC4-ALPHA/epic4-1.1.15.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-ALPHA/epic4-1.1.15.tar.bz2 It has been suggested I should announce epic4-1.1.15, which is going to be the basis for the FreeBSD port now. This is the first of hopefully several beta-quality epic4-1.1.* releases. Note that this is not a formal beta release, but rather is an alpha release that is stable, and free of any real meaningful problems. You are therefore invited to try this out if you want to be an early adopter and see what epic4-2.0 is going to look like. If you find any problems, now would be an excellent time to bring them up because I would like to have a formal release candidate by December 1, and then we'll go through the voting process and all that. Obviously if you're using epic4-1.0.1 you should not be hasty to upgrade because all epic4-1.1.* clients will break scripts written for epic4-1.0.1 for various reasons that all have to do with progress. You should as always stick with the version of epic your script was targeted for. It is always best to upgrade epic only when your scripts needs you to. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] Any users of /window lastlog_level ?
Is there anyone out there who sets /window lastlog_level to anything other than ALL? I'm not talking about /window level, but /window lastlog_level. I'm trying to find someone who uses that feature so I can talk to them about it. I'm thinking about the future of this feature, and if nobody replies back, I may just assume nobodoy uses it and may change it! So if you use the feature, please email me so I can include you in the discussions about its future. Thanks. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC][PATCH] avoid unneccessary stat() if mail is not configured
Hello, if the MAIL variable is not configured or no mail file for the user exists, then the file 'unknown' is polled. This causes unneccessary traffic if the home is nfs mounted. In this case, just leave *mail_path empty and return. I ended up rewriting the entire mail checker because of this. The new mail checking stuff is more modular (i'm sure someone will probably contribute a maildir implementation [hint hint]), and one of the features i built into it was to /set mail 0 if it can't find a mailbox to poll. That should completely avoid this bug. Thanks for the report, and the patch! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]BUG_FORM: Unrecoverable login error with /window number
The problem happens when I try to change a channel's window number (/window number XX). I first thought it could be due to binding a channel to a window, but tests showed that's not the case; even if I don't use /window bind or /window channel, but am on a channel, trying to change that window's number will crash epic with the following message: You can no longer change the window number of a window that has a channel. EPIC won't stop you, but it will panic if you try. This needs to be documented and/or refused a little better. Thanks for the heads up. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]regexec on RH9 causes critical protection error
assign re $regcomp(test) eval echo $regexec(re test) If you know how to use a debugger, it would be helpful if you can get a stack trace, and cut and paste it here. Program received signal SIGSEGV, Segmentation fault. 0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6 (gdb) bt #0 0x420bcf9c in re_search_internal () from /lib/tls/libc.so.6 #1 0x420bc877 in regexec () from /lib/tls/libc.so.6 #2 0x08067dc3 in function_regexec (input=0x80d952b test) at functions.c:412 9 To follow up on this, the problem was that passing a string to $regex() that was not returned from $regcomp() causes epic to crash. It was suggested that epic could do some basic sanity checking, and I have effected that change. The return value from $regexec() should be of a known length (it is system dependant, but it can be calculated), and $regexec() will refuse any regex that is not exactly the right length. That should avoid the most likely errors. Thanks for the report! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC4-1.1.12 now available
EPIC4-1.1.12, the latest alpha release of epic4-1.1.*, the development branch
of epic, is now available. This release comprises months of work and a lot
of new stuff:
* $serverwin([server refnum])
* Major project to replace bad quality C code with high quality C code
* ./configure --with-warns
* $dccctl(.. FLAGS ..)
* $dccctl(.. HELDTIME ..)
* $dccctl(.. HOLDTIME ..)
* QWORD (double quoted words with double quotes) for alias arglists
* Finished off full ipv6 support for dcc.
* Current channel-ness is tracked by the channel and not the window. It's
now impossible for a channel to be a current channel unless you're on the
channel.
* /set new_server_lastlog_level default changed to ALL,-DCC
* $levelwindow([lastlog level])
* $outputwindow([lastlog level] [target])
* /timer.ue alias in 'commandqueues'
* %{1}+ status expando acts sort of like %+
* /SET SWITCH_CHANNELS_BETWEEN_WINDOWS
There are a lot more changes, but these are the most important user-visible
changes. As always, refer to the UPDATES and KNOWNBUGS file in the
distribution file, as well as http://www.epicsol.org/UPDATES and
http://www.epicsol.org/CHANGELOG.
You can find the distribution at:
ftp://ftp.epicsol.org/pub/epic/EPIC4-ALPHA/epic4-1.1.12.tar.gz
ftp://ftp.epicsol.org/pub/epic/EPIC4-ALPHA/epic4-1.1.12.tar.bz2
ftp://ftp.epicsol.org/pub/epic/EPIC4-ALPHA/epic4-1.1.12.tar.Z
(The .Z file is to commemorate the ending of the lzw patent in the usa)
Jeremy
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list
Re: [EPIC]regexec on RH9 causes critical protection error
For the purposes of testing, my .ircrc was: assign re $regcomp(test) eval echo $regexec(re test) Crashing here is actually the defined (but apparantly undocumented) behavior: because the string 're' is not a value previously returned by $regcomp, passing it to $regexec() results in undefined behavior on every system. In your case, it crashes. What you meant to do was: eval echo $regexec($re test) ^ Note $ here. There is no way for epic to check whether the first argument to $regexec() is reasonable or not -- it has to trust the user to do the right thing. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]BUG_FORM
This bug has now been fixed and commited to cvs. Thanks for the bug report. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
nsx said: Yes, I am campaigning for both better precision, and a change of the lower notify interval limit. I suppose they sort of go hand in hand, since to either abolish or lower the lower limit, you'd probably need to provide better precision anyway. Kev said: Personally, I don't see the problem with the first part--increasing the precision. As for a lower limit, I would strongly suggest that it should not be less than 30 seconds. It seems that the current compromise solution seems to be acceptable to a large number of people: * Remove NOTIFY stuff from the top_of_minute timer, into a second timer. * Allow user to modify timeout interval of that second timer via /SET NOTIFY_INTERVAL * Add a #define in config.h which will set an absolute minimum value of /SET NOTIFY_INTERVAL, so that the user can be assured that a script will not set a value lower than they wish to have. * The default value of this #define will be 60 for backward compatability. Of course with every compromise, not everybody got everything they wanted, but this seems to be very much in the middle of what everybody hoped for. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
Normally I would not follow up to a request for discussion, but nsx asked me to share why I believe in the status quo. The entirity of this message is not a statement of policy or rules or anything of the sort with regard to epic. It simply states my personal opinions as an epic user, and the reasoning that prompted this discussion in the first place. Nsx said: - From what I can tell, epic doesn't allow you any more precision than minutes in the notify interval, and it refuses to accept a value of under a minute. For most of epic's life, the main focal point of everything that happens is the io() function, which i refer to as The Looper. io() has had its share of issues, particularly how everything is hardcoded into it, and that limits flexibility and generalness. One of the things that was hardcoded into the looper was top of the minute processing. At the top of every minute, epic does various housekeeping duties: 1) Checks your mail 2) Throws /on timer 3) Does your notifies 4) Updates the clock (on the status bar) Previously, EPIC always and only ever performed these duties at the top of each minute. The /SET NOTIFY_INTERVAL value was added as a way for some users, who felt that doing notifies once a minute was far too frequently and imposed too much of a burden on the server, to rachet down the frequency of their notifies. Even though the unit used was a second, the granularity was always measured in minutes, since the notifies only ever happened at most once a minute anyways. Recently, this changed somewhat. When I rewrote the /timer system, I was able to remove the top of the minute processing from the looper and instead make it a regular, recurring, system timer. Because it is now a regular, recurring, system timer, it is no longer necessarily hardcoded to happen only at the top of every minute. Nsx has pointed out that this has opened up the viability of discussing whether or not we should remove notify handling from the top of the minute processing and make it a second, separate regular, recurring, system timer with its own timeout and have it work independantly of the top of the minute timer. The reason why notify is done at most once a minute even now should be clear; it is done from within a timer that happens at most once a minute. The question then becomes, should we remove notify handling from this timer; make it operate under its own timer; and have the timeout be controlled by /SET NOTIFY_INTERVAL. This raises sticky issues however. As we all know, the server imposes flood control upon the user, generally allowing at most one protocol command per 2 seconds. Excessive commands causes the client to be penalized and eventually disconnected. In general, it would be a violation of user's expectations that changing a /SET would cause them to get disconnected from the server due to reasons that they cannot personally understand (ie, if you /set notify_interval 1, you will be disconnected eventually, the user wouldn't understand why, though). So there perhaps should be some lower limit on the number of seconds between each notify event, *even though a user may wish to do it more frequently*. The question is what that minimum number of seconds should be. My personal opinion is still that 60 seconds is best, to be most kind to the server. Notify imposes a not-small burden on the server, and much pain and suffering is caused by clients doing TOO MANY notifies, not too few... And that is my opinion. I am not speaking as a coder, but as a fellow user. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Can someone help a user with problems with red hat 8?
Hi. Charles Umpleby ([EMAIL PROTECTED]) is having problems compiling epic on redhat 8.0. Could someone help him out please? Thanks. I have determined that the problem is NOT that he does not have the linux kernel sources installed -- so it must be another problem. Thanks Jeremy --- Forwarded Message I am trying to run a make after I compile EPIC in Redhat 8.0 with GCC 3.2-7. I get a bunch of file not found errors. Can you help? As you will notice, I posted everything I get when trying to run the make. Am I missing something? Do I need to install something? I also have Redhat's standard installed version of ncurses (5.2-28). Let me know. Thanks Chuck Umpleby [root@bigblue epic4-1.1.7]# make make[1]: Entering directory `/root/epic4-1.1.7/source' gcc -g -O -I./../include -I../include -c alias.c In file included from /usr/include/signal.h:313, from ../include/irc_std.h:37, from ../include/irc.h:28, from alias.c:39: /usr/include/bits/sigcontext.h:28:29: asm/sigcontext.h: No such file or directory In file included from /usr/include/bits/posix1_lim.h:126, from /usr/include/limits.h:144, from /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/limits.h:132, from /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/syslimits.h:7, from /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/limits.h:11 from /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/syslimits.h:7, from /usr/lib/gcc-lib/i386-redhat-linux/3.2/include/limits.h:11, from ../include/irc_std.h:38, from ../include/irc.h:28, from alias.c:39: /usr/include/bits/local_lim.h:36:26: linux/limits.h: No such file or directory In file included from ../include/irc_std.h:39, from ../include/irc.h:28, from alias.c:39: /usr/include/sys/param.h:23:26: linux/limits.h: No such file or directory /usr/include/sys/param.h:24:25: linux/param.h: No such file or directory In file included from /usr/include/errno.h:36, from ../include/irc_std.h:40, from ../include/irc.h:28, from alias.c:39: /usr/include/bits/errno.h:25:26: linux/errno.h: No such file or directory In file included from /usr/include/sys/socket.h:35, from ../include/irc_std.h:49, from ../include/irc.h:28, from alias.c:39: /usr/include/bits/socket.h:305:24: asm/socket.h: No such file or directory --- End of Forwarded Message ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]Bug: ``man installhelp'' fails, EPIC4 version =4-1.1.7 (?)
When attempting to install helpfiles (hey, I was curious at the changes with bind(8) because of the keys.c big rewrite), helpfiles do not exist, so line 185 of epic4-1.1.7/Makefile is excutied incorrectly, copying the contents of epic4-1.1.7/ (including subdirectories) to /usr/local/share/epic/help. The help files are available as a separate package, and can also be fetched by way of CVS. It is certainly not acceptable for 'make installhelp' to fail in this manner and you are quite correct that some action should be taken to change its behavior. But 'make installhelp' is provided for those who may download the separate help package, and put it into the help/ directory, and want to have it automatically installed for them. An excellent place to look up help right now is http://www.epicsol.org/~kitambi/help Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Updated file for lice and epic4-1.1.7
Because several lice users have spoken up about epic4-1.1.7 breaking lice, and because I know that srfrog has more important things to do right now, I have modified the lice.binds file that comes with lice to be compatable with epic4-1.1.7. http://www.epicsol.org/~jnelson/lice.binds Your 'lice.binds' file should be found in ~/.irc/lice/lice.binds. Just overwrite your existing file with this new file and you're good to go. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Fwd: greeting goodbye.
--- Forwarded Message Date: Mon, 10 Dec 2001 22:44:48 -0700 (MST) From: Johnny Economou [EMAIL PROTECTED] To: The IRCII-EPIC List [EMAIL PROTECTED] Subject: Ircii-epic: greeting goodbye. Hello members of the IRCII-EPIC list, Since I am moving to Greece I'll have to minimise or even stop IRCing. I would like to take a moment to thank all of you that helped me all these years but mostly that you made me feel welcome in #epic and this list. Good luck to all of you and best wished for the EPIC client which made my life fun in the IRCland... best regards, John Economou (HSOC) --- End of Forwarded Message ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Translation support added back to epic
For those of you who visit us on #epic on EFNet (what, you don't hang out on #epic on EFNet? Why not? That or irc.epicsol.org -- come visit us!) know that EPIC development has resumed and we are working towards an eventual release of epic4-1.1.1, which will be the first beta release which will eventually culminate in epic4-1.2.0. One of the things that I included this weekend was adding back the translation support from ircII that i took out at the beginning of EPIC4. I added it back because of legitimite technical needs, primarily from users in russia, who need it to interface their Cyrillic terminal emulators with the always ubiquitous Latin-1 irc server. Others may find this stuff useful as well, but it was specifically for Russian users that I added this back. ircII implemented translation stuff on the *output* side of the equation (ie, stuff was translated before it was sent to the screen, and was translated when you pressed keys). After careful evaluation of this setup, it struck me that this was not the most helpful form for translation. Since it was explained to me that the purpose of translation is to translate the user's character to and from the server's character set, then it does not make sense for the client to translate from the user's character set to the server's character set and then display the server's character set onto the user's screen. Unless I'm misunderstanding people, this strikes me as not very helpful for the user. So what I have done here is implement translation as additional filtering that happens to input/output from the servers. EPIC will continue to work with the user in the user's chosen character set, but before sending anything to the server, will use the current translation to transform the user's input to the server's character set. Conversely, the first thing that EPIC will do upon receiving input from the server is to translate it from the server's character set to the user's character set, and then everything will continue from the users's character set. If I have misunderstood this, please let me know. Testing, advice, and feedback will be greatly appreciated. This feature is not for my benefit, it is for you, the users, and if I have goofed, I need to know so I can fix it quickly. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]epic crash
I also have a log accumulator that also posts diffs. I think I posted it to Jeremy, actually; did you not get it? I do not remember getting it, no... Anybody who wants to provide me with a pre-fab way to do anything like this I'm agreeable to doing. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]epic crash
On Tue, Oct 09, 2001 at 02:52:26PM -0500, Jeremy Nelson wrote: This bug was fixed yesterday. No cause for alarm. Just cvs update. Hey Jeremy, do you have a list for CVS commit mails? They're generally very helpful to those of us who don't follow CVS as closely as we should (and also for those who do if you have the right logger..) If you don't have this now and are interested, I'd be willing to help you set up a version of log_accum (my personal favorite logger, once it's been tweaked a bit...) No; there is no such list. I haven't gotten as far as understanding how this works. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]bugs in trunc()
21:12 Examples: 21:12$trunc(2 3.141592654) returns 3.14 21:12$trunc(5 3.54)returns 3.54000 Hmm, but $trunc(0 3.141592654) returns nothing. I have new_math on, but doubt this has much to do with it. I would generally consider this to be a bug in implementation. $trunc(0 ..) is not permitted; if you need to truncate to an integer, just chop it off at the decminal point. We've also determined that it rounds. Rounding is probably not what you want in trunc either. I consider this a bug in the naming of the function, round should round, trunc should trunc. I use printf to do the truncation, and it's too complicated to do it myself, so tough. ;-) You are of course welcome to submit patches if you want to see this done another way. Please be aware that some may depend on current behavior, so if anyone complains about the change, i'll send them to you. ;-) And no, a new /set will not be permitted. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
And again... Now about ON message hooks. Some hooks, like alot of public_* hooks and channel_signoff are filtered agains current channel and sender channels, other hooks are common. Shouldn't it be more clean: either filtering are to be done by scripts or in ircclient core ? In last case there should be action_other, ctcp_other, etc_other - when channel (or general 'target') is not current, action_msg, ctcp_msg - when sender is not on channel it sends message to. and ever more: send_public_other, send_msg_other - when sending messages to not current channel/nick. ? What 'policy' says about it ? The special on hooks, such as /on public_other and so forth are a terrible blight on ircII and exist strictly for backwards compatability (ie, this is not a fight i want to pick right now). I *strenuously object* to adding more of them. I also object to the removal of any legacy /on's for backwards compatability's sake. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
And u still haven't said what u think should be added and what removed ?... Or i miss some idea ? :) I think no changes should be made. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]windows / message hooks
Would't it be fine to have hooks
- for all numerics replies (by their RPL_names)
or to group ERR_ replies into one hook ?
Who would be responsible for mapping numerics to RPL_names? What happens
when a server uses a custom RPL_name that epic doesn't know about? This
is not really feasable.
- for each nonnumerics messages:
PRIVMSG, NICK, JOIN, PART, etc
There are already more than enough /on's for these types of messages.
We don't need to make it even more complicated for scripters to keep
track of what is going on. /on public_other and /on msg_group really
shouldn't exist if there were any justice in the world.
- one for ctcp, with type as one of arg
- for dcc
For backwards compatability is it possible
to generate/throw events in scripts ?
Again -- adding more /on's doesn't solve any problems, it only makes it
worse. That's why we have the patterns argument. What is the fucntional
difference between
/on ctcp_version from to argument {...}
and
/on ctcp from to VERSION argument {...}
except a few characters transposed?
I oppose adding gratuitous /on's that are already covered by other /on's.
I oppose removing legacy /on's for backwards compatability reasons only.
Jeremy
___
List mailing list
[EMAIL PROTECTED]
http://epicsol.org/mailman/listinfo/list
Re: [EPIC]8bitchars in nicks and chanel name
RoboHak wrote: The client, server, and IRC protocol all limit the characters that can be used in a nickname. The client handles that in the check_nickname() function in ircaux.c. According to the IRC protocol... cut off qMax wrote: I know IRC proto. But some servers has many extentions. extensions that cause the server to violate longstanding standard practices of the irc community cause the server to no longer become an irc server, but rather a chat service that at one time was irc-like. I don't support non-irc servers, it's too difficult to keep track of the zillion different odd breakages that each one requires. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]server groups: Protocol
Hello. I'm going to work on server groups and have some questions according to this. In doc/segver_groups and in include/sgroup.h [snip] These documents are either incomplete or obsolete. Don't bother. Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]Autocompletion
On Fri, Sep 07, 2001 at 11:19:18AM -0500, Jeremy Nelson wrote: I wished that autocompletion to be context-dependant (nickname, command, command arg, channel name) as in irssi and worked in vim-style (sequensially substituting in editline, instead of listing all choices) Should it better be implemented in code (as context_completion command) or in script ? This is by policy the responsibility of a script to do this. What and where are those policies ? Ok, Ok. So maybe policy is the wrong word. Agreed upon principle is more precise. Here are the principles: --- snip here --- * Functionality with no excuses: If what you want to do is allowed by the protocol, is reasonable to implement, and isnt soundly hated by all the other users, we'll do it (eventually). EPIC does not stop you from doing something just because i, or someone else, thinks that you have no business doing it. We try to not let EPIC get in your way. Many times, due to time (or interest) constraints, a perfectly good feature goes un-implemented. Self-initiative (eg, code it yourself, send me a patch) goes a long way towards getting your features into release quickly. * Remaining an attractive replacement of the stock client: One of my running primary goals is to reduce the CPU usage of the client. By all accounts, we have been very successful doing this. We have made sure to balance this goal as much as possible with not letting memory consumption get out of control. We have tried to fix bugs and design deficiencies in the stock client without introducing unreasonable restraints on the users. Taken altogether, EPIC is intended to be as sysadmin-friendly as the stock client. EPIC is neither more user friendly or less user friendly than the stock client, but it is *much* more scripter friendly. * A almost-completely open design environment: For the sake of efficiency, i do the release engineering. Because of various contraints on my time, i am not always able to do releases as often as users would like me to, but *everything* i release to anyone, i release to *everybody*. No release, no matter how small, is withheld from the public. I gladly take suggestions from users, and almost all new features/functionality are direct user requests. I IRC frequently and am often available for direct conversation. I try to (as much as possible) release something at least once a week, and when development is cruising along, can release once per day. --- snip here --- Functionality with no excuses covers the principle that EPIC's job is to provide tools and your job is to put them together the way you need them. EPIC has from the day it was created been about *scripting* -- and I don't expect this to change any time soon. ;-) Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
