CI: Bump to FreeBSD 13.2

Looks like there is a problem with strptime()

@brammool
maybe something here:
https://github.com/vim/vim/blob/master/src/testdir/test_functions.vim#L303
and
https://github.com/vim/vim/blob/master/src/testdir/test_vim9_builtin.vim#L4290 ?

@brammool
maybe something here:
https://github.com/vim/vim/blob/master/src/testdir/test_functions.vim#L303
and
https://github.com/vim/vim/blob/master/src/testdir/test_vim9_builtin.vim#L4290 ?

Well, the CI fails for FreeBSD 13.2, while it passes elsewhere.
Failures:
From test_functions.vim:
Found errors in Test_strptime():
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 16: Expected 0 but got -2209078800
From test_vim9_builtin.vim:
Found errors in Test_strptime():
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 6: Expected 'True' but got false
Both cases are for "strptime('%Y', '')".  Looks like it doesn't return
zero for an error.  Or perhaps it actually does accept an empty string
for %Y somehow?
--
hundred-and-one symptoms of being an internet addict:
227. You sleep next to your monitor.  Or on top of it.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

From test_vim9_builtin.vim:
Found errors in Test_strptime():
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 6: Expected 'True' but got false

is fixed on https://github.com/vim/vim/commit/c142d6513e8d71a8f26c5ca1cb00b7b3de9b15e6

From test_vim9_builtin.vim:
Found errors in Test_strptime():
command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 6: Expected 'True' but got false
is fixed on https://github.com/vim/vim/commit/c142d6513e8d71a8f26c5ca1cb00b7b3de9b15e6

That is weird, since that patch only changes how the comparison with
zero is done.  After the patch it will return the number, other than
zero, if the assert fails.
Does this depend on uninitialized memory perhaps?  Run under valgrind to
find out (if you can do that).
--
hundred-and-one symptoms of being an internet addict:
229. You spend so much time thinking what to add on this list.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

From test_vim9_builtin.vim: Found errors in Test_strptime(): command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 6: Expected 'True' but got false is fixed on c142d65
That is weird, since that patch only changes how the comparison with zero is done. After the patch it will return the number, other than zero, if the assert fails. Does this depend on uninitialized memory perhaps? Run under valgrind to find out (if you can do that).
…
-- hundred-and-one symptoms of being an internet addict: 229. You spend so much time thinking what to add on this list. /// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net \\ /// \\ \\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\ help me help AIDS victims -- http://ICCF-Holland.org ///

$ valgrind --leak-check=full vim

