Shoop

Probably Ludvig Strigeus [0].

[0] https://en.wikipedia.org/wiki/Ludvig_Strigeus

> It's written in an unusual programming language called OCaml, and in a fairly idiosyncratic dialect of it at that. This is of course no problem for a proof of concept meant to support a Ph.D thesis, but for software that's deployed in the field it makes maintenance quite difficult. Not only do we need to be bright enough to understand an algorithm that's literally someone's Ph.D thesis, but we need expertise in obscure programming languages and strange programming customs.

Looking at the code [0], it looks like fairly standard Ocaml. Any particular reason it's difficult to maintain (other than the lack of popularity of FP in general)?

(It looks like the original author of the SKS Keyserver is Yaron Minsky, the guy who convinced Jane Street to use Ocaml.)

[0] https://bitbucket.org/skskeyserver/sks-keyserver/src/default...

Working link http://ajs.github.io/tools/sleep-sort-perl6/

I too spend about 16 hours a week on Hacker News :)

D is known for having an extremely fast compiler. In fact, Walter Bright wrote one of the fastest C++ compilers (the Digital Mars C++ compiler) before he wrote D.

I believe that's the syntax for enabling a parsing mode. I think it just changed from #! to #? (to allow a nim bash shebang).

Obviously, the yikes is gone now. It was always an experimental feature, so IMO the fear of it was overblown, but it is a pretty scary idea for a feature.

> The undocumented #? strongSpaces parsing mode has been removed.

I remember seeing lots of controversy over this feature a previous time Nim was posted here. Hopefully, its removal will stop people from dismissing the language outright (which would be a shame given all the things Nim has going for it).

(That being said, if people still want to embrace Wadler's Law [0], there's the hot-button topic of case/underscore insensitivity to talk about. [1])

[0] https://wiki.haskell.org/Wadler%27s_Law [1] https://github.com/nim-lang/Nim/wiki/Unofficial-FAQ#why-is-i...

I believe the purpose of these checks is for when people's outdated wordpress install or whatever gets compromised by script kiddies. Generally, the scripts install crypto miners to mine for the hacker until your account gets shut down, running you up a huge bill in the process.

gf is awesome. Great for navigating scripts that run other scripts and also useful for creating links within a personal wiki of markdown files without a plugin like vim-wiki. While I do use a lot of plugins, I find it's a lot better to select plugins that add to vim's editing language (vim-eunuch, vim-surround, vim-vinegar, vim-exchange, vim-angry, vim-sexp-mappings-for-regular-people, vim-commentary) rather than plugins which agglomerate IDE features onto vim (vim-wiki, nerdtree, etc).

While I do have a few of these IDE-like plugins (undotree, for example), I think it's better to try plugins which embrace the "vim way" first before investing in a full IDE-like plugin. I don't mean to gatekeep by criticizing IDE-like plugins, but just to say that spending the time to learn normal mode as a true language (verbs, nouns, and all) and using plugins that follow this idea is a worthy investment. Then, add IDE-like plugins to work around the frustrating rough edges of vim once you've milked all that you can out of it.

Yes. Ninja loses 15,000 subs every day he doesn't stream [0] (The linked article is a super interesting profile -- definitely recommend it).

[0] http://www.espn.com/espn/feature/story/_/id/24710688/fortnit...

Also worth checking out: a response to the article by Frank Lantz, friend of Ian Bogost and character in the article [0].

[0] http://gamedesignadvance.com/?p=2383

sshpass works nicely.

To add some context to this, the reason why packages which depend on haskell in arch are such a mess is because "the arch way" is to dynamically link everything. This has its advantages (namely security), but is not super compatible with the haskell ecosystem which is designed with static linking in mind.

Like my parent commenter, I recommend just doing everything through stack. stack-static from the AUR [0] is the convenient way to do this (rather than dragging in a few gigs of ghc dependencies for stack only to have stack create its own local ghc installation as well).

[0] https://aur.archlinux.org/packages/stack-static/

Maybe you want to check out proselint? [0]

[0] https://github.com/amperser/proselint

