invalid argument issue after 0.69.0 upgrade

> kubectl -n otel-collector logs po/otel-collector-collector-zzs7q
Error: invalid argument "-confmap.unifyEnvVarExpansion,-component.UseLocalHostAsDefaultHost" for "--feature-gates" flag: feature gate "confmap.unifyEnvVarExpansion" is stable, can not be disabled
2024/09/09 23:14:08 collector server run finished with error: invalid argument "-confmap.unifyEnvVarExpansion,-component.UseLocalHostAsDefaultHost" for "--feature-gates" flag: feature gate "confmap.unifyEnvVarExpansion" is stable, can not be disabled

otel collectors are failing after 0.69.0 upgrade
when i describe the container i can see -confmap.unifyEnvVarExpansion, looks like new version 0.108.0 does not like it
  Containers:
   otc-container:
    Image:       ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-k8s:0.108.0
    Ports:       8888/TCP, 4317/TCP, 4318/TCP
    Host Ports:  0/TCP, 0/TCP, 0/TCP
    Args:
      --config=/conf/collector.yaml
      --feature-gates=-confmap.unifyEnvVarExpansion,-component.UseLocalHostAsDefaultHost

bug still exists in latest operator version

@jihuiyang You cannot disable the confmap.unifyEnvVarExpansion feature gate anymore.
Doing --feature-gates= -confmap.unifyEnvVarExpansion is not allowed

I did not specify --feature-gates=-confmap.unifyEnvVarExpansion, all i did was helm install 0.69.0 and somehow it had the this argument

maybe i should uninstall and whole thing and reinstall?

@jihuiyang I haven't been able to reproduce your issue yet with a clean install or with a helm upgrade.  Can you provide more details?

I tried a clean install and it worked without the --feature-gates=-confmap.unifyEnvVarExpansion flag. let me try just the upgrade

@jihuiyang thanks for trying that out. I have been debugging the upgrade process in this issue, if you run into a similar issue during the upgrade I would really appreciate if you could share the steps to reproduce. I've tried a few different ways of doing this and have yet to cause it to happen.

still running into the issue with upgrade, upgrading from 0.65.1 to 0.69
> helm --namespace otel-operator-system ls
NAME                  	NAMESPACE           	REVISION	UPDATED                             	STATUS  	CHART                        	APP VERSION
opentelemetry-operator	otel-operator-system	9       	2024-09-10 12:16:27.747165 -0700 PDT	deployed	opentelemetry-operator-0.69.0	0.108.0

Collector still sees the featuregate
> kubectl -n otel-collector describe ds/otel-collector-collector | grep feature
      --feature-gates=-confmap.unifyEnvVarExpansion,-component.UseLocalHostAsDefaultHost

Operator log
kubectl -n otel-operator-system logs po/opentelemetry-operator-595855cd5c-jx9hj -f
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","message":"Starting the OpenTelemetry Operator","opentelemetry-operator":"0.108.0","opentelemetry-collector":"ghcr.io/open-telemetry/opentelemetry-collector-releases/opentelemetry-collector-k8s:0.108.0","opentelemetry-targetallocator":"ghcr.io/open-telemetry/opentelemetry-operator/target-allocator:0.108.0","operator-opamp-bridge":"ghcr.io/open-telemetry/opentelemetry-operator/operator-opamp-bridge:0.108.0","auto-instrumentation-java":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-java:1.33.5","auto-instrumentation-nodejs":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-nodejs:0.52.1","auto-instrumentation-python":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-python:0.48b0","auto-instrumentation-dotnet":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-dotnet:1.2.0","auto-instrumentation-go":"ghcr.io/open-telemetry/opentelemetry-go-instrumentation/autoinstrumentation-go:v0.14.0-alpha","auto-instrumentation-apache-httpd":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.4","auto-instrumentation-nginx":"ghcr.io/open-telemetry/opentelemetry-operator/autoinstrumentation-apache-httpd:1.0.4","feature-gates":"-operator.golang.flags,operator.observability.prometheus","build-date":"2024-09-05T17:19:14Z","go-version":"go1.22.6","go-arch":"amd64","go-os":"linux","labels-filter":[],"annotations-filter":[],"enable-multi-instrumentation":false,"enable-apache-httpd-instrumentation":true,"enable-dotnet-instrumentation":true,"enable-go-instrumentation":false,"enable-python-instrumentation":true,"enable-nginx-instrumentation":false,"enable-nodejs-instrumentation":true,"enable-java-instrumentation":true,"create-openshift-dashboard":false,"zap-message-key":"message","zap-level-key":"level","zap-time-key":"timestamp","zap-level-format":"uppercase"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"setup","message":"the env var WATCH_NAMESPACE isn't set, watching all namespaces"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"setup","message":"Prometheus CRDs are installed, adding to scheme."}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"setup","message":"Openshift CRDs are not installed, skipping adding to scheme."}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a mutating webhook","GVK":"opentelemetry.io/v1beta1, Kind=OpenTelemetryCollector","path":"/mutate-opentelemetry-io-v1beta1-opentelemetrycollector"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/mutate-opentelemetry-io-v1beta1-opentelemetrycollector"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a validating webhook","GVK":"opentelemetry.io/v1beta1, Kind=OpenTelemetryCollector","path":"/validate-opentelemetry-io-v1beta1-opentelemetrycollector"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/validate-opentelemetry-io-v1beta1-opentelemetrycollector"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/convert"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Conversion webhook enabled","GVK":"opentelemetry.io/v1beta1, Kind=OpenTelemetryCollector"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a mutating webhook","GVK":"opentelemetry.io/v1alpha1, Kind=Instrumentation","path":"/mutate-opentelemetry-io-v1alpha1-instrumentation"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/mutate-opentelemetry-io-v1alpha1-instrumentation"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a validating webhook","GVK":"opentelemetry.io/v1alpha1, Kind=Instrumentation","path":"/validate-opentelemetry-io-v1alpha1-instrumentation"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/validate-opentelemetry-io-v1alpha1-instrumentation"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/mutate-v1-pod"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a mutating webhook","GVK":"opentelemetry.io/v1alpha1, Kind=OpAMPBridge","path":"/mutate-opentelemetry-io-v1alpha1-opampbridge"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/mutate-opentelemetry-io-v1alpha1-opampbridge"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.builder","message":"Registering a validating webhook","GVK":"opentelemetry.io/v1alpha1, Kind=OpAMPBridge","path":"/validate-opentelemetry-io-v1alpha1-opampbridge"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Registering webhook","path":"/validate-opentelemetry-io-v1alpha1-opampbridge"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"setup","message":"starting manager"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.metrics","message":"Starting metrics server"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","message":"starting server","name":"health probe","addr":"[::]:8081"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.metrics","message":"Serving metrics server","bindAddress":"<IP_ADDRESS>:8080","secure":false}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Starting webhook server"}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.certwatcher","message":"Updated current TLS certificate"}
I0910 19:17:10.847314       1 leaderelection.go:254] attempting to acquire leader lease otel-operator-system/9f7554c3.opentelemetry.io...
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.webhook","message":"Serving webhook server","host":"","port":9443}
{"level":"INFO","timestamp":"2024-09-10T19:17:10Z","logger":"controller-runtime.certwatcher","message":"Starting certificate watcher"}
I0910 19:18:05.154198       1 leaderelection.go:268] successfully acquired lease otel-operator-system/9f7554c3.opentelemetry.io
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","logger":"collector-upgrade","message":"looking for managed instances to upgrade"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","logger":"instrumentation-upgrade","message":"looking for managed Instrumentation instances to upgrade"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","source":"kind source: *v1alpha1.OpAMPBridge"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","source":"kind source: *v1.ConfigMap"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","source":"kind source: *v1.ServiceAccount"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","source":"kind source: *v1.Service"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1beta1.OpenTelemetryCollector"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","source":"kind source: *v1.Deployment"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting Controller","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.ConfigMap"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.ServiceAccount"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.Service"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.Deployment"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.DaemonSet"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.StatefulSet"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.Ingress"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v2.HorizontalPodAutoscaler"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.PodDisruptionBudget"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.ServiceMonitor"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting EventSource","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","source":"kind source: *v1.PodMonitor"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","message":"Starting Controller","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector"}
{"level":"INFO","timestamp":"2024-09-10T19:18:05Z","logger":"instrumentation-upgrade","message":"no instances to upgrade"}
{"level":"INFO","timestamp":"2024-09-10T19:18:06Z","message":"Starting workers","controller":"opampbridge","controllerGroup":"opentelemetry.io","controllerKind":"OpAMPBridge","worker count":1}
{"level":"INFO","timestamp":"2024-09-10T19:18:06Z","message":"Starting workers","controller":"opentelemetrycollector","controllerGroup":"opentelemetry.io","controllerKind":"OpenTelemetryCollector","worker count":1}

if you do this, do you see the string 'managed'?

yes i do
> kubectl -n otel-collector get otelcol otel-collector -o yaml | grep 'managementState'
  managementState: managed

I also experienced this. I had to delete and recreate the OpentelemetryCollector resource (type = sidecar, in my case).

I'm also having a similar issue upgrading from 0.69.0 to 0.74.2 - The collector is failing to start, and logging Error: invalid argument "-component.UseLocalHostAsDefaultHost" for "--feature-gates" flag: no such feature gate "component.UseLocalHostAsDefaultHost".. I applied this upgrade across multiple clusters and only some had this issue. I've confirmed that all affected clusters have spec.args.feature-gates: -component.UseLocalHostAsDefaultHost in the OpenTelemetryCollector resource, and the non-affected clusters do not. However, I did not specify this option anywhere, and I'm deploying and upgrading the operator using the terraform helm provider, so I would expect to see the same behavior across all clusters.


