If you want to pull another cable:

- secure a string to the old cable

- pull the cable out the other end, pulling the string through

- secure the string to the new cable

- pull the string out the other end, pulling the new cable into position

Pull a string alongside the new cable, too, and tie it off on both ends. Always leave a pull string in the conduit.

> a string

At this point, multiple. Just in case.

You forgot to also tie another piece of string to the new cable so that you pull the new cable AND this other bit of string through.

This gives you a piece of string in the conduit run to be able to pull through the next thing days/weeks/years later.

> [...] a string [...]

Does someone have a recommendation for a specific material the string should be made of?

Back in my day the local telephone company used waxed lacing cable for that sort of thing[1]. These days it seems that polypropylene string is popular (search on "conduit pull string").

You basically want something that is slippery and will tend to not get stuck. I have used Dacron fishing line, but that is mostly because I had a bunch of it laying around.

[1] https://en.wikipedia.org/wiki/Cable_lacing

The sell pulling string in the electrical section of the hardware store.

But make sure you don't buy pushing string by mistake!

They also make bottles of cable pulling lubricant for this purpose.

AKA boy butter [0].

0: http://www.electricalslang.com/Slang/boy%20butter

The picture in the article shows what looks like keypoint matching (ie, SIFT, SURF, FAST) between the query picture and the database. This can give an exact location if a picture of the location exists in their database.

They contrasted this with their prior technique which is more of an image classifier that can identify general location from image features. This approach does not require their database to contain a picture of the exact location.

A while back I looked at matching pursuit. At first it seemed very complicated, but after staring at it a bit realized it's simple.

- Start with a list of basis functions and your signal.

- Go through the list and find the basis function that best correlates with the signal. This gives you a basis function and a coefficient.

- Subtract out the basis function (scaled by the coefficient) from your signal, and then repeat with this new residual signal.

The Fourier transform is similar using sine wave basis functions.

The key that makes this work in situations where the Nyquist theorem says we don't have a high enough sampling rate is ensuring our sampling (possibly random) is un-correlated with the basis functions and our basis functions are good approximations for the signal. That lowers the likelihood that our basis functions correlating well with our samples is by chance and raises likelihood it correlates well with the actual signal.

Buildings as walls and using spawn points to jump through terrain are fun mechanics in WC2.

I remember creating a moat of farms around my town hall.

Hearing in noise is both what most people want from hearing aids and what they are least equipped to provide.

The traditional solution is an FM system where you give the person speaking a microphone linked to your hearing aids. There are dedicated ones like Phonak Roger. You could probably also use your phone as a microphone if it's bluetooth connected to your headphones or hearing aids.

Least equipped to provide? They've been working on machine learning algos for exactly this purpose for twenty years.

That sounds awkward.

The tech for isolating a speaker at conversational distances exists. You use half a dozen microphone transducers (minimum; Crappy microphone transducers are cheap and quality is expensive, so just use a bunch of them), and through a combination of phase and intensity they decode relative location, and amplify that phase expectation while suppressing everything that isn't phased like that. Sound is slow, and readily susceptible to real-time triangulation. The math/processing is much easier if the parallaxes are fixed (eg the microphones are arranged in a line array on the top band of a rigid pair of smart glasses), but with a little latency it's not prohibitive for a deformable array to solve for its own relative position as well.

Addressing comments on hearing aid technology:

Often people who lose their hearing want to be able to hear in social situations such as restaurants and family gatherings. In this context, the signal and noise have similar properties and are coming from the same direction. Directionality helps but can only do so much. Noise reduction can make hearing aids more comfortable to wear but don't necessarily improve comprehension in challenging situations. Progress here is fantastic -- at the same time it helps to have realistic expectations.

Putting the mic on the person speaking sidesteps the problem -- it's like the rest of the room isn't there.

That’s more a solution for far more extreme cases, including actual hearing loss. This would be far more involved than me lining up my ears with their mouth ;)

I read it as:

Dan is a moderator on a forum and his goal is to maintain a level of civil discourse rather than an aggressive style of communication. It's a very specific definition of "violence" for a specific context and perhaps there's room for clearer terminology.

If talking about UI, the flip side is not to harm the user's data. So despite containing errors it needs to representable, even if it can't be passed further along to back-end systems.

For parsing specifically, there's literature on error recovery to try to make progress past the error.

Two that come to mind:

1) Embedded systems typically do not allow data to grow without bound. If they were going to keep debugging data, they'd have to limit it to the last N instances or so. In this case N=0. It seems like the goal here was to send troubleshooting data, not keep it around.

