u/jsn

edit: disregard that, I do have an error here, thanks :).

Fails for me with:

jason@jsn tmp $ npx create-uix-app my-app
Downloading project template from https://github.com/pitch-io/uix-starter...
Unpacking into my-app...
node:fs:590
  handleErrorFromBinding(ctx);
  ^

Error: ENOENT: no such file or directory, open 'my-app/package.json'
    at Object.openSync (node:fs:590:3)
    at Object.readFileSync (node:fs:458:35)
    at /home/jason/.npm/_npx/520f0c1868eef90e/node_modules/create-uix-app/src/index.js:57:12
    at processTicksAndRejections (node:internal/process/task_queues:96:5) {
  errno: -2,
  syscall: 'open',
  code: 'ENOENT',
  path: 'my-app/package.json'
}
jason@jsn tmp $ rm -r my-app/
jason@jsn tmp $ npx create-uix-app my-app --re-frame
Downloading project template from https://github.com/pitch-io/uix-starter...
Unpacking into my-app...
undefined:10
    "lightningcss-cli": "^1.19.0

SyntaxError: Unexpected end of JSON input
    at JSON.parse (<anonymous>)
    at /home/jason/.npm/_npx/520f0c1868eef90e/node_modules/create-uix-app/src/index.js:56:28
    at processTicksAndRejections (node:internal/process/task_queues:96:5)

Thanks; yes, I looked at babashka/fs. The main difference is that babashka/fs apparently only does matching / expansion for filesystem paths and only works on JVM, and we needed something that can work with just strings and supports ClojureScript too.

There's also https://github.com/pyr/globber , but I couldn't make it work reliably for my purposes.

So, is xframe gone?

Obviously an ad for the new season of "Succession" that premiered yesterday.

Right. Well, when the Paratroopers' Day falls on weekdays (Friday, in 2013) the celebration often spills into the previous / following Sunday and Saturday.

This might be a really, really bad idea. This is August 2nd in Russia, don't know what year. It's called https://en.wikipedia.org/wiki/Paratroopers'_Day . So, this guy is in good shape, has extensive hand-to-hand combat training, is drunk enough not to feel any pain or any remorse if he maims or kills you, and there probably are dozens of his compatriots, all in the same condition, somewhere nearby who will happily join the fun if you try anything. Police will probably not intervene, they know it's not safe for them. This happens every year on August 2 in e.g. Moscow.

1) This is gonna break for lists containing nil or false, and 2) it's gonna return nil for an empty list (should return an empty list)

Sorry, you're wrong. "Traveling salesman problem" is "given a graph, find the shortest tour". "Solving traveling salesman problem" means finding such a tour for a given graph -- and that, AFAICS, is exactly what this program is doing. It absolutely doesn't mean "finding a general algorithm" (which, by the way, is also trivial: brute force is one example), and it certainly also doesn't mean "finding an efficient general algorithm".

Cool stuff! That huge position:fixed header on all pages of https://nginx-clojure.github.io/ seems super annoying, tho. With browser chrome and all, it only leaves like 50% of the screen usable (for e.g. actually reading the docs, etc).

I would suggest s/API/REST API/ at least in the title and in the introduction; there are other kinds of API, and it's very much not immediately obvious that your text is about REST APIs.

I don't understand what you're trying to achieve. The task you're describing is strictly sequential (files must be processed in order, you have to wait for the previous file task to complete before you can start the next one). Why use go-loops? They are only useful for concurrency and you just said above you can't have any concurrency here. Why not just

(let [file "dataset/flowers/rawFlowerData_2019"]
  (doseq [month ["05" "06" "07" "08" "09"]
          day ["01" "02" "03" "04" "05" "06" "07" "08" "09" "10"
                "11" "12" "13" "14" "15" "16" "17" "18" "19" "20"
                "21" "22" "23" "24" "25" "26" "27" "28" "29" "30" "31"]]
    (process-your-file-or-whatever (str file month "-" day))))

?

You have multiple go-loops running in parallel -- each of your doseq iterations spawns a new go-loop without waiting for the previous go-loops to terminate.

Hey, I know that place. It's "Nervosa" cafe in Bratislava, Slovakia, right here on Zamocka st.

I fully agree, actually. I'm not saying SHIELD really could have done better. They don't have a crystal ball, there were a lot of things they didn't know, and they had to work with the information that was available to them at the moment. I wouldn't blame them for what happened.

I'm just saying that their situation wrt their goals, as it is after S03E10, is really as bad as it gets (well, perhaps that's to be expected for midseason).

Yep, apparently the fix is not deployed yet, I still have to refresh after every storage upgrade.

I see the same bug (fixed by reload).

Yes, it's HGST now [at least for Ultrastars].

That's a lot of downtime. At this point it's cheaper to me to just buy replacements. Also, I have 2 drives misbehaving already; is there any reason to believe the ones they'll give me in "exchange" will behave better?

Yes, it may as well be so; it's a sad, sad state of things, though. I worked with whole systems vendors (yes, that's somewhat different), and you at least get "Please run this diagnostic software [windows-only or DOS] / change that BIOS setting / try that firmware update". I was surprised to get the straight "go away", so I've posted this to warn others about it.

No, I don't. Their support form explicitly asks for OS versions. They could refer me to their testing CD, though -- what do they care about my OS at all if they need a test CD report? Also, there is a Linux section in their site FAQ, it says they have a diagnostic software runnable on Linux. They also mention (Linux) smartmontools as an alternative.

Yeah, I figured as much from your first comment.

No, no, you're absolutely correct. It would be very foolish of you to base your opinion on Hitachi tech support on what some guy says on the internets.

You're much better off basing your opinion on your personal extensive experience with Hitachi tech support in case of Linux-related problems (you have that, right?), the overwhelming stream on evidence here in comments that, in fact, no, Hitachi doesn't refuse support because of Linux (you observe it right here, right?), and massive published market research from respected groups naming Hitachi the best Linux hardware vendor in "Tech Support" category (you have that, right?).

In fact, I too would be much better off basing my opinions about Hitachi on any of those three. Care to share some? Thank you!

So basically you can't read well enough to understand that the post is about HGST refusing support, not about drive problems?

Deskstars were originally IBM, IIRC -- Hitachi bought them later. They were pretty bad, yeah; I've lost 2 servers in 2003-2004 because of them.