uninitialized constant Spaceship::Pathname (NameError) after upgrading from 2.120.0 to 2.121.1

Question Checklist

[x] Updated fastlane to the latest version
[x] I read the Contribution Guidelines
[x] I read docs.fastlane.tools
[x] I searched for existing GitHub issues

Question Subject

 After upgrading Fastlane from version 2.120.0 to 2.121.1 using the command
gem install fastlane -NV, I am now seeing the error:
.../.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/module.rb:2:in `<module:Spaceship>': uninitialized constant Spaceship::Pathname (NameError)
Question Description

We have been using simple ruby scripts to use Spaceship for a while now, the template of such a script is as below:
require "spaceship"
Spaceship::Tunes.login(username, password)

Today after upgrading from version 2.120.0 to 2.121.1, all our ruby scripts that require spaceship are failing with the following error:
/users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/module.rb:2:in `<module:Spaceship>': uninitialized constant Spaceship::Pathname (NameError)
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/module.rb:1:in `<top (required)>'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/display_family.rb:1:in `require_relative'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/display_family.rb:1:in `<top (required)>'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/du/du_client.rb:2:in `require_relative'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/du/du_client.rb:2:in `<top (required)>'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/tunes_client.rb:3:in `require_relative'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/tunes_client.rb:3:in `<top (required)>'
	from /users/user/.rvm/gems/ruby-2.3.1@global/gems/fastlane-2.121.1/spaceship/lib/spaceship/two_step_or_factor_client.rb:2:in `require_relative'
	from /users/user/.rvm/gems/ruby-2.3.1@global/gems/fastlane-2.121.1/spaceship/lib/spaceship/two_step_or_factor_client.rb:2:in `<top (required)>'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/client.rb:892:in `<top (required)>'
	from /users/user/.rvm/gems/ruby-2.3.1@global/gems/fastlane-2.121.1/spaceship/lib/spaceship.rb:3:in `require_relative'
	from /users/user/.rvm/gems/ruby-2.3.1@global/gems/fastlane-2.121.1/spaceship/lib/spaceship.rb:3:in `<top (required)>'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
	from /users/user/.rvm/rubies/ruby-2.3.1/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
	from test.rb:5:in `<main>'

We have upgraded Fastlane dozens of times in the past, this is the first time we see this issue.
I am not too familiar with Ruby, therefore I apologize if this question is too simplistic.

Same here. The problem was introduced 2 days ago with this file:
https://github.com/fastlane/fastlane/blob/master/spaceship/lib/spaceship/tunes/display_family.rb#L1
I do not know how to fix it, but this might help?

Same error here. We rolled back to 2.120.0 until it's solved.
Also as far as I understand the error comes from here:
https://github.com/fastlane/fastlane/blob/master/spaceship/lib/spaceship/module.rb
Since the Pathname variable does not exist or contain any data? Maybe some file is missing from the commit introducing this file?

Thanks for reporting, this seems to be a regression. Somehow a require 'pathname' seems to have gotten lost in the code path to the spaceship module - but I am not sure yet how.

Oh yikes! Sorry about this 😞 Is it as simple as adding require 'pathname' into module.rb? I can stick up a PR if it helps?
I'm not too knowledgable on import structures in ruby but I've just realised that I don't import display_family in tunes.rb.. Is that related?

I have no idea, I hope somebody with more ruby experience will be able to help out here.
Can you go ahead and try and create a PR?

Yeah, probably it's best to add
require 'fastlane_core/helper'

as in other module.rb files (in other modules).
helper.rb includes pathname

There is one more file spaceship/lib/spaceship/tunes/language_converter.rb which relatively includes module.rb and would produce the same error if used directly from spaceship module (if publicly accessible).

I copied language_converter.rb assuming that the require it used was enough but apparently I was wrong 🙈
Does that helper need importing in module.rb to fix the issue?
I tried to reproduce the issue in a simple script but I'm unable to do so so I don't want to make a PR without being sure that I can 1) reproduce the issue and 2) I've actually fixed it. Can somebody help with replication?

I also can't reproduce this error with a Gemfile. It seems like bundler ends up requiring the correct stuff that everything needs but without bundler the proper requires aren't happening. Also looking into over here as well!

I managed to reproduce. I did not use bundler and installed gem directly.
/Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/module.rb:2:in `<module:Spaceship>': uninitialized constant Spaceship::Pathname (NameError)
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/module.rb:1:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/display_family.rb:1:in `require_relative'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/display_family.rb:1:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/du/du_client.rb:2:in `require_relative'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/du/du_client.rb:2:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/tunes_client.rb:3:in `require_relative'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/tunes/tunes_client.rb:3:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/two_step_or_factor_client.rb:2:in `require_relative'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/two_step_or_factor_client.rb:2:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:68:in `require'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship/client.rb:892:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship.rb:3:in `require_relative'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/gems/2.3.0/gems/fastlane-2.121.1/spaceship/lib/spaceship.rb:3:in `<top (required)>'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `require'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:127:in `rescue in require'
	from /Users/viktoraslaukevicius/.rbenv/versions/2.3.3/lib/ruby/2.3.0/rubygems/core_ext/kernel_require.rb:40:in `require'
	from test.rb:1:in `<main>'

I got a PR coming for this 💪

@joshdholtz, @viktorasl Thank you! 🙇🙇🙇🙇


[AutoRelease] t2-network-2022-10-10-01607(Do not merge)

https://github.com/Azure/sdk-release-request/issues/3223
Live test fail, detailed info is in pipeline log(search keyword FAILED)!!!
https://dev.azure.com/azure-sdk/internal/_build?definitionId=1016
BuildTargetingString
azure-mgmt-network
Skip.CreateApiReview
true

issue link:https://github.com/Azure/sdk-release-request/issues/3223

/check-enforcer override


Color picker RGB floating number request

Description of the new feature / enhancement
we have 0-255 range. Can you also add 0-1 range please?
Scenario when this would be used?
especially some applications like Vray, Blender uses this type of RGB range
Supporting information
No response

Does the custom format not allow you to do that?  We support float.
https://learn.microsoft.com/en-us/windows/powertoys/color-picker#managing-color-formats
/needinfo

[image: image.png]
couldn't find it. I mean in RGB  0=0 but 255=1 or 128 is 0.5 , 64 is 0.25
for example. maybe I wrote "Floating number" wrong but this is what I asked.
Clint Rutkas @.***>, 8 Haz 2023 Per, 17:46 tarihinde
şunu yazdı:

Does the custom format not allow you to do that? We support float.
https://learn.microsoft.com/en-us/windows/powertoys/color-picker#managing-color-formats
/needinfo
—
Reply to this email directly, view it on GitHub
https://github.com/microsoft/PowerToys/issues/26735#issuecomment-1582727109,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BANOUDK76MFRPEBSICVYSQDXKHQVZANCNFSM6AAAAAAY7H7VSE
.
You are receiving this because you authored the thread.Message ID:
@.***>

new Color (R = %Ref, G = %Grf, B = %Blf)
supported


value yielded by FormElement should provide two-way binding

This restores the v3 and documented behavior to update a value yielded by <form.element> in a custom control. This would fix the regression reported in #1192.
It does so by providing a two-way binding of the yielded value. This is a little bit contradictory to the intend of #1097, which removed two-way binding but only discussed it on FormElement itself - not on the yielded value property.
An alternative solution would be yielded an additional setValue this would feel more inline with DDAU. The usage would look like this:
<BsForm @model={{this.model}} as |form|>
  <form.element @property="name" as |el|>
    <input
      type="text"
      value={{el.value}}
      {{on "change" (action this.setValue value="target.value")}}
    />
  </form.element>
</BsForm>

The control component has an onChange argument, which provide the same value. But I'm not convinced by that name. I think a value property and a setValue function to update it, would be a more intuitive API.
To be honest I'm tending toward that API but only noticed after I had the fix nearly finished. So I wanted to provide that one as well to start the discussion.

Thanks @jelhan for working on this!

To be honest I'm tending toward that API

I agree.
For the record, the usage would be more like this, wouldn't it? (i.e. setValue comes form the yielded value)
{{on "change" (action el.setValue value="target.value")}}

Btw, there is nothing with which we can replace that target.value hack in an Octane world, i.e. something to get rid of action?

To be honest I'm tending toward that API

I agree.

I have implemented it in #1203.

For the record, the usage would be more like this, wouldn't it? (i.e. setValue comes form the yielded value)
{{on "change" (action el.setValue value="target.value")}}

Yes. Having this.setValue instead of el.setValue was a typo.

Btw, there is nothing with which we can replace that target.value hack in an Octane world, i.e. something to get rid of action?

I don't think so. I haven't seen a good pattern yet to replace that feature of {{action}} helper.

Closing in favor of #1203


Enables LRP to react on pod readiness.

Currently local redirect service won't react if backend pod becomes
unhealty.
This adds logic that checks the pod status within watcher and update LRP
configs accordingly.
To achieve the above goal, PodConditions are added into the slim apis to
allow for watching the "ready" condition of pods.
This PR also adds logic in LRP manager to restore service when no
backend is healthy.
Signed-off-by: Weilong Cui<EMAIL_ADDRESS>Fixes: #13168

test-me-please

All tests are passing, PTAL :)

LGTM. This is probably not easy to manually test, right? We should add some unit tests in follow-up PRs.

