How future "safe" is Carbon - anyone knows?

[skalogryz]

I still do not understand the lack of testing in Lazarus. (But somehow it turns out OK, that is by accident!)

Would there be a suggestion on how to create a unit test for LCL-UI part?

[Trenatos]

Unit tests should always be done

[skalogryz]

Unit tests should always be done

yes. yes.
but how - in cross-platform manner?
(More specifically - looking for tools)

[Trenatos]

That's what the is about.

I'm looking for unit test tools for FPC myself.

[Phil]

Unit tests should always be done

yes. yes.
but how - in cross-platform manner?
(More specifically - looking for tools)

Right, I don't know how a unit test would judge the _visual_ correctness of a UI element.

Maybe there could a database of UI element images generated from, say, the win32 widgetset. These would be judged to be "correct". Then automate the generation and capture of the same elements for another widgetset, say, Cocoa. Then do an image classification with a neural net similar to something like this:

http://yann.lecun.com/exdb/mnist

https://github.com/tensorflow/swift-models/tree/master/MNIST

If the classification doesn't identify a UI image, then it would be judged to be insufficiently "correct" visually and require manual (human) inspection. Currently manual inspection is required for all testing of UI elements.

Or something like this could be used as an example:

https://developer.apple.com/documentation/create_ml

[skalogryz]

as far as I'm aware the major Cocoa issues is of behavioral nature.

I.e. the control is there, but it's not acting the way it's "expected" to act (due to behavior in other widgetset)

Not really sure, how to test for that in automated manner. 

[Phil]

as far as I'm aware the major Cocoa issues is of behavioral nature.

I.e. the control is there, but it's not acting the way it's "expected" to act (due to behavior in other widgetset)

Exactly. And misbehavior usually manifests itself in some visual defect. That may be the end of the line, with earlier hiccups and glitches actually being the bug, but if the visual is okay, that usually means everything up to that point in the chain of events is okay. Hence why examining Lazarus itself against a widgetset is so rich in bug production: it's high up on the food chain, as it were.

[Trenatos]

@phil, fair enough, I didn't know you meant the visual aspect.

Though there are GUI testing tools, I haven't used them before.

[Phil]

@phil, fair enough, I didn't know you meant the visual aspect.

Though there are GUI testing tools, I haven't used them before.

Me neither. I don't even do much UI work anymore except Web stuff.

I don't have any idea of how realistic image classification would be for testing UI elements. It might be way more work than it's worth. However, I think you would end up with a set of tools that would be terrifically useful for other problems. Machine learning is becoming so ubiquitous that we would undoubtedly discover other uses once the first Pascal-based app or tool was underway.

If anyone is interested I have TensorFlow working on both macOS and Linux with a Pascal interface. My interest is primarily in numerical classification, not image or natural language classification, so many of the examples don't have much interest for me, but certainly those are two really active areas of investigation.

See this example for something fun:

https://appleinsider.com/articles/18/06/06/this-third-year-wwdc-scholarship-winner-built-an-ml-model-to-recognize-beer-yesterday

[Trenatos]

Wow, nice, thanks for sharing Phil.

TF is indeed something I've been tempted to get into.

As for testing, I'm looking into various GUI testing tools, there are several free/open source ones, I'll try getting it set up to test it.

But the core problem remains, Cocoa not being implemented/done.

Anyone have ideas for how we can get movement on that?

[skalogryz]

But the core problem remains, Cocoa not being implemented/done.

Anyone have ideas for how we can get movement on that?

Just work on it. 

Preferably you need to take the entire responsibility for the widgetset.
Meaning - you need to constantly work on it, until it's done.
"Until it's done" part is unclear and can span for the next decade.

(Not a joke at all! Windows / Gtk support goes on even today, started 25 years ago?)
For the best paste, it should be at least 2 hours a day. The best time is 4 hours a day.  4-5 days a week.
That's it.

Cocoa will start to shine in no time.

In the absence of enough free time as of this moment, I cannot do any significant progress on Cocoa.
(the next "Cocoa session" for me might be open in October this year)

Be prepare to fight we patches provided.
Sometimes patches come in and they look good, because they're solving a particular problem.
They might be applied (just because they were there long enough w/o anyone looking into them).
But on the long term, they might actually be damaging. Because the implementation was not good enough, causing more problems, than actually solving issues.

So making Cocoa move is easy -> work on it.

[marcov]

(Not a joke at all! Windows / Gtk support goes on even today, started 25 years ago?)

GTK1 started around 2000, win32 only started later (at first gtk was used on windows too). Micha Nelissen worked a lot on Win32 afaik. (maybe he created it, I don't know). I'd say 2003ish.

[Phil]

For the best paste, it should be at least 2 hours a day. The best time is 4 hours a day.  4-5 days a week.
That's it.

Right, that doesn't sound like something that we can reasonably expect a "volunteer" to do. But even with the offered bounty, let's see, say 20 hours per week for 10 weeks, that's $15/hour, or basically the starting pay at a Starbucks.

And I would assume that before you can work productively on a widgetset you would already need to be familiar with the inner workings of LCL and the existing widgetset code. I don't believe there's much documentation for that. Plus for Cocoa a knowledge of AppKit and Objective Pascal dialect would be assumed (those are documented). Meaning you eat that time yourself.

[dbannon]

Just for the benefit of someone watching who has not tried it. Cocoa does, right now, almost work ! Its not a case of starting from scratch, most of it is there and most of it mostly works. 

To my knowledge, there are some things that don't behave as carbon does, maybe because Cocoa wants to be different, maybe bugs. And a few things that don't work. One real structural issue is memory leaks, if you are used to Lazarus's excellent heaptrc you are very disappointed to find it does not identify the source of a leak on the Mac - that makes fixing a leak very difficult (IMHO). Apparently thats a big job to fix and, obviously, one for someone with a pretty detailed knowledge of the inner workings. If heaptrc was fixed, maybe us mere plebs could address the more mundane issues ?

Davo

 

[Phil]

Just for the benefit of someone watching who has not tried it. Cocoa does, right now, almost work ! Its not a case of starting from scratch, most of it is there and most of it mostly works. 

I don't use Lazarus, but I do monitor its state (couldn't bring myself to write progress). That includes compiling the IDE against Cocoa. That really shows the bugs and missing pieces. If you haven't tried that, do so ASAP. If the IDE were stable and usable, I might agree with you. But it's not. (But it should be a good source of bug reports.)