Show Pop-over on Workspace  Welcome

Details
This changes our logic for new accounts that access newDot for the first time!
Now, if the account is part of a workspace (or multiple) then not only should the workspace chat open by default but also, on a first access, the "Create Menu"/"Popover Menu" should open by itself showing the "Request Money" and "Add Attachment" options.
Or how it's described in the doc:

In order to display the popover menu upon first sign-in, we’ll update the show method in Welcome.js to take a new param showPopoverMenu and call it here.
In ReportActionCompose.js, we’ll create a new method called showPopoverMenu that will set isMenuVisible to true.
We’ll then update the ComponentDidMount logic to get the current user route and call Welcome.show passing an object containing the route and showPopoverMenu as the single argument, similar to how we do it in FloatingActionButtonAndPopover.js.

Fixed Issues

$ https://github.com/Expensify/Expensify/issues/270487
PROPOSAL: GH_LINK_ISSUE(COMMENT)
Tests

In any account, create a new Workspace
Invite a new user that still doesn't exist to that Workspace
Create that invited new user account in NewDot
Make sure that after signing in you are sent to the Workspace Chat and the "Create Menu" opens by itself.
Sign off that account and sign in again
Make sure you are redirected to the workspace chat but the "Create Menu" doesn't open this time.

[ ] Verify that no errors appear in the JS console

Offline tests

QA Steps

[ ] Verify that no errors appear in the JS console

PR Author Checklist

[ ] I linked the correct issue in the ### Fixed Issues section above
[ ] I wrote clear testing steps that cover the changes made in this PR

[ ] I added steps for local testing in the Tests section
[ ] I added steps for the expected offline behavior in the Offline steps section
[ ] I added steps for Staging and/or Production testing in the QA steps section
[ ] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)
[ ] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

[ ] I included screenshots or videos for tests on all platforms
[ ] I ran the tests on all platforms & verified they passed on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] I verified there are no console errors (if there's a console error not related to the PR, report it or open an issue for it to be fixed)
[ ] I followed proper code patterns (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method

[ ] If any non-english text was added/modified, I verified the translation was requested/reviewed in #expensify-open-source and it was approved by an internal Expensify engineer. Link to Slack message:

[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is correct English and approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I followed the guidelines as stated in the Review Guidelines
[ ] I tested other components that can be impacted by my changes (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar are working as expected)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] I verified that if a function's arguments changed that all usages have also been updated correctly
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG))

[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

Looking good. Just left a comment.

I think the issue is happening because we only update the isFirstTimeNewExpensifyUser NVP and send it back in Onyx in ReconnectApp and that call isn't made during this flow!

Both problems are coming from this branch, trying to fix here!

Those extra calls came from ReportActionCompose/index.js inside componentDidMount where we added the Welcome.show call. That makes sense as that component is mounted/re-created every time we access another chat.

So as I first imagined the problem is related to the fact that we only update the isFirstTimeNewExpensifyUser NVP when ReconnectApp is called and we don't call that when a user first signs in and gets redirected to the workspace chat.
I fixed this by setting the local Onyx value for the isFirstTimeNewExpensifyUser NVP to false after using it cc @luacmartins

@PauloGasparSv is this ready for review?

@PauloGasparSv is this ready for review?

Not yet @luacmartins still adding evidences!

The behavior doesn't work in mWeb! I have no idea why though.
This is also reproducible on desktop, replicating the tests steps with a small Chrome windows break the feature too.

Latest update here still trying to fix the bug.

@thesahindia @chiragsalian One of you needs to copy/paste the Reviewer Checklist from here into a new comment on this PR and complete it. If you have the K2 extension, you can simply click: [this button]

Didn't know PullerBear would be assigned here!
@chiragsalian @luacmartins @thesahindia could you please wait until I add the evidences to the P.R. tomorrow?
I'll ping everyone once the P.R. is ready.

Added the missing evidences, this is ready for a round of reviews @chiragsalian @thesahindia @luacmartins
Thks for the patience!

Reviewer Checklist

[ ] I have verified the author checklist is complete (all boxes are checked off).
[ ] I verified the correct issue is linked in the ### Fixed Issues section above
[ ] I verified testing steps are clear and they cover the changes made in this PR

[ ] I verified the steps for local testing are in the Tests section
[ ] I verified the steps for Staging and/or Production testing are in the QA steps section
[ ] I verified the steps cover any possible failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[ ] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

[ ] I checked that screenshots or videos are included for tests on all platforms
[ ] I included screenshots or videos for tests on all platforms
[ ] I verified tests pass on all platforms & I tested again on:

[ ] Android / native
[ ] Android / Chrome
[ ] iOS / native
[ ] iOS / Safari
[ ] MacOS / Chrome / Safari
[ ] MacOS / Desktop

[ ] If there are any errors in the console that are unrelated to this PR, I either fixed them (preferred) or linked to where I reported them in Slack
[ ] I verified proper code patterns were followed (see Reviewing the code)

[ ] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick).
[ ] I verified that comments were added to code that is not self explanatory
[ ] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[ ] I verified any copy / text shown in the product is localized by adding it to src/languages/* files and using the translation method
[ ] I verified all numbers, amounts, dates and phone numbers shown in the product are using the localization methods
[ ] I verified any copy / text that was added to the app is grammatically correct in English. It adheres to proper capitalization guidelines (note: only the first word of header/labels should be capitalized), and is approved by marketing by adding the Waiting for Copy label for a copy review on the original GH to get the correct copy.
[ ] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[ ] I verified the JSDocs style guidelines (in STYLE.md) were followed

[ ] If a new code pattern is added I verified it was agreed to be used by multiple Expensify engineers
[ ] I verified that this PR follows the guidelines as stated in the Review Guidelines
[ ] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[ ] I verified all code is DRY (the PR doesn't include any logic written more than once, with the exception of tests)
[ ] I verified any variables that can be defined as constants (ie. in CONST.js or at the top of the file that uses the constant) are defined as such
[ ] If a new component is created I verified that:

[ ] A similar component doesn't exist in the codebase
[ ] All props are defined accurately and each prop has a /** comment above it */
[ ] The file is named correctly
[ ] The component has a clear name that is non-ambiguous and the purpose of the component can be inferred from the name alone
[ ] The only data being stored in the state is data necessary for rendering and nothing else
[ ] For Class Components, any internal methods passed to components event handlers are bound to this properly so there are no scoping issues (i.e. for onClick={this.submit} the method this.submit should be bound to this in the constructor)
[ ] Any internal methods bound to this are necessary to be bound (i.e. avoid this.submit = this.submit.bind(this); if this.submit is never passed to a component event handler like onClick)
[ ] All JSX used for rendering exists in the render method
[ ] The component has the minimum amount of code necessary for its purpose, and it is broken down into smaller components in order to separate concerns and functions

[ ] If any new file was added I verified that:

[ ] The file has a description of what it does and/or why is needed at the top of the file if the code is not self explanatory

[ ] If a new CSS style is added I verified that:

[ ] A similar style doesn't already exist
[ ] The style can't be created with an existing StyleUtils function (i.e. StyleUtils.getBackgroundAndBorderStyle(themeColors.componentBG)

[ ] If the PR modifies code that runs when editing or sending messages, I tested and verified there is no unexpected behavior for all supported markdown - URLs, single line code, code blocks, quotes, headings, bold, strikethrough, and italic.
[ ] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[ ] If the PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[ ] If a new page is added, I verified it's using the ScrollView component to make it scrollable when more elements are added to the page.
[ ] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[ ] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

Screenshots/Videos

Web

Mobile Web - Chrome

Mobile Web - Safari

Desktop

iOS

Android

@PauloGasparSv, does this still require review from me? @luacmartins has already filled the checklist.

I just pulled from main and added a commit that shouldn't change logic, but I think it would be a good idea specially to prevent bugs that me and @luacmartins didn't catch
Not required though : )

Btw, I'm re-testing everything here and will ask for a re-review shortly.

@thesahindia yes, please review!

@thesahindia yes, you need to be part of the beta. What's the testing account you are using?

I added that account to the beta. Are you using multiple accounts to test each platform? If so, we'll need to add those to the beta too

Done!

@PauloGasparSv we have conflicts

@PauloGasparSv we have conflicts

Thks, fixing them here!

Re-test Web, Android and mWeb Chrome and the feature is still working as expected after the merge.

🎯 @thesahindia, thanks for reviewing and testing this PR! 🎉
An E/App issue has been created to issue payment here: https://github.com/Expensify/App/issues/17533.

@PauloGasparSv let's address Chirag's comment above and get this one merged today!

Fixed the conflicts with main and reworked the comments!
Re-testing everything here.

Re-tested and so far everything is working. I'm still adding iOS evidences but I think this is ready for reviews

Web
https://user-images.githubusercontent.com/6564265/233170146-f4724014-5f9c-41e0-aa39-e6debfdae34f.mov
https://user-images.githubusercontent.com/6564265/233170232-d1f0e953-e0c2-4a85-b164-36f82aefe8b0.mov

Mobile Web - Chrome
https://user-images.githubusercontent.com/6564265/233170213-91152261-ae2a-40e5-96c8-93f5b8c629a7.mov

Mobile Web - Safari
https://user-images.githubusercontent.com/6564265/233170224-98826c6f-4cfd-47ee-8572-13929bc209a5.mov

Desktop
https://user-images.githubusercontent.com/6564265/233170181-1a50c091-f5ca-4dec-b3d3-35219de59703.mov

iOS

Android
https://user-images.githubusercontent.com/6564265/233170196-44c52cfc-2376-465c-98aa-7bc83037ecb9.mov

Going ahead and merging since its was mostly minor changes since the latest approvals.

:hand: This PR was not deployed to staging yet because QA is ongoing. It will be automatically deployed to staging after the next production release.

🚀 Deployed to staging by https://github.com/chiragsalian in version: 1.3.3-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by https://github.com/mountiny in version: 1.3.3-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


Initial rule test support

This PR:

