Re: [EPIC] [list-ow...@epicsol.org: the whole config code is broken]
Richard, I'm sorry that your experience with EPIC5 did not meet your expectations. As with so many free, source available software packages, you have found that those with unusual system configurations may need to do some tweaking to get things working "just so". If you'd like to contribute your patches to the project for inclusion, please email them on to me, and I'll do what I can. However, please note that OpenSSL is an important, ubiquitous software package that provides functionality beyond just https and encryption. It is unlikely that going forward EPIC5 will be able to work without openssl. I recommend EPIC4 for your needs, if you are still interested in giving epic a try. Thanks, Jeremy [You wrote] >dear epic developers, > >i had a very hard time compiling this very client on a >vanilla ubuntu x86_64 box. > >Linux linda 2.6.32-35-generic #78-Ubuntu SMP Tue Oct 11 16:11:24 UTC 2011 x86_ 64 GNU/Linux > >Ubuntu 10.04.3 LTS > >your ssl code is absolutely broken, as is the configure script. >i had to fix the configure script by hand to disable the broken >default ssl code. > >tcl wasnt detected aswell, had to fix the generated Makefile >by hand. > >please fix the broken ssl code and configure script asap. >this renders the client totally unuzbl. > >epic version used: >epic5-1.1.2 > >using the broken ssl code by default is absolutely wrong. >especially in 3rd world countries like germany and north korea where >the use of strong crypto is unwanted and therefore strictly prohibited. > >how should a german script kid like me use this client if >even the configure script is broken ? > >or is the client developed for a different kind of user base ? >the 1337 h4x0r and s3CuRiTY Xp3rT ? for the g33x and n3rdz ? > >best regards, > >Richard Koumbos > > >- End forwarded message - ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] 2 Questions
Greetings! >1) How do I get hh:mm time stamps in front of every line? /set output_rewrite [$Z] $1- >2) How do I get a history that is as long as the client runs? EPIC retains two histories -- your /lastlog and your scrollback. You can effectively unlimit them by setting them to very high values. (To change them globally) /set lastlog 99 or /set scrollback 99 (To change them for only one window) /window lastlog 99 or /window scrollback 99 Warning -- very large scrollbacks or lastlog will consume /a lot/ of memory! If you eventually run out of memory, epic will shut down and this isn't considered a bug as such. Let me know if there's anything else I can do to be of assistance! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[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
Re: [EPIC] [epic5]browsing input history within client at the command line
>Synopsis > >Tested on the above 2 machines, as root and regular user >in both bash and sh environments, and in both console and xwindows. > >Issue: Browsing input history with ctrl+p, up arrow, and/or down arrow. Hi! In EPIC5 we scripted a lot of things that used to be hardcoded. History recall is one of those things. The strange behavior you're observing is the confluence of two signficant changes in epic5 versus epic4: epic4: always did a /load global hardcoded that you couldn't turn off epic5: Will only /load global iff you don't have your own .ircrc epic4: hard hardcoded history recall that you couldn't customize epic5: has a scripted history recall with lots of customizations, which you can activate with /load history. It is also loaded by 'global' which is why history recall worked when you didn't have an ircrc. So *if* you have an ~/.ircrc with epic5, you will probably want to add /load global to it in order to ensure maximum backwards compatability with epic4. You may be asking, why doesn't it load it like epic4 did? Most epic5 users are actually using a script, which wants to do things its own way, and so epic5 doesn't force the issue. But for those of us who roll our own ircrc, there are definitely a few adjustments in epic5 versus epic4. I do note however your point that if the ~/.ircrc is present but not readable, that epic5 treats it as though it has been loaded. I agree that's not the proper behavior, and I'll put it on the buglist to fix. Thanks for pointing that out! Please let me know if you have any more questions. We're really friendly. =) Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC Cache developers
[advertisement deleted] I have unsubscribed this gentleman from the mailing list. Hopefully he will take the hint and find a more appropriate forum. 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-1.0 now available!
EPIC5-1.0 is now available at * http://ftp.epicsol.org/pub/epic/EPIC5-PRODUCTION/epic5-1.0.tar.bz2 * http://ftp.epicsol.org/pub/epic/EPIC5-PRODUCTION/epic5-1.0.tar.gz * ftp://ftp.epicsol.org/pub/epic/EPIC5-PRODUCTION/epic5-1.0.tar.bz2 * ftp://ftp.epicsol.org/pub/epic/EPIC5-PRODUCTION/epic5-1.0.tar.gz What is there left to say? This is the first production release of EPIC5, five years and 11 days in the making. Enjoy! Thanks to everybody who helped make this possible! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Final call for objections to epic5-0.9.1 as production release
This is the final request for any last minute changes that you want to have made to epic5-0.9.1 before we turn this into a production release. These are the things I am hoping you might tell me: *) A bug, crash, or other malfunction which behaves contrary to expectations *) Anything that really annoys you (if it's small, I'll address it) *) Anything that is not the way you think it should be If there are any suggestions for changes, I will roll them up into an 0.9.2 release and we'll keep iterating until everyone is happy with the result. If nobody says anything, then we will eventually have a production release. Speak now or hold your peace later! =) Thanks, Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] First call for objections to epic5-0.9.0
As most of us know, the epic community isn't as big or as active as it used to be in years past. I'm uncertain whether there is a sufficient base of testers out there to take a vote on epic5-0.9.0. I would be appreciative if anyone who has tried epic5-0.9.0 would drop me a line and let me know so I can size up how much testing it is getting. Thanks! 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] 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] How to make epic supporting utf-8
>hi, >There is a channel, #fedora-cn on freenode, which uses utf-8 >enconding. When I use epic to join it, I always get invaild >displaying. Is epic support utf-8? How can I configire this? > >I am using epic-2.6-2.fc8 on fedora 8. Unfortunately, epic can only do "pass through". What I mean by "pass through" is that the display of utf8 characters is controlled by your terminal emulator (for example, "xterm" or "putty"). If your terminal emulator supports utf8, then everything should work except for column wrapping, which will be wrong, because epic does not yet know how to properly count columns for utf8 encoding. If, however, you're not using a utf8 terminal emulator, then you would need support in epic to convert utf8 strings into whatever your terminal emulator can display. Unfortunately, there is no support for that in epic today, either in epic4 or in epic5. It is hoped that as we learn more about i18n of console applications, or if someone who has experience with this offers us advice and code, we can make that a reality someday. But because this is just a volunteer project, I can offer no suggestion when it might happen. Some day. =) Thanks for the question! Sorry about the unhappy answer. Jeremy Nelson ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] [PATCH] Signal handling bug in epic4 2.10
>epic4 2.10 appears to have a rather serious bug that caused several >crashes for me recently. I don't know if this has been found/fixed >yet, but just in case it hasn't... Thanks for the bug report! I also don't know how this slipped through the cracks. Maybe not too many people have upgraded to epic4-2.10. There was a fix for this particular problem in epic5, which did not get backported to epic4. So I went ahead and did that now. You can cvs update to get the fix. Thanks for the patch! It is greatly appreciated. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] A proposal for a production release of epic5
It's been proposed that a major release of epic5 should be made. Although epic5 isn't feature complete, epic4-1.0 wasn't feature complete either, so it's not like we haven't ever done this before. Right now, the code base is very stable and no known bugs are known about. Unfortunately real life has been keeping me from spending as much time on epic as I would like, so it's been proposed that making a production release would raise interest in the project. If we did do a production release now, some very obvious features are still missing that we always said we would deliver (utf8 support and being able to move stuff between your windows being the two biggest ones), but there is not really any timeframe for when those would happen anyways. So the question on the table is whether we should make a production release of epic5 as it currently stands just to do it, or whether we should continue down the path we have been travelling? 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] About the next version of epic4, epic4-2.10
The next version of epic4 is likely to be called epic4-2.10. *** PLEASE LET ME KNOW RIGHT AWAY *** if you are a port/package maintainer of epic4 and if epic4-2.10 will cause you heartache. If it does, and you don't let me know, I won't know, and then I won't be too sympathetic about dealing with it after it's too late. Thanks! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] colors in our black background world
>hop said (rightly) that rearranging the colors would ultimately lead >to complaints, and that it has also (apparently) been discussed here, >so he proposed an alternative: a /set mapping, where stock, >out-of-the-box EPIC has mIRC-standard colors, and you can rearrange it >with the /set if you feel like it. Another option is a compile-time >#define or ./configure --with-rearranged-colors-nonsense switch, but >hop seemed to ignore me when I mentioned that :) The color mappings are stored in a table, which for expediency sake is static and compiled-in, but it doesn't have to be that way. After thinking about this some more, I would probably think we could all be happy with a $colorctl() function, that worked something like this: $colorctl(VALID TEXT)- Returns a list of all valid (mapped) colors, that can be used as text colors $colorctl(VALID BACK)- Returns a list of all valid (mapped) colors, that can be used as background colors $colorctl(GET TEXT) $colorctl(GET BOLD) $colorctl(GET BACK) $colorctl(GET BLINK) Each ^C color maps via four tables: depending on whether it is used as a fg color or a bg color, it specifies both the ansi color, and the bold setting, or the ansi color and the blink setting. Ansi colors are 0-15, and have nothing to do with mirc order colors and have nothing to do with ^C00 to ^C15. Ansi colors are the ^[[10m type numbers. I think it should be possible to change any of these values: $colorctl(SET TEXT ) $colorctl(SET BOLD <0|1>) $colorctl(SET BACK ) $colorctl(SET BLINK <0|1>) Then you can change any ^C code to anything you want, and go on your merry way. This would satisfy Pegasus's desire to be able to change the colors, and it would satisfy my desire that everything be 100% backwards compatable unless you opted-in to changing it. That's my two cents... Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] New EPIC5 release, epic5-0.3.7
I'm pleased to announce a new epic release, now available at: http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.7.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.7.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.7.tar.bz2 ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.7.tar.gz You may be wondering what happened to epic5-0.3.6. It was released, but because of a critical problem, it had to be withdrawn. You can still find it in the archives, but you shouldn't use it. The major addition in this release is preliminary support for /load'ing scripts out of zip files or tarballs. This code was written by fusion, to which I extend much thanks. There are, of course, many more minor changes. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] New EPIC4 and EPIC5 releases
I am pleased to announce the availability of the seventh EPIC4 production release (epic4-2.8) and the thirteenth (alpha) release of EPIC5. (epic5-0.3.5) ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.8.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.8.tar.bz2 and ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.5.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.5.tar.bz2 Although normally the only changes to epic4-2.8 would be bug fixes, a few minor feature enhancements were added by special request of scripters. EPIC5 has had many changes, and you can refer to the "UPDATES" file that ships with the release for more details. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On lvals and rvals, deref and numeric expandos
Someone made mention recently that you can't assign to a variable using
the deref operator on a numeric expando, but you can using a param:
# This works
alias testalias1 (varname) {
@ *varname = 'booya'
}
# This does not work
alias testalias2 {
@ *0 = 'booya'
}
The reason for this has to do with how tokens are handled in the math
parser. There are three types of tokens:
1) A bare variable name varname
2) A string 'booya'
3) A number 0
When you use the deref operator on a variable name, it converts the rvalue of
that variable into an lvalue.
assign varname testing
# this assigns 'this is a test' to $testing
*varname = 'this is a test'
# So *varname is the same as $testing...
*varname == 'this is a test'
# So this is always true
*varname == [$($varname)]
When you use the deref operator on a *number*, it expands to the rvalue of
the numeric expando of that number, and does *NOT* convert that rvalue into
an lvalue. This is what allows you to do:
@ foo = *0
But the thing that allows you to do that is the same thing that doesn't
allow you to do:
@ *0 = 'testing'
Because *0 is $0 and not $($0):
# This is false!
*0 == [$($0)]
# This is true
*0 == [$0]
# This is true!
*varname = [$($varname)]
# This is false!
*varname = [$varname]
Derefing variable names and numbers are at odds with each other. So it is
not possible for both
@ *0 = 'testing'
and @ foo = *0
to both work at the same time. So for backwards compatability, we will
maintain the current behavior, even though it's not consistent.
All is not lost -- you *can* assign to a variable name passed as $0, you
just have to deref it a second time, because *0 yields an rvalue, and you
can just deref it again to turn it into an lvalue:
# This assigns to the variable passed as $0
@ *(*0) = 'testing
Consequently, I recommend we make no change to how this works.
Comments, thoughts, questions, improvements, suggestions?
Jeremy
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
[EPIC] (try two) On channels and servers and string encodings...
The previous version (for some reason) was mangled into quoted-unprintable so I am sending it again this time with smaller lines so it won't be completely unreadable. This is a discussion that is strictly academic at this time. Please do not think that we are close to supporting any of this stuff. Rather, I want to start a dialog about how people want this to work, so when we do go ahead and design it, people will not think it came out of left field. So the question on the table is string encodings. The input line: Now right now, epic doesn't handle encoding on the input line -- it just assumes that each byte is one code point. For people using utf-8 one keypress may yield one codepoint may yield multiple bytes, which show up as multiple (incorrect) bytes in the input line rather than the key pressed. Column counting is not broken /as such/. The display: Right now, epic doesn't handle encoding on the output display. Any bytes received are just sent to the display, so if you output a utf-8 string on an utf-8 emulator, it will show up correctly, and if you output a utf-8 string on a iso-8859-* emulator, it will yield multiple (incorrect) characters. Column counting is (of course) broken. The servers: Globally, the user can /set translation which converts between the code points from one 8-bit character set (usually ascii) into another 8-bit character set that the server is using. This is fine, as long as both the user and the server are using 8-bit code points (which is not the case for utf-8, obviously). Channel Names: Channel names can be encoded in any encoding. A channel name like #fr=E3nd could be encoded in iso-8859-1 and take up 6 bytes, or the channel name could be encoded in utf-8 and take up 7 bytes. The irc server will treat these as separate channels, ***so it's fundamentally important to be able to specify an encoding when specifying a channel name.*** Channel messages: People who chat on the channel may (or may not) use any encoding at any time, but usually everyone uses the same encoding, which ***may or may not be the same encoding as the channel name itself***. For example, the channel name may be encoded in iso-8859-1 and the users may agree to use utf-8. ***so it's fundamentally important to be able to specify a different encoding for privmsgs on the channel than is used to specify the encoding of the channel name itself.*** THEREFORE, We're going to have to start thinking about syntax for how to specify all this stuff on a per-channel, per-server basis. As a wild example, we could prefix channel names with encoding, using invalid-for-channel characters. Example: /join (iso-8859-1)#fr=F6nd (join the channel, encoding the channel name in iso-8859-1) /join (utf-8)#fr=F6nd) (join the channel, encoding the channel name in utf-8) /join (iso--8859-1/utf-8)#fr=F6nd (the channel name is encoded in iso-8859-1, but privmsgs will be encoded in utf-8) The last thing I want to do is support utf-8 but then end up having it be half-assed and make everyone think i'm a clod for not thinking of every last important detail to take care of. So now is the time to tell me what's really important for supporting a multi-encoding irc client! Thanks for your discussion! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On channels and servers and string encodings...
This is a discussion that is strictly academic at this time. Please do not think that we are close to supporting any of this stuff. Rather, I want to start a dialog about how people want this to work, so when we do go ahead and design it, people will not think it came out of left field. So the question on the table is string encodings. The input line: Now right now, epic doesn't handle encoding on the input line -- it just assumes that each byte is one code point. For people using utf-8 one keypress may yield one codepoint may yield multiple bytes, which show up as multiple (incorrect) bytes in the input line rather than the key pressed. Column counting is not broken /as such/. The display: Right now, epic doesn't handle encoding on the output display. Any bytes received are just sent to the display, so if you output a utf-8 string on an utf-8 emulator, it will show up correctly, and if you output a utf-8 string on a iso-8859-* emulator, it will yield multiple (incorrect) characters. Column counting is (of course) broken. The servers: Globally, the user can /set translation which converts between the code points from one 8-bit character set (usually ascii) into another 8-bit character set that the server is using. This is fine, as long as both the user and the server are using 8-bit code points (which is not the case for utf-8, obviously). Channel Names: Channel names can be encoded in any encoding. A channel name like #frãnd could be encoded in iso-8859-1 and take up 6 bytes, or the channel name could be encoded in utf-8 and take up 7 bytes. The irc server will treat these as separate channels, ***so it's fundamentally important to be able to specify an encoding when specifying a channel name.*** Channel messages: People who chat on the channel may (or may not) use any encoding at any time, but usually everyone uses the same encoding, which ***may or may not be the same encoding as the channel name itself***. For example, the channel name may be encoded in iso-8859-1 and the users may agree to use utf-8. ***so it's fundamentally important to be able to specify a different encoding for privmsgs on the channel than is used to specify the encoding of the channel name itself.*** THEREFORE, We're going to have to start thinking about syntax for how to specify all this stuff on a per-channel, per-server basis. As a wild example, we could prefix channel names with encoding, using invalid-for-channel characters. Example: /join (iso-8859-1)#frönd (join the channel, encoding the channel name in iso-8859-1) /join (utf-8)#frönd) (join the channel, encoding the channel name in utf-8) /join (iso--8859-1/utf-8)#frönd (the channel name is encoded in iso-8859-1, but privmsgs will be encoded in utf-8) The last thing I want to do is support utf-8 but then end up having it be half-assed and make everyone think i'm a clod for not thinking of every last important detail to take care of. So now is the time to tell me what's really important for supporting a multi-encoding irc client! Thanks for your discussion! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Call for bugs for EPIC4
This is a call for any bugs anyone knows about in epic4. Any bugs that are reported will be fixed prior to the next release. There will be a forthcoming release of epic4, epic4-2.8, which shall contain all of the bug fixes to epic4-2.6 which are (presently) only available in cvs. These bug fixes are: * Fix inability to /query an /exec'd process. (rb Godlkworth) * Add support for +T by special request. * Fix crash for /parsekey type_text * Add $windowctl(GET CHANNELS) in kindness to BlackJac. * Fix brain-o in a previous fix. If i don't hear about any bugs in about a week, I'm going to just assume all is well and make the new release. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Further discussion on /set realname
Recently, it was proposed that we change /set realname to /set default_realname so it was more clear that changing /set realname does not, in fact, actually change your realname, but instead just changes the default that is used the next time you reconnect. There is code in 'builtins' which creates a /set reconnect for backwards compatability. There has been an objection raised that this /set should not have been changed as the old /set was not confusing and backwards incomaptability without 'builtins' was not called for. Please, would everyone weigh in on this issue, so I can know what to do? Thanks, Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] [EPIC} EPIC5-0.3.4 now available
EPIC5-0.3.4 is now available at: * http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.4.tar.bz2 * http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.4.tar.gz * ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.4.tar.bz2 * ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.4.tar.gz This is a stable alpha release that fixes all of the known issues with epic5-0.3.3 and is stable enough to be targeted by scripts and packagers. At least one script (amnesiac) is expected to target this release. Most importantly in this release, /SET REVERSE_STATUS_LINE no longer exists, so if you want your status line to be in reverse, you need to put a ^V (control-V) at the start of your /set status_format! The default status updates in config.h have all be updated. Other noteworthy changes are strong-crypto now available at the script level with $xform(), and a new script to do dcc port ranges. There is a new ** operator which should make most remaining uses of /eval unnecessary. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On removing /set reverse_status_line
Zlonix suggested we should remove /set reverse_status_line in epic5. I am not (necessarily) against this suggestion because I have a standing policy to remove retarded /set's. Generally when we've removed /set's in epic5, BlackJac (or myself) have created scripted re-implementations and put them in 'builtins' script, so those who are loading that script have some expectation of backwards compatability. We tried to remove this /set but we were unable to (properly) reimplement it in a script. That means if we remove this /set, it would break backwards compatability with all epic5 users. All epic5 users would have to ensure that their /set status_format's start with ^V if they want them reverse. This would not be required for epic4 users, and in fact, they must not do so. Comments/thoughts/suggestions? Thanks, Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.3.3 now available
I'm pleased to announce the immediately availability of epic5-0.3.3. http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.3.3.tar.gz http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.3.3.tar.bz2 ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.3.3.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.3.3.tar.bz2 Although this is an alpha release, it is quite stable, and there there are already two scripts available for it (hieona and darkstar-0.4). Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] A modest proposal on the input line
(I thought something was weird when nothing had appears on this mailing list since Jan 1st...) Executive summary: I want to change the input line so the input prompt is always visible, and when the input line scrolls, a reverse "<" or ">" will appear in the direction that has more text than can be displayed. The reason I want to do this is because this would make it easier for me to support wide characters in the input line, taking us closer to unicode support. It was in this place that I would going to include a long, rambling, boring discussion about what the tradeoffs were, but then I realized that I just don't have all of the ducks in a row to give an exhaustive defense of why I am interested in making this change. What I can tell you is sometimes the input prompt is visible, and sometimes it is not, and because the input prompt is output differently from the input line, this makes counting columns a vexing task. It would be much easier to handle the input line if I knew the input prompt was always visible, and always took up X columns, and that I could allocate the rest of the columns to the contents of the input prompt. I sincerely state that it is my belief this would make it easier to rid epic of the lame "one byte == one column" assumption that holds us back from being able to support unicode (utf-8) input. If you really are attached to the way the input prompt is handled now (with it initially being visible, but not being visible after you type a bunch of stuff), please, do say something! What does anybody think of this? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] (Test message) This time for sure!
Or I'm going to get out the pliers and start manually extracting my hair. Please forgive the test messages! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] This is a test email, test #2
The epic mailing list is broken. This is a test to see if I've fixed it. Please disregard this test message. Test #2 Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] New EPICs: EPIC4-2.6 and EPIC5-0.3.1
I am pleased to announce the release of the sixth epic4 production release, ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.6.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.6.tar.bz2 and the tenth alpha release (eleventh overall) of epic5, ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.2.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.2.tar.bz2 WHAT'S NEW IN EPIC4? * Compile-time support for maildir mail drops * HPUX is now officially supported. * Socks5 support works again (at least on freebsd) * A few bugs have been fixed WHAT'S NEW IN EPIC5? * New /on operwall, for blackjac * New server statuses, "created" and "deleted" for reconnect script * New $serverctl(get ADDRSLEFT) for reconnect script. * Major overhaul of dword support (sort of half-finished) * /WINDOW foo KILL now won't kill the current window if 'foo' doesn't exist. * Named fields in server descriptions * Ability to force a server to use ipv4 of ipv6 only * New RESET_LINE keybinding for history script * New ON CHANNEL_LOST hook for reconnect script * New ON UNKNOWN_COMMAND hook for auto-command completion scripts * New ON WINDOW_SERVER hook for reconnect script * Ability to force a certain vhost for each server * De-bogo-fication for $pop() and $push(), $shift() and $unshift() * New $curcmd() command for /set output_rewrite * The /XDEBUG command now can take a block for temporarily setting a value Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Call for errata for epic4
It's been 8 months since EPIC4-2.4 was released, and a few significant changes have been made, including the addition of support for maildir, a few bugs, and socks5 support is working again. Does anyone have anything more that needs to be changed in epic4 before another release is made? I'll probably make a release "soon" if I don't hear any requests for more changes. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] A modest reconcilliation proposal for dword support
There is still a lot of confusion regarding dword support (double quoted words) in epic4, and the changes made recently to epic5. I would like to summarize the issues at hand, and then present a modest proposal for epic5's future behavior. The problem --- There are 46 functions in epic4 that support "word lists". The problem comes is, when a "word list" contains a double quoted word, does that count as one word or multiple words? Are the double quotes kept or are they stripped away? These are the functions afterw beforew chngw cofilter common copattern corfilter corpattern difffindw findws fromw getopt globglobi indextoword insertw joinstr leftw match maxlen midwnotwnumsort numwordspattern pop prefix pushremwremws restw revwrfilter rightw rmatch rpatternshift sortsplice tow uniqunshift unsplit wordwordtoindex Functions that are not on this list should not have changed behavior between epic4 and epic5 on the basis of double quoted word support! Some of these functions support double quoted words fully (findw, getopt, match, maxlen, word), and some of them support double quoted words only when /xdebug extractw is on (chngw, insertw, midw, notw), and some functions support double quoted words, but strip the double quotes out (joinstr, common, numsort, pattern), and some functions are *broken* when you use double quoted words (afterw, beforew, fromw) There is no rhyme or reason for why there are so many special cases. This has just grown up over the course of epic's life and there has never been a project to rationalize and normalize the behavior until now. The proposal We will, by default, make all of the above functions, except for getopt globglobi not support double quoted words. That means, double quoted words have no special meaning, and double quotes are considered regular old characters. We will allow you, if you do /xdebug dword, to turn on full dword support in all of the above functions. "Full support" is still a bit nebulously defined, and may be subject to change. For the moment, it means if you have a dword on the input, it will be a dword on the output. Dwords will only count as 1 word. We will change /xdebug extractw so it only affects the $* numeric expandos. It will no longer have any effect upon built in functions or anything else. This will allow you, the scripter, to determine 1) Whether you want dword support for $* 2) Whether you want dword support for function calls on an independant basis. Right now, you can't sever these two without toggling /xdebug extractw. Remember, functions that are not on the above list are not affected by this proposal (unless I made an inadvertant exclusion), and they should behave the same in epic4 and epic5. There you have it. Comments? Jeremy ___ 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] How shall @#channel messages be handled?
As you may or may not know, @#channel messages are considered to be
/on msg_group messages, and not /on public messages.
The following shim (or something like it) is customarily used to
route these @#channel messages to the correct window:
on ^msg_group "% @% %" {
xecho -w $chanwin($rest(1 $1)) <$0:$1> $2-
}
It has been proposed that epic should be smart enough to handle these
messages natively without a script shim. I am not against this idea,
but it would be nice if some of you would give me your opinions.
Although 'builtins' has been reserved until now for backwards compatability
with epic4, It seems like something like this would fit in nicely there.
What do you all think?
Jeremy
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
[EPIC] Hear Ye, Hear Ye! Big changes to word handling coming
After discussing this on #epic (efnet), we reached a tentative agreement
that it would be a definite improvement if epic *didn't* support double
quoted words in the word list functions. At least by default.
Double quoted word support in epic is a very slipperly thing to nail down.
There is not, and there never has been a definitive list of
1) What features support only uwords always
2) What features support only dwords always
3) What features support dwords only after you /xdebug extractw
Although all of the builtin functions
common, diff, sort, numsort, uniq, remws, prefix, match, rmatch,
userhost, word, remw, insertw, chngw, {r,}{pattern,filter}, copattern,
corpattern, cofilter, beforew, key, channelmode, revw, shift, pop,
findw, findws, isnumber, unsplit, joinstr, tow, afterw, fromw
have always supported dwords[1] since they were written, we are going to
change that. The above functions will soon no longer support double
quoted words and will only support straight uwords. [2]
Furthermore, the builtin commands
/FE, /FOR I IN ...
will also stop supporting double quoted words for the same reason.
For backwards compatability, epic5 will support "/xdebug dword" which
will revert to backwards compatable epic4 behavior. THIS WILL NOT BE
THE DEFAULT.
This means this change is backwards incompatable, and therefore must be
publicly vetted on the list.
It is not expected that /xdebug dword would be withdrawn before the
next production release, which is YEARS AND YEARS AWAY.
Comments?
Jeremy
[1] "Dword" means "double quoted words" or "words with spaces surrounded
by double quotes". The double quotes are not part of the dword, by rule.
[2] "Uword" means "unquoted words" or "words without spaces". You cannot
have a uword with a space in it, by rule.
___
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] 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
[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 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] Judy Arrays
>On Wed, Aug 09, 2006 at 06:56:09PM -0500, Jeremy Nelson wrote: >> Judy Arrays is a modern associative array data structure. >> http://judy.sourceforge.net/ They could be used as a >> drop-in replacement for alists, which are unpopular with >> some people because of the slow insert and delete times. >> >> Pro: There is no beating judy for performance >As I found from sources, Associated Lists is used for this: > - crypt list > - ignore list > - logfiles list > - window list >(Though, I may be missing something) > >Jeremy, do you think that replacing alists with Jlists will >give EPIC better performance? [...] The "add_to_list" function which you looked for is the doubly-linked-list [2] handler, and this would not be affected by judy arrays, those things above would continue to be done in doubly linked lists. The "add_to_array" function is the alist api, and is used for: - Symbols (aliases, assigns, commands, functions, sets, and inline expandos) - Nicknames on channels - Notify - 005 values the server supports I think the big question is whether or not these things are important enough to optimize with a better data structure. [1] Jeremy [1] Alists have O(log2 N) lookups, O(N) inserts and deletes, and O(1) sorted-order traversal. [2] Doubly linked lists have O(N) lookups, O(N) inserts and deletes, and O(1) sorted-order-traversal. ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Judy Arrays
Judy Arrays is a modern associative array data structure. http://judy.sourceforge.net/ They could be used as a drop-in replacement for alists, which are unpopular with some people because of the slow insert and delete times. Pro: There is no beating judy for performance Pro: The judy api is not profoundly different from the alist api Pro: Judy is stable (no signficant changes in 2 years) Pro: I could probably make a shim and maintain both going forward Con: Judy is LGPLd, so I can't just drop it in epic5. Con: Which I wouldn't anyways, because Judy is bigger than epic Con: Judy is obscure and not widely deployed Con: Judy requires GNU Make (epic doesn't) What do you all think? ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Mandatory Dependancies and OpenSSL
In the past, we have had discussions about whether EPIC should have any mandatory dependancies. Most recently, we agreed that EPIC could (or should) have a mandatory dependancy on ncurses. This has not yet come to pass, but I know I have permission to do so should the time be ripe. EPIC has long had an optional dependancy on openssl, since the EPIC4-SSL project was merged in 4.5 years ago. Very recently EPIC5 has sprouted support for openssl's evp api to do strong crypto.. Now the question comes to whether we should adopt openssl's BIO api. This could not be done in a way that is "optional". It would require that openssl be a mandatory dependancy of epic5. The pros are, the openssl BIO api is transparant and allows for a lot of new things that I can't do now, with and without encryption. This would reduce special cases and testing time, and increases functionality. The cons are, openssl is a pig, not everybody has it installed, I don't know whether it's legal to use it everywhere in the world, and the general sentiment that epic should never have a mandatory dependancy. What do you all think? ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.3.1 now available
EPIC5-0.3.1 is now available at: http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.1.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.1.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.1.tar.bz2 ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.3.1.tar.gz There are many noteworthy improvements to this release: * Support for Ruby * Rewritten 'configure' support for perl and tcl, works properly now. * Nonblocking SSL negotiation with servers * Support for maildir inboxes * Can now hit to get out of scrollback mode when also in hold mode * Several new scripts to implement neat features * Generalized /on numeric ($0 == numeric, $1- == the value of $*) * Strong crypto (CAST5, blowfish, AES, AES+SHA, and SED+SHA) -- CAST5 is compatable with ircII. blowfish is not compatable with FiSH. -- CAST5, blowfish, and AES(+SHA) depend on openssl. * Support for ciphering messages based on server+nick instead of just nick. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On strong cryptography and FiSH support
Currently I'm working on adding strong cryptography using the EVP api in openssl. If you have openssl, you will have support for cast5 (fully compatable with ircII), blowfish, and aes256 (not compatable with anybody else) I have been getting requests for years for "blowfish support" but what I have concluded is that what people are asking for is FiSH support. FiSH is a plugin for mirc, irssi, and xchat that ciphers text with blowfish and ascii armors it into those "+OK " strings you see occasionally. The difficulty I'm running into with FiSH is it uses a custom algorithm for blowfish that supports keys longer than the specification (FiSH supports 576 bits, but blowfish only supports 448 bits), and some channels use the longer keylength. The other problem is the ascii armoring is a custom algorithm (like base64 but not exactly base64). The only real solution for compatability in this case is to include substantial parts of the FiSH source code into epic, since the standard tools can't do the job. [1] Unfortunately, FiSH is not licensed, intentionally by its author. This would be unsuitable for inclusion in EPIC because some distros like debian would protest, and rightly so. In conclusion, the good news is, EPIC will be sprouting strong crypto support for privmsgs/notices. The bad news is, this isn't compatable with FiSH, which is what most people wanted support for in the first place. Jeremy [1] I couldn't possibly "clean room" a cryptographic algorithm since I don't know or understand how cryptography works. All I have the ability to do is cut&paste the stuff. ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Please forgive this text message
I had to do a major upgrade of mailman and every time I've done so in the past, I've horribly broken it. So I have to send a test message to see if it goes back out. Thanks for your understanding. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Does anyone want to volunteer to help me understand utf-8...
On Fri, May 26, 2006 at 10:34:47AM -0400, Brian Bruns wrote: > On Friday, May 26, 2006 10:14 AM [EST], Jeremy Nelson wrote: > > > and what support for utf-8 would mean for epic5? I understand all of > > the principles, but what I don't understand is what things are broken > > in epic5 because of the lack of support, and then what things are at > > my disposal to "fix" these broken things. > > > > I get a lot of requests to support utf-8, but nobody seems to know > > what is required, and neither do I. So this call for assistance. > > UTF-8 display should be supported by making sure the right LANG and TERM > are set. Input is another issue. EPIC uses ncurses right? No -- epic does everything right off the pty using open() and read() and select() and so forth. You may ask about epic linking against ncurses, but that is because ncurses comes with a terminfo implementation which epic prefers to termcap. One of the things people have mentioned with utf8 support is column counting. It's apparantly no longer valid to assume every byte takes up a column: sometimes multiple bytes make up one column, and sometimes one byte takes up multiple columns. How have others solved this? Then there's issues like how should epic internally store strings, should we use utf16 (wchar_t) from c99? And what if someone is not using a utf-8 terminal emulator, how do i support those? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Does anyone want to volunteer to help me understand utf-8...
and what support for utf-8 would mean for epic5? I understand all of the principles, but what I don't understand is what things are broken in epic5 because of the lack of support, and then what things are at my disposal to "fix" these broken things. I get a lot of requests to support utf-8, but nobody seems to know what is required, and neither do I. So this call for assistance. Thanks, 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] epicsol.org should be ok now
As many of you have known, epicsol.org has been struggling with hardware issues that has caused extensive downtime in the past two weeks. I have completed the first half of an overhaul of the hardware, and this should allow epicsol.org to be stable again and not keep crashing. The second half of the overhaul will probably result in a day's worth of downtime, which will probably occur on the weekend, but won't be happening in the next couple of weeks. Thanks for everybody's patience and understanding! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] About renumbering windows
Presently in epic5, it is not possible to renumber windows that have
channels in them. This is because internally, channels are attached
to windows by refnums, so changing the window refnum requires going
back and changing all the channels. This presumptively requires hooking
/on switch_channels for every affected channel, and having looked at the
topicbar code some of you use, this would probably lead to corruption
(or crashes).
The only real solution I can come up with this after a lot of thinking is
a new /on that hooks to tell you a window has changed refnum. It would
be incumbent upon you, as a scripter, to take whatever steps with your
own data structures to run with it. Specifically, you would not get a
/on switch_channels for all affected channels.
It would work something like this:
/on window_renumber * {...}
where $0 is the old refnum, and $1 is the new refnum.
I am not (necessarily) committed towards this course of action, but I want
to get advice and suggestions before I do something we will all regret. ;-)
Jeremy
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
[EPIC] New EPIC4 and EPIC5 releases available
I am pleased to announce the availability of the fifth EPIC4 production release (epic4-2.4) and the first EPIC5 beta release (epic4-0.2.0): ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.4.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.4.tar.bz2 and ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.2.0.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.2.0.tar.bz2 Because EPIC4 is a mature finished product, the only changes since epic4-2.2 are bug fixes, the most important have to deal with remote crashes by rogue servers. EPIC4 will continue to be maintained for bug fixes only. Because EPIC5 is a (relatively) new product, and this is its first beta release, I hope it will suffice to say that epic5 is signficantly different from epic4, and you should not use an epic4 script with epic5. However, for those of you who have been waiting for a stable release of epic5 to port your scripts to it, now is the time! EPIC5 will continue active development. Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] New epicsol.org now online
As many of you know, and as many of you do not know, I had to bring up a new epicsol.org machine to replace the one that has served us since 1997. This new machine was necessary because it is rack-mounted and the place where I co-locate it (acronet.net) advised me I had to get rid of the old desktop. The new machine is more powerful (naturally) but it is completely new. This means I had to copy everything over from the old machine by hand. Doing this always involves some risk because you might forget something. But I believe that the new machine is now 100% ready and that I've found every nook and cranny and I hereby announce that epicsol.org is back up and ready to go! If you have any problems whatsoever, let me know. There will be new releases for epic4 and epic5 in the next couple of days. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Call for objections to beta release
>On Saturday 21 January 2006 18:22, Jeremy Nelson wrote: >> Unless someone objects to it (ie, by reporting a bug or something), >> I'm going to release epic5-0.2 on February 1st, which will be an >> official stable release which can be used to target scripts >> against. Josh write: >Has this been delayed or am I missing it on the website? This has been delayed because I was asked in late January to bring a new epicsol.org up and ready to be colo'd [1] "as soon as possible", which is basically late february. I'm hoping to release epic5-0.2 after I get the new epicsol.org in production. I am working hard to finish that up by later this week. Thanks for your patience. =) Jeremy [1] The current epicsol.org is a mini tower that sits upon a counter. The new epicsol.org is a regular 2u rack mounted system. ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Call for objections to beta release
A couple of weeks ago I released epic5-0.0.8 which is a stable alpha release that lacks a few features but nothing earth-shattering, on the threat that if epic5 is going to go moribund, I'd better do an official release on it and see if people will bite on it. Unless someone objects to it (ie, by reporting a bug or something), I'm going to release epic5-0.2 on February 1st, which will be an official stable release which can be used to target scripts against. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.0.8 released, beginning towards stable release
Greetings! EPIC5-0.0.8 is now available at: ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.0.8.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/EPIC5-0.0.8.tar.bz2 It has come to my notice that interest in EPIC5 has not been taking off because people are waiting for a stable release. Although there are a lot of features people have asked me to add to EPIC5, I notice that the features I do add aren't being tested (or acknowledged), probably because people are waiting for a stable release to target for their scripts. Ok. So I'm going to blink first. I've decided to impose a feature freeze and this version of EPIC5 is a release candidate for a stable beta. If you want to test EPIC5-0.0.8, to see if it's ready, go ahead. As far as anyone can tell me, epic5 is very stable, just lacking in some features. If I don't hear anything to the contrary, I will release an official stable beta release, epic5-0.1.0, which will be suitable for wide use. Remember, in epic-dom, "alpha" means "probably stable, possibly not", "beta" means "definitely stable, probably lacking some features", and "production" means "stable, and feature-complete". A beta release is ready to rock and roll for scripters. Enjoy! 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] Anyone want to defend "highlight ignores"?
"Highlight Ignores" are a feature that few know about and even fewer use. You set a "highlight ignore" with the + prefix: /ignore +hop ALL /ignore [EMAIL PROTECTED] PUBLICS When you fail to hook any of the following /on's... CHANNEL_NICKCHANNEL_SIGNOFF GENERAL_PRIVMSG GENERAL_NOTICE INVITE JOINKICKMODE MSG MSG_GROUP NICKNOTICE PUBLIC PUBLIC_OTHERPUBLIC_MSG SIGNOFF WALLOP ...the default output from the client will be embelished with a "highlight" controlled by /SET HIGHLIGHT_CHAR. If you hook the above /on's, then highlight ignores are totaly useless. If you use implied on formats, then highlight ignores are totaly useless. Anyways, I hate them. I hate them because 1) They're not ignores, they're anti-ignores. It's confusing. 2) This isn't hard to script, and a lot of people already have! 3) Hardly anybody knows about this feature. 4) Nobody uses this feature that I have ever known about. 5) The code to handle it is icky, and getting in my way. Therefore, unless someone can step up and tell me why they really love this feature and want it to stay, I'm going to remove it. I reserve the right to solicit for a script replacement for it and remove it anyways. Comments, questions, objections? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] On simplifying the mangling of stuff being displayed
Presently, there are 15 (!) /SET's that control how stuff to be displayed gets mangled by the mangler... DISPLAY_ANSIDISPLAY_PC_CHARACTERS EIGHT_BIT BEEPBEEP_MAXTAB_MAX ND_SPACE_MAXINVERSE_VIDEO BOLD_VIDEO BLINK_VIDEO UNDERLINE_VIDEO ALT_CHARSET COLOR ALLOW_C1_CHARS TERM_DOES_BRIGHT_BLINK You all know about the "mangler" sets: MANGLE_INBOUND MANGLE_OUTBOUND MANGLE_LOGFILE For the purposes of "simplification", I am trying to reduce the number of historical curiosities in epic5 that support features that extremely few people actually need, outside of unmitigated curiosity. I propose to remove most or all of these /set's and add a new one, called /SET MANGLE_DISPLAY. We know the mangler directly supports 8 of the 15 /set's, among other things: ANSI/set display_ansi ND_SPACE/set nd_space_max REVERSE /set inverse_video BOLD/set bold_video BLINK /set blink_video UNDERLINE /set underline_video ALT_CHAR/set alt_charset COLOR /set color The 7 that are not directly addressed are: /SET BEEP /SET ALLOW_C1_CHARS I think we could add these two as new mangle types. /SET BEEP_MAX Once upon a time (over 13 years ago), ircII used to beep at you once for each ^G. For the last 13 years, ircII will only beep once per line, no matter how many ^G's there are. While someone could come up with a contrived reason why keeping this might be useful, it is expensive and complicated to support this and would be much simpler to just treat it as though it had the hardcoded value everybody uses (0 -- no limit). I therefore propose to de-support this. /SET TAB_MAX IrcII used to have a hard limit of 2048 bytes (25 screen lines) per logical line of output. It used to be possible for a privmsg with over 250 tabs to exceed the 2048 byte line limit and cause overflow. EPIC has no limitation on logical line size, so this is not an issue for us. It's the same story as BEEP_MAX -- it's expensive and complicated. Hardcoding the default value of 0 (no limit) is not going to cause any real problems. I propose to de-support this. /SET EIGHT_BIT_CHARACTERS This set is meant for those whose terminal emulators are incapable of handling 8 bit data. Such terminal emulators have long since gone into history, and there is no reason why we can't assume that the user has an 8 bit capable terminal. EPIC4 will always be around and supported, and it will always support 7 bit characters, but I propose that in epic5 we no longer worry about compatability with 8-bit-incapable terminals. /SET DISPLAY_PC_CHARACTERS This is used to handle converting 8 bit characters to 7 bit equivalents for people who don't have 8 bit characters. For the same reasons as above, this is a feature that I think should be retired. /SET TERM_DOES_BRIGHT_BLINK I'm not sure what this does, so I'll keep it. I know that knghtbrd says it's very important! Jeremy ___ 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
Re: [EPIC] About changing /exec -out to use /send instead of /say
>On Wed, 2005-08-03 at 10:22 -0500, Jeremy Nelson wrote: >> 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. > >Personally, I think you're not really gaining anything by doing this, >but you are losing something in breaking backwards compatibility. >Consider that, if you currently want to send /exec to the person you're >talking to in a query, you need to do /exec -m ; with >the change, if you were talking in a query and wanted output to go to >the channel, you'd have to do /exec -m instead of /exec -o. >Basically, I don't see any net in making the change. The way it was explained to me by the person who suggested the change was that it was unexpected that you can't use /exec -o to dump to a query, channel or no channel, and if you did have a channel, typing a message would be sent to the query but /exec -o would be sent to the channel, so they claimed it was a POLA violation on both counts. I pledged to bring this matter up for discussion. So I am not trying to persuade you to accept or reject this proposal, only to get your honest opinion, and I do thank you for being willing to offer it. =) Does anyone else wish to offer their opinion on this before I table it? 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] First Call For Bugs to be Fixed in EPIC4
This email starts the process of the next release of EPIC4, epic4-2.4. You are hereby requested to send me any bugs you know of in epic4 that need to be fixed before the next release. If no bugs are reported within a couple of weeks, then the current cvs version of epic4 will be released as epic4-2.3.1. I don't know yet whether there is interest in holding a vote, or whether the changes since epic4-2.2 are so minor as not to warrant it. Advice and council is welcome. 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
Re: [EPIC] [RFD] On loading startup scripts before connecting...
>* At 2005-05-15T15:47-0500, Jeremy Nelson wrote:
>:
>| 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.
>
>Another alternative is to add an .epicrc or something that would get
>loaded right away, and leave the .ircrc behaviour as it is. Since, I
>imagine, you'd want that sometimes.
One option that has been presented is to help people wrap their startup
scripts to simulate backwards compatability, to wit:
on #^connect -1 * {
... your old ircrc goes here ...
@hookctl(remove -1)
}
This would give a reasonable approximation of present behavior...
Jeremy
___
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] New EPIC release, epic5-0.0.5
EPIC5-0.0.5 is now available (well, it was released last week), and is now available at: ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.5.tar.bz2 ftp://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.5.tar.gz http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.5.tar.bz2 http://ftp.epicsol.org/pub/epic/EPIC5-ALPHA/epic5-0.0.5.tar.gz This is the fifth alpha release of epic5 and includes the following signficant changes, the most noteworth of which is the movement of a large number of hardcoded builtin functions to script implementations which can now be tweaked and customized to your heart's content! * Change the scary "ERROR --" messages to "INFO --" and hide for dcc and exec. * Remove hardcoded limits on size of status expandos * Built in history has been moved to a script implementation * Translation support fixed for russian users * Very many commands, functions, sets, moved from builtin to 'builtins' script. * A new "loadformats" script to use implied on hooks. * Bug fixes and a multitude of smaller changes... Enjoy! Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Request for comments: New math parser default in epic5
The new math parser was first written about 7 years ago and hasn't had any significant changes for 2 years, despite rather signficant use by several scripts. So it's stable. It hasn't been turned on by default because it's not backwards compatable (natch), and some people have depended upon the bugs in the old math parser. However, it has always been expected we would flip the two, and the new math parser would be the default and you'd have to /xdebug old_math to get the old math parser. It seems that this might be the time to do this change-over. This means that going forward, epic5 scripts need to be new_math compatable. Does anyone have any comments they'd like to make about this before it happens? Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Request for discussion, to change /on leave to /on part
I do not know why /on leave was named what it was, but it is mis-named and causes me grief for people who are looking for a way to hook PARTs. In epic5, we have scripted the /leave command, so that puts one more nail in the coffin of the word "leave" as a substitute for "part". My proposal is that in epic5, we change /on leave to /on part to better reflect its purpose. This will be a backwards incomaptable change. I would prefer to just cut this over, but if many people object, I will try to device some system where a single on type can have multiple names, which automagically get converted to the canonical name. If nobody really cares about /on leave enough to want to keep it around, we should ditch it. Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] epic5 RPMs are now available
>The one question I have to Jeremy - is the wserv4 binary that is in >epic5 the same as in the older epic4? Right now, there is a conflict >between the two rpms because they both want to provide wserv4. That's correct. If I ever make any changes to wserv.c that make it imcompatable with wserv4, the new binary will be called wserv5. The wserv4 binary used by epic4 and epic5 is identically the same. 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=). 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
Re: [EPIC] To remove all restrictions on /QUOTE, even when dangerous...
>On Fri, 2005-02-11 at 10:22, Jeremy Nelson wrote: >> Presently, EPIC does not permit >> >> /QUOTE WHO Kevin wrote: >My only problem with the restriction on "/quote who" is that it's a bit >difficult to use, say, some of Undernet's /WHO extensions, particularly >together. As a POLA issue, yes, I can understand why /quote who would be desirable. That's I guess one reason why I'm not so hung up on this as I was a year ago. If someone does want to do something dangerous, then I guess that's up to them. (Just as a side note to the public, /who -literal is the "safe" version of /quote who , but I guess it's not real well known about.) Jeremy ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] To remove all restrictions on /QUOTE, even when dangerous...
Presently, EPIC does not permit /QUOTE ISON /QUOTE USERHOST /QUOTE WHO /QUOTE NICK /QUOTE QUIT /QUOTE SERVER for various technical reasons which are included at the bottom of this email. Various people have asked me to rescind these restrictions and allow the full unfettered use of all of the above. However, the use of the above is fraught with peril, and will result in undefined behavior up to and including crashing, which I accept as "normal" behavior. Therefore, it is proposed that all restrictions on prohibition of /quote be removed, and in place of a hard restrction, an ominous warning along the lines of "doing this will break your client. you have been warned" will be output instead. Any behavior whatsoever, up to and including crashing, would be considered "normal behavior" resultnig from the above. Crashes resulting from the use of the above will not be considered bugs. Comments? Jeremy -- /QUOTE ISON, /QUOTE USERHOST, and /QUOTE WHO interfere with epic's built in ison/userhost/who queue. If you do /quote the above, epic may malfunction in the following ways: 1) Notify may stop working 2) Userhost caching may stop working 3) /USERHOST -CMD may stop working 4) /WHO -LINE may stop working 5) /DCC CLOSE may stop sending DCC REJECTs 6) Numerics for ison, userhost, and who may stop working /QUOTE NICK interferes with epic's built in nickname tracking, which attempts to ensure that epic always knows what your "real" nickname is. If you do /quote nick, epic may malfunction in the following ways: 1) The status bar may stop working 2) Further nick changes may be dishonored /QUOTE QUIT interferes with epic's built in reconnection strategies. Since EPIC5 doesn't attempt to do anything when you're disconnected, this is probably OK to change, and I don't object to it. /QUOTE SERVER is a violation of the rfc protocol 4.1.4: The SERVER message must only be accepted from either (a) a connection which is yet to be registered and is attempting to register as a server, or (b) an existing connection to another server, in which case the SERVER message is introducing a new server behind that server. ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] EPIC5-0.0.3 now available
The third alpha release of EPIC5, EPIC5-0.0.3 is now available at ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.0.3.tar.gz ftp://ftp.epicsol.org/pub/epic/EPIC5-BETA/epic5-0.0.3.tar.bz2 This version has been in development for 10 months (has it really been that long?) and has an embarrasingly large number of changes since the last release (I really should release more often). This version is pretty stable, so if you've been waiting to check out epic5, have this version a try! Let me know if you run into any problems. Obligatory warning -- epic5 is a different than epic4 in a lot of very important ways. You might want to read the UPDATES file to get a leg up on the kinds of changes you should be expecting. Running an epic4 script with epic5 will meet with some breakage. Perhaps some souls will start porting their scripts to 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 via http as well
EPIC4-2.2 is also available via http at http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.2.tar.gz http://ftp.epicsol.org/pub/epic/EPIC4-PRODUCTION/epic4-2.2.tar.bz2 Those who package up epic whereby the end user downloads the source code and compiles it themselves are encouraged to consider using http instead of ftp since it doesn't have the user limit restrictions that passive mode ftp users do with our firewall. Jeremy ___ List mailing list [EMAIL PROTECTED] 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] New Release Candidate available, EPIC4-2.1.2
A rather significant bug was found in the prior release candidate relating to non-terminated double quoted words with /xdebug extractw turned on (it was a panic). So after fixing this bug, I am making a new version of the release candidate, so everyone that is allergic to CVS will have a chance to test (and vote upon) the current release candidate. I talked with most (all?) of those who have already voted [all 5 of you] and nobody seemed to have any objection to continuing the vote. So I will not restart the vote -- it still stands at 5-0. The vote stays open until it reaches 15-0. This will be as long as it needs to be, even if it is a year. It is entirely in your hands when epic4-2.2 will be released. So please test this release candidate and affirm your support for it. =) 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] Progress of Call for Votes (3-0)
For those who are not familiar with the voting procedure, if you have tested epic4-2.1.1, and have found it to be substantially without defect, and you're willing to publicly go on the record to say that, you may vote. *Everyone* who tests epic4-2.1.1 is eligible to vote, no matter who you are or what your "qualifications" are. The voting remains open until the vote reaches 15-0. This means 15 people vote Aye, and will have their names put into the VOTES file that will ship with epic4-2.2. If any proper NO votes are receieved, this is considered a "block" and the release will not occur until the problem is fixed, or substantially reasonable steps have been taken to minimize the problem. A proper NO vote indicates a specific, particular, reproducable problem that substantially limits EPIC in some way (eg, a crash). An improper NO vote would be along the lines of asking for a feature to be added, or disagreeing over whether a feature should behave the way it does. I always promise to exercise good faith in trying to determine if a NO vote is proper. (Yes, I have gotten improper NO votes in the past by people who were trying to be difficult, and I've had to ignore them. I don't like to do this, though.) Right now the vote is 3 votes AYE and 0 votes NO. The election stands open until the vote is 15-0. This will take as long as necessary. EPIC4-2.0 took a month to pass the vote. I wouldn't be suprised if EPIC4-2.2 took that long. If you've voted, I ask for your patience. If you've not voted, then test it and vote! Jeremy ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC] First Call For Votes of confidence in EPIC4-2.1.1
* The candidate release was made available on 2004-10-07 * A motion for a call of votes of confidence was made on 2004-10-10 by sirex * A call for votes of confidence was made on Oct 10, 2004-10-10 by BlackJac * The election will continue until completed, but in no case will it end before 2004-10-13 * The release will occur 2 days after the election ends, but in no case will it occur before 2004-10-15 *** ** 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-2.1.1 (as amended, a/k/a commit 721) and being made available at: ftp://ftp.epicsol.org/pub/epic/EPIC4/EPIC4-BETA/epic4-2.1.1.tar.gz (with one cvs update) 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
[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
[EPIC] [EPIC-PARTY] Change of venue, time
Due to lack of enthusiasm about the previous locale, the epic 10th anniversary party has been changed to the afternoon of Sep 18th (THIS SATURDAY) and will be held at The Good Time Emporium (goodtimeemporium.com), in Somerville, near the airport and Cambridge. The Good Time Emporium 30 Assembly Square Dr Somerville, MA 02145-1307 Everyone is of course welcome to come and bring friends. If you are coming, if you drop me an email, I'll make sure we look for you. =) 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 meet&greets 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] 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] [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] Second call for errata for epic4-2.0
The six-month window for a new epic4 production release is coming up. If there is anything about epic4-2.0 that annoys you that you feel should be changed, now is the time to tell me about it! I will make all (small) requested changes that do not break other things horribly, and then release a candidate release and go through the voting process. I would like to have a candidate release by August 6th, and the voting over and done with by the end of August. Of course, all this is driven by your requests, and participation. If nobody asks me for any changes, then there won't be any! (And this won't be my fault. ;-) 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
