Back to running

Thanks to a wonderful sunny day I was able to defeat my laziness to go out for a nice run. It was long I wasn't running outdoor and I've also been skipping quite a few times the treadmill downstairs where I was supposed to run half an hour at least three times a week (ok ... quite a bit more than a few times...).

So I've been a coward and took it easy by not running the usual one-hour path but stopping instead short of that to turn back toward home. Everything was fine except a bit of ankle pain on the left foot near the end of the run.

Surprisingly enough I met only three other runners and a guy on a bicycle... I would have expected to meet much more than that given the nice sunny Sunday (I think my record is meeting about 20 or so people down that path).

Apparently sometimes nothing is better than something

Phew!

The turney is over and I'm getting back to my normal routine. On 13-14-15 February we organized the first International Chess Tournament of Vigevano, with 120 players from all over the world including 8 GMs.
The turney itself was ok, except for the usual delay at the first round everything went smoothly and as an arbiter I had to tell something just in a few occasions...

From a software point of view instead most worked ok, including a few patches I made in the few minutes I found. Unfortunately the first round - because of the delay - started when I wasn't ready yet so I had to start the DGT boards when the games were already started, so I decided to just show on the big screens the positions and not the moves; for the other rounds instead the play zone screens were showing both the positions, moves and clocks.

We also found one of the DGT clocks to be defective (it wasn't sensing the clock button that players are required to press at every move) so the 5th board was shown without players remaining time.

A the tournament I was also asked if what was visible on the screens could have been published also on the web. I wasn't expecting this and hacking it at the moment has been a bad decision for a few reasons

• What was shown on the big screens was indeed an HTML page but I tested it only on FireFox and actually I even used a few images for figurine notation that were rescaled exactly so they could look right at the resolution/magnification I was using on the big screens. I didn't try it at all with any other browser or any other resolution.
  Of course it turns out that a self-refreshing HTML page is absolutely terrible on IE because of flashing and because it loses the scroll position (ok... IE - no matter if 5 6 or 7 - is a total crap as a browser for a jillion reasons, but still a lot of internet users for some strange reason stick to it, so anthing published on the internet - unfortunately - should be made to work also with that thing). Also someone using XP was still unable to see the small PNG i used for the figurine notation and was instead seeing just black squares (!).
  
  
• I simply added an "os.system('pscp postion.html ....');" line to put the updated file on a web server, but I was directly replacing the file being served by apache. The file was rather "big" (35k) so the upload was not instantaneous and what happened is that who was observing the game from the internet could get an incomplete HTML file. An even bigger problem was that the if file was not even complete to the "http-equiv refresh" line then the partial - totally blank - file would stuck on the browser of the observer forever.
  I fixed this only the second day by uploading with pscp to another location and then calling a cgi script to move the file to the correct position.
  
  
• The program I wrote was for showing the first 4 games in the playing area, not for publishing it on the internet, so a few "features" like figurines instead of letters were indeed "anti-features" for who was observing from a PC (with letters you could copy-n-paste in a chess program). Also the game shown was not complete for layout reasons and there was no provision for downloading the PGN of the game. Moreover it wasn't possible to go back and forth on the moves or to see just one board instead of all five of them.

All these things were nonsense for showing in the playing zone (in the room there was no reload problem ... the local file was correctly written and moved in place; and there's no mouse for who is looking at the screen so no interactive feature makes any sense at all) but made the experience for who was accessing that from the internet quite less than optimal.

What I realized only later after reading some comments was that it would have been better not showing anything at all on the internet...

So apparently sometimes nothing is better than something...

Now I'm working on a better flash-based interface for publishing the games online and hopefully I should be able to provide a better experience for viewers of the Bergamo tournament next month.

Learning LISP

I'm halfway reading Practical Common Lisp and I'm now beginning to understand a few points about LISP that were not that clear. First of all what are those famous macros and why they're so powerful. I always had the gut feeling that C++ template machinery was not good, it is a different language with a lot of limitations and even doing things like loops or ifs is not impossible but very very hard; not only template debugging is difficult but even reports about syntax errors are so bad that they look like a joke.
LISP macros can do the same as C++ templates (and more), however the language is LISP itself (if, loops, opening files... you can do whatever you need to do "compile time").
I am experimenting with a macro "defentity" that given for example

(defentity simple-point point
  (coords point))

(defentity circle line
  (center point)
  (radius float))

defines two classes, the classes "simple-point" and "circle". The center of a circle entity is a reference to a point entity and this generates a dipendence. When I change the coordinates of a point I want that all the geometry of dependent entities (for example circles that are referencing that point as center) to be invalidated.

I'm still working on it but I already got something working. The defined classes are regular CLOS classes with added "dirty" fields for invalidated geometry, cached results and accessors that do the required recursive "touching" of dependent entities on write operations. Changing referred entities, destruction and link removal is implemented (so when destroying a point all entities depending on it will be notified and given the possibility to remove the link instead of being also destroyed).

Making the same using templates with C++ would be IMO just impossible. Making the same with python would be easy (we did) but keeping much of the logic at runtime. Moving it at compile time with python would be possible but IMO a lot harder (and without much gain indeed).
With C++ a reasonable solution would be using a code generator (written e.g. in PERL) that generates the C++ code needed.

I'm trying the LISP way and so far looks promising...

Python dropped the clear distinction of compile-time and run-time as class and function definition are indeed executable statements; LISP moved further by dropping also the parse-time separation because thanks to macros even the parsing of the source is more or less an executable statement.

Amazing this thing is still working

I haven't touched this blog in three years but still this thing is apparently working ok. Quite long time ago i decided to give up with my internet presence because spare time is so scarce and I had to choose what to drop and what to keep. I decided for keeping piano playing, exercising, learning, chess playing and of course coding and a minimum quantity of the so-called "real life" as it's mandated by current society.

A lot of things changed in last three years and I really don't want to bother to list them all (who would care anyway ? :-) ).

Simply I'll try to get back at this blog because ... oh well ... just because.