Re: [EPIC] I want to change "CRAP" to "OTHER" in epic5
On Wed, 2004-03-10 at 16:07, Chip Norkus wrote: > Operwalls are delineated only by a prefix in the WALLOPS message (when sent > to users). In fact it would be trivial to fake an operwall by simply > applying this prefix to a standard wallops message. The client has no way > of determining if this is really an operwall or not, a script is better > suited to this. It would be better if scripts could simply create their > own log levels (beyond just USER1-USER4, levels with their own names etc). This isn't quite correct. Oper wallops are differentiated from *local* oper wallops by that prefix, and it is done by issuing a /whois or /userhost (I'm not sure which EPIC is using these days). The client itself adds the prefix, not the server. (Undernet's '*' and '$' prefixes are a little more specialized...) It would be very easy for the client to differentiate an *operator* wallops from a *server* wallops: is the origin a user or a server? -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [EPIC] I want to change "CRAP" to "OTHER" in epic5
On Wed, 2004-03-10 at 17:10, Chip Norkus wrote: > > This isn't quite correct. Oper wallops are differentiated from *local* > > oper wallops by that prefix, and it is done by issuing a /whois or > > /userhost (I'm not sure which EPIC is using these days). The client > > itself adds the prefix, not the server. (Undernet's '*' and '$' > > prefixes are a little more specialized...) > > > > I'm speaking of the prefix to the message itself. The client will get > something like: > :foo WALLOPS :this is a wallops message > on regular wallops and > :foo WALLOPS :OPERWALL - this is an operwall message > on operwalls. There's nothing preventing me from doing > '/wallops OPERWALL - HA HA FOOLED YOU'. I don't know of any ircd that does this, but my range of experience is rather limited. -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part
Re: [EPIC] EPIC 10th anniversary party
On Thu, 2004-04-22 at 23:58, Jeremy Nelson wrote: > There will be an EPIC 10th anniversary celebration in September in Boston. > Tentatively for now, the date is penciled in as Saturday September 18th. > If you are interested in being included in the planning of this event > throughout the summer, let me know one of these weeks and everyone who > wants can help figure out things like how people will get there, where > everyone will stay, that sort of thing. I'll be flying in for the event, > so you'll have to put up with me. :P Cool; I won't even have to do any traveling :) -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ List mailing list [EMAIL PROTECTED] 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 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. (I frequently want to look up everyone using a particular IP, which would look like "/quote who xi" in pre-restriction clients.) The options that EPIC has don't seem to cover all the possibilities. Also, Undernet's /WHO has a syntax that lets the user specify the fields which they want to see, and I could see an oper using that for some scripting--but the EPIC restrictions make it difficult to use that extension. (Moreover, that use shouldn't affect EPIC's standard who queue, since when that extension is used, ircu uses a different numeric in its reply specifically to avoid confusing clients and scripts.) From a purist standpoint, though, any restriction on /quote seems bad. The /quote mechanism is intended to allow a knowledgeable user to do things that the client does not have specific support for. Putting restrictions on it seems to me to be making policy decisions for the user. As to how to resolve the who queue issue, I don't really have any answers to that. Perhaps a /set to turn it on and off and a set of built-ins to manipulate it from a script? That way, a knowledgeable user can do stuff guaranteed to break the queue, but protect it by turning it off or manipulating it to restore integrity? -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Request for comments: New math parser default in epic5
On Thu, 2005-04-21 at 07:21 -0700, Jeremy Chadwick wrote: > Purely out of curiousity: is this new parser libgmp? If not, have you > considered using libgmp? Hell, I don't even know what libgmp "really > does", other than act as some IEEE-oriented math library... ;-) libgmp does math, not math parsing. (In particular, libgmp is a library capable of representing arbitrarily many digits of a floating point number and operating on it; it can be quite useful for encryption schemes like RSA, which entail turning a message into a huge number and raising it to exponents modulo another huge number...) -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] [RFD] On loading startup scripts before connecting...
On Sun, 2005-05-15 at 15: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. > > Please share how you feel about this change. I recently coded support into my script for randomizing my nick (and suspending channel joins) until I can log in to the Undernet channel service and activate host hiding. There were several things that made this difficult to do, and one of them is remembering to pass -B to epic when I start it. So, in summary, I'm in favor of making -B be the default. -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Judy Arrays
On Thu, 2006-08-10 at 07:15 -0500, Jeremy Nelson wrote: > 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] And I think I should point out my Database Primitives (dbprim) library, which I originally wrote for replacing ircu's database. It includes doubly-linked lists, hash tables, sparse matrices (for managing user-on-channel associations and the like), and red-black trees (for cases where you need efficient searching and ordered display)...take a look at http://www.sourceforge.net/projects/dbprim/ -- Kevin L. Mitchell <[EMAIL PROTECTED]> signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC Cache developers
On Mon, 2009-01-12 at 09:50 -0800, Scott Bruman wrote: > I am eager to locate a strong EPIC Developer for a high profile > project at a leading healthcare company in the San Francisco Bay area. > See below for details… First of all, you are an idiot. Second of all, I doubt *any* of us on this list care to see these kinds of advertisements sent to the list--in other words, DON'T SPAM US. Third, *this* EPIC is an IRC client, not a cache--which is why I'm calling you an idiot, because you've clearly failed to do your homework. -- Kevin L. Mitchell signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] im building an rpm for epic 5
On Fri, 2009-07-10 at 14:47 -0500, Jeremy Nelson wrote: > >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? DESTDIR comes from GNU Automake, I believe. Basically, it's a Makefile variable that is prepended to all installation paths--i.e., if you're installing /usr/bin/epic, you'd use something like "$(DESTDIR)/usr/bin/epic" as the installation path, and have DESTDIR set to an empty string near the top of Makefile. DESTDIR is not set by configure, nor should anything other than the installation rules in Makefile care about it; typical usage is "make install DESTDIR=/tmp/install" As for why you might want DESTDIR--RPMs generally want the files to be installed in a staging area which contains *only* the files from the package, but with paths corresponding to where the files should actually go--i.e., if your staging area is /tmp/install, you want /usr/bin/epic to show up in /tmp/install/usr/bin/epic. DESTDIR obviously makes this very easy to do. -- Kevin L. Mitchell signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] im building an rpm for epic 5
On Fri, 2009-07-10 at 19:56 -0700, Zach White wrote: > If you're taking votes, my vote is to leave it as is. It's simply an > arbitrary label, and IP works as well as DESTDIR for that purpose. > While I do think DESTDIR is the better name to have chosen from the > beginning, it's hardly worth making everyone who's already packaging > epic change their packages. Or add this to Makefile.in: DESTDIR = IP = $(DESTDIR) That way, anyone who wants to use IP can, and anyone who wants to use DESTDIR can :) (Of course, pay attention to those patches; looks like there are a couple of places where it needs to be added...) -- Kevin L. Mitchell signature.asc Description: This is a digitally signed message part ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