ClickInventoryEvent is missing location information

As of API7.1, I can't find an predictable way to find Locatable from the inventory attached to the SlotTransaction.
Sometime, the root inventory is a CarriedInventory which may contain an optional Carrier which may implement Locatable which gives us a location.
That's a lot of conditions and for everything else, I don't know how to get it.
Example 1: AE2 crafting terminal is a block, but Carrier is empty:
root/parent is: appeng.container.implementations.ContainerCraftingTerm@bb13b95
SlotTransaction{slot=org.spongepowered.common.item.inventory.adapter.impl.slots.SlotAdapter@3a86b4ad, original=SpongeItemStackSnapshot{itemType=minecraft:air, quantity=0}, default=SpongeItemStackSnapshot{itemType=draconicevolution:draconic_ingot, quantity=7}, custom=Optional.empty, valid=true}
Example 2: crafting from player inventory isn't considered a CarriedInventory?
root/parent is: org.spongepowered.common.item.inventory.adapter.impl.comp.MainPlayerInventoryAdapter@64711d47
SlotTransaction{slot=org.spongepowered.common.item.inventory.adapter.impl.slots.SlotAdapter@6b181d4e, original=SpongeItemStackSnapshot{itemType=minecraft:air, quantity=0}, default=SpongeItemStackSnapshot{itemType=thermalfoundation:material, quantity=2}, custom=Optional.empty, valid=true}
Example 3: fusion crafting with Draconic Evolusion (?) has an empty carrier
root/parent is: com.brandon3055.draconicevolution.inventory.ContainerFusionCraftingCore@5c5a75cc
SlotTransaction{slot=org.spongepowered.common.item.inventory.adapter.impl.slots.SlotAdapter@48d9b809, original=SpongeItemStackSnapshot{itemType=minecraft:nether_star, quantity=61}, default=SpongeItemStackSnapshot{itemType=minecraft:air, quantity=0}, custom=Optional.empty, valid=true}
Example 4: dropping from hotbar returns org.spongepowered.common.item.inventory.adapter.impl.comp.HotbarAdapter which doesn't implements CarriedInventory

The problem with modded containers is that we don't really have a way to know what block they belong to.
I already try finding it:
https://github.com/SpongePowered/SpongeCommon/blob/921d2295a31fd06bb3f0c4dd525ec0baf807dc64/src/main/java/org/spongepowered/common/item/inventory/util/ContainerUtil.java#L480-L501
I quickly looked at the Containers:
AE2 ContainerCraftingTerm: no idea how to get a Location
DE ContainerFusionCraftingCore: chould get Location by looking at all slots for Tileentity instead of only first one.
Player CraftingInventory:
Are you sure you got the root? Root should be ContainerPlayer which is then has the Carrier.
Hotbar:
Same thing the root should be ContainerPlayer/InventoryPlayer and should have a Carrier.

Turns out the existing approach in prism was only looking for CarrierInventory on parent. I've modified it to check if parent and root are Locatable instances before looking for if root is a CarrierInventory.
This new approach solved 2 cases (player dropping from hotbar and crafting from inventory).
After one day usage, I've collected the following behaviors:
Case 1: some blocks have carriers that aren't Locatable, including vanilla
Vanilla crafting table
carrier is Locatable net.minecraft.inventory.ContainerWorkbench@1a9c87c7
with root is net.minecraft.inventory.ContainerWorkbench@1a9c87c7
Vanilla double chest (?)
carrier is net.minecraft.inventory.InventoryLargeChest@418d3cf3
root is net.minecraft.inventory.ContainerChest@610eaa9
A sponge wrapper?
carrier isn't Locatable org.spongepowered.common.item.inventory.util.ContainerUtil$1@58ae6e2d
transaction is SlotTransaction{slot=org.spongepowered.common.item.inventory.adapter.impl.slots.SlotAdapter@1dae369e, original=SpongeItemStackSnapshot{itemType=minecraft:air, quantity=0}, default=SpongeItemStackSnapshot{itemType=minecraft:sand, quantity=50}, custom=Optional.empty, valid=true}
root is nc.container.processor.ContainerManufactory@69411b5
Case 2: items used from inventory (like backpacks, books or tools) have a CarrierInventory root with no carrier
Chisel chisel
root is team.chisel.common.inventory.ContainerChisel@120456fb
Forestry backpack
root is forestry.storage.gui.ContainerBackpack@32124e05
Iron Backpack
root is gr8pefish.ironbackpacks.container.ContainerBackpack@6da2f68f
Cooking for blockheads book
root is net.blay09.mods.cookingforblockheads.container.ContainerRecipeBook@5df5791c
Case 3: various mod containers have CarrierInventory root with no carrier
Applied Energistics2 blocks
root is appeng.container.implementations.ContainerCraftingTerm@109785e6
root is appeng.container.implementations.ContainerGrinder@48ec4842
root is appeng.container.implementations.ContainerInscriber@17b10522
root is appeng.container.implementations.ContainerInterface@61eb26d1
root is appeng.container.implementations.ContainerSkyChest@3057cf34
root is appeng.container.implementations.ContainerUpgradeable@2b45513a
root is appeng.container.implementations.ContainerVibrationChamber@3b61505c
Actually Additions blocks
root is de.ellpeck.actuallyadditions.mod.inventory.ContainerBreaker@39259aa4
root is de.ellpeck.actuallyadditions.mod.inventory.ContainerCoalGenerator@14b5c858
root is de.ellpeck.actuallyadditions.mod.inventory.ContainerGiantChest@14d112cd
Bibliocraft bookcase
root is jds.bibliocraft.containers.ContainerBookcase@eb21918
BigReactors
root is erogenousbeef.bigreactors.gui.container.ContainerReactorAccessPort@7275f0b1
Immersive engineering
root is blusunrize.immersiveengineering.common.gui.ContainerFermenter@10bcc349
root is blusunrize.immersiveengineering.common.gui.ContainerRefinery@4673ae94
root is blusunrize.immersiveengineering.common.gui.ContainerRevolver@6569255b
root is blusunrize.immersiveengineering.common.gui.ContainerToolbox@63f73065
EnderStorage
root is codechicken.enderstorage.container.ContainerEnderItemStorage@6d0897a4
ExtraUtilities2 Trash can
root is com.rwtema.extrautils2.tile.TileTrashCan$ContainerTrashCan@6676e8e4
IndustrialCraft 2
root is ic2.core.gui.dynamic.DynamicContainer@232fa339
Pam's shipping bin
root is com.pam.harvestcraft.gui.ContainerShippingBin@48db7835
ThermalExpansion machines
root is cofh.thermalexpansion.gui.container.machine.ContainerCharger@6e3baddd
root is cofh.thermalexpansion.gui.container.machine.ContainerCrucible@1c43413d
root is cofh.thermalexpansion.gui.container.machine.ContainerExtruder@90d3c38
root is cofh.thermalexpansion.gui.container.machine.ContainerFurnace@a99e79e
root is cofh.thermalexpansion.gui.container.machine.ContainerPulverizer@232432b2
root is cofh.thermalexpansion.gui.container.machine.ContainerSawmill@50a5cf5
root is cofh.thermalexpansion.gui.container.machine.ContainerTransposer@18c6c211
Tinker's blocks
root is slimeknights.tconstruct.smeltery.inventory.ContainerSmeltery@1651c806
root is slimeknights.tconstruct.tools.common.inventory.ContainerCraftingStation@1d130c9a
root is slimeknights.tconstruct.tools.common.inventory.ContainerToolForge@d48cb13
root is slimeknights.tconstruct.tools.common.inventory.ContainerToolStation@7d15a74b
Case 4: Draconic Evolution fusion crafting
root is com.brandon3055.draconicevolution.inventory.ContainerFusionCraftingCore@5c5a75cc
=> I'll try your proposal of scanning all slots
Case 5: Elulib inventory slot's root isn't a CarriedInventory
transaction is SlotTransaction{slot=elucent.elulib.container.SlotInventoryDefault@1685e7cc, original=SpongeItemStackSnapshot{itemType=gadgetrycore:silicon, quantity=64}, default=SpongeItemStackSnapshot{itemType=minecraft:air, quantity=0}, custom=Optional.empty, valid=true}
root is org.spongepowered.common.item.inventory.adapter.impl.comp.OrderedInventoryAdapter@3756c66f
=> is there an API being that OrderedInventoryAdapter class?

Does the cause tracker include the block that was activated by the player? could we recover it from the ClickInventoryEvent and ChangeInventoryEvent.Pickup events?

CarriedInventory is mixed into all Containers because in some cases we can provide a Carrier.
All we can do with those modded inventories is trying to find the TileEntity so that we can extract the location from it.
BlockCarrier and MultiblockCarrier should be present for the Vanilla Inventories that are not TileEntities (Workbench, Anvil) and the DoubleChest.
For all opened inventories the root should always be some Container.
ChangeInventoryEvent.Pickup is not an interaction with a block.
As for saving the activated block for ClickInventoryEvents that might be possible.

I see BlockCarrier has a getLocation() method but doesn't implement Locatable. Any reason for that?
EnderChest doesn't seem to have BlockCarrier for the slot parent nor root nor carrier.

I forgot to add Locatable.
EnderChests are not BlockCarriers. The player should be carrier for an EnderChest Inventory.

