mullr

Yeah, that's by far the most likely. Note that one of Gernot's non-goals is "Stopping you from shooting yourself in the foot": this is to be taken seriously. The userland libraries provided by SeL4 have no proof evidence at all, and IME look and feel like any other C codebase. It's very likely that they the same class of security problems. Further, it's /very/ difficult to build anything on SeL4 without using said libraries (ease of use is another non-goal, remember?), so I'd expect many real systems to be built on them and thus share some class if issues among them.

Alternatively, if you were using them to force a barrier in the query plan, it could completely tank. Thankfully it can be turned off, and they did this in a major release.

The term likely comes from max/msp, which has a “bang” message with a similar function.

I've struggled with jogl as well. Clojure being hosted is a definitely a double-edged sword; while it makes it possible to use something like jogl, actually doing so can require you know something (or a lot of things) about the underlying platform.

The questions you raise here are real issues. I've been able to scaffold things for newcomers to the language in the past, but I can easily imagine how they could go off the rails without some guidance. I believe that the new "deps.edn" mechanism is meant to be the official, paved path for dependency and platform interaction in the future. But until everybody is using it, there will be two ways of doing things and the confusions that goes with having a choice. Perhaps it's necessary to move the platform forward.

> I do suspect that the survey is under-weighting how much beginners must struggle to navigate setting up CLASSPATH. If you don't come to Clojure from Java then the toolchain is a bit intimidating with whatever a Maven is, followed by a process of trying to follow what both Java and Clojure tools are doing. This is one area Clojure compares very poorly with, eg, C (similarly awful setup process, but usually all the burden is shouldered by the distribution provider) or Python (use pip).

The Clojure answer is similar to the python one: use lein. This basically solves all classpath issues. In the 3 years I used Clojure professionally, there were only small handful of times I had to deal with the classpath directly, and that was only for pretty exotic packaging issues.

> It is interesting coming at Clojure from a Debian background at how resistant Leiningen has been to being integrated into the Debian apt archive. I think the package was removed in 2014 and only came back in 2018; so still isn't in the most recent stable. Given that Leiningen is itself probably the first choice of tool to manage dependencies, this raises questions about the technical underbelly of the tools used to build Clojure programs.

What questions does it raise? Debian doesn't deal gracefully with any external dependency management systems, as far as I know.

Can’t speak for aerospace, but at least for automotive systems, the functional safety standards that dictate what you have to do for the most critical parts of the system are kind of a joke. They amount to a lot of test coverage, lint tooling, and extensive requirements management that manages to still be full of gaping holes. Formal methods are suggested on a “wouldn’t it be nice” level, but nobody thinks they can afford it. There are a lot of reasons for this; inertia, inexperience with formal methods, and the difficulty of the tools comes to mind. None of them are acceptable excuses, especially as we are asked to turn more and more control over to increasingly sophisticated ADAS (eventually autonomy) systems.

> In every single time, management outsourced and took the bid from the lowest priced company.

Turns out good engineers make good money. I've worked with some brilliant engineers from India-based consulting teams, and they were not cheap.

Rocksmith is good fun, if you like that sort of thing.

I can find no reference to this; it appears he may have three daughters but they all share his surname. Source?

"Code reviews become annotations" - cool feature, and it identifies a real problem. I don't think it solves it though.

We've learned many times that your source code and its history are the thing you care about. Spreading closely related information across different systems is dicey at best. It never seems to follow the same branching structure as the source code, and external systems come and go. Even for issue trackers, one of the most obviously useful tools we have for software development, it's not obviously a good idea to refer to issue ids from source code comments.

That is to say: if you believe that code reviews are an important part of the code, or at least sometime can be, then you should be getting that information back into the code itself. Show me a way to turn code review into a code comment from the review interface, that would be cool.

Really high performance Java code tries to avoid any allocations on the hot paths, since that requires GC. This means a lot of in-place mutation on pre-allocated objects. (Lucene does this, for example) While this isn't impossible in Clojure, you do have to give up a lot of the immutable goodness that makes it such a pleasant development environment.

https://en.wikipedia.org/wiki/American_Morse_code says that 'o' was encoded as 'dit <space> dit', whereas 'i' was encoded as 'dit dit'. International Morse Code changes 'o' to be 'dah dah dah'. I cannot see any evidence American Morse was used for radio, though it may have been.

Notably absent is anything in the lisp family, which excel at symbolic manipulation. Here's a Clojure version, both vanilla and with core.match.

