- Thursday 30th January
Managed to get hold of a new
playslip (2 of the 4 stores I visited this
morning did not have the new playslip !), but I couldn't find a new
How To Play leaflet anywhere (I've phoned
up Camelot and got them to send me one through the post).
- Wednesday 29th January
Received a subscription renewal form and sent a cheque for £208
(2 tickets per draw for 104 draws) to Camelot. Also bought 2 extra tickets
for Saturday's rollover of course. Took a day off, but still phoned up
Camelot to update the delayed sales figures.
- Tuesday 28th January
Finally got to grips with the new cpp library and hence the "bhs" command I'm
using to generate the lottery pages is now linked in with that library.
- Monday 27th January
A colleague wrote an internal link checker (not dissimilar to mine), which
also usefully reports the unlinked files in the WWW tree, thus allowing
me to clear up some temporary files from the tree and also to fix a couple
of old links in this What's New section.
- Saturday 25th January
The live updates and subsequent analysis went well - less than 3 minutes
to get initial analysis pages up (5 minutes faster than anyone else)
and I announced it was a rollover at 8.50pm, with full results available
at 8.54pm - some 15 minutes before anyone else !
- Friday 24th January
I've been "fighting" with the new cpp to work around the odd problem or two
that's been cropping up, but I've now shaped it into a cpp library. The next
task is to link that library against bhs, which would speed
up that command considerably - I'll probably do that on Sunday (don't want
to tempt fate prior to Saturday's draw !).
Six months or so have elapsed since the Camelot official site opened so, with
the change of Camelot's e-mail address, I decided to e-mail them with a
critical list of what's wrong (loads of stuff !). I can't believe that they
have no ALT tags, no <NOFRAMES> section, no past winning numbers,
no prize amounts/number of winners for any draw and, to top it all
off, not a single external WWW link ! A dismal site in other words.
- Thursday 23rd January
Camelot changed the e-mail address on their WWW site today without telling
anyone it had changed (either on their home page or in the Mail section on
their site). It's no longer pointing to an obscurely numbered Pipex account,
but is actually "firstname.lastname@example.org", although it looks like they are still
only fielding WWW queries and not general questions about the lottery itself.
- Wednesday 22nd January
Received the usual mid-week sales figures from Camelot via fax, although
they are a bit sluggish with them (1.10pm today, when they should have
really sent it to me yesterday afternoon).
- Tuesday 21st January
I think I've tracked down the problem in the new cpp now, so I've switched
it back on again for page generation. Hopefully, everything will be smooth
with this extra fix (it was to do with the slash character and whether it
was part of a cpp variable or not). The next stage is to perform major
surgery on the code to read and write file handles (or char pointers) and
tack on some "glue" routines to turn it into a generic cpp library.
Once that's done, I will link against it (the shared library that is)
for the "bhs" command and my CGI code and we should see some impressive
speed improvements in both.
Work by a colleague is progressing on an Apache module to process bhs docs
on-the-fly once I've got this cpp library working. I won't initially be using
this for my lottery pages, but it opens up neat possibilities for maintaining
one bhs file when I finally go ahead and do a "hi-res" version of my lottery
pages whilst keeping a lo-res version. Rather than having to generate two
static versions of the pages, it will be able to generate both versions on
the fly from a single bhs file (via #ifdef's of course) when requested
(caching docs that haven't changed to avoid to having to generate popular
pages every time). I'm not certain I'll adopt this though - I'd need to
see what sort of impact it has the WWW server w.r.t. page serving speed.
- Monday 20th January
Finally got the number of jackpots (25) in the latest rather
"scarce" scratchcard game, Instants (Orange). There's now a
£6 discrepancy in the total prize pool quoted to me by
Camelot for the
third Super Draw, so they're
going to contact me about it. The figures for that draw were
adjusted back to their original values by Camelot (probably
due to the network crash on the draw day) and don't generate
a formula error, but Camelot's total prize pool figure doesn't
match mine !
Camelot launched their "snitch" phone line (for under-age ticket and
scratchcard sales), but I can't believe that it isn't either a freephone or
lo-call number. If you're outside Merseyside (I'm not !), it could cost you
a long distance phone call to grass on that newsagent you don't particularly
like... I actually phoned the line today for "fun" to pump the person for
info :-) It's really silly that it's cheaper to phone the Camelot lottery
line than it is to phone the "supergrass" line - it will discourage many
people from phoning I reckon.
- Saturday 18th January
The draw went reasonably well this week, with only a little sluggishness
from the GIF/page generation during the actual draw delaying the ball-by-ball
live update by a few seconds (too popular for its own good ?). A move to
a new server (about twice as fast) and Net line (also twice as fast for
most users) soon will fix that. Managed to beat all TV
full results and all the other UK lottery WWW sites to displaying the
number of winners, prize amounts and ticket sales.
Had to back out of using the new cpp at the last minute because the
bhs-generated crontab file wasn't looking too healthy (new cpp had mangled
it somewhat). Will fix that in time for the next draw.
Did some more test draws and fixed GIF generation when the live updates
status file is incomplete due to a slow mirror-back from the live server to
the build machine. I basically see if the main results data file on the
build machine is newer than the mirrored-back live updates file - if it is,
then I ignore the live updates status file.
I no longer compile with optimisation at level 2 during a draw day -
optimisation is removed for all files except the Best Performing Tickets
source code, which is at level 3 optimisation. This triples the speed of
compilation during a draw day and should speed up presentation of numerical
analysis by about 90 seconds tonight - on other days, I revert to level 2
optimisation (plus one file at level 3 as I said). I'm lucky that a 735/125
can compile about one 20K source file a second without optimisation !
On my home machine during a draw day (i.e. no optimisation), I can build all
the source code and generate 142 HTML pages and 8 GIFs from the new programs in
3 minutes 45 seconds and in 2 minutes and 45 seconds on the work build
I've moved GIF generation to be the final piece of
code run and shifted the home page and the individual lottery pages to be
the first. Before I generate the Sales Figures and All Winning Numbers sections,
I send an intermediate mirroring request in the background so that the
"critical" pages are mirrored quickly and the others get mirrored about a
minute later via a second mirror request. I am estimating that you'll see an
overall doubling of the speed that the pages are updated post-draw w.r.t.
individual lottery pages, numerical analysis and sales figures.
In a move to further speed up page generation, I want to make "bhs" a standalone
binary that no longer does a system() call to /lib/cpp. To achieve this,
a colleague discovered that there was source code to cpp in the XView 3.2
distribution and it was smaller and a lot easier to understand than GNU's
cpp. The beauty of having the source code was that I could hack the cpp to
behave more sensibly w.r.t. HTML rather C.
The following is a list of what I had to change to XView 3.2's cpp:
- Apostrophes no longer cause chaos - cpp normally treats the rest of the
line as a string and refuses to expand macros. I just told this cpp that
an apostrophe wasn't the start of a string (i.e. it was a normal
character) and this fixed the problem.
- Double quotes are no longer treated as special either - they are just
part of a normal alphanumeric string now.
- I had to retain all spaces between words (because might be in a PRE
section) - the original cpp shrunk them to a single space.
- Number parsing following a "#" character anywhere in the line was
too strict - I switched off all warnings for that.
- I now translate anything between   and ~ in the bhs
input file into a single ASCII character in the HTML output instead. This is
mainly because there's certain chars you have to workaround in /lib/cpp
(apostrophes used to have to be specified with ' in .bhs files
and commas in strings passed to macros still have to use ,
even with this hacked cpp), but all such kludges in the .bhs file are now
automatically translated to their single char equivalent in the generated
- No blank lines left behind from various # directives now - I personally
think that cpp should always remove such lines...the hacked cpp does
- Division operator (a slash char) has been disabled - caused chaos when a
URL was passed as a macro parameter, giving the sequence /) and this did
weird things to the output.
- Removed all #line directives from the output (there wasn't an
option to turn that off with the unhacked cpp !).
At this moment in time, the hacked cpp remains a separate binary that is
still called via system() from bhs, but I want to keep it like that for a
few weeks to make sure no more nasties come up (it's very easy for me to
switch backwards and forwards between /lib/cpp and the hacked XView 3.2 cpp).
Once I'm happy with it, I'll turn it into a C library that can be linked
in with any program and then I can rebuild bhs to use that library, so no
more system() calls and probably double the document generation speed !
It should also benefit the Live Updates CGI code, which currently has
to system() a bhs command, but will be able to pre-process .bhs files without
having to spawn another command if I link it against that library too.
The spin-off for MerseyWorld is that
we'll be able to use the new cpp library to process .bhs files
on-the-fly via an Apache module. This is ground-breaking stuff because
no-one on the net has such advanced server-side processing - it's far
superior to server-side includes because you've got conditional HTML,
definitions and macros, all of which are parsed and selected at run-time
(by tracking cookies) !
Fixed a very old bug I'd only just noticed with the InterLotto Multiple
Ticket Checker page. The code thought that the first
13 tickets cost 5 Swiss Francs each, regardless of which draw you
were checking against, when it fact it was the first 13 draws where
the tickets cost 5 SFr each ! I'm surprised no-one spotted this and reported
it to me...the bug had been there for about a year :-(
- Thursday 16th January
No sign of Camelot's fax, so I phoned them up and got some initial
figures (the full set, the quickest on the Net again, were phoned
back to me about 30 minutes later). The official Camelot site finally
fixed its incorrect home page at 12.53pm, over 2 days after
they'd put results from the end of August 1996 up in error !
- Wednesday 15th January
Improved the multiple ticket checker by allowing
you to change the week you are checking after you've initially
submitted your set of up to 24 tickets. This means if that if you've set
it on "latest lottery", but miss a week, you can temporarily check older
weeks without having to re-type all your ticket numbers in again. Similarly,
if you didn't select "latest lottery" when you first submitted the tickets
(i.e. you chose a particular lottery number instead), you can do so at any
time in the future and re-save your bookmark if you want.
This is the first of four stages I intend to implement w.r.t. the ticket
checker. The next stage is to try freeform text boxes for each ticket
(i.e. 17 chars wide, two such boxes to a line) instead of individual input
fields for each number on a ticket. This should reduce the number of chars
needed to transmit the URL (hopefully ! If it doesn't, I'll abandon the
The third stage is probably to submit each ticket one at a time via
the "Have You Won ?" page, accumulating a longer and longer URL
as each ticket is individually submitted. This would entirely remove the
need for the Multiple Ticket Checker page and the only limit on the number
of tickets checked would be the length of the URL supported by your browser
(other advantage - URL can be "compressed" into 6 chars per ticket). It would
also mean you could use the "Have You Won ?" form layout, which is easier
than manually typing 6 numbers in.
The final stage would be to allow multiple draws to be checked against
multiple tickets - a summary page could be output displaying the total
matches, wins and prizes for each draw, which could then be further clicked
on to get each draw's individual performance for the set of multiple tickets.
I doubt there's much else I could add once that's been completed !
- Tuesday 14th January
It was rather amusing to see that the official lottery site panicked when
they finally noticed that the old picture of Bob Monkhouse was on their
home page over 2 weeks after Dale Winton had taken over hosting the lottery
TV show. They then proceeded to upload the first page with a picture of Dale
Winton they could find, which turned out to have a date of 31st August 1996
and the winning balls for
Lottery #94 ! They uploaded this faulty page
at 10.59am today and it was still there at 3.30pm (when I was phoning Camelot
for some info, I mentioned this problem to them).
- Saturday 11th January
The Live Update seemed to suffer sort of clash between two people entering
the results simultaneously and the GIF generation went a bit strange :-(
I'll have to test that out a lot more over the next week or so. Also, the
mirror-back of the live status file seemed to take an age, which it
shouldn't have done, leading to incomplete GIF generation again.
I've been extremely busy on our
HP-UX PD archive over the last week, so I
didn't get as much time as I'd have liked to develop the lottery pages, but
I did complete some Live Updates coding I'd forgotten about (the new
machine and ball set info in the Live Updates status page).
- Thursday 9th January
Camelot's midweek fax actually arrived yesterday at 11.12am, but I never went
to check for it because it's always been sent on a Friday previously.
Anyway, the full
sales figures (including Lucky Dip, which is always the one that stalls
the fax from being sent !) are now available, quicker than anyone else
on the Internet as usual.
- Wednesday 8th January
A router went berserk for 70 minutes today, losing our net connection in the
middle of the afternoon. It appears to be back to normal now.
- Tuesday 7th January
A month after the move to this new domain, I discovered some old /htbin
CGI references (should now be /cgi-bin of course), which I corrected.
- Monday 6th January
BT have threatened to cut off my home ISDN connection, mainly because they
"cleverly" sent the bill the day before the University closed down for
Christmas and the finance department of the University (who pay the bill)
probably didn't handle it until something like 2nd January. The problem
should have been resolved by now - we got onto BT and told them that the
bill had indeed been paid. It's still working this evening, so it looks like
BT's threat hasn't been carried out - the line was only installed on
27th November, so I haven't even had two months of use from it yet !
- Sunday 5th January
The network came back at 5.37pm and I logged in some 45 minutes later.
I'd prepared all the updated pages offline, so the second the network came
back, the pages were auto-copied to the live server.
Hopefully, we'll get our new Internet connection shortly and won't be
subject to these network breaks in the future.
- Saturday 4th January
The network was down throughout the entire day, but I still (rather sad this)
did a Live Update on my home machine and went through all the
mechanisms I would have done on the live server (except I skipped the
live TV commentary of course, because no-one would see it !). I had the winning
numbers within 5 seconds of each ball coming out and phoned Camelot at 9.05pm
to get the full results, having them on my home machine's pages by 9.10pm
(probably quicker than anyone else, not that I could tell).
I also spent the time fixing minor bugs in the All Winning Numbers section
when there's only one draw for a year's page (as is the case now). Firstly,
when the winning numbers are known, but the numbers of winners and prizes
aren't, I had incorrect figures in the Lowest and Highest rows at the foot
of the table, which has now been fixed. Also, I wasn't calculating the average
number of jackpot wins correctly, which has also been remedied.
During the downtime, colleagues in our Department upgraded the internal hard
drive of the Connect WWW server (now a 1GB drive instead of an utterly feeble
400MB drive) and it now has four times as much swap space, which should make
the server (and hence these lottery pages) much more stable, especially during
- Friday 3rd January
At 9.38pm (some 4 and a half hours "late"), external network connections to
these lottery pages were severed for "essential" mains testing over the
forthcoming weekend (in the Computing Services Department, who supply us
with our SuperJANET Internet connection). Seems a strange time to
start electrical testing if you ask me !
The network connections may have been going down on me this evening, but it
didn't stop me being the first to get the "mid-week" sales figures on the
Chris Prickett tracked down the very elusive first Lucky Dip sales figure
from Camelot (week ending Saturday 23rd March 1996) because he spotted that
we had different figures. I tried to get the figure from Camelot myself,
but firstly I was told "we don't keep figures that far back" and then, the
next day, I was told that the figure was £3,496,870, which was the
amount for Saturday 30th March 1996 :-(
Chris then tried himself and someone
on the Camelot phone line had to tramp to the Newsroom to get the right
It turned out my Lucky Dip sales figure for that first week was bizarrely
almost exactly £400,000 different from the actual figure. I can only
assume that I was given an early provisional figure that was later revised.
Anyway, I've now adjusted that first week's sales figure, though I doubt anyone
would have noticed if I hadn't mentioned it here. What worries me is that this
is a new trend with Camelot's phone line - if you want old figures, it's
going to be a real pain finding them :-(
- Thursday 2nd January
Saved the 1996 access statistics, trimmed them down to only the relevant info
for the whole year (normally most sections are for the last 7 days only)
and made them available on a
separate page. I then reset analog's cache for
1996, so it will start afresh with 1997 statistics,
although there will be a 1996 overlap for the next week or so until the cache
flushes the last week of 1996 out (at which point, I'll reset it again to
get true 1997 figures).
The main aim is to beat last year's average of 12,186 hits a day of course
and hopefully the new Internet connection and server hardware we'll be
activating shortly will encourage people to make more return visits because
of the quicker response (except for .ac.uk users, who will get a slower
response I'm afraid :-( ).
- Wednesday 1st January
A new year and the first time I'll have been able to update these pages on
a New Year's Day ! Yes, I'm sad enough to have been online across the
New Year and I've now completed going around and changing the copyright
date in the footer all of these pages to 1997 :-)