FreeCAD Day 2023 - Report and Continued Discussion

Have some feature requests, feedback, cool stuff to share, or want to know where FreeCAD is going? This is the place.
Forum rules
Be nice to others! Read the FreeCAD code of conduct!
GeneFC
Veteran
Posts: 5373
Joined: Sat Mar 19, 2016 3:36 pm
Location: Punta Gorda, FL

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by GeneFC »

user1234 wrote: Sat Feb 04, 2023 8:47 pm But that is a fact.
Rule number 1 in a brainstorming session, which describes that complaint session, is that ALL contributions are initially accepted unless completely off-topic. No arguing or "correcting" allowed. Otherwise the "experts" will already have all the answers.

Any errors or "already done" can be sorted out later.

Gene
User avatar
amrit3701
Posts: 343
Joined: Mon Jun 13, 2016 5:37 pm

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by amrit3701 »

chennes wrote: Sat Feb 04, 2023 7:58 pm Stefan Tröger (@ickby) presented "Experiments in Collaborative Editing"

Many people now expect easy direct collaboration a la Google Docs, Microsoft Office, etc. Instant feedback, dynamic sharing, etc. The project goal here was to bring some of that the the CAD workflow. The data is synchronized, but not the viewport. This is only reasonable with loading/saving of individual object data. He needed to create a "single source of truth" for the data so that conflicts could be resolved. Fortunately there is a lot of literature on this problem, he uses the "Raft" algorithm because it can actually be understood. He has a working first draft, but development is a bit stalled now. Anyone want to help?

A lot of the discussion focused on how unsuitable this workflow would be for a rigorous commercial CAD environment, but the basic response (if I am paraphrasing correctly) is that this has plenty of applications beyond that, and allows instantaneous switching of "control" by just saying so in your teleconference, etc. It's not suitable for all kinds of collaboration, but is a very interesting platform for other (maybe less formal) works.
Yeah! event was awesome. Looking forward to deploy @ickby code in my local system. :)
Amritpal Singh
Github, Like my work, sponsor me!
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by onekk »

sliptonic wrote: Sat Feb 04, 2023 9:08 pm
Regarding toponaming, the thing that came clear to me is that we need to stop thinking about realthunder's code as a "thing to be merged". It isn't. It's a proof of concept of how to solve the toponaming problem. His solution has been running for years in his linkstage3 branch and can be considered proven. But as chennes said, it isn't a matter of mashing the green button. If we do that, we will make a huge mistake.
It seems reasonable, as probably a TNP mitigation algorithm could be modified in time, to suit future needs, or even delegate such task to some more things, like a database that keep track of shape modifications, ie it will store "Topology of Shapes" and a maybe a diff from the "preceding item" in history of shape.
sliptonic wrote: Sat Feb 04, 2023 9:08 pm Nor can Ondsel simply take on the task for exactly the same reason. Toponaming is FreeCAD's problem. The solution has to belong to FreeCAD. What realthunder has given us is the algorithm to solve it. All we have to do is implement the algorithm.

There are some relations between Ondsel and FreeCAD?


Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
Zolko
Veteran
Posts: 2213
Joined: Mon Dec 17, 2018 10:02 am

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by Zolko »

chennes wrote: Sat Feb 04, 2023 7:46 pm "The Role of Maintainer is Unclear"
  • The fundamental break is whether current code quality is the primary driver, or whether encouraging more development is the driver
  • DISCUSS!