adds support for unit testing alerting rules - needed as i've added my first bunch of new alerts

TODO:

[ ] integrate into ci
[ ] finalize make targets
[ ] finish test script
[ ] documentation

Checklist

[ ] Update changelog in CHANGELOG.md.
[ ] Request review from oncall area, as well as team (e.g: oncall-kaas-cloud GitHub group).
[ ] Alerting rules must have a comment documenting why it needs to exist.
[ ] Consider creating a dashboard (if it does not exist already) to help oncallers monitor the status of the issue.

I realllllly like your approach here <3
Could you write a bit of documentation in the end so we can announce that in news-ops so other team starts to test their alerts also ?

I realllllly like your approach here <3
Could you write a bit of documentation in the end so we can announce that in news-ops so other team starts to test their alerts also ?

Sure, will do that ... Initial intention was to get some early feedback if it make sense to continue on this.
Will write some documentation later on

I've had a look; ok maybe more than a look, so here is a PR to help things forward: https://github.com/giantswarm/prometheus-rules/pull/417

THX @hervenicol for your PR on this branch :heart:
I changed the directory structure a bit and add some initial notes about testing and how to add new tests.
For validation i added test cases for all CAPI and CAPO rules (to have a valid test target).
There are still some limitations (described in README.md) but maybe we can start with this and improve the script when we are at the point where we need the improvements.

Totally agree we should not wait to have something perfect before we merge, and the current status is already great!
I'd just like to clarify stuff around the promtool_ignore file before.

Status:

we need provider-specific ignore files and provider-specific tests
bust most of the tests and ignored rules are generic
So we need to have a kind of hierarchy for them.

Let's have the right structure before we merge, so we do things clean from the start when people start contributing.

@TheoBrigitte what do you think about merging this ?

Also, I think before we merge we need:

a communication because people may complain when they add new rules and it fails because they now need to write tests.
more tests, so people have examples.

That's a lot of bash foo, I am not super confident we can maintain this.

I agree the script is not very easy to read. Some refactoring / functions splitting could be useful for easier maintenance.
But on the other hand, I'd like these tests to be battle-tested ASAP so we have user feedback.
If you have ideas on how to reorganize the code, please tell!

How about we pair on it after the onsite so I can learn bash :)
Le ven. 26 août 2022, 18:25, Hervé Nicol @.***> a
écrit :

That's a lot of bash foo, I am not super confident we can maintain this.
I agree the script is not very easy to read. Some refactoring / functions
splitting could be useful for easier maintenance.
But on the other hand, I'd like these tests to be battle-tested ASAP so we
have user feedback.
If you have ideas on how to reorganize the code, please tell!
—
Reply to this email directly, view it on GitHub
https://github.com/giantswarm/prometheus-rules/pull/384#issuecomment-1228694859,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AAVIRXHO7N22B7R674CQTFDV3DVYZANCNFSM52WKAQAQ
.
You are receiving this because your review was requested.Message ID:
@.***>

Also, found a bug: the global tests don't work, because this is not where the yaml rules files are generated.
Reminder / note to self: global tests have to be run against each provider. So the fix should consist in being in the directory where rules have been generated.


Python front end - encapsulating variables

In thinking about a user-friendly Python front end we think about how well the Fortran design would work.
Specifying problems
Radiation problems are defined in one of three ways - three sets of "optical properties". Using the Fortran notation:

