Doesn't work with final releases of Xcode 8 and Swift 3

Hi, the cocoapod version is pointing to swift 2.2, pull the master branch should work

It turns out there's indeed some problem, give me 5 mins to fix it.

The problem is due to Data.length is renamed to Data.count in Foundation. Fixed now

Could you please push the latest tag to the cocoapod's trunk?. Thank you!

Also, I try using the repo url, but Xcode still complains about it:
Swift Compiler Error Group
YSMessagePack/Sources/operators.swift:11:18: Expected '{' after operator name in 'operator' declaration
YSMessagePack/Sources/operators.swift:12:19: Expected '{' after operator name in 'operator' declaration
YSMessagePack/Sources/operators.swift:25:23: 'inout' must appear before the parameter name
YSMessagePack/Sources/operators.swift:31:24: 'inout' must appear before the parameter name
YSMessagePack/Sources/pack.swift:48:61: 'inout' must appear before the parameter name
YSMessagePack/Sources/parse.swift:29:123: 'inout' must appear before the parameter name
YSMessagePack/Sources/unpack.swift:78:91: 'inout' must appear before the parameter name
YSMessagePack/Sources/unpack.swift:98:89: 'inout' must appear before the parameter name
YSMessagePack/Sources/unpack.swift:125:65: Expected type
YSMessagePack/Sources/unpack.swift:125:65: Expected ',' separator
YSMessagePack/Sources/unpack.swift:150:150: 'inout' must appear before the parameter name
YSMessagePack/Sources/unpack.swift:366:114: Unknown attribute 'escaping'
YSMessagePack/Sources/unpack.swift:366:159: Expected type
YSMessagePack/Sources/unpack.swift:366:159: Expected ',' separator
YSMessagePack/Sources/unpack.swift:389:107: Unknown attribute 'escaping'
YSMessagePack/Sources/misc.swift:129:27: Use of undeclared type 'Error'
YSMessagePack/Sources/misc.swift:135:29: Use of undeclared type 'Error'
YSMessagePack/Sources/misc.swift:129:13: Type 'PackingError' does not conform to protocol 'RawRepresentable'
YSMessagePack/Sources/misc.swift:135:13: Type 'UnpackingError' does not conform to protocol 'RawRepresentable'
YSMessagePack/Sources/misc.swift:194:34: Thrown expression type 'UnpackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/NSDataCasters.swift:79:53: 'Encoding' is not a member type of 'String'
YSMessagePack/Sources/NSDataCasters.swift:90:58: 'Encoding' is not a member type of 'String'
YSMessagePack/Sources/NSDataCasters.swift:42:43: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/NSDataCasters.swift:49:43: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/NSDataCasters.swift:56:43: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/NSDataCasters.swift:63:46: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/NSDataCasters.swift:70:46: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/NSDataCasters.swift:85:61: Use of unresolved identifier 'Data'
YSMessagePack/Sources/NSDataCasters.swift:96:56: Use of unresolved identifier 'Data'
YSMessagePack/Sources/NSDataCasters.swift:100:21: Value of type 'UnsafePointer<Void>' (aka 'UnsafePointer<()>') has no member 'assumingMemoryBound'
YSMessagePack/Sources/NSDataCasters.swift:110:43: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/operators.swift:15:13: Operator implementation without matching operator declaration
YSMessagePack/Sources/operators.swift:25:13: Operator implementation without matching operator declaration
YSMessagePack/Sources/operators.swift:21:13: Operator implementation without matching operator declaration
YSMessagePack/Sources/operators.swift:31:13: Operator implementation without matching operator declaration
YSMessagePack/Sources/operators.swift:17:5: Value of type 'NSMutableData' has no member 'append'
YSMessagePack/Sources/operators.swift:22:5: Value of type 'NSMutableData' has no member 'append'
YSMessagePack/Sources/operators.swift:27:5: Value of type 'NSMutableData' has no member 'append'
YSMessagePack/Sources/operators.swift:33:5: Value of type 'NSMutableData' has no member 'append'
YSMessagePack/Sources/operators.swift:34:9: Cannot assign to value: 'lhs' is a 'let' constant
YSMessagePack/Sources/pack.swift:157:45: 'Encoding' is not a member type of 'StringLiteralType' (aka 'String')
YSMessagePack/Sources/pack.swift:40:13: Extraneous argument label 'item:' in call
YSMessagePack/Sources/pack.swift:51:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:60:42: Cannot pass immutable value as inout argument: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:66:30: 'Encoding' is not a member type of 'String'
YSMessagePack/Sources/pack.swift:87:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:91:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:94:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:97:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:100:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:103:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:106:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:109:19: Left side of mutating operator isn't mutable: 'byteArray' is a 'let' constant
YSMessagePack/Sources/pack.swift:162:35: Use of unresolved identifier 'repeatElement'
YSMessagePack/Sources/pack.swift:186:45: Thrown expression type 'PackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/pack.swift:192:32: Thrown expression type 'PackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/pack.swift:264:50: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/pack.swift:491:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/pack.swift:492:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/pack.swift:545:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/pack.swift:547:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/pack.swift:594:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/pack.swift:646:13: Argument labels '(item:, appendToBytes:)' do not match any available overloads
YSMessagePack/Sources/parse.swift:15:93: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/parse.swift:24:97: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/parse.swift:45:77: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/parse.swift:46:77: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/parse.swift:47:77: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/parse.swift:145:39: Thrown expression type 'UnpackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/parse.swift:159:38: Thrown expression type 'UnpackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/unpack.swift:23:123: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:37:126: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:60:134: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:82:9: Value of type 'ByteArray' (aka 'Array<UInt8>') has no member 'removeSubrange'
YSMessagePack/Sources/unpack.swift:84:146: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:104:9: Value of type 'ByteArray' (aka 'Array<UInt8>') has no member 'removeSubrange'
YSMessagePack/Sources/unpack.swift:106:150: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:112:18: 'stride(from:to:by:)' is unavailable: call the 'stride(to:by:)' method instead
YSMessagePack/Sources/unpack.swift:139:150: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:170:78: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/unpack.swift:171:78: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/unpack.swift:172:78: Use of unresolved identifier 'MemoryLayout'
YSMessagePack/Sources/unpack.swift:284:117: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:291:117: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:305:115: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:311:115: '&' used with non-inout argument of type 'Int'
YSMessagePack/Sources/unpack.swift:314:43: Thrown expression type 'UnpackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/unpack.swift:353:42: Thrown expression type 'UnpackingError' does not conform to 'ErrorType'
YSMessagePack/Sources/unpack.swift:359:13: Cannot assign to value: 'len' is a 'let' constant
YSMessagePack/Sources/unpack.swift:368:21: Use of unresolved identifier 'DispatchQueue'
YSMessagePack/Sources/unpack.swift:391:9: Use of unresolved identifier 'DispatchQueue'
YSMessagePack/Sources/unpack.swift:199:52: Thrown expression type 'PackingError' does not conform to 'ErrorType'

It looks like you are using swift2.3 (By seeing "unresolved identifier 'MemoryLayout'"), or either cocoa pod is porting it as swift2.3.
I really want to push to cocoapods' trunk. But so far I'm experiencing problem that I cannot install cocoapod on my MacBook Air after updated to Sierra. I'll do it ASAP sorry about that.

@nebiros  After hours and hours fighting with cocoapods, the cocoapods is finally synchronized with GitHub tag, point YSMessagePack to tag 1.6.2 should work now.


Set drainage and infiltration to NA for basins coupled to MODFLOW

Fixes https://github.com/Deltares/Ribasim/issues/1073

This is currently failing on Ribasim allowing NaN/missing in basin.time but not basin.static.


Fix component lifecycle

This is closing #1097
As mentioned in the issue I would like to combine this issue with tests for lifecycle management.

I don't understand why I closed this one month ago. We should merge this and create a separate issue for creating lifecycle tests.

@Mergifyio backport humble
@Mergifyio backport iron

@Mergifyio backport iron


Refactor signature text and highlight total costs

Solves #620

 Small modifications for the offer layout #620

Solves #620


MAP_READY event not getting fired, when getMyLocation does not work

I'm submitting a ...  (check one with "x")

[ ] question
[x ] any problem or bug report
[ ] feature request

If you choose 'problem or bug report', please select OS:  (check one with "x")

[x ] Android
[ ] iOS

cordova information:  (run $> cordova plugin list)
cordova-plugin-compat 1.0.0 "Compat"
cordova-plugin-dialogs 2.0.1 "Notification"
cordova-plugin-facebook4 1.9.1 "Facebook Connect"
cordova-plugin-geolocation-android-activator 1.1.2 "Location Activator Cordova P
lugin"
cordova-plugin-googlemaps 2.3.6 "cordova-plugin-googlemaps"
cordova-plugin-googleplus 5.3.0 "Google SignIn"
cordova-plugin-whitelist 1.3.3 "Whitelist"

If you use @ionic-native/google-maps, please tell the package.json (only @ionic-native/core and @ionic-native/google-maps are fine mostly)
Current behavior:

Sometimes when getMyLocation could not get device location, it is not returning back after timeout (10 seconds). In such situation if I try creating map with following code
"
service.googleMapService.map = plugin.google.maps.Map.getMap(mapDivElem);
var map = service.googleMapService.map;
map.addEventListener(plugin.google.maps.event.MAP_READY, function()
{
alert("Map ready!");
callback();
});
"
MAP_READY event is not getting fired.
So the main issue is that, the function plugin.google.maps.LocationService.getMyLocation() is not returning back after timeout ({timeout:5000, enableHighAccuracy:true}), when it can not find the location.
Also not sure, why sometimes, getMyLocation() is failing to get the device's current location.
Am I the only one, who faces this issue with this plugin?
geoLocComplaint.txt
Expected behavior:

