cappuccino/cappuccino

Web Application Framework in JavaScript and Objective-J

Martin Carlberg

@mrcarlberg

The default behavior is to include the latest installed version. If you need something else you need to add it manually with the environment variable OBJJ_INCLUDE_PATHS

David Richardson

@enquora

@aksuska That was a good suggestion - unfortunately it doesn’t help. Narwhal does have appear to have a security model which could accommodate this, but it appears to be non-uniformly exposed, particularly by the File module.

It turns out that, in my own case, the problem was something else entirely - nib2cib has problems with xibs versioned for support later than the macOS 10.0 or later option. Later than that and there is an increasing matrix of output formats, depending on the xib and ibtool versions.

David Richardson

@enquora

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: fontinfo and 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 fontinfo and imagesize be left as-is, or should platform-agnostic versions be substituted, leaving open the option for eliminating ibtool and 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.

David Richardson

@enquora

My instinct on the original point is to perform minimal patching on the toolchain to allow running on Monterey - if carefully documented constraints are followed, quite possibly with manual intervention (for setting permissions on-disk or in the security control panel).

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

@daboe01

@enquora i personally think it is not worth supporting nib2cib on other platforms than macos.

you can fall back to cappusance if you want a XML-based gui builder

David Richardson

@enquora

@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.

I’m skeptical that having a pure Objective-J + Javascript toolchain will, alone, improve the robustness of the toolchain — but it wouldn’t hurt to have this as an objective.

David Richardson

@enquora

A corrollary guiding principle (with node, at least) should be, imo, that dependecy trees should be no more than 1 level deep.

Gustavo "Mucho Love"

@mucholove

@mrcarlberg - good stuff. will be testing later today :)

daboe01

@daboe01

may 2022 be the year of cappuccino :-)

Michael Bach

@michaelbach

@mrcarlberg My new year's resolve was to move to the Node version :). So I created a new user, copied my Cappuccino programs there, and followed the clear Wiki. Great, everything works after appropriately editing the Jakefile to fit my structure!
Then I tried to do same in my usual user. Switched to zsh, added the necessary path to .zshrc, but: on jake build I 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

It doesn't really "crash", but on jake releasethe Resources folder remains empty.
This options.argsoutput does not appear in the user where everything works. Is the path possibly too long?

Michael Bach

@michaelbach

@mrcarlberg @enquora SOLUTION! (well, beginning of it) Found the reason for "crash" running the node version: in the nib2cip step, it fails because there is a space in my pathname! That is a killer for me: Apple unfortunately chose "Mobile Documents" in the path for iCloud drive… This is, as David calls it, one "current gap … under node". Can that be solved?

daboe01

@daboe01

@michaelbach a softlink may work as a dirty workaround.

Michael Bach

@michaelbach

@daboe01 Thank you. I had already looked into that – why should this work, there is still a space in the path?

daboe01

@daboe01

node would only see your softlink without any spaces

Michael Bach

@michaelbach

@daboe01 Dear Daniel, I don't see how. In my Cappuccino-specific index.html I 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.

daboe01

@daboe01

@michaelbach i was thinking of creating a softlink completely outside your normal tree and cd-ing there for your actual work

David Richardson

@enquora

@michaelbach Is nib2cib the only phase which won’t accept spaces in pathnames?

His certainly is “an opportunity for improvement” - I had hoped the move to node would automatically remove the autotools inability to handle spaces in pathnames.

I’ll take a look at this.

Michael Bach

@michaelbach

@daboe01 yes, I had done that and then looked at the path, saw the space. Now I've done it again (prompted by you), this time tried to jake release there 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!

@enquora Thank you! In the compile phase there's 2 times the console outputs (in /Users/bach/…; after the second
time the message options.args: … will crash occurs, and this is generated within nib2cib in a parsing context. Of course, once that is fixed, there might be more places later… or not… :)

Martin Carlberg

@mrcarlberg

@michaelbach Thanks for finding this problem! I have reproduced it for nib2cib with one or more spaces in the path to the .xib file. 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 nib2cib_space_in_path.

Please let me know if it works for you?

Michael Bach

@michaelbach

@mrcarlberg Thanks for rapid response. No dice for me yet. I did:

git clone https://github.com/mrcarlberg/cappuccino/␍
cd cappuccino␍
git checkout nib2cib_space_in_path

ok? So far so good. Then
npm install produced

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  …

David Richardson

@enquora

@michaelbach Append .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 .patch.

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?

I don’t have time to confirm/test myself until tomorrow morning (west coast North America), but I don’t doubt @mrcarlberg has caught this one.

fwiw, a patch is the diff which git works with. Github simply layers a workflow on top of them, with their own terminology.

Michael Bach

@michaelbach

@mrcarlberg @enquora Thanks, but I give up for tonight; I'm still not conversant enough with git, oh my… I apologize for not sufficiently understanding your kind recipes.
One thought: Does fontinfo also need to be patched with respect to spaces in the path?

Martin Carlberg

@mrcarlberg

@michaelbach What version of Node do you use? (node --version from the command line can tell you that)

I don think fontinfo takes 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

Michael Bach

@michaelbach

@mrcarlberg node -v⏎v17.3.0. Ah, in the other user (where I tried to install your patch) it's v14.17.4. Yes, of course you're right, fontinfo needs not be considered. One problem less :)

Martin Carlberg

@mrcarlberg

