adinisom

They can definitely be distinct languages as is the case with protactile. For the deaf-blind people I've met, ASL is their first language and protactile is more of a second. Maybe it's different in other areas of the world.

What I've noticed is that in deaf-blind contexts plain ASL is terrible for back-channeling information... is the listener paying attention? Agreeing? Disagreeing? Laughing? Protactile communicates these back to the signer using touch, and not touching is considered rude.

The intended solution seems to be a 2% bandwidth limit for announcements and a preference for lower hop-counts to keep your flooding local.

There's a FAQ item on this: https://github.com/markqvist/Reticulum/wiki/Frequently-Asked...

Deaf ASL users have much less need to hear since their language doesn't require it. For that reason I suspect deaf folks generally find hearing less important than blind folks find seeing.

There are blind people like Daniel Kish who use echolocation to replace sight; I get the sense they're more on the difference side of the fence.

Not sure but can mention some challenges:

- The power budget of a traditional HA is ~1mW and operate on ~1V. Existing vendors use custom silicon with sub-threshold designs to hit this. I see this as one of their largest moats. Lipo rechargeable wearables work around this problem.

- Customers for your product want their hearing back, and that's not something HAs realistically provide. So selling them is pretty weird as your customer isn't going to be completely satisfied and newer HAs won't improve much along this dimension. On the other hand you can sell "comfort" via noise reduction, bluetooth streaming, and whatever technology buzzwords you can fit on a brochure.

- But can my fancier DSP algorithms improve speech understanding in noise? Maybe, but you've got a 10ms latency budget in which to do so. Hard to compete with the human brain which can cheat and backdate perceptions into the past.

- FM systems, on the other hand, can dramatically improve speech understanding by eliminating noise and echoes. Right now it's only a fit for situations where you can mic the speaker. Traditional HA companies have a hand in making these.

Mine used to have the problem. Upgrading the firmware and using Ethernet did not fix it.

Observation: disconnecting the printer from the network avoided the un-wake-able "deep sleep" state. Re-connecting the network made it susceptible again. I suspect it's particular network traffic that causes the printer to wedge into a sleep it cannot leave; possibly a Debian box that I've since de-commissioned. The problem no longer occurs despite having the same firmware as before and being connected to the network.

When you're in a better place, maybe have someone else ship them so you don't have to deal with it.

Perhaps rubber hose resistance: "I'm sorry Seydor, it appears you're being coerced to unlock this data."

Can confirm.

I don't program in Go but when there's Go software that needs fixing, it's so much easier to "go build" it and fix bugs in this unfamiliar language than it is merely to compile software written in many more familiar languages. Build systems that just work is a huge advantage.

A more complete archive: https://archive.ph/HKAF2

Transcribed using 'base' model:

https://pastebin.com/M5276AFE

For others reading, "mainstreamed" means being placed in a regular classroom. An ASL user might be mainstreamed with interpreters for communication access. On the other hand someone who grows up using oral methods for communication might use hearing aids, CI, FM units, reading/writing in a mainstream classroom.

If it were me, I'd try for a single process with the UI and the indexer running in separate threads.

Communication between threads could be as simple as global variables + a mutex lock.

Two problems to solve:

- Communication from UI thread to backend thread

- Communication from backend thread to UI thread

For communicating to the backend thread, I like using event flags but other people like using mailboxes. Both work. With event flags, you set a bit (for instance, backend_thread.start = True) and if the backend thread is sleeping, it gets woken up by the OS scheduler.

UI frameworks often provide a function to run your code in the UI thread, so your indexer could use that to periodically update the UI. For example you could have an Update() function that reads the global variables defining the state of the indexer and updates every UI element to match, and then the indexer periodically schedules Update to run on the main thread when it's doing its work.

In my work there's typically a state machine that coordinates UI + backend. It might start with state = BACKEND_STOPPED. Then when you press the start button, transitions to state = BACKEND_RUNNING and notifies the backend thread using an event flag. When the backend thread finishes, it can transition back to BACKEND_STOPPED and schedule an update to the UI.

----

Another pattern I've seen is using the database for communication. You might have a "jobs" table in sqlite with indexing jobs to perform. The front-end adds "jobs" to the table and notifies the backend thread to wake up. The back-end processes jobs and updates their status and notifies the UI thread when the status changes.

Can second the DynASM recommendation. I've used it -- was stupid easy to use. Gives your C code an in-line assembler that works at runtime to generate a function pointer.

Grounding is important for shunting the surge to ground.

Keep in mind: surge protectors and UPSes are not necessarily going to prevent damage directly caused by lightning. Lightning has a lot of energy and is high frequency and can make its own paths to ground through and around protective devices.

Lightning strikes cause power outages in a larger area. When power returns, you can get a high voltage surge. This is what surge protection suppresses and protects against.

For (1) you might try ctrl-up/down and in web browsers space and shift-space.

I've seen it happen.

I was on a team of competent people working on a dense code base before and after introduction of gatekeeping code reviews. The code base was large so no two people would be working in the same area. Before code reviews:

- Team members working on a section of code would find and fix bugs in it.

- Team members would watch the repository history to monitor for any mistakes.

When gatekeeping reviews were introduced, they were not particularly effective at finding bugs because bugs tended to be subtle and required time working on the particular code in question to identify. But the introduction of gatekeeping code review caused bugs because:

- Once reviewed, code was assumed to be good enough because hey, two people agreed on it.

- Any bugs identified would require code reviews to fix which would be an uphill battle and probably involve project management.

- Nobody's looking that closely at history because who wants to deal with finding problems and pushing through fixes? And hey, it's already reviewed.

- Knowledge of code that is being reviewed becomes stale as you start working on other features. This impacts pre-commit testing as you make changes to mollify the reviewer, and thus lead to a bug.

