text:
Exception in KmpNativeCoroutinesSyntheticResolveExtension.getDeclarations

Hello, thanks for that great library.
After updating the library version to 0.10.0-new-mm, I got a compilation issue.
During compilation when it faces @OptIn(ExperimentalTime::class) annotation in my code it throws ClassCastException.
Stacktrace:
Caused by: java.lang.ClassCastException: class java.util.ArrayList cannot be cast to class java.util.Set (java.util.ArrayList and java.util.Set are in module java.base of loader 'bootstrap')
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getDeclarations(KmpNativeCoroutinesSyntheticResolveExtension.kt:33)
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getDeclaredProperties(KmpNativeCoroutinesSyntheticResolveExtension.kt:54)
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getSyntheticPropertiesNames(KmpNativeCoroutinesSyntheticResolveExtension.kt:58)
   at org.jetbrains.kotlin.resolve.extensions.SyntheticResolveExtension$Companion$getInstance$1.getSyntheticPropertiesNames(SyntheticResolveExtension.kt:57)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$_variableNames$2.invoke(LazyClassMemberScope.kt:127)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$_variableNames$2.invoke(LazyClassMemberScope.kt:124)
   at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408)
   at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527)
   at org.jetbrains.kotlin.storage.StorageKt.getValue(storage.kt:42)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.get_variableNames(LazyClassMemberScope.kt:124)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.getVariableNames(LazyClassMemberScope.kt:179)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$_allNames$2.invoke(LazyClassMemberScope.kt:167)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$_allNames$2.invoke(LazyClassMemberScope.kt:163)
   at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408)
   at org.jetbrains.kotlin.storage.StorageKt.getValue(storage.kt:44)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.get_allNames(LazyClassMemberScope.kt:163)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.definitelyDoesNotContainName(LazyClassMemberScope.kt:184)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver$Task.mayFitForName(TowerResolver.kt:265)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver$Task.mayFitForName(TowerResolver.kt:258)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver$Task.processImplicitReceiver(TowerResolver.kt:230)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver$Task.run$processScope(TowerResolver.kt:198)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver$Task.run(TowerResolver.kt:209)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver.run(TowerResolver.kt:99)
   at org.jetbrains.kotlin.resolve.calls.tower.TowerResolver.runResolve(TowerResolver.kt:86)
   at org.jetbrains.kotlin.resolve.calls.KotlinCallResolver.resolveCall(KotlinCallResolver.kt:75)
   at org.jetbrains.kotlin.resolve.calls.tower.PSICallResolver.runResolutionAndInference(PSICallResolver.kt:101)
   at org.jetbrains.kotlin.resolve.calls.CallResolver.doResolveCallOrGetCachedResults(CallResolver.java:601)
   at org.jetbrains.kotlin.resolve.calls.CallResolver.lambda$computeTasksAndResolveCall$0(CallResolver.java:213)
   at org.jetbrains.kotlin.util.PerformanceCounter.time(PerformanceCounter.kt:101)
   at org.jetbrains.kotlin.resolve.calls.CallResolver.computeTasksAndResolveCall(CallResolver.java:211)
   at org.jetbrains.kotlin.resolve.calls.CallResolver.computeTasksAndResolveCall(CallResolver.java:199)
   at org.jetbrains.kotlin.resolve.calls.CallResolver.resolveSimpleProperty(CallResolver.java:140)
   at org.jetbrains.kotlin.resolve.calls.CallExpressionResolver.getVariableType(CallExpressionResolver.kt:111)
   at org.jetbrains.kotlin.resolve.calls.CallExpressionResolver.getSimpleNameExpressionTypeInfo(CallExpressionResolver.kt:146)
   at org.jetbrains.kotlin.resolve.calls.CallExpressionResolver.getSimpleNameExpressionTypeInfo(CallExpressionResolver.kt:135)
   at org.jetbrains.kotlin.types.expressions.BasicExpressionTypingVisitor.visitSimpleNameExpression(BasicExpressionTypingVisitor.java:172)
   at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.visitSimpleNameExpression(ExpressionTypingVisitorDispatcher.java:333)
   at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher$ForDeclarations.visitSimpleNameExpression(ExpressionTypingVisitorDispatcher.java:46)
   at org.jetbrains.kotlin.psi.KtNameReferenceExpression.accept(KtNameReferenceExpression.kt:59)
   at org.jetbrains.kotlin.types.expressions.ExpressionTypingVisitorDispatcher.lambda$getTypeInfo$0(ExpressionTypingVisitorDispatcher.java:175)
   ... 212 more

Kotlin version: 1.6.10.

And when I removed all @OptIn(ExperimentalTime::class), I got this issue (related to the posted above):
e: Compilation failed: class java.util.Collections$SingletonList cannot be cast to class java.util.Set (java.util.Collections$SingletonList and java.util.Set are in module java.base of loader 'bootstrap')
 * Source files: Greeting.kt, Platform.kt, networkDef.kt, networkExpects.kt, systemTimestampProvider.kt, Platform.kt, networkExpects.kt
 * Compiler version info: Konan: 1.6.0 / Kotlin: 1.6.0
 * Output kind: LIBRARY