2) Persisting the data may expose the driver to additional risks. Beyond the immediate risks, someone could grab the module from the junkyard and extract the data. I can appreciate devices that take steps to prevent sensitive data from falling into the hand of third parties.

It would be trivial to set it up to only delete old instances when free space goes below a threshold.

If the data can expose the driver to additional risks, then the driver can be exposed by someone stealing the vehicle and harvesting that data. Again, that can be trivially protected against using encryption which would also protect in the instance that communication was disrupted so that the tar isn't uploaded/deleted.

My favorite trick in C is a light-weight Protothreads implemented in-place without dependencies. Looks something like this for a hypothetical blinky coroutine:

  typedef struct blinky_state {
    size_t pc;
    uint64_t timer;
    ... variables that need to live across YIELDs ...
  } blinky_state_t;
  
  blinky_state_t blinky_state;
  
  #define YIELD() s->pc = __LINE__; return; case __LINE__:;
  void blinky(void) {
    blinky_state_t *s = &blinky_state;
    uint64_t now = get_ticks();
    
    switch(s->pc) {
      while(true) {
        turn_on_LED();
        s->timer = now;
        while( now - s->timer < 1000 ) { YIELD(); }
        
        turn_off_LED();
        s->timer = now;
        while( now - s->timer < 1000 ) { YIELD(); }
      }
    }
  }
  #undef YIELD

Can, of course, abstract the delay code into it's own coroutine.

Your company is probably using hardware containing code I've written like this.

What's especially nice that I miss in other languages with async/await is ability to mix declarative and procedural code. Code you write before the switch(s->pc) statement gets run on every call to the function. Can put code you want to be declarative, like updating "now" in the code above, or if I have streaming code it's a great place to copy data.

A cleaner, faster way to implement this sort of thing is to use the "labels as values" extension if using GCC or Clang []. It avoids the switch statement and associated comparisons. Particularly useful if you're yielding inside nested loops (which IMHO is one of the most useful applications of coroutines) or switch statements.

[] https://gcc.gnu.org/onlinedocs/gcc/Labels-as-Values.html

In `proto_activities` this blinking would look like this:

  pa_activity (Blinker, pa_ctx_tm(), uint32_t onMs, uint32_t offMs) {
    pa_repeat {
      turn_on_LED();
      pa_delay_ms (onMs);
  
      turn_off_LED();
      pa_delay_ms (offMs);
    }
  } pa_end

Here the activity definition automatically creates the structure to hold the pc, timer and other variables which would outlast a single tick.

I have used this approach, with an almost similar looking define for YIELD myself.

If there is just one instance of a co-routine, which is often the case for embedded software, one could also make use of static variables inside the function. This also makes the code slightly faster.

You need some logic, if for example two co-routines need to access a shared peripheral, such as I2C. Than you might also need to implement a queue. Last year, I worked a bit on a tiny cooperative polling OS, including a transpiler. I did not finish the project, because it was considered too advanced for the project I wanted to use it for. Instead old fashion state machines documented with flow-charts were required. Because everyone can read those, is the argument. I feel that the implementation of state machines is error prone, because it is basically implementing goto statements where the state is like the label. Nasty bugs are easily introduced if you forget a break statement at the right place is my experience.

Yes, 100%. State transitions are "goto" by another name. State machines have their place but tend to be write-only (hard to read and modify) so are ideally small and few. Worked at a place that drank Miro Samek's "Practical Statecharts in C/C++" kool-aid... caused lots of problems. So instead I use this pattern everywhere that I can linearize control flow. And if I need a state machine with this pattern I can just use goto.

Agreed re: making the state a static variable inside the function. Great for simple coroutines. I made it a pointer in the example for two reasons:

- Demonstrates access to the state variables with very little visual noise... "s->"

- For sub-coroutines that can be called from multiple places such as "delay" you make the state variable the first argument. The caller's state contains the sub-coroutine's state and the caller passes it to the sub-coroutine. The top level coroutine's state ends up becoming "the stack" allocated at compile-time.

Worked at a place that drank hiearchical state machines kool-aid. Yeah.

https://en.wikipedia.org/wiki/UML_state_machine#Hierarchical...

Yeah. Protothreads (with PT_TIMER extensions) is one of the classics libraries, and also was used in my own early embedded days. I was totally fascinated by its turning ergonomic function-like macros into state machines back then.

Humans are also created/derived from other works, trained, and used as a tool by humans.

It's interesting how polarizing the comparison of human and machine learning can be.