Live data from Hacker News

Spark

github.com

91–100 of 100 posts

Re: Spark

#91
post #90
post #15

This reminds me of another useful utility from the childhood: alias updick='/usr/bin/uptime | perl -ne "/(\d+) d/;print 8,q(=)x\$1,\"D\n\""'

The dick grows depending on how long the system has been running?

Exactly. Kinda measure of how strong is sysadmin.

Re: Spark

#92

Earlier quoted context omitted.

Here's a Haskell version that uses a single loop to do the normalizing, and has a main that doesn't use do syntax. This was mostly a nice little brainteaser: https://gist.github.com/1367709 mapNormalize takes a function, and produces a function that runs that function with the normalized input. It runs in a single iteration, rather than 2 maps. Credit to `dylex` for much hand holding on a single iteration normalizer…

Because Haskell is evaluated lazily, two maps doesn't imply two iterations over the data. In this case, I would expect only one pass through the data for both of the maps. Out of curiosity, I did a quick criterion benchmark for both functions. Here's the result on a list of 100 elements: benchmarking spark_mggcl mean: 49.29483 us, lb 48.77776 us, ub 50.25594 us, ci 0.950 std dev: 3.495423 us, lb 2.140951 us, ub 6.373…

I am aware of that, as I said this was more a mental exercise. normalizeMap is harder to understand, but it was interesting to write - it wasn't meant to be a stab at your code or claim it's better :)

In terms of do syntax, I try and avoid that because I find it detracts from the overall flow of data. With: "putStrLn . spark . map read =<< getArgs" I find it easy to see that main doesn't do much other than transform the users input. maybe a personal preference thing though...

Re: Spark

#93
post #88
post #72

Earlier quoted context omitted.

This is a totally fair complaint. Sometimes it is a mystery to me why HN-ers downvote things.

In all seriousness: some folks on HN (not all) seem to be the guard in the center of the panopticon. If you could see a list of who downvoted you, I'd bet that something interesting would happen. I almost expect to come back and see my karma drop as a result of this comment.

I think having downvotes public is an intersting idea. It would certainly force people to justify their downvotes, anyway.

Re: Spark

#94
I rewrote it in C, so it's faster and can work more efficiently on different data sets. It also uses a prettier algorithm for determining heights. Have fun:

http://git.zx2c4.com/spark/tree/spark.c

    $ git clone http://git.zx2c4.com/spark
    $ cd spark
    $ make
    $ ./spark 1 4 2 8 14
    ▂▃▂▅█
    $ curl -s http://earthquake.usgs.gov/earthquakes/catalogs/eqs1day-M1.txt | cut -d, -f9 | ./spark
    ▂▃▄▃▃▃▄▃▇▃▄▄▄▅▃▄▄▄▅▅▅▄▄▄▃▃▃▃▃▄▃▄█▅▄▄▄▄▃▇▄▄▄█▄▃▄▄▄▄▃▃▄▅▄▅▃▃▃▃▇▄▅▄▇▃▅▃▄▃▄▃▇▃▃▄▇▃▄▃▄▃▃▃▄▃▃▃▃▃▃▅▃▄▃▃

Re: Spark

#95
post #68

Because I want my shell prompt to be a giant graph. ▁▁▁▁▅▁▇▁▁▅▁▁▁▁▁▂▂▁▃▃▁▁▃▁▃▁▂▁▁▂▂▅▂▃▂▃▃▁▆▃▃▃▁▇▁▁▂▂▂▇▅▁▂▂▁▇▁▃▁▇▁▂▁▇▁▁▆▂▁▇▁▂▁▁▂▅▁▂▁▆▇▇▂▁▂▁▁▁▂▂▁▅▁▂▁▁▃▁▃▁▁▁▃▂▂▂▁▁▅▂▁▁▁▁▂▂▁▁▁▂▂$ Ship it.

Does HN really not have any protection against comments that are very long single words that screw up the page width?

Re: Spark

#96
post #73
post #49

Earlier quoted context omitted.

This also doesn't meet the high resolution part of Tufte's definition ("a small intense, simple, word-sized graphic with typographic resolution"[1]). [1]: http://www.edwardtufte.com/bboard/q-and-a-fetch-msg?msg_id=0...

They're comparatively higher density...

This gives you eight levels (plus blank)[1]. Most of the type I read is at least twice that many pixels high.

[1]:https://github.com/holman/spark/blob/master/spark#L46

Re: Spark

#97
post #96
post #73

Earlier quoted context omitted.

They're comparatively higher density...

This gives you eight levels (plus blank)[1]. Most of the type I read is at least twice that many pixels high. [1]: https://github.com/holman/spark/blob/master/spark#L46

Tufte honestly thinks pixelated type is pretty terrible, too. 16 pixel density is embarrassing compared to printed or pressed text.

But in either case, it's obvious that's a silly argument. Trends posterized to 8 levels are far easier to read in "sparkbar" form than as a list of numbers. It's suboptimal, but better than the plain list.

Re: Spark

#99
post #2

Ah, as inspired by Edward ttyfte.

That ^ is why HN needs a LOL button :) http://img819.imageshack.us/img819/264/hnlol.png (edit) Ah, the downvoting frenzy! 4601 karma points to go. Bring it on, fellow HNers. Don't forget to quote the guidelines and to lecture me too as no bashing is complete without showing some smug superiority with a hint of righteousness.

Would you please not do this?

Re: Spark

#100
post #75

Earlier quoted context omitted.

NetBSD seriously doesn't put bash in /bin? That's just broken by design.

I can't speak to NetBSD, but FreeBSD doesn't put any user-installed programs in /bin or /usr/bin, they all go into /usr/local. Since bash isn't distributed as part of the base system, it goes into /usr/local/bin/bash

So then how do you write cross-platform scripts? You can't even do "#!/usr/bin/env bash" since I'm assuming what you're saying means 'env' is in /usr/local/ as well, but on Linux systems it'll be in /usr/.

Broken! Can we please just pick one convention and stick with it? Oh, standards... so many to choose from.

Post reply on HN