added location for BlockCarrier on block interact / inventory open
also BlockCarrier is Locatable now
So this should work in most cases now.


pull request for e2e test at 12/18/2016 01:56:18

:white_check_mark: Validation status: passed
For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


feat(platform): support container secrets

Feature
Allows exposing secrets from AWS Parameter Store or AWS Secrets Manager to a container.
Closes #4966

Thanks @ubinatus!
Made 3 changes:

Renamed the field ssm as secrets can cause confusion w/ SST Secrets.
Made ssm take a key value objects instead of array
Granted permission to fetch from SSM and Secret Manager


Add ConfigMgr Antivirus Exclusions Article

We have been having a lot of different feedback in regards to providing official guidance regarding Antivirus Exclusions for ConfigMgr or other products collectively in MS Docs where we can collectively reference our Support Articles covering recommendations for customers.  Previously we had been leveraging other sources such as Blogs or Wiki pages to evangelize updated articles on Microsoft products.  Here is a recent example that would be more appropriately detailed in MS Docs:
https://techcommunity.microsoft.com/t5/Core-Infrastructure-and-Security/Configuration-Manager-Current-Branch-Antivirus-Exclusions/ba-p/884831
Thanks again for your time!
Brandon

I'm closing this issue, we're tracking with an internal work item (7035138)


Size 14x14 to 16x16 patch interpolation for smaller EVA 2 models

Hi,
First of all, thank you for the great work you've published. I am trying to train EVA 2 on a custom object detection dataset and noticed that the *_p14to16 pre-trained models are only available for EVA-B and EVA_L (in this table), but not for the other model sizes. I am trying to use the smaller EVA S and/or Ti models instead. As far as I understand, the conversion from p14 to p16 involves a linear interpolation of the pos_embed parameters, as mentioned here. This would mean that it could also be applied as a post-processing step of the checkpoint file for the smaller models.
I have tried to do the interpolation myself, by using the interpolate_patch_14to16.py script. However, this does not seem to work for the EVA 2 checkpoints, because of an error in accessing key values in the checkpoint:
Traceback (most recent call last):
  File "/home/tobias/EVA/EVA-01/eva/interpolate_patch_14to16.py", line 53, in <module>
    patch_embed = checkpoint["model"]['patch_embed.proj.weight']
KeyError: 'model'

I am not quite sure if applying the script would be the right approach to take or if another approach is necessary. Could you provide any feedback on this? Thanks in advance!

I think I found a decent solution. The interpolate_patch_14to16.py script can be modified in the following way:

The p14 checkpoints contain the weights under the module key, not model. I.e. use checkpoint['module'] instead of checkpoint['model'].
Bicubic interpolation does not work for half float16 precision. As far as I can see, this can be solved by converting to float32 as an intermediary step. I.e.:

        pos_tokens = pos_tokens.float()  # convert to float32 because float16 is not supported for bicubic interpolation
        pos_tokens = torch.nn.functional.interpolate(
            pos_tokens, size=(new_size, new_size), mode='bicubic', align_corners=False)
        pos_tokens = pos_tokens.half()  # convert back to float16

I think I found a decent solution. The interpolate_patch_14to16.py script can be modified in the following way:

The p14 checkpoints contain the weights under the module key, not model. I.e. use checkpoint['module'] instead of checkpoint['model'].
Bicubic interpolation does not work for half float16 precision. As far as I can see, this can be solved by converting to float32 as an intermediary step. I.e.:

        pos_tokens = pos_tokens.float()  # convert to float32 because float16 is not supported for bicubic interpolation
        pos_tokens = torch.nn.functional.interpolate(
            pos_tokens, size=(new_size, new_size), mode='bicubic', align_corners=False)
        pos_tokens = pos_tokens.half()  # convert back to float16

Hi @tobiasvanderwerff,
I think the same holds for patch_embed:
patch_embed = torch.nn.functional.interpolate(patch_embed.float(), size=(16, 16), mode='bicubic', align_corners=False)
While there is already the .float(), making the interpolate correctly work, the .half()to convert back to float16 is missing. Btw, thanks for the hint!


"Back" icon should be replaceable

When used in rtl mode, the arrow icon to close the search bar points in the wrong direction. It should be pointing to the right. It would be best to allow customizing this icon as well.

Hi, I agree.


How to use field node source_service  option on system.xml ?

Topic Link
https://experienceleague.adobe.com/docs/commerce-operations/configuration-guide/files/config-reference-systemxml.html?lang=en
Description
In the official documentation, the field node has source_service, but there is no example of how to use it, and there is no place for using it in the framework vendor. How to use this?

The source_service field node was first introduced as part of the Service Calls Framework in the Magento version <IP_ADDRESS>-dev45 in 2013.
The following are excerpts from the CHANGELOG.md file.

Various improvements:

Refactored experimental implementation of Service Calls Framework

All code from to lib/Magento/Datasource and app/code/Mage/Core/Datasource moved to app/code/Mage/Core/DataService
Added service calls support in Layout model
Fixed bugs and architectural flaws
Changed service calls declaration
Improved test coverage
Introduced mechanism to retrieve values from nested arrays by path
Added Invoker class to invoke service calls by given name
Added ability to define system configuration options via service calls. Refactored implementation for select field in XML

Related commit: https://github.com/magento/magento2/commit/a15ecb31976feb4ecb62f85257ff6b606fbdbc00
The Service Calls Framework in Magento was removed since the Magento version <IP_ADDRESS>-dev62 in 2014.
The following is an excerpt from the CHANGELOG.md file.

Removed the deprecated service-calls and data source functionality

Related commit: https://github.com/magento/magento2/commit/8f72656ff34b751fae5227481de836f269f52270
As a result, the source_service field node is no longer used.


Fleet Accounts Error 401

We have a few users with municipalities and their vehicles are under a Tesla Fleet Account with multiple vehicles.  We were able to obtain data from these fleet accounts with the owner api but receive the following error with the fleet api:
{"response":null,"error":"unknown user","error_description":""} ) 401
According to the Fleet API Docs this is due to mobile access being disabled or an expired token but they are able to access their vehicles with the mobile Tesla app and we're able to refresh their token so neither seem to be the issue.
Is there anything we need to change or they need to change to get this working or is the Fleet API not setup for these accounts yet?

See this:
As part of a security improvement, the acquisition of a new Refresh token will now render the user’s previous Refresh token and its associated Access tokens invalid
From: https://developer.tesla.com/docs/fleet-api#announcements-amp-api-changelog
This is per partner account. so, Tesla app working is not related.

We have a few users with municipalities and their vehicles are under a Tesla Fleet Account with multiple vehicles. We were able to obtain data from these fleet accounts with the owner api but receive the following error with the fleet api:
{"response":null,"error":"unknown user","error_description":""} ) 401
According to the Fleet API Docs this is due to mobile access being disabled or an expired token but they are able to access their vehicles with the mobile Tesla app and we're able to refresh their token so neither seem to be the issue.
Is there anything we need to change or they need to change to get this working or is the Fleet API not setup for these accounts yet?

This was a bug on Tesla's side that I also experienced.
Today it works fine.

Please see https://developer.tesla.com/docs/fleet-api#help-and-support.
In order to improve our response times, the scope of the Github issues tracker is being narrowed to the Golang code in the SDK. Backend issues should be reported to the Fleet API support team.


Split out embedded integration from connected integration

Generated previews are available for the following updated pages:

Mattermost for Microsoft Teams
Install the Mattermost for Microsoft Teams plugin
Collaborate within connected Microsoft Teams

Embedded integration content has been split out from plugin details:

Embed Mattermost within Microsoft Teams
Collaborate within embedded Microsoft Teams

@johndavidlugtu - I've applied your feedback; however, I think we have a few threads on this PR that may need further discussion/alignment (especially since I'm working from an understanding that the embedded experience requires the plugin itself to be installed, and your feedback suggests to be that this may not be the case).

@cwarnermm good callout!
Yes, it does use the same integration. After thinking it through a bit more based on what you raised, I'm not sure there's value in highlighting the fact it's the same integration that needs to be installed for the MS Teams connected experience (syncing) and the MS Teams embedded experience.

@johndavidlugtu - The one place where I think we need to be clear that it's the same integration is during install/setup. Admins must install the plugin first to be able to embed Mattermost in MS Teams. Thoughts?

@cwarnermm yup I think that's a good place to mention. Thanks!


Documentation error

Documentation link - https://wso2.com/whitepapers/a-pragmatic-approach-to-rock-your-api-strategy/
The sentence-
How are you treating your analytics? Does real-time analytics impacts your business?
uses Does(plural) with impacts(plural).
Update it to -
How are you treating your analytics? Does real-time analytics impact your business?

I have edited the text as suggested.


[Navigator Performance] Memory is not released after scene popped in Navigator

I have a large list rendered in Navigator, but when I popped the scene, memory was not released.
The memory usage in Instruments was like this.

But if I destroy the list  without Navigator,  memory usage would drop quickly as the following picture show:

So anyone please could give me a hint on this problem? Or anyone else has this problem too?

+1

Memory is big problem.

+1, I think I've experienced this as well (android, devmode & debug off) when transitioning between two Navigator scenes (one is a small list) are slow but getting slower and finally grinds to a halt.

+1

+1

+1

+1, also some variables are not destroyed so it's saved in memory with old data which causes confusion in usage.

+1, also some variables are not destroyed so it's saved in memory with old data which causes confusion in usage.

