After upgrading to XCode 6.4, the RoboVM Run/Debug configurations no longer work

After updating to XCode 6.4 yesterday, the Run/Debug configurations now show blanks for:
Attached device:
Signing Identity;
Provisioning Profile;
Simulator:
Device Type
I attempted to set them from the build.gradle and reimport, but the settings were ignored. Launching from the command line with the build.gradle fails under launchIOSDevice.
If you attempt to launch the simulators from the command line, a ArrayIndexOutOfBoundsException is thrown when loading the devices available:
gradle launchIPhoneSimulator --stacktrace
:launchIPhoneSimulator FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':launchIPhoneSimulator'.

1

Try:
Run with --info or --debug option to get more log output.

Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task ':launchIPhoneSimulator'.
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
at org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:306)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
at org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
at org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23)
at org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88)
at org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23)
at org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68)
at org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55)
at org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149)
at org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
at org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
at org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
at org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
at org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:169)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
at org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
at org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
at org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
at org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at org.robovm.compiler.target.ios.DeviceType.listDeviceTypes(DeviceType.java:112)
at org.robovm.compiler.target.ios.DeviceType.getBestDeviceType(DeviceType.java:221)
at org.robovm.gradle.tasks.AbstractIOSSimulatorTask.getDeviceType(AbstractIOSSimulatorTask.java:96)
at org.robovm.gradle.tasks.IPhoneSimulatorTask.invoke(IPhoneSimulatorTask.java:28)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:218)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
at org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:585)
at org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:568)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
... 44 more

The same exception is thrown in the IDE.

Thanks for reporting. We are scheduling a new studio release for next week.
I've confirmed the RoboVM IDEA plugin to work with Xcode 6.4. Please give
the snapshot a try, in either IDEA or RoboVM Studio. You can find it at
http://download.robovm.com
On Jul 2, 2015 6:03 PM, "tylerpitchford"<EMAIL_ADDRESS>wrote:

After updating to XCode 6.4 yesterday, the Run/Debug configurations now
show blanks for:
Attached device:
Signing Identity;
Provisioning Profile;
Simulator:
Device Type
I attempted to set them from the build.gradle and reimport, but the
settings were ignored. Launching from the command line with the
build.gradle fails under launchIOSDevice.
If you attempt to launch the simulators from the command line, a
ArrayIndexOutOfBoundsException is thrown when loading the devices available:
gradle launchIPhoneSimulator --stacktrace
:launchIPhoneSimulator FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':launchIPhoneSimulator'.
1
-

Try:
Run with --info or --debug option to get more log output.
Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for task
':launchIPhoneSimulator'.
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at
org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
at
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at
org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:306)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
at
org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88)
at
org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at
org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23)
at
org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68)
at
org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55)
at
org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149)
at
org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
at
org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
at
org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
at
org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at
org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:169)
at
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
at
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
at
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
at
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
at
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
at
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at
org.robovm.compiler.target.ios.DeviceType.listDeviceTypes(DeviceType.java:112)
at
org.robovm.compiler.target.ios.DeviceType.getBestDeviceType(DeviceType.java:221)
at
org.robovm.gradle.tasks.AbstractIOSSimulatorTask.getDeviceType(AbstractIOSSimulatorTask.java:96)
at
org.robovm.gradle.tasks.IPhoneSimulatorTask.invoke(IPhoneSimulatorTask.java:28)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:218)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
at
org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:585)
at
org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:568)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
... 44 more
The same exception is thrown in the IDE.
—
Reply to this email directly or view it on GitHub
https://github.com/robovm/robovm-studio/issues/8.

Oh, one more thing. Try opening Xcode and go to Xcode -> Preferences ->
Accounts. Make sure you agree to any new TOS and potentially synch you
signing identities and provisioning profiles.
On Jul 2, 2015 6:05 PM, "Mario Zechner"<EMAIL_ADDRESS>wrote:

Thanks for reporting. We are scheduling a new studio release for next
week. I've confirmed the RoboVM IDEA plugin to work with Xcode 6.4. Please
give the snapshot a try, in either IDEA or RoboVM Studio. You can find it
at http://download.robovm.com
On Jul 2, 2015 6:03 PM, "tylerpitchford"<EMAIL_ADDRESS>wrote:

After updating to XCode 6.4 yesterday, the Run/Debug configurations now
show blanks for:
Attached device:
Signing Identity;
Provisioning Profile;
Simulator:
Device Type
I attempted to set them from the build.gradle and reimport, but the
settings were ignored. Launching from the command line with the
build.gradle fails under launchIOSDevice.
If you attempt to launch the simulators from the command line, a
ArrayIndexOutOfBoundsException is thrown when loading the devices available:
gradle launchIPhoneSimulator --stacktrace
:launchIPhoneSimulator FAILED
FAILURE: Build failed with an exception.

What went wrong:
Execution failed for task ':launchIPhoneSimulator'.
1
-

Try:
Run with --info or --debug option to get more log output.
Exception is:
org.gradle.api.tasks.TaskExecutionException: Execution failed for
task ':launchIPhoneSimulator'.
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:69)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.execute(ExecuteActionsTaskExecuter.java:46)
at
org.gradle.api.internal.tasks.execution.PostExecutionAnalysisTaskExecuter.execute(PostExecutionAnalysisTaskExecuter.java:35)
at
org.gradle.api.internal.tasks.execution.SkipUpToDateTaskExecuter.execute(SkipUpToDateTaskExecuter.java:64)
at
org.gradle.api.internal.tasks.execution.ValidatingTaskExecuter.execute(ValidatingTaskExecuter.java:58)
at
org.gradle.api.internal.tasks.execution.SkipEmptySourceFilesTaskExecuter.execute(SkipEmptySourceFilesTaskExecuter.java:42)
at
org.gradle.api.internal.tasks.execution.SkipTaskWithNoActionsExecuter.execute(SkipTaskWithNoActionsExecuter.java:52)
at
org.gradle.api.internal.tasks.execution.SkipOnlyIfTaskExecuter.execute(SkipOnlyIfTaskExecuter.java:53)
at
org.gradle.api.internal.tasks.execution.ExecuteAtMostOnceTaskExecuter.execute(ExecuteAtMostOnceTaskExecuter.java:43)
at
org.gradle.api.internal.AbstractTask.executeWithoutThrowingTaskFailure(AbstractTask.java:306)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.executeTask(AbstractTaskPlanExecutor.java:79)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.processTask(AbstractTaskPlanExecutor.java:63)
at
org.gradle.execution.taskgraph.AbstractTaskPlanExecutor$TaskExecutorWorker.run(AbstractTaskPlanExecutor.java:51)
at
org.gradle.execution.taskgraph.DefaultTaskPlanExecutor.process(DefaultTaskPlanExecutor.java:23)
at
org.gradle.execution.taskgraph.DefaultTaskGraphExecuter.execute(DefaultTaskGraphExecuter.java:88)
at
org.gradle.execution.SelectedTaskExecutionAction.execute(SelectedTaskExecutionAction.java:29)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at
org.gradle.execution.DefaultBuildExecuter.access$200(DefaultBuildExecuter.java:23)
at
org.gradle.execution.DefaultBuildExecuter$2.proceed(DefaultBuildExecuter.java:68)
at
org.gradle.execution.DryRunBuildExecutionAction.execute(DryRunBuildExecutionAction.java:32)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:62)
at
org.gradle.execution.DefaultBuildExecuter.execute(DefaultBuildExecuter.java:55)
at
org.gradle.initialization.DefaultGradleLauncher.doBuildStages(DefaultGradleLauncher.java:149)
at
org.gradle.initialization.DefaultGradleLauncher.doBuild(DefaultGradleLauncher.java:106)
at
org.gradle.initialization.DefaultGradleLauncher.run(DefaultGradleLauncher.java:86)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter$DefaultBuildController.run(InProcessBuildActionExecuter.java:80)
at
org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:33)
at
org.gradle.launcher.cli.ExecuteBuildAction.run(ExecuteBuildAction.java:24)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:36)
at
org.gradle.launcher.exec.InProcessBuildActionExecuter.execute(InProcessBuildActionExecuter.java:26)
at org.gradle.launcher.cli.RunBuildAction.run(RunBuildAction.java:51)
at
org.gradle.internal.Actions$RunnableActionAdapter.execute(Actions.java:169)
at
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:237)
at
org.gradle.launcher.cli.CommandLineActionFactory$ParseAndBuildAction.execute(CommandLineActionFactory.java:210)
at
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:35)
at
org.gradle.launcher.cli.JavaRuntimeValidationAction.execute(JavaRuntimeValidationAction.java:24)
at
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:206)
at
org.gradle.launcher.cli.CommandLineActionFactory$WithLogging.execute(CommandLineActionFactory.java:169)
at
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:33)
at
org.gradle.launcher.cli.ExceptionReportingAction.execute(ExceptionReportingAction.java:22)
at org.gradle.launcher.Main.doAction(Main.java:33)
at org.gradle.launcher.bootstrap.EntryPoint.run(EntryPoint.java:45)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.runNoExit(ProcessBootstrap.java:54)
at
org.gradle.launcher.bootstrap.ProcessBootstrap.run(ProcessBootstrap.java:35)
at org.gradle.launcher.GradleMain.main(GradleMain.java:23)
Caused by: java.lang.ArrayIndexOutOfBoundsException: 1
at
org.robovm.compiler.target.ios.DeviceType.listDeviceTypes(DeviceType.java:112)
at
org.robovm.compiler.target.ios.DeviceType.getBestDeviceType(DeviceType.java:221)
at
org.robovm.gradle.tasks.AbstractIOSSimulatorTask.getDeviceType(AbstractIOSSimulatorTask.java:96)
at
org.robovm.gradle.tasks.IPhoneSimulatorTask.invoke(IPhoneSimulatorTask.java:28)
at org.gradle.internal.reflect.JavaMethod.invoke(JavaMethod.java:63)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.doExecute(AnnotationProcessingTaskFactory.java:218)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:211)
at
org.gradle.api.internal.project.taskfactory.AnnotationProcessingTaskFactory$StandardTaskAction.execute(AnnotationProcessingTaskFactory.java:200)
at
org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:585)
at
org.gradle.api.internal.AbstractTask$TaskActionWrapper.execute(AbstractTask.java:568)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeAction(ExecuteActionsTaskExecuter.java:80)
at
org.gradle.api.internal.tasks.execution.ExecuteActionsTaskExecuter.executeActions(ExecuteActionsTaskExecuter.java:61)
... 44 more
The same exception is thrown in the IDE.
—
Reply to this email directly or view it on GitHub
https://github.com/robovm/robovm-studio/issues/8.

