Necoro’s Blog

Blog? Blog? There is no blog…

Posts Tagged ‘Python

Portato’s new C-Modules

leave a comment »

As I’ve written yesterday I created an eix cache parser. But … it was overengineered: It took like ages and was way slower than the normal portage way:


$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 3.18 sec per loop
$ python -m timeit "import test; test.portage()"
10 loops, best of 3: 280 msec per loop

Thus I had to improve it: The first thing was to re-implement it using Cython. And step after step I ripped out features (in the original approach, the parser was lazy, i.e. only reading data if he needed to do so) and trimmed it down to what I really needed (opposed to being complete). Oh – and some C-level improvements :) (like using | instead of +).

Well: This is where I ended:

$ python -m timeit "import test; test.eix()"
10 loops, best of 3: 56 msec per loop

Now it is usable :)

Well — and while testing the new eix parser, I noticed, that Portato segfaults sometimes during shutdown. I thought the shm module the culprit and thus replaced the external dependency by a self-written module (again in Cython). And this also now uses message queues instead of shared memory — which is more intuitive and easier (no stupid locks and stuff). Seems to work up to now :)

Result: In the future, portato ships with C-Modules :) (hence the title

Written by Necoro

August 15, 2009 at 13:38

Posted in Portato, Python

Tagged with , , , , ,

Cobra — An alternative?

leave a comment »

As probably widely known, my preferred programming language is Python. But … well … I like to try out new things. Thus I sometimes look through the interwebs to find an interesting new alternative (Note: I still want to learn (and use) Haskell…). And recently I found Cobra: In short: It has a pythonic syntax, but knows natively about unit-tests and design by contract. The latter point is the interesting one: I also wanted to try D for the same purpose, but it a) has no real open source compiler (I know of), and b) pythonic look and feel is better then C-like. Only drawback(?): It is .NET based. But well … we’ll see how this works out. Cobra itself is also designed in a way, that it can use different backends later on. (I like exchangable backends :P)

The features of Cobra:

Lets put some code here (taken from the HowTo directory :))

class Utils

	shared

		def compute(x as float, y as float) as float
			require
				x > 0
				y > 0
			ensure
				result > 0   
			body
				return x.sqrt + y.sqrt

		def normalizeName(name as String) as String
			# If a contract has only one condition, you can write it
			# on one line and skip 'body'.
			require name.trim.length
			ensure result.length <= name.length
			return Utils.capped(name.trim)

		def capped(s as String) as String
			"""
			Returns the string with the first character capitalized.
			Returns a blank string for a blank string.
			"""
			ensure
				result.length == s.length
				result.length implies result[0] == result[0].toUpper
			test
				# Unit tests can enhance contracts by showing example
				# invocations and verifying behavior.
				assert Utils.capped('chuck')=='Chuck'
				assert Utils.capped('Chuck')=='Chuck'
				assert Utils.capped('')==''
				assert Utils.capped(' foo')==' foo'
				assert Utils.capped('f')=='F'
				assert Utils.capped('1aoeu')=='1aoeu'
			body
				if s.length
					return s[0:1].toUpper + s[1:]
				else
					return s

So … let’s see where this is going to lead :). I plan to make an ebuild for the next release (the current ones do not include sourcecode) … and then the fun can start.

Written by Necoro

April 8, 2009 at 22:59

Posted in Cobra

Tagged with , ,

Follow

Get every new post delivered to your Inbox.