RMS updates to Investigation context products #1

🗒 Summary
This is the first round of Investigation context product updates from the RMS Node.

Regarding the HST context product, we have noticed that there are three distinct versions of the Description:

The version that was historically in the context product, which is found in v1.1
The version in v1.2, which was truncated to only the first paragraph of the previous
The version in the draft webpage

In our v1.3 of the context product, we have synthesized by adding the best parts of the webpage's description to the v1.2 description.  We would like to discuss whether there is any home for the later paragraphs of the v1.1 description.

For all three of the context products edited so far in this round version 1.1 (1, 2, 3) contains a much longer Description that should be preserved somewhere.

Regarding HST, we have noticed that the Description in v1.2 of the context product is quite different from the version in the draft webpage
In our v1.3 of the context product, we have synthesized by adding the best parts of the webpage's description to the v1.2 description.  However, we are curious about where the webpage description came from.

Still to do:

Rescue the PDS3 context product urn:nasa:pds:context_pds3:investigation:mission.saturn_occultation_of_28_sagittarius_1989
Participate in updating the context products on which we are listed as contributors: namely Cassini and Juno (lead node: ATM), and Galileo and Voyager (lead node: PPI).  Hey @jmafi and @lylehuber, anything yet to discuss regarding these?

@matthewtiscareno

Regarding HST, we have noticed that the Description in v1.2 of the context product is quite different from the version in the draft webpage
In our v1.3 of the context product, we have synthesized by adding the best parts of the webpage's description to the v1.2 description. However, we are curious about where the webpage description came from.

This is a known confusion with the current portal design: https://github.com/NASA-PDS/web-modernization/issues/245
That is actually displaying the description for the HST Instrument Host NOT the Investigation description. Both are supposed to be captured on this portal page, but that is not currently occurring. We introduced some refinements to this design at our last WMWG meeting (include both Investigation and Instrument Host descriptions on the same tab, with links to "deep dive" pages with more information), but that has yet to be implemented.

when updating the labels in the "working" directories for this exercise, there is no need to create new versions of the products

I understand the point.  But the thing is that the version that you have put into the working directory has some substantial changes from the previous version, and I might want to make changes upon those changes.  We can talk about the best way to bookkeep this, but in order to keep track of whose version is whose, I thought a version increment might make sense.
Maybe the best thing to say at this point is that I'll fold my version into yours once we have come to consensus.

Following up after discussion: I see @jordanpadams's point and have merged my versions into the pre-existing versions created by EN in the working directory.

Hey @jordanpadams and EN team:  Please note this commit, in which I copied (without changing) the file mission_SATURN_OCCULTATION_OF_28_SAGITTARIUS_1989_1.0.xml from the context-pds3 directory into the working directory, and also created v1.1 of the same (with fixed filename including lowercase letters and a . between mission and saturn).
We went ahead and rewrote the description to conform with this effort.  However, the other tasks that you all did to the other context products have not been done here.  Would this be our job, or can we toss that task to you?

@matthewtiscareno we can give the other updates a shot. thanks!

@rchenatjpl for this context product update effort, @matthewtiscareno migrated the "SATURN OCCULTATION OF 28 SAGITTARIUS 1989" mission from our PDS3 context holdings to PDS4, but it will also need some of the telescopes migrated as well (or the PDS4 equivalents identified). Can you help us with that?
urn:nasa:pds:context_pds3:instrument_host:earth-based.eso1m
urn:nasa:pds:context_pds3:instrument_host:earth-based.eso22m
urn:nasa:pds:context_pds3:instrument_host:earth-based.lick1m
urn:nasa:pds:context_pds3:instrument_host:earth-based.pal200

I think so. Let me look

@matthewtiscareno FYI, I removed the old PDS3 context product from the branch since I think it is more confusing having it there. We also already have a copy of that PDS3-migrated version out there in our system bundle.
I also went ahead and migrated the label from the Product_Mission_PDS3 to Product_Context and the appropriate mods to support. Let me know if I missed anything.

PDS3 insthosts got (properly) split up into facility and telescope in PDS4.

urn:nasa:pds:context_pds3:instrument_host:earth-based.eso1m
This one exists already:
urn:nasa:pds:context:facility:observatory.eso-la_silla
urn:nasa:pds:context:telescope:eso-la_silla.1m04
I assume you’ll also need to map the context_pds3 instrument
urn:nasa:pds:context_pds3:instrument:apph.eso1m
The only 2 instruments defined so far at the PDS4 telescope are
urn:nasa:pds:context:instrument:eso-la_silla.1m04.denis
urn:nasa:pds:context:instrument:multi-host.generic_insp_hsp
The latter is probably correct. Should I ask someone who may know better, e.g. Lynn? I.e. are these two the same:
https://pds.nasa.gov/data/pds4/context-pds3/instrument/Product/inst_APPH__ESO1M.xml
https://pds.nasa.gov/data/pds4/context-pds4/instrument/multi-host.generic_insp_hsp_1.0.xml

