Re: [EPIC] Learning EPIC5; alias differences
Thanks much for this -- works like a charm! :-) I was just starting to
read the Wiki page on arguments, then I got your mail...
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
On Wed, Feb 20, 2008 at 10:04:26AM +0100, Jonas Trollvik wrote:
> If you do it like this:
> /alias t (args) {//topic $args;}
> it will not change the behaviour.
>
> Also you should not check ifs like if ( [$0]) since if you would try
> to do /t 0 the if would evaluate that to false. Instead do if ( @ ) or
> if ( # )
> (@ expands to strlen and # expands to word count)
>
> Best Regards
> Jonas / kreca
> On 2/20/08, Jeremy Chadwick <[EMAIL PROTECTED]> wrote:
> > I've been tinkering around with EPIC5 for a few days, and there's one
> > difference which has been the source of some confusion for me. Take
> > for example the following alias on EPIC4/ircII:
> >
> > alias t //topic
> >
> > This has two capabilities: a user can type "/t" and see what the current
> > topic is and when it was set, or they can type "/t hello bob" and set
> > the current topic.
> >
> > This alias breaks on EPIC5, with "/t" by itself setting the topic to
> > literally nothing. The only solution I found was to do this, which
> > seems a bit unnecessary:
> >
> > alias t { if ([$0]) { //topic $* } { //topic } }
> >
> > Is there a more intelligent way of accomplishing what used to "just
> > work" in EPIC4?
> >
> > --
> > | Jeremy Chadwickjdc at parodius.com |
> > | Parodius Networking http://www.parodius.com/ |
> > | UNIX Systems Administrator Mountain View, CA, USA |
> > | Making life hard for others since 1977. PGP: 4BD6C0CB |
> >
> > ___
> > List mailing list
> > List@epicsol.org
> > http://epicsol.org/mailman/listinfo/list
> >
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
[EPIC] history script; bizarre input behaviour
The history script in EPIC5 0.3.5 behaves oddly for me. "Oddly" means it behaves quite differently from EPIC4, ircII, and BitchX. I'm using this in my .ircrc: load history set history_persistent off set history_circleq off bind ^[[A BACKWARD_HISTORY bind ^[[B FORWARD_HISTORY bind ^P BACKWARD_HISTORY Upon launching the client, I manually type in two commands: /nick hello /join #foobarblat At this point, I'll document exactly what I see depending upon what keys are pressed, in linear/respective order: (Up-Arrow) (Up-Arrow) (Down-Arrow) /join #foobarblat (Up-Arrow) /nick hello (Up-Arrow) (Down-Arrow) /join #foobarblat (Down-Arrow) (Up-Arrow) (Down-Arrow) /join #foobarblat The behaviour I would have expected is: (Up-Arrow) /join #foobarblat (Up-Arrow) /nick hello (Down-Arrow) /join #foobarblat (Up-Arrow) /nick hello (Up-Arrow) (Down-Arrow) /join #foobarblat (Down-Arrow) (Up-Arrow) /join #foobarblat (Down-Arrow) I don't see any changes in UPDATES between 0.3.5 and 0.3.7 which would indicate any fixes, so I'm confused. :-) -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] Learning EPIC5; alias differences
I've been tinkering around with EPIC5 for a few days, and there's one
difference which has been the source of some confusion for me. Take
for example the following alias on EPIC4/ircII:
alias t //topic
This has two capabilities: a user can type "/t" and see what the current
topic is and when it was set, or they can type "/t hello bob" and set
the current topic.
This alias breaks on EPIC5, with "/t" by itself setting the topic to
literally nothing. The only solution I found was to do this, which
seems a bit unnecessary:
alias t { if ([$0]) { //topic $* } { //topic } }
Is there a more intelligent way of accomplishing what used to "just
work" in EPIC4?
--
| Jeremy Chadwickjdc at parodius.com |
| Parodius Networking http://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. PGP: 4BD6C0CB |
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
Re: [EPIC] On removing /set reverse_status_line
Remove it. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | On Sun, May 13, 2007 at 12:28:54PM -0500, Jeremy Nelson wrote: > > 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 ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] On reverse status bars and /set reverse_status_line
On Tue, Oct 03, 2006 at 05:05:09PM +0200, Stanislaw Halik wrote: > There are users depending on EPIC being as closely compatible to ircII > as possible. Gratuitous incompatibilities shouldn't be introduced. I > believe this kind of change would be a gratuitous incompatibility. /SET > REVERSE_STATUS_LINE neither halts EPIC development nor is a considerable > code bloat. My opinion goes both ways: I'd both like to see it gone, and like to see it kept for compatibility. If I had to make a choice, I'd vote for removing it. As far as I'm concerned, EPIC 5 is "less compatible" with ircII than EPIC 4 is -- and if I remember right, this has been stated by Jeremy a couple of times. Therefore I have no qualms seeing it removed in 5, but obviously kept in 4. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
[EPIC] epic5-0.2.0 Solaris 9 build problems -- missing strtoimax(3)
Seems strtoimax() is missing on Solaris. Is GNU autoconf
picking this up correctly? It doesn't seem so. Either
that or the "craziness" in include/irc_std.h and include/ircaux.h
are still using strtoimax() regardless.
System information:
SunOS XXX 5.9 Generic_117172-08 i86pc i386 i86pc
gcc version 2.95.2 19991024 (release)
GNU ld version 2.13
Link error:
gcc -g -O -o epic5 alias.o alist.o array.o clock.o commands.o compat.o crypt.o
ctcp.o dcc.o debug.o exec.o files.o flood.o functions.o gailib.o glob.o hook.o
if.o ignore.o input.o irc.o ircaux.o ircsig.o keys.o lastlog.o levels.o list.o
log.o logfiles.o mail.o names.o network.o newio.o notify.o numbers.o output.o
parse.o queue.o reg.o screen.o sdbm.o server.o ssl.o status.o term.o timer.o
translat.o vars.o who.o window.o words.oinfo.o -lcurses -L/usr/ccs/lib
-lsocket -lnsl -lresolv -lcrypt -lm
Undefined first referenced
symbol in file
strtoimax alias.o
ld: fatal: Symbol referencing errors. No output written to epic5
Other information:
bash-2.03$ grep -i strtoimax include/defs.h*
include/defs.h:/* Define this if you have a strtoimax() */
include/defs.h:/* #undef HAVE_STRTOIMAX */
include/defs.h.in:/* Define this if you have a strtoimax() */
include/defs.h.in:#undef HAVE_STRTOIMAX
config.log details:
configure:4528: checking for intmax_t in inttypes.h or stdint.h
configure:4543: stdint.h: No such file or directory
configure:4561: checking for strtoimax
configure:4589: gcc -o conftest -g -O conftest.c -lcurses -L/usr/ccs/lib
-lsocket -lnsl -lresolv -lcrypt -lm 1>&5
Undefined first referenced
symbol in file
strtoimax /var/tmp/cc7vkkII.o
ld: fatal: Symbol referencing errors. No output written to conftest
collect2: ld returned 1 exit status
configure: failed program was:
#line 4566 "configure"
#include "confdefs.h"
/* System header to define __stub macros and hopefully few prototypes,
which can conflict with char strtoimax(); below. */
#include
/* Override any gcc2 internal prototype to avoid an error. */
/* We use char because int might match the return type of a gcc2
builtin and then its argument prototype would still apply. */
char strtoimax();
int main() {
/* The GNU C library defines this for functions which it implements
to always fail with ENOSYS. Some functions are actually named
something starting with __ and the normal name is an alias. */
#if defined (__stub_strtoimax) || defined (__stub___strtoimax)
choke me
#else
strtoimax();
#endif
; return 0; }
--
| Jeremy Chadwick jdc at parodius.com |
| Parodius Networkinghttp://www.parodius.com/ |
| UNIX Systems Administrator Mountain View, CA, USA |
| Making life hard for others since 1977. |
___
List mailing list
List@epicsol.org
http://epicsol.org/mailman/listinfo/list
Re: [EPIC] About changing /exec -out to use /send instead of /say
I'm in agreement with Jeremy's original proposal. If you have an open /query, /exec -o should most definitely be going there; not doing so is unintuitive, despite "years of common IRC practise". And before someone proposes it: I also strongly object to a /set variable to define the behaviour of /exec -o with an open /query. Not that my word rules above anyone elses, but such a toggleable defeats my entire argument. Changing this in EPIC5 would be OK, but (if you're still working on it) for EPIC4, leave the old behaviour. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Aug 04, 2005 at 11:57:39AM -0500, Jeremy Nelson wrote: > >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 ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] FreeBSD and epic ports
Josh, The ports will only add support for SOCKS5 if you define WITH_SOCKS5. If you don't want SOCKS5 support, make sure WITH_SOCKS5 isn't defined (be sure to check your make.conf as well). If you DO want SOCKS5 support enabled for epic[45] via ports, you're going to have to go through the rigamaroll you mentioned (re: finding SOCKS5 source, etc.). Seems the official SOCKS[45] site is quite annoying, I'll agree. Might try using www.filesearch.ru instead: http://www.filesearch.ru/cgi-bin/s?q=socks5-v1.0r11.tar.gz&t=f&w=a&x=21&y Good luck. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Sun, May 29, 2005 at 03:58:13PM -0500, Josh Paetzel wrote: > The epic4 and epic5 ports on FreeBSD have an option to include in > SOCKS5 support. The licensing for SOCKS5 does not allow binary > download. One cannot automagically download the sources either. You > have to fill out a web-based registration, download the tarball and > then manually put it into the /usr/ports/distfiles on your FreeBSD > machine. There are other ports that get treated similar to this > situation. The problem is that I can no longer find a place to > download the SOCKS5 sources from legitimately. > > My question is this: Do I need to move heaven and earth to get SOCKS5 > working again, or can I simply remove the option from the port? > > -- > Thanks, > > Josh Paetzel > > ___ > List mailing list > List@epicsol.org > http://epicsol.org/mailman/listinfo/list ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Request for comments: New math parser default in epic5
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... ;-) Food for thought. And I hate math, by the way. -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Thu, Apr 21, 2005 at 08:00:07AM -0500, Jeremy Nelson wrote: > 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 ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
Re: [EPIC] Request for discussion, to change /on leave to /on part
Agreed entirely (and for many identical reasons ;) ). -- | Jeremy Chadwick jdc at parodius.com | | Parodius Networkinghttp://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. | On Tue, Apr 19, 2005 at 02:39:56PM -0400, Ben Winslow wrote: > On Tue, 2005-04-19 at 12:34 -0500, Jeremy Nelson wrote: > > 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 > > I propose epic5 be fairly gung-ho about backwards-incompatible changes. > I'd hate for epic to become the x86 of IRC clients. ;) > > -- > Ben Winslow <[EMAIL PROTECTED]> > > > ___ > List mailing list > List@epicsol.org > http://epicsol.org/mailman/listinfo/list ___ List mailing list List@epicsol.org http://epicsol.org/mailman/listinfo/list