I've manually verified that this works after rebasing :) will add unit/e2e tests as a follow up PR if that's okay.

test-me-please

test-me-please

PTAL :)

test-me-please

All tests were passing on ** 31ba5a6**
Here's the diff with lasted commit:
cuiwl@cuiwl:~/go/src/github.com/cilium/cilium/pkg$ git diff 31ba5a6 9532d82
diff --git a/pkg/redirectpolicy/manager.go b/pkg/redirectpolicy/manager.go
index 0d87a8d9d..5a24fd87a 100644
--- a/pkg/redirectpolicy/manager.go
+++ b/pkg/redirectpolicy/manager.go
@@ -502,10 +502,6 @@ func (rpm *Manager) upsertService(config *LRPConfig, frontendMapping *feMapping)
        }
 }

-func (rpm *Manager) checkPodReady(pod *slimcorev1.Pod) bool {
-       return k8sUtils.GetLatestPodReadiness(pod.Status) == slimcorev1.ConditionTrue
-}
-
 // Returns a slice of endpoint pods metadata that are selected by the given policy config.
 func (rpm *Manager) getLocalPodsForPolicy(config *LRPConfig, podStore cache.Store) []*podMetadata {
        var (
@@ -529,7 +525,7 @@ func (rpm *Manager) getLocalPodsForPolicy(config *LRPConfig, podStore cache.Stor
                        }).Error("failed to get valid pod metadata")
                        continue
                }
