This algorithm produces biased result with probability 1/2^(32-bitwidth(N)). Using 64 or 128 random bits can make the bias practically undetectable. Comprehensive overview of the approach can be found here: https://github.com/apple/swift/pull/39143
Yes, very nice. But it needs an update on structured documents (tree-like, as in HTML). And, ideally, it should be accompanied by work that addresses collaborative editing in such structured documents.
Is there finally a way to renew the certificate without taking down the web server listening on :443? This was the major thing missing from being able to deploy it in production.
Caddy (currently in beta) will issue and renew SSL certificates automatically with no downtime (on Linux; Windows has very brief downtime during restarts).
I can confirm that Caddy + Let's Encrypt is the most seamless and awesome way to run TLS. I did this last night for one of my LE beta whitelisted domains and it took MAYBE 4 minutes. Caddy did all the work. Kudos to the Caddy team for such a great admin experience.
Carbon components warning is because cmus currently uses libao for the sound output on OS X by default. If somebody will contribute a native OS X output plugin, it will be gone.
Thanks. I am most probably on exit route from anything Apple or Google so most likely next cmus will be playing on native Linux for me. Off topic but Apple increasingly makes it easier to make such decision.
I've been using cmus for a few months now. After trying countless music players on Linux and feeling frustrated that none of them ever felt right, cmus was the first one I thought I could get used to. In fact, I think it's the first project where I'd rather contribute new things than try to find a new project where more things feel right. So if I ever find the effort, I'll see about digging through the code and adding a couple things.
I noticed that after adding a folder to the library, it simply adds all the filepaths in that folder to lib.pl. It doesn't cache any of the metadata. This means that it has to rescan everytime. I'm wondering what thoughts went into that design decision. On the one hand, it's very easy to manage, since it's just a list of files. On the other hand, for large collections, startup time can be considerable. I have 109GiB of music, but with a top of the line SSD, it only took ten or fifteen seconds to scan the whole thing, which isn't bad.
On a similar note, it appears that because it adds all the files to the lib.pl file, and not the top level directory I added, it doesn't have any support for noticing when new files are added to my ~/music folder. This means I have to re-add ~/music when I add files to it. I guess that's not too bad. And I assume it won't add duplicates or anything if I re-add the root level directory. But what about when I remove items? Will it be smart enough to detect that they're not there? (An algorithm like: "I just traversed a directory for which there is an existing file entry in lib.pl, but during this traversal I didn't see it. I should therefore remove it.")
Cmus does cache all the metadata — in the file named, unsurprisingly, «cache». You can restart cmus, and notice that the startup will be instant (even on an HDD with 100+GiB of music).
Re-adding the ~/music should work fine. There is also an `:update-cache` command which will update the metadata for all (changed) files, and remove the missing ones.
Another thanks here. I'm between cmus and mocp at the moment due to the segfaulting bug on Debian[0] but might try to compile the latest version from source if these have been squashed upstream...
Please give the latest version a try. I am not aware of any segfaults that have not been fixed upstream. Debian packages a really ancient version of cmus for some reason.
Thanks for the encouragement. Had a bit of fun getting it to build correctly[0], but got there in the end! Would love to create a new Deb package but haven't done it before, am short on time etc. - maybe another day.
For future reference: Always start with `apt-get build-dep packagename` Whenever you are trying to build a newer version of some software that debian also packages. There is no reason to start from zero and have to discover this information for yourself one build error at a time. If you want to see what the `build-dep` list is without actually running `build-dep` try `apt-cache showsrc packagename`
Would be neat if you could also include streaming services like Pandora. I use Pianobar https://github.com/PromyLOPh/pianobar for Pandora would be nice to have some streaming tie ins. A one stop music resource so to speak. A book mark system to listening to Internet radio like cmdradio https://cmdradio.codeplex.com?
Thank you! I struggled with that for so long, and ended up installing via brew after giving up on a source build. Weird that even that process didn't set up the rc file properly.
One thing I would love to see is a folder-based music view like you have artist/album views.
I don't tag my songs, I just organise them in folders about three levels deep. What I'd like to see is a folder tree of my music folder on the left and all the files in that folder, plus all subfolders recursively, on the right. The only player I remember getting this right was amarok (now clementine). I've never once in my life ever wanted my songs listed by album or artist. I have my file manager to organise my files and they're already organised. It's really silly to ask me to organise them again in a different way that doesn't really fit my organisational style.
Moc does that. If like me you're not a music player guy you can use mplayer in slave mode, reading from a playlist created with `find | sort`. I made a script to do that and some other stuff. https://gist.github.com/afarah1/e8cbafaf1d9d8029c6ca
Ditto - automatic organisation by metadata might be nice if metadata wasn't universally inconsistent and incomplete. I tried manually fixing my whole library and it was nice for a couple of weeks, but there's so much ongoing maintainence overhead that OS-level folders are the only thing I bother with any more :(
one possibility might be to let beets handle all the music organization while cmus just leverages that to provide different views on that data using beets.
The metadata doesn't even reflect the way I think about music. And what do you do with movie OSTs, which are by ten different artists and some are songs from other albums? It's just madness.
I use beets for tagging, and it has no trouble with OSTs. It sets a different tag for Album artist and Track artist, and cmus uses the Album artist. Most soundtracks of the type you mention are under <Various Artists>.
I'm different from most people in that nearly all of my music collection is complete albums, so if that's not the case, then I could see how a file/folder layout would work better, and the artist/album view is more full-featured than the file-browser view.
[edit]
Also as far as I can tell, there's no way to filter based off of path (only filename) which might also be a good way if you prefer directory based organization.
I tag my music through MusicBrainz (https://musicbrainz.org/) and I generally don't have to worry about metadata anymore. I generally try to correct anything I find that's wrong. abcde + picard + ncmpcpp.
While that undoubtedly sounds very impressive, IMO tests should not be what you use to ensure that your software is correct — in my opinion, they can be actively a bit harmful by giving you a wrong impression of correctness.
Just take a look at https://www.sqlite.org/changes.html — after the recent 3.8.0, there were 2 bug fix releases separated by 3-4 days (!), with bug descriptions sounding relatively, hmm, trivial, should I say?
I use SQLite, and consider it a great software; just want to make a point about my own dislike of over-reliance testing. Hight-level languages and strong (automatically) provable invariants should be our basis for writing reliable software, not C with a ton of tests.
1. 3.8.0.2 fixed a logical error in the code. High-level language won't help you if you invert a logical condition or commit some more subtle logical mistake.
2. Our software also needs to be fast. No one needs a slow database engine. There is no high-level language that beats C on tasks like writing sqlite.
3. Finally, show me that unicorn high-level language with strong, automatically provable invariants and one piece of widely used, reliable software that was written in it.
Sqlite works. Testing works.
If there actually was a credible alternative to C for writing software that is efficient and reliable with requirements that sqlite has, I can assure you that people would use it. The problem is: it doesn't exist.
> 3. Finally, show me that unicorn high-level language with strong, automatically provable invariants and one piece of widely used, reliable software that was written in it.
Not implying that this is true now, but this is the specific goal of Rust, with Servo.
With its current design trajectory, Rust won't be able to prove interesting high-level invariants. It's going to give you the kinds of things you can prove with traditional ML-style type systems and affine types. The combination of the two lets you encode some interesting things, e.g. typestates, but they won't let you express something like "this browser engine correctly implements CSS".
Most high-level languages have the drawback that they usually cannot inter-operate with anything else, or if they can, it gets very ugly. This begins with C++ being impossible to consume from anything else than C++ and certainly doesn't stop with Java or similar languages. For a portable, low-level library that aims to exist nearly everywhere I doubt there is anything better than C.
And you'd need tests either way. With certain high-level languages you could reduce the need for valgrind and signed integer overflow tests perhaps, but nearly all other test (and thus error) classes remain. You will want to be safe from regressions, you will want to make sure that you can recover gracefully upon process termination, OOM or power failures. You also want to make sure that your SELECT doesn't yield different result sets than other database engines for the same data set.
All those cases are not going away, just because you use a different language. And proving things correct necessitates that your formal model accurately describes what you want to create. Bugs in said model will still be bugs in the application, even if you proved that the application conforms exactly (which still isn't easy).
For interview purposes, I build a LEGO Mindstorms framework to push the buttons and check that the correct LCD segments light up. And wait several weeks while it runs through a sufficient number of iterations to give some assurance of correctness.
For real-world purposes, I see if it turns on and gives me 4 when I do 2+2. If it fails, I buy a new one off Amazon.
Yeah - it's ludicrous to suggest provable constraints will ever really achieve anything close to the coverage these tests have.
Having said that, if you have the choice, it's still unwise to spend huge amounts of time writing+maintaining tests but then balk at the relatively short amount needed to use a strong type system. It won't catch lots of things, but it will catch quite a few. For the limited concepts it can express, it can ensure correctness more rigorously, easily and quickly than any testing can. Might as well use the easy method where you can, right?
But sqlite is old and extremely portable - the only language that springs to mind would be C++. And while that does provide advantages, it's a bit of a stretch to claim those would merit a rewrite.
If you don't actively maintain the tests, then yes you can get a wrong impression of correctness. But when done properly testing helps ensure a certain level of correctness and old bugs don't reappear. A good rule to follow is to create a test(s) for each bug and run the tests on every check-in which is pretty easy with continuous integration. This will mitigate most bugs before they reach production. And the ones that do reach production get fixed...forever.
Making changes again at the same place where a bug was fixed previously is a common offender. At least at my workplace we have regressions every now and then (and thanks to no test suite those sometimes make their way to the customer, yay). Basically every time you touch code you have the potential to break something. Even more so when a bugfix was done by adding code, not by changing it. People might accidentally rewrite the fix. If you have no tests that ensure that functionality stays that way it can be easy to break things in the process.
From my days as a release/build manager, the most common cause of this was people merging code from branches where fixes had been overlooked and similar horrors. The second highest would be people fixing something that "looked wrong" but was actually there to solve a problem.
Yeah I should have probably used the technical term: regression. It is very easy to do. Sometimes it happens when code is rewritten/refactored. Sometimes a new feature utilizes a buggy code path that was not previously used/tested. Etc.
There are no automatically provable invariants that would cover SQLite's functionality. How does a tool automatically prove that a query compiler is correct, for example? I don't see an easy way, barring writing SQLite in Coq.
Your choice of language can help you avoid, or even completely eliminate, certain types of defect.
But no language is ever going to prevent you from coding the wrong intent into your application - your programming language has no idea whether (for example) you are intending to keep or omit a left join in your optimisation routine.
