Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Disabling npm's progress bar yields a 2x npm install speed improvement

twitter.com

Post reply on HN
Print view View original

171–180 of 187 posts

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#171

Post by oldmanjay »

morebetterer wrote: post #71
scrollaway wrote: post #55

Earlier quoted context omitted.

> Never claimed that was the case. Whether you claimed it is not in question. You're saying "[color in the terminal] is the work of the devil", which has a clear intent to dissuade people from coloring terminal output. Which, frankly, is insanity. Most apps do it well nowadays: --color=auto/always/never, usually defaulting to auto. So when GP says "not everyone is you", they mean be considerate. If you want color off…

"Catered to", "dissuade", "push that choice" and "insanity"? Now this is just getting silly. You are taking my comments far too seriously.

No, you're making bad jokes in a context where they aren't welcome. You may want to try Reddit or Slashdot. They enjoy this sort of thing, I understand.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#172

Post by [deleted] »

jlas wrote: post #164
yeukhon wrote: post #106

Earlier quoted context omitted.

What do you want? a whole new process? That doesn't scale either. Come on.

What we need is to put this into a Docker container then parallelize the cloud instances using asynchronous message brokers enterprise

[deleted]

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#173

Post by caoilte »

dasil003 wrote: post #116
technomancy wrote: post #104

Earlier quoted context omitted.

Indeed; a lockfile is just a workaround for the problem of "just give me whatever" dependency declarations. Solve the problem at the root rather than piling hacks on it.

I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respecti…

We use Ruby extensively in testing and infrastructure and have lost months of cumulative developer time to this attitude. It works for a single user constantly making changes to a small piece of code and prepared to work out the solution to dependency change problems as soon as they come up. However, it doesn't scale to a team of people working on very large code bases.

One example of this is having a repeatable developer setup guide. If the dependencies might have changed by the time a new joiner starts your setup guide could very easily end up useless or misleading and that's without anything at all in your own codebase having changed.

Shrinkwrap fixes this, but always gets added after things went wrong several times already. It should be the default.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#174

Post by caoilte »

technomancy wrote: post #138
dasil003 wrote: post #129

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.

I've also been on that journey and am starting to feel the same way about variance.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#175

Post by mikeash »

dagss wrote: post #145
mikeash wrote: post #108

Earlier quoted context omitted.

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.

And yet it was perfectly obvious what was meant. If you just assume the person who made the comment is not stupid/rambling (difficult concept, I know...) it is not difficult to get the meaning at all.

You say it was perfectly obvious, I say it's almost impossible for someone steeped in iOS development to understand any way other than the way I said. Even given a huge amount of charity to the poster, the best I can do is "I have no idea what they mean by this."

How come we have to give this person the benefit of the doubt to the point of understanding a term to mean its exact opposite, but you don't have to give us any of that?

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#176

Post by morebetterer »

oldmanjay wrote: post #171
morebetterer wrote: post #71

Earlier quoted context omitted.

"Catered to", "dissuade", "push that choice" and "insanity"? Now this is just getting silly. You are taking my comments far too seriously.

No, you're making bad jokes in a context where they aren't welcome. You may want to try Reddit or Slashdot. They enjoy this sort of thing, I understand.

Thank goodness we have you and others to police the jokes. Remain vigilant! Keep up the good work.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#177

Post by stcredzero »

ClayFerguson wrote: post #68

Doing GUI calls is a notorious way to slow down apps. I sped up an app (major software from major large corporation) by a factor of 10x a few years back by removing GUI updates. What you have to do is create a thread that refreshes the GUI periodically and not let your main worker thread ever work on the GUI. This particular app was an Eclipse Plugin (a source control app) and the Eclipse SWT to update the console lo…

Doing GUI calls is a notorious way to slow down apps.

Seriously. One notable Smalltalker sped up the compiler in VisualWorks this way. Yes, there is a compiler in Smalltalk, it just usually only compiles one method at a time, which had a lot to do with why no one noticed that printing notifications to the transcript took up most of the time. So for a bulk code load, turning off the notification sped up "compile time" a whole lot. In fact, the JIT-ed Smalltalk in VisualWorks actually outperformed the C/YACC implemented compiler in a different Smalltalk.

Someone needs to keep track of this stuff. Why do we keep making the same mistakes over the decades? (Insert famous Alan Kay quote here.)

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#178

Post by amptorn »

bb88 wrote: post #34
Xophmeister wrote: post #25

Earlier quoted context omitted.

I'm not sure "IED" is the best acronym to go for, either: https://en.wikipedia.org/wiki/Improvised_explosive_device

Didn't stop NUKE, PHP Nuke, DotNetNuke, etc.

"Free software projects with terrible names" is a long, long rabbit hole.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#179

Post by BuckRogers »

I don't know the exact cause here, but I can say I'm thankful for my systems background that I've gleamed for years before moving into programming. Most sysadmin types know that displaying output on a filecopy slows down transfers greatly because the screen vsync holds up the operation.

When I write utilities today that do similar things, I only display output when writing and testing the program. Otherwise I'll write to memory then dump the results in a logfile at the end.

In this case since there is probably a less intensive way of providing status updates, and can probably be resolved by doing intermittent checks.

Re: Disabling npm's progress bar yields a 2x npm install speed improvement

#180

Post by cstrahan »

technomancy wrote: post #120
dasil003 wrote: post #116

Earlier quoted context omitted.

I'm not 100% sure from your comment, but are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? As someone writing a lot of ruby, "give me whatever" is analogous to "give me the latest unless I specify otherwise", which I consider to be a very good default. It keeps me up to date with security issues, and incompatibilities between libraries that the respecti…

> are you suggesting that by default you should vet every version exactly and freeze it at the point you defined it? Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful. Pulling in new code without you asking is a fine idea for something like apt-get where you have a huge team doing QA on the entire system working together before it even hits your repositories…

> Yes, this is the way that Guix and Leiningen and rebar3 and a bunch of other things work, and it is wonderful.

Even in Nix/Guix, it's still ideal for upstream projects to express their dependencies in terms of ranges (semver-wise), otherwise we run into the problem have either really large run-time dependency closures, or problems around e.g. wanting to use multiple (overly specified) versions of C libs within the same process.

As the current maintainer of Nixpkgs' Bundler-based build infrastructure, I've found the lockfile approach that Bundler uses to be quite frustrating - in part because Bundler's design is antithetical to packaging, but also due to the build times and sizes of the resulting packages, compared to C libraries. (People give C a hard time wrt productivity and security and such, but when it comes to packaging, C libs are usually so much easier to work with than most other higher level languages.)

I would love to see more adoption of semver, and possibly Haskell's PVP (https://wiki.haskell.org/Package_versioning_policy). Granted, dynamic programming languages don't have the benefit of making API breakage obvious at build time, so perhaps the best we can do in such cases -- if we want any certainty that packaged applications will actually function correctly -- is lock down every dependency version precisely per application...

Post reply on HN