vilya

Great explanation! I think you just made a few things about Rust click for me. Thanks!

QtCreator is brilliant, I just wish the Qt company would stop trying to hide it away! It's getting harder and harder to find the download link on their website.

Is anyone out there working to automate middle management?

You can drill down in Diskitude by right clicking. I agree it's not as nice as Daisy Disk, but it's the best I've found for Windows (for my tastes) and you can't beat the price...

Gosh there are a lot of these programs, aren't there?

For some reason I find it really hard to read these tree map visualisations. I know the theory and all that, but for me they just aren't an intuitive way of displaying that kind of information. For me a radial graph (i.e. pie chart like) is much easier to grok - I don't even have to think about it, I just get it. Seems like there must be plenty of people who don't think the same way though, given how many different tree map disk viewers there are out there!

For what it's worth I use Diskitude (http://madebyevan.com/diskitude/) on Windows and Daisy Disk (https://daisydiskapp.com/) on Mac. Both are great!

Interesting! What would you say makes it better than the others? I'm working on something similar but as-yet-unannounced and I'd love to know if we're tackling the right problems...

Maybe the effort just isn't where you're looking? Intel provides the Threading Building Blocks library for C++; some top notch debugging & profiling tools with multi-threading support; very good documentation; and they do quite a bit of community outreach to educate about and promote multi-threaded programming. (I'm not affiliated with them, just grateful for all of that stuff!)

In an incorrect sense, yes. :-)

SIMD = Single Instruction Multiple Data, meaning the same instruction being applied to multiple different values simultaneously. That's exactly what GPUs do.

The important difference is that not everything in Unreal is GC'd, only UObjects. Internally the rendering, animation, networking and other high-performance subsystems don't use GC because they can't afford the overhead. Being able to opt in to GC where it's useful is great, being forced to use it everywhere can be a hassle.

I really wish the Qt Company would stop bundling QtCreator as a required component of the Qt SDK.

I use QtCreator as my main IDE & think it's great, so of course I install new versions as soon as they become available. I compile & test against several different versions of Qt though and every single one of them lumbers me with an additional out-of-date copy of my IDE. This bugs me - more than it probably should.

> I have long wanted to see programmers experiment with taking this IDE thing much further. Almost every other authoring tool has an opaque file format, manipulated via one or more views. E.g. when a digital artist wants to create and manage a complex 3D scene, they use a tool like Maya. They're not fussed about whether they can read the file format!

Interesting choice of example, because over the last few years open formats like Pixar's USD (https://graphics.pixar.com/usd/docs/index.html) have been emerging for managing complex 3D scenes - precisely because of problems with opaque file formats.

That said, we're now seeing more and more things like Unreal Engine's Blueprints, Apple's "Swift Playgrounds" and so on. I think your wish is slowly coming true.

It's so the scanner operators can tell there's nothing hidden underneath your laptop. I'm not sure whether the laptop case (or just the battery?) can actually block the scanners, or it just makes the output image harder to interpret. Either way, I guess they want to be sure...

I think that was true back when he wrote the words, but less so now. Even if you're not noticing a delay, code that completes quicker is generally code that uses less power and you can still notice the effect on your phones battery life - or on the size of your monthly bill from your data center.

All of you complaining about this proposal not being based on Vulkan seem to be overlooking the fact that Vulkan is actually quite cumbersome to use. Metal, on the other hand, is a really well designed API and in my opinion strikes just the right balance between performance and usability. If it was available for non-Mac platforms too, it would be my first choice of graphics API every time. So for me, a cross platform web graphics API based on Metal is really quite an exciting prospect - much more so than one based on Vulkan - and I applaud Apple for proposing it.

Exactly.

Same with %: since we're talking about a number-like object, there's a clear and expected meaning for it and that is NOT cross product.

I've recently had to deal with some code that did this for work (and also used operator* for dot product) and it made the equations incredibly difficult to read. Please don't make the mistake of doing this in your own code.

The term you're looking for here is a depth matte. It's a technique that's been in use for many years now, but of course it's only as reliable as your depth data so it's just one of the many tools in a compositor's tool belt.

Doesn't it bother you that you can provide the same value to your employer as someone in Brisbane, but only get paid a fraction as much for it merely because you're in Sri Lanka?

I'm a remote worker too (and I'm very happy with the way my current employer handles it). As long as I'm available at the times and places my employer needs me to be, why should they have any say in where I live or how I spend my money? I want to be able to manage my quality of life myself, not have it decided for me by someone else!

