gtavares@Gustavos-MacBook-Air Browser % ./gtktest @implementation CPBundle (IsEqual) ^ ERROR line 62 in file:/Users/gtavares/Desktop/Browser/gtktest:62: Class CPBundle not found /Users/gtavares/Developer/cappuccino/node_modules/@objj/runtime/lib/objective-j.js:3702 throw "Compilation error"; ^ Compilation error (Use `node --trace-uncaught ...` to show where the exception was thrown) Node.js v17.0.1
@mucholove Returned here to a project after a month’s absence to find
nib2cib refusing to compile xibs that previously worked. Only changes to the machine are a handful of new commits to Cappuccino (including my fixes for
nib2cib), and the 12.0.1 update to Monterey.
Has your system also moved from macOS 12.0 to 12.0.1 in your downtime interval?
In my case, the problem seems to be permissions problems at the
ibtool phase — despite that command working just fine when run manually in the terminal. Don’t have time just now to sort it out though — reverted to using a trusty High Sierra installation.
includeURLsare the paths to the current working directory
/Users/gtavares/Desktop/Browser/gtktestand the current installed version of the Objective-J framework
/Users/gtavares/Developer/cappuccino/dist/objective-j/Frameworks. What is missing is the path to the current installed Cappuccino framework
/Users/gtavares/Developer/cappuccino/dist/cappuccino/Frameworks. I think this is a bug in the
@objj/runtimenode module. I will look into why this is happening.
includeURLsbut could be added manually with the environment variable
Property List error: Unexpected character N at line 1 / JSON error: JSON text did not start with array or object and option to allow fragments not set. around line 1, column 0.
imagesizeneeds to be replaced in the node version — it is used by
nib2cibif a xib contains images.
imagesizerequired if a xib contains an image :-) For the immediate need it can be loaded programmatically, and will be in the final version. I’m wondering what else isn’t quite there, though?
imagesize- is that one of the legacy Java-native tools?
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.