+1 Memory usage is big problem for me. I wanted to post slimier problem for android. I have monitored android app memory usage, most of memory seems to be eated by none-java code(dalvik heap),  in adb command report it reports most of memory is used by 'Unknown'. this is probably is javascript VM, (javascriptcore), and some other react-native c++ tools (NDK stuff). i hoe this problem resolve.

Please consider creating product pains post and upvoting there.

+1

I also run into this problem in the debug build.
Although, it may not be happened in the release build for my application, which is not the match memory remain.

+1, please upvote here on Product Pains for more visibility! https://productpains.com/post/react-native/navigator-performance-memory-is-not-released-after-scene-popped-in-navigator/

+1

In our iOS app, memory is increasing even when the app is "idle" (user does nothing and views are setled).
If I use the replace instead of push in the Navigator then this does not happen, so it is clearly a Navigator issue. Is there a fix for this, as this made us use only the replace method which means that we have no back functionality.

@af7 , Navigator does not unmount scenes that are off screen, because you might want to quickly go back and keep internal state like scroll position.
It sounds like we may be talking about 3 issues here:

Navigator does not unmount any of the current scenes - known design problem. We have ideas to address this in the RFC of the next navigator: https://github.com/ericvicenti/navigation-rfc/issues/4
Increasing memory usage while idle, as experienced by @af7 . We should track this in a separate issue. @hedgerwang, have you seen any memory issues with Navigator while idle?
This issue as described by the title: memory is not freed for popped scenes. From what I can tell on this thread, it seems to be Android-only and may be the same thing as #4963

+1 old variables not re-initialized

This issue seems like it went a few different ways but overall I think it led into a feature request for better navigation which is in progress so I am going to close this issue.

#10789 contains a fix for this for iOS. We aren't running Android yet so that must be a separate issue (possibly with a similar fix though). That said, this bug does exist on iOS, as I realised last week, and as reported by OP @chenjun1011, so I'm assuming others will find it via this issue.
@lacker can you re-open this until the PR gets merged?

This issue was about Navigator and not NavigatorIOS.
But regardless, thanks for fixing it! The issue is super clear as you have described it, and your fix makes sense, so I've started merging it.

@ericvicenti thanks!

Android still never clears the whole route stack (after 40 views app becomes slow and will eventually crash). Why is this closed?

Also having major issues with memory building up for each view that I go to -- to the point that the app becomes the #1 candidate for garbage collection/memory cleanup when it is backgrounded. This is a problem because it's a streaming music app, and staying alive in the background is essential.

our app at rest (login view with 3 sliding images) takes up more mem (120MB) than a reasonably active slack app. agreed this is opaque feedback. RN 0.35. investigating instruments in iOS.


GoModExtractor test cases failing

While I was working on #98 I noticed that the test cases for GoModExtractor were failing.
The ending parentheses were not being parsed properly and the for-loop were checking for ) rather than )\r.
Will open a PR to fix this.

Ah, you're on a windows machine. That could explain it.

I don't have an editor config setup for the repo. Probably worth putting one together at some point.

Can you add hacktoberfest tag?

Because this project is not just under the general Hacktoberfest event but also the Indeed one, there are some things I need to be careful of with regard to the hacktoberfest label (specifically issue sizing). I'd say the combination of this and gh-69 (gh-98) is better scoped for Indeed is looking for. Otherwise I would've.


[Feature][MasterServer] Dependent tasks can re-run automatically in the case of complement

Purpose of the pull request
This pr will close #8373

Codecov Report

Merging #8496 (3521849) into dev (95c1192) will decrease coverage by 0.18%.
The diff coverage is 13.13%.

@@             Coverage Diff              @@
##                dev    #8496      +/-   ##
============================================
- Coverage     45.42%   45.24%   -0.19%
+ Complexity     4034     4030       -4
============================================
  Files           686      688       +2
  Lines         26725    26819      +94
  Branches       2870     2882      +12
============================================
- Hits          12139    12133       -6
- Misses        13440    13537      +97
- Partials       1146     1149       +3

Impacted Files
Coverage Δ

...cheduler/common/enums/ComplementDependentMode.java
0.00% <0.00%> (ø)

...heduler/dao/entity/DependentProcessDefinition.java
0.00% <0.00%> (ø)

...lphinscheduler/service/process/ProcessService.java
31.93% <0.00%> (-0.03%)
:arrow_down:

...cheduler/api/service/impl/ExecutorServiceImpl.java
42.66% <22.72%> (-4.44%)
:arrow_down:

...inscheduler/api/controller/ExecutorController.java
40.00% <50.00%> (-1.94%)
:arrow_down:

...he/dolphinscheduler/common/enums/SqoopJobType.java
0.00% <0.00%> (-88.89%)
:arrow_down:

...e/dolphinscheduler/remote/NettyRemotingClient.java
50.70% <0.00%> (-2.82%)
:arrow_down:

...inscheduler/common/task/sqoop/SqoopParameters.java
74.00% <0.00%> (-2.00%)
:arrow_down:

...nscheduler/api/service/impl/TenantServiceImpl.java
70.53% <0.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 95c1192...3521849. Read the comment docs.

@SbloodyS Well done, thanks for your contribution.
BTW, I add the miss document label, please submit the doc after UI part finish.


Architectural help for specifying which handler to use

I'm working on a system where I've started using Mediatr to separate out our commands / queries.
One such request is GetAccountInformation
I've simplified the logic down, but the kind of issue I'm having, is we need to query a service to find out which sub-system to use, in order to get the account information.
Probably better to illustrate with code...
So, currently, in a 'core' namespace/assembly, I have
public class GetAccountInformationRequest : IAsyncRequest<AccountInformation>
{
    public string AccountReference {get; set}
}

Then, the handler looks something like this
public class GetAccountInformationRequestHandler :
    IAsyncRequestHandler<GetAccountInformationRequest , AccountInformation>
{
    private readonly IMediator _mediator;

    public GetAccountInformationRequestHandler(IMediator mediator)
    {
        _mediator = mediator;
    }

    public async Task<AccountInformation> Handle(GetAccountInformationRequest request)
    {
        //this sends a different request off to another handler which determines which sub system to use
        var subSystem = await _mediator.SendAsync(new GetAccountSubSystemRequest(request.AccountReference));

        //this is rubbish, but I've only done this to illustrate the kind of thing I need to do
        if(subSystem == 'SystemA')
            return await _mediator.SendAsync(new SystemA.GetAccountInformationRequestFromSystemRequest(request.AccountReference));
        if(subSystem == 'SystemB')
            return await _mediator.SendAsync(new SystemB.GetAccountInformationRequestFromSystemRequest(request.AccountReference));
        if(subSystem == 'SystemC')
            return await _mediator.SendAsync(new SystemC.GetAccountInformationRequestFromSystemRequest(request.AccountReference));

        throw new Exception("Unknown sub system");
    }
}

As you can see, I've then got additional namespaces (in separate assemblies) with the specific requests in -
This does feel a bit rubbish. For a start, it feels like there's a lot of duplication here - really, I just need the specific handlers
And the obvious violation of Open/Closed
Any ideas?

Feels almost like I need to be able to do something like
_mediator.SendAsync(request, "SystemA");

... and being able to 'tag' the implementations of the handler (based on namespace or something) during my container setup
unless of course, there's a better, more concrete and less string based way!

From my understanding it looks like you should take a look at the abstract factory pattern (though I'm keen to see other's approaches to the problem are).
This post should give you a better understanding of the pattern -  http://blog.ploeh.dk/2012/03/15/ImplementinganAbstractFactory/


Add e2e tests for new model overview experience (part 1)

Description
While adding e2e tests for the new model overview experience I encountered several challenges that needed to be addressed first. Therefore, this PR contains somewhat more than just the tests:

e2e-widget.js:

ability to execute individual notebooks only instead of the entire set of notebooks - this is done via a parameter for yarn e2e-widget called -n. Also, I added a parameter --skipgen to skip the notebook generation since that takes a while every time, too. When debugging this locally it can save lots of time to skip the notebook generation.
ability to generate notebooks with flights injected! We just pass feature_flights to the dashboard constructor and voila we can run e2e tests on the flighted UI. Note that the flighted notebook has a different name (which includes the flight name(s)). Right now there's only 1 flight, but if there were multiple we'd need to specify which combinations we want to have e2e tests for and add spec files accordingly (more on spec files below).

notebook/test case naming standardization: There was some inconsistency before between test case naming and notebook naming. This complicated the aforementioned individual notebook execution considerably, so I've gone ahead and standardized the names. This accounts for a lot of the changed files, although it should be trivial to skim through.
renamed modelStatistics.spec.ts to modelOverview.spec.ts - simply because we don't call it model statistics anymore, not even in the "old" model overview. The "new" model overview spec files just call describeModelOverview.
added a very basic set of tests for the new model overview experience in the e2e package (describeNewModelOverview under v2) and moved the existing ones into a v1 folder. Tests don't cover all tasks yet (only regression as of now) and are only applied to 1 notebook for now. The rest will be in a part 2 PR.
lots of spec files for the flighted notebooks. These aren't necessarily very different. The only file that actually differs is the one about model overview (using describeNewModelOverview). You can easily imagine future scenarios where there is quite a bit of difference so this duplication may end up being less duplication than it looks right now. Fortunately, I found a nice way to avoid duplicating the "expected" values (see modelAssessmentDatasets.ts). Right now, only one notebook, diabetes-regression-model-debugging, actually uses the new tests that I wrote in this PR. I will have another PR to spread it to all notebooks. It just felt like it's getting too large to add a lot more logic here.
fix random_state in notebooks where needed. Without deterministic outputs it's kind of hard to test for expected values... I'm kind of amazed we didn't run into this before.

