alternative led configuration us

for us 3 gan:
  - platform: partition
    name: "LEDs Button right"
    id: leds_button_right
    internal: true
    segments:
      - id: leds
        from: 6
        to: 7
      - id: leds
        from: 16
        to: 17
  - platform: partition
    name: "LEDs Button middle"
    id: leds_button_middle
    internal: true
    segments:
      - id: leds
        from: 3
        to: 4
      - id: leds
        from: 19
        to: 20
  - platform: partition
    name: "LEDs Button left"
    id: leds_button_left
    internal: true
    segments:
      - id: leds
        from: 0
        to: 1
      - id: leds
        from: 22
        to: 23

for 4 gang 4:
- platform: partition
    name: "LEDs Button l4"
    id: leds_button_l4
    internal: true
    segments:
      - id: leds
        from: 7
        to: 8
      - id: leds
        from: 15
        to: 16
  - platform: partition
    name: "LEDs Button l3"
    id: leds_button_l3
    internal: true
    segments:
      - id: leds
        from: 5
        to: 6
      - id: leds
        from: 17
        to: 18
  - platform: partition
    name: "LEDs Button l2"
    id: leds_button_l2
    internal: true
    segments:
      - id: leds
        from: 1
        to: 2
      - id: leds
        from: 21
        to: 22
  - platform: partition
    name: "LEDs Button l1"
    id: leds_button_l1
    internal: true
    segments:
      - id: leds
        from: 0
        to: 0
      - id: leds
        from: 23
        to: 24
      - id: leds
        from: 31
        to: 31

On the 3-gang (US) version, the difference you are proposing it to use the LEDs 16 and 17 instead of 17 and 18 currently in use for Relay 3 - Left.
https://github.com/edwardtfn/TX-Ultimate-Easy/blob/ae87f025a33d7c036ec29895ac6e986da6a6576e/ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml#L642-L648

And for the 4-gang (US) version you are proposing to use 2-LED per relay instead of 1-LED per relay on the current implementation.
https://github.com/edwardtfn/TX-Ultimate-Easy/blob/ae87f025a33d7c036ec29895ac6e986da6a6576e/ESPHome/TX-Ultimate-Easy-ESPHome_core_hw_leds.yaml#L656-L711

Ok, forget my comments about the 4-Gang model... After applying the changes I could see the issue with the previous mapping.

Could you please update your system and try again?


couldnt able to refresh this tabs in on the same page

Describe the bug
A clear and concise description of what the bug is.
To Reproduce
Steps to reproduce the behavior:

Go to '...'
Click on '....'
Scroll down to '....'
See error

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.
Desktop (please complete the following information):

OS: [e.g. iOS]
Browser [e.g. chrome, safari]
Version [e.g. 22]

Smartphone (please complete the following information):

Device: [e.g. iPhone6]
OS: [e.g. iOS8.1]
Browser [e.g. stock browser, safari]
Version [e.g. 22]

Additional context
Add any other context about the problem here.

@SGokulakrishnan what type of report is this? behave!


Likeable contract problem

the likeable contract for models return always false when checking
if (! $model instanceof Likeable && ! $model instanceof Liking)
in CanLike.php isLiking() function.

It seems like it brings problems with that after this specific PR: https://github.com/rennokki/befriended/pull/35
Someone noticed https://github.com/rennokki/befriended/pull/29 and i did the same with the other two (Block & Like) and it seems like they are broken, but the follow contract not.
I'm looking forward to fix this.

@lukadriel7, did you use the contract and the trait specified in the documentation?


Remove inactive mailing lists

closes #65

reopening

@urvishp80 I mentioned the need for "Today in History" section in generate_homepage_xml.py but you also restored the new links in

generate_weekly_newsletter_json.py
push_summary_to_es.py
xmls_generator_production.py

why is that?

@kouloumos We can drop these two inactive URLs from xmls_generator_production.py and  push_summary_to_es.py  file as we are sure that there won't be any new documents from the given two mailing lists in the future.
And for generate_weekly_newsletter_json.py and generate_homepage_xml.py we need to keep them as we are using it for "Ongoing Discussions" and "Today in History/Active Posts" respectively.


Hi - I need some help to understand how solution layers work for Choices. I have added Choices to my solution using a managed solution and made some changes outside the managed solution. Doing so, I expected to see an unmanaged layer which I can then remove if needed. But I don't see the unmanaged layer when I check solution layers.     I do see managed solutions listed here in case the same option set is extended from another managed solutions.     Happy to add any screenshots if it helps.

Basically Unmanaged layer is not getting created for Choices in the Solution after editing the choices field that is part of managed solution

@sandeep-mamidala We do not provide support here. We can point you to existing documentation or answer questions about the documentation.
See Solution layers for information about solution layers.


Support for Ubuntu 18.04 Bionic Beaver

Hello,
After a lot of testing on my own, is there any way to get this script working for Ubuntu 18.04 Bionic Beaver?
My goal is to create a custom pre-installed image for VMware ESXi and I'm really stuck here.
Thank you in advance.

Hi, thanks for asking a question. Ubuntu 18.04 does not use the autoinstall method, it uses the older preseed method. You can find more information here: https://help.ubuntu.com/lts/installation-guide/amd64/apb.html
This script does not support the older method and I do not plan to implement it. However, my other project  uses the preseed method for automating the installation of Ubuntu desktop systems. You should be able to use that as a starting point (or if you need desktop versions, it might work as-is).


containLabel not working as expected

Version
5.1.2
Reproduction link
https://codepen.io/ataft/pen/eYWqzqx
Steps to reproduce
https://codepen.io/ataft/pen/eYWqzqx
https://codepen.io/ataft/pen/dyWxpyG
What is expected?
When containLabel = true and grid left, right, top, bottom are all set to 0, I expect the axis labels to show completely without getting cut off.
What is actually happening?
As the CodePen's show, labels are being cut off, especially in the top-left and bottom-right "ends" of the axes.

containLabel is a very important feature if it can work correctly. Manually setting grid left, right, top, bottom is tedious/impossible, and leads to a lot of unnecessary whitespace.

+1 this is a big problem for me

+1

+1

+1

+1 @Ovilia

+1

+1

+1

+1

+1

+1

亲，你的邮件东阳已经收到了

+1

+1

+1


Replace ElasticSearch with Loki

How to categorize this PR?

/area logging
/kind enhancement
/priority normal
What this PR does / why we need it:
With this PR we are replacing fluend and elasticsearch with Loki.
For a log UI we are reusing the Grafana UIs from the monitoring.
The log data from the old logging stack will not be migrated!
Which issue(s) this PR fixes:
https://github.com/gardener/gardener/issues/918
Special notes for your reviewer:
/cc @mvladev @Kristian-ZH
Release note:

- Integrate Loki in place of the fluentd and elasticsearch
- the old logging data will be lost.

@wyb1 Can you please take a look on the Grafana's part?

/assign

Now when you are completely replacing the entire logging, you could change all logging related labels and annotations from garden.sapcloud.io to gardener.cloud

Changing the existing fluent-bit causes this error:
time="2020-06-29T12:01:33+03:00" level=error msg="Seed bootstrapping failed: failed to apply manifests: 2 errors occurred: [could not apply object of kind \"DaemonSet\" \"garden/fluent-bit\": DaemonSet.apps \"fluent-bit\" is invalid: spec.selector: Invalid value: v1.LabelSelector{MatchLabels:map[string]string{\"app\":\"fluent-bit\", \"gardener.cloud/role\":\"logging\", \"role\":\"logging\"}, MatchExpressions:[]v1.LabelSelectorRequirement(nil)}: field is immutable

/hold until v1.7 is released

/unhold as v1.7.0 is released

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.1 out of 2 committers have signed the CLA.:white_check_mark: vlvasilev:x: Gardener CI/CDGardener CI/CD seems not to be a GitHub user. You need a GitHub account to be able to sign the CLA. If you have already a GitHub account, please add the email address used for this commit to your account.You have signed the CLA already but the status is still pending? Let us recheck it.

/needs rebase

The component descriptor step fails - https://concourse.ci.gardener.cloud/teams/gardener/pipelines/gardener-master/jobs/master-pull-request-job/builds/1024. PTAL.

@danielfoehrKn @dguendisch @schrodit  Can you please review the PR again because your comments are fixed

I think you missed my comment in file kubernetes-pods-dashboard.json, can you recheck?