==5707== HEAP SUMMARY:
==5707==     in use at exit: 2,773,677 bytes in 22,912 blocks
==5707==   total heap usage: 46,644 allocs, 23,732 frees, 28,054,506 bytes allocated
==5707==
==5707== 12 bytes in 2 blocks are possibly lost in loss record 62 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x496D78: ??? (in /usr/local/bin/vim)
==5707==    by 0x48BDD0: ??? (in /usr/local/bin/vim)
==5707==    by 0x491CBB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==
==5707== 16 bytes in 1 blocks are possibly lost in loss record 73 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x48C9BE: ??? (in /usr/local/bin/vim)
==5707==    by 0x49268D: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 18 bytes in 1 blocks are possibly lost in loss record 75 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x48C9BE: ??? (in /usr/local/bin/vim)
==5707==    by 0x49268D: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 20 bytes in 1 blocks are possibly lost in loss record 82 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x48C9BE: ??? (in /usr/local/bin/vim)
==5707==    by 0x49268D: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BDB: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 24 bytes in 1 blocks are possibly lost in loss record 85 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x413A20: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x44F963: ??? (in /usr/local/bin/vim)
==5707==
==5707== 24 bytes in 6 blocks are possibly lost in loss record 86 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x47C337: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EDFD3: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EFAD4: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EF5DF: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EF027: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EEDDF: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EEB7C: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EE801: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E5E17: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E99BC: ??? (in /usr/local/bin/vim)
==5707==
==5707== 27 bytes in 1 blocks are possibly lost in loss record 89 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 28 bytes in 1 blocks are possibly lost in loss record 90 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x48F54A: ??? (in /usr/local/bin/vim)
==5707==    by 0x48DBFF: ??? (in /usr/local/bin/vim)
==5707==    by 0x48D400: ??? (in /usr/local/bin/vim)
==5707==    by 0x4958C2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 31 bytes in 1 blocks are possibly lost in loss record 94 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BF6: ??? (in /usr/local/bin/vim)
==5707==
==5707== 35 bytes in 1 blocks are possibly lost in loss record 99 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FD9ED: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 35 bytes in 1 blocks are possibly lost in loss record 100 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBC4C: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F28F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4823007: ???
==5707==
==5707== 48 bytes in 2 blocks are possibly lost in loss record 125 of 303
==5707==    at 0x484C984: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FBA0: ??? (in /usr/local/bin/vim)
==5707==    by 0x496D57: ??? (in /usr/local/bin/vim)
==5707==    by 0x48BDD0: ??? (in /usr/local/bin/vim)
==5707==    by 0x491CBB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 67 bytes in 2 blocks are possibly lost in loss record 142 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==
==5707== 74 bytes in 13 blocks are possibly lost in loss record 143 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x496D78: ??? (in /usr/local/bin/vim)
==5707==    by 0x48BDD0: ??? (in /usr/local/bin/vim)
==5707==    by 0x491CBB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==
==5707== 160 bytes in 1 blocks are possibly lost in loss record 166 of 303
==5707==    at 0x4850391: realloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FCF7: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B33: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BDB: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 160 bytes in 1 blocks are possibly lost in loss record 167 of 303
==5707==    at 0x4850391: realloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FCF7: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B33: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 160 bytes in 2 blocks are possibly lost in loss record 168 of 303
==5707==    at 0x484C984: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FCF7: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B33: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 227 bytes in 13 blocks are possibly lost in loss record 173 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x48C9BE: ??? (in /usr/local/bin/vim)
==5707==    by 0x49268D: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F28F: ??? (in /usr/local/bin/vim)
==5707==
==5707== 238 bytes in 12 blocks are possibly lost in loss record 174 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B6E: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 264 bytes in 11 blocks are possibly lost in loss record 179 of 303
==5707==    at 0x484C984: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FBA0: ??? (in /usr/local/bin/vim)
==5707==    by 0x496D57: ??? (in /usr/local/bin/vim)
==5707==    by 0x48BDD0: ??? (in /usr/local/bin/vim)
==5707==    by 0x491CBB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==
==5707== 401 bytes in 3 blocks are possibly lost in loss record 205 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x47C7E6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EE041: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EFAD4: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EF5DF: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EF027: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EEDDF: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EEB7C: ??? (in /usr/local/bin/vim)
==5707==    by 0x2EE801: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E5E17: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E99BC: ??? (in /usr/local/bin/vim)
==5707==
==5707== 416 bytes in 1 blocks are possibly lost in loss record 208 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F6F3: ??? (in /usr/local/bin/vim)
==5707==    by 0x4922CB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 418 bytes in 1 blocks are possibly lost in loss record 209 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F6F3: ??? (in /usr/local/bin/vim)
==5707==    by 0x4922CB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BDB: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 449 bytes in 16 blocks are possibly lost in loss record 210 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B6E: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 506 bytes in 14 blocks are possibly lost in loss record 211 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x301DF6: ??? (in /usr/local/bin/vim)
==5707==    by 0x2E87A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE747: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FE45E: ??? (in /usr/local/bin/vim)
==5707==    by 0x2FDF25: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==
==5707== 640 bytes in 8 blocks are possibly lost in loss record 221 of 303
==5707==    at 0x484C984: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FCF7: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B33: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F28F: ??? (in /usr/local/bin/vim)
==5707==
==5707== 721 bytes in 20 blocks are possibly lost in loss record 231 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B6E: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BDB: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==
==5707== 832 bytes in 2 blocks are possibly lost in loss record 233 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F6F3: ??? (in /usr/local/bin/vim)
==5707==    by 0x4922CB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x319BBF: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 2,856 bytes in 8 blocks are possibly lost in loss record 263 of 303
==5707==    at 0x4850391: realloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29FCF7: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B33: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F28F: ??? (in /usr/local/bin/vim)
==5707==
==5707== 6,304 bytes in 788 blocks are possibly lost in loss record 275 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x47ABF4: ??? (in /usr/local/bin/vim)
==5707==    by 0x2C7EE4: ??? (in /usr/local/bin/vim)
==5707==    by 0x2C82FB: ??? (in /usr/local/bin/vim)
==5707==    by 0x2F16CD: ??? (in /usr/local/bin/vim)
==5707==    by 0x48DC4C: ??? (in /usr/local/bin/vim)
==5707==    by 0x48D400: ??? (in /usr/local/bin/vim)
==5707==    by 0x4958C2: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==
==5707== 6,637 bytes in 16 blocks are possibly lost in loss record 276 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F6F3: ??? (in /usr/local/bin/vim)
==5707==    by 0x4922CB: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==    by 0x29F28F: ??? (in /usr/local/bin/vim)
==5707==
==5707== 9,661 bytes in 321 blocks are possibly lost in loss record 286 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x443870: ??? (in /usr/local/bin/vim)
==5707==    by 0x493B6E: ??? (in /usr/local/bin/vim)
==5707==    by 0x4920F9: ??? (in /usr/local/bin/vim)
==5707==    by 0x494082: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBDFE: ??? (in /usr/local/bin/vim)
==5707==    by 0x4FBA3B: ??? (in /usr/local/bin/vim)
==5707==
==5707== 21,079 bytes in 788 blocks are possibly lost in loss record 289 of 303
==5707==    at 0x484CBC4: malloc (in /usr/local/libexec/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==5707==    by 0x29F597: ??? (in /usr/local/bin/vim)
==5707==    by 0x2C7EAD: ??? (in /usr/local/bin/vim)
==5707==    by 0x2C82FB: ??? (in /usr/local/bin/vim)
==5707==    by 0x2F16CD: ??? (in /usr/local/bin/vim)
==5707==    by 0x48DC4C: ??? (in /usr/local/bin/vim)
==5707==    by 0x48D400: ??? (in /usr/local/bin/vim)
==5707==    by 0x4958C2: ??? (in /usr/local/bin/vim)
==5707==    by 0x310EC2: ??? (in /usr/local/bin/vim)
==5707==    by 0x414453: ??? (in /usr/local/bin/vim)
==5707==    by 0x41213F: ??? (in /usr/local/bin/vim)
==5707==    by 0x4122A2: ??? (in /usr/local/bin/vim)
==5707==
==5707== LEAK SUMMARY:
==5707==    definitely lost: 0 bytes in 0 blocks
==5707==    indirectly lost: 0 bytes in 0 blocks
==5707==      possibly lost: 52,588 bytes in 2,060 blocks
==5707==    still reachable: 2,721,089 bytes in 20,852 blocks
==5707==         suppressed: 0 bytes in 0 blocks
==5707== Reachable blocks (those to which a pointer was found) are not shown.
==5707== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==5707==
==5707== For lists of detected and suppressed errors, rerun with: -s
==5707== ERROR SUMMARY: 33 errors from 33 contexts (suppressed: 0 from 0)

From test_vim9_builtin.vim: Found errors in Test_strptime(): command line..script /tmp/cirrus-ci-build/src/testdir/runtest.vim[569]..function RunTheTest[52]..Test_strptime line 6: Expected 'True' but got false is fixed on c142d65
That is weird, since that patch only changes how the comparison with
zero is done. After the patch it will return the number, other than
zero, if the assert fails. Does this depend on uninitialized memory
perhaps? Run under valgrind to find out (if you can do that).
…

$ valgrind --leak-check=full vim

Only shows "possibly lost" leak warnings, these are most likely OK.
I usually run valgrind with:
valgrind --tool=memcheck --leak-check=yes

Does that make any difference?
--
hundred-and-one symptoms of being an internet addict:
235. You start naming your kids Pascal, COBOL, Algol and Fortran.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

@brammool I guess no:
==6765== LEAK SUMMARY:
==6765==    definitely lost: 0 bytes in 0 blocks
==6765==    indirectly lost: 0 bytes in 0 blocks
==6765==      possibly lost: 52,588 bytes in 2,060 blocks
==6765==    still reachable: 2,840,423 bytes in 20,863 blocks
==6765==         suppressed: 0 bytes in 0 blocks
==6765== Reachable blocks (those to which a pointer was found) are not shown.
==6765== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6765==
==6765== For lists of detected and suppressed errors, rerun with: -s
==6765== ERROR SUMMARY: 33 errors from 33 contexts (suppressed: 0 from 0)

@brammool I guess no:
==6765== LEAK SUMMARY:
==6765==    definitely lost: 0 bytes in 0 blocks
==6765==    indirectly lost: 0 bytes in 0 blocks
==6765==      possibly lost: 52,588 bytes in 2,060 blocks
==6765==    still reachable: 2,840,423 bytes in 20,863 blocks
==6765==         suppressed: 0 bytes in 0 blocks
==6765== Reachable blocks (those to which a pointer was found) are not shown.
==6765== To see them, rerun with: --leak-check=full --show-leak-kinds=all
==6765==
==6765== For lists of detected and suppressed errors, rerun with: -s
==6765== ERROR SUMMARY: 33 errors from 33 contexts (suppressed: 0 from 0)

OK, so we have no idea where those test failures are coming from.
I'm afraid I don't like including a patch that will result in test
failures.
It probably requires stepping through the code on a FreeBSD 13.2 system
to find out what is going on.  Otherwise, perhaps someone knows what
changed in FreeBSD 13.2 regarding strptime().  Or mktime(), which is
used as well.
--
hundred-and-one symptoms of being an internet addict:
238. You think faxes are old-fashioned.
/// Bram Moolenaar -- @.*** -- http://www.Moolenaar.net   \
///                                                                      \
\\        sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ ///
\\            help me help AIDS victims -- http://ICCF-Holland.org    ///

Yes I am with you, let's leave it at that for now and close this PR. - There will surely be patches coming if someone has problems with FreeBSD 13.2 and upstream vim.


Build failure: pkgsLLVM.makeBinaryWrapper

Steps To Reproduce
Steps to reproduce the behavior:

build something which uses makeBinaryWrapper (easily perl.withPackages [])

Build log
clang: error: unable to execute command: Executable "ld" doesn't exist!
clang: error: linker command failed with exit code 1 (use -v to see invocation)

Additional context
Add any other context about the problem here.
Notify maintainers

No maintainers, blame says @tie last made a modification.
Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
output here

Add a :+1: reaction to issues you find important.

No maintainers, blame says @tie last made a modification.

Hm, I can’t recall changing anything remotely related to LLVM and/or wrapper stuff recently. Which file(s) are you referring to?


Problem with the OPERATOR_LIKE

I have a basic grid with an only one FilterControl using the operator like. An give back the following error:
"Unsupported operator like"
This is my code
``$provider = new ArrayDataProvider($divisions->toArray());
        $input = new InputSource($_GET);
        $sortingInput = new InputOption('sort', $_GET);

        $grid = new Grid($provider, [
            new Column('id'),
            (new Column('name'))
                ->setLabel(ucfirst(trans('messages.name')))
            ,
            (new Column('actions'))
                ->setLabel(ucfirst(trans('messages.actions')))
                ->setValueCalculator(function($row){
                    return "id])."'>
                        | id])."'>
                        | id])."' onclick='return confirm('".trans('messages.delete')."')'>
                        ";
                })
            ,
            new FilterControl('name', FilterOperation::OPERATOR_LIKE, $input->option('name')),
            new PaginationControl($input->option('page', 1), 5),
            new ColumnSortingControl('id', $sortingInput),
            new ColumnSortingControl('name', $sortingInput),
        ]);``

I don't know what I'm doing wrong. Also always the grid print the following character by the end of the grid "}".
Thanks in advance.