- Lowering velocity lowers the rate of fixing bugs.

- A bug could be fixed but stuck in review, so it's still in the codebase for other developers to run across. You could argue: well, it's documented in JIRA! But bugs can manifest in different ways and affect multiple system.

Incentives set up a race to the bottom.

I worked in an environment that was like Raycast and later adopted gatekeeping code reviews. If the code reviewer wasn't happy you couldn't merge. This gives the reviewer power to have the author shape the code the way the reviewer prefers at little cost to the reviewer. And of course the authors often respond by doing likewise when asked to review code. My approach as a reviewer was to provide feedback without blocking merges, but this alone is not enough to incentivize reciprocal behavior.

There was a guy at work who would always complain about numbers that weren't given names as #defines regardless of whether it made sense or not (Magic Numbers!). My co-worker asked him why he was so picky about it. Apparently because someone did that to him.

As an atheist that's one thing I like about religion: preserving religious freedoms helps preserve the freedom of all people.

That said it's not a pure good. Religions can push for oppressive laws that match their beliefs.

Interestingly there was a third-party HyperTalk compiler that could produce INITs: http://www.ittybittycomputers.com/IttyBitty/CompileIt/

I head over to my friend Midev's house with precursor chemicals for VX. You complain that having the precursors to VX lying around is not a good idea. I point out that creating VX is purely hypothetical. Sure, if that happened, it'd be terrible. But, that's not happening.

Apple is deploying a technology with few legitimate uses that makes terrible things not only possible but easy all without the voluntary consent of the device's owner.

Understandable. At the same time, if you have a deaf candidate apply, you and your coworkers have the opportunity to learn some of their non-verbal communication strategies for collaboration.

Lots of info here: https://lightboard.info/

Also lots of places to buy them. Here's one: https://www.desktoplightboard.com/product/desktop-lightboard...

Unfortunately that's not possible for receivers barring a break in crypto. Receivers are authenticated by the sending devices:

https://blog.oakbits.com/google-cast-protocol-receiver-authe...

An alternative Chromecast receiver needs cooperation from the sender one way or another.

Absolutely true.

At the same time I've noticed I'm much hungrier if I don't exercise. And exercise displaces time I could be eating. So, at least for me, it seems to have an indirect impact on weight loss.

Here's the test code: https://pastebin.com/Ye8qecgW

The original issue I had is that under Windows sometimes Watchdog picks up the entire file as being Deleted/Added. Seems to be a race condition of some sort because adding "print" statements after picking up a change makes that less likely.

That causes the part guarded by __name__=="__main__" to be re-run under the Jurigged thread: https://pastebin.com/p68NBxmE

Or to get the same results without the Watchdog issue I can change time.sleep(1) to some other number.

It makes sense that if you change the program top-level Jurigged will try to re-run it but at the same time it never makes sense to re-run infinite loops. I've tested changing __name__ when re-running and that works although requires a guard and I also think it might be helpful not to re-run module code that is already running as determined by the thread's call stack.

--- (edited since can't reply) ---

Good call on de-bouncing. I tested with both "notepad" and "notepad++" and get the same behavior. The Delete/Run happens within a millisecond so 0.1s filtering should work. Perhaps that would also allow you to monitor for file Delete/Add to work with editors that use atomic replacement.

With that fixed, avoiding re-executing the main loop isn't as important but I think it's worth doing for robustness. Detecting this also gives you the option of restarting the process instead.

And the reason Jurigged breaks on changes to toplevel is it's re-running the top level in its own thread... including the infinite loop that is your application.

This makes sense: it has to re-run the module's code. As long as you don't touch the module that kicks off your application it'll work fine. How can we make it work in the same module that runs the app?

One approach that seems to work is to use the: if __name__ == "__main__" guard on your app code, then modify Jurigged to change __name__ to something else upon reloading. I'm not familiar enough with Python internals to tell if changing __name__ is kosher.

Another possibility is to examine the stack and stop executing code when reaching the root of the current stack... although there's no guarantee the code has been running long enough to reach the program's infinite loop such as when the file was modified a split second after the program started.

Neat!

Attempted to run on Windows and it almost works on my machine.

- Watchdog's win32 implementation watches directories rather than files. If Jurigged is patched to watch the directory instead, this part works.

- When the toplevel code is patched, the thread dispatching Watchdog events stops and won't pick up further filesystem changes. This can happen when changing code at toplevel or sometimes a file update gets picked up as Delete/Add instead which causes Jurigged to patch toplevel.

Still trying to track down why that happens.

Agreed: building various flavors of interpreters (such as in SICP) is an effective way to gain an understanding of different abstract semantics and how they compare.

You might also like "Programming Languages: Application and Interpretation":

1st ed: https://web.archive.org/web/20150926000110/http://cs.brown.e...

2nd ed: https://web.archive.org/web/20210121232912/http://cs.brown.e...

Also recommend lurking on http://lambda-the-ultimate.org/ to find material that interests you.

Yes, I think he finds a DSL useful for that reason: each place where flow of code diverges (FOR, IF) is recorded and serves as the identity of the entire execution path.

The differential execution approach is to "diff" the GUI by "diff"ing the program's control flow. As opposed to something like React where we're diffing the virtual-DOM output of the render().

During a GUI update the program is run comparing it's new control flow with the prior run. So for example on an IF statement, if the prior execution took branch A but the new run takes branch B, then we need to run branch A again in "erase" mode to erase everything created by branch A, then run branch B to create the new state.

You might be interested in Mike Dunlavey's Differential Execution demo:

https://sourceforge.net/projects/dyndlgdemo/files/

https://github.com/MikeDunlavey/AucUI

He explains it a bit more here:

https://stackoverflow.com/questions/371898/how-does-differen...