I'm using Node version 16 which is the current LTS. Should work with version 17 too. Earlier versions might have problem

Version 14 is probably to old....

Michael Bach

@michaelbach

Strange: if I do brew update↩︎brew upgrade node it stays at v17.3.0 – maybe Homebrew is a bit behind.

Michael Bach

@michaelbach

Progress: In the special user, where I test the Node version of Capp, the paths did not point to the more current Node. Corrected, so Node is v17.3.0 there too, and now npm install runs w/o error. Great! Proceeding…

David Richardson

@enquora

@mrcarlberg Works as expected. Thks.

David Richardson

@enquora

@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.

Michael Bach

@michaelbach

I am pretty sure that I'm now running the spaces-patched Cappuccino-Node version, and it does break when a space is in the path. Only with Xib-based applications, the simple HelloWorld of the Wiki works fine. When I removed the space in the path for counter-testing, another problem cropped up: "fontinfo can't be opened because Apple cannot check it …". Possibly because I manually copied all binaries from the cappuccino-nib2cib_space_in_pathdest library to the ~/.npm/… folders?

@enquora I'd like to stick with Homebrew, because my Jekyll-based site with many many files is based on it, and I now know at least a little my way around in Homebrew.

David Richardson

@enquora

@michaelbach fontinfo is a compiled binary - it’s subject to Gatekeeper signature/integrity checks.

Use which fontinfo to confirm the location of the instance you’re using. xattr -d com.apple.quarantine /path/to/fontinfo will remove the quarantine flag. It’s possible it was set when copying.

Martin Carlberg

@mrcarlberg

@michaelbach I found an error in the capp template Jakefile for NibApplication about the build directory but I can't replicate your problem. I have committed a fix to the branch.
The following is working for me with this fix:

martin@marm ~/L/M/c/D/t/cappuccino (nib2cib_space_in_path)> capp gen -t NibApplication MyTestNib
Creating Frameworks directory in /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks...
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/objective-j/Frameworks/Objective-J ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/Objective-J
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/objective-j/Frameworks/Debug/Objective-J ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/Debug/Objective-J
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/cappuccino/Frameworks/Foundation ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/Foundation
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/cappuccino/Frameworks/Debug/Foundation ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/Debug/Foundation
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/cappuccino/Frameworks/AppKit ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/AppKit
Copying /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/dist/cappuccino/Frameworks/Debug/AppKit ==> /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib/Frameworks/Debug/AppKit
martin@marm ~/L/M/c/D/t/cappuccino (nib2cib_space_in_path)> cd MyTestNib/
martin@marm ~/L/M/c/D/t/c/MyTestNib (nib2cib_space_in_path)> jake build
(in /Users/martin/Library/Mobile Documents/com~apple~CloudDocs/Developer/test test/cappuccino/MyTestNib)
Compiling [Browser] AppController.j...
Compiling [Browser] main.j..
Creating static file... /Users/martin/Developer/Build/Debug/MyTestNib/Browser.environment/MyTestNib.sj
Compiling [CommonJS] AppController.j...
Compiling [CommonJS] main.j..
Creating static file... /Users/martin/Developer/Build/Debug/MyTestNib/CommonJS.environment/MyTestNib.sj
----------------------------
Debug app built at path: /Users/martin/Developer/Build/Debug/MyTestNib
----------------------------
Calculating application file sizes...
Executables: 19443119, sprite data: 476594, total: 19919713
Build took 1 second
martin@marm ~/L/M/c/D/t/c/MyTestNib (nib2cib_space_in_path)>

Michael Bach

@michaelbach

@mrcarlberg Thank you for all your efforts, and obviously your iCloud-placed version works. My previous report "spaces still crash" may have been erroneous, because I think I forgot to checkout the pertinent patch. So I start from ~zero. Node is v17.3.0. I clear out the directory ~/.npm. Then I follow the wiki and do npm install -g @objj/cappuccino. Success, and capp gen HelloWorld works. Next step:
I go to a suitable directory and do git clone https://github.com/mrcarlberg/cappuccino.git. No errors, and git status after cd cappuccino says "working tree clean".
Then git checkout nib2cib_space_in_path results in "Switched to a new branch 'nib2cib_space_in_path'", looking good so far. Next, following the wiki:
npm install. Here various errors crop up:

bach@mbp14 cappuccino % npm install
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/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/myProgs/Cappuccino/cappuccino/node_modules/.staging/@objj/utils-ce17aa86
npm ERR! dest /Users/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/myProgs/Cappuccino/cappuccino/node_modules/@objj/utils
npm ERR! errno -2
npm ERR! enoent ENOENT: no such file or directory, rename '/Users/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/myProgs/Cappuccino/cappuccino/node_modules/.staging/@objj/utils-ce17aa86' -> '/Users/bach/Library/Mobile Documents/com~apple~CloudDocs/Bach/myProgs/Cappuccino/cappuccino/node_modules/@objj/utils'
npm ERR! enoent This is related to npm not being able to find a file.
npm ERR! enoent

Martin Carlberg

@mrcarlberg

@michaelbach Are you sure you are running Node version 17? It says that your version of npm is compatable with lockfileVersion@1. That should be a before version 16.

Michael Bach

@michaelbach

bach@mbp14 cappuccino % node --version
v17.3.0

bach@mbp14 cappuccino % which node
/opt/homebrew/bin/node

Where communities thrive

People

Repo info

Activity