I think you missed my comment in file kubernetes-pods-dashboard.json, can you recheck?
(Actually I copied the link to the comment, but at least for me the link doesn't work, so maybe just look for the file mentioned above: https://github.com/gardener/gardener/pull/2515/files#r446058912)

Yes, sorry. Is it okay now?

Sure, thank you very much! Nothing to add from my side.

Only a few minor comments from my side. Also, when I tested this, I came across the following issues:
I had loki crash a few times due to liveness / readiness probes failing. It did come back eventually (after 5-15 min). The second time I forced reconciliation, not sure if this helped or not. Not sure what the reason can be, maybe it's a local one with my setup.

Anecdotically we came across similar issues with loki in our testmachinery cluster: it would crash here and there due to liveness or readiness probes failing, mostly when we stressed it with queries going back more than 1 or 2 days.
We only got rid after giving generous resource limits and switched to ssd storage.
So in this case here it could be caused by the very limited resource limits of 200m for CPU (https://github.com/gardener/gardener/pull/2515/files#r446056940)

Only a few minor comments from my side. Also, when I tested this, I came across the following issues:
I had loki crash a few times due to liveness / readiness probes failing. It did come back eventually (after 5-15 min). The second time I forced reconciliation, not sure if this helped or not. Not sure what the reason can be, maybe it's a local one with my setup.

Anecdotically we came across similar issues with loki in our testmachinery cluster: it would crash here and there due to liveness or readiness probes failing, mostly when we stressed it with queries going back more than 1 or 2 days.
We only got rid after giving generous resource limits and switched to ssd storage.
So in this case here it could be caused by the very limited resource limits of 200m for CPU (https://github.com/gardener/gardener/pull/2515/files#r446056940)

Hmm, I expected that the vpa will scale up Loki if the resources are not enough for it.
@dguendisch can you suggest new limits and requests for resources and i will change it

Actually I don't know the load typically induced by a) the fluentbits ingesting data from the control plane + b) operators/users doing some adhoc queries. (In the testmachinery clusters we track logs of tests and have a different load pattern.)
Sure VPA could scale up but I guess when operator/user queries are not fitting into the current limits, it would make a bad usage experience to see loki crashing with your query, waiting for vpa to react, waiting for loki to restart, redoing your query, vpa sizing down some hours later (when no operator is doing queries anymore), next day repeat the same cycle ...
So I have no better suggestion than to experiment with it in real deployments / real usage (i.e. on the dev landscape) and see whether the current limits are too aggressive, if yes, reiterate the limits until somewhat stable settings have been found.
So please go with the current ones and be ready to adapt if we see it unusable.

Only a few minor comments from my side. Also, when I tested this, I came across the following issues:

I had loki crash a few times due to liveness / readiness probes failing. It did come back eventually (after 5-15 min). The second time I forced reconciliation, not sure if this helped or not. Not sure what the reason can be, maybe it's a local one with my setup.
I noticed a few controllers using logs in JSON format that are not properly parsed. These controllers are gardener-resource-manager and all extension controllers. I don't think this was better before this PR, so I would suggest to improve the parsing in a separate PR.

Thank you for the review, the comments are fixed.

As we are unable to reproduce this issue, I think that the best decision is to merge this PR and after that we will monitor it on the productive landscapes
The new filters/parsers will be added as improvement with another PR.

/lgtm

@ialidzhikov Can you please check if it is okay now?

@ialidzhikov Can you please check if it is okay now?

Looks like there are still 2 version bumps, my question was general - did you updated them on purpose or it is part of unwanted change? If it is the second one, then you can revert the changes in go.mod?

@ialidzhikov Can you please check if it is okay now?

Looks like there are still 2 version bumps, my question was general - did you updated them on purpose or it is part of unwanted change? If it is the second one, then you can revert the changes in go.mod?

It was part of unwanted change (maybe after make revendor). Now go.mod is the same as before

Thanks, I will try to play with it today in a more extensive manner.

Thanks @ialidzhikov for the comments. Can you please check now?

Thanks @ialidzhikov for the comments. Can you please check now?

Looks like I missed to mention in the inline comments but after enabling loki, it was not gathering logs from existing Pods (which apparently continue to log). I had to restart some Pods to be able to finally see its logs. Can you reproduce?

Thanks @ialidzhikov for the comments. Can you please check now?

Looks like I missed to mention in the inline comments but after enabling loki, it was not gathering logs from existing Pods (which apparently continue to log). I had to restart some Pods to be able to finally see its logs. Can you reproduce?

I am unable to reproduce it. We have test it with @Kristian-ZH and everything works as it should.

Give me 20 mins to test the latest changes, please :)

During this time the old EFK will not collect new logs, but the health checks will be failing with missing loki.

Hm, is this because fluent{d,-bit} in the garden namespace of the seed is already adapted to loki?

Maybe you can try to migrate the new logging stack immediately without waiting for the maintenance windows of the shoots?

How should that work, i.e., how do you concretely suggest to implement it?
@Kristian-ZH @vlvasilev Is there a way to configure the fluent{d,-bit} (or whatever is causing the issue) in a way to work with both ES and Loki?

Maybe you can try to migrate the new logging stack immediately without waiting for the maintenance windows of the shoots?

How should that work, i.e., how do you concretely suggest to implement it?

I was thinking loudly last night, and I forgot about one major disadvantage of this approach - there would be multiple detach/delete/create/attach volume operations which might lock the cloud provider account because of rate limits.

Yes, correct. I guess, if there is no way to configure fluent{d,-bit} as suggested earlier, we probably have to live with the fact that some clusters don't have logs for ~24h. I don't see a better option. /cc @vlerenc

@rfranzke There are things we have to nail 100% of the time, like not accidentally deleting clusters, and then there is everything else. Having a gap of 24h in the logs is very acceptable - we don't have to overdo it here with the switch-over, so all is good.

@vlvasilev , could you please check make test?


respect workflow for retired filtering in selection

Closes #1891 - Do not filter out subjects that have been retired for another workflow.
Also added in an explicit spec to ensure the subjects are returned in the order the selector chooses them. used mostly for priority selection but will preserve ordering for random too.
Describe your change here.
Review checklist

[ ] First, the most important one: is this PR small enough that you can actually review it? Feel free to just reject a branch if the changes are hard to review due to the length of the diff.
[ ] If there are any migrations, will they the previous version of the app work correctly after they've been run (e.g. the don't remove columns still known about by ActiveRecord).
[ ] If anything changed with regards to the public API, are those changes also documented in the apiary.apib file?
[ ] Are all the changes covered by tests? Think about any possible edge cases that might be left untested.

Nice catch.


release_suffix bad behavior in packit-service

In packit-service the behavior should be like the following:

for release_suffix = (not empty str) (release suffix in .packit.yaml is a not empty string) the custom release_suffix should be used and the spec file should be bumped (that means we should change the spec file with the custom Release)
for release_suffix == None (no release suffix keyword  in .packit.yaml) the default packit release_suffix schema should be used and the spec file should be bumped (that means we should change the spec file with the default packit Release schema)
for release_suffix == "" (empty  string for release suffix keyword in .packit.yaml) the release found in the spec file should be used and the spec file should not be changed

The Packit API has two flags the bump flag and the release_suffix flag.
We need to use the bump flag to control changes in the spec file, we can not count on the release_suffix flag, otherwise we will affect the CLI tool.
For this reason when packit-service finds a release_suffix=="" (empty) then it should force the bump flag to False!
But it seems that packit-service is not able to distinguish between a None or an "" (empty) release_suffix.
This PR has solved this issue  for the csutils project  but has introduced a new problem for the cockpit project.
Before introducing the above PR we were bumping the Release into the specfile (and also the Version which seems wrong):
https://copr-dist-git.fedorainfracloud.org/cgit/@cockpit/cockpit-preview/cockpit.git/commit/?id=b6ded94cb02b2491d570f5ec47e536b813adf285
Version was 0 instead of 279 and Release seems ok .
After the above PR the packit-service did not bump the Revision into the specfile
https://copr-dist-git.fedorainfracloud.org/cgit/@cockpit/cockpit-preview/cockpit.git/commit/?id=072531b10de3eeeb952b27f358c4b84525ebb790
The cockpit project has no release_suffix in its .packit.yaml.
The csutils has a release_suffix="" in its .packit.yaml
We solved the problem for csutils and introduced a bug for the cockpit .
I think we are not able to distinguish between a None or empty release_suffix in packit-service. Maybe this is a serialize/deserialize problem.
Action items:

[ ] find a reliable way, for the packit-service, to tell when the bump flag for the Packit API has to be True or False
Possible solutions:

instead of carry two different meanings into the release_suffix flag we could introduce the bump flag into the .packit.yaml to be more explicit (like we are with the CLI tool)
solve the serialization/deserialization problem (if any)
introduce another custom syntax for the release_suffix keyword which means -> do not bump

[ ] be sure we are not doing anything wrong with the Version value inside the spec file when bumping

In architecture meeting (24/11/22) we decided we want to add a new keyword bump to the packit.yaml file to explicitly state if the spec file should be updated or not.
After adding this new keyword we should also help our users, which are now using the release_suffix = ""', to migrate to the bump keyword.

We are now writing the wrong Version value inside the spec file when we update it.
It is fine that we are again updating it but we are messing with the Version value and we should fix it.


Check if we can only activate when workspace has app.json or app.config.json

Old version
Right now it's activated on all events.
New version
It should only happen when Expo is found in the project.
Additional context
It's not necessarily a waste, but good dev-hygiene :smile:

I can take it 🙂

Sorry for the delay again! If you want, go for it 😄 I'm not an expert with VSCode plugins. I know there are some interesting activation events that we can use, but looking forward to any contribution 👍

Is there any progress on this feature? While working on multiple projects unrelated to Expo, it is a bit annoying always getting an error on VSCode bootup.

@ekfuhrmann This has been sort-of implemented already.

We defer starting up to keep vscode as fast as possible (source - see why)
The JSON Schema only activates for app.json (source)
We fixed an issue where app.json's expo was required and would warn if it's not defined (#63)

This is as specific as we can get it. If you know a better way, feel free to open a new issue.


Update README.md

Describe the changes you've made
Cloning the repo via HTTPS fails, showing error "RPC failed; curl stream was not closed cleanly".
This can be bypassed by simply cloning the repo using SSH.
Checklist

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] All new and existing tests passed.
[x] The title of my pull request is a short description of the requested changes.

Cloning with HTTPS works fine for me. There may be some issue with your git config.

This might be a temporary issue, as the same error was reproduced on other (mobile data) networks by @arminpatel as well.


chore(master): release 1.1.27

:robot: I have created a release beep boop
1.1.27 (2023-08-21)
Bug Fixes

deps: update dependency wayofdev/laravel-cycle-orm-adapter to v4.0.65 (bb82085)

This PR was generated with Release Please. See documentation.

:robot: Release is at https://github.com/wayofdev/laravel-webhook-client/releases/tag/v1.1.27 :sunflower:


[Tracy Profiler] Add new port

Describe the pull request

What does your PR fix?

Adds port for the Tracy Profiler: https://github.com/wolfpld/tracy

Which triplets are supported/not supported? Have you updated the CI baseline?

uwp: Untested
x86: Untested
arm64-windows: Untested - CI indicated build failure
x64-windows: Tested Working
x64-windows-static: Tested Working
x64-linux: Tested Working
arm64-android: Tested Working
x64-osx: Builds on CI
Yes I've updated the CI baseline file

Does your PR follow the maintainer guide?

Yes, the formatting should be up to date

Thanks for the new port!

Is this port working for you guys? I am able to install it but most Tracy headers include other Tracy headers internally which are not dropped by this port basically rendering it useless.
E.g tracy.hpp
#include "common/TracyColor.hpp"
#include "common/TracySystem.hpp"

As only these headers are installed by default some required headers are not present.
+    ${CMAKE_CURRENT_LIST_DIR}/TracyC.h
+    ${CMAKE_CURRENT_LIST_DIR}/Tracy.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyD3D11.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyD3D12.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyLua.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyOpenCL.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyOpenGL.hpp
+    ${CMAKE_CURRENT_LIST_DIR}/TracyVulkan.hpp)

Due to tracys project structure with all subfolders, it would be best to place all headers in a separate folder and extract all dependencies into it as well.
tracy\
-- TracyC.h
-- Tracy.hpp
....
-- TracyVulkan.hpp
-- common
---- TracyColor.hpp
---- TracySystem.hpp