-               if !rpm.checkPodReady(pod) {
+               if k8sUtils.GetLatestPodReadiness(pod.Status) != slimcorev1.ConditionTrue {
                        continue
                }
                if !config.policyConfigSelectsPod(podData) {


Task: integrating the new OTNS2 code into OTNS main branch

This issue is created to coordinate the inclusion of the new OTNS2 code (from https://github.com/EskoDijk/ot-ns) into the OTNS project main branch.
Possible methods to update: (nr 2 looks best perhaps, nr 1 is also fine)

PR that is squash-merged into main (and loose all the detailed commits that led from OTNS to OTNS2)
PR that is normal-merged into main (keep all the detailed commits history - even though some are a bit sloppy)
push new code directly into main branch

Important goals of first inclusion of new code:

Don't break the OpenThread CI which relies on checking out OTNS and running the new code in standard set of OTNS simulations.

Have a usable simulator that people can use (with GUI) - running on Linux and MacOS

Less important goals for first inclusion -- these could be addressed later with PRs and fixes if needed.

Docker builds

Have a complete tutorial/guide ready to work with OTNS2

Important design aspects of OTNS2 (to be evaluated here if okay to include!):

OTNS2 supports simulation of Thread 1.1, 1.2, 1.3 legacy nodes by means of including as subproject a few repository-branches that have the right code for this.  This means the number of subprojects now increased from 1 to 4. The nice benefit of this design (using separate subprojects) is that as part of CI of OpenThread, some simulations can be added where the new OT node has to interoperate with legacy OpenThread nodes.
The project now includes C/C++ code with a custom platform for RF simulations. This is in the directory ot-rfsim. This code is not intended to replace, or compete with, the simulation platform code in the openthread repo.  In the future some merge/combine might be considered, but it's rather complex to do this already now.  Note that the co-development of OTNS simulator code and C/C++ platform code in single repo, and single PRs/commits, has been very beneficial so far - usually some simulator features requires some handling code on the platform side and vice versa.

@jwhui Here's the kick-off to integrating OTNS2 into the OTNS repo in OpenThread. It would be nice if you could check the above proposal, and let me know if anything is missing!

@EskoDijk , thanks for continuing to drive this forward.
I am fine with option 2 using a merge commit and retaining the individual detailed commits.
I think it also makes sense to have submodule references for different Thread versions / legacy implementations.

@jwhui I've now added the draft PR as #530 . Note that this includes also all of the recent commits into main of OTNS, which were manually inserted as a commit. So effectively the PR is "rebased" to latest main.
The submodules I referred to are currently hosted in my repo EskoDijk/openthread as branches. If needed we can move those refs to branches within the openthread/openthread repo but since these don't exist there yet I've left it as pointing to my own branches. Can also be updated at some later time!

There is a test PR to test the OpenThread CI "calling" OTNS2 via otns.yml. This is to check that the PR code is able to perform its CI task. See https://github.com/EskoDijk/openthread/pull/6

The submodules I referred to are currently hosted in my repo EskoDijk/openthread as branches. If needed we can move those refs to branches within the openthread/openthread repo but since these don't exist there yet I've left it as pointing to my own branches. Can also be updated at some later time!

@EskoDijk , can we simply point the submodules to specific commits in the main openthread/openthread repo?

@jwhui We could do that, but the specific commit does require a minor patch for all case (1.1, 1.2, 1.3). The patch is shown here for example for 1.3: https://github.com/EskoDijk/openthread/commit/f271e322265de9ac19be2f5e047980c4cf8af952
What the legacy-versions build script could do is just apply the patch via a small .patch file. In that case we don't need to maintain any branches. I'm okay with either a branch solution or a patch!    Maybe there's another workaround for the problem that the patch solves?  (This is: newer Apple Clang compiler is very picky about its code and generates more warnings. The older code fails on that.)

The question was raised by @wgtdkp on PR #530 if we could split the single PR into features, to allow a more meaningful code review. This is certainly possible but raises some questions:

Splitting won't reduce the total volume of code (in the end) - is it still feasible to review this volume of code? (We could allow a longer time period for this like 1 year to get all the PRs in, if that helps)
Do we want to have a working set of (unit) tests after each PR? (I assume yes)
Do we want a working OpenThread CI (via otns.yml) after each PR is applied? Or is it fine if OpenThread CI otns.yml fails, we discover it post-merge, and fix as we go? Latter would be easier to do.

Another alternative is looking at individual commits - some of these are single squash commits coming from a PR with a particular feature. But there are also a lot of intermediate "work in progress" commits, which are easy to review/follow, but only make sense in combination with other commits that work on the same feature. And this includes also code that is later on removed again. So the alternative approach would have a larger code volume even due to many refactorings that happened along the way.
Finally, there's the approach of doing a review at a glance of everything and just accepting as is.

Finally, there's the approach of doing a review at a glance of everything and just accepting as is.

I am okay with this if you could add tests for the new features in OTNS2:
Note: this is version 2.x of OTNS. It offers additional features compared to version 1:

- Support for more accurate RF simulation of OpenThread nodes. This uses the OpenThread platform `ot-rfsim`, which specifically supports RF simulation for OT nodes. This C code is included.
- Selectable radio (RF propagation) models with tunable RF parameters.
- Runtime tunable radio parameters on each individual OT node. For example, CSL parameters or Rx sensitivity.
- Control of logging display from OT-node, using `log` and `watch` CLI commands. Logging to file per OT-node. The logging output can include any enabled OT-node log items.
- Detailed logging options for RF operations (at log-level 'trace') performed in the simulated radio, at 1 us resolution.
- See packets in flight: animations in the GUI with a duration scaled to the actual time duration of a packet in flight (works at low simulation speed only).
- Support for easily adding various Thread node types (1.1, 1.2, 1.3, 1.4, 1.4 Border Router).
- New graphical displays for overall node type statistics, and energy usage (beta - contribution by [Vinggui](https://github.com/Vinggui)).
- Extended set of Python scripts for unit testing, examples, and case studies.
- Key Performance Indicators (KPI) module that tracks counters and statistics for all nodes.
- Loading/saving of network topologies in YAML files.
- Custom startup scripts with OT CLI commands, defined in a YAML file.
- Additional ["WPAN-TAP"](https://exegin.com/wp-content/uploads/ieee802154_tap.pdf) PCAP format that captures channel information.
- Various UI look & feel improvements.

So that I can review the tests only. Going forward, I think we shouldn't develop in such a way that it diverges so much and comes back with a few hundreds commits. We suffered this in ot-commissioner where the multi-network functionality is added to ot-commissioner cli in a single CL with more than 10K code. I gave up doing code review for it so we got something like this merged into ot-commissioner: #define public private.

@wgtdkp Sounds like a good idea to start with the test code. All the current feature tests are in the scripts in pylibs/unittests.  I can check if everything is there. Notably, I know there are no tests for the "energy usage" functions that I integrated in order not to lose the code forever, but never got around to testing it and documenting it. I've marked this feature as "Beta".  If needed we can do in a next PR an update to mark the feature with a warning or so, until it's properly tested.
There's also a test file test_ccm_commissioning.py which is not invoked currently, but is present as a placeholder to add this feature in the future. In script/test you can see the invoked Python scripts.

#define public private
Ouch! At least it should be safer than #define private public ;-)

Ouch! At least it should be safer than #define private public ;-)

Oh, it is actually really #define private public. See here https://github.com/openthread/ot-commissioner/blob/64928aea7c2fdcd6efe646bdcd6638758390c59b/src/app/cli/job_manager_test.cpp#L45

@wgtdkp Are you okay with using / reviewing the current set of tests for the new features as included already in this PR? (And leave any remaining tests for the "energy" feature for a future PR.)
@jwhui  I recently reconsidered the proposal (see earlier comments) of using a .patch file to make small changes to specific historic code commits used to build 1.1, 1.2, 1.3 etc nodes. This has the disadvantages that patching brings the submodules into a Git "dirty" state which is normally unwanted. A branch is much cleaner in this respect.  So is it ok to use a branch for these particular submodules?


canvas only for specific user

Hello,
create package at first!!
One question: is there an option to restrict the canvas dashboard only for specific user (e.g. Auth::id == 1)? Thanks in advanced

ok, I've solved it over a custom middleware :)

Great! Glad you got it sorted @s72817!


Feature request: Select files to download

Sometimes, repo contains different files with different quantised qulity, and I want to pick only one
Examaple: https://huggingface.co/TheBloke/llama2_70b_chat_uncensored-GGUF

This is already possible using the filter option, please check the readme instruction


[CCXDEV-8782] Check behavior when kafka is disabled

Description
The idea is to check that the notification service doesn't send any notification if the kafka broker is disabled.
Type of change

New test scenario added into existing feature file
Breaking change (fix or feature that would cause existing functionality to not work as expected)
Refactor (refactoring code, removing useless files)

Testing steps
Local.
Checklist

[ ] Pylint passes for Python sources
[ ] sources has been pre-processed by Black
[ ] updated documentation wherever necessary

closing in favour of https://github.com/RedHatInsights/insights-behavioral-spec/pull/120


Remove .babelrc from npm package

Fixes issues with redux-actions in react-native. See here for more.

Thanks for your PR. I will close this PR, because this was added in https://github.com/acdlite/redux-actions/commit/38ba98cfd0f854a1ecc1932c9e8557647c6f7e68.


The scale of the canvas needs to be fully dynamic.

Canvas width and Height are constant, instead of a percentage of the parent component size.

Issue moved to react-volume-viewer library


feat(js-sdk): add Node.js SDK

What this PR does:
Which issue(s) this PR fixes:

Fixes https://github.com/mosn/layotto/issues/258
Special notes for your reviewer:

[x] State API
[x] File API
[x] Sequencer API
[x] Distributed Lock API
[x] Pub/Sub API
[x] RPC API
[x] Binding API

Does this PR introduce a user-facing change?:

@seeflood 所有已知的 API 都实现了，可以 review 了。

Thanks for your contribution!
I will modify the check license configuration and add license headers once the code review finished (to avoid be overwrited by your push) So ignore the CI warning for now :)

move into https://github.com/layotto/js-sdk

Hi @fengmk2 ,it seems that we still need part of your PR, like:

jstype in runtime.proto

configs/config_integration_redis_etcd.json

Makefile

Could u please submit a PR only including these ? Or should I just reopen and modify this PR

@seeflood new PR landed https://github.com/mosn/layotto/pull/316


Token function can't use color opacity modifier

Description
When in import token from '@/styled-system/tokens' and use like token('colors.primary.500/20') it cause type error Argument of type '"colors.primary.500/20"' is not assignable to parameter of type 'Token'
Link to Reproduction
https://play.panda-css.com/OsKzQNo8eC
Steps to reproduce

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

JS Framework
Nextjs(App router)
Panda CSS Version
0.34.3
Browser
No response
Operating System

[X] macOS
[ ] Windows
[ ] Linux

Additional Information
No response

yeah this one is not an issue, we support directly transforming the string token fn like border: "1px solid token(colors.amber.300/50) but not in the JS token fn (the one that you have to import from styled-system)
you can achieve the same result with string concatenation on your side with something like
const mix = (value: string, percent: number) => `color-mix(in srgb, ${value} ${percent}%, transparent)`
const tokenValue = token.var('colors.amber.300');
const value = mix(tokenValue)

I think it might be worth adding to the documentation somewhere, do you want to take a shot a it ? @jungai


[Feature]  There is a need to add annotation and labels to gateway trait features

I want to add some annotations and labels to the gateway trait, but I found the parameters do not have annotations and labels.

https://github.com/kubevela/kubevela/pull/6397


Update security.js

[Current coverage][cc-pull] is 69.68%

Merging [#101][cc-pull] into [master][cc-base-branch] will not change coverage

@@             master       #101   diff @@
==========================================
  Files            20         20
  Lines           188        188
  Methods          46         46
  Messages          0          0
  Branches         28         28
==========================================
  Hits            131        131
  Misses           57         57
  Partials          0          0

Powered by Codecov. Last updated by [ba9975a...607bb35][cc-compare]
[cc-base-branch]: https://codecov.io/gh/watson-developer-cloud/personality-insights-nodejs/branch/master?src=pr
[cc-compare]: https://codecov.io/gh/watson-developer-cloud/personality-insights-nodejs/compare/ba9975ac7b3682bf7467d840e4a5cfc70134e7e5...607bb35503b5d6b49ce9c6b21611f323f08c0cc6?src=pr
[cc-pull]: https://codecov.io/gh/watson-developer-cloud/personality-insights-nodejs/pull/101?src=pr

?

I need to disable the iframe restriction so that someone can have a demo next week while I'm out.

Aah, cool.


[vk] fix wait_semaphore not being used in present_surface

Fixes #issue
PR checklist:

[ ] make succeeds (on *nix)
[ ] make reftests succeeds
[x] tested examples with the following backends: vk
[ ] rustfmt run on changed code

bors r+


It then turned out that clockcal is preventing any notification messages from popping up, although the envelope and the messages themselves appear in the menus.
Removing clockcal fixed the issue, unfortunately, as I would love to use it.
I'm fairly new to the Bangle.JS so I don't feel confident in taking on the bug myself yet.
Thanks :)
Chris

Sorry it had to do with a corrupted bootloader that didn't run the Gadgetbridge connector in the "background".
I was new to the Bangle.JS and I just encountered it again and figured out the problem on my side.


[api] enable optional promotion, enable travis

circleci is bad with the race conditions for getting these working properly. but we are finally working on travis


User Feedback Mechanism

Description
Proposal: Develop a feature to collect user feedback directly from the platform. This could be a simple form or a more advanced feature that allows users to submit suggestions and report bugs.
Impact: This would provide insights into user needs and experiences, leading to better-informed development decisions.
Suggested Implementation:

A feedback form accessible from the main navigation.
Fields for user name, email, feedback type (suggestion/bug), and a comment box.
Store feedback in a database or a flat file.
Optionally, send a confirmation email to users.

Ready to Work?

[x] I want to work on this issue @phyleria

Hi @BigBang001,
Thanks for your suggestion! Currently, the main website code isn’t available for open-source contributions. However, you can still work on this feature independently. I recommend building it as a separate React/Next.js component with mock data. Once it’s ready, we’ll help integrate it into the Chimoney website. Let me know if you’re up for this approach or if you need any help getting started!

Hi @phyleria
Thank you so much for assigning this issue to me! I am excited to get started on developing the feedback mechanism and look forward to contributing to the Chimoney platform.
As part of Hacktoberfest, I’d like to request that this issue be tagged with the Hacktoberfest label so that my contribution can be counted toward the event. This would be greatly appreciated!
Please let me know if there are any additional requirements or guidelines I should follow. I’ll begin working on the feature and keep you updated on my progress.

Done ✅
No additional requirements for now. Thanks.

Thank you for the confirmation! I’ll proceed with the development as discussed and keep you updated on my progress.


Enable client-side accessor generation for strongly typed enum attributes

Problem
Attributes whose types are named enums did not have client-side codegen working right, so had it disabled.
Change overview
Enable it.
Testing
Manually verified that we are now generating the relevant accessor code on the client side.

/rebase

fast track: change  created and approved by domain owners


added an array check for defaults

Coverage remained the same at 97.805% when pulling d71ecded93ee5de3485388b80470d652eb798ed7 on c-harris:master into df0d81dd53c3d144fe04fbb7eb65c2561c02267c on Algo-Web:master.


Snakemake_dir not updated when running app in workflow mode

config["snakemake_dir"] is automatically set to whatever path is passed into SnakeBidsApp by the user. The presents a problem in workflow mode, as config["snakemake_dir"] is (I think) typically used to get properly resolved paths to the Snakemake app directory. Since the Snakemake app is being replicated in workflow mode, the path in "snakemake_dir" should be updated to the child app. Otherwise the child maintains an unhealthy dependence on its parent.

Yeah I noticed this recently too. Only thing I can think of in the short-term to set that variable is to modify generate_inputs to return it.
I am thinking a better long-term solution is to use a get_source_path function, in draft PR #102 for now, to allow users to get paths relative to the snakefile or rule file they are in. I originally thought snakemake's workflow.source_path function could do this, but it doesn't handle paths to directories, and caches the file locally (which @tkkuehn mentioned caused some issues).
I've tried this out and seems to work fine, but would need to add some more test cases if we go ahead with it.


Bump release and improve setup.py

I already pushed the new version to pypi.

@ustroetz I guess you deleted the requirements in setup.py due to #22 ?
Maybe for a future release it could be best to re-include this line and also include the requirements.txt file when packaging a release by specifying it in a MANIFEST.in file ?


CppWinRT.2.0.201102.2 causes midl.exe internal errors due to including .winmd files from multiple copies of the SDK

I updated to Microsoft.Windows.CppWinRT.2.0.201102.2 (was on 2.0.200729.8) and now get build errors in a console app project that contains a .idl file. midl.exe reports an internal error.
The response files contents are the problem, containing .winmd references from multiple copies of the SDK.
1>    C:\Program Files (x86)\Windows Kits\10\bin\10.0.19041.0\x64\midl.exe /metadata_dir "C:\Program Files (x86)\Windows Kits\10\References\10.0.19041.0\windows.foundation.foundationcontract\<IP_ADDRESS>" /winrt /W1 /nologo /char signed /env x64 /winmd "x64\Debug\Unmerged\MyClass.winmd" /h "nul" /dlldata "nul" /iid "nul" /proxy "nul" /notlb /client none /server none /target "NT60"  /nomidl @"x64\Debug\CppWinRtClient.vcxproj.midlrt.rsp" MyClass.idl
...
1>    Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.17763.0\windows.ai.machinelearning.machinelearningcontract\<IP_ADDRESS>\windows.ai.machinelearning.machinelearningcontract.winmd
...
1>    Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.18362.0\windows.ai.machinelearning.machinelearningcontract\<IP_ADDRESS>\windows.ai.machinelearning.machinelearningcontract.winmd
...
1>    Processing WinMD c:\program files (x86)\windows kits\10\references\10.0.19041.0\windows.ai.machinelearning.machinelearningcontract\<IP_ADDRESS>\windows.ai.machinelearning.machinelearningcontract.winmd

@jlaanstra is this related to your recent changes?

does 2.0.201102.2  include @jlaanstra 's change? how do I map commits to package versions?

I see I have that change

I think I spotted the problem, see my comment in the PR.

Thanks Chris. Feel free to contribute a fix. Johan's been the only (volunteer) maintainer of the msbuild support for some time and I'm sure he could do with some support. 😉

I tried changing that but it did not work.

Think I found it. See this comment.

This is probably related to https://github.com/microsoft/cppwinrt/issues/785

I'll have a look tomorrow.

I have a repro. Will add this as a test case to the NuGetTest solution.

2.0.201113.7 has now been published.

Feel free to reopen if this is still an issue.


IDE can support multiple canisters

Reported by @kritzcreek
Resolving canister aliases in the IDE
Problems:
At this point in time the Language Server (called LS going forwards)  uses the same set of arguments as moc, meaning all canister aliases  have to be given statically on startup, and all .did files have to  be put into the same directory for the LS to find them
When the LS starts up .did files might not have been generated and  the canister ids for canisters in the project might not be known yet.
DFX generates temporary files during the build process that the  long-running LS can't read.
This means currently the LS doesn't work well in multi-canister  projects (It doesn't work for any canister that imports another one)
Solution 1:
DFX outputs the required information for the LS to a known location  in a persistent fashion. This would include:
canister alias - entry point mapping
canister alias - id mapping
a single path where all IDL files get generated (and garbage collected!)The two canister alias mappings can be used to invalidate out of dateIDL files from the LS, which can then produce more up-to-dateversions on the file system, or update them in-memory.The garbage collected bit is important because the LS can't tell whichidl files are for external services and which are for canisters thatused to exist in the local project but have been removed by the usersince.
Solution 2:
The LS reproduces enough of DFX's understanding of a project to be  able to handle the dynamic IDL generation on its own
This means moving more knowledge about what a Motoko project is  into the compiler, so would need design work

Resolved by a combination of https://github.com/dfinity/sdk/pull/2375 and https://github.com/dfinity/vscode-motoko/pull/64.


Playwright tests seem unreliable

The Playwright tests seem to fail on a regular basis, even if the code itself is good:

Closing this as it duplicates #846


support GPU inference in torchscript model for v2.5 / v2.6

This PR works for master branch, v2.5 and v2.6 release
A non-trivial PR to support GPU inference in torchscript

Load CUDA kernels as non-python modules; this is needed for torchscript compilation
Refactored CUDA APIs as functions that return output as tensors, instead of procedures that modify some passed-in tensors.
Added a workaround in case TS tries to locate and compile CUDA methods on machines that don't have CUDA / GPUs
The refactored code has passed the forward() & backward() test.
I also checked the outputs are the same for the non-torchscript and torchscript versions of the same model.

What pytest tests do we have for the code affected by these changes? I understand we have to run such tests by hand, since CCIE doesnt do that for us.

What pytest tests do we have for the code affected by these changes [edit: or at least, an automated test script, such as bash, that I could run by hand]? I understand we have to run such tests by hand, since CCIE doesnt do that for us.

@hpasapp The existing unit tests should cover most of the code paths for non-cuda usage. I also modified the C++ test to ensure the changes work for C++ and for CPU inference.

Also @cdfox-asapp feels we don't have to merge this PR into master, since we need to merge 3.0.0 dev into master anyway. The changes are identical to the PR for v3.0.0. I can make a release on this branch for Chris's project.
What do you think? @hpasapp

Advantage of not merging this branch into master? (not merging it means an additional branch to maintain and reason about.)

🎉  thanks @hpasapp @cdfox-asapp !


feature(log): Logger

#4

All Logux lines should contains Logux word. Because Logux will be used with Redux. And Redux have own logger too. So developer should understood where this console.log came from.
Sync: error code it for machines, not human. For example, errors have good human readable description error.description. Same this other messages. Image that you creating a help for junior developer with only 3 months development experience.
Should we allow developers to disable some messages type? How redux-logger deal with it?

Also, don't forget about docs in README.md. Docs is the most important part of open source (even more than code).

Thanks! Just wanted to ask about format of messages, but forgot
3. It's a good idea. I think we could add an optional second argument log(sync, option) to have possibility configuring logger. I've never worked with react, especially with redux-logger =) Probably I will look redux-logger tomorrow

We could add options later, but right now we should make text better.
For example, Logux was connected to ws://<IP_ADDRESS>:31337. Or Logux server send error: TImeout instead of Logux Sync: clientError.

Think about console as a UX. Try to explain what happen. Try to understand (or ask question for me) why developer will need this message (like connect is needed to understand what server URL is used).

Yeap. Much better. But we need full action in message (just send it as second argument, so DevTools will show nice preset).
Also using localNodeId isn't the best way. Action could be created on server and then synchronized to client. Use meta.id[1] to get real action creator.

I need help with connect. If it ClientSync, then we could detect url by sync.connection.connection.url- looks bad. And what about other cases?

You don't need to set localNodeId everywhere. Imagine real usage — you will have same nodeId again and again in your log. As a developer, will you happy with this messages?
Ask yourself, what information do you need for each event. For example, in connect event server URL will be useful.
So stop to write code, let's think first. Write what information we should print for each event.

No, it will be annoying

Logux was connected to url.
Logux changed synchronization state to state.
Logux remoteNodeId sent type error (description).
Logux localNodeId? received type error (description).
Logux added new action type to log. action meta?

Don’t write exactly text. It blocks your mind on current implementation.
Clean your brain. Forget about current implementation and code.
Ask yourself what will you need on every event? What is a context? What is a possible issues, that developer will try to fix?
And write event → data list.

connect - who, where and when connected
state - previous and new states. as addition - event, which provided new state
error - detailed description and place where it happened
add - who added this log and detailed info about this action

last chance =D

Logux connected to url.
Logus state is state.
Logux meta.id[1] added type action. action
Logux server sent error description. remoteNodeId

All this messages are not related with your message https://github.com/logux/logux-status/pull/6#issuecomment-279817653

Logux localNodeId are connected to remoteNodeId at url (you told who).
Logux change state to state (you told about prev state, but I think developer have messages history for it).
meta.id[1] added type action to Logux: action (If meta.id[1] === localNodeId write “type action was added …”).
Logux server sent error: description (we display server error in connected message)
Logux error: description (local errors should have shorter prefix)

Also don’t forget about new clean log event: https://github.com/logux/logux-core#clean

Also we need meta in add event. It contains many important b data for debug.

Thanks! I'm just hopeless
And what prefix for local errors do you mean?

Thanks! I'm just hopeless

Cult of Martians tasks should train you something, right ;).

And what prefix for local errors do you mean?

Just Logux error:

Cult of Martians is a really good thing!:+1:

😄 Waiting for messages update and options to disable messages types. And we are ready to merge.

@andrewmnlv do not do merge command ;).

Great! Tiny thing to fix — clean could be done only by current log. So there is no need to meta.id[1] + ' clean ' + action.type + ' action from Logux:.

Done, I reset a cache.

Also error should be printed by console.error, not console.log.

Never mind, I will fix it by myself. Anyway you spend so many time. Thanks, good work.

already add console.error and push it =)