urn:nasa:pds:context_pds3:instrument_host:earth-based.eso22m
This also already exists. Same facility as above, different telescope
urn:nasa:pds:context:facility:observatory.eso-la_silla
urn:nasa:pds:context:telescope:eso-la_silla.2m2
The one instrument in the context_pds3 product:
urn:nasa:pds:context_pds3:instrument:apph.eso22m
probably also maps to
urn:nasa:pds:context:instrument:multi-host.generic_insp_hsp
urn:nasa:pds:context_pds3:instrument_host:earth-based.lick1m
The facility already exists as a PDS4 context product
urn:nasa:pds:context:facility:observatory.lick
but the 1meter telescope does not. Shall I create it? They’d be
urn:nasa:pds:context:facility:observatory.lick.nickel1m
The two context_pds3 instruments are:
urn:nasa:pds:context_pds3:instrument:ccdc.lick1m
urn:nasa:pds:context_pds3:instrument:hsccd.lick1m
These would be harder to map. It looks like people can attach their own instruments to this telescope, and I can’t easily tell if the two above are still there (https://mthamilton.ucolick.org/techdocs/telescopes/Nickel/intro/)
If there’s time pressure, I would just translate the two context_pds3 to
urn:nasa:pds:context:instrument:lick.nickel1m.ccdc
urn:nasa:pds:context:instrument:lick.nickel1m.hsccd

urn:nasa:pds:context_pds3:instrument_host:earth-based.pal200
urn:nasa:pds:context:facility:observatory.palomar
urn:nasa:pds:context:telescope:palomar.hale_5m08
The 1 context_pds3 instrument in the pds3 insthost is:
urn:nasa:pds:context_pds3:instrument:circ.pal200
which has no pds4 equivalent yet. There’s a fair chance the camera’s been replaced. I would probably translate the existing product to:
urn:nasa:pds:context:instrument:palomar.hale_5m08.circ
“CIRC” is pretty general (Cassegrain infrared camera), but I don’t know enough to pick a better ID

> urn:nasa:pds:context_pds3:instrument_host:earth-based.eso1m
This one exists already:
  urn:nasa:pds:context:facility:observatory.eso-la_silla
  urn:nasa:pds:context:telescope:eso-la_silla.1m04
I assume you’ll also need to map the context_pds3 instrument
  urn:nasa:pds:context_pds3:instrument:apph.eso1m
The only 2 instruments defined so far at the PDS4 telescope are
  urn:nasa:pds:context:instrument:eso-la_silla.1m04.denis
  urn:nasa:pds:context:instrument:multi-host.generic_insp_hsp
The latter is probably correct. Should I ask someone who may know better, e.g. Lynn? I.e. are these two the same:
  https://pds.nasa.gov/data/pds4/context-pds3/instrument/Product/inst_APPH__ESO1M.xml
  https://pds.nasa.gov/data/pds4/context-pds4/instrument/multi-host.generic_insp_hsp_1.0.xml

> urn:nasa:pds:context_pds3:instrument_host:earth-based.eso22m
This also already exists. Same facility as above, different telescope
  urn:nasa:pds:context:facility:observatory.eso-la_silla
  urn:nasa:pds:context:telescope:eso-la_silla.2m2
The one instrument in the context_pds3 product:
  urn:nasa:pds:context_pds3:instrument:apph.eso22m
probably also maps to
  urn:nasa:pds:context:instrument:multi-host.generic_insp_hsp
> urn:nasa:pds:context_pds3:instrument_host:earth-based.lick1m
The facility already exists as a PDS4 context product
  urn:nasa:pds:context:facility:observatory.lick
but the 1meter telescope does not. Shall I create it? They’d be
  urn:nasa:pds:context:facility:observatory.lick.nickel1m
The two context_pds3 instruments are:
  urn:nasa:pds:context_pds3:instrument:ccdc.lick1m
  urn:nasa:pds:context_pds3:instrument:hsccd.lick1m
These would be harder to map. It looks like people can attach their own instruments to this telescope, and I can’t easily tell if the two above are still there (https://mthamilton.ucolick.org/techdocs/telescopes/Nickel/intro/)
If there’s time pressure, I would just translate the two context_pds3 to
  urn:nasa:pds:context:instrument:lick.nickel1m.ccdc
  urn:nasa:pds:context:instrument:lick.nickel1m.hsccd

> urn:nasa:pds:context_pds3:instrument_host:earth-based.pal200
This already exists:
  urn:nasa:pds:context:facility:observatory.palomar
  urn:nasa:pds:context:telescope:palomar.hale_5m08
The 1 context_pds3 instrument in the pds3 insthost is:
  urn:nasa:pds:context_pds3:instrument:circ.pal200
which has no pds4 equivalent yet. There’s a fair chance the camera’s been replaced. I would probably translate the existing product to:
  urn:nasa:pds:context:instrument:palomar.hale_5m08.circ
“CIRC” is pretty general (Cassegrain infrared camera), but I don’t know enough to pick a better ID```

@rchenatjpl

urn:nasa:pds:context_pds3:instrument_host:earth-based.lick1m
The facility already exists as a PDS4 context product
urn:nasa:pds:context:facility:observatory.lick
but the 1meter telescope does not. Shall I create it? They’d be
urn:nasa:pds:context:facility:observatory.lick.nickel1m
The two context_pds3 instruments are:
urn:nasa:pds:context_pds3:instrument:ccdc.lick1m
urn:nasa:pds:context_pds3:instrument:hsccd.lick1m
These would be harder to map. It looks like people can attach their own instruments to this telescope, and I can’t easily tell if the two above are still there (https://mthamilton.ucolick.org/techdocs/telescopes/Nickel/intro/)
If there’s time pressure, I would just translate the two context_pds3 to
urn:nasa:pds:context:instrument:lick.nickel1m.ccdc
urn:nasa:pds:context:instrument:lick.nickel1m.hsccd

Yes. Let's create the 1m telescope and the associated instruments if you can? Not a super time crunch here, but would like to have this information tracked. If you are concerned it is not accurate, then let's punt on the instruments for now and we can try to figure out who the experts on that would be to give us info.

urn:nasa:pds:context_pds3:instrument_host:earth-based.pal200
This already exists:
urn:nasa:pds:context:facility:observatory.palomar
urn:nasa:pds:context:telescope:palomar.hale_5m08
The 1 context_pds3 instrument in the pds3 insthost is:
urn:nasa:pds:context_pds3:instrument:circ.pal200
which has no pds4 equivalent yet. There’s a fair chance the camera’s been replaced. I would probably translate the existing product to:
urn:nasa:pds:context:instrument:palomar.hale_5m08.circ
“CIRC” is pretty general (Cassegrain infrared camera), but I don’t know enough to pick a better ID

Copy that. If we could get an instrument context product, that would be awesome.

I appreciate you working on this, @rchenatjpl.  To some extent, the questions you are asking will be the purview of whoever does the work of migrating this data set to PDS4, which has not happened yet.  Since this a bare context product without (as yet) any PDS4 data to point to it, I suggest you might make your best stab and not worry too much about the details.

@jordanpadams, thank you for updating the 28 Sgr context product. Here are some items I noticed:

The Identification_Area.name and Investigation.name are both still in all caps.  In fact, this is true for many context products.  Should we fix these?
I see that the LID contains observing_campaign rather than mission, which is fine.  Should we then change the filename to reflect that?
Speaking of having observing_campaign in the LID, it would be great if the context products for saturn_small_satellite_astrometry and saturn_ring_plane_crossing_1995 could have LIDs that correspond in this way.  These data sets have not been migrated to PDS4, so these context products were created prematurely and could be seen to fall under the policy in 6D.3.1 of the Standards Reference that allows multiple drafts before solidifying one as v1.0

I believe @jordanpadams wants me to merge this PR, so I'll go ahead and do that.  The items identified in my last message can be addressed later.

@matthewtiscareno

The Identification_Area.name and Investigation.name are both still in all caps. In fact, this is true for many context products. Should we fix these?

Yes. I should have probably done that but ran onto other tasks. Not super critical right now.

I see that the LID contains observing_campaign rather than mission, which is fine. Should we then change the filename to reflect that?

@rchenatjpl thoughts?

Speaking of having observing_campaign in the LID, it would be great if the context products for saturn_small_satellite_astrometry and saturn_ring_plane_crossing_1995 could have LIDs that correspond in this way. These data sets have not been migrated to PDS4, so these context products were created prematurely and could be seen to fall under the policy in 6D.3.1 of the Standards Reference that allows multiple drafts before solidifying one as v1.0

@rchenatjpl thoughts? I am OK with changing these.


crash on active/start

Turning "activate on launch" and "start at login" muliple times on and off crashes the app
21.11.14 11:11:37,056 KeepingYouAwake[10356]: Unbalanced call to enableRelaunchOnLogin: enableRelaunchOnLogin was called without a preceding call to disableRelaunchOnLogin

This crash bug should be fixed in v1.2.1.

Updates?


wildcards for subfolders not working

I believe that this src: ['dist/**/*.js'] is not working, or may be i'm doing something wrong… how can i include all js files located in 'dist' and all subfolders??

I discovered the issue with this and am in the process of resolving it


Reading shebang in comment

In my Emacs config, I have clang-format do most of my formatting.
Adding a shebang: #!/usr/bin/c -Wall -Wextra -Werror seems to mess with the formatter.
Perhaps it might be possible to put the shebang in a comment:
// #!/usr/bin/c -Wall -Wextra -Werror

and have c look for it with regex: ^\/\/[\s]?#!.*?

So here's the thing, you can comment out the shebang, but then it becomes kinda useless -- you can't execute the script with ./main.c. You could just forgo the shebang entirely and use c main.c instead.

I see. I thought the shebang was a way to pass CFLAGs. But if that's not part of the current implementation, then I understand not needing it all.


Improve ssl compose with client certs

kafka-ssl.yml: add KAFKA_CLUSTERS_0_PROPERTIES_SSL_KEYSTORE_PASSWORD and KAFKA_CLUSTERS_0_PROPERTIES_SSL_KEYSTORE_LOCATION

Can I work on this?

@FireNdIce3 hey, sorry, it's already done within #2574. Feel free to look at other issues on "up for grabs" board or via "good first issue"/"hacktoberfest" labels :)


Provide Docker image

Hey!
This exporter is exactly what I am looking for. Sadly I don't want to maintain a docker image, which is for obvious reasons going to be outdated every now and then.
Would it be possible to provide a Docker image right away?

As far as I can see in the repository, the docker is ready for a long time.

There was a typo in the docs that @maksim77 fixed, should work now!

Docker file in the repository. Closing this issue.


Blogs design

Description of the change

Screenshots
Check Netlify Preview Builds
Checklist

[x] Added description of the change
[x] I've read the contributing guidelines
[x] Search previous suggestions before making a new PR, as yours may be a duplicate.
[x] I acknowledge that all my contributions will be made under the project's license.

Notes (optional):

Btw just noticed this now after refreshing the website:

wdym? Is their something I should change?

Btw just noticed this now after refreshing the website:

wdym? Is their something I should change?

the 3rd image is bigger than the 1st and 2nd image


[NAJDORF] Bump rails to <IP_ADDRESS>

Updated Gemfile.lock.release after backport of https://github.com/ManageIQ/manageiq/pull/21812

@chessbyte These failures are unrelated to this PR, and are probably related to the backport of https://github.com/ManageIQ/manageiq/pull/21787.  @agrare @iv1111 can you take a look at these failures and determine if some test needs backporting?

would a rebase fix this?
Does seem like an odd failure

Rebased after backporting #21782, which was missed.


Add Chinese translation

Hi, I just added this simplified Chinese translation. Hope it helpful.

cool! thank you.


rofi-calc: init at 1.6

Motivation for this change
Add the rofi-calc plugin and add a way to add rofi plugins in a pure way as well.
Also adding @albakham as a maintainer since he's interested in helping to keep it up to date.
Things done

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)
Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)
[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"
[ ] Tested execution of all binary files (usually in ./result/bin/)
[ ] Determined the impact on package closure size (by running nix path-info -S before and after)
[ ] Ensured that relevant documentation is up to date
[ ] Fits CONTRIBUTING.md.

related PR: https://github.com/rycee/home-manager/pull/1109

@luc65r you might want to cherry-pick https://github.com/NixOS/nixpkgs/pull/79661/commits/e1efcdfd694afce1be996c6c4066d5a2564bdfbc here or move it to an individual PR


Fixed Rate Exchange Flow README.

Fixes #443  .
Changes proposed in this PR:

added a README for describing the FRE flow for ocean.py.

This is the correct output after the execution of buy_at_fixed_rate ended.

For search_exchane_by_data_token, this is the output that I got after playing around with that functionality.


4.1.3 tag not found

Despite the official Docker Hub page saying that 4.1.3 is a supported tag, it doesn't actually appear to exist — it's not listed on the tags page, nor is it in the Github tag details page. Is there a process by which that tag needs to be populated in the hub?
(Given that Elastic is billing this as an important security update, I'd like to be able to update to it...)

Hey, sorry about that -- it did get pushed, but the build was delayed a little bit; can you confirm that you're able to pull it down?

Confirmed!


PT Run is still not working with the new version

Microsoft PowerToys version
0.53.3
Running as admin

[X] Yes

Area(s) with issue?
PowerToys Run
Steps to reproduce
I use my assigned shortcut
✔ Expected Behavior
see the Run interface to search something
❌ Actual Behavior
Nothing happens, as if I had not used the shortcut
Other Software
PowerToysReport_2022-01-15-04-01-08.zip

Nothing in the logs seem to claim something is wrong at quick glance.  I can get this to fire with control-A as the keystroke (it is also a common keystroke, fyi).  If you use the default keystroke, does it work?  /needinfo
One quick thing you could do is delete the "settings.json" folder here: %LocalAppData%\Microsoft\PowerToys\PowerToys Run\

Nothing in the logs seem to claim something is wrong at quick glance. I can get this to fire with control-A as the keystroke (it is also a common keystroke, fyi). If you use the default keystroke, does it work? /needinfo
One quick thing you could do is delete the "settings.json" folder here: %LocalAppData%\Microsoft\PowerToys\PowerToys Run\

The folder that you have mentioned before do not exist on my W11 pc, it just exist a folder called Microsoft-Corporation. Nothing about PowerToys exist. So... tell me the next steps please, and thank you so much for your time

Are you still experiencing this issue? /needinfo


factorio: update factorio to 0.14.21

updates factorio to the latest release

Should the chart version also be bumped?

@lachie83 good idea. done

Thanks LGTM

@k8s-bot ok to test


net: wifi: Add API docs

Add a basic API docs, this can be extended to add detailed sections and details in future PRs.
Based on #59249 as that has few structure changes.

Raised: https://github.com/zephyrproject-rtos/zephyr/pull/60406


Call resolving for languages without function overloading

It might be, that we are a little bit to strict with the current call resolving.
We always check the parameter types, also for languages where no function overloading exists.
This will not map function calls, where one of the parameters have an UNKNOWN type.
This is the relevant code part:
https://github.com/Fraunhofer-AISEC/cpg/blob/fdc642b9c2b7e890e97f59a0eba154d48c05166e/cpg-core/src/main/kotlin/de/fraunhofer/aisec/cpg/ScopeManager.kt#L719-L731
Theoretically, for the "not HasFunctionOverloading" case, we could finish here with an ==1:
https://github.com/Fraunhofer-AISEC/cpg/blob/fdc642b9c2b7e890e97f59a0eba154d48c05166e/cpg-core/src/main/kotlin/de/fraunhofer/aisec/cpg/ScopeManager.kt#L723-L725
Or we only take the shortcut, when one of the types is unknown.
Update: Of course, the number of arguments must match, otherwise something is going wrong.
What do you think?
Example where current call resolving fails:
//#define MY_CONST_INT 1

void foo(int i) {
}

int main() {
    foo(MY_CONST_INT);
    return 0;
}

Independent of the function overloading thing, we could think about, if we want to allow casting from UNKNOWN type to any type to relax and over approximate the function resolution.


Add grid view, drop filtering, persistent drops, auto-start

Changelog:
Updated Dashboard:
New grid view option for the dashboard, with toggles to switch between list and grid layouts.
View preferences are saved between sessions.
Added ability to expand all character cards simultaneously.
Added Total Drops counter, which leads to the combined drops page for All Characters.
New auto-start feature for sequentially starting multiple characters.
Enhanced drops page:
New filtering options for easier item searching.
View drops from all characters in a single, consolidated list.
General enhancements:
Drop logs now persist through bot crashes or manual stops, maintaining records until Koolo is closed.

Auto start was implemented via Scheduler. Drops interface will be reworked in the new version at some point.
Thanks for the contribution though.


Modified Cards

🛠 Closes #1110
Description
Updated the card design a bit mostly it was good .
Type of change

[x] Bug fix (non-breaking change which fixes an issue)
[ ] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to not work as expected)
[ ] This change requires a documentation update

Checklist:

[x] I have made this from my own
[ ] I have taken help from some online resourses
[x] My code follows the style guidelines of this project
[x] I have performed a self-review of my own code
[x] I have commented my code, particularly in hard-to-understand areas
[x] I have made corresponding changes to the documentation
[x] My changes generate no new warnings
[x] The title of my pull request is a short description of the requested changes.

ATTACH SCREEN-SHOTS / DEPLOYMENT LINK

You should link the issue as
Closes #1110

UI of the cards are not up to the mark
Make it more attractive


Implement unwind on success semantics to support bpf_tail_call

bpf_tail_call has special semantics.
If the call returns success, then ubpf needs to store the return value and unwind the stack so to the caller.
Signed-off-by: Alan Jowett<EMAIL_ADDRESS>

Added tests for unwind, both when call returns success and failure.

@rlane Can you please take a look at this PR? I have condensed this down the minimal set of changes necessary to implement bpf_tail_call semantics on ubpf, specifically the "unwind the stack on success", with the invocation of the next program being factored out into the caller.


Modal.onRequestClose on iOS is never called

--- Please use this template, and delete everything above this line before submitting your issue ---
Description
onRequestClose is never called when the dialog is dismissed on iOS. The documentation claims it is an optional callback on iOS.
Can someone clarify if the onRequestClose is supposed to be not implemented on iOS or if this is a bug?
Reproduction
Create a simple project with a modal
Add the onRequestClose property
onRequestClose={() => {alert("Modal has been closed.")}}

The alert is not fired after the dialog has closed.
Additional Information

React Native version: 0.35.0
Platform:iOS
Operating System: MacOS

Actually the description for onRequestClose is wrong for quite a long time, it's not a function that will be called once the modal has been dismissed, but a function that will be called once you press the hardware back button, so it's invalid on iOS.
I'll send a PR then.

Thanks, it would be nice to have a callback once the dialog is fully dismissed but I will use an alternative modal for now.

@Paul-Todd what's the alternative you used?

ah...got this issue too...

I put callbacks for the ok and cancel buttons in my modal and then used that to hide the modal. I think we should have the onRequestClose method also work on iOS so we can capture the post modal close scenario.
I would have liked to have it so I could display a toast once a record was deleted.

/**
* The onRequestClose callback is called when the user taps the hardware back button.
* @platform android
*/
onRequestClose: Platform.OS === 'android' ? PropTypes.func.isRequired : PropTypes.func,
only for android

I also couldn't listen for the 'menu' event in TVEventHandler. It never fired. It's like the modal is intercepting the menu button event and not propagating it.


[1.0] Configurable timeout for airship update action

The CI jobs still run into timeouts every once in a while. This PR
incraeases the default timeout to 120 minutes (which might not even
be too unreasonable for larger deployments).
It also turns the timeout into an attribute so it can be override
via the AIRSHIP_DEPLOY_OPENSTACK_TIMEOUT enviroment variable.
(cherry picked from commit 22254a5217053fceba23486b7fac33beaa4ac632)
Backport of https://github.com/SUSE-Cloud/socok8s/pull/586

no work on stable/1.0 anymore, sorry. thanks for the contribution!


Action for searching and opening pinned shelves

Extension
https://www.raycast.com/jag-k/dropover
Description
Please consider adding an action for searching and opening pinned shelves.
Who will benefit from this feature?
No response
Anything else?
Not sure if it's helpful but here is an example, "Search Bunches" action in this extension - https://www.raycast.com/koinzhang/bunch

Thank you very much for the feature request!
Currently (as far as I know) such functionality is not available in Dropover itself, but I contacted the author (@tursunovic) of the application by email.
If @tursunovic says that this is possible, then I will definitely implement this functionality!
@raycastbot assign me
@raycastbot keep this issue open


[Core]: Remove JSDoc comments at the assertion methods

As the assertions are already documented within the QUnit public API, we can remove these JSDoc comments, avoiding duplication, less documented areas, etc.

Looks good to me.

:+1:


Outdated mention of tikv-jemallocator

https://github.com/nnethercote/perf-book/blob/22698c87d13f4aa62e3ce3886a00d4f1d90aec44/src/heap-allocations.md?plain=1#L396-L398
This is no longer the case. They are the same crate now.
https://github.com/tikv/jemallocator#tikv-jemallocator

The project is published as tikv-jemallocator and jemallocator for historical reasons. The two crates are the same except names. It's OK to use either crate.

I find this all very confusing. Here's my attempts to understand things.
Repositories

https://github.com/gnzlbg/jemallocator hasn't been updated since 2019.
https://github.com/tikv/jemallocator is a fork of https://github.com/gnzlbg/jemallocator that was last updated only a week ago, i.e. has active development.

Crates on crates.io

https://crates.io/crates/jemallocator exists.
https://crates.io/crates/tikv-jemallocator also exists.
Both are on version 0.5.0, and both were last updated on May 25, 2022.
Both link to https://github.com/tikv/jemallocator.
I haven't checked their code, but their sizes are 9.39kB and 9.38kB, which are almost identical.

AFAICT, gnzlbg/jemallocator is defunct, tikv/jemallocator is a fork of it that is maintained, and the fork is published to crates.io under two different names. Is that right?
The part of the documentation not quoted in the description above says this:

But due to lack of permissions, only jemallocator and jemalloc-sys are updated. If you want to use other crates, tikv-xxx versions are still required.

What does that mean? It makes it sounds like it does matter whether you use jemallocator or tikv-jemallocator.

I quick search leads us to https://github.com/tikv/jemallocator/issues/56

Currently, the crate we don't have permission to publish is jemallocator-global. So if you need it, then you have to use tikv-jemallocator-global and then all the dependencies will go to tikv-xxx. If you don't need it, choose whichever you like.

I ended up just removing that paragraph altogether, to avoid getting into the confusing details.


bitWriter: don't return false when overflow and add some comments

@wudping , please help to verify these three patches. Thanks

okay, you are welcome.

verify + 1


container_of is unsound

See this wayland-rs issue I reported
Should change the *mut u8 to a *mut usize

It is not


Drawable boundary boxes

Can draw, resize, move, and delete boundary boxes
Has sidebar listing the names of the boxes

lgtm 👍 styling can be figured out later.


Fix InverseCancellation to run in classical blocks

Fix issue #13437.

Summary
The InverseCancellation pass cancels pairs of gates that are inverses of each other; it now behaves as expected when running inside classical blocks of a control flow.
Details and comments
This PR fixed the bug reported in #13437 by adding the decorator @control_flow.trivial_recurse so that the pass can be iterated over all control-flow nodes.

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

Pull Request Test Coverage Report for Build<PHONE_NUMBER>4
Details

2 of 2 (100.0%)  changed or added relevant lines in 1 file are covered.
2 unchanged lines in 2 files lost coverage.
Overall coverage increased (+0.02%) to 88.954%

Files with Coverage Reduction
New Missed Lines
%

crates/qasm2/src/lex.rs
1
92.73%

crates/accelerate/src/two_qubit_decompose.rs
1
92.27%

Totals

Change from base Build<PHONE_NUMBER>9:
0.02%

Covered Lines:
79422

Relevant Lines:
89284

💛  - Coveralls

Thanks for doing this!
Can you also add some tests? You can probably just more or less copy the tests we had for CXCancellation's control flow handling into test_inverse_cancellation.py.
https://github.com/Qiskit/qiskit/blob/94cea419010b0c8210ef633bf39d4a89618ade01/test/python/transpiler/test_cx_cancellation.py#L146-L199

Done! Please kindly review.

@Mergifyio backport stable/1.4


z-index of overlay div

Is there a way to pass a css class to the Overlay?
I can set class of the Modal but is not clear how to do it for Overlay.
I can use overlay property I prefer to use CSS only styling.
I think a high-value z-index is preferred as default.
Thanks in advance

Found,
overlayClassName


Unable to install package with pip

Hi,
Installing the package with pip no longer seems to be working.
$ sudo pip3 install pay_with_amazon

Getting this response when attempting to install:
Collecting pay_with_amazon==1.0.1 (from -r requirements/base.txt (line 46)) Could not find a version that satisfies the requirement pay_with_amazon==1.0.1 (from -r requirements/base.txt (line 46)) (from versions: ) No matching distribution found for pay_with_amazon==1.0.1 (from -r requirements/base.txt (line 46))

Hello!
We apologize for that. We recently updated the version and didn't upload the tarball to PyPi. Can you please try again and let us know if you are able to?
Thanks!

Closing this. Please reopen if it is still an issue!

This issue is happening again in Python 3.6 with pip 18.0. There are currently no tarballs in PyPI.

Thanks for bringing this to our attention.
The amazon_pay-2.5.0 tarball is now there.


Popup window opens at the center of the page, instead of the center of the visible screen

Subj. In mobile browser (iPhone)

Colorbox DOES have a problem in html5 layouts if the <body> is centered without a wrapper, such as http://camendesign.com/code/developpeurs_sans_frontieres
If <body> has any kind of margin, such as { margin: 0 auto; }, colorbox fails to center the pop-up correctly.

I can see how that would be a problem.  Colorbox has to base it's positioning off of the body element (there is no element higher up the DOM tree it can append itself to), so the only solution would be to constantly check the offset of the body element and account for that in the positioning.  Thanks for the input, it would probably be worth trying to account for it.

it's no problem. happy to add a centering wrapper if only to let colorbox do its thing.
thanks for the badass plugin :)


Using with phantomjs

I am trying to get this working with phantomjs, I am using:
browser = Watir::Browser.new :phantomjs

when I run a single test file, this starts up phantomjs, but I get a timeout error for every test:
Timeout::Error: execution expired

When I try accessing a site via phantomjs in the rails console it works fine and is very fast. Any idea what this could be?

Closing this issue due to inactivity. Please reopen if you can reproduce it.

Hi,
I am getting this error Net::ReadTimeout: Net::ReadTimeout` while using watir with phantomjs. I tried the screenshot method and debug method but I still cannot find out a way to stop the error from happening. It works well when I am using chromedriver but it gets wonky when I change it to phantomjs. Pls Help!

See https://github.com/watir/watir-rails/issues/4#issuecomment-21671551 - if it works fine with chromedriver then the problem is probably within phantomjs or its webdriver. From my own personal experience there have been many different problems trying to use phantomjs and I've always falled back to using chrome or firefox instead. They're also more "real" browsers, which makes even more sense to use these for testing instead of phantomjs.

Hi Jarmo,
Thanks for the comment!
The main reason why I am using phantomjs is because I am going to push my app on Heroku and I am actually using watir as a tool to automate the process of doing some testing on my app. Do you know if there's any other way that I could make it work with/without phantomjs? I would really appreciate any suggestions!

So you're using watir for testing only? Then how does Heroku play any role in it? Use any CI (Travis, Circle or whatever) to run your tests with headless gem to test with Firefox or Chrome.


Add feature overview

features
missing features vs Horizon
future development

#42 would allow for searching through contracts by the functions in them.


Seed uniqueness in runs should be more explicitly stated

To remove any ambiguity, it'd help if the rules were super explicit about how random seeds (if used) need to be unique across all runs. I think it's left somewhat implicit now, including via the requirement to run the package checker, but a clear statement which cannot be misinterpreted would help prevent any future debate.
In HPC weak-scaling submissions we are at the point where a submitter can accidentally have multiple common seeds because of the large number of models drawn and usage of a seed generator (e.g. $RANDOM) which can produce repeats.

this was fixed in https://github.com/mlcommons/training_policies/pull/479


Quadratic delay for large POST json requests

For an NLP project (on RHEL 7.6, Python 3.4.9, Falcon 1.4.1), we send POST requests of several million characters to our microservices through gunicorn and falcon. I noticed there is a delay between the moment gunicorn gets the POST request and the moment our service starts to process it. Although nothing shows in the systemd journal, this delay is increasing quadratically with the size of the payload:

1M chars -> 10 seconds
2M chars -> 40 seconds
3M chars -> 90 seconds
4M chars -> 160 seconds
etc.

For very big payloads we soon hit the gunicorn timeout. I don't know if falcon expects to get such large POST payloads in plaintext/json, but it would be nice to get at least a warning. As a workaround, we now convert the large text string to a text file and pass it to falcon using the falcon-multipart middleware, which suppresses the delay. Happy to provide more information if needed.
Thanks for the awesome work!

Hi @madewild !
I am not completely sure it is just a Falcon issue, as it might be a combination of the interpreter (note that CPython 3.4 is soon EOL), the framework (Falcon), the WSGI application server (Gunicorn) etc.
FWIW, I could not reproduce the issue on CPython 3.5, Gunicorn 19.9.0 & Falcon 1.4.1.
I used the following application, let's call it test.py:
import falcon

class Responder:

    def on_post(self, req, resp):
        payload = req.bounded_stream.read()
        resp.media = {'size': len(payload)}

api = falcon.API()
api.add_route('/', Responder())

...and the following 16 MiB text file (basically containing '123456789ABCDEF\n' * 1024 * 1024):
ls -l data.txt
-rw-rw-r-- 1 vytautas vytautas 16777216 Mar 23 22:40 data.txt

When POSTing this file, the application was relatively snappy, I could not replicate any delays of that order of magnitude:
time curl -v \
-H "Accept: application/json" \
-H "Content-Type: text/plain" \
-X POST --data-binary @data.txt http://localhost:8000

Note: Unnecessary use of -X or --request, POST is already inferred.
* Rebuilt URL to: http://localhost:8000/
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 8000 (#0)
> POST / HTTP/1.1
> Host: localhost:8000
> User-Agent: curl/7.47.0
> Accept: application/json
> Content-Type: text/plain
> Content-Length: 16777216
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
* We are completely uploaded and fine
< HTTP/1.1 200 OK
< Server: gunicorn/19.9.0
< Date: Sat, 23 Mar 2019 21:53:51 GMT
< Connection: close
< content-length: 18
< content-type: application/json; charset=UTF-8
<
* Closing connection 0
{"size": 16777216}

real	0m0.134s
user	0m0.012s
sys	0m0.032s

Could you try isolating your case in a simple proof-of-concept sample that we could check?
As said, to be honest, I don't suspect a framework issue per se, but it is still very interesting for us in terms of documentation tips, deployment guides etc.
Kindly,
Vytas

Hi Vytas,
I confirm that I cannot reproduce the issue with Python 3.5, Gunicorn 19.9.0 & Falcon 1.4.1. So it was indeed a combination of old Python and old Gunicorn (we were using 19.7.1) causing this strange delay. Crazy that I had to enable IUS for that, RHEL7 is still stuck with Python 3.4! Thank you for your time...
Best,
Max

@vytas7,
I encountered the same issue on CentOS 7 + Python3.7 + Cython 0.29.7 + gunicorn 19.9.0 + Falcon 2.0.0
The post data size if almost 1.8M, but the delay between gunicorn and Falcon is almost 45 seconds. Any suggestions about what caused this? thank you

Hi @JerryKwan !
And no, I have no clue what is causing this. I have never been able to reproduce the issue myself. As said above, I would risk a guess it is not a Falcon issue per se but rather an issue with the WSGI mechanics such as the WSGI server, front-end proxy server/load balancer (if any) etc.
@JerryKwan Could you try running my example from this comment: https://github.com/falconry/falcon/issues/1484#issuecomment-475908156 and check if you can reproduce with it?
Alternatively, could you share your test case, as small and isolated as possible, which illustrated the problem?

Hi @vytas7 , thank you for looking into this.
This is how to reproduce this problem.
1, I use the following application,let's call it test_delay.py
import falcon

class Responder:

    def on_post(self, req, resp):
        # payload = req.bounded_stream.read()
        # resp.media = {'size': len(payload)}
        data = req.get_param('data', default='')
        print('len(data) = %s'%len(data))

api = falcon.API()
api.req_options.auto_parse_form_urlencoded=True

api.add_route('/', Responder())

2, run gunicorn
gunicorn  --workers=4 --timeout=60 --log-level=debug --reload --bind <IP_ADDRESS>:8000 test_delay:api

3, use curl to post data
data.txt
time curl -v -X POST -d @data.txt http://localhost:8000

And you will see something like this
time curl -v -X POST -d @data.txt http://localhost:8000
* About to connect() to localhost port 8000 (#0)
*   Trying ::1...
* Connection refused
*   Trying <IP_ADDRESS>...
* Connected to localhost (<IP_ADDRESS>) port 8000 (#0)
> POST / HTTP/1.1
> User-Agent: curl/7.29.0
> Host: localhost:8000
> Accept: */*
> Content-Length: 2361141
> Content-Type: application/x-www-form-urlencoded
> Expect: 100-continue
>
< HTTP/1.1 100 Continue
< HTTP/1.1 200 OK
< Server: gunicorn/19.9.0
< Date: Thu, 27 Jun 2019 09:12:55 GMT
< Connection: close
< content-length: 0
< content-type: application/json
<
* Closing connection 0

real	0m44.149s
user	0m0.017s
sys	0m0.017s

Hi @vytas7,
I think I have found the root cause of the poor performance, It was caused by the function named decode(encoded_uri, unquote_plus=True) which locates in /falcon/util/uri.py. I will fix it and send you to review

Hi @vytas7,
the decode() function should be like the following
def decode(encoded_uri, unquote_plus=True):
        """Decodes percent-encoded characters in a URI or query string.

        This function models the behavior of `urllib.parse.unquote_plus`,
        albeit in a faster, more straightforward manner.

        Args:
            encoded_uri (str): An encoded URI (full or partial).

        Keyword Arguments:
            unquote_plus (bool): Set to ``False`` to retain any plus ('+')
                characters in the given string, rather than converting them to
                spaces (default ``True``). Typically you should set this
                to ``False`` when decoding any part of a URI other than the
                query string.

        Returns:
            str: A decoded URL. If the URL contains escaped non-ASCII
            characters, UTF-8 is assumed per RFC 3986.

        """

        decoded_uri = encoded_uri

        # PERF(kgriffs): Don't take the time to instantiate a new
        # string unless we have to.
        if '+' in decoded_uri and unquote_plus:
            decoded_uri = decoded_uri.replace('+', ' ')

        # Short-circuit if we can
        if '%' not in decoded_uri:
            return decoded_uri

        # NOTE(kgriffs): Clients should never submit a URI that has
        # unescaped non-ASCII chars in them, but just in case they
        # do, let's encode into a non-lossy format.
        decoded_uri = decoded_uri.encode('utf-8')

        # PERF(kgriffs): This was found to be faster than using
        # a regex sub call or list comprehension with a join.
        tokens = decoded_uri.split(b'%')
        bytes = io.BytesIO()
        bytes.write(tokens[0])
        # decoded_uri = tokens[0]
        for token in tokens[1:]:
            token_partial = token[:2]
            try:
                # decoded_uri += _HEX_TO_BYTE[token_partial] + token[2:]
                bytes.write(_HEX_TO_BYTE[token_partial])
                bytes.write(token[2:])
            except KeyError:
                # malformed percentage like "x=%" or "y=%+"
                # decoded_uri += b'%' + token
                bytes.write(b'%')
                bytes.write(token)

        # Convert back to str
        # return decoded_uri.decode('utf-8', 'replace')
        return bytes.getvalue().decode('utf-8', 'replace')

As you can see, the main difference is we use BytesIO other than byte concatenation

Hi again @madewild and @JerryKwan !
And sorry I didn't understand you were trying to parse a URL-encoded form for which we indeed have an issue with very large keys/values. I was assuming an ordinary POST of binary data which you would read from the input stream.
Thanks @JerryKwan for providing the test cases!
We are continuing the discussion in a new issue that @JerryKwan filed: https://github.com/falconry/falcon/issues/1594


No such file or directory: CMAKE_READELF: 'CMAKE_READELF-NOTFOUND'

when I tried to config the board ID to run example,something wrong with cmake,it seems that the gcc based toolchains didn't work well. I was just cloned the master to my ubuntu and build cmake-3.8.2 then installed,what's the problem?the log show below:
CMake Error at /home/ubuntu/Desktop/zephyr/cmake/extensions.cmake:984 (message):
  No such file or directory: CMAKE_READELF: 'CMAKE_READELF-NOTFOUND'
Call Stack (most recent call first):
  /home/ubuntu/Desktop/zephyr/cmake/compiler/gcc.cmake:14 (assert_exists)
  /home/ubuntu/Desktop/zephyr/cmake/toolchain.cmake:38 (include)
  /home/ubuntu/Desktop/zephyr/cmake/app/boilerplate.cmake:243 (include)
  CMakeLists.txt:1 (include)

Seems to be a duplicate of #6911.

This happens when the build system cannot find the toolchain.
Check your environment and build variable settings.
Are you building on OS X?

This is one of those misleading warnings or errors, as @andrewboie said, it is not finding the toolchain, so please make sure you have all env variables set correctly and make sure you have a toolchain available.

"when I tried to config the board ID to run example,something wrong with cmake,it seems that the gcc based toolchains didn't work well. I was just cloned the master to my ubuntu and build cmake-3.8.2 then installed,what's the problem?"
Please follow the getting started guide and post the environment variables that are set.

Please run
echo $ZEPHYR_SDK_INSTALL_DIR
echo $ZEPHYR_TOOLCHAIN_VARIANT

I modified the gcc.make file and run "cmake -GNinja -DBOARD=arduino_101 ../.." again ,it remind me that
-- Found PythonInterp: /usr/bin/python3 (found suitable version "3.5.2", minimum required is "3.4")
-- Selected BOARD arduino_101
Zephyr version: 1.11.99
Parsing Kconfig tree in /home/ubuntu/Desktop/zephyr/Kconfig
Using /home/ubuntu/Desktop/zephyr/boards/x86/arduino_101/arduino_101_defconfig as base
Merging /home/ubuntu/Desktop/zephyr/samples/hello_world/prj.conf
CMake Error at /home/ubuntu/Desktop/zephyr/cmake/compiler/gcc.cmake:17 (message):
Zephyr was unable to find the toolchain.  Is the environment misconfigured?
User-configuration:
ZEPHYR_TOOLCHAIN_VARIANT: zephyr
Internal variables:
CROSS_COMPILE:
/home/ubuntu/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-
TOOLCHAIN_HOME: /home/ubuntu/sysroots/x86_64-pokysdk-linux
Call Stack (most recent call first):
/home/ubuntu/Desktop/zephyr/cmake/toolchain.cmake:38 (include)
/home/ubuntu/Desktop/zephyr/cmake/app/boilerplate.cmake:243 (include)
CMakeLists.txt:2 (include)
-- Configuring incomplete, errors occurred!
it seem that the ZEPHYR_TOOLCHAIN_VARIANT  was correctly what I have set, I am sorry that I am not familiar with linux develop environment, what should I do to correct it?

@gyboy : I'm not sure what the root cause is.
One abnormality is that sysroots is in  /home/ubuntu/, it should be in an "sdk" directory within /home/ubuntu/ instead.
This is what it looks like for me:

sebo@mach:~/zephyr$ ls ~/zephyr-sdk-0.9.2-rc5/
info-zephyr-sdk-0.9.2  sdk_version  sysroots

As you can see, the SDK should have a file next to sysroots called sdk_version, this file is now in your home directory, which is not great, although I can't see why this would actually be causing any errors.
Could you try re-installing the SDK? This time to a dedicated folder within /home/ubuntu.
Also, could you check if the file /home/ubuntu/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-readelf
and /home/ubuntu/sysroots/x86_64-pokysdk-linux/usr/bin/i586-zephyr-elfiamcu/i586-zephyr-elfiamcu-gcc
exist and find out if they are executable.

@SebastianBoe,thanks,actually I didn't find the directory.It seems that I have installed the sdk for many times,the first time I used the default directory whihout the command sudo and I can't see any file in  "/opt/zephyr sdk",the second time I installed the sdk in the directory "/home/ubuntu/",which you can see from the log,but still can't find any file,the last time I installed in "/home/ubuntu/zephyr-sdk",still didn't work.every time  I change the respond path of "ZEPHYR_SDK_INSTALL_DIR". I was considering whether should I remove the last time installed file then excute the setup again,however I don't know how to remove the installed sdk. I'll try to reconfig the whole environment as the guide have instructed, thanks a lot

Resolved.


DOC - fix reference to python requests library

In here - https://nornir-salt.readthedocs.io/en/latest/Connection Plugins.html#nornir_salt.plugins.connections.HTTPPlugin.HTTPPlugin - link toward python-requests library does not work- https://docs.python-requests.org/en/latest/api/ - need to fix it, presumably pointing to somewhere here - https://requests.readthedocs.io/en/latest/api/

Fixed.


[feature] - cache learn and earn

This PR fixes #gh-issue-number
Changes
Cache GET endpoints from L&E and clean when the user interacts with the lessons or when the webhook is trigged
Tests

refactored to clean cache on services rather than endpoints. Also, cache using userid instead of ip requesting (it breaks if multiple users use the same device + we don't want to use ip's)


IJCK R2C18 & 19

Page 7, line 12, mole-percent, mole-fraction, and mass-fraction include a dash in their name,
whereas this is not the case for the example on page 5 line 48 and in the description of the
composition element on page 4, line 47.
Same issue as #18 holds for page 7, line 17.

Ref: https://github.com/pr-omethe-us/pyked-papers/issues/3#issuecomment-332316621
From Kyle:

I agree that we should be consistent about using hyphen, underscore, or nothing in fields with multiple words. I like hyphens.

I agree with hyphens. However, hyphens aren't valid in Python variable names, and I suspect the problem here is the difference between the Python example and the YAML spec. I haven't checked though...

OK I see what happened here. This seems to be a mixing of the old format (when mole-fraction was the key) and the new format (when the composition type is specified by a string). I guess in one of the cases the reviewer points out in the text, we missed updating the format, and in the others, the Python representation of the string has a hyphen that we should probably delete (if its added in PyKED, we should remove it, if its not, then the manuscript is wrong).

Also, didn't we add ppm and ppb as composition types?

After checking the code (https://github.com/pr-omethe-us/PyKED/blob/master/pyked/chemked.py#L584) it looks like we just grab the value from the property dictionary, so it shouldn't have the hyphens in it, so this is all just a typo in the manuscript. That's good!


Allow example values for non-member types

This may be related to aliases, which I've seen has already been decided against.
There are times it is useful to define a Named Type of a primitive in order to imply a specific format.  Currently, the only way to define a Named Type of a primitive is:
# Email (string)

Doing so does not allow an example value to be provided for the type, which means anything that references them must provide the example value:
+ Attributes (array[Email])

will render as an empty array.  Currently, the only way to achieve the desired effect seems to be always specifying an example value
+ Attributes (array)
    -<EMAIL_ADDRESS>(Email)

@Animeye You should be able to define a sample value for a named type using the following syntax
# Email (string)
## Sample
<EMAIL_ADDRESS>

Providing a sample value like that was briefly working, but has now returned to the behavior of not showing up.  Below is a blueprint that demonstrates some of the ways that the sample value could get used
FORMAT: 1A

# Sample API

## Some URL [/test{?something}]

### Test action [POST]

+ Parameters
    + something (basestring) - The sample value should show here

+ Request (application/json)

    + Attributes (Structure_Inheritance)

+ Response 200 (application/json)

    + Attributes (Include_Inheritance)

### Array Test [PATCH]

+ Request (application/json)

    + Attributes (array[basestring])

+ Response 200 (application/json)

    + Attributes (basestring)

# Data Structures

## basestring (string)
### Sample
this-is-a-base

## Structure_Inheritance (object)
+ basetype_value (basestring) - Testing inheritance of a sample-defined value
+ obj_inheritance: welcome (string) - A value defined as an object member
+ override_inheritance: hello (string) - A value defined as an object member that will be overridden

## Include_Inheritance (object)
+ Include Structure_Inheritance
+ override_inheritance: goodbye
+ new_member: 13 (number) - A new value

Currently, none of these references to the basestring type are showing the sample value of this-is-a-base.

@Animeye There are 2 bugs in apiaryio/drafter which are effecting this. apiaryio/drafter#98 and apiaryio/drafter#117. We are going to fix them soon. Please track them there.


Install F# 4 in the mcr.microsoft.com/dotnet/framework/sdk:4.8 image

Describe the Problem
F# 5 is available, however, I am unable to reference .NET Framework only assemblies from F#.
Describe the Solution
Install the full F# 4.x (Framework version)in the image as is done with C# and VB.NET.

[Triage]  This is the first ask for full F# support.  How many customers want this?  Adding every possible component would make the sdk image that much bigger and less attractive.  We try to adhere to only adding mainline components. For non-mainline scenarios, our recommendation is to add the missing required components on top of the 'sdk' image in your own layer/image.
If you would like to see us add full f# 4.x support, please let us know.  If we don't receive much response, we will close this issue in one month.

I am okay with adding this in my own layer/image. However I am having trouble doing so. I have documented my attempts here which have so far been unsuccessful. Any suggestions?
https://stackoverflow.com/q/67479997/19977

I found a solution that works for me and I am okay with closing this request. In short, I was able to solve the issue by installing the F# Compiler Tools using paket.
https://stackoverflow.com/a/67641441/19977

[Triage] Closing as there were no other requests for this and a solution was found for the original scenario.


Adjustment to BDEF Object Handler

Adjustment to BDEF Object Handler regarding exchange file format
issue #3351

@christianguenter2 any comments?

@ThomasPloski can you update the BDEF test case here?
https://github.com/abapGit-tests/BDEF

Hi @christianguenter2, I have adapted the method call to the corresponding interface method.

@ThomasPloski old method fill_metadata_from_db can be deleted?

@christianguenter2 do you have time to take another look?

@ThomasPloski

Hi @christianguenter2 & @larshp,
Currently I have some issues with activating BDEF object. In case of I use the activation_old logic the activation proceed without issues.

BDEF is not a DDIC type. It should use the following settings
rs_metadata-ddic = abap_false.  (or remove it)
    APPEND zif_abapgit_object=>gc_step_id-abap TO rt_steps.
Then it will default to activation_old.

@ThomasPloski Is it ready for re-review?
I still get this error

@ThomasPloski Is it ready for re-review?
I still get this error

Would it be possible to send me your repo which you use to test this changes? With my BDEF test objects I do not get this issue you have mentioned.

@ThomasPloski
Sure, it the official abapGit test repo for BDEF
https://github.com/abapGit-tests/BDEF.git

@ThomasPloski

@ThomasPloski

@ThomasPloski

@ThomasPloski

@christianguenter2: I have changed the affected reference type of the BDEF create API. Now I am able import your BDEF example. Would you please double check and put changes to master? Thanks.

@christianguenter2: I have changed the affected reference type of the BDEF create API. Now I am able import your BDEF example. Would you please double check and put changes to master? Thanks.

thanks 👍

thanks 👍


Browse "select" list by page?

Hello Piotr & community,
I'm using the "select" prompt with a long list (multiple pages) and I'm wondering if it would be somehow possible to page-browse the list similar to the "enum_select" prompt, i.e. pressing page-down key browses to next page of items.
Motivation: I believe the "select' prompt with it's selected-item marker is more intuitive for users to browse and choose an item, especially with a long list.
In any case, thank you for making and sharing this great piece of work!
Cheers,
orachux

Hello there,
Thank you for using the library!
I think that adding 'page jumping' to select and multi_select would be a great addition. There is no reason why they couldn't work the same way as enum_list and jump through pages when left/right arrows are pressed, or even pageup/pagedown keys.
Do you have time to work on this and submit PR?

I could have a look, but I'm not sure if I'm proficient enough. Wanted to make sure this feature did not exist already. If I understand correctly, it's about implementing a list_paginator similar to the enum_paginator. Let's see ...

It's been a while since I've implemented the paginator. I would think that you don't necessarily have to change paginator itself as long as you pass it the next active list element which is at the start of the next page if that makes sense. In other words, I would start from looking into implementing the left & right events so that they figure out the next active element and adjust the slice of choices. It may well require small adjustment to the paginator.

@orachux Implemented navigation by page in master branch and will release as part of v0.19.0 shortly.


bug(NEXXUTILS): Send Spotify invite does not work

Check all the boxes below

[X] I have checked that this bug hasn't already been reported

Discord username
moodle.v2
Detailed Info
The send Spotify invite does not work

Steps to Reproduce

Turn on "Send Spotify invite"
Open server or DM chat
Click add attachment button
Click "Send Spotify invite" button

Crash Info
No response
Bug Screenshot

System Info
Device: OnePlus 11 (CPH2449)
Manufacturer: OnePlus
Brand: OnePlus
OS: Android
Version: 13
Discord Branch: BetaRelease
Discord Version: 200.8
Discord Build: 200108
Vendetta Version: 2cc1f8d
React Version: 18.2.0
Hermes Bytecode: 94

https://github.com/nexpid/VendettaPlugins/commit/14f3b11f8ab9a818ca133cb0fe4a9324da61bb5e


QA: Local development issue

We will run random commands in this QA. Some commands will be written invalid on purpose to test the correct response.
First, tests will be performed in a single yarn build && yarn start with disable-analytics": false.
The reason is testing previously failing analytics functions on localhost:
await htmlImage(summaryInfo);
await compositeImage();
await processTelegram(dataPadded);

After this, some tests will be performed with disable-analytics": true

/help

/wallet

/wallet 0x1F9FCc0E84dc2094499b848AE37Cd6a51db03Ff2

Previously failing functions working on localhost. The image is being generated and sent to the telegram chat.

/start

/stop

/stop


Enable unreachable_pub in object_store

Is your feature request related to a problem or challenge? Please describe what you are trying to do.

The object_store crate has a large amount of implementation details that are marked public, but are kept crate-private by being part of a crate-private module.
When reviewing a PR it can be hard to reason about what is/isn't public, and therefore what is/isn't a breaking change.
It also runs a greater risk of implementation details accidentally being exposed during a refactor.
Describe the solution you'd like

I would like to enable the unreachable_pub lint and update the relevant sites with pub(crate)
Describe alternatives you've considered

Additional context

take

label_issue.py automatically added labels {'object-store'} from #6512


fix: if dismiss/dismissAll called, don't show delayed items

Don't show toasts that are waiting for overlay to be created if dismiss/dismissAll called on them.

Hey @amxDusT
Thanks for your contribution
I will look into it ASAP


Added format to integers

MSFT employees can try out our new experience at OpenAPI Hub  - one location for using our validation tools and finding your workflow.

Contribution checklist:

[ ] I commit to follow the Breaking Change Policy of “no breaking changes
[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and errors have all been fixed in this PR. How to fix?

If any further question about AME onboarding or validation tools, please view the FAQ.
ARM API Review Checklist

[ ] Ensure to check this box if one of the following scenarios meet updates in the PR, so that label “WaitForARMFeedback” will be added automatically to involve ARM API Review. Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs, all “removals” and “adding a new property” no more require ARM API review.

Adding new API(s)
Adding a new API version
Adding a new service

[ ] If you are blocked on ARM review and want to get the PR merged with urgency, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.

Breaking Change Review Checklist
If there are following updates in the PR, ensure to request an approval from API Review Board as defined in the Breaking Change Policy.

[ ] Removing API(s) in stable version
[ ] Removing properties in stable version
[ ] Removing API version(s) in stable version
[ ] Updating API in stable version with Breaking Change Validation errors
[ ] Updating API(s) in preview over 1 year

Please follow the link to find more details on PR review process.

/azp run automation - sdk

@irrogozh, as you are working on network-july-release, but the file you modified is in 2020-06-01 folder, is it expected? Changing the format would cause breaking changes.

/azp run automation - sdk

@lirenhe, I should've updated 07-01 version, not 06-01. Fixed this. Could you please check?


ValueFromRemainingArguments parameters are not reflected as such in syntax diagrams

It is currently hard to discover if a given cmdlet/function has a ValueFromRemainingArguments parameter, so I suggest we add a new representation to syntax diagrams to signal that a given cmdlet / advanced supports does so.
We'll have to decide what an adequate representation is.
For instance, Write-Host -? shows the following for its ValueFromRemainingArguments  -Object parameter:
[[-Object] <Object>]

which does not reflect its "specialness" - you can't tell that this parameter enables specifying multiple, independent arguments that are all bound to -Object, enabling convenient free-form invocations as Write-Host a b c in lieu of (the also supported) Write-Host -Object a, b, c
Perhaps something along the lines of:
[[-Object ...] <Object>]

Environment data

PowerShell Core v6.0.0-beta.5 on macOS 10.12.6
PowerShell Core v6.0.0-beta.5 on Ubuntu 16.04.3 LTS
PowerShell Core v6.0.0-beta.5 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)
Windows PowerShell v5.1.15063.483 on Microsoft Windows 10 Pro (64-bit; v10.0.15063)

I can not repo this on Windows PowerShell v5.1.16257.1 (and 10240 too)

@iSazonov:
Sorry - I wasn't clear in my original title and post - please see if the update helps.
(I was also originally distracted by Join-Path -? not showing the new -AddtionalChildPath parameter at all - see https://github.com/PowerShell/PowerShell-Docs/issues/1612)

[[-Object] <Object>[, <Object> ...] ]

Well, the , is tricky, because we want to convey that you do not need it when taking advantage of the feature.

[[-Object] <Object>[[,] <Object> ...] ]

Keep in mind that the parameter type need not be <Object>.
Among the core cmdlets that have ValueFromRemainingArguments  parameters, you'll also see <string[]>, for instance (Get-Command -Syntax Join-Path, parameter -AdditionalChildPath).
Conceptually, a ValueFromRemainingArguments is inherently a collection, given that it can bind multiple arguments.
The tricky part is that if you don't use the parameter name explicitly, you actually must use individual arguments as opposed to an array to get the equivalent functionality
(at least with advanced functions (as opposed to compiled cmdlets), which brings us back to our perennial favorite, #2035).
In the example above, you'd really need two distinct representations:
[-AdditionalChildPath <string[]>]
or, without parameter name:
[<string> ...]
So perhaps the following?
[-AdditionalChildPath <string[]> | <string> ...]

If #2035 will be fixed  comma should be here too?   [<string>, <string> ...]

As I've argued here, I strongly feel that it should be fixed in the way that advanced functions already work (read: parameter binding must be fixed for cmdlets - the opposite of what #2035 proposes), which means that in no-parameter-name  invocations you must not use , -  because use of , changes the semantics to sticking an array into the first element of the parameter variable.

Thanks for clarify! So we blocked until #2035 will be resolved.

Not necessarily, because the <string> ... (comma-less) syntax will work either way, irrespective of how #2035 is resolved (incidentally, I just tried to clarify my arguments there).
The <string> ... (comma-less) syntax is not only the more convenient syntax, it is also the only one that works when you call a PS script from the outside.
In short: Either way, the comma-less syntax is the one worth highlighting in the syntax diagram.

P.S.: To put it differently: You don't need ValueFromRemainingArguments at all for the <string>, <string>, ... syntax - just a regular positional parameter that accepts an array.

the comma-less syntax is the one worth highlighting in the syntax diagram.

Thanks! Clear. It is good [-AdditionalChildPath <string[]> | <string> ...]


"Insert into Notebook" in Github Copilot in VSCode is not converting response data correctly into separate Markdown and Code cells

Describe the bug
The function "Insert into Notebook" in Github Copilot in VSCode is not converting response data correctly into separate Markdown and Code cells before it sends it over the Jupyter Notebook. It is not clear whether the bug is in Copilot, VSCode, or Jupyter NB in VSCode. What VScode or Github Copilot configuration can I change to fix this?
To Reproduce
Steps to reproduce the behavior:

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

Expected behavior
A clear and concise description of what you expected to happen.
Screenshots
If applicable, add screenshots to help explain your problem.

Platform  See screenshot !!

OS: [Windows 11 Pro]
IDE: [VS Code]
Language: [Python]

Additional context
Add any other context about the problem here.

@TatianaPrevalla this is not the GitHub Copilot repo.


Static IP not detecting

I have installed firmware on my WT32-ETH01 device and am attempting to assign a static IP address to it, but it always defaults to DHCP automatically. Could you please take a look at it?

I removed the initial code that sets the static IP on the ethernet module because it was causing an occasional reset and did not have the time to figure out why.  That being said, is there a reason why you aren't doing DHCP reservations for fixed IPs?  Static IPs at the device level can be very challenging since they can still be issued by the router to other devices.
Originally, I added this code simply because it was there but I have found the PHY chip to be a bit unstable with a fixed address.  Let me know your use case and I will take another stab at it.  The preferred method is to marshal IPs from the DHCP server but reserve by MAC.

I am closing this for now and will be removing the UI for the static IP on the next release.


Credit OAS-kit for original Speccy/Spectral ruleset

Speccy (was, it is now unmaintained) a thin wrapper around OAS-Kit's oas-linter. These rules then went on to inspire the original set in Spectral.

oas-linter also uses a visitor pattern to traverse the OAS document, unlike Spectral which uses JSON Path expressions to locate each rule's target.

Thanks, @MikeRalphson 👍


[Docs] Manpage poc

@precisionmoon
TODO

final docs check

Suggestions

add -no-pager
;#undocumented for checker off.

Cho, answers to the following:

are files under docs/md directory symlinks? No, currently they are actual files. We will gradually migrate these to the actual READMEs since the format is still not fixed yet
Can we make the file suffix consistent? Can everything be *.md suffix like openroad.md instead of .txt? Yes, will put that on our todo.
where are contents of docs/md/man3? Errors/info/warnings yet to be populated
where will "cat" version of man pages be populated? Does Util.tcl man command know where to find the "cat" pages? Yes they will find the files in docs/manpages/cat

@precisionmoon Ready for review.
For some reason it passes the ibex_sky130hd CI in pr-head but not pr-merge, so I am not sure if something is wrong with my branch.

@maliberty, can Jack's PR be merged?

Jack,
Please do the following and resolve merge conflicts.

git fetch origin
git merge origin/master
manually merge conflicts

Thanks.
Cho
On Tue, Feb 20, 2024 at 2:01 PM Matt Liberty @.***>
wrote:

There are a bunch of conflicts to resolve in the .tcl files
—
Reply to this email directly, view it on GitHub
https://github.com/The-OpenROAD-Project/OpenROAD/pull/4543#issuecomment-1955191909,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/BBVEJRV24ANM5ODHYJBEVH3YUUMLRAVCNFSM6AAAAABB5ICMDSVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNJVGE4TCOJQHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

@maliberty I have added new changes to local tests above. Would love your feedback. Thanks!

You have a merge conflict to address in src/mpl2/src/mpl.tcl

@luarss please resolve the conflict so we can get this merged.


Add to the wiki how to test a doc

Tow parts to this

is the code correct
is the restructured text syntax correct

The former can be quickly checked using the helper script doctest_rsts.py command. This command needs to be executed from within the doc root directory, i.e. Cogent3/doc/.
Addressing 2 is done, within the doc directory using the command
$ make html

and then open the html docs under _build/html/index.html and navigate to the new entry and check it looks OK!

Noting down here so I don't forget, but it could be useful to have "Documentation workflow" and "practices" pages on the wiki to parallel the Development workflow and practices. Mainly to make it clear that linting and testing of docs and code are different.

@GavinHuttley should e.g. nox -s testdocs-3.11 be run as well, or is doctest_rsts.py on individual files sufficient?

Wiki updated. Relevant pages are:

https://github.com/cogent3/c3dev/wiki/Contributing-documentation
https://github.com/cogent3/c3dev/wiki/Documentation-types

Let me know if anything else is required!

Edits for the https://github.com/cogent3/c3dev/wiki/Contributing-documentation page:

[ ] When you embed a snippet of restructured text in Markdown, put rst after the opening gates so we get syntax highlighting.
[ ] Change "After adding or amending code in the .rst files (i.e. jupyter-execute or code-block directives),"  to "After adding or amending code in the .rst files (i.e. jupyter-execute or doctest directives)," (code-block is never executed).
[ ] last line, because what is built is a static site, they need to open _build/html/index.html and navigate to the new content and check it

Regarding https://github.com/cogent3/c3dev/wiki/Documentation-types

[ ]  CHANGE "Note that the citations should be" to a > **Note** line with the content changed to "Only after confirming citations are not already in cogent3.bib should they be added to that file."

You can close this when those are done

Thanks!!

(Changes made, but I can't close issues)

Thanks @fredjaya !


Parsing of segment:offset jmp instructions found in 16 bit real mode

Added node type for segment:offset operands. These operands are only supported in 16 bit real mode, and they don't allow registers to be supplied as the segment or offset, so my solution only takes into account numeric literals, labels, and other forms of expressions that are supported. This still passes the same test cases it did before, but fails the same one referenced in my comment in issue #4.
This PR resolves #4.

Thank you for the PR!
Simply skimming through my old code real quick, I want to guess that this line (555~556) was maybe supposed to do what you want, but it has the surrounding [] pair mandatory along with a few optional things around; is this something completely different? I'm not as well versed in asm as I used to be.

[..] they don't allow registers [..]

I suppose that other one does allow...
Also if you could add the infringing snippet from the issue in test/corpus/source_line.txt, that would be great.

Thank you for the PR!

Yeah, absolutely!

I want to guess that this line (555~556) was maybe supposed to do what you want

Yes, I saw that line you referenced while adding the change, but it refers to an effective address which is slightly different. In a simple mov instruction for example, you could dereference an address in the rbp register for example:
mov rax, qword [rbp]. The only real difference between the effective address and the segment:offset operand is that the segment:offset isn't de-referenced, its just used alongside a jump to update the contents of the code segment register after the jump. So a line like jmp 0:short_label is used in many bootloaders to assure the code segment register is properly set to 0. It's very niche, but I figured I would try to add support for it nonetheless.
I could definitely try and modify the change such that the effective address could have optional square brackets, because the two operand types are essentially the same, but when I tried that before I ran into conflict issues with some other rule. I can absolutely try to resolve the conflict you feel that is the better approach to take, so just let me know.

Also if you could add the infringing snippet from the issue in test/corpus/source_line.txt, that would be great.

Sorry, just to make sure, are you referring to adding a new test case to the source_line tests? Or are you referring to the test case that I mentioned was failing for me prior to any changes I made? If you are referring to the test case that was failing, it is the header guard test case in the macros.txt. If you are referring to adding a new test case, I can definitely do that. I'm sorry for my confusion.

Sorry for the delay.
You went above and beyond, thank you very much for the PR!
I eventually had time to go through it. Everything seems find to me.

You're all good, I really appreciate the kind words!
Hope my contribution helps!


Rename references to kinvolk org to flatcar-linux

As the repository has been moved again. This is to allow importing the module using up to date path.
Signed-off-by: Mateusz Gozdek<EMAIL_ADDRESS>Testing done
Only go build in internal directory.

Running make also worked. Merging.


Need to fill in categories on uipa.org

As a person making an FOI request, I want to be able to search for contacts/departments by categories relevant to Hawaii.
Please use this document started by Brian:
https://docs.google.com/spreadsheets/d/1Lzx-koaf1M05BUhg0rxB4xo483ImeRjkT_qnaLh6r7M/edit#gid=323480693
Please add them to the following url when it is up:
http://uipa.org/uipa-admin/publicbody/publicbodytag/

Will be making better tasks. This doesn't have to be two tasks.


Add remote persistent worker support

Closes #776.
Implements support for persistent workers in remote builds using the Bazel remote execution protocol and the approach documented in the Bazel remote persistent workers proposal:
https://github.com/bazelbuild/proposals/blob/main/designs/2021-03-06-remote-persistent-workers.md
Includes an example setup that works with

local builds without persistent worker
local builds with persistent worker (Buck2 protocol)
remote builds without persistent worker
remote builds with persistent worker (Bazel protocol)

The Bazel remote persistent worker protocol includes an automatic fallback in cases where the remote execution system does not yet support persistent workers. To that end actions take the shape
WORKER WORKER_ARGS... @REQUEST_ARGS_FILE

The remote execution system separates worker arguments on the command-line from request arguments in the response file and adds the --persistent_worker flag.
The demo worker included in the example in this PR distinguishes between Buck2 worker, Bazel remote worker, and one-shot modes depending on whether Buck2's WORKER_SOCKET, Bazel's --persistent_worker flag, or neither is set.
The example includes a README with detailed instructions how to test this feature.

Add example for remote persistent workers
Implement support for remote persistent workers

Thanks for the PR! This looks good.
We started working on support for this internally but unfortunately it doesn't match the bazel spec exactly. For reasons that aren't entirely clear to me we can't attach the 'worker key' to the platform so it's attached elsewhere on the action.
I can't see why we can't support both APIs though and have a default 'bazel mode' for this behavior, though.
The main other difference is that on our end we construct an RE::Action for the worker, upload it and use the digest of that action as the 'worker key', instead of what I assume is requiring that the worker args are a prefix of the action args (in which case the 'worker key' doesn't really seem to matter?). Similarly we can support both in 'bazel mode' though.
Just a heads up that there is likely to be some churn around this at some point and I'm slightly concerned we may not have an easy time testing that this does the right thing in all edge cases for 'bazel mode', but I suppose we can deal with that when we get to it.
If it's easy, it would be nice to have a github action for testing the remote example. I'm not sure how difficult that is.

I can't see why we can't support both APIs though and have a default 'bazel mode' for this behavior, though.

That's great to hear! Yes, I was hoping for something along those lines.

The main other difference is that on our end we construct an RE::Action for the worker, upload it and use the digest of that action as the 'worker key', instead of what I assume is requiring that the worker args are a prefix of the action args (in which case the 'worker key' doesn't really seem to matter?).

In the Bazel version the worker key is used to associate a given action with a potentially already running worker instance on a remote executor node. But, it is not directly tied to any kind of previously uploaded blob. Bazel calculates a digest of the worker command and its inputs and uses that as a worker key. In this PR I went for the same approach.

Just a heads up that there is likely to be some churn around this at some point and I'm slightly concerned we may not have an easy time testing that this does the right thing in all edge cases for 'bazel mode', [...] If it's easy, it would be nice to have a github action for testing the remote example. I'm not sure how difficult that is.

That makes sense. I'll look into how to test this on the CI.

I noticed that the example did not use the WorkerRunInfo attributes worker and exe appropriately to distinguish between (remote) persistent worker and non-worker modes respectively. I've updated the example accordingly. This highlighted that the implementation did wrongly use request.all_args_vec for the remote persistent worker case, when it should be composing worker.exe and request.args instead. I've updated the implementation accordingly.
I will continue looking into ways to test this feature on CI.

Just to give a heads up on expected progress here. I'm on leave for the next two weeks and will get back to this when I'm back.
I've started making the setup independent on Nix, so that it is easier to integrate with CI here. That's already working locally.
The other thing is the remote execution system to test the remote persistent worker mode. I spoke with BuildBuddy, it would be possible to use BuildBuddy for this CI use-case, but it would require setting up a free account for the Meta Buck2 repository and configuring an access token for CI. @christolliday would that be possible for Meta to do? Otherwise, I'd have to look into other options to set up a compatible remote execution system on CI.

Hi @aherrmann, @KapJI is looking into setting up a build buddy account.

@christolliday @KapJI I've rebased this PR and added the changes to make it independent of Nix so we no longer require a custom worker image. I've also added a CI test for the persistent worker examples, the test requires a GitHub secret named BUILDBUDDY_API_KEY to hold the BuildBuddy token. I've tested the test script locally, but things may still fail under the GitHub actions environment. Please let me know when the BuildBuddy account is set up and a token is added as a GitHub secret, then I can test and debug the CI configuration.

@KapJI Thank you! That sounds great, I don't think it should required any additional configuration. I'll test and debug the CI setup and let you know if I run into anything.

One issue I'm encountering is that repository secrets are not exposed to GH actions runs that are initiated from forks (as is the case with this PR) for security reasons (see here). Here's what I've done now:

I've added a CI step for the persistent worker steps.
In there I check if the token is available or not. If not, I skip the remote execution tests and generate a GH actions notice annotation. So, by default the remote execution cases will only be checked on main CI or PRs coming from Meta engineers.
I've added the workflow_dispatch trigger to the CI workflow, this should allow Meta engineers to manually trigger a CI run that should have the token set (will only be available once the workflow_dispatch trigger is merged). E.g. to test that an external PR doesn't break these tests.

@KapJI could I ask you to trigger a CI run of this PR from within the Buck2 repo to test the remote execution cases? (After convincing yourself that this PR doesn't do anything dodgy with the token).
You can do this by pulling this PR's branch and then pushing it to the facebook/buck2 repo (not onto the main branch, just as a separate branch). Something along the lines of gh pr checkout 787; git push origin persistent-remote-worker. I'd expect the push trigger to fire at that point, if not you may need to add a dummy commit.

@aherrmann It's running on https://github.com/facebook/buck2/pull/800

@KapJI Thanks! Unfortunately, it looks like the token is still not available:

It is empty in the env section
The RE tests are skipped.

Is BUILDBUDDY_API_KEY configured as a repository secret? Does gh secret list include it in its output?

@KapJI friendly ping, did you have a chance to look into the above?

@aherrmann Sorry for the late reply. I fixed the secret and now it seems to run: https://github.com/facebook/buck2/actions/runs/12300843378/job/34330007436?pr=800
Run ./.github/actions/build_example_persistent_worker
  with:
    buildbuddyApiKey: ***

On #800 I also rebased to latest version where anyhow is removed and some code formatting is applied.

@KapJI Thank you! I've updated this PR to capture the rebase and formatting fixes.
I looked into the CI failure on #800. The issue seems to be that the actions are cached and don't report local or persistent worker execution as expected. I had tested this script with a read-only BuildBuddy token, but it looks like Buck2 CI has a read+write token.
I've addressed this issue by adding a cache buster. An env-var input to the action that is changed each time the test runs. I also  tried the --no-remote-cache flag to Buck2, but that had the unwanted side effect of completely omitting the action from the buck2 log what-ran output, which the test uses to determine what ran how.
I've tested these changes against a read+write BuildBuddy token as well, and the tests passed. Hopefully they'll pass on Buck2 CI as well now. Please let me know if there is anything else I should address before this PR is ready for merge.

Yes, random cache buster env var is a better choice.

I'm merging fixes for failing lints right now. Once those are merged, let's rebase and make sure CI is passing.

@KapJI I've rebased on main.
Linux CI passes.
The MacOS build and test pipeline fails with the same failure that exists on main. So, that should be unrelated to this PR.
The Windows build examples pipeline fails with also fails with the same failure that exists on main. So, that should also be unrelated to this PR.


ci: Add workflow to automatically run npm audit fix weekly

Scheduled to run every Thursday morning at 6am UTC (2am ET)
Opens a PR automatically
PR still needs to be reviewed/approved

Did you test this or is this action sourced from somewhere?

@mattrunyon Tested this here: https://github.com/mofojed/web-client-ui/pull/20


Known issues

These are test failures that are known to occur occasionally. They will be fixed eventually. (Could you be the one?!)

prop_success_array_of_struct_input: unsafeSubstExp https://github.com/ambiata/icicle/issues/599
prop_success_array_of_struct_input: glibc detected: corrupted chunks

these should be gone forever when PSV is removed.

OK if I close this, now that PSV is gone?


⚠ Bofrost.de has degraded performance

In 1df98df, Bofrost.de (https://www.bofrost.de) experienced degraded performance:

HTTP code: 200
Response time: 1794 ms

Resolved: Bofrost.de performance has improved in 46d4f75 after 6 minutes.


AKS Auto-scaler Preview ARM template support

Hi, we would like to start experimenting with the AKS auto-scaler functionality using VMSS. Is support for ARM templates coming soon or what is the status there?

@erenik Please help with the link of document on which above document feedback request is created.
In case your query in not related to document content, open a new forum thread in MSDN forum or Stack Overflow as it could be better place to get help on your scenario. These forum community  members could provide their expert guidance on your scenario based on their experience. Thanks.

@erenik Please help with the link of document on which above document feedback request is created.

@erenik I am moving ahead and closing this feedback now. Please open a new content feedback on the related document and we will definitely assist you on it. Thanks.

Hi, it is related to the guide here, which only documents az cli commands. I was wondering if the same support exists for ARM templates. https://docs.microsoft.com/en-us/azure/aks/cluster-autoscaler#enable-the-cluster-autoscaler-on-an-existing-aks-cluster
I am currently trying to enable VMSS with the AKS deploy, but guess I am missing something for the agentPoolProfiles section.

Hi,
I also try to create an AKS cluster with autoscale option enable via ARM template but get this error:
"code": "InvalidParameter",
"message": "The value of parameter orchestratorProfile.OrchestratorVersion is                                                                                invalid.",
"target": "orchestratorProfile.OrchestratorVersion"
Is it possible to have the ARM template for AKS with autoscale enable and advanced networking?


Unexpected behavior with search filter

Hi @jtrussell!
I found a strange behavior in the search filter.
Using this as example:
http://jsbin.com/rigepe/1
In the search field, type:
true
All items will be hidden, except Mustachio. And if you mark it as checked, all items will be displayed.
Now, clear the search field and type:
false
All items are displayed.
But you type some inexistent word (considering both key and value from the list - as value for the search), like:
xyz
All items will be hidden as expected.
I think this is related to the filter function in AngularJS, checking all keys and values in our list.
Can you confirm this?
Maybe before sending to the Angular filter, we could clean our collection, removing unwanted keys/values..
Is there a way to extend the filter function in the ivh-treeview?
Thanks! :beers:

You are correct, we're just leveraging Angular's filterFilter. It's pretty powerful though, for example you can give it a function rather than just a string:
In  not-view land:
$scope.myTreeFilter = function(node) {
  if( ... ) {
    // Show it!
    return true;
  }
  // Hide it!
  return false;
};

In view land:

Does that answer your question?

It's OK, but how can I get the search value in my custom search function?
My HTML looks like below, and maybe is important to say that I'm importing this template with ng-include:

    Stores

            <input type="text" ng-model="bagSearch" class="form-control" placeholder="Type here to filter" />

In my function, I tried to read the $scope.bagSearch, but returns undefined.
So I changed the function call in the HTML to:
...
ivh-treeview-filter="myFilterFn("
...

and with this I was able to read the bagSearch content, but lost the node value...
(PS: just for future reference, please could you correct your function name to myFilterFn, as referenced in the HTML? :wink:)

Thanks for pointing out the typo - fixed!
There are going to be lots of options for getting the filter string into your function. What's best is going to be largely dependent on your setup, where the filter function is defined, and how reusable you want the function to be. If the function happens to live in the same controller that the filter string is initialized in then you can do something like this. If you want to set up your filter elsewhere you might build it as a higher order function that takes a scope or a getter as a parameter and returns the filter function.
myFilterFuncFactory = function($scope, filterAttr) {
  return function(node) {
    // E.g.
    var filterStr = $scope[filterAttr];

    if( ... ) {
      return true;
    }
    return false;
  };
};

Thanks for your help!
Sorry about my lack of knowledge to get this working.

I hope everything worked out. Just FYI when #35 gets fixed that'll definitely be the optimal solution!


Add the ability to get CPU frequency

Most code used from
https://docs.rs/sys-info/0.7.0/src/sys_info/lib.rs.html#367-406

This looks good! I played around with how to deal with the result from the file open, but I'm not exactly sure. I'll keep researching in the morning.

I've looked into it more and I think I have a solution. We need to put the file read into a match with Ok and Err as the things it check for. The return type is correct. We now just need to have the Err return Err(Error::IO)
This would look like
match File::open(...) {
    Ok(_) => {
        ...
    },
    Err(_) => Err(Error::IO),
}

I've looked into it more and I think I have a solution. We need to put the file read into a match with Ok and Err as the things it check for. The return type is correct. We now just need to have the Err return Err(Error::IO)
This would look like
match File::open(...) {
    Ok(_) => {
        ...
    },
    Err(_) => Err(Error::IO),
}

That's what the ? operator does on the line File::open("/proc/cpuinfo")?.read_to_string(&mut cpu_info);

YOO, i forgot you can do that, aight, rust is a great language. Yea, if you add a ? at the end of that line, then it works. Instead of the match stuff.

YOO, i forgot you can do that, aight, rust is a great language. Yea, if you add a ? at the end of that line, then it works. Instead of the match stuff.

For some reason I couldn't get the ? operator to work in this case
match get_cpu_freq() {
  Ok(f) => println!("CPU freq is {} MHz", f),
  Err(_) => println!("Failed")
}

Probably because the main function doesn't return a result.


Patchomator does not make the App Support folder

[FATAL ERROR] /Library/Application Support/Patchomator is not writable. Re-run patchomator with sudo to create the config file there, or use a writable path with
	 --config "path to config file"

Copied patchomator.sh to /usr/local/Installomator and ran it on a fresh VM and this fatal error appears. Script does not properly create its folder dependency.
Error occurs when run via sudo
Running this command resolves the issue: mkdir -p "/Library/Application Support/Patchomator"

Good catch. Fixed and closed.