plq

My point was that green threads sort of emulate OS threads so should not be treated any differently. As Python already has nice library-level support dealing with such thread-based concurrency, there's just nothing to do for the core language team to support this use case.

> 2. Green threads don't fragment the library ecosystem.

They do. That's why you need to monkeypatch everything.

Thing is -- you got two ways to do IO in an async world: Use the async system calls nothing less than the kernel provides or use threads to use blocking system calls and emulate async IO. There's no escaping that reality irrespective of the async paradigm you are using, green threads included.

> 3. Provide a better abstraction without extra code bloat.

From what I understand, your problem has always been the GIL, not Twisted. If your business logic is not better expressed in Twisted, you should not use Twisted, period.

For some of the code I need to deal with, Twisted's callback logic fits perfectly. It makes my code more testable and easier to reason about. So that's what I'm using. For anything else, I just deferToThread and use blocking code just like normal.

This said, I'd still like to emphasize one very important point:

Here's the secret sauce of gevent: https://github.com/python-greenlet/greenlet/blob/master/plat...

A sibling comment to yours explains briefly how Windows folks have given up trying to get green threads to work even with kernel support.

I do realize the average Python programmer couldn't care less about such low level stuff. However those of us who peeked under the hood of gevent and realized how many basic assumptions it violates stays far away from it.

Green threads are the GOTO of cooperative multitasking. In case you want to switch to "structured programming" from using GOTO-based code, you need to switch to the Twisted mindset.

The general sentiment in this thread seems to be that Guido et al "blessed" the Twisted way, it's a pity and now using asyncio and friends is the only way to suspend a Python stack in a concurrent program besides using OS-level threads.

This is not correct. Green threads, as a programming paradigm, are just a sub-optimal (but cheaper) way of doing preemptive multitasking. Yes, switch is explicit, but user code can't know what will switch. So you are not supposed to treat green threads any differently from OS threads. ie you still need your mutexes, semaphores etc. if you want to avoid race conditions. Again, that's because the caller doesn't know whether a function will yield execution to the next queued task at some point. Guido explains this point pretty well in one of his PyCon keynotes.

So green threads may be great but they don't bring anything new to the table.

However, Twisted-style concurrency (aka cooperative multitasking) is a different paradigm. In Twisted, you know that you only have one thread running at a time, so you actually don't need any thread synchronization primitives when accessing non-local state. This simplifies things a great deal. Yes, not having to spawn a thread for every single concurrent IO operation has other great benefits, but that's not the reason why CPython now has a blessed event loop -- it's cooperative-multitasking-the-paradigm.

Before asyncio, there was no standard way of doing cooperative multitasking. Now there is and it's baked right into the language. Use it if you like it. If not, the old ways of doing things work just fine in Python 3.

I'll admit that the concurrency model in Python 3.4 was not perfect. However, what we have with Python 3.5 and up looks quite polished.

IIRC people DID give fossil a chance but it turned out it could eat your data. So adoption stopped abruptly. Losing data is very difficult for someone who knows how to use git reflog.

I'd love to see some evidence to back your claims regarding mobile platforms.

To satisfy LGPL, your users need to be able to swap Qt versions. For desktop platforms, that's trivial to do: Use dynamic linking and your users will be able to fiddle with the shared library files to their heart's content.

However, for IOS or Android, the moment the user changes the contents of your package, your signature is void and the vanilla platforms don't let the user install modified versions of your binary. For IOS, there are additional hurdles like the requirement to statically link or the licence incompatiblility when interfacing with IOS which to me boils down to this: If you are distributing a non-free app built with Qt Open Source via Google's Play Store or Apple's App Store, you are in violation of the terms of Qt's license.

The fact that the Qt company tries to play nice with the industry doesn't make it any less so.

I'd love to be proven wrong, but I'm just tired of watching this subject being discussed with nothing more than handwavy arguments, winks and smileys.

Could that be rather because Qt 5.7 and later requires C++11?

The automotive industry is notorious for hating to change what already works, after all.

I can't help but wonder: What is roguelike?

Doesn't this mean the OSM repository will be used as a cache of the output of someone's version of some ml algorithm?

Why not distribute the data as well as the tagger and let the users tag the data themselves? This will give more freedom to the user and arguably lead to a better quality data (e.g. some additional tuning could give better results than the general case for a given region, which can be best performed by a team more familiar with that particual area) as way more eyeballs are now on the tagger itself, not just its output.

Might be a better organized coup attempt from the remain supporters :)

When one converts to Islam, it's customary to change his name but generally people hold on to their surnames. So I always thought of him as "Muhammet Ali Clay". This apparently wasn't the case with him. Too late to edit my post now...

This news item currently has 260 upvotes on hacker news.

Think about this a little. Think and try to name anybody else from boxing (or heck, any other sports) who could be up here. I know can't think of more than a few people.

He was the greatest in his time.

Rest in peace, Mr. Clay. You are among the icons of the 20th century.

Please explain to me: What happened to the philosophy behind http://csszengarden.com ? Back when CSS needed evangelizing, the main selling point was "never touch the DOM for styling".

What went wrong?

Of course a healthy dose of exercise is not harmful and the article reiterates this point many times. However, it also says that exercising may make your body more efficient, which lowers the overall energy that's used to keep us alive, which in turn may "hurt", to a certain extent, the weight loss rate.

When I was running regularly, I could see my heart rate go down day after day when I measured it right after I woke up.

Don't exercise to lose weight. Exercise to keep healthy. If you want to lose weight, you need to keep an eye on your calorie intake more than you keep an eye on the calories you burn. Not everybody can perform a 2000-calorie workout in one go.

There was a time when the only language with decent platform support had to have turing-complete meta-programming support, inheritance, polymorphism, lambdas, preprocessor, custom allocators, placement new, std::erase_if, etc, etc. because we were basically stuck with it.

