Jump to content

Unrecognized selector sent to instance on quicklooking URL (macOS Sierra bug)


vitor

Recommended Posts

Can reproduce 100% of the time.

  1. Invoke Alfred.
  2. Type a web address, such as example.com, and let Alfred recognise it as such.
  3. Press ⇧ or ⌘Y for QuickLook preview. Alfred instantly crashes.


It also happens when previewing web addresses from Workflows. Confirmed with ShortFilms and Urban Dictionary.


Console.app outputs default    20:21:42.041103 +0100    Alfred 3    -[NSKeyedArchiver initRequiringSecureCoding:]: unrecognized selector sent to instance 0x608000107e90


Alfred 3.7 [938]
macOS Sierra 10.12.6 (16G1510)

Link to comment
Share on other sites

2 hours ago, deanishe said:

Presumably related to the Sierra Quick Look bug with URLs.

 

I was thinking the same. I plan to upgrade to Mojave so this shouldn’t affect me much longer, but decided to open a bug report anyway in case it’s something deeper in Alfred.

 

2 hours ago, deanishe said:

Why are you still on Sierra?

 

Because I always do a clean install when upgrading, but in High Sierra’s case life happened and I never got the opportunity. I also wanted to finish some CLI tools beforehand1 but never got around to it. At a certain point it started to make less sense to upgrade since I was going to have to repeat the process in a few months time. Doing an upgrade in place was also a bad option because I predict a higher than normal chance of data loss (new file system).
 

2 hours ago, deanishe said:

Aren't you having issues with broken workflows due to the ancient OpenSSL version installed?


Nope. I had a few with some of my ruby Workflows before High Sierra was released, but I fixed it temporarily by calling curl. Has been working well ever since.



1. One of them being a way to save/restore preferences. Kind of like mackup, but actually usable for my needs. Mackup moves your preference files, which is a terrible solution that continues to cause data loss for tons of people, and doesn’t work with Mac App Store apps. I have a quick and dirty solution that already works but isn’t ready to be shared yet.
 
Link to comment
Share on other sites

1 minute ago, vitor said:

 

Not an option for me because of Alfred-Workflow. I couldn't rewrite the web.py module to use cURL without dropping a lot of functionality on the floor :( 

 

Otherwise, I definitely wouldn't have upgraded.

 

3 minutes ago, vitor said:

I have a quick and dirty solution that already works but isn’t ready to be shared yet

 

Gimme gimme gimme. Mackup sucks.

 

It's so badly designed, too. I don't really understand how it's so popular.

Link to comment
Share on other sites

Would love to see you release it too. 

 

I've been exploring Nix and nix-darwin recently to fully declaratively specify what my OS uses. Would recommend you guys to check it out, it's really powerful. I don't have brew on my system for over 6 months now and love it. 

Edited by nikivi
Link to comment
Share on other sites

13 hours ago, deanishe said:

Gimme gimme gimme. Mackup sucks.

4 hours ago, nikivi said:

Would love to see you release it too. 

 

The code is terribly simple and slightly embarrassing. I wrote it as one of the first pieces of Ruby I did for myself and it stayed basically unchanged ever since. But it does work. Maybe I’ll make a simple interface for it and publish as is. Right now it’s a bunch of YAML files that contain the paths to backup, and one backup (copy from their sources to a different destination) and one restore (do the reverse) scripts.


Tip: when backing up MAS apps, the issue is that on restore (putting the files in place) the app won’t actually read the settings due to caching. The trick is to defaults read <bundle-id> afterwards. That simple.

 

14 hours ago, deanishe said:

It's so badly designed, too. I don't really understand how it's so popular.

 

Because it’s the only one for macOS, I’d say. It may also help how simple it is to create the files to reference what needs to be backed up. That goes a long way in attracting contributors. I’m pretty sure one of the strengths of HBC is how simple cask files are to read and create. There are things people submit to us that we refuse because they should be formulae (CLI-only and open-source) and the contributor prefers to make their own tap with a cask rather than building a formula that needs to replicate the compiling steps.

 

4 hours ago, nikivi said:

I've been exploring Nix and nix-darwin recently to fully declaratively specify what my OS uses. Would recommend you guys to check it out, it's really powerful. I don't have brew on my system for over 6 months now and love it. 

 