Everything is synched, the first thing I tried actually. And did you mean http://download.robovm.org? The other link is dead.
Downloading now; I'll update when I get it installed.
Best,
Tyler

I tried installing under my RoboVM 1.4 EAP installation, but I get a message:
"Plugin 'RoboVM IntelliJ IDEA Plugin' is incompatible with this installation."
I tried removing the old RoboVM plugin before installing, but got the same result.

Sorry for the inconvenience, the Studio EAP has it's API version set
incorrectly. If you are in a hurry, i suggest getting IDEA community
edition plus the RoboVM plugin snapshot. Again, sorry, you are living on
the edge with the EAP :)
On Jul 2, 2015 6:37 PM, "tylerpitchford"<EMAIL_ADDRESS>wrote:

I tried installing under my RoboVM 1.4 EAP installation, but I get a
message:
"Plugin 'RoboVM IntelliJ IDEA Plugin' is incompatible with this
installation."
I tried removing the old RoboVM plugin before installing, but got the same
result.
—
Reply to this email directly or view it on GitHub
https://github.com/robovm/robovm-studio/issues/8#issuecomment-118088378.

No worries at all, thanks for the quick updates!
Great work by the way.

Could you give the latest and greatest a try and report back?

I just reopened the project and it's showing up blank. I'll try to make a new one and see if that fixes anything.

This should be fixed with the 1.6 release. Please let us know if it doesn't fix it for you. I was unable to reproduce it locally and could only go by your log.


.Net Standard 2.0 Support

Hi great package!
I was wondering if perhaps it would be possible multi-target this project to build both .Net standard 2.1 and 2.0 nuget packages.
For us poor souls stuck on Framework 🐮

@CoenraadS , hi! I'll try build a version for 2.0. Stay tuned.

