Testing GEOSgcm with M1 GNU

I'm going to open this as a tracking branch for GEOSgcm issues when running with GNU on M1.
Thanks to @iains, these are not needed anymore for M1 and GEOS.

[x] ~pFUnit (https://github.com/Goddard-Fortran-Ecosystem/pFUnit/issues/338#issuecomment-1125160712)~
[x] ~pFlogger (https://github.com/Goddard-Fortran-Ecosystem/pFlogger/issues/80)~
[x] ~GMAO_stoch (https://github.com/GEOS-ESM/GMAO_Shared/pull/261)~

At present the only real "bug" would be in ESMA_env where we need a slight change to g5_modules to make it not complain:

[x] ESMA_env (https://github.com/GEOS-ESM/ESMA_env/pull/78)
[x] ESMA_cmake (https://github.com/GEOS-ESM/ESMA_cmake/pull/274)

Additional issue. I can get GEOSgcm to build just fine, but it can't run. The issue seems to be something in the M1 GNU I built. I did this following how @fxcoudert (or someone??) did in the Homebrew recipe for GCC, but by hand since on my laptop, I'm not allowed to install in /opt/homebrew and I could not get Homebrew M1 gcc to work when installed under $HOME.
I built as per my modulefile for gcc 11.2.0, where I use the same @fxcoudert tarball as well as a patch that I see for arm64 in the brew recipe.
The issue seems to be that the executable built by our CMake is not handling rpaths the same on Arm as it does on Intel. When rs_numtiles.x tries to run on M1, I get:
dyld[48868]: Library not loaded: @rpath/libgomp.1.dylib
  Referenced from: /Users/mathomp4/Models/GEOSgcm/install-Debug/bin/rs_numtiles.x
  Reason: tried: '/Users/mathomp4/installed/MPI/gcc-gfortran-11.2.0/openmpi-4.1.3/Baselibs/7.1.0/Darwin/lib/libgomp.1.dylib' (no such file), '/Users/mathomp4/Models/GEOSgcm/install-Debug/lib/libgomp.1.dylib' (no such file), '/Users/mathomp4/installed/MPI/gcc-gfortran-11.2.0/openmpi-4.1.3/Baselibs/7.1.0/Darwin/lib/libgomp.1.dylib' (no such file), '/Users/mathomp4/Models/GEOSgcm/install-Debug/lib/libgomp.1.dylib' (no such file), '/usr/local/lib/libgomp.1.dylib' (no such file), '/usr/lib/libgomp.1.dylib' (no such file)

and if I otool -l I see:
otool -l /Users/mathomp4/Models/GEOSgcm/install-Debug/bin/rs_numtiles.x
...
Load command 31
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/libstdc++.6.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 7.29.0
compatibility version 7.0.0
...
Load command 39
          cmd LC_LOAD_DYLIB
      cmdsize 48
         name @rpath/libgomp.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 2.0.0
compatibility version 2.0.0
Load command 40
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/libgfortran.5.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 6.0.0
compatibility version 6.0.0
Load command 41
          cmd LC_LOAD_DYLIB
      cmdsize 56
         name @rpath/libgcc_s.1.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.1.0
compatibility version 1.0.0
...

Now, let us compare that to what I see on my Intel Mac (on Big Sur):
...
Load command 30
          cmd LC_LOAD_DYLIB
      cmdsize 104
         name /Users/mathomp4/installed/Core/gcc-gfortran/11.3.0/lib/libstdc++.6.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 7.29.0
compatibility version 7.0.0
...
Load command 36
          cmd LC_LOAD_DYLIB
      cmdsize 96
         name /Users/mathomp4/installed/Core/gcc-gfortran/11.3.0/lib/libgomp.1.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 2.0.0
compatibility version 2.0.0
Load command 37
          cmd LC_LOAD_DYLIB
      cmdsize 104
         name /Users/mathomp4/installed/Core/gcc-gfortran/11.3.0/lib/libgfortran.5.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 6.0.0
compatibility version 6.0.0
...
Load command 40
          cmd LC_LOAD_DYLIB
      cmdsize 104
         name /Users/mathomp4/installed/Core/gcc-gfortran/11.3.0/lib/libquadmath.0.dylib (offset 24)
   time stamp 2 Wed Dec 31 19:00:02 1969
      current version 1.0.0
compatibility version 1.0.0

So...not sure what to do.
I do see some output in this Homebrew issue:
https://github.com/Homebrew/homebrew-core/issues/97874
like:
==> Changing dylib ID of /opt/homebrew/Cellar/gcc/11.2.0_3/lib/gcc/11/libgomp.1.dylib
  from @rpath/libgomp.1.dylib
    to /opt/homebrew/opt/gcc/lib/gcc/11/libgomp.1.dylib

and I wonder if I need to do the same thing in my by-hand install of GCC? I never have to do it on my version of GCC on Intel on Big Sur, but that is both architecture and OS changing!
A few swings around Google did bring up a configure flag called --disable-darwin-at-rpath which sounded interesting. But, when I tried it, the GCC build was not happy. This seemed to be something that @iains said it wasn't exactly supported in this issue.
Sadly, I nuked my original build of GCC to try --disable-darwin-at-rpath so I'm doing the "rebuild from scratch" sort of thing. I'll check once that's done if the libgomp.1.dylib I get on M1 looks different under otool -l compared to that on Intel.

OK. Can we start from which version of gcc you have built and how you have configured it.
It should be entirely possible (on Arm64 or x86_64) [gcc-11.3-darwin-r0 or gcc-12.1-darwin0r0] to configure it to be installed in your home directory (or /users/Shared) i.e. somewhere writable to non-admin.
If you then use that compiler to build a dependent project, the compiler should embed the rpaths that it needs (additional to any that are supplied by CMAKE or other build system).
This is (probably) not an issue with  GEOSgcm but more with the mechanisms being used to combine pieces of the build environments.

Oooh. Interesting! I see from this comment, @iains has recommended using:
https://github.com/iains/gcc-11-branch/releases/tag/gcc-11.3-darwin-r0
(associated README)
Well then, I have a task for tomorrow I do believe! Let's try building this!

OK. Can we start from which version of gcc you have built and how you have configured it.

@iains I essentially echo'd what Homebrew did as a first attempt, I grabbed the tarball they use:
wget https://github.com/fxcoudert/gcc/archive/refs/tags/gcc-11.2.0-arm-20211124.tar.gz

and a patch:
wget 'https://gcc.gnu.org/git/?p=gcc.git;a=patch;h=fabe8cc41e9b01913e2016861237d1d99d7567bf'

and apply the patch.
Then it's the usual way I build gcc:
./contrib/download_prerequisites
cd ..
mkdir build && cd build
../gcc-gcc-11.2.0-arm-20211124/configure --prefix=$HOME/installed/Core/gcc-gfortran/11.2.0 \
  --enable-languages=c,c++,fortran \
  --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk \
  |& tee configure.log
make -j4 |& tee make.log
make install |& tee makeinstall.log

It's not as fancy as Homebrew's method, but I decided to start from what I knew.
As for the "not in $HOME" that was for Homebrew's GCC. For some reason, it just wasn't happy being in somewhere other than /opt/homebrew. I know I found a post somewhere online where someone else had the same issue, but I seem to have lost it. Thus my thought to build by hand. I'm going to try gcc-11.3-darwin-r0 tomorrow

That gcc-11.2.0-arm-20211124 was an experimental branch that Homebrew has been using for some time, but we're migrating. Now I would recommend to build directly the branches from Iain's rapo, either gcc-11.3-darwin-r0 (for 11.3) or the 12.1 one.

Okay. Per @iains to fix an issue with ieee_arithmetic, I built a clone of:
https://github.com/iains/gcc-11-branch
This seems to have support for quad-precision, so we can stop caring about many of the PRs and issues above.
However, I seem to now have an error with HDF5:
make[4]: Entering directory '/Users/mathomp4/Baselibs/ESMA-Baselibs-7.1.0/src/hdf5/hl/test'
  CCLD     test_lite
ld: warning: option -s is obsolete and being ignored
ld: in ../../hl/src/.libs/libhdf5_hl.a(H5LTparse.o), in section __TEXT,__text reloc 347: symbol index out of range for architecture arm64
collect2: error: ld returned 1 exit status
make[4]: *** [Makefile:983: test_lite] Error 1

I've filed an issue (https://github.com/iains/gcc-11-branch/issues/3)

Performance Results of GEOSgcm (6 hours, C12, 1x6, No ExtData)
Release

Processor
Compiler
SDYN (s)
PHYS (s)
Last NoRad Tput (d/d)
Last Rad Tput (d/d)
Final Tput (d/d)

Cascade Lake (Discover)
GCC 11.3
11.45
36.39
501.7
372.2
348.802

Coffee Lake (Intel Mac)
GCC 11.3
15.23
58.37
287.8
224.1
232.768

M1 (Arm Mac)
GCC 11.3
4.41
41.30
533.3
362.5
340.575

---
---
---
---
---
---
---

Cascade Lake (Discover)
Intel 2021.3
2.67
28.94
806.3
526.4
472.667

Coffee Lake (Intel Mac)
Intel 2022.1

Aggressive

Processor
Compiler
SDYN (s)
PHYS (s)
Last NoRad Tput (d/d)
Last Rad Tput (d/d)
Final Tput (d/d)

Cascade Lake (Discover)
GCC 11.3
3.02
33.91
666.4
482.4
399.860

Coffee Lake (Intel Mac)
GCC 11.3
4.87
53.38
418.4
313.1
272.146

M1 (Arm Mac)
GCC 11.3
CRASH
CRASH
CRASH
CRASH
CRASH

---
---
---
---
---
---
---

Cascade Lake (Discover)
Intel 2021.3
2.48
21.30
1107.8
675.4
603.894

Coffee Lake (Intel Mac)
Intel 2022.1

Would larger final Tput be "better"?

Ah. Yes. "Tput" = "throughput" (in model-days/wall-clock-day). I just abbreviated it because the table was already too wide :)

Could you try the aggressive with -O2 -march=armv8-a -ffast-math -ftree-vectorize -funroll-loops --param max-unroll-times=4
TBH I am not sure what we would do for native at present, and we have not even started to figure out tuning for M1 (i am not sure that the relevant data are even published, so me might have to infer from what clang does).

Sadly, moving to -march=armv8-a didn't help. But I suppose the "good news" is that there are only four flags that might be causing it:

-ffast-math
-ftree-vectorize
-funroll-loops
--param max-unroll-times=4

(If -O2 is the cause, I'll eat my hat 😄 )
The GNU Aggressive flags we have are from Jerry DeLisle on the GCC list, so they were a bit above me. It will be interesting to figure out which flag(s) might be causing this. Though it is about 1 hour between each test thanks to big build!
Though, honestly, our "Release" flags seem to have all the performance we might get anyway, so the easy answer might be to just code in CMake "if APPLE and ARM64, set Aggflag=Relflags".

I also did a set of runs at C24 (so 4x the number of columns per process) as this is a bit closer to the per-process number-of-columns we run with. And the numbers are much the same.
Good news is that GCC 11 M1 is roughly as good as Intel 2022 on Coffee Lake with Aggressive flags! Kudos to @iains and the GCC Team (and I suppose the Apple chip engineers)!

 I tried doing: -Ofast -march=armv8-a and C12 ran...and it did a LOT. Made physics much faster. Sadly, though, at C24 it still crashes. I am using the same restarts, etc. So I wonder what is happening.
Oh well, at least I learned about -Ofast. New flag for me!
I suppose my next work is to move on to GCC 12 and see if it has the same issues with our model on M1 as it does on Intel.

did you have a chance to try the 12.1-pre-r1 version?

Not yet. I'm hoping to try building it today. I was pulled away to other work, but I have some time now to build compilers, etc. I'm finalizing my "get our flags right" setup first. Hopefully then GCC 12 will be plug-and-play!

edit: is the Intel issue compiler-related or something else? (equally, we want to fix bugs there too)

This issue is...weird. For some reason, GCC 12 does not like GEOS and I don't know why. I recently ran 10 runs of C12 with GCC 11 and GCC 12. With GCC 11, all 10 ran successfully. With GCC 12, only 2 of 10 ran. The other eight died in the same vertical remapping call. But no flags or source code changed between these two runs, just changed the compiler! And the crash is sporadic. One dies at 1000z, another at 0700z, another at 1330z... it's so random!
I'm going to try doing a 10-run set at a higher resolution and see what I see. C12 is so coarse that I might just be exposing a weird setup issue. But C24 is a sort of my "gold standard" low-res case.
But maybe we're seeing some sort of memory corruption on our end that GCC 12 is just more sensitive to?

yeah, probably what's more likely is that one of the array accesses is going wrong and then some inappropriate number is being pulled into the calculation.
Is there any way to produce the assembly / .s or .i even (plus the flags used to compile) .. ?

@iains Looks like your GCC 12.1 branch runs! Using a sample size of 1 run, it seems a bit slower than 11.3...but that could just be variability of the laptop (maybe it hit the efficiency cores a bit more?).
One interesting thing is that it looks like C12 GCC 12.1 on M1 is stable. I ran it a few times and nothing went wiggy. So I thought I should look at the default Intel GNU flags:
-O3 -march=westmere -mtune=generic -funroll-loops -g
  -ffree-line-length-none -fno-range-check -Wno-missing-include-dirs
  -fbacktrace -ffpe-trap=zero,overflow -fbacktrace
  -fallow-argument-mismatch -fallow-invalid-boz -falign-commons

I mean, westmere is ancient at this point and I think everything we might run on is Broadwell/Haswell at least (and with Intel Fortran we don't support anything below that because we run with core-avx2) so I decided, heck, let's try -march=haswell. And when I do that, 🎉 , I can run 10, 12 runs at C12 and nothing crashes!
Does this tell me why GCC 12 doesn't seem to like GEOS anymore? No. But is a valid workaround if it means not supporting a processor we don't use? I mean... 😄

I've no way to judge what effect we might get with the efficiency cores ...

Yeah. I might need to stroll through the Open MPI lists/repos and ask/annoy the gurus there (sorry in advance @jsquyres) and see if they have info about what happens if you do mpirun -np 6 on an Apple M1 with 4 performance and 4 efficiency cores.  (And I suppose Alder Lake will be much the same...)
Heck, from an lstopo image I made, I'm not even sure if the version of hwloc I had on hand can see the difference (though that could be from my not knowing the right options to pass hwloc...)

Final thought: With #426 we should get M1 compatibility. Huzzah!

Let's do an update of the timings with the newer GNU flags and now that I have access to an M1 Max. These are all 1-day and no extdata, history, or checkpointing to interfere.
I think the first take away is "M1 Max be nice". I mean, it's right there with  Cascade Lake with Intel compilers on Aggressive optimizations. And I'm guessing the fine folks at GNU could probably figure out how to tune for the M1 given time. At the moment I'm mainly doing:
Fortran_FLAGSarm64 = -O3 -march=armv8-a -mtune=generic -funroll-loops
  -g -ffree-line-length-none -fno-range-check -Wno-missing-include-dirs
  -fbacktrace -Wno-unused-dummy-argument -ffpe-trap=zero,overflow
  -fbacktrace -fallow-argument-mismatch -fallow-invalid-boz -falign-commons -fPIC -fopenmp

because "it works" but it's not tuned at all and Aggressive is pretty much just Release with the M1.
It's now time to try fiddling around. The -Ofast flag @iains informed me about above would be nice to get working, so I'll try for that first...

 I figured it would, but you never know!


fix(deps): update module golang.org/x/term to v0.23.0

This PR contains the following updates:

Package
Type
Update
Change

golang.org/x/term
require
minor
v0.22.0 -> v0.23.0

Configuration
📅 Schedule: Branch creation - At any time (no schedule defined), Automerge - At any time (no schedule defined).
🚦 Automerge: Disabled by config. Please merge this manually once you are satisfied.
♻ Rebasing: Whenever PR becomes conflicted, or you tick the rebase/retry checkbox.
🔕 Ignore: Close this PR and you won't be reminded about this update again.

[ ] If you want to rebase/retry this PR, check this box

This PR has been generated by Renovate Bot.

ℹ Artifact update notice
File name: go.mod
In order to perform the update(s) described in the table above, Renovate ran the go get command, which resulted in the following additional change(s):

1 additional dependency was updated

Details:

Package
Change

golang.org/x/sys
v0.22.0 -> v0.23.0


add support to set MemorySwap

Signed-off-by: Qiang Huang<EMAIL_ADDRESS>

LGTM

I think this was the commit @crosbymichael was referring to: https://github.com/docker/libcontainer/commit/e8f5b543010eb0db146fd2593284ed19af93eccd and it was merged


Enable Ceilometer events

The upstream ceilometer-write-qdr for Train is not in sync with the contents
deployed downstream for ceilometer-write-qdr.yaml. The upstream implements the
Publish parameters, but the current 16.1 deployment does not provide those.
Added appropriate configuration required for RHOSP16.1.
Signed-off-by: Leif Madsen<EMAIL_ADDRESS>

Testing is currently in progress. Do not merge, but I expect this will work.

Testing is completed and the expected configuration is available:
sinks:
    - name: event_sink
      transformers:
      triggers:
      publishers:
          - gnocchi://?filter_project=service
          - notifier://<IP_ADDRESS>:5666/?driver=amqp&topic=cloudops04-event

I can confirm events are now coming in with this change.


x/net/http2: WINDOW_UPDATE sent rate too high and can't be configured

What version of Go are you using (go version)?
golang:1.10.0 linux
Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (go env)?
container: rhel
kubenet:
What did you do?
Currently golang http2 stack will send WINDOW_UPDATE back when receive a request with data.
It means a client will recevie a response and WINDOW_UPDATE when it send a request with data to golang http2 server.
sent one 'request' package and got two 'reponse' package, that will impact client performance in a high load traffic.
In fact, golang stack use 2^31 as default window size for connection. It is very big and updated too frequently is unnecessary.
What did you expect to see?
Change this behavior or make it configurable like other language http2 stack.
I think c++/java popular http2 stack have a configurable rate (default is 50%) used for sending WINDOS_UPDATE frame when the rate of left size/total is less than it.
What did you see instead?

/cc @rs @fraenkel @bradfitz

Definitely room for improvement here. (There might even be a TODO about this in the code, IIRC) But let's not add configurability here.

The above commit is just the code change without tests. The test changes are coming as are additional tests for the new accounting. But it seems I cannot get to the codereview to mark it as DO NOT SUBMIT since I get 'No issue exists with that id (150197)'

I could not find the change in the master.
when will this change merged to master?

Reopening because https://go.dev/cl/432038 (which marked this issue fixed) was reverted.


Search box suggestions keyboard issue

When you type something in the search box, press the down arrow (to select a suggestion) and press some key*, it will go to that module as if you pressed Enter.
*Keys: Ctrl, Alt, Shift, Tab, Left arrow, Right arrow, Home, End, Delete, Page up, Page down, Windows key, F keys (F1, F2...), basically any key which doesn't produce a character (except space/backspace and up/down arrows).
(I discovered this by accident because often I'm not sure where I need to go, and I do "Ctrl+A" to select what I just typed and type something else)

Fixed. Thanks.

Hm, it seems this is fixed for Ctrl, Shift and Alt (Alt also deletes text but doesn't matter), but this is still happening with a lot of keys, like left and right arrow, Tab, F keys, Home, End, etc.
Also, while testing now, I found another weird thing - if I type for example the letter "b" and then quickly press the down arrow to select something, it will take me to the first thing selected (in this case Backup Configuration Files), without ability to choose something else.

Well, I'll check tomorrow, okay.
Are you human? 😃

Haha, I knew something like that would come up sooner or later. 😄 I actually have 8 more issues prepared, but I didn't want to make too many at once, to overwhelm you. 😄
I'm not an alien, but that happened because I was writing down in notepad whatever bug I stumbled upon while using Webmin over a period of the last half a year or something, and I didn't have time to make them into proper GitHub issues (I only wrote bugs in a few words which probably only I could understand).
And amazingly, you already fixed some of them, before I had the chance to report them, bravo! 😃 For example, here are some fixed bugs from my notes (I rewrote them now to be more understandable):

Clicking rightmost pixel on the screen does not select scrollbar (when there is no sidebar)
Virtualmin => Select virtual server => Files and Directories => Right click on a file => Edit => Shows empty window, like the file is empty (and from File Manager it's working as it should)
Virtualmin => Edit Users => Click on user => Email settings => Inbox mail file (click link) => Return to user list OR click Edit Users in left navigation => Dropdown box with virtual servers will display "/" instead of the domain list
After uploading a file in File manager, the screen stays dimmed and cannot click anything (upload is successful though)
In File manager when you click more than once on a folder, another spinning circle will appear for every click
When desktop notifications are clicked, they should do the same as when you click on the notification in the sidebar

👽

Not bad at all.
The reason I fixed them because couple of few last release it's exactly what I was doing. I also have a notepad with list of bugs, some of them were over a year old.
I also keep track of every single issue I come across. I just don't always give it a priority.
My main priority is Mail now, so I would like to ask you to report unurgent issues a bit later.
I will take a quick look at already mentioned things to keep things in order.

All right! I just checked and none of them are urgent issues. Your mail design looks amazing by the way, I can't wait to see it in action. ✉
I just donated you about 3000 руб worth of Bitcoin, to break the ice on that BTC address. 💸 Keep up the great work. 😄

Thanks a lot, appreciate this.
For all to watch and smile. 🙂
https://youtu.be/gz7IPTf1uts

Alright, fixed. Happy now? :sweat_smile:
The other issue, where you super quickly click down on the first key entry, can be left alone as is, I think! Believe me, there is no one on Earth but us are going to notice it. It's below minor lever.
Thanks overall. I like search autocomplete much more now. I wanted to do it for ages but always put this off. (I actually could not find the straight forward solution to manage private events until now).


Importing nmslib, cannot load any more object with static TLS

I am getting a dlopen error when importing nmslib after tensorflow:
python -c "import tensorflow; print(tensorflow.contrib); import nmslib"
 File "<string>", line 1, in <module>
<module 'tensorflow.contrib' from ...>
ImportError: dlopen: cannot load any more object with static TLS

(printing tensorflow contrib simulates importing a module that uses tensorflow, e.g. extending its classes)
switching the order gives no error, and everything works correctly. But in the context of a large code base, it is hard to ensure that nmslib is always imported first, since there are many entry-points. The same thing happens with tensorflow, and it looks similar to this issue: https://stackoverflow.com/questions/50398358/import-error-when-unit-testing-flask-application-with-nmslib
This does not happen on my mac, but only on our Circle CI build, running in a circleci/python:3.6 docker image.
Any suggestions for how to fix this?
I have tried setting the env variable CXXFLAGS="-fPIC -ftls-model=global-dynamic" when pip installing nmslib.

Hi @matthen thank you for the thorough investigation! does tls-model=global-dynamic help?

No it doesn't :/

Funny, we don't use much thread local storage: just a few bytes.

I was trying to reproduce the numpy example, but it seemed to be working on a new instance. I replaced the original comment above with a tensorflow example that is failing. In practice the issue looks like:
module using tensorflow module_a.py
import tensorflow

class MyClass(tensorflow.contrib....):
   ...

module using nmslib module_b.py
import nmslib

...

entry-point, e.g. a unit test: test.py
import module_a
import module_b

gives the dlopen error.

I think the tensorflow library is forcing static TLS for all the following imports, as it uses TLS and nmslib does not.
readelf -l tensorflow/libtensorflow_framework.so | grep TLS
 TLS            0x0000000000cc5360 0x0000000000cc6360 0x0000000000cc6360

no results for nmslib. That explains why importing nmslib first causes no error.

Another 'fix' is to set LD_PRELOAD=nmslib.cpython-36m-x86_64-linux-gnu.so, but I don't have a very good way of setting that everywhere/for everyone

@matthen could you try to add the option -fPIC -ftls-model=global-dynamic inside the BuildExt function in puthon_bindings/setup.py? You can then install the library locally. I think pip likely ignores external CXX flags.

I confirmed above that there is no TLS line in my built nmslib.so file with readelf:
# built normally:
readelf -l nmslib.cpython-36m-x86_64-linux-gnu.so  | grep TLS
TLS            0x00000000003f8168 0x00000000005f8168 0x00000000005f8168

# built with CXX_FLAGS="-fPIC -ftls-model=global-dynamic"
readelf -l nmslib.cpython-36m-x86_64-linux-gnu.so  | grep TLS
(no results)

thank you for the thorough check. Internet says that with global-dynamic it should be fine, but it is not, argh. :-(

One trick that helped in one part of our code was to remove some parts of tensorflow we don't use, and that use TLS:
rm -rf tensorflow/contrib/tensor_forest && touch tensorflow/contrib/tensor_forest.py

@matthen interesting, how do figure out which parts do?

Solved for me by placing  import nmslib in the _init,py file of the project

@guyalo this is interesting, thank you. @matthen could you check if this helped you?

Unfortunately that is not an option in the context of our work as we are using a mono repo with multiple entry points, unit tests, scripts etc, not all of which should import nmslib


Mapping tab - arranging by Channel No Ascending not working as expected.

Please see the attached screenshot, when in the mapping tab, channel numbers are not currently being ordered as expected, making management a little more challenging, it is as though they are not being treated as numerical values.
Version: 1.2 (0)
Docker container
Ubuntu VM

I don't see this issue myself. Can you tell me exactly your steps?

For the sake of further testing, I deleted and recreated the container,
keeping only the config files in place. The same thing happens. I tried the
basics such as ctrl+f5 refresh and incognito mode and nothing has changed.
It seems to have only happened since the recent update.
There is no change in ordering on the m3u that threadfin itself creates,
just the way that it is presented within the mapping tab.
On Mon, Aug 12, 2024 at 6:22 AM Nick Wallace @.***>
wrote:

I don't see this issue myself. Can you tell me exactly your steps?
—
Reply to this email directly, view it on GitHub
https://github.com/Threadfin/Threadfin/issues/332#issuecomment-2283132408,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADAE74XJEARXEOOW6SVXDR3ZRBBAJAVCNFSM6AAAAABMKGSHFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTGEZTENBQHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

I have just this moment fixed the issue.
It would seem that for some reason, some of the channels had been
automatically populated to have their channel name in the channel number
field.
After assigning the affected channels numbers, saving, and refreshing, it
now presents itself correctly again.
The affected channels were at the bottom of the playlist.
On Mon, Aug 12, 2024 at 11:16 AM Frankie Smith @.***> wrote:

For the sake of further testing, I deleted and recreated the container,
keeping only the config files in place. The same thing happens. I tried the
basics such as ctrl+f5 refresh and incognito mode and nothing has changed.
It seems to have only happened since the recent update.
There is no change in ordering on the m3u that threadfin itself creates,
just the way that it is presented within the mapping tab.
On Mon, Aug 12, 2024 at 6:22 AM Nick Wallace @.***>
wrote:

I don't see this issue myself. Can you tell me exactly your steps?
—
Reply to this email directly, view it on GitHub
https://github.com/Threadfin/Threadfin/issues/332#issuecomment-2283132408,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ADAE74XJEARXEOOW6SVXDR3ZRBBAJAVCNFSM6AAAAABMKGSHFSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOBTGEZTENBQHA
.
You are receiving this because you authored the thread.Message ID:
@.***>

oh nice! Glad you got it sorted


Normalize relative paths early

Currently when running on Windows, the paths for files use backslashes for a part of the workflow, and eventually get normalized into forward slashes when written out as module names. Given the reliance on regular expressions for config and in various other places, I thought it might be a good idea to normalize the relative paths from the beginning in watch.js after they come in from chokidar.
That way anytime you find yourself writing /^app\/something/ you don't need to wonder if you need to provide both slashes (or worse not adding both until someone raises an issue about Windows support).

agree. that's a nice ux improvement. let's see what we can do here.

I was having some similar troubles with then with a plugin of mine. I ended up throwing together a quick hack to get it running, but certainly wouldn't be against standardizing it on a higher level.
https://github.com/mcfarljw/replace-brunch/commit/11032a96c2ae40c40c4613f990c8c9737e6e62e4

Here is my stab on that: https://github.com/brunch/brunch/pull/1346

@paulmillr we can close this.


Operations on the Concept class: How to add a note? How to add a designation?

Operations on the Concept class: How to add a note? How to add a designation?
Need corresponding methods.

@ronaldtse Currently there are 2 options to add notes to a concept class

We can do concept.notes = ["content for note 1", "content for note 2", ...], this will make the required concept objects with content set to the string in the array.
We can pass a hash i.e concept.notes = [{content: "content for note 1"}, {content: "content for note 2", sources: [...]}, ...] with this method we can also pass source for the concept.

I'm working on adding complete documentations for what is currently implemented in Glossarist and I'll open a PR for that once done.

I want to make it possible to add notes one by one, not using =.
e.g.
concepts.notes << "content for note"
concepts.notes << {content: "content for note"}

Also for designation. Thanks.

@ronaldtse Currently there is no way to add a single note or designation. I am adding that & will open a PR for that today.


Add ability to manually input timeoffset in ArchiveTranslations

Rationale
Someone on discord wanted a way for manual input instead of only the +-60s buttons.
Before

After
After clicking on the -62s, a small dialogue will appear on screen for manual input.

Input is automatically validated by vue because the <v-text-field> is type="number".
Design Decisions Made
I've decided to create a pop up box so as to not change the current look.
Changing the <code> block that is currently used into an <v-text-field> is definitely possible, but doesn't really look as nice.
We could also potentially add more archive translations specific settings in the popup dialogue box in the future.
There are also no titles or labels in the pop up dialogue.
We can definitely add them, but will need localized strings for them.

Nice! while you're at it can you delete the -60 and +60 buttons? The top bar is too busy and your feature makes that obsolete anyway.

Removed +-60s button.

Do you want me to also revert the icons back to mdiTransferRight and mdiTransferLeft?

nah i think it's fine :+1:
Thanks for the change Flippfuzz <3


get err when training VarifocalNet using fp16

hi，when i training vfnet using ‘fp16 = dict(loss_scale=512.)’ , I get some err:
'''
File "/workspace/code/mmdet/mmdetection_xz/mmdetection/mmdet/models/dense_heads/vfnet_head.py", line 261, in forward_single
reg_feat = self.relu(self.vfnet_reg_refine_dconv(reg_feat, dcn_offset))
File "/root/miniconda3/lib/python3.8/site-packages/torch/nn/modules/module.py", line 727, in _call_impl
result = self.forward(*input, **kwargs)
File "/root/miniconda3/lib/python3.8/site-packages/mmcv/ops/deform_conv.py", line 234, in forward
out = deform_conv2d(x, offset, self.weight, self.stride, self.padding,
File "/root/miniconda3/lib/python3.8/site-packages/mmcv/ops/deform_conv.py", line 73, in forward
ext_module.deform_conv_forward(
RuntimeError: expected scalar type Half but found Float
'''

Hi @carry-xz, thanks for your PR and we will check it.

Yeah, I found this problem too.


Error on running

hi, when i try to run, it says
TypeError: null is not an object (evaluating '_reactNativeMetronomeModule.default.setBPM')

Hey!
Thanks for the report! I'll need a bit more detail to track down the issue. Can you provide me with some details of your environment (OS, node version, Android or iOS), and steps to reproduce? Thanks!!

Hi,
thanks a lot for the quick response
I'm running this on expo, and I'm sorry if this is a stupid question as I'm new to react native
I installed the metronome through the terminal, then
I tried making a very simple outline just to see if i could get the metronome to work:
import MetronomeModule from "react-native-metronome-module";
const App = () =>  {
MetronomeModule.setBPM(100);
MetronomeModule.setShouldPauseOnLostFocus(true);
MetronomeModule.start();
}
export default App;
on running i get the error.

Are you running it in ios or android emulator? Also what OS are you using?
On Wed, Aug 31, 2022 at 8:47 PM jack @.***> wrote:

Hi,
thanks a lot for the quick response
I'm running this on expo, and I'm sorry if this is a stupid question as
I'm new to react native
I installed the metronome through the terminal, then
I tried making a very simple outline just to see if i could get the
metronome to work:
import MetronomeModule from "react-native-metronome-module";
const App = () => {
MetronomeModule.setBPM(100);
MetronomeModule.setShouldPauseOnLostFocus(true);
MetronomeModule.start();
}
export default App;
on running i get the error.
—
Reply to this email directly, view it on GitHub
https://github.com/jonestristand/react-native-metronome-module/issues/3#issuecomment-1233702121,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABOGK34S7D5V5JLVHB4XBW3V4ARO3ANCNFSM6AAAAAAQB53LOM
.
You are receiving this because you were assigned.Message ID:
@.***
com>

I'm running in an IOS emulator, OS is Mac

have you run pod install?
On Wed, Aug 31, 2022 at 9:14 PM jack @.***> wrote:

I'm running in an IOS emulator, OS is Mac
—
Reply to this email directly, view it on GitHub
https://github.com/jonestristand/react-native-metronome-module/issues/3#issuecomment-1233718160,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ABOGK34TVAMAFEQ4B3OIRVTV4AUTZANCNFSM6AAAAAAQB53LOM
.
You are receiving this because you were assigned.Message ID:
@.***
com>

Pods is incompatible with Expo, when i searched online it said i didn't need it because expo handles it

I will look into this

Ran into the same error. Have you tried it with Expo?

I haven't had a chance to yet, my project is ongoing and doesn't use Expo, so I have no experience with it...

Hi, I ejected my app and now I get the following error:
`
❌  (node_modules/react-native-metronome-module/ios/MetronomeModule.swift:44:55)
42 |
43 |     do {

44 |       try AVAudioSession.sharedInstance().setCategory(AVAudioSessionCategoryPlayback, mode: AVAudioSessionModeDefault);
|                                                       ^ 'AVAudioSessionCategoryPlayback' has been renamed to 'AVAudioSession.Category.playback'
45 |       try AVAudioSession.sharedInstance().setActive(true);
46 |
47 |       self.player = try AVAudioPlayer(contentsOf: url, fileTypeHint: AVFileType.wav.rawValue);

❌  (node_modules/react-native-metronome-module/ios/MetronomeModule.swift:44:93)
42 |
43 |     do {

44 |       try AVAudioSession.sharedInstance().setCategory(AVAudioSessionCategoryPlayback, mode: AVAudioSessionModeDefault);
|                                                                                ^ 'AVAudioSessionModeDefault' has been renamed to 'AVAudioSession.Mode.default'
45 |       try AVAudioSession.sharedInstance().setActive(true);
46 |
47 |       self.player = try AVAudioPlayer(contentsOf: url, fileTypeHint: AVFileType.wav.rawValue);
`

hi, when i try to run, it says
TypeError: null is not an object (evaluating '_reactNativeMetronomeModule.default.setBPM')

Hi any one getting solution for this ?

Hey guys, sorry I haven't had time to look at this yet but will happily take a PR if anyone sorts it out in the meantime. When I'm able to get to it I will post a note here.

Hey guys, sorry I haven't had time to look at this yet but will happily take a PR if anyone sorts it out in the meantime. When I'm able to get to it I will post a note here.

@jonestristand PR created which will fix the 'AVAudioSessionCategoryPlayback' has been renamed to 'AVAudioSession.Category.playback' error. Although I'm not getting any audio playback as per #4 so interested to see if anyone else can get it working on their end.
Original issue TypeError: null is not an object (evaluating '_reactNativeMetronomeModule.default.setBPM') is caused by trying to use native modules in expo and is solved by ejecting and ensuring pods are installed with npx pod-install. I don't think there's a way to use native module like this in the expo environment.

Merged, thanks for the PR!


migration-agent image missing

In the manifest file there is a reference to:
image: husseingalal/migration-agent:dev
For instance the pull command generates this error:
 docker pull husseingalal/migration-agent Using default tag: latest Error response from daemon: manifest for husseingalal/migration-agent:latest not found: manifest unknown: manifest unknown

Currently there is only the dev Tag available.
https://hub.docker.com/r/husseingalal/migration-agent/tags


Enable automation that adds users to team

Background

AP is moving to a model where users need to be added to teams rather than direct repo access. Our Automation would address that.
AP users are going to be informed and then when agreed we'll enable that code.
Any new PAT tokens we need to create should be created using new fine grained tokens.
We will need to check if there is any conflict resulting from limits around API calls.

Acceptance Criteria

[ ] AP Org User are automatically assigned to teams.

Reference
How to write good user stories

On hold until w/c 12th December

Set up and running here https://github.com/moj-analytical-services/operations-engineering/blob/main/scripts/python/amend-user-repository-access.py

used a fine grained PAT on archive a repo but had to use a classic PAT to do org things like create team, add users, remove users etc


Break bedrock

I am trying to play a terminator challenge (From Dreams minecraft) but the plugin for the terminator has so many issues that it literally puts you on top of bedrock somehow, and i got another plugin that allows you to break bedrock, but baritone doesn't try to break it at all. So how do i make it start breaking the bedrock?

Just so that the owners / maintainers of this issue know, this was meant for here according to this message. It shouldn't have been created in that place originally, and definitely not meant for here.
Sorry for this.

why did i expect anyone to have a clue what i meant...


Fix imports order to match the new Checstyle rule

@jmazzitelli could you please review and eventually merge?


arm/neon/crc32.h:59:12: error: always_inline function '__crc32b' requires target feature 'crc' when building 0.8.2 with clang on aarch64

When building simde-0.8.2 with clang-18.1.8 on Fedora rawhide on aarch64, I'm getting the following error:
...
== Tests on clang with flags used in RPM package build ==
+ '[' include = include ']'
+ result=ok
+ result_buf=ok
+ return 0
+ result_gcc_rpm=ok
+ echo '== Tests on clang with flags used in RPM package build =='
+ BUILD_DIR=build/clang-rpm
+ CC=clang
+ CXX=clang++
+ CFLAGS='-O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-
D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -mbranch-prot
ection=standard -fasynchronous-unwind-tables  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fno-strict-aliasing'
+ CXXFLAGS='-O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE
,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong   -mbranch-pr
otection=standard -fasynchronous-unwind-tables  -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer  -fno-strict-aliasing'
+ LDFLAGS='-Wl,-z,relro -Wl,--as-needed  -Wl,-z,pack-relative-relocs -Wl,-z,now --config=/usr/lib/rpm/redhat/redhat-hardened-clang-ld.cfg  -
flto=thin -ffat-lto-objects -Wl,--build-id=sha1  '
+ _run_test_and_get_result include
+ local exit_status=0
+ local result=skipped
+ '[' 1 -lt 1 ']'
+ local cond=include
+ '[' include = include ']'
+ _run_test
+ _setup
+ meson setup build/clang-rpm
The Meson build system
Version: 1.4.1
Source dir: /builddir/build/BUILD/simde-0.8.2-build/simde-0.8.2
Build dir: /builddir/build/BUILD/simde-0.8.2-build/simde-0.8.2/build/clang-rpm
Build type: native build
Project name: SIMDe
Project version: 0.8.2
C compiler for the host machine: clang (clang 18.1.8 "clang version 18.1.8 (Fedora 18.1.8-3.fc41)")
C linker for the host machine: clang ld.bfd <IP_ADDRESS>40720
C++ compiler for the host machine: clang++ (clang 18.1.8 "clang version 18.1.8 (Fedora 18.1.8-3.fc41)")
C++ linker for the host machine: clang++ ld.bfd <IP_ADDRESS>40720
Host machine cpu family: aarch64
Host machine cpu: aarch64
Library m found: YES
Compiler for C supports arguments -fopenmp-simd: YES
Compiler for C++ supports arguments -fopenmp-simd: YES
Compiler for C supports arguments -Wpsabi: YES
Compiler for C++ supports arguments -Wpsabi: YES
Library m found: YES
Found pkg-config: YES (/usr/bin/pkg-config) 2.1.1
Build targets in project: 2002
NOTICE: Future-deprecated features used:
 * 0.64.0: {'copy arg in configure_file'}
Found ninja-1.12.1 at /usr/bin/ninja
+ _build
+ rm -f build.log
+ _time ninja -C build/clang-rpm -v -j 4
+ cat build.log
+ /bin/time -f '=> [%E]' ninja -C build/clang-rpm -v -j 4
ninja: Entering directory `build/clang-rpm'
[1/4004] clang -Itest/common/common-c.p -Itest/common -I../../test/common -I. -I../.. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -Wall -Winvalid-pch -std=c99 -O0 -g -O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-strict-aliasing -fopenmp-simd -DSIMDE_CONSTRAINED_COMPILATION -DSIMDE_ENABLE_OPENMP -Wno-psabi -DSIMDE_TEST_BARE -MD -MQ test/common/common-c.p/common.c.o -MF test/common/common-c.p/common.c.o.d -o test/common/common-c.p/common.c.o -c ../../test/common/common.c
...
[750/4004] clang -Itest/arm/neon/crc32-native-c.p -Itest/arm/neon -I../../test/arm/neon -I. -I../.. -fdiagnostics-color=always -D_FILE_OFFSE
T_BITS=64 -Wall -Winvalid-pch -std=c99 -O0 -g -O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=for
mat-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fst
ack-protector-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-str
ict-aliasing -fopenmp-simd -DSIMDE_CONSTRAINED_COMPILATION -DSIMDE_ENABLE_OPENMP -Wno-psabi -DSIMDE_TEST_BARE -MD -MQ test/arm/neon/crc32-na
tive-c.p/crc32.c.o -MF test/arm/neon/crc32-native-c.p/crc32.c.o.d -o test/arm/neon/crc32-native-c.p/crc32.c.o -c ../../test/arm/neon/crc32.c
FAILED: test/arm/neon/crc32-native-c.p/crc32.c.o
clang -Itest/arm/neon/crc32-native-c.p -Itest/arm/neon -I../../test/arm/neon -I. -I../.. -fdiagnostics-color=always -D_FILE_OFFSET_BITS=64 -
Wall -Winvalid-pch -std=c99 -O0 -g -O2 -flto=thin -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-securit
y -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -Wp,-D_GLIBCXX_ASSERTIONS --config=/usr/lib/rpm/redhat/redhat-hardened-clang.cfg -fstack-protect
or-strong -mbranch-protection=standard -fasynchronous-unwind-tables -fno-omit-frame-pointer -mno-omit-leaf-frame-pointer -fno-strict-aliasin
g -fopenmp-simd -DSIMDE_CONSTRAINED_COMPILATION -DSIMDE_ENABLE_OPENMP -Wno-psabi -DSIMDE_TEST_BARE -MD -MQ test/arm/neon/crc32-native-c.p/cr
c32.c.o -MF test/arm/neon/crc32-native-c.p/crc32.c.o.d -o test/arm/neon/crc32-native-c.p/crc32.c.o -c ../../test/arm/neon/crc32.c
In file included from ../../test/arm/neon/crc32.c:4:
../../test/arm/neon/../../../simde/arm/neon/crc32.h:59:12: error: always_inline function '__crc32b' requires target feature 'crc', but would
 be inlined into function 'simde___crc32b' that is compiled without support for 'crc'
   59 |     return __crc32b(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:85:12: error: always_inline function '__crc32h' requires target feature 'crc', but would
 be inlined into function 'simde___crc32h' that is compiled without support for 'crc'
   85 |     return __crc32h(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:111:12: error: always_inline function '__crc32w' requires target feature 'crc', but woul
d be inlined into function 'simde___crc32w' that is compiled without support for 'crc'
  111 |     return __crc32w(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:136:12: error: always_inline function '__crc32d' requires target feature 'crc', but would be inlined into function 'simde___crc32d' that is compiled without support for 'crc'
  136 |     return __crc32d(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:171:12: error: always_inline function '__crc32cb' requires target feature 'crc', but would be inlined into function 'simde___crc32cb' that is compiled without support for 'crc'
  171 |     return __crc32cb(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:197:12: error: always_inline function '__crc32ch' requires target feature 'crc', but would be inlined into function 'simde___crc32ch' that is compiled without support for 'crc'
  197 |     return __crc32ch(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:223:12: error: always_inline function '__crc32cw' requires target feature 'crc', but would be inlined into function 'simde___crc32cw' that is compiled without support for 'crc'
  223 |     return __crc32cw(a, b);
      |            ^
../../test/arm/neon/../../../simde/arm/neon/crc32.h:248:12: error: always_inline function '__crc32cd' requires target feature 'crc', but would be inlined into function 'simde___crc32cd' that is compiled without support for 'crc'
  248 |     return __crc32cd(a, b);
      |            ^
8 errors generated.
...
ninja: build stopped: subcommand failed.
Command exited with non-zero status 1
=> [3:47.29]
== Results ==
Exit status: 1
skipped: gcc without flags
skipped: gcc with -O2 flag
ok: gcc with RPM build flags
skipped: clang without flags
skipped: clang with -O2 flag
not ok: clang with RPM build flags

meson has no support for file-specific compiler flags, but this patch seems to work around the issue for me (all 2002 tests succeed):
diff -up simde-0.8.2/test/meson.build.orig simde-0.8.2/test/meson.build
--- simde-0.8.2/test/meson.build.orig   2024-04-30 16:35:50.000000000 +0000
+++ simde-0.8.2/test/meson.build        2024-08-30 11:22:14.428728668 +0000
@@ -58,6 +58,10 @@ if cxx.get_id() == 'intel'
   simde_native_cxx_flags += '-DSIMDE_FAST_MATH'
 endif

+if target_machine.cpu_family() == 'aarch64' and cc.get_id() == 'clang'
+  simde_native_c_flags += '-mcrc'
+endif
+
 if not c_openmp_simd
   simde_deps += dependency('openmp', required: false)
 endif

Hello @rathann and thank you for sharing your issue.
Not all aarch64 CPUs have the crc32 feature, so we shouldn't enable it universally.
I will open a PR that avoids using the crc32 feature unless it is already enabled.
Alas, it looks like -march=native doesn't enable crc32 automatically on many processors. You may need to use -march=armv8-a+crc or similar
See https://stackoverflow.com/questions/45625725/does-clang-lack-crc32-for-armv8-aarch64 and https://stackoverflow.com/questions/37066261/why-is-arm-feature-crc32-not-being-defined-by-the-compiler

Hello @rathann and thank you for sharing your issue.

Hi!  I'm always happy to work with upstreams on the issues we catch downstream in Fedora.

Not all aarch64 CPUs have the crc32 feature, so we shouldn't enable it universally.

I see.

I will open a PR that avoids using the crc32 feature unless it is already enabled.

Great, thanks! I'll test it as soon as I can.

Alas, it looks like -march=native doesn't enable crc32 automatically on many processors. You may need to use -march=armv8-a+crc or similar

Interesting. Thanks for the links.


Editor Phone Auth Support in 4.5.0

Hi – Really excited that version 4.5.0 includes Editor support. I'm working on something that merges data from an Anonymous user to new credentials they've created with Phone Authentication.
Anonymous Auth works in the editor with 4.5.0, but is there any way to test Phone Authentication in the Editor?

Hi,
That's great that you're excited for Editor support.  Unfortunately, the desktop implementation of Authentication does not currently support Phone Authentication, which means that the Editor version cannot either.
We'll keep this issue open though, and if anything changes we'll be sure to update this.


chore(deps): add new extension to ignore dep list

This package is always kept up-to-date because of the monorepo structure. Adding to the ignoreDeps list keeps cyclic pull requests like this one from being opened every time a new release is cut.


Listing submissions API

https://github.com/lxylxy123456/ngshare/blob/master/api-specifications.md#request-3
@Lawrence37 Do we need to include all the file lists? ("notebooks":[...])

I think the assignment directory tree should be the same as submission directory tree (only files are different)
The file list will also be available if the instructor downloads it at /api/submission/<course_id>/<assignment_id>/<student_id>. If needed, we can add an option of listing the filenames without downloading them.

I believe only the notebook files need to be listed.
The assignment and submission tree should be the same.
We shall see if listing the submitted files is necessary.

So I will leave the API without listing notebook files as for now.
Also some suggestions on writing the API docs: separate successful situations and unsuccessful:

Success
{
   "success": true,
   "assignments": [ /* assignment name */, ...]
}

Possible fail messages

"Course not found"
"Assignment not found"

You do not need to guess all possible fail messages at this time. I can do it after I implement it.
Also, I prefer having examples instead of comments (but feel free to use your the original style):

{
   "success": true,
   "assignments": [ "ass1", "ass2", ... ]
}

and

[
{
"path": "/path/relative/to/root",
"content": "base64content=="
},
...
]

@Lawrence37 Note that I am going to close this, though "notebook" is still not added in the API. If you need it please reopen or add a new issue.


Add Per Camera Snooze Functionality

Description:
Implements a per camera snooze function as present here: https://github.com/MattTW/BlinkMonitorProtocol/issues/67
Currently supports:

Getting the remaining snooze time for the camera in the format of "this time stamp is when snoozing will expire".
Setting the camera to snooze notifications

I was unable to find a value other than "240" minutes (4 hours) that worked.

There is more than can be implemented, such as snoozing an entire sync module's cameras.
As far as testing:

Currently blocked by another PR (https://github.com/fronzbot/blinkpy/pull/974)
I have tried writing tests for this PR but just not familiar enough with tox/mock testing. Seems like only 3 tests are needed:

"snooze_till" property
"snooze" function
"request_camera_snooze" request

Reason for removing my previous PR: Somehow messed up the git history while trying to squash to a single commit.
Related issue (if applicable): fixes #

https://github.com/fronzbot/blinkpy/issues/955

Checklist:

[ ] Local tests with tox run successfully PR cannot be meged unless tests pass
[X] Changes tested locally to ensure platform still works as intended
[ ] Tests added to verify new code works

I have added, but not manually tested, per sync module snooze. The api is documented in a comment on https://github.com/MattTW/BlinkMonitorProtocol/issues/67.
I have not added automated testing for my methods yet, but will take another stab at it now that the aiohttp PR has been merged.


Make a "reset.sh" script

@cpauya this fixes #269

@amodia, I tested this PR, when I run reset.sh, It deletes KALITE_PYTHON env var, /Library/LaunchAgents/org.learningequality.kalite.plist, and the symlink of kalite executable in /usr/bin.

Nice one @djallado - merging.


[Snyk] Upgrade com.fasterxml.jackson.core:jackson-databind from 2.12.4 to 2.15.2

This PR was automatically created by Snyk using the credentials of a real user.Snyk has created this PR to upgrade com.fasterxml.jackson.core:jackson-databind from 2.12.4 to 2.15.2.
:information_source: Keep your dependencies up-to-date. This makes it easier to fix existing vulnerabilities and to more quickly identify and fix newly disclosed vulnerabilities when they affect your project.

The recommended version is 30 versions ahead of your current version.
The recommended version was released a month ago, on 2023-05-30.

The recommended version fixes:

Severity
Issue
PriorityScore (*)
Exploit Maturity

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-2421244
525/1000  Why? Has a fix available, CVSS 7.5
No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-2326698
525/1000  Why? Has a fix available, CVSS 7.5
No Known Exploit

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038424
525/1000  Why? Has a fix available, CVSS 7.5
Proof of Concept

Denial of Service (DoS) SNYK-JAVA-COMFASTERXMLJACKSONCORE-3038426
525/1000  Why? Has a fix available, CVSS 7.5
Proof of Concept

(*) Note that the real score may have changed since the PR was raised.

Note: You are seeing this because you or someone else with access to this repository has authorized Snyk to open upgrade PRs.
For more information:
🧐 View latest project report
🛠 Adjust upgrade PR settings
🔕 Ignore this dependency or unsubscribe from future upgrade PRs

Checkmarx One – Scan Summary & Details – 038a62aa-745c-4fe5-a0b7-96c05b58b6bf
Fixed Issues

Severity
Issue
Source File / Package
Checkmarx Insight

CVE-2020-36518
Maven-com.fasterxml.jackson.core:jackson-databind-2.12.4
Vulnerable Package

CVE-2021-46877
Maven-com.fasterxml.jackson.core:jackson-databind-2.12.4
Vulnerable Package

CVE-2022-42003
Maven-com.fasterxml.jackson.core:jackson-databind-2.12.4
Vulnerable Package

CVE-2022-42004
Maven-com.fasterxml.jackson.core:jackson-databind-2.12.4
Vulnerable Package

Cxced0c06c-935c
Maven-com.fasterxml.jackson.core:jackson-databind-2.12.4
Vulnerable Package


class XResNet not working with mnist

the following line fails :

return act_fn(self.convs(x) + self.idconv(self.pool(x))) )

because self.pool(x)) and self.convs(x) does not match
i suggest this fix in class ResBlock(nn.Module).init

change self.pool   = noop if stride==1 else nn.AvgPool2d(2)
to          self.pool   = noop if stride==1 else nn.AvgPool2d(2, ceil_mode=True)

the ResBlock.forward could also use an in place add_  although i cannot measure the difference for xresnet18:

act_fn(self.convs(x).add_( self.idconv(self.pool(x)))) )

Thanks for suggesting the fix!


Why does cardano-graphql-v7.0.0 use 1.8T disk space

Ask a question
hi
I am using cardano-graphql-v7.0.0, it has been running for 4 months, and now I find that it takes up 1.8T of disk space,
is this a normal disk usage?
is there any way to make it take up less disk space Some?

I tried
NETWORK=mainnet LOGGER_MIN_SEVERITY=debug CARDANO_NODE_VERSION=1.35.5 docker-compose -f docker-compose.yml up -d

but seems the ogmios not receive the CARDANO_NODE_VERSION value
Building cardano-node-ogmios
Sending build context to Docker daemon  2.314MB
Step 1/40 : ARG CARDANO_NODE_VERSION=1.35.3
Step 2/40 : FROM --platform=${TARGETPLATFORM:-linux/amd64} nixos/nix:2.11.0 as build
2.11.0: Pulling from nixos/nix
40a20fdeab12: Pulling fs layer
aec9f58ab42a: Pulling fs layer

How did you deploy ada？My node takes up 700G of disk space.

I also had an unusual increment of disk space in the Asset table caused by an error in Psql Toast. Thats a big shot without more info from your side but what i would do:

Check which table/s is using this much size:

https://stackoverflow.com/a/52706756
Modified version:
select current_database() as database,
       pg_size_pretty(total_database_size) as total_database_size,
       schema_name,
       table_name,
       pg_size_pretty(total_table_size) as total_table_size,
       pg_size_pretty(table_size) as table_size,
       pg_size_pretty(index_size) as index_size
       from ( select table_name,
                table_schema as schema_name,
                pg_database_size(current_database()) as total_database_size,
                pg_total_relation_size(quote_ident(table_name)) as total_table_size,
                pg_relation_size(quote_ident(table_name)) as table_size,
                pg_indexes_size(quote_ident(table_name)) as index_size
                from information_schema.tables
                where table_schema=current_schema()
                order by total_table_size
            ) as sizes;

check for any table where index_size + table_size != total_table_size
perform a VACUUM FULL "TABLE_NAME"; on the tables affected
if you have Toast error like me you can follow https://stackoverflow.com/a/68194898 to solve it

My DB is ~300GB but Assets metadata are not fully synced


Promote ShareProcessNamespace to beta in docs

PR requested here https://github.com/kubernetes/features/issues/495#issuecomment-414452158
Nothing has changed for this feature, only a promotion from alpha to beta.

pls also fix the feature-gates.md file.

/assign @bradamant3

/lgtm

@zparnold you mean beside the doc in docs/tasks/configure-pod-container/share-process-namespace.md included in this PR?
I'm happy to write more docs for this if you point me in a good direction. When I asked what docs I should write for Alpha someone told me to write a task doc. It didn't occur to me to ask if there were additional doc requirements for Beta.

@verb I don't think there is an additional requirement, I just know that alpha features have the ability to mutate pretty significantly without warning. If you don't believe there's anything else to do here I'm ready to merge.

@zparnold Ahh, apologies, I misread your initial comment. No, this only needs an update to feature status. The feature didn't change at all from alpha to beta. Thanks!

Sounds good!
/approve


google cloud service account and networks quotas

Hi,
While using several kinds of dynamic slaves in google cloud (through labels) we found two problems:

Bug: The Credential option, was single line. For using google cloud service accounts, it needs to be multiline, to allow the input of a private key.
The fix was to change in the jelly file to a multiline field
commit: ff81acf6e1ac12fc21f5dd8804d0fa3824c79539
Bug: Networks weren't being configured when using the template option in jenkins ui. This made us hit the google cloud networks quota limit.
The fix was to pass to the template option the URI (as in the jclouds api example)
commit: 5f659921f295af105432b6235538ea0dc8915d87

Regards

Note https://github.com/jenkinsci/jclouds-plugin/pull/83 refactors the way credentials are handles as well.

Thank you for a pull request! Please check this document for how the Jenkins project handles pull requests

@olivergondza just refactored the code to introduce the minimal amount of changes to fix the bugs.
We are also aware of #83 and wish to use the same strategy for the credentials.
The multiline field change is a just a quick fix until we get #83 merged.

@olivergondza please don't merge yet, there is something fishy regarding jclouds version.

It's ready to merge.

Regarding -> Bug: The Credential option, was single line. For using google cloud service accounts, it needs to be multiline, to allow the input of a private key.
There is no change in this
Regarding -> Bug: Networks weren't being configured when using the template option in jenkins ui. This made us hit the google cloud networks quota limit.
This was caused by bumping jclouds to 2.X-SNAPSHOT, the code was reverted.

We made a monkey patch 4dddb58ea97415d889d58855b5862711adf40806 because google cloud now allows creating images from rawdisk or sourcedisk.

See: https://cloud.google.com/compute/docs/reference/latest/images/insert
We use images created using sourcedisk (using packer)
Without the monkey patch, the plugin doesn't work on projects with images created using sourcedisk (raises npe)
In jclouds-labs-google master, this problem is allready fixed
** See: https://github.com/jclouds/jclouds-labs-google/blob/master/google-compute-engine/src/main/java/org/jclouds/googlecomputeengine/domain/Image.java
** The monkey patch should be removed when the jclouds-plugin upgrades to a 2.X release (it should bring the latest jcloud-labs-google)

Regards

Any idea when this will be merged? This bug with the credentials is a real blocker

Short answer: Not anytime soon.
Long version:
I am still not finished with the changes that #83 started. The global credentials still use simple text fields instead of a Credentials object. Also, the whole blobstore code has still to be converted. (I have a PR against my fork for that, but unfortunately it is not backward compatible - so that needs more work too). As soon as I have free time I will implement those.
After that, we can think about merging this.
Apart from that, I am not really happy about that "monkey" patch. Using an unreleased (2.x) version of jclouds is not a good idea IMHO.
@olivergondza Any opinion on this?
Does anyone know, when jclouds 2.0 is to be released?
Cheers
-Fritz

Hi, first of all, I abandoned the use and contribution to this plugin in favor of https://github.com/jenkinsci/openstack-cloud-plugin, as that is all I need. Mainly because I do not see a way to responsibly maintain a plugin that tries to support so many cloud providers. Historically, there is simply not enough hands to verify new fixes from all that perspectives and no matter how hard is Apache JClouds trying, there are differences we need to pay attention to. Those differences either require countless if (provider == X) hacks and thay stretches the plugin to different directions that are quite hard to get compatible (which is sort of the case of this PR).
So while I can not comment on google cloud integration, dragging the class here temporarily is a practice used occasionally is plugins, nasty one though. Another option is build against 2.0 snapshot published by jclouds.

@jrluis and @marcuspen :
I just realized, that the multiline issue might be solved using the existing credential. So:
Could you please confirm, thet the key is a standard PEM-encoded RSA or DSA key?
If yes, this could be implemented pretty soon
Or: Do you have an example key?
Thanks
-Fritz

FYI.
Well, I signed up to google cloud service myself, just to see how these keys look. Unfortunately the are neither RSA nor DSA but a PEM-Encoded unencrypted!  PKCS#8. So this cannot be handled by the existing ssh-keys mechanisms but needs some more treatment in order to do it right.

@jrluis did you manage to make any version of the plugin work with Google Cloud Engine?

@robertdolca Yes, it's working on gcloud using a build with this pull request.

I just compiled it but I get Cannot connect to specified cloud, please check the identity and credentials: null
I am using this as endpoint https://www.googleapis.com/compute/v1/projects/<project-name> the account's client_email as identity and for the credential I tried with the key from the json file and with the converted p12.

In the meantime I figured it out. Jclouds asumes that the username is the same with the project name and the project name does not container '-'. It removes anything after - in the username and that is ther project name. Google does not follow this convention any more.

Now, that jclouds-2.0 was released last week, I added an Import feature for JSON keys and verified
overall operation. The workaround for the networks does not appear to be necessary anymore.
Therefore: closing this PR.


When exiftool fails on export | Pic still gets exported with missing data | Subsequent exports will not re-export the pic!

Latest version

Version: 0.55.2

Describe the bug
When exiftool fails exporting an edited Pic (rotated + added GPS location in iPhoto/Photos):

File is exported without GPS data (of course it depends on the error from exiftool. Possible other errors to from exiftool
Noticed that touch does not seem to also run on the file!
Although the edited file is still exported
...and subsequent runs consider the file up-to-date, when, in fact it does not have GPS data.

IMPORTANT:

Just want to make you aware of this sequence/logic for this situation in case it may be helpful for other cases. I know I have to fix the pics myself. Will do that with "Script Editor" later on...
The problem happened with a certain Camera (OLYMPUS D800, which I no longer use) and rotated pics in iPhoto.
Somehow the edited pic in Photos (that comes from ~8 years ago through several iPhotos versions) generates "Maker Notes" and "Duplicated Orientation" tag on exiftool
I know I'll have to fix them all.

1st run: exiftool error!

But the file is exported but does not get all the EXIF info. For instance no GPS position data.

2022-12-14 22:24:11.961484 -- Exporting P4021768.JPG (P4021768.JPG) (6/6)
2022-12-14 22:24:11.962024 -- Skipping original version of P4021768.JPG
2022-12-14 22:24:11.963077 -- Exporting edited version of P4021768.JPG (P4021768.JPG)
2022-12-14 22:24:11.967205 -- Writing metadata with exiftool for P4021768_edited.jpeg
2022-12-14 22:24:12.367336 -- Exported P4021768.JPG to /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg
2022-12-14 22:24:12.376409 -- ⚠  exiftool warning for file /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg: Warning: Duplicate Orientation tag in IFD0 - /var/folders/28/x8vbdy4j4vn680b5pt33hs0w0000gn/T/osxphotos_export_8vg04xwd/CDF617F6-9839-4A65-BE82-B28C45247FC6_1_201_a_exiftool.jpegWarning:  Possibly incorrect maker notes offsets (fix by -18?) - /var/folders/28/x8vbdy4j4vn680b5pt33hs0w0000gn/T/osxphotos_export_8vg04xwd/CDF617F6-9839-4A65-BE82-B28C45247FC6_1_201_a_exiftool.jpeg
2022-12-14 22:24:12.380512 -- Retrying export for photo (CDF617F6-9839-4A65-BE82-B28C45247FC6: P4021768.JPG)
2022-12-14 22:24:12.389445 -- Skipped up to date file /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg

2nd run: consider the file up-to-date! But GPS data is missing.
2022-12-14 22:26:15.367527 -- Exporting P4021768.JPG (P4021768.JPG) (6/6)
2022-12-14 22:26:15.368193 -- Skipping original version of P4021768.JPG
2022-12-14 22:26:15.369319 -- Exporting edited version of P4021768.JPG (P4021768.JPG)
2022-12-14 22:26:15.496074 -- Skipped up to date file /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg

On Photos "Revert to Original"(Cancels rotation but keep GPS data) and Re-edit to rotate: 3rd run
3rd run: perfect run. No exiftool error. GPS data exported. Touched executed.
2022-12-14 22:28:00.247428 -- Skipping original version of P4021768.JPG
2022-12-14 22:28:00.248482 -- Exporting edited version of P4021768.JPG (P4021768.JPG)
2022-12-14 22:28:00.377742 -- Writing metadata with exiftool for P4021768_edited.jpeg
2022-12-14 22:28:00.605418 -- Exported P4021768.JPG to /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg
2022-12-14 22:28:00.613356 -- Exported updated file /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg
2022-12-14 22:28:00.613782 -- Touched date on file /Users/Shared/Pictures/Export/bad_pics_export_osxphotos/local/(...)/P4021768_edited.jpeg

To Reproduce
Steps to reproduce the behavior:

Command line on the crontab

osxphotos export "${DSTFOLDER}" --exportdb ${FOLDER}/.osxphotos_export.db --load-config ${WORKFOLDER}/colibri.toml >> ${LOGFILE} 2>&1

TOML file being used

[export]
cleanup = true
db = "/Users/Shared/Pictures/iPhoto Shared Library.photoslibrary"
description_template = "Album:{album,}{newline}Description:{descr,}"
directory = "{album|filter(startswith 1|2)[/,.|:,.]}"
exiftool = true
exiftool_merge_keywords = true
exiftool_merge_persons = true
keyword_template = [ "{keyword}", "{label}", "{searchinfo.activity?activity:{searchinfo.activity},}", "{searchinfo.venue_type?venue_type:{searchinfo.venue_type},}", ]
no_progress = true
not_hidden = true
ramdb = true
retry = 2
skip_bursts = true
skip_live = true
skip_original_if_edited = true
strip = true
timestamp = true
touch_file = true
update = true

Expected behavior
Possibilities thinking out loud:

Either continue to try to re-export the file -- may be dumb as it will continue to give the same error!
One additional message to the user that he must fix it and possibly no re-exports will occur. Partially addressed as I already get the error from exiftool.
Delete the file in case of exif_tool error -- maybe too drastic.
Leave as it is.

Screenshots
N/A
Desktop (please complete the following information):

OS: Monterey 12.6.32
osxphotos version: 0.55.2

Additional context

DB with referenced pics.
Edited pics done inside iPhoto or Photos

Thanks for the detailed bug report. Will take a look when I get a chance. One guiding philosophy for osxphotos is "preserve as much data as possible" so I don't like the idea of deleting the file if exiftool fails. But the file should be attempted to exported again the next time.

I've been able to replicate this.

The problem is that the file is recorded in the database despite the exiftool error.  Any file that gets exported without a file system error gets recorded:
https://github.com/RhetTbull/osxphotos/blob/8b9af7be6758292b03dc291261636f334ff407a4/osxphotos/photoexporter.py#L1180-L1194
One option would be to not record the file in the database at all if there's an exiftool error or warning. However, that means the file would get deleted upon --cleanup and would appear as a name collision upon --update.
Another option would be to consider the file corrupt and not export it all if there's an error but that's undesirable as one of the design philosophies in osxphotos is "preserve as much data as possible" as I use this primarily as an archival tool.
A third option is to somehow annotate in the export database that file was exported but "should be retried next time".

Here's an easy fix that I've tested and works. But I am not sure if this is really the desired behavior in all cases.
If there's an exiftool error or warning (or just an error?) don't write the exifdata to the database thus osxphotos will think that exiftool hasn't been run yet on the exported file and attempt to re-export it.
However, when used with --retry this will guarantee that the photo gets retried multiple times even though it's going to fail again. This is different than a disk or network error where retry is desired but osxphotos doesn't know this.
Also, on subsequent update, these photos will always get re-exported if user doesn't fix the EXIF. If the bad data is in the original image, user cannot fix the EXIF once imported to Photos (not without a bit of hacking the library).  So these will always get re-exported which may be confusing to users.
Open to ideas on how to handle this.
Maybe a flag but that won't be obvious to users necessarily.
The current design treats exiftool as a best-effort "post processing" process independent of the actual export. I think this is preferred in most cases with the exception of your case where the edited pic has bad EXIF and can be corrected.

After thinking through this more I tend to agree the as-is behavior is probably best. However, here's a possible solution that gives the user control:

Modify the export database to include an error column that would store any errors generated during export including exiftool errrors and warnings. This would be useful in general to be able to examine what errors occurred during export after the fact.  This data is stored in the results table but that doesn't happen until after the export is complete.  I'd opt for error instead of exiftool_error to account for other errors. Internally, would likely use json to store the errors in the column so I wouldn't have to change the database schema in the future.
Add an option like --update-errors (open to naming ideas!) that would attempt to re-export any file where the last run had an error (exiftool or otherwise) even if that file would not have otherwise been updated. In conjunction with --update this would allow you to re-attempt these files after you fixed the EXIF data.
Add an option to the osxphotos exportdb command to be able to inspect errors, clear the error flag, etc.

Fixed in v0.55.3 which adds --update-errors to export and --last-errors, --errors to osxphotos exportdb for viewing which files produced errrors.

I normally run osxphotos export at 3:44 in the morning and it takes ~4 hours to complete up to 7:44. It seems to me:

--last-errors filters the errors for the last date/time run
but some errors (shown with --errors) are tagged with a different date/time, thus not allowing "--last-errors" to tag them correctly.
I believe with the --retry option osxphotos attempts to export the file a few times and gets multiple errors and eventually succeeds, but stages the error with a different date/time.

My interpretation:

I understand last-errors would report last run errors tagged with the same start date, in my case:  2022-12-31T03:45:24.439678

$ osxphotos exportdb --last-errors .osxphotos_export.db
/Volumes/photo-1/Family.Photos/(...)/IMG_20221105_205105.HEIC, 2022-12-31T03:45:24.439678, Warning:  Fixed incorrect list type for XMP-mwg-rs:RegionList - /tmp/osxphotos_export_548nd0vk/IMG_20221105_205105_exiftool.HEIC
/Volumes/photo-1/Family.Photos/(...)/IMG_20220730_162555.HEIC, 2022-12-31T03:45:24.439678, Warning:  Fixed incorrect list type for XMP-mwg-rs:RegionList - /tmp/osxphotos_export_ur7kcj0h/IMG_20220730_162555_exiftool.HEIC
(...)

But checking the --verbose output file and the command --errors I get other errors with different  indexed date/time

$ grep P5290141  runOSxPhotos.cron.err
2022-12-31 07:19:07.541211 -- Exporting P5290141.JPG (P5290141.JPG) (82955/89381)
2022-12-31 07:19:07.769180 -- Writing metadata with exiftool for P5290141.JPG
2022-12-31 07:19:07.973021 -- Exported P5290141.JPG to /Volumes/photo-1/Family.Photos/(...)/P5290141.JPG
2022-12-31 07:19:07.981135 -- ❌  exiftool error for file /Volumes/photo-1/Family.Photos/(...)/P5290141.JPG: Error:  Bad MakerNotes offset for Olympus_ImageProcessing_0x0801 - /tmp/osxphotos_export_ovuuxubq/P5290141_exiftool.JPG
2022-12-31 07:19:07.982026 -- ❌  Error exporting photo (1E8448C7-2200-47B2-A869-61285E4C569C: P5290141.JPG) as /Volumes/photo-1/Family.Photos/(...)/P5290141.JPG: Error:  Bad MakerNotes offset for Olympus_ImageProcessing_0x0801 - /tmp/osxphotos_export_ovuuxubq/P5290141_exiftool.JPG
2022-12-31 07:19:07.982560 -- Retrying export for photo (1E8448C7-2200-47B2-A869-61285E4C569C: P5290141.JPG)
2022-12-31 07:19:07.991384 -- Skipped up to date file /Volumes/photo-1/Family.Photos/(...)/P5290141.JPG

$ osxphotos exportdb --errors .osxphotos_export.db
(...)/IMG_20220806_171248.HEIC, 47E8C0CF-CED4-481C-AED3-149092760399, 2022-12-31 07:22:36.272, {"error": [], "exiftool_error": [], "exiftool_warning": [["/Volumes/photo1/Family.Photos/(...)/IMG_20220806_171248.HEIC", "Warning:  Fixed incorrect list type for XMP-mwg-rs:RegionList -
/tmp/osxphotos_export_t4hp4d1s/IMG_20220806_171248_exiftool.HEIC"]]}
(...)/IMG_20221224_185404.HEIC, 07D4C738-2B74-4379-8C8D-9B855740E3E7, 2022-12-31 07:22:15.001, {"error": [], "exiftool_error": [], "exiftool_warning": [["/Volumes/photo-1/Family.Photos/(...)/IMG_20221224_185404.HEIC", "Warning:  Fixed incorrect list type for XMP-mwg-rs:RegionList -
/tmp/osxphotos_export_s8umqo1l/IMG_20221224_185404_exiftool.HEIC"]]}
(...)/IMG_20221127_204729.HEIC, B8FE6BA1-FBE1-492D-8B1F-75752FBA5E3C, 2022-12-31 07:19:54.881, {"error": [], "exiftool_error": [], "exiftool_warning": [["/Volumes/photo-1/Family.Photos/(...)/IMG_20221127_204729.HEIC", "Warning:  Fixed incorrect list type for XMP-mwg-rs:RegionList -
/tmp/osxphotos_export_gw4lqkex/IMG_20221127_204729_exiftool.HEIC"]]}
(...)/P5290141.JPG, 1E8448C7-2200-47B2-A869-61285E4C569C, 2022-12-31 07:19:07.991, {"error":
[["/Volumes/photo-1/Family.Photos/(...)/P5290141.JPG", "Error:  Bad MakerNotes offset for Olympus_ImageProcessing_0x0801 - /tmp/osxphotos_export_ovuuxubq/P5290141_exiftool.JPG"]], "exiftool_error": [["/Volumes/photo-1/Family.Photos/(...)/P5290141.JPG", "Error:  Bad MakerNotes offset for Olympus_ImageProcessing_0x0801 - /tmp/osxphotos_export_ovuuxubq/P5290141_exiftool.JPG"]], "exiftool_warning": []}
(...)

I understand last-errors would report last run errors tagged with the same start date,

--last-errors does not look at the date/time, it looks at the most recent export results stored in the database (the source for --report) and extracts any errors found there. --errors searches for any errors stored in the error column of the database. Neither filters on date/time group.
I looked at the code and I can't see any obvious causes nor can I replicate this. I'll take a deeper look when I get a chance but it may be a while as I've got other projects going. I view osxphotos exportd as a sort of a "best effort" project that I don't spend a lot of time on.   It's a collection of useful utilities but not intended to be a "primary" feature.
Note: the date/time stamp shown in --errors is the date/time that photo's record was last updated (when --update was run), not the date/time the error occurred.  I realize this isn't intuitive but it's a limitation of the export database schema and when I added the errors column I didn't want to make significant changes to the database (which always introduces risk of more severe bugs).

Please try to generate a report for the last run using osxphotos exportdb /path/to/export/ --report debug.csv 0 and see if the missing errors show up in the report.

I looked at the code and I can't see any obvious causes nor can I replicate this. I'll take a deeper look when I get a chance but it may be a while as I've got other projects going. I view osxphotos exportd as a sort of a "best effort" project that I don't spend a lot of time on. It's a collection of useful utilities but not intended to be a "primary" feature.

Sure. No worries at all. I have the output of the run and I get the errors from there. So I'm good!

Coming off a report from #999 one additional report on item 3.  reported on this comment (link)
One example. Exporting to the local SSD file with errors. but saving file and then deleting.
16:27:26 MSP X[850]> mkdir XYZ; osxphotos export XYZ  --uuid 18CD34E6-8E32-4873-BBA7-0EE8C9822EC0 --load-config export.toml --exportdb ./.osxphotos_export.db
2023-04-08 16:27:41.133699 -- Loaded options from file export.toml
2023-04-08 16:27:41.134218 -- osxphotos version: 0.59.1
2023-04-08 16:27:41.134485 -- Python version: 3.11.2 (main, Mar 24 2023, 00:28:48) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
2023-04-08 16:27:41.150960 -- Platform: macOS-12.6.4-x86_64-i386-64bit, 12.6.4
2023-04-08 16:27:41.151991 -- Verbose level: True
2023-04-08 16:27:41.152691 -- exiftool path: /usr/local/bin/exiftool
Using last opened Photos library: /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary
2023-04-08 16:27:41.155992 -- Warning: export database '/Users/Shared/Pictures/Logs/X/.osxphotos_export.db' is in a different directory than export destination '/Users/Shared/Pictures/Logs/X/XYZ'
2023-04-08 16:27:41.156976 -- WARNING: found other export database files in this destination directory branch.  This likely means you are attempting to export files into a directory that is either the parent or a child directory of a previous
export. Proceeding may cause your exported files to be overwritten.
2023-04-08 16:27:41.157601 -- You are exporting to /Users/Shared/Pictures/Logs/X/XYZ, found .osxphotos_export.db files in:
2023-04-08 16:27:41.157929 -- /Users/Shared/Pictures/Logs/.osxphotos_export.db
Do you want to continue? [y/N]: y
2023-04-08 16:27:42.712701 -- Created export database ./.osxphotos_export.db
2023-04-08 16:27:42.714609 -- Processing database /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/photos.db
2023-04-08 16:27:42.716401 -- Processing database /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/Photos.sqlite
2023-04-08 16:27:42.723428 -- Processing database.
2023-04-08 16:27:42.723809 -- Database version: 6000, 7.
2023-04-08 16:27:42.724131 -- Processing persons in photos.
2023-04-08 16:27:42.755999 -- Processing detected faces in photos.
2023-04-08 16:27:42.871317 -- Processing albums.
2023-04-08 16:27:43.445391 -- Processing keywords.
2023-04-08 16:27:43.737461 -- Processing photo details.
2023-04-08 16:27:48.694457 -- Processing import sessions.
2023-04-08 16:27:48.931822 -- Processing additional photo details.
2023-04-08 16:27:50.471268 -- Processing face details.
2023-04-08 16:27:50.864890 -- Processing photo labels.
2023-04-08 16:27:57.290581 -- Processing EXIF details.
2023-04-08 16:27:58.004333 -- Processing computed aesthetic scores.
2023-04-08 16:27:58.730824 -- Processing comments and likes for shared photos.
2023-04-08 16:27:58.735070 -- Processing moments.
2023-04-08 16:27:58.801673 -- Done processing details from Photos library.
2023-04-08 16:27:58.840982 -- Exporting 1 photo to /Users/Shared/Pictures/Logs/X/XYZ...
2023-04-08 16:27:58.879972 -- Exporting IMG_0855.JPG (IMG_0855.JPG) (0/1)
2023-04-08 16:27:58.882187 -- Writing metadata with exiftool for IMG_0855.JPG
2023-04-08 16:27:59.394560 -- Exported IMG_0855.JPG to /Users/Shared/Pictures/Logs/X/XYZ/XXX/IMG_0855.JPG
2023-04-08 16:27:59.472380 -- Error exporting photo (18CD34E6-8E32-4873-BBA7-0EE8C9822EC0: IMG_0855.JPG) as IMG_0855.JPG: '0634722E-DB05-4F18-B6A3-9E612256E1F2'
2023-04-08 16:27:59.472947 -- Retrying export for photo (18CD34E6-8E32-4873-BBA7-0EE8C9822EC0: IMG_0855.JPG)
2023-04-08 16:27:59.475435 -- Writing metadata with exiftool for IMG_0855.JPG
2023-04-08 16:27:59.610230 -- Exported IMG_0855.JPG to /Users/Shared/Pictures/Logs/X/XYZ/XXX/IMG_0855.JPG
2023-04-08 16:27:59.611411 -- Error exporting photo (18CD34E6-8E32-4873-BBA7-0EE8C9822EC0: IMG_0855.JPG) as IMG_0855.JPG: '0634722E-DB05-4F18-B6A3-9E612256E1F2'
2023-04-08 16:27:59.611773 -- Retrying export for photo (18CD34E6-8E32-4873-BBA7-0EE8C9822EC0: IMG_0855.JPG)
2023-04-08 16:27:59.613263 -- Writing metadata with exiftool for IMG_0855.JPG
2023-04-08 16:27:59.750949 -- Exported IMG_0855.JPG to /Users/Shared/Pictures/Logs/X/XYZ/XXX/IMG_0855.JPG
2023-04-08 16:27:59.752195 -- Error exporting photo (18CD34E6-8E32-4873-BBA7-0EE8C9822EC0: IMG_0855.JPG) as IMG_0855.JPG: '0634722E-DB05-4F18-B6A3-9E612256E1F2'
2023-04-08 16:27:59.752651 -- Processed: 1 photo, exported: 0, updated: 0, skipped: 0, updated EXIF data: 0, missing: 0, error: 1, touched date: 0
2023-04-08 16:27:59.753070 -- Elapsed time: 0:00:00
2023-04-08 16:27:59.753397 -- Cleaning up /Users/Shared/Pictures/Logs/X/XYZ
2023-04-08 16:27:59.753926 -- Deleting /Users/Shared/Pictures/Logs/X/XYZ/2016-08-15 Verão Algarve 2016 II/IMG_0855.JPG
2023-04-08 16:27:59.754395 -- Deleting empty directory /Users/Shared/Pictures/Logs/X/XYZ/XXX
2023-04-08 16:27:59.754777 -- Deleting empty directory /Users/Shared/Pictures/Logs/X/XYZ
2023-04-08 16:27:59.755066 -- Deleted: 1 file, 2 directories
2023-04-08 16:27:59.756321 -- Writing export database changes back to ./.osxphotos_export.db
2023-04-08 16:27:59.760528 -- Cleaning up lock files

export.toml used
[export]
cleanup = true
description_template = "Album:{album,}{newline}Description:{descr,}"
directory = "{album|filter(startswith 1|2)[/,.|:,.]}"
exiftool = true
exiftool_merge_keywords = true
exiftool_merge_persons = true
keyword_template = [
    "{keyword}",
    "{label}",
    "{searchinfo.activity?activity:{searchinfo.activity},}",
    "{searchinfo.venue_type?venue_type:{searchinfo.venue_type},}",
]
no_progress = true
not_hidden = true
ramdb = true
retry = 2
skip_bursts = true
skip_live = true
skip_original_if_edited = true
strip = true
timestamp = true
touch_file = true
update = true
verbose = true

Trying to --debug and --breakpoint options but don't seem to be able to. Additionally behaviour seems to be difference. And a crashlog is generated.
$ osxphotos --debug --breakpoint=osxphotos.photoexporter.PhotoExporter.write_exiftool_metadata_to_file export XYZ  --uuid 18CD34E6-8E32-4873-BBA7-0EE8C9822EC0 --load-config export.toml --exportdb ./.osxphotos_export.db
Debugging enabled
2023-04-08 17:59:51.815882 -- Loaded options from file export.toml
2023-04-08 17:59:51.816394 -- osxphotos version: 0.59.1
2023-04-08 17:59:51.816646 -- Python version: 3.11.2 (main, Mar 24 2023, 00:28:48) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
2023-04-08 17:59:51.832841 -- Platform: macOS-12.6.4-x86_64-i386-64bit, 12.6.4
2023-04-08 17:59:51.833983 -- Verbose level: True
2023-04-08 17:59:51.834686 -- exiftool path: /usr/local/bin/exiftool
Using last opened Photos library: /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary
2023-04-08 17:59:51.838331 -- Warning: export database '/Users/Shared/Pictures/Logs/X/.osxphotos_export.db' is in a different directory than export destination '/Users/Shared/Pictures/Logs/X/XYZ'
2023-04-08 17:59:51.839470 -- WARNING: found other export database files in this destination directory branch.  This likely means you are attempting to export files into a directory that is either the parent or a child directory of a previous
export. Proceeding may cause your exported files to be overwritten.
2023-04-08 17:59:51.839992 -- You are exporting to /Users/Shared/Pictures/Logs/X/XYZ, found .osxphotos_export.db files in:
2023-04-08 17:59:51.840315 -- /Users/Shared/Pictures/Logs/.osxphotos_export.db
Do you want to continue? [y/N]: y
2023-04-08 17:59:53.711372 -- Created export database ./.osxphotos_export.db
2023-04-08 17:59:53,714 - osxphotos - DEBUG - photosdb.py - 290 - dbfile = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary
2023-04-08 17:59:53,715 - osxphotos - DEBUG - photosdb.py - 306 - dbfile = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/photos.db
2023-04-08 17:59:53.715154 -- Processing database /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/photos.db
2023-04-08 17:59:53.717373 -- Processing database /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/Photos.sqlite
2023-04-08 17:59:53,725 - osxphotos - DEBUG - photosdb.py - 357 - _dbfile = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/photos.db, _dbfile_actual = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/database/Photos.sqlite
2023-04-08 17:59:53,725 - osxphotos - DEBUG - photosdb.py - 371 - library = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary, masters = /Users/Shared/Pictures/iPhoto Shared Library.photoslibrary/originals
2023-04-08 17:59:53,725 - osxphotos - DEBUG - photosdb.py - 1627 - _process_database5
2023-04-08 17:59:53.725343 -- Processing database.
2023-04-08 17:59:53.725891 -- Database version: 6000, 7.
2023-04-08 17:59:53,726 - osxphotos - DEBUG - photosdb.py - 1650 - Getting information about persons
2023-04-08 17:59:53.726263 -- Processing persons in photos.
2023-04-08 17:59:53.802756 -- Processing detected faces in photos.
2023-04-08 17:59:53.922860 -- Processing albums.
2023-04-08 17:59:54.544071 -- Processing keywords.
2023-04-08 17:59:54.849618 -- Processing photo details.
2023-04-08 18:00:00.343722 -- Processing import sessions.
2023-04-08 18:00:00.628693 -- Processing additional photo details.
2023-04-08 18:00:02.227692 -- Processing face details.
2023-04-08 18:00:02.622020 -- Processing photo labels.
2023-04-08 18:00:09.566328 -- Processing EXIF details.
2023-04-08 18:00:10.348979 -- Processing computed aesthetic scores.
2023-04-08 18:00:11.155977 -- Processing comments and likes for shared photos.
2023-04-08 18:00:11.160614 -- Processing moments.
2023-04-08 18:00:11.232753 -- Done processing details from Photos library.
2023-04-08 18:00:11.283673 -- Exporting 1 photo to /Users/Shared/Pictures/Logs/X/XYZ...
2023-04-08 18:00:11.324557 -- Exporting IMG_0855.JPG (IMG_0855.JPG) (0/1)
2023-04-08 18:00:11.329158 -- Writing metadata with exiftool for IMG_0855.JPG
2023-04-08 18:00:11.969097 -- Exported IMG_0855.JPG to /Users/Shared/Pictures/Logs/X/XYZ/XXX/IMG_0855.JPG
2023-04-08 18:00:12,061 - osxphotos - DEBUG - photosdb.py - 2703 - Caught _dbalbum_folders KeyError for album: 0634722E-DB05-4F18-B6A3-9E612256E1F2
Something went wrong and osxphotos encountered an error:
'0634722E-DB05-4F18-B6A3-9E612256E1F2'
Crash log written to '/Users/Shared/Pictures/Logs/X/osxphotos_crash.log'
Please file a bug report at https://github.com/RhetTbull/osxphotos/issues with the crash log attached.
2023-04-08 18:00:12.072760 -- Cleaning up lock files

the Crash log is:
osxphotos crash log
Created: 2023-04-08 18:00:12.062135
osxphotos version: 0.59.1
Platform: macOS-12.6.4-x86_64-i386-64bit
Python version: 3.11.2 (main, Mar 24 2023, 00:28:48) [Clang 14.0.0 (clang-14<IP_ADDRESS>)]
sys.argv: ['/Users/MSP/Documents/Apps/osxphotos/venv3.11/bin/osxphotos', '--debug', '--breakpoint=osxphotos.photoexporter.PhotoExporter.write_exiftool_metadata_to_file', 'export', 'XYZ', '--uuid', '18CD34E6-8E32-4873-BBA7-0EE8C9822EC0', '--load-config', 'export.toml', '--exportdb', './.osxphotos_export.db']
CRASH_DATA:

(...)

osxphotos version: 0.59.1
Error: '0634722E-DB05-4F18-B6A3-9E612256E1F2'
Traceback (most recent call last):
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/albuminfo.py", line 244, in folder_list
    return self._folders
           ^^^^^^^^^^^^^
AttributeError: 'ProjectInfo' object has no attribute '_folders'

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/crash_reporter.py", line 36, in wrapped
    return func(*args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/cli/export.py", line 1445, in export
    export_results = export_photo(**kwargs)
                     ^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/cli/export.py", line 1907, in export_photo
    results += export_photo_to_directory(
               ^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/cli/export.py", line 2250, in export_photo_to_directory
    raise e
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/cli/export.py", line 2224, in export_photo_to_directory
    export_results = exporter.export(
                     ^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photoexporter.py", line 486, in export
    all_results += self._export_photo(
                   ^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photoexporter.py", line 1215, in _export_photo
    rec.photoinfo = self.photo.json()
                    ^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photoinfo.py", line 1898, in json
    dict_data = self.asdict()
                ^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photoinfo.py", line 1795, in asdict
    project_info = [p.asdict() for p in self.project_info]
                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photoinfo.py", line 1795, in <listcomp>
    project_info = [p.asdict() for p in self.project_info]
                    ^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/albuminfo.py", line 306, in asdict
    dict_data["folder_list"] = [f.uuid for f in self.folder_list]
                                                ^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/albuminfo.py", line 246, in folder_list
    self._folders = self._db._album_folder_hierarchy_folderinfo(self._uuid)
                    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photosdb/photosdb.py", line 2736, in _album_folder_hierarchy_folderinfo
    return self._album_folder_hierarchy_folderinfo_5(album_uuid)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/Users/MSP/Documents/Apps/osxphotos/venv3.11/lib/python3.11/site-packages/osxphotos/photosdb/photosdb.py", line 2777, in _album_folder_hierarchy_folderinfo_5
    folders = self._dbalbum_folders[album_uuid]
              ~~~~~~~~~~~~~~~~~~~~~^^^^^^^^^^^^
KeyError: '0634722E-DB05-4F18-B6A3-9E612256E1F2'

I think I've fixed this in the branch I'm currently working on for #999. Will try to get a new release out this weekend.

@teh-hippo can you send me one of the files in question? Ideally I'd like the original from Photos and the version processed by exiftool.

@teh-hippo thanks for the test data. I'm not sure why this is happening now but I am able to replicate it. Seems only to be an issue with HEIC. This did not always behave this way so not sure what changed (may be related to specific version of exiftool). I can work around this be changing how the face regions are written from the current format to a a struct:
    "RegionInfo": {
        "AppliedToDimensions": {
          "W": 4032,
          "H": 3024,
          "Unit": "pixel"
        },
        "RegionList": [
          {
            "Name": "Face2",
            "Type": "Face",
            "Area": {
              "X": 0.28545492666739014,
              "Y": 0.4058795908771494,
              "W": 0.2098364531993866,
              "H": 0.27978193759918213,
              "Unit": "normalized"
            },
            "PersonDisplayName": "Face2"
          },
          {
            "Name": "Face3",
            "Type": "Face",
            "Area": {
              "X": 0.280715821281312,
              "Y": 0.07760194916363539,
              "W": 0.08417508751153946,
              "H": 0.11223345001538594,
              "Unit": "normalized"
            },
            "PersonDisplayName": "Face3"
          }
        ]
      }

I will try to get to this as soon as able. In the meantime, it does appear the data is actually being written correctly but the warning is annoying.