macos 运行demo报错

2024-06-29 10:35:35,039 - main - INFO: Call symbol "__ZL9protocolsv"
2024-06-29 10:35:35,039 - main - INFO: Start emulate at libobjc.A.dylib!0x1947fb630
2024-06-29 10:35:35,051 - main - INFO: Call symbol "__objc_init"
2024-06-29 10:35:35,052 - main - INFO: Start emulate at libobjc.A.dylib!0x19480ae0c
Traceback (most recent call last):
File "/Users/kingking/Working/PycharmWorkPlace/reverse/IOS/chomper/examples/example_ios_bangbang.py", line 48, in
main()
File "/Users/kingking/Working/PycharmWorkPlace/reverse/IOS/chomper/examples/example_ios_bangbang.py", line 21, in main
emu = Chomper(
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/core.py", line 98, in init
self.os.initialize()
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/os/ios/os.py", line 293, in initialize
self._enable_objc()
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/os/ios/os.py", line 259, in _enable_objc
self.resolve_modules(dependencies)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/os/ios/os.py", line 230, in resolve_modules
self.init_objc(module)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/os/ios/os.py", line 156, in init_objc
self._init_objc_vars()
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/os/ios/os.py", line 140, in _init_objc_vars
self.emu.call_symbol("__objc_init")
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/core.py", line 745, in call_symbol
return self._start_emulate(address, *args)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate
self.uc.emu_start(address, stop_addr)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/unicorn/unicorn.py", line 550, in emu_start
raise self._hook_exception
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/unicorn/unicorn.py", line 392, in wrapper
return func(self, *args, **kwargs)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/unicorn/unicorn.py", line 681, in _hook_intr_cb
cb(self, intno, data)
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/core.py", line 439, in _interrupt_callback
AutomicInstruction(self, code).execute()
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/chomper/instruction.py", line 19, in init
self._inst = next(self.emu.cs.disasm_lite(code, 0))
File "/Users/kingking/opt/anaconda3/envs/reverse/lib/python3.8/site-packages/capstone/init.py", line 1077, in disasm_lite
res = _cs.cs_disasm(self.csh, code, len(code), offset, count, ctypes.byref(all_insn))
ctypes.ArgumentError: argument 2: <class 'TypeError'>: wrong type

这个是 captsone 版本的问题，你现在应该是 4.x ，可以升级到 5.x 。

Installing collected packages: capstone
Attempting uninstall: capstone
Found existing installation: capstone 4.0.1
Uninstalling capstone-4.0.1:
Successfully uninstalled capstone-4.0.1
Successfully installed capstone-5.0.1
可以正常跑起来了，但是最后还是报了错

lief 这个库的版本也需要升到 14.0.1 。

Installing collected packages: lief
Attempting uninstall: lief
Found existing installation: lief 0.13.2
Uninstalling lief-0.13.2:
Successfully uninstalled lief-0.13.2
Successfully installed lief-0.14.1
非常感谢大佬指导，终于跑起来了

报错了版本都是你指定的那些版本
2024-07-10 14:07:31,836 - main - INFO: Load module "TextInput"
2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_MGCopyAnswer" at 0x1d20560a0
2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_calloc" at 0x1d2056170
2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_dispatch_async" at 0x1d2056190
2024-07-10 14:07:34,399 - main - INFO: Call symbol "_map_images"
2024-07-10 14:07:34,399 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-07-10 14:07:34,476 - main - INFO: Call symbol "_load_images"
2024-07-10 14:07:34,477 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac
2024-07-10 14:07:34,480 - main - INFO: Load module "PhysicsKit"
2024-07-10 14:07:34,972 - main - INFO: Call symbol "_map_images"
2024-07-10 14:07:34,972 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-07-10 14:07:34,983 - main - INFO: Call symbol "_load_images"
2024-07-10 14:07:34,984 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac
2024-07-10 14:07:34,985 - main - INFO: Load module "CoreAutoLayout"
2024-07-10 14:07:35,276 - main - INFO: Hook import symbol "_calloc" at 0x1d3d3fa00
2024-07-10 14:07:35,277 - main - INFO: Hook import symbol "_malloc_good_size" at 0x1d3d3fa50
2024-07-10 14:07:35,352 - main - INFO: Call symbol "_map_images"
2024-07-10 14:07:35,353 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-07-10 14:07:35,372 - main - INFO: Call symbol "_load_images"
2024-07-10 14:07:35,373 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac
2024-07-10 14:07:35,374 - main - INFO: Load module "UIFoundation"
2024-07-10 14:07:36,581 - main - INFO: Hook import symbol "_calloc" at 0x1d296b018
2024-07-10 14:07:36,581 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x1d296b2b0
2024-07-10 14:07:36,582 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x1d296b2c0
2024-07-10 14:07:36,867 - main - INFO: Call symbol "_map_images"
2024-07-10 14:07:36,868 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-07-10 14:07:36,926 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28
2024-07-10 14:07:36,927 - main - INFO: State: x0: 0x00000001da4b1da8 [libc++abi.dylib!0x1b928bda8], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x0000000000077e98, x4: 0x0000000000000000, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x0000000000000000, x8: 0x0000000000000000, x9: 0x0000000000000000, x10: 0x0000000008150000, x11: 0x0000000000002000, x12: 0x0000000000001fff, x13: 0x0000000000000fbf, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000001, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x0000000821a9d1a0 [UIFoundation!0x1d9a681a0], x20: 0x0000000000000000, x21: 0x00000008224e6878 [UIFoundation!0x1da4b1878], x22: 0x0000000821a9d1c0 [UIFoundation!0x1d9a681c0], x23: 0x0000000000000000, x24: 0x00000002afe30ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x000000081a9b3cf0 [UIFoundation!0x1d297ecf0], x26: 0x0000000000000000, x27: 0x0000000000000069, x28: 0x0000000821a9d1a0 [UIFoundation!0x1d9a681a0], x29: 0x0000000000077ec0, x30: 0x00000002afe0f140 [libobjc.A.dylib!0x1947f9140]
2024-07-10 14:07:36,927 - main - ERROR: Initialize Objective-C failed.
2024-07-10 14:07:36,927 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 210, in _start_emulate
self.uc.emu_start(address, stop_addr)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/unicorn/unicorn.py", line 547, in emu_start
raise UcError(status)
unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/os/ios/os.py", line 176, in init_objc
self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 745, in call_symbol
return self._start_emulate(address, *args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 215, in _start_emulate
self.crash("Unknown reason", from_exc=e)
File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 381, in crash
raise EmulatorCrashedException(message) from from_exc
chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140
2024-07-10 14:07:36,930 - main - INFO: Load module "UIKitServices"
2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_MGCopyAnswer" at 0x1d210a1a8
2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_dispatch_async" at 0x1d210a218
2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x1d210a2a8
2024-07-10 14:07:37,214 - main - INFO: Call symbol "_map_images"
2024-07-10 14:07:37,214 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-07-10 14:07:37,225 - main - INFO: Call symbol "_load_images"
2024-07-10 14:07:37,226 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac

报错了版本都是你指定的那些版本 2024-07-10 14:07:31,836 - main - INFO: Load module "TextInput" 2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_MGCopyAnswer" at 0x1d20560a0 2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_calloc" at 0x1d2056170 2024-07-10 14:07:34,184 - main - INFO: Hook import symbol "_dispatch_async" at 0x1d2056190 2024-07-10 14:07:34,399 - main - INFO: Call symbol "_map_images" 2024-07-10 14:07:34,399 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-07-10 14:07:34,476 - main - INFO: Call symbol "_load_images" 2024-07-10 14:07:34,477 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac 2024-07-10 14:07:34,480 - main - INFO: Load module "PhysicsKit" 2024-07-10 14:07:34,972 - main - INFO: Call symbol "_map_images" 2024-07-10 14:07:34,972 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-07-10 14:07:34,983 - main - INFO: Call symbol "_load_images" 2024-07-10 14:07:34,984 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac 2024-07-10 14:07:34,985 - main - INFO: Load module "CoreAutoLayout" 2024-07-10 14:07:35,276 - main - INFO: Hook import symbol "_calloc" at 0x1d3d3fa00 2024-07-10 14:07:35,277 - main - INFO: Hook import symbol "_malloc_good_size" at 0x1d3d3fa50 2024-07-10 14:07:35,352 - main - INFO: Call symbol "_map_images" 2024-07-10 14:07:35,353 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-07-10 14:07:35,372 - main - INFO: Call symbol "_load_images" 2024-07-10 14:07:35,373 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac 2024-07-10 14:07:35,374 - main - INFO: Load module "UIFoundation" 2024-07-10 14:07:36,581 - main - INFO: Hook import symbol "_calloc" at 0x1d296b018 2024-07-10 14:07:36,581 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x1d296b2b0 2024-07-10 14:07:36,582 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x1d296b2c0 2024-07-10 14:07:36,867 - main - INFO: Call symbol "_map_images" 2024-07-10 14:07:36,868 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-07-10 14:07:36,926 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28 2024-07-10 14:07:36,927 - main - INFO: State: x0: 0x00000001da4b1da8 [libc++abi.dylib!0x1b928bda8], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x0000000000077e98, x4: 0x0000000000000000, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x0000000000000000, x8: 0x0000000000000000, x9: 0x0000000000000000, x10: 0x0000000008150000, x11: 0x0000000000002000, x12: 0x0000000000001fff, x13: 0x0000000000000fbf, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000001, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x0000000821a9d1a0 [UIFoundation!0x1d9a681a0], x20: 0x0000000000000000, x21: 0x00000008224e6878 [UIFoundation!0x1da4b1878], x22: 0x0000000821a9d1c0 [UIFoundation!0x1d9a681c0], x23: 0x0000000000000000, x24: 0x00000002afe30ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x000000081a9b3cf0 [UIFoundation!0x1d297ecf0], x26: 0x0000000000000000, x27: 0x0000000000000069, x28: 0x0000000821a9d1a0 [UIFoundation!0x1d9a681a0], x29: 0x0000000000077ec0, x30: 0x00000002afe0f140 [libobjc.A.dylib!0x1947f9140] 2024-07-10 14:07:36,927 - main - ERROR: Initialize Objective-C failed. 2024-07-10 14:07:36,927 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140 Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 210, in _start_emulate self.uc.emu_start(address, stop_addr) File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/unicorn/unicorn.py", line 547, in emu_start raise UcError(status) unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/os/ios/os.py", line 176, in init_objc self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs) File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 745, in call_symbol return self._start_emulate(address, *args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 215, in _start_emulate self.crash("Unknown reason", from_exc=e) File "/Library/Frameworks/Python.framework/Versions/3.11/lib/python3.11/site-packages/chomper/core.py", line 381, in crash raise EmulatorCrashedException(message) from from_exc chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140 2024-07-10 14:07:36,930 - main - INFO: Load module "UIKitServices" 2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_MGCopyAnswer" at 0x1d210a1a8 2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_dispatch_async" at 0x1d210a218 2024-07-10 14:07:37,182 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x1d210a2a8 2024-07-10 14:07:37,214 - main - INFO: Call symbol "_map_images" 2024-07-10 14:07:37,214 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-07-10 14:07:37,225 - main - INFO: Call symbol "_load_images" 2024-07-10 14:07:37,226 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac

这个报错目前属于正常情况，一般不会影响最终结果，最终执行结果有报错吗

m1 macos 运行 example中的example_ios_ali_vmp_sign.py，报如下错，没有结果输出，依赖环境如下：
Package             Version

capstone            5.0.3
chomper             0.3.2
importlib-resources 6.4.4
lief                0.15.1
pip                 21.1.2
pyelftools          0.31
setuptools          57.0.0
unicorn             2.0.1.post1
wheel               0.36.2
zipp                3.20.0
2024-08-22 14:51:41,813 - main - ERROR: Initialize Objective-C failed.
2024-08-22 14:51:41,813 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140
Traceback (most recent call last):
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate
self.uc.emu_start(address, stop_addr)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start
raise UcError(status)
unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc
self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol
return self._start_emulate(address, *args)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate
self.crash("Unknown reason", from_exc=e)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash
raise EmulatorCrashedException(message) from from_exc
chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140

m1 macos 运行 example中的example_ios_ali_vmp_sign.py，报如下错，没有结果输出，依赖环境如下： Package Version
capstone 5.0.3 chomper 0.3.2 importlib-resources 6.4.4 lief 0.15.1 pip 21.1.2 pyelftools 0.31 setuptools 57.0.0 unicorn 2.0.1.post1 wheel 0.36.2 zipp 3.20.0
2024-08-22 14:51:41,813 - main - ERROR: Initialize Objective-C failed. 2024-08-22 14:51:41,813 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140 Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate self.uc.emu_start(address, stop_addr) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start raise UcError(status) unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol return self._start_emulate(address, *args) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate self.crash("Unknown reason", from_exc=e) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash raise EmulatorCrashedException(message) from from_exc chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140

最终的日志停留在哪呢，这个报错目前是正常的，不会中断执行

2024-08-22 16:43:52,615 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28
2024-08-22 16:43:52,615 - main - INFO: State: x0: 0x00000001da44b5c0 [libc++abi.dylib!0x1b92255c0], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x00000000080fffc0, x4: 0x00000000080e0080, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x00000000000006a0, x8: 0x0000000000000000, x9: 0x0000000000000010, x10: 0x0000000008100000, x11: 0x0000000000004000, x12: 0x0000000000003fff, x13: 0x00000000000007a5, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000005, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x20: 0x0000000000000000, x21: 0x00000008f69a0710 [UIKitCore!0x1da44a710], x22: 0x00000008f5fb7568 [UIKitCore!0x1d9a61568], x23: 0x0000000000000000, x24: 0x00000002c8430ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x00000008ee388540 [UIKitCore!0x1d1e32540], x26: 0x0000000000000000, x27: 0x0000000000000e19, x28: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x29: 0x0000000000077ec0, x30: 0x00000002c840f140 [libobjc.A.dylib!0x1947f9140]
2024-08-22 16:43:52,615 - main - ERROR: Initialize Objective-C failed.
2024-08-22 16:43:52,615 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140
Traceback (most recent call last):
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate
self.uc.emu_start(address, stop_addr)
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start
raise UcError(status)
unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc
self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs)
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol
return self._start_emulate(address, *args)
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate
self.crash("Unknown reason", from_exc=e)
File "/Users/sailorzhang/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash
raise EmulatorCrashedException(message) from from_exc
chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140
2024-08-22 16:43:52,629 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,629 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,629 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,630 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,635 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,635 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,635 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,636 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,638 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,638 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,639 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,640 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,640 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,642 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,642 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,643 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,643 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,644 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,644 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,646 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,646 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,647 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,648 - main - INFO: Load module "CSMBP-AppStore-Package"
2024-08-22 16:43:55,155 - main - INFO: Hook import symbol "_calloc" at 0x104f45430
2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_calloc" at 0x104f45430
2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_dispatch_async" at 0x104f45540
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_malloc_size" at 0x104f45e08
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x104f45ec8
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_posix_memalign" at 0x104f46150
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x104f462f8
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x104f46300
2024-08-22 16:43:55,171 - main - INFO: Call symbol "_map_images"
2024-08-22 16:43:55,172 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-08-22 16:43:56,494 - main - INFO: Call symbol "_load_images"
2024-08-22 16:43:56,495 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac
2024-08-22 16:43:56,637 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:56,638 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:56,642 - main - INFO: Call symbol "_CFArrayCreateMutable"
2024-08-22 16:43:56,643 - main - INFO: Start emulate at CoreFoundation!0x1803d9ff4
2024-08-22 16:43:56,644 - main - INFO: Call symbol "_CFStringCreateWithCString"
2024-08-22 16:43:56,645 - main - INFO: Start emulate at CoreFoundation!0x18040e36c
2024-08-22 16:43:56,645 - main - INFO: Call symbol "_CFArrayAppendValue"
2024-08-22 16:43:56,646 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
2024-08-22 16:43:56,647 - main - INFO: Call symbol "_CFStringCreateWithCString"
2024-08-22 16:43:56,648 - main - INFO: Start emulate at CoreFoundation!0x18040e36c
2024-08-22 16:43:56,648 - main - INFO: Call symbol "_CFArrayAppendValue"
2024-08-22 16:43:56,649 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)