I'm not sure if it matters, but since there are so many different packages, I'm using
<PackageReference Include="Microsoft.AspNetCore.SignalR" Version="1.1.0" />
Despite it's name, this package also works on framework. On our project we basically upgraded as far as we could, before packages became core exclusive. This means we are also using:
    <PackageReference Include="Microsoft.AspNetCore" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Hosting.WindowsServices" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="2.2.0" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning" Version="3.1.5" />
    <PackageReference Include="Microsoft.AspNetCore.Mvc.Versioning.ApiExplorer" Version="3.2.0" />
    ```

    If required I can upload a demo project.

@CoenraadS , I published a preview version of my package. Please test if it works with your project and let me know. Thanks!

It's working <3

@CoenraadS , you can add xml comments and set the http verb like this:
options.AddSignalRSwaggerGen(x => { 	x.UseXmlComments("path to xml comments file"); 	x.Operation = Operation.Get; });
If I can help with anything else, let me know.


Spike: KubeFlow for ML Workflows

Description:
KubeFlow is a potential solution for optimizing ML workflows and deployment pipelines. This spike is to investigate its capabilities, advantages, and potential shortcomings to determine its fit for our future projects.
Tasks:

[ ] Set up a KubeFlow instance in a sandbox environment.
[ ] Walk through the basic KubeFlow tutorials and understand its key components.
[ ] Implement a simple ML model through KubeFlow's pipeline.
[ ] Document any limitations or challenges discovered during the exploration.
[ ] Prepare short demo

Acceptance Criteria:

[ ] A running KubeFlow instance in the sandbox environment.
[ ] Documented outcomes from each task listed above.
[ ] Short demo

Resources:
KubeFlow Official Documentation
KubeFlow GitHub Repository

Closing this as KubeFlow is not relevant at this moment for the integration with Azure OpenAI


problems install v4

Trying to install go-git.v4, I get this error:
$ go get -u gopkg.in/src-d/go-git.v4/...
# gopkg.in/src-d/go-git.v4/formats/packfile
../../../gopkg.in/src-d/go-git.v4/formats/packfile/scanner.go:168: undefined: io.SeekCurrent
../../../gopkg.in/src-d/go-git.v4/formats/packfile/scanner.go:311: undefined: io.SeekCurrent
../../../gopkg.in/src-d/go-git.v4/formats/packfile/scanner.go:316: undefined: io.SeekStart
../../../gopkg.in/src-d/go-git.v4/formats/packfile/scanner.go:434: undefined: io.SeekCurrent
../../../gopkg.in/src-d/go-git.v4/formats/packfile/scanner.go:454: undefined: io.SeekCurrent

Looks like the methods SeekCurrent and SeekStart really don't exist.
Rather, the golang io package defines a Seeker interface, with a Seek method, that takes it's Current/Start/End parameter as an integer argument:
https://golang.org/src/io/io.go?s=4702:4774#L102
https://golang.org/src/io/io.go?s=4702:4774#L20

Looks like the methods SeekCurrent and SeekStart really don't exist.

Whoops. I see now this is precisely what this code is trying to do; access these constants.
https://github.com/src-d/go-git/blob/master/formats/packfile/scanner.go#L158

Apparently this is a Go 1.6 vs. 1.7 thing. Sorry to bother you with this issue. Thanks for making such a great library!

Hahaha, yes, we only support 1.7, sorry about the outdated documentation. We plan to release the v4 soon, and update all the examples and documentation. Thanks


[Check Symptoms]: Mockup general chat container within page

Enhancement
Desired Functionality
I need to mockup what that in-page chat container looks like across all screen sizes
Current Functionality
Currently there is no chat container here
Other remarks
Related to: https://github.com/CovidSC/covidsc-web/issues/52

We aren't sure how much of this will be within our control yet but here is a mockup of how this will ideally look:


LevelResolver of JsonTemplateLayout wrongly assumes that Level.values() is constant

LevelResolver contains caches for Level-to-String conversion. These caches are populated only once at class initialization and used throughout the lifetime of the class. Though Level.values() used for populating these caches are not constant and hence can cause LevelResolver to miss entries for levels that are added after the class initialization.

Fixed in e0a2bcb4dc4c475ec79bb8b7b876f46062579eef (2.x) and 97e441dd9ee4236fd1ba31bc373bebee483a2ddc (main).


Add query flags to declare (refactor transaction flow)

DISCLAIMER: I know this PR is big :(, but I felt it was necessary already when I tried to add query_flag for declare and I noticed that I probably had to duplicate methods in the current design (from send existing integration), and the NRE API UX felt bad. I feel that letting this refactor for later would have made it harder.
Fixes #308 #242
Besides adding query_flag for declare and deploy_contract, this PR proposes a refactor of the internal transaction flow of Nile, improving the NRE interfaces, and making it easier to add logic to transactions in one place, among other things...
Now NRE transaction execution commands always (must) return a transaction status, containing the tx_hash, the status of execution (ACCEPTED, REJECTED, etc...), and error messages in case of REJECTION, improving the UX. status is always used even when track or debug are not set, with the difference that it doesn't hang, but return the current status.
These are some examples of what you can do with scripting now:
# script.py
async def run(nre):
    accounts = await nre.get_accounts(predeployed=True)
    account = accounts[0]

    # get account declare wrapper
    # the wrapper is for registering deployments, or declarations, those Nile specific things
    # you could use the low level transaction to avoid this, and just execute the transaction
    tx = await account.declare("Account", watch_mode="track")

    # get the estimate fee in WEI
    fee = await tx.estimate_fee()

    # get the simulation trace in a dict
    simulation_trace = await tx.simulate()

    # execute the transaction
    # you will get the tx_status even if you pass pass watch_mode=None
    # in this case the transaction won't hang, and the status will be PENDING
    # in a testnet (probably, could be REJECTED)
    tx_status, _ = await tx.execute()

    # print ACEPTED_IN_L2
    print(tx_status.status)

    # more info in tx_status, always available after the execution
    print(tx_status.tx_hash, tx_status.error_message)

IMPORTANT: There are a lot of tests to either add, refactor or remove, then I will wait for approval of the logic before starting adding coverage. I tested the features manually before submitting them.
NOTE: The only command I haven't refactored is the deploy of the account itself, because deploy_account is not using execute_call, but calling the gateway directly. I know this is because deploy_account in starknet_cli requires a straknet account, and is not open to integrations @martriay. I would need to work in a work around for this, but I didn't want to delay this PR more. That's the only command that is not going through the new flow.
Every feedback is appreciated, I know there should be a lot of details, but I hope the idea would help us.

direction looks good, but I don't think we can squeeze it into this milestone. the idea was to release a patch and this won't even make it for the actual release train (we already have ERC1155 as main priority and a lot of unexpected time went to Nile issues). we can find time for it in the next one though, since it already overlaps a bit with it.
besides code duplication, are there any real blockers to implement the feature without a full refactor?

let's do that. we just need to release a patch and unblock Eric's work on the upgrade plugins.

Sure.

most of the issues you mention are out of scope for this specific issue and goals we have in mind.

Agree out of scope for this issue. For goals, IMO they are crucial long-term for adoption, and they get harder to tackle as the project grows bigger.

@martriay @andrew-fleming this PR is ready for review already


SSO experimental sample cleanup

Cleaned up and simplified the SSO experimental sample.
Improved dialog flow.
Removed unnecessary overloads.
Aligned sample structure and code with SkillDialog sample

Hi @JonathanFingold, this will probably impact some of the docs we have, can you also take a look?
Thanks

Hi @JonathanFingold, this will probably impact some of the docs we have, can you also take a look?
Thanks

Hi @JonathanFingold, this will probably impact some of the docs we have, can you also take a look?

@gabog -- Thanks, I'll take a look.

Hi @JonathanFingold, this will probably impact some of the docs we have, can you also take a look?

@gabog -- Thanks, I'll take a look.

This is a stale PR, closing


Fixed printing disabled

Fixes #131

Coverage increased (+0.09%) to 87.858% when pulling 4c9f0ec6f98b04664650a5d30d558f263040048b on bs/fix_memcpy into 1287329ddf48d8a8982a7d0774323a492895beda on master.

Looks good! Thanks for doing this. I just have one minor comment.


Dependencies: Update pylint~=2.16.0

Codecov Report
All modified lines are covered by tests :white_check_mark:

Comparison is base (379c8c0) 89.87% compared to head (e7a3e4d) 89.87%.

Additional details and impacted files
@@           Coverage Diff           @@
##             main      #69   +/-   ##
=======================================
  Coverage   89.87%   89.87%
=======================================
  Files          10       10
  Lines         464      464
=======================================
  Hits          417      417
  Misses         47       47

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.


tests improvements

fix(plugins/npm): optimize conditions
fix(plugins/git): add more optimizations
fix(plugins): npm/post optimizations
test: add more cases, improve old behaviors
chore(ci): add more env for tests
fix(core): throw on empty repo
test: add new test-cases

Pull Request Test Coverage Report for Build #77
Details

34 of 40 (85.0%)  changed or added relevant lines in 4 files are covered.
27 unchanged lines in 4 files lost coverage.
Overall coverage increased (+4.8%) to 91.182%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

plugins/npm-post.sh
24
27
88.89%

plugins/npm.sh
2
5
40.0%

Files with Coverage Reduction
New Missed Lines
%

presets/workspace.sh
1
94.0%

presets/conventional-commits.sh
3
92.31%

release.sh
8
95.56%

plugins/github-release.sh
15
37.5%

Totals

Change from base Build<PHONE_NUMBER>:
4.8%

Covered Lines:
455

Relevant Lines:
499

💛  - Coveralls


Date format of quote wrong

Describe the bug
The format of the "date of quote" is dd/MM/yyyy hh:mm:ss on some machines format
To Reproduce
Steps to reproduce the behavior:

Go to https://quotes.kallisto.li/
Look at the date of a quote

Expected behavior

The time part is removed.
The format is displayed either as dd.MM.yyyy or dependen on the culture of the user

@Kifkof
I believe the current date format is actually MM/dd/yyyy


load_gltf doesn't preserve node's postion values

I've been encountering this issue persistent across all the gltf files I've tried where multiple nodes of the gltf scene are centered on the origin ignoring their position defined in the gltf file. You can reproduce the bug with the code from repo example:
    let default = concat!(env!("CARGO_MANIFEST_DIR"), "/test_data/Plane/scene.gltf");
    window.scene.add(&gltf);

    let mut mixer = three::animation::Mixer::new();
    for clip in gltf.clips {
        mixer.action(clip);
    }

I got the gltf from: https://sketchfab.com/models/f312ec9f87794bdd83630a3bc694d8ea#download
As you can see the propellers are not where they are supposed to be:

Pinging @alteous just in case


[Hackathon] Implementation of Gallery feature UI

Choose UI framework
Prototyping
Design component or make it out for Hackathon

This is great work!
Thank you for this work. Dongguri.
/cc @nadongguri, @coconutperm, @hyungheo


No way to support custom LWIP implementations when NO_LWIP enabled

The Pico SDK gives a good, simple set up for LWIP use, but it combines the WiFi state control and the TCP stack setup in cyw43_lwip https://github.com/georgerobotics/cyw43-driver/blob/195dfcc10bb6f379e3dea45147590db2203d3c7b/src/cyw43_lwip.c and in the SDK proper in pico_cyw43_arch.
Unfortunately, I think this makes it impossible, without duplicating large portions of the CYW43 support in the SDK, to do more advanced setup (i.e. configure the AP to other addresses, start with a static IP address, use IPV6) and use.
The SDK can be configured with CYW43_LWIP=0 while still enabling the CYW43 driver (I assume mainly for LED support?) and all the WiFi link-level support, but any use of LWIP at the app-level is denied because there are predefined callbacks the CYW43 driver calls that are hard-coded to panic the machine:
https://github.com/raspberrypi/pico-sdk/blob/2e6142b15b8a75c1227dd3edbe839193b2bf9041/src/rp2_common/pico_cyw43_arch/cyw43_arch_threadsafe_background.c#L300-L317
If these panic CBs were made weak, then the default behavior would still happen (as an aside, does it make sense to crash w/apanicin runtime on the device vs. just failing to link at build time?) but a user application could but an application could override them and do their own LWIP from-the-ground-up implementation.
The alternative now would be to build with CYW43_LWIP=0 but not use anything from pico_cyw43_arch and  delete the fake CBs in the SDK .c library and implement your own cyw43_cb_process_ethernet, etc.

#960 is related to this.  Multicast packers are filtered in the CYW43 driver, making IPv6 communications impossible.

I love my Raspberry Pi, and Pico's and I just got my hands on 5 Pico W's. I was extremely disappointed in the lack of documentation and examples for C/C++ of the SDK for Pico W. The "how to" official Raspberry Pico W guide on getting connected spends just a few pages on C/C++ before quickly moving on to python which takes up most of the document with more examples etc...
I understand for many Python is the language of choice. However Raspberry shouldn't leave those who choose C/C++ as 2nd class customers. We deserve the same level of attention and examples Python gets. I apologize if this is not the correct place for this to be brought up but I'm not sure how else to get feedback to Raspberry that will actually be seen/read.
You have nice pictures and examples for wiring an LED and seeing it on a webpage for Python, all missing from the C portion. Why? I hope Raspberry as the Pico W's continue to take off in popularity really steps up their game with more detailed examples, (commented code) and a robust SDK. I know ultimately many developers will do this on their own and share it, but I feel Raspberry owes it to the C community to not have to stumble so hard keeping in mind not all C programmers are experts such as myself.
Programming The Raspberry Pi Pico In C - by Fairhead, Harry - this book -  was a godsend.
It got me up and running quickly versus what Raspberry offers. You have example projects with code and of course the SDK PDF, but a few more in-depth examples wouldn't hurt (especially in the SDK PDF) and sometimes they go a long way for people who are not C experts. I'm not giving up on C or the Pico W, I know more will come. I hope it gets the attention deserved.
The ESP8266 wifi module for example has tons of great information both in C and in python. I own some of these ESP8266's and My main attraction to the Pico W was it was built in and I was expecting a robust SDK. I hope you'll prove me right.
ProTip for Raspberry or anyone extremely skilled in C, if you write a book similar to the one I mentioned and go even deeper you will make a fortune!
I mean no disrespect and I am eager to see future documentation/SDK/code examples that are yet to come! C is not dead! :)

@anglerfish27 you will only annoy people putting random comments on random bug reports. You'll achieve more by commenting on the forum. Have you looked at the examples in the pico-examples repo? What's missing? Post your feedback in the forum

I'm not sure how else to get feedback to Raspberry that will actually be seen/read.

If you want to provide actual feedback, rather than just moaning, you can do so at https://github.com/raspberrypi/pico-feedback
The reason there's so much more hand-holding in the getting-started guide for Python than there is for C, is because we've naturally assumed that more beginners will choose to use Python than use C.
As Peter mentions, there are additional C examples for Pico W in https://github.com/raspberrypi/pico-examples/tree/develop/pico_w

@anglerfish27 I will remove your comment soon, since it has nothing to do with this issue... so please copy/paste it if you wish to submit it to pico-feedback

I've had some serious user hours running the PicoW and a some painful debugging of my Arduino core code to get things stable and come up with several issues related to this LWIP/CYW43 stuff.  If it would be better to close this issue and open a new one, please let me know.  Also, again, I'm not trying to present myself as an LWIP expert...but I have seen a lot of the LWIP code from within GDB at this point. 😆
Weak calls for the cyw43_cb callbacks
This is needed to allow separation of WiFi physical link and the TCP/IP link state.  The original PR (closed now) seems to meet this specific requirement.   https://github.com/raspberrypi/pico-sdk/blob/2e6142b15b8a75c1227dd3edbe839193b2bf9041/src/rp2_common/pico_cyw43_arch/cyw43_arch_threadsafe_background.c#L300-L317
"Background" LWIP mode is dangerous and should be deprecated/removed or all LWIP calls should be wrapped
LWIP is not multi-thread safe/re-entrant in the NO_SYS mode, at all.  See https://www.nongnu.org/lwip/2_0_x/pitfalls.html .  But, the CYW43 wrapper is calling sys_check_timeouts from an alarm/IRQ.  99% of the time this is fine in a lightly loaded system.  But under load you may end up inside LWIP code when the IRQ fires and sys_check_timeouts ends up modifying LWIP state.  When that happens you will end up crashing as things become inconsistent internally.  I've also seen infinite loops inside LWIP because of this, so even though there is no crash there is a hang.
Also, the CYW43 driver
https://github.com/georgerobotics/cyw43-driver/blob/195dfcc10bb6f379e3dea45147590db2203d3c7b/src/cyw43_lwip.c#L219 is also using an LWIP netif->input() call from within an IRQ callback from the WiFi chip.  The same issue happens at this point because LWIP isn't re-entrant in NO_SYS.  You could be within an LWIP block and hit this line and the LWIP state will become borked.
A potential (extreme) solution to this would be to use the linker wrap -Wl--wrap=... option to wrap all LWIP calls and set a semaphore so that the sys_check_timeouts and the netif->input() call can be skipped if the IRQ happens while w/in LWIP code.  My own code ended up doing this with simple wrappers and either skipping the sys_check_timeouts call and the netif->input calls (dropping the packet) while inside an LWIP call.
The background mode is really nice from a user perspective and would be great to keep, IMHO.  But it's just not stable under continuous load w/o some work in my experience.
I think SYS_ARCH_PROTECT/UNPROTECT should be defined for background (NO_SYS) mode
This is more of a pico-examples thing, but the LWIP memory management routines are not re-entrant (see above).  pbuf_xxxx is legal to call from within an interrupt context, but it is not interrupt safe either.  So, either the pbuf_xxx calls need to be protected in the same way as other upper-LWIP layers, or interrupts need to be disabled for safety.  For example, the CYW43 Ethernet driver could allocate a PBUF to store the received packed from within an IRQ even if it couldn't call netif->input() due to the block described above (i.e. the LWIP wrappers could netif->input() the PBUF at some safe point later).
In my own experience the above changes moved my CYW43/LWIP from crashing after 10s of minutes and 10,000s of GET requests to running for > 24hrs and 2 million GETs w/o a crash or hang while in NO_SYS mode.

Thanks for the detailed report;

LWIP is not multi-thread safe/re-entrant in the NO_SYS mode, at all. See https://www.nongnu.org/lwip/2_0_x/pitfalls.html . But, the CYW43 wrapper is calling sys_check_timeouts from an alarm/IRQ

This is a bug which i just noticed myself this week.

^ but yes, please separate the above info into a new issue

I've hidden the comment here and moved to #1079.  The weak callbacks are still needed and covered w/the original notes.

fixed by #1177

#1177 merged into develop


Respect parameters of superclass’s initialize method

In the AutoInject's generated #initialize, send arguments to super() based on the arity of that method.
This should ensure it will work in situations where the AutoInject module is mixed into a subclass, with the intention that some or all of the injected dependencies get passed to the superclass's #initialize (e.g. when auto-injecting the ROM environment into a ROM::Repository::Root subclass).
This is still a WIP, but the most complicated case is done (support for param arguments). I'm posting this PR in case anyone wants to start looking things over while I work on the rest.
Still to do:

[x] Param arguments
[x] Hash arguments
[x] Keyword arguments
[x] Support for Ruby 2.0.x and 2.1.x (which don't have #super_method)

Passing proper args up to the super initialize method now works for all injection types!
I've also broken the code down into smaller files and done some renaming to make everything a little clearer:

Injector is the object connected to the container ready to be mixed in inside your app’s classes.
Injection is the module that actually gets included when the Injector is called with the names of the class’s dependencies.

I was about to say this was ready to go into master, but it seems this still hasn't fixed the problem with ROM::Repository::Base 😩 I'll keep this open and do some more investigating.

Oh wait! It does fix the ROM::Repository::Base issue! In my test case I forgot to include the injection.
So now we can do this (lifted from a dry-web app of ours):
require 'rom-repository'
require 'my_app/import'

MyApp::Container.boot!(:rom)

module MyApp
  class Repository < ROM::Repository::Root
    include MyApp::Import("persistence.rom")
  end
end

And the ROM container gets properly passed to the repository 🎉
So this is ready to go into master now.

Fantastic, awesome work!

👍  nice! Will try it ASAP


Dev to main sync

Developer Name: @shubhamsigdar1
PR Number(s):-

https://github.com/Real-Dev-Squad/website-my/pull/515

Issue Ticket Number:-

https://github.com/Real-Dev-Squad/website-my/issues/507

Backend changes

[ ] Yes
[x] No

Frontend Changes

[x] Yes
[ ] No

Is Under Feature Flag

[x] Yes
[ ] No

Database changes

[ ] Yes
[x] No

Breaking changes (If your feature is breaking/missing something please mention pending tickets)

[ ] Yes
[x] No

Deployment notes - No
Any special instructions for the deployment - No
Tested in staging

[x] Yes
[ ] No

List of PRs going in this Sync.

https://github.com/Real-Dev-Squad/website-my/pull/515

Also attach their screenshots.
https://github.com/Real-Dev-Squad/website-backend/assets/107163260/57d93eca-de6a-4760-8491-eb44dbdcb95f

@PeeyushPrashant


RedirectUri Format Causes Issue With Client Side Routing

I'm getting unexpected results when the client is redirected back to the application after sign in. The initial redirect url is in the following hash  format:
http://localhost:4200/login#state=4f396e52-01c4-4ede-bafc-2964d1391182&client_info=mytoken&id_token=mytoken
In this case my client side login route is never activated, instead the framework or web server redirects browser back to http://localhost:4200.  The return url from the tenant should be in query string format like below:
http://localhost:4200/login?state=4f396e52-01c4-4ede-bafc-2964d1391182&client_info=mytoken&id_token=mytoken
I'm not certain if this is an issue with the library itself, or an issue with the server side code on the tenant.

My issue is was trying to handle the post sign in logic outside of the token callback. So I moved my return url logic inside the token callback method


imu style updates

The GPS tests probably caused the failure. I just fixed it, so it should run this time.

This branch got into a weird state. Going to redo my edits and open a new pull request.


Added Diaspora support for social links in footer.html

Added Diaspora for social links in footer.html and _config.yaml. Defautl Icon is currently a simple square.
I already requested an additional FontAwesome icon for Diaspora. This can be replaced as soon as available.
Cheers,
Bernd

I will look like Demo

The theme has been rebuilt to support any type of icon/link in the author sidebar and footer, which makes these sorts of edits unnecessary.
This will land in #265 once merged.

3.0.1 has been released and now supports adding your own "author" links now.


How to get inference result?

Thanks for your great work.
I want to infer a trained spacetimeformer model. The model needs 4 inputs; (x_c, y_c, x_t, y_t).
We have only x_c, y_c, and x_t ready.

y_t must be zeros with right shape. Right?

output, (logits, labels), attn = spacetimeformer(x_c, y_c, x_t, y_t).  The output has two tensors; output.loc and output.scale.
What is the real output for y_t here? output.loc or output.scale?
Thanks in advance.

Hi, if you are using a MSE or MAE loss function, the output you are looking for is output.loc, which is the mean of the distribution the model predicts. output.scale is the std dev and it will not be informative unless you are training with the NLL loss function.

We must feed zero y_t to the model. Right?

And the output.loc needs inverse scaling or can be used directly as predicted values?

Hopefully this is fixed with the new Forecaster.predict method


[cleanup] Remove v0_deprecated batch ingestion jobs

Clean up v0_deprecated batch ingestion jobs

Codecov Report

Merging #10532 (7f36b2e) into master (1fc8150) will decrease coverage by 13.93%.
The diff coverage is n/a.

@@              Coverage Diff              @@
##             master   #10532       +/-   ##
=============================================
- Coverage     27.80%   13.87%   -13.93%
- Complexity       58      437      +379
=============================================
  Files          2087     2049       -38
  Lines        112307   110257     -2050
  Branches      16918    16678      -240
=============================================
- Hits          31226    15302    -15924
- Misses        77988    93713    +15725
+ Partials       3093     1242     -1851

Flag
Coverage Δ

integration1
?

integration2
?

unittests2
13.87% <ø> (?)

Flags with carried forward coverage won't be shown. Click here to find out more.
see 977 files with indirect coverage changes
:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

@snleee @jackjlli Do we still need these old deprecated ingestion jobs?


Biased Shapley Value Implementation

Thanks for the nice work!
The Shapley values implementation gives a biased estimate of the formula given in the paper as the weighting factor is missing. This leads to biased Shapley value estimates, though I do not believe it would change the gist of your results.
Some relevant pointers to how Shapley values are currently computed in the codebase:

The Shapley value (positive,negative) pairs are prepared here for example for the neighbors.
Since each feature is dropped/replaced with a 50% chance (here and here), there is an equal probability for each coalition size (i.e., feature subset size), |S|.
The Shapley value is then computed as the average of those pairs here.

My back-of-the-envelope expectation computation suggests that in such case a weighting factor of $\frac{2^{n-1}}{n {n - 1 \choose |S|}}$ needs to be added to unbias the estimate of the Shapley value, where n is the number of features for the current datapoint (i.e., the history and visible neighbors) and $|S|$ is the number of features (history/neighbors) that will be dropped/replaced. The numerator is needed to take into account the sampling probability of each sample, as each of the n-1 features will be dropped/replaced with a probability of $\frac{1}{2}$.
Do you possibly have some insights on the missing weighting factor? Was the weighting factor left out on purpose?

Hi,
Thanks for your question and interest in our paper.
Yes, you are right, but in our experimental results, we observe no difference between adding the weights or not, hence we opt for the simpler version in the code.
Best,
Osama

Thank you for the quick response and clarification, Osama. Closing the issue in that case!


Add build-logic to make adding new modules easier

Summary
This moves sigstore-java sources to sigstore-java folder. The move itself is done in a separate commit to make review easier.
Release Note

Added build-logic to make adding new modules easier

Documentation
WDYT?

Sorry for force-push storm. I just realized that I should move /build.gradle.kts -> /sigstore-java/build.gradle.kts before adding build logic.
Then Git realizes that /build.gradle.kts with added build logic is a brand new file, and it shows a better history for /sigstore-java/build.gradle.kts

There's a recent idea to use /gradle/plugins folder instead of /build-logic: https://github.com/gradle/gradle/pull/21192

I think what would make this easier for is to just create the new dir structure without build logic updates.
The build-logic seem to apply pretty strongly to a gradle plugin? But maybe I'm misunderstanding it.

I must have missed this.
I believe this PR adds only the bits that are required to build sigstore-java, and the build logic updates for building Gradle plugin are not here (they go in the last commit of https://github.com/sigstore/sigstore-java/pull/98)

If this is ready to go, I'll merge it?

Go ahead


[WIP]Improve symbol bindings

This PR needs to run more tests to be merged. Please focus on reviewing the interface changes first.
The digit 2 in the names of InitXXX functions is used to distinguish from the old interfaces. I will remove the digit 2 once we finalize the interfaces after the review.
In the backend, the binding flow for symbol.simple_bind is
MXExecutorSimpleBind-->Executor::SimpleBind-->GraphExecutor::Init2-->GraphExecutor::InitGraph2-->GraphExecutor::InitFullGraph2

and for symbol.bind is
MXExecutorBindEX-->Executor::Bind-->GraphExecutor::Init2-->GraphExecutor::InitGraph2-->GraphExecutor::InitFullGraph2

The Init2 functions for simple_bind and bind are different, while they share the same InitGraph2 and InitFullGraph2.
This PR:

Moved NDArray creation to the backend from symbol.simple_bind.
Changed front end function _bind_ith_exec to go through the symbol.simple_bind flow.
Consolidated symbol.simple_bind and symbol.bind flows in backend for maximum code sharing.

@piiswrong @eric-haibin-lin @madjam

Could you resolve the conflicts and fix lint?

@eric-haibin-lin Fixed.

Generally looks good. Please remove *_v1 in front end and add more tests.

Is this good to merge?

@eric-haibin-lin This still needs tests for executor group. After discussing with @piiswrong , we can do it in this way. Submit this PR in your repo and you can use it for sparse tensor, while I finish writing tests for the executor group. Let me know what you think.

@reminisce are you gonna submit another to dmlc/mxnet after your test is done? What's the implication when the sparse branch merges with dmlc/mxnet?

@eric-haibin-lin If I submit this PR to your repo, I will submit test PR to your repo too. You can merge with dmlc/master after your sparse tensor is done with my changes on symbol binding. Does this work for you?

Yeah that sounds good!

I submitted this PR to https://github.com/eric-haibin-lin/mxnet/pull/31 for sparse tensor development. Please do not merge this PR into dmlc/master.

I'll merge this for now. We may need to improve some error messages if users get confused by it.

Yes better error message is needed, i am aware that it segfaults when infer shape fails in graph_executor.

why would it segfault? @reminisce Could you fix that first?

The functions InferShape and InferType could fail if users provide insufficient information. If it fails, the program continues with 0-size ndarrays and may cause segfaults.


Ignore transient proto directories

Remove proto and stack related working directories :)

I didn't realize people actually looked at examples!


T02.06-Solution-AddPolish

Finished by EGMP

Complete.

Done!

PR is requesting we merge changes from later lesson branches into earlier lesson branches.
We will not be doing this as these branches are set-up this way on purpose for the course.


Introduce command register mechanism to allow splitting command definition to multiple TUs

To make #1138 possible, we must have a register mechanism instead of a global command table, which is provided in this PR.

Thanks all. Merging...


Install hangs

Install hangs after verify Dotnet 7 and the WASM module. Says it is uninstalling current version and stops there. Any idea on fix?
Never mind..fix was to restart system. It then fully installed.

Closing => fixed itself ;)
Next Time: At least a Screenshot (Installer has no Log File) - or else the Issue will directly be closed.


New org

Hi @veeramarni @jokeyrhyme
I'm re-organizing some of my stuff on Github and I have big plans related with TypeScript. When I created this organization the plan was to create tools to help Redux developers but I want to increase the scope and help TypeScript developers in general.
So I have created a new org https://github.com/FullstackTypeScript and I have plans to transfer the repositories from this org to the new org.
I will invite you to join the new org :smile:

@remojansen I'm working on creating a lerna package system to incrementally add packages to avoid being too opinionated with packages and provide a various way to implement react redux best practices. Also, we can inject reducer's to develop a highly scalable app.
Created something here
This is highly experimental now, but once it comes to a stable point, I want to push it here.
I will also look forward to new FullStackTypescript plan.

@veeramarni that soudns great for me the Idea is to use FullStackTypescript as a place for people to share TypeScript projects that will help other TS developers :)

Welcome to the new org 🎉


SyntaxError: Unexpected token export in index.js

Thanks for your API, I'd like to use it but got some errors at node_modules/google-slides/index.js:1
The error is:
(function (exports, require, module, __filename, __dirname) { export { API, TextReplacement } from './api.js'
SyntaxError: Unexpected token export
at new Script (vm.js:73:7)
at createScript (vm.js:245:10)
at Object.runInThisContext (vm.js:297:10)
at Module._compile (internal/modules/cjs/loader.js:657:28)
at Module._extensions..js (internal/modules/cjs/loader.js:700:10)
at Object.require.extensions.(anonymous function) [as .js] (/usr/local/lib/node_modules/babel-cli/node_modules/babel-register/lib/node.js:152:7)
at Module.load (internal/modules/cjs/loader.js:599:32)
at tryModuleLoad (internal/modules/cjs/loader.js:538:12)
at Function.Module._load (internal/modules/cjs/loader.js:530:3)
at Module.require (internal/modules/cjs/loader.js:637:17)

Hi @jennycai0807
Please make sure you are using the latest version of nodejs:
nvm install node
nvm use node
node -v

The output from the last line must be 13.11.0 or greater, otherwise this package will not work for you.
You may also need to add "type": "module" to your package.json file.
I am closing this issue for now. If neither of these steps fixes your problem, please create a new issue, and include your node version, the exact code you are running, and the error you are getting.
Thanks! :)


ServerMap Drawing not working properly after 2.3.0

Hello,
I just have updated to version 2.3.0 and I found myself with the problem below

I did clone the repository and built from source....
is something wrong that I need to take care of?

We do not reproduce this problem.
Can you provide information on how the problem is reproduced?

git clone --branch v2.3.0 https://github.com/pinpoint-apm/pinpoint.git
./mvnw clean install -DskipTests=true

moved the content inside the "deploy" folder and have executed it.
hbase version= 2.3.0

https://github.com/pinpoint-apm/pinpoint#compatibility
Check the HBase compatibility table.

I see... looks like I was distracted :D
thanks for clarification!

I mean... I'm supposed to continue building using that workround?
-Dhbase.shaded.client.version=2.1.1

Now I'm facing this.
java -jar pinpoint-hbase2-collector-boot-2.3.0.jar
Exception in thread "main" java.lang.ClassNotFoundException: com.navercorp.pinpoint.collector.Hbase2CollectorApp
at java.net.URLClassLoader.findClass(URLClassLoader.java:382)
at java.lang.ClassLoader.loadClass(ClassLoader.java:418)
at org.springframework.boot.loader.LaunchedURLClassLoader.loadClass(LaunchedURLClassLoader.java:151)
at java.lang.ClassLoader.loadClass(ClassLoader.java:351)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:348)
at org.springframework.boot.loader.MainMethodRunner.run(MainMethodRunner.java:46)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:108)
at org.springframework.boot.loader.Launcher.launch(Launcher.java:58)
at org.springframework.boot.loader.JarLauncher.main(JarLauncher.java:88)


Changes for the version 2 of the paper

This includes

2 new 2D ConvNet architectures (one is not entirely working properly),
the speed test,
new results.

What is not included is a notebook to test the 2D ConvNet architecture. Should I include it? I would need to clean it before.

Thanks!
What is the notebook testing? If it's worthwhile to share it I would include it. It might even serve us in the future. ;)
Should we keep the 2D ConvNet architecture that doesn't really work?

Could we make a folder for the stuff we want to keep but that are not in a very good shape. We could put the notebook and the cnn.py in this folder. Beside the bug, the CNN implementation is  better than the one I eventually used. So I think we should keep it in case I figure out why batch norm is not working one day.

Good idea! We could have something like staging or experimental.

Good let us go for experimental

Please also state in the README what experimental is.

It should be ready for merging...

LGTM! Thanks @nperraud


Show not submitted homework (count) for student

Like notifications in apps (iOS-style)

fixed the bug that an error was thrown when logging in without being assigned to at least one class
error report in backend repo


docs: adding information about environments

Status
READY
Description
Adds documentation about environments.
Type of Change

[ ] ✨ New feature (non-breaking change which adds functionality)
[ ] 🛠 Bug fix (non-breaking change which fixes an issue)
[ ] ❌ Breaking change (fix or feature that would cause existing functionality to change)
[ ] 🧹 Code refactor
[ ] ✅ Build configuration change
[x] 📝 Documentation
[ ] 🗑 Chore

Would this resolve  #557?

Resolves #557 (commentign for reference).

Yep!


Improved app startup routine

Resolved / Related Issues

[x] Were these changes approved in an issue or discussion with the project maintainers? In order to prevent extra work, feature requests and changes to the codebase must be approved before the pull request will be reviewed. This prevents extra work for the contributors and maintainers.

Validation
How did you test these changes?

[ ] Did you build the app and test your changes?
[ ] Did you implement any design changes to an existing feature?

[ ] Was this change approved?

This is Phase 1 of startup routine improvements.
(More are on their way but will be in separate PRs to avoid conflicts)

I'll investigate


npm changeset version command formats the package.json

Problem
when running npm changeset version,  the package.json file is being formatted.
The formatting turns this:
"files": ["dist"],

to this:
"files": [
    "dist"
],

This formatting is WRONG.
A. Why does it need to happen?
B. What is causing the formatting?
I have no husky, I have no prettier. I am using VSCode, and the formatOnSave is disabled.
This is a very small project created today.
This is a HUGE ISSUE for me

B. That's how JSON.stringify stringifies JSON when using the space parameter.
A. If the space parameter isn't used, JSON.stringify stringifies JSON as a single line.
You can see the difference here: https://stackblitz.com/edit/vitejs-vite-f9dpnq?file=src%2Fmain.ts

Is there a way to tell changesets to run a custom npm script that formats the file?
For example:
{
  "check": "biome check --write"
}

It would need to run after changesets updates package.json and before it creates a Pull Request.

sadly, to this day of writing the comment, there isn't...
I hate to be doing this in a another package's thread..., but I ended up switching to another tool on npm, called lvlup, which doesn't format your package.json at all, and only works for a single repo (not a monorepo with many packages) and just performs a simple find & replace.
Full Disclosure ⚠
The tool barely has weekly downloads,
as I am the developer/maintainer of it. I find myself often creating new packages and needed an appropriate tool.


Individual perk popularity rankings not appearing

I'm no longer able to see the perk popularity ranking number that would appear on each perk bubble on the weapon inspection window. Tested in DIM Beta and main release.

fixed on version 0.9, thanks for reporting !

Thanks!

Hey with 0.9 I'm seeing it work on some of my guns but it still does not show the popularity rankings on most of my items. At a glance it seems that it's working on all my crafted weapons, but not random rolls.


Crash when logging an error in bugsag 6.0 using Malloc Scribble, Malloc Guard Edges and Guard Malloc

Description
Calling Bugsnage.notifyError(error: Error) crashed in Bugsnage 6.0, did not crash in 5.23.2
Issue
Calling Bugsnage.notifyError(error: Error) crashes in Bugsnage 6.0 when I have Malloc diagnostics enabled. It does not crash when only Malloc Scribble in enabled, or if Malloc Scribble is not enabled and
Malloc Guard Edges and/or Guard Malloc are enabled.
Environment
Xcode 11.5
Simulator running iOS 13.5
Scheme Diagnostics
Malloc Scribble
Malloc Guard Edges
Guard Malloc
Library versions:

Bugsnag version (from your Podfile, Podfile.lock, or elsewhere): 6.0
CocoaPods version (if any) (pod -v): 1.9.1
Carthage version (if any): n/a
iOS/tvOS/macOS version(s) iOS 13.5
debug mode or production?: Debug
How are you initializing Bugsnag? Can you share a snippet of your
AppDelegate where Bugsnag is configured?

Example code snippet
import Bugsnag

        var config:BugsnagConfiguration
        config = BugsnagConfiguration("xxxxx")
        config.releaseStage = "staging"
        config.sendThreads = .unhandledOnly
        config.appVersion = "the version string"
        Bugsnag.start(with: config)

// (Insert code sample to reproduce the problem)

Bugsnag.notifyError(error)

Error messages:
Thread 4: EXC_BAD_ACCESS (code=1, address=0x60012ae59000)

at strlen()

void bsg_kscrw_i_resetThreadTraceData() {
    if (bsg_g_thread_json_data == NULL) {
        bsg_g_thread_json_data = malloc(bsg_g_thread_json_size);
    }
    memset(bsg_g_thread_json_data, 0, strlen(bsg_g_thread_json_data));
}

I suspect that strlen() is crashing becuase bsg_g_thread_json_data is not a null terminated string? I changed strlen(bsg_g_thread_json_data) to bsg_g_thread_json_size but it still crashes

Fixed in v6.0.1


Upgrade support modules to go1.21

Please specify the area for this PR
/server
/generator
/tests
/registry-library
What does does this PR do / why we need it:
Upgrades the go version for the index/server, index/generator, registry-library & tests/integration from v1.19 to v1.21
Which issue(s) this PR fixes:
Fixes https://github.com/devfile/api/issues/1562
PR acceptance criteria:

[ ] Test Coverage

Are your changes sufficiently tested, and are any applicable test cases added or updated to cover your changes?

Documentation (WIP)

[ ] Does the REST API doc need to be updated with your changes?
[ ] Does the registry library doc need to be updated with your changes?

How to test changes / Special notes to the reviewer:

WIP because I'd like to test it with a local deployment of the registry. Not sure if we should vendor the tests/integration dir

Decided not to include vendor files for test/integration. Also tested locally and both viewer & server look working :)

Changes to the modules looks good, few change requests:

You'll need to update Go version in the CI workflow files:

https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/.github/workflows/ci.yaml#L24
https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/.github/workflows/codecov.yaml#L31
https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/.github/workflows/pushimage-next.yaml#L33

You'll need to update the Go version in the Dockerfiles:

https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/.ci/Dockerfile#L15
https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/tests/integration/Dockerfile#L15
https://github.com/thepetk/devfile-registry-support/blob/59fca64828c9e0977a4b56ebe24624b53ac0d59d/index/server/Dockerfile#L17

Note: In addition to needing the open seperate PR(s) for bumping the devfile/api version (and k8s indirect dependencies) to resolve the issue completely, this also contributes to resolving devfile/api#1557.

Yeah my bad forgot to push my latest changes :( I've also re-created the PR as I needed to rebase a lot of stuff. I think now is completed. For https://github.com/devfile/api/issues/1557 I agree. I'll put a blocked label in the issue that this PR is closed and I'll try to complete 1557.

@michael-valdron a question here is should we go to 2.3.0-alpha instead of 2.3.0?

After discussion we'll go with 2.3.0.
FYI I've opened devfile/api#1571 in order to release devfile/api version 2.3.0. Post merge I'll update the current PR for registry-library to use the latest api version.

@michael-valdron the devfile/api 2.3.0 is now released. I've included the bump up of devfile/api in server and generator in this PR. If I'm not wrong we need a separate PR to update the generator dependency on server & registry-library right?

WIP: Because we need to fix the issue brought from code gen and updates the generator schema: https://github.com/devfile/registry-support/blob/ecdf9433d0cf6fc9fdca7f0404a57586cb87a38c/index/server/pkg/server/types.gen.go#L20

@michael-valdron a question here is should we go to 2.3.0-alpha instead of 2.3.0?

After discussion we'll go with 2.3.0.
FYI I've opened devfile/api#1571 in order to release devfile/api version 2.3.0. Post merge I'll update the current PR for registry-library to use the latest api version.

@michael-valdron the devfile/api 2.3.0 is now released. I've included the bump up of devfile/api in server and generator in this PR. Once I've fixed the status failures, If I'm not wrong we need a separate PR to update the generator dependency on server & registry-library right?

@thepetk server should be fine to update now as it references the local generator with replace and builds with it, in the case of registry-library despite the replace it should be updated in a separate PR because it can be shipped by itself and will need the revision updated.

blocking https://github.com/devfile/library/pull/212 from merging

@michael-valdron still struggling to understand why the oapi-codegen updates the github.com/devfile/registry-support/index/generator/schema to sigs.k8s.io/structured-merge-diff/v4/schema :thinking:

@michael-valdron still struggling to understand why the oapi-codegen updates the github.com/devfile/registry-support/index/generator/schema to sigs.k8s.io/structured-merge-diff/v4/schema 🤔

@thepetk Its because the schema.Schema defined here is auto resolving the package to use which causes a conflict between sigs.k8s.io/structured-merge-diff/v4/schema and the intended github.com/devfile/registry-support/index/generator/schema.
We'll need to investigate a way of forcing github.com/devfile/registry-support/index/generator/schema as our intended target package.

@michael-valdron still struggling to understand why the oapi-codegen updates the github.com/devfile/registry-support/index/generator/schema to sigs.k8s.io/structured-merge-diff/v4/schema 🤔

@thepetk Its because the schema.Schema defined here is auto resolving the package to use which causes a conflict between sigs.k8s.io/structured-merge-diff/v4/schema and the intended github.com/devfile/registry-support/index/generator/schema.
We'll need to investigate a way of forcing github.com/devfile/registry-support/index/generator/schema as our intended target package.

Changing schema.Schema to Schema seemed to fix it for me locally unless there is something I overlooked. Give that a try and see if it is viable?
@michael-valdron @thepetk

@michael-valdron still struggling to understand why the oapi-codegen updates the github.com/devfile/registry-support/index/generator/schema to sigs.k8s.io/structured-merge-diff/v4/schema 🤔

@thepetk Its because the schema.Schema defined here is auto resolving the package to use which causes a conflict between sigs.k8s.io/structured-merge-diff/v4/schema and the intended github.com/devfile/registry-support/index/generator/schema.
We'll need to investigate a way of forcing github.com/devfile/registry-support/index/generator/schema as our intended target package.

Changing schema.Schema to Schema seemed to fix it for me locally unless there is something I overlooked. Give that a try and see if it is viable?
@michael-valdron @thepetk

For my case it doesn't work as the generated code has an invalid model name inside. This issue has been occurred due to vendoring of the sigs.k8s.io dir after the bump up of the k8s dependencies. It seems to me that the schema package of the structured-merge-diff module is conflicting with the generator one.
Is strange that the x-go-type-import stops working and we cannot add the extra package anymore.

Even if you revert the sigs.k8s.io change to the generated code and then make the schema.Schema -> Schema change and then regenerate, it still gives an invalid model? @thepetk


Chisel Pipelined GEMM

A CHISEL pipelined GEMM module along with associated unit tests are being added with this pull request.
Significant cycle count improvements are seen for conv2D workloads. In particular, when evaluated with "tvm/vta/tutorials/frontend/deploy_classification.py" with the tsim target using all 6 supported ResNets, overall speedups range from 3.10x to 3.69x as shown in the table below. Top 5 labels all match for the default "cat.png" image in all cases.

Net
Baseline, cycles
With Pipelined GEMM, cycles
Speedup

resnet18_v1
27,679,515
7,729,601
3.58

resnet34_v1
57,471,735
15,736,441
3.65

resnet18_v2
27,558,980
7,608,808
3.62

resnet34_v2
57,270,321
15,534,528
3.69

resnet50_v2
68,187,407
22,012,906
3.10

resnet101_v2
129,263,035
39,182,158
3.30

Code contributions to this PR were made by the following individuals (in alphabetical order): @suvadeep89, @stevenmburns, @pasqoc, @adavare, @sjain12intel, @aasorokiin, and @zhenkuny.

I'm also curious about logic resource consumption for the simple GEMM and pipelined GEMM. Do you have numbers on that ?

As for logic resource. After synthesis the pipelined VTAShell design has 43 more sequential cells. Pipelined ALU has 6% larger area. Pipelined GEMM has the same area as the Simple one.


Update docs to specify supported version of kind

Currently, we support 0.5.1 version of kind. Our development doc does not mention
it. This PR updates the doc specifying the supported version of kind.

Can you also add a note about it in the "Deploying with Kubernetes In Docker (kind)" section? It's easy to miss in the bullet list, especially for "speed readers" like me :laughing:

/retest


[python] Fix and test setup.py flags to external shared objects

Issue and/or context:

Closes #2210
Follow-up to #2220
Address broken feedstock builds in https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/91 and https://github.com/TileDB-Inc/tiledbsoma-feedstock/pull/95

Changes:

Restores the flags --tiledb and --libtiledbsoma that are passed to setup.py

Notes for Reviewer:
Here's what happened. PR #1937 fixed the shared object copying when an external libtiledb or libtiledbsoma is provided via the env vars TILEDB_PATH or TILEDBSOMA_PATH. Unfortunately, it broke the command-line flags --tiledb and --libtiledbsoma. It overwrites them with None. This is why the tiledbsoma-feedstock nightlies immediately started failing after it was merged, which is the only place where we still build tiledbsoma-py with setup.py.
We assumed there was a macOS-specific problem because 1) the linux-64 feedstock build continued to pass, and 2) #1937 only tested on linux and not macOS. However, after I added a macOS job in #2220, we knew it was not specific to macOS since macOS also properly copies the objects when using the env vars.
I figured it out by investigating the differences between linux and macOS in setup.py. It turns out that linux has a fall-back method to search for a system installation of libtiledbsoma. This is the only reason that the linux-64 feedstock build passed.
https://github.com/single-cell-data/TileDB-SOMA/blob/793818d778e75812193bcef49064d412c77ed855/apis/python/setup.py#L146-L147
In order to catch this type of regression in this repository, I added an extra job to my python-so-copying workflow that confirms the flags --tiledb and --libtiledbsoma are functional. To emulate the feedstock build, I delete cmake from the runner. Thus if tiledbsoma-py is unable to use the command-line flags and tries to fall back to building libtiledbsoma from source with cmake, it will fail (which I confirmed on a branch in my fork by temporarily reverting my fixes to setup.py).

See also #2210 for troubleshooting context.


MAX row in Matrix Dynamic (question)

It's possible to add a new properties in Matrix Dynamic, in particular "max row", to control the maximun number off row added by the user?
Today there is only the properties MIN ROW :)

@care46 Yes, make sense. We will do it.
Thank you,
Andrew

@care46 It is done. It will be available in the next minor update.
Thank you,
Andrew

Awesome! Thanks!!! ;)


⚠ ClamAV has degraded performance

In 7d9e530, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 192 ms

Resolved: ClamAV performance has improved in eeb742d after 11 minutes.


Initial commit of DALL-E and Segment Anything notebook

Notebook walking users how to use Meta's Segment Anything model to dynamically mask and in-paint DALL-E images.

 I'm hitting a ConnectionError/MaxRetryError on this line filepaths = process_dalle_images(generation_response, "generation", base_image_dir). Tried waiting and running again 30 minutes later but hit the same thing. Any idea why?

 I'm hitting a ConnectionError/MaxRetryError on this line filepaths = process_dalle_images(generation_response, "generation", base_image_dir). Tried waiting and running again 30 minutes later but hit the same thing. Any idea why?

Looks like a transient error. All good now!


Why is there no js script for frontend+backend?

I was just wondering why there is no script.js file for frontend+backend
The current block assets are:
 * 1. blocks.style.build.css - Frontend + Backend.
 * 2. blocks.build.js - Backend.
 * 3. blocks.editor.build.css - Backend.

Why is this missing the (seemingly) obvious 4th option?
 * 4. blocks.script.build.js - Frontend + Backend.

So I've been trying to implement this myself in a fork, and would like to create a pull request.
I'm just wondering how I can test if my changes work.
I have made some changes in the packages/cgb-scripts/template/src folder, when I execute the folowing commands:
git clone git@github.com:pwkip/create-guten-block.git
cd create-guten-block
yarn
yarn create-guten-block demo-block

After this I do not see my changes reflected in the demo-block/src folder.
What can I do in order to generate a demo-block based on my own local cgb-scripts code?

@ahmadawais it would be great if there was a configuration file to modify the default webpack config or at least to add your own stylesheets and scripts for bundling.

Would really love something like this for blocks that require dynamic JS on the frontend for things like modals, AJAX, form validation etc


CLOUDSTACK-8640: Revert to AWS SDK 1.3.22

The newer SDKs API changed which causes our S3 Template Downloader to never complete.
Although we should fix the Template Downloader we can revert to the old AWS SDK for now.
The fix on the longer run will be rewriting the S3 Template Downloader.
Two methods had to be disabled for now since the old SDK does not support them. They can
be re-enabled when the Template Downloader has been fixed.

:+1:

:+1:


Create 136_single_number.py

I looked at the solutions and then wrote the solution myself. I need to go over hash maps.

@sb2nov

This works and is correct code so LGTM but I think we can write this in an easier to understand manner.


MinMaxStack

Add functions

bottom
bottomOption
apply
reverseIterator
push
pushAll
popAll
popWhile

Codecov Report

Merging #30 (5b97e50) into main (00bde84) will increase coverage by 0.05%.
The diff coverage is 100.00%.

@@            Coverage Diff             @@
##             main      #30      +/-   ##
==========================================
+ Coverage   98.76%   98.82%   +0.05%
==========================================
  Files          63       63
  Lines         405      425      +20
  Branches       27       30       +3
==========================================
+ Hits          400      420      +20
  Misses          5        5

Impacted Files
Coverage Δ

...in/scala/algo/data/stack/mutable/MinMaxStack.scala
85.71% <ø> (ø)

...a/algo/data/stack/mutable/DefaultMinMaxStack.scala
100.00% <100.00%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 00bde84...5b97e50. Read the comment docs.


Use "route modifier tags" for commented routes

For commented routes use
https://www.playframework.com/documentation/2.6.x/Highlights26#Route-modifier-tags? So instead of the #deadbolt:... comment syntax we could use "play conform" tags like + deadbolt:... in the routes file now?
(I didn't look into the code to know if thats possible and how it works)

You're on a role at the moment!
I kept the current style over from 2.5, but it makes sense to move to route modifiers if they're now supported.  I'll keep support for the current style until 2.7.  I'll look into this went I have some time, probably the weekend.

BTW: Play Java filters have a serious performance issue. Check https://github.com/playframework/playframework/issues/8010.
We could work around that performance problem if the deadbolt filter - instead of extending play.mvc.Filter - directly extends its superclass play.mvc.EssentialFilter.

Any plans on when this might be fixed?

@patrickliangli If @schaloner or I have time we might fix this before the 2.7 release, however we might not have time :wink: If you want to provide a pull request I am happy to review it!

Working on this right now...


Fatal NullPointerException while initializing application context

Describe the bug
I got the following NullPointerException while trying to initialize my Authorization server:
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'authorizationServerSecurityFilterChain' defined in class path resource [org/springframework/security/config/annotation/web/configuration/OAuth2AuthorizationServerConfiguration.class]: Bean instantiation via factory method failed;
nested exception is org.springframework.beans.BeanInstantiationException: Failed to instantiate [org.springframework.security.web.SecurityFilterChain]: Factory method 'authorizationServerSecurityFilterChain' threw exception;
nested exception is java.lang.NullPointerException: Cannot invoke "java.lang.Integer.intValue()" because the return value of "org.springframework.security.config.annotation.web.builders.FilterOrderRegistration.getOrder(java.lang.Class)" is null

Specifically, the error happened while trying to start the ApplicationContext.
To Reproduce
I followed Baeldung's Spring OAuth Server tutorial verbatium. I ran the application via gradle bootRun.
Spring boot plugin version: 2.5.0
Spring oauth2 authorization server version: 0.1.1
Gradle version: 7.0.4
Expected behavior
I expected the application to start.
Sample
My sample is here. I copy and pasted from the tutorial I referenced above.
Let me know if I can help out with any additional information. I am also interested in contributing to this project, so let me know if I can be of any help fixing this bug. Thanks again!

This is a regression in Spring Security 5.5. Please see comment.

Closing as duplicate #307


[Improvement] Task fast fail once blocks fail to send

What changes were proposed in this pull request?
[Improvement] Task fast fail once blocks fail to send

In single replica mechanism, single one batch data sent failed should make task fast fail.
When some remaining block events in dataTransferPool wait to be sent, we should abandon it.
More precisely, we need to interrupt send requests belonged to failed tasks. (Using the GrpcFuture to cancel it)

Why are the changes needed?

When shuffle-sever is down, in current codebase, the shuffle-write client will block and retry too much times. Actually, it should fast fail once partial blocks fail to send.
When using the custom retry policy in rpc layer like #308 , this PR will solve the potential problem of waiting too long wait time when specifying the  1min  retry time.

After this patch, fail time is limited in 2min. Before, it will be for 10min+
Does this PR introduce any user-facing change?

No
How was this patch tested?

UTs
Online real tests

Codecov Report

Merging #332 (1476998) into master (9f0610a) will increase coverage by 1.22%.
The diff coverage is 69.23%.

@@             Coverage Diff              @@
##             master     #332      +/-   ##
============================================
+ Coverage     61.09%   62.31%   +1.22%
+ Complexity     1509     1391     -118
============================================
  Files           185      172      -13
  Lines          9410     8174    -1236
  Branches        918      804     -114
============================================
- Hits           5749     5094     -655
+ Misses         3357     2804     -553
+ Partials        304      276      -28

Impacted Files
Coverage Δ

...he/uniffle/client/impl/ShuffleWriteClientImpl.java
25.35% <69.23%> (+4.12%)
:arrow_up:

...g/apache/hadoop/mapred/SortWriteBufferManager.java

...rg/apache/hadoop/mapred/RssMapOutputCollector.java

.../java/org/apache/hadoop/mapreduce/RssMRConfig.java

...n/java/org/apache/hadoop/mapreduce/MRIdHelper.java

...apache/hadoop/mapreduce/v2/app/RssMRAppMaster.java

...preduce/task/reduce/RssRemoteMergeManagerImpl.java

.../hadoop/mapreduce/task/reduce/RssEventFetcher.java

...pache/hadoop/mapreduce/task/reduce/RssFetcher.java

... and 5 more

:mega: We’re building smart automated test selection to slash your CI/CD build times. Learn more

PTAL @jerqi

Is it necessary that we use GrpcFuture to cancel the request?

I have some concern whether the isValidTaskId is a good implement way.

Is it necessary that we use GrpcFuture to cancel the request?

If the request is very slow or hang, grpc future could cancel the request, otherwise we have to wait.

I have some concern whether the isValidTaskId is a good implement way.

I have no other idea to implement this feature. If using the thread.interrupt, it wont abandon the events have been in dataTransferPool.

If we use Netty to transfer the data, will this feature bring difficulties to us?

I think we could shorten the thread sleep time from 100ms -> 10ms in GrpcFuture wait

Is isValidTaskId  rpc failureCallback?

Is isValidTaskId rpc failureCallback?

Sorry I don’t got your thought

In rpc system, there is a concept called failureCallback, it is used to process the failure result. You can refer to brpc.
https://brpc.apache.org/docs/client/basics/#use-newcallback

Got it. But in this case, we want to cancel the request instead of callback

PTAL @jerqi

Wait for a moment. I think this is  a typical mechanism. I want to find whether any other system have similar mechanism.

We'd better consider compatible problems with Netty rpc.

We'd better consider compatible problems with Netty rpc.

Got you point. Maybe we could remove the rpc retry in this PR. And add it after netty design finished. What do u think? @jerqi

We'd better consider compatible problems with Netty rpc.

Got you point. Maybe we could remove the rpc retry in this PR. And add it after netty design finished. What do u think? @jerqi

Netty may not have GrpcFuture, too.

I think you misunderstand my thought. In this PR, I do the three changes

In single replica mechanism, single one batch data sent failed should make task fast fail.
When some remaining block events in dataTransferPool wait to be sent, we should abandon it.
More precisely, we need to interrupt send requests belonged to failed tasks. (Using the GrpcFuture to cancel it)

So I could remove the 3th change in this PR.

Netty may not have GrpcFuture, too

By the way, this rpc retry relies on the dedicated rpc implementation. So the GrpcFuture is only for the grpc instead of bare netty. And I also wont use this to be compatible with bare netty.

We'd better consider compatible problems with Netty rpc.

Got you point. Maybe we could remove the rpc retry in this PR. And add it after netty design finished. What do u think? @jerqi

Netty may not have GrpcFuture, too.

I think you misunderstand my thought. In this PR, I do the three changes

In single replica mechanism, single one batch data sent failed should make task fast fail.
When some remaining block events in dataTransferPool wait to be sent, we should abandon it.
More precisely, we need to interrupt send requests belonged to failed tasks. (Using the GrpcFuture to cancel it)

So I could remove the 3th change in this PR.

Netty may not have GrpcFuture, too

By the way, this rpc retry relies on the dedicated rpc implementation. So the GrpcFuture is only for the grpc instead of bare netty. And I also wont use this to be compatible with bare netty.

Ok.


ZEVA - Display credit application history information to IDIR

Title: Display credit application history information to IDIR
Description: The status information displayed to IDIR staff only provides the latest action. The BCeID status includes a history of the Excel upload and when it was saved and submitted to government. We'd like to display this info on the IDIR side as well.
Wireframe:

Purpose and benefit to user: It is important to government to retain the info of when the CA was submitted
Acceptance Criteria:

[ ] Given I am a government user when I am viewing a credit application, then I should see the history displayed below the status.

Development Checklist:

[ ] Make sure credit history is uniform on BCeID side and IDIR side.
[ ] Ensure existing credit applications are updated to pull and include the history information.

Notes:

Hey team! Please add your planning poker estimate with Zenhub @AlexZorkin @emi-hi @tim738745 @vibhiquartech @jig-patel @JulianForeman

The intention here was that IDIR users should see the history in all relevant status. Currently it is only showing when the credit application is in 'Issued' and 'Rejected' statuses.
Please make the history also visible in these statuses: Submitted, Validated and Recommend Issuance.


perf(codegen): faster writing indentation

Write indentation faster. Previously was writing indentation to buffer with a call to memset, which is relatively expensive. Where indentation <= 16 (common case), write 16 tabs with a single 16-byte XMM write, which is faster.

+1% perf gain.

Merge activity

Dec 13, 12:16 AM EST: The merge label '0-merge' was detected. This PR will be added to the Graphite merge queue once it meets the requirements.
Dec 13, 12:16 AM EST: A user added this pull request to the Graphite merge queue.


[ClangImporter] Add the sysroot directly to the clang Driver used to find the libc header path

getToolChain() and AddClangSystemIncludeArgs() don't parse the arguments to set the sysroot, so set it directly instead. Also, remove a redundant check for a valid directory.
Fixes #60224
@egorzhdan, let me know what you think, this fixes the issue with cross-compiling the stdlib from linux to Android.
@3405691582, please try it out with your OpenBSD cross-compile.

This seems to build successfully on Linux->OpenBSD cross-compile. I'll just try a clean from-scratch cross-compile just to be certain, but looking good so far.

Okay, minor problem on the clean cross-compile (snipping down):
FAILED: stdlib/public/core/LINUX/x86_64/Swift.o .../build/cross2/swift-linux-x86_64/stdlib/public/core/LINUX/x86_64/Swift.o
cd .../build/cross2/swift-linux-x86_64/stdlib/public/core && /usr/bin/python3.10 .../swift/utils/line-directive @.../build/cross2/swift-linux-x86_64/stdlib/public/core/e67df6fd1e28512e9207be0ab7682f2a716b8641.txt -- .../build/cross2/swift-linux-x86_64/./bin/swiftc -c -sdk -target x86_64-unknown-linux-gnu ...
<unknown>:0: error: no such file or directory: 'x86_64-unknown-linux-gnu'

Note the lack of flag after sdk here.

I think this LGTM with a from-scratch cross-compile build.

@swift-ci please smoke test

@egorzhdan, please go ahead and merge, I'd like to use this in the next trunk snapshot.

Thanks, this got the community Android CI building the stdlib again, now to look into the failing tests because of other unrelated issues.


Fix CRD removal race condition

related to: https://bugzilla.redhat.com/show_bug.cgi?id=2035324
What's happening
To understand what's occurring I need to point out a few things about how the system works.

We register mutation/validation webhooks our CRDs which are served by virt-api
Update/Patch to our KubeVirt APIs fail when virt-api is unavailable due to these webhook registrations
virt-api will fail to initialize if not all CRDs are registered due to not being able to sync informer cache.

What we have going on in this BZ is that during teardown, virt-api re-initialized (most likely due to CDI apis being removed), and was unable to come back online due to some of our CRDs no longer being registered. Since virt-api hosts the webhooks for all our CRDs, any remaining KubeVirt CRs in the cluster that require the removal of finalizers will fail because we can't call Patch/Update without webhooks being online.
The result is a deadlock of sorts. We can't remove objects with finalizers because we can't call Update/Patch on those objects. And we can't call update/patch because virt-api is down, and virt-api is down because some KubeVirt APIs have already been removed which prevents the informer cache from syncing.
virt-controller is subject to this same issue. If some CRDs are not registered anymore, virt-controller will fail to initialize in that situation.
Logs show sequence of events
virt-api re-initializes because DataSource object from CDI is removed.
2022-01-11T11:15:52.647206472Z {"component":"virt-api","level":"info","msg":"Reinitialize virt-api, cdi DataSource api has been removed","pos":"api.go:985","timestamp":"2022-01-11T11:15:52.647130Z"}
virt-api is stuck trying to come back online but can't sync informers
022-01-11T11:53:19.372804960Z E0111 11:53:19.372752       1 reflector.go:138] pkg/controller/virtinformers.go:305: Failed to watch *v1alpha1.VirtualMachineRestore: failed to list *v1alpha1.VirtualMachineRestore: the server could not find the requested resource (get virtualmachinerestores.snapshot.kubevirt.io)
2022-01-11T11:53:34.820951778Z E0111 11:53:34.820897       1 reflector.go:138] pkg/controller/virtinformers.go:305: Failed to watch *v1.VirtualMachineInstancePreset: failed to list *v1.VirtualMachineInstancePreset: the server could not find the requested resource (get virtualmachineinstancepresets.kubevirt.io)

virt-controller can't patch VMI object because virt-api isn't initialized.
2022-01-11T11:53:52.792661238Z {"component":"virt-controller","level":"info","msg":"reenqueuing VirtualMachineInstance kubevirt-hyperconverged/fedora-responsible-boar","pos":"vmi.go:272","reason":"patching of vmi conditions and activePods failed: Internal error occurred: failed calling webhook \"virtualmachineinstances-mutator.kubevirt.io\": failed to call webhook: Post \"https://virt-api.kubevirt-hyperconverged.svc:443/virtualmachineinstances-mutate?timeout=10s\": no endpoints available for service \"virt-api\"","timestamp":"2022-01-11T11:53:52.792516Z"}

The Fix
We need to change the deletion order from this...

Delete all CRDs
Delete Webhook registrations

to this...

Add finalizers to all CRDs
Delete All CRDs (finalizer prevents them from being completely removed)
Remove All CRD finalizers after waiting for all CRDs to report CRs are removed
Delete webhook registrations

When  a CRD is marked for deletion, no new creations can occur while CRs for that CRD are being removed. By freezing the ability to create new objects when tearing down our API, we can do a controlled deletion of all CRs and only delete the CRDs once all CRs are removed.
Essentially, we're not allowing CRDs to disappear until every CR associated with the KubeVirt API is gone. That allows our control plane to properly tear down CRs without hitting issues with API's being unavailable.
Fixes issue associated with blocked uninstalls when VMIs exist during removal

/retest

that CI runs looks bad but I think you got unlucky and it was a connectivity issue
/retest

/hold
I want to add a functional test

/hold cancel
This should be good to go now.

/retest

/lgtm
Thank you!

/lgtm
/approve

/cherry-pick release-0.49


Disallow Illegal Characters in File Names on Windows

This pull request hopefully :crossed_fingers: solves issues such as #62 which arise from illegal characters attempting to be in file names on Windows. On macOS and GNU/Linux systems, this is less of a problem, but still a problem, so let's squash it here.

Furthermore, this pull request addresses another bug found in #62 : Windows has a 260-character absolute file name limit. Thus, logic has been added to track.Track.set_outfile() such that, if the absolute file name is longer than 260 characters, truncate it to just the track number and codec; e.g. 23.flac. If this is still too long, then log a warning and return early.

Then, in this (probably too-large) pull request, multiple GitHub actions have been changed in order to :crossed_fingers: more robustly upload artifacts upon cutting a release.