Thank you for your patience :smile:


Emit events when g-image is loaded

Summary
I'd like to be able to tell when an image has finished loading via a g-image component, so that I can hook other things on to it, such as a lightbox zoom.
Basic example
<g-image src="~/image.png" width="500" @loaded="imageLoaded" />
Motivation
Being able to perform other tasks on the page or image once it has loaded, e.g. knowing the final size of the image element, hooking on things such as the mediumZoom library etc.
Ideally, there would also be a way of hooking on to these events through images that are parsed within markdown.

You can try to use the load event. But you'd need to check if event.target.src is a URL because the inline SVG image will also trigger the load event.
<g-image src="~/image.png" @load="imageLoaded" />

imageLoaded (event) {
  if (/^data/.test(event.target.src)) return
  // image loaded
}


Something EN pin

@corygrant knows

One of the PCBs @rusefillc got from JLCPCB had a strange issue where the EN pin on the TPS56339DDCR (U1) buck converter had a 2mohm resistance to ground.
The EN pin should be completely floating (see section 7.3.2 of the datasheet).
This led to lots of power issues:

Power not turning on
Power fluctuating
Lots of noise from the board
Power only turning on when touching the EN pin with my finger

To fix this I cut and removed the pin and now the power is stable.
I'll update the PCB to remove the pad for EN (pin 5).