2024-08-22 16:43:52,615 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28
2024-08-22 16:43:52,615 - main - INFO: State: x0: 0x00000001da44b5c0 [libc++abi.dylib!0x1b92255c0], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x00000000080fffc0, x4: 0x00000000080e0080, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x00000000000006a0, x8: 0x0000000000000000, x9: 0x0000000000000010, x10: 0x0000000008100000, x11: 0x0000000000004000, x12: 0x0000000000003fff, x13: 0x00000000000007a5, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000005, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x20: 0x0000000000000000, x21: 0x00000008f69a0710 [UIKitCore!0x1da44a710], x22: 0x00000008f5fb7568 [UIKitCore!0x1d9a61568], x23: 0x0000000000000000, x24: 0x00000002c8430ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x00000008ee388540 [UIKitCore!0x1d1e32540], x26: 0x0000000000000000, x27: 0x0000000000000e19, x28: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x29: 0x0000000000077ec0, x30: 0x00000002c840f140 [libobjc.A.dylib!0x1947f9140]
2024-08-22 16:43:52,615 - main - ERROR: Initialize Objective-C failed.
2024-08-22 16:43:52,615 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140
Traceback (most recent call last):
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate
self.uc.emu_start(address, stop_addr)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start
raise UcError(status)
unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc
self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol
return self._start_emulate(address, *args)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate
self.crash("Unknown reason", from_exc=e)
File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash
raise EmulatorCrashedException(message) from from_exc
chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140
2024-08-22 16:43:52,629 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,629 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,629 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,630 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,635 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,635 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,635 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,636 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,638 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,638 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,639 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,640 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,640 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,642 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,642 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,643 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,643 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,644 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,644 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_getClass"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,646 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:52,646 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:52,647 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:52,648 - main - INFO: Load module "CSMBP-AppStore-Package"
2024-08-22 16:43:55,155 - main - INFO: Hook import symbol "_calloc" at 0x104f45430
2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_calloc" at 0x104f45430
2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_dispatch_async" at 0x104f45540
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_malloc_size" at 0x104f45e08
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x104f45ec8
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_posix_memalign" at 0x104f46150
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x104f462f8
2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x104f46300
2024-08-22 16:43:55,171 - main - INFO: Call symbol "_map_images"
2024-08-22 16:43:55,172 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc
2024-08-22 16:43:56,494 - main - INFO: Call symbol "_load_images"
2024-08-22 16:43:56,495 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac
2024-08-22 16:43:56,637 - main - INFO: Call symbol "_sel_registerName"
2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4
2024-08-22 16:43:56,638 - main - INFO: Call symbol "_objc_msgSend"
2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460
2024-08-22 16:43:56,642 - main - INFO: Call symbol "_CFArrayCreateMutable"
2024-08-22 16:43:56,643 - main - INFO: Start emulate at CoreFoundation!0x1803d9ff4
2024-08-22 16:43:56,644 - main - INFO: Call symbol "_CFStringCreateWithCString"
2024-08-22 16:43:56,645 - main - INFO: Start emulate at CoreFoundation!0x18040e36c
2024-08-22 16:43:56,645 - main - INFO: Call symbol "_CFArrayAppendValue"
2024-08-22 16:43:56,646 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
2024-08-22 16:43:56,647 - main - INFO: Call symbol "_CFStringCreateWithCString"
2024-08-22 16:43:56,648 - main - INFO: Start emulate at CoreFoundation!0x18040e36c
2024-08-22 16:43:56,648 - main - INFO: Call symbol "_CFArrayAppendValue"
2024-08-22 16:43:56,649 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)