e: java.lang.ClassCastException: class java.util.Collections$SingletonList cannot be cast to class java.util.Set (java.util.Collections$SingletonList and java.util.Set are in module java.base of loader 'bootstrap')
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getDeclarations(KmpNativeCoroutinesSyntheticResolveExtension.kt:33)
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getDeclaredFunctions(KmpNativeCoroutinesSyntheticResolveExtension.kt:184)
   at com.rickclephas.kmp.nativecoroutines.compiler.KmpNativeCoroutinesSyntheticResolveExtension.getSyntheticFunctionNames(KmpNativeCoroutinesSyntheticResolveExtension.kt:188)
   at org.jetbrains.kotlin.resolve.extensions.SyntheticResolveExtension$Companion$getInstance$1.getSyntheticFunctionNames(SyntheticResolveExtension.kt:54)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.addSyntheticFunctions(LazyClassMemberScope.kt:343)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.computeExtraDescriptors(LazyClassMemberScope.kt:109)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$allDescriptors$1.invoke(LazyClassMemberScope.kt:70)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope$allDescriptors$1.invoke(LazyClassMemberScope.kt:62)
   at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedLazyValue.invoke(LockBasedStorageManager.java:408)
   at org.jetbrains.kotlin.storage.LockBasedStorageManager$LockBasedNotNullLazyValue.invoke(LockBasedStorageManager.java:527)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassMemberScope.getContributedDescriptors(LazyClassMemberScope.kt:92)
   at org.jetbrains.kotlin.resolve.DescriptorUtils.getAllDescriptors(DescriptorUtils.java:598)
   at org.jetbrains.kotlin.resolve.lazy.descriptors.LazyClassDescriptor.resolveMemberHeaders(LazyClassDescriptor.java:665)
   at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.resolveAllHeadersInClasses(LazyTopDownAnalyzer.kt:241)
   at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.analyzeDeclarations(LazyTopDownAnalyzer.kt:214)
   at org.jetbrains.kotlin.resolve.LazyTopDownAnalyzer.analyzeDeclarations$default(LazyTopDownAnalyzer.kt:58)
   at org.jetbrains.kotlin.backend.konan.TopDownAnalyzerFacadeForKonan.analyzeFilesWithGivenTrace(TopDownAnalyzerFacadeForKonan.kt:107)
   at org.jetbrains.kotlin.backend.konan.TopDownAnalyzerFacadeForKonan.analyzeFiles(TopDownAnalyzerFacadeForKonan.kt:68)
   at org.jetbrains.kotlin.backend.konan.KonanDriverKt$frontendPhase$1.invoke(KonanDriver.kt:54)
   at org.jetbrains.kotlin.backend.konan.KonanDriverKt$frontendPhase$1.invoke(KonanDriver.kt:53)
   at org.jetbrains.kotlin.cli.common.messages.AnalyzerWithCompilerReport.analyzeAndReport(AnalyzerWithCompilerReport.kt:113)
   at org.jetbrains.kotlin.backend.konan.KonanDriverKt.frontendPhase(KonanDriver.kt:53)
   at org.jetbrains.kotlin.backend.konan.KonanDriverKt.runTopLevelPhases(KonanDriver.kt:31)
   at org.jetbrains.kotlin.cli.bc.K2Native.doExecute(K2Native.kt:81)
   at org.jetbrains.kotlin.cli.bc.K2Native.doExecute(K2Native.kt:37)
   at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:92)
   at org.jetbrains.kotlin.cli.common.CLICompiler.execImpl(CLICompiler.kt:44)
   at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:98)
   at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:76)
   at org.jetbrains.kotlin.cli.common.CLITool.exec(CLITool.kt:45)
   at org.jetbrains.kotlin.cli.common.CLITool$Companion.doMainNoExit(CLITool.kt:227)
   at org.jetbrains.kotlin.cli.bc.K2Native$Companion$mainNoExitWithGradleRenderer$1.invoke(K2Native.kt:393)
   at org.jetbrains.kotlin.cli.bc.K2Native$Companion$mainNoExitWithGradleRenderer$1.invoke(K2Native.kt:392)
   at org.jetbrains.kotlin.util.UtilKt.profileIf(Util.kt:22)
   at org.jetbrains.kotlin.util.UtilKt.profile(Util.kt:16)
   at org.jetbrains.kotlin.cli.bc.K2Native$Companion.mainNoExitWithGradleRenderer(K2Native.kt:392)
   at org.jetbrains.kotlin.cli.bc.K2NativeKt.mainNoExitWithGradleRenderer(K2Native.kt:634)
   at org.jetbrains.kotlin.cli.utilities.MainKt$daemonMain$1.invoke(main.kt:62)
   at org.jetbrains.kotlin.cli.utilities.MainKt$daemonMain$1.invoke(main.kt:62)
   at org.jetbrains.kotlin.cli.utilities.MainKt.mainImpl(main.kt:17)
   at org.jetbrains.kotlin.cli.utilities.MainKt.daemonMain(main.kt:62)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
   at org.jetbrains.kotlin.compilerRunner.KotlinToolRunner.runInProcess(KotlinToolRunner.kt:130)
   at org.jetbrains.kotlin.compilerRunner.KotlinToolRunner.run(KotlinToolRunner.kt:77)
   at org.jetbrains.kotlin.gradle.tasks.AbstractKotlinNativeCompile.compile(KotlinNativeTasks.kt:361)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
   at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
   at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   at java.base/java.lang.reflect.Method.invoke(Method.java:566)
   at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:104)
   at org.gradle.api.internal.project.taskfactory.StandardTaskAction.doExecute(StandardTaskAction.java:58)
   at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:51)
   at org.gradle.api.internal.project.taskfactory.StandardTaskAction.execute(StandardTaskAction.java:29)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$2.run(ExecuteActionsTaskExecuter.java:502)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:29)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$1.execute(DefaultBuildOperationRunner.java:26)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.run(DefaultBuildOperationRunner.java:56)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$run$1(DefaultBuildOperationExecutor.java:74)
   at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.runWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:45)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.run(DefaultBuildOperationExecutor.java:74)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:487)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:470)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.access$300(ExecuteActionsTaskExecuter.java:106)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.executeWithPreviousOutputFiles(ExecuteActionsTaskExecuter.java:271)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution.execute(ExecuteActionsTaskExecuter.java:249)
   at org.gradle.internal.execution.steps.ExecuteStep.executeInternal(ExecuteStep.java:89)
   at org.gradle.internal.execution.steps.ExecuteStep.access$000(ExecuteStep.java:40)
   at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:53)
   at org.gradle.internal.execution.steps.ExecuteStep$1.call(ExecuteStep.java:50)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
   at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
   at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:50)
   at org.gradle.internal.execution.steps.ExecuteStep.execute(ExecuteStep.java:40)
   at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:68)
   at org.gradle.internal.execution.steps.RemovePreviousOutputsStep.execute(RemovePreviousOutputsStep.java:38)
   at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:50)
   at org.gradle.internal.execution.steps.ResolveInputChangesStep.execute(ResolveInputChangesStep.java:36)
   at org.gradle.internal.execution.steps.CancelExecutionStep.execute(CancelExecutionStep.java:41)
   at org.gradle.internal.execution.steps.TimeoutStep.executeWithoutTimeout(TimeoutStep.java:74)
   at org.gradle.internal.execution.steps.TimeoutStep.execute(TimeoutStep.java:55)
   at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:51)
   at org.gradle.internal.execution.steps.CreateOutputsStep.execute(CreateOutputsStep.java:29)
   at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:58)
   at org.gradle.internal.execution.steps.CaptureStateAfterExecutionStep.execute(CaptureStateAfterExecutionStep.java:39)
   at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:60)
   at org.gradle.internal.execution.steps.BroadcastChangingOutputsStep.execute(BroadcastChangingOutputsStep.java:27)
   at org.gradle.internal.execution.steps.BuildCacheStep.executeWithoutCache(BuildCacheStep.java:180)
   at org.gradle.internal.execution.steps.BuildCacheStep.executeAndStoreInCache(BuildCacheStep.java:156)
   at org.gradle.internal.execution.steps.BuildCacheStep.lambda$executeWithCache$2(BuildCacheStep.java:130)
   at java.base/java.util.Optional.orElseGet(Optional.java:369)
   at org.gradle.internal.execution.steps.BuildCacheStep.lambda$executeWithCache$3(BuildCacheStep.java:130)
   at org.gradle.internal.Try$Success.map(Try.java:164)
   at org.gradle.internal.execution.steps.BuildCacheStep.executeWithCache(BuildCacheStep.java:84)
   at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:74)
   at org.gradle.internal.execution.steps.BuildCacheStep.execute(BuildCacheStep.java:46)
   at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:40)
   at org.gradle.internal.execution.steps.StoreExecutionStateStep.execute(StoreExecutionStateStep.java:29)
   at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:36)
   at org.gradle.internal.execution.steps.RecordOutputsStep.execute(RecordOutputsStep.java:22)
   at org.gradle.internal.execution.steps.SkipUpToDateStep.executeBecause(SkipUpToDateStep.java:105)
   at org.gradle.internal.execution.steps.SkipUpToDateStep.lambda$execute$0(SkipUpToDateStep.java:98)
   at java.base/java.util.Optional.map(Optional.java:265)
   at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:53)
   at org.gradle.internal.execution.steps.SkipUpToDateStep.execute(SkipUpToDateStep.java:37)
   at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:85)
   at org.gradle.internal.execution.steps.ResolveChangesStep.execute(ResolveChangesStep.java:42)
   at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:37)
   at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsFinishedStep.execute(MarkSnapshottingInputsFinishedStep.java:27)
   at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:92)
   at org.gradle.internal.execution.steps.ResolveCachingStateStep.execute(ResolveCachingStateStep.java:50)
   at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:114)
   at org.gradle.internal.execution.steps.ValidateStep.execute(ValidateStep.java:57)
   at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:73)
   at org.gradle.internal.execution.steps.CaptureStateBeforeExecutionStep.execute(CaptureStateBeforeExecutionStep.java:47)
   at org.gradle.internal.execution.steps.SkipEmptyWorkStep.lambda$execute$2(SkipEmptyWorkStep.java:92)
   at java.base/java.util.Optional.orElseGet(Optional.java:369)
   at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:92)
   at org.gradle.internal.execution.steps.SkipEmptyWorkStep.execute(SkipEmptyWorkStep.java:33)
   at org.gradle.internal.execution.steps.legacy.MarkSnapshottingInputsStartedStep.execute(MarkSnapshottingInputsStartedStep.java:38)
   at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:43)
   at org.gradle.internal.execution.steps.LoadExecutionStateStep.execute(LoadExecutionStateStep.java:31)
   at org.gradle.internal.execution.steps.AssignWorkspaceStep.lambda$execute$0(AssignWorkspaceStep.java:40)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter$TaskExecution$2.withWorkspace(ExecuteActionsTaskExecuter.java:284)
   at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:40)
   at org.gradle.internal.execution.steps.AssignWorkspaceStep.execute(AssignWorkspaceStep.java:30)
   at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:37)
   at org.gradle.internal.execution.steps.IdentityCacheStep.execute(IdentityCacheStep.java:27)
   at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:44)
   at org.gradle.internal.execution.steps.IdentifyStep.execute(IdentifyStep.java:33)
   at org.gradle.internal.execution.impl.DefaultExecutionEngine$1.execute(DefaultExecutionEngine.java:76)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeIfValid(ExecuteActionsTaskExecuter.java:185)
   at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:174)
   at org.gradle.api.internal.tasks.execution.CleanupStaleOutputsExecuter.execute(CleanupStaleOutputsExecuter.java:109)
   at org.gradle.api.internal.tasks.execution.FinalizePropertiesTaskExecuter.execute(FinalizePropertiesTaskExecuter.java:46)
   at org.gradle.api.internal.tasks.execution.ResolveTaskExecutionModeExecuter.execute(ResolveTaskExecutionModeExecuter.java:51)
   at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:57)
   at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:56)
   at org.gradle.api.internal.tasks.execution.CatchExceptionTaskExecuter.execute(CatchExceptionTaskExecuter.java:36)
   at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.executeTask(EventFiringTaskExecuter.java:77)
   at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:55)
   at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter$1.call(EventFiringTaskExecuter.java:52)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:200)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$CallableBuildOperationWorker.execute(DefaultBuildOperationRunner.java:195)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:75)
   at org.gradle.internal.operations.DefaultBuildOperationRunner$3.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:153)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.execute(DefaultBuildOperationRunner.java:68)
   at org.gradle.internal.operations.DefaultBuildOperationRunner.call(DefaultBuildOperationRunner.java:62)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.lambda$call$2(DefaultBuildOperationExecutor.java:79)
   at org.gradle.internal.operations.UnmanagedBuildOperationWrapper.callWithUnmanagedSupport(UnmanagedBuildOperationWrapper.java:54)
   at org.gradle.internal.operations.DefaultBuildOperationExecutor.call(DefaultBuildOperationExecutor.java:79)
   at org.gradle.api.internal.tasks.execution.EventFiringTaskExecuter.execute(EventFiringTaskExecuter.java:52)
   at org.gradle.execution.plan.LocalTaskNodeExecutor.execute(LocalTaskNodeExecutor.java:74)
   at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:402)
   at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$InvokeNodeExecutorsAction.execute(DefaultTaskExecutionGraph.java:389)
   at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:382)
   at org.gradle.execution.taskgraph.DefaultTaskExecutionGraph$BuildOperationAwareExecutionAction.execute(DefaultTaskExecutionGraph.java:368)
   at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.lambda$run$0(DefaultPlanExecutor.java:127)
   at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.execute(DefaultPlanExecutor.java:191)
   at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.executeNextNode(DefaultPlanExecutor.java:182)
   at org.gradle.execution.plan.DefaultPlanExecutor$ExecutorWorker.run(DefaultPlanExecutor.java:124)
   at org.gradle.internal.concurrent.ExecutorPolicy$CatchAndRecordFailures.onExecute(ExecutorPolicy.java:64)
   at org.gradle.internal.concurrent.ManagedExecutorImpl$1.run(ManagedExecutorImpl.java:48)
   at java.base/java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1128)
   at java.base/java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:628)
   at org.gradle.internal.concurrent.ThreadFactoryImpl$ManagedThreadRunnable.run(ThreadFactoryImpl.java:61)
   at java.base/java.lang.Thread.run(Thread.java:834)

It is worth to mention, that it happens only when I compile my project for a native platform (not the JVM one).

Oh, my bad. I forgot to update the Kotlin version from 1.6.0 to 1.6.10

FYI if possible I would recommend updating to 0.11.1-new-mm, it contains some bug fixes and kotlinx.coroutines has been updated from 1.6.0-RC3 to 1.6.0.

Yes, I've just noticed that 0.11.1 is available. The repo main page still says that 0.10.0 is actual :-)

Yeah that's a little confusing will updated that, thanks!

authors: rickclephas ultraon

repo: rickclephas/KMP-NativeCoroutines


text:
App Crashes on vosk.loadMedel Dynamically (Expermintal)

Hi,
I couldn't make the pods install successfully inside my ios folder, although i made all steps correctly like the README.
but anyway, i tried to use the expermintal method and load the model dynamically. the app loads up in loading state until the model is downloaded, but immediately crashes when passing the downloaded folder to vosk.loadModel,
here is a full code
import * as FileSystem from "expo-file-system";
import JSZip from "jszip";

