Random Acts of Senseless Blogging

@Anonymous Sorry, not seen that error.

2010-03-31T15:13:43.403+01:00

@Anonymous Sorry, not seen that error.

It compiled using your commands but when I try to ...

2010-03-31T14:58:30.886+01:00

It compiled using your commands but when I try to run the testsuite or doing anything I get {"error":"bad_request","reason":"invalid UTF-8 JSON"}
Did you have the same Error or a solution for that?

@ThomasH. I've seen the ring of processes a fe...

2009-11-27T19:43:04.173Z

@ThomasH. I've seen the ring of processes a few times now as well as various Joe Armstrong talks but I don't think I've seen that one before. Thanks!

Just for your entertainment: This all goes back (I...

2009-11-27T15:02:23.090Z

Just for your entertainment: This all goes back (I think) to a very entertaining talk Joe Armstrong gave a couple of years ago at a small conference (LL2 at MIT), entitled "Concurrency oriented programming in Erlang", and I was really amused to see it re-surface in the Go presentation. It's very entertaining and still instructive, so if you have an hour and want something to smile, give it a go. It's the first talk of the morning session, so you don't have to wait through the video. But have his slides alongside :).

I managed to push the Erlang version to 1300000 by...

2009-11-16T22:34:06.204Z

I managed to push the Erlang version to 1300000 by shutting down everything and running from a terminal. Anything more than that and the Linux OOM killer kicked in and did its job ;-).

Sadly, I could only get the Go version up to about 260000 before memory was exhausted.

At 250000, Erlang took 0m2.401s and Go took 4m31.750s although the Go times were quite variable.

For reference, Erlang with 1000000 processes took 0m31.461s.

I don't have Stackless installed so can't provide timings for that, sorry.

How does it scale if you bump it up to 1,000,000 t...

2009-11-16T10:40:33.602Z

How does it scale if you bump it up to 1,000,000 tasklets? Does it increase by the same constant factor for all three languages?

I just updated the post with the latest xulrunner ...

2009-11-12T10:41:55.871Z

I just updated the post with the latest xulrunner paths (it's just been upgraded) and to use LD_RUN_PATH instead of LD_LIBRARY_PATH. LD_RUN_PATH gets built into the binary at link time making it faster and easier to run once installed.

@Anonymous thread locals may or may not be a probl...

2009-11-04T20:42:29.788Z

@Anonymous thread locals may or may not be a problem for you. It depends how you want to write and run your web application.

If you use thread locals you're limiting yourself to running in a web server that is threaded. That quite likely excludes event-driven servers, i.e. Twisted, eventlet/spawning, Tornado, and all the generator-based servers, that can typically handle huge numbers of concurrent connections.

If it makes sense for your application to use thread locals then fine, no problem. But why be forced down that route by a library or framework unless truly necessary?

I'm not saying that thread locals have no purpose but I believe they are often abused:

* to provide psuedo-globals. WSGI already has a great request-scoped place for this - the environ.

* for the "convenience" of not having to pass args to functions. Passing args around is a good thing - it's explicit and makes code more readable, testable and predictable.

restish doesn't use thread locals (it works fine in a threaded or event-driven server) and explicitly passes the request/environ to anything that needs it. That's the way I like it ;-).

So, what is the problem with thread locals? I'...

2009-11-04T16:41:44.196Z

So, what is the problem with thread locals? I'm looking at different frameworks right now trying to pick one out. Is thread locals something I should be concerned with? (I dont have much experience with threads locals or their downsides)

Thanks for sharing this. I just setup a vm of karm...

2009-11-01T17:32:52.522Z

Thanks for sharing this. I just setup a vm of karmic and I'm just itching to experiment (-:

@AK I've just rewritten the post. I hope it he...

2009-11-01T10:32:17.127Z

@AK I've just rewritten the post. I hope it helps but, if not, let me know and I'll try to help.

Sorry, but this is quite interesting so can you pr...

2009-11-01T09:17:47.804Z

Sorry, but this is quite interesting so can you provide some context to this, like what sudo apt-get packages are required.

Oops, fixed. Thanks Anonymous.

2009-09-19T13:44:54.195+01:00

Oops, fixed. Thanks Anonymous.

typo: s/Torndao/Tornado/;

2009-09-19T02:25:05.930+01:00

typo: s/Torndao/Tornado/;

@Matt That's perfectly fine, I am always happy to ...

2009-01-03T15:23:00.000Z

@Matt That's perfectly fine, I am always happy to be corrected :-)

@Esaj sorry for singling out your specific post to...

2009-01-03T14:56:00.000Z

@Esaj sorry for singling out your specific post to the CouchDB mailing list but it really just reminded me of something I've seen in a few other places and always struck me as unnecessary.

For reference, here's the thread that started started this.

Thanks for the comments!

Hehe, it's the first time I've posted a sentence t...

2009-01-03T14:28:00.000Z

Hehe, it's the first time I've posted a sentence to a mailing list only to find it has sparked a whole blog post about the subject! Yes, the sentence on its own was an utter falsehood, but in my defence, I was trying to get at the fact that new unique UUIDs *must* be generated *every single time* they are requested, and any in-between proxies cannot cache anything or "optimise" multiple GET requests into one or anything like that.

Now, after further research into the HTTP RFC it seems that operations are all transparent unless otherwise explicitly requested, so in fact my worries were probably unfounded.

Actually, the UUID generator changes no state in C...

2009-01-03T09:30:00.000Z

Actually, the UUID generator changes no state in CouchDB. CouchDB relies on the uniqueness "guarantees" inherent in UUIDs to assume that the UUIDs are currently unused and do not need to be reserved.

It's safe to GET the resource multiple times, has no unintended side effects and does not affect other clients. Therefore, it seems to me that the _uuid resource, used in isolation, is both safe and idempotent.

While I don't know CouchDB internals, it sounds to...

2009-01-03T07:18:00.000Z

While I don't know CouchDB internals, it sounds to me like the implementation of the unique ID does change the server state (and it would be too difficult to remove that from the implementation and still be able to provide a uniqueness guarantee) so the CouchDB implementers are doing the right thing.

The flaw in your example is that a time server is not required to require a unique response for every request. Two responses that are close enough together (or happening effectively simultaneously on different processors) can return the same response. Since it does not provide a uniqueness guarantee, a timeserver can be RESTful and use GET.

I doubt you can come up with an implementation of a UUID generator that is both stateless and portable.