@Honeybunch
Or maybe I am doing something wrong but there isn't a full install option either so could you please help me out on this one?
Because as far as I can tell these files are missing and should be included in the project as well.
Regards Artur

Huh, strange! I'll take a peek as soon as I can.

Yeah this is on me.
There's a PR to fix it in upstream here: https://github.com/wolfpld/tracy/pull/312
And a PR to fix the patch in vcpkg here: https://github.com/microsoft/vcpkg/pull/22510

@S0PEX , Please try pr #22510 to see if it can meet your needs

@JonLiu1993
The new port works and I am able to compile my project now. One thing I noticed though is that although Tracy is also compiled as debug with /Mtd the CMake script will always link the static release version /MT  of Tracy in both release and debug settings.
So it is only using lib\TracyClient.lib although debug\lib\TracyClient.lib is also available.
@Honeybunch
Thanks for the fast response and incredibly fast fix.
Appreciate it.


How to Buffer Sent Messages when connection is lost but "Disconnect" event is not launched?

I'm developing a real-time chat app with Socket.io.
I implemented the Ack callback for all the event that I need to emit using the chat ("join","readMessages", etc...).
I'm trying to do the same thing with the "createMessage" event.
It happens that when the socket is connected, everything is ok and the Ack returns empty (successfully emitted).
Now I need to implement a persistent queue of messages that is filled when i'm trying to send a message and the connection is lost. The problem is that, the "Disconnect" event is called 20-30 second after the connection is lost.
So for example if on my emulator I disconnect the WiFi and then 1 second later I try to send a message, i emit a "createMessage" event with an Ack, but nothing returns back so I don't even know if the event was succesfully emitted and that's why I cannot handle the case when connection was lost but the socket didn't already return a "Disconnect" event.
I mean, when I know that socket.isConnected()==false I can queue messages and then re-send them when i'm reconnected.
But in the interval of time in which Socket.io is polling to understand if connection was lost or something else, how I can handle the "createMessage" emit?

I implemented an AckWithTimeOut so that, if in 5000ms (example) i don't receive an Ack, I know that there was an error and the emit failed.
This was made in the SocketIO repo, here the issue.
https://github.com/socketio/socket.io-client-java/pull/517


Include dist on GitHub / npm.

Nice work on the input!
The mains in the package.json currently pointing to non-existent dist/.

Also I built the dist and dropped into a project. Any ideas on these errors?

Thank you for the report! I thought the dist was included in the npm module but not on Github, but I'll double check. As for these errors, I'll also check: which version of Vue are you using?

Errors might be my fault on controlled props and such.


set up page structure markup

In this PR, I laid out skeleton markup for the page structure and did some light styling (mainly on nav, main, footer). I already set up a basic CSS system in an earlier commit. Below is a screenshot of how it looks so far:

Codecov Report

Merging #444 into master will decrease coverage by 6.29%.
The diff coverage is n/a.

@@            Coverage Diff            @@
##           master     #444     +/-   ##
=========================================
- Coverage   76.51%   70.22%   -6.3%
=========================================
  Files          44       44
  Lines        1367     1377     +10
  Branches      253      258      +5
=========================================
- Hits         1046      967     -79
- Misses        263      339     +76
- Partials       58       71     +13

Impacted Files
Coverage Δ

packages/microcosm/src/addons/indexing.js
0% <0%> (-100%)
:arrow_down:

packages/microcosm/src/addons/action-form.js
0% <0%> (-97.62%)
:arrow_down:

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 ca2e6aa...033a2d7. Read the comment docs.

@chloehwang If you don't mind, could you run this at the root of the project:
yarn format

That'll make CI happy :)


Sign in with Apple and anonymous users

[REQUIRED] Step 2: Describe your environment

Xcode version: 11.2.1
Firebase SDK version: 6.13.0
Firebase Component: Auth
Component version: 6.4.0

[REQUIRED] Step 3: Describe the problem
Steps to reproduce:
In our current setup, users are always logged in anonymously, then they can deicide to login/sign in, at which point we either link the anonymous user to the used provider or sign in.
Auth.auth().currentUser?.link(with: credential) { result, error in
    if let error = error, (error as NSError).code == AuthErrorCode.credentialAlreadyInUse.rawValue {
        Auth.auth().signIn(with: credential) { result, error in
            // continue
        }
    } else {
        // continue
    }
}

This works fine with other providers (eg: Facebook), but using "Sign in with Apple", an existing user can't sign in, and I get the error:
Error Domain=FIRAuthErrorDomain Code=17094 "Duplicate credential received. Please try again with a new credential." UserInfo={NSLocalizedDescription=Duplicate credential received. Please try again with a new credential., FIRAuthErrorUserInfoNameKey=ERROR_MISSING_OR_INVALID_NONCE}
It seems that the credential is only valid for a single request, so I can't seem to be able to achieve this without having to show 2 login prompts, or discarding the anonymous user and simply using signIn

Hi @Sephiroth87, thanks for reporting this. I'll try to reproduce this behavior on my end, and I'll let you know with my findings.

@Sephiroth87 I got the same behavior on my end. As what you have mentioned, it looks like the credential is only valid for a single request in Apple provider. Upon checking this link, the "ERROR_MISSING_OR_INVALID_NONCE" means that "The request contains malformed or mismatched credentials.".
It is also mentioned here that:

For every sign-in request, generate a random string—a "nonce"—which you will use to make sure the ID token you get was granted specifically in response to your app's authentication request.

With this, it seems like you need to re-generate a random nonce string as this step is important to prevent replay attacks.

Yes, the problem is, since the nonce is linked to the ID token, if I need to generate a new pair, I'd have to show the ASAuthorizationController again, which is not a great experience.

@Sephiroth87 Yes, you'd need to show the ASAuthorizationController again to generate a new nonce string. I even tried this using phone number, and I got an error "The SMS code has expired. Please re-send the verification code to try again". It seems that the Apple and phone number provider has the same flow and their credentials are only valid for a single request.

So basically "Sign in with Apple" and anonymous users are just incompatible?

@renkelvin can you answer this last question? This sounds like it would be an issue for all nonce-related flows in the future, not just Apple.

Try linking then sign in are actually 2 separate requests, so to be OIDC compliant, the nonce has to be different. And yeah, it's not just for Apple, it would be the same for other OAuth requests with nonce.
@Sephiroth87 A solution to your case is to not setting nonce (it's optional). This way you can do it as the same as Facebook IDP.

Sounds like this is working as intended, though it's potentially confusing.

@renkelvin I tried not setting the nonce, but I get the same error...

Yeah, it seems Apple's credential is forbidden to reuse. Let me double check with my teammates.

It's confirmed that you can't reuse the credential of Apple.
The solution is that, once you receive the error after linking, you can retrieve an updated credential from the error object with:
error.userInfo[FIRAuthErrorUserInfoUpdatedCredentialKey]
Then you can use the update credential to sign in the user without the second login prompt.

This is convoluted enough that we should probably document it.

Thank you, it's working now 🎉
I agree with maybe adding some documentation, also as a feature request I would suggest a single function that does either the linking or the signin (unless I'm the only one using it that way)

Docs updated at cr/288738567 (Googler-only link). They'll likely be merged and published at the end of this week or beginning of next.
The automatic linking behavior is likely something we'll keep in FirebaseUI.

I am having the exact same problem, but error.userInfo only contains the error code and localized string, no value FIRAuthErrorUserInfoUpdatedCredentialKey, so I cannot use the trick mentioned by @renkelvin
I have just done a pod update to make sure I am using the latest version of the API, but no luck.
How can you integrate sign in with Apple without having to show the ASAuthorizationController again?

Can you share the error? If it's the same error, it's likely some weird provider behavior that requires a reauth under certain conditions.

Error is ["FIRAuthErrorUserInfoNameKey": ERROR_MISSING_OR_INVALID_NONCE, "NSLocalizedDescription": Duplicate credential received. Please try again with a new credential.]
but userInfo does not contain any updated credential like it is described in this thread

Does this always happen, even with a very recent sign-in?

Yes it does happen next time I try to sign in.
Scenario is:

successful login with Apple for first time
save identityToken and nonce in UserDefaults (I do not want to generate a nonce each time to avoid having to display ASAuthorizationController at each app launch)
Stop the app
Restart the app, at which point it creates an Oath credential with saved identityToken and nonce and tries to sign in to Firebase
login callback returns the error mentioned without any updated credential

I am not a security engineer, but you should definitely get some expert advice before storing auth stuff in user defaults.
In this case you're receiving the error because you're trying to re-use a nonce, and they exist specifically to avoid being re-used.

Thanks @morganchen12
Now that you say it, this is actually obvious.
That being said, I could not find any other way to authenticate user to firebase with Apple without displaying again the ASAuthorizationController.
I understand this now becomes out of topic for this thread, but then how do I manage to have my user signed in with apple at every app launch without displaying ASAuthorizationController?
I need this to have the same uid across multiple devices of the user. This is so I can sync their data stored in Firebase Realtime database without relaxing security rules ($uid === auth.uid) on user node.

Firebase Auth will automatically persist your user in Keychain, so for normal user tasks you won't need to reauthenticate. For account-related tasks like linking a provider you will still need to reauthenticate.
You should be able to fetch the uid without reauthenticating.

OK, I get it now and it does work.
Thanks a lot and sorry for my confusion

No problem!

Hi, we're having the issue with Unity and the Apple Sign In Popup coming up every time.
We're just getting the Duplicate credentials error as we're trying to avoid the Apple Sign In pop up when we reconnect.
We store the idToken off on the first login and then use that on subsequent logins ..but this throws the exception - just a few questions on the above threasd,  how do you 'fetch the uid without reauthenticating' - if the user has switched their apple id etc, is this valid? thnx

Hey @simontgs, this thread has gotten a little out of hand. For Unity-related issues, please file a support ticket to Firebase Support.
The user persistence is something that Auth does by default on iOS via Keychain, so it should work without requiring you to store any login information. Are you able to reproduce this bug in an iOS-only project?

Hey morgan, thanks, we haven't tried a pure ios project only, we're just using Unity.
We sign in with Apple Sign In ( Unity plugin ) - received the idToken from Apple and store that off
We then use this in the following code. Note: first time in is fine, second time in, we pull the idToken out of our PlayerPrefs and feed it in and get the duplicate credential as a result.
We have tried several alternatives to no avail.

  Call Unity Sign In with Apple, retrieve the id token and store it

Validate the token with firebase and sign in...
 2)   var credential = OAuthProvider.GetCredential( "apple.com",token,  null, Guid.NewGuid().ToString());
  3)   var fbUser = await auth.SignInWithCredentialAsync(credential);