// Model URL and directory where the model will be stored
const modelUrl =
  "https://alphacephei.com/vosk/models/vosk-model-small-en-us-0.15.zip"; // Replace with your model's URL
const modelDir = `${FileSystem.documentDirectory}vosk-model`;

export const downloadAndUnzipModel = async () => {
  try {
    // Check if model already exists
    let modelPath;
    const modelExists = await FileSystem.getInfoAsync(modelDir);
    if (!modelExists.exists) {
      // Define zip path where the model will be downloaded
      const zipPath = `${FileSystem.documentDirectory}vosk-model.zip`;

      // Download the model zip file
      const downloadResumable = FileSystem.createDownloadResumable(
        modelUrl,
        zipPath
      );

      const downloadResult = await downloadResumable.downloadAsync();
      if (downloadResult?.uri) {
        console.log("Model downloaded successfully:", downloadResult.uri);

        // Read the zip file and extract it
        const zipData = await FileSystem.readAsStringAsync(downloadResult.uri, {
          encoding: FileSystem.EncodingType.Base64,
        });

        const zip = new JSZip();
        const content = await zip.loadAsync(zipData, { base64: true });

        // Create the directory for the unzipped model
        await FileSystem.makeDirectoryAsync(modelDir, { intermediates: true });

        // Unzip each file and save it to the model directory
        for (const [filename, file] of Object.entries(content.files)) {
          if (!file.dir) {
            const fileData = await file.async("uint8array");
            const filePath = `${modelDir}/${filename}`;
            await FileSystem.writeAsStringAsync(
              filePath,
              Buffer.from(fileData).toString("base64"),
              {
                encoding: FileSystem.EncodingType.Base64,
              }
            );
            console.log(`Extracted: ${filePath}`);
          }
        }
        console.log("Model downloaded and unzipped successfully");
      } else {
        console.error("Failed to download the model");
      }
    } else {
      console.log("Model already exists, skipping download", modelDir);

      // List contents of modelDir
      const contents = await FileSystem.readDirectoryAsync(modelDir);
      modelPath = contents[0];
      if (contents.length > 0) {
        const firstSubdirectory = `${modelDir}/${contents[0]}`;
        try {
          const subdirectoryContents = await FileSystem.readDirectoryAsync(
            firstSubdirectory
          );
          console.log(
            `Contents of ${contents[0]} directory:`,
            subdirectoryContents
          );
        } catch (error) {
          console.error(
            `Error reading contents of ${contents[0]} directory:`,
            error
          );
        }
      } else {
        console.log("No subdirectories found in modelDir");
      }
    }

    return modelPath || undefined;
  } catch (error) {
    console.error("Error downloading or initializing the model:", error);
  }
};

and inside my screen i did this:
import { Button, Image, StyleSheet } from "react-native";

import { HelloWave } from "@/components/HelloWave";
import ParallaxScrollView from "@/components/ParallaxScrollView";
import { ThemedText } from "@/components/ThemedText";
import { ThemedView } from "@/components/ThemedView";
import { useState, useEffect, useRef } from "react";
import { downloadAndUnzipModel } from "@/src/utils/downloadModel";
import Vosk from "react-native-vosk";

export default function HomeScreen() {
  const [loading, setLoading] = useState<boolean>(true);
  const vosk = useRef<Vosk | null>(null);
  const [result, setResult] = useState<string>("");
  const [recognizing, setRecognizing] = useState<boolean>(false);

  useEffect(() => {
    const downloadModelAsync = async () => {
      const modelDir = await downloadAndUnzipModel();
      console.log("Model is downloaded and unzipped");
      try {
        if (modelDir) {
          vosk.current = new Vosk();
          await vosk.current.loadModel(modelDir);
          vosk.current
            ?.start()
            .then(() => {
              console.log("Starting recognition...");
              setRecognizing(true);
            })
            .catch((e) => console.error("Error starting recognition:", e));
        }
      } catch (error) {
        console.error("Error loading model:", error);
      }
      setLoading(false);
    };
    downloadModelAsync();
  }, []);

  useEffect(() => {
    if (!vosk.current) return;
    const resultEvent = vosk.current.onResult((res) => {
      console.log("An onResult event has been caught: " + res);
      setResult(res);
    });

    const partialResultEvent = vosk.current.onPartialResult((res) => {
      setResult(res);
    });

    const finalResultEvent = vosk.current.onFinalResult((res) => {
      setResult(res);
    });

    const errorEvent = vosk.current.onError((e) => {
      console.error(e);
    });

    const timeoutEvent = vosk.current.onTimeout(() => {
      console.log("Recognizer timed out");
      setRecognizing(false);
    });

    return () => {
      resultEvent.remove();
      partialResultEvent.remove();
      finalResultEvent.remove();
      errorEvent.remove();
      timeoutEvent.remove();
    };
  }, [vosk]);

  return (
    <ParallaxScrollView
      headerBackgroundColor={{ light: "#A1CEDC", dark: "#1D3D47" }}
      headerImage={
        <Image
          source={require("@/assets/images/partial-react-logo.png")}
          style={styles.reactLogo}
        />
      }
    >
      <ThemedView style={styles.titleContainer}>
        <ThemedText type="title">Welcome!</ThemedText>
        <HelloWave />
      </ThemedView>
      <ThemedView style={styles.stepContainer}>
        <ThemedText type="subtitle">
          {loading ? "Loading..." : "Ready, start recording"}
        </ThemedText>
      </ThemedView>
      <ThemedView style={styles.stepContainer}>
        <ThemedText type="subtitle">
          {result ? `Result: ${result}` : "No result yet"}
        </ThemedText>
      </ThemedView>
      <ThemedView>
        {!loading && !recognizing && (
          <Button
            onPress={async () => {
              if (vosk.current) {
                await vosk.current.start();
                setRecognizing(true);
              }
            }}
            title="Start Recording"
          />
        )}
        {!loading && recognizing && (
          <Button
            onPress={() => {
              if (vosk.current) {
                vosk.current.stop();
                setRecognizing(false);
              }
            }}
            title="Stop Recording"
          />
        )}
      </ThemedView>
    </ParallaxScrollView>
  );
}

const styles = StyleSheet.create({
  titleContainer: {
    flexDirection: "row",
    alignItems: "center",
    gap: 8,
  },
  stepContainer: {
    gap: 8,
    marginBottom: 8,
  },
  reactLogo: {
    height: 178,
    width: 290,
    bottom: 0,
    left: 0,
    position: "absolute",
  },
});

so I added the permissions to Info.plist
<key>NSMicrophoneUsageDescription</key>
<string>This app requires access to the microphone for speech recognition.</string>

so the downloaded folder is correct and here is the contents from the downloaded folder as shown in the logs
 LOG  Contents of modelDir:
 LOG  Contents of vosk-model-small-en-us-0.15 directory: ["README", "am", "graph", "ivector", "conf"]
 LOG  Model is downloaded and unzipped

and then the app crashes with this error:
ERROR (VoskAPI:Model():model.cc:122) Folder '/private/var/containers/Bundle/Application/479BB9D6-8897-485E-A2E8-A950D1A64F6B/demo.app/vosk-model-small-en-us-0.15' does not contain model files. Make sure you specified the model path properly in Model constructor. If you are not sure about relative path, use absolute path specification.

@BiskremMuhammad  I have the same problem, However, I'm not using dynamic linking, and it only happens on iOS, have you come up with a solution?

@joaolobao380 It never worked with me with native module for ios, (download the model and added the folder to xcode), but i manage to solve it and load the model successfully with dynamic load, using a download utility and let the app download the model internally and unzip it. so my solution included the above code, but at the end i removed the file:// from the downloaded model path and it worked.

perfect!! Thank you!

This is what should be happening with model loading- try to load from a dynamic path, otherwise default to the app bundle. If the static loading is not working, there may be some helpful logs when running the app from XCode. What are the logs you are seeing with the static load?

Can you follow the updated README and let us know if it still crashes ?

I can confirm that with a trailing file:// it does not work

Created this PR, please let me know if it resolves your issue! https://github.com/riderodd/react-native-vosk/pull/79

source: gharchive/issue

authors: BiskremMuhammad ShristiC joaolobao380 riderodd

repo: riderodd/react-native-vosk

license: MIT

license_type: permissive

license_source: github-api


text:
CryptoNet upgrade

CryptoExchange.Net has changed substantially in the last few versions.
I'm trying to get Bitmex.Net compiled againt this new version. Since it is not going to be a small patch I would like to hear from you guys the best way we can handle this effort.

@jrocha  feel free reopen if you'll have any issues

authors: jrocha ridicoulous


text:
store tag detail data in yaml

https://forum.obsidian.md/t/colorful-tag-1-2-0-add-extra-info-for-tag/47006/2

#40


text:
Support Ruby 1.8.7

In addition to Ruby 1.9.x, Ruby 1.8.7 should be supported.

+1

authors: caryp magneland

license: mit

license_source: bigquery


text:
Enhance help story

If you type help to the robat it gives you a nice list of things you can ask. But it's quite alot of text
t. Maybe we can enhance this story by making a bullet list.

Add some bullet points to the story. Would love to enhance this more bij adding something like a list command which shows all the topics. (not the example questions)
Because the confidence is all over the place the list command isn't reliable enough.

repo: rijkvanzanten/robat


text:
How do I get a message response?

Hi, this is more of a question than an issue.
I am new to Actor model and trying to figure out how it works while reading some papers on it. So please bear with me.
Here I am trying to get response for the messages I sent.
extern crate riker;
extern crate riker_default;
#[macro_use]
extern crate log;

use riker::actors::*;
use riker_default::DefaultModel;
use std::time::Duration;

struct Counter {
    count: i32,
}

impl Counter {
    fn get_count(&mut self) -> i32 {
        self.count
    }

    fn new() -> BoxActor<Opr> {
        Box::new(Counter{ count: 0 })
    }
}

#[derive(Debug, Clone)]
enum Opr {
    Add(i32),
    Sub(i32)
}

impl Into<ActorMsg<Opr>> for Opr {
    fn into(self) -> ActorMsg<Opr> {
        ActorMsg::User(self)
    }
}

