tmux doesn't help you in this scenario, because the tmux process is lost during a system reboot. I concur with the parent - Terminal.App's ability to restore the previous sessions output after a system crash (which on my macbook Air ranges from daily to weekly - FTDI USB Drivers and Display Port cable being to the two major reason) really make me appreciate that feature.
"FTDI USB Drivers", if it's the VCP ones the very latest ones have been reasonably stable for me. I've not had a system crash for quite a while now, whereas I was having them weekly with an older version.
Nope - I'm on the latest 2.2.18 drivers still flakey as can be - This has been an ongoing issue for me for about two years - it's a pain when you are working on a Cisco Router, and you unplug the cable and kernel panic. I guess on the (weirdly?) pro side, it's at least fairly consistent - about 20% of the time, the Macbook (two generations now for me, 2010, and 2013) kernel panics.
This is where Terminal.app (or possibly OS X 10.9 + Terminal.app) ability to show you your terminal history on recovery from Kernel Panic is really appreciated.
If only there was a reliable USB-Serial cable/controller/interface for the Mac. Unfortunately, RS-232 is so rare (except for consoling into Cisco Routers?) that there is no incentive for any vendor to actually write a half stable driver.
I don't know what sort of serial adapter you're using, but I've used a number of the PL2303-based ones over the years (currently a Trendnet TU-S9), and have never had them cause any sort of instability. Weird.
I've never found any one particular USB-Serial Adapter to be any more reliable. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD. Still kernel panics when I pull out the USB Cable.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
I've never found any one particular USB-Serial Adapter to be any more reliable with the FTDI drivers on the Mac. Currently using the Tripp Lite Keyspan, Model USA-49WG, SKU CU8037. Appears on the USB chain as: Product ID: 0x0131, Vendor ID: 0x06CD.
I carry a Dell Laptop when going to customer sites+Putty for consoling into Cisco Routers because I've never found a Serial Cable/USB combination that doesn't cause the Macbook air to Kernel Panic.
I'll give the PL-2303 based device a chance - I see there is a nice comparison site here:
My point is that her tenure in the executive branch extended beyond her involvement in the Iraq War. As SoS, she was also involved in Africa policy, led a push for proactive diplomacy, etc.
In addition, the comments about hiring Rice to secure government contracts is absurd in the opposite direction.
Here's a handful of things I really appreciate about Haskell, although some of this apply to other ML family languages as well:
1.) Algebraic Data Types let you enforce a huge amount of correctness in your programs simply by how you define your types.
For example, say you have a data type that represents a player's state in a game. If the player is alive, he has a "HP" and "inventory" record. If the player is dead, he should just be dead—HP and inventory may or may not be set to 0 and None, respectively. In C or OOP languages, you just get a player object/struct and you have to enforce this state logic manually, and you can easily write a function that puts the player in an inconsistent state (player.alive = False, but player.HP = 15). In Haskell, you can define the player such that code that produces this kind of inconsistent state will not compile.
Of course, you should still write tests in Haskell, but it's amazing to me that the type system can catch the vast majority of programming errors before your program even compiles. It takes longer to get something up and running, but you make up for this up front cost with long term gains in maintainability.
2.) Functional purity enforces two very useful properties:
a.) Data is never mutated by accident. This ensures you never have to look beyond the scope of the function you're working on (or closing over, in some cases) to know what's going on. You can then compose these functions to create more complex programs.
b.) When you do need mutability and side effects to happen, Haskell forces you to be very explicit about this and enforces a strict separation between "pure" and "effectual" code. This seems arbitrary until you realize that almost all of your errors not caught by the compiler happen because of IO. Whereas you have complete control over the pure part of your program, IO is nondeterministic and full of exceptions and edge cases. Separating this part of your code makes it far easier to reason about what's happening, adding to maintainability.
As a side note on the last point: people make the argument that this separation makes Haskell impossible to do printf debugging. Not true—the standard library provides ways of circumventing the type system specifically for this reason.
3.) "Monads" and other fancy sounding abstractions can be hard, but with practice they become as intuitive as inheritance in OOP. The real barrier to entry is the awful, awful documentation everywhere. I make no apologies for that: it's just really shitty and the community needs to do a hundred times better.
> In C or OOP languages, you just get a player object/struct and you have to enforce this state logic manually, and you can easily write a function that puts the player in an inconsistent state (player.alive = False, but player.HP = 15).
False. In OOP you can do this using the visitor pattern. The difference is that Haskell makes this real convenient, with its algebraic types feature baked into the language, while OOP makes it very cumbersome.
> As a side note on the last point: people make the argument that this separation makes Haskell impossible to do printf debugging. Not true—the standard library provides ways of circumventing the type system specifically for this reason.
It's still far more annoying when the language is lazily evaluated and has Haskell syntax.
> False. In OOP you can do this using the visitor pattern. The difference is that Haskell makes this real convenient, with its algebraic types feature baked into the language, while OOP makes it very cumbersome.
I don't think we're on the same page here. I meant to say that Haskell protects against inconsistent states: you literally cannot create a dead player with HP and Inventory records. I don't have a strong grasp on the visitor pattern, but I'm not sure how it can be used to accomplish compile time guarantees that the properties of an object will always be correct.
> It's still far more annoying when the language is lazily evaluated and has Haskell syntax.
Python:
def f(x,y):
print x, y
return x + y
Haskell:
f x y = traceShow (x, y) (x + y)
Laziness is a separate issue altogether. Debugging lazy behavior is difficult in any language, and you would have similar problems in Python if you were testing deeply nested generators.
That said, laziness should not be an issue if you are simply testing that functions are correct, since most functions are pure and you will almost never use lazy IO.
If you need to debug evaluation order or a memory leak, that's much harder, and admitted one of Haskell's biggest weaknesses. My answer here is that you should almost always prefer strict data structures and functions unless you really need laziness. That's not a cure all, but it is a good policy when programming in Haskell.
> don't think we're on the same page here. I meant to say that Haskell protects against inconsistent states: you literally cannot create a dead player with HP and Inventory records. I don't have a strong grasp on the visitor pattern, but I'm not sure how it can be used to accomplish compile time guarantees that the properties of an object will always be correct.
An example of the visitor pattern:
class LivePlayer;
class DeadPlayer;
class PlayerVisitor {
public:
virtual void VisitLive(LivePlayer *p) = 0;
virtual void VisitDead(DeadPlayer *p) = 0;
};
class Player {
public:
virtual void Visit(PlayerVisitor *v) = 0;
virtual ~Player() { }
};
class LivePlayer : public Player {
public:
void Visit(PlayerVisitor *v) { v->VisitLive(this); }
LivePlayer(int hp, std::vector<InventoryItem> inventory)
: hp_(hp), inventory_(inventory) { }
int hp() const { return hp_; }
const std::vector<InventoryItem> &inventory() const { return inventory_; }
private:
int hp_;
std::vector<InventoryItem> inventory_;
};
class DeadPlayer : public Player {
public:
void Visit(PlayerVisitor *v) { v->VisitDead(this); }
DeadPlayer() { }
};
This is equivalent to the Haskell code
data Player = LivePlayer Int (Vector InventoryItem) | DeadPlayer
including the fact that in this example the objects are immutable.
Instead of using a case expression to pattern match over the player, you'd have to construct a PlayerVisitor and implement the visit methods on that type.
Things can be made a bit less cumbersome than that, for example in a language with lambdas, you can just have the Visit method take a lambda for each subclass, and each subclass's implementation calls one. That makes it arguably equally convenient to use the types (with some extra parentheses), but it's still much more annoying to define the types that way in the first place.
I think even the visitor pattern isn't required here, all you need is subclassing. Although this clutters things up more by having abstract methods in the base class, technically that's all you need.
To be fair, if the place you're trying to debug is not evaluated (be it due to laziness or because it's generally dead code) that should be a pretty strong indicator something is wrong.
Your confirmation email was sent to my spam folder.
Here's some things you can do to make your email look less like spam:
1.) Use Sublimall in the from field (never leave the from field blank).
2.) Include a physical address for your company somewhere in the message body.
3.) Use better english and include an explanation of what this email is, what triggered it, instructions to ignore the email if the recipient didn't request it.
I like spaced repetition apps, but I'm kind of annoyed that this is just a sloppy landing page without a demo or a concrete description of what the app does. I would resubmit after the app is ready to launch, or you at least have some kind of demo.
You're right. This is a just landing page I put together really quickly after I got annoyed with managing my flashcards in Anki. However, I want to use the interest and feedback of HN as motivation and inspiration to really flesh out the details of noot.
edit: fyi I do have prototype working in Django but it really looks terrible and I'd be embarrassed to show screenshots of my work so far.
I've been wanting to build a good SaaS flashcard app too (I'm interested in flashcards since that's how I study Scrabble words - tournament player) but I have no time. Good luck =)
The guy in the above mentioned 'lets play' videos says that the DOS version (he has) has a bug which lets you use the soldering iron in the tutorials but not in the actual game.
This is silly. "Government wasn't important to the construction of our transportation infrastructure" is an argument you're not going to win, and this conversation increasingly feels like you're grasping at straws.
I feel like the reasonable middle ground here is simply what Fred Turner is insisting: the two components are intertwined and symbiotic. Why is that so hard to accept?
Just so people who only read the headline or skimmed the post know the whole story, the author of this blog ambushed a random Google employee with questions about the treatment of Google contract employees in a private chat room and proceeded to publish quotes from the conversation out of context.
This is clearly done with the intention of embarrassing Travis Collins on the internet, which is in express violation of Digital Ocean's policy which forbids using the service to harass or embarrass others. The author makes a bunch of terrible, incoherent excuses for his disgusting behavior and tries to rally support for his cause on Hacker News.
Pretty embarrassing and deplorable behavior on the OP's part, all considered.
Terminal.app almost certainly does not do what you're describing by default.