Feat/add reassure perf setup

Details

In the PR we set up the reassure testing library so we can use the measureFunction methods to test the core methods in Onyx and ensure they do not regress in terms of performance
Related Issues

https://github.com/Expensify/App/issues/39164
Automated Tests

Manual Tests

Author Checklist

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

[x] I added steps for local testing in the Tests section
[x] I tested this PR with a High Traffic account against the staging or production API to ensure there are no regressions (e.g. long loading states that impact usability).

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

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

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

[x] I verified that any callback methods that were added or modified are named for what the method does and never what callback they handle (i.e. toggleReport and not onIconClick)
[x] I verified that the left part of a conditional rendering a React component is a boolean and NOT a string, e.g. myBool && <MyComponent />.
[x] I verified that comments were added to code that is not self explanatory
[x] I verified that any new or modified comments were clear, correct English, and explained "why" the code was doing something instead of only explaining "what" the code was doing.
[x] I verified proper file naming conventions were followed for any new files or renamed files. All non-platform specific files are named after what they export and are not named "index.js". All platform-specific files are named for the platform the code supports as outlined in the README.
[x] I verified the JSDocs style guidelines (in STYLE.md) were followed

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

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

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

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

[x] If the PR modifies a generic component, I tested and verified that those changes do not break usages of that component in the rest of the App (i.e. if a shared library or component like Avatar is modified, I verified that Avatar is working as expected in all cases)
[x] If the main branch was merged into this PR after a review, I tested again and verified the outcome was still expected according to the Test steps.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

Screenshots/Videos

Android: Native

Android: mWeb Chrome

iOS: Native

iOS: mWeb Safari

MacOS: Chrome / Safari

MacOS: Desktop

I have read the CLA Document and I hereby sign the CLA

recheck

Maybe not, the reassure test is not passing on this PR @rinej

I'll wait to review until the tests pass.

I ran them and they still don't pass.

@rinej I believe they will autoapprove after you first PR merged

@tylerkaraszewski It looks likes the npx command didn't work on the pipeline, I installed the required package explicitly, please check it now, thanks!

Hmm, still failing.

restarted the actions

@rinej still not happy

@mountiny @tylerkaraszewski I found the issue and the best solution would be to split this PR into two separate PRs
First -> Add reassure and example tests
Second -> Add GH workflows to compare results on feature and main branch
We need to split it, because in the workflow we switch to main branch and run the reassure test there, so it is required to have at least one test in place on the main branch
Here is the first PR -> https://github.com/Expensify/react-native-onyx/pull/530
Please have a look on it. After we merge it, I will update the current one, and the workflows should pass

I am not sure what happened here, I have merged the other PR you have linked but github seems to have merged this one too, how were they linked together?

@rinej the actions folder is not in main so this is somewhat misleading

@mountiny I created the new PR here -> https://github.com/Expensify/react-native-onyx/pull/531

I am not sure what happened here, I have merged the other PR you have linked but github seems to have merged this one too, how were they linked together?

If PR A contains a set of commits, and PR B contains a superset of those commits, then when you merge B, A will also show as merged, as all of its commits have been merged.

as all of its commits have been merged

Yeah the confusing part was that the diff changes showing from the A were not in main as I assume they were reverted in some later commit in B.


No option 'user' in section: 'DEFAULT'

Describe the bug
I know there are other 2 reports about this but both are closed with little to no information on how to solve, the script just stops and says the config file has no user, however i already remade the file 3 times and made sure the user was right
Expected behavior
Run script as normal
Instance Type (please complete the following information):

ARM or Micro:  ARM
Micro Second Instance: Yes
Custom Image or default: Custom, Oracle Linux 7.9

Environment (please complete the following information):

Micro Instance or Local:  Micro
OS: Ubuntu
Version:

Screenshots
Additional context
Tried the solution of removing /home/ , did not work

Hi @Caduzin2005,
This is defiently an issue with the setup, could you please verify the oci_config and oci_env files? They should resemble the following format, with only the values changed:
oci_config:
[DEFAULT]
user=ocid1.user.oc1..aaaaaaaa
fingerprint=2e:c0:...
tenancy=ocid1.tenancy.oc1..aaaaaaaapoaaa
region=ap-hyderabad-1
key_file=/home/ubuntu/oracle-freetier-instance-creation/oci_api_private_key.pem

oci.env:
Ensure the path to OCI_CONFIG is correct:
# OCI Configuration
OCI_CONFIG=/home/ubuntu/oracle-freetier-instance-creation/oci_config

Also, please check that there are no spaces in any of your paths.
Thanks!

Hi @Caduzin2005,
This is defiently an issue with the setup, could you please verify the oci_config and oci_env files? They should resemble the following format, with only the values changed:
oci_config:
[DEFAULT]
user=ocid1.user.oc1..aaaaaaaa
fingerprint=2e:c0:...
tenancy=ocid1.tenancy.oc1..aaaaaaaapoaaa
region=ap-hyderabad-1
key_file=/home/ubuntu/oracle-freetier-instance-creation/oci_api_private_key.pem

oci.env: Ensure the path to OCI_CONFIG is correct:
# OCI Configuration
OCI_CONFIG=/home/ubuntu/oracle-freetier-instance-creation/oci_config

Also, please check that there are no spaces in any of your paths.
Thanks!

Thank you very much, there was a typo on the oci config path, just noticied now, thanks


As a developer, I want data structures to store my report data, so that I can save reports to the database

Description:
Create datastructures to store report data as described in the miro board: Whiteboarding_2024_04_12
@dleard we might need clarification about LFO data (if applicable)
Acceptance Criteria:
Given I am a developer
When I develop a reporting form
Then I have tables to store the data following the program configuration
Given I am a developer
When I store data from a reporting form
Then the data is stored in json format, regardless of the schema that generated it
Given I am developer
When I store data from a reporting form
Then I have the following tables to fan out the data:

activity_form_data (json_data, report_version_id, activity_id)
source_type_data (json_data, report_version_id, source_type_id, activity__form_data_id)
unit_data (json_data, report_version_id, source_type_data_id)
fuel_data (json_data, report_version_id, fuel_id, source_type_data_id, emission_data_id)
emission_data (json_data, report_version_id, gas_type_id, source_type_data_id, fuel_data_id)
methodology_data (json_data, report_version_id, methodology_id)

A graph of the architecture:

Development Checklist:

[x] aforementioned tables
[x] model tests
[x] Meets the DOD

Definition of Ready (Note: If any of these points are not applicable, mark N/A)

[x] User story is included
[x] User role and type are identified
[x] Acceptance criteria are included
[ ] Wireframes are included (if required)
[x] Design / Solution is accepted by Product Owner
[ ] Dependencies are identified (technical, business, regulatory/policy)
[x] Story has been estimated (under 13 pts)

Definition of Done (Note: If any of these points are not applicable, mark N/A)

[ ] Acceptance criteria are tested by the CI pipeline
[ ] UI meets accessibility requirements
[ ] Configuration changes are documented, documentation and designs are updated
[ ] Passes code peer-review
[ ] Passes QA of Acceptance Criteria with verification in Dev and Test
[ ] Ticket is ready to be merged to main branch
[ ] Can be demoed in Sprint Review
[ ] Bugs or future work cards are identified and created
[ ] Reviewed and approved by Product Owner

Notes:

I will close this ticket, however but noting that we still need some clarity on fuels (and how emissions categories fits in with them).


update the open external dartdoc link

Fix #300.

new image:

I only think that it may be sometimes useful to know to which library an element belongs.

@kasperpeulen, totally agree. We did loose a bit with this PR. I'll open a new issue.


Add Irida term id range

I'd rather have ranges for people and an "in_subset " annotation property for groupings like this.

Ok.  I was thinking it might not be just me contributing new items from our ontology group; but if you want it organized by user thats fine.

Pull request now has
 allocatedto: "Damion Dooley"

Pier, I think this is good to go now, right? https://github.com/FoodOntology/foodon/pull/9/files

Yes, looks good


RedisAdapter only drop index bug

hi，RedisAdapter only drop index
source in "nano-redis": "1.7.0"
public drop(table: string, callback: () => void): void {

        this._getDB(table).del(this._key(table, "_index"), () => {

            let newIndex = new DatabaseIndex();
            newIndex.doAI = this._dbIndex[table].doAI;
            this._dbIndex[table] = newIndex;

            this._pub.publish(this._id, JSON.stringify({
                source: this._clientID,
                type: "clr_idx",
                event: {
                    table: table
                }
            }));

            fastALL(this._dbIndex[table].keys(), (item, i, done) => {
                this._getDB(table).del(item, done);
            }).then(callback);
        });

    }

my
RedisAdapter.prototype.drop = function (table, callback) {
        const _this = this;
        _this._getDB(table).del(_this._key(table, '_index'), () => {
            const delKeys = Object.assign([], _this._dbIndex[table].keys());
            let newIndex = new DatabaseIndex();
            newIndex.doAI = _this._dbIndex[table].doAI;
            _this._dbIndex[table] = newIndex;

            _this._pub.publish(_this._id, JSON.stringify({
                source: _this._clientID,
                type: 'clr_idx',
                event: {
                    table: table
                }
            }));

            fastALL(delKeys, (item, i, done) => {
                this._getDB(table).del(_this._key(table, item), done);
            }).then(callback);
        });
    };

Hey thanks for letting me know about this!
A new version of the redis adapter, 1.7.1 was just released to NPM with a fix for this.
I'm closing this issue, feel free to comment if you run into this problem again and we'll reopen the issue.

Sorry, the new version doesn't work.
Please modify the 522 line.
From
this._getDB(table).del(item, done);
To
this._getDB(table).del(this._key(table, item), done);

thanks again man, the fix is live as of 1.7.2


This is not a bug, but a question.

First of all, so sorry for posting this here, but I couldn't find anywhere else to ask this (or any useful Google results). I am quite intrigued with the context value in the constructor, I haven't seen that used before in userscripts and I can't seem to find out where it comes from. Could you possibly give a short description of where it comes from and what the object references? :P

at the bottom, it calls the function we create with the context argument with window


Revise architecture diagram for STRA based on email from Jenny Li

STRA is ready for submission, this is a dependency for the completion

Sent by email.


Update tapir-akka-http-server, ... to 1.7.4

About this PR
📦 Updates