Disclaimer: I’ve been a Homebrew (Cask) maintainer for five years and have never used Nix (though I have looked at it), so my opinion may be biased. Then again, I’ve been thinking of creating a new package manager for experimentation for almost as many years; I’ve been pushing for major changes in HBC ever since I’ve started using it; and even with imperative languages I’ve always defaulted to programming functionally, so may bias might be balanced out.


For brevity in what follows, when I say something “is” a certain way interpret it as “it seems to me that it is” that way.

 

Note: at some point in time, every part of HBC’s documentation has either been written by me or had my input, so I’m pretty familiar with it and take some pride in how it continues to evolve. However, here I’m talking about HB’s documentation, in which I had virtually no say.


Homebrew’s documentation is simpler. The website gets you up and running fast and commands are clear. Want to install something? brew install something. What else can you do? brew help shows you a few commands. Don’t know what they do? man brew explains them right at the top. Main commands are given as words (not flags) so you understand you’re in a specific mode. It’s just brew (the name of the program) followed by an action (install), followed by a package name. Almost as if you’re giving orders to someone.


Compare that to Nix’s documentation. The quickstart is confusing as hell. It uses four different nix- commands: -env, -shell, -channel, -collect-garbage. They give you the short versions of flags (-i, -e, -p) instead of the longs ones, so you don’t even understand what they mean. So, which nix- command should I use? No clue. How many are there? No clue. Let’s try nix --help. Oh, hey, that does output something! Is it useful to clarify which commands exist? Not one bit. Maybe man nix? Nope, doesn’t exist. Alright, nix-env seems to be the thing that installs things, let’s try nix-env --help. What? It opens the man page and has no quick explanation section of what it is. Its description is nix-env - manipulate or query Nix user environments. What does that even mean?!


Every time I looked at Nix I thought of Gentoo. Gentoo is a powerful Linux distribution indeed, but after a while of using it you start to wonder why you’re doing that to yourself.


Note this is not a stab at Nix, but at its documentation. I started contributing to HBC pretty much as soon as I found it, because things were simple. I knew way less back then, and could still navigate it effortlessly; I look at Nix’s documentation now and at a glance and have no idea what’s going on, why I should care, or where I should look to see if I should care.


I see nothing in Nix that does what Hombrew Cask does (install GUI and proprietary apps). Sure, I know they mention it can be used for that, but other than a few open-source darlings (Firefox, iTerm) I don’t see any apps. And it seems they try to do to GUI apps the same they do to CLI apps, which is to separate them from the rest of the system (so what, so does Homebrew), and recommend you link them. Uuh, boy, they’re in for a nasty surprise. If they ever get serious about supporting macOS GUI apps, their whole system will crumble. It happened to us. A too large portion of macOS GUI apps expect to be in /Applications and break (each in their own way) if they’re not there. Not linked there, but there. Plus, you can’t reliably deal with installers and still keep them closed off from the rest of the system and have them work without a hitch. I mean, maybe you can, but get ready for some serious head banging and frustration. One thing I’ve learned with dealing with so many GUI apps is that everything has a specific exception. We had to change our whole modus operandi just to get back on track.


Sure, Homebrew has problems like the confusing beer nomenclature (I never found it to be a problem, but I’ve seen many reports), but it works like I want. Where it doesn’t, no other package manager does. I could expand on it, but I don’t feel like writing a(nother) novel.


In sum, I don’t really see the point in switching to Nix. It won’t actually fix anything and will be worse in important areas.

Link to comment
Share on other sites

The real reasons I stopped using brew over nix is because all the packages I need on brew were on nix and nix was much faster at installing and uninstalling things.

 

But beyond that, I want to use one package manager for everything. I hate how there is npm, go, pip.. who do the same thing. Install packages. I want one interface to install all my packages and this is achievable with nix because nix is a smartly designed DSL that was written to solve the problem of package manager fundamentally. It started as a research project with a whole paper written on it to address why Nix exists and what problems it solves.

 

Sure Nix is much more UX unfriendly than brew. But the only few commands users that have brew use are 'brew install', 'brew uninstall' and 'brew cleanup' (if they remember it exists).

 

