press are optional parts of the toolchain but
nib2cib isn’t — it must run using node for the full set of usage cases.
Highlights, fwiw, that we don’t have anything like the testing needed for the toolchain itself. It’s not suprising parts of it are brittle. When teaching software architecture courses in the 90s , it’s what we called ‘an opportunity for improvement’ ;-)
flattenis not yet supported in the Node version but
fontinfois native Mac OS tools and is only needed when running
nib2cibas you say. The need to convert
fontinfoto something else is not high on my list.
gtktestwritten in Objective-J. I have tested myself with a simple Objective-J tool with a shebang like this
#!/usr/bin/env objjand it does now work. The update is in the
Which returns me to my original thinking - the toolchain is very brittle, but any work on it is seemingly best directed at filling in the current gaps when running under node.
This is a bit problematic just yet - both inline and external documentation of toolchain components are Spartan in the extreme, with domain knowledge seemingly gone with the original authors. And, there is an apparent unwillingness to form a consensus on just what should be supported, what functionality is critical, and on what platforms.
fwiw, this comes to mind:
imagesize are currently native macOS utilities. Their normal use is by
nib2cib — this implies that tool should only ever be usable on the macOS platform. Nevertheless, the xib format is XML and thus ripe for auto generation and maniplulation by external tools - on any platform. Should
imagesize be left as-is, or should platform-agnostic versions be substituted, leaving open the option for eliminating
plutil dependance and making the toolchain cross-platform (conceptutually, at least).
As it turns out,
imagesize has other problems. It doesn’t escape spaces in pathnames, and thus fails in the same way the autotools suite does. And, on my own Monterey installation, it is failing to build and install when Cappuccino source is bootstrapped.
One of the (perhaps minor) advantages of moving to node is escaping the prison of autotools requiring pathnames without spaces in.
All other effort should be directed towards filling in the gaps in node support, along with developing a proper C.I. regime for the entire toolchain.
If more than just one person is going to work on this it’s necessary to settle on some guiding principles though.
@daboe01 I agree philosophically. There is, though, a potential advantage for some workflows in running C.I. or deployement/packaging processes on a non-macOS platform. In particular, our tool chain is brittle — in part because it isn’t subject to the same amount of automated testing.
This lack of automated testing is particularly acute with those tools which are macOS-native. It’s arguable that logistical difficulties in setting up automated tests for those native tools are partially responsible for the lack of testing. Compilers and other tools are often more difficult to test, so it’s not the only reason.
Jakefileto fit my structure!
jake buildI get this error
bach@mbp14 _cappDevelop % jake build (in /Users/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/Projekte/Websites/WWW-michaelbach-de/ot/ang-Bourdon/_cappDevelop) options.args: Resources/MainMenu.xib,/Users/bach/Library/Mobile,Documents/com~apple~CloudDocs/Bach/Projekte/Websites/WWW-michaelbach-de/ot/ang-Bourdon/_cappDevelop/Build/Debug/capp/Resources/MainMenu.cib options.args.length > 2, will crash
jake releasethe Resources folder remains empty.
options.argsoutput does not appear in the user where everything works. Is the path possibly too long?
index.htmlI only use relative paths, and don't use spaces. But somewhere during the compile process the path is expanded to full length, and near its "upper end" (see above) there sits "Mobile Documents". So I don't see where I could insert a soft link.
jake releasethere and find the same crash. So unfortunately this does not help. Of course I could move my actual tree with all of ~100 Capp. programs out the of iCloud tree, but would loose synchronising across machines (unless switching to some other offer, with its own problems). So here's to hoping it's only very little work to fix the Node branch to make do with spaces in path names (escaping or only use relative paths). Would love to fully switch to the Node branch!
(in /Users/bach/…; after the second
options.args: … will crashoccurs, and this is generated within nib2cib in a parsing context. Of course, once that is fixed, there might be more places later… or not… :)
nib2cibwith one or more spaces in the path to the
.xibfile. I have made a fix in this branch: https://github.com/mrcarlberg/cappuccino/tree/nib2cib_space_in_path. You should be able to install that version with the instructions from the wiki under the headling "... from source ....". Use above path to the repository and the branch
git clone https://github.com/mrcarlberg/cappuccino/␍ cd cappuccino␍ git checkout nib2cib_space_in_path
npm WARN read-shrinkwrap This version of npm is compatible with lockfileVersion@1, but package-lock.json was generated for lockfileVersion@2. I'll try to do my best with it! npm ERR! code ENOENT npm ERR! syscall rename npm ERR! path /Users/capp/Documents/Cappuccino/cappuccino/node_modules/.staging/@objj/utils-ef80a171 npm ERR! dest /Users/capp/Documents/Cappuccino/cappuccino/node_modules/@objj/utils npm ERR! errno -2 npm ERR! enoent ENOENT: no such file or directory, rename '/Users/capp/Documents/Cappuccino/cappuccino/node_modules/.staging/@objj/utils-ef80a171' -> '/Users/capp/Documents/Cappuccino/cappuccino/node_modules/@objj/utils' npm ERR! enoent This is related to npm not being able to find a file. npm ERR! enoent …
.patch to the commit URL, then save locally. Your browser (Safari at least) will likely want to append
.txt to the file - the file can be named whatever you want, but make the extension
Then, use the branch of cappuccino you’ve normally been using (with a quick fork, if you wish) and apply the patch -
git-apply path/to/patchfile. This should avoid differences in the npm lockfile?
fontinfotakes a path as an argument
NAME fontinfo -- retrieve information about a font SYNOPSIS fontinfo [-n] font [size [string]] DESCRIPTION fontinfo is a tiny utility that returns information about a font. The font name must be a full PostScript name, not a display name. So you would use something like "LucidaGrande-Bold", not "Lucida Grande Bold". The size can be any floating point number
@michaelbach We’re likely best off supporting only the current LTS version of Node (now at 16). I use the macOS installer package from nodejs.org — I normally avoid Homebrew (it has an idiosyncratic and unconvential perspective on best practices for package management) and use MacPorts. In this case, the MacPorts package has a Python3 dependency (which seems gratuitous), so the canonical installer seems the best bet.
When trying out a change on a source installation which has suddently broken, a quick branch from the last known working version, followed by any changes, is the sanest way to keep a production environment in working order. Reversion is a quick Stash and Checkout away. I keep a collection of patches proven to work for Github PRs which have yet to be merged but are otherwise safe.
It’s usually easiest to apply a patch, if those changes originate elsewhere. If a Git GUI client doesn’t have an option to apply a patch, the client is probably overly-simplistic, immature or otherwise not a good candidate for regular use. Having said that, one can always use the command line to apply a patch.