The article specifically mentions this optimization as not working with the compiler at that time, hence the need for the separate index variable.
> We will edit su.c to prevent the overflow by maintaining a counter, i, and verifying it against the buffer size during the read loop. I initially attempted a fix using pointer arithmetic, but the 1973 C compiler didn’t like it, while it didn’t refuse the syntax, the code had no effect. I settled on a simpler index-based check instead.
Well really, the language _is_ the difficulty of much of hardware design, both Verilog and VHDL are languages that were designed for simulation of hardware, and not synthesis of hardware. Both languages have of similar-but-not-quite ways of writing things, like blocking/nonblocking assigns causing incorrect behavior that's incredibly difficult to spot on the waveform, not being exhaustive in assigns in always blocks causing latches, maybe-synthesizeable for loops, etc. Most of this comes from their paradigm of an event loop, handling all events and the events that those events trigger, etc, until all are done, and advancing time until the next event. They simulate how the internal state of a chip changes every clock cycle, but not to actually do the designing of said chip itself.
I'm tooting my own horn with this, as I'm building my own language for doing the actual designing. It's called SUS.
Simple things look pretty much like C:
module add :
int#(FROM:-8, TO: 8) a,
int#(FROM: 2, TO: 20) b ->
int c {
c = a+b
}
It automatically compensates for pipelining registers you add, and allows you to use this pipelining information in the type system.
It's a very young language, but me, a few of my colleagues, and some researchers in another university are already using it. Check it out => https://github.com/pc2/sus-compiler
> miss the time when "confused" for a computer program was meant in a humorous way
Not sure what about this isn’t funny. Nobody died. And the notion that traffic lights going down would not have otherwise caused congestion seems silly.
> what about the emergency services not being able to reach their destinations?
Did they have documented problems?
This is akin to the Waymos honking at each other at 3AM. Annoying. Potentially dangerous in various circumstances. But ultimately just destructive in a way unlikely to repeat.
American cops, fire, and EMS will go upstream on a one way road, or use the sidewalk or the grass if they have to. The Blues Brothers film may even be the material used to train some of the more ambitious departments.
Have you seen how human drivers deal with traffic lights and emergency vehicles at the same time? Waymo made the right call to suspend service, they will probably update their playbook to suspend service during power outages in the future.
Humans certainly are imperfect and make mistakes, but will iterate with the understanding that doing nothing at all and blocking emergency vehicles is untenable.
At the least we will fall back to incentive/disincentive social behavior. People will supply ample friendly and unfriendly advice to try to unwind the knot.
Waymo should lose their operating license based on this experience. It's self-evidently dangerous to everyone to be incapable of basic iteration. There's a whole set of law driver's are supposed to follow for handling failed traffic lights. Why have lower expectations of an anonymous car than a human?
> Waymo should lose their operating license based on this experience.
Then everyone should lose their licenses as well by your draconian reasoning. Because…
> There's a whole set of law driver's are supposed to follow for handling failed traffic lights.
And they don’t, it’s chaos.
> Why have lower expectations of an anonymous car than a human?
You obviously have higher expectations for autonomous cars than humans, it is not the other way around for those of us who disagree with you. The only difference is that Waymo can get better with experience and humans generally don’t.
> > There's a whole set of law driver's are supposed to follow for handling failed traffic lights.
> And they don’t, it’s chaos.
Do you live in areas where traffic lights go out regularly?
Because for human driver it is a non-issue. It becomes an all-way stop and you take turns, it is easy. Traffic throughput slows down a bit, but nothing approaching chaos about it. If waymo can't deal with this, that's a problem.
Developing new technologies has risks. In the absence of anything really bad actually happening, I think we can solve the problem by adding new requirements to Waymo's operating license (and all self driving cars) rather than kneecapping the technology.
Regulation is about setting minimum standards for acceptance, not specifying exactly how.
This means that if I walk into a random croissant shop and buy a croissant, I don't subsequently have 2 days of food poisoning.
Arguably, healthier being the default is also good. The less I personally need to think about this, the more I can think about other more useful things.
Just now, I'm travelling through India, and today was particularily rough. (I'm trying to go from Delhi Airport to Agra). Multiple Ubers turned out bad (scams, no-show, or fucking with pickup point). I spent several hours in this limbo getting nowhere. I end up taking a train without ticket on advice of multiple people around me, since the counter refused to sell me one.
Turns out, wrong train, going slightly the wrong way. But a guy walks up to me in the train, asks me where I'm going, and starts to help me get to where I need to go. He arranged a bunk for me, talked to the conductor for me, bought(!) another train to Agra for me, called hostels in Agra, etc etc. I've had multiple such encounters here in India, of people going so far out of their way to help me here, something you would honestly never see in my country Germany. It's like a strange incongruence, with one fraction of the population hell-bent on fleecing you for all you've got, and another that will go way further out of their way for you than you could ever imagine.
This correlates with tourism. Low touristy places you standout and people treat you nicer than normal.
In touristy places you are just a target. It’s just different places have different strategies for fleecing you. For example in Japan you probably wouldn’t even know you got ripped off but India they are likely so obvious about it you never get fleeced.
If you find the sheer number of people too much, do visit either Himachal Pradesh or Uttarakhand! You will find THE kindest people there. Though be careful of leopard and bear attacks in Uttarakhand right now!!
Oh, I just came back from Shimla actually. I stayed in Narkanda for 2 days to do some hiking, and Shimla one day, though I didn't interact with many people there. My next stop is Kochi, hopefully things are also a little quieter there.
Kochi is also a very nice city, but if you're coming from Shimla or even Delhi you're going to find it sweltering hot probably. It's about 26⁰C (80⁰F) right now... (I'm close to Kochi and honestly in these temperatures it doesn't even feel like Christmas)
Ps, Kochi can be quite bustling. The more remote and rural towns (like Munnar) are a relatively safer bet.
Make sure you try to talk in English and see. Most people should know or atleast understand english there. And Kerala food can be spicy and it's hot out there. Make sure your drink enough water and stay hydrated.:)
Printing the hash of the result is a nice trick I've used a couple of times myself, but jumping through the hoops of making the inputs parametrizeable (a la env vars) is only going to make your benchmarks less reliable, not more. It could be that the request for the env var gets moved past you let start = now() call, and therefore you're now partly benchmarking std::env::get().
Instead, stick with std::hint::black_box for both inputs and outputs. Your benchmark will have no overhead from them, and you're benchmarking exactly what you intend. For low-level benchmarks, use repeats (again with std::hint::black_box on independent loops, or a proper microbenchmarking framework
I've used tree-sitter for generating my parsers in Rust, and just working with the untyped syntax tree it generates, and gives you error-tolerance for free. It's a bit of a setup at first tho, requiring an extra crate for the generated parser, but editing it from there saves so much time.
What do you mean exactly by "error-tolerance"? Is it like, each node is wrapped into a result type, that you have to match against each time you visit it, even though you know for a fact, that it is not empty or something like that?
I suppose that one of the pros of using tree-sitter is its portability? For example, I could define my grammar to both parse my code and to do proper syntax highlighting in the browser with the same library and same grammar? Is that correct? Also it is used in neovim extensively to define syntax for a languages? Otherwise it would have taken to slightly modify the grammar.
Oh nono, with tree-sitter, you get an untyped syntax tree. That means, you have a Cursor object to walk the tree, which creates Node objects as you traverse, that have a "kind" (name of the tree-sitter node), span, and children. (I recommend using the rust tree-sitter bindings itself, not the rust wrapper rust-sitter).
Yes, portability like that is a huge benefit, though I personally utilized it for that yet. I just use it as an error-tolerant frontend to my compiler.
As to how errors are reported, tree-sitter creates an ERROR or MISSING node when a particular subtree has invalid syntax. I've found that it never leaves a node in an invalid state, (so never would it create a binaryop(LeftNode(...), Op, ERROR) if RightNode is not optional. Instead it would create an ERROR for binaryop too. This allows you to safely unwrap known fields. ERROR nodes only really bunch up in repeat() and optional()s where you would implicity handle them.
Error tolerance in this context means the parser produces a walkable AST even if the input code is syntactically invalid, instead of just throwing/reporting the error. It’s useful for IDEs, where the code is often in an invalid state as the developer is typing, but you still want to be able to report diagnostics on whatever parts of the code are syntactically valid.
Software Transactional Memory is an interesting idea. I looked into it with much interest as I hadn't heard of it before.
Sadly, the simplicity benefits it touts over Mutexes simply don't pan out. You still have to have some structure around your critical section, it forces you to still contend with partially-updated intermediate values, which mutexes spare you from.
Likewise, the composition issue isn't more solved with STM than with Mutexes. Implementations that wish to support re-entrant transactions still have overhead over those that don't, similar to the overhead a reentrant_mutex has over a regular mutex.
With an Upgradeable Shared Mutex one can take a simple shared read lock, an exclusive write lock, or an upgradeble read lock. The upgradeable read lock can then - without unlocking - be upgraded to an exclusive lock once you've prepared the writes you wish to do, keeping the exclusive section as short as possible. To avoid deadlock, the upgradeable read lock can exist concurrently with simple read locks, but not other upgradeable locks.
reply