I love the UI! Maybe this would get into the hands of more people if it were just statically hosted html + js (maybe on gh-pages) that stored your todo items in browser local storage?

Note that there is an open issue to perform the self-update before the update: [0]. Could be a good first patch for someone looking to contribute :)

[0] https://github.com/rust-lang/rustup.rs/issues/1838

This update comes with a new version of rustup which has much faster updating, especially on windows [0]. If you'd like to experience this performance improvements, run `rustup self update` before your upgrade!

[0] https://www.reddit.com/r/rust/comments/brtec1/rustup_1183_re...

Now there is a regrade system that lets you ask for more partial credit if you feel that the autograder was too harsh. That being said, its still relatively easy to get a lot of points off for a small mistake :(. You definitely have to be really careful during 213 exams but thankfully there's plenty of time to redo all the questions 2 or 3 times.

Some builds in this project are out-of-tree (the best practices cmake way with a separate build directory). Some are built in-tree (with json files, libraries, object files, LLVM ir files, and more scattered in the same directories as source code). I can't be bothered to spend the time to learn, write, debug, and maintain the correct grep invocation to do this. rg has saved me the 10 minutes it would take to do this, and 28 seconds * ~1000 grep invocations. I'm a very happy customer.

The project is a fork of LLVM. We're implementing compiler support for a new design for threading on x86.

Here's a blog post from the author explaining how rg works: [1]. It's from 2016 so the benchmarks may not be up to date, including for rg's competitors.

[1] https://blog.burntsushi.net/ripgrep/

I use rg on a very large project (8.5 million LOC, 5.2G of files including the build). Searching with rg takes less than 2 seconds and I don't ever have to think about it. rg automatically handles not searching the build files and autogenerated files which often contain lots of matches but are never what I want to search. Additionally, rg has an excellent --vimgrep feature which makes it easy to integrate with the vim quickfix list.

Vanilla grep, meanwhile takes 30 seconds -- too long to search while maintaining flow.

For me, the whole thing _is_ that it is faster than grep. AFAIK, a lot of its speed is due to breaking compatibility with grep to allow for more convenient defaults (skip binary files by default, skip .gitignore by default, etc) which also happen to be faster. For me this is a clear win-win.

Also, I have an 8 core machine. To be waiting for a 30s search knowing 7 cores are doing nothing makes me sad.

$400 screwdrivers? The screwdrivers pictured were 349 rupees ~ $5.

Does anyone have a timestamp for Larry Wall talking about types?

It's somewhat similar, except C++'s [] leads to memory unsafety whereas Rust's [] on slices has bounds checks and will abort the program on failure. Your program will crash but it won't be an exploitable bug (except for a DOS). .get(), meanwhile, returns an Option so that code written using it can recover from OOB accesses.

The unix infrastructure is still in place and widely used by nearly all cs courses.

How does a blocking CSPRNG mitigate this attack?

Again, it makes no sense to say that a CSPRNG can start "running low" on entropy.

Here's what djb has to say about this:

     Cryptographers are certainly not responsible for this superstitious nonsense. Think about this for a moment: whoever wrote the /dev/random manual page seems to simultaneously believe that

    (1) we can't figure out how to deterministically expand one 256-bit /dev/random output into an endless stream of unpredictable keys (this is what we need from urandom), but

    (2) we _can_ figure out how to use a single key to safely encrypt many messages (this is what we need from SSL, PGP, etc.).

    For a cryptographer this doesn't even pass the laugh test.

(Unless you're talking about the early boot seeding problem that /dev/urandom has on linux, which is a very real problem).

For reference, here's the classic source I think you're referring to: https://www.2uo.de/myths-about-urandom

(2007)

Python negative indexing isn't modulo. It's just shorthand for array[len(array)-i].

  >>> a = [1, 2, 3]
  >>> a[-1]
  3
  >>> a[-2]
  2
  >>> a[-3]
  1
  >>> a[-4]
  Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  IndexError: list index out of range

Elm is still implemented in Haskell. Self-hosting isn't a goal.