impl Actor for Counter {
    type Msg = Opr;

    fn receive(
        &mut self,
        _ctx: &Context<Self::Msg>,
        msg: Self::Msg,
        _sender: Option<ActorRef<Self::Msg>>,
    ) {
        match msg {
            Opr::Add(n) => {
                self.count += n;
            }
            Opr::Sub(n) => {
                self.count -= n;
            }
        }
    }
}

fn main() {
    let model: DefaultModel<Opr> = DefaultModel::new();
    let sys = ActorSystem::new(&model).unwrap();

    let props = Props::new(Box::new(Counter::new));
    let my_actor = sys.actor_of(props, "my-actor").unwrap();

    my_actor.tell(Opr::Add(10), None);
    my_actor.tell(Opr::Sub(3), None);

    std::thread::sleep(Duration::from_millis(500));
}

From looking at the Actor trait's receive method, currently that should not be possible, right?
pub trait Actor : Send {
    type Msg: Message;

    // ...

    fn receive(&mut self, ctx: &Context<Self::Msg>, msg: Self::Msg, sender: Option<ActorRef<Self::Msg>>);

    // ...
}

Hewitt writes,

Messages in the Actor Model are decoupled from the sender and are delivered by the system on a best efforts basis.
If an Actor is sent a request, then the continuation must be one of the following two mutually exclusive possibilities:

to process the response resulting from the recipient receiving the request
to throw a Messaging exception

Just sitting there forever after a request has been sent is a silent failure, which is unacceptable. So, in due course, the infrastructure must throw a Messaging exception as governed by the policies in place if a response (return value or exception) to the request has not been received.
Ideally, if the continuation of sending a request is to throw a Messaging exception, then the sender of a response to the request also receives a Messaging exception saying that the response could not be processed.
If desired, things can be arranged so that Messaging exceptions are distinguished from all other exceptions.
Runtime failures are always a possibility in Actor systems and are dealt with by runtime infrastructures. Message acknowledgement, reception, and response cannot be guaranteed although best efforts are made.

So, does current implementation fit into this description? How can I get a response for the message I sent?
Also, let's say I like to have two different messages rather than an enum, so that each has its own impl blocks:
struct Add(i32);

impl Add {
   // ...
}

struct Sub(i32);

impl Sub {
   // ...
}

So, to handle them, still I have to use pattern matching in receive function, right? Wouldn't it be better to have a separate handler for each message?

Thank you for the detailed answer. I will send a pull request for the documentation once I digest it.

I was still planning on sending that PR but I see someone already did it (https://riker.rs/messaging/).
Please forgive my extreme procrastination, life is very hectic and demanding these days.
Thank you for the great work.

repo: riker-rs/riker


text:
Console error with 'not-draggable' class

First, i would like to thank you guys for the excellent work so far.
In my application i have a dropdown inside an item of the kanban. When the dropdown is show, i don't want the item to be draggable,  so i'm adding the class 'not-draggable', which i have found in the plugin code. The problem is, when we try to drag an item an error in the console appears, although the item really do not drag.
My question is, i'm using the class in the wrong way or it is really an error in the plugin?
The error is below:
Uncaught TypeError: can't access property "getBoundingClientRect", el is null          jkanban.js:1344:28

I've added the following verification in line 983:  (!source || item.classList.contains('not-draggable')) { return }
The console error is gone. But i don't know if it is a fix or just a work around. If you guys have a solution i would appreciate.

Hi @felipeEddy  can you make a pull request?

Hello @riktar, i made the pull request: https://github.com/riktar/jkanban/pull/92
Hope it helps. Thanks for the reply.

Hi, @felipeEddy you had worked on dist folder. Can you aplly your modifiy to dev file and build all?

@riktar I noticed when I applied the class inside my kanban-item div it does not work. Is it possible to extend this feature to scan for underlaying not-draggable classes?

@riktar I noticed when I applied the class inside my kanban-item div it does not work. Is it possible to extend this feature to scan for underlaying not-draggable classes?

I guess that might not be possible, while dragula event is attached to an entire item.

@marcosrocha85 Do you think so? Is it not possible to check if there is a class when starting to drag? If so cancel the drag functionality.

I don't know if I misread you, but the point of this issue were if item had a 'not-draggable' class so mouse down would not fire dragging. That's actually in production on jKanban. If an item had 'not-draggable' class drag should be cancelled.

@marcosrocha85 Yes I understand, I saw the code in production. But this works only on the kanban-item element not elements inside right? Is that possible to fix?
Because I have a dropdown inside kanban-item which I want to exclude for dragging.

I got it. I drag was being fired just on kanban-item, but it appears to being fired on element that fires the mouse down. I'll take a look at this just right now.

@marcosrocha85 Yes I understand, I saw the code in production. But this works only on the kanban-item element not elements inside right? Is that possible to fix?
Because I have a dropdown inside kanban-item which I want to exclude for dragging.

I was able to reproduce the issue by adding a dropdown (select) inside an item. The problem is that the drag event is fired after mouse leaves the select element and besides that the event parameters doesn't give any clue that the event came from there. In fact, dragula (which handles the drag and drop from jKanban) is thinking everything started from kanban-item element. What I done in the past was using a plugin like https://github.com/sandywalker/webui-popover like Trello does (poping up a window or dialog in order to show possible options to act)

I was thinking, what if you use the property "itemHandle"?
itemHandleOptions:{
    enabled: false,
},

@marcosrocha85 I tried this but it doesn't have any effect. Do you know something else what I can try?

@marcosrocha85 I've tried some code and the code below fixes the issue.
// Fixed dropdown drag issue
$('#kt_kanban_4').on('mousedown', '.dropdown', e => {
   e.preventDefault();
   e.stopImmediatePropagation();
   e.stopPropagation();
});

@marcosrocha85 I've tried some code and the code below fixes the issue.
// Fixed dropdown drag issue
$('#kt_kanban_4').on('mousedown', '.dropdown', e => {
   e.preventDefault();
   e.stopImmediatePropagation();
   e.stopPropagation();
});

You can use jKanban dragEl or dropEl events.
dragEl: function(el, source) {
  if ($(el).hasClass('not_draggable')) {
    jkanban.drake.cancel(true);
  }
}, // AND/OR
dropEl: function(el, source, target, sibling) {
  if ($(el).hasClass('not_draggable')) {
    jkanban.drake.cancel(true);
  }
}

You can play with that and develop a solution that fits your needs. 🙃

repo: riktar/jkanban


text:
Debug information while making stuff in terra

Hi !
Background
I was going through your introduction over at http://rileyjshaw.com/terra and I got stumped by the following not working as demonstrated:

Initially I thought the frequency of frames was too high so I set about counting the number of Ticks:

It turned out only 8 ticks were happening.
-- At this point I realised the creature 'Plant' from the first screenshot was not initialised.
So, my suggestion is:
Lets have some debug info available in terra from dev tools!
One I have added in for myself is 'registeredCreatures':

Note
I'm a noob, please excuse me if I missed an existing way of getting this information.

Having gone through the rest of the tutorial over at http://rileyjshaw.com/terra, it might just be sufficient to give users something to copy-paste for simplePlant.

@RossKinsella thank you SO much for the detailed report! This was a huge oversight on my part; I didn't realize that I'd skipped the simplePlant initialization in the tutorial. I just updated the site, let me know what you think!

Looks good!

authors: RossKinsella rileyjshaw

repo: rileyjshaw/terra


text:
Expo - Duplicate module name: react-native

Paths: /Users/user/myapp/app/node_modules/@rimiti/react-native-toastify/node_modules/react-native/package.json collides with /Users/user/myapp/app/node_modules/react-native/package.json
$ expo diagnostics

  Expo CLI 2.21.2 environment info:
    System:
      OS: macOS 10.14.5
      Shell: 5.3 - /bin/zsh
    Binaries:
      Node: 10.16.0 - ~/.nvm/versions/node/v10.16.0/bin/node
      Yarn: 1.16.0 - ~/.yarn/bin/yarn
      npm: 6.9.0 - ~/.nvm/versions/node/v10.16.0/bin/npm
      Watchman: 4.9.0 - /usr/local/bin/watchman
    IDEs:
      Android Studio: 3.4 AI-183.6156.11.34.5522156
      Xcode: 10.2.1/10E1001 - /usr/bin/xcodebuild
    npmPackages:
      expo: ^33.0.0 => 33.0.7
      react: 16.8.3 => 16.8.3
      react-native: https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz => 0.59.8
      react-navigation: ^3.3.0 => 3.11.0
    npmGlobalPackages:
      expo-cli: 2.21.2

"dependencies": {
    "@expo/vector-icons": "^9.0.0",
    "@rimiti/react-native-toastify": "^1.2.0",
    "axios": "^0.18.0",
    "expo": "^33.0.0",
    "expo-linear-gradient": "~5.0.1",
    "formik": "^1.5.1",
    "lodash": "^4.17.11",
    "metro-react-native-babel-preset": "^0.52.0",
    "moment": "^2.24.0",
    "react": "16.8.3",
    "react-native": "https://github.com/expo/react-native/archive/sdk-33.0.0.tar.gz",
    "react-native-datepicker": "^1.7.2",
    "react-native-dotenv": "^0.2.0",
    "react-native-elements": "^1.1.0",
    "react-native-modal-selector": "^1.0.3",
    "react-navigation": "^3.3.0",
    "styled-components": "^4.1.3",
    "yup": "^0.26.10"
  },

$ expo publish
Unable to find an existing Expo CLI instance for this directory, starting a new one...
Starting Metro Bundler on port 19001.
Tunnel ready.
Publishing to channel 'default'...
(node:4924) UnhandledPromiseRejectionWarning: Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  Paths: /Users/user/myapp/app/node_modules/@rimiti/react-native-toastify/node_modules/react-native/package.json collides with /Users/user/myapp/app/node_modules/react-native/package.json

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:4924) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 2)
(node:4924) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.
(node:4924) UnhandledPromiseRejectionWarning: Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  **Paths: /Users/user/myapp/app/node_modules/@rimiti/react-native-toastify/node_modules/react-native/package.json collides with /Users/user/myapp/app/node_modules/react-native/package.json**

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)
(node:4924) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by throwing inside of an async function without a catch block, or by rejecting a promise which was not handled with .catch(). (rejection id: 3)

