I recommend "A Guide to the Good Life" by William Irvine. The title is a bit off-putting, but it gives a good survey of the philosophy and history of stoicism along with good examples of applying it to modern life. After reading it, you might have a better sense of which primary sources will be most relevant to what you're looking for.
They are much harder to sterilize, and autoclaves don't work. Ideally you'd dispose all tools exposed to prions, but if that's infeasible, the CDC recommends an autoclave in a bath of NaOH.
Sure, but it's also expected that it should provide output that could be compiled to produce the input, and in this case it's impossible to satisfy both those constraints. The best thing would probably be to leave a comment in the generated source code explaining the problem, and provide an option to rename overlapping functions.
It's not necessary always possible to output valid-to-compile Java sources. If the bytecode came from a different JVM language, then there are times where javac can't emit certain bytecode patterns.
I would argue that decompilers are primarily reference tools (i.e., a more readable disassembly). It is wrong to see them as source code recovery tools because they will never be able to capture every aspect of the original program. So it doesn't make sense to have as a primary goal the ability to provide output that can be compiled again. It is more important that they more faithfully represent the disassembly.
Basically, ask for an amount of memory, and give back a pointer to memory. But it does not allow you communicate anything but the amount on an allocation, and you can only give a memory pointer on freeing. If, for example, malloc had an interface like:
One can imagine you could optimize based on the given hint. Once you open up one kind of hint, you can imagine many other kinds of things users could communicate explicitly to the memory allocator about the allocation and access patterns of their data.
All implementations of free also need to find the related metadata for the given pointer. We could also imagine an interface for free which required the user to maintain that, but could perhaps speed things up:
void free(void* ptr, meta_t d);
Or, we could also imagine communicating how important it is to free this memory:
In the latter case, maybe the memory allocator could put off doing delayable requests, and do them in a batch later. (Making it a bit more like garbage collection.)
I'm not sure any of these ideas would help, but the point is that because of the limited interface, we really can't explore them. We can, but then convincing the rest of the world to change such a basic building block of C code is quite hard.
> In the latter case, maybe the memory allocator could put off doing delayable requests, and do them in a batch later. (Making it a bit more like garbage collection.)
Amusingly, when I've used an IMMEDIATE/DELAYABLE style hint, it was for the opposite purpose: I had some batched deallocs that I would either delay (to spread out over multiple frames instead of handling as a single batch, to eliminate the framerate hitch we were getting), or perform immediately as a single batch (to achieve greater throughput when switching scenes as delayed deallocation was adding untenable amounts of overhead.)
> We can, but then convincing the rest of the world to change such a basic building block of C code is quite hard.
Changing such a fundamental building block if C is impossible.
However, providing a second alternative interface, for those applications which could really benefit from such fiddly high performance tweaks, already happens a good bit in games at least. Pool allocators, allocators with extra debug information, allocation of entirely different styles of memory (e.g. write combined memory for texture uploads)... lots of stuff out there. Some low level graphics APIs now make you decide if e.g. you want to put shader constants in their own GPU buffers, or just interleave them into the command buffers themselves...
"jemalloc has an alternative API that allows specifying the size of the allocation"
I would like to see an API for malloc where you don't need to specify the size of the allocation :-)
For those who wonder: it takes additional flags specifying alignment, whether to zero memory, whether to store data in a thread-specific cache, or am arena to use.
Another way of improvement is to use alloca() for small local (to function) objects but there is no direct way to know if a variable is local or not (in C and C++ at least).
> We can, but then convincing the rest of the world to change such a basic building block of C code is quite hard.
I can be made with static analysis or binary instrumentation.
malloc(sizeof(foo)) is slower than alloc_foo() because the latter can simply be a pointer increment, but there is no way to tell the malloc() interface that you're going to be doing nothing but allocating foo for a while.
malloc() can guess this with heuristics, but a good malloc() needs to perform well for a wide variety of use cases: Surely you can appreciate that balance has a cost that the specialised allocator simply doesn't have to pay.
Part of my work deals with medical patient safety but I study all sorts of safety including airlines, nuclear power, oil & gas drilling and refining, ....
There should be a mechanical fail-safe if the power cuts in this case.
In our DARPA Grand Challenge vehicle in 2005, we had a non-computerized system for an emergency stop. A hardware timer had to be reset every 120ms by the computers. If it timed out, a relay dropped out, and an electric motor with two sources of DC power (the main power system, and a battery) drove the brake pedal down until a hydraulic pressure switch detected full brake pressure and turned it off.
In addition, the throttle control went through a pull cable device with an electromagnet. With the electromagnet on, a servomotor could operate the throttle. The emergency stop system would drop power on the electromagnet if the stall timer timed out, or on some other fault conditions. That forced the throttle to idle.
Then we had an Eaton VORAD radar. That data went into the main mapping system, along with LIDAR data, but it also was processed by a simple separate process that computed time to collision from range and range rate, and if it didn't compute a safe distance, or didn't reset the watchdogs, tripped the emergency stop system. If this happened, the LED sign on the back of our vehicle displayed "COLLISION IMMINENT".
This happened once during the Grand Challenge preliminaries. Several vehicles were in the starting gates side by side. We were ready to go, all systems running and armed, waiting for DARPA to release the hold signal they were sending by radio. The organizers decided to release the CMU vehicle first, and it came out of the starting gate and cut in front of our vehicle. The safety systems tripped and "COLLISION IMMINENT" appeared in the sign. After a few seconds, with the threat gone, the system reset and the sign went dark.
This was all fully automatic. There was also a remote engine kill system, required by DARPA.
We didn't win. But we didn't crash or hit anything. There were Grand Challenge entries that ran away, including, in 2004, one from CMU. Another one ran away because they filled their disk with logging info and this stalled the software. Steering and throttle froze, and the vehicle ran away until it hit something.
If you work on automatic driving, you have to prepare for trouble like this.
If your battery dies while the car is running (say, even, that something causes a physical disconnect between the batteries and the rest of the car — a wiring fault, or whatever). Ideally you would be able to pull to the side of the road while your vehicle coasts, braking as necessary.
If the system detects a power disconnect and instantly engages all brakes, does that help or harm? Additionally, since powered items like anti-lock brakes are now unavailable, how hard should the brakes be engaged? Fully? Slightly?
Slamming on the brakes in a failure scenario is not automatically the right answer. Odds are it's probably the wrong answer more often than not.
To answer the question, it's quite possible to have a braking system that engages in the event of power failure. I've heard of even double-redundant braking systems, so three total systems have to fail before the brakes fail. It was on a Rolls Royce as I recall. The owner was crowing about how his brake job cost more than my car.
If there is no power than chances see there is limited steering as well. Probably safer to have motionlessn 2-ton rock rather than a 2-ton ballistic missile.
Power steering might be off, but that doesn't mean steering is limited.
A motionless 2-ton rock in the middle of a busy interstate because of a power blip is a terrible idea. And again, how hard exactly should the system brake? Pick a value between 0% braking and 100% braking that brakes maximally without locking up the brakes.
A 2-ton brick spinning down a busy interstate because the brakes locked up is arguably even worse than a motionless one.
Wait, do regular cars engage the emergency brake in a fail-safe way? I've always treated the emergency brake as a way to keep a stopped car from moving, not as a way to make a moving car stop.
No, a regular car will not engage brakes without human interaction. The fail-safe is having two independent systems - hydraulic for the foot brake and wire rope for the hand brake in most vehicles.
Additionally automatic transmissions have a transmission lock, but that won't work while the vehicle is in motion.
Some modern cars use electric systems for both, I'm not sure how that would work.
Also, the hydraulic brake system is built with redundancy (dual circuit), so even a sudden big leak in a brake line will leave you with some braking power.
And the power braking system, being pneumatic IIRC, keeps working for a couple of hard stomps on the pedal even if the engine stops running and you lose 12V.
Pretty much the only thing you can expect to lose is the ABS. Even then, I understand that system has a failsafe such that it keeps the car from spinning in the event of malfunction and brake lockup. You can see this in ABS-related accidents as straight skidmarks. But I don't think that works when you've lost electric power.
Edit: actually, the recent Koenigsegg One:1 high speed crash (driver not hurt) during testing at the Nurburgring was an ABS sensor failure, you can see the hallmarks in photos. Koenigsegg also deserve big props for having been completely open about it.
No, the handbrake (not emergency brake) is actually connected (mechanically) to a completely separate set of brakes on the rear wheels. Only on custom-built drift cars á la Ken Block is the handbrake connected to the normal brake calipers.
It depends on the car. Some of them engage the same calipers the hydraulic system uses. Some have a separate caliper or drum. Older, drum brake cars engaged the same shoes the hydraulic system used. And if you go back far enough, some had mechanical pawls or band type brakes that engaged at the transmission.
And drift cars use a separate hydraulic brake attached to the rear disks.
This is correct. Some emergency brakes uses a screw mechanism to activate the brake cylinder piston to push on the pads. Same stopping mechanism as if you push on the brake pedal.
Others (usually less expensive cars) have a set of drum brakes inside the disk brake that act as emergency brakes.
If you have rear drum brakes, it's the same as my first example. The emergency brake activates the normal braking system.
Maybe. But that's the main (traction) battery. Certainly regenerative breaking is out, but the 12V battery should not be disengaged and provide enough energy to apply the brakes. Not sure how the Tesla is actually engineered though, as I'm a Leaf owner.
1) This is true on the mac too, but it's option instead of ctrl. (option + arrows, option + shift + arrows). It's certainly not common for apps to break this afaik.
Looks like their plan is to reuse the ocaml compiler backends that output javascript; but it doesn't sound like they're doing anything explicit to promote Reason -> Javascript compilation.
Well, if you ignore the red button that runs you through comparisons of different Javascript syntax to the equivalent Reason syntax, then sure, they aren't doing anything explicit...
Whether they have an intermediate step that is OCaml or not is irrelevant. Most compilers have one of more intermediate representations between source and executable. I think providing a syntax comparison to Javascript right next to a syntax comparison to OCaml is a clear indication that they are marketing to Javascript programmers, and the only reason for that is if they intend thelanguage as a replacement or supplement to Javascript.
That may or may not seem relevant to you based on ciniglio comment, but I think it's on point if you follow the thread from it's source down.
In 2016, "marketing to JavaScript programmers" is pretty much the same thing as "marketing to programmers". Providing context that the vast majority of programmers will understand is helpful regardless of the compilation strategy. That being said, of course people want a language that can compile to JavaScript, and it's worth mentioning the expanding set of options for doing so. But the syntax comparison really would be worthwhile even if it weren't the case, if only to provide context to what is likely the largest developer community that exists today.