ArrayDataProvider does not supports LIKE (it's hard to implement), use FilterOperation::OPERATOR_STR_CONTAINS
Please give me know if problem with  "}" remains after replacing FilterOperation::OPERATOR_LIKE  to FilterOperation::OPERATOR_STR_CONTAINS

Another note: unlike it's done in nayjest/grids, here FilterOperation::OPERATOR_LIKE don't wraps input with % charecters, it's designed to allow usage of placeholders that works with SQL like (%, ?) inside input.
So, FilterOperation::OPERATOR_STR_CONTAINS is equivalent to FilterOperation::OPERATOR_LIKE  from natyjest/grids (for data-providers that reads from DB it  adds LIKE "%{$value}%" to SQL )

The operator: OPERATOR_STR_CONTAINS works well. Thanks!

What about problem with  "}" . Does It disappeared when you fixed errors?


Create a check that finds values outside of predefined min and max ranges

This occurs when data is collected, and then the range restriction is put into place.

Closing "checks" related issues in favor of future re-imaginations.


Issue 2565: join component should expect a list of devices from config

Related issue (if applicable): fixes #2565
Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#
support multiple components. (#2565)

Looks good!

It would have been fine for you to merge @kellerza (except obviously you forgot to give the 🐬 )

Will pack some tuna for the next round :fish: :smile:


⚠ Kijk op Bodegraven-Reeuwijk has degraded performance

In 6d817e1, Kijk op Bodegraven-Reeuwijk (https://www.kobr.nl) experienced degraded performance:

HTTP code: 500
Response time: 6686 ms

Resolved: Kijk op Bodegraven-Reeuwijk performance has improved in 3e7ec7c after 16 minutes.


ApiError with no reason. Cloud function, upload API

In my firebase cloud function, I get the following error: Cannot parse JSON response (which is not very helpful).
My cloud function is generating multiple csv files and trying to upload them to GCS bucket.
The weird part is that some of the files do get uploaded, and some of them fail. It seems to be random.
I tried 2.4.2, 2.4.3, 2.5.0 , all are giving the same error.  Earlier version 1.x was giving ESOCKETTIMEDOUT errors.
When i run the function locally, I never get this error. It always finishes success.
Could you please help to understand how to debug the same?
Error: Cannot parse JSON response
    at ApiError (/user_code/node_modules/@google-cloud/storage/node_modules/@google-cloud/common/build/src/util.js:43:9)
    at Util.parseHttpRespBody (/user_code/node_modules/@google-cloud/storage/node_modules/@google-cloud/common/build/src/util.js:185:42)
    at Util.handleResp (/user_code/node_modules/@google-cloud/storage/node_modules/@google-cloud/common/build/src/util.js:134:117)
    at retryRequest (/user_code/node_modules/@google-cloud/storage/node_modules/@google-cloud/common/build/src/util.js:422:22)
    at onResponse (/user_code/node_modules/@google-cloud/storage/node_modules/retry-request/index.js:200:7)
    at /user_code/node_modules/@google-cloud/storage/node_modules/teeny-request/build/src/index.js:158:17
    at process._tickDomainCallback (internal/process/next_tick.js:135:7) message: 'Cannot parse JSON response'

Environment details

OS: mac
Node.js version: v8.9.4
npm version: 5.6.0
@google-cloud/storage version: 2.5.0, 2.4.3, 2.4.2, 1.3

promises.push(Promise.all([

                filesysRef
                .outputFile(tmpFilePath, values.join('\n'))
                .then(() =>
                  gcs.bucket(bucketName).upload(tmpFilePath, { destination: filePath } )),

                filesysRef
                .outputFile(tmpItemFilePath, items.join('\n'))
                .then(() => gcs.bucket(bucketName)
                .upload(tmpItemFilePath, { destination: itemFilePath }
                )),

              ])
              .then(() => {
                gcs.bucket(bucketName).file(itemFilePath).exists()
                .then(() => { hour.ref.remove().then(() => console.log('done removeal'));
              }, err => console.log(err))
              .catch(error => {
                console.log(error)
              })
              .then(() => filesysRef.unlinkSync(tmpItemFilePath))
              .then(() => filesysRef.unlinkSync(tmpOrderFilePath))
            );

Function returns a Promise.all(promises) eventually. T.
There is possibly a correlation on the memory size allocated to the function and the number of failures, but again I am not getting any useful error message to debug what the exact cause of the ApiError is.
Would appreciate help in understanding how I can find the real reason of failure.

The way I've worked around this bug right now is the following.

Created two functions to do the processing, a parent and child.
parent function looks at the datasets and creates publishes multiple messages to a topic.
The child function then subscribes to individual messages, in each instance it works on individual buckets and hence generates one csv per data bucket.

This way the amount of memory being used per function call is limited and so far i'm not getting the error anymore (because individual buckets are small, compared to the sum of all).
But again, my data is not that huge. its 200 or so jsons. divided in around 10 or so buckets, and I have 256 mb allocated to the functions.

@Kshitij-Banerjee sorry for the trouble. We have seen this "Cannot parse JSON response" error before, and it is either when the Storage JSON API doesn't return JSON for some reason, or when we somehow ping the XML API.
I filled in some blanks in your reproduction code: https://gist.github.com/stephenplusplus/82ad8615b7a7461c2426b7f33f9ae164 -- does this still look correct?
Any other details about the environment would be helpful as well (the more the better).

@Kshitij-Banerjee It seems like there is a lot of moving parts to your scenario, and any of them could be the culprit. In general, Pub/Sub has been working on some memory issues, and on top of that GCF is a unique environment. I'm going to close, but if you can provide more information about how to reproduce, we can start digging in. Sorry for the trouble.


cargo-tauri: init at 1.0.5

Description of changes
Adds the cargo-tauri package, used for building Tauri projects - https://github.com/tauri-apps/tauri

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[ ] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

This pull request has been mentioned on NixOS Discourse. There might be relevant details there:
https://discourse.nixos.org/t/prs-ready-for-review/3032/1119


Beam search

Should we retire beam-search as decoding method?

beam-search doesn't consistently outperform sampling or greedy decoding
beam-search generation takes much longer than other methods during inference
dropping beam-search would allow us to add other decoding method / prompt regime without increasing eval time

But:

such change would further complicate the comparison of old/new eval results

have provisionally dropped beam search in favor of self-correction / peer review


cannot create new git branch after upgrade to 1.11.0

VSCode Version: 1.11.0
OS Version: windows 10

Steps to Reproduce:

click on left lower corner git menu (where the current branch name displayed)
on the top bar will open autocomplete menu with all branch names list
previously you was able to to write the new branch name , press enter, and the new branch was created, but now - nothing happens

Thanks

Experiencing same issue and can't seem to find how you're supposed to do it after the update.

Tracking with #24023


Adding code to run on Powersystem

Hi
Here is my contribution to your code, its working good on powersystems.
Thanks for the code, its working good.
What do these changes do?
Added Architecture "ppc64le"
Are there changes in behavior for the user?
No

Thank you for your contribution, but this is a pure-JS module which does not use any OS APIs in Node.js, so there isn't really a need to test on various operation systems and architectures within this project, which is why it does not test on Windows, either. This change further ties us in to Travis CI, which is in the process of being removed from our projects due to it no longer being free soon.


SPM doesn't compile properly with version 8.x.x

PromiseKit major version = 8
We are using SwiftPM to install PromiseKit and get the following error using version 8.x.x:
package 'package.swift' is using Swift tools version 3.1.0 which is no longer supported; consider using '// swift-tools-version: 5.9' to specify the current tools version

We are using Swift Tools 5.9 as you can see from our Package.swift file:
// swift-tools-version:5.9
// The swift-tools-version declares the minimum version of Swift required to build this package.

import PackageDescription

let package = Package(
    name: "AllegionNetworking",
    platforms: [
        .iOS(.v13)
    ],
    products: [
        // Products define the executables and libraries a package produces, and make them visible to other packages.
        .library(
            name: "AllegionNetworking",
            targets: ["AllegionNetworking"])
    ],
    dependencies: [
        // Dependencies declare other packages that this package depends on.
         .package(url: "https://ircost.visualstudio.com/Allegion/_git/Allegion.Logging.iOS",
                  .upToNextMajor(from: "4.0.0")),
         .package(url: "https://ircost.visualstudio.com/Allegion/_git/Allegion.Security.iOS",
                  .upToNextMajor(from: "3.0.0")),
         .package(url: "https://github.com/mxcl/PromiseKit",
                  .upToNextMajor(from: "8.0.0")),
         .package(url: "https://github.com/PromiseKit/Foundation",
                  .upToNextMajor(from: "3.0.0")),
         .package(url: "https://github.com/realm/SwiftLint",
                  .upToNextMajor(from: "0.53.0")),
         .package(url: "https://github.com/Quick/Nimble",
                  .upToNextMajor(from: "13.0.0"))
    ],
    targets: [
        // Targets are the basic building blocks of a package. A target can define a module or a test suite.
        // Targets can depend on other targets in this package, and on products in packages this package depends on.
        .target(
            name: "AllegionNetworking",
            dependencies: [
                .product(name: "AllegionLoggingLite", package: "Allegion.Logging.iOS"),
                .product(name: "AllegionSecurity", package: "Allegion.Security.iOS"),
                "PromiseKit",
                .product(name: "PMKFoundation", package: "Foundation")
            ],
            plugins: [.plugin(name: "SwiftLintPlugin", package: "SwiftLint")]),
        .testTarget(
            name: "AllegionNetworking-UnitTests",
            dependencies: ["AllegionNetworking", "Nimble"],
            path: "Tests/AllegionNetworkingTests/Unit",
            resources: [
                .copy("Supporting Files/developerapi.allegion.com.cer"),
                .copy("Supporting Files/www.google.com.cer")
            ],
            swiftSettings: [
                .define("SPM")
            ],
            plugins: [.plugin(name: "SwiftLintPlugin", package: "SwiftLint")]),
        .testTarget(
            name: "AllegionNetworking-IntegrationTests",
            dependencies: ["AllegionNetworking", "Nimble"],
            path: "Tests/AllegionNetworkingTests/Integration",
            plugins: [.plugin(name: "SwiftLintPlugin", package: "SwiftLint")]),
        .testTarget(
            name: "AllegionNetworking-FunctionalTests",
            dependencies: ["AllegionNetworking", "Nimble"],
            path: "Tests/AllegionNetworkingTests/Functional",
            plugins: [.plugin(name: "SwiftLintPlugin", package: "SwiftLint")])
    ]
)

Changing the Swift Tools version does not change anything.  PromiseKit version 6.22.1 works just fine with Swift Tools 5.9 and all is well, but we would like to update to the newest version of PromiseKit.

Hello @cbauer10
What about this fix?

Hello @cbauer10
Have you tried my fork in your project? Just want to know if my fix is correct.

@RomanPodymov
Yes, this does resolve the issue.  I support your PR #34.
@mxcl
Any chance we can update Foundation to the latest version as @RomanPodymov has suggested?

sorry for the delay


adding keyboard support to text-input

responsivenexx fix in the footer

@Jialecl, can you please resolve the conflicts??


Remove dead placeholder / prompt param

the x-select component code has  placeholder yet the the template doesn't take advantage of it.

Good catch. This is actually leftover from when we supported a blockless form of the component. If you still would like to do that you can use x-select-blockless.

FWIW this change fixes it (app/templates/components/x-select.hbs):
{{#if placeholder}}
  {{#x-option}} {{placeholder}} {{/x-option}}
{{/if}}
{{yield}}

@stephencattaneo
The philosophy of x-select is to be as thin a wrapper around the native select option as possible. That way, it remains simple, flexible, and clear how to work with it given knowledge of the standard select and option tags.
So would definitely accept a PR to remove the placeholder attribute, but not one to use it in the template.


pandoc-citeproc-0.14 out of bounds for hakyll

pandoc-citeproc-0.14 (John MacFarlane<EMAIL_ADDRESS>@jgm) is out of bounds for:

[ ] hakyll-<IP_ADDRESS> (==0.13.*). Jasper Van der Jeugt @jaspervdj. @jaspervdj. Used by: library

Both pandoc-citeproc and hakyll have been removed from the build plan for now per #3232.


hdkey: save seed for use in multiple derivations

our wallet wants to derive several accounts at a time. it's more efficient to do the expensive part of stretching the mnemonic into a seed once and allow the library user to get multiple paths' keys from that seed.

https://github.com/oasisprotocol/oasis-sdk/blob/8039a75d7fe42dd8021317424cee073e60435f84/client-sdk/ts-web/core/src/hdkey.ts#L33-L35

Originally posted by @lukaw3d in https://github.com/oasisprotocol/oasis-wallet-web/pull/1454#discussion_r1192749215

interesting, mnemonicToSeed from bip39 looks like it uses @noble sha512 in pbkdf2 https://github.com/bitcoinjs/bip39/blob/v3.1.0/src/index.js#L41 (c: 2048, whatever that parameter is)
derivePath calls derive, and derive calls makeHDKey, and the stuff outside makeHDKey doesn't look like it ought to take 300+ms
and makeHDKey uses js-sha512, if I were to count it out, three calls per path


Loosened dataclasses-json and removed pandas's jinja extra

Description
https://github.com/run-llama/llama_index/pull/8049 seems to have unnecessarily pinned dataclasses-json so it stays like >=0.5.7,<0.6. This PR loosens that dependency, which fixes https://github.com/run-llama/llama_index/issues/9039.
It also removes the jinja extra from pandas, which fixes https://github.com/run-llama/llama_index/issues/9038.
Type of Change

[x] Bug fix (non-breaking change which fixes an issue)
[x] Breaking change (fix or feature that would cause existing functionality to not work as expected)

How Has This Been Tested?

[ ] Added new unit/integration tests
[ ] Added new notebook (that tests end-to-end)
[x] I stared at the code and made sure it makes sense

Thanks for removing Jinja, that was from a failed fix 😅 didn't mean to commit that whoops


ImportError: cannot import name bbox_overlaps_cython

I run python ./fgfa_rfcn/demo.py
then have a problem,
Traceback (most recent call last):
File "./fgfa_rfcn/demo.py", line 21, in
from utils.image import resize, transform
File "/home/grade3_weiyun/projects/Flow-Guided-Feature-Aggregation-master/fgfa_rfcn/../lib/utils/image.py", line 6, in
from bbox.bbox_transform import clip_boxes
File "/home/grade3_weiyun/projects/Flow-Guided-Feature-Aggregation-master/fgfa_rfcn/../lib/bbox/bbox_transform.py", line 3, in
from bbox import bbox_overlaps_cython
ImportError: cannot import name bbox_overlaps_cython
how should i do?

Did you run "sh init.sh"?

Duplicate of #https://github.com/msracver/Deep-Feature-Flow/issues/21

I also encountered this problem, would like to ask how to solve it, can only use python2?

I also meet this problem when use python3 anaconda3. I solved with building an environment about python2.7, it works well!


Basic log docs missing details from PG blogs

Many important details provided in PB blog posts are missing here. For example, basic logs do not contribute to commitment tiers.
https://techcommunity.microsoft.com/t5/microsoft-sentinel/new-blog-post-the-basic-logs-for-microsoft-sentinel-kql/m-p/3259001
https://techcommunity.microsoft.com/t5/microsoft-sentinel-blog/faq-search-basic-ingestion-archive-and-data-restoration/ba-p/3205600

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 19c4afbf-7154-d80e-b7f0-63b6bc0f3399
Version Independent ID: d22a7324-cb52-40aa-27fe-421fe3e70fba
Content: Configure Basic Logs in Azure Monitor (Preview) - Azure Monitor
Content Source: articles/azure-monitor/logs/basic-logs-configure.md
Service: azure-monitor
Sub-service: logs
GitHub Login: @guywi-ms
Microsoft Alias: guywild

@AndrewBlumhardt
Thanks for your feedback! We will investigate and update as appropriate.

@AndrewBlumhardt Thanks for your feedback! We've create a work item to follow up and address this issue. We intend to update this article shortly with the relevant content. I'm going to go ahead and close this issue now. Thanks again 👍
#please-close


Is it harmless to call download() many times?

Say at 11:11:07.0 I call x.download()
Say that will take about three seconds to reach playerItemReadyToPlay and 10 seconds to fully download.
At 11:11:08.0 I call x.download() again

is this completely harmless ?

Does it know it is already doing x ?

thanks!  @neekeetab - amazing library, the best

+1

Calling download when there’s already a file loading has no effect

If we repeatedly call download on the same item (even if item is being actively downloaded), will the item be downloaded again? Or is there a way we can check if an item has already been downloaded? Thanks.
Sent via Superhuman<EMAIL_ADDRESS>)
On Wed, Jan 08, 2020 at 11:42 PM, Nikita Belousov <<EMAIL_ADDRESS>> wrote:

Calling download when there’s already a file loading has no effect
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (
https://github.com/neekeetab/CachingPlayerItem/issues/28?email_source=notifications&email_token=ACRBWAPIC7VRWDZCSIUQ6DTQ43INJA5CNFSM4JZC7EGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIPKISY#issuecomment-572433483
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/ACRBWAMTIGZIYL6SMJRM2T3Q43INJANCNFSM4JZC7EGA
).

It will not be downloaded again. When loading is complete, delegate's playerItem(_ playerItem: CachingPlayerItem, didFinishDownloadingData data: Data) is called

Great - thanks!

Great, thanks!
Sent via Superhuman<EMAIL_ADDRESS>)
On Thu, Jan 09, 2020 at 3:53 AM, Nikita Belousov <<EMAIL_ADDRESS>> wrote:

It will not be downloaded again. When loading is complete, delegate's playerItem(_
playerItem: CachingPlayerItem, didFinishDownloadingData data: Data) is
called
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub (
https://github.com/neekeetab/CachingPlayerItem/issues/28?email_source=notifications&email_token=ACRBWAPYRIN4ZUZZBD6LZ23Q44F5NA5CNFSM4JZC7EGKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEIQBRPQ#issuecomment-572528830
) , or unsubscribe (
https://github.com/notifications/unsubscribe-auth/ACRBWALAQU36MDAM7ZPSZMDQ44F5NANCNFSM4JZC7EGA
).

Is there any way I can check whether my file is present in the cached list? and also I wanted to clear the memory when total memory consumption is more


run rnn_train.py fail!

nice job!
I use your code to train a model.meet one problem.
The model have three classes,I use three kinds videos to train it. name action1,action2,action3.
I success to
python "Video To Frame.py"
python retrain.py --bottleneck_dir=bottlenecks --model_dir=inception --summaries_dir=training_summaries/long --output_graph=retrained_graph.pb --output_labels=retrained_labels.txt --image_dir=majorData
python make_predictions.py
python make_predictions_pool.py
But when run rnn_train.py,it fail. just as this:
1action2 2
action1 1
action3 0
Total dataset size: 82
Traceback (most recent call last):
File "rnn_train.py", line 52, in
main(filename, frames, batch_size, num_classes, input_length)
File "rnn_train.py", line 13, in main
filename, frames, num_classes, input_length, True)
File "/home/stockerc/project/sign-language-gesture-recognition/rnn_utils.py", line 62, in get_data
X = X.reshape(-1, num_frames, input_length)
ValueError: cannot reshape array of size 49446 into shape (201,64)
How do I define the follow:
input_length = 64 ?
frames = 201
batch_size = 32
num_classes = 64
in the rnn_train.py  file!
which means   input_length ?
Thanks you!

When I use mode 2 and modify rnn_train.py just as this:
filename = 'data/cnn-features-frames-1.pkl'
input_length = 2048
#filename = 'data/predicted-frames-1.pkl'
#input_length = 64
It can be trained!

@zy486at189cn
Hi,
After you finish training model. Does the test running perfect or not? Cause when I was running test steps, they just said InvalidArgument Error. Do you know how to fix it?

nice job!
I use your code to train a model.meet one problem.
The model have three classes,I use three kinds videos to train it. name action1,action2,action3.
I success to
python "Video To Frame.py"
python retrain.py --bottleneck_dir=bottlenecks --model_dir=inception --summaries_dir=training_summaries/long --output_graph=retrained_graph.pb --output_labels=retrained_labels.txt --image_dir=majorData
python make_predictions.py
python make_predictions_pool.py
But when run rnn_train.py,it fail. just as this:
1action2 2
action1 1
action3 0
Total dataset size: 82
Traceback (most recent call last):
File "rnn_train.py", line 52, in
main(filename, frames, batch_size, num_classes, input_length)
File "rnn_train.py", line 13, in main
filename, frames, num_classes, input_length, True)
File "/home/stockerc/project/sign-language-gesture-recognition/rnn_utils.py", line 62, in get_data
X = X.reshape(-1, num_frames, input_length)
ValueError: cannot reshape array of size 49446 into shape (201,64)
How do I define the follow:
input_length = 64 ?
frames = 201
batch_size = 32
num_classes = 64
in the rnn_train.py file!
which means input_length ?
Thanks you!

input_length denotes the size of the representation of each frame. In the first case that would be equal to the number of classes.

Scripts have been updated to automatically handle this based on how many classes are present in the training folder.

nice job!
I use your code to train a model.meet one problem.
The model have three classes,I use three kinds videos to train it. name action1,action2,action3.
I success to
python "Video To Frame.py"
python retrain.py --bottleneck_dir=bottlenecks --model_dir=inception --summaries_dir=training_summaries/long --output_graph=retrained_graph.pb --output_labels=retrained_labels.txt --image_dir=majorData
python make_predictions.py
python make_predictions_pool.py
But when run rnn_train.py,it fail. just as this:
1action2 2
action1 1
action3 0
Total dataset size: 82
Traceback (most recent call last):
File "rnn_train.py", line 52, in
main(filename, frames, batch_size, num_classes, input_length)
File "rnn_train.py", line 13, in main
filename, frames, num_classes, input_length, True)
File "/home/stockerc/project/sign-language-gesture-recognition/rnn_utils.py", line 62, in get_data
X = X.reshape(-1, num_frames, input_length)
ValueError: cannot reshape array of size 49446 into shape (201,64)
How do I define the follow:
input_length = 64 ?
frames = 201
batch_size = 32
num_classes = 64
in the rnn_train.py file!
which means input_length ?
Thanks you!

Hello, Did you get the solution of this? I am getting same error.


update build tools to no longer "magically" pull in related pkg dependencies

Jira
http://vjira2:8080/browse/BDS-2111
Summary
Removes "magically" pulling in related Bolt dependencies in our Webpack build + removes extra comments generated in prod mode. As a result (mostly from the dependency-related update), this PR shaves off around 200KB off our total JS bundle size!

Details
This "feature" was originally intended to help catch and wire up undeclared dependencies within Bolt components which given how things have been trending, should no longer be required.
How to test

Confirm tests passing
Double-check with @remydenton on if we'd expect any unforeseen side-effects from this downstream

Closing out -- this is now replaced by #1864


test-nmos-is0405 fails IS-04 test 10 when nmos-cpp-node uses avahi

Hi, everyone,
I've been doing development guided by the test-nmos-is0405 script Riedel has shared, and the trunk (as of 91750507f34) fails IS-04 test 10, "Node advertises a Node type mDNS announcement with no ver_* TXT records in the presence of a Registration API", at least when test-nmos-is0405 is built using avahi. The error message from the test is "No matching mdns announcement found for node."
I've looked at it with the DNS-SD browser provided by avahi, and the records are very strange. nmos-cpp_node_ip-address:port is displayed in the browser, but when I select it, the only thing the browser eventually shows is a "timeout reached" message. By comparison, the RDS shows a DNS record with a bunch of information, including a couple of TXT records.
Has anyone else run these tests against nmos-cpp-node? Do you see the same behavior, and are you running avahi or mdnsbridge?
Thanks,
Bill

Thanks for the report - coincidently we had scheduled to look at the test-nmos-is0405 scripts this week, so it's good timing.
How have you built/run nmos-cpp-node - with dns_sd.h and libdns_sd.so from mdnsResponder with its mdnsd daemon or the compatibility versions from libavahi-compat-libdnssd?

nmos-cpp_node_ip-address:port is displayed in the browser

Well, I guess that's a start, that is the default naming style used by nmos-cpp-node for its service instance.

but when I select it, the only thing the browser eventually shows is a "timeout reached" message.

That sounds like an Avahi/mdnsResponder interop issue, but we will investigate here.

By comparison, the RDS shows a DNS record with a bunch of information, including a couple of TXT records.

Are you using nmos-cpp-registry, the BBC registry or another one?
Thanks.

I'm using libavahi's compatibility library. I'm using the BBC registry image that they published early this year -- I tried the vagrant image but kept being stymied fairly late in the boot-up process. I haven't tried it against nmos-cpp-registry lately.

Hi Bill,
We've just tried the tests on nmos-cpp-node with nmos-cpp-registry, under Ubuntu 14.04 (64-bit), first built with mdnsResponder and mdnsd, and then built with libavahi-compat-libdnssd-dev and avahi-daemon. All the automatic IS-04 tests pass, including test 10.
I would believe that using a different registry would cause different results for some tests, but hopefully not for test 10. I would also hope that the difference is not Ubuntu 14.04 vs. 16.04 or 64-bit vs. 32-bit. There must be something else different in the setup that is causing failures for you, but I'm not sure what to suggest investigating next.

My machine is 64-bit as well.
In any event, I'm still in the duct tape and bailing wire stage, so I don't need to pursue this test any further in my environment.
Thanks for looking into it.

Hi Bill,
I'm happy to keep this open, as I am tracking differences/interop issues between the various DNS-SD implementations on each platform.
One thing: can you tell me what the host-name of your machine is, and whether you are specifying it explicitly when launching nmos-cpp-node (like nmos-cpp-node "{\"host_name\":\"foo\"}") or not?
Thanks!

Hi, Gareth,
The machine's hostname is "hobbes", but I'm setting it to "D13_04204" (or somesuch) on the command line.
Also, I realized I have a 32-bit chroot lying around. I rebuilt nmos-node-cpp using it and still see the problem. So, it's not a 32-bit node program (although avahi-daemon is still 64-bit, of course).

The machine's hostname is "hobbes", but I'm setting it to "D13_04204" (or somesuch) on the command line.

Is it possible you could try it without specifying the host name?

That fixes it! I'm only setting the host name for testing purposes anyhow, so this problem shouldn't impact my work in the long term.
Thanks!

I've finally managed to run these tests based on our compilation - I can confirm that using the container version of nmos-cpp compiled with Avahi works fine against the Riedel tests. Specifically test 10 passed correctly.

That fixes it! I'm only setting the host name for testing purposes anyhow, so this problem shouldn't impact my work in the long term.

In this case the host name also needs a name record. It might work putting your test name in your /etc/hosts file. I think we have used this configuration to override the host name for Mininet virtual hosts.

With two recent commits, 600bf053aeb028b716d424943babb07eabf4ced5 and a29d232c7bbe30b22ce95493353a35ef04289f6f, nmos-cpp will now attempt to register the .local address record(s) when a hostname is specified explicitly on the command line. This works when built with when built with mDNSResponder/Bonjour, but the Avahi compatibility layer unfortunately doesn't implement this functionality. However, using avahi-publish -a before starting the node seems to work in that case.
I.e., @billt-hlit

The machine's hostname is "hobbes", but I'm setting it to "D13_04204" (or somesuch) on the command line.

Something like this should work...
avahi-publish -a -R D13_04204 `hostname -I`
nmos-cpp-node "{\"host_name\": \"D13_04204\"}"

Also, when using Avahi, in order that .local addresses can be looked up by nmos-cpp nodes, it's important that the Name Service Switch uses Avahi to resolve .local names. The magic in /etc/nsswitch.conf is to have a hosts stanza like so:
hosts:          files mdns4_minimal [NOTFOUND=return] dns

Hi, I'm facing a problem that I think is related to this topic.
I'm using an nmos register instance one one machine and I have a node one a different device that is trying to register things on the register api of the first device. I'm using avahi layer so far.
the problem is that I'm able to see and resolve the advertisement of the registration device:
avahi-browse -r _nmos-query._tcp

eth0 IPv4 nmos-cpp_query_10-232-21-63:3211              _nmos-query._tcp     local
=   eth0 IPv4 nmos-cpp_query_10-232-21-63:3211              _nmos-query._tcp     local
hostname = [ultritouch.local]
address = [<IP_ADDRESS>]
port = [3211]
txt = ["pri=0" "api_ver=v1.0,v1.1,v1.2,v1.3" "api_proto=http"]

avahi-browse -r _nmos-register._tcp

eth0 IPv4 nmos-cpp_registration_10-232-21-63:3210       _nmos-register._tcp  local
eth0 IPv4 registration_10-232-20-25_http                _nmos-register._tcp  local
=   eth0 IPv4 nmos-cpp_registration_10-232-21-63:3210       _nmos-register._tcp  local
hostname = [ultritouch.local]
address = [<IP_ADDRESS>]
port = [3210]
txt = ["pri=0" "api_ver=v1.0,v1.1,v1.2,v1.3" "api_proto=http"]

but when I instantiate the node application, it complains that it could not find any IP address for the specified hostname.
1970-01-01 00:33:02.124: more info:<PHONE_NUMBER>: After DNSServiceBrowse, DNSServiceBrowseReply got service: nmos-cpp_registration_10-232-21-63:3210 for regtype: _nmos-register._tcp. domain: local. on interface: 2
1970-01-01 00:33:02.126: more info:<PHONE_NUMBER>: DNSServiceResolve for name: nmos-cpp_registration_10-232-21-63:3210 regtype: _nmos-register._tcp. domain: local. on interface: 2
1970-01-01 00:33:02.128: too much info:<PHONE_NUMBER>: After DNSServiceBrowse, DNSServiceProcessResult succeeded
1970-01-01 00:33:02.128: more info:<PHONE_NUMBER>: After DNSServiceBrowse, DNSServiceBrowseReply got service: nmos-cpp_registration_10-232-21-63:3210 for regtype: _nmos-registration._tcp. domain: local. on interface: 2
1970-01-01 00:33:02.129: more info:<PHONE_NUMBER>: DNSServiceResolve for name: nmos-cpp_registration_10-232-21-63:3210 regtype: _nmos-registration._tcp. domain: local. on interface: 2
1970-01-01 00:33:02.140: too much info:<PHONE_NUMBER>: After DNSServiceResolve, DNSServiceProcessResult succeeded
1970-01-01 00:33:02.140: too much info:<PHONE_NUMBER>: After DNSServiceResolve, DNSServiceProcessResult succeeded
1970-01-01 00:33:02.152: too much info:<PHONE_NUMBER>: After DNSServiceResolve, DNSServiceProcessResult succeeded
1970-01-01 00:33:02.587: too much info:<PHONE_NUMBER>: After DNSServiceResolve, DNSServiceProcessResult succeeded
1970-01-01 00:33:02.588: more info:<PHONE_NUMBER>: After DNSServiceResolve, DNSServiceResolveReply got host: ultritouch.local. port: 3210
1970-01-01 00:33:02.588: more info:<PHONE_NUMBER>: getaddrinfo for hostname: ultritouch.local.
1970-01-01 00:33:02.591: more info:<PHONE_NUMBER>: Using getaddrinfo, got no addresses for host: ultritouch.local.
it looks like the application is trying to resolve the hostname in order to find the IP address. I'm wondering why does it need to resolve the hostname for a second time if the IP address is something that is already provided by the mdns when the service is resolved.
thanks for your time on this.
Tassiano

it looks like the application is trying to resolve the hostname in order to find the IP address. I'm wondering why does it need to resolve the hostname for a second time if the IP address is something that is already provided by the mdns when the service is resolved.

Although avahi-browse shows the resolve step as returning hostname and IP address at the same time, it's actually two different DNS records - and two different API calls in the dns_sh.h API, DNSServiceResolve and DNSServiceGetAddrInfo. Unfortunately the Avahi implementation doesn't support the second of those, so we use their recommended workaround which is the system call getaddrinfo, instead. That's what we see in your log.
Do you have the /etc/nsswitch.conf magic mentioned above in https://github.com/sony/nmos-cpp/issues/10#issuecomment-404886096?

Do you have the /etc/nsswitch.conf magic mentioned above in #10 (comment)?

yes.
cat /etc/nsswitch.conf
passwd:         files
group:          files
shadow:         files
hosts:          files mdns4_minimal [NOTFOUND=return] dns mdns4
networks:       files dns
protocols:      files
services:       files
ethers:         files
rpc:            files
if instead of using avahi layer I use the mdnsresolver, the step of resolving the hostname using //getaddrinfo// would be bypassed and the use of the //DNSServiceGetAddrInfo// would be used instead? meaning that the hostname resolution would not be required at this point.

if instead of using avahi layer I use the mdnsresolver, the step of resolving the hostname using //getaddrinfo// would be bypassed and the use of the //DNSServiceGetAddrInfo// would be used instead?

Yes.

I've replaced avahi by the mdnsd with the patches available inside this repo, but now I'm on a situation where the application dont seems to even try to find the registration:
1970-01-01 00:08:39.770: info:<PHONE_NUMBER>: Starting nmos-cpp node
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Process ID: 1165
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Initial settings: {"connection_port":8856,"host_address":"<IP_ADDRESS>","host_addresses":["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"],"log_level":-40,"node_port":12345,"seed_id":"d1b96a18-4dd1-4c02-bd79-a0f68de37b6c"}
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Configuring nmos-cpp node with its primary Node API at: <IP_ADDRESS>:12345
1970-01-01 00:08:39.847: info:<PHONE_NUMBER>: NmosIS05ActivatorClient initialized. ret 0
1970-01-01 00:08:39.848: info:<PHONE_NUMBER>: NODE IS05 thread waiting
1970-01-01 00:08:39.855: info:<PHONE_NUMBER>: Preparing for connections
is there anything else that I'm missing, maybe on the configuration file?
thanks!

Further info:
Started        0:04:14.268016
End            0:04:18.585656
Captured for   0:00:04.317640
Unique source addresses seen on network: 1 (IPv4)

Modern Query        Packets:          382   (avg 5309/min)
Legacy Query        Packets:            0   (avg    0/min)
Multicast Response  Packets:            0   (avg    0/min)
Total     Multicast Packets:          382   (avg 5309/min)

Total New Service Probes:             729   (avg10132/min)
Total Goodbye Announcements:            0   (avg    0/min)
Total Query Questions:                789   (avg10965/min)
Total Queries from Legacy Clients:      0   (avg    0/min)
Total Answers/Announcements:            0   (avg    0/min)
Total Additional Records:               0   (avg    0/min)

Service Type             Total Ops   Probe   Goodbye  BrowseQ  BrowseA ResolveQ ResolveA
_rtsp._tcp.                   460        0        0        0        0      460        0
_http._tcp.                   106        0        0       14        0       92        0
_nmos-register._tcp.           69        0        0       23        0       46        0
_nmos-registration._tcp.       54        0        0        8        0       46        0
_nmos-query._tcp.              30        0        0        7        0       23        0
_sftp-ssh._tcp.                25        8        0        0        0       17        0
_ssh._tcp.                      8        8        0        0        0        0        0
_nmos-node._tcp.                8        8        0        0        0        0        0
_smb._tcp.                      7        0        0        0        0        7        0
_dns-sd._udp.                   7        0        0        7        0        0        0

Source Address           Total Ops   Probe   Goodbye  BrowseQ  BrowseA ResolveQ ResolveA    Pkts    Query   LegacyQ Response
<IP_ADDRESS>                  774       24        0       59        0      691        0      382      382        0        0
buildroot-13.local.                           ARMV7L         LINUX
mDNSPosix.c:mDNSPlatformSetAllowSleep(): NOT IMPLEMENTED!
mDNSPosix.c:mDNSPlatformSetAllowSleep(): NOT IMPLEMENTED!
mDNSPosix.c:mDNSPlatformSetAllowSleep(): NOT IMPLEMENTED!
mDNSPosix.c:mDNSPlatformSetAllowSleep(): NOT IMPLEMENTED!
mDNS_FinalExit: RR Cache was using 0 records, 0 active

its seems that the MDNS is working although the traffic seems quite intense.
thanks

I've replaced avahi by the mdnsd with the patches available inside this repo, but now I'm on a situation where the application dont seems to even try to find the registration:
1970-01-01 00:08:39.770: info:<PHONE_NUMBER>: Starting nmos-cpp node
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Process ID: 1165
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Initial settings: {"connection_port":8856,"host_address":"<IP_ADDRESS>","host_addresses":["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"],"log_level":-40,"node_port":12345,"seed_id":"d1b96a18-4dd1-4c02-bd79-a0f68de37b6c"}
1970-01-01 00:08:39.774: info:<PHONE_NUMBER>: Configuring nmos-cpp node with its primary Node API at: <IP_ADDRESS>:12345
1970-01-01 00:08:39.847: info:<PHONE_NUMBER>: NmosIS05ActivatorClient initialized. ret 0
1970-01-01 00:08:39.848: info:<PHONE_NUMBER>: NODE IS05 thread waiting
1970-01-01 00:08:39.855: info:<PHONE_NUMBER>: Preparing for connections
is there anything else that I'm missing, maybe on the configuration file?
thanks!

My bad. For some reason I've reverted the /etc/nsswitch.conf;
now with the line:
hosts:          files mdns4_minimal [NOTFOUND=return] dns
the system seems to attempt to locate the service, but it can't still:
1970-01-01 00:02:04.920: info:<PHONE_NUMBER>: Starting nmos-cpp node
1970-01-01 00:02:04.924: info:<PHONE_NUMBER>: Process ID: 595
1970-01-01 00:02:04.925: info:<PHONE_NUMBER>: Initial settings: {"connection_port":8856,"host_address":"<IP_ADDRESS>","host_addresses":["<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>","<IP_ADDRESS>"],"log_level":-40,"node_port":12345,"seed_id":"fdba1e45-9fce-464f-9e71-d40846873a71"}
1970-01-01 00:02:04.925: info:<PHONE_NUMBER>: Configuring nmos-cpp node with its primary Node API at: <IP_ADDRESS>:12345
1970-01-01 00:02:04.998: info:<PHONE_NUMBER>: NmosIS05ActivatorClient initialized. ret 0
1970-01-01 00:02:04.998: info:<PHONE_NUMBER>: NODE IS05 thread waiting
1970-01-01 00:02:05.008: info:<PHONE_NUMBER>: Preparing for connections
1970-01-01 00:02:05.017: info:<PHONE_NUMBER>: Ready for connections
1970-01-01 00:02:05.065: info:<PHONE_NUMBER>: Registered advertisement for: nmos-cpp_node_192-168-12-30:12345._nmos-node._tcp
1970-01-01 00:02:05.077: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:02:06.078: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:02:06.079: info:<PHONE_NUMBER>: Adopting peer-to-peer operation
1970-01-01 00:02:07.080: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:02:37.102: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:02:38.102: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:03:08.130: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:03:09.131: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:03:39.160: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:03:40.161: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:04:10.190: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:04:11.191: info:<PHONE_NUMBER>: Attempting discovery of a Registration API
1970-01-01 00:04:41.221: warning:<PHONE_NUMBER>: Did not discover a suitable Registration API via DNS-SD
1970-01-01 00:04:42.222: info:<PHONE_NUMBER>: Attempting discovery of a Registration API

Sorry for the noise here guys, I found the source of my problem: my manual installation of the mdnsresolver was missing one part and in one of my tests the libdns_sd.so used on the target was correct (generated from the mdns repo), but the .so used on the compilation phase of my node was pointing to the one generated by avahi.
now everything seems to work as expected. thanks!!

That's very good news. I've had the problem of a confused avahi-mdnsResponder system myself. Glad you got it working!


Support for AutoScaling?

How difficult would i be to create a module for polling and auditing autoscaling configurations?
I plan on creating this but am not sure where to start.
There will need to be a new watcher for autoscaling and a new auditor. Is the best way to start by creating a new watcher based off of the others but trying to poll for autoscale configs?
No rush, any help would be appreciated.
Thanks

Shouldn't be too difficult.
You could start off with a new watcher and leave the auditor for later.  Look at sns/sqs/ses for some simple examples.
I'll help you out if you get stuck.
What kind of audit checks do you have in mind?

I'm looking to alert on AutoScaling groups that have no instances assigned to them.  My lack of AWS API knowledge is causing me some trouble. Using the other watchers as a rough template I so far have
=======================================================================
from security_monkey.watcher import Watcher
from security_monkey.watcher import ChangeItem
from security_monkey.constants import TROUBLE_REGIONS
from security_monkey.exceptions import InvalidARN
from security_monkey.exceptions import InvalidAWSJSON
from security_monkey.exceptions import BotoConnectionIssue
from security_monkey import app
import json
import re
from boto.sns import regions
class AutoScaling(Watcher):
index = 'AutoScaling'
i_am_singular = 'AutoScaling Topic Policy'
i_am_plural = 'AutoScaling Topic Policies'
def __init__(self, accounts=None, debug=False):
    super(AutoScaling, self).__init__(accounts=accounts, debug=debug)

def slurp(self):
    """
    :returns: item_list - list of AutoScaling Item's.
    :returns: exception_map - A dict where the keys are a tuple containing the
        location of the exception and the value is the actual exception

    """
    self.prep_for_slurp()

    item_list = []
    exception_map = {}
    for account in self.accounts:
        for region in regions():
            try:
                (autoscaling, topics) = self.get_all_topics_in_region(account, region)
            except Exception as e:
                if region.name not in TROUBLE_REGIONS:
                    exc = BotoConnectionIssue(str(e), 'autoscaling', account, region.name)
                    self.slurp_exception((self.index, account, region.name), exc, exception_map)
                continue

            app.logger.debug("Found {} {}".format(len(topics), AutoScaling.i_am_plural))
            for topic in topics:
                arn = topic['TopicArn']

                if self.check_ignore_list(arn):
                    continue

                item = self.build_item(arn=arn,
                                       conn=autoscaling,
                                       region=region.name,
                                       account=account,
                                       exception_map=exception_map)
                if item:
                    item_list.append(item)
    return item_list, exception_map

def get_all_topics_in_region(self, account, region):
    from security_monkey.common.sts_connect import connect
    autoscaling = connect(account, 'autoscaling', region=region)
    app.logger.debug("Checking {}/{}/{}".format(AutoScaling.index, account, region.name))
    topics = []
    marker = None
    while True:
        topics_response = self.wrap_aws_rate_limited_call(
            autoscaling.get_all_topics,
            next_token=marker
        )
        current_page_topics = topics_response['ListTopicsResponse']['ListTopicsResult']['Topics']
        topics.extend(current_page_topics)
        if topics_response[u'ListTopicsResponse'][u'ListTopicsResult'][u'NextToken']:
            marker = topics_response[u'ListTopicsResponse'][u'ListTopicsResult'][u'NextToken']
        else:
            break
    return autoscaling, topics

def _get_topic_subscriptions(self, autoscaling, arn):
    # paginate over each topic subscription
    token = None
    all_subscriptions = []
    while True:
        subscriptions = self.wrap_aws_rate_limited_call(
        subscriptions = self.wrap_aws_rate_limited_call(
            autoscaling.get_all_subscriptions_by_topic,
            arn,
            next_token=token
        )
        all_subscriptions.extend(
            subscriptions['ListSubscriptionsByTopicResponse']['ListSubscriptionsByTopicResult']['Subscriptions']
        )
        token = subscriptions['ListSubscriptionsByTopicResponse']['ListSubscriptionsByTopicResult']['NextToken']
        if token is None:
            break
    return all_subscriptions

def _get_autoscaling_policy(self, attrs, account, region, arn, exception_map):
    try:
        json_str = attrs['GetTopicAttributesResponse']['GetTopicAttributesResult']['Attributes']['Policy']
        return json.loads(json_str)
    except:
        self.slurp_exception((self.index, account, region, arn), InvalidAWSJSON(json_str), exception_map)
        raise

def _get_autoscaling_name(self, arn, account, region, exception_map):
    try:
        return re.search('arn:aws:autoscaling:[a-z0-9-]+:[0-9]+:([a-zA-Z0-9-]+)', arn).group(1)
    except:
        self.slurp_exception((self.index, account, region, arn), InvalidARN(arn), exception_map)
        raise

def build_item(self, arn=None, conn=None, region=None, account=None, exception_map={}):
    config = {}

    try:
        attrs = self.wrap_aws_rate_limited_call(
            conn.get_topic_attributes,
            arn
        )

        config['subscriptions'] = self._get_topic_subscriptions(conn, arn)
        config['policy'] = self._get_autoscaling_policy(attrs, account, region, arn, exception_map)
        config['name'] = self._get_autoscaling_name(arn, account, region, exception_map)
    except:
        return None
    return AutoScalingItem(region=region, account=account, name=config['name'], config=config)

class AutoScalingItem(ChangeItem):
def init(self, region=None, account=None, name=None, config={}):
super(AutoScalingItem, self).init(
index=AutoScaling.index,
region=region,
account=account,
name=name,
new_config=config)
=======================================================================
However running " python manage.py find_changes -a all -m AutoScaling" Is throwing the error "'Problem Connecting to autoscaling/Dev-Test/us-east-1:\nThe connection_type supplied (autoscaling) is not implemented.'
Adding ('AutoScaling', u'Dev-Test', u'us-east-1') to the exceptions list. Exception was: 'Problem Connecting to autoscaling/Dev-Test/us-east-1:\nThe connection_type supplied (autoscaling) is not implemented.'"
I have also added the new watcher to "monitors.py" with the None attribute for an auditor for now

I am still getting "Problem Connecting to autoscale/Dev-Test/sa-east-1:\n'module' object has no attribute 'autoscale'" But am not sure why.
->security_monkey.common.sts_connect
if connection_type == 'autoscale':
if 'region' in args:
region = args['region']
del args['region']
else:
region = 'us-east-1'
    return boto.ec2.autoscale.connect_to_region(
        region,
        aws_access_key_id=role.credentials.access_key,
        aws_secret_access_key=role.credentials.secret_key,
        security_token=role.credentials.session_token,
        **args)

--> security_monkey_watchers.autoscale
for region in regions:
app.logger.debug("Checking {}/{}/{}".format(self.index, account, region.name))
            try:
                rec2 = connect(account, 'autoscale', region=region)
                autoscale_groups = self.wrap_aws_rate_limited_call(
                    rec2.get_all_groups
                )
                # Retrieve account tags to later match assigned EIP to instance
                tags = self.wrap_aws_rate_limited_call(
                    rec2.get_all_tags
                )

Trying to copy the ELB watcher but use the AWS API to get all current Autoscaling groups. I want to check each group for assigned instances (but that will be the auditor's job...need to get the watcher working first)

Okay. I'm really close. I just can't get the right API call to get the autoscale group details.
I'm looking for this JSON output from the describe autoscaling group CLI command - > http://docs.aws.amazon.com/cli/latest/reference/autoscaling/describe-auto-scaling-groups.html
Then I can just check if instances has content.
Currently I'm using
60             for region in regions:
61                 try:
62                     autoscale = connect(account, 'autoscale')
63                     autoscale_groups = self.wrap_aws_rate_limited_call(
64                         autoscale.get_all_groups
65                     )
66                     # Retrieve account tags to later match assigned EIP to instance
67                     tags = self.wrap_aws_rate_limited_call(
68                         autoscale.get_all_tags
69                     )
70                 except Exception as e:
71                     if region.name not in TROUBLE_REGIONS:
72                         exc = BotoConnectionIssue(str(e), self.index, account, region.name)
73                         self.slurp_exception((self.index, account, region.name), exc, exception_map)
74                     continue
autoscale.get_all_groups just returns [AutoScaleGroup] But I need more details like in the link above.
Any ideas? I'm slowly learning the inning workings of security monkey :)

This looks promising.
To play with the AutoScaleGroup object, I typically do this:
from ipython import embed
embed()

Which will drop you into an interactive shell when it reaches that bit of code.  (Run python manage.py find_changes -m autoscaling, adjusting for the spelling you chose for the index.)
Then you can use ipython to run dir against the object and use tab completion to see what instance variables, properties, and methods are available.
If you have forked security_monkey and pushed your autoscaling code up to your own repo, let me know and I'll use that to play.

Thank you so much!
The ability to tab complete the API functions is exactly what I needed. I did not know about being able to use ipython to embed a shell...that's going to be super handy in the future.
And currently it's in a private fork but I may consider opening it once I get all the features I want in it

Watcher is working :) Time to start on the auditor. The hard part was checking autoscale group for launch configs then for security groups designations in the launch config.
ipython embed() was a life saver.
Thanks monkeysecurity!


[Feature] Add a create transfer endpoint

🚀 Feature
Expose create_transfer endpoint on the beacon node that receives the private key of the sender, the recipient, an amount of credits to send and performs the transfer on chain.
Motivation
This is necessary to implement transfers in the wallet.

the official should not provide, this only can used in private env and local full node, because it is not security and privacy

Agreed, it is not secure or private.


Add a Test Suite for the Project Itself

It would be nice to have an automated test script to run all the challenges against their solution code to verify the solutions are passing. This could be setup using jest and probably would not be very difficult to create since all the challenges export their test function and their solution code.

Nope.


Note the requirement to install openapi-gen from the vendor tree

This was missed when the openapi generators were merged, and a few
people have hit this issue recently.
Signed-off-by: Kyle Mestery<EMAIL_ADDRESS>

As I noted @pkdas, please look here for the documentation fix.


Dont mutate type node during completions of parameters with type 'any'

fix https://github.com/microsoft/pxt-minecraft/issues/2094
When a symbol with 'any' type had a default value, this was mutating parameter node / changing it from any to the type of the default value. So in minecraft, currently player.say's block can take numbers / any, but if you switch to typescript and happen to get a completion generated for player.say the apiInfo will get changed / the block will no longer accept numbers or other values until you refresh.

Add a test? Also what change regressed this?

https://github.com/microsoft/pxt/pull/7322, I'll see about adding a test - a bit tricky / might require adding more to the language-service tests to be able to check something like this, as currently they just check the completions that get outputted.


Change bs-platform from master to current release

I would say yes to this. We do not depends on BS specific stuff too much, we don't need to use the master branch.

Thanks!


ViT and BYOL runtime error during training

I've copied and pasted the same code in the README for Self-Supervised training and it comes out with this error
Traceback (most recent call last):
  File "train_scratch_byol.py", line 18, in <module>
    hidden_layer = 'to_latent'
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/site-packages/byol_pytorch/byol_pytorch.py", line 210, in __init__
    self.forward(torch.randn(2, 3, image_size, image_size, device=device))
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/site-packages/byol_pytorch/byol_pytorch.py", line 240, in forward
    target_encoder = self._get_target_encoder() if self.use_momentum else self.online_encoder
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/site-packages/byol_pytorch/byol_pytorch.py", line 27, in wrapper
    instance = fn(self, *args, **kwargs)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/site-packages/byol_pytorch/byol_pytorch.py", line 214, in _get_target_encoder
    target_encoder = copy.deepcopy(self.online_encoder)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 180, in deepcopy
    y = _reconstruct(x, memo, *rv)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 281, in _reconstruct
    state = deepcopy(state, memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 150, in deepcopy
    y = copier(x, memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 241, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 150, in deepcopy
    y = copier(x, memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 241, in _deepcopy_dict
    y[deepcopy(key, memo)] = deepcopy(value, memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/copy.py", line 161, in deepcopy
    y = copier(memo)
  File "/usr/local/Caskroom/miniconda/base/envs/thesis_proposal/lib/python3.7/site-packages/torch/tensor.py", line 47, in __deepcopy__
    raise RuntimeError("Only Tensors created explicitly by the user "
RuntimeError: Only Tensors created explicitly by the user (graph leaves) support the deepcopy protocol at the moment

@suarezjessie Hi! Could you paste me the full script so I can reproduce this error?

@suarezjessie I may have introduced a bug in the latest commit to BYOL, do you want to give 0.5.4 of byol-pytorch a try?

@lucidrains used the 0.5.4 version and it works like a charm! Thanks!


Add support for BenchmarkDotNet

This is a rebased version of #34, so all credit goes to baronfel
I went ahead and updated the supported tools in the README and action.yml file as well. Let me know if there are any other changes you'd like me to make. What should I do about the broken benchmarkdotnet badge images?

Oh nice, thanks for doing this rebase!

@baronfel sure thing!

Fixed the compiler errors and ran the tests (they all pass now).

Thanks @cabauman for fixing the  issues. I'll  have a look at the changes over the weekend

Changes made! Let me know if you find anything else.

PR looks great! Please just run npm run format to fix the linting issues

Oops. Yes, of course.


MAUI images not cross-platform on Windows?

On this page, in the "Draw an Image" section, there is a notation that PlatformImage is not supported on Windows.  It seems crazy to have a "Multi-Platform Application UI", from Microsoft, that supports all platforms except Microsoft Windows.
I've asked this before, but I was hoping, with the release of .NET 7, that this might have changed. However, it appears it is still an issue.
Am I really forced to write platform-specific code for something as simple as drawing an image on a canvas? Is there even a way to do this on Windows?
Any idea if/when there will be a mechanism for drawing images on a canvas that is truly multi-platform?
It seems this should be slightly embarrassing for Microsoft...that an example in their documentation has to explicitly exclude their own operating system.
For further examples of the havoc this causes, I direct you to the following page: .NET MAUI / Graphics / Images.
The many, many notes/warnings about the incompatibilities inherent in MAUI image handling reinforce the impression that MAUI is "not ready for prime time". I honestly hope this impression, and the delays resolving it, won't negatively impact its future.
Thanks in advance for your time.

Document Details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 0ca86947-204f-9c45-223d-724fb59b4938
Version Independent ID: 0ca86947-204f-9c45-223d-724fb59b4938
Content: Draw graphical objects - .NET MAUI
Content Source: docs/user-interface/graphics/draw.md
Product: dotnet-mobile
Technology: dotnet-maui
GitHub Login: @davidbritch
Microsoft Alias: dabritch

Hi @techfan101
I hear you and I agree. There have been multiple attempts to fix this issue (see https://github.com/dotnet/Microsoft.Maui.Graphics/pull/464 and https://github.com/dotnet/maui/pull/9948) but it didn't make it in for .NET 7.
I've sent a message to the engineers to find out how/when this will get resolved. I'll get back to you when I know more.

Thank you for trying @davidbritch. I really do appreciate it. I hope the response is positive.
However, I already waited 6 months for a fix in .NET 7. From the discussion, it looks like we're waiting another year for a fix in .NET 8 (best case). And, I'm not even counting how long I waited for MAUI to hit GA in the first place.
Drawing an image is about as basic as it gets for a UI. I can't believe it takes a year and a half to rename a couple of classes and interfaces. That's crazy!
Basic issues like this coupled with the ever-growing backlog are creating a bad impression in the development community. At this pace, MAUI will fail. It will certainly be great when it's done, but there will be no one left waiting to use it.
I hope Microsoft adds more resources to the project (if that's the problem).
For my part, I started transitioning future development to Flutter. I guess I'll continue along that path, which is heartbreaking.
I genuinely wanted MAUI to succeed. I prefer C# to Dart and VS Pro to VS Code, but I guess it's time to move on.
Maybe I'll check back, in another 6 months, to see if the situation has improved or continues to deteriorate. I might still have one final opportunity to try a project in MAUI :)
Best of luck and thanks again for trying.

Hi @techfan101
The engineers have created a new PR to fix this issue: https://github.com/dotnet/maui/pull/12104
But you may be right as to the release in which this will land.