What's New On These Pages: January 1997

Next month: February 1997

• 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 "[email protected]", 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 machine.

  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 &#32; and &#126; 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 &#39; in .bhs files and commas in strings passed to macros still have to use &#44; 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 .html file.
  • No blank lines left behind from various # directives now - I personally think that cpp should always remove such lines...the hacked cpp does now.
  • 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 idea).

  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 peak times.

• 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 Net :-)

  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 figure ! 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 :-)

Previous month: December 1996

© Richard K. Lloyd & Connect Internet Solutions Limited  2024