1scl problems are defined in terms of tau
2str problems are defined in terms of tau, ssa, g
nstr problems are defined in terms of tau, ssa, p (we don't currently have much implemented in Fortran)

Each variable might depend on a vertical coordinate (ilay) and/or a spectral coordinate (igpt); p also has a "moment" dimension (imom). The underlying kernels all operate on more than one profile at a time (icol) as the first dimension.
Planets receive radiation from their host star and emit radiation themselves. For the purposes of gas optics we treat these as distinct, so we have two gas optics variants:

_int for internal sources represent planetary radiation and returns layer, level, and surface sources. Each has a spectral dimension; there is one more level than layer, and the surface has no vertical extent.
_ext represents stellar radiation. It returns the solar source (inc_flux) which has a single spectral dimension.
Gas optics calculations also return the set of 1scl, 2str, or nstr optical properties depending on user desires.

Solving problems
The solvers depend on whether the sources are internal (lw for longwave) or external (sw for shortwave). Each takes  a set of optical properties (e.g. noscat solvers use 1scl optical properties) and the corresponding set (int/ext) of source functions.
In practice shortwave problems always use a two-stream specification, while longwave solvers might use either a scalar or a two-stream specification.
Encapsulation
In the Fortran interface there is one class grouping together the optical properties and a second grouping together the longwave source functions; the shortwave source is passed around as a plain array. Using classes makes for a smaller number of variables and ensures the right grouping.
Does this approach make sense in Python too?

We discussed this at a group meeting recently.
Conceptually we can think of each problem as having optical properties, sources (of radiation), and boundary conditions. The combination of optical properties and sources defines the kind of problem to be solved; it's also what comes back from the gas optics. Users will specify boundary conditions.
We could distinguish these, e.g.
gas_optics = rrtmgp.GasOptics(SCHEME_DATA)
atmosphere = xr.open_dataset(SOME_FILE) # temperature, pressure, gas concentrations
optical_props, sources = gas_optics.gas_optics(atmosphere)
bcs = atmosphere # with agreed names for surface properties, say
flux_up, flux_dn = rte.solve(optical_props, sources, bcs)

This makes everything clear. One clear disadvantage is that the optical_props, sources, and boundary conditions share coordinates in space and along the spectrum. To me that suggests putting them in the same dataset:
gas_optics = rrtmgp.GasOptics(SCHEME_DATA)
atmosphere = xr.open_dataset(SOME_FILE) # temperature, pressure, gas concentrations
problem = gas_optics.gas_optics(atmosphere)
problem["surface_emissivity"]  = 1.
flux_up, flux_dn = rte.solve(problem)

This is conceptually less clear and relies (more?) on conventions for arrays within datasets.

@tcmetzger these are some nice "spelling" examples for us to implement

@tcmetzger @sehnem One thought after discussions with @brendancol earlier today: optical properties and source functions both have a spectral dimension/discretization. In general, there are spectral "bands" that cover particular frequencies/wavelengths (and have starting and ending values of those coordinates); for the gas optics there may also be "g-points" within each band that aren't ordered in any particular way.
This comes up when creating a problem definition/set of optical properties from multiple components in the atmosphere (like gases and clouds) - not only do we have to ensure that the discretizations are the same but we need the ability to broadcasts values defined on bands to each g-point within the band. Like this, if we use a single dataset for the whole problem:
gas_optics = rrtmgp.GasOptics(SCHEME_DATA)
cloud_optics = rrtmgp.CloudOptics(MORE_SCHEME_DATA)

atmosphere = xr.open_dataset(SOME_FILE) # temperature, pressure, gas concentrations
clouds = xr.open_dataset(SOME_OTHER_FILE) # cloud properties

problem = gas_optics.gas_optics(atmosphere)
# "problem" is defined on g-points
cloud_optics(clouds).add_to(problem)  # or maybe problem += cloud_optics(clouds)
#cloud_optics(clouds) is defined on bands
problem["surface_emissivity"]  = 1.

flux_up, flux_dn = rte.solve(problem)

@RobertPincus, I reviewed your suggestion and the current implementation, what do you think of the implementation bellow?
gas_optics = rrtmgp.GasOptics(SCHEME_DATA)
cloud_optics = rrtmgp.CloudOptics(MORE_SCHEME_DATA)

# Here the user can create different atmospheres and clouds to be used in multiple problems
atmosphere = gas_optics.load_atmosphere(SOME_FILE)
clouds = cloud_optics.load_clouds(SOME_OTHER_FILE)

# As the problem is part of RTE, we could create a class there with
# some defaults but that could be modified if needed, it could be
# configured in the class initialization or by changing the attributes
problem = rte.Problem(atmosphere, clouds) # could be and other name used Problem as was used in the other example
problem.surface_emissivity = 1

# Configs for the parallelization could be added here
flux_up, flux_dn = rte.solve(problem)

I have not worked on the clouds yet, but if there is a high dependency on the atmosphere, we could also do something like
gas_optics = rrtmgp.GasOptics(SCHEME_DATA)
cloud_optics = rrtmgp.CloudOptics(MORE_SCHEME_DATA)

atmosphere = gas_optics.load_atmosphere(SOME_FILE)
clouds = cloud_optics.load_clouds(SOME_OTHER_FILE)
atmosphere.load_clouds(clouds)

problem = rte.Problem(atmosphere)
problem.surface_emissivity = 1

flux_up, flux_dn = rte.solve(problem)

Does it make sense?
@brendancol from a technical point of view, currently we are using xarray accessors, should we keep using it, should we use classes as Robert suggested, or could we use accessors in a layer underneath the classes?

@sehnem If I understand right you are proposing a refinement - to make a Problem class associated with the RTE module. Do I have that right? This could be a good choice but we'll need to work some things through.
A complete description of a problem to be solved by RTE contains optical properties, source functions, and boundary conditions, each on a grid with spectral, vertical, and instance dimensions (ngpt, nlay, and ncol in the Fortran code). There are different variables associated with the source functions and boundary conditions for the LW and SW variants.
The cloud (and aerosol) optics code returns optical properties alone, while gas optics returns optical properties and source functions. We can provide default values for boundary conditions.
The normal course of things in the the Fortran is to compute the gas optics and source functions, possibly compute fluxes, compute cloud optics, update the problem definition, then compute fluxes.
Would it be Pythonic to define an rte.Problem class with three variants that encapsulates the optical properties (i.e. allows only certain combinations of arrays within the data set) and subclasses rte.Problem.LW and rte.problem.SW as containers for the combination of optical properties, source functions, and boundary conditions? cloud_optics() would return a Problem but gas_optics() would return a Problem.LW?

The normal course of things in the the Fortran is to compute the gas optics and source functions, possibly compute fluxes, compute cloud optics, update the problem definition, then compute fluxes.

I was missing that, maybe it is better to put this on hold and implement after the cloud optics is at least partially done. I have not worked with that so I was not aware of it.
I will keep working on other fixes with results that are not matching using v0.18 RTE-RRTMGP and latest set of data, now the pyrte result for lw is exactly half of the expected in the data repository, not sure if there was some change but I will debug it.

@sehnem With respect to the test data, there was a change in the RTE release in May (https://github.com/earth-system-radiation/rte-rrtmgp/pull/282/files) that might be relevant.

@sehnem It may take a bit for the cloud optics to be merged to develop in the Fortran repo - there's an issue with the CI (not relevant for us but still a show-stopper). In terms of the design isn't it enough to know that cloud optics will return a set of optical properties?

@RobertPincus I can work on that as the cloud optics will take some time. It is something that should no be too hard to change if needed, just thought that it may be better to do it as a last step it there was no blocker.
Thanks for pointing the changes from may, some of these functions were reimplemented in python so it is probably it.

@sehnem @tcmetzger A revised spelling for the front end.
# Clear sky example
gas_optics_lw   = rrtmgp.GasOptics(SCHEME_DATA)
gas_optics_sw   = rrtmgp.GasOptics(OTHER_SCHEME_DATA)

atmosphere = xr.open_dataset(SOMEFILE)

# Demonstrating gas optics

# Longwave examples

# Adds a problem (tau), sources (lay_source, lev_source), and boundary conditions (surface_emissivity) to 'atmosphere'
gas_optics_lw.compute_gas_optics(atmosphere, problem_type="absorption")

# Creates a new xr.Dataset with problem (tau), sources (lay_source, lev_source), and boundary conditions (surface_emissivity)
# with coordinates and dimensions taken from 'atmosphere'
# 'absorption' is the default for LW problems
lw_problem = gas_optics_lw.compute_gas_optics(atmosphere, problem_type="absorption", add_to_input = False)

# Creates a new xr.Dataset with problem (tau, ssa, g), sources (lay_source, lev_source), and boundary conditions (surface_emissivity)
# with coordinates and dimensions taken from 'atmosphere'
lw_problem = gas_optics_lw.compute_gas_optics(atmosphere, problem_type="two-stream", add_to_input = False)

# Shortwave examples
# Adds a problem (tau, ssa, g), sources (toa_source), and boundary conditions
# (surface_albedo_direct, surface_albedo_diffuse, solar_zenith_angle) to 'atmosphere'
# 'two-stream' is the default for SW problems
gas_optics_sw.compute_gas_optics(atmosphere)

# Access the problem data:
lw_problem["tau"] /= 2.

# Examples of solution

# Appends DataArrays of (broadband) fluxes to the input dataset
# Default is broadband (spectrally-integrated) fluxes
# Should the fluxes have names showing SW or LW?
rte.solve(problem)

flux_up, flux_down = rte.solve(problem, add_to_input = False)

spec_flux_up, spec_flux_down = rte.solve(problem, add_to_input = False, spectrally_resolved = True)

# Does this make sense? Or do we use .pipe()
custom_out = rte.solve(problem, add_to_input = False, reduction = Callable)

@RobertPincus I created a basic implementation for the LW problem, now I am using xarray objects as return types. The implementation followed your suggestions but I had to change a few things, instead of compute_gas_optics I used the accessor name gas_optics and compute. For RTE it is rte_solve as I am using just a function to select the right method.
Let me know if that looks good, the other attributes that are not in this example should be implemented as you suggested.
rte_rrtmgp_dir = download_rrtmgp_data()
input_dir = os.path.join(rte_rrtmgp_dir, "examples", "rfmip-clear-sky", "inputs")

# This is to load one of the default files that the library automatically downloads, but
# it also accepts paths do netcdfs.
# gas_optics_lw is a xarray dataset
gas_optics_lw = load_gas_optics(gas_optics_file=GasOpticsFiles.LW_G256)

atmosphere_path = os.path.join(input_dir, "multiple_input4MIPs_radiation_RFMIP_UColorado-RFMIP-1-2_none.nc")
atmosphere = xr.load_dataset(atmosphere_path).sel(expt=0)

# here it uses some default names for the variables, we need to implement support for custom dataset names
# and gas selections. It support add_to_input or the creation of a new dataset.
gas_optics_lw.gas_optics.compute(atmosphere, problem_type="absorption")

# The output of gas_optics.compute will have an attribute that will describe the problem,
# LW, SW, absorption, 2-src, etc. And it will be used to call the function.
fluxes = rte_solve(atmosphere, add_to_input=False)

@RobertPincus about this last line, the reduction would be a method applied to the output, or something else?
custom_out = rte.solve(problem, add_to_input = False, reduction = Callable)

@sehnem Yes, that was the idea, but it's inspired by the Fortran where there are fewer options. It might be valuable here if providing a function makes it easier to parallelize the reduction over dask chunks. On the other hand if rte.solve(problem, add_to_input = False).pipe(reduction) has the same effect we wouldn't need to pass the function explicitly.

@sehnem I hadn't noticed your initial longwave implementation. The revised syntax

looks fine to me. Are the gas_optics.compute() and rte_solve() methods both able to append to the input data set and/or return a new xr.Dataset per user request?

@RobertPincus yes, both support appending or the return of only the results.
I think that this reduction function could work in both ways. I will take a look at the fortran code to get some reference and test what would work the best.


messages: MessaveAckKeyspaceIds

There is a need for a V2 level API for message acks.
BUG=38423920

@michael-berlin I need to override codeclimate for some var names it's flagged. The names are non-compliant because they need to match the proto names. I tried to assert them as WontFix, but it says I'm not authorized.

@michael-berlin I need to override codeclimate for some var names it's flagged. The names are non-compliant because they need to match the proto names. I tried to assert them as WontFix, but it says I'm not authorized.

I think it only complains about the loop variable? You could rename these? ;) Fixing this now (at the price of breaking consistency) would be the easiest solution. This way you also avoid that somebody else runs into this problem at a later point when they touch that code. Note that the golang team doesn't provide directives to exempt something e.g. // NOLINT does not work.
In any case, the Code Climate check is configured as optional (same as with Travis) i.e. you can always override/ignore it. Only the CLA check or the pull approve one require admin rights to ignore it.

I could, but I'd be breaking consistency on how proto names variables. In general, they say that one should not fix golint warnings for golint's sake. Exceptions are allowed where it makes sense.
I can rename these variables, but we'll need a way to override these because there will be cases where it won't make sense to comply.

I could, but I'd be breaking consistency on how proto names variables. In general, they say that one should not fix golint warnings for golint's sake. Exceptions are allowed where it makes sense.

Is this written down somewhere? :) Given that they don't provide a directive to exempt things, I feel like their primary goal is to not have such exceptions in the first place i.e. always write compliant code :)

I can rename these variables, but we'll need a way to override these because there will be cases where it won't make sense to comply.

We can skip the check on a per file basis and do so for generated code: https://github.com/youtube/vitess/blob/master/.codeclimate.yml#L14
For not generated code, I don't want to skip files. Otherwise, we would skip legitimate problems in the same file as well.

Skipping files would not be a good idea. We should just be able to override specific reports (which codeclimate allows, with the right permissions).
The golint documentation specifically states that warnings can be ignored if it doesn't make sense: https://github.com/golang/lint#purpose. And here are some supporting arguments in issues:
https://github.com/golang/lint/issues/89
https://github.com/golang/lint/issues/209

Skipping files would not be a good idea. We should just be able to override specific reports (which codeclimate allows, with the right permissions).

I tried the "Approve" feature in Code Climate and it works for me. Because of my approval, the check is green now.
Did you login with your GitHub account on Code Climate?
I checked the Code Climate settings but didn't find anything which would allow me to configure a list of allowed approvers. My guess is that, similar to Travis, you just need to be a collaborator of the project and then it works? We can follow up with them on that.
Nonetheless, let me repeat what I said earlier:

you can ignore the check anyway because it's optional
in my personal opinion, you should just rename the local variables to *ID. Everybody knows that golint is picky about ID and would understand if you break the consistency there. IMO that's better than being bothered by this check over and over again. After all, our Git commit hook will nag you about that as well - and that cannot be permanently ignored like Code Climate seems to support. And unlike generated code, we can change the name here and make the warning go away.

All review comments addressed including variable renaming.


[6.0] Fix relative_protocol_witness_table.swift on some bots

Cherry-pick https://github.com/apple/swift/pull/72677 to 6.0.
rdar://125566233

@swift-ci please smoke test


[Tagger][Aggregator] Add Agent tagger tags to telemetry metrics submitted by the Aggregator

What does this PR do?

Expose a new tagger function AgentTags to collect Agent tags
Add Agent tags to the telemetry metrics submitted by the Aggregator

Motivation
It's useful to have container/pod tags attached to following metrics:

datadog.agent.running
datadog.agent.started
datadog.agent.up (service check)
datadog.agent.python.version

Additional Notes

Needs to be enabled via basic_telemetry_add_container_tags
The added tags respect the ChecksCardinality config

Describe your test plan
Enable the feature and check whether the pod tags were added

thanks @olivielpeau - PR ready for a second review


Enforce folder numbering script

Description
This pull request adds a GitHub Actions CI workflow to check for unique task prefixes in the tasks directory, ensuring that no duplicate prefixes exist. This helps maintain organization and prevents issues during task management.
Tests
The script was tested locally to confirm that it correctly identifies duplicate prefixes. All prefixes in the current tasks directory were verified for uniqueness.
Additional context
This implementation aims to enhance the CI process by ensuring task prefix uniqueness, thereby preventing potential conflicts.
Metadata

Fixes #203

Hi @ShubhSensei, do you plan on addressing the comments here?

Hi @ShubhSensei, do you plan on addressing the comments here?

Thankyou for waiting. I'm working on it and I'll revert to you ASAP.

Closing as stale since there are also now some conflicts