https://gist.github.com/mullr/d655db18ebb7aa77a62e

'ci(' works, I just tried it. I don't know the 't' parameter there, but 'da(' works as expected as well.

Is it? The cool thing demonstrated here is that you can send functions over the wire. I can't find any facility in Finagle to do that. Indeed, prior to JVM 8 the permgen made such systems all but impossible in java-land.

(when (seq s) ...) reads to me as "do this as long as I can treat s sequentially". The following operations on s require it to be seqable, so it's like a runtime type check. not-empty is less direct, and feels like it's assuming that s is seqable.

Of course, not-empty is implemented with (when (seq)), so there's no REAL difference. At the end of the day, (when (seq)) is what people use.

A good way to frame this: http://martinfowler.com/bliki/TestPyramid.html

> audio software/hardware manufacturers tend to ignore Windows

Really? Apogee is the only manufacturer in this market I can think of, out of many, that supports Apple products but not Windows. All latency-fearing Windows audio software and hardware uses ASIO, for which there is broad industry support.

> Audio hardware manufacturers want to release products for platforms that people are actually using, so they target OS X.

I think you perceive their motivations correctly, but most people would reach a different conclusion than you have. Anecdotal evidence suggests that said manufacturers have as well.

> The really weird thing is that I get better latency when recording through my iPad then I do when recording through my beefy gaming rig.

The latency of a digital audio system is determined by the amount of buffering in the signal path, but your computer must be able to keep those buffers reliably full. Your iPad, being a more controlled system with fewer background processes, should be able to do a much better job of this than your desktop box, where anything goes.

Clojure is dynamically typed, homoiconic, and places a lot of emphasis on immutability and managing state. Scala has different design goals. Idiomatic Clojure code is quite different, structurally, from idiomatic Scala. You should try it, and believe it when everyone says that the parentheses fade after about a week.

Market researcher, that is.

http://pouchdb.com/faq.html addresses many of these questions.

The technical details:

https://developers.seagate.com/display/KV/Kinetic+Open+Stora...

The important, actual TLDR: "Kinetic Open Storage is a drive architecture in which the drive is a key/value server with Ethernet connectivity."

There's a lot of hate bouncing around here for Jenkins. Can we stop for a moment and remember what it meant to set up a build system before Jenkins was around? Sure, it's not rocket science, but Jenkins made things quite a lot easier and made continue integration actually possible to think about for many shops. It's no small feat that they managed to do this for n revision control systems * m languages with associated build systems and testing frameworks * q random options and make it still mostly work.

Jenkins moved the minimum acceptable level of automation, for the industry, up quite a lot farther than it used to be. Say what you will but remember its impact, and that the guy who made it is quite possibly reading this thread.

It never occurred to me that they'd be using tagged pointers for Objective-C runtime stuff. Of course it's obviously a good idea, but only after hearing it does it become so. Objective-C is always more dynamic than you think it is, so taking implementation cues from other dynamic language runtimes makes perfect sense.

It appears that they've been using tagged pointers on the desktop since 10.7, which I never realized: http://objectivistc.tumblr.com/post/7872364181/tagged-pointe...

Clearly this is not surprising.

Amazon has an interesting problem - they exist as an alternative to real-estate heavy consumer goods businesses, and yet they now find they need real-estate. They new a partner with stores in many locations, but whose business won't be cannibalized by amazon itself.

They need McDonalds.

It would be very good for A fast food restaurant to have an Amazon locker, I think. Both draw heavily on those who are too busy working during the day and just want to grab something on the way home.

I don't know much about how Apple works, but any software of reasonable size simply has to ship with bugs. I'd bet there were more important problems being fixed up until the last minute.

When you say that a background task should be made into a RESTful API call, I assume you mean that instead of spinning up a local thread to do the work you should defer it to another service. Certainly you can do that, but async/await is still relevant in that case.

The key question is: while said REST call is happening, what is the caller doing? Normally, he's sitting there and blocking his thread until the call finishes (i.e. consuming one thread from the connection thread pool). With async/await, the thread is released back into the thread pool until the result is ready, then it picks up where it left off.

So anything where you might want to deal with background operations that take a long time (including network / db / filesystem access, i.e. most applications that aren't pure functions) in a connection-oriented system can greatly benefit from async/await. Even if it's just a regular desktop app, it appears to be a useful mechanism for coordinating different background tasks.

It can take a few tries before things start to click. It also helps quite a lot to be using a modern variant (Clojure, probably Racket)