In nix it's 'nix-env -f '<nixpkgs>' -iA <pkg-name>' to install and I use 'nix-env -q | fzf | xargs -I{} nix-env -e {}' to fzf search through packages installed to uninstall them instantly. I use this tool to search for packages to install. And if it doesn't exist, investing time into learning some Nix pays off hugely because it's much easier to create package derivations in Nix than ruby (especially complex ones). Also I believe NixOS/nixpkgs is one of the top 5 most active repos on GitHub so your derivation can be merged and helped on near instantly. You can derive packages for your own use of course too.

 

But there is a lot lot more to Nix than that. One of my ideas is to build a universal nix installer that leverages tools like go2nix and npm2nix to install everything with nix. I was inspired how nearly all Haskell packages are distributed with Nix already. Although I was told it was a stupid and impossible to implement idea on IRC. Which by the way is another huge advantage to Nix. #brew on Freenode is effectively dead. #nixos however is one of the most active channels on Freenode. You can get help for what you need in seconds. And Deanishe knows how much I like to ask for help from other people. ?

 

So yeah, Nix just tries to solve package management on a more fundamental level. And it's worth at least learning it just to open your eyes to what is possible.

 

 

 

Edited by nikivi
Link to comment
Share on other sites

13 minutes ago, nikivi said:

nix was much faster at installing and uninstalling things.

 

To each their own. I never bought the speed of install/uninstall argument regarding package managers. You’re not doing it all the time. I’d rather have correct than fast (and Nix might just be both). But even if you were doing it all the time, by far the biggest culprit of slow installs is the time it takes to download something, and that’s dictated by your connection, not the software.

 

1 hour ago, nikivi said:

But beyond that, I want to use one package manager for everything. I hate how there is npm, go, pip.. who do the same thing. Install packages. I want one interface to install all my packages and this is achievable with nix

 

This is also achievable with Homebrew. brew-gem does it for ruby gems. No idea if there are others for Python/Node, but there’s no reason they aren’t feasible.


Also, I’m wary of package managers that manage packages of others. They’ll either have outdated/abandoned packages without you knowing, or if they’re getting updated automatically they’re at the mercy of the originator, and I’d rather not have that. Some problems cannot be solved technically.

 

I’ll add you haven’t addressed my point about proprietary/GUI apps. If Nix doesn’t have them, then it doesn’t have everything. And if it doesn’t have them, then it doesn’t address my needs.

 

15 minutes ago, nikivi said:

Sure Nix is much more UX unfriendly than brew.

 

You say that like it’s a small thing. I have stuff to do. If I wanted to fight with my tools all day I’d have stayed in Linux. The measure of a tool isn’t just power. It doesn’t matter if a tool is the best thing since sliced bread if one can’t understand how to use properly, or if taking the time to understand it overshadows its advantages.


I understand you (you personally) are always trying new tools are trying to optimise the smallest of things. There’s nothing inherently bad in it (quite the contrary!). I’m like that too but fight not to be. It’s the reason I learned vim (which I use to this day); the reason I used Linux in full CLI mode (I even got mplayer working); the reason I switched to Gentoo; the reason I did sometimes monthly, sometimes weekly, and sometimes multiple times a day clean installs of my system. All in the name of perfecting my install scripts and getting the perfect configuration right of the bat.


I’ve managed to scale it down considerably. Now I only do yearly clean installs, and even those are starting to become a chore (good!). Sometimes I still fall off the wagon, like the time I switched to yarn after it was released (in my defence, npm does suck) and eventually went back (no real benefit). It’s the reason I tried the silver searcher (such a great name) and eventually switched to ripgrep. No real regrets there, as it didn’t take long and I use it frequently.


The penny started dropping when I got into college and had to get a laptop, but realised (before I even installed anything) I wouldn’t have the time or patience to do the school work and manage the Linux system all day. So I scaled back to Debian (mild success). Maybe I should’ve joined Linux Admins Anonymous, or something. Eventually, optimisations start to become ricing.

 

39 minutes ago, nikivi said:

In nix it's 'nix-env -f '<nixpkgs>' -iA <pkg-name>' to install and I use 'nix-env -q | fzf | xargs -I{} nix-env -e {}' to fzf search through packages installed to uninstall them instantly.

 

