Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - hamlet

Pages: [1] 2 3 4
General / Re: Variable's scope lifetime [LPC]
« on: December 22, 2011, 09:44:13 am »
from a "security" standpoint, it's important to zero variables at the start to ensure you don't get access to the previous memory occupant's data.  There's no need for this security when it's -you- (this particular bit of code) reusing the same space, though.

So consider the "variables are zeroed" thing not a feature but just a side-effect of something else.  In other words, never assume it will be true.  Always zero your variables if it's relevant.

Drivers / Re: FreeBSD 8.1 amd64 + FluffOS 2.23 (compile Oops?)
« on: November 29, 2011, 08:16:56 am »
If you'll figure out what .h in /usr/include should be included for log2, I'll fix it.

General / Re: Old mudlibs and drivers
« on: July 31, 2011, 10:37:34 pm »
Where "wrote" is used charitably.

General / Re: administration
« on: July 18, 2011, 03:21:51 pm »
Hm.  Something had me out of bed last night with feelings that a terrible thing had happened.  At least now I know what it was...

Drivers / Re: FluffOS-2.22
« on: February 18, 2011, 10:59:45 pm »
Did you try compiling 2.22 on a 32-bit machine?  The gubuntu I'm currently messing with is 32bit, and the driver I made insta-segfaults.  I'll do some looking tomorrow to see if I can diagnose the problem, but I was wondering whether it's just me or whether it might truly be a 32-bit issue.

General / Re: Ban everybody!
« on: November 24, 2010, 01:45:04 pm »
Aw.  You banned "everybody" and not me?  I feel left out.  Where's the love?

Will terminal_colour() not do what you need?

Drivers / Re: LDMud 3.5 - this_player() confused?
« on: August 07, 2010, 02:50:27 pm »
Uh.  "when I linkdead a character" might be a bit vague here.  If you're dropping the telnet and messages are -still- coming through, you need to panic, change your drawers, and then switch to Windows because it's probably more secure (shocking, I know) than the swiss cheese OS you're running.  When a telnet link is dropped, the OS is supposed to ensure that any future messages don't come through.  That's kind of the point.

Drivers / Re: FluffOS-2.20
« on: May 24, 2010, 10:54:09 am »
back to the licensing thing, then.  FluffOS can't be used for a for-profit mud.  (not even in Taiwan).

General / Re: heart_beat v. call_out
« on: April 23, 2010, 02:38:24 pm »
Well, I was thinking of something specific that I was messing with the other day when I said "interrupts".  It is an interrupt of sorts....

Some things could use knowing whether a certain file has changed lately.  A dumb way would be to setup polling using call_out() for all things that fit in that category.

Instead, I put a hook in valid_write() that calls a handler with "file xxx is being changed".   the handler keeps track of who might want to know about specific files.

Soooo... interrupts!  You register, and you get told.  No need to poll.  And that's purely lib-level except the driver call to valid_write(), so there's nothing really arcane about it.  I guess it's not precisely what was originally meant by interrupts, but it's clearly the same idea, and clearly better than a bunch of polling.  You know, unless I implement it in a really dumb way.

General / Re: heart_beat v. call_out
« on: April 22, 2010, 03:58:00 pm »
And remember that interrupts are better than polling.

Dead Souls Support / Re: Lenarics help thread
« on: April 09, 2010, 01:36:07 pm »
Our task tracker has "FALSE" as a possible state just for that sort of thing.  As opposed to "CODE" or "PATCHED".

Drivers / Re: FluffOS manual/documentation on WWW?
« on: March 28, 2010, 05:20:16 pm »
For the nroffed MudOS docs, couldn't you just use a roff2wiki sort of thing and be done?  Or am I missing a subtlety of your goal?

General / Re: evaluate() vs (*f)() troubles in MudOS
« on: March 17, 2010, 06:25:33 am »
I think we would need to see more code.  I can't get (*f)() to work in that context at all unless it returns a string.  both on FluffOS and v22.2b9.

Where does f get set?

Code Vault / Re: wildmat_to_regexp()
« on: February 10, 2010, 11:36:20 am »
Here's the equivalent (or thereabouts) using only replace_string().  I haven't looked at it for a while, but I think it was pretty reliable.

Code: [Select]
/* Unix-style wildcards.  Thrown up by Hamlet, Aug 1997 */

string wild2regexp(string pattern, int sloppy) {
  string tmp;

    return "^$";

  tmp = implode(explode(pattern, " ") - ({ "" }), " ");

    return "^$";

  /* Escape things that have special meaning in regexp but not
     as wildcards.
  tmp = replace_string(tmp, ".", "\\.");
  tmp = replace_string(tmp, "+", "\\+");
  tmp = replace_string(tmp, "$", "\\$");
//tmp = replace_string(tmp, "{", "\\{");
//tmp = replace_string(tmp, "}", "\\}");

  /* Next bit is a silly hack because I suspect it's faster than a loop */
  tmp = replace_string(tmp, "[^", "!@#(");
  tmp = replace_string(tmp, "^", "\\^");
  tmp = replace_string(tmp, "!@#(", "[^");

  /* next, translate wildcards into regexp syntax */
  tmp = replace_string(tmp, "*", ".*");
  tmp = replace_string(tmp, "?", ".");
  /* note that [] doesn't need changed */

  /* Unlike regular expressions, spaces and commas denote a list of things */
  tmp = replace_string(tmp, " ", "|");
  tmp = replace_string(tmp, ",", "|");

  tmp = "^" + tmp;

  if(!sloppy) /* If we're being strict, We force matched termination */
    tmp += "$";

  return tmp;

/* This one works in the same way as regexp() but with unix-type
   wildcards instead.  (flag & 1) still means return indices in
   the return.  (flag & 2) still means reverse the matching.
   (flag & 4) means sloppy end-of-string stuff.
mixed wildcard(mixed junk, string pattern, int flag) {
  string tmp = wild2regexp(pattern, (flag & 4));

  return regexp(junk, tmp, flag);

Pages: [1] 2 3 4