| --- Log opened Sun Apr 15 00:00:01 2012 |
| 00:27 | <&Derakon> | Hm, I guess the right way to do a sorting function where you sort first by field A, then by field B, then by etc. would be "return cmp(self.A, alt.A) or cmp(self.B, alt.B) or ..." |
| 00:28 | < Rhamphoryncus> | That's the traditional way. cmp() is depreciated though |
| 00:28 | <&Derakon> | What should I use instead then? |
| 00:29 | < Rhamphoryncus> | Have to do the separate methods :/ |
| 00:29 | <&Derakon> | I don't follow. |
| 00:30 | < Rhamphoryncus> | __lt__, __gt__, etc |
| 00:30 | <&Derakon> | Oh. Feh. |
| 00:31 | < Rhamphoryncus> | Ahh, 2.5 has a functools.total_ordering() class decorator |
| 00:31 | < Rhamphoryncus> | http://docs.python.org/library/functools.html#functools.total_ordering |
| 00:31 | < Rhamphoryncus> | oops 2.7 |
| 00:31 | < Rhamphoryncus> | 2.5 is the module itself :) |
| 00:31 | <&Derakon> | This still seems to be much more of a bother than just implementing __cmp__. Bah. |
| 00:32 | < Rhamphoryncus> | Yeah |
| 00:32 | < Rhamphoryncus> | There's good reasons for it, but it's still a wart |
| 00:32 | | cpux [cpux@Nightstar-c5874a39.dyn.optonline.net] has joined #code |
| 00:53 | <&Derakon> | Reason I asked is because I'm working on an alternate serialization method for the monster definitions in Angband. |
| 00:54 | <&Derakon> | Currently they look like this: http://pastebin.com/1r3dvsj2 |
| 00:54 | <&Derakon> | And format changes are a big deal. |
| 00:54 | <&Derakon> | I converted to JSON and got...this: http://pastebin.com/aVCruX75 |
| 00:55 | <&Derakon> | Which is less than ideal in many ways. |
| 00:56 | <&Derakon> | (Specifically, keys within the dict aren't ordered nicely, e.g. name should be the first entry; it's horribly vertically-oriented; there's quotation marks all over the place) |
| 00:56 | <@rms> | JSON specifies that keys must be double quoted |
| 00:57 | <@rms> | Single quoted strings don't exist at all |
| 00:57 | <&Derakon> | I'd rather not have to quote keys at all unless they have colons in them, frankly. |
| 00:57 | <@rms> | RE the actual object, descript should be a string instead of an array |
| 00:57 | <@rms> | Then don't use JSON |
| 00:57 | <&Derakon> | The format of the object is basically a direct port of the monster record, as it currently stands. |
| 00:57 | <&Derakon> | I'll be fixing warts later. |
| 00:58 | <@rms> | Blows is an array of arrays? |
| 00:58 | <&Derakon> | Do you have a suggested non-JSON serialization? |
| 00:58 | <@rms> | XML, YAML, INI |
| 00:58 | <&Derakon> | At the moment, yeah. Each blow has multiple fields describing how it works. |
| 00:59 | <&Derakon> | I haven't gotten around to implementing combat yet so I'm leaving those as just the strings used to represent them. |
| 01:00 | <&Derakon> | XML has even worse verbosity issues than JSON does. I'll check out YAML and INI; I'm not familiar with their formats. |
| 01:01 | <&McMartin> | INI is very restricted and Windows-specific: don't use it for anything cross-platform or, to be honest, non-legacy |
| 01:01 | <&Derakon> | ...righto. |
| 01:01 | <@rms> | PHP uses INI just fine |
| 01:01 | <&McMartin> | INI is what eventually became the Registry. |
| 01:01 | <&McMartin> | rms: The prosecution rests its case. |
| 01:01 | <&McMartin> | YAML... well, look at it, I guess |
| 01:02 | <@rms> | *rollseyes* |
| 01:02 | <&McMartin> | I don't like YAML. |
| 01:02 | <&Derakon> | What's your complaint about it? |
| 01:03 | <&McMartin> | It's kind of the anti-XML, and looking at them side-by-side makes me prefer XML's rigid structure. |
| 01:03 | <&Derakon> | s/int/int(s)/ |
| 01:03 | <&McMartin> | YAML |
| 01:03 | <&McMartin> | YAML strikes me as trying to look like a well-organized text file full of notes. |
| 01:03 | <@rms> | YAML would be fine if it wasn't for the "spaces for indents" rule. |
| 01:04 | <&McMartin> | And while that's great for reading, it seems to lend itself to the same kind of failure modes Inform 7 has where it looks like English text so you just stick random sentences in. |
| 01:04 | <@rms> | INI is fine for relatively simple data (going into nested stuff is impossible without hackery) |
| 01:04 | <@rms> | MySQL also uses INI |
| 01:04 | <&McMartin> | INI's best if you have exactly one layer of nesting. |
| 01:05 | <@rms> | Yeah |
| 01:05 | <&McMartin> | INI with zero layers of nesting is inoffensive but strictly speaking violates the INI standard. |
| 01:05 | <&McMartin> | Most INI readers will handle that, but if you're looking at that you actually just have a file full of key-value string pairs. |
| 01:06 | <&McMartin> | INI also starts choking if there are newlines or various other things. |
| 01:06 | <&Derakon> | So what would be your choice for serialization, McM/ |
| 01:06 | <&Derakon> | ? |
| 01:06 | <&McMartin> | As I said - I'm partial to XML, because I'm willing to trade rigidity for the ease of processing that regularity gives. |
| 01:06 | | * rms would personally use JSON |
| 01:07 | <&McMartin> | I'm well aware that I'm making a bunch of design tradeoffs in that choice. |
| 01:07 | <&McMartin> | JSON and YAML are both rational and eminently reasonable choices as well. |
| 01:07 | <@rms> | XML isn't regular though. |
| 01:07 | <&Derakon> | My goals are first to make something that is human-editable without massive pain, and second to make it readily extensible. |
| 01:07 | <&Derakon> | IME hand-editing XML is not fun. |
| 01:07 | <@rms> | It is however annoyingly rigid. |
| 01:07 | <&McMartin> | Depends on the XML. |
| 01:07 | <&McMartin> | But JSON is *probably* the best choice with those. |
| 01:08 | <&McMartin> | YAML has some sharp corners that aren't easy to immediately see. |
| 01:08 | <&McMartin> | Derakon: It's worth noting that most of the review websites I make are generated from hand-written XML documents, so while using All The XMLs is a pain in the ass, I've got a subset I can use without pain. |
| 01:09 | <@rms> | If you want human editable, INI or YAML are better choices. However, you might be better off with a custom format, or simply having a good set of tools to manipulate the data. |
| 01:10 | <&McMartin> | An extension of JSON that makes quoting keys optional and permits comments is actually very nice indeed >_> |
| 01:10 | <&Derakon> | That would sound roughly ideal, yes. |
| 01:11 | <&McMartin> | What kind of data here is being serialized? |
| 01:11 | <@rms> | What FreeCraft does is units are actually scripts |
| 01:11 | <@rms> | LUA, specifically |
| 01:11 | <&Derakon> | Monster records for Angband. |
| 01:11 | <&Derakon> | Compare original record: http://pastebin.com/1r3dvsj2 |
| 01:11 | <&Derakon> | Naive JSON serialization of same: http://pastebin.com/aVCruX75 |
| 01:12 | <&McMartin> | OK, since descriptions can be multiline, INI is out |
| 01:12 | <@rms> | TMW's old server software also loaded NPCs from scripts |
| 01:12 | <&McMartin> | Which is too bad, because otherwise this has the Single Level Of Nesting that INI is ideal for. |
| 01:12 | <&Derakon> | Well, I plan to extend it to include display metadata. |
| 01:12 | | * McMartin nods |
| 01:12 | <&McMartin> | That looks eminently reasonable |
| 01:13 | <&McMartin> | with one possible shift in that maybe the description should be all one string? |
| 01:13 | <&McMartin> | I forget if JSON does the C thing where adjacent strings are auto-concatted. |
| 01:13 | <&Derakon> | Yeah. |
| 01:13 | <&Derakon> | I'm not touching the inherent structure of the record yet, but I do plan to remove warts like that. |
| 01:14 | < Rhamphoryncus> | If you grouped some of the keys together then you might be able to get them on one line.. but most of the bulk is simply from having names |
| 01:14 | <&Derakon> | Having names is good, though, for readability; the old format is famously inscrutable. |
| 01:14 | < Rhamphoryncus> | yup |
| 01:14 | <&McMartin> | I am pro-names. |
| 01:15 | < Rhamphoryncus> | I'd look at mid points though, for comparison |
| 01:15 | <&Derakon> | I guess what I want is basically the JSON version, but without quoted key names, and with a consistent key order, and with more vertical compactness by putting multiple key/value pairs on each line. |
| 01:15 | <&Derakon> | Mid points? |
| 01:15 | <@rms> | You're using Python right? |
| 01:15 | <&Derakon> | Yeah. |
| 01:16 | <@rms> | If so, that's why you're not getting "consistent key order" |
| 01:16 | <&Derakon> | That's dicts for you, yes. |
| 01:16 | < Rhamphoryncus> | Mid point meaning name most things, but where possible group logically related values together and leave their individual meanings implied |
| 01:16 | < Rhamphoryncus> | Surely the json serializer is capable of sorting? |
| 01:17 | <&Derakon> | It is. |
| 01:17 | < Rhamphoryncus> | sort_keys=True |
| 01:17 | <&Derakon> | But the name field should really be at the top of each record, not the middle. |
| 01:18 | <@rms> | flags: {male: true, light: true, drop: 40, onlyGold: true, rand: 50, openDoor: true, bashDoor: true, takeItem: true} |
| 01:18 | < Rhamphoryncus> | Yeah, I'm looking |
| 01:18 | <@rms> | Gender shouldn't be a flag though |
| 01:18 | <&Derakon> | There's MALE, FEMALE, and NEUTER genders. |
| 01:19 | <&Derakon> | So it's not binary. |
| 01:19 | <@rms> | ... |
| 01:19 | <@rms> | Way to miss my point |
| 01:20 | <@rms> | Gender shouldn't be a flag, the implication being it should be it's own field. |
| 01:20 | <~Vornicus> | I think what he means is, everything has a gender; putting it in a flag makes it optional when you'd expect it not to be. |
| 01:20 | <@rms> | Unless you want: "FLAGS": ["MALE","FEMALE"] |
| 01:21 | <~Vornicus> | --indeed, optional or doubleable, but I guess if you're fighting plants they're both~ |
| 01:21 | <&Derakon> | Heh. |
| 01:21 | <&Derakon> | But okay, fair enough. |
| 01:21 | < Rhamphoryncus> | flags is.. the opposite of the mid point I was suggesting. It's a grouping by implementation rather than purpose |
| 01:21 | <&Derakon> | That's another thing that'll probably get cleaned up later. |
| 01:22 | < Rhamphoryncus> | If you cut the flowers off it's male, female, AND neuter XD |
| 01:22 | <&Derakon> | Most flags are about one of item drops, elemental resistances, terrain interaction abilities, behavioural abilities, or...random miscellaneous crap. |
| 01:22 | <&Derakon> | Oddly enough Angband doesn't have any plant monsters. |
| 01:23 | <&Derakon> | Anyway, so really the flags here should be something like "drop: {rate: 40, type: gold}; movement: {erratic: 50}; terrain: {doors: [open, bash], can_pickup: true}", etc. |
| 01:24 | <@rms> | Keep in mind how you're accessing things too |
| 01:25 | <@rms> | Do you really want to do lookup(terrain.doors, "open") when checking in the AI routine? |
| 01:26 | <&McMartin> | flags : [ "PONCIEST_PONCE_WHO_EVER_PONCED_PAST_THE_PONCING_PARLOR" ] |
| 01:26 | <@rms> | Wouldn't terrain.doors.open be better |
| 01:26 | <&McMartin> | rms: Given that this is Angband, I'm guessing that JSON here is only being used as a marshalling format. |
| 01:26 | <&Derakon> | Yeah. |
| 01:26 | <@rms> | Ah |
| 01:26 | <&Derakon> | As for actual "can I open doors", I would do "if OPEN_DOORS in self.subscriptions", but that has to do with my object model. |
| 01:28 | < Rhamphoryncus> | Looks like python's json supports OrderedDict |
| 01:29 | < Rhamphoryncus> | although older versions had a bug in the C variant of the lib which didn't |
| 01:29 | < Rhamphoryncus> | IOW, take your dict, throw it into a list, sort it how you want, throw it in to an OrderedDict, then throw that at json |
| 01:30 | <&Derakon> | Hm. Thanks, will give that a try as soon as I die. |
| 01:30 | <&McMartin> | I didn't realize Angband had Python components. |
| 01:30 | <&Derakon> | It doesn't. |
| 01:30 | <&Derakon> | I'm...kinda rewriting it. |
| 01:33 | <~Vornicus> | ALl together now: you fool |
| 01:33 | <&Derakon> | Hey now, I've come up with a pretty cool system, and so far it's actually working too! |
| 01:33 | <&Derakon> | http://angband.oook.cz/forum/showpost.php?p=68364&postcount=24 |
| 01:43 | < Rhamphoryncus> | Derakon: wait, by rewriting you mean an entirely new engine that's just reusing the data files? |
| 01:43 | <&Derakon> | Yeah. |
| 01:44 | < Rhamphoryncus> | That's both better and worse. I can't decide :) |
| 01:44 | <&Derakon> | Heh. |
| 01:56 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 02:16 | | Kindamoody[zZz] is now known as Kindamoody |
| 02:54 | | * Derakon tries to figure out how to get newlines inserted only after specific fields in the JSON serialization. |
| 02:56 | <&Derakon> | Short of basically doing the serialization myself, I don't see how I can do it... |
| 03:01 | <&Derakon> | Okay, how's this look? http://pastebin.com/fR2gZHcT |
| 03:02 | <~Vornicus> | It's serialization |
| 03:02 | <~Vornicus> | Who gives a fuck what it looks like. |
| 03:02 | <&Derakon> | Uh, this is the master record for monster types. |
| 03:02 | <&Derakon> | When monsters get changed, these get modified. |
| 03:02 | <&Derakon> | By hand, usually. |
| 03:06 | <&Derakon> | The serialization used for savefiles and the like will be completely different, I expect. A lot more compact, for one thing. |
| 03:08 | < Rhamphoryncus> | depending on how effective gzip is ;) |
| 03:09 | <&Derakon> | Heh. |
| 03:09 | <&Derakon> | Yeah, it'll probably be a bunch of pickled objects, then gzipped. |
| 03:10 | < Rhamphoryncus> | heh |
| 03:11 | < Rhamphoryncus> | I would consider rolling your own format instead of json |
| 03:11 | <&Derakon> | Well, with the OrderedDict the only remaining thing that's bothering me is the quotation marks. |
| 03:11 | <&Derakon> | And that doesn't seem like enough of an issue to abandon standards. |
| 03:11 | | * Rhamphoryncus nods |
| 03:20 | <~Vornicus> | okay so |
| 03:21 | <~Vornicus> | I say, each thing should get its own line. |
| 03:21 | <~Vornicus> | Sparse is better when making human-editables. |
| 03:22 | <&Derakon> | If I did that then a single record wouldn't fit in view comfortably. |
| 03:27 | | * Rhamphoryncus checks out yaml.org |
| 03:28 | | * Rhamphoryncus checks out anything but yaml.org |
| 03:29 | <~Vornicus> | Der: oh well? |
| 03:29 | <~Vornicus> | I mean right now I'm looking at records that are several pages long printed and there's little I can do about it. |
| 03:30 | <~Vornicus> | If it's over 20 lines long then you're stuck. You can't have /everything/ above the fold. |
| 03:30 | <&Derakon> | I also should note that the newlines aren't inserted arbitrarily; they're grouping semi-related concepts. |
| 03:30 | <&McMartin> | Rhamphoryncus: This is why I considered YAML for my game review page data, and then decided that hand-editing XML in this format was better: https://hkn.eecs.berkeley.edu/~mcmartin/stack.xml |
| 03:31 | < Rhamphoryncus> | That actually looks good |
| 03:31 | < Rhamphoryncus> | Probably because there's large text blocks to ground it |
| 03:31 | <&McMartin> | As I said much earlier today: I'm partial to XML even for hand-editing, as long as I get to control the format. |
| 03:31 | < Rhamphoryncus> | content >> metadata |
| 03:31 | <&McMartin> | It's even more natural here, of course, because I'm using it to build XHTML with. |
| 03:32 | < Rhamphoryncus> | But Derakon's format will have farm more tag than content |
| 03:32 | <&McMartin> | That's true. |
| 03:32 | <&McMartin> | Though with all the flags, "element name *as* content" might be reasonable, etc. |
| 03:35 | | Janus [NSwebIRC@Nightstar-27138e8c.res.rr.com] has joined #code |
| 03:36 | | * Janus rolls in from out of nowhere. Brings the usual bag of dumb questions with him! |
| 03:36 | <&McMartin> | Many cores, no waiting. |
| 03:36 | | * McMartin goes off to get dinner |
| 03:39 | < Janus> | I was wonderin' what you folks use to parse .txt files if anything? I've just been... kinda brute forcing it up to now. Like. Reading and comparing letters or words at a time, and it's slightly different every time I write a parsing thingy. |
| 03:40 | <&McMartin> | This is oddly on-point at the moment. |
| 03:40 | <&McMartin> | Derakon has been working on setting up file formats. |
| 03:40 | <&Derakon> | Well, I'm working on converting from an old format to a new one. |
| 03:41 | <&Derakon> | I had to ad-hoc the parser for the old one. |
| 03:41 | <&Derakon> | What kind of text are you dealing with, Janus? |
| 03:41 | <&Derakon> | (As a general rule, with consistent formats, string.split will serve you well) |
| 03:42 | <&McMartin> | (If you've got a grammar built on it, there are theoretical constructs you can build on top of that, but while I'm an expert on it, I can't summarize it neatly before dinner~) |
| 03:42 | <&McMartin> | (I am working on a programming language compiler with All The Shinies in it, though, and it should be published soonish I hope. Or something that works end-to-end for a subset of it, anyhow.) |
| 03:46 | < Janus> | Well! the format can be anything, since I'd be writing the .txt files manually too. It'd just be a list of items or materials, with values like density and ignition point attached to them, and maybe tags like "brittle" or "glossy" |
| 03:46 | < Janus> | Writing a parser is pretty error prone for me though. ... like most other things. orz |
| 03:46 | < Namegduf> | I would really suggest using a standard format. |
| 03:47 | < Namegduf> | Like JSON or XML. |
| 03:47 | < Namegduf> | Let a structuring standard take care of encoding. |
| 03:47 | <&Derakon> | Yeah, if you're not shackled to a pre-existing format, just use a standard serialization/deserialization library. |
| 03:48 | <&Derakon> | It'll save you a lot of grief, and if you're worried about filesizes then you can just gzip them. |
| 03:48 | < Namegduf> | (Or use JSON, which will be barely larger than plaintext) |
| 03:48 | < Janus> | XML, I read a book on that -- er. I tried to read a book on that once, it was pretty cryptic. But I gathered it was just... a system of tags? Like... <athing> more things </athing>? |
| 03:48 | <&Derakon> | Pretty much. |
| 03:49 | <&Derakon> | HTML and XML look very similar in many ways. |
| 03:49 | < Namegduf> | http://json.org/ <- The index page here defines JSON formally. |
| 03:50 | | * Derakon discovers to his dismay that JSON does not allow you to have a comma after the last entry in a list. |
| 03:50 | < Namegduf> | It's basically foo { x: "y", a: "b" } |
| 03:50 | < Janus> | Oh, that doesn't seem too bad |
| 03:50 | <&Derakon> | So my manual recreation of JSON syntax to make things a little easier on my human users is getting semi-complicated. |
| 03:50 | < Namegduf> | Derakon: Yeah, that's always been illegal in JSON proper, because it was intended as an interchange standard rather than a "humans write this" standard. |
| 03:50 | < Namegduf> | Have you considered YAML? |
| 03:51 | <&Derakon> | I'm --> <-- this close to being done with the JSON approach. |
| 03:51 | < Namegduf> | It's JSON-derived and supports human-friendly syntax. Also complicated and big. |
| 03:51 | <&Derakon> | We had a discussion about the different options earlier. |
| 03:51 | < Namegduf> | Ah. |
| 03:51 | < Janus> | The writing part was what made me shy away from XML. At least, closing tags seemed like a pain |
| 03:51 | <&Derakon> | My main complaint with YAML actually is that unlike JSON it doesn't have a standard library built into Python. |
| 03:51 | < Namegduf> | Janus: JSON is much more succinct. |
| 03:51 | <&Derakon> | Again, trying to make things easier on other people. |
| 03:52 | < Namegduf> | Ah, I see. |
| 03:52 | < Namegduf> | You need both human readability AND standardisation? |
| 03:52 | <&Derakon> | (Though in this case it's more of a "I want people who are complete Python newbies to be able to get set up and running as easily as possible". Thus my only external dependency so far is wxPython) |
| 03:52 | <&Derakon> | I want as much of both as possible. |
| 04:04 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has quit [Client exited] |
| 05:29 | | eckse [eckse@Nightstar-17a53c9c.dsl.sentex.ca] has quit [Client closed the connection] |
| 05:29 | | eckse [eckse@Nightstar-17a53c9c.dsl.sentex.ca] has joined #code |
| 05:29 | | mode/#code [+o eckse] by ChanServ |
| 06:25 | | Derakon is now known as Derakon[AFK] |
| 07:16 | | eckse [eckse@Nightstar-17a53c9c.dsl.sentex.ca] has quit [Ping timeout: 121 seconds] |
| 08:25 | < Janus> | Oh man I love this json stuff. It's almost /too/ easy to add things now |
| 08:28 | <&McMartin> | Heh heh |
| 08:28 | <&McMartin> | Automatic serialization libraries are like a drug |
| 09:31 | | AnnoDomini [annodomini@Nightstar-087c9ed9.adsl.tpnet.pl] has joined #code |
| 09:31 | | mode/#code [+o AnnoDomini] by ChanServ |
| 10:14 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has joined #code |
| 10:42 | | Janus [NSwebIRC@Nightstar-27138e8c.res.rr.com] has quit [[NS] Quit: Page closed] |
| 12:15 | < gnolam> | TADPOLE relies heavily on JSON. |
| 12:17 | < gnolam> | All the material presets, all the project files. |
| 12:19 | < gnolam> | And in one instance, FrankenJSON - the project file data gzipped and base64-encoded. |
| 12:19 | <&McMartin> | Please |
| 12:19 | <&McMartin> | Surely such horror-show JSON should be called "Vorhees"? |
| 12:19 | < gnolam> | Hee |
| 12:24 | <&McMartin> | "Our death ray doesn't seem to be working. I'm standing right in it, and I'm not dead yet!" |
| 12:25 | < gnolam> | (The reason for the gzipping and base64-encoding being that it needs all the input data to make sense of the output data - the output only gives you the average energy deposited in each region per simulated particle, and then you need to work backwards from that using the relative activities and emission yields of all the nuclides involved to convert that to energy deposited over time (= dose rate).) |
| 12:26 | | * McMartin nods |
| 12:27 | < gnolam> | (So that input data needs to be embedded in a way that survives all the way through to the output files.) |
| 12:27 | <&McMartin> | It's the sort of thing where I'd prefer to drop the JSON wrapper and either use the bits directly, or shift over for that data to some kind of self-describing binary format like IFF. |
| 12:28 | < gnolam> | In this case, that would just be extra dev work for no real gain. |
| 12:30 | | Kindamoody is now known as Kindamoody|afk |
| 12:47 | | Stalker [Z@Nightstar-3602cf5a.cust.comxnet.dk] has quit [Ping timeout: 121 seconds] |
| 13:11 | | Rhamphoryncus [rhamph@Nightstar-5697f7e2.abhsia.telus.net] has joined #code |
| 13:23 | | Kindamoody|afk is now known as Kindamoody |
| 14:12 | | AnnoDomini [annodomini@Nightstar-087c9ed9.adsl.tpnet.pl] has quit [[NS] Quit: JUSTICE!] |
| 15:42 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 15:43 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has joined #code |
| 15:43 | | mode/#code [+o himi] by ChanServ |
| 16:14 | < Rhamphoryncus> | If a "cache" is only prefilled at the start (the contents are derived from something else and discardable when you're done) and has no replacement policy (a miss will always be a miss) what would you call it? |
| 16:16 | < gnolam> | A lookup table? |
| 16:17 | < Rhamphoryncus> | Doesn't seem right |
| 16:17 | | Derakon[AFK] is now known as Derakon |
| 16:25 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has quit [[NS] Quit: KABOOM! It seems that I have exploded. Please wait while I reinstall the universe.] |
| 16:25 | | celticminstrel [celticminst@Nightstar-5d22ab1d.cable.rogers.com] has joined #code |
| 16:47 | | Kindamoody is now known as Kindamoody|out |
| 17:01 | <@rms> | A Store or HashTable? |
| 17:05 | | * gnolam sticks by his LUT. |
| 17:24 | < Rhamphoryncus> | It's hard to describe because it's not doing anything special |
| 17:25 | < Rhamphoryncus> | "take data, process, store for future use" is something we do everywhere |
| 17:27 | <@rms> | Yeah, that's a LUT |
| 17:43 | | eckse [eckse@Nightstar-d9cc4185.dsl.sentex.ca] has joined #code |
| 17:43 | | mode/#code [+o eckse] by ChanServ |
| 17:45 | <&Derakon> | Yikes, my first pass at JSONifying the object records resulted in huge records. http://pastebin.com/WpqTHdRz |
| 17:47 | <@rms> | Well yeah, the other format was terse as all hell |
| 17:58 | < Rhamphoryncus> | yup |
| 18:00 | < Rhamphoryncus> | Does the damage line even exist? Or is it normally just a placeholder for objects that can't be used that way? |
| 18:01 | <&Derakon> | The P: line in the original record is for armor and weapon stats. |
| 18:01 | <&Derakon> | I'm omitting it for records where it's irrelevant. |
| 18:01 | <&Derakon> | There's a hell of a lot of items that just do 1d1 damage when thrown and otherwise have no armor/weapon stats. |
| 18:01 | | * Rhamphoryncus nods |
| 18:02 | < Rhamphoryncus> | hrm. Regex. I'm recommending regex. :/ |
| 18:02 | <&Derakon> | Oh, the conversion parser's complete. |
| 18:02 | < Rhamphoryncus> | No, I mean roll your own format rather than json |
| 18:02 | <&Derakon> | Oh. |
| 18:03 | <&Derakon> | I can compactify this while still having it be legal JSON. I'll just have to write my own serializer. |
| 18:03 | < Rhamphoryncus> | Look at piling. I'm not sure that's better than the original |
| 18:04 | <&Derakon> | I am thinking about restoring the "XdY" notation rather than having numDice and dieSize entries. |
| 18:05 | <&Derakon> | The original records had A+XdYMZ (e.g. "10+1d30M6"), and any one of those could be optional. That was kind of annoying. |
| 18:05 | <&Derakon> | E.g. you could just have "-10", or "d30M5" (with an implicit 1 at the front). |
| 18:09 | < Rhamphoryncus> | http://pastebin.com/jyPWebbn |
| 18:09 | < Rhamphoryncus> | That alone is an improvement over the original |
| 18:10 | <&Derakon> | Heh. |
| 18:10 | < Rhamphoryncus> | 'course I don't know half the fields there :P |
| 18:11 | <&Derakon> | Note that the line you labeled "damage" is actually base AC : base weapon damage : armor bonus : weapon finesse bonus : weapon prowess bonus [: weapon balance : weapon heft] |
| 18:11 | < Rhamphoryncus> | not surprising |
| 18:12 | < Rhamphoryncus> | that could be.. defence: 0:0 and offence: 1d1, 0, 0, 0 |
| 18:13 | < Rhamphoryncus> | Or have sublabels. AC on the defence line |
| 18:14 | | * Derakon eyes some other entries. |
| 18:14 | <&Derakon> | Dagger: weight: 1.200000000000000002. |
| 18:14 | <&Derakon> | Whoops. |
| 18:14 | < Rhamphoryncus> | The other approach: build an editor. The json is failing to being human editable, so bite the bullet and build something that is |
| 18:15 | < Rhamphoryncus> | everybody loves floating point ;) |
| 18:15 | <&Derakon> | I've considered building an editor into wizard mode. |
| 18:15 | <&Derakon> | But that's a later step |
| 18:15 | <&Derakon> | The main goal of JSONifying is to make the object record format more extensible. |
| 18:15 | <&Derakon> | So I can stick in optional data and have it work more nicely. |
| 18:15 | <&Derakon> | Changing the object record format in the original Angband is a major pain. |
| 18:15 | | * Rhamphoryncus nods |
| 18:16 | < Rhamphoryncus> | Then demote human editable to "where practical" |
| 18:16 | <&Derakon> | (Since you have to modify the records (often of every object), then modify the parser, the object model, and only then can you actually use the new data in the code) |
| 18:16 | <&Derakon> | Right. |
| 18:17 | <&Derakon> | The code used to enforce sequential item IDs too, for that matter. |
| 18:17 | <&Derakon> | Though I believe that at least has been fixed. |
| 18:18 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has quit [Connection reset by peer] |
| 18:19 | | ToxicFrog [ToxicFrog@ServerAdministrator.Nightstar.Net] has joined #code |
| 18:19 | | mode/#code [+o ToxicFrog] by ChanServ |
| 18:22 | <&jerith> | Vornicus: You've done this kind of thing before. |
| 18:23 | <&jerith> | I'm writing a dice roll statistics thing for a game I'm playtesting. |
| 18:24 | <&jerith> | There are five dice, and you get a single reroll of any number of them. |
| 18:25 | <&jerith> | But then there are modifiers. You can pay to reroll a subset of dice again, there are options to get an extra die or to reduce the cost of a combo you're trying to get. |
| 18:27 | <&jerith> | The combos are things like "two doubles, 3 or higher" and "sequence of three, starting at 2 or higher". |
| 18:39 | <&Derakon> | First pass at compactifying: http://pastebin.com/VYAyq732 |
| 18:39 | <&Derakon> | The allocation line's not so great, but the others seem passable. |
| 18:40 | <&jerith> | I have a brute-force thing that does the single-throw case. |
| 18:41 | | * Derakon amuseds at http://angband.oook.cz/forum/showpost.php?p=68557&postcount=5 |
| 18:48 | <@rms> | jerith: Are you implementing the one-roll system/ |
| 18:48 | <&jerith> | rms: I'm trying to model the probabilities for an existing game mechanic. |
| 18:49 | <&jerith> | Mostly so the designer can better tune the point values of each card. |
| 18:50 | <&jerith> | (He's a great artist and a decent game designer. He isn't really a statistician.) |
| 18:50 | <~Vornicus> | jerith: are you making yahtzee here? |
| 18:51 | <~Vornicus> | Optional rerolls are hellacious because now we're into game theory too. |
| 18:51 | <&jerith> | The mechanic is based on yahtzee. (Which I don't actually know.) |
| 18:55 | | * jerith wanders off to play Dominion for a bit. |
| 19:06 | | Kindamoody|out is now known as Kindamoody |
| 19:13 | | Syloq_Home [Syloq@NetworkAdministrator.Nightstar.Net] has quit [Client closed the connection] |
| 19:18 | | Eri [Eri@Nightstar-3e5deec3.gv.shawcable.net] has joined #code |
| 19:45 | | Kindamoody is now known as Kindamoody[zZz] |
| 20:33 | | Stalker [Z@Nightstar-5aa18eaf.balk.dk] has joined #code |
| 20:34 | <~Vornicus> | Man some people have too much time on their hands. |
| 20:35 | <~Vornicus> | APparently some researchers figured out how to make logic gates using live crabs. |
| 20:35 | < gnolam> | Linked it yesterday. |
| 20:36 | < gnolam> | <gnolam> http://www.complex-systems.com/pdf/20-2-2.pdf <- "In computer models and laboratory experiments we demonstrate that swarms of soldier crabs can implement logical gates when placed in a geometrically constrained environment" |
| 20:38 | <&Derakon> | Haven't they done the same thing with slime molds? |
| 20:40 | < gnolam> | I've only heard of various routing stuff done with slime molds. |
| 20:41 | < gnolam> | (Which thoroughly unimpresses me, BTW) |
| 21:05 | | Stalker [Z@Nightstar-5aa18eaf.balk.dk] has quit [[NS] Quit: If I had a world of my own, everything would be nonsense. Nothing would be what it is because everything would be what it isn't. And contrary-wise; what it is it wouldn't be, and what it wouldn't be, it would. You see?] |
| 21:08 | | Stalker [Z@Nightstar-5aa18eaf.balk.dk] has joined #code |
| 21:13 | | Serah [Z@Nightstar-5aa18eaf.balk.dk] has joined #code |
| 21:14 | | Stalker [Z@Nightstar-5aa18eaf.balk.dk] has quit [Ping timeout: 121 seconds] |
| 21:15 | < Rhamphoryncus> | jerith: when dice rolling gets complicated I've always resorted to randomly doing it a few (hundred) thousand times and collating the result |
| 21:24 | | Noah [noah@Nightstar-b8b9786c.pools.spcsdns.net] has joined #code |
| 21:53 | | himi [fow035@Nightstar-5d05bada.internode.on.net] has quit [Ping timeout: 121 seconds] |
| 22:06 | < Rhamphoryncus> | Oi, long trains are stupidly effective in openttd. Had a bogged network with 5 tile trains. Two stations were only pulling 50% and 85% of the available cargo. Replaced them all with 3 engine 10.5 tile trains and they do 100% cargo. Only problem is I have a massive backlog of unused trains XD |
| 22:11 | < Tarinaky> | You can have multiple engines? |
| 22:11 | < Tarinaky> | I thought that was only possible for Diesel Multiple Units? |
| 22:14 | < Rhamphoryncus> | nope, openttd has supported it forever |
| 22:14 | < Rhamphoryncus> | For aesthetics you usually put them all at the front, which in real life you had to do for steam engines |
| 22:18 | < Noah> | I saw something on the Science Channel about those fast trains that can run on old rail, they use magnetic eddie current breaking, and they have several smaller electric engines interspersed under the train, it's pretty neat |
| 22:19 | < Rhamphoryncus> | oh nice. I think the future will be more like that, but with magnetic acceleration too |
| 22:20 | < Rhamphoryncus> | Make every bogie a magnetic engine and you can even use it to control and reduce rail contact, reducing or eliminating wear |
| 22:21 | < Noah> | Well, the eddy current brakes are (technically) wearless, the German ICE 3s use them currently |
| 22:22 | < Noah> | I figured the future of railless trains would be more like magnetic "vacuum" tubes, where the train floats inside it |
| 22:23 | < Rhamphoryncus> | Oh I don't mean railless |
| 22:23 | < Noah> | Ah |
| 22:23 | < Rhamphoryncus> | I mean either existing rails (if the steel is acceptable) or something that can be used directly in place of |
| 22:23 | <&Derakon> | ...erk. Someone just pointed out to me that you can't insert comments into JSON. |
| 22:23 | <&Derakon> | That's a problem. |
| 22:24 | < Noah> | Wow, really? |
| 22:24 | < Noah> | YAML can I think |
| 22:24 | <&Derakon> | Yeah. |
| 22:24 | <&Derakon> | The suggestion was to use YAML for precisely that reason. |
| 22:25 | < Noah> | I guess the best you can do for JSON would to make an example file with comments explaining elements |
| 22:25 | <&Derakon> | And that only works for explaining generalities. |
| 22:25 | <&Derakon> | If you want to explain why this particular record has $weird_oddity then you're out of luck. |
| 22:25 | < Noah> | Right |
| 22:26 | < Namegduf> | Derakon: A fairly easy thing you can do is preprocess out comments. |
| 22:26 | < Namegduf> | But it is the biggest thing about JSON which is not designed for human read/writeability. |
| 22:26 | <&Derakon> | Yeah. |
| 22:27 | <&Derakon> | And preprocessing = ick. |
| 22:27 | < Namegduf> | Eh. |
| 22:27 | <&Derakon> | Ideally the resource files should be some standard format and Just Work. |
| 22:27 | < Namegduf> | No more so than gzip or SSL is. |
| 22:27 | < Rhamphoryncus> | Derakon: just make a comment section beside the description |
| 22:27 | < Namegduf> | Oh, for other program usage? |
| 22:27 | < Namegduf> | Yeah. |
| 22:27 | <&Derakon> | Rhamph: would work, but it's hackish as hell. |
| 22:27 | < Noah> | That's what I was thinking |
| 22:27 | < Rhamphoryncus> | Naw |
| 22:28 | < Rhamphoryncus> | Especially if you add an editor later it makes perfect sense |
| 22:30 | <&Derakon> | Mm, and if we assume that most modifications down the road will be done by editors instead of by hand, then non-data comments would likely get destroyed regularly anyway. |
| 22:30 | <&Derakon> | No good answer then. :( |
| 22:30 | < Namegduf> | Ah, yeah. |
| 22:31 | < Namegduf> | You'd need some format which preserved comments in the in-memory representation. |
| 22:31 | < Namegduf> | In some stable to write out manner. |
| 22:31 | < Namegduf> | This is possible and feasible but non-trivial and probably no standard format will do. |
| 22:31 | < Rhamphoryncus> | XML can |
| 22:31 | < Noah> | ewewew |
| 22:31 | < Rhamphoryncus> | But I prefer a comment field in json |
| 22:32 | <&Derakon> | Yeah, XML is out. |
| 22:32 | <&Derakon> | I know McM likes it, but for me it's too verbose. |
| 22:33 | < Namegduf> | YAML might be able to. It's an obscenely complicated format and I can't tell from the spec. |
| 22:33 | < Namegduf> | It says that "Comments are a presentation detail" and discusses comment generation but I'd need to actually read the whole file to know if it is retained in memory. |
| 22:34 | < Namegduf> | "presentation details" seem to include formatting preferences in the various alternative ways of writing data in YAML. |
| 22:34 | < Namegduf> | It isn't in Python as standard but there is at least a Python library. |
| 22:35 | < Namegduf> | If no better options can be found. |
| 22:35 | < Noah> | Yea, I've used the Python library, but I haven't had to deal with commenting just yet |
| 22:35 | < Namegduf> | I think standardisation of a human-editable config file format is not considered very important. |
| 22:35 | < Namegduf> | By most people using/making config file formats. |
| 22:35 | < Namegduf> | So good options are kinda limited. |
| 22:36 | < Namegduf> | If you think editors are going to be the main thing, you could just use JSON, have a comment field, and presume most people will be using editors anyway. |
| 22:36 | < Namegduf> | That'd be compromising in favour of ease of editor writing. |
| 22:37 | <&Derakon> | I honestly don't know what the dominant approach will be. |
| 22:37 | < Namegduf> | Ah. |
| 22:37 | <&Derakon> | Currently everyone does their edits by hand, but that's got to at least be in part because the existing format isn't parser-friendly. |
| 22:38 | < Namegduf> | Hrm. |
| 22:38 | < Namegduf> | Other ugly alternatives: Multiple config file formats, YAML->JSON processor option. |
| 22:39 | < Namegduf> | Maybe optionally support a YAML/custom file and generate a JSON file from it if present. |
| 22:39 | < Namegduf> | Problem is you can't have hand-editing and editors at once. |
| 22:39 | < Namegduf> | You need to delete the YAML file before the JSON file will work. |
| 22:39 | <&Derakon> | Yeah, having some kind of interchange format seems more complicated than beneficial. |
| 22:40 | < Noah> | http://pyyaml.org/ticket/114 |
| 22:41 | < Namegduf> | Looks like a no for preservation of comments in PyYAML. |
| 22:41 | < Rhamphoryncus> | IMO you've already lost the "human editable" part. There's just too much data to present cleanly without an editor. |
| 22:42 | < Namegduf> | I'm dubious that average users should ever be exposed to a config file. |
| 22:42 | < Namegduf> | And I tend to think those that directly tinker can handle rules like JSON's. |
| 22:42 | < Namegduf> | But that's ideal. |
| 22:42 | < Namegduf> | We have reality to deal with. |
| 22:44 | < Namegduf> | If users are already having to cope, making it harder for them is not a good thing. |
| 22:49 | | 629AAATFX is now known as sshine |
| 22:56 | < Noah> | "Write your own"? |
| 22:56 | <&Derakon> | Every time you write your own format, you also have to write your own parser. |
| 22:57 | < Namegduf> | It seems like he wants other people to be able to parse it without relying on a library in a language he wrote. |
| 22:57 | <&Derakon> | (And everyone who wants to use your data in a different language has to write their own parser, too) |
| 22:58 | < sshine> | does anyone here have experience with incremental database backups? |
| 23:00 | <&Derakon> | Hm, I think I don't like the way I handled the "A+XdYMZ" conversion. |
| 23:01 | <&Derakon> | That is, the original format specifies some numbers as A + XdY, plus a depth-dependent modifier Z. |
| 23:01 | <&Derakon> | E.g. 2 + 2d4 M8 means a range of 4-18, of which 4-10 is random and you get a bonus added on of up to 8 as you get deeper in the dungeon. |
| 23:02 | <&Derakon> | I split that out into four components, and then discovered that I'd need all four, if only as zeroes, when I get to the actual code anyway... |
| 23:02 | <&Derakon> | And having them each as separate components doesn't really improve legibility. |
| 23:05 | < Noah> | Fuck yea! Survivorman marathon! |
| 23:27 | | himi [fow035@D741F1.243F35.CADC30.81D435] has joined #code |
| 23:27 | | mode/#code [+o himi] by ChanServ |
| 23:55 | | Eri [Eri@Nightstar-3e5deec3.gv.shawcable.net] has quit [Operation timed out] |
| --- Log closed Mon Apr 16 00:00:15 2012 |