U.S. Should Open America's Doors to Hong Kong's Citizens - <AUTHOR> https://www.bloomberg.com/opinion/articles/2020-05-27/trump-should-open-america-s-doors-to-hong-kong-s-citizens <comment><USER2> > it's easy to forget that many oppressed and subjugated people around the > world still look to the U.S. with hope

It's easy to forget because it's just a fairy tale Americans tell themselves. Oppressed and subjugated people flee to the nearest country that isn't the one oppressing them. Often that country is in fact China (from North Korea).

This article doesn't even pretend to be talking about saving oppressed and subjugated people though; it almost brags that the idea is for the US to cynically "benefit from the human capital that created [Hong Kong's] wealth".

The people this article is talking about - the "financial and creative genius" \- could walk into any country they wanted to, if they wanted to leave their home. They don't need the US.

<comment><USER3> Rich Western countries will for the most part, only accept the best and the brightest, refugee or not. People who under different circumstances, would still have been able to jump through the various hurdles to immigrate legally.

I read plenty of stories about the million plus people that have been afforded entry to Europe in the last few years. Yet there is very little in the English-language press about the millions more that have made their homes, for better or for worse, in neighbouring countries like Jordan, Lebanon and Turkey.

<comment><USER4> Best and brightest are wanted but that overlooks the millions of immigrants who are not so by qualifications and yet they still achieve success. So having these prequalifications is kind of silly. America's construction boom is fueled by immigrants as is most of Los Angeles restaurant scene.

</comment></comment></comment><comment><USER5> What would be the diplomatic consequences of this? I'm assuming China would be very unhappy with any country making this offer to Hong Kongers, but perhaps I'm wrong and they'd prefer for dissidents to leave.

<comment><USER6> Minimal real diplomatic consequences, other than China issuing some loud statements that they're furious at the US meddling in their internal affairs. It might amount to 100k-300k people as a max range.

It's an excellent opportunity for China to demonstrate the superiority of their system, as they so frequently claim.

We'll play a little game. Open immigration into China for US citizens. Open immigration into the US for Chinese citizens. Let's see who gets the most immigration (it'd be lopsided 1,000 to 1 with millions of immigrants flowing into the US; we did it with Cuba from ~1960-1980, there's no reason we can't do it for people wanting to flee China; if the next Democrat President is smart, they'll implement a variation of this to create a more aggressive and persistent brain drain on China).

<comment><USER7> The last thing we need is another Nixon moment of opening America to China. This has not proven to be in our best favor, aside from the multiple Chinese viruses that have floated our way; trade imbalance, current manipulation, gross human rights violations, IP theft, hacking, subversion of elections, oh gosh the list goes on. America must close the door on China.

</comment></comment></comment><comment><USER8> Add the UK to that list too.

<comment><USER9> Yes, perhaps they could come to the UK and protest against the way the British government allows its citizens to be extradited to the USA. The existing British population seems a bit too meek in that respect.

</comment></comment><comment><USER7> The United States should take the radical position that Taiwan is a country separate from China. Especially now, why is this not getting more attention?

<comment><USER10> China should take the radical position that Hawaii is a country separate from the US. Especially now, why is this not getting more attention?

Same logic as yours. But even more relevant as Taiwan (Formosa) was historically part of China, whereas Hawaii was a separate kingdom annexed by force by the US.

</comment></comment><comment><USER3> I think it's safe to say that in an election year and with everything else going on, the likelihood of this even being proposed is close to nil.

</comment><comment><USER11> Yes, let's provide as much cheap labor as possible in a time of record unemployment! What could go wrong?

<comment><AUTHOR> > _cheap labor_

This does not describe the Hong Kongers likely and able to emigrate.

<comment><USER12> yeah, even without considering who is likely and able to emigrate, HK median income is higher than the median income of some U.S. states.</comment></comment></comment>


Let's Toss for It - A Surprising Curb on Political Greed - <AUTHOR> http://www.constitution.org/elec/sortition_knag.htm

<comment><USER2> A fascinating idea, but I shudder to think what kind of randomness generator they'd use---too many people "trust the computer" and don't know anything about randomness (and have never even heard the term "pseudorandom").

Although, the mental image of robed justices and besuited representatives standing around a well-recorded table and solemnly rolling a d20 does have a certain appeal. :)