Those times are now way behind us. Today, there is a plethora of languages to choose from, each with their strengths and weaknesses, each most powerful in the niche it's designed for.

Go is not a language with generics. If you need generics, don't use Go.

Go should not have generics unless it's trying to dominate the world. And we all know that no language can achieve world domination nowadays, not anymore. So it should rather trying to be the best language possible in the niche it was designed for. That niche doesn't need generics. On the contrary, a vocal part of the community says generics would taint Go.

Go doesn't have generics. It's however got a proper FFI. Use it. Or don't.

I always found SVG (plus the Inkscape CLI) to be the best interface for generating PDF documents.

I'm sure there are arguments in favour of libraries like this such as performance or better control but when all you need is to generate a simple invoice with a couple of dynamic fields, just use Inkscape to draw your template and your favourite XML library to put values in it in your code. When you need the PDF, use inkscape --export-pdf to get your PDF document.

SVG also makes it quite easy to show an in-browser preview of the generated document before performing the actual conversion, avoiding a costly PDF generation most of the time.

UPX is not magic -- it compresses machine code and makes sure unpacking code is run every time the executable is loaded. So if you only care about the size of the binaries in transit, don't use UPX, just use eg NSIS with lzma compression. You'll probably end up with a smaller package this way.

Yes, I was actually suprised that all graphs were going up :) Number of users increased -- great but ping times and packet loss should be at an all-time low now and these are the graphs that we want to see!

How is this "fixing the internet"? This is just good old network optimization. And a local one, not "internet-wide" by any means! Colossal undertaking, sure, kudos to Riot team for pulling it off. But... I don't see what makes this different.

I remember the Jill Price case. Turned out she was obsessively going over all her memories, non-stop, all the time. So hers was a normal brain, just trained very well to retain memories by unending repetition.

I just skimmed the article, but findings seem no different -- only more people are found to have this condition, and it actually has a sciencey name now: HSAM.

I wonder why BBC is running a story about this again?

> What happens when some of this old hardware breaks and it becomes not only impossible to find replacement parts but also impossible to fabricate new ones in house.

You get a modern Fortran compiler, you compile the old code for the new stuff and off you go. What am I missing?

> Eventually, like all languages, Fortran will die out as time goes on. So few people know it now that it is inevitable.

Like ALL languages? Ha, tell that to the COBOL programmers at the heart of some financial institutions mate. Heck, RPG is still supported on some IBM hardware.

I don't know you. I'm not remotely a VMWare customer, haven't even used VMWare Player.

It just warmed my heart that you and your team put your heart and soul to that product and loved every second of it. Thanks for doing all that hard work and doing it the way it's supposed to be done.

In the first year of grad school when I was trying to choose a field to delve in, real time rendering was one of the options. So I took the relevant CS-fivesomething class to see how things worked.

The first time I got my feet wet with code, I realized that the workflow was mostly "write and pray it works". No debugging tools, huge blobs of proprietary code and total lack of consensus among manufacturers even on the most basic stuff scared me away. I ended up doing a machine learning thesis instead.

This was almost ten years ago. I can't say I've been following the graphics field closely, but my impression is that while tooling came a long way in the past ten years, the GPU is still mostly a black box for the developers who don't have access to a debug build of the driver of the graphics hardware at hand.

Such initiatives couldn't come soon enough.

std::vector spec leaves quite a bit of performance-critical details unspecified. I imagine the allocator behaviour differs enough between implementations that they implemented their own to keep performance in different platforms more predictable. The performance requirements for a physics engine can be quite different from the general case that the std::vector spec is aiming for.

I imagine templates are frowned upon for the same reason -- too many moving parts. Otherwise they're perfectly fine to use in projects that have goals other than portably predictable performance.

I agree, the ll alias would be the first thing to change for me.

> I then remembered that when you put the window in the notification area or in the start-menu bar, Windows immediately reclaims unused/freed memory.

Wow. Is this a horrible hack or a wonder of the tight integration between the GUI and the kernel in an operating system designed to be used in a desktop? I'm torn :)

This family has apparently been doing a lot of things right from a business and operations management perspective. But their alloys are not "secret". It's actually never been a secret :) Production of cymbals is one of the lesser-known deep-rooted traditions in Istanbul.

http://www.aa.com.tr/en/culture-and-art/468267--holy-metal-i...

FWIW "Zildjian" is a mix of Turkish and Armenian. "Zilciyan" would be the Turkish spelling where "Zil" is cymbal or bell in Turkish, the -ci suffix adds a "seller-of" or "manufacturer-of" meaning and -yan == -ian, "descendant-of" in Armenian.

Actually, I'm more interested in when a GCC with this patch will be marked stable by one of the distros that I use.

> The issue with their ideas was that we weren’t facing a market problem. The customers were buying; they just weren’t buying our product. This was not a time to pivot.

A true gem, it's very important to make this distinction.

> You should first check if the compiler doesn't do it for you.

It probably doesn't, because otherwise Intel wouldn't have submitted this patch that adds computed goto support to CPython: http://permalink.gmane.org/gmane.comp.python.devel/153401

Well, commit logs could be good complement to developer documentation, if done properly. e.g. "See <some hash range> to see how to add a new protocol to Spyne!" "See <some hash range> to see how a new statement could be added to CPython!."

But, yes, if you care this much about commit format, put structured data in commit logs using yaml or something and be done with it :)

There are many open source projects who are basically one-man shows (SQLAlchemy springs to mind -- it recently reached 1.0 after 9 years of intensive hacking) which survive just fine. I agree that having an active community helps, but being the main author of an open source project myself, I feel that the real reason a project survives is because its authors' lives depend on it :)