crustycoder

> It's technically impossible for the foreseeable future to predict how a bell will sound if struck for the first time.

https://news.ycombinator.com/item?id=31327966

Indeed we don't in the same way that beer drinkers don't call themselves biochemists - even though some of them may be.

Speaking of beer and bell ringers here's what the Rev H. T Ellacombe had to say about them in 1861:

"it was a well-known fact that, as a body, a more drunken set of fellows could not be found."

"I have heard of clergymen who have even refused to accept a living where there was a peal of bells; and of those who have said, upon learning the number of the bells in the tower, 'Then, certain it is, there are as many drunkards in the village.' 'That man is a ringer,' is is quite enough in some places to intimate that he is an idle, sottish character. I know one clergyman curacy who left his curacy in Worcestershire on account of the conduct of the ringers."

Some traditions are worth keeping up ;-)

I started 38 years ago. If you can remember 38 years ago, you weren't there ;-)

No internet. Same problems.

It's no different to writing any other compiler for Language X in Language X, and that's a really common thing to do. The Java compiler emits files containing Java Bytecode which are subsequently run by a different invocation of the JVM.

Don't what the problem was, I got my free holiday to Orlando out of it, on the day I wanted and from the airport I wanted... ;-)

The article missed out one important detail - the deal included very overpriced accommodation, which is how they were going to claw the cost of the flights back. But they failed to make booking the accommodation through the deal mandatory, so people took the flights and not the accommodation.

Yes, indeed that's true. But they get upset if you tell them that their genius new idea is just an old idea they didn't know about ;-)

No.

If you don't expect to be learning new stuff every day throughout your entire career, you are in the wrong line of business.

When you need something done quickly and properly first time, hiring someone who has seen same the same half-assed ideas "reinvented" over and over for the last 30+ years and who won't try to sell them to you as the New Shiny makes much more sense. Unless you are into square wheels, of course.

Most of the time experience and healthy cynicism is the cheapest option.

60 year old here, still writing code for a company that provides Cloud services, today I'm hacking away on some Scala. My role model and hero is Roger Faulkner, the creator of /proc who died at 76 "with his boots on". An elder statesman who took no shit from anybody, and a true gentleman to boot.

https://thenewstack.io/remembering-roger-faulkner/

Ooh no, don't ever call bellringers that, unless you want to cause grave offence. Campanologist is a name for wussy academics, bellringers ring bells. And drink beer ;-)

Nah, the mouldings are entirely decorative. And bells are tuned by taking off material on a lathe at various positions on the inside of the bell.

https://funwithbells.com/nigel-taylor/

https://www.youtube.com/watch?v=JEJkMalMVv4

Yeah, it's full of geeks :-]

The bells studied in the PhD thesis are primarily used for English Change Ringing, which started in the early 1600s and the compositions played on them (methods) are based on mathematics, specifically Group Theory, rather than being tunes in the normal sense - the aim is to ring all the possible permutations of the bells.

The Mathematics of Bell Ringing https://www.youtube.com/watch?v=44jXUo6KaVs

Performances (Peals) consist of 5040 changes (sequences), have a strict set of rules and take around 3 hours 15 minutes to complete, and must be rung entirely from memory, with no written aids.

In the early 1960s a CS algorithm for efficiently enumerating permutations was published, the Steinhaus–Johnson–Trotter algorithm. It's in Knuth, for those who have access to a copy. Unfortunately for them, it had been known by English Change Ringers as Plain Changes, since around 1621.

It's usually one miserable git who complains, most people who buy houses next to big sticky up things at the end of religious building are smart enough to figure out what's in them.

There's usually two different things going on in UK bell towers - bell ringing which involves ringing the bells full-circle using the internal clappers, and clock chiming which uses external hammers driven my the clock. The clock chiming is much quieter than change ringing.

Ours only chimes on the hour but it's going 24/7 and is very close to the surrounding houses (~40m) some of which are uphill and directly in line with the bells. I had to go in today to fettle it as it wasn't chiming and someone had posted on the village FB group that they were missing it. That's a fairly regular occurrence, most people people like hearing them, even through the night. Any complaints we get are when the clock stops.

It is possible to modify clocks to stop them chiming overnight, although ours is still in its entirely mechanical 1883 form, including me having to wind it every week.

It's been around for a while but he's still active in the field (he recorded & analysed our bells a couple of years ago) and he's revamped the site fairly recently.

I wouldn't worry, if that was the intent, I think it backfired ;-)

