CADCloud

[vejmarie]

Just a cosmetic idea I had here, what would you think of allowing to use a same gradient background color as in FreeCAD?

the ugly '80 blue one

80's are trendy (especially to me who is 45 )

[vejmarie]

How would you like feedback? Should i post here or create issues on your github repo?

I think the best will be on github likt that we can keep track of everything. I also have created a project associated to the github page, where we can list tasks and cherry pick the one that we are interested by. My current priority is to build the Docker image as this is a good idea to locally test such services especially if you want submit patch.

Let's assume that justyour.parts is the online platform for the moment

[vejmarie]

Looks very promising. Sorry for this total newbie question, but I know little about the practice of cloud, the companies I used to work keep their precious data in house.

Maybe better see CADCloud as some kind of GitLab for CAD.
I say GitLab (instead of GitHub) because in the same way there is are actually 2 things behind :

• Either you can use a cloud-based instance of the CADCloud server (like gitlab.com is for GitLab). It may offer all kind of free/paid services
• Or you can host your own instance of CADCloud and use it privately (like a company may host its own GitLab server)

You are right this is more a gitlab approach. Right to choose is always better

[wmayer]

I will try to build a container during the week-end. If I am unable to make it, it will have to wait for 2 weeks because I have to attend the OCP summit and need to move myself back from Europe to US. The Cloud workbench needs to be activated at compilation time -DBUILD_CLOUD=1 and it shall be included as a standard feature into your binaries tree.

I will have a look to support remote Link for Part::Link I think it is a great idea. I need to parallelize the download operations which are severely sequential and dependant of latency which is just frustrating with modern machin which could handles many threads.

FYI, yesterday evening I built the Cloud module on Linux and got a failure because of the file xlocale.h. Any idea if this is needed on some platforms? If yes which package would have to be installed? Looking at the Ubuntu package I didn't get a clear answer: https://packages.ubuntu.com/search?sear ... n&arch=any

At least for me it worked to just comment out the file. Also I added the build option BUILD_CLOUD into CMake so that users can activate it more conveniently. git commit f4dcd0a5f9164

[vejmarie]

If you got ubuntu, you might have to apply this as a workaround

ln -s /usr/include/locale.h /usr/include/xlocale.h

Newer version of ubuntu are a little bit weird regarding locale management unfortunately

[kkremitzki]

There was an old OpenCASCADE bug triggering that problem which can be found searching the forums, you probably need to wrap #include <xlocale.h> in an #if defined(__APPLE__) #endif block.

[vejmarie]

There was an old OpenCASCADE bug triggering that problem which can be found searching the forums, you probably need to wrap #include <xlocale.h> in an #if defined(__APPLE__) #endif block.

Argh another MacOS weird behavior. Sorry .

[wmayer]

ln -s /usr/include/locale.h /usr/include/xlocale.h
Newer version of ubuntu are a little bit weird regarding locale management unfortunately

Sure? If this header is supposed to be part of the standard C library then it's not xlocale.h but clocale when using it in C++.

Here is the bug report in OCC https://tracker.dev.opencascade.org/view.php?id=28971 and it states that xlocale.h is a non-standard header file.

[vejmarie]

ln -s /usr/include/locale.h /usr/include/xlocale.h
Newer version of ubuntu are a little bit weird regarding locale management unfortunately

Sure? If this header is supposed to be part of the standard C library then it's not xlocale.h but clocale when using it in C++.

Here is the bug report in OCC https://tracker.dev.opencascade.org/view.php?id=28971 and it states that xlocale.h is a non-standard header file.

I believe kkremetzi approach is far much better than what I guide you to
https://www.linuxquestions.org/question ... 175612648/
xlocale.h has been deprecated in glibc, so we shouldn't include it on linux and windows, but it has to be included on MacOS or FreeBSD. Regarding linux only with recent version of glibc

[JulianStirling]

You are right this is more a gitlab approach. Right to choose is always better

The idea of a GitLab for Open Hardware is really exciting! We do most of our hardware development on GitLab (Example1 Example2). We find it very powerful for OpenSCAD as we can use the CI to build the STLs, and the OpenSCAD code is easy to track in Git.

Our designs in FreeCAD are much harder to track in Git (E.g. this much less complete project).

The biggest issue we have had with GitLab are that many members of the hardware community are not Git savvy and find it hard to contribute. The other is that if we keep generated files such as STL files out of the repo then parts cannot be viewed.

The biggest thing I have found at OpenHardware events that people talk about is documentation. I work on a program for hardware documentation. This generates web documentation from GitLab CI (example) which has threeJS for viewing STLs generated by the CI. What it lacks is a good way to show things like STEP and FCStd files, this seems like a !HUGE! step in the right direction.

I would be very interested in talking about how to integrate documentation into justyour.parts. I also encourage you to join the GOSH - Gathering for Open Science Hardware, you will find many people very interested in this project.

Thank you for starting this project, Iook forward to the Docker image.