I like that lambda trick. I was hoping Crash would actually crash the program so you could tell if you won by looking at the error it gives (if its KeyboardInterrupt or something else).
Here's mine.
$ python -c 'import random;L=sorted(str(random.randint(1,9)) for i in range(4));a=raw_input(L);print(eval(a)==24,sorted(filter(str.isdigit,a))==L)'
['2', '6', '7', '8']8*(7+2-6)
(True, True)
Try to make it print (True, True) without abusing eval too much (intended to be +-*/() only with digits as tokens).
A nicer interface, but too long:
import random;L=sorted(str(random.randint(1,9)) for i in range(4));a=raw_input(" ".join(L)+"\n> ");print(eval(a)==24,sorted(filter(str.isdigit,a))==L)
He can save 14 more if instead of creating a function he copies the function content inside of 'onclick'. And he can save one by using +new Date instead of Date.now().
The start tag is mandatory. The end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <div>, <dl>, <fieldset>, <footer>, <form>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <header>, <hr>, <menu>, <nav>, <ol>, <pre>, <section>, <table>, <ul> or another <p> element, or if there is no more content in the parent element and the parent element is not an <a> element.
And "there is no more content in the parent element" applies here.
Actually, what you call "very specific cases" are in fact, well, all reasonable cases. That list consists of all block level elements that can appear in `body`, so the statement could be reworded, that "<p> cannot contain any block-level element, so any inline element after <p> falls in, any block level element ends opened <p>".
Funny fact is that presence of optional end tags means nearly nothing for HTML parsers used in current browsers, they just ignore them. Some border cases regarding white space exists, or at least existed in the past, but in general, if you feed browser with document
Author here - I'll implement some of these suggestions and see if the extra space might allow for something a little more interesting. It's a pleasant surprise to see a pull request on this little thing.
- if you aim for low character count instead of low byte count, you can pass your code through my unicide packer here: http://xem.github.io/obfuscatweet/
- Golf your code even more (using the tips of the other comments), and use all the remaining chars to add features to your game and fill the 140 chars of a tweet :)
A few of us were doing this over on Twitter, with the typical "guess a number" games. But Alex's was the best so far! I built a few games, but all of them were too big.
Can anyone speak a bit more to that? I was wondering if this was just a convenience feature that browsers added or something that has been in Javascript all along?
Yup - in fact there's an old bug that jQuery (in versions < 2, I believe) accounts for where IE would return elements with a name equal to the id you're searching for as the underlying system there was all wonky.
e.g:
<input name="test">
<div id="test">
document.getElementById('test'); // <input> in IE6
I believe this also wound up in some Webkit and Opera releases, perhaps for emulation. Someone more knowledgeable about it all should feel free to correct me if I'm wrong though.
(Edited for code formatting, I don't comment too much these days)
One thing I've always meant to do was to put together a system for loading and saving Sinclair ZX81 games via Twitter messages.
Depending on how much you cheat, you can get about two bytes of data per Twitter character. That'd allow 256 bytes of game to live comfortably within a single twit, which is a quarter of an unexpanded ZX81 RAM. By comparison, that would take almost ten seconds to load off tape. You should be able to get a respectable ZX81 game in that.
With something like the JtyOne Javascript ZX81 emulator (http://www.zx81stuff.org.uk/zx81/jtyone.html) and some Twitter interaction, the whole process should be pretty seamless --- click on a twit to play; modify it using the ZX81's built-in cough IDE; click on a button to reshare...
It's OT but I can't resist: I recently found out that a selection of these little "synths" have been implemented in the chipsounds VST instrument using its bandlimited oscillators. You can play them up and down the keyboard and they sound awesome.
Wow, that is really lovely .. thanks for pointing that out!
(I'm really more of a hardware guy myself, love to strip the SID's from any C64's I find in the trash .. and of course synths (analog and digital) are really a different subject altogether .. but I'll check out chipsounds on a DAW next time I get a chance. Ta!)
Increment global state variable, add it to e, which is the number of milliseconds the game has been running modulo 300. Then set the margin size to that value. It's a simple pseudo-pseudorandom number generator.
In case any one was wondering the difference between "s++" and "++s" (the former of which is probably more common), prepending the "++" increments the variable before returning it, whereas appending it would increment after returning the value.
The code you posted is essentially equivalent to "s = s + 1; a.style.margin = s + e % 300".
Reminds me when my father showed me "number guessing" game on TI-57 calculator. It had 50 instructions (button presses) of memory. It's interesting that the size wasn't that a big deal then. :-)
All that matters is that s changes for each call. It really doesn't matter what the value is or how it changes. In this case incrementing afterwards would be "s+++e%300" which looks gross and using any parenthesis for clarity would take up more space.
[1]: http://arunrocks.com/python-one-liner-games/