Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 21 03:53
    daumiller starred cappuccino/cappuccino
  • May 17 14:48
    cappbot commented #2967
  • May 17 14:29
    cappbot closed #2967
  • May 17 14:29
    cappbot commented #2967
  • May 17 14:29
    cappbot labeled #2967
  • May 17 14:14
    daboe01 commented #2967
  • May 17 11:58
    ivucica commented #2967
  • May 12 19:04
    cappbot commented #3042
  • May 12 18:41
    cappbot labeled #3042
  • May 12 18:41
    cappbot milestoned #3042
  • May 12 18:33
    enquora edited #3042
  • May 12 18:33
    enquora opened #3042
  • May 03 09:04
    iKettles starred cappuccino/cappuccino
  • Apr 26 18:17
    cappbot commented #3005
  • Apr 26 18:11
    cappbot closed #3005
  • Apr 26 18:11
    cappbot commented #3005
  • Apr 26 18:11
    cappbot labeled #3005
  • Apr 26 17:59
    daboe01 commented #3005
  • Apr 26 16:34
    michaelbach commented #3004
  • Apr 26 16:33
    michaelbach commented #3004
Martin Carlberg
@mrcarlberg
Some other news! I have now added Github Actions on the Node branch. It will build everything and run all the test cases when new commits or pull requests are created. Now we don't need Travis anymore :smiley:
For more info check: https://github.com/cappuccino/cappuccino/actions
And it is very fast :smile:
Michael Bach
@michaelbach
FANTASTIC! Thanks.
David Richardson
@enquora

@mrcarlberg afaik we can build and test XcodeCapp using github actions too. I began looking at this several months ago. From what I saw, the oldest support OS is High Sierra.

Does limiting XcodeCapp support to macOS 10.13 to fit Github’s CI pipeline cause problems for us?

XcodeCloud is available now too, but that is tied to individual Apple IDs - Github Actions seems the better choice.

I continue picking away at the problems in XcodeCapp as time permits and will set up CI actions for it.

Martin Carlberg
@mrcarlberg
@enquora If GitHub only supports 10.13, I think go for it. Should be ok for most.
Martin Carlberg
@mrcarlberg
I have played around with the Build Badge at the top left of the README file at https://github.com/cappuccino/cappuccino. We now also have one for the Node version :smile:
daboe01
@daboe01
@mrcarlberg great work! very much appreciated!
Gustavo "Mucho Love"
@mucholove
@daboe01 - For objects that are semantic, e.g. User—I construct the same object in Objective-C and Objective-J from the same JSON. Much of it is the same—as are many other calculations and logic. Some things are different—and yet—I can use the same API and logic for these so that my code "Just Works"TM and much of it already does!!! Will check out the Acorn file and the test cases soon enough and report back to y'all.
@mrcarlberg - In my files—I have both @import / and #import statements because Objective-J so far as I know does not really understand #import. Technically—Objective-J should never see my #import statements because these are hidden behind an #if statement
For my Objective-J build, I have to comment out the Objective-C part of the import section because it causes Objective-J to sputter
Would be great to remove the dead code from the Cappuccino source
David Richardson
@enquora
Do bundles in the Frameworks folder need to be compiled to be @<import>ed? Having trouble with several third-party bundles and frameworks there.
Doing some refactoring of an app that has a usage case for functionality as a reusable framework - not able to get @imports working.
David Richardson
@enquora
ok, the problem was when using index-debug.html to preview during development, and the frameworks missing in Frameworks/Debug. Is creation of symlinks there something we should automate - as a capp task and in XcodeCapp?
David Richardson
@enquora

@mrcarlberg This question is probaby for you (but anyone with large app experience should chime in)…

Our main app is best approached as a plugin host, with something like 1 1/2 dozen modules which a user can activate. They all have content displayed in the host app, in a defined subview.

Until now, all the modules have lived in a Modules bundle in the main app, each with their own sub-bundle. This works, but it is a subtle invitation for unwanted coupling.

Moving the plugin bundles to the Frameworks folder is more elegant, but they are under active development, including xibs. XcodeCapp won’t see resources in those bundles to recompile (especially xibs). Adding the Framework bundles as separate Xcode projects runs into temporary path permission problems with nib2cib.

It looks as though the only proper way to do this is to move the bundles to their own projects and git repositories.

Thoughts on best practices for large scale development and modularity?

Martin Carlberg
@mrcarlberg
@mucholove Looking forward to see your problems reduced to a simple test case :smiley:
Martin Carlberg
@mrcarlberg
@enquora Is it XcodeCapp that is the main headache for you here?
A Framework is a Bundle so I guess your modules are just a plain Frameworks. Looks very straightforward to me.
To have each as a separate Xcode project looks also very simple. Is your setup that gives you path permission problems the thing you need to look at? It feels like this is coming back to you all the time?
Our project has a very simple setup with one main application with about 35 xib files. To this we have a number of Frameworks and a Theme. We never use XcodeCapp because it overwrites the project file all the time. We run nib2cib and/or objj2objcskeleton manually or with a simple bash script.
David Richardson
@enquora

