141–150 of 187 posts
Progress bar or not, npm has gotten extremely slow with v3, to the extent that someone is working on a performance-centered alternative called ied: http://gugel.io/ied/ installs are literally the #1 thing npm needs to do well, and I really hope we see some improvement soon.
Earlier quoted context omitted.
That's frustrating, I got bitten by that a couple of times. I'm wondering when will they add a LOCKFILE like every other build system out there :'(
I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.
Earlier quoted context omitted.
I agree, but I'm curious what other build systems have a lock file? Ruby does through bundler, who else does this right? I can't think of any.
And it's so awesome when you discover devs have used lockfiles to leave you stuck on known-insecure gems instead of updating their fucking code to support the newer patched version.
Earlier quoted context omitted.
You're not being charitable enough to the comment... you two are in completely agreement with one another if you only changed the meaning of the word "main". It's clear the grandparent meant "the thread that's doing the work."
It's really difficult to get to that meaning, because "main thread" is what you call the thread where main() is invoked and which is where all the GUI calls must happen. You can't use a common term in context to mean something different from its common meaning and expect people to follow.
Earlier quoted context omitted.
If you want to do this in ruby you can just specify a version manually. If you don't, you still get versions frozen by default with Gemfile.lock. It doesn't pull in anything automatically—by default you get no updates, you can choose to update a single dependency, or the whole thing if you want to verify it works on the latest (useful for libraries for instance). I'm not sure I see the downside. FWIW I have been doin…
> I hold up Bundler as one of the great success stories of open source It's a great success in many ways, but the problem it solves is completely self-inflicted by rubygems. I've also been doing Ruby for over a decade, but I've also learned a lot from other library ecosystems, and I feel pretty confident saying that disallowing version ranges makes all those headaches completely evaporate.
Generally I'd use semver ranges in libraries, and then fixed versions + lockfiles for transitive deps in applications.
I suppose this is roughly equivalent to doing `:pedantic :abort` in leiningen, except you wont't have as many warning to squash - either way you have to rely on the test suite to tell you if the versions you've pegged work.
Earlier quoted context omitted.
This is backward. Since UIKit is single threaded, the main thread must work on GUI: the best practice is that nothing except GUI work should happen there.
You're not being charitable enough to the comment... you two are in completely agreement with one another if you only changed the meaning of the word "main". It's clear the grandparent meant "the thread that's doing the work."
Earlier quoted context omitted.
You don't use syntax highlighting?
No, never had a need for it.