As part of this discussion, we talked about:
  • "Merge fast" can lead to technical debt that is difficult to get out of later (can't just revert when other changes depend on it)
  • Discussion of branch strategy: what is the best fit for FreeCAD? Right now we have working master, branches for releases. Could go to a dev branch, more stable master, tags for releases. Or "Git Flow" workflow, with feature branches feeding dev branch feeding stable master.
Specifically, in the current C4-like scheme, it is stated that there should be only 1 branch (Master) with very liberal merging process.

It has been said – don't remember who – that this had been used by another project, which presented very good initial results, but later brought huge problems because of the amount of bad code burden. Some people then argued that bad code can be removed, but once it's in "Master" it's, in reality, very hard to remove and the code tends to grow and grow.

To overcome this, I proposed to have a "development" branch, where code could be added quite freely, and improved in place, and even removed if too wrong. Some argued that the current FreeCAD "Master" branch is in effect the development branch, and functionally that's true, but psychologically it's not. If something is in Master, people will expect it to be there, while if it's only in a development branch people intuitively understand that it's not to be used for production. It has been argued that if we have too many feature branches then re-basing them will be a daunting task.

Therefore, but this was not discussed during the meeting, I propose the following merging scheme:

  • Have 2 FreeCAD branches, and only 2 : Master and Development. Master is always clean and compiles fully, while Development can be partially broken.
  • All new features are merged exclusively into development, only critical bugfixes are merged into Master, and into Development in parallel
  • Merging into Development should be quite open and fast, but ...
  • ... it is understood that features and code can also easily be removed if testing shows it's bad/unnecessary
  • when enough new features have been merged into Development, it is merged into Master
In this scheme, and using the Debian nomenclature, tagged releases (20.1 ...) are the equivalent of Debian Stable, Master is the equivalent of the Debian Testing, and Development is the equivalent of Debian Sid. I think that Debian has shown that this is quite a successful development process.
try the Assembly4 workbench for FreCAD — tutorials here and here
Hologram
Posts: 201
Joined: Thu Nov 03, 2022 3:05 pm

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by Hologram »

Zolko wrote: Mon Feb 06, 2023 2:40 pm
  • Have 2 FreeCAD branches, and only 2 : Master and Development. Master is always clean and compiles fully, while Development can be partially broken.
  • All new features are merged exclusively into development, only critical bugfixes are merged into Master, and into Development in parallel
  • Merging into Development should be quite open and fast, but ...
  • ... it is understood that features and code can also easily be removed if testing shows it's bad/unnecessary
  • when enough new features have been merged into Development, it is merged into Master
In this scheme, and using the Debian nomenclature, tagged releases (20.1 ...) are the equivalent of Debian Stable, Master is the equivalent of the Debian Testing, and Development is the equivalent of Debian Sid. I think that Debian has shown that this is quite a successful development process.
This is also, in my understanding how it is done in Krita and it works very well. The idea is also that you can port the bugfixes to master so you can have monthly or bi-monthly releases of the master branch with bugfixes except for when a major release takes place. Essentially, there are then 3 versions in Krita: the last major release (either feature release or bug fix release) a major release Plus version (which includes additional bugfixes to the last release) and the development branch. The releases are for the average user, the Plus versions grant extra stability and can be used by people who benefit from a particular bug fix and finally there's the development branch, which users can try to provide feedback or to spot bugs early on (but is not recommended for production work).

This also ensures that you can provide more frequent releases and user benefits, while also encouraging devs to merge things more easily. You could also incorporate feature freeze windows prior to releases. In which case, there would be a 4th temporary branch that is designated as Beta that is prepared for release. The Plus version can then be kept online but stagnant until the next release, when it is re-opened based on release.

Hope it makes sense, just throwing in some other successful examples. :)
Just ignore when you think it is added noise.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by onekk »

Have 2 FreeCAD branches, and only 2 : Master and Development. Master is always clean and compiles fully, while Development can be partially broken.
It is already like this:

Once release stable will receive usually bugfixes and some backport to correct some problems.

Development is development so it integrate new functionalities and bugfixes.

Maybe now that there are TNP mitigation merging "in process" it may seems that there are three version but reasons for a separate TNP version have been explained countless times that repeat them is not useful.


The fact that the bugfix is done using point-releases could be misunderstood, but it is almost clear, and even Debian to remain near the proposed example use point releases on stable distribution.

Debian however is not as plain as depicted as you could complicate things adding many "non official" repositories and backports and the ability to mix stable with sid, it could became a nightmare to maintain.


Kind Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
User avatar
chennes
Veteran
Posts: 3878
Joined: Fri Dec 23, 2016 3:38 pm
Location: Norman, OK, USA
Contact:

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by chennes »

Zolko wrote: Mon Feb 06, 2023 2:40 pm Therefore, but this was not discussed during the meeting, I propose the following merging scheme:
  • Have 2 FreeCAD branches, and only 2 : Master and Development. Master is always clean and compiles fully, while Development can be partially broken.
  • All new features are merged exclusively into development, only critical bugfixes are merged into Master, and into Development in parallel
  • Merging into Development should be quite open and fast, but ...
  • ... it is understood that features and code can also easily be removed if testing shows it's bad/unnecessary
  • when enough new features have been merged into Development, it is merged into Master
In this scheme, and using the Debian nomenclature, tagged releases (20.1 ...) are the equivalent of Debian Stable, Master is the equivalent of the Debian Testing, and Development is the equivalent of Debian Sid. I think that Debian has shown that this is quite a successful development process.
In this scheme, do we generate our "dailies"/"weeklies" from Development? And then when we merge to master we (manually or automatically on merge) build something we call "Testing"? Then "Stable" is done the way we normally do releases?
Chris Hennes
Pioneer Library System
GitHub profile, LinkedIn profile, chrishennes.com
User avatar
kkremitzki
Veteran
Posts: 2511
Joined: Thu Mar 03, 2016 9:52 pm
Location: Illinois

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by kkremitzki »