The OS setup is absolutely standard (Monterey hardly allows anything else). XcodeCapp appears to have been designed with the intent all xibs are stored in the main bundle’s Resources folder and doesn’t seem to behave well if not. Keeping xib resources separate from their associated code resources is increasingly a problem for managing the app, as it grows. Using folders in the Xcode sidebar as logical groups is one answer to that, but, as you point out, XcodeCapp is ill-behaved wrt Xcode project files (in some circumstances). That can, should, and will be fixed, but this app has also grown beyond the point where a monolithic project structure is appropriate. It is also just a nuissance to keep one or more terminal windows open to watch and compile nibs. And also to create Objective-C matching class definitions. And Xcode doesn’t have an integrated terminal capability.

Packaging as frameworks, in the Frameworks folder, seems the best approach. At the moment, the modules are under active development - for refactoring. I’m also somewhat concerned about managing imports in the frameworks scenario - there are currently cross-dependencies, and it’s not yet obvious how those will be sorted out.

An allied problem is that I insist on far more separation of concerns into individual files than most people probably do, with smaller controllers for many, if not most, individual sub-views. That’s before getting to datasources and delegates. It’s reached the point these really should be packaged directly with their associated xib assets. Some will suggest avoiding xibs altogether - my experience is it’s very difficult to get a visually polished result going that route.

Simpling moving the module bundles into the Frameworks folder has resulted in jake build problems though. It looks to me as though, as frameworks, they need to be kept entirely out of the main app, built separately, and the build artifacts symlinked or copied in. I assume the reason XcodeCapp allows adding multiple projects which are actively watched is to accommodate just such an approach. I was hoping someone might actually have experience with such, but it seems not.

For the moment, staying with the monolithic project structure is workable. A single module is currently being factored out into a separate app, and that can be used as a base to work back upwards in complexity.

One thing I’ve noticed is the monolithic on-disk structure of this app has negatively influenced coupling of the constituent parts - it’s more rigid than need be.

It’s probably time to revisit Nuage’s project structure - it’s of the scale I envisage this app soon reaching and perhaps it offers some guidance.

Martin Carlberg
@mrcarlberg
@enquora Yes, managing a big project can be difficult. We try to keep a clean project structure. For long the source structure of an application or framework has to be flat. With that I mean that all source files has to be on the root level. The Foundation and AppKit frameworks do have folders with source files like CPArray etc. The problem is that it has to be built before it can be used in an application. The build process will flatten the source structure. So you can use a folder structure in your own application but you have to build it before you can run it in the browser. Just reload and compile it on load in the browser will not work. The pull request #2963 changes this by allowing the file structure to be declared in the Info.plist file. This allows a deep structured project to be compiled in the browser.
Another way to get structure in a project is to use group folders in Xcode. We use that a lot in our project. This makes it easy to find stuff that are related. Se attached screenshot.
Skärmavbild 2021-11-11 kl. 22.09.48.png
Michael Bach
@michaelbach
@mrcarlberg "Group folders": they would be nice, but they are lost on rebuilding of xyz.xcodeproj, e.g. after Reset the project in XcodeCapp, right?
David Richardson
@enquora

@mrcarlberg I had come to the same conclusions over the last few years. The best approach available now has been to use Xcode’s sidebar groups to provide useful organization. It works, but one must be careful to not select ‘Group with folder’. I had noticed #2963 when it was posted, but failed to grasp its significance. fwiw, there has long been a Ruby gem to synchronize Xcode’s virtual folder with the on-disk structure: https://github.com/venmo/synx

An analagous automated tool would nicely complement #2963

Martin Carlberg
@mrcarlberg
@michaelbach Yes, XcodeCapp will destroy the project file. We don't use XcodeCapp because of this problem. We run nib2cib and objj2objcskeleton manually or by a script
@enquora An automated tool to keep the Info.plist file synchronized with the file structure should be nice for #2963.
Michael Bach
@michaelbach
@mrcarlberg Ah, thank you.
David Richardson
@enquora

Anyone able to describe in detail how an app built for release bootstraps itself? I’m in the process of hardening ours, starting with prohibiting everything, then specifically allowing the pathnames required by the app.

Strangely, one of the first URL requests is for main.j, which isn’t a file in the Release build artifacts, despite having a reference in index.html. Having trouble understanding where the request for main.j originates - although I’m guessing it’s a fallback built into the Objective-J runtime file.

Insight welcomed. It will also help in process of defining the offline operation requirements.