fix(build): rm NODE_ENV var

This PR removes NODE_ENV from being set from the Dockerfile, which is causing Konflux builds to fail because we are now referencing a dev dependency in next.config.js, which we don't get installed because NODE_ENV=production.

/lgtm thanks Rachel :)


Bug: "when green flag clicked" rendered in wrong language

What happens
Code renders to English.

Expected
Image should be in same language.
http://scratchblocks.github.io/#?lang=nb&script=når grønt flagg klikkes

Duplicate, #131

I've already fixed this in master, thanks!

Now fixed!


methods config should be configurable

Line 7 of methods.py has the hardcoded value:
CONFIG_PATH = 'methods'
This should be moved to a configuration parameter by run_config.yaml

From my comment on #21: I think we want to leave these values out of the run config yaml. The run config is supposed to be logically linked to a datarun (which is machine-agnostic), and the output folders for models and metrics, if configurable, should be a machine-by-machine choice.
It might make sense to have model_dir and metric_dir be arguments to work() in worker.py.

Thanks, that makes sense.  I added new pull request #30 which takes your suggestions into account.


Update 10. Filtering.md

Fixed syntax in example

👍  thanks
I also added the changes to https://docs.hyva.io/doc/10-filtering-JbCbwNMVSY where the docs are maintained and exported into the repo usually.

Ups, sorry for the accidental close :)


need matmul fp64 support from oneDNN

🐛 Describe the bug
test_ops.py::TestCommonXPU::test_dtypes_nn_functional_scaled_dot_product_attention_xpu FAILED

Skip this case to WA this issue.
Versions
yongliang/sdpa-math
8a35768

@ZhiweiYan-96 please double check whether we can close this issue

duplicated with https://github.com/intel/torch-xpu-ops/issues/253, close it


rob/lockedtokens staking proxy templates

Adds staking proxy transactions and GenerateXXXXXScript methods.
Test simply checks that the GenerateXXXXXScript methods can find their resources.

Thank you Rob! We won't be using these though, so I'll close this PR.


Add signal* icons

closes #283

feedback: any better way to make it distinct from bar-chart

@ericfennis how about something like this?

@mittalyashu
I think it is too thick. The lucide style is, thin and simplistic.
I don't really bother me that the icon is a bit similar with bar-chart. The signal icon is to be fair a sort of bar chart icon displaying the strength of the signal.

I'm not sure if the icon "signal-zero" is correct

@@maxim-s-barabash you right. This need a fix


Upgrade ocfl-java to 2.1.0, flyway to 9.x and try to fix some flappin…

…g tests
JIRA Ticket: https://fedora-repository.atlassian.net/browse/FCREPO-3936
What does this Pull Request do?
Upgrades ocfl-java dependency to 2.1.0
Upgrades flywaydb dependency to 9.x
Tries to solve two flapping tests with using a single thread to get both actions within one second and to use await to wait a bit for changes.
How should this be tested?
This really needs a test against S3, I took the defaults from the ocfl-java documentation so it is possible these are not ideal for our use case.
Interested parties
Tag (@ mention) interested parties or, if unsure, @fcrepo/committers

This PR will depend on https://github.com/fcrepo/fcrepo-storage-ocfl/pull/57 being merged first.

@whikloj fyi it looks like the tests don't like the flyway cleanDisabled setting. Seems like it's coming from the TestIsolationExecutionListener calling flyway.clean()


Decouple session management of tokens from user data

What this does
Our current implementation is fine, but becomes a problem the moment you want to update the users stored info without also updating their token.
Checklist

[x] soft decouple in Vue
[ ] Refactor to have only 1 endpoint/model/shape have a token in it
[ ] Separate Vue calls for user data and user token
[ ] Update React
[ ] Update React Native

How to test
Add user steps to achieve desired functionality for this feature.

@paribaker and @lakardion - You might be best equipped to help Ed with this one.

@oudeismetis I removed the coupling in Vue which was the only client that was having both user and token combined in the same state.
After the new endpoint for the token is ready we can update all the clients to use it.
So right now the two places we're getting a token for the app are login and sign-up.
For login we should just send the user and pass to get the token.
Then for sign-up we should do the post for creating the user and subsequently perform a login (aka get the token with the user and pass) ?


Azure Communication Services - Long Run Operations

There is an ongoing swagger change to have method name:
create_search -> begin_reserve_phone_numbers
purchase_search -> begin_purchase_reservation
release_phone_numbers -> begin_release_phone_numbers
However the swagger is not ready yet, so you will see intermediate states in this PR like:
begin_reserve_phone_numbers is returning LROPoller[PhoneNumberSearch]
It should be:
begin_reserve_phone_numbers is returning LROPoller[PhoneNumberReservation]
It will be fixed before next release after updated swagger is ready.

Do we contain breaking changes? (break the code in last beta release. If yes, please list them in changelog

I have created a new issue and will make a separate PR for the changelog https://github.com/Azure/azure-sdk-for-python/issues/14961


Ref/tx notes

Coverage decreased (-0.1%) to 85.269% when pulling 667145014c62a330e622d26208cc0483a85f02b5 on isocolsky:ref/tx-notes into 60d94dad97d3bbd71199ddd3df232621ac6b43f0 on bitpay:master.


Fixed a syntax error in the PlatformIO guide

Fixed a typo in the project creation command of the PlatformIO guide: command failed with
error: Found argument '--framework' which wasn't expected, or isn't valid in this context
	Did you mean --frameworks?

If the error is about framework, why are you pluralizing platform?

If the error is about framework, why are you pluralizing platform?

Yep, totally missed that somehow. #33


Add doc comments for HttpsApplicationBuilderExtensions.UseKestrelHttps() methods.

https://github.com/aspnet/KestrelHttpServer/blob/dev/src/Microsoft.AspNetCore.Server.Kestrel.Https/HttpsApplicationBuilderExtensions.cs

@mikeharder You're re-doing these right now anyways... https://github.com/aspnet/KestrelHttpServer/issues/720


CLOUD-470 Use more up to date cert manager

Test name
Status

self-healing
passed

scaling
passed

big-data
passed

init-deploy
passed

recreate
passed

scaling-proxysql
passed

storage
passed

self-healing-advanced
failed

upgrade
passed

demand-backup
passed

limits
passed

operator-self-healing
passed

upgrade-consistency
passed

one-pod
passed

monitoring
passed

auto-tuning
passed

monitoring-2-0
passed

scheduled-backup
passed

affinity
passed

proxysql-sidecar-res-limits
passed

PXC operator docker - perconalab/percona-xtradb-cluster-operator:PR-329-ded5c53a

Test name
Status

scaling
passed

scaling-proxysql
passed

upgrade
passed

big-data
passed

upgrade-consistency
passed

init-deploy
passed

storage
passed

limits
passed

monitoring
passed

monitoring-2-0
passed

affinity
passed

proxysql-sidecar-res-limits
passed

self-healing
passed

self-healing-advanced
passed

recreate
passed

demand-backup
passed

scheduled-backup
passed

operator-self-healing
passed

one-pod
passed

auto-tuning
passed


Add Serialize/Deserialize derives for types

Should I just derive it or maybe serialize/deserialize from [f32; C] kinds of types?

 Until serde grows a way to explicitly flatten nested structures, it's best to write manual implementations that forward to the existing [f32; N] impl for sanity's sake.

@Ralith I was thinking so too, I'll try to work on that tomorrow.

I don't think this is a Serde problem, but rather the formats using it. For example, you can compare RON output versus JSON here - https://github.com/servo/webrender/pull/1829
@Aceeri
I believe having a serde feature (not enabled by default) would make perfect sense here. Thanks for filing the issue!

@kvark

I don't think this is a Serde problem, but rather the formats using it. For example, you can compare RON output versus JSON here

That doesn't demonstrate the problem I'm referring to; the json output, despite having more newlines, is perfectly sanely structured. See e.g. https://github.com/sebcrozet/nalgebra/issues/249 for contrast.

Looking further, it looks like matrices are generated like struct Matrix2<T> { x: Vector2<T>, y: Vector2<T> }. That entails a derived JSON/toml/... serialization along the lines of { "x": [...], "y": [...] } which seems verbose and unintuitive compared to the more typical [[...], [...]] sort of thing you see in e.g. nalgebra's serde implementation.

@Ralith

{ "x": [...], "y": [...] } which seems verbose and unintuitive compared to the more typical [[...], [...]]

It doesn't appear obviously worse to me. I can live with that.
@Aceeri are you going to finish up the PR with changes I requested in the review?

yes, going to finish it later today, havent had much time in the past few days.

An AsRef implementation has been merged in #23, which could be used to substantially reduce the complexity of these impls by forwarding to the official impls for arrays.

@Aceeri ping!

Oop, forgot about this, I'll do this today hopefully.

Going to close this, I remember having some annoying issues trying to get [T; n] to behave here.

@Aceeri apparently, this would be very useful for Amethyst interop. Would you be interested in reviving and landing this?


Added FOLLOW pagination type.

This only follows pages (dynamically) after crawling all of the links in the base page. If you have any interest in this PR, I can flesh out the implementation and docs.

as far as I understand you would provide a Xpath pointing to the next page. Most sites using pagination have a "next page" link which disappears on the last page. This would be very useful if you wanted to scrape all pages instead of first n.

@holgerd77 I tested this PR and seems to work fine (done only 1-2 simple modifications with DDS 0.11.2). I think its good to merge it cause it solves the problem with dynamic max_page pagination of DDS.

@bezkos Thought about that, I'll do a slightly different implementation allowing for more flexibility on pagination, but this will be integrated into next release.
Cheers
Holger

@holgerd77 Based on this PR, i implemented one form of ASP/JS pagination for DDS. I can't do new PR cause i use a previous version of DDS for it. If u interested for it, i can write here the new code so u can append this pagination in next version of DDS.

Hi @bezkos, thanks for the offer! As I mentioned in the comment before, I already implemented this in the latest development branch, will be released any time soon.
Greetings
Holger

@holgerd77 This PR is for HTML pagination, I implemented ASP/JS pagination as i mention above.

Hi @bezkos, sorry for the late answer: what exactly do you mean with ASP/JS pagination? Can you give an example use case and shortly describe, how this is then handled with your implementation/how it works in DDS?

@holgerd77 You can see this kind of pagination here
https://stackoverflow.com/questions/10218581/using-scrapy-to-scrap-asp-net-website-with-javascript-buttons-and-ajax-requests
To handle this pagination, u need to scrape some fields from GET/POST requests, add some extra params and use FORMREQUESTS to get data.

@bezkos Hmm, at first glance I'm not seeing any point, why this can't be done with the existing DDS implementation

@holgerd77 Did u achieve to scrape a site like this with existing DDS options?


Remove unnecessary pod dependencies from share extension so we remove build warning: Get rid of warning: "ld: linking against a dylib which is not safe for use in application extensions"

Fixes #6127
Includes #6128
Not bazillion lines of these anymore, which makes build warnings too noisy to be useful:

ld: linking against a dylib which is not safe for use in application extensions

Force-pushed to fix commit message


About hta runtime

Hi, I found that there are no hta third_party in current release version, but it does exist in v0.11.0 release version, so why has it been removed from current version? If I still want to use hta runtime, can I use the hta third_party from v0.11.0 directly?
thanks

Yes we have removed the hta, because we are not authorized by Qualcomm.


How to compile Pantry Party for iOS?

Is there a guide/steps how to compile Pantry Party for iOS? I tried something with Xcode, but it didn't load it.

PantyParty is a nativescript app. They have some getting started guides
that are far better than anything I could write.
If you can't find one, or get stuck, let me know.
On Sun, Jul 4, 2021, 3:58 PM Alexander @.***> wrote:

Is there a guide/steps how to compile Pantry Party for iOS? I tried
something with Xcode, but it didn't load it.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/PantryParty/pantry_party/issues/124, or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQ6MXZ37CHWHM4W6JXHCLTWC4PDANCNFSM47ZPXFDQ
.

Thanks, and i found the website https://docs.nativescript.org/ . When i have some more time, i will execute the steps and see how i far i get.
Maybe this is useful information to put in the README file on github?

Finally got it compiled, but i needed to use node v14 (v16 does not compile with dependencies). Currently still trying to figure out how to make an IPA file and upload it to my phone. I don't have a developer account, so Xcode is not working with me.

Hey,
Apple is kinda a pain like that. You can use nvm (node version manager) if
you need more than one node version.
I think your should still be able to use the simulator without a developer
account. If you still have problems you can also do dev against an Android
simulator and I'll test it against iOS.
On Thu, Jul 8, 2021, 3:47 AM Alexander @.***> wrote:

Finally got it compiled, but i needed to use node v14 (v16 does not
compile with dependencies). Currently still trying to figure out how to
make an IPA file and upload it to my phone. I don't have a developer
account, so Xcode is not working with me.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PantryParty/pantry_party/issues/124#issuecomment-876213387,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQ6MV7W72R5DKO24UXM3LTWVJ2FANCNFSM47ZPXFDQ
.

Just asking: Do you know if i can compile + load the app on an Android phone without a required subscription with google? In such case, i will order myself an Android ;-)

