339 karma · joined October 25, 2013
async / await isn't really concurrency. It's a mechanism for picking up the job after something else has been done (perhaps like a callback). In a way it's been an advantage of Javascript: one or two threads do all the work in a timely way without all that messy thread scheduling and context switches.
Looking at the wider group, I would think there's lots of roles for robotics in construction. Delivery of heavy items across uneven terrain or up stairs - may be something like a robotic hod carrier.
So not a dispersal order then.
[Edit for format and dreadful spelling].
https://duckduckgo.com/?t=ffsb&q=llandow+&ia=images&iax=imag...
Well that's a big ask. Who do we hold responsible for nothing changing?
Hmm. May be it's me. Not sure I'm up for getting out and confronting the police today.
The build of a component would only have access to the API's of the other components (and this can include not having knowledge of the container it runs in).
The implementation can then change rapidly, with the API that the other teams develop against moving more slowly.
Even so, code reviews can be critical. The things to look out for (and block if possible) are hidden or poorly defined parameters like database connections/transactions, thread local storage and general bag parameters.
In some languages dependency injection should be useful here. Unfortunately DI tools like Spring can actually expose the internals of components, introduce container based hidden parameters and usually end up being a versioned dependency of every component.
Perhaps you could just rely on the user navigating across a number of pages on your attack site.
The search method involved uncompressing each word (one at a time) until either the word was found or one that should follow it.
However, I did intend to use a binary search of the word list on the floppy. I arranged it so any zeroes in the list indicated the start of a word from which decompression could start. Under maximum compression there would be only 26 zero bytes in the list, but by selecting short words at regular intervals I could spinkle zeros throughout the list (approx 1 per block). A binary search could scan for the zeros, decompress the associated word and find the section that should contain the target word.
Tasman didn't go for this. They sorted all the words to be checked in memory, then opened the file and did a complete scan.
I don't know/remember the terms under which this happened. I do remember that when I was trimming it down I found the list contained the trademarks of a competitor. These were removed.
In my first job I worked for Tasman in Leeds and produced a Word Processor for IBM PC compatibles in 8086 assembler with some help, and then a spelling checker.
For the spelling checker I did a whole load of analysis on a 70,000 word list from Collins and produced a list of tokens to represent common strings of letters. However, in the end I really had to cut the original word list down to get the whole thing onto a single 360K floppy.
After I left Tasman, I was lying in bed one night still thinking about it and realised where I had gone wrong. The tokenising thing, which someone else had put me onto had blinded me. I had stared at word lists for months and hadn't pinned down the obvious pattern. All but 26 words in the 70,000 word list shares the bulk of their characters with the word before it.
So the solution is use 5 bits of the first byte as a count of chars from the word before, 3 bits indicate commons enddings (ship, s, ing) or that the following bytes are tokens for the rest of the word. With this I got the word list compressed to less than 2 bytes per word.
I took this back to Tasman. They put all 70,000 words and the spelling checker onto a 175K floppy for the ZX Spectrum +3.
[Edited for typos]
Keep cancelling it, but they keep tricking me again.
Better solution: stop using big branded, overly clever and difficult to use wiki software. Have a single wiki, not split artificially by project, that can be searched as a single entity.
If the code branches the documentation branches, if it merges the documentation merges. Documentation can then made to be part of "code complete" for developers. Think README.md
However, there's always resistance to this wacky idea. Chief being the lack of tools and management fear of editing text files. This article also adds searchability to the negatives.
Amusingly I've just followed a link on HN to The Economist [https://www.economist.com] - their popup offers a link to "manage your cookies" where you can untick huge numbers of them or click "Opt Out All". Great - did that, however on returning to the page found the popup still covers part of the page :-)
However, we must remember Hanlon's Razor.
What are "there tokens"? Aw come on. How do you expect me to take any of this seriously with grammatical mistakes like this?
... and so programmed to crash just like Golgafrinchan Ark Fleet Ship B?
I followed the feedback link and reported a whole heap of these, including links to Streetview showing the "No Cycling" signs in some places. I got automated replies to say that someone would deal with my report - but nothing happended. They are all still showing up.
Perhaps even Google doesn't care about Google.
The upside for the user is that location and whatever the one site is able to determine about the user is all that can be shared. If the user hasn't logged in with their real name - that probably isn't much.