Screen capture or video record:

Related code, data or error log (please format your code or data):
The person who share your project files on Github (or other git repository) is in faster lane than other people.
Please share your project files on Github or others(Bitbucket, Gitlabs...etc).
If you don't want to share your project files, please create a demo project, then share it.

Screen captures, and/or native logs(such as Logcat, xcode logs) are appreciate.

Giving much information, you are waiting time is less.
Thank you for your cooperation.

Please share the project files that reproduce your issue 100% onto GitHub.

ping

Hi this issue is not reproducible everytime. I noticed that getMyLocation is not getting current location only when I am inside my office workarea. When I go out it is working. Also just I noticed that no other apps such as google map, uber could find the current location in my mobile.
I checked google map app on the other phone, it is showing the exact place. The problem happens with Redmi mobile only.
And my worry is that, why the the error function is not getting called after timeout, This makes the plugin not to work, when I try to show the map, thus not displaying map at all.
I have shared the file yesterday with two functions in it (which I use).
Were you able to test whether the timeout behaviour of the app actually work?
I do not think I can provide you the source that reproduce the issue 100%, as I face this issue only on Redmi mobile.
If you need, I will try to create a sample project and provide you.
All I would like to know is, has anybody checked if timeout actually works when app is unable to find current position. because when timeout is not working, it makes whole plugin's functions not to work.

If you don't satisfy this plugin behavior, please use othet plugins, such as cordova-geolocation-plugin.


Revert "fixed S3 bucket options merge error"

Reverts owen2345/camaleon-cms#872

@owen2345 something is wrong?

There were errors on CI and it was the reason.


Stages not working

When using --stage=??? to apply command, it seems to be ignored.
➜  realist-gordon gordon apply --stage=prod
Applying project...
  0001_p.json (cloudformation)
    ✓ No updates are to be performed.
  0002_pr_r.json (custom)
    ✓ code/contrib_lambdas_version.zip (2a16cb60)
    ✓ code/api_faqslist.zip (995f9a9f)
  0003_r.json (cloudformation)
    UPDATE_COMPLETE_CLEANUP_IN_PROGRESS waiting... |
Project Outputs:
  LambdaApiFaqslist
    arn:aws:lambda:us-east-1:xxxxxxxxx:function:dev-realist-gordon-r-ApiFaqslist-1S4WC563WH6W9:current
  ApigatewayReaslistapi
    https://45ry8uwz9l.execute-api.us-east-1.amazonaws.com/dev
➜  realist-gordon

Hello @jatsrt that's unexpected...  it looks like the --stage=prod park is not making it into gordon somehow... and it is using the default dev stage. You can try to run $ gordon apply --stage=proc --debug to get information about the context that gordon is passing from one template to another.

I want to know the stage in my code's context, so add a parameter/context of Stage
Collision with --stage
Remove and works

Interesting... that sounds like a bug to me! gordon should (at least) shout with a warning about the collision...
The second interesting thing is that I should make available (in an easy way) the stage of the lambda so it can be pass as context.
Will take note and fix it somehow


Fix examples

Currently, there are a lot of examples that failed cozy, which is a regression. See commented ones in test_examples.sh.

[ ] ztopo-cache
[ ] nonscalar-tuple
[ ] sat4j-literal-storage
[ ] docstring
[ ] openfire-roster
[ ] redmine
[ ] argmin
[ ] rot1

What is going wrong in each case?
A few notes about what to expect:
The case study ones (ztopo-cache, openfire-roster, and sat4j-literal-storage) make references to the projects they belong to and therefore must be compiled by their projects' respective build systems, with all the other project files in place. They are in the examples folder as examples, not as tests, and will not work without a lot more infrastructure.
Some of the new ones (nonscalar-tuple and redmine, maybe) use features that have never been supported, like collections inside of other types like tuples or collections. These aren't really regressions, more like examples that exercise not-yet-implemented functionality.

I see, I think we can have different levels of expectation:

level 1: don't crash cozy
level 2: don't crash compiler
level 3: can be executed
level 4: functionality validated

currently all examples not commented out can reach level 2, and with a proper driver program like MaxBagMain.java, it might reach level 4.
I think we can be super flexible here, but I think clarifying this in a CI-backed way would be helpful to users.

What is going wrong in each case?

I will detail the problem of each case in separate issues in coming days


Ensure jax.jit static_argnums is refactored to static_argnames

Functions that currently mark static_argnums=(0, 1, 2) should be updated to use the safer static_argnames=('tom', 'dick', 'harry') that is now available.

Closed by #19


Details page on the right side - removable

Describe the feature you'd like
Hello!
Is it possible to make the details page when u are on a page removable?
Describe the benefits this would bring to existing BookStack users
Better reading with more space
Can the goal of this request already be achieved via other means?
No
Have you searched for an existing open/closed issue?

[X] I have searched for existing issues and none cover my fundemental request

How long have you been using BookStack?
0 to 6 months
Additional context
No response

Hi @SwiftRedline,
This is not something I'd support as an interface option but the following should hide the "Details" section of a page, when added to the "Custom HTML Head Content" customization setting:
<style>
#page-details {
    display: none;
}
</style>

This is not an officially supported customization, so could break upon future updates.


Performance comparison with rc-field-form?

Is there a performance comparison chart?

Sry there won't be a performance comparison chart. This lib is just for combining ant design form with react hook form. It's not about performance.


fix: typo in master_template and correct MP21ZD options

as discussed in https://github.com/zwave-js/node-zwave-js/pull/2905#issuecomment-989975974

TODO: include https://github.com/zwave-js/node-zwave-js/issues/3901


meteoruser to control app deployed with MUP

Hi,
it's not a proper issue, maybe I'm doing something wrong. I'm trying to remotely control my app deployed with MUP and using child_process 'exec' command which by default uses 'meteoruser' (didn't succeeded to change that).
I added meteoruser to sudo group in order to get initctl access but even with that and adding in Upstart.conf the sudo group I can't get anything else than status option. To modify I'm stuck ("start: You do not have permission to modify job" [jobname]...) and it looks like this thread :
http://askubuntu.com/questions/229809/allow-non-sudo-group-to-control-upstart-job
So maybe it is because the conf deployed by mup is in /etc/init but do you think there would be a workaround for that?
Thanks for your help!

I found a workaround using a subshell but I still wonder if this is not caused by the use of [userdown] API


Flux throwing error about deprecations and Seccomp

Trying to update the version of Zarf in DI2-ME, and Flux is throwing an error and restarting, which is causing the booting up of Big Bang to fail
Zarf version: 0.19.4
Flux version: 3 different versions tried, all with the same errors (The Flux kustomization in Big Bang v1.28.0, 1.33.0, and 1.36.0)
K8s version: v1.23.6+k3s1 (from the zarf-builtin K3s)

Pod log
root@ip-172-31-87-202:~/zarf-package-software-factory/build# kubectl logs helm-controller-568967f974-xr8rn -n flux-system --previous
{"level":"info","ts":"2022-06-17T03:18:26.082Z","logger":"controller-runtime.metrics","msg":"Metrics server is starting to listen","addr":":8080"}
{"level":"info","ts":"2022-06-17T03:18:26.082Z","logger":"setup","msg":"starting manager"}
{"level":"info","ts":"2022-06-17T03:18:26.083Z","msg":"Starting server","kind":"health probe","addr":"[::]:9440"}
{"level":"info","ts":"2022-06-17T03:18:26.083Z","msg":"Starting server","path":"/metrics","kind":"metrics","addr":"[::]:8080"}
I0617 03:18:26.184212       7 leaderelection.go:248] attempting to acquire leader lease flux-system/helm-controller-leader-election...
I0617 03:18:26.189658       7 leaderelection.go:258] successfully acquired lease flux-system/helm-controller-leader-election
{"level":"info","ts":"2022-06-17T03:18:26.189Z","logger":"controller.helmrelease","msg":"Starting EventSource","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","source":"kind source: *v2beta1.HelmRelease"}
{"level":"info","ts":"2022-06-17T03:18:26.189Z","logger":"controller.helmrelease","msg":"Starting EventSource","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","source":"kind source: *v1beta2.HelmChart"}
{"level":"info","ts":"2022-06-17T03:18:26.189Z","logger":"controller.helmrelease","msg":"Starting Controller","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease"}
{"level":"info","ts":"2022-06-17T03:18:26.290Z","logger":"controller.helmrelease","msg":"Starting workers","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","worker count":4}
{"level":"info","ts":"2022-06-17T03:18:55.428Z","logger":"controller.helmrelease","msg":"HelmChart 'bigbang/bigbang-bigbang' is not ready","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"bigbang","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:18:55.431Z","logger":"controller.helmrelease","msg":"reconcilation finished in 14.405509ms, next run in 10m0s","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"bigbang","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:19:02.890Z","logger":"controller.helmrelease","msg":"could not find optional Secret 'bigbang/terraform'","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"bigbang","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:19:05.178Z","logger":"controller.helmrelease","msg":"HelmChart 'bigbang/bigbang-gatekeeper' is not ready","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"gatekeeper","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:19:05.183Z","logger":"controller.helmrelease","msg":"reconcilation finished in 72.448922ms, next run in 5m0s","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"gatekeeper","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:19:05.202Z","logger":"controller.helmrelease","msg":"reconcilation finished in 2.413942608s, next run in 10m0s","reconciler group":"helm.toolkit.fluxcd.io","reconciler kind":"HelmRelease","name":"bigbang","namespace":"bigbang"}
{"level":"info","ts":"2022-06-17T03:19:09.697Z","logger":"KubeAPIWarningLogger","msg":"policy/v1beta1 PodSecurityPolicy is deprecated in v1.21+, unavailable in v1.25+"}
{"level":"info","ts":"2022-06-17T03:19:16.336Z","logger":"KubeAPIWarningLogger","msg":"spec.template.metadata.annotations[container.seccomp.security.alpha.kubernetes.io/manager]: deprecated since v1.19, non-functional in v1.25+; use the \"seccompProfile\" field instead"}
E0617 03:19:57.615831       7 leaderelection.go:367] Failed to update lock: Put "https://<IP_ADDRESS>:443/apis/coordination.k8s.io/v1/namespaces/flux-system/leases/helm-controller-leader-election": context deadline exceeded
I0617 03:19:57.615893       7 leaderelection.go:283] failed to renew lease flux-system/helm-controller-leader-election: timed out waiting for the condition
{"level":"error","ts":"2022-06-17T03:20:27.624Z","logger":"setup","msg":"problem running manager","error":"leader election lost"}

