dkfellows

There are a very few truly global entities there, most notably the current working directory and the environment variables. They're global because the underlying concept leaks through into C code you link in and subprocesses you launch, and changing that would be really quite nasty. The Tcl interfaces to those things are internally protected against multithreaded access, of course, but you can still get yourself into a mess that way.

The bit I really like about Tcl is how easy it makes asynchronous I/O across all its supported platforms. This doesn't sound significant to Linux users, but on Windows that's a very very big deal...

Long term, the Cisco router support became the non-recursive execution engine (of Tcl 8.6) which stopped things from blowing up on the tiny stack sizes that Cisco equipment is configured with.

And which gives us tailcalls and coroutines.

There's no macros because there's uplevel (and upvar) instead. It's a different way to do homoiconicity. And the variable binding rules are quite different, which makes for quite a different language in practice.

The current main project for Tk, targeting the 9.2 release next year, is porting to work on Wayland. (But not dropping support for X11, Windows or macOS.) Apparently, the widget demo is now working (i.e., you could probably build some applications on it) but advanced features like accessibility support are still in progress.

You need tools adequate to the task, but the task isn't necessarily what other people think it is. In this case, I'd bet the tasks are to learn what's going on inside a database and become better at programming in Python, not to write a high-performance production-ready database implementation.