Lexical Context error in serverless Next.js app

Link to reproduction
https://github.com/wiggindev/payload-lexical-rsc-repro
Describe the Bug
@payloadcms/richtext-lexical imports createContext. Importing it into payload.config.ts will throw errors in server components.
To Reproduce

yarn create next-app
Downgrade to latest v13.x (currently 13.5.6)
yarn add @payloadcms/next-payload payload
yarn next-payload install
yarn add @payloadcms/richtext-lexical
Add editor: lexicalEditor({}) to payload.config.ts
Call await getPayloadClient() from any server component

When you open the admin panel, it will work as expected. When you open any server component page that interacts with getPayloadClient, it throws createContext only works in Client Components. Add the "use client" directive at the top of the file to use it.
Payload Version
2.1.1
Adapters and Plugins
richtext-lexical

Thank you for reporting this! I've pushed out a fix which will be available in the next version :)


"Can't resolve reference" when using nested $ref

What version of Ajv are you using? Does the issue happen if you use the latest version?
6.5.4
Ajv options object
{
  allErrors: true
}

JSON Schema
{
  "$id": "http://example.com/example.json",
  "type": "object",
  "definitions": {
    "datetime": {
      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T ?[0-9]{2}:[0-9]{2}:[0-9]{2}(Z|[+-][0-9]{4})?$",
      "type": "string",
      "examples": [
        "2017-07-18T00:00:00Z"
      ]
    }
  },
  "$schema": "http://json-schema.org/draft-07/schema#",
  "properties": {
    "request": {
      "$id": "/properties/request",
      "type": "object",
      "properties": {
        "date": {
          "$ref": "#/definitions/datetime",
          "title": "date",
          "default": ""
        }
      }
    }
  }
}

Sample data
{
  "request": {
    "date": "2018-05-03T00:00:00Z"
  }
}

Your code
const ajv = new Ajv({
  allErrors: true
});
ajv.validate(definition, data);

Validation result, data AFTER validation, error messages
can't resolve reference #/definitions/datetime from id http://example.com/properties/request

What results did you expect?
When using the ajv-cli library (ajv validate -s def.json -d data.json), it works and says the data is valid, but when using the node package it gives the error as shown above
Are you going to resolve the issue?
not sure what to do, is it a config issue?

