Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • Jan 13 08:28
    mrcarlberg updated the wiki
  • Jan 11 16:44
    mrcarlberg updated the wiki
  • Jan 11 15:02
    ezeaguerre starred cappuccino/cappuccino
  • Jan 10 06:17
    daboe01 commented #3000
  • Jan 07 23:00
    michaelbach synchronize #2998
  • Jan 07 21:56
    mrcarlberg commented #2998
  • Jan 07 21:03
    cappbot commented #3016
  • Jan 07 20:54
    daboe01 commented #3000
  • Jan 07 20:51
    daboe01 commented #3000
  • Jan 07 20:49
    daboe01 synchronize #3000
  • Jan 07 20:38
    cappbot labeled #3016
  • Jan 07 20:38
    cappbot milestoned #3016
  • Jan 07 20:28
    daboe01 commented #2575
  • Jan 07 20:27
    daboe01 opened #3016
  • Jan 07 18:34
    daboe01 commented #2967
  • Jan 07 16:12
    michaelbach commented #2998
  • Jan 07 15:20
    mrcarlberg commented #2998
  • Jan 07 15:14
    mrcarlberg commented #3013
  • Jan 07 07:36
    daboe01 commented #3013
  • Jan 07 07:34
    daboe01 commented #3013
Martin Carlberg
@mrcarlberg
@enquora The easiest way to solve Narwhal problems is a move to the Node version :smiley:
David Richardson
@enquora
It’s a bad look simply capping legacy version at Big Sur, but I began wondering this morning if that is our best policy.
Doesn’t address the not-yet-available imagesize required 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?
Otherwise, I’m fine personally with jumping to the node branch now. I have a day or two of work left on something which can be accomplished on my old High Sierra machine. This is refactoring a small component of our main application into a separate module. Will look at node on the full project then.
Remind me about imagesize - is that one of the legacy Java-native tools?
David Richardson
@enquora
And if it is, would running it using Java, as in inline process, work in the short term?
I vaguely remember a Java=>Objective-C compiler, as well.
David Richardson
@enquora

flatten and 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’ ;-)

David Richardson
@enquora
imagesize appears to be native Objective-C in a single simple implementation file. Has this just been overlooked in the node branch?
aksuska
@aksuska
@enquora narwhal has to call sudo somewhere, so shouldn't be hard to find...
Martin Carlberg
@mrcarlberg
@enquora I'm totally fine with supporting a legacy version of Narwhal. The problem is that I don't have time to work on it. Maybe someone else can step up?
@enquora press and flatten is not yet supported in the Node version but nib2cib is. imagesize and fontinfo is native Mac OS tools and is only needed when running nib2cib as you say. The need to convert imagesize and fontinfo to something else is not high on my list.
We all are currently using the Node version with great success.
Martin Carlberg
@mrcarlberg
@mucholove I think I have fixed the problem you had with importing Foundation in your tool gtktestwritten in Objective-J. I have tested myself with a simple Objective-J tool with a shebang like this #!/usr/bin/env objj and it does now work. The update is in the @objj/runtime
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
IMG_3742.JPG
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