com.softwaremill.sttp.tapir:tapir-akka-http-server
com.softwaremill.sttp.tapir:tapir-enumeratum
com.softwaremill.sttp.tapir:tapir-json-circe
com.softwaremill.sttp.tapir:tapir-swagger-ui-bundle

from 1.7.3 to 1.7.4
📜 GitHub Release Notes - Version Diff
Usage
✅ Please merge!
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention me in the comments below.
Configure Scala Steward for your repository with a .scala-steward.conf file.
Have a fantastic day writing Scala!

🔍 Files still referring to the old version number
The following files still refer to the old version number (1.7.3).
You might want to review and update them manually.
project/Version.scala

⚙ Adjust future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "com.softwaremill.sttp.tapir" } ]

Or, add this to slow down future updates of this dependency:
dependencyOverrides = [{
  pullRequests = { frequency = "30 days" },
  dependency = { groupId = "com.softwaremill.sttp.tapir" }
}]

labels: library-update, early-semver-patch, semver-spec-patch, old-version-remains, commit-count:1

Superseded by #511.


Remove: vim.vim version 8.2.4533

## .\Tools\YamlCreate.ps1 -PackageIdentifier vim.vim -Mode 5 -SkipPRCheck -PackageVersion 8.2.4533

[X] Have you signed the Contributor License Agreement?
[X] Have you checked that there aren't other open pull requests for the same manifest update/change?

[X] Does your manifest conform to the 1.0 schema?

Microsoft Reviewers: Open in CodeFlow

/azp run


[DO NOT MERGE] Test cryptographic footprint scanning on integrations-core

What does this PR do?
Adds lines to codeql_config.yml and codeql_analysis.yml to run custom codeql from our qlpack.
Motivation

This serves as a proof of concept for integrating custom CodeQL rules in an integrations-core branch.  Once I get qlpack rules merged into the original qlpack, I'll remove the reference to the fork.
Additional Notes
DO NOT MERGE this into the mainline branch - these rules are experimental and may clutter Github Security reports.  I'm trying to see that they look good in Github Security + CI/CD
Review checklist (to be filled by reviewers)

[ ] Feature or bugfix MUST have appropriate tests (unit, integration, e2e)
[ ] PR title must be written as a CHANGELOG entry (see why)
[ ] Files changes must correspond to the primary purpose of the PR as described in the title (small unrelated changes should have their own PR)
[ ] PR must have changelog/ and integration/ labels attached

Note - integrations-core is 96% python, while my rules are checking go.  Doh.  If this gums up the PRs in integrations-core, close.  Otherwise, revisit when python rules are out.

Hi! This PR is like a month old. Are we blocking on anyone?

Closing for now


add footer, modal, and move some containers around

#337 has a todo to add a modal.  I have a modal and a place for about stuff in my walkthrough branch.  I pulled that out into this branch so we aren't doubling work.
Changes proposed in this pull request:

adds react modal
adds footer
moves a little bit of the markup around
fixes an issue with the group sidebar not scrolling.

Steps to functionally test this:

click on About in the footer. A placeholder modal should appear.

The look of the footer is very basic and unstyled.

closing this since it's inside the walkthrough PR


Threoretical question: Programmatic usage and receiving results as objects

Hi!
I doing some research about some reporter for mocha to be used inside AWS lambda function.
Since lambda has readonly file system, i need to receive JSON results as object, not as file. Then i will pass that json as response to caller, where i will grab all those objects, and generate HTML on caller side(host that ivoked lambda).
Sure i understand that this is pretty crazy usage, most of all i will fork this repo and rewrite some parts to make that happen. But can you guys point me to right direction to make that fast?
So what i need

get results as object instead of JSON file. Probably i can monkey-patch some NodeJS fs functions to intercept saving to file call.

Grab array of JSON results, and generate HTML from them

Attachments and so on not planned yet.

@adamgruber Thank you! I will try this soon!


[CRA - RxJS - SC] Fix profile page image

The profile page shows a broken image and has alt text "Avatar" until the image loads.

#639


Tests fail for Raspberry Pi Zero

Hello. I'm trying to run OpenCL on Raspberry Pi Zero with Raspbian (Debian Buster). I know that the library was not designed for Zero, but since this guy claimed it worked for him, I decided to give it a try. So here is what I discovered:

VC4CL cannot be built on latest Raspbian, because it doesn't have /opt/vc/. Not sure if it is supposed to be there or they moved it to other place.
Latest version of VC4C throws unexpected reloc type 0x03 error. Could be fixed with '-DCMAKE_CXX_FLAGS=-fPIC'.
VC4CL commit with "stable" tag cannot be compiled: Program.cpp needs Optional.h but can't find it. Can be fixed easily.
TestVC4CL from 2021/09/14 passes only 36.6% of tests.
After playing with /opt/vc/bin/container_test I discovered that now TestVC4CL passes 54% of tests.

Could you please comment this situation?
Even if it doesn't work for me, you do a great job. Thank you.

a60945c9982a8ed07b7c216a308bf4beee903bce (or just use latest master) should fix it. If it does not, can you give me the exact thing which fails + message?
see https://github.com/doe300/VC4CL/issues/105#issuecomment-1024877957, I should probably disable by default or monkey-patch the validator
was my fault, I restructured code in VC4C too soon ;) Both masters should work well together.
I am currently working on improving test stability for both VC4C and VC4CL, but some of the tests for TestVC4CL (or TestVC4C for that matter) never passed. I guess these are less in a sense of regression tests, more like to have some code I can test (and fix).
What is /opt/vc/bin/container_test, I don't think I have ever heard of it? What did you change there?

About the test passage, VC4CL is not complete, so while I agree having failing own tests may be confusing, other tests won't pass 100% too. E.g. currently it passes around 90+% of boost/compute tests, some only after fixing or modifying the tests to work on the platform and IIRC about 2/3 of OpenCL piglit tests. Similarly the OpenCL-CTS tests are largely passed, but with some major holes (e.g. anything non-trival math related).

No it does not, because there still is a line elseif(CROSS_COMPILE OR EXISTS "/opt/vc/include/bcm_host.h"). It doesn't see /opt/vc. This would probably result in undefined reference to bcm_host_init (but I need a day to recompile everyting)
2,3) Happens. Just saying
Wouldn't it be better to create simple "2 + 2" example to verify if the library is working or not? Everyone says about boost tests and 90% of support. I don't know much about boost, I am interested if my program will work or not. I need to verify I have right compiler, right kernel, right firmware and right everything. And when I see "clCompileProgram" I get a feeling that something has gone terribly wrong and the whole thing doesn't work.
Well, I had the idea that maybe official programs will be executed without problems, so I played with programs from /opt/vc/bin. And apparently container_test made something to GPU so that tests executed better (I also noticed that pseudographics in raspi-config were replaced by characters).
Okay, I finally brought it to work, and I want to say that VC4CL is extremely unfriendly. CL/ocl.h has functions with cl prefix, while VC4CL has VC4CL_ prefix. So functions are compiled, but cannot be linked. What I did is including "icd_loader.h" and adding "-Duse_cl_khr_icd=true", only then it could be executed.
And when I execute this example (that you mentioned as a helloworld in this topic ), I get clEnqueueNDRangeKernel fail.
All of this still applies to source from  2021/09/14. Should I build the latest?

Oh right, missed that one. Does the header file /usr/include/bcm_host.h exist on your system? Or where the is the header bcm_host.h located?

I don't know much about boost, I am interested if my program will work or not.

Not sure if I understand you correctly, but if you want to run own code then I cannot guarantee that it works, since that depends on so many things. You will have to try it out and if the compilation fails then it could very well be a bug/missing feature in VC4C.
The issue with the prefixes is that there are basically 2 ways of using any OpenCL implementation: directly or via an ICD loader. If you want to use it directly, configure CMake with -DBUILD_ICD=OFF, then the clXXX symbols will be provided. If used via an ICD loader, then the loader will do the function mapping depending on the active implementation. See also https://github.com/doe300/VC4CL#khronos-icd-loader for how to enable ICD loader support for a source-build.
As for the source code version, I would always recommend to use latest master.

Does the header file /usr/include/bcm_host.h exist on your system? Or where the is the header bcm_host.h located?
I reinstalled my system, I have Buster now. there is no /usr/include/bcm_host.h, I have it in /opt/vc/include/bcm_host.h. I guess same applied to Bullseye, but not 100% sure.

Not sure if I understand you correctly, but if you want to run own code then I cannot guarantee that it works, since that depends on so many things.
Well, it would be nice if you could provide some simple program and say "This one is one true way. If it is compiled and works, other programs written in similar way may probably also work. If it is not compiled or doesn't work, it's your problem". Instead you provide no examples and don't guarantee that user's code works. Totally fair from your side, but it doesn't help anybody in using the library.

Thanks for icd-loader advice. As said, I'll compile the newest version till tomorrow evening and might update some info.

About which software should work: Any OpenCL client application which works on other OpenCL implementations and does not use some implementation specific features or unsupported extensions shoudl work. If it does not, it is likely a bug in VC4CL.
I just tested on a fresh installation of Bullseye and besides one fix with the header paths (which I will probably commit today or so) it compiles fine. But Buster is definitively tested more extensively.

Okay, I tried this example, started it with sudo and it works. You are a genius, man. You don't accept donations, do you?


Use HTM escape chars

Simplify the template by using html escape chars

Coverage remained the same at 81.339% when pulling dfb6ac09917aba60b684230a413f24f041b5c929 on jderusse:fix-html-chars into d38f2f2a5a0d387e9788b1cc6cc5e96817e8c5df on Rebilly:master.

@jderusse 👍
Thanks!


Improve service and dependencies namespace

Add struct DependencyFromService to associate a Dependency, a Service and the dependency name.
Use it to solve the complexity of the namespace

Close https://github.com/mesg-foundation/core/issues/200

I reduced the complexity of the DependencyFromService.Start by moving the WaitForContainerStatus function directly in the container.Start function and to have this consistent I did the same for the container.Stop function and so WaitForContainerStatus can be private in this package now


Move EmsRefresh targets to MiqQueue data

Reduce the overhead of put_or_update by moving EmsRefresh targets from
MiqQueue args to data.  Also replace uniquing the targets on put with
msg.args[0] | targets with just a simple concat and unique the targets
on the dequeue side.

