Hardcode https://community.pennmush.org/taxonomy/term/1 en Changing the softcode parser https://community.pennmush.org/node/1113 <span class="field field--name-title field--type-string field--label-hidden">Changing the softcode parser</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Thu, 2012-07-19 22:38</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>Every softcode function is implemented by a corresponding C function (Here called a FUNCTION, after the macro that sets up its arguments). Arguments passed to the function are give in an array of strings, and it returns things by appending to another string. For functions that work with numbers or dbrefs or other things besides strings, there's a lot of conversions from strings to another type and then back. This seems like a waste.</p> <p>I want to change this so that FUNCTIONs take arguments and return values in <a href="http://en.wikipedia.org/wiki/Tagged_union">variant types</a>. Call them pvs, short for penn values. If a function's arguments are already in the right data type, no conversion is needed. add(mul(2,3), sub(6,3)) would mean mul() and sub() would have to convert from the default string arguments, but add() would get two doubles as args, instead of strings.</p> <p>For each mush data type (Integers, doubles, strings, dbrefs, booleans, etc.), there would be a set of pv creation, manipulation and predicate functions. For example, pv_new_int, pv_is_int, pv_to_int, pv_int_val would respectively make a new tagged integer value, test if a pv is an int, convert any other pv type to a newly returned int one, and return the integer stored in the pv.</p> <p>I'm planning on making them immutable, which means that string pvs will only have enough space allocated to store one particular string, instead of the current 8k chunks that we throw around all over the place. Less memory! They'd also get garbage collected as needed, to avoid having to deal with keeping track of when they should be freed. Less programmer time!</p> <p>Lists would be a pv type too, represented as an array of pvs. I'm toying with unboxed numeric arrays, for use with things like vector functions, as well. Instead of an array of pvs, it'd be an array of doubles that aren't wrapped in a pv struct. More space savings.</p> <p>This is a big project; it requires fiddling with the Lovecraftian monstrosity that is process_expression(), and every single FUNCTION. Everybody with custom hardcode that adds functions would have to rewrite theirs too. It might be a PennMUSH 1.9 or 2.0 level change.</p> <p>It might make sense to add unicode support at the same time, since that requires touching even more stuff. At the very least, the changes will make it easier to convert later.</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Fri, 20 Jul 2012 03:38:13 +0000 raevnos 1113 at https://community.pennmush.org How Do I Report a Bug or Suggest a New Feature to Penn? https://community.pennmush.org/node/1087 <span class="field field--name-title field--type-string field--label-hidden">How Do I Report a Bug or Suggest a New Feature to Penn?</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>MrWigggles</span></span> <span class="field field--name-created field--type-created field--label-hidden">Fri, 2012-05-11 15:14</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>If you think you've found a bug or want to suggest a new feature to Penn, then you'll want to go the Google Code for Pennmush. </p> <p>http://code.google.com/p/pennmush/</p> <p>From there, you'll want to clink on the Issues tab, where you'll be brought to a list of the current open ticket for PennMush. You'll notice a mix of bug reports and new features. </p> <p>Then you'll want to click on the New Issue button, and select on the pull down menu, Feature Request or Bug Report and fill out the form.</p> </div> Fri, 11 May 2012 20:14:36 +0000 MrWigggles 1087 at https://community.pennmush.org The changes to flags in p7 https://community.pennmush.org/node/984 <span class="field field--name-title field--type-string field--label-hidden">The changes to flags in p7</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Fri, 2011-10-07 02:29</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>p7 saw a significant change to the way that flags (And powers) are stored on objects. </p> <p>Some background: Flags are implemented internally as an array of bits. To see if a flag is set on an object by name (As in the softcode hasflag() function), you look up the bit position of that flag by its name, and index the object's flag array to see if that bit is 1 or 0. Because new flags can be added at run time with @flag, this bit array is dynamically allocated, and grown if needed. On M*U*S*H, it's currently taking up 9 bytes worth of space. </p> <p>There are a lot of possible combinations of flags that can be set, but most objects only have a few (Or none) set, and some combinations are more likely than others. Many objects have a set of flags shared by a few or many other objects. On M*U*S*H, again, only 500 out of 12000 objects boast unique combinations of flags that no other object shares.</p> <p>Before p7, each object in the database had those 9 bytes allocated separately. Again using M*U*S*H as an example, that works out to 107109 bytes, or about 105 kilobytes. There's also some more space being used by malloc() for its record keeping; call it an extra 4 bytes, which increases the space used by flags by half again. On 64 bit systems, it's probably 8 bytes instead, doubling the space. That's almost as much memory as my first computer came with, though it's just a drop in the bucket these days.</p> <p>Starting with p7, objects with the same flags set share the same bit array in memory. All objects only set NO_COMMAND share the same 9 bytes of memory representing their flags, with reference counting to keep track of how many times a particular set of flags is in use so it can be freed when unused. In addition, the bit arrays are stored in slabs, an alternate to malloc that provides minimal overhead, very compact management of pools of small, same-sized chunks of memory. There's some new added memory in the form of a hash table that's used to look up flagsets, but even with it, the amount of memory used by flags is probably 20%-40% of before.</p> <p>The impact on memory usage is pretty minor (100kB one way or the other isn't going to make a difference unless you're trying to run a big game on mid 90's era hardware), but the sharing and slabification of flag bit arrays helps improve cache locality. The flagsets used by a large percentage of objects are likely to be loaded in at least L2 cache a majority of the time, speeding up access time when checking for a flag — something that's done all the time. That's a larger benefit of shared flagsets than the space savings, IMO.</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Fri, 07 Oct 2011 07:29:45 +0000 raevnos 984 at https://community.pennmush.org Persistant SSL connections https://community.pennmush.org/node/930 <span class="field field--name-title field--type-string field--label-hidden">Persistant SSL connections</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Sun, 2011-05-15 18:11</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>It still needs some more work before getting checked in for p5, but I have SSL connections that persist across @shutdown/reboots instead of getting dropped up and running. Only a few years after working out the basic design. Can't work faster than that!</p> <p>The big problem has been that OpenSSL doesn't have a way of saving internal state across a reboot so that the same connections can be reused. In general, from a security standpoint, this is a good thing. It's just frustrating for players who use SSL connections. The solution is to use a proxy process to handle the SSL connections.</p> <p>Shortly after reading the configuration files, the mush now forks a child process if it's starting up for the first time and not rebooting. That child (The slave) listens for SSL connections, accepts them, and for each one opens a new, unencrypted connection to the main mush process and pipes data between the two. Currently, instead of a completely separate executable (Like info_slave for hostname lookups), it shares the same binary as the main mush, just doing its own thing instead of going on to read the databases and such. I might change this to be like info_slave, but for now it was convenient to be able to access the ssl-related configuration options directly instead of having to pass them to the slave via command line arguments or something.</p> <p>The mush and ssl slave communicate over a unix socket (An entity that lives in the filesystem but is opened and manipulated with the socket API). It's unencrypted, but if somebody can listen in on it, they have enough control over the host's kernel to do far far worse — plus the data isn't encrypted in the mush anyways as it is now. This type of socket is far more efficient than IP ones for local connections, and allows for some nifty things I'm not currently doing but might.</p> <p>One part I still need to do is passing the remote host address to the mush for sitelock checks and the like. Right now, all SSL connections look like they're coming from localhost. I'm still debating doing the hostname lookup in ssl slave, or passing the IP address to the mush and then to info slave. It's simpler to do it in the ssl slave.</p> <p>Instead of rolling my own event loop setup in ssl slave to do things when various sockets have data waiting or can be written to, I'm using the third-party <a href="http://monkey.org/~provos/libevent/">libevent library</a>. This makes it dead easy — libevent has a system where you can write data to a buffer and have it sent to the underlying socket once that socket can be written to without blocking, doing all the fiddling with partial writes and keeping track of what's still pending for you. Also, it supports OpenSSL sockets. I wouldn't mind using it in the main mush process, actually, instead of our current event loop and network i/o code.</p> <p>The eventual end result to people who use SSL connections is that they'll be able to connect to games, not get kicked on reboots, and have no way to tell they're not connected directly to the mush.</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Sun, 15 May 2011 23:11:48 +0000 raevnos 930 at https://community.pennmush.org PennMUSH sourcecode documentation https://community.pennmush.org/node/927 <span class="field field--name-title field--type-string field--label-hidden">PennMUSH sourcecode documentation</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>talvo</span></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 2011-05-11 21:25</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>For anyone interested in hacking PennMUSH, you can now view the documentation for the PennMUSH source code (taken directly from the comments in the source) online, at <a href="http://doxygen.pennmush.org/">http://doxygen.pennmush.org</a>.</p> <p>You can see the functions that exist, the arguments they take, and their expected return values, all with automatic links to which files they're found in, the members of the structures used, etc.</p> <p>There's still quite a lot of stuff at the moment that isn't documented, but I'm gradually working on documenting/commenting more of the structures, #defines and functions that are likely to be of use to people who want to make custom hacks to Penn for their games.</p> <p>(For anyone interested, all the content there is built automatically using <a href="http://www.doxygen.org/">Doxygen</a>, which is really, really awesome.)</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Thu, 12 May 2011 02:25:02 +0000 talvo 927 at https://community.pennmush.org Perfect Hash Tables https://community.pennmush.org/node/913 <span class="field field--name-title field--type-string field--label-hidden">Perfect Hash Tables</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Sat, 2011-04-16 02:04</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>For cases where we have to check to see if a string is one of a fixed set of values that will never change while a MUSH is running, Penn uses a tool called <a href="http://www.gnu.org/software/gperf/">gperf</a> to generate lookup functions that use a <a href="http://en.wikipedia.org/wiki/Perfect_hash_function">perfect hash table</a> to quickly and efficiently check for a match.</p> <!--break--><p>For details on the format of a gperf file, see its documentation.</p> <p>To include a gperf-generated table in Penn:</p> <ol> <li>Create a new <var>foo.gperf</var> gperf file. See the existing ones for templates.</li> <li>Look for the existing gperf entries in <tt>src/Makefile.in</tt> and add a new one following their template to generate <var>foo.c</var>.</li> <li>Run <code>./config.status</code> to rebuild <tt>src/Makefile</tt>.</li> <li>In the source file that uses the lookup function, <code>#include "foo.c"</code></li> </ol> <p>Examples can be seen in <tt>src/funmath.c</tt> and <tt>src/markup.c</tt>, among others.</p> </div> Sat, 16 Apr 2011 07:04:52 +0000 raevnos 913 at https://community.pennmush.org Roadmap https://community.pennmush.org/node/893 <span class="field field--name-title field--type-string field--label-hidden">Roadmap </span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Thu, 2010-07-01 20:17</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>A partial list of the larger changes I want to get into Penn someday.</p> <ul> <li>Unicode support. Might be easier to rewrite from scratch, given how much stuff assumes that 1 byte equals 1 character.</li> <li>SSL connections that don't drop on a reboot. I know how I want to implement this, just need to sit down and do it.</li> <li>@mail rewrite. Internals only, for the most part. I feel that fancy editors and the like are better done in softcode. But right now, when you send a message to multiple people, each one gets their own individual copy with no clue that it was sent to more than one person unless you mention it in the body. That could be done so much better.</li> <li>Main loop rewrite. I want to put timed events like dbcks and saves into a queue instead of special-casing each one. Possibly also move to an event loop system like libevent or libev provides instead of our own select-based one.</li> <li>Speeding up softcode. The big one for me is eliminating a lot of the string &lt;-&gt; native datatype conversions. This is another big one because it requires touching every single softcode function's implementation, and the parser.</li> <li>Extended range for time/date functions. This one isn't so huge, but it does involve finding a good open-source library to do all the calculations. Open to suggestions.</li> </ul> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Fri, 02 Jul 2010 01:17:01 +0000 raevnos 893 at https://community.pennmush.org PennMUSH git repository https://community.pennmush.org/node/872 <span class="field field--name-title field--type-string field--label-hidden">PennMUSH git repository</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>raevnos</span></span> <span class="field field--name-created field--type-created field--label-hidden">Wed, 2010-02-03 10:55</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>I've put up an experimental git repository for Penn.</p> <p>Get it via: git clone http://download.pennmush.org/Repos/pennmush.git</p> <p>Handy for local hackers, since you can create local branches for custom stuff and keep up to date. I think. Branches and git and I haven't gotten along in the past. Please don't ask me how to use it. </p> <p>It should sync with the master subversion repository on googlecode every couple of hours.</p> <p>Branches and tags that exist in SVN aren't working right yet; I think it might be an issue between the git-svn created private master, and the bare copy that's being exported on the web server. I don't know enough about git to tell. </p> <p>It's a work in progress. Play with it, but don't rely too much on it for now. There's kinks to work out.</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Wed, 03 Feb 2010 16:55:53 +0000 raevnos 872 at https://community.pennmush.org Errors Compiling Pennmush-1.8.3p10 in Cygwin https://community.pennmush.org/node/870 <span class="field field--name-title field--type-string field--label-hidden">Errors Compiling Pennmush-1.8.3p10 in Cygwin</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>Tamesis</span></span> <span class="field field--name-created field--type-created field--label-hidden">Sat, 2010-01-16 06:20</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>Hey everyone,</p> <p>I've been struggling with getting Pennmush-1.8.3p10 to compile on Cygwin. The Cygwin package on my computer is complete, such that Pennmush-1.8.1p10 compiles cleanly. The following is the error message I am receiving during the compile process:</p> <p>gcc -std=gnu99 -ggdb -O -W -Wall -pedantic -Wno-comment -I/usr/include/ -I.. -I.<br /> ./hdrs -c -o strutil.o strutil.c<br /> strutil.c:1193: error:conflicting types for 'imaxdiv_t'<br /> /usr/include/inttypes.h:231: error: previous declaration of 'imaxdiv_t'<br /> make[1]: *** [strutil.o] Error1<br /> make[1]: Leaving directory '/home/pennmush-1.8.3p10/src'<br /> make: *** [all] Error2</p> <p>I should also note that I experience this same error for pennmush-1.8.3p11 and for 1.8.3p0. Any help you may offer would be greatly appreciated!</p> <p>Thanks,<br /> Tamesis</p> </div> Sat, 16 Jan 2010 12:20:38 +0000 Tamesis 870 at https://community.pennmush.org Frustrated with Flat Files https://community.pennmush.org/node/864 <span class="field field--name-title field--type-string field--label-hidden">Frustrated with Flat Files</span> <span class="field field--name-uid field--type-entity-reference field--label-hidden"><span>Ruby</span></span> <span class="field field--name-created field--type-created field--label-hidden">Sun, 2010-01-10 14:15</span> <div class="field field--name-topic field--type-entity-reference field--label-hidden field__items"> <div class="field__item"><a href="/taxonomy/term/1" hreflang="en">Hardcode</a></div> </div> <div class="node__links"> <ul class="links inline"><li class="comment-forbidden"></li></ul> </div> <div class="clearfix text-formatted field field--name-body field--type-text-with-summary field--label-hidden field__item"><p>I keep trying and searching for a simple and idiot-proof way to install a flat file/backup into an existing, running MUSH. I need the code that's on it - but I have no coder.</p> <p>Is there anyone out there who knows?</p> </div> <section class="field field--name-field-blog-comments field--type-comment field--label-above comment-wrapper"> </section> Sun, 10 Jan 2010 20:15:53 +0000 Ruby 864 at https://community.pennmush.org