I'll fire an email to firebase support, thnx


Driver export format and location definitions

As highlighted in #82 and #74 as of the last release we've added new ways to export devices, and to transition we still have some of the old ones.
Goal: a clear definition driver export format and location that covers development and production needs (writing/debugging drivers and running driver via cli, driver manager and ...) for future SDK versions.

Driver export format - how in code a driver should be exported
Driver export location - where within a package a driver should be exported

Driver export standard
Driver export format
The format from 0.50.x should be flexible enough:
module.exports = {
  devices: [
    deviceA,
    // and so on if multiple devices
  ]
}

Recommendation: 1 device per export/module, unless the devices are variations or similar (v1 & v2 or lite & premium).
Driver export location

One single file should export the devices array defined above.
That file should be linked as the package's main property in the package.json:

{
  ...
  "main": "devices/index.js",
  ...
}

This makes the devices easily accessible via require('neeo-driver-example').devices and more flexible as that location could also be "index.js" or "dist/index.min.js" and so on.
0.50.x export:
Driver export format
Currently as of 0.50.5 with the neeo-sdk cli the expected format of a device driver is:
module.exports = {
  devices: [
    deviceA,
    deviceB,
    // and so on
  ]
}

Regardless of if that driver has one or more devices in it. The CLI then combines all the drivers it finds and loads them in a server.
Driver export location
As of 0.50.5 will be loaded from different locations based on use case. If we consider the neeo-sdk cli as the emerging standard, it will look for devices in the driver export format at these locations:

For devices local to workspace

devices/${driverName}/index.js
devices/index.js

For devices installed from npm, available in node_modules

node_modues/${moduleName}/devices/index.js

0.50.5 export location example:
Let's say we're in a work space using:

some local drivers in development: localDeviceA, localDeviceB, localDeviceC
some external drivers installed via npm: externalDeviceA, externalDeviceB

The local setup looks like this:
devices/
  localDeviceA/
    index.js (exports localDeviceA in the driver export format)
  localDeviceB/
    index.js (exports localDeviceB in the driver export format)
  localDeviceC/
  	nonStandardDevice.js (exports localDeviceC but not in index.js)
  index.js (exports localDeviceC in the driver export format, after loading it from nonStandardDevice.js)
node_modules/
  externalDeviceA/
    devices/
      index.js (exports externalDeviceA in the driver export format)
  externalDeviceB/
    devices/
      index.js (exports externalDeviceB in the driver export format)
package.json

This will load all drivers from 3 different paths in different ways and only partially leveraging the NPM package loading sytem.
0.49.x and before export:
Drivers didn't export themselves but started their servers.

This made combining drivers in to 1 server difficult without writing code
This made running multiple servers difficult without managing ports
It also couples different concerns: device definition and handling with server

Driver export format
None.
Driver export location
None.

Some background and thoughts:
Driver export format:
I think the 0.50.x format is fine and gives flexibility to add other elements later or to export extra non standard properties if needed.
Driver export location:
I think the devices/ folder needs to go. It's imposing structure that doesn't need to be imposed.

external drivers could use the package.json main property to specify which file exports the devices
** it could be devices/ but doesn't have to be leaving the structure up to the developer

So then require('neeo-driver-example') would return the driver export format to it's user (cli or driver manager) which I think would be much cleaner (and flexible). It leaves the local development use case open tho.
Some history bits:
It came about because we wanted to make it easy to drop several device drivers in a folder and run them all at once without editing code or ports to make it more user friendly. Then we realized this might make it tricky to install (put the modules in, run npm install in each sub folder) and we could instead load packages from npm directly and that would allow npm install to only be run once. We thought the devices option would be useful for local development, and keeping the same format on the external driver side minimizes the effort switching between development and production.

Basically, all drivers are loaded "by convention". There is the possibility to prevent drivers to be loaded using the env variable: NEEO_DEVICES_EXCLUDED_DIRECTORIES=["file1", "file2"]. It's also possible to configure the devices folder using NEEO_DEVICES_DIRECTORY="directory".
But I agree with @pfiaux, we should move towards a more defined way of loading devices, but also keep the configuration centralised in the package.json to make it less confusing.

Not only by convention but also implicitly, (a driver called my-awesome-driver would not match the neeo- filter and be excluded even if it was a valid driver).
we could move to explicit naming using the package.json (similar to say cordova plugins):
"neeoSdkOptions": {
  "drivers": [
    "neeo-driver-example", // these are the name of npm modules, which are already installed locally
    "neeo-driver-example2"
  ],
}

But this adds some duplicate data since they will also be listed in dependencies.
Also regarding the Driver export location, i'm still wondering how or if we need to handle the local use case. Here's some options I thought of:

CLI checks the package.json main property and loads devices from that file
CLI takes an additional parameter with a path to load devices from (neeo-sdk start devices/index.js)
CLI reads the path or paths to load devices from as an array from the package.json neeoSdkOptions
CLI reads paths from env variables

It's mainly relevant to the CLI and not necessarily to the driver export standard. Perhaps this is a discussion more specific to the CLI and it's use of neeoSdkOptions, other tools don't necessarily need to use this and should be able to do it differently.
I've updated the description driver export format at the top of the issue.
@nklerk @Shepless do you think that setup makes it clear and flexible enough to work with drivers? (both the driver development and running driver sides should be clear now)

I'll need to read it a couple of times and test some stuff to give a definitive feedback. I can however already comment on the struggles i had in adopting the CLI until now, Although i can code I'm not a developer that needs half the word to understand the bigger picture, the lack of experience will be the same or more so with users that like to fiddle around but have no clue about node, NPS etc.. For then a linear always the same approach is recommended. My struggles can help in finding an easy way for the user.
Now concrete, here are my struggles.