For the record, I fully expect to delete everything v1/old as soon as we are confident about v2/new. This will not linger around like other "old" parts that we've seen in the past.
Checklist

[ ] I have added screenshots above for all UI changes.
[ ] Documentation was updated if it was needed.
[x] New tests were added or changes were manually verified.

Codecov Report

Merging #1462 (2a53ea9) into postbuild (f968546) will increase coverage by 12.99%.
The diff coverage is n/a.

@@               Coverage Diff               @@
##           postbuild     #1462       +/-   ##
===============================================
+ Coverage      87.00%   100.00%   +12.99%
===============================================
  Files            100         8       -92
  Lines           4801        64     -4737
===============================================
- Hits            4177        64     -4113
+ Misses           624         0      -624

Flag
Coverage Δ

unittests
100.00% <ø> (+12.99%)
:arrow_up:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

...bleai/responsibleai/_tools/causal/causal_result.py

raiwidgets/raiwidgets/fairness_dashboard.py

...onsibleai/responsibleai/managers/causal_manager.py

erroranalysis/erroranalysis/_internal/utils.py

...ponsibleai/responsibleai/_tools/shared/versions.py

responsibleai/responsibleai/exceptions.py

raiwidgets/raiwidgets/explanation_constants.py

...ranalysis/erroranalysis/_internal/cohort_filter.py

.../responsibleai/_managers/counterfactual_manager.py

raiwidgets/raiwidgets/interfaces.py

... and 82 more

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 f968546...2a53ea9. Read the comment docs.

Will we move these tests to AML once v2 of model overview is fully released?

Will we move these tests to AML once v2 of model overview is fully released?

I would assume so! I haven't quite had a chance to look into how we're testing for AML in detail yet, but if it's as simple as calling describe<insert component name> then I'm sure we'll want to do it!

The steps to run e2e still remains same? should we add updated script commands to https://github.com/microsoft/responsible-ai-toolbox/blob/main/CONTRIBUTING.md

Current specs:
    "e2e": "nx e2e dashboard-e2e",
    "e2e-watch": "yarn e2e dashboard-e2e --watch",
    "e2e-widget": "node ./scripts/e2e-widget.js",

e2e here means the non-notebook tests, e2e-watch is the same with individual test case execution, and e2e-widget is the notebook e2e tests. I've only adjusted the e2e-widget script, but will update the instructions now.

Closing this PR to open a new one targeted at main!


Release 1.3.1

[x] Start from the release branch
git checkout release
[x] Make a new branch for the release cycle
git checkout -b releases/{version}
[x] Merge the current master with the release
git pull origin master
[ ] Start a release
bumpversion release
[ ] Edit doc/CHANGELOG.rst
[ ] Send the release to be evaluated
git push
[ ] Verify CI on azure
[ ] Manually trigger a jpype.release on azure
If successful, download the artifacts for publication.
[ ] Advance the release pointer
git checkout release
git merge releases/<version>
[ ] Publish the release

Add draft release on github
Attach the artifacts to the release.

[ ] Start master on a new cycle

Use a PR to pull release back to master
git checkout master
git checkout -b cycle
git merge release
bumpversion patch
Use PR to insert the cycle in master

will this support py 3.10 on linux? currently it wants gcc installed:
Collecting JayDeBeApi==1.2.3
  Downloading JayDeBeApi-1.2.3-py3-none-any.whl (26 kB)
Collecting JPype1
  Downloading JPype1-1.3.0.tar.gz (820 kB)
     ━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━ 820.3/820.3 KB 558.9 kB/s eta 0:00:00
  Preparing metadata (setup.py) ... done
Building wheels for collected packages: JPype1
  Building wheel for JPype1 (setup.py) ... error
  error: subprocess-exited-with-error

  × python setup.py bdist_wheel did not run successfully.
  │ exit code: 1
  ╰─> [56 lines of output]
      running bdist_wheel
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-3.10
      creating build/lib.linux-x86_64-3.10/jpype
      copying jpype/__init__.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_classpath.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_core.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_gui.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jarray.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jclass.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcollection.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcustomizer.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jexception.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jinit.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jio.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jmethod.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jobject.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jpackage.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jproxy.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jstring.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jthread.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jvmfinder.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_pykeywords.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/beans.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/config.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/dbapi2.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/imports.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/nio.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/pickle.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/protocol.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/types.py -> build/lib.linux-x86_64-3.10/jpype
      package init file 'jpype/_pyinstaller/__init__.py' not found (or not a regular file)
      creating build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/entry_points.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/example.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/hook-jpype.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/test_jpype_pyinstaller.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_core.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcollection.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jio.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jstring.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jthread.pyi -> build/lib.linux-x86_64-3.10/jpype
      running build_ext
      Call build extensions
      Using Jar cache
      copying native/jars/org.jpype.jar -> build/lib.linux-x86_64-3.10
      Call build ext
      building '_jpype' extension
      creating build/temp.linux-x86_64-3.10
      creating build/temp.linux-x86_64-3.10/native
      creating build/temp.linux-x86_64-3.10/native/common
      creating build/temp.linux-x86_64-3.10/native/python
      gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -Wall -fPIC -Inative/common/include -Inative/python/include -Inative/embedded/include -Inative/jni_include -I/usr/local/include/python3.10 -c native/common/jp_array.cpp -o build/temp.linux-x86_64-3.10/native/common/jp_array.o -g0 -std=c++11 -O2
      error: command 'gcc' failed: No such file or directory
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
  ERROR: Failed building wheel for JPype1
  Running setup.py clean for JPype1
Failed to build JPype1
Installing collected packages: JPype1, JayDeBeApi
  Running setup.py install for JPype1 ... error
  error: subprocess-exited-with-error

  × Running setup.py install for JPype1 did not run successfully.
  │ exit code: 1
  ╰─> [56 lines of output]
      running install
      running build
      running build_py
      creating build
      creating build/lib.linux-x86_64-3.10
      creating build/lib.linux-x86_64-3.10/jpype
      copying jpype/__init__.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_classpath.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_core.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_gui.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jarray.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jclass.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcollection.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcustomizer.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jexception.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jinit.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jio.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jmethod.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jobject.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jpackage.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jproxy.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jstring.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jthread.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jvmfinder.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_pykeywords.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/beans.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/config.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/dbapi2.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/imports.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/nio.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/pickle.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/protocol.py -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/types.py -> build/lib.linux-x86_64-3.10/jpype
      package init file 'jpype/_pyinstaller/__init__.py' not found (or not a regular file)
      creating build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/entry_points.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/example.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/hook-jpype.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_pyinstaller/test_jpype_pyinstaller.py -> build/lib.linux-x86_64-3.10/jpype/_pyinstaller
      copying jpype/_core.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jcollection.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jio.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jstring.pyi -> build/lib.linux-x86_64-3.10/jpype
      copying jpype/_jthread.pyi -> build/lib.linux-x86_64-3.10/jpype
      running build_ext
      Call build extensions
      Using Jar cache
      copying native/jars/org.jpype.jar -> build/lib.linux-x86_64-3.10
      Call build ext
      building '_jpype' extension
      creating build/temp.linux-x86_64-3.10
      creating build/temp.linux-x86_64-3.10/native
      creating build/temp.linux-x86_64-3.10/native/common
      creating build/temp.linux-x86_64-3.10/native/python
      gcc -pthread -Wno-unused-result -Wsign-compare -DNDEBUG -fwrapv -Wall -fPIC -Inative/common/include -Inative/python/include -Inative/embedded/include -Inative/jni_include -I/usr/local/include/python3.10 -c native/common/jp_array.cpp -o build/temp.linux-x86_64-3.10/native/common/jp_array.o -g0 -std=c++11 -O2
      error: command 'gcc' failed: No such file or directory
      [end of output]

  note: This error originates from a subprocess, and is likely not a problem with pip.
error: legacy-install-failure

× Encountered error while trying to install package.
╰─> JPype1

note: This is an issue with the package mentioned above, not pip.
hint: See above for output from the failure.

Once the dist is released it should have precompiled binaries available so no gcc required.

Very nice a new release is coming, especially with the improved Python 3.10 support. Is a release date expected?

Would have been out 2 weeks ago but we hit some reports of segfaults.  So I am guessing 2 weeks from now they will be resolved so I can continue the release.


[zh] Sync feature-gates/g*.md

Related to issue https://github.com/kubernetes/website/issues/44410
Add the new 'stages' metadata to all zh feature gate filename prefixed with "g" in
content/zh-cn/docs/reference/command-line-tools-reference/feature-gates/

gce-regional-persistent-disk.md
generic-ephemeral-volume.md
graceful-node-shutdown-based-on-pod-priority.md
graceful-node-shutdown.md
grpc-container-probe.md

/approve

/lgtm


Remove "parent" property?

2nd-level CityObjects like "BuildingInstallation" offer a "parent" property of type string which is the ID of the parent CityObject. It is assumed that every 2nd-level CityObject has exactly one parent, and this is fine for the CityJSON core objects.
But what about extensions? The EnergyADE, for instance, defines a feature type called Construction to define the structure, material and energy-related properties of walls or roofs. As many walls in a building are of the same type, their Construction only needs to be defined once in a dataset and then can be reused by the different wall objects. This also helps to keep the file size small.
So, when mapped to a CityJSON extension, "Construction" would be an example of a CityObject having multiple parents. A simple string would not be sufficient anymore. I see three possibilities to solve this:

