Comments for drboblog

Comment on All aboard the Bendy Bus by Philip Withnall

Philip Withnall — Fri, 20 Jan 2012 21:19:46 +0000

Agreed. I guess it would also be good to statically check the reachability of every state in the machine before running it, and warn the user if some states were definitely not reachable. (I suspect that even for the restricted language I’ve allowed in machine descriptions, however, that reachability is undecidable.)

Comment on All aboard the Bendy Bus by Matteo Settenvini

Matteo Settenvini — Fri, 20 Jan 2012 09:29:34 +0000

I see. But I still suspect it would be more useful to have a guarantee of full coverage, were this tool to scale for more complex applications in the future. You could probably translate from one representation to the other automatically, and then look for coverability / reachability. Also because with complex data structures, the number of states in a PN would be likely to increase greatly, so specifying it by hand is not ideal.

Comment on All aboard the Bendy Bus by Philip Withnall

Philip Withnall — Thu, 19 Jan 2012 23:24:35 +0000

(I omitted from the blog post that Bendy Bus has built-in support for marking any data structure, such as would be returned in a D-Bus method reply, as fuzzable. Whenever that data structure (string, integer, array of structs, a{sv}, etc.) is evaluated, it’ll be fuzzed. This is achieved by using the ‘?’ postfix operator on the data structure in the machine description file. The value of the data structure in the machine description will be used as a default value, which may get through fuzzing unmodified, may be emptied/deleted, or may be mutated. Fairly standard fuzzing stuff, really.)

Comment on All aboard the Bendy Bus by Philip Withnall

Philip Withnall — Thu, 19 Jan 2012 23:20:08 +0000

Those look like interesting models, I’ll have to take a look into them, thanks.

However, the systems which are being modelled by Bendy Bus typically only have a couple of states, and reaching any of those states is statistically quite likely. For example, a simple model of a Telepathy connection manager would just have the states ‘disconnected’, ‘connecting’ and ‘connected’. In my experience so far, a lot of the code coverage comes as a result of fuzzing data in D-Bus method replies, and making random transitions inside a given state.

For example, the Telepathy machine I’ve been testing with will easily reach the ‘connected’ state, then randomly make transitions from ‘connected’ to ‘connected’, adding a contact to the contact list each time. Fuzzing the data on the contact (its alias, avatar, status, etc.) is what gets the code coverage — for Telepathy, at least.

It would be reassuring to be able to guarantee that all states in the simulation will be reached, but I suspect that most D-Bus services will have very few states.

Comment on All aboard the Bendy Bus by Matteo Settenvini

Matteo Settenvini — Thu, 19 Jan 2012 23:04:22 +0000

Question: if you are interested in verifying reachability of a set of states, why not using a Petri Net instead of a simple NFA? They allow for a set of very fast techniques for determining if a state can be reached, for example via a modified version of the Karp-Miller algorithm.

That way you don't need to "generate fuzzyness" and hope to get there statistically. Or maybe I misunderstood your words... but if you go by random, the problem is you might never catch the bad configuration you're looking for, which is not that nice.

If you don't like Petri Nets, there are other models that might be of interest, in the field of WSTSs (Well-Structured Transition Systems).

Comment on Character encoding and locales by kd_harrington

kd_harrington — Sun, 28 Aug 2011 08:36:37 +0000

Ye whittle meaning from the secrets of black magic.

Please could you explain supersymetry to me next ?

Comment on Character encoding and locales by Sean Burke

Sean Burke — Sun, 28 Aug 2011 04:28:57 +0000

I still feel like the best option here is to have your msgids written in American English and let gettext handle character set conversion. At least then your fallback strings will be mostly viewable.

Comment on Character encoding and locales by Sean Burke

Sean Burke — Sun, 28 Aug 2011 00:37:33 +0000

Ahh, right. Well, it's worth noting that just about any locale that isn't Western European (and probably some that are) will still have some people using locales which aren't byte-compatible with UTF-8. The punchline is, assuming people are using a UTF-8 locale is a Bad Idea. (I'm with Philip here.)

Comment on Character encoding and locales by Philip Withnall

Philip Withnall — Sat, 27 Aug 2011 20:45:42 +0000

Ack, yes. I somehow ended up thinking that iconv() would replace unrepresentable glyphs with a replacement character rather than just erroring.

For my second suggestion, the programmer can know ahead of time the full range of Unicode characters which may need transliterating, as they're just the ones used in the msgid strings. I'm not considering transliterating translated strings from message catalogues, as that would be ridiculous.

I guess if you can't find a useful representation of a given Unicode character in ASCII, there's always the replacement character. Not perfect, but the best I could come up with.

Comment on Character encoding and locales by Philip Withnall

Philip Withnall — Sat, 27 Aug 2011 20:26:57 +0000

Not UTF-8 compatible in that they're not encodings of Unicode, and their encodings aren't byte-compatible subsets of UTF-8 in the way that ISO-8859 is, for example.