The Big Bang Gatekeeper HelmRelease fails with error Helm upgrade failed: another operation (install/upgrade/rollback) is in progress. It happens right after the Flux pods restart after they throw the above error.

@RothAndrew I ran into this when I wasn't giving my BB package enough resources on just a normal deployment. At first the gatekeeper helm-release simply errored out saying max retries hit, I tried increasing the number of retries and reconciling the gatekeeper helm-release but then eded up seeing the Helm upgrade failed: another operation (install/upgrade/rollback) is in progress error instead.
If this is something that's blocking you at the moment I was told that removing the gatekeeper-system-gatkeeper.v1 secret and having flux reconcile the HR again will get it unstuck. Credits to @blancharda
k delete secret -n bigbang sh.helm.release.v1.gatekeeper-system-gatekeeper.v1

flux reconcile hr -n bigbang gatekeeper

Thanks 😄 Will need to figure out the root cause though if I want to get this zarf package working without manual intervention.

Making my own K3s Zarf package using the code from Zarf v0.17.0 and using that instead of the builtin k3s completely solved the issue. So I think that narrows it down to an incompatibility in the K3s version, the K8s version, or the configuration of K3s.
@jeff-mccoy how do you feel about rolling back the K3s version we're using? This is blocking me from upgrading the Zarf version in DI2-ME, unless I stick with my own K3s package

@RothAndrew I ran into this when I wasn't giving my BB package enough resources on just a normal deployment. At first the gatekeeper helm-release simply errored out saying max retries hit, I tried increasing the number of retries and reconciling the gatekeeper helm-release but then eded up seeing the Helm upgrade failed: another operation (install/upgrade/rollback) is in progress error instead.
If this is something that's blocking you at the moment I was told that removing the gatekeeper-system-gatkeeper.v1 secret and having flux reconcile the HR again will get it unstuck. Credits to @blancharda
k delete secret -n bigbang sh.helm.release.v1.gatekeeper-system-gatekeeper.v1

flux reconcile hr -n bigbang gatekeeper

I also find flux can conflict with CRDs in Big Bang upstream and often the remedy is a reinstallation/upgrade of flux.
If you have the luxury on the cluster to do some troubleshooting, this is usually my order of operations.
flux suspend hr -n bigbang bigbang
flux uninstall hr gatekeeper -n gatekeeper-system
flux resume hr -n bigbang bigbang