Keep the restriction that a CityObject can have at most one parent. As a consequence, CityObjects like "Construction" cannot be reused. Instead, every wall would have to reference its own "Construction" copy as child even if all these copies would have identical properties and values. This would also increase file size.

Redefine "parent" to be an array of strings to be able to reference the IDs of multiple parents.

Completely remove the "parent" property from all CityObjects. As a consequence, the bi-directional associations between CityObjects would become one-directional (from the parent to the child via the "children" property).

I propose option 3. When reading a CityJSON dataset into main memory, it is really simple to internally create pointers from a child to its parent(s) based on the "children" property in case an application really needs to navigate associations in both ways. Moreover, having both "children" and "parent" as properties in the dataset increases the possibility of inconsistencies between them.

The issue I see is that we identify a 2nd-level CityObject if it has the property "parent"... it's pretty useful when scanning a file to count number of CO (eg Buildings): you just count those not having a "parent" property (and thus BuildingPart not counted as a CO). Of course one can compute these rather easily, but I still think it's elegant and simple.
What we could do is have "parent" be an array. That would solve the problem with Extensions, and it would also harmonise the property with that of "children". Now one is array the other is string, but both arrays of strings would mean less error-prone maybe.


Fixed issues #28 and #31

Issue #28 $.each{...} was appending to table, the table was not always where the table rows were located if they were in "tbody". Issue #31, finding cells by :nth-of-type did not consider row headers.

Thanks!


Upgrade version.jooq 3.14.3 -> 3.14.4

This PR contains the following updates:

Package
Update
Change

org.jooq:jooq-meta-extensions
patch
3.14.3 -> 3.14.4

org.jooq:jooq-codegen-maven
patch
3.14.3 -> 3.14.4

org.jooq:jooq-meta
patch
3.14.3 -> 3.14.4

org.jooq:jooq-codegen
patch
3.14.3 -> 3.14.4

org.jooq:jooq
patch
3.14.3 -> 3.14.4

[ ] If you want to rebase/retry this PR, check this box

Suggested commit message:
Upgrade jOOQ 3.14.3 -> 3.14.4

See:
- https://www.jooq.org/notes
- https://github.com/jOOQ/jOOQ/compare/version-3.14.3...version-3.14.4


Close task with auto_recrawl

I want close task that has self.crawl(this_url,age=1800, auto_recrawl=True)
I have condition:
If response.orig_url != response.url:
self.crawl(this_url,age=0, auto_recrawl=False)
#This task rewrite in DB, but go on to restart, every 1800 seconds...
How close this task?

self.crawl(this_url, auto_recrawl=False, force_update=True)

Another question about auto_recrawl.
If pyspider keeps ACTIVE tasks in memory, how many auto_recrawl tasks can be active in the same time?
For example we need to automatically update 10k pages every 30 seconds - we set auto_recrawl for all theese tasks, but somehow many of them not processing and scheduler behavior is quite strange. Some tasks work, some not, even from other projects.
How we can achive this?
Can we just set exec_time manually and will task be put in queue  (not mermoy) ?

Updating 10k pages every 30 seconds means pyspider need to make 333 requests per second, which are huge to handle and limited by the rate.
The queue is implemented in memory. But you can try to store the latter part of the queue onto disk.

Ok, we can use age +- few seconds for reduce load on scheduler, but, anyway, we trying to achive huge data update: in future we need to keep up-to-date data from about 250k pages, refreshing it every 1-5 minutes.
Any ideas how we can do that?
Now scheduler + rabbit on one server and 35 fetchers + 100 processors + 10 result workers on second server, all data saving in result workers are made by batch queries, but, still, seems to be ACTIVE queries sit in memory and scheduler can't process new tasks until done with that ACTIVE.
Can scheduler put auto_recrawl tasks in queue somehow?

Firstly, you need huge bandwidth to fetch the pages in short interval.
Secondly, pyspider need to dispatch ~830 requests per second, which is too large for pyspider. It's better to implement another scheduler scan & dispatch the tasks rather than put them in queue. Other components can be reused.
Current implement of scheduler is using time-based queue to track every auto recrawl tasks to support recrawl mechanism, it can not support large number of recrawl tasks.

Can it be achived if we run few instances of pyspiders on different servers by same scheme (scheduler+rabbit and fetchers/workers) and put some big projects on that instances? Bandwith is 100Gb as far as I know.

Only one scheduler instance is allowed. And yes, you can separate the projects onto different servers (A project on A, B project on B) but can't share the same database table.
The current queue based implement doesn't suit for your case (huge number of tasks, same interval). The appropriate way is putting the auto recrawl tasks into a separate table and scan over the tasks every minutes without any queue.

Soo we can run tasks as recursion ? Using, for example, another queue and worker which will get tasks and send message for project for creating tasks?
Like it: Task completed, send message for creation same task to project Z. Project Z put task in some other queue (redis, rabbit, etc). Then Project X take queue from redis and sending messages to projects, which creating task inside self.
Will it works?
Or the second idea... based on setTimeout like in JS, job is done - creating subthread which wait 5 mins and fire self.crawl with force_update.
Any suggestions?
Or can you explain, please, how do that without queue?

"other queue (redis, rabbit, etc)" cost memory resources too and "creating subthread" cost even more...
To do so without queue: when a task marked as auto_recrawl, put it into another database table, for example, named auto_recrawl_tasks. A script or something select * from auto_recrawl_tasks every minute. As all of the tasks in the auto_recrawl_tasks table needs to be recrawled, it's effective to scan over the table (than using a queue and query the complete info of each task).
And, of cause, you can add last crawled time and interval info for each task in the auto_recrawl_tasks table.


add default error boundry to project

What does this PR do and why?
What: This adds an error boundry to the entire project. It's basically a giant try catch block.
Why: If there's a piece of client side JS that throws (and isn't handled) that will crash the app with a white screen.
We want a way to tell the user that something went wrong. Additionally, we want to log it in Sentry.
Mostly copy-pasta from the nextjs docs
How to test: Add a throw Error('test error') in the project, the application will show a prompt asking the user to reload the page. I feel like we should design something a bit nicer. I thought this was okay for the moment.
There isn't much in the project for error screens at the moment. This could be a good opportunity to design 500, 400, client side errors, and project not found pages.

More here: https://nextjs.org/docs/advanced-features/error-handling#handling-client-errors
Provide a description of what this PR does. Link to any relevant GitHub issues, Notion tasks or Discord discussions.
Screenshots or screen recordings
<>
If applicable, provide screenshots or screen recordings to demonstrate the changes.
Acceptance checklist

[ ] I have evaluated the Approval Guidelines for this PR.
[ ] I have tested this PR in all supported browsers.
[ ] I have tested this PR in dark mode and light mode (if applicable).

Current dependencies on/for this PR:

main

PR #2616   👈

This comment was auto-generated by Graphite.

additionally, I think there's more to be desired in terms of a error page. This could be a good time to have standard 400, 500, and project not found, and client side error pages built across the project

@wraeth-eth -- would you mind taking a look at this PR while @tomquirk is away? He LGTM'ed the bundle analyzer PR. I don't want to assume this PR has an LGTM, would love some extra 👀

Hey @benschac thanks for this, although i think we can opt for a Next-idiomatic approach here: https://nextjs.org/docs/advanced-features/custom-error-page


Limit total audio files playing to 1 with option

Might be useful to let others specify they only want to have one audio file playing at a time. e.g. I play a sound all active sounds get paused automatically. (having specified an option that I want that to be the behavior to this angular directive).
I did a quick look at wavesurferjs and it doesn't seem to do this.

It's because of using unique ID. Just I was planning to play one audio file, so If you want multiple audio files, It can be done in another way instead of adding an id. Maybe adding a random number besides the id or get it using selector like
element.children()[index]

Ah yeah I guess this issue isn't relevant unless you were wanting to accept my pull request. If not that's fine, I'll keep developing my own fork if you don't want to go that direction.

Yeah! I'm testing it and I'll accept it.

Great. I look forward to making more pull requests.


Can we expose isSelected helper from <Select.Item /> instead of <Select.ItemIndicator />

Describe the feature in detail (code, mocks, or screenshots encouraged)
Hi. Thank you for this library! 🌻  I don't know what exactly is the reasoning behind the existence of <Select.ItemIndicator /> but  from my perspective as a user of this lib it feels weird. In my app, I need conditional <Select.Item /> styling using isSelected bool  but it is exposed from another component when it could just be on <Select.Item /> itself as there are no specific builders only slot props. Currently, I need to asChild on <Select.ItemIndicator /> only to get access to isSelected.  So, is there a specific reason for this?
*Not a big issue at all but thought it could be cleaner that way
What type of pull request would this be?
Enhancement
Provide relevant links or additional information.
No response

We can certainly add this.

Closed by #285


Create spans from transaction

This is convenient feature to use in reactive environment where it is not possible to use thread locals across the transaction lifecycle.

Since this is a community submitted pull request, a Jenkins build has not been kicked off automatically. Can an Elastic organization member please verify the contents of this patch and then kick off a build manually?

Hey Dimitry and thanks for this awesome PR!
I'll have a closer look later this day. Could you explain why you changed all Spanproperties, like start and type to be volatile? Isn't a span only accessed from a single thread?

Hi @dmitry-saraykin, we have found your signature in our records, but it seems like you have signed with a different e-mail than the one used in yout Git commit. Can you please add both of these e-mails into your Github profile (they can be hidden), so we can match your e-mails to your Github profile?