Martin Carlberg
@mrcarlberg
@enquora This is the generic bootstrap steps (the simplified version :smiley: ). If you have built for release all the source files are already compiled and stored together for each bundle in one file. See below:
  1. index.html is read and parsed by the browser
  2. The file Frameworks/Objective-J/Objective-J.js is read and executed. It will setup the Objective-J runtime.
  3. The file ./Info.plist is read and parsed to get stuff like path to main file (usually main.j), is it prebuilt etc...
  4. The main file is read.
  5. The file is parsed to create an AST tree of the code by the Objective-J compiler if not yet compiled. If it is pre built each source file in the bundle is stored together precompiled in one file. Each file will then be extracted from the common file instead of loaded separately. For example Frameworks/Foundation.sj etc.
  6. If the file does any @import then read each of the imported files.
  7. For each imported file continue on step 5 and building a dependent tree of all source files.
  8. When the last files without any imports are read and if needed parsed by the Objective-J compiler. Usually Foundation/CPObject.j and some other similar classes. The load system now starts execute each source file from the leafs of the recursive tree that is built when loading all the imported files above. If the source files are not pre built the compiler will generate the compiled javascript code from the previously generated AST tree before executing it.
  9. The dependency tree is walked back down to the main file.
  10. When the main file is executed as the last file the load system will check if there exists a main function. The function is called.
Martin Carlberg
@mrcarlberg
And this description is now available on our wiki with a new link under the new In depths header from the main wiki page :smile: : https://github.com/cappuccino/cappuccino/wiki/Bootstrap
https://github.com/cappuccino/cappuccino/wiki
Martin Carlberg
@mrcarlberg
@enquora Also, to answer your question about the main.j file. The Cappuccino runtime and load system will not access main.j separately if your app is prebuilt, only the common <Your App>.sj file.
daboe01
@daboe01
@mrcarlberg thank your for this explanation. very much appreciated.
David Richardson
@enquora
@mrcarlberg Just what is needed - thanks. Particularly helpful for setting up service workers to run offline.
David Richardson
@enquora
A peripheral question, but what is the purpose of the Build/AppName.build folder? It’s obvously part of the build process, but it isn’t erased afterwards and doesn’t seem to be part a deployment cycle. Is it used for diffing/incremental compilation?
Martin Carlberg
@mrcarlberg
@enquora Build/AppName.build is, as you say, used in the build process. It stores all the compiled source files before the common source file is being created. It is not removed after the build process as it is also used the next time you build to only recompile the files that are changed. You can remove it by doing jake clean or just remove from command line with rm or from the FInder.
David Richardson
@enquora

@mrcarlberg Do you know if the Jakefile syntax is sufficiently close to that of a Makefile for a make linter to be usable?

I’ve just had a modification to the standard Jakefile in a project which unintentionally introduced invalid characters. Running jake produced very unhelpful feedback — it complained the problem was in the Cappuccino’s narwhal bootstrap.js file :-(

Perhaps I hadn’t had my morning coffee, but it took an hour for the eureka moment when I realized the problem was in the Jakefile itself.

Martin Carlberg
@mrcarlberg
@enquora The Jakefile syntax is very different from a Makefile so I don't think that is possible. Sometimes the error messages can be very "unhelpful". A good thing is that they are much better i the Node version :smiley:
Gustavo "Mucho Love"
@mucholove
Hello! I haven't touched my computer for the last few weeks and am getting an error—probably because my CAPP_BUILD file is external. Here's the deal:
gtavares@Gustavos-MacBook-Air Browser % ./gtktest 
/Users/gtavares/Developer/cappuccino/node_modules/@objj/runtime/ lib/objective-j.js:3946
                        throw new Error("Could not load file at " + aURL + (compilingFileUrl ? " when compiling " + compilingFileUrl : "") + "\nwith includeURLs: " + StaticResource.includeURLs());
                        ^

    Error: Could not load file at Foundation/Foundation.j when compiling file:/Users/gtavares/Desktop/Browser/gtktest
with includeURLs:     /Users/gtavares/Desktop/Browser/Frameworks/,/Users/gtavares/Developer/cappuccino/dist/objective-j/Frameworks/
    at completed (/Users/gtavares/Developer/cappuccino/node_modules/@objj/runtime/lib/objective-j.js:3946:31)
I have my Cappuccino inside /Users/gtavares/Developer/cappuccino/ and my $CAPP_BUILD set to /Users/gtavares/Developer/cappuccino/Build
This is running a shell script with the header #!/usr/bin/env objj
Gustavo "Mucho Love"
@mucholove
As an example—when I compile it without the import line—it goes pretty far, but of course it misses the first few categories I extended from Foundation
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
David Richardson
@enquora

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

Gustavo "Mucho Love"
@mucholove
@enquora — yes, I am on Monterey now
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