I love valgrind and it saved my ass countless time when tracking memory leaks or overflows. The main issue I've always had with it is filtering the output easily. When you use external libraries (portaudio or Qt for example but also proprietary libraries I had to use at work) a lot of the debug messages pollute what is really yours and your leak is then a needle in a haystack.
I remember trying multiple solutions with exception files and such but not having a lot of luck at filtering the ones I did not care about while keeping my own errors displayed. It's clearly user error on my end but I always gave up and rewrote smaller samples without external dependency when I could.
I've encountered a lot of issues on Windows XP with QT/Angle but also quite a lot on Windows Vista/7 where the graphic drivers by default don't support properly OpenGL or pretend they do but don't answer properly to Qt's requests. This ended up with a big chunk of my users having a blank window or even no window displayed to them and no way to reliably detect this on our end.
This feature has been in the works for multiple months now and I'm really glad to finally see it ship officially with Qt 5.4, so congrats to the team!
What I don't understand is why not have this be "opt-in". Meaning if your company does not need this feature for real legal reasons they don't enable it and everyone is happy. I've heard a few people saying they did not want this feature in Hipchat and would have to switch to make sure there team was not suspicious. If my company never needs to access private chats for legal reasons, there is no reason it should be enabled today and they can have access to it in 3 years.
I understand specific companies have specific needs and Slack has to meet some of these but there is no reason that this should impact everyone else.
Sorry if I wasn't clear enough. What I mean is that if in 3 years my company needs to have access to some logs, they will have to go through the multi-steps process but then have access to whatever they need (starting from today's logs)
What I meant was that the possibility to access private chats should stay not retroactive and only happen once the company has explicitly stated it will need this feature enabled.
EDIT: so that if my company has no legal needs today it won't have access to private chats made today once they decide in the future that they now need the feature
You could say they just learnt from the Hipchat announcement and remebered to address the issue head-on which makes it seem like they really care. But in the end the problem is exactly the same and your company will now have access to whatever you write including private chats. Personally that means I'll ensure to avoid private chat on Slack and use external tools again on top of everything I already use which is clearly annoying.
When I look for a job I apply to multiple companies at the same time when I find job openings that match what I'm looking for and also apply to companies I'd love to work for that don't have openings.
So I end up having multiple phone interviews and then on-site interviews until I get one or more good offers. Just recently I got 3 really good offers in the span of two weeks and took the time to chose the one I really wanted to accept. I told each company I was interviewing at other places too and wanted some time to think.
That's a question I'm clearly interested in! I just moved to another country and am working on a website to play my favourite board games with my family and was wondering if I could publish it on github or if I should keep this private as I don't have the rights for the board game.
Does it also mean that when doing an API client library for stripe you have to handle all this complexity about versionning? Because if someone updates to the latest version of the library but still wants to use the old way of creating a charge (staying on the example where charge would now always be 1$) he would want to be able to do it without having to find an older version of the library that supported this API version.
This actually works out okay for most of our libraries. For the ones that can support it (Ruby, Python, etc), we don't hardcode the properties for any resources and instead generate objects on-the-fly when you make an API request.
In the $1 example, the libraries will just construct a Charge object without the `amount` property, since it wasn't returned in the API response.
You're right that it isn't perfect for other languages, though. We're working on making our versioning story better in our docs, libraries, webhooks, etc. (:
I understand how you handle it on your end but let's assume I decide to build an API for a language you don't support yet. In a few months when you add new versions of the API where some fields become optional or mandatory, then won't I have to know all this as the library developer and handle each case? Because some of my users would expect to still be able to send the charge amount while others would not.
I'm more thinking in the idea of doing some "pre-validation" in my library to avoid an API call from the client when something is already expected to fail (like missing the amount field right now) which would not fail with a new version of the API. So I would have to adapt to each version to know that this user would require the amount field while another one would not.
Yeah, we specifically designed this setup with your situation in mind. As the author of a library, you can specify the version you want to use. So your code will work on any account, regardless of what that account's version is set to.