cappuccino/cappuccino

Web Application Framework in JavaScript and Objective-J

Martin Carlberg

@mrcarlberg

@didierkorthoudt I will take a look why this is happening with your Node version.

enquora

@enquora:matrix.org

I don’t either. Nevertheless, it is nil. When hiding it, it’s necessary to do so in applicationDidFinishLaunching. I haven’t checked behaviour in an Objective-C app, but this smells like a bug. Which may be causing other problems too. It also looks confusing to newcomers to set the window to full browser size in awakeFromCib, but to hide the app menu in applicationDidFinishLaunching!

Martin Carlberg

@mrcarlberg

@enquora A quick check in CPMenu.j:

- (void)awakeFromCib
{
    if (_name === @"_CPMainMenu")
    {
        [self _setMenuName:@"CPMainMenu"];
        [CPMenu setMenuBarVisible:YES];
    }
}

This means that the mainMenu is set in awakeFromCib:. I think this is a bug as I should already be set when awakeFromCib: methods are called. Your awakeFromCib: is called before this one is but it could have been called after. There is not order on when they are called.

Martin Carlberg

@mrcarlberg

@didierkorthoudt It looks like there is a problem when installing from npm. Try use the instructions under the title: Install from source without install with npm

David Richardson

@enquora

@mrcarlberg I assume the intention is to track the current LTS version of Node (now version 16)?

David Richardson

@enquora

Curiously, a one-day gap exists between an LTS version going into maintenance mode and the next LTS version becoming active.

David Richardson

@enquora

Does anyone with a good memory know why XcodeCapp uses a third-party NSProgressIndicator?

Similarly, the XcodeCapp code seems to use Python to execute several trivial shell operations. I have a vague memory that a Python package was once used to create and manage Xcode xcodeproj files, although this is no longer the case. This needs to be fixed, as the Python runtime referenced is Python 2, which has been deprecated for some time and is likely to disappear from the core OS distribution at any time.

Can anyone confirm my memory of this?

Martin Carlberg

@mrcarlberg

@enquora Yes, Node version 16 is a good version to use now. Version 14 does also work right now but the target is 16.

@enquora I have not been working a lot with the code in XcodeCapp so I'm not sure why. Maybe someone else has any idea why? But as you say Python2 is kind of old...

Martin Carlberg

@mrcarlberg

And I guess a third-party NSProgressIndicator might not be necessary to use

David Richardson

@enquora

There’s no way to set the representedObject for a menuItem in IB, is there?

David Richardson

@enquora

@mrcarlberg Is the need to @import viewcontrollers in code even though they might be referenced only in xibs a fundamental limitation of our compiler or something that just needs some effort behind it?

The runtime throws an error that it can’t reference the controller class - unless it’s @imported somewhere, such as the app controller or delegate.

David Richardson

@enquora

To my mind, IB and the productivity improvements it brings are a ‘unique selling proposition’ which we would be wise to promote (yes, I’m aware it can cause commit clashes when used in some circumstances, and many will complain about that).

Nevertheless, I regularly forget this requirement and routinely spend several hours debugging/remembering the cause. This isn’t the sort of experience we want newcomers to have.

Our main app is white-labelled for multiple users and I’m refactoring just now to make it more designer/junior developer friendly for quick modification to accommodate client quirks.

Martin Carlberg

@mrcarlberg

@enquora @import is currently the only way to tell the runtime to load a class that is referenced dynamic from for example a xib. It is not anything that is handled by the compiler but maybe nib2cib could track referenced classes in the cib file and the framework could load them when the cib is loaded.

daboe01

@daboe01

Safari 15 has broken disclosure indicators, at least in CPOutlineView. They are stuck closed. This is using macOS 12, second release candidate.
Anyone using the Safari 15 preview under Big Sur who can test?

@enquora:matrix.org i do not see any issues on safari 15.1 with the kitchen sink app on https://cappuccino-testbook.5apps.com/#ThemeKitchenSink

David Richardson

@enquora

@daboe01 I’m in the process of refactoring a view using CPOutlineView and will look more closely at this. It’s entirely possible something in the view delegate is only half implemented in this app and causing problems. Strange it should have worked properly until Safari 15 though.

David Richardson

@enquora

A vector version of the XcodeCapp logo is needed for ongoing maintenance and isn’t present in the repo. Does anyone remember who did the original artwork? It’s not obvious from the commit history.

I have autotraced the raster version and it’s a good starting point for cleanup - but it would be nice to have the original.

Perhaps I should rephrase as “who is likely to have produced the original”.

Gustavo "Mucho Love"

@mucholove

So I'm trying to install Cappuccino NPM from source—and I got this error.

cappuccino % jake install
(in /Users/gtavares/cappuccino)
Error on line 53 of file [unknown]
Error: require error: couldn't find "fs"

My guess is that Jake was not installed for npm. Fair enough so I do:

   jake install