chennes wrote: Sat Feb 04, 2023 7:04 pm Next up we discussed some more far-reaching future possibilities, led by Kurt (@kkremitzki):
  • CAD Web stack based on ideas from Post GIS
  • Adding PyKDE to the PySide imports
  • Rewrite critical parts of OpenCASCADE Kernel in ... Rust?
  • Rust is polarizing - what about Nim?
Fleshing this out a bit as I kinda rushed through things trying to let everybody go to lunch:

CAD Web Stack

QGIS is a sort of cousin application to FreeCAD, being a cross-platform Qt-based app for a deep technical purpose: geographic information systems & modeling.

It supports several remote backends. One of those is PostGIS, which is a PostgreSQL extension providing geospatial data types and operations. This spawned a whole ecosystem:

- Spatialite is similarly a DB extension, but for SQLite, which replaces a database server with a simple file, so you get the power of a DB without the network round trip
- Wrapping these spatial DBs is e.g. GeoAlchemy, based on SQLAlchemy, a Python SQL toolkit and object relational mapper
- One level higher, geospatial web apps and services can be created by GeoDjango, an included contrib module in the Django Python web framework

So, there's a whole software ecosystem spawned by PostGIS. Why not a PostCAD, OpenCASCADE-powered CAD data types and operations in PostgreSQL? By turning the DB into a CAD application server, we can use FreeCAD as a client to a more powerful machine. There's also the huge feature set of these databases: for example, access control, centralized authentication, deduplication, transactions, replication, and more.

PyKDE

Wouldn't it be nice if people could focus more on CAD development in FreeCAD instead of needing to be UI/UX designers? We already rely on Qt as an application framework. The KDE Frameworks are a set of 83 add-on libraries for programming with Qt, which would take care of a lot of our non-CAD concerns.

However, FreeCAD already groans under the weight of its dependencies. Adding in KDE deps would be asking a lot without already having the thing you're trying to make. Instead, we can look to PySide, the Python bindings for Qt. This allows us to interact with FreeCAD's interface dynamically, avoiding the need to add or change C++ code and recompile.

Similarly, there have been a few abandoned efforts at a PyKDE, providing the power of the KDE Frameworks but in a form that could be more easily distributed as a workbench instead of requiring core FreeCAD changes, at first. I was able to take the most recent attempt, PyKDE5, and basically dust off the cobwebs and run a demo app. Would it be worth going further?

I discussed this with some of the KDE people at the Ubuntu Summit, who helped me on some possible funding sources for this sort of project, but for now, to be continued...

OpenCASCADE & Rust

OpenCASCADE is sort of the elephant in the room when it comes to FreeCAD's functionality & reliability. Similarly, there are rumblings about the long-term fate of C++ and its possible replacement by Rust. The argument, in short, is that about 60-70% of browser & kernel bugs are caused due to memory-unsafety, and Rust can provide guarantees about entire elimination of this class of bug.

See this publication on the topic by Consumer Reports, previously known for winning the fight to have car seat belts and exposing the danger of cigarettes.

However, attempting rewrites for software is generally fraught with peril, and the idea of replacing OpenCASCADE wholesale is of an absurd scope.

How could incremental progress be made?

The Data Exchange module of OpenCASCADE is used for file format support, or in other words, ingesting untrusted data. If a Rust implementation of Data Exchange could be produced, it is something which could be useful on its own, even if that project went no further.
Like my FreeCAD work? I'd appreciate any level of support via Patreon, Liberapay, or PayPal! Read more about what I do at my blog.
grd
Posts: 328
Joined: Wed Apr 13, 2022 5:13 am
Location: Eindhoven, The Netherlands

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by grd »

kkremitzki wrote: Mon Feb 06, 2023 10:50 pm OpenCASCADE & Rust

OpenCASCADE is sort of the elephant in the room when it comes to FreeCAD's functionality & reliability. Similarly, there are rumblings about the long-term fate of C++ and its possible replacement by Rust. The argument, in short, is that about 60-70% of browser & kernel bugs are caused due to memory-unsafety, and Rust can provide guarantees about entire elimination of this class of bug.

See this publication on the topic by Consumer Reports, previously known for winning the fight to have car seat belts and exposing the danger of cigarettes.

However, attempting rewrites for software is generally fraught with peril, and the idea of replacing OpenCASCADE wholesale is of an absurd scope.

How could incremental progress be made?