I suspect ajv-cli can be ignoring $id - it needs to be upgraded.
The problem is that inner $id (“/properties/request) changes base URI and with the changes base $ref cannot be resolved. Not sure what was the intention to have that $id, but in its presence relative $ref won’t work, it has to be absolute (or at least “/example.json#/definitions/datetime”)


Consider designing bootc as a library to be used by installer applications

Right now bootc only seems envisioned as a simple CLI application to install and lifecycle an ostree based system using ostree containers as the install/update payload. Given the inevitability that a use case will necessitate a higher level "installer", bootc could have an API available to use in a higher level rust application that could function itself as the installer. This would enable a distro to create a proper installer application while fully integrating the capabilities of bootc (IE: more evolved than a shell script installer).

The vast majority of the code already lives as a separate library crate under https://github.com/containers/bootc/tree/main/lib.  The current bootc cli is really just a thin wrapper around the library.  It looks like we don't currently publish that on crates.io for general use, but we could start doing so.  At the very least if someone wanted to use it as a dependency today they could do so via a cargo git dependency.

Yeah I think my point was to perhaps consider this as more of a prominent feature. Obviously it could be included somehow today but the focus seems on it being a standalone tool at the CLI level.

Having higher level installers wrap/integrate with bootc install was very much a big design goal from the start. I think we have the essentials of that now with bootc install to-filesystem being there.
This intersects with both #440 and #522
What specific issues for an installer though do you forsee being improved with an API versus a fork/exec model? The main ones are usually things like progress reporting, but we could also do that via either e.g. capnpnp or varlink over a fd.

Better integration potential and not bringing in a secondary IPC scheme to support (thus requiring whatever interacts with bootc to also support said scheme).
I could agree that just using bootc as an external process checks all the boxes but unfortunately the CLI output right now is not very useful/helpful for integrating with an installer that uses install to-filesystem. See #536.
If the idea is to keep relations with bootc to being something that's just exec'd via the shell or some wrapping application there need to be serious improvements to the ability to configure it to to produce useful, parseable output (such as outputting a path to the ostree deployment directory -- there are probably others here). ostree container image deploy has a flag to get the deployed commit hash. Accoutrements like this are needed for full viability of this model. You could probably cover the vast majority of needs with a few options to tailor the outputs.
For the cases where the bootc CLI interface doesn't cleanly provide what's needed though, an API affords the installer creator maximum ability to get whatever is needed pretty much just subject to the limitations of the language and libraries they're willing to bring in.
I'm also not a huge fan of just creating more CLI apps that output json. It is common but feels like a unix anti-pattern to me. Doing this for a CLI app implicitly required that jq is included in the build if interaction is via shell or bootc gets exec'd from a wrapping application that can deal with the json. Clean simple parseable text ouput would be best for CLI/exec interaction, a la what you can configure from dnf and rpm.

I'd tend to lean to mark this as a dup of #522 per above.

I am certainly not suggesting bootc needs an IPC abstraction beyond what you get from stdin/stdout. If bootc isn't a long lived daemon process I'm really unclear what additional IPC interfaces get you or your users. Either a clean and useful CLI interface or actual native rust API. A whole other IPC interface seems like more to support for minimal additional value but a rust API could be low cost (sounds like bootc is already a good chunk there). Same goes for a CLI. Perhaps separate the business logic into a crate and create a CLI that just uses the available API from the crate. That is all I am really suggesting here.
The ostree-ext API already has a lot but one shouldn't have to create a completely new (competing?) tool from that level up.

I am certainly not suggesting bootc needs an IPC abstraction beyond what you get from stdin/stdout. If bootc isn't a long lived daemon process I'm really unclear what additional IPC interfaces get you or your users.

Note that varlink in particular is very much designed to operate over a socketpair() between a parent and child process.  When people hear "IPC" they often think about the other end being e.g. a systemd service listening on a socket (or all the way to a DBus like model).  But, so can capnpnp (and for that matter, dbus can operate point-to-point, though it is inherently always bidirectional).

Clean simple parseable text ouput would be best for CLI/exec interaction, a la what you can configure from dnf and rpm.

What text output are people parsing from those tools?  With rpm there's stuff like --queryformat, sure; but for things like installs - I'm not aware of much that's intended to be machine-parsable from either tool, especially dnf.

I am certainly not suggesting bootc needs an IPC abstraction beyond what you get from stdin/stdout. If bootc isn't a long lived daemon process I'm really unclear what additional IPC interfaces get you or your users.

Note that varlink in particular is very much designed to operate over a socketpair() between a parent and child process. When people hear "IPC" they often think about the other end being e.g. a systemd service listening on a socket (or all the way to a DBus like model). But, so can capnpnp (and for that matter, dbus can operate point-to-point, though it is inherently always bidirectional).

Still not convinced an IPC would really vastly improve the user experience. Maybe for some real time updates like status or something as you suggested. Not my need though. That is not the problem that generated this issue though.
Definitely think you could get the same effect as an IPC from an API though, at lower cost, and leave the IPC business (if such business is even warranted) to whatever installer application resides above bootc. Instead of choosing what IPC will be used and dictating this to downstream users. I only see more problems this route.
At the moment the bootc CLI is too simplistic to really be of great use to a wrapping installer script or an application that would exec this off and just get to deal with stdin/stdout. One should not have to ostree admin status their way to finding the deployment directory when bootc internally uses that info but just doesn't make it accessible to the user. This is a problem.
Seems like it would be pretty easy to have bootc output an installation summary file somewhere or suppress the status messages (-q flag?) and produce it on stdout? These are the types of improvements that would enhance the user experience.

Clean simple parseable text ouput would be best for CLI/exec interaction, a la what you can configure from dnf and rpm.

What text output are people parsing from those tools? With rpm there's stuff like --queryformat, sure; but for things like installs - I'm not aware of much that's intended to be machine-parsable from either tool, especially dnf.

Parseable might've been the wrong word. Point is clean text output with useful information in it that can be readily used in an ad-hoc shell command or non-interactively in a script. Currently bootc does not today really have much to offer here for installing. bootc status tries to provide this but it only works for a booted system. Maybe bootc status should grow some features to provide install details before first boot?
rpm queryformat is a good example of how that tool can be configured very flexibly to produce useful output for routine shell tasks/scripts. dnf supports the same formats with repoquery. The systemd CLI tools often have similar options to configure output for non-interactive use in scripts.


Rename PKU Beta to API?

Is your feature request related to a problem? Please describe.
A lot of users view pokemon unity framework as if it were a game development project, when in actuality it's a framework for users to apply their own skills to develop a game using tools that reduce repetitive work and tedious labor. It's not a "game" so there is no, "when are we going to be able to play it?" questions that should be asked/answered, and more... "when will it work for this [insert something visual a user has created, example: a map] that i made?"
The whole reason and purpose behind a "demo" is not to say: "this is the game we're making" but to express "this is something YOU can make too, if you applied this to your project"
Describe the solution you'd like
Maybe instead of calling it a "framework" (which may hold a bit of confusion in it's own way), we just call it an "API" instead? At least then, when we say "this is unstable" it can better translate from "it doesnt work for your needs" to a better statement that resembles "it isnt giving the correct results it should right now."
Describe alternatives you've considered
I've considered PKU building both sides of a project (the front-end and back-end). But it's extremely difficult to focus on both sides simultaneously, without having any set blueprints or our layouts in place (considering all the different opinions and various options on how to approach things). For a while the project hasnt made a lot of progress on front-end side of things. Maybe it might be best to leave the creative input in the hands of the end-user, instead of the PKU develop team deciding in stone how things should be done?
Maybe it might be best to use GitHub to offer the connections and channels that a lot of users are lacking and in-demand of: source code and backend developers. Every time a new pokemon project is started, they're immediately done in secrecy, so their code isnt shared, and every project is in need of a developer/programmer (because finding someone capable of committing to something of this magnitude for an indefinite amount of time is also a challenge).
Additional context
At this point, PKU Beta is capable of supporting MANY scenarios and project application. But the obstacle that's keeping users from moving forward is that they're waiting for a "complete" product to be shipped, when the product itself requires end-users to do their part as well. The demo is only a "sample" to say "this is how we did thing", but the end user doesnt have to replicate our approach. They can do things their own way, and just apply our work to their progress. (That way it's like having your own development team of programmers, when you know absolutely nothing about programming).

Whenever I think of an API, my mind immediately jumps to REST Services and integrations into business applications. While @GMR516 raises a good point about the definition of what an API is, @herbertmilhomme is absolutely correct that it should be classified as an API. However, should you call it this? Probably not, because you want to stay focused for your end goal. Leaving it as an API or even a "Studio" (I think GameMaker) detracts from the vision of the project.


dns cache: remove main thread assert in cache lookup

Commit Message: dns cache: remove assert at this layer
Additional Description: Envoy Mobile has logic that executes on the main thread but may not have the necessary state to pass this assertion. This change maintains the existing convention that callers of the DNS cache manager should validate their thread context independently.
Risk Level: Low
Testing: Local & CI
Signed-off-by: Mike Schore<EMAIL_ADDRESS>

@mattklein123 agreed. Issue is here https://github.com/envoyproxy/envoy-mobile/issues/1842


feat: add ngenuity port

Description
This PR adds the aura-theme port for ngenuity (Hyperx Software rgb controller) 💜
Assets

Checklist

[x] PR description included
[x] I've read the documents
[x] I know I shouldn't change any files in the packages folder manually
[x] I've attached an image to the icon of the app that this port is related to
[x] I've attached a screenshot with a good zoom in fullscreen showing this port in action
[x] I've created or commented in an issue related to this port asking to work on it

Hi @joaopealves , after fixing the points in the review, don't forget to update the main readme with the ngnuity app in the list. Thanks 💜

@joaopealves Thank you so much bro! 💜


upgrading TF to 1.9.0

Describe your changes

Issue ticket number and link
Type of change 🧩

[ ] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] Documentation update
[ ] Other (please explain in the description section above)

Checklist before requesting a review

[ ] I have performed a self-review of my own code
[ ] I have double checked this work does not include any hardcoded secrets or passwords
[ ] I have made corresponding changes to the documentation
[ ] I have provided details on how I have tested my code
[ ] I have referenced the ticket number above
[ ] I have provided a description of the ticket
[ ] I have included unit tests to cover any testable code changes

Superseded by: https://github.com/Planning-Inspectorate/appeals-back-office/pull/512


Difficulties with joining complex style statements

I would like to first extend my gratitude for this library, it is very cool and easy to work with.
However, I have been having issues when using :style with multi-line return values.
I am going through the gum demo and implementing it using bblgum, but I can't figure out how I should handle the last :join statement as it is combining two multi-line :style results.
If I am not joining, the solution posted by the author in this issue works fine. But alas, not when joining.
The following snippet is what I am trying to recreate. I have added some variables so that it can be copy/pasted into a bash environment to test. The complete script is available at the link provided in a previous paragraph.
Also I removed an exclamation mark, as it was causing issues directly in the terminal, but that is besides the point.
NAME="Foo"
GUM="Bar"
NICE_MEETING_YOU=$(gum style --height 5 --width 25 --padding '1 3' --border double --border-foreground 57 "Well, it was nice meeting you, $(gum style --foreground 212 "$NAME"). Hope to see you soon.")
CHEW_BUBBLE_GUM=$(gum style --width 25 --padding '1 3' --border double --border-foreground 212 "Don't forget to chew some $(gum style --foreground "#04B575" "$GUM") bubble gum.")
gum join --horizontal "$NICE_MEETING_YOU" "$CHEW_BUBBLE_GUM"

Any assistance appreciated.

You know what, I think posting this issue was enough to figure it out by myself. I simply used clojure.string/join and there you have it.
(let [name (:result (b/gum :style ["Foo"] :foreground 212))
      gum (:result (b/gum :style ["Bar"] :foreground "#04B575"))
      nice (str/join "\n"
                     (:result (b/gum :style [(format "Well, it was nice meeting you, %s. Hope to see you soon!" name)]
                                     :height 5
                                     :width 25
                                     :padding "1 3"
                                     :border "double"
                                     :border-foreground 57)))
      chew (str/join "\n"
                     (:result (b/gum :style [(format "Don't forget to chew some %s bubble gum." gum)]
                                     :width 25
                                     :padding "1 3"
                                     :border "double"
                                     :border-foreground 212)))]
  (b/gum :join [nice chew] :horizontal true :as :ignored))

Hopefully this can help someone else.

There is not such function in the library, but it might be helpful to define something like this for extensive scripting:
(defn gumrf
  "Run a b/gum and return first result"
  [& args]
  (->> args (apply b/gum) :result first))

Define this on top of the file and save yourself a lot of boilerplate.


Basic 2D representation component

Try to prepare a component that allows to display 2D spectra.
The data that is generated and that should be displayed is present in the testcase:
https://github.com/cheminfo/nmr-displayer/blob/f6f56cfb0c9d719ca951fb0f2427232cc9c68a00/src/data/data2d/__tests__/Datum2D.test.js
let contour = datum2D.getContourLines();

This is really the beginning and we will discuss after about the interactions with the 2D Component.
In order to display correctly the 2D you will also need the min and max X and Y that is present in datum2D.data

@michaelwenk @steinbeck Do you have something we could use ? We would like to be able to display soon a 2D spectrum.

Michael is working on this.
I was/am assuming that you guys communicate regularly.
@Michael: Did you respond to this?
Kind regards,   Chris
—
Prof. Dr. Christoph Steinbeck
Analytical Chemistry - Cheminformatics and Chemometrics
Friedrich-Schiller-University Jena, Germany
Phone Secretariat: +49-3641-948171
http://cheminf.uni-jena.de
http://orcid.org/0000-0001-6966-0814
What is man but that lofty spirit - that sense of enterprise.
... Kirk, "I, Mudd," stardate 4513.3..

On 10. Feb 2020, at 18:09, Luc Patiny<EMAIL_ADDRESS>wrote:
@michaelwenk @steinbeck Do you have something we could use ? We would like to be able to display soon a 2D spectrum.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

@lpatiny For now, I developed a very simple project which is able to load in a 2D NMR jcamp file and display contour lines (svg with paths as contour) for a certain contour level. The next step is to replace the contour level increase/decrease buttons by a scrolling on the mouse.


Add option to include non-latin characters

First of all, awesome library!
I would like to open a discussion for adding an option to support for non-latin characters.
As far as I see it,  99% of browsers would parse this example correctly without messing up the route:
http://www.my-site.com/article/עוגת-בננה-זה-טעים-מאוד
http://www.my-site.com/article/香蕉蛋糕都不错
http://www.my-site.com/article/كعكة-الموز-جيدة

If there's any reason this shouldn't be allowed, I would really like to learn why.
Thanks!

The speakingurl already supports Arabic and Burmese chars as well.
I believe if you send a Pull Request with support for the others languages you need, will be very welcome for this repo.

PS: Maybe the answer will help you as well https://github.com/pid/speakingurl/issues/61

@leocaseiro This converts Arabic characters to latin characters. Not so good for seo

As far as I see it, 99% of browsers would parse this example correctly without messing up the route:
If there's any reason this shouldn't be allowed, I would really like to learn why.
If you don't need transliterated URLs, go with it :-) otherwise you can use speakingurl
That speakingurl is available, means not, that you have to transliterate your URLs ;-)

I would like to open a discussion for adding an option to support for non-latin characters.
That's a good point, to support non-latin characters as-is, and only replace special characters.
I will add this on the todo list, thanks

Thanks @pid!
Can you think on top of your head of a Regex phrase that might do the trick?

Can you think on top of your head of a Regex phrase that might do the trick?
obviously... but I will check

Perhaps something like this:
[\u0590-\u05FF\u0600-\u06FF\u0400-\u04FF\w\s\d]
This covers hebrew, arabic and Cyrillic


use int32_t to define int and int64_t to define long. in VC long is 3…

in vc, long is just 32bit. I think it makes more sense to use int32_t to define kInt and use int64_t to define kLong

This was used for redirect the calls to MPI. Maybe I was wrong on this. Shouldn't MPI_LONG be of same type as long in compiler? or not

I see. MPI specification requires that MPI_LONG = long in C. Then we should
define MPI_LONG_LONG, since size_t is defined as long long in VC
On Wed, May 20, 2015 at 10:14 AM, Tianqi Chen<EMAIL_ADDRESS>wrote:

This was used for redirect the calls to MPI. Maybe I was wrong on this.
Shouldn't MPI_LONG be of same type as long in compiler? or not
—
Reply to this email directly or view it on GitHub
https://github.com/dmlc/rabit/pull/13#issuecomment-103727545.

--
HONG Chuntao
System Research Group
Microsoft Research Asia

ic, can you update the PR for this?

sure
On Wed, May 20, 2015 at 10:27 AM, Tianqi Chen<EMAIL_ADDRESS>wrote:

ic, can you update the PR for this?
—
Reply to this email directly or view it on GitHub
https://github.com/dmlc/rabit/pull/13#issuecomment-103729785.

--
HONG Chuntao
System Research Group
Microsoft Research Asia


Ignore extra whitespace in node texts

As discussed in https://github.com/gnapse/jest-dom/issues/9#issuecomment-380500371

This looks unrelated, and perhaps there's a brittle test in the wait-for-element part. I just ran npm run test:update locally and it all passes with full coverage. Plus a change to the README breaking a test makes no sense.

BTW (unrelated but) have you considered adding npm run test:update to be run in a pre-push hook in your projects?

I've restarted the build. Yes, that's odd. Hmmm...

BTW (unrelated but) have you considered adding npm run test:update to be run in a pre-push hook in your projects?

I have not! Hmmm... I wonder if I could make it interactive. If there are snapshot differences, ask the user if they'd like to cancel the commit or update them... Not sure that'd be possible with lint-staged though...

The restarted build passed! 😱

Uh oh... We should probably look into that.


Add development norm for squash merging

The Problem:
We've never stated our preference for "squash merging"
The Fix:
This PR adds a line to the development norms document that specifies our preference for this type of merge.

 Thank you for your submission, we really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.


Ensure that DOM nodes do not override global PyViz object

A really stupid bug meant that if there was a header tag in a JupyterLab notebook it would end up being added to window.HoloViews and alias it to windows.PyViz, this makes sure these variables are overridden if they reference DOM nodes.

Horrible bug! Fix makes sense though...
Anything more to do here or should I just merge?

Should be good to merge.


fix(ui): loading state shows up when switching between tabs (assets)

To reproduce:

sign in with an account
click on the "Data" tab
click on the "Portfolio" tab

@fadeev, @marinhoarthur,
Is this issue related to what we discussed regarding reloading components when changing a router? I wonder if solution can be in one task. Wdyt?

For now let's fix skeleton-forever. Soon enough we will be refactoring overall fetching of data.


Add W003 testcase

Has local zipped content because we need to unpack an empty directory which git cannot handle

Pull Request Test Coverage Report for Build 155

3 of 3 (100.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage increased (+0.1%) to 91.886%

Totals

Change from base Build 153:
0.1%

Covered Lines:
1189

Relevant Lines:
1294

💛  - Coveralls


[icons] Sync the Material Icons

Updated the icon set with the latest from Google
Preview: https://deploy-preview-33988--material-ui.netlify.app/material-ui/material-icons/

Yes, I think we should. @hbjORbj, please make sure to include it in the release notes.


AttributeError: module 'osmnx' has no attribute 'footprints_from_place'

#### Problem description (what did you do, what did you expect to happen, and what actually ####happened)
Hello everybody,
I am trying to run the code as per Github example:

gdf = ox.footprints_from_place(place='Emeryville, California, USA')

Unfortunately I got the following error:
AttributeError                            Traceback (most recent call last)
 in ()
----> 1 gdf = ox.footprints_from_place(place='Emeryville, California, USA')
AttributeError: module 'osmnx' has no attribute 'footprints_from_place'
I also checked similar issues with module footprints_from_place, but I was pretty much unable to find a viable solution.
Should I upgrade OSMNX to version 0.9?
Please provide a valid path solution. Thanks in advance. Andrea
#### What operating system, architecture, Python version, and OSMnx version are you using?
 The buildings module will be fully removed in v0.10.
If you're using OSMnx<0.9, then use ox.buildings_from_place. If you're using OSMnx>=0.9, then use ox.footprints_from_place. See the documentation for more usage details.

Hi @gboeing , many thanks for the clarifications,
I will use the code suggestions, you sent me. Sorry if I do not have read carefully. Regards.
Andrea

It is really helpful for me! Thanks a lot.

Hi,
I am trying to run this code on Jupyter on mac which I did it before, but I don't know why it does an error like this:
AttributeError: module 'osmnx' has no attribute 'distance'
and the code itself is:
incr = 0
same_count = 0
for ind, row in nearestNodes_under2000.iterrows():
u, v, key = ox.get_nearest_edge(Graph, (row['Point_X'],row['Point_Y']))
nn = min((u, v), key=lambda n: ox.distance.great_circle_vec(row['Point_X'],row['Point_Y'], Graph.nodes[n]['y'], Graph.nodes[n]['x']))
if row['NN_ID'] == nn and ['NN_Distance'] < 2000:
    print(int(row['NN_ID']), " -> ", nn, " - X:", Graph.nodes[nn]['x'], " - Y:", Graph.nodes[nn]['y'])
    same_count += 1
    print ("They are same:", same_count)
else:
    nid = int(row['NN_ID'])
    print("Diff: ", nid, " -> ", nn, " - X:", Graph.nodes[nid]['x'], " - Y:", Graph.nodes[nid]['y'])
incr += 1

could you please help me what can I do to solve it.

@Mehrdadbabazadeh17 this isn't related to this issue (deprecation of buildings module). Please open a new issue and completely fill out the new issue template and we can take a look.

ox.footprints_from_place

@gboeing As far this, I do not seem to solve the problem.
ox.footprints_from_place(place)

AttributeError: module 'osmnx' has no attribute 'footprints_from_place'

Version:
print(ox.__version__)
1.1.2

@arilwan this is an old thread referring to now-deprecated modules from before v1.0. Use the geometries module and see the usage examples repo for demonstrations of functionality.

but now I can't find either of them! module 'osmnx' has no attribute 'footprints_from_place' and module 'osmnx' has no attribute 'footprints_from_place'

@Alouette-29 see the comment previous to yours.


The logout URL specified in the security configuration should be available

Description of the bug
After doing logout() you typically want to refresh or redirect to another URL so that the user does not remain on a page she does not have access to. In the Spring Security configuration you provide a "logout URL" which is the URL to redirect to after logout. This URL should be available on the client side. Right now you need to manually enter it in the client side code.
Versions:
- Vaadin / Fusion version:21 alpha 5

Needs to be defined:

How to exactly send the configuration properties to the client, preferably when bootstrapping the application (e. g., as index.html response content)
Define the client-side API for accessing the properties

The logoutUrl is an example of server runtime configuration, so it is practically not available on build time.
Other related use cases:

user-defined custom properties, for e. g., sending API keys / ids for third-party service APIs
other Fusion-related configuration (endpoints path prefix, etc.)

Note that we have a global namespace Vaadin.TypeScript populated in the index.html script. One idea is to use it for sending the properties, and define a user-facing API around it for accessing those from TypeScript.

Let’s make a 3-day research to define and prototype the unknowns here.


Debug Datum Runs Interactively

What is the goal / desired outcome?
I want to see what's going on with my code in the pach environment, generally to debug when something is not working as expected
If there is a way to accomplish this today via workaround, what does that require?
If I actually understand how inputs work, I can run my pipeline's container with test data for a datum locally, using docker volumes to mount in the correct input. Often, though, the problem is that I have misunderstood what data will be presented to my code, in which case this won't really help. To debug that, I can write and package up a container that will log output to inspect the file system, but that's pretty tedious.
glob-file can sometimes help to see what data will be available in a given run, but it falls down if they have anything more complicated than a single PFS input, and also doesn't actually set up the env that their code will/did see
(Optional) What is your proposal for a feature to solve this?
pachctl debug-datum puts the user into an interactive session to explore the container set up as it was when that datum was run:
$ pachctl debug-datum <job-id>  <datum-id>
Launching container...
Loading data...
Running default shell (/bin/bash)...
root@<datum-shorthash>:/pfs$ ls  # data has been mounted into the container
input-1
input2
out
root@<datum-shorthash>:/pfs$ echo $PACH_JOB_ID  # all job-time env vars are set
<the id the job in which this datum was run>
root@<datum-shorthash>:/pfs$ echo $PACH_OUTPUT_COMMIT_ID
<the id of the commit to which this datum's results were written>
root@<datum-shorthash>:/pfs$ echo $input-1_COMMIT
<the id of the input commit>
root@<datum-shorthash>:/pfs$ echo $CMD  # one additional env var
<the command that would have been run in the job>
root@<datum-shorthash>:/pfs$ $CMD  # executes the user code

A few options this should probably take:

pipeline version: defaulting to the version with which the datum was run makes sense, but if someone updates the pipeline without --reprocess it would be nice to be able to interactively run with the latest version of the pipeline spec
command to execute: default should probably be the container's default shell; if that doesn't exist (as is the case for some slim images), there should be a fallback option of specifying what command to exec (eg if their processing code is in python, good chance they want to poke around using an interactive python shell). If possible, it would also be great to inject busybox into containers that don't have a default shell and where they don't specify something (eg for debugging, even if your image only contains a single go binary), but no idea how feasible that is.
just run the actual command that was run in the job, but do so with their terminal attached interactively

maybe run this as a forked process, rather than exec-ing, so that the container remains intact at the end, and drop them into a shell to debug after the fact?

Behind the scenes, thinking this probably does a kubectl exec with some special flag to the worker process that sets up the state, and then execs the requested process. This won't work for hub, though, as we're not planning to give users kubectl access, so we may need to come up with some other solution in that context (can we just steal kubectl's exec code directly, and put it in pachctl?)
Edit: This is in some ways similar to @jdoliner 's Pachyderm Shell proposal (#3150), but far more limited (and therefore a bit simpler) by being focused on the debug use-case

At the moment, I'm not proposing we persist any output. That being said, I could see some use-case for that if a similar mechanism were extended a bit: something like this could be nice even just to interactively play with some data in your pach cluster without pulling it locally. But to serve that use-case, we would need some different way of specifying what data to pull in, since creating a pipeline and running a job just for the sake of creating a datum to play with feels pretty silly. How we'd want that to work would likely be similar to the mechanism for running Jupyter and persisting the notebook/output (#3681) Edit: i think what I'm talking about here re:exploration is basically the same as @JoeyZwicker 's shell proposal (#728)

Discussed offline with @jdoliner a while back, but never wrote this up:
It was discussed to expand the usage of list datum as a good way to do this. it would allow the user to see exactly how many datums and what data would be seen by the current pipeline and greatly help with debugging code.
It was also discussed that the user could even pass a pipeline spec or glob patterns to list datum so they can iterate and explore without needing to actually have a running pipeline at all nor actually update an existing one.
JD can expand further on what he has in mind for the API here.


Synchronously check all transactions to have non-zero length

As part of newPayload block hash verification, the transactionsRoot is computed by the EL. Because Merkle-Patricia Tries cannot contain [] entries, MPT implementations typically treat setting a key to [] as deleting the entry for the key. This means that if a CL receives a block with transactions containing one or more zero-length transactions, that such transactions will effectively be skipped when computing the transactionsRoot. Note that transactions are opaque to the CL and zero-length transactions are not filtered out before newPayload.
# https://eips.ethereum.org/EIPS/eip-2718
def compute_trie_root_from_indexed_data(data):
    """
    Computes the root hash of `patriciaTrie(rlp(Index) => Data)` for a data array.
    """
    t = HexaryTrie(db={})
    for i, obj in enumerate(data):
        k = encode(i, big_endian_int)
        t.set(k, obj)  # Implicitly skipped if `obj == b''` (invalid RLP)
    return t.root_hash

In any case, the blockHash validation may still succeed, resulting in a potential SYNCING/ACCEPTED result to newPayload by spec.
Note, however, that there is an effective hash collision if a payload is modified by appending one or more zero-length transactions to the end of transactions list: In the trivial case, a block with zero transactions has the same transactionsRoot (and blockHash) as one of a block with one [] transaction (as that one is skipped).
This means that the same blockHash can refer to a valid block (without extra [] transactions added), but also can refer to an invalid block. Because forkchoiceUpdated refers to blocks by blockHash, outcome may be nondeterministic and implementation dependent. If forkchoiceUpdated deems the blockHash to refer to a VALID object (obtained from a src that does not have the extra [] transactions, e.g., devp2p), then this could result in honest attestations to a CL beacon block with invalid [] transactions in its ExecutionPayload, risking finalizing it.
The problem can be avoided by returning INVALID in newPayload if there are any zero-length transactions entries, preventing optimistic import of such blocks by the CL.

Since verify_and_notify_new_payload is an EL function rather than the CL, I don't think what is specified in the consensus-specs has to be exactly the same as what is done in the EL. I think we have this function here only to roughly show what is verified.
If this check is not relevant to the CL, I don't think we should include it in the spec since it will distract CL researchers. Do you think this check is relevant to the CL?
I feel that this issue is related to MPT and it's very opaque to the CL and the CL researchers have to dig deeply why we need this check which I think they don't need to. What do you think?

verify_and_notify_new_payload represents all necessary checks that must be done at the bare minimum, even when the EL has not synced any state. The empty transaction check is one of them.
Note that certain CL implementations support syncing without a connected EL for maintenance use cases, and if engine_newPayload is skipped, then the CL itself has to perform these checks. It is very useful for such implementation to have an exhaustive list of checks that must be done, i.e., to have verify_and_notify_new_payload.

I've decided to push this to a later release. We need more folks to review this.

Had a meeting with @hwwhww and we agreed to merge this one & include it in the upcoming release.


UI fix for Iphone 12

Some screen are not working for iphone 12

Regarding mobile phone repair, you can learn about PHONEFIX. The official website of PHONEFIX includes a variety of mobile phone repair services. If you need it, you can learn about it.


Fixes wrong Accept media type that was causing a 500

https://developer.github.com/v3/issues/#list-issues-for-a-repository
lists

application/vnd.github.symmetra-preview+json
application/vnd.github.squirrel-girl-preview
application/vnd.github.machine-man-preview

which map to

mediaTypeLabelDescriptionSearchPreview
mediaTypeReactionsPreview
mediaTypeIntegrationPreview

Thank you, @phylake! Could you please also update the corresponding test?
This PR generates the Travis CI failure:
	github_test.go:115: Header.Get("Accept") returned "application/vnd.github.squirrel-girl-preview, application/vnd.github.symmetra-preview+json, application/vnd.github.machine-man-preview+json", want "application/vnd.github.squirrel-girl-preview, application/vnd.github.symmetra-preview+json, application/vnd.github.sailor-v-preview+json"

If you run go test ./... locally, you should see the problem.

I think Travis CI failed to update the status check. It all looks green to me. What should I do?

I restarted the build... Let's see if that fixes it.

That seems to have worked.

It looks like this was mistakenly changed in #910.
Thank you for catching and fixing this, @phylake!
LGTM.
Merging.


Update GitHub actions using Node.js 16 before Spring 2024

Node.js 16 is deprecated and will be removed in GitHub hosted workers by "Spring 2024":

https://github.blog/changelog/2023-09-22-github-actions-transitioning-from-node-16-to-node-20/

Update GitHub actions using Node.js 16.

automated-publish.yaml: https://github.com/Azure/enterprise-azure-policy-as-code/blob/main/.github/workflows/automated-publish.yaml

actions/checkout: https://github.com/actions/checkout

publish-docs.yaml: https://github.com/Azure/enterprise-azure-policy-as-code/blob/main/.github/workflows/publish-docs.yaml

actions/checkout: https://github.com/actions/checkout
actions/setup-python: https://github.com/actions/setup-python

@techlake - this is fixed in development environment - I'll wait for you changes to be pulled to GH before closing

Fixed in v10.0.0 released on 4/5/2024


Combos don't always get placeholders from taginfo

When you hover over an item, combo fields are created, and taginfo calls fire off to fetch the placeholders for those fields.  But it seems like if you select the item by clicking on it before the callback is called, the field never gets a placeholder.

Oh, it's probably because the requests are debounced
https://github.com/openstreetmap/iD/blob/master/modules/services/taginfo.js#L139


Make an option to disable specific state variables from serialization

In the old, struct first approach, we had an option to disable serialization for specific variables with json:"-" tag. This can help drastically improve performance with decreasing payloads size. In the new state wrapper we don't have such option. Need to bring a solution for this.

As an option we can use the same scheme as Go uses - ignore lowercase fields. We are passing map as a component state, so we will not get an access error in templates while referencing this fields. Previously, with structs, we couldn't use this approach because template can't reference private struct fields.

It was decided to use private: preffix


RHOAIENG-1044: Update hardcoded constants as environment variables

Description

Refactored the controllers/utils function GetIstioControlPlaneName to no longer reference IstioNamespace and IstioControlPlaneName constants, and to return errors instead of automatically setting the env vars. Removed the constants from the constants/constants.go file, and replaced all references of the constants in the code with a call to the utils function mentioned before.
How Has This Been Tested?

Merge criteria:

[ ] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[ ] The developer has manually tested the changes and verified that the changes work

@mholder6 the changelist on this PR looks wrong, needs a rebase probably

/lgtm


[IRGen] Emit keypath thunk helpers with swiftcc to match the caller cc

KeyPath thunk helpers are called from stdlib indirectly through
descriptor and its calling-convention in the caller side are SwiftCC.
However, the definition side expects C calling-convention, so they
can be broken on some architectures, that SwiftCC is not compatible
with C-CC on it.
This patch changes to use SwiftCC consistently on caller side and
definition side.
This doesn't have any effect on the ABI stable platforms because
SwiftCC is compatible with C-CC on them.
This fixes case 2 of https://bugs.swift.org/browse/SR-15188
CC: @MaxDesiatov

@swift-ci please smoke test

@swift-ci please test Windows platform

@swift-ci please test Windows platform