Update registry.jl

[Larbino1]

Change to stl binary/ascii type detection. Removed check on value of final attr bits, which caused a failure to parse for me, incorrectly treating it as an ascii type stl. If the eof is in the correct place, this value does not matter.

@SimonDanisch Maybe as a MeshIO contributor you can give this a quick look? Its a tiny change!

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 91.66%. Comparing base (d30fbd7) to head (9ffb6e7).

Additional details and impacted files

@@            Coverage Diff             @@
##           master     #388      +/-   ##
==========================================
- Coverage   91.69%   91.66%   -0.03%     
==========================================
  Files          10       10              
  Lines         710      708       -2     
==========================================
- Hits          651      649       -2     
  Misses         59       59              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[SimonDanisch]

Could you add a small test file?

[Larbino1]

Could you add a small test file?

Yeah sure.

Do you mean:

• A test in FileIO
• Checking that detect_stlascii, and detect_stlbinary work
• By adding to the repo an STL of each type, and testing both

[SimonDanisch]

Add a test file here:

FileIO.jl/test/query.jl

Lines 356 to 366 in d30fbd7

	@testset "STL detection" begin
	q = query(joinpath(file_dir, "ascii.stl"))
	@test typeof(q) <: File{format"STL_ASCII"}
	q = query(joinpath(file_dir, "binary_stl_from_solidworks.STL"))
	@test typeof(q) <: File{format"STL_BINARY"}
	open(q) do io
	@test position(io) == 0
	skipmagic(io)
	@test position(io) == 0 # no skipping for functions
	end
	end

[Larbino1]

@SimonDanisch

I've included the file as a test case. Please let me know if you would like any other work, or if you can support merging.

I guess eventually supporting STLs with attribute data would be nice, but for this specific problem (a binary stl, with nonzero 'attribute byte count' but actually containing no attribute byte data), things work correctly rather than being misconstrued as an ASCII stl.

[Larbino1]

Just bumping this again @SimonDanisch @sjkelly

It works, the test is in, the change non-breaking. If there is anything I can do to help get this merged let me know.