</comment><comment><USER3> For more technical details on the machinery that the ancient greeks used to select folks: [http://www.alamut.com/subj/artiface/deadMedia/agoraMuseum.ht...](http://www.alamut.com/subj/artiface/deadMedia/agoraMuseum.html)

From the OP article:

> _The pressures of party politics have ensured that, although the formal > mechanism remains the same, today's electors are bound by their party > mandate to vote for the party's candidates; hence, the outcome of the > election turns entirely on the party composition of the Electoral College._

In many states, it is against the law for an electoral college elector to vote for anyone other than the party that appointed them.

Disclaimer: I actually ran for elected office in 2008. While I came in dead last, I learned a lot and had a blast. In your local community, you will find that there are part time positions that you (hah! even you!) can run for. If there is an office you care about, then I recommend you learn what it takes and then run for office.

</comment><comment><USER4> I haven't been blown away by democracy's ability to build competent governments, and the self-selection biases are terrible. Hard to see how chance could be much worse.

<comment><USER5> "Democracy" (really small r republican government) is not designed so much to "build competent governments" but to solve nastier issues like the succession problem, the willingness of a current official to step down and allow his successor to replace him. You don't have to read very much history to see why solving this is critical.

I just don't see a coin toss conferring anywhere near the level of legitimacy needed for successions.</comment></comment>


Who is leading the 5G patent race? (Dec 2018) - <AUTHOR> https://www.iam-media.com/who-leading-5g-patent-race <comment><USER2> The whole "who is winning the X race?" meme where X is typically "5G" or "AI" is tiresome. Nobody can say that 5G or AI is going to create any value, but they can say that A is greater than B.</comment>


Elon Musk and the Cult of the Celebrity Savior - <AUTHOR> https://www.villagevoice.com/2018/07/13/elon-musk-and-the-cult-of-the-celebrity-savior/ <comment><USER2> Putting aside the issue of Elon Musk, this is the most interesting line to me: _The distribution of public goodwill is an economy not of labor but of attention._

I think a lot of us have experienced this in the context of tech support from Google or some other algorithmically driven giant; something goes wrong and the only recourse is Twitter. I really don't want to live in a world of arbitrary and unappealable actions by monopolists, with my only recourse being a social media appeal.

Yet that's the obvious trend.

<comment><USER3> Even HN is part of this phenomenon. Sometimes having a highly voted blog article complaining about poor customer experience or corporate malfeasance is the only way to get companies to respond.

<comment><USER4> Unsure why you got down-voted here, I've seen evidence of this (although not personally experienced it).

I'd guess any public area where people who are the companies customer visits, where you end up complaining in public, ends up being a possible place where this might happen. The only gripe I have with this trend is where people choose to go direct to social media vs the appropriate channels for support. The fear i have is that if enough people do this, normal support channels might get under resourced.

Having said this, i'm often impressed with the support i get when i ask for it. I rarely ask, but i probably should more often. A classic case of "you only get what you ask for", but a good reminder that you should probably be asking more often.

</comment></comment></comment><comment><USER5> [https://www.independent.co.uk/news/world/asia/thai-cave- resc...](https://www.independent.co.uk/news/world/asia/thai-cave-rescue-elon- musk-british-diver-vern-unsworth-twitter-pedo-a8448366.html)

this elon guy seems to have some psychological issues so better let him be a savior for just a minute, before he hurts anybody

<comment><USER6> And this comes just days after he said:

 _"I have made the mistaken assumption—and I will attempt to be better at this—of thinking that because somebody is on Twitter and is attacking me that it is open season," he said in an hour-long interview with Bloomberg Businessweek for this week 's cover story. "That is my mistake. I will correct it."_ [1]

My completely non-tech relatives in the UK asked if I'd heard of "that Tesla man", so I think he has damaged his and Tesla's reputation there. Hopefully the cave diver sues and donates the money somewhere worthy.

[1] [https://www.bloomberg.com/news/features/2018-07-13/-the- last...](https://www.bloomberg.com/news/features/2018-07-13/-the-last-bet-the- company-situation-q-amp-a-with-elon-musk)

</comment></comment><comment><USER7> It amazes me how many people seem to have bought into his cult of personality. Hopefully his recent pedophile outburst will give them some pause, and lead them to consider the long-term societal effects of worshipping corporate oligarchs.

</comment><comment><USER8> It's really interesting. The more remarkable successes Musk has, the more a certain large group of people and media organizations attack him. It almost makes you think they have some sort of hidden motivation.

<comment><USER9> You can be a hundred times a bigger a dick than Elon Musk and won't get a hundredth the publicity. Its all about clicks!</comment></comment>


Swiss Army Knives used in MacGyver episodes (2019) - <AUTHOR> https://www.macgyveronline.com/macgyververse/equipmenttech/saks-used-in-each-episode/ <comment><USER2> Check out the Victorinox Signature Lite - it's a very small keychain knife with a blade, scissors, pen (!), led light, nail file and screwdriver. It's not longer than a regular door key and very light. You won't even notice you are carrying it. I have had it with my keys for 10 years. [https://www.victorinox.com/global/en/Products/Swiss-Army- Kni...](https://www.victorinox.com/global/en/Products/Swiss-Army-Knives/Small- Pocket-Knives/Signature-Lite/p/0.6226)

<comment><USER3> I agree, the Victorinox Signature Lite is probably my allover favorite for light everyday carrying, and is my current one. Descending priorities: scissors, nail file, pen, knife blade, screwdriver, and flashlight. To add a Philips screwdriver, there's the Victorinox Midnite Manager.

I've carried many models of Victorinox, in a few different colors, and two models of keychain Leathermans.

I also carried a few of the Victorinox ones with USB flash drives, and made a multitool Linux distro for them: [https://www.neilvandyke.org/lildeb/](https://www.neilvandyke.org/lildeb/)

If you want a keychain multitool with pliers, the Leatherman Squirt PS4 is great. The corners of the Leatherman Micra destroyed my pockets, but the way the handles fold in that model means it's relatively better for keeping the blade from closing on your fingers if you're abusing it. These things are pretty tough, and I once used a Squirt in my fist to urgently hammer in the hinge pin of an old metal door

I occasionally pine for one of the Victorinox RescueTools, which can be used to rescue someone from a car, or to escape from one yourself. They're a bit big to carry around all day, and I don't have a practical need where I live. They're also expensive to lose, if you get forget to leave it at home before a flight.

<comment><USER4> If I may ask, did you mean that scissors and a nail file are the most important tools for you, or the other way round? Because, going by descending priorities, I would have listed these items almost in the reverse order :)

<comment><USER3> It's the closest I'll get to Crocodile Dundee rugged person shaving with a knife. :)

</comment></comment></comment></comment><comment><USER5> I was a big fan of Victorinox growing up but I find Leathermans more useful to have around because they have pliers and Philips screwdrivers built in. I've done various home repair and auto stuff with it, which I doubt a Victorinox would be capable of.

I picked up a Leatherman Wingman for $25 in Canada over a decade ago. It's less portable than a Swiss Army knife (about twice as big) but If I had to pick a one tool, it would be the Leatherman.

[https://www.leatherman.com/wingman-11.html](https://www.leatherman.com/wingman-11.html)

<comment><USER6> Not to contradict your opinion or the usefulness of Leathermans but I'll just point out that the Victorinox Swiss Champ has both pliers and a Philips screw driver.

Victorinox also make Leatherman style multitools. That must mean Leatherman are on to something though.

Personally I prefer a SAK because it's small and doesn't have a locking blade.

In many parts of the world simply having a locking blade in your pocket "without good reason"[2] will get you in trouble, whereas a SAK like a Swiss Champ is ok.

1\. [https://www.swissarmy.com/us/en/Products/Swiss-Army- Knives/M...](https://www.swissarmy.com/us/en/Products/Swiss-Army- Knives/Medium-Pocket-Knives/Swiss-Champ/p/1.6795)

2\. [https://www.gov.uk/buying-carrying-knives](https://www.gov.uk/buying- carrying-knives)

<comment><USER7> Regarding [2], I asked a copper in Liverpool about this. The passport office threatened to call the police when I turned up with a french folding-knife on my keychain. I was annoyed enough to go ask someone.

He said my reason of "I need it to cut the tomatoes for my sandwich" was good enough.

There's also the comment David Cameron made about that aspect of the law:

"Police must exercise common sense. This is about kitchen knives being stuffed down the front of tracksuits" [1]

But it does feel a bit like one of those laws that can be applied selectively to get people if the police really want to.

[https://police.community/topic/272735-jail-knife-carriers- sa...](https://police.community/topic/272735-jail-knife-carriers-says- cameron/)

<comment><USER6> Yeah you're taking a gamble on the good will of the police officer that searches you.

The way it was explained to me was, you take lock knife to and from a fishing trip but you can't divert to the local super market on the way. Interestingly your car counts as a public place so you can't just leave a Leatherman in the glovebox (either locker or unlocked) for emergencies.

A Swiss Army knife with a sub 3" friction folding blade won't break that rule. I think the only places you can't really take one are the airport or a football match.

You still can't wave one about like a nob but that's a different set of laws.

</comment></comment></comment></comment><comment><USER8> SAKs are the best example for an exercise in restraint. Buy one with too many features and you won't carry it everywhere with you, buy one with too little and you'll cover too few situations where it could be useful.

Buying a new one is for me a very calming experience as I get to contemplate how I spent the last few years and how my life over the coming years is going to change.

<comment><USER9> For my personal carry, the overarching question is: pliers, or no pliers.

For years and years, it was pliers. Last decade, no pliers.

When I had the pliers, I used them all. the. time.

But without them, I very seldom miss them. I don't have a good explanation for this, that's just how it is.

<comment><USER10> "I suppose it is tempting, if the only tool you have is a hammer, to treat everything as if it were a nail."

[https://en.m.wikipedia.org/wiki/Law_of_the_instrument](https://en.m.wikipedia.org/wiki/Law_of_the_instrument)

</comment></comment></comment><comment><USER3> I'm still amused by one Swiss army knife anedcote.

One place I worked as a software engineer, we had to carry lots of different physical keys (and, IIRC, a keycard), for getting among parts of the building, and even for going to the restroom. And a convention caught on of, when you sat down at a meeting, of putting your keyring on the table, so it didn't dig into your leg, ruin your trousers, etc.

One day, two representatives of a Swiss company fly in for a meeting. Management and key engineers walk into the conference room, me and this other engineer put our keychains with red Swiss army knives on them on the table. I don't think she or I realized it before we did it, but, if someone didn't know the convention, I suppose it looked like we were displaying our Swiss army knives specifically to honor our guests from Switzerland.

</comment><comment><USER11> I recommend the Victorinox cybertool or the swiss tool/swiss tool spirit if you want the best SAK for an engineer. I collect them.

<comment><USER12> My parents gifted me a Cyber Tool M for my first IT gig. Still on my desk and used almost daily 25 years/5 jobs later.

</comment></comment><comment><USER6> Shows how memory can play tricks on you. I haven't seen the show in years.

I just assumed the character always used a Swiss Champ as that used to be a sort of unofficial standard for mountain climbers going to places like Everest.

</comment><comment><USER13> I carry a Swiss+Tech multitool [https://www.amazon.com/gp/product/B001AY2WLU/](https://www.amazon.com/gp/product/B001AY2WLU/) . Its pliers acts as a keychain, and no blade means I can keep it through airports.

</comment><comment><USER14> Is there an actual plot point for Mac carrying around a random Swiss army knife from what seems like a collection to rival the actual Swiss army, or did the producers just choose the easy way to do it?

<comment><USER15> I don't see how using a huge number of different knives instead of reusing the same one every episode is "the easy way to do it".

<comment><USER14> I'm assuming they'd pick the knife based on what tools the plot requires Mac to have access to at any certain time.

</comment></comment></comment><comment> the-dude Carrying knives has been made illegal by our city council in our city center. I break that 'law' every day.

I carry a _Ranger_ with locking blade.

<comment><USER16> All knives, or a certain size of knife?

<comment> the-dude All knives, even craftsman who carry tools are officially violating this local 'law'. Several cities in NL have this.

</comment></comment></comment><comment><USER17> I still carry a Swiss Army Knife because of that show. And I still find some reason to use it almost every day.

</comment><comment><USER18> They made swiss army knives look disposable! Congrats!</comment>


Bpython is a fancy interface to the Python interpreter - <AUTHOR> http://bpython-interpreter.org/ <comment><USER2> I love that the website has an "Alternatives" section linking to competitors. That's not only classy, it also communicates confidence and inspires trust.

</comment><comment><USER3> Pycon lightning talk about bpython:

[http://www.youtube.com/watch?feature=player_detailpage&v...](http://www.youtube.com/watch?feature=player_detailpage&v=N4zdWLuSbV0#t=643s)

<comment><USER4> Starts at 10:45

</comment></comment><comment><USER5> I've used _bpython_ a lot in the past - mostly for it's instant syntax highlight and autocompletion, but I recently discovered _ipython qtconsole_ and I can say it's much better (yes, it's not in the console, but I'm ok with that). Its syntax highlighting is as good as bpython's, but allows me to use it like a text editor and go up a few lines, edit, execute. Bpython cannot do that.

Also, bpython is a bit buggy when it comes to pasting about a page worth of code/string. In the nice case the syntax highlight gets confused. In the not so nice - it becomes completely unusable, so that I have to kill it.

<comment><USER6> Yeah. And I use ipython's %ed command for that kind of long scripts (emacsclient as editor). Also really great feature.

</comment></comment><comment><USER7> Heh, The overall sentiment in irc freenode #python is a general dislike of ipython and a recommendation of bypthon as a good alternative to the REPL. It's a pretty light alternative but I still generally use ipython these days.

<comment><USER8> When I saw ipython for the first time I was really excited but now I realize I never actually use it. Any thoughts about why it isn't appreciated?

<comment><USER9> I think ipython is widely appreciated in the scientific/numeric python community.

<comment><USER10> This seems right to me. ipython also has some features that go way beyond enhancements to the REPL.

</comment></comment></comment></comment><comment><USER11> This is something I always loved about Python (as compared to other languages): There are several awesome interpreters available for it!

This one has a curses-based interactive GUI for docs and autocompletion.

IPython has this awesome qtconsole that can show matplotlib plots inline with the code. Then there is its HTML notebook which is probably awesome for presenting stuff.

Even IDLE is pretty cool, actually.

Is stuff like this available for other programming languages? I know Matlab has something vaguely similar to IPython and I think the IPython notebook is inspired by mathematica?

In comparison IRB seems really boring to me. Does Ruby have a cool interpreter? Perl? R?

<comment><USER12> > Does Ruby have a cool interpreter?

I don't know if it's cool, but I know of at least one alternative to irb: <http://pry.github.com/>

<comment><USER13> Pry is pretty cool. It adds some debugger-like features and editor integration, adds some convenient built-in commands, and improves on the UI in similar ways to bpython.

</comment></comment></comment><comment><USER14> I really like the "instant" auto-completion. Can someone throw light on how it was done?

<comment><USER15> The code that generates the completions [1] and displays them [2] is fairly simple. It uses a mix of scanning for a function's docstring, Python's built- in rlcompleter module [3] to generate the possible identifiers and keywords, its own module scanner for imports [4].

[1] [https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...](https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/repl.py#cl-583)

[2] [https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...](https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/cli.py#cl-409)

[3] <http://docs.python.org/library/rlcompleter.html>

[4] [https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/...](https://bitbucket.org/bobf/bpython/src/2b3fb2cb6500/bpython/importcompletion.py)

<comment><USER14> That's very useful. I wish shells like bash/zsh had this instant auto- completion!

</comment></comment></comment><comment><USER16> I've been aware of this for awhile but this prompted me to play with it. Killer feature for me: it can be easily installed inside a virtualenv. This is not (last I checked) possible with ipython.

<comment><USER17> I have had good experiences with ipython inside virtualenv, what's the problem?

<comment><USER16> Just that "pip install ipython" has never worked properly for me when I'm inside an virtuelenv. I just tried it and it worked, so maybe the problem was fixed in the year or two since I last tried it, or maybe I was broken but have been fixed in the last couple years...

<comment><USER18> You have to "easy_install readline" into your virtualenv along with "pip install ipython" to get ipython's control characters working (otherwise ipython outputs what looks like garbled text). readline is easy_install'd rather than pip'd to because easy_install'd libs end up at the head of sys.path.

<comment><USER19> i thought you only needed to do that on a mac, on linux it seems to work fine with pip install ipython

<comment><USER20> Yes, that's right. On Linux, you already have readline installed. But neither Macs nor IPython can ship with readline itself, because of the GPL, so by default you get the inferior libedit.

The Qt console doesn't require readline, but it does require Qt (and zeromq, and pygments).

</comment></comment></comment></comment></comment></comment><comment><USER6> Offtopic: with all these ipython/bpython's only thing that bugs me is need to do pip install -U ipython bpython (which downloads significant portion of bytes) in every virtualenv. I wonder if there's something like "pip install -U ipython --local-cache" option to copy existing ipython inside this virtualenv.

<comment><USER21> There is: [http://stackoverflow.com/questions/4806448/how-do-i- install-...](http://stackoverflow.com/questions/4806448/how-do-i-install-from- a-local-cache-with-pip)

<comment><USER6> Wow, thanks a lot! I wonder why it's not in default somewhere.

</comment></comment></comment><comment><USER22> This is really nice, but if you use vim you can use ScreenShell, which lets you execute parts of your buffer in a python interpreter (also works with lisp and any other language with a REPL). So you already have syntax coloring, completion, tags, etc.

</comment><comment><USER23> FYI for Windows users..."pip install bpython" won't work. You must install the Curses binary. I suggest from here: <http://www.lfd.uci.edu/~gohlke/pythonlibs/#curses>

<comment><USER24> I didn't know about this - we actually have a GTK version that needs some tidying up and packaging before we actually release it (if anyone is interested in helping with this that would be great as none of us use Windows - see the bpython website for details on how to get involved).

Could you possibly drop me an email or get me on IRC (again, see website for details) to let me know how this curses binary works on Windows ? It'd be great to add some documentation to the bpython site on this.

</comment></comment><comment><USER25> I installed bpython, but found it to be much more CPU intensive than ipython, for working on small machines (like a raspberry pi). Of course it's not a problem if you have a reasonnably decent hardware.

Edit: setting auto_display_list to False in ~/.bpython/config (not XDG compliant directory :( ) helps a lot. You can then use completion only when you need it.

</comment><comment><USER26> This looks very nice, but you'll notice the Arabic unicode sample is rendering left-to-right, as almost all terminals currently are. I haven't seen any terminal beyond right-to-left specific ones that support proper Arabic yet :/

<comment><USER27> You're complainimg to the wrong audience.

I rarely need Arabic bidi support in a shell, and if I do, I tend to copy paste from a proper text editor.

<comment><USER26> Yes, I agree but I don't do any Arabic editing in terminal. The only time I bump up against this problem is when in Arabic IRC channels with irssi, and all the letters are separated and backwards. I usually switch to IRCCloud's web IRC when I'm chatting in Arabic channels anyways.

<comment><USER2> Over at Konversation, we implemented our bidi text behavior with the help of KDE's Arabic and Hebrew translators. Not only do we render the words correctly RTL, we also switch the overall directionality of the line based on the implied direction of the majority of characters within it, i.e. a line containing predominantly Arabic will be aligned to the right of the window with the nickname to the right of the message. This makes it rather pleasant to use for Arabic channels.

Edit: And I should mention that to my knowledge, KDE's terminal emulator Konsole will render Arabic text correctly as well. However irssi would need to do the alignment part.

</comment></comment></comment></comment><comment> cool-RR What would make me use this is a way to get Django to use it when you launch `manage.py shell`, similarly to ipython.

One advantage over ipython I see here is that it doesn't use sqlite (I think), so it might run on Heroku.

<comment> cool-RR Update: Django uses `bpython` by default if `ipython` isn't installed! Woohoo!

<comment><USER24> Yeah, I don't use Django so I never did this myself, but somebody kindly did the work for us. :)

</comment></comment></comment><comment><USER28> using bpython has encouraged me to write more docstrings, which I previously did not do so much for personal projects ...

(because they are right there in the interpreter)

</comment><comment><USER29> is there a good emacs-mode for python that gives interactive development of the same level as inferior-lisp[1]? the python-modes i've seen only let you re-execute a file, but not a buffer or expression.

inferior-lisp makes all the problems bpython is trying to solve, irrelevant.

[1] example: <http://vimeo.com/22798433> (4 mins)

<comment><USER30> I patched python-mode to do this (also did something similar for node and a few other interpreters). Main thing is to add a "py-execute-line" routine and a few others as wrappers around the file execution code. If there's interest, might post as open source.

EDIT: here is a snippet

      (defun py-execute-line (&optional async)
        "Send the current line to the inferior python process using py-execute-region."
        (interactive "P")
        (save-excursion
          (end-of-line)
          (let ((end (point)))
            (beginning-of-line)
            (py-execute-region (point) end async)))
      )

That's the py-execute-line function, which is sending code to py-execute- region defined in python-mode ([http://bazaar.launchpad.net/~python-mode- devs/python-mode/py...](http://bazaar.launchpad.net/~python-mode-devs/python- mode/python-mode/view/head:/python-mode.el#L7828)).

For some reason the default python mode in emacs is python.el rather than python-mode.el. So you probably want to start by using python-mode.

</comment></comment><comment><USER31> Does BPython play nice with matplotlib/pylab yet? Last time I was very impressed with its functionality, but I could get it to draw a graph properly.

Fortunately, IPython, especially with the new --qtconsole, is also very _very_ good.

</comment><comment><USER32> I'll switch to bpython when it gets all the readline shortcuts that I use without even thinking (like alt-b, alt-f, alt-backspace, ctrl-c, etc.).

<comment><USER24> The worst thing is it's been at least two years since somebody first asked about this and we still haven't done it, even though it's really, really easy. :) I'll try to get this done soon if anybody is willing.

</comment></comment><comment><USER33> I really like this: Add "import bpdb; bpdb.set_trace()" to your code, and from pdb type 'B' to drop into bpython.

</comment><comment><USER34> Hmm, not bad. Actually, not bad at all. Very intuitive. I wish you could change the theme color though.

<comment><USER3> Yes you can change the colors. <http://docs.bpython- interpreter.org/themes.html>

<comment><USER35> There doesn't seem to be a color theme that works with a standard black on white xterm. All of the defaults seem to be designed for Windows' white on black... Even defining 'prompt = k' (where 'k' is black) produces a nearly invisible grey prompt. Thanks but no thanks, I'll stick with vi/vim.

<comment><USER36> Terminals have had a black background since monitors first appeared. This makes sense because a monitor bombards you with light and having a black background minimizes the amount of light you're exposed to, and thus fatigue (looking into a monitor is essentially looking into a lamp). I suppose the first window managers later reversed this with white as the default background; perhaps this has to do with the idea of a desktop metaphor where white backgrounds mirror the typical color of paper, who knows.

Note that the tradition is not white on black, but gray on black, because the former has too much contrast which gives it a kind of afterglow effect. Monochrome monitors used to support only a single color, such as blue, orange or green. That's why green on black now has (IMHO silly) "retro" connotations.

</comment></comment></comment></comment><comment><USER37> This is nice for just exploring Python (and modules).

</comment><comment><USER38> this is awesome.

<comment><USER39> just got me ipython (a ~few minutes back), and bpython (like a ~minute back), and this feels damn awesome! I mean bpython!</comment></comment>


Samsung Power Outage Kills 3.5% Of Global Flash For March - <AUTHOR> http://www.tomshardware.com/news/samsung-power-outage-flash-pyeongtaek,36670.html <comment><USER2> Numbers are a little suspect. Capacity is 120k, and they say up to 60k damaged? Inventory being what it is, they're doing great if they have half the wafers in process at any given time. So if there's a power bump, 60k is an absolute maximum. Furthermore, almost none of these lots are a dead loss. The ones in diffusion furnaces and wet hoods are likely 100% scrap, but CMP, CVD, implant, and dry etch mostly process one wafer at a time. Some of the wafers may be dusted by vacuum loss, but that's usually recoverable. Most photo layers give you redos -- strip off the resist and try again. I'd estimate the actual scrap from this event at no more than 10k wafers. The rest will be delayed production, but not a dead loss.

Edit: oops, I left out metals and test. Metals is a chamber process, wafers in process will be killed but unlikely it's the whole lot. You can lose wafers at test if they're in burn-in or being lasered.

Edit: I confused capacity and monthly output. My numbers are probably 3-4x low in terms of total impact on production, although they're likely reasonable in terms of their effect on one month's worth of output. 60k still seems like an overstatement.

<comment><USER3> The numbers aren't suspect, the journalist just segued into a second topic without being clear.

The outage happened at the Pyeongtaek plant, which according to Wikipedia has capacity of 450,000 chips per month[1]. Making the maximum estimated damage only 13% of monthly production capacity, not 50%.

The Xi'an plant is a completely different plan, which is beginning an expansion at the end of the month that should add 200k/month of additional capacity at that plant. Nifty fact, but not immediately relevant to the outage that happened.

[1] [https://en.wikipedia.org/wiki/List_of_semiconductor_fabricat...](https://en.wikipedia.org/wiki/List_of_semiconductor_fabrication_plants)

<comment><USER2> Ah, good point, I was confusing capacity with monthly output. 3-4x sounds about right.

</comment></comment></comment><comment><USER4> A 30-minute downtime? I'm surprised there's no mention of backup generator capacity. I assumed this is a requirement for all fabs?</comment>


Moving to Australia as a progressive in 2016 - <AUTHOR> https://puzzling.org/politics-and-society/2016/11/moving-to-australia-as-a-progressive-in-2016-introduction/ <comment><USER2> Don't do it - Australia is not looking much better right now, or in the foreseeable future.

I am an Australian.

If you want to move somewhere progressive, look at New Zealand.</comment>


5 Attributes of Highly Effective Programmers - <AUTHOR> http://www.philosophicalgeek.com/2008/01/20/5-attributes-of-highly-effective-programmers/ <comment><USER2> I thought there were only 3, and they were Laziness, Impatience and Hubris. Damn. I've clearly been going about this "programming" thing the wrong way...

</comment><comment><USER3> \- Humility

\- Love of Learning

\- Detail-orientedness

\- Adaptability

\- Passion</comment>


Uber is tracking its drivers in China, will fire anyone attending taxi protests - <AUTHOR> http://www.theverge.com/2015/6/14/8778111/uber-threatens-to-fire-drivers-attending-protests-in-china

<comment><USER2> Here's an excerpt from the original Wall Street Journal article that this article is based on:[1]

`` _In two short messages sent to Uber drivers in Hangzhou and circulated online—verified with Uber in China by The Wall Street Journal—Uber urged its drivers not to go the scene and instructed those already there to leave immediately. Uber said it would use GPS to identify drivers that had refused to leave the location and cancel its contracts with them.

The messages said Uber's actions were designed to "maintain social order."

In a statement issued Saturday, Uber also said one Uber driver involved in an incident during Friday's confrontation was licensed and had cooperated with the Hangzhou authorities. The company was strongly against any extreme behavior that could affect harmony and stability, the statement added._``

"Maintain social order"? "Extreme behavior that could affect harmony and stability"? Those sound exactly like words that we'd expect to be hearing from China's authoritarian government, not from an American company.

[1] [http://www.wsj.com/articles/uber-orders-drivers-in-china- to-...](http://www.wsj.com/articles/uber-orders-drivers-in-china-to-steer- clear-of-taxi-protests-1434181092) [paywalled, available via Google search]

</comment><comment><USER3> > The company reportedly said in messages to its drivers that it will use GPS > coordinates to determine if drivers are attending the protests, which have > been sparked by the rise of illegal competition for taxi drivers. Uber's > harsh stance, the company says, is designed to "maintain social order."

It feels like Uber is ultimately less about rides and more about tracking and control.

</comment><comment><USER4> I never used Uber, but I will be boycotting them intentionally after this.</comment>


HTML to CMS - <AUTHOR> http://vemo.me

<comment><AUTHOR> For a test drive : [http://vemo.me/html2cms](http://vemo.me/html2cms)

</comment><comment><AUTHOR> This platform will take 70% of valid HTML5 templates and will convert it to a super easy CMS just like that..</comment>


Ask HN: How do I practice being compassionate? - <AUTHOR> I just saw the movie 'A Beautiful Day in the Neighborhood' and really want to be more like Mr. Rogers. Personable, warm, and compassionate. I'm 36 now and some traits are no longer easy to change, what can I do to change and head that direction? <comment><USER2> I think that an important precursor to being compassionate is the ability to sense what others might be going through and wanting to help. The fact that you were moved by the film (which I haven't watched btw) and want to be more like Mr. Rogers is an indication that the precursor exists.

Other than that, we often strive for bigger changes that we can make. Instead, we must start with our immediate circle and always keep an open eye for what we can do to help this very minute in our family, neighbourhood, work or friend circle.

Anything counts - from fixing someones computer or helping them with taxes to just catching up with someone for coffee and hearing them out about the difficult ordeal they are going through.

</comment><comment><USER3> Read this book: The Art of Happiness, 10th Anniversary Edition: A Handbook for Living

Buddhism is almost by definition compassion.

<comment><AUTHOR> Thanks will check it out

</comment></comment><comment><USER4> Mr. Rogers was a Presbyterian minister. His ministry field was literally his TV program. It was flowing out of his Christianity.

I'm not sure to what degree you can be like him without that foundation.

</comment><comment><USER5> Pema Chodron's books are a great source of wisdom about compassion. I would suggest practice having compassion for yourself first. Compassion for others will flow directly from that.

<comment><AUTHOR> Thanks will check it out

</comment></comment><comment><USER6> Non-Violent Communication is quite useful.</comment>


A note of reflection after 10 years of "A successful Git branching model" - <AUTHOR> https://nvie.com/posts/a-successful-git-branching-model/ <comment><USER2> I tried using Gitflow on our team, but there was too much complexity for me. We ended up switching to Trunk Based Development (TBD)[1] which I and my team found to be much simpler.

[1] [https://trunkbaseddevelopment.com/](https://trunkbaseddevelopment.com/)

<comment><USER3> Same here. Trunk based is easy to explain and enforce.

The only challenge we faced was maintaining patch releases. Folding in fixes for common issues which were found in newer releases sometimes involved more than just cherrypicking the fix into a patch release for an older version.

This inevitably led to asking users to update to more up-to-date versions. This further enforced the linear development paradigm.

<comment><USER4> This is the one thing that I find lacking in trunk-based development. I work on multiple products that have a release branch for each minor release, and it works incredibly well other than this as a minor pain point.

I find the easiest way is that if you _know_ you want (or even think you might want) a particular fix in a patch version, you can make a branch _from_ the oldest release branch you want to support. When you create a PR, you can easily target to the release branch (or another later release branch) or master, depending on what you want. You can even do multiple PRs to merge it multiple places.

No matter how you go about it, it should always be safe to merge a release branch back into master. In fact, this is a good thing to do after you release a patch version, but can also be done whenever you need a particular fix in newer (master, or other feature branch code) code immediately.

Merging release branches like this makes following a fix significantly easier than if you do it with cherry picking. Consider if you're looking at bug ticket, and trying to figure out what branches/releases it was fixed in. If the PR was merged to master, then later cherry picked to an older release, all you'll see is it was in master. Unless someone manually comments about it or your tooling picks it up based on references, the only other thing to do is check the code itself to see if the fix is there. When you instead merge forward, even if the ticket comments are wrong or not there, you can literally follow the branches from the PR/commits and see every release it got into.

<comment><USER5> > Unless someone manually comments about it or your tooling picks it up based > on references.

I don't find this to be overly burdensome on the tooling. If the ticket- tracking system can't automate traceability between git commits and tickets, then it isn't well-suited to git-based software development.

We use the following policy:

\- A bugfix commit must fix the bug, the whole bug, and nothing but the bug. If that seems impractical for the task at hand, make it practical by breaking up the bug's ticket into smaller elements.

\- Bugfix commits always cite the bug tracking system's ticket number.

\- The bug tracking system observes the git tree and maintains its own linkage to it.

\- When cherry-picking the bugfix to other affected branches, pass the `-x` argument to `git cherry-pick`.

That's it. The (cherry-picked from) comment helps out when just viewing the git history on its own. And the bug tracking system lets you quickly see all of the commits and pull requests that referred to the bug.

</comment></comment></comment></comment><comment><USER6> Reading the comments, I realize I'm a git neophyte (limited experience working on some open source software, didn't know "gitflow" was a thing) so excuse me for my naive question. But what about this simple workflow. Developers submit PR on top of a master branch (developer is in charge of rebasing, PR must pass integration test). Administrator is in charge of merging, maintains a linear history. Releases are just tags on master. Has this workflow a name? anything wrong with it?

<comment><USER7> the risk of this workflow is that PRs will languish for too long, and the work required to rebase them when they're actually needed will cause friction and mistakes. this will often manifest when your software reaches a certain level of maturity and you have established a release model that distinguishes between a release that includes only bugfixes and a release that introduces new features.

you definitely want to get your PRs merged in to _something_ as soon as they are complete, to avoid bitrot. but just because they're complete doesn't mean you want them included in the next release.

<comment><USER8> You can merge master/develop into your PR multiple times, always keeping it up to date with the latest until until it can be merged.

This is the magic of git, it allows multiple merges something that wasn't possible in older systems.

<comment><USER9> That is what I do too. Combined with restriction on the pull request so you can't merge it if it's behind the branch you are merging onto.

</comment></comment></comment></comment><comment><USER10> Is this related to the "Please stop recommending Gitflow" [1] article posted yesterday?

[1] [https://news.ycombinator.com/item?id=22485489](https://news.ycombinator.com/item?id=22485489)

<comment><USER11> Kind of, that article recommends making things less complex if you do continuous delivery to a SaaS.

The update article mentions it was meant for versioned software.

I tried to articulate the various levels of branching you need in GitLab Flow [https://docs.gitlab.com/ee/topics/gitlab_flow.html](https://docs.gitlab.com/ee/topics/gitlab_flow.html) The various levels are: feature branches, production branches, environment branches, and release branches.

<comment><USER12> Sounds like gitlab tried to fix githubflow instead of realising its fundamentally broken and going with the gerrit pattern that works fine for both trunk based and release style applications.

<comment><USER11> We offer multiple options that depend on your need. GitHub flow and Git flow are at two ends but there are also intermediate steps.

</comment></comment></comment></comment><comment><USER13> We started with gitflow, but our team ended up going with a Release based branching system as the constant integration of various features ended up giving less control on what to deploy and when. Most common scenario...

Devs create feature branches from master

Features will be targeted to a release at some point, Release branch gets taken from master

Devs PR feature branches to the release branch

Release branch merges back to master on deployment.

<comment><USER14> that workflow has always been my preference. QA can review features in batches, you can schedule releases to minimize impact, and several eyes are on the release to catch possible bugs.

</comment></comment><comment><USER15> A problem with GitFlow is it's painful to follow PR model.

Especially on the Github repository where pushing to master is a lock and can only done by PR and merge(or squash or whatever).

Let's take a look at a release:

1\. Branch of release/1.0 from develop 2\. Fix some bug, then at the time of deploymennt. Merge it back to master _and_ develop

But once we merge, github close the PR... If we attempt to create another PR for other branch. The Github now see different history between master/develop...

<comment><USER16> There exist scripts and workflows to perform auto-merges from all release branches back to master. This way, you only have to care about branching off releases, and hotfixes will automatically land on develop once released.

(Assuming master is your "next release", and develop is your main development branch)

<comment><USER15> Like I said, I cannot merge because we cannot push from our computer to Github(It's locked).

The only way to get code into branch is by doing a PR, and click merge button on Github UI. But a PR cannot be merged twice.

And If I open two PRs two master/develop then I will see this kind of error on Github: "This branch is 1 commit behind. 1 commit ahead of develop"

<comment><USER16> the way to go here is probably creating an "administrator" account which is used by those merging scripts, and allow push access to protected branches for administrators.

<comment><USER17> So, on my team, juniors can create feature branches and easily deploy a feature branch to a 'staging' server.

If the feature is deemed good, an 'admin' will 'finish' the feature and it is merged into develop branch.

Then, when we are ready for a release, the 'admin' will create a release and both develop and master are updated.

Updating master triggers a webhook that deploys the release.

For a hotfix, the release step is skipped, but both develop and master are updated, again causing the webhook to trigger a deployment.

</comment></comment></comment></comment></comment><comment><USER18> I've yet to work on a codebase that was so congested it required such strong delineation between feature/hotfix/release but I can see how it might be required at a certain size. I wonder what that threshold is.

<comment><USER19> It depends what you're working on. We have a fairly small team (7 engineers) working on a reasonably complex app (many features).

Our "features" take anything from 1 day to 3 weeks of effort, and generally need to roll out as a whole. They are often really upgrades of existing features, and the work to continuously merge w/ feature flags, supporting both flows/designs, is just not something we've felt was worth the extra time.

We release on a 2 week cycle, the same day each time. We merge our features into the develop branch as they are ready and safe for production.

Our scheduled release day is Wednesday. The Thursday beforehand, we branch from develop into a release/x.y.0. This builds release candidates. We have a sanity check on Friday, then our remote QA team runs through them over the weekend. Any issues they find, we try to have squared away by Monday, Tuesday at the latest.

Meanwhile other team members are still merging new things into develop. It's useful to have that release branch because it lets the rest of the team keep moving - we maybe only put out 1 or 2 developer's features each cycle, the rest are still trickling in.

Once we release, we tag, merge into master, and start over again. If any issues show up on production, we use the hotfix branch, hotfix/x.y.z. That let's us resolve issues with risking a ship of any of the changes that have come into develop that haven't had a few days of stability behind it.

For our team scale, we have a lot of users (100k's DAU), and we find this method is a nice balance between the pace of output you might get from true CI but with the reliability of a more traditional cycle.

Backend and web projects, however... Straight CI, into master, and we roll out test > staging > production when we're happy.

<comment><USER18> I basically follow the same protocol as you up to this point:

> Once we release, we tag, merge into master, and start over again. If any > issues show up on production, we use the hotfix branch, hotfix/x.y.z. That > let's us resolve issues with risking a ship of any of the changes that have > come into develop that haven't had a few days of stability behind it.

In our case, there's no point in a hotfix branch because master is always considered stable. You don't merge to master unless you're ready for that code to hit production. Feature gates are used for hiding live code when necessary for marketing announcements or if the feature simply isn't ready for actual customer usage yet (sometimes we leave the endpoints live but turn off all the navigation to the endpoint so we can send out the link as a "beta" test for specific customers).

This does occasionally cause problems with feature branches lagging behind, but it's on the developer to ensure that their code merges into master smoothly (usually best done by syncing your feature branch back up to master frequently)

</comment></comment></comment><comment><USER20> It all depends on the situation. The simplest possible situation of mostly just having a master branch also can work quite well. When you have specialized testers that test a candidate release you start to need release branches. Feature branches start being necessary if changes are temoprarily incompatible with current master. This should not be too common, though. In many cases one can avoid feature branches by having feature switches that get removed as soon as a feature is done. If one wants to or needs to use feature branches they should be short-lived because one will be creating a merge hell if this is not the case. The git flow seems just too complicated for most cases. One comment already notices that it is quite unclear why a separate development and master branch are necessary.

</comment><comment><USER21> I love this branching model. I have being used in all projects and teams I can. I use it even in projects where I work alone. For me it is the ultimate branching model.

<comment><USER22> Same for me, I see many comments about this not being ideal for scalable projects or Saas, but in my experience gitflow has worked well even for maintaining pcb design repositories!

<comment><USER21> For me it is being super good in scalable projects, and together with well oiled CICD pipelines.

</comment></comment></comment><comment><USER23> AFAICT Gitflow just has one more branch than it needs. If you got rid of the master branch and supported production releases off release branches it would be just as useful and significantly less complicated. Can anyone explain to me what real value the master branch adds in this model? And without using fluffy meaningless words like, "source of truth," please.

<comment><USER24> I don't really understand the distinction between develop and master either. You're supposed to branch off develop and merge forward back into develop, then merge into a release branch, then merge into master. So everything in develop is supposed to end up in master.

So... why not branch off master and merge back into master?

<comment><USER25> There is a small trade secret, that's hard to visualize. If you merge two changes into master you can break it.

The fact that a change passed a CI and another change passed a CI doesn't mean they can merge and the result is guaranteed to pass CI. It will often break and if you think for a minute you will come up with really rudimentary examples of this.

The really primitive solution is to call the merge-recipient branch the "develop" and only merge to "master" when you are sure what you are merging is good. You'll be ok if you do it sequentially (no parallel merges to master).

A more complicated solution is to actually test (in CI) "what happens when I merge this" but in hiding, without showing it to others. Even more complicated is to do it in parallel. Gitlab calls it Merge Trains (Premium only). Zuul-CI calls it gate/gating and has a pretty good description here: [https://zuul- ci.org/docs/zuul/discussion/gating.html#testing...](https://zuul- ci.org/docs/zuul/discussion/gating.html#testing-in-parallel)

<comment><USER26> Also known as the "Not Rocket Science" rule: [https://graydon2.dreamwidth.org/1597.html](https://graydon2.dreamwidth.org/1597.html)

When you're ready to merge, have CI test the result of the merge, and only push the merge commit if things pass. Don't let anyone other than CI push to master.

You can set up a bot with a queue to do this, of course, but you can also define "CI" as a shell script. GitHub, GitLab, etc. will automatically close a pull request if you push to master; you don't have to push the button on the website. Train people to not hit "merge" and instead to run a script, something like this which I just threw together:

        #!/bin/sh -e
        repo="$(mktemp -d)"
        git clone https://... "$repo"
        cd "$repo"
        git merge "$1"
        make test
        git push
        cd
        rm -rf "$repo"

If tests fail, it'll abort at "make test". If someone else pushed something, it'll abort at "git push" and you can just rerun the command, which will test the result of the latest merge. If you retry a lot, it's a sign your team is busy enough you should invest in setting up a real bot - not a sign that you should forego this property and land untested things on the develop branch and make yourselves deal with doing development on top of untested code.

<comment><USER25> I don't like the article - too many words, too many digressions. Also the chosen catch-phrase is poor.

As long as GitHub does it wrong, you won't be able to "train people" not to hit the big juicy green button, that should be really a big red "Emergency Merge - Can Break The Receiving Branch" button.

</comment></comment></comment></comment></comment><comment><USER27> I have never succeeded in working in a branch and having the real owners accept my state.

I am of course talking about 'outsider' changes to code, but the effect is real: the master owner can elect to say "sorry, we decided to re-architect significantly and what you did is now superfluous, or at least too hard for us to re-integrate" and almost everything I have been involved with, this is what happened.

Submitting small patches to their head state is more effective for me than trying to maintain state against a moving target with a realistic chance of making significant change, and having it accepted into the mainline.

</comment><comment><AUTHOR> Strongly agreed with the new author note. I used the same ideas with the teams I've been coaching: "Consider your context...." as the need or not of support for multiple versions and "...Decide for yourself.

</comment><comment><USER28> I accept your apology.

History is for reading, not writing. Do we make decisions that give us readable and informative histories? The people who give up and rebase absolutely everything into one linear trunk are not working optimally, but at least they're trying.

</comment><comment><USER29> So cool that something Linus Torvalds made to solve his own problems, spread all around the world so quickly. I guess great dev tools can only be made by great developers, who have been through a lot of scenarios/problems themselves.

<comment><USER30> Don't neglect to give enough credit to BitKeeper, the DVCS some kernel folks used before and whose design in broad strokes was cloned by Linus.

<comment><USER31> Or even further back: BitKeeper was a successor to an earlier DVCS from the early 1990s, Sun Workshop TeamWare. Everything old is new again.</comment></comment></comment>