Almost all quoting for non-trivial cases comes down to the [list] command. It does the Right Thing, especially in the critical cases where you're generating a command to call later. Pretty much everything else is either much simpler to the point of needing no thought at all, or complex enough that you're best off writing a command to do it properly (e.g., because you're generating JSON or CSV or some other language like that) as you'll want to test it thoroughly too.

It's hard to be much more specific than that without talking detailed examples.

The main issue with supporting those IDEs is that the Language Server Protocol is vast and really quite complicated. More than a weekend's work to go to doing the interesting bits so life gets in the way...

The IDE tools for Tcl have tended to be commercial and to not see much general adoption. Never understood why.

Python has nothing at all like safe interpreters (I've looked). You just can't prevent things from leaking, it isn't designed for it at all. You can do a half-hearted approach by specifying the globals dictionary to eval(), but you can't really count on safety because the builtins do the leaking and you can't really stop anyone from finding a way to get back to that; the language is just too deeply interlinked for a proper security boundary to be erected anywhere inside it.

Well, there are classes and objects in there now. They're designed for modelling pretty heavyweight entities like widgets instead of lightweight things like linked lists.

It was a fun OO system to write. It's much more dynamic than it appears to be at first glance; it's first glance looks much like many other languages object systems with a few slight oddities (no new operator, but rather classes have a new method).

Technically, all values are considered subtypes of strings, but the notion of types is quite different to those of many other languages. In particular, Tcl's types do not describe the memory storage model of their values. (They're implemented with 64-bit words and buffers and arrays and so on, but that's not what the value model describes.)

It works well as long as your goal isn't to totally eliminate boxing of values.

Tcl uses a memory model internally where each piece of memory belongs strictly to the thread that allocated it, with this enforced in lots of places. There are a few loopholes past it (for process-wide concepts such as the current working directory cache, or for inter-thread messaging) but by and large you write what appears to be single-threaded code.

There's support for deep coroutines and non-blocking I/O so it isn't limiting. You only really need multiple threads when dealing with compute-heavy code or a particularly crufty API.

Technically, Tcl's internal type system is that all other value types are subtypes of string, universally serializable to string, and will correctly round-trip through string. But it also means that you can type-pun stuff if you want; it just costs time.

FWIW, the best handling I know of JSON in Tcl is the rl_json package (https://github.com/RubyLane/rl_json) which essentially makes JSON into what works like a native Tcl value type.

That's an excellent question!

It's not at all like IP. The basic message size is (IIRC) 64 or 96 bits, comprising a system control word, an application header word, and an optional payload word. The application header word describes what the identity of the sender of the message is (well, in theory it could describe the destination too, but then we'd not have enough space to address much at all) and is used in the routing of the messages. Each chip has a very fast masked CAM (the key IP of SpiNNaker) that is used to convert from the application header word to the destinations to deliver that packet to, which is one channel to each core on the chip and one channel to each direction in the logical triangular mesh in which the chips are connected. The router is very fast indeed, and very low power, so we can generally count on routing a packet right to the opposite side of the machine in a few milliseconds, and I'd have to look up the energy cost of a packet (we've published it, but I forget where). I believe our route planning software takes this delay into account. It also tries to put neurons that communicate with each other close together.

For greater delays than that, we also have a delay slot system (for up to 16 simulation timesteps, which is approximately 16ms) in our synapse model, and specialized pseudo-neurons that implement longer delays than that on cores that we set aside for the purpose (and which, because they only handle delays, are much easier to make scale).

We do source routing mainly because this was hardware designed from the beginning to do neural simulation; source routing is a natural way to implement (an abstraction of) axons, as each axon is capable of connecting to many different dendrites. This is very much an abstraction of what happens in reality, but it has worked well for us. Also yes, our routing algorithms most definitely do try to limit the amount of traffic going down each communication link. Since communication during execution is pretty predictable (at least statistically) this is far more practical than with IP, where the dominating factors relate far more to being able to manage the network without knowing its total state.

It's basically very different in approach to many modern computers. The cores are slow and low-powered, but the interconnect is very fast for routing small packets to multiple destinations, which means that computational tasks that would otherwise be utterly dominated by communication costs (e.g., neural simulations) become a lot more tractable.

But since it's all done in soft realtime with very low level code (and no hardware floats in the current hardware generation) and not much of an OS, it's a very unusual platform for people to work with. Much more like programming used to be like in the 1980s, if my memory serves me right. (One of the key distinguishing things about SpiNNaker in the field of neuromorphic systems is that actually has an OS at all. Most competitor systems are purely bare metal, as they're put together by deep hardware hackers without consulting software engineers.)

It really depends on whether you include the memory in that count, as memory uses masses of transistors without being very interesting as most of those transistors spend their time just sitting there in a stable state. It's the transistor count (more properly, the gate count; gates can be thought of as multiple transistors fused together, yet they're truly a single thing in terms of manufacturing and layout) in the computational parts of the processor that is really interesting.

SpiNNaker is built using old ARM968 cores on an ancient process (because that was cheap, for various reasons). The SpiNNaker2 hardware (under design; I can't remember if it is next year or the one after when it is finalized) will be on a modern process that will let us pack ten times as many cores on per chip, with those cores being quite a lot more powerful. Which isn't bad; we're not a commercial outfit here…

There isn't a plan to do the whole human brain, and doing so would require both at least two further generations of hardware and likely building a new facility for deploying it in. If someone's got a spare billion, and a decade or so to work on it, we could give it a go, but it is a lot to spend for no actual certainty that we'd succeed.

We do plan to simulate the mouse brain, but our interests are more in understanding network-level mechanisms that are difficult to study at the neuron or whole-brain levels. The meso-scale stuff is where understanding is critical and tricky.

> Science journalism is generally just awful.

Not just science journalism. I've yet to see a journalist get a story 100% right where I knew the facts personally ahead of time. If you're lucky, they've just garbled people's names...

It theoretically has 1036800 processors. It doesn't actually have that many because core-level manufacturing yields aren't 100%. The software architecture is designed to be resilient to this.

The million was a figure chosen to be eye-catching to funders and to force the initial design team to address scalability from the beginning, according to Steve Furber. So yes, it's a bit arbitrary.

The actual figure is (for technical reasons) a multiple of 2592. Those technical reasons? That's the topological tiling unit used in the overall toroidal mesh (48 chips per board, arranged to tile in groups of three boards, all times 18 which is the number of cores per chip; 1 OS core, 16 application cores, and 1 bonus that is sometimes available and sometimes not, in order to keep overall chip yields sufficiently high).

SpiNNaker is particularly for studying neural structure, especially on the scale from small groups of neurons up to brain structures of a few million, on timespans of a few seconds to a few hours at simulation timesteps on the size order of a millisecond. That's a scale where doing the study in vivo or in vitro is technically extremely challenging; signal analysers find that awkward, either to get that many channels that fine or to get that density of sampling. Or both; getting either is hard and getting both is crazy hard.

But being able to simulate neural networks that can do their learning on-line and in real time, all while actively processing input (and in a controlled fashion) is an interesting capability anyway, as it means SpiNNaker can control physical robots in interesting ways (and those may be commercially interesting). And it's low-power enough that doing this in the wild is practical, rather than needing to upload everything into the Cloud for analysis. That may also be commercially interesting.

The unit cost of a chip isn't too much. The price of doing the design and creating the masks for the silicon OTOH...

> Specifically, how will you prevent SpiNNaker from going down the same path as the Connection Machine - (stops doing AI stuff because, say, geneticists want to use it for protein sequencing)?

I'm on the team. I can say that we're specifically funded to do and support computational neuroscience. However, if someone comes along with money wanting to do other kinds of projects on the hardware (and are able to handle the special characteristics of the machine itself) then they're welcome. The challenge is that it's non-conventional in a number of ways that make porting code tricky: in particular, the messages are small, designed to be multicast rather than unicast, the instruction memory per core is only 32kB, and there's no hardware floating point at all in the current generation. (You can do floating point in emulation. We do that in one of our projects.)

> Why do you see this as the future over something like NVIDIA's new HGX-2 or clusters of TPUs?

We see it as solving different problems. Those approaches you mention are great for solving problems that resolve to big matrix operations; SpiNNaker is better at tackling problems that are dominated in terms of description by communication. Neural simulations are really just vast hybrid ODE systems, but where it is possible to break up the simulation into lots of communicating domains (the synapses and neurons).

The next generation will have single precision hardware floats, but that's still at the prototype stage (with little bits of the processor running on a monster FPGA in the lab).

The key however is that SpiNNaker is a MIMD system (the cores are really independent of each other, except for a shared clock and chip-level shared co-packaged SDRAM) with a very fancy fast multicast interconnect that's been tuned for handling small source-routed packets without guaranteed delivery (but with guaranteed detection of failure to deliver). It's the almost complete antithesis of MPI, and it is by using that well that we get great performance in neural simulation. (I'm a software developer on the team.)

The processor cores in SpiNNaker run at 200MHz (yes, this is slow!), and can usually issue one instruction per CPU cycle (that's quite nice). However, the trick to getting lots of neurons in is in keeping the number of CPU cycles per synapse event down, since there's a lot more of those than there are neurons.

Yes, bits of the synapse processing code are in assembly coded to waste not one cycle at all. It turns out to be vital to do that in order to keep the efficiency high (and that has many key knock on effects; the synaptic density is a critical parameter for overall model scaling).

In any case, to say that neurons process information at 200Hz is wrong. Or rather it is not even wrong. The individual neurons don't really do very much, but the overall network does a lot and it isn't limited to 200Hz at all. It's just that it handles time in a totally different way to conventional computers...

Our press office are definitely a law unto themselves, but the analogy was drawn in the event. It's also inaccurate, as it doesn't count the extra ~billion gates per chip for the memory (as that's just a co-packaged standard SDRAM module). It's just that we don't usually think about those as those SDRAMs are very reliable and don't cause us much trouble at all.

The brain definitely is able to use not just spiking frequency (which is approximately the same as EEG voltage, though not really) but also spiking patterns to encode information. We've observed some highly interesting phase locked loops showing various higher-order patterns in simulations (we simply don't have fine enough tools to look for the equivalent in the biology).

The variation in neurotransmitters allows for different sorts of activation, typically with different physical parameters (size of activation, time over which it decays) and multiple ways they interact with the other neurotransmitters.

Sparse networks are not understood to anything like the same extent as dense matrices. And another key property that most ML is missing is large numbers of feedback loops. Again, that makes predicting behaviours extraordinarily difficult.

FWIW, this is based on SpiNNaker, which is a system with a million CPU cores and a custom low-power multicast network backplane. It's possible to do simpler neural models with much less power than we do (and some of our competitors do just that) but it's not at all clear that those simple models are actually sufficiently biologically relevant to produce enough of the phenomena that we care about. Having a system flexible enough to support a dynamic research agenda is vital, but does increase the energy cost per neuron and per synapse.

We can do dynamic networking — the routing tables for the hardware is reloadable at runtime — but it's sufficiently difficult to do the routing computations that we only do that when the simulation is stopped at the moment. (We actually usually use the machine to compute its own routing tables; that's the fastest approach since it is a massively parallel problem.)

However, the effective network can route dynamically (by faking things on top of an initially-zero-weight all-to-all connection pattern between two neuron populations). One of our PhD students is working on this, and on the types of dynamic online learning that this enables, modelling the dynamic generation and removal of synapses that occurs in biological neurons. We also support tuning of connection weights in response to the history of synaptic activity via Spike Timing Dependent Plasticity (STDP), and have done for a few years (using earlier generations of the hardware config).

The usual problem is to do with managing list construction, and the usual answer is the [list] command, which Does The Right Thing for sane code. We also made sure that such lists go through the script evaluation engine cleanly (except for the first word, which will be forced to be interpreted as a command name, obviously). I think we (well, mostly me in this case) sorted this out properly in 8.5.

Still, we don't recommend tying objects with important lifetimes to values; Tcl really assumes that it can clone and release them as it sees fit (and effectively that it can interconvert through the serialization without problems). It's a pretty different design decision to what most programming languages go with, and has a lot of consequences, some really good and some quite irksome at times.

There's quite a few extension packages that do the sort of thing you're talking about without trouble. In particular, the packages for handling talking to DOM trees, DCOM interfaces, and JVMs all take this approach without becoming disaster zones. Another approach is to put the magical value in a variable and refer to that variable by name (which is a bit more easily done when it is an array element). I'm sure something could be worked out.

Yes, that's at least technically possible. On the other hand, there's enough work that I believe it very unlikely that anything would be rejected like that provided it works well with the rest of the language, and is reasonably documented and tested. I also know the people involved; we're more of the "You're doing the work? Let us hold your coat for you." persuasion.

The bounties are not large enough to pay someone to solve them. The ones that are fairly low value are likely to get picked off rapidly by the existing community by just focusing their attention slightly differently. The high value ones are in the class where you'd need a team of expert programmers to take them on, and would expect to be supporting them for an extended period of time; that can burn through $100k in pretty short order. (Yes, I'm working on that particular bounty, but I was doing so before the bounty was announced. I know how exactly difficult it is.)

IOW, these are all rewards for success, not pay for doing.