I can't speak for others, but I'd go further and say that LLMs allow me to go deeper on the design side. I can survey alternative data structures, brainstorm conversationally, play design golf, work out a consistent domain taxonomy and from there function, data structure and field names, draft and redraft code, and then rewrite or edit the code myself when the AI cost/benefit trade off breaks down.

> I've learned to draw much stricter boundaries.

Could you elaborate on what has worked for you?

I imagine people who work in customer service have strategies too.

https://privatebin.net/?db6418554d9d5728#3NjbsSUYzw227zG5P1k...

Daily snapshot of the generated doxygen docs are here: https://files.portaudio.com/archives/pa_v19_doxydocs.tgz

website: www.portaudio.com

GitHub (including wiki): https://github.com/PortAudio/portaudio

I'd also like to make a general comment about "making an impact" on open source projects. There are many ways to help out on an open source project, but one good way is to maximise the benefit:maintainer-cost ratio. Maintainer cost comes in a number of forms: cognitive and time cost of reviewing PRs, engaging in design discussions, iterating on PRs, coordinating a "live" work in progress PR for long periods of time, you get the idea. With this in mind, I like it when the contributor owns the PR from submission to merge, don't just make the PR, help the maintainers get it over the line however is needed. A lot can be done by simply submitting PRs that follow project guidelines and established conventions, are targeted at a single improvement, making them uncomplicated, quick and easy to review, and most importantly such obvious improvements that there is no question about merging the change. A pet peeve of mine is PRs that include one excellent insta-merge change and an unrelated change that is controversial or requires significant rework. Keep PRs orthogonal, atomic, simple. It might be more work for you but if you are available to contribute you are not the time-poor party.

It's worth considering that the dataflow graph (as an abstract mathematical graph), the computation graph (the partial order of function execution required to compute the data), the traversal strategy, the runtime representation of the graph, the runtime data structure for the graph, and the runtime data structures for efficient reactive update are all separate but related aspects.

For instance, push and pull are both directed graphs. They have the same connectivity, but the direction of the arrows is reversed. You can only efficiently traverse edges in the direction that you represent. A dataflow graph has edges pointing from sources to sinks, a data dependency graph has edges pointing from sinks to sources. [Side note: if a computation can produce multiple results the data dependency graph and the computation dependency graph are not exactly the same thing and you need to be clear on the distinction, but I am assuming here single-output nodes]. In a dataflow graph you want to evaluate the changed nodes prior to evaluating the downstream nodes that depend on them. As TFA states, this necessitates a postorder (children first) traversal of the data dependency graph, starting at all terminal sinks, and terminating at sources or already visited nodes. You can use a sense-reversing "visited" flag on each node to avoid a reset pass. As noted in the article this traversal need only be performed when the graph topology changes. But for stable traversal order the topological sort can be cached in an array. Needless to say that arrays are much faster to iterate over than any kind of pointer chasing. [Witness the rise of Entity-Component systems over OO models]. I suspect that there is a cut-over point where it is more efficient to iterate the entire array (perhaps with memoized results, or JIT compilation) than to perform a more surgical "update only what is downstream of the changes" approach. Another approach is to assign all nodes a contiguous integer id, and maintain a dirty node bitmask where bit-indices correspond to node ids. In addition, each source has a bitmask that is 1 for all downstream dependent nodes. When a source changes, bitwise-or source.downstream_dependents bitmask with the global dirty_nodes bitmask. To evaluate (not necessarily immediately), iterate in topological order processing only the dirty nodes. In any case, the point I'm trying to make is that the data structure that is best for building or manipulating the graph could very well be different from the data structure that is best for computing the desired results. There will be trade-offs to be made. For this reason alone it's best to keep the graph-theoretic properties and the implementation data structures separate in your head.

In my view the interesting requirements raised by the article are (1) lazy evaluation (e.g. of expensive or conditionally required data). This might be where control flow graphs of basic blocks enter the story. and, (2) dynamic reconfiguration during node evaluation. Some questions I'd be asking about dynamic reconfiguration are: what happens if you delete a node that has yet to be evaluated? will new subgraphs "patched in" to the existing graph (how exactly?), or are they always disconnected components that can be evaluated after the current graph traversal completes?

