Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Gustavo "Mucho Love"
@mucholove
OMG. So nutty
David Richardson
@enquora
which version? 12.0.1, or initial release?
Gustavo "Mucho Love"
@mucholove
12.0.1
David Richardson
@enquora
It was a security update - I’m wondering if it didn’t include significant tightening of permissions.
Gustavo "Mucho Love"
@mucholove
Wow—well, let me see if I can get it to run
The thing I'm confused about is this: includeURLs: /Users/gtavares/Desktop/Browser/Frameworks/,/Users/gtavares/Developer/cappuccino/dist/objective-j/Frameworks/
The URL where the frameworks are located dosen't include: /Users/gtavares/Developer/cappuccino/Build/
David Richardson
@enquora
I won’t have time to look into this further until the weekend, but are your paths and project all on the same volume and container? No symlinks, for instance
No symlinks off-volume
Gustavo "Mucho Love"
@mucholove
One volume, no containter—not running Docker or similar
David Richardson
@enquora
And to confirm, none of the handful of changes in Cappuccino in October and November pulled in?
Gustavo "Mucho Love"
@mucholove
I'm using the Node branch
From the looks of it, Node hasn't been merged with master/main—but I may be wrong
Commit hash: b6310328
David Richardson
@enquora
It’s an independent branch. I’m not using it yet, so don’t remember exactly what changes have occured recently.
Martin Carlberg
@mrcarlberg
@mucholove The includeURLs are the paths to the current working directory /Users/gtavares/Desktop/Browser/gtktest and 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/runtime node module. I will look into why this is happening.
Also, keep in mind that the path to the current Build directory is usually not included in the includeURLs but could be added manually with the environment variable OBJJ_INCLUDE_PATHS
David Richardson
@enquora
@mrcarlberg nib2cib is failing here, whether using narwhal or node. Can confirm it is working for yourself using node?
I presume you’re using your new MacBook Pro, so must be using one of the two versions of Monterey and Xcode 13?
error is 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.
This happens with both with Xcode 13.1 and 13.2.
David Richardson
@enquora
Also, narwhal’s File and System module processes run as root creating permission problems with directories and files. Narwhaljs.org documentation is Spartan — do you know of a simple way to specify the user and group which should be used for system processes?
It appears imagesize needs to be replaced in the node version — it is used by nib2cib if a xib contains images.
Does this seem correct?
Martin Carlberg
@mrcarlberg
@enquora I'm on Monterey running a M1 Max with Xcode 13.1. I have no problems with nib2cib or Xcode 13.1. I'm using the latest Node version.
@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 :)