Archive for the 'Mac' Category

Vice 3.1 Mac OS X

I’ve compiled vice which is now compatible with 10.9+. The official build is only compatible to 10.12. In order to compile it on my system (10.11) I did:

  • Install Xcode and command line utilities
  • Download a 10.9 SDK: Old SDKs
  • Patch the build file: remove the “clang workarounds for now” (line 198-201) of file “build-vice-dist.sh”
  • Start the build tool: DEV_BASES=/Library/Developer/CommandLineTools/ /Users/alx/Develop/Vice/vice-3.0/build/macosx/build-vice-dist.sh x86_64 10.9 clang cocoa dmg

Vice-macosx-cocoa-x86 64-10.9-clang-3.0 (29.1 MiB, 4. January 2017)

Update: compiled Vice 3.1

Vice-macosx-cocoa-x86 64-10.9-clang-3.1 (77.3 MiB, 1. September 2017)

Vice-macosx-sdl-x86 64-10.9-clang-3.1 (79.7 MiB, 2. September 2017)

Copy sparsebundle to disk on Linux

I’ve figured out an pretty easy way to copy the contents of a OS X sparsebundle onto a whole disk on linux.
First go into the Image.sparsebundle directory and have a look at the Info.plist. You need the values for size and band-size.
Now in a shell enter:
for i in $(seq 0 $(({size}/{band-size}-1))) ; dd if=`printf "%x" $i` of={/dev/sdx} bs={band-size}c seek=$i ; done
All in one line and replace everything in curly braces with the desired value, e.g. “{band-size}” => “8388608”.

FireWire hard disk emulation

I’ve discovered a way to use a file on a computer as a FireWire Harddisk for another computer. This is a handy way to work with older Apple computers because it’s way easier than burning CD’s or using a read FW HDD.

The setup is not that complicated but still there is some to do.

Continue reading ‘FireWire hard disk emulation’

TextWrangler remote control

Do you ever wanted to open a file while logged in a remote server via ssh on your local TextWrangler/BBEdit? Now that’s possible!

TextWrangler/BBEdit can open files per sftp (via ssh). This set of tools allows it you to launch edit on a remote server, but your local TextWrangler/BBEdit opens the file.

Get it here: TextWrangler remote control

BBEdit: I haven’t tested it, but it should also work. (I do not own BBEdit)

Apples Integers

I was wondering whether I should use int, long or NSInteger. It took me a bit but I figured it out!

On OS X and iOS the following table shows you the the size of the types:

char       8 bit
short     16 bit
int       32 bit
long      system size
long long 64 bit

So, on 32bit OS X long is 32 bit, on 64bit OS X it’s 64 bit (unsure for iOS).

NSInteger has always the size of an pointer.

Often asked: “Use int or NSInteger?”. Answer: use NSInteger for pointers, ok usually you should use the pointer type itself, and for everything else use the size you require.

If you want exactly 8 bits, use int8_t for sigend or uint8_t for unsigned, for an integer which has at least those bits, use (u)int_least8_t (analogue for 16/32/64 bits).

Performance: you can use (u)int_fast8_t for the fastest type, which can hold (u)int_8_t. But since (u)int_leastY_t and (u)int_fastY_t are defined as (u)intY_t on OS X and iOS it should make no difference. I use the direct types for when all the bits are used, and the fast types when I don’t use exactly but less bits.

At last: don’t forget the LL or ULL suffix for 64bit constants (you can use (U)INT64_C(num) for always the correct suffix, also for 8/16/32), and the “%lld” in a formatted string for 64bit variables.
(example: NSLog(@"number: %lld", 1LL << 48);)

If you have more information or maybe corrections, please post a comment.

Easy Currency FAQ

Continue reading ‘Easy Currency FAQ’

Widgets

Continue reading ‘Widgets’