See also: eigenvalue, differential operator, diagonalisation, modal analysis

* not a legal definition, IANAL.

In my view the Fourier Transform is still useful in the real world. For example you can use it to analytically derive the spectrum of a given window.

But I think the parent is hinting at wavelet basis.

I got this advice in 1998. I have the book. I found it useful for the "art" part. It got me through the projects that I was working on at the time, but personally it didn't help me with the fundamentals. Paraphrasing what has been said on this site many times in the past: AoE is a great first book in practical electronics if you already have an undergraduate degree in physics. I showed my brother AoE when he was building guitar pedals and he couldn't make sense of it and said it was obviously assuming things that he didn't know (he had no high-school science background).

There are a lot of potential and/or assumed pre-requistites even for basic electronics: high school physics, first-year calculus, maybe a differential equations course, certainly familiarity with complex numbers. As I understand it EEs take vector calculus and classical electromagnetism, that's a long road for self-study. For that reason it's hard to give general advice about where to begin.

For someone starting out I think the first things to study are DC and then AC analysis of passive circuits (networks of resistors, capacitors, inductors), starting with networks of resistors. Ohms Law, what current and voltage actually mean, some basic introduction to the physics passive components. This is the basics, and I don't see AoE getting anyone over this hump. This could be learnt in many ways, electronics technicians and amateur radio people know this stuff -- there are no doubt courses outside university both on line and in person. If we're talking books, get a second hand copy of Grob's "Basic Electronics." Once that's covered you can move on to semiconductors. I can recommend Malvino's "Electronic Principles," but this book won't teach you about resistors, capacitors and inductors. After that I think the Art of Electronics would be approachable. And also more specialised topics like digital design or operational amplifier circuits.

A book that usually gets a mention is Paul Scherz "Practical Electronics for Inventors." I got that book later, I personally found it a bit overwhelming with the mixture of really basic practical stuff combined with more advanced circuit theory, but it's no doubt popular for a reason.

Another standard recommendation is to buy one ARRL Handbook from each decade (I have 1988), the older ones have less advanced (hence more accessible) material. But reading the "Electronics Fundamentals" chapter is no substitute for Grob and Malvino.

As I understand it Taxi is where new development is happening: https://github.com/fpganinja/taxi

There is some use, how much I don't know. I guess it should be established best practice by now. Also run test suites with valgrind.

Historically many of the C/C++ static analyzers were proprietary. I haven't checked lately but I think Coverity was (is?) free for open source projects.

One common failure mode of "do the smallest/easiest thing first" that the article didn't address was that sometimes it's so easy to "buy the running shoes" that you end up with a house full of "easy first steps." I think a better approach is to aim to eliminate unnecessary complexity in moving towards the goal. You can do this by aiming for the smallest, easiest, and simplest first step that simultaneously maximises progress towards the goal. e.g. "I want to make a stand to hold my XYZ." Bad first step: Buy a 3D printer. Good first step: Improvise something out of cardboard.

In my view the specialised hardware is just a way to get more accurate transmission and arrival timestamps. That's useful whether or not you use PTP.

> My mental model is that you form a connected graph of clocks and this allows you to convert arbitrary timestamps from any clock to any clock. This is a lossy conversion that has jitter and can change with time.

This sounds like the "peer to peer" equivalent to PTP. It would require every node to maintain state about it's estimate (skew, slew, variance) of every other clock. I like the concept, but obviously it adds complexity to end-stations beyond what PTP requires (i.e. increases the hardware cost of embedded implementations). Such a system would also need to model the network topology, or control routing (as PTP does), because packets traversing different routes to the same host will experience different delay and jitter statistics.

> TicSync is cool

I hadn't seen this before, but I have implemented similar convex-hull based methods for clock recovery. I agree this is obviously a good approach. Thanks for sharing.