The Data Exchange module of OpenCASCADE is used for file format support, or in other words, ingesting untrusted data. If a Rust implementation of Data Exchange could be produced, it is something which could be useful on its own, even if that project went no further.
Although Rust certainly has its strong points, I don't like the language. I didn't read the entire article about memory safety but one line I want to quote:
Additionally, using Rust for new projects will ultimately result in higher productivity.
So they admit that, and I think that they are right. Here is another quote from that same article:
There’s also a perception that memory-safe languages, namely Rust, are harder to learn and will be difficult to use with hardware, which may dissuade people from learning it in the first place. (However, most other memory-safe languages, like Python, Go, and JavaScript, achieve temporal memory safety through garbage collection, which substantially simplifies many aspects of programming, making the languages famously easier to learn.
Not only to learn but to read and write as well.

So... Why don't we rewrite FreeCAD in Rust? The answer is easy. It is because FreeCAD is a volunteer project and there is no law that requires you to write your code in a memory safe language. But when the time is there that such a law does exist, then I am seriously suggesting to use Nim instead of Rust. Why? Again, because Nim is much easier to read and write which will result in an increase of productivity.

Having said that, there are about a dozen of C files in the FreeCAD repo. That is it, the rest is all C++.
About Nim. Latest Release 2.0.2. Here is Nim in 100 seconds and a Nim package. There are Qt and OCCT packages.
User avatar
onekk
Veteran
Posts: 6144
Joined: Sat Jan 17, 2015 7:48 am
Contact:

Re: FreeCAD Day 2023 - Report and Continued Discussion

Post by onekk »

There are other project that use OpenCascade and many of them have less problem than FreeCAD in using some things.

One example is the Fillet, it is almost deprecated and declared buggy by OpenCascade developers, so probably it will be more simple to avoid to use it, and "simply" write a substitution code that "make the job" , and maybe doing the same for parts that are not working flawlessy until it will be a more easier than replacing the entire "3d modelling engine" with something that seems to no exist in the OpenSource Ecosystem.

Similarly to solve the TNP problem it could be implemented a real database that store model Topology instead of using the XML scheme actually used base on SQLite that has the ability to produce a unique file containing the database, and is used as example by Firefox to store many data.


But all these are long term projects and involve changing probably too much of FreeCAD and breaking the compatibility with old files that probably will be similar to a rewrite of FreeCAD.

As XML schema could be simply modified to store "locations of objects in the database" or "SQL queries" that will supply needed informations stored in the database in a way that is compatible with what actually is stored in the XML file.

But will involve to change the file format as there will be an "Old format" and a "new format", and probably there will be the need to write conversion functions or "helper program" that will convert "Old format" into "new format".

But when a real database is implemented, managing 10 or 100 or 1000 objects will impact less performance as the Database is specifically made to reduce "retrieving times" expecially if the old way is parsing a "file from start to end" as the XML format implies to do.

As some data could be compressed easily and SQlite could store even " binary blobs" it could even store images and maybe coin3d scenes too, and save some transactional data about the "history of the model" on some extent, to take trace of modifications (some strategies has to be used to avoid storing too much datas)

Something could be done as example if you create a sort of "NewPart WB" that store his data in the database but use the OCCT to do the modelling part when needed, ie only when creating the final solid, to not rely on the "not stable" Topology enumeration that OCCT is using and that is the cause of TNP.

About languages, even C++ is memory safe if you code it carefully and do some "garbage collection" manually when needed, and check input data to not produce memory overflows, but this usually implies to have some "coding standards" and "best practices" when coding, that probably are used by "professional programmers" and not much by other programmers, Sadly I don't remember the link but not very long ago I have read an interesting article about the "Supposed modernity" of new languages, done by some expert programmers that at the very end is saying that probably it is a matter of "trends", like in the fashion when the past year dress is an old dress despite it will make the job and his even elegant, but a program is not an "hair cut" nor a dress, it is something functional.

As usual talks are interesting as probably they break the "habits" and tend to show "different points of view" that usually are the base of changing and revolutions, but then someone has to "translate" thinking in "real things", if you could speak of real thing when dealing with "soft"ware, that is by definition very "soft" and not "hard" but these are the basic of "computer science" and probably the wast majority of the audience here. (hoping so :lol:)

Sadly i could read some C++ but I have not learned to program with it when my mind was more "flexible" (I'm not gone past the "hello world", and a little of "C++ for impaired" that is the Arduino Language).

my 2ct (hoping it is not too "old fashioned" to be understandable)


Kind Regards

Carlo D.
GitHub page: https://github.com/onekk/freecad-doc.
- In deep articles on FreeCAD.
- Learning how to model with scripting.
- Various other stuffs.

Blog: https://okkmkblog.wordpress.com/
Post Reply