You just described two cryptic operations, and in one of them you needed a non-macOS-native tool as an intermediary between the tool and xargs. If those are typical, you either need to memorise those flags, have aliases for them, or constantly check the help. All those options are bad design.

 

45 minutes ago, nikivi said:

it's much easier to create package derivations in Nix than ruby (especially complex ones).

 

I’d like to see one. But the point doesn’t really hold anyway. Does this look like ruby? No. Remove the (quasi-)boilerplate first and last lines, and it doesn’t even look like runnable code. We get contributions from people who don’t even know how to code, let alone in Ruby, precisely because the DSL is simple.

 

48 minutes ago, nikivi said:

Also I believe NixOS/nixpkgs is one of the top 5 most active repos on GitHub

 

Again, point doesn’t hold. Last year (or was it the one before?) Homebrew Cask was the repository with the most contributions on Hacktoberfest. I know that because they told us. And it was a pretty typical month. We get dozens of daily contributions.

 

51 minutes ago, nikivi said:

your derivation can be merged and helped on near instantly.

 

So do we. If a PR is well done, it’s usually merged in a few minutes.

 

51 minutes ago, nikivi said:

You can derive packages for your own use of course too.

 

brew tap.

 

54 minutes ago, nikivi said:

#brew on Freenode is effectively dead. #nixos however is one of the most active channels on Freenode.

 

Except we are active on different mediums. We go where the users go. Most of our users prefer opening issues, so that’s where we are. Saying “this tool has a chat in the platform I want” only addressed your concern.

 

1 hour ago, nikivi said:

Nix just tries to solve package management on a more fundamental level.

 

I believe you. And I believe they have engineers that are way better than I am at both coding and application design. But I also believe they won’t solve the the proprietary/GUI apps problem while keeping true to their current methodology. They’re yet at the first mistake of thinking siloing apps and linking them to /Applications works. If they expand the amount of apps, they’ll soon find that doesn’t fly. To fix that they’ll need to either:

  1. Modify proprietary binaries. Yeah, no thank you, not taking that chance.
  2. Refuse apps that don’t behave well with that model. Prepare to not have a ton of useful and popular apps.
  3. Convince every developer to change their distribution model. Anyone doubts that’s impossible?
  4. Really solve the issue, in a way that keeps apps working smoothly without modification. I’ll be really impressed and concede!

 

In and episode of Hypercritical (I think either 14: A Dark Age of Objective-C or 15: The Bridges of Siracusa County), John Siracusa commented on what made Rails so popular (and by extension Ruby), when it was so technically flawed, like the first web framework of an amateur. It was the idea of convention over configuration. It’s because the experience of using it was so much better. Technical merit isn’t everything (or else JavaScript wouldn’t have stuck around, let alone rise like it has). People need to get shit done. Documentation matters. Experience matters. Interface matters.


See, I have no doubt Nix is great. If you tell me it’s amazing and academically proven to be the best way to build a package manager, I’ll believe you. I’m a huge fan of functional programming, and in particular would like to use Haskell. But so far all the advantages you’ve mentioned are either things Homebrew can do, or theoretical advantages that don’t (yet?) have demonstrable effects. You also did not address the impactful disadvantage of it not having proprietary/GUI apps. So for now Nix is an ostensibly superior package manager that doesn’t have the packages I need. Why should I switch? The answer is I shouldn’t. Not unless I want to enjoy messing with it, and in that case there are things that I’d both be rather be doing and would be more useful to everyone, like learning Haskell.

 

1 hour ago, nikivi said:

And it's worth at least learning it just to open your eyes to what is possible.

 

Sure, but we can say that of tons of tools. And again, learning Haskell at this point would be a way better return on investment.

Link to comment
Share on other sites

I typically don’t add posts one after another, but separating this might make sense for those who won’t read the walls of text.


I’m glad you found a package manager that suits you. Not every software fits everyone, which is why there are always new tools that do the same in a different way. Nix isn’t a competitor to Hombrew, and neither is Macports. We don’t try to stop people from leaving and don’t try to convert them. Every software has tradeoffs. We’re trying to build the best software we can with the ones we chose, and everyone should use the software that made the choices that best align with their own.