Yep with Android you only need an account to publish to the app store
On Thu, Jul 8, 2021, 8:34 AM Alexander @.***> wrote:

Just asking: Do you know if i can compile + load the app on an Android
phone without a required subscription with google? In such case, i will
order myself an Android ;-)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PantryParty/pantry_party/issues/124#issuecomment-876401534,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQ6MQJHU355F6LSVU2JF3TWWLOPANCNFSM47ZPXFDQ
.

Ok, i got it compiled for Android and the emulator is working ;-) Only cannot test the scanner, maybe i will buy a cheap Android phone.

You should be able to use a webcam. It is clunky and grainy.but works.
Are you trying to make a change in specific?
On Fri, Jul 9, 2021, 10:31 AM Alexander @.***> wrote:

Ok, i got it compiled for Android and the emulator is working ;-) Only
cannot test the scanner, maybe i will buy a cheap Android phone.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PantryParty/pantry_party/issues/124#issuecomment-877232056,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQ6MURCLFSGEV7FCK2LC3TW4B4TANCNFSM47ZPXFDQ
.

Yes, I am trying to add "Barcode Data Source" for the Albert Heijn (NL) - because my wife normally buys stuff there.

Awesome! Let me know if you need any help. They have a public api?
On Fri, Jul 9, 2021, 2:38 PM Alexander @.***> wrote:

Yes, I am trying to add "Barcode Data Source" for the Albert Heijn (NL) -
because my wife normally buys stuff there.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/PantryParty/pantry_party/issues/124#issuecomment-877382061,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AABQ6MXMPLOQWJ5QHAE27BLTW4623ANCNFSM47ZPXFDQ
.


cmd/compile/internal/noder: TestUnifiedCompare fails with changes in dev.fuzz branch

I noticed this when merging master into dev.fuzz, originally at CL 347232 PS1. See test log. The error is:
--- FAIL: TestUnifiedCompare (29.96s)
    --- FAIL: TestUnifiedCompare/linux/amd64 (29.95s)
        unified_test.go:121: running /workdir/go/bin/go list -e -export -json -gcflags=all=-d=unified=0 -d=inlfuncswithclosures=0 -d=unifiedquirks=1 -G=0 -- std
        unified_test.go:121: running /workdir/go/bin/go list -e -export -json -gcflags=all=-d=unified=1 -d=inlfuncswithclosures=0 -d=unifiedquirks=1 -G=0 -- std
        unified_test.go:95: package "testing/internal/testdeps": compile output differs
FAIL
FAIL	cmd/compile/internal/noder	29.971s

We use type aliases in testing/internal/testdeps to avoid an import cycle between testing and internal tests of internal/fuzz and the packages it depends on. That may be tripping something here.
Per discussion with @mdempsky, it sounds like this may be an overly strict test. We'll skip it on dev.fuzz for now, but we won't merge dev.fuzz into master before the test is fixed.

@mdempsky  This is in the 1.18 milestone; time to move to 1.19?  Thanks.
As far as I can tell the test doesn't pass right now, but it doesn't seem to be due to fuzzing.
=== RUN   TestUnifiedCompare/linux/amd64
    unified_test.go:128: running /home/iant/go/bin/go list -e -export -json -gcflags=all=-d=unified=0 -d=inlfuncswithclosures=0 -d=unifiedquirks=1 -G=0 -- std
# constraints
../../../../constraints/constraints.go:13:2: syntax error: unexpected ~, expecting method or interface name
../../../../constraints/constraints.go:20:2: syntax error: unexpected ~, expecting method or interface name
../../../../constraints/constraints.go:27:9: syntax error: unexpected |, expecting semicolon or newline or }
../../../../constraints/constraints.go:34:2: syntax error: unexpected ~, expecting method or interface name
../../../../constraints/constraints.go:41:2: syntax error: unexpected ~, expecting method or interface name
../../../../constraints/constraints.go:49:10: syntax error: unexpected |, expecting semicolon or newline or }
    unified_test.go:149: exit status 2

That failure looks like it's because std now includes package constraints, which can't be compiled with -G=0 (because it relies on generics).
I'm leaning towards just removing TestUnifiedCompare anyway. I feel like it's served its purpose of bootstrapping unified IR, and at this point preserving byte-for-byte identical output with -G=0 seems to slow down development more than help.

Both the dev.fuzz branch and the constraint package are gone. I think we can close this.


First part of AWS S3 API, various small fixes.

Pull Request Description

Add type detection for Mixed columns when calling column functions.
Excel uses column name for missing headers.
Add aliases for parse functions on text.
Adjust Date, Time_Of_Day and Date_Time parse functions to not take Nothing anymore and provide dropdowns.

Removed built-in parses.
All support Locale.
Add support for missing day or year for parsing a Date.
All will trim values automatically.

Added ability to list AWS profiles.
Added ability to list S3 buckets.
Workaround for Table.aggregate so default item added works.