2024-08-22 16:43:52,615 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28 2024-08-22 16:43:52,615 - main - INFO: State: x0: 0x00000001da44b5c0 [libc++abi.dylib!0x1b92255c0], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x00000000080fffc0, x4: 0x00000000080e0080, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x00000000000006a0, x8: 0x0000000000000000, x9: 0x0000000000000010, x10: 0x0000000008100000, x11: 0x0000000000004000, x12: 0x0000000000003fff, x13: 0x00000000000007a5, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000005, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x20: 0x0000000000000000, x21: 0x00000008f69a0710 [UIKitCore!0x1da44a710], x22: 0x00000008f5fb7568 [UIKitCore!0x1d9a61568], x23: 0x0000000000000000, x24: 0x00000002c8430ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x00000008ee388540 [UIKitCore!0x1d1e32540], x26: 0x0000000000000000, x27: 0x0000000000000e19, x28: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x29: 0x0000000000077ec0, x30: 0x00000002c840f140 [libobjc.A.dylib!0x1947f9140] 2024-08-22 16:43:52,615 - main - ERROR: Initialize Objective-C failed. 2024-08-22 16:43:52,615 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140 Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate self.uc.emu_start(address, stop_addr) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start raise UcError(status) unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol return self._start_emulate(address, *args) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate self.crash("Unknown reason", from_exc=e) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash raise EmulatorCrashedException(message) from from_exc chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140 2024-08-22 16:43:52,629 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,629 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,629 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,630 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,635 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,635 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,635 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,636 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,638 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,638 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,639 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,640 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,640 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,642 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,642 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,643 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,643 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,644 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,644 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,646 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,646 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,647 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,648 - main - INFO: Load module "CSMBP-AppStore-Package" 2024-08-22 16:43:55,155 - main - INFO: Hook import symbol "_calloc" at 0x104f45430 2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_calloc" at 0x104f45430 2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_dispatch_async" at 0x104f45540 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_malloc_size" at 0x104f45e08 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x104f45ec8 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_posix_memalign" at 0x104f46150 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x104f462f8 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x104f46300 2024-08-22 16:43:55,171 - main - INFO: Call symbol "_map_images" 2024-08-22 16:43:55,172 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-08-22 16:43:56,494 - main - INFO: Call symbol "_load_images" 2024-08-22 16:43:56,495 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac 2024-08-22 16:43:56,637 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:56,638 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:56,642 - main - INFO: Call symbol "_CFArrayCreateMutable" 2024-08-22 16:43:56,643 - main - INFO: Start emulate at CoreFoundation!0x1803d9ff4 2024-08-22 16:43:56,644 - main - INFO: Call symbol "_CFStringCreateWithCString" 2024-08-22 16:43:56,645 - main - INFO: Start emulate at CoreFoundation!0x18040e36c 2024-08-22 16:43:56,645 - main - INFO: Call symbol "_CFArrayAppendValue" 2024-08-22 16:43:56,646 - main - INFO: Start emulate at CoreFoundation!0x1803856c4 2024-08-22 16:43:56,647 - main - INFO: Call symbol "_CFStringCreateWithCString" 2024-08-22 16:43:56,648 - main - INFO: Start emulate at CoreFoundation!0x18040e36c 2024-08-22 16:43:56,648 - main - INFO: Call symbol "_CFArrayAppendValue" 2024-08-22 16:43:56,649 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)

这个问题比较奇怪，看着像是 unicorn 内部直接崩溃了，是只有这个示例是这样还是全部都是这样？可以提供下你的系统版本和 处理器型号吗？