Hi Felix,
In general  Spans and Transactions can be used across multiple threads in case of multithreaded processing or reactive programming. Here is example of usage spans in multiple threads with spring webflux client
//Thread 1:
Span span = transaction.createSpan();
span.setType("ext");
span.name("Some micro-service call");
webClient.post().uri(...).retrieve().doOnSuccess(r-> {
    //This will happen in another thread:
    span.end();
});

Jenkins test this, please.

Codecov Report

Merging #123 into master will increase coverage by 0.28%.
The diff coverage is 90.62%.

@@             Coverage Diff              @@
##             master     #123      +/-   ##
============================================
+ Coverage     76.73%   77.02%   +0.28%
- Complexity      950      958       +8
============================================
  Files            99       99
  Lines          3297     3312      +15
  Branches        291      293       +2
============================================
+ Hits           2530     2551      +21
+ Misses          615      605      -10
- Partials        152      156       +4

Impacted Files
Coverage Δ
Complexity Δ

...co/elastic/apm/plugin/api/SpanInstrumentation.java
68.42% <ø> (ø)
5 <0> (ø)
:arrow_down:

...ain/java/co/elastic/apm/impl/transaction/Span.java
91.66% <100%> (+0.28%)
22 <2> (+1)
:arrow_up:

...ain/java/co/elastic/apm/impl/ElasticApmTracer.java
77.08% <100%> (+1.58%)
39 <2> (-2)
:arrow_down:

...ava/co/elastic/apm/impl/transaction/SpanCount.java
100% <100%> (ø)
5 <2> (ø)
:arrow_down:

...a/co/elastic/apm/impl/transaction/Transaction.java
80.19% <100%> (+4.61%)
31 <5> (+6)
:arrow_up:

...tic/apm/plugin/api/TransactionInstrumentation.java
59.37% <40%> (-3.59%)
5 <0> (ø)

...a/co/elastic/apm/report/ReportingEventHandler.java
81.81% <0%> (+6.06%)
10% <0%> (+1%)
:arrow_up:

... and 1 more

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 4acfcb9...430a119. Read the comment docs.

I've created ElasticApm#startAsyncTransaction method to create transactions which are not bound to the current thread and must be tracked manually.
Also added Span#createSpan method to create child spans.
Changed Transaction#createSpan to create always top level spans

I like that approach of having a method for creating a non-thread bound transaction and span. I just think we should come up with a better name, as transactions are not inherently async when created with the startAsyncTransaction method. Some possibilities:

startNonActiveTransaction, which would correspond to co.elastic.apm.impl.ElasticApmTracer#activate
make non-active transactions the default and add a method for creating thread-bound transactions
make non-active transactions the default and add a method for making the transaction active on the current thread, add another one to deactivate.
make it only possible to create non-active transactions with the public API, possibly adding support for that later

I'm working on some changes based on your PR

I think startNonActiveTransaction is not a good name because the user can think that the transaction is not going to be sent or tracked. A better name may be startManualTransaction. Or may be there should be some method which creates/reuses currently active transaction but tells not to end it automatically
It should be possible to create transactions which are bounded to the thread as it will allow to use automatic instrumentation of all internal calls

Also found a bug with gzip. Currently agent uses zip instead of gizp and apm-server fails to parse such requests

closing in favor of https://github.com/elastic/apm-agent-java/pull/133. @dmitry-saraykin, could you please review that PR if it covers your use case?


I got error "Can not read property of undefined" but swiper works. Can I know What I missed?

BUG REPORT TEMPLATE
Vue.js version and component version
I'm using Vue.js 2.6.1  and awsome swiper 3.1.3
Situation
This is code works well.
          <transition :name="routerTransition" mode="out-in">
            <swiper :options="swiperOption"  :ref="reportSwiper" >
              <swiper-slide v-for="date in DateList" v-bind:key="date">
                <router-view v-bind:date-info="date" ></router-view>
              </swiper-slide>
            </swiper>
          </transition>

And I wanted to get active index. So I used computed.
	  computed: {
		currentSwiperDate() {
		  const swiper = this.$refs.reportSwiper.swiper;
		  if (!swiper)
		  {
			this.returnCurrent(0);
			return;
		  }
		  const index = swiper.realIndex;
		  this.returnCurrent(index);
		},
	}

But I get this error message.
[Vue warn]: Error in render: "TypeError: Cannot read property 'swiper' of undefined"
What is Expected?
I want to know what I missed. I enlisted reference reportSwiper and accessed.
Why swiped is undefined? what should I do to get activeindex?
What is actually happening?
It does not works. I get error.
[Vue warn]: Error in render: "TypeError: Cannot read property 'swiper' of undefined"

@parkyh1974 Same error here. Did you get a solution?

use ref instead of :ref

@Griffin23 Yes.
:ref="contextData"
ref="string"


Merge release/1.3 to develop

Conflicts:

README.md
Edited to accept merge
core/pom.xml
Used develop SNAPSHOT
core/src/main/java/co/cask/wrangler/steps/language/SetCharset.java
Corrected package to use develop
core/src/main/java/co/cask/wrangler/steps/row/SetRecordDelimiter.java
Corrected package to use develop
pom.xml
Used develop SNAPSHOT
service/pom.xml
Used develop SNAPSHOT
transform/pom.xml
Used develop SNAPSHOT

LGTM 👍


Consider using license expressions rather than a list of licenses

These are specified in SPDX and provide a clean short hand for eventually complex licensing. See for instance its emerging use in the latest Linux kernel. NB: I helped there and I am an SPDX co-founder.

Note: https://spdx.org/spdx-specification-21-web-version#h.jxpfx0ykyb60

Included in CycloneDX 1.1


vault_secret resource missing

Hi!
Please restore the vault_secret resource, it's needed to read secrets from Vault using Chef.
Looks like it went missing in this PR.
Thanks in advance,
Stephen

Was taking a look at this and what I am not personally sure is whether using the node.run_state is still the correct method. Currently in my environment I have a library that is part of a cookbook that provides a function that is utilized.

Hey @PowerSchill, thanks for taking the time to check this out!
Using node.run_state is still the recommended way as far as I know (according to the docs anyway) to store transient data that will not be persisted and saved to the Chef server.
Take this example:
vault_secret "secret/#{node['hostname']}/ssh_host_keys" do
  address node['vault']['address']
  token File.open(node['vault']['token_path'], 'rb').read.chomp
end

%w(
  ssh_host_dsa_key
  ssh_host_dsa_key.pub
  ...
).each do |ssh_host_key|
  file "/etc/ssh/#{ssh_host_key}" do
    ...
    sensitive true
    content lazy { node.run_state["secret/#{node['hostname']}/ssh_host_keys"].data[:"#{ssh_host_key}"] }
    notifies :restart, 'service[sshd]', :delayed
  end
end

Doing this allows me to retrieve values from Vault and store them in a hash in the node object to be used by other resources, safe in the knowledge that that part of the node object will not be saved to the Chef server and thus those secrets are only in memory while the Chef client runs.
Just to clarify, this issue is around the functionality that used to exist, not how it was implemented or could be reimplemented. I'm totally not opposed to implementing this in a better way, but I hope this information will help in restoring what was removed until that happens.
Stephen

I will work on it but we definitely have to remove the Poise dependency.  If you are aware of an easy way we can start a vault server and populate some values that would be awesome so I can include the unit test.


Flesh out the CLI and logic to support Compute RPC calls

@mattgeddes
I was thinking that for the compute job RPC stuff, we could get that sorted in parallel with the stuff I'm doing. If the client can send a job consisting initially of a string representing a CID, the server can receive that, add the job to an in-memory queue, and return its job ID (a random UUID). We can have the queue worker(s) just mark each job as having completed successfully, such that a status call for that job UUID will give the status back and (if it's completed), dequeue the job.

Parent issue is #519

Closed as of #754


Generated code

I've seen this issue discussed previously - generating code so that we can have type safe model functions, e.g. person.getName(), without having to create lots of getters and setters like
  public String getName() {
    return getString("name");
  }

My proposal is - an annotation generator like this - https://github.com/Saravanan21/activejdbc-generator (created separate project just because it was easier to test, but will merge into existing annotations if it seems reasonable).
The annotation processor looks for annotations of the form
@ModelAnnotation(
        propsPath = "var/conf/db.properties"
)

where the indicated file is a properties file looking like the following
db.driver = org.postgresql.Driver # Optional
db.url = jdbc:postgresql://localhost:5432/football
db.username = football
db.password = footy

It uses this to connect to the database and make a schema query to get all the column names and types, then generates a model which can then be extended.
Usage: I have a table named Person, say with several fields, including first_name and last_name, thus I created the following class Person.java:
@Table("Person")
@ModelAnnotation(
        propsPath = "var/conf/db.properties"
)
public class Person extends ModelPerson {
    public String getName() {
        return getFirstName() + " " + getLastName();
    }
}

When I build my project, the annotation processor generates a class named ModelPerson, which looks likes the following
package com.saravanan.football.model;

import java.lang.Integer;
import java.lang.String;
import java.sql.Timestamp;
import java.util.Date;
import org.javalite.activejdbc.Model;

public abstract class ModelPerson extends Model {
  public Integer getId() {
    return getInteger("id");
  }

  public void setId(Integer Id) {
    setInteger("id", Id);
  }

  public String getFirstName() {
    return getString("first_name");
  }

