Re: [EPIC] EPIC 10th annivesary party -- Sepetember 18th evening, Boston
On Aug 31, 2004, at 4:43 PM, Jeremy Nelson wrote: 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! DAMMIT! Conflict! The 18th is Mixfest. Anyway, I'd suggest something in Cambridge, either the CBC (for beer) or Flattops (for pool and beer). The CBC is probably better for talking and drinking, as they have a room towards the back with large tables. Both are in the 1 Kendall Square complex, which is about a 5 minute walk from the Kendall T stop on the Redline, and has a parking garage in the back. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC] EPIC 10th annivesary party -- Sepetember 18th evening, Boston
On Aug 31, 2004, at 6:53 PM, [EMAIL PROTECTED] wrote: I was thinking redbones in davis square myself. redbones is great for eating. Finding seating for 15 people and being able to talk above the noise might be a little tricky -- Monte On Tue, Aug 31, 2004 at 05:35:28PM -0400, John Payne took a crayon and proceeded to scribble outside of the lines: :) :) On Aug 31, 2004, at 4:43 PM, Jeremy Nelson wrote: :) :) 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! :) :) DAMMIT! Conflict! The 18th is Mixfest. :) :) Anyway, I'd suggest something in Cambridge, either the CBC (for beer) :) or Flattops (for pool and beer). The CBC is probably better for :) talking and drinking, as they have a room towards the back with large :) tables. :) :) Both are in the 1 Kendall Square complex, which is about a 5 minute :) walk from the Kendall T stop on the Redline, and has a parking garage :) in the back. :) :) :) ___ :) List mailing list :) [EMAIL PROTECTED] :) http://epicsol.org/mailman/listinfo/list ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]notify interval proposal
I've been frustrated for awhile with the fact that epic doesn't allow you to easily modify the notify interval. From what I can tell, epic doesn't allow you any more precision than minutes in the notify interval, and it refuses to accept a value of under a minute. There's a couple of things I'd like to see changed in epic's notify system. First off, I'd like to see more precision; I'd prefer to be able to set this value in seconds, not just in minutes. Secondly, I'd like to see the lower limit completely abolished. The /timer command has no lower limit, why should the notify system? While power users may be able to to change this behavior by making their own modifications to epic's source code, it is mildly annoying, and not everybody can do this. I'd like to see epic's notify system behave the way I've described by default. Please send back your feedback on this issue, whether you're in agreement, disagreement, or even if you're ambivalent towards the issue. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
Re: [EPIC]notify interval proposal
I'd assume that most users who would set notify_interval, would know what they're doing, but I may be wrong. I can certainly see the scenario in which a new user who likes to experiment, unsuspectingly sets this to what most would consider an unreasonable value (such as 1), but I also assume even the most unfamiliar user to epic would be more cautious than that, and realize that tinkering with things without realizing their purpose can have consequences. Nonetheless, I can certainly see why Jeremy sees it prudent to enforce a lower limit here. But at the very least, I would like to see what I would consider a more reasonable lower limit (20-30 seconds, perhaps). I wouldn't consider that too unreasonable since the majority of the IRC population is probably mIRC clients, and they all use a 30 seconds interval. ___ List mailing list [EMAIL PROTECTED] http://epicsol.org/mailman/listinfo/list
[EPIC]Perl patch..
The perl patch is there again because the old one doesn't work with
the new string patch. You have to run autoconf and use the --with-perl
switch with configure. It seems that it requires perl 5.6 or 5.6.1 to
build. This has to be sorted out yet.
diff -ruN ../epic4-1.0.1/acconfig.h ./acconfig.h
--- ../epic4-1.0.1/acconfig.h Tue Dec 5 11:11:56 2000
+++ ./acconfig.hThu Sep 20 09:56:20 2001
@@ -192,6 +192,11 @@
#undef Rlisten
#undef Rselect
+/*
+ * Perl support.
+ * /
+#undef PERL
+
/* Define this is DIRSIZ takes no argument */
#undef DIRSIZ_TAKES_NO_ARG
diff -ruN ../epic4-1.0.1/configure.in ./configure.in
--- ../epic4-1.0.1/configure.in Tue Dec 5 11:11:56 2000
+++ ./configure.in Thu Sep 20 09:56:20 2001
@@ -366,6 +366,32 @@
)
dnl --
+dnl
+dnl Perl support?
+dnl
+
+AC_MSG_CHECKING(whether to support Perl)
+AC_ARG_WITH(perl,
+[ --with-perl[=PATH] Compile with perl support.],
+[ case $withval in
+ no)
+ AC_MSG_RESULT(no)
+ ;;
+ *)
+ if test x$withval != xyes; then
+ LIBS=$LIBS -L$withval
+ fi
+
+ AC_MSG_RESULT(yes)
+ LIBS=$LIBS `perl -MExtUtils::Embed -e ldopts`
+ PERLDOTOH=perl.o
+ AC_DEFINE(PERL)
+ ;;
+ esac ],
+ AC_MSG_RESULT(no)
+)
+
+dnl --
dnl --
dnl
dnl closing stuff
@@ -381,6 +407,7 @@
if test -z $CFLAGS; then CFLAGS=-g -O; fi
if test -z $LDFLAGS; then LDFLAGS= ; fi
+if test -z $PERLDOTOH; then PERLDOTOH= ; fi
if test -z $bindir; then bindir=\${prefix}/bin; fi
if test -z $libdir; then libdir=\${prefix}/lib; fi
if test -z $irclibdir; then irclibdir=\${libdir}/irc; fi
@@ -414,6 +441,7 @@
AC_SUBST(CFLAGS)
AC_SUBST(LDFLAGS)
+AC_SUBST(PERLDOTOH)
AC_SUBST(bindir)
AC_SUBST(irclibdir)
AC_SUBST(libexecdir)
diff -ruN ../epic4-1.0.1/include/array.h ./include/array.h
--- ../epic4-1.0.1/include/array.h Tue Dec 5 11:11:57 2000
+++ ./include/array.h Thu Sep 20 09:56:20 2001
@@ -31,3 +31,9 @@
char * function_gettmatch (char *);
#endif
+
+typedef struct an_array_struct {
+char **item;
+long *index;
+long size;
+} an_array;
diff -ruN ../epic4-1.0.1/include/defs.h.in ./include/defs.h.in
--- ../epic4-1.0.1/include/defs.h.inTue Dec 5 11:11:57 2000
+++ ./include/defs.h.in Thu Sep 20 09:56:20 2001
@@ -181,6 +181,11 @@
#undef Rlisten
#undef Rselect
+/*
+ * Perl support.
+ */
+#undef PERL
+
/* Define this if you have setsid() */
#undef HAVE_SETSID
diff -ruN ../epic4-1.0.1/source/Makefile.in ./source/Makefile.in
--- ../epic4-1.0.1/source/Makefile.in Thu Mar 15 07:01:46 2001
+++ ./source/Makefile.inThu Sep 20 09:56:20 2001
@@ -17,7 +17,7 @@
ircsig.o keys.o lastlog.o list.o log.o mail.o names.o network.o \
newio.o notice.o notify.o numbers.o output.o parse.o queue.o reg.o \
screen.o server.o status.o term.o timer.o vars.o who.o window.o \
- words.o @ALLOCA@
+ words.o @PERLDOTOH@ @ALLOCA@
INCLUDES = -I@srcdir@/../include -I../include
@@ -73,6 +73,9 @@
screen.o: Makefile ../Makefile
$(CC) $(CFLAGS) $(ANSIFLAGS) $(INCLUDES) -c @srcdir@/screen.c \
-DWSERV_PATH=\$(INSTALL_WSERV)\
+
+perl.o: perl.c Makefile ../Makefile
+ $(CC) $(CFLAGS) $(ansiflags) $(INCLUDES) -c perl.c `perl -MExtUtils::Embed -e
+ccopts`
#
diff -ruN ../epic4-1.0.1/source/array.c ./source/array.c
--- ../epic4-1.0.1/source/array.c Tue Dec 5 11:11:56 2000
+++ ./source/array.cThu Sep 20 09:56:20 2001
@@ -173,11 +173,13 @@
#define ARRAY_THRESHOLD100
+#if 0
typedef struct an_array_struct {
char **item;
long *index;
long size;
} an_array;
+#endif
static an_array array_info = {
(char **) 0,
@@ -356,6 +358,63 @@
}
/*
+ * This was once the inner loop of SETITEM.
+ * The documentation for it still applies.
+ */
+int set_item (char* name, long item, char* input)
+{
+ long index = 0;
+ long oldindex;
+ an_array *array;
+ int result = -1;
+ if (array_info.size ((index = find_item(array_info, name)) = 0))
+ {
+ array = array_array[array_info.index[index]];
+ result = -2;
+ if (item array-size)
+ {
+ oldindex = find_index(array, item);
+ index = find_item(*array, input);
+ index = (index = 0) ? index : (-index) - 1;
+ move_index(array, oldindex, index);
+ new_free(array-item[item]);
+ malloc_strcpy(array-item[item], input);
+ result = 0;
+ }
+ else if (item == array-size)
+ {
+ RESIZE(array-item, char *, array-size + 1);
+ array-item[item] = (char *) 0;
+
[EPIC]String handling speedups and realloc() issues.
This patch does two things...
First, it replaces new_realloc() with one that actually calls realloc(),
using new_malloc() as a template. This has a big impact on performance
for string append functions because realloc typically does a whole lot
of good stuff to prevent the block being copied when it doesn't have to
be.
Secondly, it renames the 4 m_*3cat* functions with a new argument to
point to the end of the string, and #defines the old names to point to
the new with a token extra argument.
The impact of both of these is that the performance of certain functions
which call them repeatedly is greatly improved.
The design of the last one isn't so great. Instead of 4 3cat functions,
there are now 8. Hop has expressed that it would be a better idea to go
right through the source altering their use for the new functions, then
remove the old. I am happy to do this if need be.
This alias demonstrates the improvement:
alias purge {
# revw does actually improve performance due to the way
# variables are stored.
@:list=revw($aliasctl(assign pmatch \\[$*\\]))
fe ($list) bar {
^assign -$bar
}
if (functioncall()) {
return $#list
} else {
echo $#list purged.
}
}
One other thing in the patch not covered by all this is that it turns
variable storage size checking for the delete case on again. I can only
guess that this was originally turned off because new_realloc was so
slow.
diff -ruN ../epic4-1.0.1/include/ircaux.h ./include/ircaux.h
--- ../epic4-1.0.1/include/ircaux.h Thu Mar 8 05:03:23 2001
+++ ./include/ircaux.h Tue Aug 28 04:36:52 2001
@@ -24,6 +24,10 @@
fatal_malloc_check ((void *)(x), (y), __FILE__, __LINE__)
#define RESIZE(x, y, z) new_realloc((void **) (x), sizeof(y) * (z))
#define LOCAL_COPY(y) strcpy(alloca(strlen((y)) + 1), y)
+#define m_e3cat(x,y,z) m_ec3cat((x),(y),(z),NULL)
+#define m_s3cat(x,y,z) m_sc3cat((x),(y),(z),NULL)
+#define m_s3cat_s(x,y,z) m_sc3cat_s((x),(y),(z),NULL)
+#define m_3cat(x,y,z) m_c3cat((x),(y),(z),NULL)
extern int need_delayed_free;
void fatal_malloc_check (void *, const char *, char *, int);
@@ -37,7 +41,7 @@
char * new_next_arg(char *, char **);
char * new_new_next_arg(char *, char **, char *);
char * s_next_arg (char **);
-char * last_arg(char **);
+char * last_arg(char **, size_t *cluep);
char * expand_twiddle (char *);
char * upper (char *);
char * lower (char *);
@@ -48,10 +52,10 @@
char * malloc_strcpy (char **, const char *);
char * malloc_strcat (char **, const char *);
char * malloc_str2cpy (char **, const char *, const char *);
-char * m_s3cat_s (char **, const char *, const char *);
-char * m_s3cat (char **, const char *, const char *);
-char * m_3cat (char **, const char *, const char *);
-char * m_e3cat (char **, const char *, const char *);
+char * m_sc3cat_s (char **, const char *, const char *, size_t *clue);
+char * m_sc3cat(char **, const char *, const char *, size_t *clue);
+char * m_c3cat (char **, const char *, const char *, size_t *clue);
+char * m_ec3cat(char **, const char *, const char *, size_t *clue);
char * m_2dup (const char *, const char *);
char * m_3dup (const char *, const char *, const char *);
char * m_opendup (const char *, ...) __A(1);
diff -ruN ../epic4-1.0.1/source/alias.c ./source/alias.c
--- ../epic4-1.0.1/source/alias.c Tue Dec 5 11:11:57 2000
+++ ./source/alias.cTue Aug 28 04:38:35 2001
@@ -2354,6 +2354,7 @@
{
char **mlist = NULL;
char *mylist = NULL;
+ size_t mylistclue = 0;
int num = 0, ctr;
if (!my_stricmp(listc, *))
@@ -2368,7 +2369,7 @@
for (ctr = 0; ctr num; ctr++)
{
- m_s3cat(mylist, space, mlist[ctr]);
+ m_sc3cat(mylist, space, mlist[ctr], mylistclue);
new_free((char **)mlist[ctr]);
}
new_free((char **)mlist);
@@ -2380,6 +2381,7 @@
{
char ** mlist = NULL;
char * mylist = NULL;
+ size_t mylistclue = 0;
int num = 0,
ctr;
@@ -2390,7 +2392,7 @@
for (ctr = 0; ctr num; ctr++)
{
- m_s3cat(mylist, space, mlist[ctr]);
+ m_sc3cat(mylist, space, mlist[ctr], mylistclue);