I like that you guys are being open about this, but the way you calculate compensation leaves a pretty bad taste in my mouth. I very much dislike the idea that you, as an employer, are deciding what proportion of their income your employees should be spending on rent. You're also effectively saying that work done by someone who lives in a cheaper location is less valuable to the company than the same work done by someone who lives in a more expensive location. Maybe all employers do this and the only difference is that you guys are being honest about it, but still... yuck.

> It's hard to refute directly because there isn't any motivation or reasoning presented, only prescriptions (the author cites their "experience" in comments), so the best I can do is point out that most of it is really bad advice.

If you want to refute it, why not say what you think is wrong with each of the prescriptions instead of just saying "most of it is bad"?

Personally I agree with most of the prescriptions but there's one I disagree with completely and another that I'd add a caveat to.

The one I disagree with is using c headers instead of their c++ wrappers. Some of the c++ wrappers do actually add value (e.g. cmath adding templated versions of abs, etc) and it's easier for me to remember a single consistent rule ("use the c++ wrappers, always") rather than a list of which ones to use the c++ wrapper for and which to use the c header for.

The one I'd add a caveat to is the one about not using anything from the STL that allocates: I think that's good advice under some circumstances, but not all. The STL containers are really useful for getting something up and running quickly, so I think it's fine to use them in that case and only switch to custom containers once allocation shows up as a hot spot in your profiling.

As a caveat to the caveat, I would add that STL classes should only ever be used as an internal implementation detail, never exposed as part of an API. This is because the implementation of the STL classes can change, causing binary incompatibility. For example, Microsoft changed their implementation of std::string between Visual Studio 2008 and 2010 (if I remember correctly; and possibly again since?); if you have a library compiled against the older std::string you can't use that in a project being compiled against the newer std::string and vice versa - unless you have the source for the library and can recompile it. Using your own classes protects you from that because it puts you in control of when the ABI changes.

I think the grandparent post is talking about decoding to RGB with a full 32-bit float per channel, which is 12 bytes per pixel rather than 8. The high precision is needed for HDR and for the extra processing you have to do to the pixels after they're decodeed - motion compensation, gamma correction, etc.

Fair enough, I understand the desire not to bump the major version in this case. It does still kind of suck for users of the library though.

The case I was talking about was the OpenVR library, which changed the names for some of its enum values in the upgrade from 1.0.4 to 1.0.5. The change was documented in the release notes and it was straightforward to fix our code, but now we have to document that we require at least v1.0.5 and everyone building our code has to update their copy of OpenVR and so on. There are knock-on effects, is what I'm trying to say.

My opinion, as someone whose code got broken by a library micro version update just yesterday, is that the responsible thing to do is add a new function with the new args instead of changing the old one. Change the implementation of the old one so it calls through to the new one with suitable parameter values & and mark the old version as deprecated, but please don't remove it until the next major release!

I love my Aorus X3: http://www.aorus.com/Product/Features/X3%20Plus%20v6

Portability, power and build quality are all excellent. Battery life isn't up to MacBook standards, but you get a good 4 to 5 hours on a single charge which is still fairly usable. The trackpad isn't as nice as a MacBook either, but it's good enough. Everything else about it has the MacBook Pro completely outclassed in my opinion.

I thought that too. I found it hard to believe that anyone would write either of the first two versions without having thought of the 3rd - or, you know, just having 2 or 4 separate for loops. Maybe there was something about the problem's context that the author left out of the post though?

"Dear ImGui" (https://github.com/ocornut/imgui) is an absolute delight to use. Can't recommend it highly enough. It's not suitable for every project, but when it does fit then I can't think of anything else I'd rather use.

That's exactly my point: when the compiler can decide not to do something you told it to you don't have full explicit control over everything. That's not a bad thing though - the compiler usually makes good decisions on your behalf. Usually.

> Want to know where every last cycle goes and explicitly control everything? C

So... you compile with optimisation switched off?

In CUDA you can write your device kernel as a templated function and the compiler will specialise it based on how it's called by the host. In some cases this can result in big speed-ups while keeping the code simple and maintainable. You could get the same speed from specialising the code by hand, or with a separate code generation tool; but having that ability built in to the compiler makes it very easy to use.

It's also handy for the compiler to be able to check for errors in shader invocations. Looking up parameters by name and setting them dynamically adds a whole class of potential runtime errors that don't exist in straight c++ programs.

Nvidia have been promoting something called Roborace, which is running as something to do with the Formula E series. Is this anything to do with that?

https://en.m.wikipedia.org/wiki/Roborace