On Sat, Mar 16, 2024 at 10:04:34AM -0500, Kurt Kremitzki wrote: > The current status of this: > > - the Path workbench has a test which checks string equality on > generated vs expected G-code for an operation. On the i386 arch only, > the produced G-code is not what is expected, although it is > consistent. In a G-code viewer, what is produced is visually > identical, just with an increased number of arcs of shorter length. > I've patched this test with a special-case check to use a different > "expected" string id the arch is i386, and this works, even if not > elegant; the further yak-shaving needed has been discussed with > upstream.
I think this is a feasible way forward. (I'd also not focus too much on i386, as this architecture is showing it's age and hardware supporting only i386 must be quite ancient in 2024, especially when doing CAD on it.) Said that, I think it makes sense to keep it working on a best effort basis, but this should not be a blocker for the other archs. IOW, I think your patch/approach is more than appropiate. > > - on armel, it seems FEM workbench tests are failing, but it isn't > enough to e.g. disable that workbench, because then the failures just > pop up elsewhere. I've repeated this "disable test, different test > segfaults elsewhere" pattern about 5 times. It seems like, for some > reason, the armel builds are no longer viable. It isn't ideal, but > FreeCAD is probably not getting much use on the arch, so it may be > that it ought to be removed from the architecture. I agree, armel is not the target audience for a CAD system, it is like i386, just worse by magintudes in terms of perfomance/usablity. > I would appreciate some feedback on these 2 items. I could do an > upload with a patch for the Path test and request armel removal if > nobody has any better suggestions or reservations about this approach. IMHO a sane solution. Thanks for caring! > Thanks, > Kurt
signature.asc
Description: PGP signature
