A killer recipe..

If you got an idee-fixe-du-jour, all you need to do is to hint your friend to come back to you and attach some official task to it for you. Preferrably with the supposed deadline, and make it all very seriozz.

The idea du jour will lose a lot of its sparkling - so you'll get your best to get rid of it as soon as you can.

This behaviour indeed not anything of an invention, but feels quite funny to experience it consciously.

I'm curious if this is the timing that matters, or really it is that the idee-du-jour would really be persistent in case it was worth it - so one can really use it as a "tester" ?

Impressive 3d for your home use..

The videos are not so new, but I did not see them before. I can feel a trip to the shop sometime :)

The future of the internet and how to stop it

looks like a book worth reading.

Brings up the balance between the "sterile" and "generative", with the boom of 90s being because of the technology becoming generative, and the current success flipping it back into sterile field. It's quite insightful and relevant for anyone - thinking of where is their place in this emerging soup. Long watch, but very much worth it.

Web3.0

this is so web3.0!

p.s. don't try :%d, afterwards it does not work very well.

The most clicked global warming story of the month

Great tits cope well with warming

sweet :-)

character vs. token based parser in Parsec with haskell

Ok, the first parser did look *ugly*, so I wrote a bit less ugly one, using the token parser. It's not much shorter,
but runs two times faster!

$ time ./packet_template_token >/dev/null

real    0m0.138s
user    0m0.130s
sys     0m0.006s
$ time ./packet_template_char >/dev/null

real    0m0.395s
user    0m0.388s
sys     0m0.005s
$

In case you are interested, both are here

Packet template parser in Haskell

As part of the dive into Haskell, I've tried out Parsec, which allows a pretty intuitive construction of parsers.

The result is a parser that can consume the packet template file. It does not do anything smart with it beyond some printing.

You can take a look at the two here.

The code leaves a lot to be desired - as I've used the lowest-level character parser.

Geek humor in haskell

Lately I'm periodically flirting with Haskell - and today I've found an incredibly funny page, which at the same time offers an ample educational content.

Enjoy.

Flying wooden cubes and the tree eclipse

Texture sending code finally works - the stupid mistake was in the wrong assumption about the lower level. So now I can enjoy the strange tree-like sun. Moreover, after the peek at libsl the TextureEntry is somewhat done as well - so now the cubes are made of wood instead of some strange gray matter.

All of this has exposed a few interesting bugs in the lower-level code - timers/slists, which I seem to have found and fixed - although as can be clearly seen, the strings now look a bit like junk - because of the absent null terminator (which was being automagically added by the same code that caused the texture sending to fail). To make them show up quicker, I made a funny patch - which attaches a callback on every object being created and makes it float up to 10m, and then back to 1m, then up again.

Creating the masses of these has exposed another interesting dilemma, which will probably cause the tweak to the use of the simple slist crawlers for the object updates. The funny problem for now looks as follows: suppose I have 100 objects. All of them are with timer callbacks, so they *move* - and move often.

This results in the corresponding slist entries being deleted and reinserted at the tail of the update slist.

Due to the "pull" nature of the updates, if the update iterator moves not too far within one step - then this results in some objects never moving on the client - because by the time the iterator manages to walk to them, they are on the tail of the slist again... I'll need to prove this theory by adding the dynamically tweakable number of the updates sent within a single cycle, but it seems rather plausible.

The interesting question is how to do it in the least quirky way - one possible solution is to measure the frequency of the reinserts of the given object update node, and if the number is consistently high, to periodically leave a node lingering around marked as "secondary", and have a "cleanup" iterator slowly moving alongside the slist and wiping out the secondary nodes. So the slower clients have a chance to get the updates still.

Having the lowest speed of it bounded, would guarantee that the maliciously (or pathologically:) slow client can not stall the resources on the server by forcing it to create an infinitely long slist. Of course, the slow client will now have to pay a price of potentially getting the multiple duplicate updates as it moves along - but that is a fair price for keeping the data structure size O(1) instead of O(Nclients) for the case of the separate per-client queueing. Of course, premature optimization and all that - maybe it is simpler not to try to be smart and have a per-client "intelligent queues" - but assuming there are 200 clients, each object change implies the 200x work at once, and probably to throw away stuff for the majority of these... That's seems a bit too wasteful - and would kill the elegance of simply putting the newly connected client to crawl from the beginning of the object update slist...

New toys for the human :-)

I've been quite silent for a couple of weeks - mainly because of the human's RL trip to the US. Of course, this had a side of visiting some local gadget shops... And with the euro being expensive as it is... the human has gone slightly bananas and forgot that there was common sense. One of the nicest acquisitions was the Eeepc. In folded state it is quite exact to the A5 size - so it is really no bigger than most of the books - which proved to be a huge advantage in the airplane - alongside with the almost 3.5 hours of battery life. And in addition to the formfactor, the goodness one gets for approximately 350 euros (if all the math is right) is 1G of RAM, 8G of flash, wireless/ethernet, and the camera.

Now, here's the coolest part - it comes with Xandros linux preinstalled. So, even though the default desktop seemed kind of cute, the first thing indeed that was apt-gotten, was the fluxbox, gcc, git, openssl&co, and other practically pointless things. And i did not have to wipe out the whatever-other-OS-that-was-there-before and fiddle with the basics (kernel configure/compile is exciting only the first twenty times or so)

The first usage experiment shown that the human needs to compartmentalize the motoric memory responsible for typing (as now I tend to hit "F1" instead of "Esc"), and that the fingers are a bit too fat.

As a nice bonus, the beast auto-starts Amarok when it sees the iPod Nano connected to it. As a not-so-nice bonus the Amarok's song layout does not get recognized by iPod Nano, the only way I've solved that is by using the "standard means" aka iTunes on Windows.

The CPU is not a demon (only 600Mhz), and graphics seems to be not accelerated (so no SL, even though there's no point to run it as it would have been too slow) but having a familiar architecture in a size of a pocket book is very pleasing.