Building iOS bundle
Error: jest-haste-map: Haste module naming collision:
  Duplicate module name: react-native
  Paths: /Users/user/myapp/app/node_modules/@rimiti/react-native-toastify/node_modules/react-native/package.json collides with /Users/user/myapp/app/node_modules/react-native/package.json

This error is caused by `hasteImpl` returning the same name for different files.
    at setModule (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:569:17)
    at workerReply (/Users/user/myapp/app/node_modules/jest-haste-map/build/index.js:641:9)
    at process._tickCallback (internal/process/next_tick.js:68:7)

Hello @appjitsu ,
Do you still have this error ? Did you try to update RN ?

I have different problem but I believe the root cause is the same. The problem is that react-native-toastify includes all react and react-native stuff as direct dependencies. How this should be done is through peer dependencies instead.
I think package.json of this library should look something like this:
"dependencies": {
    "prop-types": "15.x"
  },
"peerDependencies": {
    "react": "16.x",
    "react-dom": "16.x",
    "react-native": "0.59.x"
}

Hello @ronkot ,
Could you please test this @rimiti/react-native-toastify@1.2.2-0 version and let me know if it's now ok. 🙏

I confirm you that's working well:

Nice, super speed fix 😄  🎉
Using exact version numbers as a peer dependency will cause version mismtach warnings for most users, but it should not affect the behavior. If you want to refine the fix further, just use peer dependency version range as I suggested in https://github.com/rimiti/react-native-toastify/issues/11#issuecomment-668392449.
Anyway, super work. Thanks for this library! 💪

Aha!
Thanks for your contribution 🙏
New PR related to your last comment. #20

authors: appjitsu rimiti ronkot

repo: rimiti/react-native-toastify


text:
CallLogRecordLegInfo missing "reason" field

The CallLogRecordLegInfo class should delcare a "reason" field per the Swagger doc:
https://netstorage.ringcentral.com/dpw/api-reference/specs/rc-platform.yml?v=2019032720190322-1152

Hi @dougkpowers from the link you posted, I see that CallLogRecordLegInfo class does NOT have a reason field. Could you please double check?

you're right....but it's there in the payload that gets returned from the api call.
I wonder why it's in the payload but not documented in the swagger doc?

@dougkpowers Then it is a bug of our swagger spec. I will escalate this issue.
Once swagger spec fixed, I will release new version of the SDK.

Fixed

authors: dougkpowers tylerlong


text:
Cannot read properties of undefined (reading 'rootUri')

when ctrl+alt+enter on windows, a warning message appear at the bottom-right corner
Cannot read properties of undefined (reading 'rootUri')

having the same issue here

Duplicates of #43

Hiii, sorry for delay, I just publish the version with the fix from @Diogo-Rossi so it will be available soon

authors: Charlie50503 Diogo-Rossi jasonaviandres rioukkevin

repo: rioukkevin/vscode-git-commit


text:
You have to be online to see this screen.

THe user interface outputs "You have to be online to see this screen." even though I have internet connection.

You have to click on the gear icon in the app, then settings, then network settings option on the left, then click the box under the online mode section to put the client online. This guide has some useful info: https://cryptorum.com/threads/rippex-guide-for-storing-ripple-xrp.89/

repo: rippex/ripple-client-desktop

license: ISC


text:
feat(tx): Add NFTokenID link to NFT transaction pages

High Level Overview of Change

Context of Change

Type of Change

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Refactor (non-breaking change that only restructures code)
[ ] Tests (You added tests for code that already exists, or your new feature included in this PR)
[ ] Documentation Updates
[ ] Release

TypeScript/Hooks Update

[ ] Updated files to React Hooks
[ ] Updated files to TypeScript

Before / After
Before

After

Test Plan

Can you use NFTokenLink on the NFT tab for an account too?

source: gharchive/pull-request

repo: ripple/explorer


text:
Proposal: Reliable Transaction Submission in rippled

Rationale: Reliable/robust transaction submission is the biggest feature of Ripple-REST that isn't covered by RippleAPI. Despite the thorough documentation, this remains one of the hardest things to do properly when integrating a business with the XRP Ledger. Adding reliable transaction submission to a client library is infeasible since it involves running as a persistent service and persisting data (probably to a database). Those are both things that rippled does already. As an added bonus, putting this functionality in rippled gives us access to tools to conveniently backfill ledger history in case of an outage. We can reduce barriers to entry in the XRP Ledger ecosystem by building reliable transaction submission into rippled servers so businesses who run rippled always and automatically have access to a quality implementation of reliable transaction submission.
Prerequisites
To use this described implementation, users must have the following

A way to generate UUIDs
A way to track those UUIDs for future lookups
Admin access to a rippled server

These features are admin-only for a similar reason to why wallet_propose is admin-only. They don't pose risks to the server administrator, but users would be very unwise to use them on servers that they don't control.

The rippled server must have non-ephemeral storage for persisting reliable transaction submissions. This storage can be separate from the ledger store and shard store (and may not need nearly as many IOPS).

These requirements are very similar to the requirements for using Ripple-REST for reliable transaction submission, except that the user does not need to run a Node.js server with Ripple-REST.
Architecture
Add several new API methods for submitting transactions reliably and managing them. Because these API methods store secrets on behalf of the user, I suggest making them admin-only. Add a new data store, tentatively called the reliable submission store, for tracking reliably submitted transactions.
One or more backgrounds job should run as part of rippled to manage the state of any reliable transaction submissions whose current status is not final. These jobs' responsibilities include:

Checking new validated ledgers to see if they contain the pending reliably-submitted transactions, and updating those transactions' status in the reliable submission store. (Updates occur when attempts at submitting the transactions are included in validated ledgers or exceed their LastLedgerSequence values, and when submitting follow-up attempts to transactions that failed initially.)
Resubmitting reliably-submitted transactions up to the maximum number of attempts. This frequently involves changing some automatically-filled values and re-signing the transaction. (Note: transactions that result in tec codes are not retried, since the results of retrying such transactions are likely to be the same.)
Backfilling ledger history so as to ascertain the outcome of reliably-submitted transactions, if there is missing ledger history. (For example, after restarting following an outage.)

API
This proposal adds several new admin methods to the JSON-RPC and WebSocket APIs of rippled. The methods are (names are placeholders):

submit_reliable_tx: initiate reliable submission of a transaction
get_reliable_tx: check the status of a reliably-submitted tx
delete_reliable_tx: delete a reliable tx submission. (This does not directly affect the XRP Ledger data itself)