@agrare changes I needed to do to have working refresh https://github.com/ManageIQ/manageiq/pull/16274
https://github.com/ManageIQ/manageiq/pull/16274/commits/c51b163a8795a2521224d20bc2ac058694269609 is tricky, since refresh expects 'targets' as a first arg. Not sure if that can break code that expects data as second arg. Maybe we should rather change the interface of refresh method? (which might bring other problems, so maybe new wrapper method would be better)

@agrare @Fryguy also the disadvantage of fetching the whole data to ruby is rising mem consumption, I see it takes around 800MB for 4k targets. So that will hit any worker that will be doing the queuing. (using DB concat, memory is flat)

Okay with https://github.com/ManageIQ/manageiq-schema/pull/107 merged I just dropped the last commit since all it did was handle migrating queue args.

@Fryguy can you take another look?  Should be ready now.


Feature request : Penalties after activation.

Adrenaline is very cool at the same time very overpowered so for that matter I would like to suggest having penalties like Debuff ,Hunger drain, etc. after each rush. For example something like Hediff with 5 stages consist of Deadly, extreme, serious, minor and hidden.
How that work? lemme explains. So after the end of each rush Pawn/Creature will get Tired hediff which increase their tiredness ,hunger and lower their movement ,manipulation. Starting severities is based on adrenaline severities with each tick their severity slowly goes down to minor then hidden. while Pawn/Creature has already got tired effect if adrenaline rush goes again it will increase severity  at the end of rush by 2 of the currently having tired hediff i.e. pawn A has first rush then got tired at extreme severity then when it dropped to minor then unfortunately rush goes again which increase severity by 2 from minor to extreme regardless of adrenaline severity at the end of the recent rush. First rush will always cause hediff severity based on adrenaline severity(when pawn doesn't have Tired hediff on) but IF they have it will increase the severity of current one by 2 and during the rush tired hediff won't take effect until the end of current rush and IF pawn already has tired hediff at serious severity next rush will cause severity to goes deadly which has a chance to cause heart attack.(Pawn cannot get Tired hediff at deadly stage at the end of the rush unless they already got one at serious severity).

Sorry I didn't see this sooner; GitHub doesn't exactly notify me and I'm not sure where abouts you can change that! Something along the lines has been added since, so I am going to close this. Thanks though :)


Add number of partition and number of replication to topic list page

Great project.
The topic list view only has one topic name column. It'd be great if we can see number of partition and number of replications from the same page.

number of partitions and broker spread percentage has been added to topic list.  closing.


Padding on checkbox makes payment processor table spacing weird

Ugh, dealing with forms is the worst thing.


Potential misleading is_file_valid

The statement is_file_valid is misleading as it also reports the security.txt as valid that are missing the expires field.

Thank you


iOS ScrollView: Add scrollBy method

Android PR: facebook/react-native#15610
Currently, React Native allows you to scroll a ScrollView to a particular position using scrollTo. If instead you want to scroll by a delta, you could try to do this using scrollTo (add the delta to the current scroll position) but this doesn't always work out as intended due to the async nature of React Native (what you think is the current scroll position might be a stale value). This change introduces a scrollBy API to solve this problem. scrollBy takes a delta to scroll by and native takes care of doing the arithmetic because it knows the latest scroll position.
Test Plan
In a test app, verified that scrollBy works properly with and without animation and for both horizontal and vertical ScrollViews. Also, my team is using this change in our app.
Adam Comella
Microsoft Corp.

@rigdern Thank you for the is great PRs!
Honestly, I am a bit conserned about should we have this or not; I see a great advantage in having the smallest possible set of APIs.
Because of asynchronous nature of RN, this method is already asynchronous. So, if we simply implement reliable getter for contentOffset value (which we also need, right?), we will be able easily implement scrollBy in pure JavaScript.

@shergin As you point out, you can implement scrollBy in terms of scrollTo as long as you know the current scroll position and the delta you want to scroll by. If you have the current scroll position in JavaScript, you could implement scrollBy in terms of scrollTo. However, because native and JavaScript communicate asynchronously, doing this calculation in JavaScript always runs the risk of it being done with a stale scroll position. This is why we moved the calculation to native.
Before implementing scrollBy, my team tried doing the calculation in JavaScript using the latest position given by onScroll. However, we ran into some scrolling issues that were resolved by introducing this scrollBy API.

@rigdern Yes, implementing this natively makes this faster but it does not makes it synchronous. It helps a bit and probably fixes your case, but conceptually it is pretty same as my proposed alternative solution.
UIBlock will be executed on UIManager "tick" anyway (~60hz). Native contentOffset  implementation though should be much more perfromant (you can use simple distach_async to retrieve value from main thread), so you will be able get result before the next tick. So, I bet my proposed solution will be as fast as this one. (But it is much simpler and we end up with two method instead on one.)

@shergin I'm not sure I understand your proposal. Can you elaborate?

@rigdern
Sure!
Step 1. Implementing a prop/method currentContentOffset which return promise with offset value.
Step 2. Implementing scrollBy as a combination of currentContentOffset and scrollTo.

@shergin let's say you want to scroll by 50 pixels. What happens if by the time your scrollTo is processed, the scroll position has changed such that your currentContentOffset value is off by 10 pixels? Then your scrollTo request will only move you by 40 pixels instead of the 50 that you wanted.
Isn't this a problem that your proposal has but my proposal does not?

@rigdern I believe, your proposal has (almost) same issue, unfortunately. Even if the shift itself will be performed at exact amount of pixels, because of async nature of RN, your app will still have no idea what's going on with scrollview. So, your contr-case looks pretty limited to me.
Beside that, afaik, getting this value should be very very fast, comparable to generic dispatch_async, so you will get wrong/obsolete result almost only if some animation is performing.

@shergin regarding the app not knowing what the ScrollView is doing, there's another PR I'll be sharing which causes the ScrollView to fire an event after it applies the scrollTo/scrollBy operation. The combination of the event and the scrollBy method have given us a good experience for manipulating the ScrollView.
Does this address your concern about this proposal having almost the same problem as yours?

@rigdern Sure, firing onScroll event right after scrollTo is a good idea! But I don't think that it can help here.

@shergin To be clear, we're not reusing the onScroll event. We have a a separate event called onScrollPositionSet which native fires after applying the scrollTo/scrollBy request. An app can keep track of what the ScrollView is doing by ignoring all onScroll events that occur after JavaScript has called scrollTo/scrollBy but before it receives the corresponding onScrollPositionSet event.
Can you elaborate on your concern with this solution?

@sahrens Spencer, we need you second opinion (or blessing) here!
So, the main question: Should we have scrollBy implemented natively or should we have just currectContentOffset implemented natively?

Let me guess - are you using this for an inverted scroll list to do an animated reveal of new items at the bottom? If so, have you tried layout animation and do things work well when the scroll position is in the middle of the content somewhere?
If not, giving us more context on your scenario would help.
I agree with @shergin in general that minimizing the API is generally good, but I can see some cases where scrollBy might be really helpful.

@sahrens
We have a vertical virtualized list view where all of the items are absolutely positioned. The item positions are controlled by AnimatedValues because we want to avoid having to go through the diffing process to move them.
A scenario where scrollBy is useful is when we load items above the user's viewport which causes the y position of items in the viewport to change. If we didn't do anything additional, this would cause the items the user is looking at to fly off of the screen. To avoid this, we update the scroll position (by the amount the y coordinate of the viewport items changed) and update the y coordinates at the same time.
We initially tried to do this with scrollTo by adding the current scroll position to the y coordinate delta. However, sometimes the current scroll position value was stale by the time scrollTo ran which caused us to scroll to the wrong position and for the user to perceive a jumpiness. Consequently, we've introduced a native scrollBy implementation so we don't have to worry about using a stale value for current scroll position.
I added this example to the PR description.

Ah yes, I have proposed a different solution to this problem - I would posit that the current behavior (content jumping when offscreen layout changes) is rarely what should happen and we should change the bahevior of ScrollView to prevent this, so you can append to the top or bottom with no movement of content in the view port. We'll probably need to hate the behavior somehow so we don't break legacy cases, but I think we should change the behavior long term.
@shergin: I think you might have a task for this. Thoughts?

@sahrens Can you elaborate on the details of how this ScrollView change will work? Can you clarify what you meant by "We'll probably need to hate the behavior...". I think you meant to use a different word than "hate".
To be clear, we are using a custom virtualized list view implementation. We aren't using React Native's ListView or VirtualizedList.

Speaking about current scrollBy proposal, here is what I dislike with this in short:

Complex (and eventually unnecessary) native implementation;
Having concept: "I am business logic; I have no idea of current/actual ScrollView state; but, anyways, please scroll it to 50 pixels down.".

So, I believe we can solve both problems having trivial currectContentOffset implementation and trivial scrollBy implementation (in JS!). We have not tried it yet. 😞 I feel I have to implement it by myself.
Speaking about "content-offset aware relayout": Yes, we discussed it (just created t21772624), and that is great idea, but I am not sure that I know how to implement it. Yet. And looks like we have to have a way to specify exact node which have to define "stable position".

Ha yeah meant "gate" the behavior.
Basically, by default, if you add items off the top of the screen, then we should automatically do the compensation you're trying to do manually.

But at the very least we could make it a new prop, like maintainVisibleContentPosition or something.

@sahrens supporting a maintainVisibleContentPosition prop in the ScrollView might make the scrollBy method unnecessary because that's the kind of behavior we're trying to achieve through scrollBy.
However, I suspect implementing this logic in ScrollView will be harder than us implementing it in our virtualized list view because our virtualized list view knows a lot more about its content. It knows the content consists of a sequence of items, it knows the size and position of each item, and it knows when the content is changing. Whereas the ScrollView makes fewer assumptions about its content which makes it a more general problem which is harder to solve. Also, I imagine the maintainVisibleContentPosition implementation would need to query for the position of the "locked" element so we'd have to make sure that wouldn't hurt performance.
@shergin you mentioned these criticisms of scrollBy:

Complex (and eventually unnecessary) native implementation;
Having concept: "I am business logic; I have no idea of current/actual ScrollView state; but, anyways, please scroll it to 50 pixels down.".

I agree with the desire to keep the surface area small by only adding APIs that are necessary.
I'm not sure why you characterize the native implementation as "complex". It looks like a small amount of straightforward code.
You mentioned "I am business logic; I have no idea of current/actual ScrollView state;" I wouldn't say it "has no idea". It knows what the ScrollView is doing but its knowledge of the details might be slightly out-of-date. Consequently, if it were to use its slightly out-of-date information in the calculation, the result would be slightly off which would be noticeable to the user.

I feel I have to implement it by myself.

Feel free to do that. We experimented with various solutions on Android and ended up with a native scrollBy in order to avoid the problems mentioned earlier in this thread. You can see if your experiments yield the same conclusion.
What are the next steps for working towards a conclusion on this PR?

I think scrollBy is pretty simple so pretty low risk and low cost in terms of API bloat, so if we're not sure how long it would take to get a proper solution in place, I think it would be ok to do this in the mean time. Maybe we shouldn't document it to discourage usage though?
Are you ok with moving forward on this, @shergin?

Also, are you really not seeing any flicker with this? Seems like you would run the risk of flickering depending on if the layout takes more than a frame to compute or not. Or are you doing something else to try and synchronize, like waiting for onLayout or something?

@sahrens

Also, are you really not seeing any flicker with this?

I asked my team about this and you are correct. It turns out we ended up seeing flickering on Android. To fix this, we wrote a custom native module which repositions the items and updates the scroll position in the same frame. (It's not that general of a solution. The method takes a list of views, a list of coordinates to move the views to, and a delta to scroll by and then applies all of that information in the same frame.) So we're no longer using this scrollBy patch on Android.
On iOS, we're still using this scrollBy patch and we're not seeing any flickering.

Oh another issue - does scrollBy (or your custom native module on Android) maintain scroll momentum nicely?
Here's another approach - what about rendering an "infinite" container on top of your content with a big contentInset to compensate for it, then render new items into that container stacking up from the bottom (flex-end) and reduce the contentInset at the same time so they can be scrolled to? Then you don't have to muck with scroll position at all. If that approach works, maybe we can bake it into FlatList...

@sahrens
Regarding scroll momentum, we designed our virtualized list view to avoid interfering with scroll momentum. It does this by waiting for the scroll position to stop changing (so the ScrollView is probably idle) before setting the scroll position.
I know that contentInset is an API on iOS. Is something similar supported on Android?
By the way, I think it's unlikely that my team will be able to switch to a generalized virtualized list. We wrote 2 custom virtualized lists. The first one was intended to handle all virtualized list scenarios in our app (we open sourced it: https://microsoft.github.io/reactxp/docs/extensions/virtuallistview.html). However, one of the virtualized list scenarios in our app was more complicated than the others so we ended up writing a second customized virtualized list just for that scenario. This second more complicated one is the one that uses scrollBy and the one we've been talking about here.

... Flickering on Android supports my theory (where the app does not really know what's going on and ask ScrollView to scroll by some amount of pixels). So, we are lucky, this solution works on iOS for this very specific case, but it does not work on Android because... we are not lucky on Android.
This make me feel uncomfortable with this approach.

If it waits for scrolling to stop to adjust scroll position, it must also wait to insert the new item, right? Otherwise it would jump. In that case, what happens if you scroll continuously until the ScrollView stops at the edge - would the new content pop in at that point?
Looks like your VirtualListView is very similar to VirtualizedList. That's cool you keep the DOM order constant and change the offsets. I thought about doing that, but it made it hard to leverage the power of native layout and LayoutAnimation for cell height changes and animated drag-and-drop.
What does recycling actually do? Looks like all it does is recycle the info objects which are very lightweight? There is quite a bit of code though so I probably missed something. I found recycling actually had little benefit and in some cases was actually worse because the react diffing of totally different items was more expensive than just rendering new, and the bottleneck is the js, not the native view creation. The JS VM GC is also very good at short lifecycle object management, unlike say dalvik, so I saw little benefit from recycling js objects.
In any case, have you tried a side-by-side perf test with VirtualizedList? I'm curious how they compare.

@shergin

(where the app does not really know what's going on and ask ScrollView to scroll by some amount of pixels)

I'm not sure what you mean by this. If you mean that the flickering happens because the scrollBy and the repositioning of items happen in different frames, then yes that's right. I'm not sure why they happen in the same frame on iOS but get split across frames and cause flickering on Android. As you say, we are lucky on iOS.

Thanks for the discussion. We decided to go with an alternative solution. We built a native module which combines a number of operations our virtual list view implementation requires (e.g. scrolling & repositioning items) into a single method so all of the operations are completed in the same frame.

maintainVisibleContentPosition is now in RN 0.54.


JWT-Configuration for TomEE is insufficient

Currently, if the selected MP Server is for example "Payara Micro" and there is "JWT Auth" selected in the "Examples for specifications" section, the resulting zip-File contains a resource-file "payara-mp-jwt.properties", which defines the accepted issuer.
On the other hand, if the selected MP Server is "Apache TomEE 8.0.0-M2" and "JWT Auth" selected, the resulting zip-File does not contain configuration for the accepted issuer. In this case the accepted issuer is meant to be configured in the resource-file "microprofile-config.properties". That file is already present but has only definitions for the Config-API.
In order to be tested immediately, the file "microprofile-config.properties" should already define the accepted issuer and the "publickey.location" for TomEE.

Hi @jumpingElephant,
I tried again and it seems that TomEE 8 M2 isn't checking the accepted issuer as the example is working fine. (the starter integration for TomeEE is created by TomiTribe)
Are you aware that this check will be performed in M3 or Final of TomEE 8?

The demo is now working for me. I cannot reproduce, what I did wrong the last time. So this issue seems to be cleared to me.
Even though it seems strange to me that TomEE accepts just any issuer, that can be defined in the JWTClient-class when creating the token, as long as the issuer is not defined in the properties.

@jumpingElephant
Please open an issue at the https://github.com/apache/geronimo-jwt-auth repository to make such an issuer mandatory.

After some investigation I found, that the RFC for JWT 7519 says that the Issuer Claim is optional. So, I guess this behavior is valid, even if I don't like it.

@jumpingElephant
It is not what the RFC says what it is important, but what is defined within the JWT Spec. And this is what is defined

The mp.jwt.verify.issuer config property allows for the expected value of the iss claim to be specified. A MicroProfile JWT implementation must verify the iss claim of incoming JWTs is present and matches the configured value of mp.jwt.verify.issuer.

So it seems that TomEE 8 M2 is not compliant with the MP Spec.

Hi,

so I've created an issue here https://issues.apache.org/jira/browse/TOMEE-2533 . I hope this was the right place to go.

There is an entry in the Geronimo mail archive<EMAIL_ADDRESS>which refers to a bug-issue to ensure the issuer in JWT is optional in Geronimo. Is the issuer a point in MicroProfile, where it is meant to be more restrictive, than the RFC?

Gesendet: Dienstag, 28. Mai 2019 um 16:18 Uhr
Von: "Rudy De Busscher"<EMAIL_ADDRESS>An: eclipse/microprofile-starter<EMAIL_ADDRESS>Cc: jumpingElephant<EMAIL_ADDRESS>Mention<EMAIL_ADDRESS>Betreff: Re: [eclipse/microprofile-starter] JWT-Configuration for TomEE is insufficient (#142)
@jumpingElephant
It is not what the RFC says what it is important, but what is defined within the JWT Spec. And this is what is defined
The mp.jwt.verify.issuer config property allows for the expected value of the iss claim to be specified. A MicroProfile JWT implementation must verify the iss claim of incoming JWTs is present and matches the configured value of mp.jwt.verify.issuer.
So it seems that TomEE 8 M2 is not compliant with the MP Spec.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or mute the thread.


Adding banner patterns to Netherite shields.

Describe the feature you'd like
Vanilla shields can have banner patterns added, so it only makes sense that Netherite shields could have banner patterns as well.
Describe how this feature adheres to the vanilla feel
It's literally a vanilla feature.

wait is it not working?

wait is it not working?

Nope, but I thought it was an oversight and not a bug.

Nope, but I thought it was an oversight and not a bug.

ill check it out

ill check it out

ok this is fixed in the next version

ok this is fixed in the next version


Future directions for RGBDS

Concern has been expressed towards RGBDS updates mixing breaking changes and important bugfixes. We are complying with semantic versioning, since 0.x is basically "anything goes", but in practice we have users strongly relying on our API (the three repos used as part of the test suite probably are good enough examples), so we effectively are in 1.x
Part of the problem is that even small bugfixes can be breaking. Fixing #362 caused the following to stop working (and the behavior was clearly wrong, and it fixed some other code):
list_item: MACRO
.__item\1
if (_NARG > 1)
    db .__item\2 - .__item\1
endc
ENDM

current_list_item = 0

next_list_item: MACRO
next_list_item_index = current_list_item + 1
    list_item {current_list_item}, {next_list_item_index}
current_list_item = next_list_item_index
ENDM

Possible solutions:

Bump version to 1.0.0 and start being careful with breaking changes
Create a "LTS" branch that won't get minor changes and bugfixes that have potential to break backwards compatibility
Do some pre-releases in addition to stable ones?

Why not just keep it like we're doing now except every minor version (note: not a patch version) may break the API in some manner?
Develop a "stable" branch next to the development branch for the next 0.x.0.
As for when to switch to 1.0, I don't really know, but 0.x vs 1.x means very little for this project. Could even just drop the major version.

Considering how certain large projects use RGBDS in the wild, I definitely think a 1.0.0 release makes sense. Breaking changes will be coming one way or another, so distinguishing non-breaking features from non-breaking bugfixes seems like it'll be useful for those maintainers.

@pinobatch suggested releasing the rewritten RGBLINK (#434) as an alternative linker in RGBDS 0.3.9. I'd be down for doing that, then axing it for 1.0.0 after it gets sufficient testing from 0.3.9.
The motivation for people to use the new RGBLINK would be better error messages, and maybe more.

Is that really desireable? Aren't both versions supposed to be compatible? If so, why would a user notice the difference?

They're supposed to be compatible, but given the amount of edge cases that have to be taken into account, I'm expecting bugs.

As precedent for side-by-side distribution of the stable and experimental linkers, I'd draw an analogy to a distribution that ships both the default linker of GNU Binutils and the rewritten "gold" linker. Or 2014 when Wikipedia was running a beta test of HHVM (which was then a faster PHP interpreter) for users that opted in.

That's because gold and ld have a different featureset. These are two identical linkers with the exact same featureset.
It should never be expected for a new x.x.0 version to be completely flawless, that's what the last version component is for. If there's unexpected bugs, you fix them, and publish the next patchver within the week. Here's where having a stable branch comes into play. You can't predict or test for every bug, and people can always downgrade.

There hasn't been commit activity or error reports for a month, so I'm suggesting we release RGBDS 0.3.9.
Here is the changelog I have written so far:

rgbasm:

Enforced non-overwritability of some symbols
- now allows assembling a file from stdin
Allowed PUSHS to be used before a section declaration
Prevented generating symbols with invalid names using macros
Fixed the precedence of the == operator
Added different output formats to bracketed symbols
Fixed a parsing bug with some nested if constructs
Improved error reporting now reports actual file line numbers as well as string expansions
Added multiple charmaps (be careful as some feature has been deprecated, a warning has been added about it)
Fixed bug with line numbers in some IF/ELIF/ELSE blocks
Added configurable recursion limit to prevent infinite loops
Fixed unary NOT being a no-op on constant expressions
Made behavior consistent whether outputting a .o file or not
Allowed tabs to be used before line continuations
Allowed sections without content to be placed anywhere
Make error message more explicit with macro argument 0

rgblink:

Improved many error messages

rgbgfx:

Added an option to use the GBC's color profile

other:

Added more tests
Did some internal cleanup
Improved cross-platform compatibility of test suite

Also fixed a lot more bugs and crashes in rgbasm and rgblink.

Does anyone have any objections? Unless something comes up, I will try to release by the end of the week.


Close #209: Implement login via Google

This seems to be working but definitely could use some more thorough testing.

Please add me as a reviewer when you're ready! Big change and I'll make time to review properly. :)

Will do!

According to Google we need a privacy policy in order to use their sign in. Here's some guidance on what we need to put in it: https://developers.google.com/actions/policies/privacy-policy-guide

I'm not sure how to fix the codeclimate error but I think this is otherwise good to go!

This is really good! First pass seems like everything should work. I'm going to reproduce locally and test it as well.
One question: can you delineate the data shape for a user document before and after this change? That is, can you share a sample JSON object of a user currently, and what happens to the same data when the user logs in with Google?
In an ideal world, we would:

Use the Meteor emails field, not our custom email field
Clean out the Meteor profile field and make it empty. We should use that field for user-set preferences (e.g. preferred name), and otherwise use helper functions to access the full name etc. For password accounts we should store name, profile picture etc. data here as well.
Store legacy SAML data in services.saml, and Google data in services.google.

I'm going to dig deeper into the account merging code, but in the meantime here's a reference to some similar code I wrote recently: https://raw.githubusercontent.com/athyuttamre/isotopeticketing/master/imports/startup/server/config.js?token=ABaqJpf0Q56btJUbBxsoI1Cptv9DMo-Bks5aUDZWwA%3D%3D

Do we actually need to be fully merging accounts? Right now I'm just copying roles from password accounts to google accounts with the same email. This lets us set roles via settings.json. I figured if we fully transition from SAML to Google before the spring semester starts we don't need to actually merge accounts as everyone's permissions change anyway.

After this change, you can declare a Google user with certain roles in settings.json similarly to how it was done with SAML:
{
    "email"<EMAIL_ADDRESS>    "type": "admin",
    "google": true
}

When the server starts this will create an entry like this in the database:
{
  "_id":"M3DgLFQTzi64rZ7kr",
  "emails":[
    {
<EMAIL_ADDRESS>      "verified":false
    }
  ],
  "profile":{},
  "roles":{
    "__global_roles__":[
      "admin"
    ]
  }
}

When the user first logs in this above document is replaced with the following:
{
  "_id":"3a9JkFeiu4q9x9BxN",
  "createdAt":  ISODate("2018-01-01T16:58:55.960Z"),
  "services":{
    "google":{
      "accessToken":"-hidden-",
      "idToken":"-hidden-",
      "scope":[
        "https://www.googleapis.com/auth/userinfo.email",
        "https://www.googleapis.com/auth/userinfo.profile"
      ],
      "id":"109727452202965947886",
<EMAIL_ADDRESS>      "verified_email":true,
      "name":"Gregory Carlin",
      "given_name":"Gregory",
      "family_name":"Carlin",
      "picture":"https://lh5.googleusercontent.com/-V3ITR2avDWg/AAAAAAAAAAI/AAAAAAAAAHU/7OFSSxKhql0/photo.jpg",
      "locale":"en"
    },
    "resume":{
      "loginTokens":[
        {
          "when": ISODate("2018-01-01T16:58:55.975Z"),
          "hashedToken":"-hidden-"
        }
      ]
    }
  },
  "name":null,
  "status":{
    "online":false,
    "lastLogin":{
      "date": ISODate("2018-01-01T16:58:56.224Z"),
      "ipAddr":"<IP_ADDRESS>",
      "userAgent":"Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/63.0.3239.84 Safari/537.36"
    }
  },
  "roles":{
    "__global_roles__":[
      "admin"
   ]
  }
}

Unfortunately I don't have a copy of the SAML license nor do I have access to the current VM so I don't exactly know what a SAML user looks like, but is it really relevant if we don't need to migrate/merge users?


Koa 2.x

Will need to support async await with koa 2.0:
app.use(async (ctx, next) => {
  // ...
  await next();
  // ...
});

hi @chentsulin :)
when could i use koa-graphql on koa2. please
i builded app based on koa2.
THX.

For Koa 2, use koa-convert to convert the middleware:
var koa = require('koa');
var mount = require('koa-mount'); //<EMAIL_ADDRESS>var convert = require('koa-convert');
var graphqlHTTP = require('koa-graphql');

var app = new Koa();

app.use(mount('/graphql', convert(graphqlHTTP({ schema: MyGraphQLSchema, graphiql: true }))));

@chentsulin I think it is worth to refactor this middleware to use async await, as async await landed on node 7, and the syntax is much better than generators
why do we have req and request ? - https://github.com/chentsulin/koa-graphql/blob/master/src/index.js#L100
I have a trouble with optics because of this: https://github.com/apollographql/optics-agent-js/issues/88

Sure, we definitely need migrate from generator to async await. I will work on this in the next few days.
request in koa is an abstraction on top of node's vanilla request object, providing additional functionality and it can avoid some buggy node behavior. But I reuse the getGraphQLParams function which exported by express-graphql and it only supports req (node's vanilla request object or decorated by express) so just a workaround there. Ideally we should use request everywhere.


Include Python Versions in Documentation

I noticed this set of tables on the Pillow installation page, and I'd like to replicate it in our documentation.
https://pillow.readthedocs.io/en/stable/installation.html

"SnakeMD at its core is a dependency-free markdown generation library. As a result, you shouldn't have to concern yourself with issues that can arise due to dependency conflicts in your environments. However, SnakeMD is a Python library and is constrained by the various versions of Python. To help you navigate this, the SnakeMD documentation includes tables of Python support as seen below. Make sure to always install a version of SnakeMD that is tested for your version of Python."


[BEAM-10761] Prefer TestPubsub#assertSubscriptionEventuallyExists when waiting to inject data

Renamed TestPubsub#checkIfAnySubscriptionExists to TestPubsub#assertSubscriptionEventuallyCreated (original is still there and marked deprecated), and updated the docstring.
Use TestPubsub#assertSubscriptionEventuallyCreated everywhere that TestPubsubSignal was being used to block before injecting data into a pubsub topic.

GitHub Actions Tests Status (on master branch)

See CI.md for more information about GitHub Actions CI.

Run Java PostCommit

Run SQL PostCommit

Run Java PostCommit


concentration of 5-formyltetrahydrofolic acid in plant structure

This concentration points to CHEBI:15640 - 5-formyltetrahydrofolic acid, but it seems like the hasDbXrefs are coming in at too broad a level. Can the INFOODs and USDA_NDB tags be associated with concentrations at a more granular level? Is it really the case that multiple ones are correct for 5-formyltetrahydrofolic acid? Ideally INFOODs and USDA_NDB are only 1-1 DB Xrefs.

Hi @ddooley, I'm so sorry for my delayed reply I didn't get a notification, I will check what's wrong.
Thanks for finding this it's an error, it should have been associated only to USDA_NDB: 1192 and not to all the other cross-references, I will check what was wrong and create an update at the end of this month.

@ddooley I have some questions about this issue but before that, I just wanted to let you know that the new release will have the changes for this mistake, now 5-formyltetrahydrofolic acid is only associated to USDA_NDB: 1192.
For the granular level of tagnames from USDA/INFOODs, I associated the term 'concentration of carbohydrate' to the following code numbers from USDA:
1005	Carbohydrate, by difference
1050	Carbohydrate, by summation
1072	Carbohydrate, other
Do you think it would be better to only associate it to "1072" "carbohydrate, other"?

@ddooley what's your opinion about it? If you think is ok I will close this issue. Otherwise we can ask people from INFOODs and USDA?

So the 'concentration of carbohydrate' would be a generic ontology class that wouldn't commit to how that concentration was analyzed. Under it we'd place subclasses for 1005, 1050, and their 1072 ("Carbohydrate, other" which in their semantic translates to "neither by difference or summation").  'concentration of carbohydrate' wouldn't technically map to any USDA codes directly.  A question is whether USDA wants to add a generic 'concentration of carbohydrate' code to their flat list to indicate unspecified analytic method, but that probably wouldn't be used by them, so rather useless on their side.

@Graham-J-King What do you think? I think this might be something related to the Analytical methods class?

@LilyAndres @ddooley
My thoughts: I think we have to be careful in the tagging process where they may be one-to-many or many-to-one relationships inherent. I would think most people see a tag associated and assume a one-to-one relationship. There is a need for some association of evidence trail or relationship to be declared, as xrefs can get very messy to manage and lead AI astray.


Features/update nn model

Update Recommendations
Location

data/models/nearest_neighbors
separated info to labs 1 and 2
nn.ipynb
final.csv

Details

used updated merged csv to update recommendations with new data points
ran on numeric columns (most string/object columns are summaries of numeric columns)

Committed Features
Users will now have updated recommendations for similar cities to include new data points of walk, bike, bus scores and school summaries

 DS will update recommendations to include new features.

 DS will create endpoint that shows rental predictions.


Quick question about debugging Typescript version

This web version is pretty hell to debug in the console because first transpiled es6 and ts, and the through react native modules. Or is it anything one can do to better that?

I found a few things that might help:

https://code.visualstudio.com/docs/typescript/typescript-debugging
https://blog.fullstacktraining.com/debugging-typescript-in-the-browser/
https://medium.com/@dupski/debug-typescript-in-vs-code-without-compiling-using-ts-node-9d1f4f9a94a
https://www.google.com/search?q=debug+transpiled+typescript

I should get around to doing this but I don't have the time currently. If you can get it working please do send a PR :)

@vongohren Do you have a sample repository or sample code that is "hell to debug" using this starter? I'd love to recreate what you see and try to create a PR for this issue.

@AryanJ-NYC hey, no sorry, I believe its all cleaned up unfortunately. This is a bit too long ago for my repos and local code.
But I believe it was pretty basic initialization with typescript.
It is clear when you do remote debugging and try to do breakpoints or understand what line the code points to.
Sorry I could not help more :(


Incompatability with Sodium, Animatica, & Enhanced Block Entities

As seen in this reddit, I troubleshooted: https://www.reddit.com/r/fabricmc/comments/1h59bdd/could_not_execute_entrypoint_stage_client_due_to/
When I launched Fabric MC 1.21.1 with Bewis + sodium animatica & EBE, it crashed. Removed Animatica & EBE, still crash as seen in reddit post.

So I usually play with sodium and for me it works, but let me see if I can do something about your issue

Ok so I looked at your crash report and It looks like it is a problem with the mixin for the block outline. I can do something about, but I will not release a new version for 1.21.1, but It will be fixed with the 1.21.4 version


Pre wrapped in div has extra paragraph inserted

Take a look at this example
Is this expected behavior? It seems that when a <pre> is not a direct child of root, markdown-it doesn't treat the code inside of it as pre text. Instead, it gets an empty paragraph.

commonmark dingus At least, reference implemantation has the same problem. May be worth to ask here https://github.com/jgm/CommonMark/issues.
But keep in mind, that commonmark is not very friendly about empty lines in html blocks. See spec. Even if you fix somehow this example, you will not fix all such problems.

Good point. I fixed my example by moving my <pre> on a separate line, and that worked. I was just surprised because Commonmark describe the <pre> as special which made me think that it's actually parsing the HTML to figure out where to allow empty lines. But I guess it's only if the pre is first on a line.

Yeah, div on separate lines is ok
Anyway, i'd suggest to close issue here as spec-related. You can rise this question in spec repo (if needed), and if spec will be updated, markdown-it will follow very soon.
Also, i'd suggest to override fenced block renderer, to have custom look for special names. That will eliminate the need to use html at all. Of cause, i don't know your goals and can not guarantee it will be good for you. But if you describe your needs, i'll try to help.

Thx!


[Bug]updated traces and services tests with new refresh button

Description
Fixed services and traces failing tests
Issues Resolved
[List any issues this PR will resolve]
Check List

[ ] Commits are signed per the DCO using --signoff

By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

observability workflow failed, could you please add successful test results?


Raven is not configured

When loading the Redux Raven Middleware as described the console says:
Error: Raven has not been configured.
When trying to initialise Raven from the same console it says it's already configured:
<EMAIL_ADDRESS>{}).install();

Error: Raven has already been configured
I tracked down the afterLoad function doesn't know of window.RavenConfig .. could this be a clue as to what's wrong?

Ok, so it seems it does actually log exceptions to Raven, including state and all the goodness. Just odd the message shows up. I'll try putting it up online somewhere to see if it could be related to local development.

Do you have raven-js installed already? Maybe it's unintentionally bundling two copies. I might need to make this lib use peerDeps.

You could be on to something .. npm list gives, after the tree:
`npm ERR! extraneous<EMAIL_ADDRESS>/Users/........./node_modules/redux-raven-middleware``

I am getting this issue as well, I'll get around to it some time.
If the bug is an error that occurs before Raven is initialize, maybe queue it until Raven is initialized.


Separate IDs and names

We should generate IDs for pods/containers as primary keys instead of their names.

What would happen if someone tries to create twice a container named the same? But probably different config?

We will probably need a lookup table for names to tell fastly it's duplicate and stuff like these..

Yeah the namespace would be different in meta.

On Sep 18, 2016, at 11:30 AM, Antonio Murdaca<EMAIL_ADDRESS>wrote:
What would happen if someone tries to create twice a container named the same? But probably different config?
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub, or mute the thread.


get_io_service deprecated and then removed in boost 1.70

get_io_service deprecated and then removed in boost 1.70
https://github.com/rstudio/rstudio/issues/4636

The previously deprecated get_io_context and get_io_service member functions have now been removed.
The previously deprecated service template parameters, and the corresponding classes, have now been removed.
Added a new async_result form with an initiate static member function.

Looks like .get_executor().context() should be used instead, and most usages of io_service should become io_context.

https://stackoverflow.com/questions/56327920/how-to-get-the-io-context-from-a-strand-in-boost-1-68

The following appears to fix issues. Works w boost 1.72
Replace  io_service  with  io_context
Replace calls to get_io_service() with get_io_context()
The following works with the changes.
async_connect
async_query
Cannot get the following to compile. Something with the placeholders it seems
async_store_result

serial_port does not contain a get_io_context() using io_context instead of io_service.
This has beautifully broken my current project. Now I need to figure how to sort this or go back to previous boost version.

Try my fork at https://github.com/adrianboston/amy
It works with the deprecated and removed io_service.
It conforms to the current ( 1.73 ) boost asio and from versions roughly 2 yrs ago according to the following issue:


v0.6.0

Changelog:

✨ Added conversion to <amp-youtube> for iframes with YouTube src attributes

Coverage remained the same at 100.0% when pulling 08eca4f312217a95b2d78a3ed9b25806cc79e0b7 on kevinansfield:v0.6.0 into a9444d63d7b0b8ca406a4118134ce130401cf417 on jbhannah:master.

Coverage remained the same at 100.0% when pulling 08eca4f312217a95b2d78a3ed9b25806cc79e0b7 on kevinansfield:v0.6.0 into a9444d63d7b0b8ca406a4118134ce130401cf417 on jbhannah:master.


Rocket NGINX fixes Expires: max issues, however, files are still showing "File not cached"

HTTP/1.1 304 Not Modified
Server: nginx
Date: Mon, 11 Jul 2016 18:27:20 GMT
Last-Modified: Wed, 06 Jul 2016 21:17:06 GMT
Connection: keep-alive
ETag: "577d7552-162b"
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000
X-Rocket-Nginx-Bypass: No
X-Rocket-Nginx-Reason: File not cached
X-Rocket-Nginx-File: /home/theupbeatk9/public_html/wp-content/cache/wp-rocket/theupbeatk9.com//wp-content/uploads/2016/06/upbeat-k9-logo.png/index-https.html_gzip
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block

Currently using:

NGINX 1.10.1
PHP 7.0.7
PHP-FPM
WordPress 4.5.3
WP-Rocket 2.8.8

It seems like this is a request for an image, right ?  If so, images are not cached by Rocket-Nginx so that would be normal.  Rocket-Nginx simply adds headers to make the browser cache them.  As per your headers, it seems like it's working fine:
Expires: Thu, 31 Dec 2037 23:55:55 GMT
Cache-Control: max-age=315360000

So yes, Rocket-Nginx that did no cache it.  The browser did though.  It is the right behaviour.
Can you confirm your request's headers is for an image ?

@maximejobin Yes, that was for an image. However, even when I check a CSS or JS file, or any file for that matter it's never showing X-Rocket-Nginx-Bypass: Yes
HTTP/1.1 304 Not Modified
Server: nginx
Date: Mon, 11 Jul 2016 18:46:01 GMT
Last-Modified: Wed, 06 Jul 2016 21:16:04 GMT
Connection: keep-alive
ETag: "577d7514-ad51"
X-Rocket-Nginx-Bypass: No
X-Rocket-Nginx-Reason: File not cached
X-Rocket-Nginx-File: /home/theupbeatk9/public_html/wp-content/cache/wp-rocket/theupbeatk9.com//wp-content/themes/Divi/js/custom.js?ver=2.7.8/index-https.html_gzip
X-Frame-Options: SAMEORIGIN
X-Content-Type-Options: nosniff
X-Xss-Protection: 1; mode=block

Images, CSS and JS files are not cached by Rocket-Nginx.
Only HTML pages (WordPress pages, posts, custom post types) are.
I checked your homepage and it did not trigger Rocket-Nginx to server the file.  My question is: Can you list all the files in the following directory /home/theupbeatk9/public_html/wp-content/cache/wp-rocket/www.theupbeatk9.com/ ?

@maximejobin
 tree
.
├── 2016
│   └── 07
│       ├── the-upbeat-k9-expanding-to-south-west-florida-as-the-program-launches-in-naples
│       │   ├── index-https.html
│       │   ├── index-https.html_gzip
│       │   ├── index-mobile-https.html
│       │   └── index-mobile-https.html_gzip
│       └── where-do-you-find-your-motivation
│           ├── index-https.html
│           └── index-https.html_gzip
├── blog
│   ├── index-https.html
│   ├── index-https.html_gzip
│   ├── index-mobile-https.html
│   └── index-mobile-https.html_gzip
├── category
│   ├── general
│   │   ├── index-https.html
│   │   └── index-https.html_gzip
│   └── press-release
│       ├── index-https.html
│       └── index-https.html_gzip
├── contact-us
│   ├── index-https.html
│   ├── index-https.html_gzip
│   ├── index-mobile-https.html
│   └── index-mobile-https.html_gzip
├── index-https.html
├── index-https.html_gzip
└── locations
    ├── boston-massachusetts
    │   ├── index-mobile-https.html
    │   └── index-mobile-https.html_gzip
    ├── index-https.html
    ├── index-https.html_gzip
    ├── index-mobile-https.html
    ├── index-mobile-https.html_gzip
    └── naples-florida
        ├── index-mobile-https.html
        └── index-mobile-https.html_gzip

12 directories, 28 files

Did you alter the script in any way ? (even a suggestion made by the WP-Rocket team... like commenting a line or anything else.)

Because I think you checked the "mobile" cache in WP-Rocket.  So, if you did that, maybe you also edited the script as suggested by them to get around a bug with mobile cache in Rocket-Nginx.

I did enable the mobile cache in WP-Rocket and as per http://docs.wp-rocket.me/article/663-mobile-cache-desktop-view-displayed-for-mobile-devices I made the change to line 23.
https://github.com/maximejobin/rocket-nginx/blob/master/rocket-nginx.conf#L23
I've now removed that change and set it back to 1.
Please advise, thanks.

2 things here:

By commenting the line, you'll never see the "Yes" you are looking for.
By NOT commenting the line, you won't get the cache working for both mobile AND desktop.

The reason is that Rocket-Nginx cannot detect correctly if it's a mobile or not.  I am working on a fix for that.
If your site is reponsive (which looks like it is), you do not need to activate the "mobile cache".  Please check if the website looks the same with and without the option checked.  If it is the same, don't check this checkbox and you'll get the "Yes" for the Bypass.

Inside of WP-Rocket are you referring to the option Enable caching for mobile devices or Create a caching file for mobile visitors?
Currently I have the following set in WP-Rocket:

[x] Enable caching for mobile devices.

[ ] Create a caching file for mobile visitors.

Line 23 is set to 1 in rocket-nginx.conf

Ok, that way, you are good.  Simply leave the rocket-nginx.conf as is (without commenting a line) and you should get a "Yes".

I checked your homepage and I confirm.... it works! :smiley:

Thanks @maximejobin


Update README.md

Didn't see this before I created some conflicts, plus I wanted to retain the routing to demonstrate that the WebSocket can be a portion of a larger application.
Fixed example for v2.0.0-rc2 in readme with ed408970287bd710a35f1d110005a18c39dab987.
Thanks for the contribution though!


[T5A3][T11-A2]Joshua Ching

Accepting this PR without a review because another of your PRs for this tutorial was reviewed in detail.


Miscellaneous StreamMessage improvements

Change the return type of SubscriptionImpl.executor() to EventExecutor
Make DefaultStreamMessage.demand non-volatile
Make sure 'inOnNext' is reset to false even if Subscriber.onNext()
raises an exception
Simplify doRequest()
No noticeable performance regression or improvement

Thanks!


Javadocs and import cleanup

Looks good but we need the same pull request on the spec side :)

ok


support for validating unknown fields

Signed-off-by: Balaji Vijayakumar<EMAIL_ADDRESS>

With this one problem i see is we are getting some unintended warnings like,
INFO[0000] Using the existing instance "vz"
WARN[0000] Ignoring: vmType vz: [CPUType Firmware Video]
WARN[0000] Ignoring: vmType vz: mounts[0]: [SSHFS NineP]
WARN[0000] Ignoring: vmType vz: mounts[1]: [SSHFS NineP]

Is this okay to have like this ?? Any pointers ??
One way i could think of is to use pointer and handle null checks accordingly.


TabExpansion puts a small error in $error

If you import PoshRSJob and check $error[0] you'll find this:

Get-Variable : Cannot find a variable with the name 'Options'.
At ...\PoshRSJob\Scripts\TabExpansion.ps1:20 char:11

If (-not (Get-Variable -Scope Global -Name Options -ErrorAction:Silen ...

It's not an error, of course. But if you wanted to avoid putting extraneous stuff into $error you can do the check in a different way; with Get-Variable -Scope Global | Where { $_.Name -eq "Options" }.

Fix is in queue for the next version update.


[plot] Unselect active curve when clicking on empty space

This PR allows to unselect active curve with a left click in empty area of the plot.
It does not interfere with drag operation
closes #1612

It seems to be working.


Prefix controllers and services

Just aggregating all the issues that would be resolved when we get to this task. This is related to #157 but not exactly the same issue. We can do this task before we get to resolving #157.
This should be a non-breaking change for majority of users and a minor inconvenience for the few that are depending on the services declared.
Root cause of #3302, #2458, #1753

So we've pretty much decided on using a prefix of uib- for directives and uib for controllers and services.

would it be uibAccordionController then? (as an example)

@wesleycho I think the prevailing style guide has controllers named with the leading character capitalized, i.e: UibAccordionController.

That makes sense.

I initially intended uibAccordionController, but I'm completely open to this. If there's a prevailing style guide, let's go with it.

Those who use the older versions should also see a $log message mentioning that the old usage is deprecated. Use of $compileProvider.directive and $provide.factory (and similar) should be useful for defining the old names.

Guys,
Can anyone please update what is the real problem here?
I have nearly broked the leg of my chair from laughing - so true:
https://github.com/angular-ui/bootstrap/issues/1994
:laughing:
Beside my own issue https://github.com/angular-ui/bootstrap/issues/2581 over half year ago, there is a whole sophisticated network of highly interlinked discussions on that matter. If I could export it to a nice graph diagram, I would sell it to an important art museum :smile:
This is a top public repo on Github and 2nd to Angular's original one to whoever is using Angular and that issue seems to be most frequently discussed, causing all sort of annoyances, pushing people away from the project and even from Angular. Yet this issue(s) is(are) dragging for over 2 years at least.
Can anyone please explain why and what is it that holds it back and clarify what kind of help is needed?
Any plans to open a branch dedicated to this issue/milestone/nicetohave/annoyingnottohave... ?

@dmitriz You can see its been scheduled for 1.0.0.

@dmitriz as said before me it is indeed planned for v1.0.0. The reason we didnt make this a higher than 1.0 priority is mainly due to two things:

Make it work first. We have hundreds of PRs and issues related to functionality/bugs
Its a boat load of work as you can imagine. That shouldnt be a reason but given the limited time we all have available to spend on this project, this can be an issue.

Im confident that this will be tackled in the upcoming months rather than years though. We have a new team of maintainers and lots of issues and PRs are being closed and merged every day now.
:+1: bear with us!

I welcome PRs on this issue to speed things along but be aware that it might need some rebasing later.

Thanks for the update!
Unless I am overlooking something, a simple job would be:

Add names to the anonymous functions defining directives.
Additional prefixed directives declarations linking to those functions.

That would allow both custom prefixed and un-prefixed versions.
Would that not do it?
Am I too naive? :)

This change isn't referring to directive prefixes, which is in #157 . This change is to ensure that controllers, services, constants, anything we declare on the module (except directives) must be prefixed.
For example, in https://github.com/angular-ui/bootstrap/blob/master/src/tabs/tabs.js, the TabsetController will now be UibTabsetController. Note that the references to the controller, in the tabset directive need to be changed as well.

Should we try introducing a style guide as well?  Todd Motto and John Papa have published a couple that do a good job of explaining the how and why of their recommendations.

Sorry for the confusion and thanks @chrisirhc for clarification (I am sort of lost in the interlinked network :)
So here is a proposal (hopefully in the right issue :) that looks simple to me:

Create a dedicated "prefixed" branch for all the work on prefixes.
Manually add prefixes to all internal controllers and services.
Release prefixed versions as 1.0.x-prefixed-prereleased or something like that.
Write clear explanation what this prerelease is and how to use it.

Am I proposing to maintain two separate releases?
No! It should suffice to clearly declare it as unstable prerelease meant for folks who know what they are doing. Plus invite them to rebase onto more recent bug fixes and submit PR if they want to.
Occasionally we may rebase and update the release ourselves. I imagine this can be completely automated, e.g. Mr. Travis can do it for us :)
What about folks who use those controllers in their code?
Since these are not officially documented, that would be again folks who know what they are doing. Probably a small percentage of users. They have the options:

keep using current version and do nothing;
switch to the prerelease version and update their code, likely in very few places.

Further suggestions

Decide on which controllers and services are encouraged to be used and which are not.
Document all of them meant for public use.
Prefix with $ all the others and state clearly that they are for internal use.

We will continue in #4373. We decided how to do it and we just need to work on it.


@cython.trashcan directive to enable the Python trashcan for deallocations

Fix #1354
This enables a @cython.trashcan directive which can enable using the Python trashcan for deallocations. This is optional, disabled by default (but one could argue about making it enabled by default).

Concerning testing: it's hard to test that the trashcan is not used: the only observable effect is a stack overflow (typically leading to a segmentation fault).

Actually, it spoke too quick: the order of deallocations between base class and subclass is different, so trashcan usage can be detected.

PyPy doesn't use the trashcan (it supports the Py_TRASHCAN macros as no-op). So disabling them in Cython under PyPy is the right thing to do.

I think that I took care of all your comments.

Perfect! I'll merge it right away to avoid bit-rot, because it is a clear improvement over not supporting the trashcan mechanism at all. If the CPython devs decide that they want thing different, we can adapt to it on our side later.

Thanks! Should I take care of docs and changelog?

Please do. :)

I finally took the time to understand this, and not that it matters (since this is already merged), but this makes sense to me now and I agree that it's useful to be able to (re-)use this mechanism when implementing Cython types. Thanks!
My thinking had been that it should be possible to re-implement something like this specifically for cypari, and while it could be done it would be much more of a PITA, when we can reuse the mechanism that's already there in the Python interpreter for exactly this purpose.

IIUC it should be possible to use this also without the additional feature in Cython, but it's certainly cleaner this way.


postgres: listen_addresses no longer sets PGHOST

Describe the bug
After updating from devenv 1.0.2 to 1.0.8 we could no longer connect to our database during CI tests. After extensive debugging (mostly because I knew nothing about PGHOST) it was determined to be caused by this change
git diff v1.0.7..v1.0.8 src/modules/services/postgres.nix
diff --git a/src/modules/services/postgres.nix b/src/modules/services/postgres.nix
index 7e8584c..183aff5 100644
--- a/src/modules/services/postgres.nix
+++ b/src/modules/services/postgres.nix
@@ -282,10 +282,7 @@ in
     packages = [ postgresPkg startScript ];

     env.PGDATA = config.env.DEVENV_STATE + "/postgres";
-    env.PGHOST =
-      if cfg.listen_addresses == ""
-      then runtimeDir
-      else cfg.listen_addresses;
+    env.PGHOST = lib.mkDefault runtimeDir;
     env.PGPORT = cfg.port;

     services.postgres.settings = {

In our CI it never quite worked until I set listen_addresses to "<IP_ADDRESS>", although I did not quite understnad at the time why
To be honest, I think how we fixed it merely worked around a different issue. The issue being that we run our CI on NixOS github runners which has a particular runtimeDir which is then overridden when we use devenv shell within that same environment. This manifests itself in the sense that psql works during devenv process but at some point the PGHOST (or runtimeDir) is changed again
from memory, /var/run/1000/devenv/something_socket vs /tmp/devenv/something_socket
the current 'fix' I have now is setting
if System.get_env("CI") == "true" do
  System.put_env("PGHOST", "<IP_ADDRESS>")
end

in our runtime config. Which should speak for itself
Anyway, this still raises a different question as to why is PGHOST currently 'hardcoded' or even set at all, with no clear way to override. Could it be that the previous code was better? Apart from the listen_addreses = "*" issue I believe was the cause of this change?
Version
1.0.7 and 1.0.8

@DGollings, PGHOST is there as a default to help tools connect to the database. Perhaps we need to parse listen_addresses after all to set this properly.
But I'm surprised to hear that the socket directory doesn't work for you. I wonder if it's because of the systemd service or the runner. For example, It might be a sign that we need to detect and use RUNNER_TEMP when setting up our temporary directories.
It's tough for us to document these things right now, because it's just an env var. We'll soon have a place to do so per service, language, etc.
cc @k3yss

what makes PGHOST special is that if set the driver uses that, pretty much disregarding other options/settings/parameters afaict
which makes setting it from devenv without being able to override it (easily) a little problematic :)
It is however true that the root issue is likely the whole systemd -> runner -> devenv shell combo, and something somewhere in the tmp directories changing. How can I help debug this? Some strategically placed echos are likely useful, where would you like to see some?

which makes setting it from devenv without being able to override it (easily) a little problematic :)

{ pkgs, lib, config, inputs, ... }:

{
 services.postgres.enable = true;
 env.PGHOST = "custom-pg-host";
}

I can easily override it like this, does this not work for you? While sending the patch you mentioned before I was expecting people to change their PGHOST in a similar manner.

You might be over estimating the average nix user. Was not aware that that would override the other value.
Also, it feels unintuitive to change so 'outside' of the services and postgres context.
Also, you'd have to know that many drivers use that value and that it's being set in the first place by devenv.
But thanks, good to know, it'll make it easy to remove my workaround :)

You might be over estimating the average nix user. Was not aware that that would override the other value.
Also, it feels unintuitive to change that 'outside' of the services and postgres context.

I am working on the new documentation here to resolve this exact issue, we can include a small guide in it on how to use postgres with devenv : )

Also, you'd have to know that many drivers use that value and that it's being set in the first place by devenv.

The default value that we are setting for the PGHOST is based upon the Official Postgres documentation, I find it a bit strange that drivers that you are mentioning are expecting <IP_ADDRESS> as the value, but since the POSTGRES documentation mentions to use the unix socket I don't really see a reason to change it.

The default value that we are setting for the PGHOST is based upon the Official Postgres documentation, I find it a bit strange that drivers that you are mentioning are expecting <IP_ADDRESS> as the value, but since the POSTGRES documentation mentions to use the unix socket I don't really see a reason to change it.

Oh no, there's two issues here. One being PGHOST and all we've discussed so far regarding defaults and discoverability.
But the other issue is that your default, and I believe you if you say it's a good default, for whatever reaso, does not play nicely with systemd and devenv shell combined (we think)
As mentioned, I'd be happy to help debug?

As mentioned, I'd be happy to help debug?

That would be awesome! I don't have any experience with systemd, but if you could provide detailed steps on how to create a reproducible setup of the problem and share some logs, I'd be happy to take a look.

what makes PGHOST special is that the driver uses that if set, pretty much disregarding other options/settings/parameters afaict
which makes setting it from devenv without being able to override it (easily) a little problematic :)
It is however true that the root issue is likely the whole systemd -> runner -> devenv shell combo, and something somewhere being changed regarding the tmp directories by something. How can I help debug this? Some strategically placed echos are likely useful, where would you like to see some?
* before devenv (`ci.yaml`)

* pre setting up service (`devenv.nix`)

* post setting up service (`devenv.nix`)

* within `devenv shell`

* env as seen from within application?

?

As mentioned, I'd be happy to help debug?

That would be awesome! I don't have any experience with systemd, but if you could provide detailed steps on how to create a reproducible setup of the problem and share some logs, I'd be happy to take a look.

Sure, how does this sound? https://github.com/cachix/devenv/issues/1374#issuecomment-2282705206

What I want to know is the step before these, specifically how to provision the CI environment locally and the steps how I would reproduce the error.

If you happen to run NixOS it should be easy enough to set up your own version of this:
github-runners = {
      runner = {
        name = config.networking.hostName;
        user = *youruser*;
        enable = true;
        replace = true;
        url = "redacted";
        tokenFile = *github token runner file*;
        extraPackages = with pkgs;
          [
            devenv
            bash
            # any other dependency you might want to add
          ];
        extraEnvironment = {
          NIXPKGS_ALLOW_UNFREE = "1";
          JAVA_HOME = "${pkgs.openjdk}";
        };
        serviceOverrides = {
          ProtectProc = "default";
          ProtectSystem = "full";
        };
      };
    };

if not, the above pretty much is a systemd service, which you could install like this
As to how to reproduce in more detail, these steps work:
  processes = {
    phoenix.exec = ''
      # sets up db automatically
      until psql -U "postgres" -c '\q' 2>/dev/null; do
        sleep 1
      done

      mix ecto.setup
      mix phx.server
    '';
  };

These are run by devenv itself within the systemd environment
neither psql nor ecto.setup error. The former being postgres cli and the latter the same Elixir Postgres driver that I have referenced before
What does not work is this:
      - name: Build the devenv shell and run any pre-commit hooks
        run: devenv shell mix check

which is running the same Postgrex/Ecto-like code as in mix ecto.setup but within a 'new' context/shell/env (being devenv shell)


Cifuzz dev

What changes this PR introduces
Docker image modification

The base docker image was changed to ubuntu 2204 as it is more stable and cross compatible due to stable
glibc version.

Mock and utility introduction

Added some mocks for libevent functions to execute events in blocking mode during fuzzing.
Added some utilities for ca fuzzers to copy certificates from /etc/iked/ to current directory because normally, the ca process runs in a chroot jail in /etc/iked and this is not optimal to do during fuzzing.

Fuzzer and env update

Updated fuzzers to use the mocks and ca fuzzers to use key setup and ca configuration functions
Updated env creation and cleanup by initializing the event creation and destruction to avoid false positive segfault crashes.

LGTM


storage: Add invocation-id to x-goog-api-client header for c# storage

Tracking ticket to add a unique invocation-id to the x-goog-api-client header for all Storage API requests.
See nodejs  example

@Rishabh-V: We'll need to work out how to integrate this with GAX (which populates the x-goog-api-client header). I'm not thrilled about this being within that header to be honest, but we'll see...

Sure @jskeet


Update moment tensor images

Since https://github.com/geophystech/seismo-api/issues/10 is done the client should be updated to get the correct URL from the response.
And let's use SVG version. :slightly_smiling_face:

It's blocked until https://github.com/geophystech/seismo-api/issues/10#issuecomment-374831453 is fixed.


Run manifest check only aganist the changed manifest

Description
Run manifest check only aganist the changed manifest
Issues Resolved
closes https://github.com/opensearch-project/opensearch-build/issues/4075
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.
Testing Screenshots:
Getting list of changed files in 'manifests/**/*.yml'

Running manifest-checks-jdk11  jobs:

Hey @hitenshKharva ,
Thanks for the PR. This will save us a lot of resources and time. Were you able to test this workflow?
You can do that by raising a pull request against you branch enhancement/Run-manifest-check-only-aganist-the-changed-manifest. The PR can be adding a a dummy component to any 1 manifest file. Click on actions and see that only checks run only for that manifest unlike https://github.com/opensearch-project/opensearch-build/actions/runs/6424012688/job/17443911911

hello @gaiksaya
I tried testing it but I guess I am still facing some issues with it. Trying to figure a way out creating a pull request on my branch as discussed.

Changed the PR title to match the exact change.

Hi @hitenshKharva I see push as a trigger too. Can you try merging your test PR in your fork for which you posted above snippets. Not sure if files changed will be grabbed for push as a trigger.
If not we can remove that I believe, WDYT @prudhvigodithi @peterzhuamazon ?

Yes @gaiksaya  we can remove the push trigger, here is the example one https://github.com/opensearch-project/opensearch-build/actions/runs/6511391743 that was triggered after the code is merged to main which is not required as we have one on raising a PR pull_request. Thank you


update actions to publish with code sign

Pull Request
📖 Description
This will implement publishing to NuGet using GitHub Actions, instead of or in addition to, Azure DevOps.  Initially, we needed Azure DevOps while we figured out the Code Signing piece of the equation Microsoft requires.  Now that is figured out we can try and incorporate that back into GitHub Actions and have all code in one place.

🎫 Issues

👩💻 Reviewer Notes

📑 Test Plan

✅ Checklist
General

[ ] I have added tests for my changes.
[ ] I have tested my changes.
[ ] I have updated the project documentation to reflect my changes.
[x] I have read the CONTRIBUTING documentation and followed the standards for this project.

Component-specific

[ ] I have added a new component
[ ] I have modified an existing component

⏭ Next Steps

I don't know how we can add a connected service name when publishing with Github. On ADO, we have a connected service name that is FAST-NuGet-Publishing-SC. if we use the same, it won't work.


Fix 200630

This request fixes incorrect calculation of the energy; energy reporter and enstrophy reporter. The values saved by the reporter are converted directly to physical unity.

@McBs I will have a look once all tests pass


spring.cloud.config.retry.useRandomPolicy not being applied

I see in https://github.com/spring-cloud/spring-cloud-config/pull/2353, that support was added for the spring.cloud.config.retry.useRandomPolicy property. However, it's not actually being applied when I run one of our ConfigServer clients.   (I observed this by adding a break point in RetryProperties,isUseRandomPolicy(). It's never being called. Note that we have spring.config.use-legacy-processing=true.
Analysis: The retry appears to be configured in ConfigServiceBootstrapConfiguration.configServerRetryInterceptor. In spring-cloud-config-client-4.0.5.jar, I see that the RetryInterceptorBuilder is not calling the retryPolicy builder method. Was that a miss in the above-mentioned PR?

Yeah I think you are right.  You are using bootstrap configuration then and not leveraging spring.config.import?

Yeah I think you are right. You are using bootstrap configuration then and not leveraging spring.config.import?

Yes, that's correct.