The UK government did promise to reduce the grounds for noise complaints about church bells, on the grounds that normally they were there before the complainant arrived, and would still be there long after they were gone, but it appears it was like many government promises...

https://www.churchtimes.co.uk/articles/2018/2-february/news/...

The only remaining dedicated bell foundry in the UK is in Loughborough - https://taylorbells.co.uk/ You can visit :-)

For literally centuries European bell tuning was all done by rule of thumb, with results varying from to sublime to abysmal. It was all finally figured out by Canon Simpson in 1895/6 who described the relationship between the 5 main components of a bell's strike note - the hum, prime, tierce, quint and nominal.

https://www.hibberts.co.uk/building-a-bell-sound/

In the UK we have 61,626 documented bells (a lower bound) spread across 7,148 towers. https://dove.cccbr.org.uk

In the last year unaffected by COVID, there were 10,701 recorded performances and many more unrecorded ones and practices. https://bellboard.uk/

There are 23,397 Methods and 52,650 Compositions available, where a Method is roughly equivalent to a piece or song in traditional music terms. http://methods.ringing.org/intro.html

Yes, Bill did. He's a really nice guy and the subject of bell tuning has been of academic interest for a very long time, because they don't produce a single note and the note you "hear" isn't produced by the bell at all. See for example Nobel Laureate Lord Rayleigh's paper of 1890, linked to on Bill's site.

I'd rather they fixed the remote development in IntelliJ first. You can sort of (ab)use the remote deployment feature in Ultimate for it, but it's clearly not intended for that. And it's extremely clunky - for example the ability to exclude files from syncing is completely underpowered.

And why the hell is selecting files yet another different way of doing what's basically the same task as elsewhere? I'd suggest they should be using the File Scopes feature except it's terminally useless, with it's wierd-ass, barely documented and inadequate syntax. I've never managed to get it to work adequately.

There seems to be a common failing with JetBrains product development, they try to rush out as many different features as possible, presumably for the purposes of marketing "tick lists", but many of them are poorly designed, bug ridden and never worked on after v1.0

IntelliJ - because all the alternatives are even worse.

I shouldn't have to point out just how broken that is as a way of supporting paying customers.

Like the OP I've simply stopped reporting bugs, because they don't get looked at for literally years, let alone fixed.

The product is OK-ish, the support is abysmal.

36 years in and still learning new stuff and hacking.

Personally I'm not that surprised, criticism of any type is no longer PC. I think you nailed it with "well understood" - exactly so, anyone with an interest in this area knows about this stuff.

It would have been fine if the post was along the lines of "I've observed XXX, there's clearly something strange going on" but as you say there was a misinformed leap to blame the kernel devs. That's not OK as bearing in mind the exposure the post got, there's a real danger that the misinformation it contains will become "accepted knowledge".

The guy is a professional dev working on Linux, are you seriously suggesting he shouldn't know what "man" does? And are you seriously suggesting that searching for "spin" is somehow arcane?

https://www.google.com/search?q=linux+spin+lock+library

pthread_spin_lock(3) is on the first page, along with a RH presentation which explains exactly why trying to roll your own userspace implementation is unlikely to be successful. The guy simply didn't do his homework, I have no idea why you are trying to defend him.

  $ man -k spin
  pthread_spin_destroy (3) - initialize or destroy a spin lock
  pthread_spin_init (3) - initialize or destroy a spin lock
  pthread_spin_lock (3) - lock and unlock a spin lock
  pthread_spin_trylock (3) - lock and unlock a spin lock
  pthread_spin_unlock (3) - lock and unlock a spin lock
  TAP::Parser::Scheduler::Spinner (3perl) - A no-op job.

Sigh...

The sorts of problems inherent in userspace spinlocks are even called out in the Linux manpages, shame the article's author didn't bother to look:

http://man7.org/linux/man-pages/man3/pthread_spin_init.3.htm...

Spin locks should be employed in conjunction with real-time scheduling policies (SCHED_FIFO, or possibly SCHED_RR). Use of spin locks with nondeterministic scheduling policies such as SCHED_OTHER probably indicates a design mistake. The problem is that if a thread operating under such a policy is scheduled off the CPU while it holds a spin lock, then other threads will waste time spinning on the lock until the lock holder is once more rescheduled and releases the lock.

If threads create a deadlock situation while employing spin locks, those threads will spin forever consuming CPU time.

User-space spin locks are not applicable as a general locking solution. They are, by definition, prone to priority inversion and unbounded spin times. A programmer using spin locks must be exceptionally careful not only in the code, but also in terms of system configuration, thread placement, and priority assignment.