As someone who maintains a package manager and still has thoughts of making a new one to try some ideas, I can claim I’ve thought about this enough to say that at least for now, Homebrew is the one best suited for me.

Link to comment
Share on other sites

1 hour ago, vitor said:

You also did not address the impactful disadvantage of it not having proprietary/GUI apps

 

You can use Nix side by side with homebrew. So there is no issue there. I actually lied when I said I fully deleted homebrew. I still keep it around when there is a package on brew that is not on nixpkgs and I am too lazy to write a derivations (read the docs).

 

Thank you for your comments, I found them to be incredibly useful. I didn't know Homebrew had a Discourse forum, I agree that it's a better choice than IRC in many ways. Although Nix also created a Dicourse forum recently. I hate open source projects who use tools like Slack, Discord for communication. So much info gets lost in these silos with no way to Google for it. ? 

 

learning Haskell at this point would be a way better return on investment

 

You've been meaning to learn Haskell for quite a while now I feel. Why not just dive in and build some stuff with it? I find that's the best way to learn things. Maybe make a Haskell workflow? ?

Edited by nikivi
Link to comment
Share on other sites

2 hours ago, vitor said:

They’re yet at the first mistake of thinking siloing apps and linking them to /Applications works

 

It's just another shade of the same crap that is using npm to install workflows.

 

Based on a one-sentence description, it sounds like a better way, but in practice it's fundamentally incompatible with the way the target system works and thus causes more problems that it solves.

 

Link to comment
Share on other sites

3 hours ago, nikivi said:

You can use Nix side by side with homebrew.

 

But then I’m adding a new tool to manage without needing to.

 

3 hours ago, nikivi said:

You've been meaning to learn Haskell for quite a while now I feel.

 

I have. I even started Haskell Programming from First Principles, which was supposed to be this holy grail book for Learning Haskell, but was unbelievably bored. I see that Lynda has a course in it. I might try it later.

 

3 hours ago, nikivi said:

Why not just dive in and build some stuff with it?

 

Because right now it’s what I want, but not what I need. Can’t justify the time commitment.

 

1 hour ago, deanishe said:

It's just another shade of the same crap that is using npm to install workflows.

 

As soon as I see an npm install command on a Workflow’s description, I close the page. No looking back.

 

2 hours ago, deanishe said:

but in practice it's fundamentally incompatible with the way the target system works and thus causes more problems that it solves.

 

Yep. Summed it up perfectly.

Link to comment
Share on other sites

5 hours ago, vitor said:

supposed to be this holy grail book for Learning Haskell, but was unbelievably bored

I’d give Programming in Haskell book a try: 

 

http://www.cs.nott.ac.uk/~pszgmh/pih.html

 

It’s written but a professor in very good language. It’s what 70%+ of UK unis use for learning Haskell I believe. I started reading it and am enjoying it. 

 

Going to to finish it and rewrite AwGo in Haskell so it’s puure. 

Edited by nikivi
Link to comment
Share on other sites

  • Andrew changed the title to Crash when quicklook-previewing URL (macOS 10.12 bug)
  • 3 years later...

@deanishe @nikivi In case you’re still interested, I finally released my mackup alternative; you’re the first to know. The current list of supported apps is a tad weird, some of them may even be discontinued. I’m not particularly enthused about the problem space of backing up app settings, I just wanted something fairly robust for my needs and it didn’t exit.

 

I’ve been hackilly and manually using snippets of this code over the years and it has worked well, but because it’s only needed on occasion I had been indefinitely putting off making it into a proper tool.

 

I’ll probably expand the list of supported software, but that’s hand waved into the future. I take PRs, the format is dead-simple.

Link to comment
Share on other sites

2 hours ago, nikivi said:


Hadn’t heard of it. But in addition to being a GUI app (which I don’t want), it’s clearly abandoned: the repo starts with “Syncalicious is in its early stages of development” and the last commit was two years ago.

 

In contrast, Tape is probably done. If it works—and for me it does—the core tool probably won’t get many updates, just the definitions.

Link to comment
Share on other sites

  • vitor changed the title to Unrecognized selector sent to instance on quicklooking URL (macOS 10.12 bug)
  • Vero changed the title to Unrecognized selector sent to instance on quicklooking URL (macOS Sierra bug)

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...