TODO: Maybe also a update_reliable_tx method to update the settings of a reliably-submitted (but not final) tx?
submit_reliable_tx
Submit a transaction for reliable submission.
The fields provided to this method are a superset of the fields supported by the sign method, except that the offline field of the sign method is not allowed. The reliable transaction submission system persists all the values from this request, including the provided secret/seed/seed_hex/passphrase, so that it can re-submit the transaction if appropriate. (Optionally, to reduce attack surface, rippled can delete the saved secret value when the transaction's outcome is final.) Certain fields in the tx_json may be omitted so that rippled can automatically fill them with appropriate values. Unlike with regular signing and submitting, rippled can change the auto-filled values if it needs to re-sign and re-submit the transaction. Fields explicitly specified MUST NOT be changed even for resubmission. (Exception: adding the reliable_submission_id to the Memos array.) See "Modifying for Submission" below for details.
In addition to the sign parameters, the user provides the following fields:

Request Field
Value
Description

reliable_submission_id
String - UUID
An identifier provided by the client to track this transaction. If the transaction fails and must be re-submitted with a different transaction hash, the user can still identify it by this ID. This must be a validly formed UUID.

max_attempts
Integer
(Optional) Maximum number of times to submit the transaction if it is not included in a validated ledger. Defaults to 3. Cannot be less than 1. The initial submission counts as attempt 1.

ledger_index_offset
Unsigned Integer
(Optional) How high to set the LastLedgerSequence relative to the current ledger. Defaults to 3.

When it receives the request, the reliable submission system does the following things in order: (Note: To avoid failures, it's important that the following occur in the proper order.)

It modifies the transaction for submission (see "Modifying for Submission" below) and signs the resulting transaction instructions.
It persists the reliable submission object to the reliable submission store, including the hash of the signed transaction. (See below for details of what's persisted.)
If and only if persisting the reliable submission object succeeded, it submits the transaction for consideration in the next open ledger or queue according to normal transaction submission.

The data persisted to the reliable submission store includes:

All fields specified in the submit_reliable_tx request.
The default values of request fields that weren't explicitly specified. This includes max_attempts, ledger_index_offset, fee_mult_max, fee_div_max, and build_path.
The additional fields defined in the following table:

Saved Field
Value
Description

submission_status
String
A string defining where the transaction is in the reliable submission process. When initially persisted, this has the value submitted. See submission_status Values

submitted_hashes
Array of Strings
An array of transaction hashes of attempts at submitting this transaction, ordered from newest to oldest, so that element 0 of the array is always the one most likely to succeed or have succeeded. The length of this array is the number of attempts made to submit the transaction so far, so it will never be greater than max_attempts. When initially persisted, this array is length 1, containing the hash of the first attempt (even before it has been submitted).

min_ledger_index
Number
One higher than the latest validated ledger_index at the time the reliable transaction submission was received. In other words, the earliest possible ledger version in which this transaction could appear.

recent_last_ledger_sequence
Number
The LastLedgerSequence of the most recent attempt at submitting the transaction.

Note: The maximum number of ledger versions the system may have to search to confirm a transaction's final result may be greater than ledger_index_offset because the auto-filled LastLedgerSequence is based on the current ledger while the min_ledger_index is based on the latest validated ledger. (This is by design; if there's a delay in consensus, there may be several closed, unvalidated ledgers, and in that case, it is unlikely but possible for a newly-submitted transaction to be included in those ledger indexes. To maximize chances of the transaction succeeding, we set the LastLedgerSequence based on the current ledger, but to avoid failing we search as far back as the earliest ledger index it could possibly appear in.)
get_reliable_tx
Look up the status of a reliably-submitted transaction.
The request contains just one field:

Request Field
Value
Description

reliable_submission_id
String - UUID
The identifier of the reliably-submitted transaction to look up.

The response contains the entire saved reliable submission object, including:

Response Field
Value
Description

reliable_submission_id
String - UUID
The identifier of this reliably-submitted transaction.

tx_json
Object
The transaction instructions as provided in the original request.

secret / seed / passphrase / seed_hex
String
(One of these fields) The secret field provided in the request, in the same format as required by the sign command. TODO: Optionally, this field can be deleted automatically if the transaction has a final result.

key_type
String
The type of secret key provided. Either secp256k1 or ed25519.

build_path
Boolean
(Payment transactions only) Whether to automatically fill the Paths field of the transaction. Note: Unlike the sign command's current behavior, reliable transaction submission should use the value, not the presence, of this field.

fee_mult_max
Integer
Limit on how high the automatically-provided Fee can be.

fee_div_max
Integer
Divider for the fee_mult_max (1 if the request didn't specify it).

submission_status
String
A string defining where the transaction is in the reliable submission process. When initially persisted, this has the value submitted. See submission_status Values

submitted_hashes
Array of Strings
An array of transaction hashes of attempts at submitting this transaction, ordered from newest to oldest, so that element 0 of the array is always the one most likely to succeed or have succeeded. The length of this array is the number of attempts made to submit the transaction so far, so it will never be greater than max_attempts.

min_ledger_index
Number
One higher than the latest validated ledger_index at the time the reliable transaction submission was received. In other words, the earliest possible ledger version in which this transaction could appear.

recent_last_ledger_sequence
Number
The LastLedgerSequence of the most recent attempt at submitting the transaction.

max_attempts
Integer
Maximum number of times to this transaction may be submitted. The initial submission counts as attempt #1.

ledger_index_offset
Unsigned Integer
How many ledger versions to allow between submitting a single attempt and failing that attempt (used for setting LastLedgerSequence values)

result
String
(Omitted unless the submission_status is succeeded, failed, or rejected) The transaction engine code of the final attempt at submitting the transaction. If submission_status is succeeded, this is always tesSUCCESS. If submission_status is failed, this is always a tec-class code. If submission_status is rejected, this is either a tem-class code, tefPAST_SEQ, or tefMAX_LEDGER.

delete_reliable_tx
Remove a reliable submission object from the reliable submission store.
The request contains just one field:

Request Field
Value
Description

reliable_submission_id
String - UUID
The identifier of the reliably-submitted transaction to delete.

The response contains the last known state of the given reliable submission, in the same format as get_reliable_tx.
This method deletes the reliable submission object, but it does not affect the processing of any attempts to process that transaction that have already been submitted. It does prevent future retries and aborts any backfilling that was necessary to determine the final status of this transaction.
Other Details
submission_status Values
The submission_status field of a Reliable Transaction Submission object has the following possible values:

Value
Definition

submitted
The transaction has been received (and probably submitted) but its outcome is not yet final. This status applies before the transaction has been included in a validated ledger. When in this state, element 0 of the submitted_hashes array is the identifying hash of the currently-pending version of the transaction. In extreme cases, a reliable submission may be persisted in this state even if the attempt at submitting the transaction failed due to an outage.

queued
The transaction has been submitted or resubmitted, and the preliminary result of submission was terQUEUED, and the transaction has not yet been locally applied to any ledger version. If the transaction is included in an open or closed ledger (including as a result of switching to a different closed ledger received from peers in consensus), the status changes to submitted or resubmitted as appropriate. TODO: maybe remove this status in favor of just using submitted?

resubmitted
The transaction did not succeed on a previous attempt, but it encountered an error that could be retried, so it has been modified as necessary, signed again, and submitted again. As with the submitted status, element 0 of the submitted_hashes array is the currently-pending transaction hash. Later elements of the array are the hashes of previous submission attempts. TODO: maybe remove this status in favor of just using submitted?

succeeded
The transaction has been included in a validated ledger with a tesSUCCESS result. In this case, element 0 of the submitted_hashes array is the identifying hash of the transaction that succeeded.

failed
The transaction has been included in a validated ledger with a failed transaction result (a tec-class code). It will not be retried.

rejected
The transaction has not been included in a validated ledger and it will not be retried. This includes the following cases: (1) any "Malformed" transaction (a tem-class code), (2) the transaction had an explicitly-specified Sequence value but resulted in tefPAST_SEQ, (3) the transaction has been attempted max_attempts times and the last attempt has a LastLedgerSequence higher than the latest validated ledger version, or (4) the transaction instructions contain an explicitly specified LastLedgerSequence parameter which is lower than the latest validated ledger version.

unknown
The transaction's  Due to a gap in ledger history, the final outcome of the transaction is not known. If it has any reliably-submitted transactions in this state, rippled tries to backfill ledger history to determine the final outcome. This may occur if rippled was stopped or lost power when a transaction's outcome was pending.

Caution: There's a slight difference between case 3 of rejected and a tefMAX_LEDGER result. Any given attempt at submitting the transaction can fail with tefMAX_LEDGER but the reliable transaction submission may not have failed finally if the transaction can be modified and submitted again. In other words, if max_attempts is higher than the number of attempts made so far and the transaction instructions do not include a hard-coded LastLedgerSequence parameter, a tefMAX_LEDGER result is not final. Another case in which tefMAX_LEDGER is not final is if it results from a closed-but-not-validated ledger version that's higher than LastLedgerSequence. If a different version of a closed ledger is validated by consensus, the transaction could still become included in a validated ledger.
The following state diagram shows the possible transitions of submission_status values (for the proposal as written and for the variant where resubmitted and queued are removed):

TODO: It's worth discussing how unknown status should interact with ledger history and online delete. The most user-friendly behavior, assuming these commands remain admin-only, is that the server should automatically backfill ledgers even in excess of the desired number of historical ledgers to save, and online delete should not delete ledgers in the range of min_ledger_index to recent_last_ledger_sequence (inclusive) while a reliable submission's status is unknown. After the transaction's outcome is confirmed, it would be OK to delete those ledgers, but the ledger containing the transaction should not be deleted.
Modifying for Submission
Before the transaction is signed and submitted, rippled automatically fills certain fields the same way it auto-fills them when doing online signing. In addition to that, reliable transaction submission automatically adds the following:

A memo containing the reliable_submission_id. If the transaction already has a Memos field, this memo is appended to the Memos array. See "Memo Format" for details.
A LastLedgerSequence field with a value equal to the current ledger index plus the ledger_index_offset from the request.

The reliable transaction submission system does not persist the automatically-provided fields in the reliable submission store. This is to distinguish between explicitly specified fields (which are not modified) and automatically-filled fields (which can be modified when resubmitting the transaction).
If a reliably-submitted transaction fails to be included in a ledger, rippled can attempt to resubmit the transaction. This may require modifying certain fields of the transaction. This should always be based on the persisted tx_json instructions, not the signed instructions from any given attempt. In all cases except the Memo field, the modified fields MUST NOT overwrite fields that were explicitly defined in the tx_json of the original request.

The auto-filled LastLedgerSequence should be modified if a previous attempt failed to be include the transaction in a validated ledger before its LastLedgerSequence. The new LastLedgerSequence value should be equal to the current ledger plus the persisted ledger_index_offset.

Note: In many cases, the new LastLedgerSequence will be equal to the old LastLedgerSequence plus the ledger_index_offset. However, this is not true in case of power outages or busy servers, where additional time may pass between when the initial submission fails and when it gets resubmitted.

The auto-filled Sequence field can be modified if the transaction results in tefPAST_SEQ. This is unlikely to occur unless a user is submitting transactions on multiple systems in parallel.
The auto-filled Fee field can be modified if the provisional result of the transaction was a failure due to an insufficient transaction cost. The new Fee value must not be higher than the amount defined by the fee_mult_max and fee_div_max values of the initial request. Result codes that should prompt an increased transaction cost include telCAN_NOT_QUEUE, telCAN_NOT_QUEUE_FEE, telCAN_NOT_QUEUE_FULL, telINSUF_FEE_P, terINSUF_FEE_B. TODO: Maybe this should just happen automatically based on the expected transaction cost at the time of resubmission and not based on the result of the previous submission, since transaction costs may increase coincidentally around the time of resubmission even if the previous attempt didn't fail for transaction cost reasons?
The auto-filled Paths of a Payment (if build_path was provided) can be updated at the time of resubmission.
No other fields should be modified when resubmitting. (The Memos field should still be modified to include the reliable_submission_id memo.)

Note: The user may explicitly provide some auto-fillable fields, such as Fee, Sequence, or LastLedgerSequence. Those fields must never be modified, even though it may eliminate some opportunities to resubmit a transaction. For example, if the user provides a Sequence field and the sending account's Sequence field in a validated ledger is or becomes higher than the reliably-submitted transaction's Sequence field before even the first attempt is included in a validated ledger, the reliable submission object goes to the rejected status rather than being resubmitted with a higher sequence number.
When resubmitting, the reliable submission system should do the following steps in order (similar to the initial attempt):

Update the auto-filled fields and sign the updated transaction instructions.
Persist updates to the reliable submission object in the reliable submission store. In particular:

Prepend the new transaction hash to the submitted_hashes array.
Update the min_ledger_index to the latest validated ledger index plus one.
Update the transaction's submission_status to be resubmitted.
Update the recent_last_ledger_sequence with the LastLedgerSequence of the updated transaction.

If and only if persisting the updated reliable submission object succeeded, submit the updated transaction for consideration in the next open ledger or transaction queue according to normal transaction submission.

Memo Format
When transactions are submitted using this mechanism, rippled adds a memo with the reliable_submission_id so that you can recognize when a transaction is the result of a particular reliable-transaction-submission. The memo has the following format:

Field
Value

MemoData
The reliable_submission_id UUID, in a binary big-endian encoding. (Not Microsoft's COM/OLE mixed-endian encoding.)

MemoFormat
The value 0x55554944 (the ASCII for "UUID"). Note: Surprisingly, there isn't a MIME type for UUIDs.

I'll give this a close read, but I highly support revisiting better ways to do reliable transaction submission.

(Made slight edits to fix typos, add a link to the fields of the sign method, and clarify that the reliable submission store should not be on ephemeral storage.)

Yeah, ugh. And add FirstLedgerSeqence symmetric to LastLedgerSequence for a
simple mental model, and don't cry about 4 bytes while using 160 bits for
"USD" and endless 0s for inner nodes :)
I recommend a dumb peer (https://github.com/ripple/rippled/issues/2413)
implemented on the JVM, that just tracks state from validators, and does
not process transactions. With a plugin system for user commands
(bots/whatever) and data processing :)
And useable as a library, and with a Pony with a ripple tattoo

Totally agree this should be in rippled, and yes, impossible to put RTS in
client libs without handling persistence of txns before putting on the
network for handling crash recovery.
Nice work pushing this Rome.
What is a txn id???

I'm not sure I understand everything you said, @sublimator. Are you suggesting that FirstLedgerSequence should be added as a common transaction field? I think I could get behind that. It's not necessary for this proposal, but would be convenient for it.
Also, I'm adding a ledger_index field which should appear in the result when the transaction is confirmed into a validated ledger.

noticed one typo in submission_status "unknown". Looks like the beginning didn't get deleted.
The transaction's Due to a gap in ledger history,

On thing I found counterintuitive is that
submit_reliable_tx - is a superset of submit
get_reliable_tx - is not a superset of tx
It looks like you need to first get_reliable_tx(), then tx(submitted_hashes[0])
Is that what you are thinking?

This looks awesome Rome. I highly support it!
If building this into rippled itself turns out to be troublesome, then maybe build it as an optional executable. One that's packaged with rippled and designed to run on the same box.

This may be bike-shedding at this point, but I think the status name failed is going to cause confusion with people who don't read documentation. feeClaimed seems more intuitive to me.

authors: BobWay mDuo13 sublimator ximinez

repo: ripple/rippled


text:
Remove comment about passing allocator to KeyCache

After some discussion on https://github.com/ripple/rippled/pull/2595, we have decided that the allocator should not be plumbed through the KeyCache class template. As such, remove the comment suggesting to push the allocator through.
Reviewers:
@scottschurr

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Thank you for your submission. It will be reviewed soon and submitted for processing in CI.

Here's a thought in case you would like to continue cleaning up this code base.  There are quite a number of FIXME and TODO notes littered around the code base.  Many are quite old.  You might pick 10 or 20 likely looking suspects among those and drop them in an issue.  (Don't list all the FIXMEs or it will be too intimidating to triage.)  Somebody on the team could do a quick triage of that short list to see which are...

Stale and the note should simple be removed from the codebase.
Good things to fix and probably don't have lots of tricky parts.
Good things to fix, but look nasty and complicated.

There's real benefit to the code base even if we just remove a few of the stale FIXMEs.  And, if we can spot a few that don't have seriously tricky parts, it may reduce the amount of thrash that your fixes go through.
Again, that's just a thought.  And thanks very much for your contributions and continued interest.

Hi Scott, don't be sorry about the level of thrashing. I'm glad that people care about high-quality code and doing the right thing from a code base maintenance perspective too.
I'll happily scan through the FIXME and TODOs laying around and work to understand them a little before starting up a list in an issue I will file. That was in my backlog of things to look into until I had a further direction of things that may be good considering that I am:

An external contributor
Still fairly new to the codebase

I appreciate the help and patience on your end in providing advice and review.

Merged with #2629 as f58916a2e4748e626cb0768a5dba5e79e2abba02. Thanks for your contribution, @JoeLoser.

authors: JoeLoser nbougalis ripplelabs-jenkins scottschurr


text:
Adjust cache parameters for 'huge' node size

In some edge cases, the tuning for 'huge' node size could result in very high memory usage.

Duplicate of
https://github.com/ripple/rippled/pull/980

authors: JoelKatz vinniefalco


text:
fix: handle ownership of temp segment path to delete on Drop

Closes #1223
Going to have another look through later to see if there is a cleaner way to handle this, and see if there is a clean way to handle warn logging on delete fail. I didn't love the implications of adding the warn log to the error:
diff --git a/risc0/zkvm/src/host/client/env.rs b/risc0/zkvm/src/host/client/env.rs
index 0ac1e3c6..157c082b 100644
--- a/risc0/zkvm/src/host/client/env.rs
+++ b/risc0/zkvm/src/host/client/env.rs
@@ -101,6 +101,16 @@ pub struct ExecutorEnv<'a> {
     pub(crate) pprof_out: Option<PathBuf>,
 }

+impl Drop for ExecutorEnv<'_> {
+    fn drop(&mut self) {
+        if let Some(DirectoryPath::TempDir(dir)) = self.segment_path.take().as_deref() {
+            if let Err(e) = std::fs::remove_dir_all(dir.path()) {
+                tracing::warn!("failed to close tempdir: {:?}", e);
+            }
+        }
+    }
+}
+
 impl<'a> ExecutorEnv<'a> {
     /// Construct a [ExecutorEnvBuilder].
     ///
diff --git a/risc0/zkvm/src/host/client/prove/bonsai.rs b/risc0/zkvm/src/host/client/prove/bonsai.rs
index af1c7ada..bda1193e 100644
--- a/risc0/zkvm/src/host/client/prove/bonsai.rs
+++ b/risc0/zkvm/src/host/client/prove/bonsai.rs
@@ -57,7 +57,7 @@ impl Prover for BonsaiProver {
         client.upload_img(&image_id_hex, elf.to_vec())?;

         // upload input data
-        let input_id = client.upload_input(env.input)?;
+        let input_id = client.upload_input(env.input.clone())?;

         // upload receipts
         let mut receipts_ids: Vec<String> = vec![];

This CI fails because the tempfile dep is only pulled in when not the zkvm target, but the ExecutorEnv is exposed also to the zkvm target. This seems like it shouldn't be, since the segment storage wouldn't work within the zkvm, but instead of changing the API surface or making a hacky workaround, I'll leave this PR as is until it's decided what to do with that.

I'm thinking the underlying problem is that the SegmentRef isn't really needed anymore. I'd like to do some discovery work on seeing if we can drop this which I think will make the need for temporary files go away entirely.

authors: austinabell flaub


text:
Integrate risc0-ethereum on CI

Drop Ethereum crates, now moved into the risc0-ethereum own repo
Update the xtask bootstrap-groth16 tool to work with the external risc0-ethereum repo
Fix ceremony.dockerfile
Add to CI a workflow to check when changes brake our ethereum-related repos (risc0-ethereum and bonsai-foundry-template). The patching is done via a python script rather than with Cargo patch as it is more flexible, allowing to also patch git submodule dependencies without requiring any changes on the external repos.
These checks also include checking the Solidity verifier (on risc0-ethereum) against a Groth16 receipt generated from the risc0 repo.

[x] risc0-ethereum
[x] bonsai-foundry-template

TODO:

[x] remove the capossele/risc0-CI branch once we land the required changes on risc0-ethereum #38 and bonsai-foundry-template #89
[x] move the governance example to risc0-ethereum and adjust its website's related links temporarly to 0.20 branch

Resolves: https://github.com/risc0/scratch/issues/270
Resolves: https://github.com/risc0/risc0/issues/1406

The risc0-ethereum CI tests are now failing as we updated the ALLOWED_IDS_ROOT, and that is expected.

Converting to draft until we fix one small issue after some introduced changes


text:
new instruction proposal Zihintpause

I wonder if new proposals like this new instruction should be added at this early stage to riscv-config
it is not in the ratified specs
and there seems no place from riscv.org that I can see its definition.
is it a real instruction or pseudo
will this instruction being in the device yaml affect anything - like selection/config of tests, test generators, simulators?
why has this instruction been singled out to be added?
what about all other proposed extensions.
thanks for any clarifications...

Adding updates to riscv-config is part of the ratification process for an instruction/extension. I guess I should have waited for the official raitification announcement before merging the PR.
The changes made for this PR will not affect existing tools in anyway. They can however choose to do something extra with this if they like.
@gfavor will probably be best to answer questions on the origin on this instruction

I think it has been ratified now; it was a fast-track ratification. It is a hint instruction which (architecturally) acts like a NOP. So, this can probably be closed, though the question remains: at what point should instructions and features be added to the config schema?

Yes, this was officially ratified at the beginning of the year.  There was even a public announcement about it as the first extension using the new fast-track process - along with quotes from Mark and me about the wonders of the fast-track process and the instruction itself.

If it was ratified - surely it would be in on the RISCV.org specifications page?
https://riscv.org/technical/specifications/
Maybe somebody should get that page up to date if there are ratified specs not listed there?
In fact that page should only have ratified specs.
Maybe the working group chair of the ratified spec should ensure that that page gets updated.
Otherwise the ratified spec is just a secret and can not be of much interest if it is not publicised.
People should not be confused as to what the specs are ... there should be one home... https://riscv.org/technical/specifications/
and it should be up to date, comprehensive, and complete.
Simon

I think this is an issue to bring up with the Unpriv IC.  I suspect, with all the various unpriv extensions happening this year, this gets into the mechanics of releasing new ratified Unpriv specs (of which I have no idea what are the intended mechanics).
As a side-note, the PAUSE Hint extension was quite publicly announced (i.e. in the RVI marketing sense).  I don't remember what was done announcement-wise within the RVI techncial community.

Zihintpause is now supported in riscv-config and is ratified. Closing this for now

authors: Imperas allenjbaum gfavor neelgala simon5656

repo: riscv-software-src/riscv-config


text:
Merge block_hashes.jsons into block_hashes.bincode

Closes #241
Depends on #440. But anyway, only last 2 commits are relevant to this pr

Here are benchmarks:
Before (all logs in pastebin):
After (pastebin)

pastebin.com refused to connect.

You should upload the files here instead.

@kien-rise added reports under spoiler. Take a look :pray:

repo: risechain/pevm


text:
ci(Mergify): configuration update

This change has been made by @arkbriar from Mergify config editor.

fix #330

repo: risingwavelabs/risingwave-operator


text:
Microbenchmark all parsers

Seems like there could be regression / perf optimizations for various parsers. We need to micro-benchmark all of them.

[x] Json parser
[ ] Avro
[ ] Debezium
[ ] Any more?

cc @tabVersion

Another comment by @neverchanje :

Personally, if I wanted to test if there is some bottleneck in the parser, I would create a source and a dummy sink (blackhole) and see whether the throughput is bounded by the IO or by the CPU. If it’s CPU, it means that the parser spends too much time, which is definitely unexpected.

repo: risingwavelabs/risingwave


text:
validate compatibility between connector type and row format

For example:
create materialized source s1 (
    v1 int,
    v2 float,
    primary key (v1)
) with (
    connector = 'datagen',
    fields.v1.kind = 'sequence',
    fields.v1.start = '1',
    fields.v1.end  = '10',
    fields.v2.kind = 'sequence',
    fields.v2.start = '11',
    fields.v2.end = '20',
    datagen.rows.per.second='15',
    datagen.split.num = '1'
) row format debezium_json;

The create source succeeds but warning for every row in the log.
Probably validating as early as possible is better?
Or the current approach is intentional?
It's a two-dimensional matrix, isn't it?
connector type X row format type.

related https://github.com/risingwavelabs/risingwave/issues/6948

datagen connector, after #7032 , will directly produce datachunks and ignore the row format properties.

#7612 introduces native as datagen's default row format. But we still accept row format json for test use.
We will ban other row formats from creating source with datagen connector.

authors: fuyufjh lmatz tabVersion


text:
rename SourceCtrlOpts::chunk_size to max_chunk_size to better reflect the meaning

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#16440  👈
#16407
#16439
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @stdrc and the rest of your teammates on  Graphite


text:
chore: enable connector node ut on ci

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Checklist For Contributors

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] I have demonstrated that backward compatibility is not broken by breaking changes and created issues to track deprecated features to be removed in the future. (Please refer to the issue)
[ ] All checks passed in ./risedev check (or alias, ./risedev c)

Checklist For Reviewers

[ ] I have requested macro/micro-benchmarks as this PR can affect performance substantially, and the results are shown.

Documentation

[ ] My PR DOES NOT contain user-facing changes.

Click here for Documentation
Types of user-facing changes
Please keep the types that apply to your changes, and remove the others.

Installation and deployment
Connector (sources & sinks)
SQL commands, functions, and operators
RisingWave cluster configuration changes
Other (please specify in the release note below)

Release note

related #8641


text:
follow関連APIのレスポンスのIDわからん

{
  "id": 0,
  "following": false,
  "followed_by": true
}

IDが何を指すべきなのかわからない。
今の実装だと、AがBをフォローしている、BがAをフォローしているという２つのレコードがある可能性があるし、フォローしてなくてフォローされてなかった場合レコードは存在しない。
テーブルの設計が間違ってる？？
account同士の関係を表すtableを作るとしたら、レコードの数膨大になるからそれはよくなさそう。

swagger見たら相手のIDって書いてあった


text:
Added relations handling

Added ability to specify relations using with parameter.

Hi @AlexKel sorry for delay, so busy! 🙏🏻
Thanks for your contribution, so useful! 😃

authors: AlexKel rjlopezdev


text:
Add failing test for BTreeMap empty serialization

I don't quite know the fix for this, but hopefully its easy if you know the code. Figured a failing test might be useful.
But standard (not AsVec) archive of a BTreeMap fails when its empty.
thread 'test_alloc::tests::archive_empty_btree_map' panicked at 'index out of bounds: the len is 0 but the index is 0', /.../rkyv/rkyv/src/collections/btree_map/mod.rs:532:27

This looks good, thanks for the PR/bug report. I'll take a look at this in #187 and get a fix in as soon as possible.

Sorry totally spaced on following up here -- thanks so much for fixing this, and so quickly. Appreciate it!

authors: djkoloski ianoc

repo: rkyv/rkyv


text:
In order for Calc to read files produced by CSVTest the values must be properly escaped for the ' delimiters

Right now, CSVTest just prints the field values surrounded by single quotes, regardless of the contents. But, in order for Calc to properly read and digest them, the contents of the field must be properly escaped in the case of embedded single quotes and backslashes.  There are CharUtil methods to do this, which should be used.

Of course, we could add an option to CSVTest to write it out in JSON format, so that Calc could read it more or less natively...
Could be an object of column arrays (if there are header column names) or just an array of arrays if not.
If it was an object, then there could be metadata also/instead (such as header names, number of rows, number of columns, etc.)

Also, any embedded newlines or other control characters need to be escaped in the strings in order for Calc to digest the file.

It also appears that the test coverage for "CSVTest" isn't great -- many of the tricky code paths in CSVParser and CSVWriter are not tested at all.

repo: rlwhitcomb/utilities


text:
Types are missing fields when reading file without first importing package

When an NWBFile containing a LabeledEvents or TTLs type is read using PyNWB without first calling import ndx_events, then it is missing the timestamps dataset which should be inherited from Events. Interestingly, the description attribute is correctly inherited from Events.
Example code:
from pynwb import NWBHDF5IO
# import ndx_events

with NWBHDF5IO('nwbfile.nwb', 'r', load_namespaces=True) as io:
    nwbfile = io.read()
    print(nwbfile.acquisition['LabeledEvents'])

Output without importing ndx_events:
LabeledEvents abc.LabeledEvents at 0x1745887195848
Fields:
  data: <HDF5 dataset "data": shape (3,), type "<u4">
  data__labels: ['a' 'b' 'c']
  description: behavioral events of the experimental paradigm

Output with importing ndx_events:
LabeledEvents ndx_events.events.LabeledEvents at 0x2565438502472
Fields:
  data: <HDF5 dataset "data": shape (3,), type "<u4">
  description: behavioral events of the experimental paradigm
  labels: ['a' 'b' 'c']
  timestamps: <HDF5 dataset "timestamps": shape (3,), type "<f4">
  unit: seconds

This is likely an issue of within-spec spec resolution when handling load_namespaces=True and has to be addressed within HDMF.

MWE to generate a file with `LabeledEvents`
from pynwb import NWBFile, NWBHDF5IO, validate
import datetime
from ndx_events import LabeledEvents

nwbfile = NWBFile(
    session_description='session_description',
    identifier='identifier',
    session_start_time=datetime.datetime.now(datetime.timezone.utc),
)

labeled_events = LabeledEvents(name='LabeledEvents',
                               description='behavioral events of the experimental paradigm',
                               timestamps=[1, 2, 3],
                               data=[2, 1, 0],
                               labels=['a', 'b', 'c'])
nwbfile.add_acquisition(labeled_events)

filename = 'nwbfile.nwb'

with NWBHDF5IO(filename, 'w') as io:
    io.write(nwbfile)

with NWBHDF5IO(filename, 'r') as io:
    errors = validate(io)
    print(errors)
    nwbfile = io.read()
    print(nwbfile)
    print(nwbfile.acquisition['LabeledEvents'])

Thanks to @ttngu207 for the bug report!

Thanks to @ttngu207 for the bug report!

repo: rly/ndx-events


text:
Istructions/Docs not well explained

10minutes stuck here with my dork.txt file
Can you add option to search urls using .txt files containing urls

you mean searching dorks from a file?
Edit
@unfairDude So I will add a feature that will allow you to use queries from a text file, or just a string as query.  The program will detect what kind of input you pass as query, between file or string.
Example
Run it with queries from a file
oxdork queries.txt

Run it with a string query
oxdork query_string

Thanks for the suggestion! :)