2024-08-22 16:43:52,615 - main - INFO: Backtrace: libobjc.A.dylib!0x1947f9140, libobjc.A.dylib!0x1947f913c, libobjc.A.dylib!0x194809c3c, libobjc.A.dylib!0x1947f9e28 2024-08-22 16:43:52,615 - main - INFO: State: x0: 0x00000001da44b5c0 [libc++abi.dylib!0x1b92255c0], x1: 0x0000000000000000, x2: 0x0000000000000000, x3: 0x00000000080fffc0, x4: 0x00000000080e0080, x5: 0x0000000000000000, x6: 0x0000000000000000, x7: 0x00000000000006a0, x8: 0x0000000000000000, x9: 0x0000000000000010, x10: 0x0000000008100000, x11: 0x0000000000004000, x12: 0x0000000000003fff, x13: 0x00000000000007a5, x14: 0x0000000000000000, x15: 0xffffffffffffffff, x16: 0x0000000000000005, x17: 0x0000000000000000, x18: 0x0000000000000000, x19: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x20: 0x0000000000000000, x21: 0x00000008f69a0710 [UIKitCore!0x1da44a710], x22: 0x00000008f5fb7568 [UIKitCore!0x1d9a61568], x23: 0x0000000000000000, x24: 0x00000002c8430ef9 [libobjc.A.dylib!0x19481aef9], x25: 0x00000008ee388540 [UIKitCore!0x1d1e32540], x26: 0x0000000000000000, x27: 0x0000000000000e19, x28: 0x00000008f5fb7548 [UIKitCore!0x1d9a61548], x29: 0x0000000000077ec0, x30: 0x00000002c840f140 [libobjc.A.dylib!0x1947f9140] 2024-08-22 16:43:52,615 - main - ERROR: Initialize Objective-C failed. 2024-08-22 16:43:52,615 - main - ERROR: Unknown reason at libobjc.A.dylib!0x1947f9140 Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 210, in _start_emulate self.uc.emu_start(address, stop_addr) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/unicorn/unicorn.py", line 547, in emu_start raise UcError(status) unicorn.unicorn.UcError: Invalid memory read (UC_ERR_READ_UNMAPPED)
The above exception was the direct cause of the following exception:
Traceback (most recent call last): File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/os/ios/os.py", line 166, in init_objc self.emu.call_symbol("_map_images", 1, 0, mach_header_ptrs) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 758, in call_symbol return self._start_emulate(address, *args) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 215, in _start_emulate self.crash("Unknown reason", from_exc=e) File "/Users/test/Data/opensource/chomper/venv/lib/python3.8/site-packages/chomper/core.py", line 381, in crash raise EmulatorCrashedException(message) from from_exc chomper.exceptions.EmulatorCrashedException: Unknown reason at libobjc.A.dylib!0x1947f9140 2024-08-22 16:43:52,629 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,629 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,629 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,630 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,630 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,635 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,635 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,635 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,636 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,636 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,638 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,638 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,639 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,639 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,640 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,640 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,640 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,641 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,641 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,642 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,642 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,642 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,643 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,643 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,644 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,644 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,644 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_getClass" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x194805c54 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,645 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,645 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,646 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:52,646 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:52,646 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:52,647 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:52,648 - main - INFO: Load module "CSMBP-AppStore-Package" 2024-08-22 16:43:55,155 - main - INFO: Hook import symbol "_calloc" at 0x104f45430 2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_calloc" at 0x104f45430 2024-08-22 16:43:55,162 - main - INFO: Hook import symbol "_dispatch_async" at 0x104f45540 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_malloc_size" at 0x104f45e08 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_notify_register_dispatch" at 0x104f45ec8 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_posix_memalign" at 0x104f46150 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_rdlock" at 0x104f462f8 2024-08-22 16:43:55,163 - main - INFO: Hook import symbol "_pthread_rwlock_unlock" at 0x104f46300 2024-08-22 16:43:55,171 - main - INFO: Call symbol "_map_images" 2024-08-22 16:43:55,172 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9dcc 2024-08-22 16:43:56,494 - main - INFO: Call symbol "_load_images" 2024-08-22 16:43:56,495 - main - INFO: Start emulate at libobjc.A.dylib!0x1947f9eac 2024-08-22 16:43:56,637 - main - INFO: Call symbol "_sel_registerName" 2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1948074a4 2024-08-22 16:43:56,638 - main - INFO: Call symbol "_objc_msgSend" 2024-08-22 16:43:56,638 - main - INFO: Start emulate at libobjc.A.dylib!0x1947ec460 2024-08-22 16:43:56,642 - main - INFO: Call symbol "_CFArrayCreateMutable" 2024-08-22 16:43:56,643 - main - INFO: Start emulate at CoreFoundation!0x1803d9ff4 2024-08-22 16:43:56,644 - main - INFO: Call symbol "_CFStringCreateWithCString" 2024-08-22 16:43:56,645 - main - INFO: Start emulate at CoreFoundation!0x18040e36c 2024-08-22 16:43:56,645 - main - INFO: Call symbol "_CFArrayAppendValue" 2024-08-22 16:43:56,646 - main - INFO: Start emulate at CoreFoundation!0x1803856c4 2024-08-22 16:43:56,647 - main - INFO: Call symbol "_CFStringCreateWithCString" 2024-08-22 16:43:56,648 - main - INFO: Start emulate at CoreFoundation!0x18040e36c 2024-08-22 16:43:56,648 - main - INFO: Call symbol "_CFArrayAppendValue" 2024-08-22 16:43:56,649 - main - INFO: Start emulate at CoreFoundation!0x1803856c4
Process finished with exit code 138 (interrupted by signal 10: SIGBUS)

这个问题比较奇怪，看着像是 unicorn 内部直接崩溃了，是只有这个示例是这样还是全部都是这样？可以提供下你的系统版本和 处理器型号吗？

macOS Monterey 12.2.1.  Apple M1 Pro

Apple Silicon 崩溃问题统一到 #92


[feat] [macOS] Add an option to configure acceptsFirstMouse

Describe the problem
Add a way to pass acceptsFirstMouse to macOS windows
Describe the solution you'd like
Expose https://github.com/tauri-apps/wry/issues/714
Alternatives considered
No response
Additional context
No response

Hi, I would like to work on this.
Since I am a beginner i have very little idea about what to do.
Could you guide me on this.
I would learn all the necessities to solve this issue!

@adityanain29 thanks for wanting to contribute, this issue should wait until a new WRY version is published. However you can work on it and change the wry dependency here https://github.com/tauri-apps/tauri/blob/dev/core/tauri-runtime-wry/Cargo.toml to point to the WRY git repo and make your changes. You can also take this PR https://github.com/tauri-apps/tauri/pull/5317 as inspiration on how to do it

@adityanain29 sorry I didn't see your message and pushed a PR for this: #5374 :(

Np. I would try to contribute in some other way to this project.


35

@g4s8 Please assign me

Job gh:artipie/rpm-adapter#37 is not assigned, can't get performer

Pull request #37 was not merged, no payment for ARC, see §28


Error installing Accio

Hi there, I'm having an issue installing Accio. I'm getting this Validation Failed error after the brew install accio command:
"The listed users and repositories cannot be searched either because the resources do not exist or you do not have permission to view them."
My homebrew version is current at 2.1.15. Please see the screenshot below:

Thanks in advance!

@pvcary Thanks for reporting this. Can you please provide more info about:

the version of macOS you are using
the version of you Xcode command line tools (xcodebuild -version)
the version of Swift (swift -version)

Thet would help fix the issue.


add pwm trim parameters

@bartosz-wawrzacz @tumbili this is a continuation of https://github.com/PX4/Firmware/pull/5488
Initial commit adds just one trim parameter (PWM_MAIN_TRIM2) and the necessary vitrual methods in the Mixer class hierarchy, and only for PX4IO. It also retains the PWM pulsewidth-space definition of trim, and sets the default to 1500, but that should perhaps change to the normalized [-1,1] range.

Trims work correctly from console and QGC, but the new parameters are showing up in the default group in QGC.
But parameters.xml looks OK, I think. Also, we'll need a feature request for QGC to add sliders.

Nice!

@kd0aij Looking forward to this!

params show up correctly in QGC now: rebased and squashed

@kd0aij Is this ready for testing?

@tumbili Trim parameters are working in the IO coprocessor, and I'd appreciate testing of that. You should be able to adjust trims by setting PWM_MAIN_TRIM_1-8 via QGC. As I noted above, it might be better to switch to normalized units (with zero neutral) instead of usec (with 1500 neutral).
But I've been unable to get the aux_trim parameters to work in the FMU. I've run into a least one bug on master which broke the aux pwm outputs for fmu-v2, and am having trouble getting the aux outputs to work even in v1.4.4 with a standard plane config. I haven't pushed the FMU changes yet, since I can't even make the basic functions work consistently.

@tumbili aux pwm is OK in v1.4.4, but not in v1.4.3 or master. I can't make any sense of the commit tree from 1.4.3 to 1.4.4 so I can't even do a bisect; This PR is stalled till I can figure out what's wrong.

You can start with this diff: git diff v1.4.4 src/drivers/px4fmu/. And then simply use GDB or printfs to see if the mixer loads successfully and if the system is trying to output something.
I also advise to run a make clean just to be sure that you picked up most recent NuttX (which had a mixer load fix).

@kd0aij Ok, cool! Once fmu works as well I'll give it a try.

@dagar  @LorenzMeier Note that this PR modifies build cmake config fmu-v2_default in order to avoid flash overflow. It removes INAV and switches to the new logger.
That should be fine for testing purposes, but that config change shouldn't go in while there are still legacy Pixhawk users who need EKF replay with the default fmu-v2 build. That's assuming replay doesn't yet support the new logging format.

@bartosz-wawrzacz @dagar @LorenzMeier  One issue we haven't discussed yet is my assumption that neutral trim is 1500 usec, and changing the default trim value from 0 to 1500. I'm sure this breaks @bartosz-wawrzacz current usage.
I'd prefer to change neutral trim back to zero, but I think we'll need yet another PWM parameter to specify the neutral (mid) position, since I don't think it's correct to assume neutral is the midpoint between PWM_MIN and PWM_MAX. Unless it is correct/acceptable to have the neutral point (and trim) move around with min/max? If we were to move to per-channel min/mid/max parameter values, there would be no need to specify the output scaler in mixer files, because we would have complete specification of a piecewise linear mapping of [-1, 0, 1] to [pwm_min, pwm_mid, pwm_max] in the parameters. (the assumption that neutral is the midpoint between min/max is built into pwm_limit_calc)