If that continues to be unsuccessful take a look at some of the events inside namespaces (monitoring/istio-system/etc.
kubectl get events -n bigbang
# looking for helm release errors which often help pin down a breaking change item.

....this may or may not help.
This script upgrades flux is quite handy.

@anoncam thanks, that's helpful.
Do you know what the resolution of this is so that the error won't happen in the first place? Is it to upgrade flux past where even Big Bang has it in the base/flux folder?

My need is to be able to get the full deployment up and running with no human intervention. I'm able to do a lot in a Zarf package but adding kubectl commands as after: scripts is definitely not ideal

I think an init container prior to reconciliation to remove all the CRDs from previous HRs would be an interesting way to clean the environment prior to reattempting.  For Big Bang Monitoring, for instance: honorLabels: true required a torching of all the monitoring CRDs and then re-reconciling BB with flux.

Gathering more data now:

Trying latest version of Kind (k8s v1.24.0)
Will try a version of Kind that gets as close as possible to the version of K3s we're using (v1.23.6)
Will try latest version of upstream k3s
Will try latest version of upstream flux against current k3s

@YrrepNoj didnt you deploy the latest zarf + bb core on eks today? What versions were those?

Latest version of Kind that uses k8s v1.24.0 worked successfully. This issue did not occur

Zarf: v0.19.4
k8s: 1.22
BB: 1.33.0

kind create cluster --image "kindest/v1.23.6 worked successfully. The issue did not occur.

K3s v1.24.1+k3s1 using this zarf package worked successfully. The issue did not occur.

Sounds like this is the winner? Just upgrade the version of K3s to latest? I'll test a couple more times to make sure it wasn't a fluke.

Reconfirmed the issue still happens on the builtin k3s

Reconfirmed the issue doesn't happen on the latest version of k3s


ResponseCachingMiddleware is logging a warning on valid HEAD responses

Steps to reproduce the behavior:

Using this version of ASP.NET Core: '2.2'
Create a controller action with HttpHead attribute
Return content length header but no body
See warning The response could not be cached for this request because the 'Content-Length' did not match the body length., logged by Microsoft.AspNetCore.ResponseCaching.ResponseCachingMiddleware

As described in MDN it is correct to return the Content-Length header without a body:
https://developer.mozilla.org/en-US/docs/Web/HTTP/Methods/HEAD

A response to a HEAD method should not have a body. If so, it must be ignored. Even so, entity headers describing the content of the body, like Content-Length may be included in the response. They don't relate to the body of the HEAD response, which should be empty, but to the body of similar request using the GET method would have returned as a response.

Is there any good reason why ResponseCachingMiddleware is logging this warning on HTTP HEAD requests? https://github.com/aspnet/AspNetCore/blob/3c0fb1a3f8609aae3165d43cb61fed10d9e1bf4f/src/Middleware/ResponseCaching/src/ResponseCachingMiddleware.cs#L372

I don't think there's an intentional reason we are logging that warning. You are correct that it doesn't seem appropriate to log it on a HEAD request since there is intentionally no body. I think we could add an else if branch to this that avoids the warning if and only if Method == HEAD && Body.Length == 0 && ContentLength != 0, since that's the case allowed by the spec.
Thoughts @Tratcher @davidfowl ?

Hi Andrew,
I had a look at this and the issue is not the warning per se.
I believe the middleware should not skip the caching in this scenario, as the response is still valid to be cached similar to a HEAD with no Content-Length.
I'm working on a PR for this right now.
Thanks,
Alessio

That was fast. Thanks @alefranz 👍

Thanks @alefranz for the fix!


oorzaak 4000  (problem seems to be related to the proximus DNS see Issue #89)

Hi, I'm a beta tester and when I open the app i got an error message.
OORZAAK: 4000
Er is iets fout gegaan.
Error during web request, http status 901
In attach the screenshots of the detail of the error message.
I'm using an Samsung S8 plus running and Android Version 9. G955FXXSADTI1
The version of Coronalert is 1.6.0
My girlfriend has the same problem on an Samsung S10 running android Version 10. G970FXXU8DTH7
Kind regards
Koen Deschepper

Had the same issue on two devices:
A one plus 6 running android 10. The issue got resolved after switching to 4g instead of wifi.
A samsung galaxy s10e running android. Switching to 4g didn't help.

The problem has been resolved in the mean time. Thanks for reporting!


Fix certificate errors when accessing koji-hub

During a build, koji-hub is accessed from outside the
default network created by docker-compose. For this reason
the hostname "koji-hub" does not resolve as expected. The
alternative is to access koji-hub by its IP address, which
has worked in the past. However, due to newer koji versions
certificate verification is stronger, requiring the IP address
to also be list in koji-hub's identity certificate.
For simplicity the special IP address <IP_ADDRESS> is used for
certificate generation. This IP has shown to be consistent
across different hosts (container registry is already accessed
this way).

Hard coding of <IP_ADDRESS> will be addressed by https://github.com/lcarva/osbs-box/issues/63.


Handle function extensions and don't double encode

Adds support for passing function as handlers for extensions
Fixes double encoding of extension messages

Looks great @RangerMauve. Merging

1.0.3

Yay! Gonna be nice to showcase this in my workshop today. 😁


Multiple issues / feature requests

Overall - I (LOVE) this module and it does make a solid installer package. Thank you!
Maybe it's just my ignorance, but the -Platform option doesn't have any effect on the target path when I use ProgramFilesFolder. It always installs to \Program Files (x86). Is there a way to install to \Program Files or even a custom location?
On Windows 11, the  -NewInstallerShortcut doesn't seem to have any effect after installation. No shortcut appears on Start, Taskbar or Desktop. Maybe I'm misunderstanding that?
The documentation markdown shows -Product, but the function expects -ProductId or -ProductName (ambiguous).

Glad you're digging it!

Maybe it's just my ignorance, but the -Platform option doesn't have any effect on the target path when I use ProgramFilesFolder. It always installs to \Program Files (x86). Is there a way to install to \Program Files or even a custom location?

Not really sure why this is the case but seems like it's a bug.

On Windows 11, the -NewInstallerShortcut doesn't seem to have any effect after installation. No shortcut appears on Start, Taskbar or Desktop. Maybe I'm misunderstanding that?

Interesting. I haven't actually done this in a while so maybe it broke with Win11.

The documentation markdown shows -Product, but the function expects -ProductId or -ProductName (ambiguous).

Just fixed this.

Thank you for the fast reply!  I also think it might be a misunderstanding on my part with where to "nest" the New-InstallerDirectory items and New-InstallerShortcut within the New-Installer -Content script block.  I may have things in the wrong place?  Here's an example...
`[CmdletBinding()]
param (
[parameter()][string]$ProductName = "My Application",
[parameter()][string]$ShortName = "MyApp",
[parameter()][string]$Version = "1.0.0",
[parameter()][guid]$UpgradeCode = '44de2fbc-3027-4f46-8b6b-ef9fddb328ad',
[parameter()][string]$Publisher = "Dave",
[parameter()][string]$SourcePath = "d:\labsources\pkg\source",
[parameter()][string]$IconPath = "D:\sources\pslabs.ico",
[parameter()][string]$OutputFolder = "d:\labsources\pkg\output",
[parameter()][string]$AboutURL = "https://github.com/skatterbrainz/powershell-labs"
)
Import-Module psmsi
New-Installer -ProductName $ProductName -Manufacturer $Publisher -UpgradeCode $UpgradeCode -Content {
New-InstallerDirectory -PredefinedDirectory "LocalAppDataFolder" -Content {
New-InstallerDirectory -DirectoryName $ShortName -Id "main" -Content {
Get-ChildItem -Path $SourcePath -Filter "." |
Where {$.Attributes -ne 'Directory'} |
Foreach { New-InstallerFile -Source $.FullName -id $($.BaseName -replace '-','') }
}
New-InstallerDirectory -PredefinedDirectory "DesktopFolder" -Content {
New-InstallerShortcut -Name $ShortName -FileId "README" -IconPath $IconPath
}
}
} -OutputDirectory $OutputFolder -Version $Version -Platform x64 -AddRemoveProgramsIcon $IconPath -AboutLink $AboutURL
`


Error logs hit when deleting VM (after stop/starting felix)

Repro scenario.  On Openstack Icehouse with calico:

create a VM on a host.
stop felix on that host
start felix on that host
delete the VM.

At the time of deletion, we get 8 errors in felix.log like this:
2015-09-30 15:40:06,016 [ERROR][31781/8] calico.felix.fiptables 569: Failed to delete chain felix-p-_a15fd76a273ef0d-o, giving up. Maybe it  is still referenced?
Readily reproducible at present on Master.

I believe I have diagnosed his issue.  It occurs whenever the final endpoint using a profile is deleted during the graceful restart window.  This issue is that

the IptablesUpdater recognises that the endpoint chain is still in use so it decides to stub it out
during the graceful restart window, it doesn't stub out chains that it knows already exist (this prevents us from stubbing out a "leaf" chain because we learned about the "branch" chain before the leaf).

The fix should be to stub out chains during the GR window iff they were explicitly deleted.


How to use other pretrained backbone?

How to change the backbone to any other pretrained backbone in timm.models?

You need to create a config.
https://github.com/rwightman/efficientdet-pytorch/blob/master/effdet/config/model_config.py#L118-L194


FGA 1556 Bluestacks Not Tapping On The Right Spot

Preparation

[X] I tested the latest release
[X] I looked at other issues (even the closed ones)
[X] I read the Troubleshooting Guide

FGO server
NA
FGA build number
1556
Describe the bug
The bot doesn't seem to tap on the right spot, it's tapping a lot higher than it's supposed to be on bluestacks 4, I've tried searching for the same issue but I can't really find one (maybe I just suck at searching or it's only happening to me)
Video
https://user-images.githubusercontent.com/62210258/144207148-64fede28-51fe-49fd-95f7-099152dbf249.mp4
Device model
Bluestacks 4 - Nougat 32-bit
Android version
7
Screen size
1920x1080
RAM
2GB

I recently switched to BlueStacks HyperV and reinstalled FGO/FGA from scratch today.  I'm experiencing similar behavior, although I am on build 1562.

I recently switched to BlueStacks HyperV and reinstalled FGO/FGA from scratch today. I'm experiencing similar behavior, although I am on build 1562.

I don't know if it's on purpose or not but after letting it tap on random servants profiles for a bit it started to work properly.

@Claey See the last question in the troubleshooting guide, it's normal.


Projects Plugin cleanup

Howdy! Found some time to cleanup the plugin I wrote a few months ago.

added pjo alias for pj open
cleaned up indentation to conform to editorconfig
added menu for identical project names condition (e.g. /projects/foobar  &&  /work/projects/foobar)
added more verbose error messages and handling

Thanks!


sitemap: hide hidden pages from sitemap

Discussed in https://github.com/McShelby/hugo-theme-relearn/discussions/68

Originally posted by jehoshua7 August 29, 2021
I have been using the following code to hide content
hidden = true
which works fine, yet I noticed the content still appears in the sitemap. Should the hidden feature extend to the sitemap ?
Ref - Sitemap template/ and  Means to exclude content from sitemap.xml #653

The sitemap has the same function as the menu itself: to discover content. therefore it should behave the same and hide all pages that are hidden and all pages below those pages.

I decided to have a new config parameter for this feature. disableSeoHiddenPages is false by default and causes hidden pages to show up on the sitemap.xml and in Google (and other search engines) search.


make sure that environment variables are used correctly

Already fixed by https://github.com/Jumpscale/jumpscale_core8/pull/252

are you sure that PR #252 fix the issue, as far as i can see, it will write the environment variables after pulling the repos ?

@ahussein nice catch

reviewed and tested.
the  #252 fixes both issues

@abdulrahmantkhalifa  I just tried to install js8 and tried to set the JSBRANCH env variable but the master branch was used anyhow!


ATT.Pitch became more and more big, vehicle position draft

ATT.Pitch  got big and big, from 0.025 to 0.1 almost in five minutes, the vehicle horizontal position draft more and more quickly , so any issure with my multicopter?
(software version: 1.5.5
hardware pixhawk)

Log
http://logs.uaventure.com/view/nwpou7XbSC97DMy226bfYU

Did you check if your compass is correctly pointing towards the magnetic North?

i haven't check it ... how can i  comfirm this issure caused by compass direction.?

Let me explain a bit: the attitude estimation and control look fine. The pitch reference is moving with the X position error. My guess is that your position controller is correcting in the wrong direction. (However, I'm surprised that it does not diverge faster and why it is only visible on one axis).
So, to verify this, just go outside and compare the heading displayed by QGC with the compass of your smartphone or with a known geographic reference.
And if you are sure that you can swith back to manual and pilot it manually, you can try to move the pitch stick of your remote to see if the quad position diverge (be careful to switch back quickly to manual). If you are not sure to be able to do this, don't try.

thanks a lot, i will check it before takeoff.

@liang-tang  Any news?

everything works well.


Add Ammonite script for generating mergify YAML

I tried to make this as simple as possible, the functions are very much like templated JSON.
The main purpose is to unfold the stable branches into the backport rules, as well as generate merging rules as well.
Because different repos have different stable branches and different CI, I made the script take a simple YAML file that will be customized per repo. We can customize this further if needed.
Example
FIRRTL Input:
conditions:
  - status-success=Travis CI - Pull Request
branches:
  - 1.2.x
  - 1.3.x
  - 1.4.x

Output:
pull_request_rules:
- name: automatic squash-and-merge on CI success and review
  conditions:
  - status-success=Travis CI - Pull Request
  - '#approved-reviews-by>=1'
  - '#changes-requested-reviews-by=0'
  - base=master
  - label="Please Merge"
  - label!="DO NOT MERGE"
  - label!="bp-conflict"
  actions:
    merge:
      method: squash
      strict: smart
      strict_method: merge
- name: backport to 1.4.x
  conditions:
  - merged
  - base=master
  - milestone=1.4.x
  actions:
    backport:
      branches:
      - 1.4.x
      ignore_conflicts: true
      label_conflicts: bp-conflict
    label:
      add:
      - Backported
- name: backport to 1.3.x, 1.4.x
  conditions:
  - merged
  - base=master
  - milestone=1.3.x
  actions:
    backport:
      branches:
      - 1.3.x
      - 1.4.x
      ignore_conflicts: true
      label_conflicts: bp-conflict
    label:
      add:
      - Backported
- name: backport to 1.2.x, 1.3.x, 1.4.x
  conditions:
  - merged
  - base=master
  - milestone=1.2.x
  actions:
    backport:
      branches:
      - 1.2.x
      - 1.3.x
      - 1.4.x
      ignore_conflicts: true
      label_conflicts: bp-conflict
    label:
      add:
      - Backported
- name: label Mergify backport PR
  conditions:
  - body~=This is an automated backport of pull request \#\d+ done by Mergify
  actions:
    label:
      add:
      - Backport
- name: automatic squash-and-mege of 1.2.x backport PRs
  conditions:
  - status-success=Travis CI - Pull Request
  - '#changes-requested-reviews-by=0'
  - base=1.2.x
  - label="Backport"
  - label!="DO NOT MERGE"
  - label!="bp-conflict"
  actions:
    merge:
      method: squash
      strict: smart
      strict_method: merge
- name: automatic squash-and-mege of 1.3.x backport PRs
  conditions:
  - status-success=Travis CI - Pull Request
  - '#changes-requested-reviews-by=0'
  - base=1.3.x
  - label="Backport"
  - label!="DO NOT MERGE"
  - label!="bp-conflict"
  actions:
    merge:
      method: squash
      strict: smart
      strict_method: merge
- name: automatic squash-and-mege of 1.4.x backport PRs
  conditions:
  - status-success=Travis CI - Pull Request
  - '#changes-requested-reviews-by=0'
  - base=1.4.x
  - label="Backport"
  - label!="DO NOT MERGE"
  - label!="bp-conflict"
  actions:
    merge:
      method: squash
      strict: smart
      strict_method: merge

Let's talk about this tomorrow.
I think chisel-release should be code/script free. Would have been good, if I had told you this earlier :-(
It should just be the repository for the gitmodules.
All code to manipulate this should be in chisel-repo-tools.
Not set in stone but, it can be very unwieldy to work on stuff because of the long-lived parallel branches.

I have moved this script into chisel-repo-tools in the scripts directory


style: include a more modern Lato font (Fixes: #591)

A modern version supports more non-Latin characters that started to appear in translations.
License to use & redistribute the font is granted at
https://github.com/latofonts/lato-source/blob/master/LICENSE.txt

Thanks for taking care of this!


Re-introduce the introduction to tBTC in README

I somehow lost this during the MD->AsciiDoc conversion of the README.
It doesn't look like AsciiDoc supports relative links(?), so I've made it absolute for now.

It doesn't look like AsciiDoc supports relative links

It should. I'll have a look today.

 Another option if the other file is asciidoc is to use the regular cross-reference syntax <<./path/thing.adoc,link text>>, or you can leave off the link text if you want it inferred (can't recall if that works for cross-file references).


Not Found match does not working with Nesting Route

Fallback not found route is a little bit confused with nest.
Example
<Switch>
  <Route path="/" nest>
    <AppPage>
      <Route path="/posts"><PostsView /></Route>
      <Route path="/posts/:postId"><PostDetailView /></Route>
    </AppPage>
  </Route>

  <Route path="/auth">
    <AuthPage />
  </Route>

  <Route>
    <NotFound />
  </Route>
</Switch>

'/' represents app page, <AppPage/> wraps nested views.
'/auth' represents unauthorized page, <AuthPage/> contains login form.
The last route fallback to a not found page (globally)

Unexpected

'/some-path-not-exist' didn't reach the not found page route
The nest '/' route caught every non-existing paths instead, even the path is not existing inside nesting.

Expected

Whether nest prop true of false, should maintain the same expectations
'/some-path-not-exist' path should match the fallback route - <NotFound /> if it's not being strictly matched inside nesting routes.

Suggestions
For example
<Switch>
  <Route path="/" nest>
    <Route path="settings" nest>

      <SettingsView>
        <Switch>

          <Route path="appearance">
            <AppearanceView />
          </Route>

          <Route>Not found - You may checkout /settings/appearance</Route>

        </Switch>
      </SettingsView>

    </Route>
  </Route>

  <Route>
    <NotFound />
  </Route>
</Switch>;

Would be better:

Match inside not found if '/settings/some-path-not-exist'
Match outside not found if '/some-path-not-exist'
'/settings/language' fallbacks to inside not found (<Route>Not found - You may checkout /settings/appearance</Route>)
'/set' fallbacks to outside

This feels more like an issue with your application structure and not so much with this lib.
 What you want is multi-level matching. React Router implemented something like this, but it comes at the drawback that all routes need to be defined beforehand.
wouter has a more simplistic approach. Switch evaluates each child with a path-prop, and renderes the first match. In this case your main route. If you restructure your examples like this they would work as you expect:
<Switch>
  <Route path="/auth">
    <AuthPage />
  </Route>

  <Route path="/posts" nest>
    <AppPage>
      <Route path="/"><PostsView /></Route>
      <Route path="/:postId"><PostDetailView /></Route>
    </AppPage>
  </Route>

  <Route>
    <NotFound />
  </Route>
</Switch>

<Switch>
    <Route path="/settings" nest>

      <SettingsView>
        <Switch>

          <Route path="/appearance">
            <AppearanceView />
          </Route>

          <Route>Not found - You may checkout /settings/appearance</Route>

        </Switch>
      </SettingsView>

    </Route>

  <Route>
    <NotFound />
  </Route>
</Switch>


Sub OUs not deploying as expected, failure at Prepare stage

Describe the bug
Creating SUB-OUs seems to fail.  Parent OU already exists.  Attempting to create sub-OUs under the parent OU.  As pictured in LZA config.
The following OUs were already deployed:
organizationalUnits:

name: Architecture
name: Security
name: Infrastructure
name: Sandbox
name: PlatformEngineering
name: PlatformEngineering/Prod
name: PlatformEngineering/Dev
name ResearchEngineering
name: ResearchEngineering/Prod
name: ResearchEngineering/Dev
name: ResearchEngineering/Colo
name: ResearchEngineering/Colo/Prod
name: ResearchEngineering/Colo/Dev
name: Vendor

Attempting to create:

name: Architecture/Prod
name: Architecture/Dev
name: Architecture/Sandbox

Pipeline stage failure: Prepare stage
To Reproduce
Steps to reproduce the behavior.
Deploy multiple OUs with sub OUs via LZA config.
Run LZA Pipeline and an error occurs.
Remove those same OUs and that solves the error but unable to deploy new sub-OUs
Expected behavior
The expected behavior is that new sub-OUs are deployed via the LZA config.  The code-pipeline is started and the OUs are deployed via the code-pipeline.
Please complete the following information about the solution:

[ ] Version: v1.9.1

To get the version of the solution, you can look at the description of the created AWS CloudFormation stack used to install the LZA (AWSAccelerator-InstallerStack). For example, "(SO0199) Landing Zone Accelerator on AWS. Version 1.5.1.". If the description does not contain the version information, you can look at the Parameters of the stack for the RepositoryBranchName as that should contain the version number.

[ ] Region: [eu-east-1]
[ ] Was the solution modified from the version published on this repository? No.
[ ] If the answer to the previous question was yes, are the changes available on GitHub?
[ ] Have you checked your service quotas for the services this solution uses? Yes.
[ ] Were there any errors in the CloudWatch Logs? Errors are in codepipeline, pictured below.

Screenshots
If applicable, add screenshots to help explain your problem (please DO NOT include sensitive information).

Additional context
Add any other context about the problem here.

We manually recreated the OUs and had the pipeline register them with control tower. Now we are getting the following error in the prepare stage...
2024-09-16 16:59:52.681 | info | index | The organization unit "Architecture/Sandbox" already exists in AWS Organizations, create organizational operation skipped.
2024-09-16 16:59:52.922 | info | index | The organizational unit "Architecture/Sandbox" is not registered into AWS Control Tower, it will be registered now.
2024-09-16 17:00:00.591 | info | index | Enabling baseline for "Organizational Unit "Sandbox" with id "ou-yyax-*****mz7" for parent "Architecture". Baseline version is "4.0" and baseline identifier is "arn:aws:controltower:eu-west-1::baseline/17BSJV3IGJ2*****".
2024-09-16 17:00:01.182 | error | runner | This baseline is already enabled on this target. To resolve any enablement failures or drift, call ResetEnabledBaseline. To update the baseline version or parameters, call UpdateEnabledBaseline.
ValidationException: This baseline is already enabled on this target. To resolve any enablement failures or drift, call ResetEnabledBaseline. To update the baseline version or parameters, call UpdateEnabledBaseline.
    at de_ValidationExceptionRes (/codebuild/output/src1540/src/s3/00/source/node_modules/@aws-sdk/client-controltower/dist-cjs/index.js:1298:21)
    at de_CommandError (/codebuild/output/src1540/src/s3/00/source/node_modules/@aws-sdk/client-controltower/dist-cjs/index.js:1192:19)
    at processTicksAndRejections (node:internal/process/task_queues:95:5)
    at async /codebuild/output/src1540/src/s3/00/source/node_modules/@smithy/middleware-serde/dist-cjs/index.js:35:20
    at async /codebuild/output/src1540/src/s3/00/source/node_modules/@smithy/core/dist-cjs/index.js:165:18
    at async /codebuild/output/src1540/src/s3/00/source/node_modules/@smithy/middleware-retry/dist-cjs/index.js:320:38
    at async /codebuild/output/src1540/src/s3/00/source/node_modules/@aws-sdk/client-controltower/node_modules/@aws-sdk/middleware-logger/dist-cjs/index.js:33:22 {
  '$fault': 'client',
  '$metadata': {
    httpStatusCode: 400,
    requestId: 'c5387b70-7932-46ba-a27c-c8f2a39f1322',
    extendedRequestId: undefined,
    cfId: undefined,
    attempts: 1,
    totalRetryDelay: 0
  },
  level: 'error',
  mainLabel: 'accelerator',
  [Symbol(level)]: 'error'
}
error Command failed with exit code 1.


Propose syntax-sugar for referring to tasks in other crates

I have a workspace with many crates. As part of the packaging process, I'd like to copy some files (html templates) between them. This copy stage depends on some preprocessing defined in src/web/Makefile.toml. In the root Makefile.toml I am having to create a dummy task that changes directory and runs the target I want.
src/web/Makefile.toml
[tasks.yarn]
command = "yarn"

[tasks.css]
command = "yarn"
args = ["build"]
dependencies = ["yarn"]

[tasks.dist]
command = "cp"
args = ["-a", "static/.", "dist/"]
dependencies = ["css"]

Makefile.toml
[tasks.web-dist]
cwd = "src/web"
command = "cargo"
args = ["make", "dist"]

[tasks.web-release]
cwd = "src"
command = "cp"
args = ["-r", "web/dist", "application/dist"]
dependencies = ["web-dist"]

The combined result of which is:

compile the css
copy it into dist along with the static files
copy the files into the application crate

My question: there is a little boilerplate task here, would it be an idea to provide some sugar and allow me to define a dependency as follows instead?:

[tasks.web-release]
cwd = "src"
command = "cp"
args = ["-r", "web/dist", "application/dist"]
dependencies = ["web:dist"]

web:dist could either be a path or a crate in the workspace, and it refers to the dist task inside the Makefile there.

Interesting idea.
What if it was an object instead?
dependencies  = [ { cwd = "src/web", name = "dist", fork = true }, { name = "some-local-task" } ]

which would trigger a sub cargo make process (as you did manually)?
The fork would always be true, but if i'm making it an object now, i need to think of future support for other things.
does it make sense?

Yeah that could work, while making "some-local-task" and { name = "some-local-task" } equal. If you give some pointers I'd be happy to take a crack at it once we think about it a little more.

@arlyon if you want create a PR (always happy to get help) here are the pointers i can give:

types.rs - update the task and platform task structs to have dependencies instead of vec of strings, a vec of enum of either string or a new type that can have those fields. I do stuff like that a LOT in that file so you have many examples.
execution_plan.rs - when you loop over dependencies, if you come up with a fork one, create a task in runtime instead of pulling a task from the read toml file. give the task some name like 'forked_dependency' or something....
that runtime created task should have command->cargo args->make, all needed stuff, task name from obj, cwd-> from obj
i have create_proxy_task or something in the runner.js that can be used... it knows to automatically put in the command line all the needed args that you put in the original invocation. which is very important.
tests
examples
docs - content.md/nav.md as readme.md is generated from those via cargo make generate-docs

if you feel its too much, its ok. just tell me and i'll take it.

Cool, I had a go at the first bit. Expect a PR soon :)

@arlyon i was manually testing this one and i found a bug there when the path specifies a file name as well (i was actually testing the cross-file.toml you created).
I think the issue is that you take the full path as directory path and do not split the filename from it
let mut proxy_task = create_proxy_task(&proxy_name, true, false);
proxy_task.cwd = Some(path.to_owned());

what i think you wanted to do is check that path and than if its a dir than ok, if its a file to break it down to path to put in cwd and filename to put in the cargo make args list.
would you like to take care of it or should I fix it?

i would also add a test for both scenarios to make sure the generated proxy task is as we wanted it to be.

Hey! Yes it seems I missed that case, I thought that that was covered since the example I wrote worked but that was in the same directory. I'll get a patch up asap

@arlyon are you taking care of this one or you prefer me to fix it?

Hey, I've been working on this but its a bit more complex than I had initially thought regarding paths and things.

i can take a look as well.

Yes, that would be helpful. This next few days are quite busy with work wrapping up before the holidays and I understand it's kind-of time sensitive. Thank you (and sorry)!

@arlyon fixed it. you can look at the relevant commit if you are interested.

released


Cache parallel_runtime_rspec.log

Provide a detailed description of the proposed feature
The parallel tests gem we're using groups tests better based on test runtime. If this file is cached between runs and jobs then our parellisation should be more efficient.
What is the motivation for the feature?
Speeding up test runtime using documented behaviour.
How will the feature be relevant to at least 90% of Homebrew users?
It will not be.
What alternatives to the feature have been considered?
The status quo.

Hi, I'm new to HomeBrew open source and wishes to contribute in it by working on this issue. Can someone give me a heads up upon this.

Please go ahead and work on it, @Manav-Kumar. You may find this guide helpful: https://docs.brew.sh/How-To-Open-a-Homebrew-Pull-Request
Thanks!

@MikeMcQuaid
Can we solve this issue by adding the two below?
1 --runtime-log option to parallel_args  in dev-cmd/tests.rb
2. parallel tests log path for cache to .github/tests.yml

@hyuraku Yes, that sounds right!


restore zoom

Right now, I have this setting "editor.mouseWheelZoom": true, which enables me to zoom only the editor and not the explorer, but there isn't a way to restore the zoom unless I go to the command palette and type >Editor Font Zoom Reset
Since in order to manipulate the zoom what I do is CTRL + MOUSEWHEELMOVE,  I would like to suggest the use of CTRL + MOUSEWHEELCLICK to restore it

In my VSCode 32bit version Win7 Ultimate,
I use   "  ctrl + -  " for zoomout and "  ctrl + + " for zooming in;
I think editing in json only effects the editor , i.e. whatever you type in json it only applies for editor part.

@tymsai what you are doing with those keybindings is zooming in/out the whole window (editor, explorer, icons, tabs, etc) and that zoom can be reset by doing CTRL + 0
There's an option in settings, Editor: Mouse Wheel Zoom. I you check that ("editor.mouseWheelZoom": true) you can zoom only the editor without afecting the rest of the window.
But there isn't a shortcut to reset that zoom, hence my proposal

I think #3130 could solve this.

Let's track in #3130


Issue with Latest versions for aws amplify

Hello,
I tried running this app with latest versions of aws amplify. 1.0.4. I encountered following issues.

Greetings do not update after login.
even when logged in if we go to the login page it shows login form for brief seconds before showing After login component.

hey @yalamber yes Amplify 1.0.0 is a breaking update. I will look into this later. Thank you!

Hey @yalamber sorry for the long delay. FYI I am updating the tutorial with Amplify 1.1. Authentication part is finished. With help of Hub it is actually much simpler for getting notified by login action.

The whole tutorial is rewritten


Nuke CARGO_* env variables for nested cargo

I hit this in https://github.com/EmbarkStudios/rust-gpu/pull/291 and did a quick fix with my Try workaround on CI... commit and was intending on doing the proper fix if that passed, but mergify got happy and did its thing. So, filing this issue so we remember to do the proper fix.
Not sure if we should nuke all CARGO_* env variables, we should look through the list and figure out which ones to keep, but generally yeah.
More explanation on how this causes things to go wrong can be found in that link to the glam PR in https://github.com/EmbarkStudios/rust-gpu/pull/291

I have a fix for this on the vuild-system branch, by just removing all env variables and putting PATH back in.

clearing all environment variables sounds incorrect, there's potentially really important variables configuring things, right?

clearing all environment variables sounds incorrect, there's potentially really important variables configuring things, right?

Well I should be clear, all except the ones we set. So we're still passing arguments and RUSTFLAGS to configure cargo. It is working for me on all the runners, and fixed the clippy issue for me.

I don't think it's a good idea to remove more than CARGO_FEATURES_* and CARGO_CFG_* (which we know the nested Cargo will set whichever are appropriate - also, AFAICT there are no other Cargo env vars that have dynamic names like that).
It might work in isolation, but when taking into account all OSes and Linux distros, and whatever build scripts might be running for dependencies of shaders, etc. I don't see it always working, and it's safer to only remove the problematic sets.


Create ToDo_MVC

For training purposes....

Is this a mistake?

yes it is. I'm clicking around... dangerously so it seems.


Add "updates to geo filters" blog post

Preview: http://website.mlab-sandbox.measurementlab.net/
To be published after https://github.com/m-lab/etl-schema/pull/123

This change is

@stephen-soltesz Thanks! Updated.
Made comment on #692


Hourly Forecast Temps Wonky

This is something I noticed last night and I'm seeing it again tonight. I'm assuming that this is an HRRR issue and not a pirateweather issue and if so then feel free to close.
Anyway I've noticed that the hourly temps seem to fluctuate overnight for seemingly no reason. Here's what pirateweather is showing for my location currently:

Here's Environment Canada's hourly forecast for comparison:

Not shown in the screenshot was HRRR forecasting a temp of -7 at 8pm. No idea why it's saying that 11pm is going to be the coolest part of the night when usually around 6am is the coldest part of the night.

Definitely was a HRRR issue as now everything looks normal now.

Since I'm pretty confident that this was a HRRR issue and not a PW issue since the issue seemed to solve itself last night I'm going to close this topic. There's not much you can do on your end to fix the issue outside of adding in NBM which isn't the priority at the moment.

Even though your gut feel here was right (it was an HRRR issue), thanks for opening this issue! It's always helpful to keep track of issues and limitations with HRRR to see where it's doing well and where it needs work. NBM is still on tap for the new year, so I haven't forgotten about it ☀

It seems to have at least sorted itself out better the last few days so it's not as bad as the example I showed last week. I know HRRR is being replaced by RRFS sometime next year so maybe that will be any better? It has a NA 3km domain which is similar to the domain offered by RAP so that'll be nice.

I know I've brought this up before but one thing HRRR struggles at times is precipitation. I haven't found a global source of radar but the closest thing I could find is this API from RainViewer. The only downside is that everything is in image files and you'd have to do a bunch of conversions in order to get it to be in a usable file format.
This from EUMETSTAT while not global might still be useful to cover areas outside of NA which aren't covered by RainViewer?


Added 404 handler

Fixes: https://github.com/oVirt/ovirt-web-ui/issues/631

Added 404 error handler
Refactor error boundary

If page doesn't exists:

If VM doesn't exists:

ci test please

ci test please

LGTM

If I try to show https://my_vm/ovirt-engine/web-ui/disk the page is blank, same goes if I try anything else supposedly non-existent, however if I use https://my_vm/ovirt-engine/web-ui/pools, the handler works.

@isaranova - Good catch!  This only happens in a normal deployment through the war file.  We would never hit it running the dev server.
@bond95 - Take a look at the web.xml.  Probably need to change the URL mappings: https://github.com/oVirt/ovirt-web-ui/blob/857c4c22fcd009783dfd7d62a8fee03a0d2274ac/packaging/ovirt-web-ui.war/WEB-INF/web.xml#L87-L95

LGTM


Charts - Support for multiple data series support and dual Y axes

Is your feature request related to a problem? Please describe.
I need to be able to add multiple data series on the same line or bar chart, and assign each of them to either the left or the right Y axis.
Describe the solution you'd like
Being able to add multiple data series on the same line or bar chart, and assign each of them to either the left or the right Y axis.
Describe alternatives you've considered
So far I've been sticking to Community Edition and exporting data to excel. I would upgrade without hesitation if dbeaver had powerful enough charts support. I work a lot with time series, and need to plot graphs of up to 10,000+ data points.
Additional context
I'm also struggling with lack of readability and configurability of labels and colors on charts.
Units support would also be amazing.
Many thanks for your consideration

Thank you for the idea!


Types

Before continuing, it would be good to figure out how to implement types. Should be easy... post some notes in here if necessary.

Good enough for now. Will add more later.


make: in CI, copy binaries from "bin/downloaded" to "bin/tools"

This is to work around the fact that binaries in hostPath-mounted directories cannot be executed even if the permissions are correct.
I also fixed how tool versions are handled when switching across branches. Previously, if you were switching back and forth between two versions of Go or Kind, the second time would not work. Thanks @munnerz for raising this issue in https://github.com/jetstack/testing/pull/651.
I also propose to remove all the env vars (HELM, COSIGN, CMREL, YQ, KUBECTL, KIND, CRANE, CLIENT_GEN, CONVERSION_GEN, CONTROLLER_GEN, DEEPCOPY_GEN, DEFAULTER_GEN, INFORMER_GEN, LISTER_GEN) since it makes it a bit clearer using e.g. bin/tools/yq as both the binary path and a prerequisite.
For example, in the following example, we are referring to cosign in two different ways: bin/tools/cosign and $(COSIGN):
bin/SHA256SUMS.sig: bin/SHA256SUMS bin/tools/cosign
	$(COSIGN) sign-blob --key $(COSIGN_KEY) $< > $@

A clearer way is to use bin/tools/cosign in both cases:
bin/SHA256SUMS.sig: bin/SHA256SUMS bin/tools/cosign
	bin/tools/cosign sign-blob --key $(COSIGN_KEY) $< > $@

/kind cleanup
NONE

/hold

I see it's got past the setup stage now, so presumably the latest change works 👍🏼
/lgtm

/unhold

This PR breaks signing helm charts:
https://github.com/cert-manager/cert-manager/pull/4988/files#diff-7fad63ce343e43adef92cb03937db29d2f40b2c1d8c0b0de84735176ec697bf2L61-R61
The CMREL variable which was removed because it wasn't used anywhere did not resolve to bin/tools/cmrel, it resolved to $(PWD)/bin/tools/cmrel which was a full absolute path. That means that cd $(dir $<) && $(CMREL) worked fine but cd $(dir $<) && bin/tools/cmrel doesn't because the path has changed.


file_write_as_test, stream_from_iterable_test don't finish, fail testing on iso-stress bot

iso-stress testing seems to fail with two tests not finishing, perhaps getting stuck:
from iso-stress log
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/lib_2/async/stream_from_iterable_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/lib_2/async/stream_from_iterable_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/lib_2/async/stream_from_iterable_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/lib_2/async/stream_from_iterable_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/standalone_2/io/file_write_as_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/standalone_2/io/file_write_as_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/standalone_2/io/file_write_as_test.dart] starting ...
[/b/s/w/ir/cache/builder/sdk/runtime/tests/concurrency/../../../tests/standalone_2/io/file_write_as_test.dart] starting ...
=> Running "out/ReleaseTSANX64/dart --disable-dart-dev -Drepeat=4 -Dshard=187 -Dshards=200 --no-sound-null-safety --enable-isolate-groups runtime/tests/concurrency/generated_stress_test.dart.jit.dill" failed with -9

With stream_from_iterable_test removed https://logs.chromium.org/logs/dart/buildbucket/cr-buildbucket.appspot.com/8840959064476822304/+/u/Run_Isolate_Stress_Tests_shard_9/task_stdout_stderr:_Run_Isolate_Stress_Tests_shard_9 shows another hanging build now with just file_write_as_test.dart starting, not finished.

Thanks, @aam!
Guess this issue was addressed now.


Add dark theme

fix #54

Codecov Report

:exclamation: No coverage uploaded for pull request base (master@91c5197). Click here to learn what that means.
The diff coverage is n/a.

@@            Coverage Diff            @@
##             master      #57   +/-   ##
=========================================
  Coverage          ?   73.27%
=========================================
  Files             ?      521
  Lines             ?    11792
  Branches          ?        0
=========================================
  Hits              ?     8640
  Misses            ?     2891
  Partials          ?      261

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 91c5197...6f7e2e9. Read the comment docs.


Updated README.md - added Solidity, EVM Resource

Added Link to -> Solidity, Ethereum Virtual Machine, Hardhat, ethers.js, Damn Vulnerable Defi Part1 and Part 2

Fixes Issue

Changes proposed

Screenshots

Note to reviewers

I'm not sure if this should be added as it seems to be covering too many different technologies.

It covers Solidity and EVM in depth by step by step through documentation, other topics can be optional to opt out not.

@prathamesh2525 Please think about it from a totally newbie's perspective. Giving them tons of technologies all at once is going to confuse them a lot rather than making them understand. Please feel free to open a PR with individual resources instead of a all-in-one

Yeah I totally agree with you. Maybe It can be added to the intermediate level.


improve loading screen

The screen will now show a loading icon instead of text if the table is loading

Pull Request Test Coverage Report for Build 270

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 82.979%

Totals

Change from base Build 268:
0.0%

Covered Lines:
91

Relevant Lines:
99

💛  - Coveralls


HTTP status 409 Conflict Prometheus to Thanos Receiver Metrics

Hello All,
I have built an integration between Prometheus and Thanos Receiver. This is through the Open Telemetry Collector. Below is the part of ConfigMap in Open Telemetry Collector.
otel-collector-config.yaml: |-
receivers:
prometheus:
config:
scrape_configs:

job_name: "otel-collector-monitoring-1"
scrape_interval: 5s
honor_labels: true
metrics_path: '/federate'
params:
'match[]':
'{job=~".+"}'
static_configs:
targets:
'prometheus-k8s:9090'
exporters:
prometheus:
endpoint: "<IP_ADDRESS>:8889"
metric_expiration: 180m
prometheusremotewrite:
endpoint: http://host.minikube.internal:32200/api/v1/receive

I see the metrics correctly landing in Thanos-Receiver. But Open Telemetry Collector keeps throwing continuously this error:
What could be the reason for same? and also the fix?
2022-09-27T09:42:23.200Z error exporterhelper/queued_retry.go:183 Exporting failed. The error is not retryable. Dropping data. {"kind": "exporter", "data_type": "metrics", "name": "prometheusremotewrite", "error": "Permanent error: Permanent error: remote write returned HTTP status 409 Conflict; err = %!w(): store locally for endpoint thanos-receive-default-0.thanos-receive-default.thanos.svc.cluster.local:10901: conflict\n", "dropped_items": 91}
go.opentelemetry.io/collector/exporter/exporterhelper.(*retrySender).send
go.opentelemetry.io/collector@v0.56.0/exporter/exporterhelper/queued_retry.go:183
go.opentelemetry.io/collector/exporter/exporterhelper.(*metricsSenderWithObservability).send
go.opentelemetry.io/collector@v0.56.0/exporter/exporterhelper/metrics.go:132
go.opentelemetry.io/collector/exporter/exporterhelper.(*queuedRetrySender).start.func1
go.opentelemetry.io/collector@v0.56.0/exporter/exporterhelper/queued_retry_inmemory.go:119
go.opentelemetry.io/collector/exporter/exporterhelper/internal.consumerFunc.consume
go.opentelemetry.io/collector@v0.56.0/exporter/exporterhelper/internal/bounded_memory_queue.go:82
go.opentelemetry.io/collector/exporter/exporterhelper/internal.(*boundedMemoryQueue).StartConsumers.func2
go.opentelemetry.io/collector@v0.56.0/exporter/exporterhelper/internal/bounded_memory_queue.go:69

Hi, I am experiencing the same situation here, but just when traffic is high.
Did it ever get resolved or any clues of some configuration that can fix that?

Hey folks,
Have you tried exporting to Prometheus as well? Could you post your full collector configurations?
I vaguely remember there are some related issues on the exporter in OTEL repo, this could be potentially bug where the data is not being exported correctly or could be also misconfiguration (especially in case you have multiple collector instances).
Related issue https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/11438

sure,
---
receivers:
  kafka:
    brokers:
    - kafka:9092
    topic: otlp_metrics-sink-id-222
    protocol_version: 2.0.0
extensions:
  pprof:
    endpoint: <IP_ADDRESS>:1888
  basicauth/exporter:
    client_auth:
      username: <<user>
      password: <<pass>
exporters:
  prometheusremotewrite:
    endpoint: <<endpoint>>
    auth:
      authenticator: basicauth/exporter
  logging:
    verbosity: detailed
    sampling_initial: 5
    sampling_thereafter: 50
service:
  extensions:
  - pprof
  - basicauth/exporter
  pipelines:
    metrics:
      receivers:
      - kafka
      exporters:
      - prometheusremotewrite

This is a new scenario for us, we didn't have any issues running through a Mimir. but we faced this in thanos.
The load is a bit higher than from the mimir scenario as well.
Thanks @matej-g

Hey @lpegoraro,
Thanks for providing that extra info.
What is your receiver setup? Are you using replication? Do you see all your data as expected or are some data points missing? (Feel free to post your receiver config as well).
It could be that in such case the 409 is benign. It can signal that your receiver instances already have this data, and so it refuses to write it. This could happen in a scenario with high load and replication.

am also facing the same issue

This is generally not a problem, it often happens when agents retry sending samples. Unless data is missing, the error can be ignored.

how can add an option to ignore?

I was also facing the same issue when ingesting metrics using OTel collector prometheusremotewrite exporter. The culprit seems to be the target_info metrics which are enabled by default. Sometime these target info metrics have some labels without any value (mostly net_host_port) which causes 409 conflict error on the thanos side.
The issue got fixed when I disabled the target_info metrics from OTel side.
exporters:
  prometheusremotewrite:
    target_info:
      enabled: false

Ok, i can also confirm that the disable of "target_info" does not solves the issue

It solved  the problem on my side
On Mon, 6 May 2024, 18:58 Fabien Lenoir, @.***> wrote:

Ok, i can also confirm that the disable of "target_info" does not solves
the issue
—
Reply to this email directly, view it on GitHub
https://github.com/thanos-io/thanos/issues/5732#issuecomment-2096388047,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIQH7IM2WSENYA6TWEPIWJDZA6SD5AVCNFSM6AAAAAAQWTPZ5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGM4DQMBUG4
.
You are receiving this because you commented.Message ID:
@.***>

hi @kimpetertanui , how did you managed to solve it ?

I added below to my otel collector. target_info  section is what I was
missing
exporters:
prometheusremotewrite:
target_info:
enabled: false
On Mon, 6 May 2024, 19:04 Fabien Lenoir, @.***> wrote:

hi @kimpetertanui https://github.com/kimpetertanui , how did you
managed to solve it ?
—
Reply to this email directly, view it on GitHub
https://github.com/thanos-io/thanos/issues/5732#issuecomment-2096398193,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AIQH7IIY567ULY53FTRNLE3ZA6SXXAVCNFSM6AAAAAAQWTPZ5SVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDAOJWGM4TQMJZGM
.
You are receiving this because you were mentioned.Message ID:
@.***>

I notice that errors are limited to 3 or 4 each time. On Thanos receiver side, there's 4 replicas. Would it be possible that there's a missing setting on thanos that would explain that the remote write tries to write 4 times same metrics at the same time, which would explain this conflict ?

We have similar set-up and even though we've disabled target_info we still receive a lot of 409 Conflicts as well as Out of Order responses... not quite sure what can be done here as receiver does not have many options to control it's behaviour - do you think if I'd deploy kafka in front of a receiver that would help with "out of order" issues and 409's ?

I think there may be a relation with thanos receiver replicas and replication factor. How many replicas of pod receiver do you have ? what is the replication factor ?

@flenoir currently we do have 3 replicas of receiver and replicationfactor = 2 on receiver & receiver distributor.

The best way I know you can debug this is by changing the log level of the receiver from info to debug. Then you should be able to see what is causing the conflict. For e.g. here is a sample log that I was seeing
Labels with empty name in the label set" lset="labels:<name:"__name__" value:"target_info" > labels:<name:"http_scheme" value:"http" > labels:<name:"instance" value:"instance-xyz" > labels:<name:"job" value:"demo-job" > labels:<name:"net_host_name" value:"host-xyz" > labels:<name:"net_host_port" >
If you look closely the last label net_host_port doesn't have a value like other labels.

Hi @Ygshvr
I am facing this issue and noticed it is due to the same label net_host_port sometimes does not have value. Do you know how to handle this?

ts=2024-12-26T18:11:39.774638327Z caller=writer.go:129 level=debug component=receive component=receive-writer tenant=default-tenant
msg="Labels with empty name in the label set"
lset="labels:<name:\"__name__\" value:\"http_server_duration_milliseconds_bucket\" >
labels:<name:\"cluster\" value:\"o11y-stag-eu-west-1\" >
labels:<name:\"from\" value:\"otel-collector\" >
labels:<name:\"http_flavor\" value:\"1.1\" >
labels:<name:\"http_method\" value:\"PUT\" >
labels:<name:\"http_route\" value:\"/oauth-providers-internal/:domainUuid/:oauthUuid\" >
labels:<name:\"http_scheme\" value:\"http\" >
labels:<name:\"http_status_code\" value:\"200\" >
labels:<name:\"instance\" value:\"002d6d03-214f-4667-bca2-64a642e16d42\" >
labels:<name:\"job\" value:\"ccaas/auth\" >
labels:<name:\"le\" value:\"50\" >
labels:<name:\"net_host_name\" value:\"localhost\" >
labels:<name:\"net_host_port\" > "


Improved help experience

In this pull request all issues listed in ticket #113
Mainly:

Splitting up our massive README.md file into separate pages per topic, i.e. installation, getting started, etc.

Updated the generate_docs() function to mirror the splitting up of our README onto the documentation website. All changes inside the /docs folder are related to this.

Various improvements to generate_docs() documentation website output, mainly much more usable "Commands" page and translation of GitHub alert tags:

[!IMPORTANT]
This is an important message

Added special README--PYPI.md for PyPI with all internal links translated to absolute links linking to docs website (TO BE TESTED ON NEXT UPDATE)

Support for querying command categories in the CLI, eg. ? molecule working set or mws ? will get you:

About your Molecule Working Set
-------------------------------
Your molecule working set (MWS) is an in-memory list of small molecules that is the subject of your calculations and manipulations.

The MWS makes it easy to gather candidate molecules from various sources, either by adding them individually, by loading them in batch from a
dataframe, CSV or SDF file, or by bookmarking molecules in the GUI. You can then calculate certain properties, perform triage and then store
the results in your workspace as a molecule set, ready for further processing within OpenAD or elsewhere.

Please note that at this time the MWS does not support macromolecules, only small molecules.

Molecule Working Set Commands
-----------------------------
add molecule|mol <name> | <smiles> | <inchi> | <inchikey> | <cid> [ as '<name>' ] [ basic ] [ force ]
remove molecule|mol <name> | <smiles> | <inchi> | <inchikey> | <cid> [ force ]
list molecules|mols
show molecules|mols
enrich molecules|mols with analysis
clear analysis cache
display sources <name> | <smiles> | <inchi> | <inchikey> | <cid>
rename molecule|mol <molecule_identifer_string> as <molecule_name>
load molecules|mols from file '<filename.molset.json|sdf|csv|smi>' [ enrich ] [ append ]
load molecules|mols from dataframe <dataframe> [ enrich ] [ append ]
merge molecules|mols data from dataframe <dataframe> [ enrich ]
export molecules|mols [ as '<filename.molset.json|sdf|csv|smi>' ]
clear molecules|mols [ force ]

Cleaned up some inconsistencies and typos in the model commands help

Item 6 "Cleaned up some inconsistencies and typos in the model commands help" Actually will break the Model Services Model for handling shell commands for Users with special characters or executing from Shell. Also the Clause Naming changes will mean the Tell Me Functions will get confused.
Please remove all changes to model services and To Do Statements in code areas an resubmit with the standard Lint , as any modules changed are coming up as significantly changed and hard to review.


Avoid comparing buttons when there is guaranteed to be no difference

Reduces allocations when moving the mouse with no buttons pressed.
Before:

After:

I've fixed this via copy in the ButtonInput ctor (and removed the linq in there for safety) but will block to double-check allocations. Pretty sure we're in the clear, though.

Unblocking, still looks fine.

Note that I didn't check allocs while pressing buttons, but if that's an issue (potential ImmutableArray allocs) it's better addressed in a later PR. My focus so far has only been on no input or move-only.

I've changed one code path to use ImmutableArray.Create():
[Benchmark]
public ImmutableArray<int> ArrayToImmutable() => new[] { 1, 2, 3 }.ToImmutableArray();

[Benchmark]
public ImmutableArray<int> CreateImmutable() => ImmutableArray.Create(1, 2, 3);

|           Method |       Mean |     Error |    StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|----------------- |-----------:|----------:|----------:|-------:|------:|------:|----------:|
| ArrayToImmutable | 126.481 ns | 1.0339 ns | 0.9671 ns | 0.0608 |     - |     - |      80 B |
|  CreateImmutable |   6.272 ns | 0.0284 ns | 0.0252 ns | 0.0305 |     - |     - |      40 B |

We need to be really careful about this stuff, because it's super easy to say we're saving allocations but causing overall performance regressions. ImmutableArray is still very new to me so I've got a while to go in figuring out best practices / performance characteristics.
For example. I think we'll eventually want to have ButtonStateDifference store ImmutableArrays so that ButtonInput can then construct a builder using the exact length of differences and significantly improve performance even more:
[Benchmark]
public ImmutableArray<int> ListThenToImmutable()
{
    var list = new List<int>();

    for (int i = 0; i < 10; i++)
        list.Add(i);

    return list.ToImmutableArray();
}

[Benchmark]
public ImmutableArray<int> ImmutableBuilder()
{
    var builder = ImmutableArray.CreateBuilder<int>(10);

    for (int i = 0; i < 10; i++)
        builder.Add(i);

    return builder.MoveToImmutable();
}

|              Method |      Mean |    Error |   StdDev |  Gen 0 | Gen 1 | Gen 2 | Allocated |
|-------------------- |----------:|---------:|---------:|-------:|------:|------:|----------:|
| ListThenToImmutable | 172.33 ns | 1.538 ns | 1.438 ns | 0.2196 |     - |     - |     288 B |
|    ImmutableBuilder |  32.80 ns | 0.139 ns | 0.123 ns | 0.0732 |     - |     - |      96 B |

Yep, definitely. My goal was to get allocs down to close-to-zero then do a performance pass afterwards. It's hard to cover all bases at once.

I don't think you're going to get much from a post-mortem sampling, just because the amount we're seeing here is in the range of nanoseconds. But when you add 100ns to 20 different places, suddenly you've got a very diverse call stack that increases runtime by 0.2ms, which by itself is going to be in the 0% range of an entire game.
That's why I'd advocate for profiling performance (even if just via benchmarks) as these changes get made instead.

I'll be testing on an empty game, should still be easy to notice such tiny issues by isolating everything else away.


Add array-contains operator

Add array-contains as an operator to the Query#where method.

@schmidt-sebastian I don't have permissions to add you as a reviewer to this PR. Can you add yourself?