yes exactly, queries inside a .txt file would be amazing.

@unfairDude I have pushed a release to pypi. If you're still running v3.0.0, update to the latest release and you should be able to pass a file containing queries to the program.
Enjoy!

@unfairDude I have pushed a release to pypi. If you're still running v3.0.0, update to the latest release and you should be able to pass a file containing queries to the program.
Enjoy!

just updsted it.
amazing.
I only have one issue but probably more related to google,
When i use tor, i get the error "429 too many requests"

@unfairDude I have pushed a release to pypi. If you're still running v3.0.0, update to the latest release and you should be able to pass a file containing queries to the program.
Enjoy!

just updsted it. amazing.
I only have one issue but probably more related to google, When i use tor, i get the error "429 too many requests"

Oh yeah, that happens even when you use a VPN.
Solution is probably not using any form of VPN or Tor😅

but then you will get timeoutted if when using normal ip after 50/60 results

but then you will get timeoutted if when using normal ip after 50/60 results

Here's a wild idea, buy a new pc everytime you get 50 results. It's guaranteed to work😂
But serious talk, try using google cloud or gitpod

thank you, on my way to the shop 😬

thank you, on my way to the shop 😬

Haha good luck mate


text:
Strange locale issue

I use de_DE locale. (env tells me LANG=de_DE.UTF-8)
When I use pacman, it is fully localized into German. Pacaur is not, and this is where it gets strange. When I do:
$ pacaur -S pacaur
:: Package(s) pacaur not found in repositories, trying AUR...
:: resolving dependencies...
:: looking for inter-conflicts...
:: pacaur-4.2.22-1 is up to date -- reinstalling