Screenshots

Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] The documentation has been updated, if necessary.
[x] Screenshots/screencasts have been attached, if there are any visual changes. For interactive or animated visual changes, a screencast is preferred.
[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.
[ ] If GUI codebase was changed, the GUI was tested when built using ./run ide build.

(btw. the examples next to formats for date/time are just pure gold! I think it's a very cool idea that may be worth expanding into other places)

(btw. the examples next to formats for date/time are just pure gold! I think it's a very cool idea that may be worth expanding into other places)

Ah, and as I was mentioning - I think we need to figure out some way to test S3 and related stuff on CI relatively ASAP - while I appreciate we don't want to make our default checks too slow, the nightly check and an opt-in label to run the additional checks on a specific PR would be really useful - otherwise it's just too easy to introduce breaking changes.


Remove unused http Writer wrapper

What this PR does:
Remove unused http Writer wrapper, and I will bring a new later.
Which issue(s) this PR fixes:

Fixes #
Special notes for your reviewer:
Does this PR introduce a user-facing change?:

Codecov Report

Merging #312 (cece104) into develop (63637b1) will increase coverage by 0.52%.
The diff coverage is 50.00%.

@@             Coverage Diff             @@
##           develop     #312      +/-   ##
===========================================
+ Coverage    36.01%   36.54%   +0.52%
===========================================
  Files           55       54       -1
  Lines         3301     3251      -50
===========================================
- Hits          1189     1188       -1
+ Misses        1992     1943      -49
  Partials       120      120

Impacted Files
Coverage Δ

pkg/common/http/manager.go
66.66% <ø> (-0.99%)
:arrow_down:

pkg/context/http/context.go
6.66% <ø> (+0.48%)
:arrow_up:

pkg/server/listener.go
0.00% <0.00%> (ø)

pkg/filter/metric/metric.go
64.70% <100.00%> (ø)

Continue to review full report at Codecov.

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


Add translator support for Assignment Shift Left token

Hey @samthakur587 can I have this issue?

#149


Pin Jinja2 to use at least 2.10

See original issue on GitLab
In GitLab by [Gitlab user @awacheux] on Jan 16, 2018, 10:20
Jinja2 2.10 import time has been divided by two compared to Jinja 2.9.6.
To prevent any performance issue, we should pin Jinja2 to use at least 2.10.

In GitLab by [Gitlab user @awacheux] on Jan 16, 2018, 10:28
Find attached a Jupyter notebook that demonstrates the issue.
jinja2-benchmark.ipynb

In GitLab by [Gitlab user @jjardon] on Jan 16, 2018, 11:19
mentioned in commit 810b96cd02ff6d812eb2e1b7f76ab160dbe66d0d

In GitLab by [Gitlab user @jjardon] on Jan 16, 2018, 11:19
mentioned in merge request !239

In GitLab by [Gitlab user @jjardon] on Jan 16, 2018, 14:48
mentioned in merge request buildstream-docker-images!16

In GitLab by [Gitlab user @jjardon] on Jan 16, 2018, 14:51
mentioned in commit 301f195fa8f0cdbbb91e1f61494b17dfe6722065

In GitLab by [Gitlab user @jjardon] on Jan 17, 2018, 17:32
mentioned in commit b7099b125ef9c4cd1c1105648f5992b4f4a63fe4

In GitLab by [Gitlab user @jjardon] on Feb 1, 2018, 16:38
mentioned in commit 573a6c8f1c155e1a8509ac4c1e982e9c98ffc836

In GitLab by [Gitlab user @jjardon] on Feb 5, 2018, 13:43
mentioned in commit 945054df3821b7b53183983625f87c2e46fb6dd3

In GitLab by [Gitlab user @juergbi] on Feb 5, 2018, 14:23
closed via merge request !239


Wireframe update

this pr contains updates to the opportunity pages (opportunity table and posts pages) to have them look like the wireframes.

(This PR also seems to include all the changes that were merged in the last PR. Not sure why. I merged the changes (including Seb's adjustments) into this branch from upstream but I assumed that git would recognize that these are not changes that need to be re-applied upstream? Also I don't understand why all these commits seem to be from Mar. 5?  Most are from today or yesterday. Why are you like this git?????


Sentence takes time to understand "Create a new event subscription for an Azure subscription subscription, using default filters."

The page has a sentence that says Create a new event subscription for an Azure subscription subscription, using default filters.
That could be made easier to say, "Create a new event-subscription for Azure Subscription"

Document details
⚠ Do not edit this section. It is required for learn.microsoft.com ➟ GitHub issue linking.

ID: 63e73e1b-aad9-0ce8-be1f-a9b9d02ca6d4
Version Independent ID: 73525c5f-94f3-1c07-e3b6-3a022aab2a10
Content: az eventgrid event-subscription
Content Source: latest/docs-ref-autogen/eventgrid/event-subscription.yml
Service: event-grid
GitHub Login: @rloutlaw
Microsoft Alias: routlaw

route to CXP team

@sijucm Thanks for reaching out to us and reporting this issue. We are looking into this issue and we will provide an update.


operator [R] project-quay (3.9.0-nightly.20230524)

Add 3.9.0-nightly.20230524 to community operators

/merge possible

/merge possible


initial pull request template

Testing if committing this to cql4bonnie works, or if we have to add them to the master branch.
After merged, should populate PR with the template file.

@edeyoung I'm going to merge into cql4bonnie and test if this works. I assume it will not, as detailed in https://help.github.com/articles/creating-a-pull-request-template-for-your-repository/, but would be happy if it does work.


cmake: remove _if_kconfig() functions

This set of functions seem to be there just because of historical
reasons, stemming from Kbuild. They are non-obvious and prone to errors,
so remove them in favor of the _ifdef() ones with an explicit
CONFIG_ condition.
Script used:
git grep -l _if_kconfig | xargs sed -E -i "s/_if_kconfig\(\s*(\w*)/_ifdef(CONFIG_\U\1\E \1/g"

Signed-off-by: Carles Cufi<EMAIL_ADDRESS>

I thought those were actually very useful, nice and clever macros..

I thought those were actually very useful, nice and clever macros..

Beauty is in the eye of the beholder. I personally find them confusing and needless, but let's see what others think. I'll add an RFC to the title.

@nashif Unless I'm mistaken this is unearthing actual bugs:
Found references to undefined Kconfig symbols. If any of these are false
positives, then add them to UNDEF_KCONFIG_WHITELIST in check_compliance.py in the ci-tools repo.

If the reference is for a comment like /* CONFIG_FOO_* */ (or
/* CONFIG_FOO_*_... */), then please use exactly that form (with the '*'). The
CI check knows not to flag it.

More generally, a reference followed by $, @, {, *, or ## will never be
flagged.

CONFIG_GROVE                               drivers/CMakeLists.txt:17
CONFIG_KERNEL                              kernel/CMakeLists.txt:42, kernel/CMakeLists.txt:43
CONFIG_RTC                                 drivers/CMakeLists.txt:27

I personally find them confusing and needless, but let's see what others think. I'll add an RFC to the title.

I also would prefer that the config option is shown there, it is more clearer to the reader so +1 to this one.

Unless I'm mistaken this is unearthing actual bugs:

yup, those predate the kconfig checking and kconfig variables are constructed so kconfig sanity does not catch such issues.

The _kconfig variant makes it harder to search CMakeLists.txt for occurrences of CONFIG or other identifiers that enable certain compilations. If file name gets changed or Kconfig option gets changed, then we end up changing to _ifdef anyway.
The _ifdef variant may be given list of files to include and I do not know whether _kconfig could do the same.

Removed RFC from the title since this seems to have enough support.


Internal Network Exception...

I'm trying to join the server but kick me of proxy for Internal Network Exception.
https://imgur.com/a/WWr20
I send
session.send (new ServerSpawnPositionPacket (pos));
and
session.send(new ServerJoinGamePacket(0, false, GameMode.SURVIVAL, 0, Difficulty.PEACEFUL, 10, WorldType.DEFAULT, false));
Thanks for all solutions!

Any stacktraces?

No.

@Steveice10

What Minecraft version is this, and are you sending the join packet before the spawn position packet?

Minecraft/McProtocolLib version is 1.8.8, yes i sending join packet.

@HP888 anything written in the minecraft log?

No, logs are clear.

Older protocol version is not supported, just use 1.12 or fix this problem yourself :)

@HP888 javastart.pl


Add support for searching scrollback for specific posts/threads

This reduces the needs for searching through IRC client logs for specific post/threads by Mattermost IDs. Instead, we can use the scrollback feature, e.g.:
# Only show the first 5 posts in thread.
/msg mattermost scrollback 1n4gsc6g638q9y53drezgf44gy 5

# Show all posts within the returned thread.
/msg mattermost scrollback 1n4gsc6g638q9y53drezgf44gy 0

Added workaround for https://github.com/mattermost/mattermost-server/issues/23081

matterclient PR has been merged

vendored file needs to be removed also :)

Oh ok, reverted the changes to the vendored file

Cleaning it up cherry-picking the relevant commits into master

Okay, now this is merge-able.


Feature: add broker.publisher(filter=...) option

We should make publisher call optional in a cases where user should suppress an answer for one publisher and still publisher for another one
Example:
@broker.subscriber("in")
@broker.publisher("out1")
@broker.publisher("out2")
async def handler():
    if ...:
        raise SkipMessage   # skip both publishers
    else:
        return "result"     # call both publishers

And with filter API:
@broker.subscriber("in")
@broker.publisher(
    "out1",
    filter=lambda data: bool(data)  # call it if the message is not None
)
@broker.publisher("out2")           # call it always
async def handler():
    if ...:
        return "result"

I think, publisher filter should be one of the following signatures (related to #1431):
def pub_filter(data: Response) -> bool:
    ...

async def pub_filter(data: Response) -> bool:
    ...

We can do it via middleware


Civ 6502

Before creating a pull request make sure that:

[x] commit messages are meaningful and follow good commit message guidelines
[ ] README and other documentation has been updated / added (if needed)
[x] tests have been updated / new tests has been added (if needed)
[x] Screenshot attached for the Evidence of manual testing
[x] Functional, Smoke and API tests have been run locally
[x] Full gradle build and run tests with coverage have been completed (if needed)

Please remove this line and everything above and fill the following sections:
JIRA link (if applicable)
https://tools.hmcts.net/jira/browse/CIV-6502
https://tools.hmcts.net/jira/browse/CIV-6503
Change description
screen 2 and 3
Testing branch and instruction
Does this PR introduce a breaking change? (check one with "x")
[ ] Yes
[x] No

use feature branch


Completely local control of entities via Alexa

Description:
This PR adds the ability to natively discover and control devices via Alexa (Amazon Echo, Dot, or Tap). It accomplishes this by emulating a Philips Hue bridge, which Alexa has native, local support for, presenting entities as lights. Entities that can be turned on (or off) or have their brightness set are supported; this includes lights, scripts, and other devices. It also allows for exposing entities in configurable domains by default, or for only exposing entities that are specifically marked.
This will complete this Pivotal story.
A lot of this code is based off ha-local-echo. Thanks to Bruce Locke!
Python is not a language I use often, and this is my first foray into developing for Home Assistant, so please let me know if there's anything that can be improved! I also have not gotten around to writing tests for this, but I can in the next few days. I can also add documentation to home-assistant.io over the next few days.
Example entry for configuration.yaml (if applicable):
alexa_local_control:
  host_ip: <IP_ADDRESS>
  listen_port: 8300
  off_maps_to_on_domains:
    - script
    - scene
  expose_by_default: true
  exposed_domains:
    - light

homeassistant:
  customize:
    light.bedroom_light:
      # Don't allow light.bedroom_light to be controlled by Alexa
      echo: false
    light.office_light:
      # Address light.office_light as "back office light"
      echo_friendly_name: "back office light"

Checklist:
If user exposed functionality or configuration variables are added/changed:

[ ] Documentation added/updated in home-assistant.io

If code communicates with devices, web services, or a:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[x] New dependencies have been added to the REQUIREMENTS variable (example).
[x] New dependencies are only imported inside functions that use them (example).
[x] New dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
[x] New files were added to .coveragerc.

If the code does not interact with devices:

[ ] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Woah, was not expecting this! Thanks for contributing. There's a few structural issues which i'll point out in line comments momentarily.

This is going to need tests.

Yep, I agree! It's reasonably complex, so I'll add some tests over the next day or so when I have time to do so.

I'd like to come up with a better name for this. Maybe just alexa_local? Or merge it entirely into the alexa component and enable it with a configuration flag...

We also need to be mindful of the Alexa/Hue limit on 49 devices total.

Indeed. I'm not sure what the best way to go about this is, especially since the ability to expose entities by default is there (how do you choose which ones to expose by default if the user has >49 devices?). My first thought would be to expose manually marked ones first, then arbitrarily choose default-exposed entities until we reach 49, but that obviously isn't particularly consistent. Telling users they have to manually mark which entities to expose if they exceed 49 exposed-by-default entities could also work, but that's not very user friendly. Thoughts from others?

I'd rather just have users manually specific up to 49 devices to expose.
We also should filter out real Hue devices by default to remove duplicates.

I think that off_maps_to_on_domains can be hardcoded to only support script and scene.

Thinking more about the overlapping routes issue, I do think it would be best to only accept requests from the Alexa User Agent.
On a similar topic of the component name, I think it might be better to remove the Alexa branding from this, since I could see a bunch of different use cases for this, like with the new Logi Pop buttons. Maybe just name this hue_bridge? Users could then add the User Agents to the list as more device support is added.

We should not use Flask. Instead, use the internal HTTP framework.
To initialize a web server, use this code: https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/http.py#L112-L133
Once you have a server, you can register views on it, like you would in normal Home Assistant land.
You can pass a shared dictionary as constructor to the views so that they share the token registry.

Let's rename this to hue_bridge or fake_hue

Of those two, I'd go for fake_hue, hue_bridge might be confused with the hue component.

I'm open to naming it anything other than what it currently is. Feel free
to come up with a better name :)
On Tuesday, August 23, 2016, Matthew Bowen<EMAIL_ADDRESS>wrote:

Of those two, I'd go for fake_hue, hue_bridge might be confused with the
hue component.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/2942#issuecomment-241812769,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIVHA-tI30kgtbnvUl_Gr-yCPOHvXdks5qiy_1gaJpZM4JqUCO
.

--
Robbie Trencheny (@robbie http://twitter.com/robbie)
925-884-3728
robbie.io

In that case, I'd say 'emulated_hue_bridge or 'emulated_hue would be the most accurate then. The first is the most descriptive, albeit wordy to type.

Let's go for the second option.
On Tuesday, August 23, 2016, Matthew Bowen<EMAIL_ADDRESS>wrote:

In that case, I'd say 'emulated_hue_bridgeor 'emulated_hue would be the
most accurate then. The first is the most descriptive, albeit wordy to type.
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/home-assistant/home-assistant/pull/2942#issuecomment-241813597,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AABIVMeUCEENS0bKrbU6LRQAXqm4pxwGks5qizCPgaJpZM4JqUCO
.

--
Robbie Trencheny (@robbie http://twitter.com/robbie)
925-884-3728
robbie.io

Sounds good! I'll do the rename soon.

What should the echo and echo_friendly_name attributes be renamed to? First thought is emulated_hue_exposed and emulated_hue_friendly_name, both of which are again a bit wordy but accurate.

@mgbowen emulated_hue and emulated_hue_name is fine.

@mgbowen Do you want me to go put all the still valid line comments back in, or can you just look through the existing ones to find what still needs to be done?

I can look through them. When I think I'm at a good point where I've done all that I can think of, I'll ask you to take a look and point out what else should be done. Thanks!

@mgbowen No rush at all, but we are releasing 0.27 in about 16 hours. If you can get those tests happy again before then we should be good to put this into 0.27. Otherwise, it'll wait until 0.28 in 2 weeks. If you can't make that deadline, please do not stress at all about it, just very excited to see this make it in soon 💃

I have coverage at a good place, so let me see if I can get my tests to run correctly. I'd love to see it make it into 0.27!

💃!

Looks like it's all good to me! Want me to squash the commits into one? Also, do you want me to throw together some documentation for home-assistant.io real quick?

We can take care of the squash when we merge it. Go ahead and start writing docs for this. I'll take a deeper look at this now to make sure it's good.

Once all my line comments are fixed up this should be good to merge, but I want a second pair of eyes to look so @Teagan42 will be later tonight. It also still needs docs.

Great! I just pushed commits that should fix everything but the username stuff, and I'm in the process of writing documentation now, should be done fairly soon.

I created a PR for home-assistant.github.io: https://github.com/home-assistant/home-assistant.github.io/pull/845. Please let me know if anything needs to be changed or added; I imagine the sidebar is one thing that needs to be looked at.

btw ping @blocke, just want to make sure he knows this is being added :)

Thanks! 🐬 🍪 💯

@mgbowen So a few things to improve this component now that it's merged:

type should be different based on capability. If the entity is a switch, it should be "On/off light", if it's a on/off light same thing, if it's a light that supports color then "Color temperature light". Full list is here on Hue API docs.
That username authentication thing I mentioned. You should be storing a list of all registered usernames in a file. If someone tries to access the API and the file doesn't list the username they are attempting to use, then block it.

I've got nothing else for the moment, it's working fantastically so far! Thanks for your hard work on this!!!

Sounds good. I'm moving apartments this weekend, so I might not be able to get to it for a bit, but I'll try hopefully before 0.28!

On Aug 30, 2016, at 6:05 PM, Robbie Trencheny<EMAIL_ADDRESS>wrote:
@mgbowen So a few things to improve this component now that it's merged:
type should be different based on capability. If the entity is a switch, it should be "On/off light", if it's a on/off light same thing, if it's a light that supports color then "Color temperature light". Full list is here on Hue API docs.
That username authentication thing I mentioned. You should be storing a list of all registered usernames in a file. If someone tries to access the API and the file doesn't list the username they are attempting to use, then block it.
I've got nothing else for the moment, it's working fantastically so far! Thanks for your hard work on this!!!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.

@mgbowen  For sure, thank you for your hard work.
+1 to @robbiet480  suggestion. I've protected the API via an iptables rules to allow only the HASS IP and Alexa to connect it, but would be nice to have an authorization set for it.
I also bought to test an Osram Lightify Garden lights and when using the emulated_hue via voice command it works (it toggle the lights on/off), however Alexa returns an error message It is working for other platform and devices. I'll dig into to it a little bit later this week.
Thank you again!

Just a heads up that I updated my list.


Filling out HTTP API

for remaining integration with travis-api, travis-hub, and travis-:ghost:

The "request change" thing is mostly for the constant-time comparisons for auth tokens. The remainder are just things that I noticed that I'm not sure about, I'll leave those up to you.


[es-dev-server] concatening twice the CWD and cannot find the configuration file.

Issue
I have a es-dev-server.config.js in the directory where I execute es-dev-server.
The configuration file is ignored.
This is what I get when using the --debug option

Given the current working directory is /root/gits/hanja-everlast in this case the path is twice concatenated when trying to resolve the configuration file.
Versions
os : Debian 9 (stretch)
es-dev-server :  1.35.0
Additional informations

If I use -c es-dev-server.config.js directly, it works.
I don't have this issue on my development machine (Fedora 31) although I have the same es-dev-server, node and npm version installed.

I'm running into the same issue as well. I created a small repo to demo the issue: https://github.com/rodrigo-garcia-leon/es-dev-server-default-config-issue
In the repo, running npm start results in nothing, whereas running npm start:config opens the index.html file in a browser. This last behavior is the one expected in this case, since the config file has the open option in it.
Going into the code, in the file packages/es-dev-server/src/command-line-args.js I see the following (lines 215-220):
    const defaultConfigPath = path.join(
      process.cwd(),
      dashesArgs['root-dir'] || '',
      defaultConfigDir,
      defaultConfigName,
    );

Like @vdegenne mentions, the CWD is being concatenated twice, because earlier in the code the variable defaultConfigDir is populated by a call to process.cwd() (line 163).
I guess this could be solved by doing something like this instead:
    const defaultConfigPath = path.join(
      defaultConfigDir,
      dashesArgs['root-dir'] || '',
      defaultConfigName,
    );

So CWD only comes from defaultConfigDir, and the option root-dir is used for subsequent traversal if specified by the user.

Oddly on my fedora I run now into the same issue as well. I need to use -c <config-filename> explicitly.

Thanks for reporting this guys


nixos/parsedmarc: follow upstream configuration

Starting in version 8.0.0, most options from the imap section have been moved to the mailbox section.

https://github.com/domainaware/parsedmarc/commit/6b2131f0e80e1ab8908540e3d2547b9503b784e5
Description of changes

Things done

Built on platform(s)

[x] x86_64-linux
[ ] aarch64-linux
[ ] x86_64-darwin
[ ] aarch64-darwin

[ ] For non-Linux: Is sandbox = true set in nix.conf? (See Nix manual)
[x] Tested, as applicable:

NixOS test(s) (look inside nixos/tests)
and/or package tests
or, for functions and "core" functionality, tests in lib/tests or pkgs/test
made sure NixOS tests are linked to the relevant packages

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[ ] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.05 Release notes)

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

CCing @talyz for a review since I'm unable to do so via GitHub.

Sorry for the late reply, I totally missed this! Everything looks good to me! Thanks!


(PUP-8265) Remove ExecutionResult and Target data types

This commit removes the ExecutionResult and Target data types from
the puppet core. They will instead be added to the boltlib module.

CLA signed by all contributors.

Changes have already happened on Puppet that break bolt, so if we want to use puppet#master even without this change I think we'll need to merge https://github.com/puppetlabs/bolt/pull/202.

It looks like https://github.com/puppetlabs/bolt/pull/202 actually depends on this.


Remove preview Portal.

Events tab is visible without need of feature flag

@jlichwa : Thanks for your contribution! The author(s) have been notified to review your proposed change.

#please-close


SSL connect error code: 35

I update a utility that was working fine, but then getting in a few machines this error (SSL connect error code: 35) and was unable to see what could have caused it.
I tried compiling everything statically (the first was the past version and the second is upgrade):
isahc = { version = "0.9.13", features = ["static-ssl", "static-curl", "text-decoding", "http2", "json", "cookies"] }

isahc = { version = "1.4.0", features = ["static-ssl", "static-curl", "text-decoding", "http2", "json", "cookies"] }

The affected machines are all windows server r2. How can I diagnose this?

Thanks for filing an issue! This definitely should not be the case, so something must be going wrong here. At the very least, SSL connect error code: 35 is a really poor error message! Let's see if we can get to the bottom of this.
First, if you have a larger error string or panic message, its always helpful to include that so that we can see more context.
Second, could you share how you are configuring your HTTP requests? And, if you're using a custom HttpClient instance, please share how you've configured that as well. That will help identify if the issue could be related to a particular configuration.
Thirdly, you can get a lot more debugging information if you capture the log output on the isahc logging target. If you don't have a log-compatible logger already, you can capture this using a logger like env_logger and then setting an environment variable before running your utility: RUST_LOG=isahc=debug. This will print out lots of useful information, particularly around SSL which we are interested in. If you could share that here (first sanitizing any sensitive data you might have of course) then that would probably be the biggest help in identifying the problem.
My gut reaction is that this might be a regression in the curl VTLS engine on Windows, but I can't be confident of anything yet! There's no changes to Isahc's default SSL configuration between 0.9.x and 1.x that I recall.

Is super-weird, the RUST_BACKTRACE=1 does not work on that windows (?), so the only thing I get is the same error.
Other enterprise software made by another company in .NET/SQL Server also gets hit by an SSL error.
I try to extract a minimal sample with the same code (bellow) and it does not trigger the bug, which makes me flip :). Our customers were desperate so I replace isahc with ureq (hail static types and easy refactorings with Rust!):
`ureq = { version = "2.1.1", features = ["default", "json", "charset", "cookies"] }
And it works.
This is likely a very freaky bug so our workaround works for us so far. I think close the issue and just put it here in case other people get affected and we can get more info...
P.D: The site SSL was from cloudflare. The code to call it was:
use isahc::prelude::*;
use std::time::Duration;
use isahc::{HttpClient, HttpClientBuilder, Response, Body};
use isahc::auth::Authentication;
use isahc::http::request::Builder;
use isahc::Request;
use serde::{Serialize, Deserialize};
use isahc::config::{SslOption, CaCertificate};

#[derive(Debug, Clone, Serialize, Deserialize)]
pub struct LoginRow {
    pub company: String,
    pub user_name: String,
    pub password: String,
    pub client_id: String,
}

impl LoginRow {
    pub fn new() -> Self {
        LoginRow {
            company: "_sync".to_string(),
            user_name: "abc".into(),
            password: "12345678".into(),
            client_id: "Web".to_string(),
        }
    }

    pub fn new_user_auto(company: &str, user: &str) -> Self {
        LoginRow {
            company: company.to_string(),
            user_name: user.to_string(),
            password: "".to_string(),
            client_id: "Web".to_string(),
        }
    }
}

pub fn build_client(timeout: u64) -> HttpClientBuilder {
    let timeout = Duration::from_secs(timeout);

    HttpClient::builder().timeout(timeout).cookies()
}

pub fn build_request( headers: &[(&str, &str)], url: &str, agent: &str) -> Builder {
    let mut req = Request::builder()
        .header("Accept-Encoding", "gzip, deflate")
        .header("User-Agent", agent)
        .ssl_ca_certificate(CaCertificate::file("curl-ca-bundle.crt")) //try with same from Curl, not change on bug
        .authentication(Authentication::all());

    for (name, value) in headers {
        req = req.header(*name, *value);
    }

    req.method("POST")
        .timeout(Duration::from_secs(60 * 5))
        .uri(url)
}

pub fn fetch<B>(
    client: &HttpClient,
    url: &str,

    headers: &[(&str, &str)],
    body: &B,
) -> Result<Response<Body>, isahc::Error>
    where
        B: Serialize + core::fmt::Debug,
{
    let mut body = serde_json::to_vec(&body).unwrap();
    // Hack for a customer that don't accept a body on GET (this is called with '()')
    if body == [110, 117, 108, 108] {
        body.clear();
    }

    let response = build_request( headers, url, "Sync/1.0").body(body)?;
    let response = client.send(response)?;

    Ok(response)
}

fn isaac() -> Result<(), isahc::Error> {
    let client = build_client(10000 * 3).build()?;
    let headers = &[("content-type", "application/json")];
    let url ="https://???.???.net/v1/api/login"; //cloudflare serve this

    let login = LoginRow::new();
    let response = fetch(&client, url,  headers, &login)?;

    println!("Headers: {:#?}", response.headers());
    println!("Status: {}", response.status());

    Ok(())
}

fn main() -> Result<(), bool> {
    isaac().map_err(|e| {
        eprintln!("{}", e);
        false
    })
}

I don't want to put undue pressure on you if you don't have the time to help (if not that's OK) but I'd still like to get to the bottom of this and discover the root cause if possible and see if there's something we can do about this from Isahc.
A possible reason ureq worked is that it uses rustls as the SSL engine instead of the operating system's SSL engine, so I suspect that's where things are going astray. It could be that the SSL settings configured in the operating system isn't correct, or certificates aren't quite configured right, or something along that nature.
Using env_logger and RUST_LOG is definitely the way to go here to capture more troubleshooting information. In it the logs will state explicitly what SSL engine is being used and how it is being initialized.
(I'm sad to see you go, but ureq is a good library too.)


How to rewrite output file name with settings.json?

Is there a setting I can use in settings.json to rewrite the root-part of the output filename (not the extension)? For instance, I want to have what is called "style.scss" in my dev/ folder output to "index.css" in my css/ folder.
I tried using savePathReplacementPairs like this:
          "savePathReplacementPairs": {
            "/style.css/": "/index.css/"
          },

Here's my full settings.json:
{
  "liveSassCompile.settings.formats": [
      {
          "format": "expanded",
          "extensionName": ".css",
          "savePathReplacementPairs": {
            "/style.css/": "/index.css/"
          },
          "savePath": "/css"
      },
      {
        "format": "compressed",
        "extensionName": "min.css",
          "savePath": "/css"
      }
  ],
  "liveSassCompile.settings.excludeList": ["**/node_modules/**", ".vscode/**"],
  "liveSassCompile.settings.generateMap": false,
  "liveSassCompile.settings.autoprefix": ["defaults"],
  "liveSassCompile.settings.partialsList": [
    "/**/_*.s[ac]ss"
  ],
}

Related to: #350

Sorry, it's not possible.
The extension has always done straight conversions to not risk user unintentionally overwriting files - because of this the functionality isn't there.
This has been requested on the odd occasion. When I start actively working on the v7 stuff I'll keep this in mind; but there's no guarantee I'll be able to figure a way to incorporate it - as such, I'll close this issue

Again, please feel free to continue commenting if you have more queries


Always use latest emoji DB

Hesitant to use this in prod because, if a new version's pushed out that changes the structure of the JSON file, we'll start getting errors for no immediately obvious reason.
It's more trouble in the long-term, but I'd go for version locking, at the very least major (not sure if possible to specify a semver range in the link).


Update Blocto wallet creation instructions

Context
Currently, the blocto wallet creation instructions on the doc site is out of date
https://docs.onflow.org/flow-token/delivery/#blocto
Following these instructions is not sufficient to receive a wallet that is ready for Token Delivery from DapperLabs (e.g. has a properly setup Locked Tokens side car account)
There are additional steps that must be followed.
Ideally, we'd get this in ASAP as many people are currently creating accounts for Token Delivery over the next month or so

This should be added to after one sets up a Blocto wallet successfully as additional steps to ensure the Blocto wallet is capable of receiving locked FLOW.

Download the Blocto app
Open browser in Blocto app
Go to: https://flow-wallet.blocto.app/lock-account
Follow the instructions and set up lock account
OR
Or alternatively, on your mobile device use this link https://blocto.app.link/locked-flow. This will take users through download and open that lock account page

OK, I added these instructions:
https://github.com/onflow/flow/pull/624
@hanaito0 @Kay-Zee


After chat setup outline

huh says we have a broken url for this: (updates can be made during the Just-in-Time process) but it seems fine in the previous PR

huh says we have a broken url for this: (updates can be made during the Just-in-Time process) but it seems fine in the previous PR

nevermind... I think we have a duplicate report thing happening

huh says we have a broken url for this: (updates can be made during the Just-in-Time process) but it seems fine in the previous PR

nevermind... I think we have a duplicate report thing happening

Nah, this is related to: https://github.com/jhudsl/OTTR_Template/issues/590 which has actually been a long standing problem. You can add this url to ignore_urls.txt in the meantime if you don’t want the alert.

huh says we have a broken url for this: (updates can be made during the Just-in-Time process) but it seems fine in the previous PR

nevermind... I think we have a duplicate report thing happening

Nah, this is related to: jhudsl/OTTR_Template#590 which has actually been a long standing problem. You can add this url to ignore_urls.txt in the meantime if you don’t want the alert.

hmm I did that be then got this:

I think I will just add the remaining structure that we talked about if that's ok?

Okay. Thanks for letting me know. It’s apparently having a lot of trouble with this format of url but it should be made to be more flexible than this.

OK I added the structure that I thought we talked about - we can always undo the last commit if we don't like it. :)
I added more chapters to make it easier for us to not overlap.

LGTM and we can always tweak it later :)