The CLI is delivered with the SDK. but the SDK is included in the driver. a chicken and egg problem arises for me. So do i first need to install the SDK or first the driver.
I was trying to structure my driver (https://github.com/nklerk/neeo_driver-kodi/tree/next) i chose to include the full path as described. this will however overwrite files when other drivers are build the same way, so mi issue was how would i keep the package.json unieque while offering a simple solution without difficult structures.
NPM introduces a totally different way of adding drivers as modules. and added at least to me a lot to the confusion.

To a user, the most simple solution is:

npm install neeo-sdk
download driver from git
extract driver folder in /drivers/
exec npm start

The SDK would scan reclusively either package.json or more future proof neeodriver.json
The json could look something like https://github.com/nklerk/nl.nielsdeklerk.neeo/blob/master/app.json
Sorry for not yet answering the question directly.

Thanks for the feedback @nklerk, good points!

Agreed on the CLI vs SDK, we plan to split the CLI from the SDK (avoiding the other problem you mentioned above) in #82
The structure of drivers and role of npm needs better documentation from us. If you install the driver via npm it will go to node modules (npm supports github urls as well). For example if I wanted to install your kodi driver i could run npm install --save git+https://github.com/nklerk/neeo_driver-kodi#next. The driver will the be loaded from ./node_modules/neeo_driver-kodi/devices/index.js automatically by the CLI. The advantages being:

You don't need to manage the files (download from github, move to correct location)
You don't have to worry about other drivers overriding your files since they'll be in separate folders
You don't need to run npm install multiple times (instead of going to each folder in devices to run npm install, you can run it once on the root)

Since we didn't do the split yet I'll just call it neeo-cli and outline how it might work for the advanced user who only wants to run drivers:

Install the CLI globally
Go to the folder where you want to install the drivers
run neeo-cli init server – this creates the minimum setup
run neeo-cli add neeo_driver-kodi – this downloads the driver from npm or github urls, extracts it (in node_modules) and installs the dependencies
run neeo-cli start server – this starts with all the drivers that were added

Then the CLI will also have some tools for developers like

run neeo-cli init driver – asks some question like driver name, device type, do you need discovery, and then generates some starting driver code you can complete

This would be the perfect solution!

I didn't plan on getting involved in the discussions that are taking place here, but seeing the way drivers are currently "forced" to be structured in a certain way (although there are workarounds) I wanted to hop in and give a nudge towards configuration as @bdauria already mentioned earlier.
I think there are three two to go forward if we want to expose drivers through config:

Use" NPM's main property to point to the file drivers are exposed in.
Add a "neeo" section to package.json, containing devicesPath or something similar. This would also allow further configuration in the future.

Sadly we don't have default/unnamed exports yet, so for now we're forced to name our export. I'm not quite opposed to devices. If there is a "neeo" section in package.json I suppose the devices export name could be configured there, or the path could contain the export name as is commonly used in serverless config, see:

AWS SAM, the handler (synonymous with neeo's devices) is exported in index.js as handler
https://docs.aws.amazon.com/lambda/latest/dg/serverless_app.html
Serverless, the handler is exported in handler.js as hello
https://serverless.com/framework/docs/providers/aws/guide/functions/

I'm completely in favour of @pfiaux suggestion of how the CLI would be used to add new drivers, as I'm not quite fond of having to clone drivers into a certain directory. I would like to suggest that individual drivers are spawned in separate processes to avoid a bad driver from bringing everything down. Im that case I think it would be wise to look at existing process managers to avoid reinventing the wheel.

I would like to join this discussion, beside i currently have no time for playing with the new SDK.
I definitly like the Point, that @nklerk mentioned. From side of a User it must be as simple as possible to load a driver to NEEO. Currently it is hard enough to do so because needed to Setup an external Device to run the Code.
But due to this will not be changed within the next Releases, i like the Following way:
Let the User Download the NEEO-SDK and install it via NPM, then there need to be one Folder (as it currently is) for all Drivers that are available so no new Installation is required for each driver and no Additional Config needs to be done by enduser.
I know, that Github is not very good when merging Code to one repository, but i also don't like the way to search for each driver and implement it every time.
Optimal solution (in my eyes) are:
Programmers provide a single folder for an driver sorted the way he likes which can be copied to folder Devices inside the SDK the SDK Scans this folder and awaits a "overhand of the Name and Capability" of the Driver (e.g. Name: Enigma2, Type: Mediaplayer Type: Single / Multi)
The Type needs to overhand if the Driver should run as single instance or can be run together with others!
Then the SDK start a server instance and loads the driver to the brain(s) or it groups drivers by (max 5 or so) and provide this to the Brain(s)
If one Driver crashes the SDK provide a Logfile into an folder (to be send to developer / NEEO) on request only.
Automatic restaret of the Driver when it was crashed to provide control of the device when the crash is one time only.
There should not be to much related to the enduser, thereofr a simple as possible concept should be approched.
Later on when a HTTP control of the Brain is officialli supported, this can also lead to loading a Zip file into the Brain which is then extracted and stored under a single folder.

Apologies @pfiaux @bdauria @nklerk I have been AFK for this week - life and stuff 😄
I think the convention of a package exporting a single driver makes the most sense to me as multi-export comes with big challenges in terms of process management and also installation/maintenance.
I'm not sure I'm fully understanding the discussion around location though? To me, this shouldn't be a problem. If you npm install 10 drivers and they all have a standard "main": "./path-to-entry.js" then this is fine? All you'd need to do it is require() the packages and you're up and running.
However, if we're talking about a use case where you have local and npm packages in the same project, then to me that doesn't make sense. As a developer, if I'm creating a new driver - that driver should be self-contained and not need to depend on another driver. If we want to "combine" drivers to run from a single server - we're moving out of the responsibilities of the SDK to build a driver and into the next "architectural" level - e.g. Driver Manager/CLI Server Start. I hope that makes sense. In short what I am saying is - I can't see a valid reason for a driver package to need a dependency on another driver package. If we treat that as the norm and best practise then the location discussion is redundant as it just leverages standard npm practises.

Let's split off the single vs multiple driver discussion to a separate issue #100 because there's other concerns with that change architecture wise. For now we'll keep the devices array which we recommend to only be used with 1 device (plus arrays make for easier functional programming).
After looking over the pros and cons for local vs npm packages here I think we're going to go with the npm setup and stop supporting local drivers directly. We lose the convention of drivers in devices/ but local drivers can still be supported differently and gain in flexibility. It will provide a better experience in all cases, especially when we add some helpers to the CLI.
Summary
Let's say we're in  /neeo-sdk-server/, and we want to install packages:

an npm package: npm install neeo-driver-example
a git package with public url: git+https://github.com/nklerk/neeo_driver-kodi#next
a local package in /my-driver/: npm link ../my-driver

This treats local and npm packages the same way so only 1 setup to support for driver managers and developers and avoids any drivers accidentally depending on another. Also it leaves it up to the driver managers (CLI, driver manager, ...) which drivers to load. In some cases automatically loading all compatible drivers makes sense, in others we might want an explicit whitelist or blacklist but that should be up to the manager code to handle as it wants.
It will also be easier for the advanced user running SDK devices:
mkdir neeo-sdk-server && cd neeo-sdk-server && echo '{}' > package.json
npm install --save neeo-sdk neeo-driver-example
./node_modules/bin/neeo-sdk start

No manual managing of folders, downloading/extracting and installing dependencies. As @Shepless mentioned the best practice would be to leverage npm.
It leaves 1 lose end, as a developer writing a driver how do easily I run the driver I'm currently working on for development. I don't think it needs a special kind of standard defined here, there's currently multiple options and we can add more via the CLI to handle this case.

@pfiaux I'm fully with you on this. one way of installing and running drivers is the way to go.
For development i would like to keep the option to use MS visual code in debugging mode. I'm not sure how that is called but the feature where the dev can halt code and look inside variables etc. but I guess this is what you meant.

We've published updated examples including a a skeleton/minimal driver in the next branch:
https://github.com/NEEOInc/neeo-sdk-examples/tree/next/neeo-driver-example
We'll update the readme in the SDK as part of #82 and we have a work in progress CLI which will be in a separate repository with the install documentation.


[SPARK-48019] Fix incorrect behavior in ColumnVector/ColumnarArray with dictionary and nulls

What changes were proposed in this pull request?
This fixes how ColumnVector handles copying arrays when the vector has a dictionary and null values. The possible issues with the previous implementation:

An ArrayIndexOutOfBoundsException may be thrown when the ColumnVector has nulls and dictionaries. This is because the dictionary id for null entries might be invalid and should not be used for null entries.
Copying a ColumnarArray (which contains a ColumnVector) is incorrect, if it contains null entries. This is because copying a primitive array does not take into account the null entries, so all the null entries get lost.

Why are the changes needed?
These changes are needed to avoid ArrayIndexOutOfBoundsException and to produce correct results when copying ColumnarArray.
Does this PR introduce any user-facing change?
The only user facing changes are to fix existing errors and incorrect results.
How was this patch tested?
Added new unit tests.
Was this patch authored or co-authored using generative AI tooling?
No.

thanks, merging to master/3.5!


Implement disabled state

Implements disable feature.
Fixes #15

Hi @Meravici, thanks for the PR - Looks good to me!


remove space should not change cluster

What happened?
when using devspace remove space with multiple clusters and contexts, it will not return you to the same cluster as the space was in you just removed
What did you expect to happen instead?
I would expect it to return me to the same cluster as the namespace was in
How can we reproduce the bug? (as minimally and precisely as possible)
have multiple clusters and contexts defined, create, and then remove a namespace.
Local Environment:

DevSpace Version: [use devspace --version]
4.12.3
Operating System: windows | linux | mac
mac
Deployment method: helm | kubectl apply
helm

Kubernetes Cluster:

Cloud Provider: google | aws | azure | DevSpace Cloud | DevSpace Cloud Enterprise | other
aws
Kubernetes Version: [use kubectl version]
GitVersion:"v1.18.2"

Anything else we need to know?
/kind bug

@blairham Thanks for opening this issue.
I am not sure if I understand what you mean by return me to the same cluster as the namespace was in? Do you want DevSpace to switch back to the admin context you used beforehand to connect the cluster?
If that's the case, I don't think that will be possible because DevSpace does not keep track of the contexts you used to connect clusters and more importantly, most non-admin users will not have such a context.
If I misunderstand your feature request, let me know.

@LukasGentele Sure let me draw a bigger picture
Let's say I have 3 clusters defined in my kubectl:
production
pre-production
development
Now I only have devspace hooked up to say: development
I create a space in the development cluster, say 'blairham' now I have a new context in the development cluster called 'devspace-blairham'
If I remove that space 'blairham', that was created in the development cluster. I would expect it to put me back in the development cluster, currently it just random.
I would assume that you can track the parent cluster a space was created in and when deleting that space it switch back to that parent context instead of letting kubectl pick one.

Alright, I understand. That is actually not an easy feature because there are a couple of issues to resolve:

What could happen when non-admin users that do not have the cluster-wide context delete a space?
It is not easy to determine which context belongs to a certain cluster. We'd have to check all contexts and the API servers and even that does not mean there would be a match or there could be many (e.g. other spaces, other non-devspace related contexts for the cluster).
It is entirely possible to have multiple contexts for the same cluster (I mean DevSpace even does this for each space), so how do we determine which one it the 'right' context to switch to?

I think one alternative thing we could do (without having to resolve the open questions) is to show a picker after devspace remove space where the user can select a new current-context instead of choosing one automatically.

Closing due to inactivity. If you are still facing this issue, please reopen for us to re-look at it.


Amend merge_cubes utility to handle issues raised by grid blending.

As IMPROVER developers we need to improve the merge_cubes utility to handle situations that have been identified during the implementation of grid blending.
We have created patch scripts within our suites to aid with cycle and grid blending. Issue #275 will address the need to merge cubes before blending that has currently been patched for cycle blending.
When blending grids we encountered the following problems with merge_cubes:

failed to merge when cube cell-methods are different between the inputs.

failed to merge when one cube has a forecast_period or other scalar coordinate with bounds and one cube has a forecast_period or other scalar coordinate without bounds.

Problem 2 above is only encountered in our archive trials (running say 21Z to 06Z) when the MOGREPS-UK 21Z Cycle blend (which is a blend of one cycle, 15Z being unavailable) is then called into the blendgrids at cycles 00-06Z. In this case the UKVx cycle blend contains a forecast_period with bounds but MOGREPS-UK does not. Note that just stripping the bounds from the forecast_period is not sufficient.
Acceptance criteria:

merge_cubes deals with unmatched cell methods, creating new metadata as appropriate.
merge_cubes deals with scalar coordinates from two cubes, where one has bounds and one does not.
unit_test coverage extended appropriately.

As part of #366 merge_cubes was amended to deal with unmatched cell methods. Currently it just removes mismatching cell methods so it may need revisiting if creating new metadata may be more appropriate.


Bug Fix and compatibility changes Laravel 5.6+

This pull request fix issues with namespaces and add more options to configure Google Logs
Also Service Provider are auto injected now
The changes break who are using current version, so a new version must increments the major number

Hello @mazinsw Using this package i should be able to see the logs of the app in google cloud logging? For example, I enable SQL logging, but I don't see any of the queries when using this package. am I missing anything? PS: I am using Laravel 8.

Hi @bhaidar , yes you can view logs (better filtered by logName) on Logs Explorer, you must guarantee that everthing is configured correctly, the main project is not working (this pull request solves), you need to use this fork to work properly until it is merged, follow my composer.json fragment, algo you must add stackdriver to channels of stack or set LOG_CHANNEL as stackdriver

    "homepage": "https://www.myhomepage.com",
    ...
    "repositories": [
        {
            "url": "https://github.com/grandchef/laravel-google-cloud-logging.git",
            "type": "git"
        }
    ],
    "require": {
       ...
        "superchairon/laravel-google-cloud-logging": "master",
       ...
   }

Thanks @mazinsw Can you share with me all configuration needs to enable Stackdriver on Google App Engine for Laravel? Anything to add into appyaml file?

File .env
Entries
LOG_CHANNEL=stackdriver

File config/logging.php
Add channel:
'stackdriver' => [
    'driver' => 'stackdriver',
    'level' => 'debug',
    'logName' => 'my-website-log-name',
    'projectId' => env('GOOGLE_CLOUD_PROJECT_ID', 'project-id-here'),
    'keyFilePath' => env('GOOGLE_CLOUD_KEY_FILE', base_path('my-service-account-key.json')),
    'labels' => [
        'environment' => env('APP_ENV'),
    ],
],

At Google Console create service account with permission "Logging Admin" and json key, read this docs https://cloud.google.com/iam/docs/creating-managing-service-account-keys
put file my-service-account-key.json at app root
Test some exception

Thanks @mazinsw All works well!

@mazinsw Hey! Any idea why a log name is not created under Log Explorer? The GAE service account has Logging Admin permission, still not working. That's another project I am working on right now. Thanks

logName is a property of log, it is required by Logging, are you sure that the log is created without logName?


Clean up SQL and AD config

This PR suggests that the config file should have an example for AD as well as LDAP.  It also suggests that the SQL config should more closely mirror what is suggested for MySQL config in the README(e.g. user=powerdnsadmin instead of user=root).  It also splits the config into multiple variables.  Let me know what you think.
Cheers

Since you edited both those files; maybe we can just remove the config_template_docker.py completely? The only (major) difference is that the Docker-version has LOG_FILE = '/dev/stdout', which, imho, can just be a line that is commented out like;
LOG_FILE = 'logfile.log'
# For Docker, set the following
#LOG_FILE = '/dev/stdout'

... or similar. The fact that config_template_docker.py is completely outdated (compared to config_template.py) suggests that it might be a good idea to remove it (-:

Done.

Looks good to me. Merging. Thanks @elitest.


Fix iterateOverNode for PHP 8

See https://github.com/soundasleep/html2text/pull/87/files

Looks ok to me


DS-790 Content items deprecation

Jira
https://pegadigitalit.atlassian.net/browse/DS-790
Summary
The props content_items and contentItems were deprecated. The new prop items was added.
Details
The usage of content_items and contentItems were replaced with items. Additionally, objects with image attributes (src, width, height, etc.) were updated with the image set, to pass data the correct/new way, as was said in this discussion
:arrow_down: :arrow_down: :arrow_down: :arrow_down:
Old usage :x:
{% include<EMAIL_ADDRESS>with {
    opacity: 'heavy',
    fill: 'gradient',
    content_items: [
      {
        pattern: 'image',
        src: '/images/content/backgrounds/background-tall-4.jpg',
        ...
      },
    ]
} only %}

New usage :white_check_mark:
{% set image %}
  {% include<EMAIL_ADDRESS>with {
    background: true,
    attributes: {
      src: '/images/content/backgrounds/background-tall-4.jpg',
      ...
    },
  } only %}
{% endset %}
{% include<EMAIL_ADDRESS>with {
  opacity: 'heavy',
  fill: 'gradient',
   items: [
    image
  ]
} only %}

Updated in places wherever pattern: 'image' was in usage:

Layouts folder
Components folder
-- Background
-- Band
-- Breadcrumb
-- Card
-- Carousel
-- Modal
-- Sticky
Pages folder
-- Boc
Experiments folder
Archive
-- Academy
-- Content Hub
-- Events
-- Homepage
-- Partners
-- Product

How to test
Pull The Branch. Check if there are no errors related to the new prop (items) usage. Confirm that we can pass an object with image attributes to the items: [...] and an image variable.
Release notes
The props content_items and contentItems related with the bolt-background component are deprecated. Please use the correct way of passing an image to the new prop items.

The changes look good AFAICT.
I'm just catching up on the history of this work. So, apologies in advance if this is totally off base, but:

Since this is a deprecation not a removal, we should target master not release/6.x, right? I vaguely remember us rebasing this on the release/6.x branch intentionally so lmk if I'm missing something.
Since this is a deprecation, we should still allow the old props and not do this, right? Or do we not care because the validation only works in Bolt?

cc @remydenton @colbytcook

@danielamorse

I saw that DS-602 was set to release/6.x so following that, I did the same here. If it's wrong that's my mistake.

When it comes to deprecation our Wiki says this ->> deprecating properties
And we can find a lot of examples in the Bolt repository using
  not: {
    anyOf: [
    ...
    ]
 }

But there are also deprecated props in components that don't use that, for example: ol.twig, ul.twig or chip-list.twig

The changes look good AFAICT.
I'm just catching up on the history of this work. So, apologies in advance if this is totally off base, but:
1. Since this is a deprecation not a removal, we should target `master` not `release/6.x`, right? I vaguely remember us rebasing this on the `release/6.x` branch intentionally so lmk if I'm missing something.

2. Since this is a deprecation, we should still allow the old props and not do [this](https://github.com/boltdesignsystem/bolt/pull/2510/files#diff-cbecbc9144fa63e844ba8e21f9ace5e0dbe9b701c58f3a0dbff4dd1610dcd955R7-R16), right? Or do we not care because the validation only works in Bolt?

cc @remydenton @colbytcook

@MarcinMr @danielamorse

Yes since this is a deprecation we should re-target this to master instead. Marcin the reason https://github.com/boltdesignsystem/bolt/pull/2478 was merged into release/6.x was because it was a remove task (with examples on the live site) and not a deprecation task like this one.
I think it is fine to keep the deprecations in the not key, since like you said Dan the validation is only on the Bolt side and it would be nice to have a layer of checking.

Marcin, I left a small comment (basically just to keep things consistently, really not an important fix but something that I would rather not get copied to Drupal at one point). Approved

This looks great, nice work @MarcinMr 🙏 .


Added t3-env for typesafe environment variables

This PR implements the use of t3-env in the next app, expo app (also added the EAS_SLUG variable) and in the packages folder for common variables. Fixes #90.
Currently I couldn't get it working for the api environment variables defined in the .dev.vars.
@timothymiller Do you have some suggestions on what could be going wrong on native? Web works fine. I also implemented the ThemeToggle component for native (currently commented out), if you could test that also would be great.

Already encountering some errors with eas build, I'm going to move the env from packages to app.

Maybe the environment checking in the expo folder doesn't make much sense, need some feedback on this.

Now expo build succeeds but the app crashes on open with the t3-env error.

We don't need t3-env for this functionality. We've also moved onto using Valibot over Zod.
My inspiration comes from this video: https://www.youtube.com/watch?v=q1im-hMlKhM

Yeah that's nice, declaring them in the global scope seems the right way. In the near future I'm going to refactor all of this to this approach using valibot, removing t3-env and zod

We don't need t3-env for this functionality. We've also moved onto using Valibot over Zod.
My inspiration comes from this video: https://www.youtube.com/watch?v=q1im-hMlKhM

I've implemented env-variables.ts files with valibot in the features, next and expo folders. Now the variables are typed and available in the intellisense.
Removed t3-env and zod. The only problem that remains is checking if the variables are present at build time, since this implementation doesn't do that currently (only parses their types).

👉 Expo loads env vars with the EXPO_PUBLIC prefix by default
👉 Next loads env vars with the NEXT_PUBLIC prefix by default
👉 Wrangler wants env vars inside .dev.vars
😩
I think we might have to write a transform to handle them all
https://docs.expo.dev/guides/environment-variables/

👉 Expo loads env vars with the EXPO_PUBLIC prefix by default
👉 Next loads env vars with the NEXT_PUBLIC prefix by default
👉 Wrangler wants env vars inside .dev.vars

Yeah that's kind of a mess 😖

I think we might have to write a transform to handle them all

I have very small knowledge on how we could do that at build time, do you have any sources/ideas that I could take a look at?

I'm thinking about writing a small ts shim that will take a global .env file and move it to either the expo or next folder with the appropriate prefix during the UI package build time

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe?)

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe, at least for the next and expo ones?)

Generating them can be done, but it's the accessing them from the app folder that is awkward.

It introduces runtime overhead

@albbus-stack I would like something like this in the future, but it will be tricky because access env vars on different platforms have different prefixes, so typesafety around one standard is tricky...

Yeah in fact I had defined three separate files for expo, next and packages. It should be possible to generate them using your script (maybe, at least for the next and expo ones?)

Generating them can be done, but it's the accessing them from the app folder that is awkward.

Yeah the problem is inside the app folder


Possible Misinterpretation in the Calculation of TP, TN, FP, FN in evaluate_entity_level_using_knn Method

In the evaluate_entity_level_using_knn method in the model/eval.py file, the calculation of True Positives (TP), True Negatives (TN), False Positives (FP), and False Negatives (FN) seems to be incorrect. The current code is as follows:
for i in range(len(y_test)):
    if y_test[i] == 1.0 and score[i] >= best_thres:
        tn += 1
    if y_test[i] == 1.0 and score[i] < best_thres:
        fn += 1
    if y_test[i] == 0.0 and score[i] < best_thres:
        tp += 1
    if y_test[i] == 0.0 and score[i] >= best_thres:
        fp += 1

In my understanding, the label y_test for malicious entities is 1, and score[i] should be greater than the set threshold. Therefore, the corrected code should be:
for i in range(len(y_test)):
    if y_test[i] == 1.0 and score[i] >= best_thres:
        tp += 1
    if y_test[i] == 1.0 and score[i] < best_thres:
        fn += 1
    if y_test[i] == 0.0 and score[i] < best_thres:
        tn += 1
    if y_test[i] == 0.0 and score[i] >= best_thres:
        fp += 1

Could you please confirm if my understanding is correct? Thank you.

You are correct, and fortunately this bug does not affect anything else. It has been fixed.


feature diagnose for cluster balance

Proposed changes
Usage: show proc "/diagnose/cluster_balance"
Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

run buildall

run buildall

run clickbench

run buildall

run buildall


No wallet database exists

Hello,
I got an issue when I launch agents using this project, and the error is the following :

prover_1      | 2021-03-18 08:44:39,640 aries_cloudagent.commands.start ERROR Exception during startup:
prover_1      | Traceback (most recent call last):
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/indy/sdk/wallet_setup.py", line 169, in open_wallet
prover_1      |     credentials=json.dumps(self.wallet_access),
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/indy/wallet.py", line 127, in open_wallet
prover_1      |     open_wallet.cb)
prover_1      | indy.error.WalletNotFoundError
prover_1      |
prover_1      | The above exception was the direct cause of the following exception:
prover_1      |
prover_1      | Traceback (most recent call last):
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/commands/start.py", line 72, in init
prover_1      |     await startup
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/commands/start.py", line 28, in start_app
prover_1      |     await conductor.setup()
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/core/conductor.py", line 91, in setup
prover_1      |     self.root_profile, self.setup_public_did = await wallet_config(context)
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/config/wallet.py", line 40, in wallet_config
prover_1      |     profile = await mgr.open(context, profile_cfg)
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/indy/sdk/profile.py", line 161, in open
prover_1      |     opened = await indy_config.open_wallet()
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/indy/sdk/wallet_setup.py", line 182, in open_wallet
prover_1      |     ) from x_indy
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/aries_cloudagent/indy/sdk/wallet_setup.py", line 169, in open_wallet
prover_1      |     credentials=json.dumps(self.wallet_access),
prover_1      |   File "/home/indy/.pyenv/versions/3.6.9/lib/python3.6/site-packages/indy/wallet.py", line 127, in open_wallet
prover_1      |     open_wallet.cb)
prover_1      | aries_cloudagent.core.error.ProfileNotFoundError: Wallet 'Prover' not found: Error: Wallet not found
prover_1      |   Caused by: No wallet database exists