AUR Packages  (1): pacaur-4.2.22-1

:: Proceed with installation? [Y/n] y
$

Pacaur aborts instead of continuing with the installation. When I instead press the localized j (German: "Ja" means "Yes") then the installation continues.

Thanks for the report. This is likely a regression introduced in this 17ce8c8d5dac36f8778442089858e158c061f956, and I have pushed a possible fix in 361f5ee23cd7de48196ccb9b198bb8bbf959939c. Could you install pacaur-git and check if the issue still exists?

Hey, this seems to fix the issue.

authors: Weishaupt rmarquis

repo: rmarquis/pacaur

license: isc


text:
Change intializer path to config/initalizers in README.md

Change the path in the README.md for the initializer file to
config/initializers instead of app/config/initializers.

derp, thanks!

authors: bzf rmosolgo

repo: rmosolgo/react-rails-hot-loader


text:
Google: Eliminate render-blocking JavaScript and CSS in above-the-fold content

It is possible to leave the CSS in the

Hi. To change the order of connection styles, you need to expand your own View class and override the methods renderHeadHtml and renderBodyEndHtml.
The responsibilities of this extension is not included to change the boot order.

authors: newerton rmrevin


text:
Send push notifications for repository activities

Bug Report Dump (Auto-generated)

Version 1.16.0 (1513134612)
Device: iPhone X (iOS 11.2)
TestFlight: false

Going to close as a duplicate of #224 - Let's keep the conversation in one place so it's easier to pick up!
Irrespective of the details such as what notifications are sent for what I think we can all agree that push notifications would be a welcomed feature!

authors: RishabhTayal Sherlouk

repo: rnystrom/GitHawk