Comments for Ahruman’s Webthing

Comment on Almost elegant cave man debugging by Jens Ayton

Jens Ayton — Sun, 05 Sep 2010 17:14:39 +0000

Kaks, that depends on whether the type decoding works in GNUstep. If so, it’s just a matter of adding the files. If not, well, it may be fiddly.

Comment on Almost elegant cave man debugging by Kaks

Kaks — Thu, 02 Sep 2010 13:25:50 +0000

Hmm, sounds like Oolite might be getting some more debugging stuff soon… Or am I reading too much into this? ;)

Comment on Almost elegant cave man debugging by Jens Ayton

Jens Ayton — Tue, 24 Aug 2010 18:13:38 +0000

As it turns out, the multi-pass fix was easier than I thought, and the parse tree harder – in particular, since it follows pointers in some cases, representing data locations in an abstract way becomes problematic. Bad luck for Joachim. :-)

Comment on Almost elegant cave man debugging by Jens Ayton

Jens Ayton — Tue, 24 Aug 2010 13:42:05 +0000

As it turns out, generating a parse tree may be a good idea, because correct alignment calculations sometimes require look-ahead. For example, in 64-bit, struct { int16_t a, struct { int16_t b, int64_t c }} is interpreted as [short][short][pad-32][long long], when it should be [short][pad-48][short][pad-48][long long]. Getting this right requires finding the alignment of the inner struct, which is the same as the alignment of the biggest element in it. An easier fix would be to use two passes to read structs, but this will still require redesign to get the alignment information where it’s needed.

Comment on Almost elegant cave man debugging by Jens Ayton

Jens Ayton — Sun, 22 Aug 2010 09:34:05 +0000

It’s a recursive descent parser which finds the type and location of each piece of data. Making a tree out of that is trivial; just build a node in each handler and pass the right parent node to any sub-decoder calls.

Comment on Almost elegant cave man debugging by Joachim Bengtsson

Joachim Bengtsson — Sun, 22 Aug 2010 08:41:31 +0000

Aw, I was hoping you were parsing the @encode expression into an object tree, and then making that into a string; I have wanted to transform the @encode string into something useful many times but never had the energy to parse strings :P This is probably a good start though, so thanks :)

(for example, I want to make an ffi cif from an encoding string to make this thing work better: http://github.com/nevyn/NSObject-AddMethod/blob/master/NSObject%2BAddMethod.h )

Comment on Proposal: generics (and some other stuff) for Objective-C by Jens Ayton

Jens Ayton — Mon, 28 Jun 2010 19:09:33 +0000

It wouldn’t break supersetosity if var could be redefined, somewhat analogous to the way self can be used in non-method contexts. But that would cause new problems, so I agree – an @-keyword would be better, yet uglier. (It could perhaps be defined to a normal identifier in a standard header, just as id is typedefed, or bool is in C99.)

Comment on Proposal: generics (and some other stuff) for Objective-C by Ondra Hošek

Ondra Hošek — Mon, 28 Jun 2010 18:56:08 +0000

I might be a bit late to the fray, but calling the infer-me type “var” would break ObjC’s strict-superset-ness, since I’d not be able to declare an “int var;” anymore. This is very probably the reason why every ObjC keyword is prefixed with an @ sign.

Comment on Hacking your Log Messages by Jens Ayton

Jens Ayton — Fri, 20 Nov 2009 13:18:44 +0000

This also works in The Cocotron as of r646.

Comment on Proposal: generics (and some other stuff) for Objective-C by Jens Ayton

Jens Ayton — Mon, 16 Nov 2009 23:16:09 +0000

“…add this metadata to the interface” is a good phrase. Every now and then, I read or write code like: - (NSArray *) frobs; // Array of JAFrob This is suboptimal for – once again – exactly the same reason - (id) frobs; // NSArray of JAFrob would be. The genericized form, - (NSArray[JAFrob] *) frobs; gives you the whole scoop in one place consistently with non-container methods.