Fish shell does not seem to like to live within the DTerm terminal emulator. Sadly, DTerm seems in a state of abandon.
What I do now is to force bash as the shell used by DTerm. I do this by launching:
env SHELL=/bin/bash open /Applications/DTerm.appThe current Mac Mini has many uses and most of them are not for desktop users. So, what would you want to use a small “cheap” computer running macOS for?
None of these things need a x86 processor.
I bet that whatever replaces the Mac Mini will be the first ARM based Mac. And it will be glorious.
Today my MiKTeX installation stopped installing packages on the fly. After trying to install packages through Package Manager I found out that this did not work either. The error that I have obtained is this:
The executed process did not succeed.
fileName="C:\Program Files (x86)\MiKTeX 2.9\MiKTeX\bin\initexmf.exe", arguments=" --mklinks --mkmaps", exitCode="1"I googled around and found out that this might be a problem with the installation folder not being accessible and the suggested solution was to install MiKTeX somewhere else (or just for the local user). This was not an option for me as a toolchain that does not depend only on me requires the latex binary to be in the default folder.
My solution was to go to the C:\Program Files (x86)\MiKTeX 2.9 folder properties and changing the Users permissions to Full Control. Not extremely secure but at least now I can build my documentation.
It is always annoying when people expect you to collaborate with them and they send you locked files.
This trick only works for documents that are protected for Review. Not when you can not even open them.
So, let us assume you have a Protected.docx file that looks something like this. Notice the disabled Delete Comment, Accept Changes and so buttons.
A good thing to know is that .docx (and .xlsx) files are just zipped folders.
Rename the Protected.docx file to Protected.zip and unzip it. You will obtain something that looks like this:
Open the file word/settings.xml. Its contents will look somewhat like this (except there will be more of it and everything will be on the same line):
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<w:settings xmlns:mc="http://schemas.openxmlformats.org/markup-compatibility/2006" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:r="http://schemas.openxmlformats.org/officeDocument/2006/relationships" xmlns:m="http://schemas.openxmlformats.org/officeDocument/2006/math" xmlns:v="urn:schemas-microsoft-com:vml" xmlns:w10="urn:schemas-microsoft-com:office:word" xmlns:w="http://schemas.openxmlformats.org/wordprocessingml/2006/main" xmlns:w14="http://schemas.microsoft.com/office/word/2010/wordml" xmlns:w15="http://schemas.microsoft.com/office/word/2012/wordml" xmlns:sl="http://schemas.openxmlformats.org/schemaLibrary/2006/main" mc:Ignorable="w14 w15">
<w:zoom w:percent="100"/>
<w:proofState w:spelling="clean" w:grammar="clean"/>
<w:trackRevisions/>
<w:documentProtection w:edit="trackedChanges" w:enforcement="1" w:cryptProviderType="rsaFull" w:cryptAlgorithmClass="hash" w:cryptAlgorithmType="typeAny" w:cryptAlgorithmSid="4" w:cryptSpinCount="100000" w:hash="1+kEXOhPYpKExv2F8dIx9VCN5Ps=" w:salt="aOdV7QoW4ZJW3KVDxd7jBg=="/>
<w:defaultTabStop w:val="720"/>
<w:characterSpacingControl w:val="doNotCompress"/>
<w:savePreviewPicture/>
<w:compat>
<w:useFELayout/>
...Notice the
<w:documentProtection w:edit="trackedChanges" w:enforcement="1" w:cryptProviderType="rsaFull" w:cryptAlgorithmClass="hash" w:cryptAlgorithmType="typeAny" w:cryptAlgorithmSid="4" w:cryptSpinCount="100000" w:hash="1+kEXOhPYpKExv2F8dIx9VCN5Ps=" w:salt="aOdV7QoW4ZJW3KVDxd7jBg=="/>this is the source of our woes. Now, simply remove the characters between <w:documentProtection and the first /> you encounter after it. Save the file.
Now, zip the folder back again. It is important that you compress the files as they were: the folders word, _rels, docProps and the file [Content_Types].xml are on the top level of the zip (i.e.: not in a subfolder that was probably created when you unzipped the original file). Let us call the new file Unprotected.zip
Finally, rename the file back to Unprotected.docx.
And voilà:
Note: Word might complain about the document being corrupted, simply choose Open Anyway and re-save the file again.
It is interesting that when you move, suddenly everybody you talk to has a cousin with a moving company.
And then they are disappointed that you have went with a professional rather than gamble on a small, family-held, business.
I had a problem. First I have set up an UITextView with these parameters:
view.backgroundColor = UIColor.blueColor()
view.text = "An example text"
view.textColor = UIColor.whiteColor()
view.textContainerInset.top = 0
view.textContainerInset.bottom = 0I wanted to be able to centre the text in the view vertically. This should be easy, one just needs to position the top of the text according to the formula: top = (container.height - content.height) / 2. However, when you look at the actual look of the UITextView you will see this:
view.font = UIFont.boldSystemFontOfSize(100.0)
view.font = UIFont(name: "DINCondensed-Bold", size: 100.0)
Ouch, there is a semi-randomly placed offset at the top of the text. Turns out the point size of a font is not always the one you have demanded. However it is possible to get the actual height. An UIFont class provides a bunch of useful metrics:
view.font = UIFont.boldSystemFontOfSize(100.0)
view.font.capHeight // 70.5
view.font.pointSize // 100.0
view.font.ascender // 95.2
view.font.lineHeight // 119.3
view.font = UIFont(name: "DINCondensed-Bold", size: 100.0)
view.font.capHeight // 71.2
view.font.pointSize // 100.0
view.font.ascender // 71.2
view.font.lineHeight // 100.0On a graph this would look like this:
Finally, the method you can now use is:
extension UITextView {
func centerTextVertically() {
guard let ascender = view.font?.ascender else {
return
}
guard let capHeight = view.font?.capHeight else {
return
}
view.textContainerInset.top = (view.bounds.height - ascender - (ascender - capHeight)) / CGFloat(2.0)
}
}Note that this will only for one liners and only if you know the height of the UITextView (i.e.: the height was given to it on creation)
The rumour about Apple removing the 3.5mm jack in the future iPhone has wreaked havoc around the Internet. There are several arguments for and against it, but I think there is only one that is valid: it would make it impossible to create accessories for iPhone without going through the MFI process.
Case in point, Apple has recently featured this application in their advert “Ridiculously Powerful”.
This application would probably never exist without the possibility to leverage a cheap and universal interface with the device.
Here is a theory. There have been quite a lot of rumours about a new “iPhone 6C” which ought to have the 6’s internals in a brand new 4” plastic body. However, with no parts leaks this late into summer, the existence of this model is not a given. (side note: there are no leaks for the iPhone 6S plus out either)
We know that Apple has already broken the pattern of older devices moving down the price range with the 5C. I think this year the pattern could be broken again.
After the iPhone 5C was introduced, the Internet was swamped with articles describing how much of a flop it was. The reality is that most people who buy iPhones in October buy the latest and beefiest one.
So, what if Apple introduced the new, plastic, iPhone 6C in September but only made it available in shops in December for the holidays? This would give them approximately until October to ramp up the production, which would explain the lack of the leaks.
Not only would they protect themselves. But they would also get an excuse for the lower number of phones sold.
Edit 2015-09-14
Well, first predition, first failure. My score so far: 0 out of 1.