From geek_show at dsl.pipex.com Wed Dec 5 19:12:58 2007 From: geek_show at dsl.pipex.com (andy) Date: Wed, 05 Dec 2007 18:12:58 +0000 Subject: [python-uk] Anyone alive Message-ID: <4756EA2A.6050106@dsl.pipex.com> Hi all At the risk of being flamed, I just wanted to see if this list was still active. I've been a subscriber for a few days now and there have been no posts. Andy -- "If they can get you asking the wrong questions, they don't have to worry about the answers." - Thomas Pynchon, "Gravity's Rainbow" From fuzzyman at voidspace.org.uk Wed Dec 5 19:18:28 2007 From: fuzzyman at voidspace.org.uk (Michael Foord) Date: Wed, 05 Dec 2007 18:18:28 +0000 Subject: [python-uk] Anyone alive In-Reply-To: <4756EA2A.6050106@dsl.pipex.com> References: <4756EA2A.6050106@dsl.pipex.com> Message-ID: <4756EB74.4000500@voidspace.org.uk> andy wrote: > Hi all > > At the risk of being flamed, I just wanted to see if this list was still > active. I've been a subscriber for a few days now and there have been no > posts. > No-one here but us chickens... Michael http://www.manning.com/foord > Andy > > From Pierre.DeWet at BITC.ORG.UK Wed Dec 5 19:16:22 2007 From: Pierre.DeWet at BITC.ORG.UK (Pierre DeWet) Date: Wed, 05 Dec 2007 18:16:22 +0000 Subject: [python-uk] Anyone alive (Out of office) Message-ID: I will be out of the office until Monday 10 December. If your request is urgent, please contact the helpdesk at: helpdesk at bitc.org.uk, alternatively, please dial: 0207 566 8771 Cheers Pierre From tim.couper at scivisum.co.uk Wed Dec 5 19:20:29 2007 From: tim.couper at scivisum.co.uk (Tim Couper) Date: Wed, 05 Dec 2007 18:20:29 +0000 Subject: [python-uk] Anyone alive In-Reply-To: <4756EA2A.6050106@dsl.pipex.com> References: <4756EA2A.6050106@dsl.pipex.com> Message-ID: <4756EBED.4050609@scivisum.co.uk> yes alive and used for announcing uk-specific python events (and other chat), like the upcoming meet-up in London tomorrow evening, if I'm not mistaken .. Tim Dr Tim Couper CTO, SciVisum Ltd www.scivisum.com andy wrote: > Hi all > > At the risk of being flamed, I just wanted to see if this list was still > active. I've been a subscriber for a few days now and there have been no > posts. > > Andy > > From mail at timgolden.me.uk Wed Dec 5 19:36:19 2007 From: mail at timgolden.me.uk (Tim Golden) Date: Wed, 05 Dec 2007 18:36:19 +0000 Subject: [python-uk] Anyone alive In-Reply-To: <4756EA2A.6050106@dsl.pipex.com> References: <4756EA2A.6050106@dsl.pipex.com> Message-ID: <4756EFA3.30706@timgolden.me.uk> andy wrote: > Hi all > > At the risk of being flamed, I just wanted to see if this list was still > active. I've been a subscriber for a few days now and there have been no > posts. This list tends to be used for meetup or job postings (ie things which are specific to the UK). Every so often there's a burst of other activity, but I think most people subscribe to the main Python mailing list / newsgroup (python-list at python.org or comp.lang.python). Feel free to post here or there with questions etc. And have a look at the PyConUK Groups page, which seems to have become the de facto starting point for UK-based Python groups http://www.pyconuk.org/community/PythonGroups TJG From a.harrowell at gmail.com Wed Dec 5 19:45:47 2007 From: a.harrowell at gmail.com (Alexander Harrowell) Date: Wed, 5 Dec 2007 18:45:47 +0000 Subject: [python-uk] Anyone alive? Message-ID: I'm sure many have seen this: http://xkcd.com/353/ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-uk/attachments/20071205/c45da632/attachment.htm From geek_show at dsl.pipex.com Wed Dec 5 19:50:35 2007 From: geek_show at dsl.pipex.com (andy) Date: Wed, 05 Dec 2007 18:50:35 +0000 Subject: [python-uk] Anyone alive? In-Reply-To: References: Message-ID: <4756F2FB.9050308@dsl.pipex.com> Alexander Harrowell wrote: > I'm sure many have seen this: > > http://xkcd.com/353/ > ------------------------------------------------------------------------ > > _______________________________________________ > That's funny!! :) Thanks -- "If they can get you asking the wrong questions, they don't have to worry about the answers." - Thomas Pynchon, "Gravity's Rainbow" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-uk/attachments/20071205/a04e3f5e/attachment.htm From geek_show at dsl.pipex.com Wed Dec 5 19:37:33 2007 From: geek_show at dsl.pipex.com (andy) Date: Wed, 05 Dec 2007 18:37:33 +0000 Subject: [python-uk] Anyone alive In-Reply-To: <4756EBED.4050609@scivisum.co.uk> References: <4756EA2A.6050106@dsl.pipex.com> <4756EBED.4050609@scivisum.co.uk> Message-ID: <4756EFED.4080503@dsl.pipex.com> Tim Couper wrote: > yes alive and used for announcing uk-specific python events (and other > chat), like the upcoming meet-up in London tomorrow evening, if I'm not > mistaken .. > > Tim > > Dr Tim Couper > CTO, SciVisum Ltd > > www.scivisum.com > > > > andy wrote: > >> Hi all >> >> At the risk of being flamed, I just wanted to see if this list was still >> active. I've been a subscriber for a few days now and there have been no >> posts. >> >> Andy >> >> >> > _______________________________________________ > Well then hello both Tim & Michael. What are the toics for tomorrow's meeting Tim? A -- "If they can get you asking the wrong questions, they don't have to worry about the answers." - Thomas Pynchon, "Gravity's Rainbow" -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-uk/attachments/20071205/9672812b/attachment.htm From andy at reportlab.com Thu Dec 6 10:11:56 2007 From: andy at reportlab.com (Andy Robinson) Date: Thu, 6 Dec 2007 09:11:56 +0000 Subject: [python-uk] Anyone alive In-Reply-To: <4756EFED.4080503@dsl.pipex.com> References: <4756EA2A.6050106@dsl.pipex.com> <4756EBED.4050609@scivisum.co.uk> <4756EFED.4080503@dsl.pipex.com> Message-ID: <956003ae0712060111k41ad1f9ev39517c5f16d80565@mail.gmail.com> > Well then hello both Tim & Michael. What are the toics for tomorrow's > meeting Tim? It was last night while this thread was going on. Several mini talks at Thoughtworrks office, very well attended, I skipped the pub afterwards but at least 30 people headed that way... - Andy From mgrazebrook at compuserve.com Fri Dec 7 01:42:46 2007 From: mgrazebrook at compuserve.com (Michael Grazebrook) Date: Fri, 07 Dec 2007 00:42:46 +0000 Subject: [python-uk] Forwarding an Agency python request Message-ID: <47589706.6060701@compuserve.com> I know it's an agency, and know nothing about the agency, but since at least one person at last night's meeting was looking for work I hope it's OK to forward the following spam: ------ From othon.vroulakis at it-skillfinder.co.uk A leading investment bank, located in Central London, is currently looking for Python developers to join their team. The ideal candidate will have great technical skills as well as a proven financial background (ideally in credit derivatives). Duration of contract: 6 months extendable with the choice of working permanently for the employer. Excellent rates guaranteed. Start date: ASAP but could wait for the right person. Othon Vroulakis IT- Skillfinder 20 St Dunstan's Hill London EC3R 8HY www.it-skillfinder.co.uk Direct Line: +44 (0)20 7256 3538 Switchboard: +44 (0)20 7256 3550 Fax: +44(0)20 7256 3551 From rakesh.thakrar at microcom-recruitment.com Fri Dec 7 10:31:22 2007 From: rakesh.thakrar at microcom-recruitment.com (Rakesh Thakrar) Date: Fri, 7 Dec 2007 09:31:22 -0000 Subject: [python-uk] Python and Linux Vacancies Message-ID: Hi All, I am looking for a number of Permanent Python Developers for clients based in Central London, South London and Bristol. I am also looking for a Linux enthusiasts (graduates welcome to apply) for an innovative software company in Cambridge. If you are interested in finding out more please do not hesitate to contact me. Regards Rakesh ___________________ Rakesh Thakrar Manager Microcom Recruitment Division Tel: 0845 389 2322 Mob: 079 7094 3227 Fax: 0845 389 2392 www.microcom-recruitment.com Unit F The Chase Foxholes Business Park John Tate Road Hertford SG13 7NN Permanent and Contract IT Recruitment Specialists ____________________________________ ************************************************************ The views expressed in this e-mail are not necessarily the views of European Recruitment Network Ltd, its directors, officers or employees make no representation or accept any liability for its accuracy or completeness unless expressly stated to the contrary. This e-mail, and any attachments are strictly confidential and intended for the addressee(s) only. The content may also contain legal, professional or other privileged information. Unless expressly stated to the contrary, no contracts may be concluded on behalf of European Recruitment Network Ltd by means of e-mail communication. You may report the matter by calling us on 0845 389 2322. Please ensure you have adequate virus protection before you open or detach any documents from this transmission. European Network Recruitment Ltd does not accept any liability for viruses. European Recruitment Network Ltd is registered in England: Company number: 5651508. Registered Office: Greener House, 66-68 Haymarket, London, SW1Y 4RF ************************************************************ -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-uk/attachments/20071207/fe955813/attachment.htm From ms at cerenity.org Sun Dec 9 00:51:15 2007 From: ms at cerenity.org (Michael Sparks) Date: Sat, 8 Dec 2007 23:51:15 +0000 Subject: [python-uk] Minimalistic software transactional memory Message-ID: <200712082351.16237.ms@cerenity.org> I've just posted this message on comp.lang.python fishing for comments, but I'll post it here in case there's any feedback this way :-) (apologies for any dupes people get - I don't *think* python-uk & pyconuk are strict subsets) I'm interested in writing a simple, minimalistic, non persistent (at this stage) software transactional memory (STM) module. The idea being it should be possible to write such a beast in a way that can be made threadsafe fair easily. For those who don't know, STM is a really fancy way of saying variables with version control (as far as I can tell :-) designed to enable threadsafe shared data. I'm starting with the caveat here that the following code is almost certainly not threadsafe (not put any real thought into that as yet), and I'm interested in any feedback on the following: * Does the API look simple enough? * Are there any glaring mistakes in the code ? (It's always harder to see your own bugs) * What key areas appear least threadsafe, and any general suggestions around that. If I get no feedback I hope this is of interest. Since these things get archived, if you're reading this a month, 6 months, a year or more from now, I'll still be interested in feedback... OK, API. First of all we need to initialise the store: S = Store() We then want to get a value from the store such that we can use the value, and do stuff with it: greeting = S.using("hello") Access the value: print repr(greeting.value) Update the value: greeting.set("Hello World") Commit the value back to the store: greeting.commit() If you have concurrent updates of the same value, the following exception gets thrown: ConcurrentUpdate cf: >>> S = Store() >>> greeting = S.using("hello") >>> par = S.using("hello") >>> greeting.set("Hello World") >>> par.set("Woo") >>> greeting.commit() >>> par.commit() Traceback (most recent call last): File "", line 1, in File "", line 12, in commit File "", line 11, in set __main__.ConcurrentUpdate That's pretty much the simplest API I can come up with. (I've tried a few others but didn't really like them) The way this works is we have a Store that manages Values. (perhaps a better name may be variables to avoid clashing with pythons parlance of labels and values?) Anyhow, you can ask the store for Value, which it will give you. The Value knows what it's called and where it's from, so when you tell it to commit, it can try to do so. The little detail here is you get a copy of the Value not the stored Value. (This is to avoid accidental concurrent update of the same actual object) As a result, Store looks like this: class Store(object): def __init__(self): self.store = {} def get(self, key): return self.store[key].clone() def set(self, key, value): if not (self.store[key].version > value.version): self.store[key] = Value(value.version+1, value.value, self, key) value.version= value.version+1 else: raise ConcurrentUpdate def using(self, key): try: return self.get(key) except KeyError: self.store[key] = Value(0, None,self,key) return self.get(key) def dump(self): for k in self.store: print k, ":", self.store[k] You'll note that the set method is the greatest candidate for any possible race hazard here - though I can see a possible boundary issue in "using". (I think :-) Otherwise I think the above code is relatively straightforward. You'll note that this API allows this: greeting.set("Hello") greeting.commit() greeting.set("Hello World") greeting.commit() greeting.set("Hello World. Game") greeting.commit() greeting.set("Hello World. Game Over") greeting.commit() The other class is value that looks like this: class Value(object): def __init__(self, version, value,store,key): self.version = version self.value = value self.store = store self.key = key def __repr__(self): return "Value"+repr((self.version,self.value,self.store,self.key)) def set(self, value): self.value = value def commit(self): self.store.set(self.key, self) def clone(self): return Value(self.version, self.value,self.store,self.key) To me this looks like a pretty complete minimalistic thing, which does seem to work OK, but I'm interested in the three points I mention above - if anyone is willing to comment - specifcally: * Does the API look simple enough? * Are there any glaring mistakes in the code ? (It's always harder to see your own bugs) * What key areas appear least threadsafe, and any general suggestions around that. Full code below. Many thanks for any comments in advance, Michael -- Michael Sparks, Kamaelia Project Lead http://kamaelia.sourceforge.net/Developers/ http://yeoldeclue.com/blog #!/usr/bin/python class ConcurrentUpdate(Exception): pass class Value(object): def __init__(self, version, value,store,key): self.version = version self.value = value self.store = store self.key = key def __repr__(self): return "Value"+repr((self.version,self.value)) def set(self, value): self.value = value def commit(self): self.store.set(self.key, self) def clone(self): return Value(self.version, self.value,self.store,self.key) class Store(object): def __init__(self): self.store = {} def get(self, key): return self.store[key].clone() def set(self, key, value): if not (self.store[key].version > value.version): self.store[key] = Value(value.version+1, value.value, self, key) value.version= value.version+1 else: raise ConcurrentUpdate def using(self, key): try: return self.get(key) except KeyError: self.store[key] = Value(0, None,self,key) return self.get(key) def dump(self): for k in self.store: print k, ":", self.store[k] S = Store() greeting = S.using("hello") print repr(greeting.value) greeting.set("Hello World") greeting.commit() # ------------------------------------------------------ print greeting S.dump() # ------------------------------------------------------ par = S.using("hello") par.set("Woo") par.commit() # ------------------------------------------------------ print greeting S.dump() # ------------------------------------------------------ greeting.set("Woo") greeting.commit() print repr(greeting), repr(greeting.value) S.dump() From mike at decipher.me.uk Mon Dec 10 10:20:00 2007 From: mike at decipher.me.uk (Mike Ross) Date: Mon, 10 Dec 2007 09:20:00 -0000 (GMT) Subject: [python-uk] Python and Linux Vacancies In-Reply-To: References: Message-ID: <47192.69.93.64.122.1197278400.squirrel@mail3.webfaction.com> Hi Rakesh, Can you provide me with more details on the Python vacancies in Central and South London? What are the full job descriptions and which companies are recruiting? Regards, Mike Ross. > Hi All, > > > > I am looking for a number of Permanent Python Developers for clients > based in Central London, South London and Bristol. > > > > I am also looking for a Linux enthusiasts (graduates welcome to apply) > for an innovative software company in Cambridge. > > > > If you are interested in finding out more please do not hesitate to > contact me. > > > > Regards > > Rakesh > > > > ___________________ > Rakesh Thakrar > Manager > Microcom > Recruitment Division > Tel: 0845 389 2322 > Mob: 079 7094 3227 > Fax: 0845 389 2392 > www.microcom-recruitment.com > Unit F > The Chase > Foxholes Business Park > John Tate Road > Hertford > SG13 7NN > > Permanent and Contract IT Recruitment Specialists > > ____________________________________ > > ************************************************************ > The views expressed in this e-mail are not necessarily the views of > European Recruitment Network Ltd, its directors, officers or employees > make no representation or accept any liability for its accuracy or > completeness unless expressly stated to the contrary. > This e-mail, and any attachments are strictly confidential and intended > for the addressee(s) only. > The content may also contain legal, professional or other privileged > information. Unless expressly stated to the contrary, no contracts may > be concluded on behalf of European Recruitment Network Ltd by means of > e-mail communication. You may report the matter by calling us on 0845 > 389 2322. > Please ensure you have adequate virus protection before you open or > detach any documents from this transmission. European Network > Recruitment Ltd does not accept any liability for viruses. > > European Recruitment Network Ltd is registered in England: Company > number: > 5651508. > Registered Office: Greener House, 66-68 Haymarket, London, SW1Y 4RF > > ************************************************************ > > > > _______________________________________________ > python-uk mailing list > python-uk at python.org > http://mail.python.org/mailman/listinfo/python-uk > From rakesh.thakrar at microcom-recruitment.com Mon Dec 10 14:04:41 2007 From: rakesh.thakrar at microcom-recruitment.com (Rakesh Thakrar) Date: Mon, 10 Dec 2007 13:04:41 -0000 Subject: [python-uk] Python and Linux Vacancies Message-ID: Hi Mike, Thanks for getting back to me. Could you please send me your CV with your contact details? Regards Rakesh -----Original Message----- From: python-uk-bounces at python.org [mailto:python-uk-bounces at python.org] On Behalf Of Mike Ross Sent: Monday, December 10, 2007 9:20 AM To: UK Python Users Subject: Re: [python-uk] Python and Linux Vacancies Hi Rakesh, Can you provide me with more details on the Python vacancies in Central and South London? What are the full job descriptions and which companies are recruiting? Regards, Mike Ross. > Hi All, > > > > I am looking for a number of Permanent Python Developers for clients > based in Central London, South London and Bristol. > > > > I am also looking for a Linux enthusiasts (graduates welcome to apply) > for an innovative software company in Cambridge. > > > > If you are interested in finding out more please do not hesitate to > contact me. > > > > Regards > > Rakesh > > > > ___________________ > Rakesh Thakrar > Manager > Microcom > Recruitment Division > Tel: 0845 389 2322 > Mob: 079 7094 3227 > Fax: 0845 389 2392 > www.microcom-recruitment.com > Unit F > The Chase > Foxholes Business Park > John Tate Road > Hertford > SG13 7NN > > Permanent and Contract IT Recruitment Specialists > > ____________________________________ > > ************************************************************ > The views expressed in this e-mail are not necessarily the views of > European Recruitment Network Ltd, its directors, officers or employees > make no representation or accept any liability for its accuracy or > completeness unless expressly stated to the contrary. > This e-mail, and any attachments are strictly confidential and intended > for the addressee(s) only. > The content may also contain legal, professional or other privileged > information. Unless expressly stated to the contrary, no contracts may > be concluded on behalf of European Recruitment Network Ltd by means of > e-mail communication. You may report the matter by calling us on 0845 > 389 2322. > Please ensure you have adequate virus protection before you open or > detach any documents from this transmission. European Network > Recruitment Ltd does not accept any liability for viruses. > > European Recruitment Network Ltd is registered in England: Company > number: > 5651508. > Registered Office: Greener House, 66-68 Haymarket, London, SW1Y 4RF > > ************************************************************ > > > > _______________________________________________ > python-uk mailing list > python-uk at python.org > http://mail.python.org/mailman/listinfo/python-uk > _______________________________________________ python-uk mailing list python-uk at python.org http://mail.python.org/mailman/listinfo/python-uk From r.taylor at eris.qinetiq.com Tue Dec 11 14:36:14 2007 From: r.taylor at eris.qinetiq.com (Richard Taylor) Date: Tue, 11 Dec 2007 13:36:14 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712082351.16237.ms@cerenity.org> References: <200712082351.16237.ms@cerenity.org> Message-ID: <200712111336.18980.r.taylor@eris.qinetiq.com> Mike I don't think that you can rely on the threadsafety of these functions. Even if they are threadsafe in C Python (which I doubt that 'set' is), the locking in Jython in more fine grained and would likely catch you out. I would suggest that you should routinely wrap shared datamodels like these in thread locks to be certain about things. I would also suggest that a small change to the Value class would make it possible for client code to subclass it, which might make it more flexible. Here is my suggestion, bare in mind that I have not tested the thread locking code beyond making sure that it runs :-) Regards Richard #!/usr/bin/python from threading import Lock, RLock class Locker(object): def __init__(self,lock): self._lock = lock def __call__(self): lock = self._lock def wrap(f): def newFunction(*args, **kw): lock.acquire() try: return f(*args, **kw) finally: lock.release() return newFunction return wrap write_lock = Locker(Lock()) read_lock = Locker(RLock()) class ConcurrentUpdate(Exception): pass class Value(object): def __init__(self, version, value,store,key, *tup, **kw): self.version = version self.value = value self.store = store self.key = key self.tup = tup self.kw = kw def __repr__(self): return "Value"+repr((self.version,self.value)) def set(self, value): self.value = value def commit(self): self.store.set(self.key, self) def clone(self): return self.__class__(self.version, self.value,self.store,self.key,*self.tup, **self.kw) class Store(object): def __init__(self, value_class=Value): self.store = {} self.value_class = value_class @read_lock() def get(self, key): return self.store[key].clone() @write_lock() def set(self, key, value): if not (self.store[key].version > value.version): self.store[key] = self.value_class(value.version+1, value.value, self, key) value.version= value.version+1 else: raise ConcurrentUpdate @read_lock() def using(self, key): try: return self.get(key) except KeyError: self.store[key] = self.value_class(0, None,self,key) return self.get(key) def dump(self): for k in self.store: print k, ":", self.store[k] S = Store() greeting = S.using("hello") print repr(greeting.value) greeting.set("Hello World") greeting.commit() print greeting S.dump() # ------------------------------------------------------ par = S.using("hello") par.set("Woo") par.commit() # ------------------------------------------------------ print greeting S.dump() # ------------------------------------------------------ greeting.set("Woo") try: greeting.commit() except ConcurrentUpdate: print "Received ConcurrentUpdate exception" print repr(greeting), repr(greeting.value) S.dump() On Saturday 08 December 2007, Michael Sparks wrote: > I've just posted this message on comp.lang.python fishing for comments, but > I'll post it here in case there's any feedback this way :-) > > (apologies for any dupes people get - I don't *think* python-uk & pyconuk are > strict subsets) > > I'm interested in writing a simple, minimalistic, non persistent (at this > stage) software transactional memory (STM) module. The idea being it should > be possible to write such a beast in a way that can be made threadsafe fair > easily. > > For those who don't know, STM is a really fancy way of saying variables > with version control (as far as I can tell :-) designed to enable threadsafe > shared data. > > I'm starting with the caveat here that the following code is almost > certainly not threadsafe (not put any real thought into that as yet), > and I'm interested in any feedback on the following: > > * Does the API look simple enough? > * Are there any glaring mistakes in the code ? (It's always harder to see > your own bugs) > * What key areas appear least threadsafe, and any general suggestions > around that. > > If I get no feedback I hope this is of interest. Since these things get > archived, if you're reading this a month, 6 months, a year or more from > now, I'll still be interested in feedback... > > OK, API. > > First of all we need to initialise the store: > > S = Store() > > We then want to get a value from the store such that we can use the value, > and do stuff with it: > > greeting = S.using("hello") > > Access the value: > > print repr(greeting.value) > > Update the value: > > greeting.set("Hello World") > > Commit the value back to the store: > > greeting.commit() > > If you have concurrent updates of the same value, the following exception > gets thrown: > ConcurrentUpdate > > cf: > >>> S = Store() > >>> greeting = S.using("hello") > >>> par = S.using("hello") > >>> greeting.set("Hello World") > >>> par.set("Woo") > >>> greeting.commit() > >>> par.commit() > Traceback (most recent call last): > File "", line 1, in > File "", line 12, in commit > File "", line 11, in set > __main__.ConcurrentUpdate > > That's pretty much the simplest API I can come up with. (I've tried a few > others but didn't really like them) > > The way this works is we have a Store that manages Values. (perhaps a better > name may be variables to avoid clashing with pythons parlance of labels and > values?) > > Anyhow, you can ask the store for Value, which it will give you. The Value > knows what it's called and where it's from, so when you tell it to commit, > it can try to do so. The little detail here is you get a copy of the > Value not the stored Value. (This is to avoid accidental concurrent update > of the same actual object) > > As a result, Store looks like this: > > class Store(object): > def __init__(self): > self.store = {} > > def get(self, key): > return self.store[key].clone() > > def set(self, key, value): > if not (self.store[key].version > value.version): > self.store[key] = Value(value.version+1, value.value, self, key) > value.version= value.version+1 > else: > raise ConcurrentUpdate > > def using(self, key): > try: > return self.get(key) > except KeyError: > self.store[key] = Value(0, None,self,key) > return self.get(key) > > def dump(self): > for k in self.store: > print k, ":", self.store[k] > > You'll note that the set method is the greatest candidate for any possible > race hazard here - though I can see a possible boundary issue in "using". > (I think :-) > > Otherwise I think the above code is relatively straightforward. You'll note > that this API allows this: > > greeting.set("Hello") > greeting.commit() > greeting.set("Hello World") > greeting.commit() > greeting.set("Hello World. Game") > greeting.commit() > greeting.set("Hello World. Game Over") > greeting.commit() > > The other class is value that looks like this: > > class Value(object): > def __init__(self, version, value,store,key): > self.version = version > self.value = value > self.store = store > self.key = key > > def __repr__(self): > return "Value"+repr((self.version,self.value,self.store,self.key)) > > def set(self, value): > self.value = value > > def commit(self): > self.store.set(self.key, self) > > def clone(self): > return Value(self.version, self.value,self.store,self.key) > > To me this looks like a pretty complete minimalistic thing, which does seem > to work OK, but I'm interested in the three points I mention above - if > anyone is willing to comment - specifcally: > > * Does the API look simple enough? > * Are there any glaring mistakes in the code ? (It's always harder to see > your own bugs) > * What key areas appear least threadsafe, and any general suggestions > around that. > > Full code below. > > Many thanks for any comments in advance, > > > Michael > -- > Michael Sparks, Kamaelia Project Lead > http://kamaelia.sourceforge.net/Developers/ > http://yeoldeclue.com/blog > > #!/usr/bin/python > > class ConcurrentUpdate(Exception): pass > > class Value(object): > def __init__(self, version, value,store,key): > self.version = version > self.value = value > self.store = store > self.key = key > > def __repr__(self): > return "Value"+repr((self.version,self.value)) > > def set(self, value): > self.value = value > > def commit(self): > self.store.set(self.key, self) > > def clone(self): > return Value(self.version, self.value,self.store,self.key) > > class Store(object): > def __init__(self): > self.store = {} > > def get(self, key): > return self.store[key].clone() > > def set(self, key, value): > if not (self.store[key].version > value.version): > self.store[key] = Value(value.version+1, value.value, self, key) > value.version= value.version+1 > else: > raise ConcurrentUpdate > > def using(self, key): > try: > return self.get(key) > except KeyError: > self.store[key] = Value(0, None,self,key) > return self.get(key) > > def dump(self): > for k in self.store: > print k, ":", self.store[k] > > S = Store() > greeting = S.using("hello") > print repr(greeting.value) > greeting.set("Hello World") > greeting.commit() > # ------------------------------------------------------ > print greeting > S.dump() > # ------------------------------------------------------ > par = S.using("hello") > par.set("Woo") > par.commit() > # ------------------------------------------------------ > print greeting > S.dump() > # ------------------------------------------------------ > greeting.set("Woo") > greeting.commit() > > print repr(greeting), repr(greeting.value) > > S.dump() > _______________________________________________ > pyconuk mailing list > pyconuk at python.org > http://mail.python.org/mailman/listinfo/pyconuk > > -- QinetiQ B009 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS Jabber: RichardTaylor at jabber.org PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7DA9FD9 Key fingerprint = D051 A121 E7C3 485F 3C0E 1593 ED9E D868 A7DA 9FD9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/python-uk/attachments/20071211/4a005fb1/attachment.pgp From ms at cerenity.org Tue Dec 11 18:15:51 2007 From: ms at cerenity.org (Michael Sparks) Date: Tue, 11 Dec 2007 17:15:51 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712111336.18980.r.taylor@eris.qinetiq.com> References: <200712082351.16237.ms@cerenity.org> <200712111336.18980.r.taylor@eris.qinetiq.com> Message-ID: <200712111715.52077.ms@cerenity.org> Hi Richard, On Tuesday 11 December 2007 13:36, Richard Taylor wrote: > I don't think that you can rely on the threadsafety of these functions. > Even if they are threadsafe in C Python (which I doubt that 'set' is), the > locking in Jython in more fine grained and would likely catch you out. It's perhaps worth noting in the version of the code I posted, in this thread, where it said... """What key areas appear least threadsafe, and any general suggestions around that.""" ...I knew that set and using were not threadsafe, but wondered about other parts. I perhaps should've been more explicit on that point. (I wanted to simply post some ideas which showed the core logic without locking. Perhaps a mistake :) Anyhow, the current version is here: https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/branches/private_MPS_Scratch/Bindings/STM/Axon/STM.py In that version, "set" now looks like this: def set(self, key, value): success = False if self.lock.acquire(0): try: if not (self.store[key].version > value.version): self.store[key] = Value(value.version+1, copy.deepcopy(value.value), self, key) value.version= value.version+1 success = True finally: self.lock.release() else: raise BusyRetry if not success: raise ConcurrentUpdate and "using" has changed to "usevar: (using now relates to a collection) def usevar(self, key): try: return self.get(key) except KeyError: if self.lock.acquire(0): try: self.store[key] = Value(0, None,self,key) finally: self.lock.release() else: raise BusyRetry return self.get(key) Since mutations of the store rely on acquiring the lock on the store, that should be safe(r). User code doesn't have to worry about locks however - which is course the point of the code :-) The reason for specifically using the acquire(0) call rather than acquire() call is because I want it to fail hard if the lock can't be acquired. I know it'd be nicer to have a finer grained lock here, but I'm personally primarily going to be using this for rare operations rather than common operations. These locks above are of course in relation to write locking. I'll think about the read locking you've suggested. Your locking looks incorrect on using since it both allows reading and writing of the store. (retrieve value & if not present create & initialise) I also think the independent locks are a misnomer, but they're useful for thinking about it. > I would suggest that you should routinely wrap shared datamodels like these > in thread locks to be certain about things. Indeed. It makes the code look worse, so for this example I was really after suggestions (like yours :-) of "OK, where does this break badly" as well as "does the logic look sane?". > I would also suggest that a small change to the Value class would make it > possible for client code to subclass it, which might make it more flexible. I'm not convinced by the changes to Value - its there for storing arbitrary values, rather than extending Value itself. It's probably worth noting that .clone has changed in my version to this: def clone(self): return Value(self.version, copy.deepcopy(self.value),self.store,self.key) Which includes deepcopy on the value stored by Value. I'm beginning to think that Value should be called "Variable" to make this clearer... > Here is my suggestion, bare in mind that I have not tested the thread > locking code beyond making sure that it runs :-) The feedback is much appreciated - it's making me think more about the read locking aspect. I suspect the GIL in CPython *may* make the reads safe, but the lack of a GIL in jython & ironpython probably renders the reads in using & get unsafe. (and I would like this to be safe in jython & ironpython) It's interesting though, after having developed large amounts of code of code based on no-shared-data & read-only/write-only pipes with data handoff and not having had any major concurrency issues (despite mixing threads and non threads) switching to a shared data model instantly causes problems. The difference is really stark. One is simple, natural and easy and the other is subtle & problematic. I'm not shocked, but find it amusing :-) Many thanks for the feedback! Michael. From r.taylor at eris.qinetiq.com Wed Dec 12 09:43:14 2007 From: r.taylor at eris.qinetiq.com (Richard Taylor) Date: Wed, 12 Dec 2007 08:43:14 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712111715.52077.ms@cerenity.org> References: <200712082351.16237.ms@cerenity.org> <200712111336.18980.r.taylor@eris.qinetiq.com> <200712111715.52077.ms@cerenity.org> Message-ID: <200712120843.18345.r.taylor@eris.qinetiq.com> Mike On Tuesday 11 December 2007, Michael Sparks wrote: > Hi Richard, > > > On Tuesday 11 December 2007 13:36, Richard Taylor wrote: > > I don't think that you can rely on the threadsafety of these functions. > > Even if they are threadsafe in C Python (which I doubt that 'set' is), the > > locking in Jython in more fine grained and would likely catch you out. > > It's perhaps worth noting in the version of the code I posted, in this thread, > where it said... > > """What key areas appear least threadsafe, and any general suggestions > around that.""" > > ...I knew that set and using were not threadsafe, but wondered about other > parts. I perhaps should've been more explicit on that point. (I wanted to > simply post some ideas which showed the core logic without locking. Perhaps a > mistake :) > I did miss the subtlety :-) but at least it prompted me to reply! > Anyhow, the current version is here: > > https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/branches/private_MPS_Scratch/Bindings/STM/Axon/STM.py > > In that version, "set" now looks like this: > def set(self, key, value): > success = False > if self.lock.acquire(0): > try: > if not (self.store[key].version > value.version): > self.store[key] = Value(value.version+1, > copy.deepcopy(value.value), > self, key) > value.version= value.version+1 > success = True > finally: > self.lock.release() > else: > raise BusyRetry > > if not success: > raise ConcurrentUpdate > > and "using" has changed to "usevar: (using now relates to a collection) > > def usevar(self, key): > try: > return self.get(key) > except KeyError: > if self.lock.acquire(0): > try: > self.store[key] = Value(0, None,self,key) > finally: > self.lock.release() > else: > raise BusyRetry > > return self.get(key) > > Since mutations of the store rely on acquiring the lock on the store, that > should be safe(r). User code doesn't have to worry about locks however - > which is course the point of the code :-) > I like to use explicit read locks for shared data structures, mainly because it makes it much safer when someone comes along and adds functionality to the methods later on. The next developer may not realise that the method needs to be threadsafe so the explicit locking code will help. I like to use decorators for the same reason, it is very easy to get the try/finally wrong end up with deadlocks. I think that I would split the usevar method in two and use decorators to acquire the read and write locks e.g. @read_lock() def usevar(self, key): try: return self.get(key) except KeyError: return self.make(key) @write_lock() def make(self,key): self.store[key] = Value(0, None,self,key) return self.get(key) > The reason for specifically using the acquire(0) call rather than acquire() > call is because I want it to fail hard if the lock can't be acquired. I know > it'd be nicer to have a finer grained lock here, but I'm personally primarily > going to be using this for rare operations rather than common operations. > Personally I am not sure that I would bother with the non-blocking acquire here. It will complicate the client code and the length of time that the lock will be held will be so small that almost all client code will simply retry the set. So I would go for a blocking acquire or maybe add a timeout based exception to catch a deadlock. > These locks above are of course in relation to write locking. I'll think about > the read locking you've suggested. > > Your locking looks incorrect on using since it both allows reading and writing > of the store. (retrieve value & if not present create & initialise) Yep, I did say that it was not tested :-) It is wrong on 'set' as well, as 'set' should acquire both the read and the write lock. > I also think the independent locks are a misnomer, but they're useful for > thinking about it. > > > I would suggest that you should routinely wrap shared datamodels like these > > in thread locks to be certain about things. > > Indeed. It makes the code look worse, so for this example I was really after > suggestions (like yours :-) of "OK, where does this break badly" as well as > "does the logic look sane?". Decorators help to hide the details from the main code path. I think that decorators are over used sometimes, but in this case I think that are very useful. > > I would also suggest that a small change to the Value class would make it > > possible for client code to subclass it, which might make it more flexible. > > I'm not convinced by the changes to Value - its there for storing arbitrary > values, rather than extending Value itself. It's probably worth noting > that .clone has changed in my version to this: > > def clone(self): > return Value(self.version, > copy.deepcopy(self.value),self.store,self.key) > > Which includes deepcopy on the value stored by Value. I'm beginning to think > that Value should be called "Variable" to make this clearer... > I just have a tendency to like to enable flexibility from client code where it is possible. I think I have fought with library code that was inflexible one too many times :-) > It's interesting though, after having developed large amounts of code of code > based on no-shared-data & read-only/write-only pipes with data handoff and > not having had any major concurrency issues (despite mixing threads and non > threads) switching to a shared data model instantly causes problems. > > The difference is really stark. One is simple, natural and easy and the other > is subtle & problematic. I'm not shocked, but find it amusing :-) I agree. Where possible we use 'pipe and filter' or 'message queue' patterns for inter-thread communication. We have a library based around the MASCOT design method that uses concepts of 'queues' and 'pools', which has proved very powerful for large multi-threaded applications. We have found that the best way to avoid thread related problems is to indulge in a little design work to explicitly limit all thread communication to a few well thought through mechanisms and then police their use rigidly. Regards Richard -- QinetiQ B009 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS Jabber: RichardTaylor at jabber.org PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7DA9FD9 Key fingerprint = D051 A121 E7C3 485F 3C0E 1593 ED9E D868 A7DA 9FD9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/python-uk/attachments/20071212/949a3f7c/attachment-0001.pgp From jamesdtarin at googlemail.com Fri Dec 14 15:51:43 2007 From: jamesdtarin at googlemail.com (james tarin) Date: Fri, 14 Dec 2007 14:51:43 +0000 Subject: [python-uk] DJANGO/Python Developer positions (Contract/Permanent) Message-ID: Hi There, I'm hoping it is OK to post this message to this list, as I have seen Job ads here before: We are currently expanding our in-house team to take forward the development of an exciting Web 2.0 business networking platform and have both permanent and contract opportunities for django/python developers. We are a small team which is working on a functionally complex Web 2.0networking platform and are looking for talented developers to play an important role in this innovative project. Comfortable working with others and able to talk to non-technical staff, this is an opportunity for your creative side. The people we're looking for will have experience in requirements analysis, design, coding and unit testing of scalable, distributed, fault-tolerant applications in Web environments. You will also need the following: - Development experience using Python and preferably DJANGO - Experience of at least one other OO language such as Java or C++ - Hands-on knowledge of relational databases (preferably PostgreSQL) - Basic LINUX system administration skills - Experience of working with Subversion or other source control systems If you are in need of a new challenge then give me (James) a ring on 01865 339395 or mail me at spam*at*meltwaterventures.com -------------- next part -------------- An HTML attachment was scrubbed... URL: http://mail.python.org/pipermail/python-uk/attachments/20071214/5b995ec1/attachment.htm From ms at cerenity.org Thu Dec 20 00:43:10 2007 From: ms at cerenity.org (Michael Sparks) Date: Wed, 19 Dec 2007 23:43:10 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712120843.18345.r.taylor@eris.qinetiq.com> References: <200712082351.16237.ms@cerenity.org> <200712111715.52077.ms@cerenity.org> <200712120843.18345.r.taylor@eris.qinetiq.com> Message-ID: <200712192343.11023.ms@cerenity.org> On Wednesday 12 December 2007 08:43:14 Richard Taylor wrote: > I like to use explicit read locks for shared data structures, mainly > because it makes it much safer when someone comes along and adds > functionality to the methods later on. I've had a think about this - especially with regard to reading locks - and thought in more detail about how the functions operate and what API is likely to get used. In the end I came to the conclusion that the problem areas are (naturally) these parts: class Store(object): def usevar(self, key): def set(self, key, value): def using(self, *keys): def set_values(self, D): The thing here all of these functions have in common is they are all read-write on the state (eg creating non-pre-existing vars). So rather than having separate read & write locks, I've decided on a single lock for read-write. The API for store has also changed such that it has the following methods as well: def __get(self, key): def __make(self, key): def __do_update(self, key, value): def __can_update(self,key, value): These however assume the store is locked by the caller. (incidentally, I split a conceptual __try_update into __can & __do since that makes __do_update reusable. (DRY principle) ) They're marked private to indicate to a user that using these outside the class could easily cause problems. I agree generally speaking about using decorators, however, this is intended to be used in Kamaelia's core concurrency framework "Axon". At present that code is largely python 2.2.late compatible, meaning that it should be portable to Nokia Series 60 phones as well as Jython. The other aspect is we have very very minimal reimplementations of the core in Ruby & C++ (as well as a shedskin compiled version), and I've even seen a Java reimplementation of the core as well.... So decorators - nice as they are (and relevant here) - are something I try and avoid - in the core at least. Using just the one lock though simplfies the boiler plating, and also I feel dramatically reduces the chances of any form of lock up based on trying to access the STM. > > It's interesting though, after having developed large amounts of code > > based on no-shared-data & read-only/write-only pipes with data handoff > > and not having had any major concurrency issues (despite mixing threads > > and non threads) switching to a shared data model instantly causes > > problems. > > > > The difference is really stark. One is simple, natural and easy and the > > other is subtle & problematic. I'm not shocked, but find it amusing :-) > > I agree. Where possible we use 'pipe and filter' or 'message queue' > patterns for inter-thread communication. We have a library based around the > MASCOT design method that uses concepts of 'queues' and 'pools', which has > proved very powerful for large multi-threaded applications. I'd not heard of MASCOT - I'll take a look into it. It sounds very similar to what we currently do in Kamaelia. I suspect pools maybe similar to what we call backplanes. > We have found > that the best way to avoid thread related problems is to indulge in a > little design work to explicitly limit all thread communication to a few > well thought through mechanisms and then police their use rigidly. Indeed. That's the main reason for slowly progressing this STM code :-) I think the latest iteration is now minimally sufficiently safe. (ie safe from user code for the 4 main calls a user can/will do) The current iteration of the code can be found here: https://kamaelia.svn.sourceforge.net/svnroot/kamaelia/branches/private_MPS_Scratch/Bindings/STM/Axon/STM.py Many thanks for the feedback - much appreciated! Regards, Michael. -- http://yeoldeclue.com/blog http://kamaelia.sourceforge.net/Developers/ From r.taylor at eris.qinetiq.com Thu Dec 20 08:55:11 2007 From: r.taylor at eris.qinetiq.com (Richard Taylor) Date: Thu, 20 Dec 2007 07:55:11 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712192343.11023.ms@cerenity.org> References: <200712082351.16237.ms@cerenity.org> <200712120843.18345.r.taylor@eris.qinetiq.com> <200712192343.11023.ms@cerenity.org> Message-ID: <200712200755.15903.r.taylor@eris.qinetiq.com> Mike On Wednesday 19 December 2007, Michael Sparks wrote: > The thing here all of these functions have in common is they are all > read-write on the state (eg creating non-pre-existing vars). So rather than > having separate read & write locks, I've decided on a single lock for > read-write. That is reasonable. There can be performance improvements from using separate read/write locks under certain loads, but I doubt that is an issue here. > I agree generally speaking about using decorators, however, this is intended > to be used in Kamaelia's core concurrency framework "Axon". At present that > code is largely python 2.2.late compatible, meaning that it should be > portable to Nokia Series 60 phones as well as Jython. The other aspect is we > have very very minimal reimplementations of the core in Ruby & C++ (as well > as a shedskin compiled version), and I've even seen a Java reimplementation > of the core as well.... I see your problem. Decorators are not for you at the moment. > > I agree. Where possible we use 'pipe and filter' or 'message queue' > > patterns for inter-thread communication. We have a library based around the > > MASCOT design method that uses concepts of 'queues' and 'pools', which has > > proved very powerful for large multi-threaded applications. > > I'd not heard of MASCOT - I'll take a look into it. It sounds very similar to > what we currently do in Kamaelia. I suspect pools maybe similar to what we > call backplanes. You won't find much on MASCOT unfortunately: http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Operation_and_Test gives you the bare bones but not much else. Although I currently work for the successor of the Royal Radar Establishment at Malvern, where the method was developed, I did not learn it here. I was taught it as part of my decree course at Aberystwyth in the late 80s. Anyone else out there still using MASCOT? Regards Richard -- QinetiQ B009 Woodward Building St. Andrews Road Malvern Worcs WR14 3PS Jabber: RichardTaylor at jabber.org PGPKey: http://pgp.mit.edu:11371/pks/lookup?op=get&search=0xA7DA9FD9 Key fingerprint = D051 A121 E7C3 485F 3C0E 1593 ED9E D868 A7DA 9FD9 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 189 bytes Desc: This is a digitally signed message part. Url : http://mail.python.org/pipermail/python-uk/attachments/20071220/f2da20cc/attachment.pgp From ms at cerenity.org Thu Dec 20 12:26:15 2007 From: ms at cerenity.org (Michael Sparks) Date: Thu, 20 Dec 2007 11:26:15 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712200755.15903.r.taylor@eris.qinetiq.com> References: <200712082351.16237.ms@cerenity.org> <200712192343.11023.ms@cerenity.org> <200712200755.15903.r.taylor@eris.qinetiq.com> Message-ID: <200712201126.15774.ms@cerenity.org> On Thursday 20 December 2007 07:55:11 Richard Taylor wrote: > That is reasonable. There can be performance improvements from using > separate read/write locks under certain loads, but I doubt that is an issue > here. Indeed. I'm tempted to do value level locking at somepoint, but performance isn't likely to be an issue here. > You won't find much on MASCOT unfortunately: > http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Oper >ation_and_Test gives you the bare bones but not much else. But that gives me enough search terms to find this: http://www.object-forge.com/ And from that I should be able to ferret out more... Which gives me: http://www.object-forge.com/Release1.0/docs/abbref.zip Which gives me a reference PDF! :-D >Although I > currently work for the successor of the Royal Radar Establishment at > Malvern, where the method was developed, I did not learn it here. I was > taught it as part of my decree course at Aberystwyth in the late 80s. It sounds really interesting and seems to have a fair amount in common with Kamaelia - with probably pools being the only thing really missing - though the tracker (the CAT) which is designed to track values & services looks *close* to being like pools. Not quite the same, but close. Our backplanes are similar in a way, but rather different as well (they're more ephemeral and more a pub/sub thing than a store/retrieve - which the pools appear to be). Reading more of that PDF, it looks like our CAT (co-ordinating assistant tracker) is perhaps very much closest to MASCOT's pools, but because it's not been anything like an STM or similar it's been relatively crippled. The idea of being able to use the cat to produce a simple solution to the dining philosophers problem is quite amusing: take forks... (pseudo python, ignoring various details) not_have_forks = True while not_have_forks: try: S = forks = S.using("fork.1", "fork.2") if forks["1"].value == None and forks["2"].value == None: forks["1"].value = id(self) forks["2"].value = id(self) forks.commit() not_have_forks = False except ConcurrentUpdate: time.sleep(random()) # random backoff - doesn't guarantee success except BusyRetry: time.sleep(random()) # random backoff - doesn't guarantee success eat() # Put forks back - should always succeed. Should. :-) try: forks["1"].value = None forks["2"].value = None forks.commit() except ConcurrentUpdate: pass except BusyRetry: pass I'd not even really bothered with the dining philosopher's problems because it's not mapped to a real world problem so far for us, but that PDF made it clear that's what we can do on page 16... In Kamaelia, a component appears to be equivalent to mascot activity. (We allow generators, threads and (experimentally) processes to be the activity part a component) The linkages between outboxes and inboxes appear to be directly equivalent to a MASCOT channel. Furthermore, given under the hood we collapse inboxes and outboxes together as an optimisation when a linkage is made, the relationship between llnkage/box and a MASCOT channel is quite obvious... A key difference though is that channels appear to exist independently in a system - this I guess means that the MASCOT activities need to know the global/subsystem name of the channel upfront ? (Whereas, effectively, we provide a local alias which the system wires up at runtime) Hmm... looking at this more, I'm guessing no - because it looks like these can be arguments. Reading more, it looks like all our inbox/outboxes default to being directly equivalent to MASCOT argument connections. However, component is also our unit of composition so component is also our equivalent to a MASCOT subsystem. Though we do have Chassis components whose purpose is largely to have something you bolt other components to. MASCOT set's appear to be very similar (from description) to our concept of pipelines and graphlines. It also appears that the fact we can introspect running systems to look at linkages/boxes/components visually seems to be something we have in common (based on object forge descriptions!) You may find this page relatively amusing: * http://kamaelia.sourceforge.net/Docs/NotationForVisualisingAxon (That notation isn't widely used because the visualisation/visual creation tool we use doesn't use that notation, but the doc above was one of the earliest sketch ideas for a notation) Reading through that PDF it looks like somethings we do make life simpler (people appear to have to use locking directly in that implementation). > Anyone else out there still using MASCOT? I suspect I'm going to be ferreting out as much information about MASCOT as I can :-) Very many thanks for the feedback and search terms - amazingly useful! :-D Merry Christmas :-) Michael. From tibs at tibsnjoan.co.uk Thu Dec 20 23:07:03 2007 From: tibs at tibsnjoan.co.uk (Tony Ibbs) Date: Thu, 20 Dec 2007 22:07:03 +0000 Subject: [python-uk] Cambridge & East Anglia Pub Meeting, 8th Feb Message-ID: The next meeting of the Cambridge & East Anglia Python group will be at 8pm on Tuesday 8th February 2008 at the Carlton Arms (http://www.thecarltonarms.co.uk/). Meetings after that will be on the first Tuesday of each month, same time, same place. Tony Ibbs / Tibs -- tibs at tibsnjoan.co.uk http://www.pyconuk.org/community/Cambridge_and_East_of_England http://groups.google.com/group/campug From tibs at tibsnjoan.co.uk Thu Dec 20 23:11:28 2007 From: tibs at tibsnjoan.co.uk (Tony Ibbs) Date: Thu, 20 Dec 2007 22:11:28 +0000 Subject: [python-uk] Cambridge & East Anglia Pub Meeting, 8th *Jan*, not Feb Message-ID: Apologies -- the next Cambridge & East Anglian Python group meeting will be on the 8th *January* 2008. The other details were right, though: Carlton Arms at 8pm. Tony Ibbs / Tibs From ms at cerenity.org Fri Dec 21 17:51:58 2007 From: ms at cerenity.org (Michael Sparks) Date: Fri, 21 Dec 2007 16:51:58 +0000 Subject: [python-uk] [pyconuk] Minimalistic software transactional memory In-Reply-To: <200712200755.15903.r.taylor@eris.qinetiq.com> References: <200712082351.16237.ms@cerenity.org> <200712192343.11023.ms@cerenity.org> <200712200755.15903.r.taylor@eris.qinetiq.com> Message-ID: <200712211651.58702.ms@cerenity.org> On Thursday 20 December 2007 07:55:11 Richard Taylor wrote: > You won't find much on MASCOT unfortunately: > http://en.wikipedia.org/wiki/Modular_Approach_to_Software_Construction_Oper >ation_and_Test This was indeed enough for me to find lots :-) Including: * The Official Handbook of Mascot : Version 3.1 : June 1987 http://async.org.uk/Hugo.Simpson/MASCOT-3.1-Manual-June-1987.pdf linked from: * http://async.org.uk/Hugo.Simpson/ Interestingly (to me :-), reading the documention, their starting point was essentially very similar to mine - cf http://kamaelia.sourceforge.net/Introduction Well, I do like doing software archaeology... (I have a copy of Simula BEGIN for example, along with various occam books :-) Something striking - the above manual is over 20 years old, and appears intensely relevant today. Secondly, that manual covers version 3.1. Version 1 dates back to 1975 (according to Hugo Simpson's page) - predating Smalltalk (but 8 years after Simula had its first book published...). It's really incredible just how much of their wheels we've reinvented :-) I don't know whether to be really happy (reinvention of something previously successful implies its a good idea :-) or whether to cry :-) (really happy really :-) Michael -- http://yeoldeclue.com/blog http://kamaelia.sourceforge.net/Developers/