  public void setFirstName(String FirstName) {
    setString("first_name", FirstName);
  }

  public String getLastName() {
    return getString("last_name");
  }

  public void setLastName(String LastName) {
    setString("last_name", LastName);
  }

  ...
}

This allows Person to compile correctly (no import needed as ModelPerson is generated in the same package), and as you see our function we wrote getName() uses the two generated functions getFirstName() and getLastName().
The sql datatypes are used to know whether to generate getString vs getInteger vs getDate etc.
The only downside I have is that I need to specify the properties path with the database information - though I think that's reasonable and can't think of a neater alternative. I was looking at annotation processor styles - e.g. how Immutables do it https://immutables.github.io/style.html - but couldn't get my processor to pick them up for some reason, so will keep digging. But assuming that's doable, then you could just use @ModelStyle either on each model class individually, or at the package level by putting it in package-info.java, and avoid having to repeat that db.properties path.
Does this sound like a reasonable overall solution?

First, the @MotelAnnotation is not necessary, as  you can add a a property file to the project with your configurations: http://javalite.io/database_connection_management#multiple-environments-property-file-method
Second, while this will reduce the amount of work you need to setup your models initially, there are problems with generated code:

It complicates the framework and tools
It generates code inside the existing classes, potentially wiping out non-getter/setter methods. In our projects, it is typical to write all kinds of data access methods with complex SQL inside models. If you add a new column to the table, and decide to re-run your code generator, your generator will delete manually written code.
In our projects, we only write getters and setters we actually use in code. Those attributes used in views of ActiveWeb are automatically pulled up by Freemarker. However, your code generator will indiscriminately generate accessors for all columns, regardless if they are needed or not.

While generally a good idea, it just has too many problems associated with it. This was considered around 2009, but quickly abandoned after such analysis.

True, although so does instrumentation.

I'm not generating it inside the same class - in my example above the abstract class ModelPerson is generated, which has all the getters/setters. I only have to write the Person class that extends ModelPerson. So my manually written code in Person doesn't get updated and there's a clear distinction between manually written code and boilerplate generated.

I'm not using ActiveWeb so can't comment on that one, is it bad to have extra getters that you don't want in your views? Presumably that could happen anyway. But haven't used ActiveWeb so will leave that one to you.

What about a config file? everytime it generates codes, it create a "gen.ignore" file, to ignore all previous generated columns. And you could put only the columns you want to generate in the config file.

@LouizFC this is the point! It makes the framework complicated. Lets say you completed development of this, and it is somehow working. TRy writing documentation explaining to people how to use it :). Currently, no files are needed for configuration

Agree that config files make it complicated. I don't see the complication in my proposal, given point 2 above.

Just having an abstract class in the first place is a complication. In most of the projects we have one model per table

I feel like the fact that the second class is generated and should never be touched or need to be looked at makes it not any more complex from a use perspective. But understand your push back, thanks for taking the time to reply!

@Saravanan21 thanks for understanding!
The benefit does not outway the effort here.


[Question] Help Offer - German Translation

Hey 👋  I wanted to ask if more translations are planned. I found the lang file in the games resources and made my own german translation which replaces the russian one. If you want I could make / improve the german Translation 😉

You can ping me (Tomat#0001) in the I.RULE Discord for the translator role.
Anyone is free to fork this repository and PR any translations without prior contact.


Add a simple variant implementation similiar to std::variant

Approving given @andy31415 is OK with this... personally a little worried about this type of thing proliferating heavily.


Fix mypy issue with entry_points

This was causing a mypy failure locally — it may be a dependencies issue, but I thought there was limited downside to widening this ignore

Why is the ignore even needed? We do this on other places without an issue:
https://github.com/pydata/xarray/blob/b1392d03d5081c04b8188f4a92a8d4a95fea1b51/xarray/core/npcompat.py#L42-L45

@Illviljan Maybe because this one here is in try/except?

I'll have a look how this resolved, since I've copied that in #5959.

I suppose the try/except is the issue. I think the If-check seems clearer, since we then know when to remove it.

(tbc, no strong view on the exact form here — I merged just so we had a clean branch — very happy to anyone to make any other changes)


FR: high scores

Keep a log of the top 5 high sores. Users can submit a name for the leaderboard if they rank on it. Max characters for the user name should be 10.

I'd like to work on this together. We did such a great job of adding a high score to python-hangman. This might be more complex but im looking forward to it adding a competitive element to the game


Holograms can't be created in the first second with extreme hologram limit values (GetInt bug)

Because an E2's code on a local server or singleplayer game is already immediately available when the E2 is created, the code immediately starts running as soon as the expression exists in the world. However, the function holoCreate waits until the minimum amount of time has passed (after Uploading has disappared from the toolgun screen) before doing anything.
This can lead to cases where if you have an E2 that uses an iterator on an interval/tick to create holos, any holograms created in the first second are never created.
To reproduce: After starting either a singleplayer game or a local server, use this expression 2 code: (edited)
if(clk()){ #second execution
    holoCreate(2)
    print(holoEntity(2),holoEntity(2):pos())
}else{ #first execution
    interval(1000)
    holoCreate(1)
    print(holoEntity(1),holoEntity(1):pos())
    entity():setPos(entity():toWorld(vec(0,0,30))) # set pos upward after the first hologram tries to create. Visibly leaves the hologram behind on multiplayer.
}

It should print the first holo's pos [0,0,0] immediately as the toolgun fires (a null entity), and then the second holo's pos after 1 second. (correctly created)
Lowering the interval below one second, puts the second hologram below the minimum time threshold for code uploading, and then you'll have both holograms print pos [0,0,0].
Trying this on a multiplayer server works correctly, as the first hologram is created when the e2 is finished uploading and runs, as does the second hologram after 1 second.

Because an E2's code on a local server or singleplayer game is already immediately available when the E2 is created, the code immediately starts running as soon as the expression exists in the world.

How exactly is this different from what happens on a server?
I can't reproduce you behavior in single player, local server, or on a dedi. In the past I remember the holo position not updating immediately, however I can't reproduce that now and can't think of a reason it would occur.

It's different because when an E2 is created by the toolgun, the server will wait until your client finishes uploading the code to the server before running. In singleplayer the E2 runs immediately after being created with the toolgun.
Updated code: print(holoEntity(1)) instead of using the interger to prove that the holo entity simply doesn't exist.
https://youtu.be/IdeNAnW5nkc
Alternatively, try the code I used in finding the bug in the first place: (using the navmesh extension and a high hologram burst amount & delay)
@persist N:array I
if(first()){
    runOnTick(1)
    N=navmeshes()
    printTable(N)
}else{
    I++
    holoCreate(I,N[I,navmesh]:navCenter(),vec(5))
}

It'll skip creating holograms for the first second's worth of ticks, then create size 5 holograms at the center of the nav areas normally.

Both of these work just fine for me on both single player, local server, and dedi

It's different because when an E2 is created by the toolgun, the server will wait until your client finishes uploading the code to the server before running. In singleplayer the E2 runs immediately after being created with the toolgun.

This still doesn't make sense cause it still doesn't start running until after the code is received and compiled. The conditions are all the same.

Bigdog does your E2 turn red when you put it down, before coloring itself normal? Mine doesn't. Only on multiplayer

No it doesn't, it's the same as yours. And as I explained it doesn't matter when the code runs, it doesn't affect the holograms in any way. Could you try reinstalling and turning off/disabling workshop/legacy addons.

In progress:
Disable all workshop addons except for Wiremod
Delete /lua from garrysmod folder, verify game integrity.
Launch with -noaddons, leave off -noworkshop as I'm intending to use the workshop version of Wiremod.

Yep, it's still happening

Ok so holoCanCreate returns 0 until the e2 finishes uploading, gonna look at that

Found it
I had wire_holograms_burst_amount set to an absurd value<PHONE_NUMBER>99)
Bringing it down to 1000 fixes it

So it was just a bad convar?


bridges: Added Ko-Fi.com bridge

I created a bridge for the ko-fi.com website
It brings the latest 10 posts and only their first paragraph.
This can be tested at http://rssbridge.walkero.gr/ if you would like to have a look.

cool


Speed up CI workflows

This patch adds GitHub Actions steps for caching. For example, rust-cache action sets CARGO_INCREMENTAL: 0 to disable incremental compilation.
ref: Fast Rust Builds - https://matklad.github.io/2021/09/04/fast-rust-builds.html

I resolved a merge conflict.

Thanks!


Adding debug target on Makefile, fixing leaderElection and imageConfi…

…gFile reference

What this PR does:
This PR adds the make debug directive, which allows developers to attach the debugger to delve locally in port 2345.
It also fixes the config files for the manager and container images, to correctly load the default operator config, and allow for properly downloading the cassandra container images.
Which issue(s) this PR fixes:
Fixes #610
Checklist

[ ] Changes manually tested
[ ] Automated Tests added/updated
[ ] Documentation added/updated
[ ] CHANGELOG.md updated (not required for documentation PRs)
[ ] CLA Signed:  DataStax CLA

Hey, slipped a bit under my radar. The debug targets in Makefile are alright, but the config changes are not. The /configs is the intended default location and we want to keep leaderElection enabled by default.


Add target option to run checks for specifics images

#270 Usage in CI/CD image pipelines
#286 Running checks for a specific container or image

is this option removed? I'm not able to scan specific image or container.

Hi @kumarchatla, -i and -x now checks both images and containers.
https://github.com/docker/docker-bench-security/commit/c53157e184135eb037df28005e04747f8748d907