Tag: devtools

Programming in C

On tbasic, I've been doing all my C coding in BBEdit, not fucking Xcode, and it is fantastic. Doesn't crash. Syntax highlighting works, and by "works" I mean doesn't replace my text with Cyrillic as Xcode is wont to do (I do not like the new BBEdit color theme editor, but it's a far cry from stabbing me in the face like Xcode does). BBedit's window stays where I fucking put it, and sidebar shows clearly which files are open and modified. Running make from iTerm2 works fine, if you aren't an idiot and each compile produces less than a handful of errors. I can't really use BBEdit for JavaScript which needs more tool support, but for simpler languages, it's fine.

OS X Mojave no longer has C man pages visible anywhere I can find, so Dash is the only way to look anything up:

To use it from the shell, create dashman: (hashtag command-line integration, I couldn't find this in any search, and Dash has no AppleScript which is my usual solution to o'erweening GUIs)

#!/bin/zsh
open "dash://$*"

Hm. So, I've worked with people who don't learn their languages, they just rely on autocomplete in an IDE, snippets, and StackOverflow. If this is you, if you can't code without an Internet connection, you can't code. Please stop programming, go away, and read a book until you know the syntax and fundamental APIs, because right now you do more harm than good.

That said, while I studied K&R (and Stephen Kochan's Programming in C, my introduction back in the '80s) with the intensity of a snake-handler reading his Bible, I certainly can't remember every strcspn, strcoll, strstrn or whatever random series of 7-letter identifiers they had to use back in the '70s (even in the late '80s, I was still using C compilers which only distinguished 7-letter identifiers). C's libraries are often gibberish and searchable man pages are all we have.

Chicken Soup

(a bunch of stuff in a pot)

REPL

The Chicken csi REPL is appalling after using some nice REPLs, it doesn't even have history by default. I couldn't reliably get non-GNU readline-likes to work, so:

% chicken-install -sudo readline
% cat >~/.csirc
(use readline)
(current-input-port (make-readline-port))
(install-history-file #f "/.csi_history")
^D

So at least now it has the usual up/down/emacs-like keys.

Long fucking ways from the old Symbolics LISP Machines. Why don't we have environments like that anymore? Why is everyone content to just use fucking emacs (I've never been emacsulated) or other editor, and a boring REPL? DrRacket is just a REPL that destroys its memory every time you edit code, and it's the most graphically advanced LISP-type environment. And this is why I still just use Atom with Symbols Tree View (even though it thinks variable definitions are functions), and copy-paste into iTerm if I want to test something.

Value Unpacking

Not having nice R6RS macros for this, and unwilling to fight with classic macros, I've been using values to unpack lists into variables, and because I can never remember the exact syntax, I made this cheat-sheet:

(define a '(1 2 3))
(define b '(4 5 6))
;; then one of these:
(define-values (x y z) (apply values a)) (printf "~s,~s,~s\n" x y z)
(set!-values (x y z) (apply values b)) (printf "~s,~s,~s\n" x y z)
(let-values [[(x y z) (apply values a)] [(q r s) (apply values b)]] (printf "qrs:~s,~s,~s xyz:~s,~s,~s\n" q r s x y z))

Probably not efficient, but better than car, cadr, caddr, etc. Maybe I should move all my list-structures into vectors, but then I'd still have to convert them to lists half the time. Here's where Python is the programmer's best friend, even if it is 10,000x slower:

a = (1, 2, 3)
x, y, z = a
print(f"{x},{y},{z}")

Why Did LISP Fail?

How did a more advanced language with better tools just die off commercially, and now if you want to work in it, you have to cobble together a bunch of half-broken shit?

I think there's 3 reasons:

  1. It's hard and ugly. It may be logically compelling, but when you see a page of parens your brain panics and looks for a place to hide.
  2. Companies value the fake productivity of thousands of lines of C, Java, or Swift (aka C++2020) code more than having safety, security, and correct reasoning. Who cares if millions of people will suffer and possibly die from your code, as long as you can ship TODAY?
  3. A lot of LISP "hackers" are insufferable douchebags, both old beardy fuckers who've been doing it for 50 years and mewling children who learned it last week. Every new variant makes the older contingent more angry at even seeing a mention of it, and the sneering fetuses think whatever variant they learned is Divine Wisdom, rather than just an engineering tool that may need to be improved.

Text Filter

  1. I need a utility to filter some text, like awk but more modern regexp.
  2. Start writing utility.
  3. Discover I wrote this exact utility in 2006, and forgot about it. Apparently I did something with it in 2009. I may have blogged about it on my old site, too lazy to go searching.
  4. Clean it up for Python 3.7 and release.

Utility/Filter 1.1 can be downloaded, put it in your ~/bin or /usr/local/bin folder and call it with Filter.py -h.

BSD license, so do what thou wilt with it, but don't be a dick (uploading my stuff to github as if it's yours is dickish), OK?

Xcode Packaging

Speaking of packaging, a thing I hated in Xcode, which made me wish to be filled with nuclear fire, transformed into Godzilla, and stomp thru 1 Infinite Loop, was the package structure:

foo/
    foo/
        foo-Info.plist
        foo-Prefix.pch
        foo.entitlements
        all source, images, and config files in a single giant mess, regardless of "groups"
    foo.xcodeproj/
        foo.xcodeproj/
            project.pbxproj
        project.xcworkspace/
            contents.xcworkspacedata
            xcshareddata/
                foo.xccheckout
            xcuserdata/
                mdh.xcuserdatad/
                    UserInterfaceState.xcuserstate
                    WorkspaceSettings.xcsettings
                    xcschemes/
                        xcschememanagement.plist
        xcuserdata/
            mdh.xcuserdatad/
                xcdebugger/
                    Breakpoints_v2.xcbkptlist
                xcschemes/
                    foo debug.xcscheme
                    foo release.xcscheme
                    xcschememanagement.plist
    fooTests/
        more sources

Are you fucking kidding me?

Groups aren't folders, they're just keywords grouped together until Xcode decides to fuck you over and disorganize them. To fight the project dump dir, I'd make a group, then add a subfolder, edit the group to reference the folder, and then I could create files in their own nicely-organized subfolder. There is of course no automatic name sorting, because that's a developer convenience and Xcode hates developers.

Test code couldn't be in the same folder as the code it was testing. So you'd edit a file, then edit a test file WAY over in a different tree. Good luck knowing how much coverage you had.

I especially love how foo.xcodeproj/xcuserdata/ and foo.xcodeproj/project.xcworkspace/xcuserdata/ have duplicate structures for develop & run/debug modes, because obviously the runtime and debug teams are separate and hate each other.

Icon Composer

In their ongoing efforts to break Mac development tools, Apple disabled and destroyed the rather nice Icon Composer.app because there's nobody left in-house who could figure out how to generate @2x images (protip: you use double size and rename it!), and now you have to use command-line iconutil with a set of magic filenames and no help.

So I wrote a little shell util, icontool.zsh:

#!/bin/zsh
if [[ $# -ne 2 ]]; then
    echo "Usage: icontool INIMAGE.png OUTFILE.icns"
    exit 1
fi
WORKDIR=$TMP/icontool.iconset
rm -rf "$WORKDIR"
mkdir "$WORKDIR"
sips "$1" --resampleHeightWidth 1024 1024 --out "$WORKDIR/icon_512x512@2x.png"
sips "$1" --resampleHeightWidth 512 512 --out "$WORKDIR/icon_512x512.png"
cp "$WORKDIR/icon_512x512.png" "$WORKDIR/icon_256x256@2x.png"
sips "$1" --resampleHeightWidth 256 256 --out "$WORKDIR/icon_256x256.png"
cp "$WORKDIR/icon_256x256.png" "$WORKDIR/icon_128x128@2x.png"
sips "$1" --resampleHeightWidth 128 128 --out "$WORKDIR/icon_128x128.png"
sips "$1" --resampleHeightWidth 64 64 --out "$WORKDIR/icon_32x32@2x.png"
sips "$1" --resampleHeightWidth 32 32 --out "$WORKDIR/icon_32x32.png"
cp "$WORKDIR/icon_32x32.png" "$WORKDIR/icon_16x16@2x.png"
sips "$1" --resampleHeightWidth 16 16 --out "$WORKDIR/icon_16x16.png"
iconutil --convert icns "$WORKDIR" --output "$2"

Preferably feed it a 1024x1024 input image, it'll resize all the others; the small sizes might be blurry but it's good enough for most uses, and you can edit the contents of WORKDIR and run the iconutil line again if you need to.

Marzipan and Electron

Chris is missing the point of both technologies. And I'm sure not a brat Millennial.

Marzipan (candy frosting) is a legacy porting technology: Existing iOS apps can cost more to port to AppKit than they're worth, but may be worth something as a cheap Marzipan port. Nobody ports their iOS apps to tvOS or watchOS because it's not profitable, and everyone (in the first world with money) has an iPhone already.

I loved my UNIX® workstation Macs after suffering with Linux for a decade+, but Timmy Cook's Apple abandoned the Mac after Steve's death and Scott Forstall's firing. Anyone making new native Mac apps is in an abusive relationship: Apple does not love you, and does not care about the Mac.

I'd rather eat broken glass than run Linux again, and I have never and will never be a Windows weenie, but I'm not relying on Apple to support desktop developers ever again.

Apple's Mac apps have generally been shit for years now, because they won't spend the resources to develop & support their own stuff. iTunes is a bloated pile of crap, half-broken because it has to run on Windows, too; you don't like hybrid web apps? Everything except your library is web or XML rendering. Pages and Numbers were fast, minimally useful apps that got rewritten based on the iOS versions, and are just about useful for a memo or a chart, but not real work. Mail's a clusterfuck and not half as useful as when it supported more scripting and addons.

The new Mac commercials, first in years, show the broken-keyboard laptops and models they no longer make, nobody coding Mac apps, no desktop Macs. Where's that shiny "new" iMac Pro from last winter? Isn't that what a real musician would use? A near-blind photographer squints at a tiny Mac laptop instead of a giant 27" retina display?

This is how technical, developer-oriented Apple ads were in 2002:
apple_unix_ad-s

Electron and Node are the future (along with Elixir, Go, Rust, maybe others?). It's 100x faster and more fun (attach the FunMeter™ somewhere fun) to code in than Swift, you can use any good editor instead of fucking Xcode, do layout with HTML/CSS instead of the rotting corpse of Interface Builder trapped inside Xcode. And it's cross-platform; 95% of the users (even in the first world with money) don't run Mac, because Apple never updates the Macs, they failed utterly to follow-through with Macs behind iPhones. There's 20x bigger market potential.

The future is certainly not banging your head against the Swift and Xcode walls, just to make a pure Mac app nobody will see. You can't make fun of Electron's runtime, which needs Node and Chromium, if you use Swift, which has a giant runtime turd because their amateur hour C++ compiler nerds can't make a stable ABI. The Mac's only future source of native apps is Marzipan ports.

There can be performance problems in Electron, but Slack's an outlier at 196MB binary and devouring 1.2GB RAM(!!!); it's the bloated WalMart-shopping fat-ass of Electron apps. Discord is also Electron, it has a 136MB binary and uses 360MB RAM, and does more, faster and better than Slack. Atom is the original Electron, has a 541MB binary, and uses 600MB RAM, for an entire editor/IDE.

My game currently has a 139MB binary, and uses 200-300MB RAM when running. Comparing to a random casual game from my Steam library, Chainsaw Warrior (well, "casual"; I've only beaten it once on Easy). It's based on Unity (another VM!), has a 249MB binary, and uses 200MB RAM when running, plus Steam itself uses 130MB RAM (I may yet integrate Steam into mine, so that may even out). It doesn't seem excessive.

I can't compare my Swift game prototype from 3 years ago, because it was written in a version of Swift that doesn't compile in any Xcode that runs on current hardware & OS, and Xcode "helpfully" deleted the built binary; who needs working binaries, right? I might have an old Xcode on my old laptop? Maybe I could waste a couple days fixing the code by hand in current Xcode, if I hated myself or loved Timmy Cook's Apple that much?

New languages evolve fast, but I can run 20-year-old Javascript and it'll run thousands of times faster than it did in the '90s, because the language was improved with forwards-compatibility in mind, hardware caught up, and the newer VMs compile & run it faster. I can compile 30-year-old Objective-C, and it'll run.

We had something similar to web tech 20 years ago with desktop Java, but the convicted criminal organization Microsoft sabotaged it and made a shitty single-platform ripoff called C#. Viruses became a problem for applets, which had nothing to do with desktop Java, but killed Java deployment even before Oracle bought & ruined SUN. Android runs on another Java ripoff, but their dev tools and APIs are even shittier than Xcode or C#, and the users are poor, so why make anything for them? Server-side development in Java, Clojure, or Scala, running on the Java VM, is hidden away in a back room, and made as boring as possible.

So now we have to reinvent the runtime, this time with Node & Chromium. OK with me.

Learn2JS

I've updated the Learn2JS shell, which makes it easy to get started writing client-side Javascript.

  • Added eslint tags and an initial config, so you can check for errors while editing.
  • Switched from a Python web server to light-server on Node; even though the shell doesn't use Node directly, it seems more consistent.
  • Added Canvas class to simplify setting up and drawing on HTML canvas.

Any suggestions or feedback? I just use this myself to script things quickly, but I'm happy to enhance it into a better learning tool.

Tower of Babel

Ugly shit from my package.json:

 "scripts": {
    "start": "electron .",
    "build": "rm -rf build && babel app -d build/app && cp -R assets package.json build && cp app/*.html build/app && cd build && npm install --only=prod && cd ..",
    "dist-mac": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.icns' --platform=darwin",
    "dist-linux": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon-256.png' --platform=linux",
    "dist-windows": "electron-packager build --out=dist --asar --overwrite --icon './assets/i/appicon.ico' --platform=win32",
    "dist-all": "npm run dist-mac && npm run dist-linux && npm run dist-windows",
    "dist-help": "electron-packager --help 2>&1 |less"
  },

So I wanted to filter my source through babel-minify.

Build out to a "build" dir… and everything breaks. Copy in assets, package, HTML files… "Missing module". Turns out known issue, closed but I don't see an actual solution: Nuking & reinstalling my node_modules did nothing, and I have latest stable versions (maybe "stable" is the problem?) of everything.

As a brute-force Hulk-smash solution, shoving that "npm install" in the build script works, and is easier than figuring out what I should change.