I tried multiple things and the problem doesn't come from Docker, ports aren't used. I guess it may be a set up problem.
Any idea ?
Thanks for your help,

Can you provide some information on how you are starting the agents?

I'm using docker commands to start the agents ->
docker-compose build
docker-compose up

Can you provide your docker-compose.yml file?

docker-compose.zip
The file is this one.
Just to precise a little bit : the project is working for all the others one that used it. I am the only one in this case.
I tried to disable my firewall and my antivirus in order to try if that's because of this, but it didn't changed anything.

Thanks can you also share the startup command for the agent (with all the parameters)?

FROM bcgovimages/von-image:py36-1.14-1
ARG PROVER_SEED
ARG PROVER_AGENT_ENDPOINT
ARG PROVER_WALLET_KEY
ARG PROVER_ADMIN_API_KEY
ARG GENESIS_URL
ARG INBOUND_PORT
ARG API_PORT
ENV SEED=$PROVER_SEED
ENV AGENT_ENDPOINT=$PROVER_AGENT_ENDPOINT
ENV WALLET_KEY=$PROVER_WALLET_KEY
ENV ADMIN_API_KEY=$PROVER_ADMIN_API_KEY
ENV GENESIS=$GENESIS_URL
ENV AGENT_INBOUND_PORT=$INBOUND_PORT
ENV ADMIN_API_PORT=$API_PORT
RUN pip install aries-cloudagent
ENTRYPOINT ["/bin/bash", "-c", "aca-py start  --inbound-transport http <IP_ADDRESS> $AGENT_INBOUND_PORT
--outbound-transport http
--admin <IP_ADDRESS> $ADMIN_API_PORT
--seed $SEED
--endpoint $AGENT_ENDPOINT
--wallet-key $WALLET_KEY
--wallet-name Prover
--wallet-type indy
--label CertPROVER
--admin-api-key $ADMIN_API_KEY
--auto-accept-invites
--auto-accept-requests
--auto-respond-messages
--auto-respond-credential-proposal
--auto-respond-credential-offer
--auto-respond-credential-request
--auto-respond-presentation-proposal
--auto-respond-presentation-request
--auto-store-credential
--enable-undelivered-queue
--genesis-url $GENESIS", "--"]

Is that what you were looking for?
Another precision, is that the same error shows up for the others agents that you can see in the docker-compose file (issuer, verifier).

Hi @ytebboune when you "pip install aries-cloudagent" you get the latest published version. aca-py version 0.6.0 was released recently, so I suspect what's happening is that previously people were getting aca-py 0.5.6 and now you're running with 0.6.0
You need to add an additional parameter --auto-provision to tell the agent to create its wallet if it doesn't already exist.
Alternately you can run aca-py provision ... which will do any necessary wallet setup, and then aca-py start ...
(The changes in 0.6.0 are to make wallet creation always explicit)

That's it !
Thanks a lot, really. I spent days on it.


fix udp mux on AWS/ECS

For user verify ice fix can work at AWS/ECS https://github.com/livekit/livekit/pull/1036

Close this since we have a better way to fix the issue


[Bug]: Old tags when trying to make a service update

Is there an existing issue for this?

[X] I have searched the existing issues

Example public repository
coolify
Description
I am using the n8n service and would like to do an upgrade to the newest version. While a container is stopped, on the tag lists there are only old tags.
BTW. The newest n8n version is 0.209.0 but when I'm creating a new service, coolify automatically prompt the 0.207.0 version.

Steps To Reproduce
Create a new service and try to select version 0.20x.0
Version
3.12.4

Will fix this in the next version!

I've updated the script that generates the tags so that the new tags will be available in 10 minutes on your instance. Let me know if it is still not working.

Hi! we now have access to the most recent tags, but not to the latest one from 2 days ago.

Have you updated the tag list once or wrote a code to refresh tag's list every time? Because as @Auran0s said, there aren't the newest tags on the list. The same issue is f.ex. in Appsmith application.

@andrasbacsai can you please refer to the question above? Currently, the newest version of n8n is 0.211.2 but in the Coolify there is 0.210.1. Same with appsmith - the newest is 1.9.3 but in the Coolify is 1.9.1

@andrasbacsai I think we should reopen the issue, I have the same problem as everyone here. The versions that are available for n8n through coolify stop at 0.210.1 but 0.212 exists in the n8n repository.
I would like my coolify to be able to fetch its own tags and not be dependent on a json file that is in coolify. I would also like coolify to be able to fetch newer tags without needing to update coolify itself!
Thanks

@andrasbacsai are you there? Could you check above conversation?


Containers: Lists

Node based container, implemented with std::list or std::forward_list.
Possibly only a list for objects, but perhaps integer and string lists too.

Command
Purpose
Args
Notes

LST_CREATE
Creates list
name,lenHint
Call reserve() with a clamped lenHint

LST_DELETE
Deletes entire list

LST_LEN
Returns size()

LST_COPY
Creates a copy of this list
src_pos, dest_pos, len, destination
Creates a new list destination, copying nodes from [src_pos,src_pos+len] to dest_pos

LST_MOVE
Move nodes to a different list
src_pos, dest_pos, len, destination
Moves nodes from [src_pos, src_pos+len] to destination at dest_pos. Create destination if it does not exist. See std::list::splice()

LST_SET_HEAD
Add to head of list
item
Returns size()

LST_SET_TAIL
Add to tail of list
item
Returns size()

LST_SET
Add by position
item, pos
If pos > size(), add to tail. If pos < 0 or empty() add to head. Returns pos

LST_GET_HEAD
Get head item

LST_GET_TAIL
Get tail item

LST_GET
Get an item by position
pos
Decide what to return if pos out of bounds

LST_RMV_HEAD
Delete head

Return size()

LST_RMV_TAIL
Delete head

Return size()

LST_RMV
Delete by position
pos, len
Removes from pos to pos+len. pos must be in range, but if pos+len > size() remove from pos to end. Returns size()


Add generics in SingleType

Inside the generic goes a comma separated list of Type:
SingleType = ( TypeIdentifier | PredefinedType ) [ "<" Type *( "," Type ) ">" ]

Examples:
list<foo>
Foo<bar | baz>
foo<x, y, z | f>

Done!


[SPARK-38896][CORE][SQL] Manual close KVStoreIterator and remove finalize() from LevelDB/RocksDB

What changes were proposed in this pull request?
The main change of this pr as follows:

Use Utils.tryWithResource to recycling all  KVStoreIterator opened by RocksDB.view(Class<T> type).iterator and RocksDB.view(Class<T> type).iterator
Remove the finalize() method from LevelDB/RocksDB

Why are the changes needed?

Using finalize()  to recycle resources is not a good way, see Effective Java Item 7 Avoid finalizers
finalize() is identified as deprecated  after Java 11 and forRemoval=true after Java 18

Does this PR introduce any user-facing change?
No
How was this patch tested?
Pass GA

Maybe we should split this PR into two small pr:
One use Utils.tryWithResource close all KVStoreIterator opened by RocksDB.view(Class<T> type).iterator and RocksDB.view(Class<T> type).iterator
The other one remove the finalize() method from LevelDB/RocksDB
If necessary, please let me know

Test Link: https://github.com/LuciferYang/spark/runs/6020180085

Test link https://github.com/LuciferYang/spark/runs/6051837286


Fixed writing pages in the same thread that does EnqueuePage

AsyncManualResetEvent was using TaskCompletionSource which by default runs continuations synchronously. That led to writing pages in the same thread that called EnqueuePage and, as a result, ~4x performance degradation.
Used more correct way to asynchronously wait for wait handle.
This partially fixes #2451

I am concerned about the extra dependency in System.Threading.ThreadPool

Hi @JKamsker , this dependency exists only because of netstandard1.3 target (for some reason thread pool routines are not available out of box in netstandard1.3). I don't think it is a vulnerable package or something.
Benchmark code is contained in this bug - #2451 , as well as results in terms of time taken to run the app. This pr aimed to partially fix it as well

Hey @alexbereznikov, thanks for this fix. I've a couple of suggestions.
And please, can you add unit tests for this, that way we can avoid regressions

Hey @pictos , regarding unit test for this - I can't think of a good way to create a unit test for this without exposing DiskWriterQueue internals or coming up with additional abstractions that required only for tests.
I added an ENSURE check instead, so in case of regression - tests will fail.

Closed as redundant due to #2515


Improve the error messages in the merger if you send in an invalid message

I was sending some hand-rolled messages to the merger this evening, patching up a reindex. The merger takes a collection of WorkIdentifier instances, which is defined as:
case class WorkIdentifier(identifier: String, version: Option[Int])

In my naïveté, I sent the following WorkIdentifier to the merger: WorkIdentifier(id = "qwkttzg2", version = None). I promptly saw a null pointer exception coming from the ElasticRetriever in the merger logs, which was both confusing and wrong. We pretty much never want to be throwing a null pointer error – it indicates a higher-level bug somewhere else, and we should catch it and explain what's actually gone wrong.
Digging in, I discovered that the ElasticRetriever throws a null pointer error if you ask it to retrieve an empty list of IDs. I've replaced that error with an assertion that throws a more explicable error message ("You should never look up an empty list of IDs!"). If it turns out there is some scenario when this is useful, it'll be easier to debug.
But why was the merger retrieving an empty list of IDs? Because it only asks the ElasticRetriever to find Works whose WorkIdentifier has a non-empty version.
I had to stare at the matcher code for quite a while to convince myself that yes, sometimes this field will be empty and that's okay, and also that the matcher should always include at least one non-empty version in the results it sends. I've added some comments to the matcher graph code so it's easier to follow, and an assertion/comment in the merger to catch this as well.

This is failing because of a flaky test that's fixed in https://github.com/wellcomecollection/catalogue/pull/1254

This is failing because of a flaky test that's fixed in https://github.com/wellcomecollection/catalogue/pull/1254

I'm going to merge this as-is to get the matcher changes in; if somebody wants to come back and make this a NonEmptyList, let's do that separately.

I'm going to merge this as-is to get the matcher changes in; if somebody wants to come back and make this a NonEmptyList, let's do that separately.


Compatibility with NetStandard2.0 and NetFramework

Hello,
Is there any plans to have compatibility with NetStandard2.0 to be playable on mono/net framework?
Also is it possible to have this cross platform? F.e. it is possible to use Avalonia host to be launched on Linux.

I have no plans on going back from NetCore 3.1 on the contrary my plans go to Net5. Anyway if you need it you can probably backport to NetFramework without much problem. There's a stalled NetFramework branch in the repo: https://github.com/BluestormDNA/ProjectPSX/tree/NetFramework48
ProjectPSX is already cross platform. The OpenTK host runs on Linux. It's a test on crossplatform so it haves a very basic UI with just an OpenTK (glfw3) window to draw the full VRAM, input for gamepad, and sound. To make it run once the window has appeared just DRAG AND DROP your cue/bin file.
Technically you can build an Avalonia project just implement the ProjectPSX IHostWindow interface to let it know how/where to draw, and just call ProjectPSX RunFrame() 60 times a second...


Add ability to ignore csv fields as requested in #15

Coverage remained the same at 100.0% when pulling 03970f33fc7ea41b9f3607b38aa915c182522f47 on ckirby:master into 79f71ef35c30ec1a508d07c7db02c2cc73e0feee on california-civic-data-coalition:master.

Thanks for this patch. I'll take a look when I find a minute. Out of curiosity, what is your use case for this feature?

First let me say that I really like the project and like supporting it with
new code (I also submitted the patch for the static_mapping functionality).
I saw someone submitted issue 15 and thought I could use the feature too.
Use case: I have a system where data providers send us large data sets that
we use postgre_copy to insert. For various reasons we don't update the
model until all providers are onto the new data spec, so being able to
ignore the new fields until flipping the switch on the model is useful.
I also have some thoughts on how to tackle issue #26 (
https://github.com/california-civic-data-coalition/django-postgres-copy/issues/26)
would you be interested in a patch with that functionality?
Best,
Chaim
On Mon, Oct 10, 2016 at 9:12 PM, Ben Welsh<EMAIL_ADDRESS>wrote:

Thanks for this patch. I'll take a look when I find a minute. Out of
curiosity, what is your use case for this feature?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/california-civic-data-coalition/django-postgres-copy/pull/30#issuecomment-252697772,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAFeHjbzVNBbBK7gv3B7yTigZlJNLJQ_ks5qyoABgaJpZM4KSlQi
.

Coverage remained the same at 100.0% when pulling 73dc5f3d50aff118f7fe793ca27215d5c15fab1e on ckirby:master into 79f71ef35c30ec1a508d07c7db02c2cc73e0feee on california-civic-data-coalition:master.

Moments ago I pushed a change to the master branch that take a different approach to solving the problem.
Rather than add a new keyword argument that requires users to explicitly list the headers they'd like to skip, I've tried to rework the application so it will "just work" and allow for headers to be omitted from the map input without any extra configuration.
I've added the tests you submitted here to see if I got it right, and they appear to be passing. If you have the time, let me know what you think of this stab at a solution.

@ckirby, if you don't protest, I think I might close this pull request and keep the alternative implementation of your feature described above.


Do we actually want random_flip?

Was wondering whether it actually makes sense to train the model w/ random_flip data augmentation.
Faces are asymmetric and presumably we'd want the model to be able to take advantage of that.  We don't really need a model that's invariant to mirror images, since these are relatively rare.
However -- empirically, does training w/ random_flip yield better results on standard benchmarks?

Hi,
That's an interesting question. I haven't tested the difference between flipping and not flipping, and I guess it depends on the dataset that is used for training as well (i.e big dataset => less need for data augmentation). But I guess the cases where the model need to use information about left and right are also relatively rare.

Yeah, makes sense.  I may do a test at some point.  Will report here if I do.
I've read in some of the literature of people catting/summing the feature vectors of regular/horizontally flipped versions of the query images.


Add support for configuring SSL version

I have a need to limit the SSL connection to TLS 1.1 or better.

@labrown LS 1.5.3 release has explicitly rejected SSLv3 and allows TLS 1.1 onwards

Very good!

@labrown actually Logstash 1.5.4 support TLS 1.1 and Logstash 2.0 support TLS 1.2


pin numpy to <2 in ci/docker

Description
pinning the numpy version across ci/docker to <2. nump 2.x is released, and causing issues across ci/docker.
I will wait to merge this until reviewing with team on monday

going to merge this now to get nightly runs against this change


Update SR-IOV chart to declare k8s 1.25 support

SR-IOV chart doesn't seem to reference any APIs that are removed in k8s 1.25 and don't use PSPs.
However, the chart defines catalog.cattle.io/kube-version as >= 1.20.0-0 < 1.25.0-0 and it needs to be changed to >= 1.20.0-0 < 1.26.0-0 so these charts declare as supporting 1.25.
Additionally, the latest version of the chart has catalog.cattle.io/rancher-version: '>= 2.6.0-0 < 2.7.0-0' and it should be updated to catalog.cattle.io/rancher-version: '>= 2.7.0-0 < 2.8.0-0' instead as the chart is for 2.7.x releases.
Part of https://github.com/rancher/rancher/issues/39366

Since we can't test the actual SR-IOV chart due to a lack of hardware, we should ensure that the chart appears correctly in the Apps Marketplace.


Moved GMIT's file to appropriate folder according to guideline

@rachetm Thank you for the update! Pull request merged.


Download data wrong location

During user testing with @pshab, we noticed that changing the location and then downloading data for a graph downloaded the data for the previous location, not the newly selected location.

confirm this is now working


Analyzer can add 'Instance' entries

Describe the feature
When the analyzer finds a decorated type, it can add, as a 'fix' the code to generate an attribute for an 'Instance'

We are moving away from 'Instances', preferring static readonly fields in the value object itself


Unable to locate Grids or Windows

I am trying to test drive a WPF application. I have the WinAppDriver loading properly, and the Driver as well opening up my application. However, when I try to FindElement for a Window or a Grid, I get an error.
OpenQA.Selenium.WebDriverException: 'An element could not be located on the page using the given search parameters.'
My find is quite simple IMHO.
var mainWindow = Driver.FindElementByAccessibilityId("MainWindowGrid");
Likewise the xaml is simple.

<Grid.RowDefinitions>

.....
It seems like the only thing I can find is a Button. What am I doing wrong that I cannot locate anything useful? Please help. Thank you.

What is shown in inspect.exe?

I'm sorry, what is the inspect.exe tool? Do you mean after using the UIRecorder?

No the one that comes with windows SDK.

I have the sdk installed but I don't see the inspect.exe.

I found a copy of it. Trying it now. It shows the automation id I'm expecting when I hover over the menu option I want. What am I missing?

I think I found something. If I try to find the nested button, it won't find it....until I click the parent's File menu option. Is that required? Why can't it find the nested file menu exit button?


Document week / w suffix

As mentioned in graphite-project/whisper#239 the code supports "week"
as a unit of time, so document it

Codecov Report

Merging #2107 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master    #2107   +/-   ##
=======================================
  Coverage   78.88%   78.88%
=======================================
  Files          78       78
  Lines        7626     7626
  Branches     1515     1515
=======================================
  Hits         6016     6016
  Misses       1383     1383
  Partials      227      227

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 15f16a3...5231d27. Read the comment docs.


Variables doesn't work in multipart form body

I have checked the following:

[X] I use the newest version of bruno.
[X] I've searched existing issues and found nothing related to my issue.

Describe the bug
If i enter values itself everything works fine, But if i trying to use variables get an error.
Windows 11 x64
.bru file to reproduce the bug
No response
Screenshots/Live demo link

I am sorry for the inconvenience caused by this bug, @Belozertsev-av.
The issue you reported is a duplicate of https://github.com/usebruno/bruno/issues/352. There is already a pull request (https://github.com/usebruno/bruno/pull/2329) waiting to be merged. Thank you for your patience!
Please add a 👍 reaction to the issue https://github.com/usebruno/bruno/issues/352 instead.


Create LICENSE

https://github.com/virattt/ai-hedge-fund?tab=readme-ov-file#license mentions a license file that does not exist, creating here.

Thanks @ScottBrenner !


Fuzzing no longer deterministic

Component
Forge
Have you ensured that all of these are up to date?

[X] Foundry
[X] Foundryup

What version of Foundry are you on?
forge 0.2.0 (56dc746 2022-08-26T00:05:24.870934Z)
What command(s) is the bug in?
forge snapshot
Operating System
macOS (Apple Silicon)
Describe the bug
Forge fuzz testing gas usage is no longer deterministic. Running forge snapshot --diff yields a different result each time. This breaks our CI as it relies on the snapshot diff.

this was just fixed here https://github.com/foundry-rs/foundry/pull/2950
will land in next nightly.
sorry about that

yup, it was

@transmissions11 fyi

amazing fix times as always, thank you kings


Fix layout for very long strings in user profile

Right now, the personal fields on profile pages (and likely in other places) seem to have character limits that are either nonexistent or large enough to seem so. As displayed below, this can lead to some of our pages looking less-than-ideal if someone fills a field in with an overtly-long response.

This also makes it harder when we want to use this information on other parts of the site, such as in contributor searches and the such.

Firstly, I agree with Lyndsy's point that it is unnecessary to set the maximum length here.  And also the reason why it is out of boundary is because the input is a very long word. In default setting, that word will not be break and also its length will be the width of the table cell (td).
However, in our real use case, it is nearly impossible to have such a long single word. The most complicated one may be just as the same as Lyndsy pointed out. Below is the screen shot when it shows in our table.

As we can see, the width is dependent on the longest word here. Our current implementation totally meets the needs in real usage setting. Therefore, I suggest that we could close this issue.

@lbanner This will be fixed with 0.45, on staging you can see that the table cells already break the long words:

OK .... any particular PR?

@lbanner This one -- https://github.com/CenterForOpenScience/osf.io/pull/3952

Thanks

This pr has been merged and deployed on production.