Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Hello, >From my side (upstream): 1. I fixed the compilation with ENDIAN_BIG in this commit: https://github.com/castle-engine/castle-engine/commit/63ccfc4dd327fc4de1c71f8b351e1ab1933ba47d . It's now pushed to CGE master. I just removed the swap -- just like Abou said, indeed the swap in this case wasn't sensible at all. Note that I tested ENDIAN_BIG compilation now in a rather stupid way (I just define it manually, while actually running compiler on regular x86_64). I didn't really run it on big-endian machine. 2. Abou's idea with "case" in record -- that's just an excellent idea. Thank you, I have implemented it now :) Details: - Note that it would not solve the faulty code in src/scene/load/x3dloadinternal3ds.pas , doing stuff like "Col3Byte[2] := b;" , because "AsBytes" is not a default property. - Note that all record properties have to stay read-only otherwise we run into a risk of "traps". This is described on https://castle-engine.io/coding_traps and at comment "Note: We avoid introducing in these records *any* method that changes the current record value." in https://github.com/castle-engine/castle-engine/blob/master/src/base/castlevectors_generic_float_record.inc . So the writes to records must happen directly through fields. Using "case" allows us to expose fields in more ways -- great! - Using "case" is an excellent idea to have writeable Data, and also "subsets" like XY inside TVector3, XYZ inside TVector4. It's now done on branch https://github.com/castle-engine/castle-engine/tree/vectors-data-as-case . I'll merge it tomorrow if it will pass all automatic Jenkins tests (with various FPC and Delphi versions -- but I did test that FPC 3.2.0, 3.2.2, trunk and Delphi 11 all allow "case" in advanced records). Thanks! Michalis niedz., 9 kwi 2023 o 18:09 Abou Al Montacir napisał(a): > > Hi, > > On Thu, 2022-05-26 at 20:23 +0200, Abou Al Montacir wrote: > > CGE build correctly on m68k architecture now. > > This was broken again in new upstream 7.0~alpha.2 release. > > There was a rework of TVector3Byte where the base data was changed from an > array to a record fields and a default property was added to allow array like > access. > However, this array like property is read only, while a load from stream > function tries, in big endian mode, to switch bytes. > While I don't think this swap endianess code is needed at all, I would > preferred a faster implementation with basic records: > > TVector3Byte = packed record > > case Boolean of: > > false: (x, y, z: Byte); > > true: (AsBytes: array[0..2] of Byte); > > end; > > > Anyway, I'll let upstream fix this as they wants, but probably this will > never be in Bookworms. > > -- > > Cheers, > Abou Al Montacir
Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Hi, On Thu, 2022-05-26 at 20:23 +0200, Abou Al Montacir wrote: > CGE build correctly on m68k architecture now. This was broken again in new upstream 7.0~alpha.2 release. There was a rework of TVector3Byte where the base data was changed from an array to a record fields and a default property was added to allow array like access. However, this array like property is read only, while a load from stream function tries, in big endian mode, to switch bytes. While I don't think this swap endianess code is needed at all, I would preferred a faster implementation with basic records: TVector3Byte = packed record case Boolean of: false: (x, y, z: Byte); true: (AsBytes: array[0..2] of Byte); end; Anyway, I'll let upstream fix this as they wants, but probably this will never be in Bookworms. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#891685: [Pkg-pascal-devel] Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Fixed -1 7.0~alpha.1+dfsg-8 CGE build correctly on m68k architecture now. -- Cheers, Abou Al Montacir signature.asc Description: This is a digitally signed message part
Bug#891685: castle-game-engine: FTBFS on m68k: color and vector tests fail
Source: castle-game-engine Version: 6.4+dfsg1-2 Severity: normal Tags: upstream User: debian-...@lists.debian.org Usertags: m68k Builds of castle-game-engine for m68k (admittedly not a release architecture) have been failing. In addition to the general big-endian test suite issues I reported as #891684, there are four more I see only on m68k [1]: Failure: Message: TTestCastleColors.TestHSV: Exception class: EAssertionFailedError Exception message: at $8007A68A TTESTCASTLECOLORS__TESTHSV, line 62 of tests/testcastlecolors.pas Failure: Message: TTestImagesDraw.TestDrawToRgb: Vectors (TVector3Byte) are not equal: expected: 2 3 32, actual: 2 3 11 Exception class: EAssertionFailedError Exception message: Vectors (TVector3Byte) are not equal: expected: 2 3 32, actual: 2 3 11 at $802E59AC TCASTLEBASETESTCASE__ASSERTVECTOREQUALS, line 109 of tests/castlebasetestcase.pas Failure: Message: TTestImagesDraw.TestDrawToGrayscaleAlpha: Vectors (TVector2Byte) are not equal: expected: 111 128, actual: 103 128 Exception class: EAssertionFailedError Exception message: Vectors (TVector2Byte) are not equal: expected: 111 128, actual: 103 128 at $802E5842 TCASTLEBASETESTCASE__ASSERTVECTOREQUALS, line 101 of tests/castlebasetestcase.pas Failure: Message: TTestCastleSceneManager.TestLoadLevel: Vectors (TVector3) are not equal: expected: 2.15621185302734 2 -2.33851003646851, actual: 3.2496919631958 2 -5.4161548614502 Exception class: EAssertionFailedError Exception message: Vectors (TVector3) are not equal: expected: 2.15621185302734 2 -2.33851003646851, actual: 3.2496919631958 2 -5.4161548614502 at $802E615E TCASTLEBASETESTCASE__ASSERTVECTOREQUALS, line 151 of tests/castlebasetestcase.pas Could you please take a look? Thanks! [1] https://buildd.debian.org/status/fetch.php?pkg=castle-game-engine=m68k=6.4%2Bdfsg1-2=1518961263=0 -- Aaron M. Ucko, KB1CJC (amu at alum.mit.edu, ucko at debian.org) http://www.mit.edu/~amu/ | http://stuff.mit.edu/cgi/finger/?a...@monk.mit.edu
