Comments for Found http://www.pale.org Jim Finnis' personal blog Mon, 13 May 2013 00:37:21 +0000 hourly 1 http://wordpress.org/?v=3.5.1 Comment on post 3514 by Chef Robbie http://www.pale.org/?p=3514#comment-4663 Chef Robbie Mon, 13 May 2013 00:37:21 +0000 http://www.pale.org/?p=3514#comment-4663 It was Sergeant Wilson who had an Auntie Lettice.

]]> Comment on History by Jim http://www.pale.org/?p=5736#comment-4423 Jim Sun, 05 Feb 2012 22:09:55 +0000 http://www.pale.org/?p=5736#comment-4423 Pedantry.

]]> Comment on History by Chris http://www.pale.org/?p=5736#comment-4422 Chris Fri, 03 Feb 2012 10:11:51 +0000 http://www.pale.org/?p=5736#comment-4422 Thats not entirely true as not everyone starts at the same age :P.

]]> Comment on History by Dave http://www.pale.org/?p=5736#comment-4421 Dave Thu, 02 Feb 2012 23:57:39 +0000 http://www.pale.org/?p=5736#comment-4421 Well, I was 8 and 2 months, but yeah, OK. :D

]]> Comment on post 169 by Jim http://www.pale.org/?p=169#comment-4399 Jim Mon, 05 Dec 2011 22:56:46 +0000 http://www.pale.org/?p=169#comment-4399 Interesting. Blimey, I’d forgotten all about this. I hope I don’t stir him up again…

]]> Comment on post 169 by Neil http://www.pale.org/?p=169#comment-4398 Neil Mon, 05 Dec 2011 19:05:01 +0000 http://www.pale.org/?p=169#comment-4398 Funny looking back at all this 5 years on. The reason for the sacking was verbal abuse of a menber of the team, and hacking into the email accounts of other team members. He believed that others in the team were plotting against him and got increasingly volatile and aggresive in work. He was suspended and then sacked by the Head of the Library. He has kept a pretty low profile since.

]]> Comment on ARTOS – Audio Real-Time Operating System by Paul Norris http://www.pale.org/?p=5669#comment-4377 Paul Norris Thu, 13 Oct 2011 17:16:00 +0000 http://www.pale.org/?p=5669#comment-4377 I’ve got a bound copy of a paper that came with my PP10 called ‘Pythagoras – Software and System Design’ by Charles Francis. Its actually marked as confidential. I guess this is the paper you’re talking about?

Unfortunately the backup battery ran out on my unit so the software was deleted from the RAM, rendering it far and away the most expensive two units of dead electronics i’ve ever owned. I don’t have the installation floppies and TL Audio support department deny ever having produced this machine, which is useful of them.

]]> Comment on Lana: more progress by Andrew Tindall http://www.pale.org/?p=5704#comment-4375 Andrew Tindall Tue, 13 Sep 2011 17:29:58 +0000 http://www.pale.org/?p=5704#comment-4375 how long before jimscript is powerful enough to be used to create a sentient machine that tries to destroy humanity?

]]> Comment on Lana: docs and argh! by Jim http://www.pale.org/?p=5692#comment-4360 Jim Mon, 08 Aug 2011 12:39:46 +0000 http://www.pale.org/?p=5692#comment-4360 Aha, it’s more complicated than that. It’s already sort-of doing the right thing:

void setPropRef(Object *o, unsigned int propid) {
clr(); // the offending line, clears the previous value
d.o = o;
d2.u = id;
type = PropRef;
incRef();
}

The above code is called on the stack top value – the first thing it does is clr(), which clears the existing value, dereferencing the object and so deleting it. The incRef() later comes a little too late.

]]> Comment on Lana: docs and argh! by Jim http://www.pale.org/?p=5692#comment-4359 Jim Mon, 08 Aug 2011 09:51:38 +0000 http://www.pale.org/?p=5692#comment-4359 fabs(): the problem is the generated code – here’s the trace:

Lana System 0.0 command line interpreter
. create().foo=1
EXECUTE and clear
0 EXEC 8dc76e8 64: startestmt (0) < >
0 EXEC 8dc76ec 10: varref (create) (131082) < >
0 EXEC 8dc76f0 11: call (0) < > r:NF:08dccd48
0 EXEC 8dc76f4 15: propref (foo) (74) < > O:8dccf28/(ct1)
0 EXEC 8dc76f8 53: immed (1) < > PR:8dccf28/74
0 EXEC 8dc76fc 14: set (0) < > PR:8dccf28/74 I:1
Segmentation fault

This is what happens:

  • varref(create) puts a reference to the “create” global on the stack
  • call dereferences it and calls the value- a native function to create an object. This gives us an object with a refct of 1 (as we can see from the stack trace)
  • propref(foo) stacks a reference to the “foo” property in the object on top of the stack (the property doesn’t need to be set in the object, essentially the value is just a pointer to the object and the int property code)
  • immed(1) stacks the integer value 1
  • set should store the value on top of the stack into the reference one below. And this is where it all goes wrong. What happens if I look at the refcounting is that propref overwrites the value on top of the stack with a property reference, decrementing the reference count on the object that was stored in that slot. That’s correct. Unfortunately that causes the object to be deleted, because it’s refcount was just 1. What should happen is that the property reference also constitutes a reference, so the ref count should be incremented on the object before the overwrite. I think I’m not quite correctly accounting for proprefs as references.

I’ll look at it when I’ve got a minute.

]]>