And now I get:

   cappuccino % jake install
   jake aborted.
  ReferenceError: ObjectiveJ is not defined

Where am I screwing up??

Martin Carlberg

@mrcarlberg

@mucholove Do you have the correct PATH to the tools? What if you type which capp?

Gustavo "Mucho Love"

@mucholove

When I do which capp I get capp not found

OK. Got it. Since I followed the tutorial, the npm install only runs locally and I needed to run npm -g install to place it in the ~/.npm/bin

Maybe change it in the tutorial or make a note of global vs local install? https://github.com/cappuccino/cappuccino/wiki/node

Gustavo "Mucho Love"

@mucholove

One more question—I was looking through the Preprocessor.j file and was trying to figure out where #if is implemented because I consider the Preprocessor to have a bug (#if does not work until it we call @import <Foundation/Foundation.j>. The hash function really confuses me. Where can I maybe find the implementation or understand how #if works so I can fix my issue?

Preprocessor.prototype.hash =     function(tokens, aStringBuffer)
{
    var buffer = aStringBuffer ? aStringBuffer : new StringBuffer(),
        token = tokens.next();
    if (token === TOKEN_PRAGMA)
    {
        token = tokens.skip_whitespace();
        if (token === TOKEN_MARK)
        {
            while ((token = tokens.next()).indexOf("\n") < 0);
        }        }        else
        throw new SyntaxError(this.error_message("*** Expected \"pragma\" to follow # but instead saw \"" + token + "\"."));
};

Martin Carlberg

@mrcarlberg

@mucholove Thanks for the suggestion on the tutorial on the difference between local and global. I will try to make it more clear.

@mucholove The file Preprocessor.j is deprecated and not used anymore. Actually it should be removed from the repository. It is the old compiler that was a kind of advanced search and replace of parts of the code to transpile it from Objective-J to Javascript.

The "preprocessor" you are looking for is in the acorn.js file. It is part of the Tokenizer.

Martin Carlberg

@mrcarlberg

Can you explain in more detail what kind of bug you have found regarding #if?

Gustavo "Mucho Love"

@mucholove

Hey!! So I currently have some code that will perfectly compile in both Objective-J and Objective-C by wrapping VARs and IVARs and PARAMs in Macros. The one thing I can’t do is get the compiler to ignore my #import statements which I hide behind an #if statement at the top of the file. I use a macro defined in the Jakefile such as #if CAPPUCCINO … #else … #endif

Actually, using any Macros before running @import has caused a problem for me

Gustavo "Mucho Love"

@mucholove

Will look into the acorn.js file though my sense tells me this was generated??

daboe01

@daboe01

@mucholove can you tell us what your usecase is for having the same source for oJ and oC?

David Richardson

@enquora

@daboe01 Cappuccino has so many rough edges and corner cases it is often more productive to develop first in Objective-C, then port. And, the Xcode debugger is still more user-friendly than any browser’s — even though both Safari and Chrome’s are modelled on it.

I’ve also wished more than once, when porting existing Objective-C code (usually a framework), for this ability

@mucholove Acorn uses a plugin architecture, is well-documented, and under active development. It’s probably not extraordinarily difficult to add what you have described. Caveats are: the version we have is of the same vintage as narwhal. It’s unclear to myself how much the extension functionality has moved on in the near-decade since we last updated. Nor if our version has been tweaked directly in ways which require porting.

David Richardson

@enquora

@daboe01 Case in point: I would likely still be struggling to confirm it is our own handling of view scaling which is wonky and incorrect if I hadn’t developed test cases first in Objective-C. The ability to compile test cases directly in both Objective-C and Objective-J, side-by-side, same code base, would have saved much of the remaining time.

Martin Carlberg

@mrcarlberg

@mucholove Acorn is not generated. It is a very fast hand coded Javascript tokenizer/parser. It uses some special implementations that they have tested out over many years to be extremely efficient. As @enquora says we use a kind of old version that only support ES5, except the Node version that also supports await/async. The latest Acorn has a poor man type of plugin architecture that can be used to extend the parser. But it is very dependent of the internal workings so not very good at extending more complex things like we do with the Objective-J language. It is also hard if not impossible to extend the Tokenizer with that plugin architecture. The Tokenizer is modified in our version to implementation our preprocessor. It is not built like a regular preprocessor that "preprocess" the file and creates a new file that is then compiled. It is implemented as a Recursive Token Transformer. It will transform tokens on the fly to the "preprocessed" result. This allow it to be very fast and only do one scan over the source file when compiling.

Martin Carlberg

@mrcarlberg

@mucholove You talk about both #import and @import when you describe your problems with the preprocessor. Do you use both? #import is a preprocess import and is different from @import.

Martin Carlberg

@mrcarlberg

@mucholove Also, we have a lot of test cases for the preprocessor in tests.js at https://github.com/mrcarlberg/acorn. Should be nice if we could get your problem as a test case too.

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.

Where communities thrive

People

Repo info

Activity