Crash on latest MacOS 15.1 beta, and RC1, RC2 and Release

@martinfekete10
hello now i have another issue...
well the app crashes with the crash log you see i fully remove the app for testing but has the same crash....
see the log for more

Translated Report (Full Report Below)
Process:               Tuneful [722]
Path:                  /Applications/Tuneful.app/Contents/MacOS/Tuneful
Identifier:            com.Martin-Fekete.Tuneful
Version:               1.6.7 (1.6.7)
Code Type:             ARM-64 (Native)
Parent Process:        launchd [1]
User ID:               501
Date/Time:             2024-10-19 21:42:33.0629 +0300
OS Version:            macOS 15.1 (24B5077a)
Report Version:        12
Anonymous UUID:        D34575CD-EBBB-5F24-D100-957B2D98A06D
Time Awake Since Boot: 75 seconds
System Integrity Protection: enabled
Crashed Thread:        0  Dispatch queue: com.apple.main-thread
Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Exception Codes:       0x0000000000000001, 0x00000001022fab5c
Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Terminating Process:   exc handler [722]
Thread 0 Crashed::  Dispatch queue: com.apple.main-thread
0   Tuneful                       	       0x1022fab5c 0x1022c0000 + 240476
1   Tuneful                       	       0x1022e57e8 0x1022c0000 + 153576
2   Tuneful                       	       0x1022e4f18 0x1022c0000 + 151320
3   Tuneful                       	       0x10230924c 0x1022c0000 + 299596
4   Tuneful                       	       0x102309444 0x1022c0000 + 300100
5   SwiftUI                       	       0x1c7db8254 AppDelegate.applicationDidFinishLaunching(:) + 1024
6   SwiftUI                       	       0x1c7db8374 @objc AppDelegate.applicationWillFinishLaunching(:) + 192
7   CoreFoundation                	       0x198a9a800 CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER + 148
8   CoreFoundation                	       0x198b2b66c ___CFXRegistrationPost_block_invoke + 88
9   CoreFoundation                	       0x198b2b5b4 _CFXRegistrationPost + 436
10  CoreFoundation                	       0x198a6943c _CFXNotificationPost + 732
11  Foundation                    	       0x199c11b14 -[NSNotificationCenter postNotificationName:object:userInfo:] + 88
12  AppKit                        	       0x19c5d8614 -[NSApplication _postDidFinishNotification] + 284
13  AppKit                        	       0x19c5d83c4 -[NSApplication _sendFinishLaunchingNotification] + 172
14  AppKit                        	       0x19c5d6824 -[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:] + 500
15  AppKit                        	       0x19c5d642c -[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:] + 488
16  Foundation                    	       0x199c3a79c -[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:] + 316
17  Foundation                    	       0x199c3a594 _NSAppleEventManagerGenericHandler + 80
18  AE                            	       0x19ff88134 0x19ff7c000 + 49460
19  AE                            	       0x19ff87a58 0x19ff7c000 + 47704
20  AE                            	       0x19ff80fa4 aeProcessAppleEvent + 488
21  HIToolbox                     	       0x1a3e38c4c AEProcessAppleEvent + 68
22  AppKit                        	       0x19c5cfd00 DPSNextEvent + 1420
23  AppKit                        	       0x19cf0fe0c -[NSApplication(NSEventRouting) nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 688
24  AppKit                        	       0x19c5c2ae0 -[NSApplication run] + 480
25  AppKit                        	       0x19c599364 NSApplicationMain + 888
26  SwiftUI                       	       0x1c6c42340 specialized runApp(:) + 160
27  SwiftUI                       	       0x1c70b2ee4 runApp(:) + 84
28  SwiftUI                       	       0x1c742bf24 static App.main() + 224
29  Tuneful                       	       0x10230d154 0x1022c0000 + 315732
30  dyld                          	       0x19863c274 start + 2840
Thread 1:
0   libsystem_pthread.dylib       	       0x1989ba0e8 start_wqthread + 0
Thread 2:
0   libsystem_pthread.dylib       	       0x1989ba0e8 start_wqthread + 0
Thread 3:
0   libsystem_pthread.dylib       	       0x1989ba0e8 start_wqthread + 0
Thread 4:: caulk.messenger.shared:17
0   libsystem_kernel.dylib        	       0x19897ddb0 semaphore_wait_trap + 8
1   caulk                         	       0x1a39f20e0 caulk::semaphore::timed_wait(double) + 220
2   caulk                         	       0x1a39f1f8c caulk::concurrent::details::worker_thread::run() + 36
3   caulk                         	       0x1a39f1c60 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread*>>(void) + 96
4   libsystem_pthread.dylib       	       0x1989bf2e4 _pthread_start + 136
5   libsystem_pthread.dylib       	       0x1989ba0fc thread_start + 8
Thread 5:: caulk.messenger.shared:high
0   libsystem_kernel.dylib        	       0x19897ddb0 semaphore_wait_trap + 8
1   caulk                         	       0x1a39f20e0 caulk::semaphore::timed_wait(double) + 220
2   caulk                         	       0x1a39f1f8c caulk::concurrent::details::worker_thread::run() + 36
3   caulk                         	       0x1a39f1c60 void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread*>>(void) + 96
4   libsystem_pthread.dylib       	       0x1989bf2e4 _pthread_start + 136
5   libsystem_pthread.dylib       	       0x1989ba0fc thread_start + 8
Thread 0 crashed with ARM Thread State (64-bit):
x0: 0x00006000031c2f48   x1: 0x0000000200000003   x2: 0x0000000000000000   x3: 0x00006000031cd980
x4: 0x0000600000ab0580   x5: 0x0000000000000000   x6: 0x00000000000022a0   x7: 0x0000000000001600
x8: 0xfffffffe00000000   x9: 0x0000000200000003  x10: 0x0000000000000003  x11: 0x0000000000001940
x12: 0x00000000000007fb  x13: 0x00000000000007fd  x14: 0x000000009ee4c066  x15: 0x000000009ec4bffb
x16: 0x00000001a99f96b8  x17: 0x0000000000000066  x18: 0x0000000000000000  x19: 0x00006000031c2f40
x20: 0x00006000031cd8c0  x21: 0x0000000000000000  x22: 0x00006000031cd940  x23: 0xd000000000000012
x24: 0x00000000000001a8  x25: 0x000000010237d000  x26: 0x000000012871ac90  x27: 0x0000000000000001
x28: 0x0000000000000000   fp: 0x000000016db3dd00   lr: 0x00000001022fab5c
sp: 0x000000016db3dcd0   pc: 0x00000001022fab5c cpsr: 0x60001000
far: 0x0000000000000000  esr: 0xf2000001 (Breakpoint) brk 1
Binary Images:
0x1022c0000 -        0x10235bfff com.Martin-Fekete.Tuneful (1.6.7) <7d6bff4d-071c-3041-8aa5-52c1020e8d59> /Applications/Tuneful.app/Contents/MacOS/Tuneful
0x102488000 -        0x1024cbfff org.sparkle-project.Sparkle (2.5.1)  /Applications/Tuneful.app/Contents/Frameworks/Sparkle.framework/Versions/B/Sparkle
0x105fb4000 -        0x105fbffff libobjc-trampolines.dylib ()  /usr/lib/libobjc-trampolines.dylib
0x1072c0000 -        0x1079e3fff com.apple.AGXMetalG14X (322.10)  /System/Library/Extensions/AGXMetalG14X.bundle/Contents/MacOS/AGXMetalG14X
0x1c6bf6000 -        0x1c83b8fff com.apple.SwiftUI (<IP_ADDRESS>)  /System/Library/Frameworks/SwiftUI.framework/Versions/A/SwiftUI
0x198a28000 -        0x198f1cfff com.apple.CoreFoundation (6.9)  /System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x199c08000 -        0x19aa47fff com.apple.Foundation (6.9) <16dd093e-d6f4-36d3-b613-b421942590b1> /System/Library/Frameworks/Foundation.framework/Versions/C/Foundation
0x19c595000 -        0x19d990fff com.apple.AppKit (6.9) <9590e846-3e86-3ab6-98af-21f126fbfee1> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
0x19ff7c000 -        0x19fff0ff7 com.apple.AE (944)  /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE
0x1a3e0f000 -        0x1a4116fff com.apple.HIToolbox (2.1.1) <09a4ef71-958e-3515-ad71-00ac2a96c41a> /System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox
0x198636000 -        0x1986b87b7 dyld () <1a5989f6-6d3e-3db4-af88-abc6ba680754> /usr/lib/dyld
0x0 - 0xffffffffffffffff ??? () <00000000-0000-0000-0000-000000000000> ???
0x1a9621000 -        0x1a9bc7fff libswiftCore.dylib () <3f11f9f0-3e2d-381c-8c70-142f47e9ad1b> /usr/lib/swift/libswiftCore.dylib
0x1989b8000 -        0x1989c4fff libsystem_pthread.dylib () <97366a98-0b27-364f-bf0e-395bf521343f> /usr/lib/system/libsystem_pthread.dylib
0x19897d000 -        0x1989b7ff7 libsystem_kernel.dylib () <9fea25a4-e8ca-3f3d-901c-a53ff2bc7217> /usr/lib/system/libsystem_kernel.dylib
0x1a39f0000 -        0x1a3a17fff com.apple.audio.caulk (1.0) <09515a7f-2784-3a5f-a161-ca68012e418e> /System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk
External Modification Summary:
Calls made by other processes targeting this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by this process:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
Calls made by all processes on this machine:
task_for_pid: 0
thread_create: 0
thread_set_state: 0
VM Region Summary:
ReadOnly portion of Libraries: Total=1.2G resident=0K(0%) swapped_out_or_unallocated=1.2G(100%)
Writable regions: Total=851.3M written=466K(0%) resident=466K(0%) swapped_out=0K(0%) unallocated=850.8M(100%)
                            VIRTUAL   REGION

REGION TYPE                        SIZE    COUNT (non-coalesced)
===========                     =======  =======
Activity Tracing                   256K        1
AttributeGraph Data               1024K        1
ColorSync                          480K       24
CoreGraphics                        32K        2
Foundation                          16K        1
Kernel Alloc Once                   32K        1
MALLOC                           838.7M       47
MALLOC guard page                  384K       24
STACK GUARD                       56.1M        6
Stack                             10.6M        6
VM_ALLOCATE                        192K        6
__AUTH                            2849K      353
__AUTH_CONST                      39.1M      537
__CTF                               824        1
__DATA                            14.5M      517
__DATA_CONST                      17.1M      543
__DATA_DIRTY                      1350K      159
__FONT_DATA                        2352        1
__LINKEDIT                       586.1M        5
__OBJC_RW                         2354K        1
__TEXT                           672.2M      560
__TPRO_CONST                       272K        2
mapped file                      192.3M       19
owned unmapped memory               32K        1
page table in kernel               466K        1
shared memory                      912K       14
===========                     =======  =======
TOTAL                              2.4G     2833

Full Report
{"app_name":"Tuneful","timestamp":"2024-10-19 21:42:33.00 +0300","app_version":"1.6.7","slice_uuid":"7d6bff4d-071c-3041-8aa5-52c1020e8d59","build_version":"1.6.7","platform":1,"bundleID":"com.Martin-Fekete.Tuneful","share_with_app_devs":0,"is_first_party":0,"bug_type":"309","os_version":"macOS 15.1 (24B5077a)","roots_installed":0,"name":"Tuneful","incident_id":"77A247BF-ADC1-47E1-8C84-ADF34558B853"}
{
"uptime" : 75,
"procRole" : "Default",
"version" : 2,
"userID" : 501,
"deployVersion" : 210,
"modelCode" : "Mac14,13",
"coalitionID" : 791,
"osVersion" : {
"train" : "macOS 15.1",
"build" : "24B5077a",
"releaseType" : "User"
},
"captureTime" : "2024-10-19 21:42:33.0629 +0300",
"codeSigningMonitor" : 1,
"incident" : "77A247BF-ADC1-47E1-8C84-ADF34558B853",
"pid" : 722,
"translated" : false,
"cpuType" : "ARM-64",
"roots_installed" : 0,
"bug_type" : "309",
"procLaunch" : "2024-10-19 21:42:32.9031 +0300",
"procStartAbsTime" :<PHONE_NUMBER>,
"procExitAbsTime" :<PHONE_NUMBER>,
"procName" : "Tuneful",
"procPath" : "/Applications/Tuneful.app/Contents/MacOS/Tuneful",
"bundleInfo" : {"CFBundleShortVersionString":"1.6.7","CFBundleVersion":"1.6.7","CFBundleIdentifier":"com.Martin-Fekete.Tuneful"},
"storeInfo" : {"deviceIdentifierForVendor":"ACE16471-2CB0-5792-B160-F6F4998B792F","thirdParty":true},
"parentProc" : "launchd",
"parentPid" : 1,
"coalitionName" : "com.Martin-Fekete.Tuneful",
"crashReporterKey" : "D34575CD-EBBB-5F24-D100-957B2D98A06D",
"codeSigningID" : "com.Martin-Fekete.Tuneful",
"codeSigningTeamID" : "RM399ZL5B5",
"codeSigningFlags" :<PHONE_NUMBER>,
"codeSigningValidationCategory" : 3,
"codeSigningTrustLevel" :<PHONE_NUMBER>,
"instructionByteStream" : {"beforePC":"n2ooOJMOAPngAxSq/XtDqfRPQqn2V0Gp+F/EqMADX9bgAxOq1/YAlA==","atPC":"IAAg1P8DAtHpIwFt/G8CqfpnA6n4XwSp9lcFqfRPBqn9ewep/cMBkQ=="},
"bootSessionUUID" : "116F8FE3-B0F4-4511-8E11-C7E7B4FBF644",
"sip" : "enabled",
"exception" : {"codes":"0x0000000000000001, 0x00000001022fab5c","rawCodes":[1,4331645788],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
"termination" : {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace/BPT trap: 5","byProc":"exc handler","byPid":722},
"os_fault" : {"process":"Tuneful"},
"extMods" : {"caller":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"system":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"targeted":{"thread_create":0,"thread_set_state":0,"task_for_pid":0},"warnings":0},
"faultingThread" : 0,
"threads" : [{"triggered":true,"id":9242,"threadState":{"x":[{"value":105553168445256},{"value":8589934595,"symbolLocation":67,"symbol":"OBJC_CLASS_RO$GEOPDSearchQueryTokenImportanceMetadata"},{"value":0},{"value":105553168488832},{"value":105553127474560},{"value":0},{"value":8864},{"value":5632},{"value":18446744065119617024},{"value":8589934595,"symbolLocation":67,"symbol":"OBJC_CLASS_RO$GEOPDSearchQueryTokenImportanceMetadata"},{"value":3},{"value":6464},{"value":2043},{"value":2045},{"value":2665791590},{"value":2663694331},{"value":7140775608,"symbolLocation":0,"symbol":"swift_release"},{"value":102},{"value":0},{"value":105553168445248},{"value":105553168488640},{"value":0},{"value":105553168488768},{"value":14987979559889010706},{"value":424},{"value":4332179456},{"value":4973505680},{"value":1},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":4331645788},"cpsr":{"value":1610616832},"fp":{"value":6135471360},"sp":{"value":6135471312},"esr":{"value":4060086273,"description":"(Breakpoint) brk 1"},"pc":{"value":4331645788,"matchesCrashFrame":1},"far":{"value":0}},"queue":"com.apple.main-thread","frames":[{"imageOffset":240476,"imageIndex":0},{"imageOffset":153576,"imageIndex":0},{"imageOffset":151320,"imageIndex":0},{"imageOffset":299596,"imageIndex":0},{"imageOffset":300100,"imageIndex":0},{"imageOffset":18621012,"symbol":"AppDelegate.applicationDidFinishLaunching(:)","symbolLocation":1024,"imageIndex":4},{"imageOffset":18621300,"symbol":"@objc AppDelegate.applicationWillFinishLaunching(:)","symbolLocation":192,"imageIndex":4},{"imageOffset":468992,"symbol":"CFNOTIFICATIONCENTER_IS_CALLING_OUT_TO_AN_OBSERVER","symbolLocation":148,"imageIndex":5},{"imageOffset":1062508,"symbol":"___CFXRegistrationPost_block_invoke","symbolLocation":88,"imageIndex":5},{"imageOffset":1062324,"symbol":"_CFXRegistrationPost","symbolLocation":436,"imageIndex":5},{"imageOffset":267324,"symbol":"_CFXNotificationPost","symbolLocation":732,"imageIndex":5},{"imageOffset":39700,"symbol":"-[NSNotificationCenter postNotificationName:object:userInfo:]","symbolLocation":88,"imageIndex":6},{"imageOffset":275988,"symbol":"-[NSApplication _postDidFinishNotification]","symbolLocation":284,"imageIndex":7},{"imageOffset":275396,"symbol":"-[NSApplication _sendFinishLaunchingNotification]","symbolLocation":172,"imageIndex":7},{"imageOffset":268324,"symbol":"-[NSApplication(NSAppleEventHandling) _handleAEOpenEvent:]","symbolLocation":500,"imageIndex":7},{"imageOffset":267308,"symbol":"-[NSApplication(NSAppleEventHandling) _handleCoreEvent:withReplyEvent:]","symbolLocation":488,"imageIndex":7},{"imageOffset":206748,"symbol":"-[NSAppleEventManager dispatchRawAppleEvent:withRawReply:handlerRefCon:]","symbolLocation":316,"imageIndex":6},{"imageOffset":206228,"symbol":"_NSAppleEventManagerGenericHandler","symbolLocation":80,"imageIndex":6},{"imageOffset":49460,"imageIndex":8},{"imageOffset":47704,"imageIndex":8},{"imageOffset":20388,"symbol":"aeProcessAppleEvent","symbolLocation":488,"imageIndex":8},{"imageOffset":171084,"symbol":"AEProcessAppleEvent","symbolLocation":68,"imageIndex":9},{"imageOffset":240896,"symbol":"DPSNextEvent","symbolLocation":1420,"imageIndex":7},{"imageOffset":9940492,"symbol":"-[NSApplication(NSEventRouting) nextEventMatchingEventMask:untilDate:inMode:dequeue:]","symbolLocation":688,"imageIndex":7},{"imageOffset":187104,"symbol":"-[NSApplication run]","symbolLocation":480,"imageIndex":7},{"imageOffset":17252,"symbol":"NSApplicationMain","symbolLocation":888,"imageIndex":7},{"imageOffset":312128,"symbol":"specialized runApp(:)","symbolLocation":160,"imageIndex":4},{"imageOffset":4968164,"symbol":"runApp(:)","symbolLocation":84,"imageIndex":4},{"imageOffset":8609572,"symbol":"static App.main()","symbolLocation":224,"imageIndex":4},{"imageOffset":315732,"imageIndex":0},{"imageOffset":25204,"symbol":"start","symbolLocation":2840,"imageIndex":10}]},{"id":9246,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":13}],"threadState":{"x":[{"value":6136033280},{"value":3331},{"value":6135496704},{"value":0},{"value":409604},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6136033280},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6855303400},"far":{"value":0}}},{"id":9249,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":13}],"threadState":{"x":[{"value":6136606720},{"value":5379},{"value":6136070144},{"value":0},{"value":409604},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6136606720},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6855303400},"far":{"value":0}}},{"id":9250,"frames":[{"imageOffset":8424,"symbol":"start_wqthread","symbolLocation":0,"imageIndex":13}],"threadState":{"x":[{"value":6137180160},{"value":17923},{"value":6136643584},{"value":0},{"value":409604},{"value":18446744073709551615},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":0},"cpsr":{"value":4096},"fp":{"value":0},"sp":{"value":6137180160},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6855303400},"far":{"value":0}}},{"id":9251,"name":"caulk.messenger.shared:17","threadState":{"x":[{"value":14},{"value":105553154778490},{"value":0},{"value":6137753706},{"value":105553154778464},{"value":25},{"value":0},{"value":0},{"value":0},{"value":4294967295},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":18446744073709551580},{"value":8687611792},{"value":0},{"value":105553149342128},{"value":105553149342128},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7040082144},"cpsr":{"value":2147487744},"fp":{"value":6137753472},"sp":{"value":6137753440},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6855056816},"far":{"value":0}},"frames":[{"imageOffset":3504,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":14},{"imageOffset":8416,"symbol":"caulk::semaphore::timed_wait(double)","symbolLocation":220,"imageIndex":15},{"imageOffset":8076,"symbol":"caulk::concurrent::details::worker_thread::run()","symbolLocation":36,"imageIndex":15},{"imageOffset":7264,"symbol":"void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread*>>(void)","symbolLocation":96,"imageIndex":15},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":13},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":13}]},{"id":9252,"name":"caulk.messenger.shared:high","threadState":{"x":[{"value":14},{"value":105553154776828},{"value":0},{"value":6138327148},{"value":105553154776800},{"value":27},{"value":0},{"value":0},{"value":0},{"value":4294967295},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":18446744073709551580},{"value":8687611792},{"value":0},{"value":105553149342544},{"value":105553149342544},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0},{"value":0}],"flavor":"ARM_THREAD_STATE64","lr":{"value":7040082144},"cpsr":{"value":2147487744},"fp":{"value":6138326912},"sp":{"value":6138326880},"esr":{"value":1442840704,"description":" Address size fault"},"pc":{"value":6855056816},"far":{"value":0}},"frames":[{"imageOffset":3504,"symbol":"semaphore_wait_trap","symbolLocation":8,"imageIndex":14},{"imageOffset":8416,"symbol":"caulk::semaphore::timed_wait(double)","symbolLocation":220,"imageIndex":15},{"imageOffset":8076,"symbol":"caulk::concurrent::details::worker_thread::run()","symbolLocation":36,"imageIndex":15},{"imageOffset":7264,"symbol":"void* caulk::thread_proxy<std::__1::tuple<caulk::thread::attributes, void (caulk::concurrent::details::worker_thread::)(), std::__1::tuplecaulk::concurrent::details::worker_thread*>>(void)","symbolLocation":96,"imageIndex":15},{"imageOffset":29412,"symbol":"_pthread_start","symbolLocation":136,"imageIndex":13},{"imageOffset":8444,"symbol":"thread_start","symbolLocation":8,"imageIndex":13}]}],
"usedImages" : [
{
"source" : "P",
"arch" : "arm64",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "1.6.7",
"CFBundleIdentifier" : "com.Martin-Fekete.Tuneful",
"size" : 638976,
"uuid" : "7d6bff4d-071c-3041-8aa5-52c1020e8d59",
"path" : "/Applications/Tuneful.app/Contents/MacOS/Tuneful",
"name" : "Tuneful",
"CFBundleVersion" : "1.6.7"
},
{
"source" : "P",
"arch" : "arm64",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "2.5.1",
"CFBundleIdentifier" : "org.sparkle-project.Sparkle",
"size" : 278528,
"uuid" : "f6d9e0bb-3dec-34d5-8524-32b314d93248",
"path" : "/Applications/Tuneful.app/Contents/Frameworks/Sparkle.framework/Versions/B/Sparkle",
"name" : "Sparkle",
"CFBundleVersion" : "2032"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"size" : 49152,
"uuid" : "f1242604-dcb7-30a9-a19a-182991e6e645",
"path" : "/usr/lib/libobjc-trampolines.dylib",
"name" : "libobjc-trampolines.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "322.10",
"CFBundleIdentifier" : "com.apple.AGXMetalG14X",
"size" : 7487488,
"uuid" : "f6817cf9-b70f-382a-839f-1fdd973b9138",
"path" : "/System/Library/Extensions/AGXMetalG14X.bundle/Contents/MacOS/AGXMetalG14X",
"name" : "AGXMetalG14X",
"CFBundleVersion" : "322.10"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "<IP_ADDRESS>",
"CFBundleIdentifier" : "com.apple.SwiftUI",
"size" : 24915968,
"uuid" : "f7866487-a2e8-3a43-b954-928209003d9c",
"path" : "/System/Library/Frameworks/SwiftUI.framework/Versions/A/SwiftUI",
"name" : "SwiftUI",
"CFBundleVersion" : "<IP_ADDRESS>"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.CoreFoundation",
"size" : 5197824,
"uuid" : "ae4610f8-7c5c-3484-858e-cae7457d206e",
"path" : "/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation",
"name" : "CoreFoundation",
"CFBundleVersion" : "3107"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.Foundation",
"size" : 14942208,
"uuid" : "16dd093e-d6f4-36d3-b613-b421942590b1",
"path" : "/System/Library/Frameworks/Foundation.framework/Versions/C/Foundation",
"name" : "Foundation",
"CFBundleVersion" : "3107"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "6.9",
"CFBundleIdentifier" : "com.apple.AppKit",
"size" : 20955136,
"uuid" : "9590e846-3e86-3ab6-98af-21f126fbfee1",
"path" : "/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit",
"name" : "AppKit",
"CFBundleVersion" : "2575.20.20"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "944",
"CFBundleIdentifier" : "com.apple.AE",
"size" : 479224,
"uuid" : "c859086e-8eb3-3969-8e2b-3a748120dab7",
"path" : "/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/AE.framework/Versions/A/AE",
"name" : "AE",
"CFBundleVersion" : "944"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "2.1.1",
"CFBundleIdentifier" : "com.apple.HIToolbox",
"size" : 3178496,
"uuid" : "09a4ef71-958e-3515-ad71-00ac2a96c41a",
"path" : "/System/Library/Frameworks/Carbon.framework/Versions/A/Frameworks/HIToolbox.framework/Versions/A/HIToolbox",
"name" : "HIToolbox"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"size" : 534456,
"uuid" : "1a5989f6-6d3e-3db4-af88-abc6ba680754",
"path" : "/usr/lib/dyld",
"name" : "dyld"
},
{
"size" : 0,
"source" : "A",
"base" : 0,
"uuid" : "00000000-0000-0000-0000-000000000000"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"size" : 5926912,
"uuid" : "3f11f9f0-3e2d-381c-8c70-142f47e9ad1b",
"path" : "/usr/lib/swift/libswiftCore.dylib",
"name" : "libswiftCore.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"size" : 53248,
"uuid" : "97366a98-0b27-364f-bf0e-395bf521343f",
"path" : "/usr/lib/system/libsystem_pthread.dylib",
"name" : "libsystem_pthread.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"size" : 241656,
"uuid" : "9fea25a4-e8ca-3f3d-901c-a53ff2bc7217",
"path" : "/usr/lib/system/libsystem_kernel.dylib",
"name" : "libsystem_kernel.dylib"
},
{
"source" : "P",
"arch" : "arm64e",
"base" :<PHONE_NUMBER>,
"CFBundleShortVersionString" : "1.0",
"CFBundleIdentifier" : "com.apple.audio.caulk",
"size" : 163840,
"uuid" : "09515a7f-2784-3a5f-a161-ca68012e418e",
"path" : "/System/Library/PrivateFrameworks/caulk.framework/Versions/A/caulk",
"name" : "caulk"
}
],
"sharedCache" : {
"base" :<PHONE_NUMBER>,
"size" :<PHONE_NUMBER>,
"uuid" : "e45a8bfa-06ca-35cb-9bc8-16faca8ebabd"
},
"vmSummary" : "ReadOnly portion of Libraries: Total=1.2G resident=0K(0%) swapped_out_or_unallocated=1.2G(100%)\nWritable regions: Total=851.3M written=466K(0%) resident=466K(0%) swapped_out=0K(0%) unallocated=850.8M(100%)\n\n                                VIRTUAL   REGION \nREGION TYPE                        SIZE    COUNT (non-coalesced) \n===========                     =======  ======= \nActivity Tracing                   256K        1 \nAttributeGraph Data               1024K        1 \nColorSync                          480K       24 \nCoreGraphics                        32K        2 \nFoundation                          16K        1 \nKernel Alloc Once                   32K        1 \nMALLOC                           838.7M       47 \nMALLOC guard page                  384K       24 \nSTACK GUARD                       56.1M        6 \nStack                             10.6M        6 \nVM_ALLOCATE                        192K        6 \n__AUTH                            2849K      353 \n__AUTH_CONST                      39.1M      537 \n__CTF                               824        1 \n__DATA                            14.5M      517 \n__DATA_CONST                      17.1M      543 \n__DATA_DIRTY                      1350K      159 \n__FONT_DATA                        2352        1 \n__LINKEDIT                       586.1M        5 \n__OBJC_RW                         2354K        1 \n__TEXT                           672.2M      560 \n__TPRO_CONST                       272K        2 \nmapped file                      192.3M       19 \nowned unmapped memory               32K        1 \npage table in kernel               466K        1 \nshared memory                      912K       14 \n===========                     =======  ======= \nTOTAL                              2.4G     2833 \n",
"legacyInfo" : {
"threadTriggered" : {
"queue" : "com.apple.main-thread"
}
},
"logWritingSignature" : "f23de90ca43093f6a5ce26292b643d9c52d42976",
"trialInfo" : {
"rollouts" : [
{
"rolloutId" : "5f72dc58705eff005a46b3a9",
"factorPackIds" : {
  },
  "deploymentId" : 250000014
},
{
  "rolloutId" : "639124e81d92412bfb4880b3",
  "factorPackIds" : {

  },
  "deploymentId" : 250000011
}

],
"experiments" : [
{
"treatmentId" : "993c66e1-bf83-41fd-a09f-0d8d5906d223",
"experimentId" : "664fc3cd79a61a0b8b557292",
"deploymentId" : 500000013
}
]
}
}

Hi, I am not experiencing this issue on my computer (M1 Macbook Air). Could you find and send me this file ~/Library/Preferences/com.Martin-Fekete.Tuneful.plist? It contains your Tuenful preferences (e.g. if you are using minimal or full popover) and I'm thinking it can be caused by some of the preferences

Sure but I’m sure will be empty or on default settings cause I remove the app completely for testing 29 Οκτ 2024, 11:59, ο χρήστης «Martin Fekete @.***>» έγραψε:
Hi, I am not experiencing this issue on my computer (M1 Macbook Air). Could you find and send me this file ~/Library/Preferences/com.Martin-Fekete.Tuneful.plist? It contains your Tuenful preferences (e.g. if you are using minimal or full popover) and I'm thinking it can be caused by some of the preferences
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

I just published a new release, try to check if it doesn't resolve the issue

@martinfekete10
i have the same issue the app won't even start just creates a caches folder and a log....
don't know what's happening before the latest macos 15.1 beta dont remember the number works as intented after that all the updates that i had had the same effect the app won't open. i attach the log file if helps....
Tuneful-2024-10-29-232017.txt

I'm making a clean installation to test it even further, fingers crossed to be that the issue...

@martinfekete10
i made a clean installation of macOS 15.1 Release and i have the same issue sadly.
its the only app i have and acts like this...hope for a fix!

I just release a new version v1.7.1 which migh have resolved this issue, let me know if it persists or not


fix: traps v3 and logging

:tada: This PR is included in version 0.11.0-beta.25 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


[vulnerabilities_fixed_60_days] all medium and high severity vulnerabilities must be resolved within 60 days

(This is required for lowest level passing for CII.)
There MUST be no unpatched vulnerabilities of medium or high severity that have been publicly known for more than 60 days.
The vulnerability must be patched and released by the project itself (patches may be developed elsewhere). A vulnerability becomes publicly known (for this purpose) once it has a CVE with publicly released non-paywalled information (reported, for example, in the National Vulnerability Database) or when the project has been informed and the information has been released to the public (possibly by the project). A vulnerability is medium to high severity if its CVSS 2.0 base score is 4 or higher. Note: this means that users might be left vulnerable to all attackers worldwide for up to 60 days. This criterion is often much easier to meet than what Google recommends in Rebooting responsible disclosure, because Google recommends that the 60-day period start when the project is notified even if the report is not public. Also note that this badge criterion, like other criteria, applies to the individual project. Some projects are part of larger umbrella organizations or larger projects, possibly in multiple layers, and many projects feed their results to other organizations and projects as part of a potentially-complex supply chain. An individual project often cannot control the rest, but an individual project can work to release a vulnerability patch in a timely way. Therefore, we focus solely on the individual project's response time. Once a patch is available from the individual project, others can determine how to deal with the patch (e.g., they can update to the newer version or they can apply just the patch as a cherry-picked solution).
(see: https://github.com/coreinfrastructure/best-practices-badge/blob/master/doc/criteria.md#vulnerabilities_fixed_60_days)

This is tied into https://github.com/odpi/egeria/issues/1386 - if you put together a security issue management process this would likely be taken care of.

I can work on an initial draft to this & also extend to documenting in our scan processes (there is some already) both in the code (pmd/spotbugs), and externally (sonar cloud for code issues) and most specifically our CLM scans & OWASP build flag

I think we have a process now, and don't currently have open CVEs. See #1386.


Remove unused samples attrs

Description
Removing unused columns from our db and unused code related to those columns
Checklist:

[x] I have run through the testing script to make sure current functionality is unchanged
[x] I have done relevant tests that prove my fix is effective or that my feature works
[x] I have spent time testing out edge cases for my feature
[x] New and existing unit tests pass locally with my changes

@cdebourcy we still need the memory fields right?


Interplanetary nearby

A majority of our users lives on planet Earth.
So until space travel becomes more common, I suggest not showing other planets' Wikidata items in Nearby.
Items on other planets also use the same Wikidata property, see for instance https://www.wikidata.org/wiki/Q634366
We should accept items that have no P376 (located on astronomical body) or that have one set to Earth.
Low priority, as there are still few Wikidata-documented objects on other planets. I just stumbled upon one, tough.

P8981 (lunar coordinates) solves the problem for Lunar places, furthering lowering this issue's priority.
But still, we can't expect a new property to be created for every astronomical body.


Use usdt instead of usd for Bitfinex

Bitfinex uses USD but it's just another tether. We should use usdt everywhere for consistency.

I found out that CCXT uses two ways of describing ID's of assets. This is my little workaround for when I know an exchange has no fiat pairs.
    ```
    market_universe = exchange.load_markets()
    for x in market_universe:
        if 'quoteId' in market_universe[x]:
            base = market_universe[x]['quoteId']
        else:
            base = market_universe[x]['quote']

        # We catch USD/USDT naming differences between exchanges here
        # This does not work for exchanges that actually use USD (fiat) trading pairs
        if context.base_currency == 'usd':
            if base.lower() == 'usdt':
                context.base_currency = 'usdt'

Thanks for posting this @salihkilic!


[Feature Request] Search Bar

Adding a search bar for google/duckduckgo/etc. With option of above or below the Featured Links section if possible.

@evlsmurf What exactly is the use case for this? Since on all major browsers, the address bar always doubles up as a search bar.
The search in the app currently is configured to only search for existing links on the start page. I could overload it to also search using a search provider, but that is a lot of work and want to understand the requirement before i decide to rework that section.

Just for searching, guess i just got use to using them from other startpages. Not necessarily needed like u said.

https://github.com/ashwin-pc/hiccup/pull/3

@evlsmurf I see why most start pages use it now. Hope you like this implementation.


How can I make changes to the stylesheet?

For some reason when I try to make changes to the scss files they never show up. I even tried completely deleting lines of code and its styling will still be there. For example, I've completely deleted lines 22-24 of ionic-material/src/scss/elements/item.scss yet the border-radius is still in effect. And this is just one of a few changes I've been trying to make. I even tried running ionic setup sass again and still the original ionic-material styles will show. Is there anything special I'm supposed to be doing to see my changes reflect?

Ah thanks,  I'll give this a try when I begin working again

Nope, this solution didn't work. It sort of just freezes my developer tools panel. I currently have to just manually override everything in my styles.css. If there's a better solution out there, I'd greatly appreciate it. Thanks for trying though @blinksmith

Do check if there is some error comes whenever you change scss file.


Remove DoubleLimb abstraction in favor of overflow builtins

If I think hard enough, we should be able to use mulWithOverflow and addWithOverflow to perform the carry and borrow primitive operations. The bonus this has is that we can then operate on 64-bit words on x64_64 instead of 32-bit words that we currently are (with DoubleLimb being a typedef for a 64-bit word).

It might be worth double checking to make sure that it would actually be a performance win to do so. I probably don't know what I'm talking about, but I've heard stories of things like SIMD being a surefire performance boost until it's tested and it turns out cache misses were the bottleneck all along. But i like the idea of using the biggest primitives possible just on principle, even if the performance boost is negligible.

Definitely right in that profiling would be beneficial to actually determine the improvement.
As some consolation GMP seems to be using the native word size in their code so I would expect it has some worthwhile benefits.
https://github.com/omco/gmp/blob/f7a8037df5b01f4e40a9d2e71ab6fdda749a7df9/mpn/x86_64/gmp-mparam.h

Wow! This is exciting.


Remove extra ColumnLayouts

Follow up to #203

Update from 0e2e651 to f9f46e7

Potential maximum width solution for issue @jarolrod  pointed out

Update from f9f46e7 to 4dc32c4:

Fix NodeSettings padding/margins by setting the Page padding values instead of using anchors.


think

to finish the project,I should split the project to multiple mission.

[x] crawl service--2015-01-13
[x] node service--2015-01-14
[x] test--2015-01-15
[x] demo--2015-01-16

demo is finish now,so close it


Review accuracy of Civil Parishes in FC1 vld files

We now test the civil parish in csv files against the PARMS to ensure that they are entered correctly.
As far as I am aware the old vld files loaded into FC1 did not have this check. In addition the FC2 PARMS was updated during the cutover to the new system.
The work that was done linking the PARMS has made our public searches more accurate. However the historic data has not had the alignment done.
Can we get a report on the civil parishes that do not align with the PARMS please?
We will need the piece number, ED number and the civil parish that has been recorded but dos not appear in the PARMS against that piece. We also need the PARMS civil parishes for that piece. We only need a report entry once for every unique civil parish in an ED within a piece where there is not a match.
Once we know the extent of the problem then we can take action to update the historic data and that will make our existing searches more accurate.
I am not sure what the impact of breaking down pieces into parts in FC2 will have on this report. We need to have a look at this as well and this report will show us whether there has been any.
Geoff

@geoffj-FUG could you clearly identify the purpose of this activity. Why do we need to do it?
I know you say "make our existing searches more accurate" but I fail to see how.
@PatReynolds for information
You may recall that in the latter part of last year we made the transition to use FreeCEN2 Places for both input streams instead of Places (freecen1) for vld files and FreeCEN2 Places for csv. This ensured that we used a consistent place name and its location. The latter enabled the reintroduction of the Nearby Places option. Personally I am not convinced that neither the team nor the research community realise the significance of this transition.
As we say in the Help for researchers
A Place is usually the location associated with the Registration Sub District used by the Census Enumerator: where this is unknown we use the location of the Registration District. With the transcriptions started in 2021 we use the location that is associated with the Civil Parish and which provides a more localised set of records.
Fundamentally this means that csv records are searched with a greater granularity than vld records.
We achieved this by connecting every vld to its appropriate freecen2_piece and its freecen2_place. All search records for each vld were then updated to include the information for freecen2_place.
As you are all too aware vld files are not segregated by ED or civil parish hence FreeCEN2 has never had a civil parish or ED search capability.
This is because there is fundamental difference in the design of FreeCEN2 compared with FreeCEN1.
FreeCEN1 had 2 search collections (Tables). A Household collection that contained all of the fields for a dwelling (Census	County	District	Civil Parish	Ecclesiastical Parish	  Piece	Enumeration District	Schedule	House Number	House or Street Name) each of which was indexed and an Individual collection with each individual and all its fields joined to its household.
FreeCEN2 only has a single search collection. The search record. This has only a few of the individual fields and a very few household fields(Census	County Place). However for vlds it displays the details from 2 non searchable collections (dwellings and individuals) and for csv from the csv entries collection.
**Bottom line is that the FreecCEN1 search is a much more powerful search engine than the current implementation of FreeCEN2 **
In summary, the Ecclesiastical Parish, ED and Civil Parish information displayed by FreeCEN2 are informational items only.
The enormous amount of work being proposed in this story to reconcile the Ecclesiastical Parish, ED and Civil Parish in vld entries with the FreeCEN2 parameters is only warranted if it is intended to add these as searchable fields in what one would likely want to call FreeCEN3!

The first step would be making the civil parish and ecclesiastical parish entries for a file consistent.
There are 10557 vld files. These have 18160 unique values of civil parishes and 16645 ecclesiastical parish in freecen_dwellings. There was no quality control on these fields so there are variations.
Some examples of the variation in civil parish names as entered.
"Toxteh Park",
"Toxteht Park",
"Toxteth Park",
"Toxteth Park Lan",
"Toxtheth Park",
    "Upton Cum Chalvey",
    "Upton Cum Chanley",
    "Upton Cun Chalvey",
    "Upton With Chalvey",

This work alone I estimate to be a 21 .
The second step would be to compare the civil parish names for a vld file with the freecen2_civil_parish names for the freecen2_piece of the vld files. I estimate to be a 21 level of effort

Kirk
That is exactly why I created this story.
There was no quality control on the entries. Your examples of Toxteth Park show that the problem may be bigger than I anticipated.
The civil parish was entered by the transcriber regularly throughout an ED, rather than just at the first entry as we now do in FC2. That means that the entry could be mis-typed within the ED.
The ecclesiastical parish is a bigger problem. When WinCC was set up the Ecclesiastical Parish field was completed using references transferred to WinCC from the PARMS. This created a debate when we redeveloped the front end of FreeCEN2 as CSVProc regarding TNA records and the recording of civil or ecclesiastical parishes. It is now well established that the PARMS contains civil parishes not ecclesiastical parishes. The amount of data affected is huge so we must assume that we cannot do anything with it. We would need to go back and check every ED in every piece to correct the problem. So, in my view, the ecclesiastical parish data is a loss. It is not practical to bring it up to scratch and we do not have a reference file to compare it with.
The wish to upgrade the search report capabilities of FC2 to match FC1 has been raised as the next step in the development of FC2. The accuracy of any new searches is dependent on the accuracy of the underlying data. The civil parish data struck me as an area that might be able to be improved given that it is usually limited to one entry per ED, and for those EDs with more than one civil parish it is only a very few. Hence the desire to see how big the problem was by doing a match with the PARMS to identify those civil parishes not in the PARMS.
I had not expected to see the results in Kirk’s review of the data, given that the process is Transcribe, Proofread and Validate. It shows that the Proofreader has not been picking up these typos. The Validator would not have seen them as they were not tested in Valdrev as they are now by the CSVProc upload.
We have also made the effort to align the PARMS with the Gazetteer, with a significant loss of Coordinator goodwill in the process. So, one step in the integrity links has already been achieved.
It strikes me that the need to identify these civil parish variations is now even more important as they affect the usefulness of the collected data. We have introduced the data integrity tests into FC2 so it seems logical to at least examine the extent of this data mismatch problem.
If it is practicable to update the civil parish data then it becomes possible to use this field to search, for instance the civil parish as a sub-set of the census place or maybe even as an optional alternative to the census place.
I am not sure what a 21 work estimate means.  Is there a scale reference that I can look at please?
Geoff
From: Kirk Dawson @.>
Sent: Saturday, 26 March 2022 1:29 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: geoffj-FUG @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Review accuracy of Civil Parishes in FC1 vld files (Issue #1397)
The first step would be making the civil parish and ecclesiastical parish entries for a file consistent.
There are 10557 vld files. These have 18160 unique values of civil parishes and 16645 ecclesiastical parish in freecen_dwellings. There was no quality control on these fields so there are variations.
Some examples of the variation in civil parish names as entered.
"Toxteh Park",
"Toxteht Park",
"Toxteth Park",
"Toxteth Park Lan",
"Toxtheth Park",
"Upton Cum Chalvey",
"Upton Cum Chanley",
"Upton Cun Chalvey",
"Upton With Chalvey",

This work alone I estimate to be a 21 .
The second step would be to compare the civil parish names for a vld file with the freecen2_civil_parish names for the freecen2_piece of the vld files. I estimate to be a 21 level of effort
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1397#issuecomment-1079142032 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFL737SFLGLSCR5ME5DVBXLVJANCNFSM5RQ6XAVQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFK5OFOEJUNVYTS7CRTVBXLVJA5CNFSM5RQ6XAV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIBJGNEA.gif Message ID: @.*** @.***> >

@geoffj-FUG efforts are ball park guess of the amount of time an experienced person might take. 1 is a line of code; 3 is an hour or so; 5 up to a day; 8 up to a week; 13 up to a month; 21 up to 4 months; 40 a year or more.

Thank you
Geoff
From: Kirk Dawson @.>
Sent: Sunday, 27 March 2022 8:05 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: geoffj-FUG @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Review accuracy of Civil Parishes in FC1 vld files (Issue #1397)
@geoffj-FUG https://github.com/geoffj-FUG  efforts are ball park guess of the amount of time an experienced person might take. 1 is a line of code; 3 is an hour or so; 5 up to a day; 8 up to a week; 13 up to a month; 21 up to 4 months; 40 a year or more.
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1397#issuecomment-1079783491 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFO2R4AWRPTS5WDQ23LVB6CX3ANCNFSM5RQ6XAVQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFPHO3DXV2OZKSTDZMTVB6CX3A5CNFSM5RQ6XAV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOIBODAQY.gif Message ID: @.*** @.***> >

We need to revisit the FreeCEN roadmap, and allocate this to a part of it.

Pat
This is just one story.
The Epic is review accuracy of existing data uploaded from FC1. There are several issues involved. All issues are created by vld files having no integrity testing. All csv files uploaded now are integrity tested but vld files uploaded now are not and can’t be.
The first thing that we should clean-up is the Civil Parishes. These were repetitively entered in FC1 and not tested. The incidence of typos is significant. (For csv files they are entered once per ED  unless they change within an ED and integrity tested against the PARMS). The other cause of incorrect civil parishes is the need in FC1 to abbreviate some of them to fit the spreadsheet column width (which was governed by Wincc and Valdrev constraints).
At the moment researchers cannot search against the civil parishes within a piece. If they could the search would produce poor results because many civil parishes are mis-spelt.
Once cleaned up we have the option of introducing searching civil parishes as a subset of the Registration District (or even of the County).
The second data field that needs looking at is the Places of Birth. There are a huge number of entries on the database that are not in the Gazetteer. There are a number of causes including (in no particular order) typos, abbreviations, validators adding incorrect spellings to their test file to eliminate repetitive mis-spellings by the enumerators. Places we have not yet added to the Gazetteer, the Gazetteer now using the greater to smaller rule etc.
No work can start on POB searching until this has been sorted out.
FC1 and FC2 have different validation policies –
FC1 was if there is evidence that a place reasonably existed, pass it or note that it cannot be located.
FC2 is if a place is in the Gazetteer pass it or note that it cannot be located. If it is in the Gazetteer it existed, has a url as a reference and as it is geolocated it can be linked to Google Maps and its location displayed. It is this change in policy that will make high quality POB searching possible.
Any attempt to move forward on searching at the moment will result in a garbage in, garbage out scenario.
So I agree, we need to revisit the roadmap, because at the moment there is a huge hole in the road!
Geoff
From: PatReynolds @.>
Sent: Thursday, April 7, 2022 2:08 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: geoffj-FUG @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Review accuracy of Civil Parishes in FC1 vld files (Issue #1397)
We need to revisit the FreeCEN roadmap, and allocate this to a part of it.
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1397#issuecomment-1090446770 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFIWM4BB6ZOFR7MWOUDVDWZGTANCNFSM5RQ6XAVQ .
You are receiving this because you were mentioned.Message ID: @.***>

There is no Epic with the word Review in it (there is only one Epic - the Accessibility Review.  Do you mean this story is an epic? Or should I create an epic and put this and other stories in it?

This would be part of the clean-up of the vld files. It cannot proceed until the vld uploads are no longer happening.
Geoff

This story should be given priority over #1458 as it affects current searches. The other story affects future searches.
Geoff

Although this is blocked by story Cease vld Uploads is it possible to develop the report now so that we can see the magnitude of the problem. We can then decide how best to tackle the amendments.

@AnneV-Learn
Story #1397 (was in product backlog but I have moved it to In Progress). – this can be commenced prior to the vld data collection being closed as any problems will be one-off for each piece.
Can we get a report of pieces with Civil Parishes that are not in the PARMS please? We will need the piece number, ED number and the civil parish that has been recorded but does not appear in the PARMS against that piece. Unique (Piece Number, ED, Civil Parish), where Civil parish for that piece is not in the PARMS. We only need a report entry once for every unique civil parish in an ED within a piece where there is not a match. We also need the PARMS civil parishes for that piece, but we can look those up in the County options (we must anyway to ascertain where the problem is).
There will be occasions where there is a mismatch between the piece number in the data set and the piece number in the PARMS. So, our report should test for the first characters followed by a underscore and then the text before the next underscore in the PARMS. That will eliminate problems with the PARMS numbering.
This report will be run no more than half a dozen times – once for the first pass, again when the data has been amended, again when we close vld uploads and again when any additional problems have been fixed. (plus a couple for retries!).
If it can be in csv format then the report can be loaded into a spreadsheet and amendments managed with the spreadsheet.
Geoff

@geoffj-FUG I have coded the rake task to do this and Vino deployed it to Test3 today. I constructed it so that it works through a max of 500 VLD files at a time (although it does work on complete counties, so if it hits the limit of 500 vld files part way through a county it will go on to complete that county but not move onto the next county). This was done so that running it across the Production environment would be manageable. It outputs a log file (summarising the processing) and a CSV file. The file names include the span of chapman codes that it covers.
In the CSV file you may see MISSING in the fc2_piece_number and/or fc2_piece_civil_parishes column, this indicates the link from the VLD file to the fc2 Params is missing, which may occur quite a lot on the Test3 database as to my knowledge the test data there has never been fully updated to the full fc2 structures across the board and certainly does contain anomalies.
I just ran it once on Test3 today and I will email you the output files for your review and comment before  progressing any further.

Anne
That report looks great, thank you.
The Missing links that I have looked at so far are all Scotland. We will need to address this if there is not a Scottish PARMS data available yet. One option would be to copy the FC1 PARMS for Scotland into the new version. However I suspect that something exists because otherwise our searches would not work.
What really stands out in the report is that we need to be able to do a find/replace on the civil parishes, in order:
Find all '&' and replace with ' and '
Find all full stops and replace with a space
Find all commas and replace with a space
Find all space space and replace with space (to remove double spaces generated by above replacements).
Can we arrange for these find/replacements in the main data set please and thn run the report on the main database.
Can I have an option in the vld files menu to run the report County by County please? It will need to be at Master Coordinator and Data Manager level. Then I can start looking at the necessary changes.
We will also need a passworded find / replace that I can run to fix up civil parish names. It should be limited to changes within a particular piece.
Geoff

@geoffj-FUG Bear in mind that the report I sent you was from the Test3 data and only covered chapman codes AGY - CAE.
I’ll start looking at how best to do the Civil Parish find/replace (lots of records to work through there) and adding the option to run the CP not in PARMS report from the Manage VLD page.

@AnneV-Learn
The characters that I identified are not standardised but create ERROR messages. That is why they need amending.
I made Vino aware at the scrum that I was suggesting a find/replace. You may like to discuss this functionality with her.
She is happy for us to work on the vld data collection itself, but is still thinking about how to achieve it.
Geoff

@geoffj-FUG
I realise that the characters that you identified are not standardised but was wondering regardless of that if I should be comparing standardised place names in the listing of invalid civil parishes in VLD file data.
Yes I will discuss the whole find/replace requirement with @Vino-S when I have given it some more thought myself.

The special characters advised by Kirk never seem to have been implemented. I have therefore amended the Handbook to show the original text. The priority now is to have an edit function available to me so that I can amend civil parishes within a piece. This should be on the vld dataset and can be implemented as soon as it is available.
Geoff

In discussion with Lemon about the issue

Lemon has fixed spawned process issue, just needs testing that the fix works.

Thanks @vino-s  - that appears to have fixed the spawned process issue on Test3.

@geoffj-FUG Just to let you know that I have completed the 'cleaning' of the production VLD file Civil Parish names as per your specification:
Find all '&' and replace with ' and '
Find all full stops and replace with a space
Find all commas and replace with a space
Find all space space and replace with space.
I hope to have the Listing of Invalid Civil Parishes and Editing of Civil Parishes for VLD files available for testing on Test3 soon.

@geoffj-FUG The VLD File List Invalid Civil Parishes and Edit Civil Parish functionality is Ready for Testing on Test3. I have sent you an email to explain what is there.

Anne
The spreadsheet looks good.
In addition to my query just now, I think that FreeCEN searching uses the text converted to lower case. Look at Row 75 in the spreadsheet for Somerset. Weston super Mare is correct in the PARMS but there is an upper case in the civil parish.
If the system converts to lower case for searching can we allow the Weston Super Mare version through with no impact?
There will be several of these instances. If we can ignore the case then can you amend the code to do that please? It will make life so much easier.
Geoff
From: Anne Vandervord @.>
Sent: Thursday, 23 February 2023 2:41 AM
To: FreeUKGen/FreeCENMigration @.>
Cc: Geoff J @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Review accuracy of Civil Parishes in FC1 vld files (Issue #1397)
@geoffj-FUG https://github.com/geoffj-FUG  The VLD File List Invalid Civil Parishes and Edit Civil Parish functionality is Ready for Testing on Test3. I have sent you an email to explain what is there.
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1397#issuecomment-1440393092 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFNNSMN4UA244YEMDPLWYY6QBANCNFSM5RQ6XAVQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFN56NIUKUEZBKNP2VLWYY6QBA5CNFSM5RQ6XAV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOKXNKPBA.gif Message ID: @.*** @.***> >

Anne
The find/replace function works perfectly.
Can we change it so that it cycles back to the Edit form please? You will see from the Somerset spreadsheet that there may be many entries for the same piece. By cycling back to the edit form I will not have to keep selecting Show for the same piece.
Geoff

@geoffj-FUG - CSVProc validation of Civil Parish does indeed match the lowercase version of the name, so I'll make that change to the Listing of Invalid Civil Parishes.
I'll also change so that it returns to the Edit page (rather than the index) after a successful edit.
I'll let you know when Test3 code has been updated so that you can then re-test.

Ok this changes have now been deployed to Test3, so ready for you to test @geoffj-FUG
Could you also confirm that system_administrator, data_manager and master_county_cooordinator are the correct roles to have access to the new List Invalid and Edit Civil Parishes functionality.

Anne
Can you make it available to Coordinators.
Although I will not be asking coordinators to do it, I know that there are a couple who will.
I will have a look at it now.
Geoff
From: Anne Vandervord @.>
Sent: Thursday, 23 February 2023 8:08 PM
To: FreeUKGen/FreeCENMigration @.>
Cc: Geoff J @.>; Mention @.>
Subject: Re: [FreeUKGen/FreeCENMigration] Review accuracy of Civil Parishes in FC1 vld files (Issue #1397)
Ok this changes have now been deployed to Test3, so ready for you to test @geoffj-FUG https://github.com/geoffj-FUG
Could you also confirm that system_administrator, data_manager and master_county_cooordinator are the correct roles to have access to the new List Invalid and Edit Civil Parishes functionality.
—
Reply to this email directly, view it on GitHub https://github.com/FreeUKGen/FreeCENMigration/issues/1397#issuecomment-1441490952 , or unsubscribe https://github.com/notifications/unsubscribe-auth/AKCPIFPN5ELAPS2WKPCOFPTWY4ZJPANCNFSM5RQ6XAVQ .
You are receiving this because you were mentioned.  https://github.com/notifications/beacon/AKCPIFIQRZMHXMZV7XFF3WTWY4ZJPA5CNFSM5RQ6XAV2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOKXVWQCA.gif Message ID: @.*** @.***> >

Anne
That is all very good. I have now come across another problem. If you look at RG511923 there are a whole series of entries for Bishops Lydeard (same for North Petherton in the next piece). You will see that there are lots of options in the PARMS listing. So I need to be able to choose whether I am amending the whole piece or just the ED. Otherwise I will be changing every entry in the piece and not be able to see what has been changed (in other words I can make a mess).
That was an unforeseen problem.
Can you put this option in please?
Maybe we can put a list box with the EDs that the selected entry occurs in (or even with all the ED numbers) so that the ED can be selected and the change only happen in that ED. Make the first option All EDs. The submit button would be below this box.
Geoff

Anne
It has just struck me that another option is to list the ED next to the civil parish in the dropdown listing of the edit form. Then that can be selected and the change made to that ED alone. EDs will need to be looked at individually when these instances occur so it will not make a big difference to the work involved fixing the entries up.
Geoff

@geoffj-FUG Yes I did wonder if that might be acceptable. Keeps the form simple too. I’ll re-code for that and then you can re-test to assess if it is practical. Thinking the drop-down would show ED followed by ‘ - ‘ then the Civil Parish eg ‘1 - Farncombe’, is that ok or would you prefer a different format?

Anne
Yes. 1 - Farncombe format will be good.
Geoff

@geoffj-FUG Test3 has now been updated as discussed above.
Well slight change - the  dropdown shows ED followed by ‘ -- ‘ then the Civil Parish eg ‘1 -- Farncombe’ so has to clearly differentiate from Civil Parishes names that could contain single hyphens.
So over to you for re-testing.

See story #1493 this additional action at data manager level will be needed to clean up the civil parish entries. The Scotland Coordinator will also need this new action.
Anne, How big a task is it please?

This looks good and works well. I have marked it as ready for deployment. I have created story #1497 to enable an action that we will need to complete this task.
Geoff

I have thought about permissions. Yes, make it available to coordinators as well please
Geoff

Works well in live system. However I have found a new issue.
If we have a look at the Somerset listing we have HO107944. It is showing a mismatch. In the PARMS there are two entrie that make up the piece - HO107_944A and HO107_944B. The entry has only been tested by the routine against 944A. It has rejected the entries in 944B. So we need some way of making sure that we test against all the PARMS entries.
This has occurred because the vld data is not split into the new pieces but is one intact piece.
Geoff

@geoffj-FUG OK I’ll look into that. I didn’t realise that one VLD file could be linked to more than one PARMS record.

@geoffj-FUG I’ve updated the code for the report and it is now available for testing on Test3.

I don't have suitable data in the test3 environment. Thats why it was missed during test last time.
Deploy it and I will check it there. I am the only user so the risk is very low.
Geoff

@geoffj-FUG If I have understood the issue correctly I think SOM HO511925.VLD might be a case you could check on Test3.

Another request please. Can we ignore hyphens in the PARMS please and treat them as a space? I have worked through about 17- changes and am beginning to pick up these little quirks.
Geoff

Anne
Looks good. Fingers crossed!
Geoff

Deployed: closing


Error: https://json-schema.org/draft/2020-12/schema is not a schema. Found a document with media type: application/octet-stream

I'm guessing you're looking for a JSON Schema validator that supports 2020-12. You'll find that at https://github.com/hyperjump-io/json-schema-validator. This package is used to create custom dialects and probably not what you are looking for. If I'm wrong, please ask a question and I'll do my best to help.

Hi @jdesrosiers,
Thanks for your response.
But we are using this package in our Node.js Project ( package version is<EMAIL_ADDRESS>).
After deployment, this project in AWS lambda shows project size is more them 3.2 MB.
Because of this https://bundlephobia.com/package/<EMAIL_ADDRESS>Can please help me on this.

I think you meant to make that comment on https://github.com/hyperjump-io/json-schema-validator/issues/13


<nuxt-link> without to props crash

Versions

nuxt: 2.15.8
node: 16.14.0

Steps to reproduce

In you nuxt app, add a <nuxt-link to="/">, the page render correctly.
Remove the to="/", the page crash and Nuxt show the error.vue layout.

What is Expected?
The page shouldn't crash. <nuxt-link> without to props should be treated like links without href and redirect to the root /.
What is actually happening?
The page crash with a nuxt fatal error:

Cannot read properties of undefined (reading '_normalized')

please , provide  the full list of error log.

Yes, but it shouldn't crash the whole app if it's missing showing the Nuxt Error page.

I realise this is a vue-router issue, so i opened: https://github.com/vuejs/router/issues/1648


D35E System Support

It would be nice to include the formulas for the Dungeons & Dragons 3.5e system (https://foundryvtt.com/packages/D35E/).
The appropriate formulas are:

Lockpick<EMAIL_ADDRESS>Break<EMAIL_ADDRESS>
That should be all to get it working.
(Foundry VTT v11.313 | D35E v2.3.2)
All the best and thanks for this useful module.

Sure, i will add it with the next update. Glad you enjoy the module.

I have added the default formulas and few other default values for D&D 3.5e with v1.10.6


Fix onboarding link in README

Description
The current org readme links to the onboarding guide at https://github.com/opensearch-project/.github/blob/main/profile/ONBOARDING.md, which is a 404. This updates the link to the correct location.
It may at some point be worthwhile to run a link checker in the repo to find other dead links.
Issues Resolved
N/A
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

It may be better to close this in favor of #206 since those changes are a superset of this. Will leave this open for now since it's already approved and fixes the only Lychee true-positive.

Closing after #206 .


monero: 0.10.1 -> <IP_ADDRESS>

Motivation for this change
bump to latest upstream
Things done

[x] Tested using sandboxing
(nix.useSandbox on NixOS,
or option build-use-sandbox in nix.conf
on non-NixOS)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] Linux

[x] Tested compilation of all pkgs that depend on this change using nix-shell -p nox --run "nox-review wip"
[x] Tested execution of all binary files (usually in ./result/bin/)
[x] Fits CONTRIBUTING.md.

sorry for the noise, pushed an incorrect branch earlier. this should fix the travis build.

Thanks!


XCode 11 SPM support

Updated package definition to comply with Swift Tools 5.1 and XCode 11
Moved MortarVFL to default source folder
Fixed iOS version compatibility errors when used as package

This will break the podspec, as-is.  I'll land and clean up a bit


SCF TPL Builds

Description
Addresses bullets in #20036

update config site files for SCF TPL builds
TPL builds are done on both magma and sierra but I still need to update the sierra config site.

Type of change

[ ] Bug fix
[ ] New feature
[ ] Documentation update
[x] Other~~
config site files

How Has This Been Tested?

will test when I do builds/installs
Reminders:

Please follow the style guidelines of this project.
Please perform a self-review of your code before submitting a PR and asking others to review it.
Please assign reviewers (see VisIt's PR procedures for more information).

Checklist:

[ ] I have commented my code where applicable.
[ ] I have updated the release notes.
[ ] I have made corresponding changes to the documentation.
[ ] I have added debugging support to my changes.
[ ] I have added tests that prove my fix is effective or that my feature works.
[ ] I have confirmed new and existing unit tests pass locally with my changes.
[ ] I have added new baselines for any new tests to the repo.
[ ] I have NOT made any changes to protocol or public interfaces in an RC branch.

merge w/ develop in #20106


Binding to non-null IEnumerable doesn't work

When using the binding feature in the config system, for IEnumerable collections that have a default, non-null value, the collection is never assigned into the target model. For example:
For this json:
{
  "config": {
    "data": [ "a", "b" ]
  }
}

and this application code:
 public class Config
    {
        IEnumerable<string> _data = new List<string>();
        public IEnumerable<string> Data
        {
            get
            {
                return _data;
            }
            set
            {
                _data = value;
            }
        }
    }

    public class Program
    {
        public static void Main(string[] args)
        {
            var config = new ConfigurationBuilder()
                .SetBasePath(Directory.GetCurrentDirectory())
                .AddJsonFile("test.json")
                .Build();

            var val = config.GetSection("config").Get<Config>();
            Console.WriteLine(val?.Data?.Count());
        }
    }

The output is:
0
Press any key to continue . . .

I'd expect it to print "2".
I'd argue the issue is in BindInstance and explicit handling for IEnumerable should be made (much like the check for IsArray https://github.com/aspnet/Configuration/blob/dev/src/Microsoft.Extensions.Configuration.Binder/ConfigurationBinder.cs#L281).

@ajcvickers - any updates on when this is going to be fixed? Thank you!

@lbogdanov It's currently in the backlog, which means it's not going to be fixed in an upcoming release. Beyond that, it will depend on prioritization against other work.

The correct behaviour is to overwrite. Not append.
This is how other collections behave, and its generally how a json parser behaves regarding default values on a POCO.


pretrained.th

Dear professor syuqings,
Strictly follow REDME ,In the third step of the training,Why was the post-training assessment not as high as the second-training model?Am I loading and training the pretrained.th the wrong way?
Looking forward to your reply

Hi, I'm sorry to make the confusion. Actually, there are two training stages in total, not three.
The first stage is trained with the cross-entropy. In this stage, you can choose to train the model with full video frames (step 1 in the readme), or train the model with only key frames (step 3 in the readme).
The second stage is fine-tuning the model in the first stage with rl.
In the normal setting, you don't need to perform the step 3 in the readme.
I will update the readme to avoid the confusion.


Enable theme mode dark for heatmap

Is there any method to change default heatmap fill #fff to #192734
?
theme: {
   mode: 'dark',
},

Not working for heatmap. Preview:

Related to #1532

PR #1666 fixes this.


Much less than, much greater than symbols

It would be nice to have ≪ and ≫ in asciimath

Unfortunately << and >> are already used as input symbols for angle brakets, so I'm not sure what a reasonable input symbol for these would be.

I think a text-based symbol would be fine. mtg and mlt would be fine

In the areas where I do research, the expression
f << g
has the same meaning as
f = O(g) ,
where big-O notation is being used in that equation.
So in that context, ll and gg would be reasonable notations.
However, in that context << does not mean "much less than".
See
https://math.stackexchange.com/questions/199753/how-does-one-read-aloud-vinogradovs-notation-ll-and-ll-epsilon
It could be a bad idea to implement notation with a
different meaning that is commonly used.
On Sat, 3 Nov 2018, TMiguelT wrote:

I think a text-based symbol would be fine. mtg and mlt would be fine
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the
thread.[AAM6LO1QQ5vMNZkRPNv7ZElFZ6gteigUks5urldSgaJpZM4YNGOo.gif]

Thanks David, it's helpful to know the symbol has other meanings in other contexts.
I agree that reusing the LaTeX symbols, ll and gg, seems like a reasonable approach.

Hi, I would need that one too :)


Noufalrahim/feat/added units to pressure sore

Proposed Changes

Fixes #8209
Added Units
Added Units to i18n locale files (Consultation.json)
More?

@ohcnetwork/care-fe-code-reviewers
Merge Checklist

[ ] Add specs that demonstrate bug / test a new feature.
[ ] Update product documentation.
[ ] Ensure that UI text is kept in I18n files.
[ ] Prep screenshot or demo video for changelog entry, and attach it to issue.
[ ] Request for Peer Reviews
[ ] Completion of QA

@noufalrahim please add human firendly title and description for the PR. We also expect you to complete the #Merge Checklist
cc @rithviknishad

@noufalrahim can you push the changes requested by @bodhish


Decentralisation

Can the transactions and wallet generation be created and signed locally and broadcasted to the node at a later stage?

Now you can rem sendrawtransaction and change output log "result"  txid : sign_result,
//let broadcast_result = await exe(btc_cli_path + ' sendrawtransaction "'+sign_result.hex+'" ' + max_fee);
        //broadcast_result = broadcast_result.trim();

        const result = {
            error : false,
            txid : sign_result,
            amount : amount.toString()
        };

I don't think the problem is in the broadcasting, it's rather in the wallet creation and the fact that a name collision can essentially allow a bad actor to "steal" another user funds

sorry for the misunderstanding, I thought you were interested in how to verify a transaction before sending it.
As for the node, you mean if someone uses rpcallowip=*?

I mean like creating the wallet on the local machine and then using pipe to submit the transaction without exposing the private key itself

Probably we just need to understand how we can as xverse or similar wallets (using satsconnect) give us a fresh new wallet, like a change wallet for example. In this case we can avoid pipe website generate privkeys and exposing them to the public

Simply avoiding to call the fundrawtransaction calls and adding the --disable-private-key flag during wallet creation should do the trick, then users have to sign and broadcast the transaction locally. What do you think? @BennyTheDev


how to use the search api with POST method by the default client

Hi, can you provide some information about the Elasticsearch version you're executing the requests against, and also about the environment (ie. is any proxy involved) and hosting (ie. how is the cluster deployed/hosted)?

Hello, any news here? Search API should work with a GET request under normal circumstances, so that's why I'm wondering about the environment.

Could we reopen this issue? Migrating from "github.com/olivere/elastic", i am trying to use POST for the _search api. It is important to us, because our queries are sometimes longer than GET permits.


BUG: The avatar field is not working in the profile form (uploadfield).

The avatar field is not working in the profile form (uploadfield).
The image is uploaded but it is not linked to the member record, for some reason in ForumMemberProfile it works better and it does not have this problem.
From what I've seen, it may be solved by this:
https://github.com/silverstripe/sapphire/pull/1862
https://github.com/tractorcow/sapphire/blob/3.1-uploadfield-enhancement-unsquashed/docs/en/reference/uploadfield.md
Regards,
Jose A.

Thank you for your contribution here. I just wanted to let you know that we’re looking to improve our management of issues and pull requests, with a goal to providing clear direction on how Symbiote contributes to the open source community. As part of this ongoing effort:

issues and pull requests that have been open prior to December 2017 with no recent activity are being closed

this is included

if you can confirm this remains applicable for SS3.6+ please do open it again

remaining issues and pull requests will be

categorised

on a clear path to resolution (whatever the next step may be).

This ultimately brings us one step closer to our ambition; being able to prioritise current issues and contributions in a timely manner. If you have any questions, please see https://www.symbiote.com.au/contributing for further information.


DockingUI.initialize makes things worse?

I see in the single-app MainFrame demo a mention of DockingUI.initialize().  If I have FlatLaf installed and I add this line it turns the three dots on the right into a white square:

If I ignore DockingUI.initialize() it shows up correctly.

Also worth noting the X on each tab shows up in FlatLaf but not if I use
UIManager.setLookAndFeel(UIManager.getSystemLookAndFeelClassName());

The icon might be an issue with the module changes I made. I'll give that a look later.
The X is a special feature of FlatLaf. The System Look and Feel that comes with Swing doesn't provide it.

The icon thing was an issue with loading resources. It is fixed in the latest 0.11.0-SNAPSHOT.

Nice.  Woah, the new ... is super dark on the Light version.
On Wed, Dec 13, 2023 at 5:46 PM Andrew Auclair @.***>
wrote:

The icon thing was an issue with loading resources. It is fixed in the
latest 0.11.0-SNAPSHOT.
—
Reply to this email directly, view it on GitHub
https://github.com/andrewauclair/ModernDocking/issues/151#issuecomment-1854974037,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AALFRBQIPW27AU5SLLBEFTTYJJK65AVCNFSM6AAAAABATSWS6GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQNJUHE3TIMBTG4
.
You are receiving this because you authored the thread.Message ID:
@.***>

--
Dan Royer
Owner, Marginally Clever Robots, Ltd.
1<PHONE_NUMBER> <16042599564> @.***
https://marginallyclever.com http://www.marginallyclever.com
https://www.facebook.com/MarginallyClever/
https://www.instagram.com/imakerobots/
https://www.youtube.com/channel/UCfbRxqjuOgE2EzRKxcePArw
https://twitter.com/MarginallyC https://github.com/MarginallyClever/

The icon is an svg and gets colored based on the UI property TableHeader.foreground. That probably should be more configurable.

[ ] Make Docking UI extension svg colors customizable


json::array::erase(it) seg fault on linux

array::erase(it) seg faults when called on a thread other than the main thread
environment:
$ uname -a
Linux localhost.localdomain 5.16.18-200.fc35.x86_64 #1 SMP PREEMPT Mon Mar 28 14:10:07 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
$ gcc --version
gcc (GCC) 11.2.1 20220127 (Red Hat 11.2.1-9)
tested on boost 1.76.0 and 1.78.0
example code attached:
test.zip
regards,
jeremy godfrey

This fails for me without a separate thread
    void
    testIssue692()
    {
	    array a;
	    object obj;
	    obj["test1"] = "hello";
	    a.push_back(obj);
	    a.push_back(obj);
	    a.push_back(obj);
	    a.push_back(obj);
	    a.push_back(obj);
	    while(a.size())
		    a.erase(a.begin());
    }

Congrats Jeremy :)

great, thanks Vinnie


[SPARK-18874][SQL][FOLLOW-UP] Improvement type mismatched message

What changes were proposed in this pull request?
Improvement IN predicate type mismatched message:
Mismatched columns:
[(, t, 4, ., `, t, 4, a, `, :, d, o, u, b, l, e, ,,  , t, 5, ., `, t, 5, a, `, :, d, e, c, i, m, a, l, (, 1, 8, ,, 0, ), ), (, t, 4, ., `, t, 4, c, `, :, s, t, r, i, n, g, ,,  , t, 5, ., `, t, 5, c, `, :, b, i, g, i, n, t, )]

After this patch:
Mismatched columns:
[(t4.`t4a`:double, t5.`t5a`:decimal(18,0)), (t4.`t4c`:string, t5.`t5c`:bigint)]

How was this patch tested?
unit tests

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/1281/
Test PASSed.

Test build #93506 has started for PR 21863 at commit e455bda.

Could you add a test case?

Test build #93506 has finished for PR 21863 at commit e455bda.

This patch fails Spark unit tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test FAILed.

Test FAILed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93506/
Test FAILed.

@gatorsmile Hi sean, isn't @mgaido91 working in the same area with the in subq pr ?

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/testing-k8s-prb-make-spark-distribution-unified/1297/
Test PASSed.

Test build #93529 has started for PR 21863 at commit e55d700.

@gatorsmile Got it. Thank you.

Test build #93529 has finished for PR 21863 at commit e55d700.

This patch passes all tests.
This patch merges cleanly.
This patch adds no public classes.

Merged build finished. Test PASSed.

Test PASSed.
Refer to this link for build results (access rights to CI server needed):
https://amplab.cs.berkeley.edu/jenkins//job/SparkPullRequestBuilder/93529/
Test PASSed.

Thanks! Merged to master.

a late LGTM


Workflow Engine

Is there an existing issue for this?

[X] I have searched the existing issues

Is your feature request related to a problem? Please describe the problem.
We need a solution to building complex style workflows in Medulla. This is to orchestrate longer business oriented tasks and procedures.
In the past we have looked at Argo Workflows, and is still on the table but I want to open the discussion to additional options.
Describe the solution you'd like
This is an investigation oriented task with the goal of finding a proper solution to handle workflows for Medulla. Overall for this to be considered complete we must come to a consensus on what workflow engine to use. Even if one is not listed yet in this ticket, we are open to ideas so long as they meet the following requirements:

Runs on k8s
Can be deployed as a part of a helm chart
Open source

Additional context
General Workflow Engine List:

Awesome Workflow Engines

Some initial options:

Argo Workflows
Brigade
Workflow Core
WorkflowEngine.NET

Can we look into terraform as an option for a workflow engine?

we can also utilize terragrunt as a wrapper that provides additional tools.

Code-Red looks interesting. I think it would be worth exploring.


Remote OCommand update not reloading vertex (v2.1.x)

When an SQL Update command is run using the Graph API connected to a remote database, the update saves to the database but when the vertex is retrieved using getVertex(rid), a stale version is retrieved. NOTE: This issue is not seen when running against a local database.
This has been observed in v2.1.x.
Here is a example code to reproduce there error:
OrientGraph g = factory.getTx();  // Using remote OrientGraphFactory (ie. remote:localhost/testdb)

OrientVertex v = g.addVertex(null);
v.setProperties("Counter", 0);
g.commit();

System.out.println(v.getProperties() + ", version=" + v.getRecord().getVersion());
v = g.getVertex(v.getId());

String cmd = String.format("UPDATE %s SET Counter = 10", v.getId());
g.command(new OCommandSQL(cmd)).execute();

v = g.getVertex(v.getId());
//v.reload();
System.out.println(v.getProperties() + ", version=" + v.getRecord().getVersion());

factory.close();

If run as is output looks like:
{Counter=0, @rid=#9:29, @class=V}, version=1
{Counter=0, @rid=#9:29, @class=V}, version=1
If you uncomment the //v.reload output looks like:
{Counter=0, @rid=#9:30, @class=V}, version=1
{Counter=10, @rid=#9:30, @class=V}, version=2

Hi @crbaptiste
In current release it is a known limitation and the expected behavior.
Please check the docs here
http://orientdb.com/docs/last/Transactions.html
Thanks
Luigi

I had already read that doc, but I missed that the OCommand happens outside the transaction.
Is this something that future versions will remedy or a limitation that we just need to get used to?

Hi @crbaptiste
We will implement server-side transactions in the future, so this problem will be eventually fixed, but in the short term I think you will have to deal with this limitation.
Thanks
Luigi

Thanks for the clarification!


As a Mac User, I need to configure the container logs window to use larger text and remember my settings after relaunch

Hi @andynawabi
Yep, we received the same issues already. After next release, we'll make a roadmap for v2, one of main part will be template system, where each user can customize a view.

great to know, I like what you've developed so far.
On Wed, Dec 5, 2018 at 6:13 PM Igor Kozlovsky<EMAIL_ADDRESS>wrote:

Hi @andynawabi https://github.com/andynawabi
Yep, we received the same issues already. After next release, we'll make a
roadmap for v2, one of main part will be template system, where each user
can customize a view.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/DockStation/dockstation/issues/154#issuecomment-444723068,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AFTdaBF0FDuEFgVfcugvgG96llNwYO_Pks5u2H0sgaJpZM4Y9mqS
.

I need this feature, too...


WIP: chore: use ts 3.4 to build, use incremental builds

What?
...
Why?
...

This is being implemented by #197


[BUG] Aether mod prevents setting bedrock on fire for Grains of Infinity

Is there an existing issue for this?

[X] I have searched the existing issues

Current Behavior
When The Aether is loaded with EnderIO, setting bedrock on fire to get Grains results in 0% chance of getting them.
Expected Behavior
Lighting a dozen or so blocks should net ~6 grains after the fires goes out.
Steps To Reproduce

Place several Bedrock blocks in creative
Light them all on fire

Environment
- OS: Windows 10
- Java version:  17.0.6
- Minecraft version: 1.20.1
- Version: 6.0.23 alpha
- The Aether - 1.20.1-1.1.0-neoforge (its for Forge too)

Anything else?
Behaviour is the same in creative or survival
Without Aether, grains spawn as expected.
This might be relevent:
https://github.com/The-Aether-Team/The-Aether/blob/58a7331c5707fc6991a86304857f5c215dd4edc3/src/main/java/com/aetherteam/aether/world/AetherLevelData.java
Line 23:
this.gameRules = new WrappedGameRules(worldData.getGameRules(), ImmutableSet.of(GameRules.RULE_WEATHER_CYCLE, GameRules.RULE_DOFIRETICK));
doFireTick is true in the test vanilla superflat world though

while it is 50% chance to spawn grains of infinity, but i believe this maybe on Aether side, we will have look at it, Aether does do weird shit to the game like overhaul Vanilla's play style

Is there an alternative setting or workaround for making Grains of Infinity?

I am also having this issue, I have no idea how to fix this besides removing the Aether mod or something, but that will break my current survival world and I don't really wanna get rid of the Aether in the first place

Could you open this issue on The Aether's issue tracker as well? I try to look into bugs that are reported there as quickly as I can. From a quick look though I have no concrete ideas; my first guess would be there has to be some kind of conflict preventing code in the FireCraftingHandler class from running, but there's no event cancellation so that makes the theory a bit confusing.

Could you open this issue on The Aether's issue tracker as well? I try to look into bugs that are reported there as quickly as I can. From a quick look though I have no concrete ideas; my first guess would be there has to be some kind of conflict preventing code in the FireCraftingHandler class from running, but there's no event cancellation so that makes the theory a bit confusing.

Thanks for looking into this :) if it leads you to something that's being done incorrectly on our end, please let us know, thanks!

Also ran into this issue, and I believe I tracked down the cause. Did some testing and found that disabling doFireTick would actually make it work. Dug into the code and it appears that the issue is caused by a specific interaction between Aether's method of disabling fire ticks in its dimension, and EnderIO's fallback path for when doFireTick is disabled.
https://github.com/Team-EnderIO/EnderIO/blob/91b6719254a126a0d6d1843142a859fe67a03a39/src/main/java/com/enderio/base/common/handler/FireCraftingHandler.java#L143-L167
Aether mod makes doFireTick false for its dimension only, which triggers this code path. Since there is no check for which dimension the tracked fire is in, it tries to find the fire blocks in the wrong dimension, and stops tracking when it of course doesn't find fire at the expected positions. If I understand the code correctly, this may also be broken when you have doFireTick disabled and try to make grains of infinity in any dimension other than the overworld, though I didn't actually test that.
I made a patch locally, and confirmed that adding a check for the matching dimension in the loop fixes the issue. Conveniently, the FireIndex record already has this info, so it's an easy 1-2 line change.

Away from my pc so unable to double check this, but it makes complete sense! Thanks a lot for looking into this, feel free to send a PR if you would like :)

There ya go!


⚠ AlphaRatio has degraded performance

In 6cfe46f, AlphaRatio ($AR) experienced degraded performance:

HTTP code: 200
Response time: 735 ms

Resolved: AlphaRatio performance has improved in 87339ab.


FetchArt / EmbedArt - fetch art from specific url

if not found or if set in options prompt for a url from where to get the album art
.. so that we dont have to download it and use the [-f IMAGE] option :)

to develop this further: this could be an additional source for fetchart, e.g. url. which alway prompts for an url but otherwise having the same flow.


[documentation] - update lessons component documentation

### SRS List of Lessons New. documentation was update.


chore: bump various k8s.io components' version

Description
Dependabot is having issues with bumping multiple k8s.io components' version due to dependency issues. This PR consolidated all version bumps.
Related Issue
If this pull request is related to any issue, please mention it here. Additionally, make sure that the issue is assigned to you before submitting this pull request.
Checklist

[ ] I have read the contributing documentation.
[ ] I signed and signed-off the commits (git commit -S -s ...). See this documentation on signing commits.
[ ] I have correctly attributed the author(s) of the code.
[ ] I have tested the changes locally.
[ ] I have followed the project's style guidelines.
[ ] I have updated the documentation, if necessary.
[ ] I have added tests, if applicable.

Screenshots (if applicable) or Testing Completed
Please add any relevant screenshots or GIFs to showcase the changes made.
Additional Notes
Add any additional notes or context about the pull request here.

Please refer to the CONTRIBUTING.md file for more information on how to contribute to this project.

@nddq can you dust this off and bump to k8s 1.30.1 like I did in https://github.com/microsoft/retina/pull/395?
critically we need controller runtime 0.18+


ESA 1.0.1 not compatible with ember-data < 1.13?  handleResponse doesn't exist on beta18

Not sure if this is mentioned anywhere, as I can't see a minimum requirement for ember-data (only ember at 1.12), but it does seem like ember-simple-auth requires ember-data 1.13 (if ember-data is used).
In particular, the DataAdapterMixin uses the handleResponse callback, however, handleResponse does not exist until ember-data 1.13, ajaxError and ajaxSuccess are used on prior versions.
I'm working on polyfilling this to make our app work right now, but might want to update the minimum requirements somewhere and mention the ember-data version.
There are also issues with ember-data beta19.2 due to initializers, store:main, store:application, and service:store registry names... I could not actually even get anything to load on beta19.2.  Rolling back to 19.1 fixed some of the initializer issues, but broke other parts of our app, hence forcing me to rollback to beta18.
Here's some of the issues I encountered:
Ember 1.11.3, ESA 0.8, ember-data beta16 = everything works, but ESA is using old API
upgraded to:
Ember 1.12.1, ember-data beta19.2, ESA 0.8 = everything works, but tons of deprecations due to initializer/instance initializer errors
After following the ESA upgrade guide and upgrading to ESA 1.0.1 and refactoring our session service, upgraded to:
Ember 1.12.1, ember-data beta19.2, ESA 1.0.1 = everythings broke, due to some interaction between ESA 1.0.1 and ember-data beta 19.2, related to store:main, store:application names
Downgraded ember-data:
Ember 1.12.1, ember-data beta 19.1, ESA 1.0.1 = ESA works, initializer deprecations mostly fixed, but ember-data beta 19.1 broke some other parts of our app (unrelated to ESA, some change to component 2way bindings).  handleResponse also still does not exist.
Downgraded ember-data again:
Ember 1.12.1, ember-data beta 18, ESA 1.0.1 = ESA works for initial authentication, login/logout, but fails when a 401 response is returned, due to DataAdapterMixin using handleResponse instead of ajaxError

This is my current solution, seems to work, just not sure if that "return true" affects anything on ajaxError vs handleResponse
/**
	adapters/application.js

            @TODO: NOTE, ember-data 1.13 changes ajaxError and ajaxSuccess to use handleResponse
	this is a polyfill for ESA compatibility with ember-data beta18
**/
ajaxError: function(jqXHR) {
	// if 401, ESA needs to invalidate
	if (jqXHR && jqXHR.status === 401) {
		if (this.get('session.isAuthenticated')) {
			this.get('session').invalidate();
		}
		return true;
	} else {
		return this._super.apply(this, arguments);
	}
}

You're right - this should be mentioned in the docs.


feat: add data-sveltekit-replacestate option to links

An additional data-sveltekit-replacestate option on top of the existing options.
Closes #9014.
Please don't delete this checklist! Before submitting the PR, please make sure you do the following:

[x] It's really useful if your PR references an issue where it is discussed ahead of time. In many cases, features are absent for a reason. For large changes, please create an RFC: https://github.com/sveltejs/rfcs
[x] This message body should clearly illustrate what problems it solves.
[x] Ideally, include a test that fails without this PR but passes with it.

Tests

[ ] Run the tests with pnpm test and lint the project with pnpm lint and pnpm check

Changesets

[x] If your PR makes a change that should be noted in one or more packages' changelogs, generate a changeset by running pnpm changeset and following the prompts. Changesets that add features should be minor and those that fix bugs should be patch. Please prefix changeset messages with feat:, fix:, or chore:.

Linting is failing because of a TS error in the following:
one

I couldn't find where I would make the appropriate updates to fix this. I tried looking for corresponding data-sveltekit-noscroll TS definitions but didn't find anything. All I could find are some generated types in test-tmp/.../elements/index.d.ts:
// SvelteKit
'data-sveltekit-noscroll'?: true | '' | 'off' | undefined | null;
'data-sveltekit-preload-code'?: true | '' | 'eager' | 'viewport' | 'hover' | 'tap' | 'off' | undefined | null;
'data-sveltekit-preload-data'?: true | '' | 'hover' | 'tap' | 'off' | undefined | null;
'data-sveltekit-reload'?: true | '' | 'off' | undefined | null;

Just had another little look at this and realised the corresponding types are within sveltejs/language-tools.
I can make a PR there too but I'm not sure what the process is for ensuring the changes to both would be released in sync?

@dummdidumm what's the process for merging in changes across the 3 repos this affects? Will updates to sveltejs/language-tools and sveltejs/svelte get published first and then we can move forward with this PR?
Is there anything else I can do to help on this PR here?

Yes we will likely merge Svelte/language-tools first.
That said - since you now nicely laid out all the needed PRs across the repos, would you be open to also adding data-sveltekit-keepfocus (would close #7895)? Then we'd have parity with the goto options.

Sure, I'll try and have a look in the next few days.

I've added -keepfocus, and also made changes for the form handlers. As I said before, I'm not too well versed in Sveltekit forms yet so might be worth checking that part of the PR a bit more closely!