main and aux trim parameters are normalized values with range limited to [-0.2, 0.2] and default of zero.
"pwm info" displays the currently loaded trim values, but "pwm trim" has been removed since it wasn't designed to handle signed values

@kd0aij Can you rebase and add the pwm out sim back and see if you have enough flash? Is this ready to be merged?

After rebase and before adding pwm out sim back:
gcc-arm-none-eabi-4_9-2015q3/bin/../lib/gcc/arm-none-eabi/4.9.3/../../../../arm-none-eabi/bin/ld: region `flash' overflowed by 9436 bytes

We might have to move optional software components like estimators to the FMUv3 config.

Looks OK with pwm_out_sim if inav and logger are removed.
I tested this on pixracer and fmu-v2, and it is functional, but note that it uses normalized values for trim instead of the usec values in the original version. Would be nice if at least one other dev could test.

And please rebase, thanks!

rebased, deleted commented code and AERTA config

@LorenzMeier any idea why CI isn't running on this?

Jenkins test this please.

We're ready to merge this with the two suggested changes applied.

I think this has all requested changes; had a flash overflow with mpu9250 added back to fmu-v2, so I rebased. "view changes" just showed me everything in the PR, not just those relevant to a review.

Almost - I'd like to avoid bundling this with the logger change and gating it on us validating that we can use the new logger and people understand the change. Let's change one thing at a time.


Feedback from UG set-up

Alright, so here is all of my feedback from your awesome move-to-brain-brew set-up for UG. Sorry if this is a bit raw and disorganised. 😅

builder_files - I know the naming of this folder is not tied to Brain Brew, but I feel like scripts would be a better name. The way I see it, the YAML files in this folder are "scripts" that define "tasks".

brain_brew_config.yaml - very minor, but what would you think of calling this file brain-brew.config.yaml?

I come from a web front-end background, and that's how config files are usually named (e.g. webpack.config.js, postcss.config.js, etc.)
The Python package is called brain-brew, so I think this should be consistent (also I'm more of a kebab-case than snake_case kind of guy 😄).
All that being said, I'm not familiar with Python naming conventions, so I could be way off.

generate syntax - in the YAML builder files (scripts?), I find the generate syntax a bit confusing, as it encompasses both read and write operations (sometimes both in the same task, with save_to_file).
I feel like having separate, independent read (i.e. parsing a file/folder) and write (i.e. writing to a file/folder) tasks would make things a lot clearer. Here is how I see it:

In a read operation, you describe:

the file/folder name of the resource you want to parse,
its type (i.e. CSV, CrowdAnki JSON, YAML deck part, etc.),
the "deck parts" you want to parse from it, to which you give unique names (following a naming convention of sorts).

In a write operation, you describe:

the destination file/folder of the resource you want to write,
its type,
the named deck parts declared in the script's read tasks and how they are to be used in the destination resource.

This is a huge simplification of the problem, but do you see where I'm getting at?

Deck parts is what you call the various pieces of a deck's metadata, right? Would you be able to write down a list somewhere of all the deck parts that you have defined/identified, just so we're clear?

Perhaps it's your plan, but I feel like some of the deck parts could be split up even more so they could live in separate files like in AnkiDM -- I liked how templates and the deck's description lived in HTML files, the styles in a CSS file, etc.

Thanks for the feedback, let me take these in the order that makes most sense to me:
Structural changes

brain_brew_config.yaml - very minor, but what would you think of calling this file brain-brew.config.yaml?

The global config file will soon be fully removed, I hope. It is no longer useful, in my eyes, and I wish for everything that it does to be configurable in the builder files yaml files that define the tasks of how stuff is made 😏 So the media super-folder will soon be definable per task, so different decks can even use replacement media 👍

Perhaps it's your plan, but I feel like some of the deck parts could be split up even more so they could live in separate files like in AnkiDM -- I liked how templates and the deck's description lived in HTML files, the styles in a CSS file, etc.

That's the plan, indeed! I would like to have css and html be their own files too, but I'd like that to be optional, not necessary. The current issue is that I don't know how I should structure the files after this, while trying to maintain the ability to merge to and from crowdanki 🤔 the templates are either used or not, no worries there, but the for the css I think having a bunch of separate css files which can be combined together would be best. This way an extended deck can add just one css part to get some new functionality in their new card, or can overwrite just a specific part in order to change some functionality. All the while they keep the most recent changes in the main repo, with the minimum changes propagating out into them (and less work for us 😅 )
Just spit balling ideas, lemme know if anyone has a better suggestion 😁👍
Names of stuff

builder_files - I know the naming of this folder is not tied to Brain Brew, but I feel like scripts would be a better name. The way I see it, the YAML files in this folder are "scripts" that define "tasks".

In the sense of what I call things in the code I've pretty much been winging it on the names, just picking whatever makes sense in my head. Absolutely nothing in the system needs to be called that, and can be changed to whatever makes more sense 👍 A "Builder" made sense to me as it 'builds' the stuff, but yes I can also see a "script" also works 👍 I'll have a think about it, and would like to hear what others think.
However the other way to look at this is: what do we call the folder in the UG repo? Call it literally whatever you want 😁 as long as you run it in the command line or point to it in the script, s'all good. Same with every folder in any repo that uses UG. The global_config can even be renamed, as long as you run brain brew with -g name_of_config 👍

generate syntax - in the YAML builder files (scripts?), I find the generate syntax a bit confusing, as it encompasses both read and write operations (sometimes both in the same task, with save_to_file).

Same goes with these! The term "Generate" just makes sense to me, as it makes those things, however this one is entirely superfluous. generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .*csv.* 😄 Same goes for generate crowdanki or make me a crowd anki pls as it matches .*crowd[\s_-]*?anki.* which you can find here in the code. My intention here is to have these keys be flexible in that users can put whatever makes sense but still have it match an actual transform task. So something like english csv may make sense in this case, and would still work! 😁 I just did not want to limit users to a specific key set, which may change in the future, and that others may not like whatever naming convention is/was used, like Generate_Csv_Collections 😅 this way, you are free to do it yourself, as long as it matches only 1 of the tasks!
Deck Parts are the only special one right now, as the name is a top level task and it also matches each of the other types in it's children (their X_from_source type, such as notes_from_crowdanki). So these are all equivalent:
generate deck parts:
   from csv:
      ...
   csvs:
      ...
   country_csv:
      ...

and the top level again does not need the term generate, though it is what the task does, it makes deck parts. The second reason deck parts are special is that they do not save as a file by default, and are merely held in memory so that other files can be made with them. One can save them to memory if they wish, but it is optional.

I feel like having separate, independent read (i.e. parsing a file/folder) and write (i.e. writing to a file/folder) tasks would make things a lot clearer.

It's a little more complicated than that, as a task does not simply read or write, usually both are done as it is more of a transform of one data into another, each time. Csv <-> Deck Parts <-> Crowd Anki. The only step that is just a read is reading a Deck Part from the local Yaml representation, as in
generate deck parts:
   from deck part:
      ...

So I chose for everything to be a generation task, you make a deck part, you make a csv, you make a crowd anki (and more to come) and that is the entirety of the top level key definitions. Also the 'read' tasks, which make the non deck part file tasks have no concept of the files in the system used previously. Only Deck Parts is a working list that is kept in memory, and can be referenced in other tasks. That's how I designed the system to be reliant on Deck Parts, as I want each source type to be entirely independent of the others.

Deck parts is what you call the various pieces of a deck's metadata, right? Would you be able to write down a list somewhere of all the deck parts that you have defined/identified, just so we're clear?

The Deck Parts to me are: Notes, Note Models, Headers, and Media. I go into detail on these here https://github.com/ohare93/brain-brew/issues/4#issuecomment-644975261
I would like to remove Headers entirely as a requirement, but that will take some more work in CrowdAnki in order to get to there. I believe you agree with me on that goal 😅 For the time being they are a necessary evil.
One can ofc break down Note Models into further smaller components, such as Templates and Fields, but I think they are related enough to be a part of the same general thing, even if they end up being stored in separate files. I hope to add in a filter for these two fields into Brain Brew soon, in the form of a whitelist or blacklist, so that one can choose to only use the Fields and Templates that you want (when doing a transform in either direction, that is). This will hopefully also be an option in CrowdAnki itself, which may remove the requirement of generating an Extended deck in the first place 🤔 😁 the user simply gets the option in CrowdAnki to include them or not (and I am sure we can set the default to be without the extra two templates).

but the for the css I think having a bunch of separate css files which can be combined together would be best

Totally! The blurring of the flags could live in its own file, for instance.

However the other way to look at this is: what do we call the folder in the UG repo?

I like scripts because it's very generic and quite a common name, but I also like .brain-brew, which is the complete opposite. Tooling folders like the latter seem to be becoming a convention of sorts, and they have the merit to be clear.

generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .csv.

Riiiight, I get it now! Pretty cool, actually. 🙂
A part of me can't help but wonder, though, whether it wouldn't be safer and clearer to know exactly which transformer is run. I'm thinking that if transformers were to become more specific or cross-purpose, regexes could become confusing or run into conflicts. A clearer identification would also:

make it a lot easier to find the transformer's source code and documentation;
avoid relying on people writing good, meaningful task names.

In my opinion, you could get the best of both worlds with something like:
- Task name that can be anything
  transformer: my_transformer
  # ... (rest of config)

I also wonder whether the deck-part-parsing "sub-tasks" (e.g. - from csv:) couldn't just be top-level tasks in their own right, with their own, purpose-built transformers -- something like:
- Parse note model from YAML
  transformer: note_model_from_yaml
  part_id: ug
  # ...

- Parse English notes from CSVs
  transformer: notes_from_csv
  part_id: english
  # ...

- Parse German notes from CSVs
  transformer: notes_from_csv
  part_id: german
  # ...

# etc., then the "output" tasks:

- Generate CrowdAnki JSON
  transformer: all_deck_parts_to_crowdanki
  output_folder: build/Ultimate Geography
  note_model: ug
  notes: english
  # ...

We could then come up with a naming convention for the transformers, like:

<deck_part_type>_from_<format> for deck parts parsers;
<deck_part|"all_deck_parts">_to_<format> for generators that take deck parts and output files.

The example above packs a lot of suggestions. I've probably over-simplified things since I don't have a full picture of all the use cases you're trying to cover, but do you see where I'm getting at? I should probably justify a bit more where the above syntax came from... 😅
Basically, in my opinion, what I'm suggesting would clear up a number of confusions, and notably the following:

- from csv:
  notes:
    # ...

The notes object adds a level of nesting, and is most often used on its own. By having dedicated transformers to parse each type of deck part from each file format that can store them, the whole thing can be declared in a single line, with zero extra level of nesting: transformer: notes_from_csv.

- generate deck parts:
  - from deck parts:
    #...

Some deck parts (note models and headers) can be stored in YAML files, but they end up as deck parts in Brain Brew's runtime memory as well. I had a lot of trouble getting my head around this because of these two lines.
The verb "generate" for a task that puts something in memory feels wrong (see item below about save_to_file).
from deck parts doesn't convey anything about the file format.

notes:
  name: english

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id -- it's clear that it's an identifier that is meant to be used later on, and it also clarifies what the output of the transformer is (i.e. a deck part in memory).

save_to_file: src/deck_parts/notes/english.yaml

I'm back to what I was saying about a task/transformer doing both read and write operations. In my opinion, a transformer should only do one and be named accordingly: notes_from_csv already parses notes from CSV files; it shouldn't also write to a file (c.f. single-responsibility principle). Why not have dedicated transformers take care of writing each type of deck part to YAML?
- Save notes to YAML
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

Wow, that was a lot, sorry. 😄 I hope there's something in there that makes sense! 😅

I haven't fully digested @axelboc's suggestions, but some partially thought-out, randomly-ordered (sorry!) responses.
Before diving in, none of the issues are IMO "breaking" and bikeshedding syntax should probably be relatively low in priority, at the moment. (Even though in the long run, getting syntax right is important.)

generate csv as a top level key in the Yaml matches the CsvGenerate task in the code only because the key matches the regex .csv.

I agree with @axelboc and also prefer unambiguous task names (for instance, it makes it easier to grep the source code for references :)). OTOH flexible names are indeed cool and neat, so perhaps there could be a "canonical" name, while also allowing matching by regex?

It's a little more complicated than that, as a task does not simply read or write, usually both are done as it is more of a transform of one data into another, each time.

Is this for example when you're writing a set of fields/columns to a CSV, which also contains other fields/columns which aren't being modified? (As would presumably be the case when converting a single language CrowdAnki deck to CSV.)

save_to_file

I admit that I like this key, even though it mixes reading and writing (and is "impure"/results in "side effects"), as it's a neat way of caching the intermediate data (the "deck part").
I don't think that it should really be used "in production", since IMO there should only be a single source of truth, but I imagine that it might be extremely valuable for quick debugging.

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id

I found name as the name of the "id" to be OK. part_id or even just id would have also been OK.
Perhaps, for clarity, there could be an (unenforced) convention on identifier names (just like there is for variable names in some programming languages)? For instance ALL_CAPS or _underscore_prefixed or suffixed_? I'm not sure if it's worth it, though.
(Off-the-cuff-thought: As a far more disruptive suggestion, we could have the name as the top-level, e.g.
- Ultimate Geography:
  - from deck parts:
      note_models:
        - file: src/deck_parts/note_models/Ultimate Geography.yaml

according to the idea that what we're doing is defining "Ultimate Geography" for later use. ("Ultimate Geography = ..."). Obviously, there'd need to be a way of disambiguating between identifiers and writing-to-end-files transformations.
Aaah, but this wouldn't work in the case of CrowdAnki → CSV transformations, since we'd need the equivalent of (model_name, notes_name, headers_name) = ..., which wouldn't work with YAML.)

Sorry for the late reply, I have been rather busy. Will become a dad in the next month or so, so plenty to do! :grin: :tada:

I like scripts because it's very generic and quite a common name, but I also like .brain-brew, which is the complete opposite. Tooling folders like the latter seem to be becoming a convention of sorts, and they have the merit to be clear.

How about a recipe? :wink: this Brain-Brew after all! :grin: Though I would say the files should still be .yaml so that code editors can give highlighting and autocomplete for yaml specific keys :+1:

The way deck parts are identified in memory through name is not very explicit in my opinion. That's why, in my example, I suggest using a key called part_id -- it's clear that it's an identifier that is meant to be used later on, and it also clarifies what the output of the transformer is (i.e. a deck part in memory).

Good suggestion, I shall adopt this immediately :+1:

I'm back to what I was saying about a task/transformer doing both read and write operations. In my opinion, a transformer should only do one and be named accordingly: notes_from_csv already parses notes from CSV files; it shouldn't also write to a file (c.f. single-responsibility principle). Why not have dedicated transformers take care of writing each type of deck part to YAML?

- Save notes to YAML
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

I get what you're saying, but this comes with a few downsides. First of all, the first line here would not be valid, as the rest is a dictionary, so this would either have to be made into an explicit comment key, or just a yaml comment itself. Which we can already do, I guess :sweat_smile: Secondly, having transformer be a key inline with the rest of the keys complicated type prediction when running prechecks to see if all the expected keys are present. It is still possible to do so with this structure, but it is more difficult, I believe. Also, it creates wasted lines of repetition, in my opinion, where a nested format would be simpler. For instance, the following:
- generate deck parts:
  - from deck parts:
      note_models:
        - name: Ultimate Geography
          file: src/deck_parts/note_models/Ultimate Geography.yaml
        - name: Ultimate Geography Combined Fields
          file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

would turn into
- generate deck parts:
  - from deck parts:
    - transformer: note_model
      name: Ultimate Geography
      file: src/deck_parts/note_models/Ultimate Geography.yaml
    - transformer: note_model
      name: Ultimate Geography Combined Fields
      file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

and the extra lines would only compound as more parts / transformers are used :sweat: This also would not work for tasks which take lists. I will keep the nesting as it is for now, but ofc anyone can point out something I missed :grin:

The verb "generate" for a task that puts something in memory feels wrong

Hmm :thinking: I get that. Do you have a better suggestion? create_deck_parts, build_deck_parts?

Edit: actually it seems that save_to_file is also used for the "final" writing-to-file, for instance in source_from_anki.yaml, which feels slightly weird.

I understand your confusion about this key. The exact same result could be achieved by having a separate write deck parts key which takes a list of part_ids and their write location, and then writes those to disk. Though I just felt that this was rather clunky, as all deck parts are immutable so their content will never change due to being used by other tasks. So writing them at the end of the process is unnecessary, though I agree would perhaps add clarity when reading the task list itself.
I will not change this behaviour at the moment, but anyone else can feel free to implement a write deck parts top level task :+1: which should be quite easy.

I agree with @axelboc and also prefer unambiguous task names (for instance, it makes it easier to grep the source code for references :)). OTOH flexible names are indeed cool and neat, so perhaps there could be a "canonical" name, while also allowing matching by regex?

 This is indeed an incredibly unimportant feature, that I have already spent too much time on, compared to the other large tasks that still exist. Standard expected keys will suffice. However I will leave the implementation using Regex for now, so that improvements can be made here in the future.

Changes made! See my PR for all the nitty gritty details: https://github.com/ohare93/brain-brew/pull/13 I just went with my best judgement from out conversation, but nothing is permanent :+1:
I have updated the Move-To-Brain-Brew branch of UG to reflect these changes :+1: Which you can find here https://github.com/ohare93/anki-ultimate-geography/commit/ab83d80f5c57e6caf81896b12f21e03fc46861cf
Remember to run pipenv install again, to update to the latest version of Brain Brew!

Sorry for the late reply, I have been rather busy. Will become a dad in the next month or so, so plenty to do! 😁 🎉

Wow, congrats!! 👶 🍼

How about a recipe? 😉 this Brain-Brew after all! 😁

Love it! 😁

First of all, the first line here would not be valid, as the rest is a dictionary [...]

Right, silly me, the syntax I had in mind was more like that of GitLab CI:
Save notes to YAML:
  transformer: notes_to_yaml
  output_file: build/english.yaml
  notes: english

Does dropping the top-level array syntax pose a challenge? I'm not all that familiar with the inner-workings of YAML (as you may have guessed 😄), so perhaps the array provides better ordering guarantees?

Secondly, having transformer be a key inline with the rest of the keys complicated type prediction when running prechecks to see if all the expected keys are present. It is still possible to do so with this structure, but it is more difficult, I believe.

Makes sense, I get you. Anyway, as you said, it doesn't matter if the transformer name is the top-level key since it's easy to add a comment above it! https://tenor.com/view/smart-so-sosmart-gif-15534259

Also, it creates wasted lines of repetition, in my opinion, where a nested format would be simpler.

I slightly disagree on this one: I think that repetition can make things clearer if it's the right kind of repetition. Repeating the transformer, in my opinion, is a good thing because it makes identifying all the transformations that take place easier. If this leads to config repetitions across multiple tasks, then this could be addressed specifically (i.e. by providing a syntax to share config between tasks at the top-level, for instance).
That being said, allowing multiple tasks to be defined as an array under the same transformer is conceptually sound, so this is more of a philosophical discussion. 😄

Changes made!

Awesome! part_id really makes things clearer, and build_deck_parts has a lot less of a file-writing vibe. 💯

Looking back at the updated build_deck_parts syntax, I still think this should be flattened or rethought somehow 🤔:
- build_deck_parts:
  - from_deck_parts:
    note_models: ...
    headers: ...
  - from_csvs:
    notes: ...

(I think) I fully understand the syntax now, so I'm happy to work with it for the time being. However, I do feel like the from_ keys interfere with readability. To me, a couple of more readable alternatives could be:

- build_deck_parts > - note_model > - from_deck_parts,
- build_deck_parts > - note_model_from_deck_parts,
- build_note_model > - from_deck_parts,
- build_note_model_from_deck_parts.

If I'm not mistaken, currently, a build_deck_parts "sub-transformer" (like from_deck_parts) can potentially handle multiple types of deck parts. The alternatives I suggest would basically require splitting the sub-transformers so that one sub-transformer can build only one type of deck part from one source format. Is this right, and if so, is this something you would consider doing in the long term?
Note that you could still nest multiple tasks under the same transformer if you wanted:
- build_deck_parts:
  - note_model_from_deck_parts:
    - part_id: Ultimate Geography
      file: src/deck_parts/note_models/Ultimate Geography.yaml
    - part_id: Ultimate Geography Combined Fields
      file: src/deck_parts/note_models/Ultimate Geography Combined Fields.yaml

That being said, allowing multiple tasks to be defined as an array under the same transformer is conceptually sound, so this is more of a philosophical discussion. smile

:laughing: I get your point about certain types of repetition though, that makes sense. Let's file this away as a bridge to cross after a bunch of bigger breaking changes fundamentally change the structure of the whole program again :sweat_smile:

Looking back at the updated build_deck_parts syntax, I still think this should be flattened or rethought somehow thinking:

:man_shrugging: not much difference in the end result here. Why do you prefer this flattened structure in this instance though? :thinking:
- build_deck_parts:
  - from_deck_parts:
      note_models:
        - part_id: Ultimate Geography
          file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        - part_id: default header
          file: src/deck_parts/headers/default.yaml

I made it the way it currently is as I had (have?) the expectation that a user will only ever perform 1 instance of reading all the deck parts, at the start of the Recipe. "Why split it up into multiple, if they'll just group them all together anyways?" was my thought :thinking: One can always make multiple from_deck_part tasks, each with a subset of the deck parts, though I cannot foresee a use case for that :thinking:
Anyways not explicitly against this change, but it will be low priority without further convincing :sweat_smile:

Fair enough 😅
Regarding from_deck_parts > note_models and the like, it's not so much about the flattening per se, but about the cognitive simplicity of one transformer having one input and one output (i.e. one deck part, not multiple deck parts). The flattening is something that can be gained from this simplicity.
Moreover, if you take the names of the deck part transformers on their own (from_deck_parts, from_csvs, etc.), they give me no information as to which deck part they are able to build. They are too generic and vague. Can from_csvs build note_models? Smaller, atomic transformers called note_model_from_deck_parts, or note_from_csvs, would be self-descriptive.
Side note, I'd recommend at least renaming from_deck_parts to from_yaml_deck_parts to convey the source format. Someone may want to store raw deck parts in another format one day. 🤷♂
Regarding build_deck_parts, I get that this is a way to group deck part building tasks, but I don't really get the benefit of that. If anything, I see two downsides:

It looks like a transformer in its own right, but it's not... not really anyway. The real transformers are from_csvs, etc., right? I feel like having transformers at different nesting levels in the recipe file increases the cognitive complexity.
You mention that users would group all deck part building tasks at the top of the recipe, but what's the harm in interleaving them with generate tasks? Someone may want to have a recipe that builds a deck part, then does something with it, then builds another deck part and does something else with it. I don't know, I feel like it's just an unnecessary constraint.

I hope my reasoning makes more sense, but no worries if I didn't manage to convince you 😉. Thank you for taking the time to chat about this! 🍻

You mention that users would group all deck part building tasks at the top of the recipe, but what's the harm in interleaving them with generate tasks? Someone may want to have a recipe that builds a deck part, then does something with it, then builds another deck part and does something else with it. I don't know, I feel like it's just an unnecessary constraint.

That is my expectation, yes. But as I said earlier, there is no limitation here. Someone can use multiple build_deck_parts tasks, or multiple from_deck_parts.

Side note, I'd recommend at least renaming from_deck_parts to from_yaml_deck_parts to convey the source format. Someone may want to store raw deck parts in another format one day. man_shrugging

Not a bad idea :+1:

Regarding from_deck_parts > note_models and the like, it's not so much about the flattening per se, but about the cognitive simplicity of one transformer having one input and one output (i.e. one deck part, not multiple deck parts).

But the same is not true about other transformers, like deck_parts from_crowdanki:
- build_deck_parts:
  - from_crowd_anki:
      folder: brain_brew_build/Ultimate Geography/
      notes:
        part_id: standard notes
        sort_order: [Country]
        save_to_file: src/deck_parts/notes/english.yaml
      note_models:
        - part_id: Ultimate Geography
          save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        part_id: default
        save_to_file: src/deck_parts/headers/default.yaml
      media:
        from_notes: true
        from_note_models: true

One can create Notes, multiple NoteModels, Headers, and Media. Would you also suggest breaking this up into multiple? :slightly_frowning_face:
Hmm, I thought I would be more against this, but looking back on my reasoning I am seeing some misalignment.
My main reason was to limit repetition which could lead to mistakes, but with Yaml Anchors that can be mitigated. Further weight behind your argument is that my actual code is written in this atomic structure that you are advocating for. Before my rewrite there was a lot more interdependencies between the different components, and the final one remaining (Notes need to know the names of the Note Models) can be fixed with no worries.

I think that smaller, atomic transformers called note_model_from_deck_parts, or note_from_csvs, would be self-descriptive.

 Better to get this stuff nailed down while nobody is using the program! :smile:

Further thought: perhaps each top level step should be explicitly named by the user :thinking: rather than it being a list. This would help with the end goal of allowing others to more easily replace one specific part of the Recipe. Rather than splitting up the steps into multiple files which is annoying and not as easily readable, or replacing a specific numbered step which would be prone to errors.
This could also just be optional, for repos such as UG which will actually use it, and the rest can use just a standard list.
Thoughts? :grin: This is the time for these high level design discussions, while everything is young and easily changed :laughing:

Just catching up with this. Awesome! 🍻 Glad to hear also that your code is already suited to making this change, I was worried it'd be too much work.

Further thought: perhaps each top level step should be explicitly named by the user 🤔 rather than it being a list.

Could you just please clarify what you mean with a quick example, to make sure I understand?

I'm back to it :muscle: Atomisation complete :+1:

Build parts are now much more atomic
Media files are read in groups, and can change for each export.

It is also possible to combine or subtract media groups before exporting them

Yamale is now used to validate Yaml

See pull https://github.com/ohare93/brain-brew/pull/14 for the code changes.
I have also updated the Move to Brain Brew branch of UG https://github.com/ohare93/anki-ultimate-geography/commit/903b21e0c2d0a4c6cd107dcdfca9458aad9a570d Here'ss an example of a difference:
Old
- build_deck_parts:
  - from_crowd_anki:
      folder: brain_brew_build/Ultimate Geography/
      notes:
        part_id: standard notes
        sort_order: [Country]
        save_to_file: src/deck_parts/notes/english.yaml
      note_models:
        - part_id: Ultimate Geography
          save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
      headers:
        part_id: default
        save_to_file: src/deck_parts/headers/default.yaml
      media:
        from_notes: true
        from_note_models: true

New
- build_parts:
  - notes_from_crowd_anki:
      source: brain_brew_build/Ultimate Geography/
      part_id: standard notes
      sort_order: [Country]
      save_to_file: src/deck_parts/notes/english.yaml
  - note_models_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: Ultimate Geography
      save_to_file: src/deck_parts/note_models/Ultimate Geography.yaml
  - headers_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: default
      save_to_file: src/deck_parts/headers/default.yaml
  - media_group_from_crowd_anki:
    - source: brain_brew_build/Ultimate Geography/
      part_id: all_anki_media
  - save_media_group_to_folder:
      parts: [all_anki_media]
      folder: src/deck_parts/media
      clear_folder: false

I will release this new version tomorrow so others can try it, so only local installs will work until then, fyi :+1: Anyways, glad to be back! :grin: I will not work on the NoteModel parts being separate files :tada:

That definitely looks cleaner!
I hope you're a happy dad now, though I'm also glad that you're still finding time to work on this! :)

Note Model is now separated :partying_face: CSS and Templates live in their own files, and Fields are done through Yaml. Again, see the latest in move_to_brain_brew for the details.
Just have some fixes to do to allow easy generation of the extended deck (is currently working, but requires duplication of Note generation step :angry:) then I'll release the latest and give y'all a proper update in the move_to_brain_brew branch :+1:

Great work!! It's looking really good. 💯

I guess this issue is resolved! :grin:

I guess this issue is resolved! :grin:


Pods stuck on Terminating after EKS 1.26 update

What happened:
Once EKS was updated to 1.26  and even with EKS 1.27 (nodes use EKS-optimized ami ami-0c92ea9c7c0380b66 (amazon-eks-node-1.27-v20230919)) some of the pods were stuck in Terminating indefinately.
At the same time, Karpenter recognizes the node as empty and deletes it (so the pod can be listed with kubectl, but its node is already gone),
What you expected to happen:
There are no pods that are stuck in Terminating.
How to reproduce it (as minimally and precisely as possible):
I'm not aware of a reliable way to reproduce it.
Environment:

AWS Region: us-east-1
Instance Type(s): doesn't matter, happens on different instance types.
EKS Platform version (use aws eks describe-cluster --name <name> --query cluster.platformVersion): eks.5
Kubernetes version (use aws eks describe-cluster --name <name> --query cluster.version): 1.27
AMI Version: ami-0c92ea9c7c0380b66 (amazon-eks-node-1.27-v20230919)
Kernel (e.g. uname -a): Linux ip-10-34-44-24.node.domain 5.10.192-183.736.amzn2.x86_64 #1 SMP Wed Sep 6 21:15:41 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux
Release information (run cat /etc/eks/release on a node):

BASE_AMI_ID="ami-0963f2c76238b64d5"
BUILD_TIME="Tue Sep 19 17:51:01 UTC 2023"
BUILD_KERNEL="5.10.192-183.736.amzn2.x86_64"
ARCH="x86_64"

If the Pod is left in an indeterminate state and the instance no longer exists, that isn't a problem with the kubelet/AMI. It may be related to this issue with the pod garbage collector: https://github.com/kubernetes/kubernetes/issues/118261


Fix precommit: should check all combinations of the options.

Now the precommit checks only the {release,debug} native targets and unittests
with all combinations. Because testing on every target needs a lots of efforts,
added a new target called "precommit_heavy".
This target checks all targets with every combinations.
JerryScript-DCO-1.0-Signed-off-by: Zsolt Borbély<EMAIL_ADDRESS>

The precommit fail related to #762.

@bzsolt, please rebase to the current master

LGTM

Landed in b8b587f76c41fcd3b46550642a64d0fad34f5610.

Sorry wrong PR :)

I've updated the PR, @akiss77 could you check it please?

LGTM (please rebase)

LGTM
@zherczeg, please check the changes.

LGTM


resin-init-flasher: The use of echo might differ between differnet sh…

@agherzan @floion
Signed-off-by: Theodor Gherzan<EMAIL_ADDRESS>

LGTM


Updated dependencies and did npm audit

Hey there! Thanks for the Pull request it looks great! Happy Hacktoberfest :)


⚠ Text Filter API Endpoint has degraded performance

In 80033f2, Text Filter API Endpoint (http://textfilter.roblox.com/) experienced degraded performance:

HTTP code: 200
Response time: 2078 ms

Resolved: Text Filter API Endpoint performance has improved in 496857d.


BTCPay improvements, RTL and BTC-RPC-Explorer update

btcpay: update to v<IP_ADDRESS> and fix folders
btcpaydata - store settings and invoices now stay after restore
The latest version fixes an error getting price data from BitcoinAverage
Introducing a BTCPayDomain variable to raspiblitz.conf. Possibly affecting: https://github.com/rootzoll/raspiblitz/issues/969
btc-rpc-explorer: update to 1.1.8 - tested ok

RTL now at official 0.6.1 and minimizing installed packages with npm install --only=production as suggested in: https://github.com/rootzoll/raspiblitz/issues/960#issuecomment-573360875


Error (403:Forbidden error) while downloading the weights of pointpillar model

I find the 403: Forbidden error when trying to download the weights of the model through the link: https://storage.googleapis.com/open3d-releases/model-zoo/pointpillars_kitti_202012171738utc.pth
I am unable to download the file even through the browser
Request you to take a look and correct it. Thanks

Could you please indicate where this URL comes from? I don't see any reference to it in torchvision's codebase

@NicolasHug Sorry, by mistake raised this issue in this forum. I was supposed to raise it in Open3D forum. Sorry!


cleanup scripts and a forgotten migration

sp_ticket_id is updated to recipient when placed rooms are transferred
find_drama checks rooms for known drama. we will keep / update this script.
fix_room fixes known drama in rooms. we will keep / update this script.
fix_swap "finishes" half-completed swaps. we will not keep / update this script once we are done the cleanup.
also i forgot a migration lol

pretty sure that this will definitively close #132 once we run the cleanup scripts


html & markdown preview

can you add preview for html & markdown?

The idea is good btw

can you add preview for html & markdown?

Why not? 🙂

There is a suggestion to make the file name display  instead. If the title is not in the code, then the file name

There is another suggestion, the preview display can be in desktop/mobile mode and can be zoomed in and zoomed out.

There is another suggestion, the preview display can be in desktop/mobile mode and can be zoomed in and zoomed out.

And you also need a java script console. Then it will be ready.

There is another suggestion, the preview display can be in desktop/mobile mode and can be zoomed in and zoomed out.

And you also need a java script console. Then it will be ready.

This will be added in next commit but it will take week because I am busy with other things


Support for Shemaless

When retrieving a SinkRecord from the Connect API the value type can be

Struct -> Shema with types
Map -> Map<String,Objects> without types
String -> unhandled
bytes[]  -> unhandled

Currently supporting the Map type is partial we would like to refactor a more complete and stable solution

@mzitnik "Shema" here is a mistype of Schema or something else?

Implemented & merge https://github.com/ClickHouse/clickhouse-kafka-connect/pull/27