Proposal: don't pluralize metric namespaces

There are two reasons behind this proposal:

To create less ambiguity when naming new metrics
I think it creates slightly better attribute names (when sharing the metric namespace), e.g.

system.process.status (vs system.processes.status)
jvm.thread.state (vs jvm.threads.state)

This would affect these metrics names:

system.processes.count -> system.process.count
system.processes.created -> system.process.created
db.client.connections.* -> db.client.connection.*
jvm.threads.count -> jvm.thread.count
jvm.classes.count -> jvm.class.count

It may also affect these metrics if we decide to add .count (or .usage) to them:

process.threads -> process.thread.count
process.open_file_descriptors -> process.open_file_descriptor.count

I think a year ago we decided to move this direction.  See the updated pluralization rules in the spec: https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/metrics/semantic_conventions/README.md#use-count-instead-of-pluralization
We should just clean up the specification of ambiguity of this topic.

Can you please list all impacted metric names? Or maybe if it is easier just prepare a draft PR with all name changes. I think seeing all names would help better understand the impact.

@tigrannajaryan I've closed the initial PR which expanded the scope to both metric namespaces and metric names, and opened a fresh PR that limits the scope to this issue only, which applies only to metric namespaces (and not metric names).
this issue affects the following metric namespaces:

jvm.threads.* -> jvm.thread.* (#252)
jvm.classes.* -> jvm.class.* (#252)
db.client.connections.* -> db.client.connection.* (#259)
system.processes.* -> system.process.* (this should probably be bundled into other breaking system metric changes, e.g. https://github.com/open-telemetry/semantic-conventions/pull/89#pullrequestreview-1516461871)

Renaming system.processes.count (Total number of processes in each state) to system.process.count sounds ok to me, but renaming system.processes.created (Total number of created processes) to system.process.created makes the name less descriptive and a bit confusing IMO. Maybe we should consider a different name if we avoid pluralized namespaces.
I'd also suggest bringing metrics currently emitted by Collector receivers but not defined in the semantic conventions. There must be plenty of them with pluralized namespaces. Maybe they can influence this decision. I can do that exercise if it makes sense

I checked the collector receivers. Most of the exposed metrics don't have pluralized namespaces. But there are still a few of them with pluralized namespaces. I'll put all of them here with their description for the full context:
Kubelet stats receiver:
- `container.pids.count`: Number of pids in the container's cgroup
- `container.pids.limit`: Maximum number of pids in the container's cgroup

Elasticsearch receiver:
- `elasticsearch.node.operations.current`: Number of query operations currently running
- `elasticsearch.node.operations.completed`: The number of operations completed by a node.
- `elasticsearch.node.operations.time`: Time spent on operations by a node.
- `elasticsearch.node.operations.get.completed`: The number of hits and misses resulting from GET operations.
- `elasticsearch.node.operations.get.time`: The time spent on hits and misses resulting from GET operations.
- `elasticsearch.node.shards.size`: The size of the shards assigned to this node.
- `elasticsearch.node.shards.data_set.size`: Total data set size of all shards assigned to the node. This includes the size of shards not stored fully on the node, such as the cache for partially mounted indices.
- `elasticsearch.node.shards.reserved.size`: A prediction of how much larger the shard stores on this node will eventually grow due to ongoing peer recoveries, restoring snapshots, and similar activities. A value of -1 indicates that this is not available.
- `elasticsearch.node.thread_pool.tasks.queued`: The number of queued tasks in the thread pool.
- `elasticsearch.node.thread_pool.tasks.finished`: The number of tasks finished by the thread pool.
- `jvm.classes.loaded`: The number of loaded classes
- `jvm.gc.collections.count`: The total number of garbage collections that have occurred
- `jvm.gc.collections.elapsed`: The approximate accumulated collection elapsed time
- `elasticsearch.node.ingest.documents.current`: Total number of documents currently being ingested.
- `elasticsearch.node.ingest.operations.failed`: Total number of failed ingest operations during the lifetime of this node.
- `elasticsearch.node.pipeline.ingest.documents.preprocessed`: Number of documents preprocessed by the ingest pipeline.
- `elasticsearch.node.pipeline.ingest.operations.failed`: Total number of failed operations for the ingest pipeline.
- `elasticsearch.node.pipeline.ingest.documents.current`: Total number of documents currently being ingested by a pipeline.
- `elasticsearch.node.segments.memory`: Size of memory for segment object of a node.
- `elasticsearch.index.operations.completed`: The number of operations completed for an index.
- `elasticsearch.index.operations.time`: Time spent on operations for an index.
- `elasticsearch.index.shards.size`: The size of the shards assigned to this index.
- `elasticsearch.index.operations.merge.size`: The total size of merged segments for an index.
- `elasticsearch.index.operations.merge.docs_count`: The total number of documents in merge operations for an index.
- `elasticsearch.index.segments.count`: Number of segments of an index.
- `elasticsearch.index.segments.size`: Size of segments of an index.
- `elasticsearch.index.segments.memory`: Size of memory for segment object of an index.

Exp var receiver:
- `process.runtime.memstats.total_alloc`: Cumulative bytes allocated for heap objects.
- `process.runtime.memstats.sys`: Total bytes of memory obtained from the OS.
- `process.runtime.memstats.lookups`: Number of pointer lookups performed by the runtime.
- `process.runtime.memstats.mallocs`: Cumulative count of heap objects allocated.
- `process.runtime.memstats.frees`: Cumulative count of heap objects freed.
- `process.runtime.memstats.heap_alloc`: Bytes of allocated heap objects.
- `process.runtime.memstats.heap_sys`: Bytes of heap memory obtained by the OS.
- `process.runtime.memstats.heap_idle`: As defined by https://pkg.go.dev/runtime#MemStats
- `process.runtime.memstats.heap_inuse`: Bytes in in-use spans.
- `process.runtime.memstats.heap_released`: Bytes of physical memory returned to the OS.
- `process.runtime.memstats.heap_objects`: Number of allocated heap objects.
- `process.runtime.memstats.stack_inuse`: Bytes in stack spans.
- `process.runtime.memstats.stack_sys`: Bytes of stack memory obtained from the OS.
- `process.runtime.memstats.mspan_inuse`: Bytes of memory obtained from the OS for mspan structures.
- `process.runtime.memstats.mcache_inuse`: Bytes of allocated mcache structures.
- `process.runtime.memstats.mcache_sys`: Bytes of memory obtained from the OS for mcache structures.
- `process.runtime.memstats.buck_hash_sys`: Bytes of memory in profiling bucket hash tables.
- `process.runtime.memstats.gc_sys`: Bytes of memory in garbage collection metadata.
- `process.runtime.memstats.other_sys`: Bytes of memory in miscellaneous off-heap runtime allocations.
- `process.runtime.memstats.next_gc`: The target heap size of the next GC cycle.
- `process.runtime.memstats.pause_total`: The cumulative nanoseconds in GC stop-the-world pauses since the program started.
- `process.runtime.memstats.last_pause`: The most recent stop-the-world pause time.
- `process.runtime.memstats.num_gc`: Number of completed GC cycles.
- `process.runtime.memstats.num_forced_gc`: Number of GC cycles that were forced by the application calling the GC function.
- `process.runtime.memstats.gc_cpu_fraction`: The fraction of this program's available CPU time used by the GC since the program started.

Flink metrics receiver:
- `flink.jvm.gc.collections.count`: The total number of collections that have occurred.
- `flink.jvm.gc.collections.time`: The total time spent performing garbage collection.

HAProxy receiver:
- `haproxy.connections.rate`: Number of connections over the last elapsed second (frontend). Corresponds to HAProxy's `conn_rate` metric.
- `haproxy.connections.total`: Cumulative number of connections (frontend). Corresponds to HAProxy's `conn_tot` metric.
- `haproxy.connections.errors`: Number of requests that encountered an error trying to connect to a backend server. The backend stat is the sum of the stat. Corresponds to HAProxy's `econ` metric
- `haproxy.connections.retries`: Number of times a connection to a server was retried. Corresponds to HAProxy's `wretr` metric.
- `haproxy.sessions.count`: Current sessions. Corresponds to HAProxy's `scur` metric.
- `haproxy.sessions.total`: Cumulative number of sessions. Corresponds to HAProxy's `stot` metric.
- `haproxy.sessions.average`: Average total session time in ms over the last 1024 requests. Corresponds to HAProxy's `ttime` metric.
- `haproxy.sessions.rate`: Number of sessions per second over last elapsed second. Corresponds to HAProxy's `rate` metric.
- `haproxy.requests.denied`: Requests denied because of security concerns. Corresponds to HAProxy's `dreq` metric
- `haproxy.requests.errors`: Cumulative number of request errors. Corresponds to HAProxy's `ereq` metric.
- `haproxy.requests.redispatched`: Number of times a request was redispatched to another server. Corresponds to HAProxy's `wredis` metric.
- `haproxy.requests.total`: Total number of HTTP requests received. Corresponds to HAProxy's `req_tot`, `hrsp_1xx`, `hrsp_2xx`, `hrsp_3xx`, `hrsp_4xx`, `hrsp_5xx` and `hrsp_other` metrics.
- `haproxy.requests.queued`: Current queued requests. For the backend this reports the number queued without a server assigned. Corresponds to HAProxy's `qcur` metric.
- `haproxy.requests.rate`: HTTP requests per second over last elapsed second. Corresponds to HAProxy's `req_rate` metric.

Host metrics receiver:
- `system.filesystem.inodes.usage`: FileSystem inodes used.
- `system.processes.created`: Total number of created processes.
- `system.processes.count`: Total number of processes in each state.

Memcached receiver:
- `memcached.connections.current`: The current number of open connections.
- `memcached.connections.total`: Total number of connections opened since the server started running.

OracleDB receiver:
- `oracledb.sessions.usage`: Count of active sessions.
- `oracledb.sessions.limit`: Maximum limit of active sessions, -1 if unlimited.
- `oracledb.processes.usage`: Current count of active processes.
- `oracledb.processes.limit`: Maximum limit of active processes, -1 if unlimited.
- `oracledb.enqueue_locks.usage`: Current count of active enqueue locks.
- `oracledb.enqueue_locks.limit`: Maximum limit of active enqueue locks, -1 if unlimited.
- `oracledb.dml_locks.usage`: Current count of active DML (Data Manipulation Language) locks.
- `oracledb.dml_locks.limit`: Maximum limit of active DML (Data Manipulation Language) locks, -1 if unlimited.
- `oracledb.enqueue_resources.usage`: Current count of active enqueue resources.
- `oracledb.enqueue_resources.limit`: Maximum limit of active enqueue resources, -1 if unlimited.
- `oracledb.transactions.usage`: Current count of active transactions.
- `oracledb.transactions.limit`: Maximum limit of active transactions, -1 if unlimited.

PostgresQL receiver:
- `postgresql.bgwriter.buffers.allocated`: Number of buffers allocated.
- `postgresql.bgwriter.buffers.writes`: Number of buffers written.

Redis receiver:
- `redis.clients.connected`: Number of client connections (excluding connections from replicas)
- `redis.clients.max_input_buffer`: Biggest input buffer among current client connections
- `redis.clients.max_output_buffer`: Longest output list among current client connections
- `redis.clients.blocked`: Number of clients pending on a blocking call
- `redis.keys.expired`: Total number of key expiration events
- `redis.keys.evicted`: Number of evicted keys due to maxmemory limit
- `redis.connections.received`: Total number of connections accepted by the server
- `redis.connections.rejected`: Number of connections rejected because of maxclients limit
- `redis.commands.processed`: Total number of commands processed by the server

SAP HANA receiver:
- `saphana.service.memory.compactors.allocated`: The part of the memory pool that can potentially (if unpinned) be freed during a memory shortage.
- `saphana.service.memory.compactors.freeable`: The memory that can be freed during a memory shortage.

I believe most of them can be easily renamed to avoid pluralized namespaces. However, if we just remove the s ending, some metrics will get less descriptive names, e.g. container.pid.limit or redis.client.connected. Do we have any other guidelines that can be applied for renaming this kind of metrics?
cc @djaglowski FYI

Another scenario to consider: https://github.com/open-telemetry/opentelemetry-collector-contrib/issues/24905#issuecomment-1688903953.
We'd like to add new metrics to the kubeletstatsreceiver that include in the name a section clarifying which conceptual "limit", either requests or limits, is being used to calculate utilization. The Kubernetes term for the values we're using are plural and for the best name recognition experience for these metrics we'd like to use requests and limits.


Improve manual tests to auto using atip for securitymanu

Impacted TCs num(approved): New 0, Update 2, Delete 0
Unit test Platform: Android
Android test result summary: Pass 2, Fail 0, Block 0

LGTM


Traffic Cone Visual Bug

Please use the below as a template when making your report.
Describe the bug
Traffic cones appear to glow in the dark or have a blue filter over them.
Is it already a known issue?
Don't believe so
Steps to reproduce
Spawn in game, look at traffic cone (only really obvious at night)
Contact:
Please list your discord name if you are in our discord: spookyboi
Screenshot attached.

It will be fixed in next patch. It's from https://www.nexusmods.com/fallout4/mods/70447 and is a texture conflict with another texture mod.


logos-derive Cargo.toml can't find README.md on nightly

error: failed to download `logos v0.11.4`

Caused by:
  unable to get packages from source

Caused by:
  failed to parse manifest at `C:\Users\jonat\.cargo\registry\src\github.com-1ecc6299db9ec823\logos-0.11.4\Cargo.toml`

Caused by:
  readme file with name '../README.md' was not found

This is apparently caused by Cargo placing logos and logos-derive sources in the same directory of its registry, rather than placing the latter inside the former. logos-derive's Cargo.toml looks for "../README.md", which is not present.
I also asked about this on Stack Overflow, which has some more detail.

The issue seems to have mysteriously disappeared again in nightly-2020-06-13, though I still don't know what the cause was.


[Release] Release 4.0.0rc1

@github-actions crossbow submit --group verify-rc-source --param release=4.0.0 --param rc=0

@github-actions crossbow submit --group verify-rc-source --param release=4.0.0 --param rc=1

The packaging builds are running at https://github.com/ursacomputing/crossbow/branches/all?query=4.0.0-rc1
Travis is the bottleneck there, the arm64 builds are going to take 4-5hrs approximately.

@github-actions crossbow submit -g verify-rc-binaries

@github-actions crossbow submit --group verify-rc-binaries --param release=4.0.0 --param rc=1

@github-actions crossbow submit --group verify-rc-wheels --param release=4.0.0 --param rc=1

@github-actions crossbow submit --group verify-rc-binaries --param release=4.0.0 --param rc=1


Docs.MS Release Updates for azure-communication-administration

Update docs metadata and targeting for release of azure-communication-administration

Docs Build status updates of commit c23a446:
:clock10: Full build: the average full build time is 115 min(s) 56 sec(s), this is based on the last 856 build(s) for this repository.

Docs Build status updates of commit c23a446:
:white_check_mark: Validation status: passed

File
Status
Preview URL
Details

docs-ref-services/communication-administration-readme-pre.md
:white_check_mark:Succeeded
View (azure-java-stable) View (azure-java-preview) View (azure-java-legacy)

package.json
:white_check_mark:Succeeded

For more details, please refer to the build report.
Note: Broken links written as relative paths are included in the above build report. For broken links written as absolute paths or external URLs, see the broken link report.
For any questions, please:Try searching in the Docs contributor and Admin GuideSee the frequently asked questionsPost your question in the Docs support channel


Fix sourcemap support once and for all

Problem:

ganache-core requires source-map-support/register at top module scope.
Loading source-map-support multiple times in different versions leads to broken source map support: https://github.com/evanw/node-source-map-support/issues/200
This caused a lot of different issues in the Ethereum ecosystem:

Hardhat- https://github.com/EthWorks/Waffle/issues/281
Optimism - https://github.com/ethereum-optimism/plugins/issues/29
Jest integrations
probably more to come

Quick workaround:
source-map-support is able to ąvoid re-registering if one particular version is registered multiple times so a reasonable workaround is to force install only one particular version. To do this add in package.json:
"resolutions": {
    "source-map-support": "0.5.19"
  }

Real solution:
I see few solutions to this problem:

Not to import source-map-support in this library at all. source-map-support was designed not to be included in other libraries. I believe that it should be importing in some kind of executors like ganache-cli

Import it only when not in tests as celo did in their fork: https://github.com/celo-org/ganache-core/commit/3dbc32b214b3bb8f0dda2bfd909850a752a73a55 - I am not sure about this solution.

Try to push a fix to source-map-support to detect multiple registers across different versions. Fix seems to be easy to create but the library doesn't seem to be maintained anymore.

@gnidan I am linking past discussion with @sz-piotr: https://github.com/trufflesuite/truffle/issues/3432
Let me know how can I help to get this fixed.

The next version of ganache core will handle source-map-support properly (suggestion #1), and truffle will as well: https://github.com/trufflesuite/truffle/pull/3929
p.s., resolutions is a yarn-only feature.

That's perfect @davidmurdoch. Should I close this now or when it gets merged?

The next version of ganache core will handle source-map-support properly (via # 1)

This awesome news! Thanks @davidmurdoch!

@krzkaczor no need to close it. We'll handle it once 7.0 goes out.

For anyone looking for a really quick fix (read: hack), this worked for me in the meanwhile:
package.json
"scripts": {
    "postinstall": "cat /dev/null > node_modules/source-map-support/register.js",
}


Add a VU meter

This adds a VU meter for the the master output, displayed on the far right hand side of the Song, Chain, Phrase and Groove screens (currently no space on the Table screen).

Fixes: #42

Now rebased onto v2.0 branch

@maks Few observations, let me know what you think:

It seems like we are not sampling all channels, or at least it's not showing correctly. Tardline for example, 3rd line, VU meter seems to follow channel 2 but no (aparent) incidence on sound of channel 4
Meter goes to red pretty often, but I'd expect the max to be coincident to clipping
For chains that do not have any sound, the last output level that was displayed is used rather than 0 (this shows when playing a chain individually for example)
When stopping, VU meter doesn't go to zero, it stays in the last displayed value

@democloid hmm the code samples the master audio coming out of the audio driver, not individual channels, you can see the left channel code here. It does only take the peak value per sample period (size of the mixbuffer). I wonder if that could be causing the display to be a bit off? I did think about that perhaps I should be getting the RMS power value which is I think what real VU meters try to show but wasn't sure if that would be too heavy calculation doing it per sample?
With clipping, I didn't think following the existing clipping code:
if (v > f_32767) {
        v = f_32767;
        clipped_ = true;
      }

but I guess I can change the colour to match that too, what do you think?
With chains, I'm not showing the chains audio, just the master audio out. All the screens only show master mix out at the moment, as there is no infrastructure to get the per channel audio levels at the moment exposed up to the UI layer, it can be done, it just needs to repeat what I did here for the master mix, but I think that should be a separate PR.
For stopping, yes good point! thats a bug because I must not be clearing the last value on stop event, will fix that.

Doing this on a per sample basis may not be the most accurate way of doing this. What is actually being displayed in that case? given that we update the screen at 50Hz and we have 44100Hz sound, what is actually being displayed? probably the last sample measured before rewriting the screen.
When I mention chains, I mean when you play on the chains screen. In that case, the chain audio IS the master audio. My point is that it doesn't seem like samples from other channels are being represented in the master VU meter. i.e if you check the VU meter for channel 4 you see it's oscillating around ~33% when playing that line I mentioned, but when playing all channels together, VU meter goes to zero often. It could be an artifiact of the sampling I mentioned before.


Multiple IPv4 ranges in AllowedIPs

Hello,
I tried to add multiple IPv4 ranges in AllowedIPs but I got an error:
wg-access-server    | time="2022-03-31T07:26:35Z" level=error msg="invalid cidr in
AllowedIPs: invalid CIDR address: <IP_ADDRESS>/16,<IP_ADDRESS>/16" file="main.go:145"

Here is the corresponding line in docker-composer.yaml
      - "WG_VPN_ALLOWED_IPS=<IP_ADDRESS>/16,<IP_ADDRESS>/16"

I got two questions: is this possible and what if it is, what is the correct syntax? Else could we dig to add such feature?

Okay, thanks for the info about the newline char. I will try this.
It could also be better to have splitting on comma, indeed. Thanks again.

So it works well like this:
- "WG_VPN_ALLOWED_IPS=<IP_ADDRESS>/16\n<IP_ADDRESS>/16

So as it works we could close this issue, unless you prefer we keep it open, looking for a improvment on the parser. As you wish.

Oh, you fixed this so quickly, many thanks!


FP for CVE-2016-3720 on non-affected Jackson version

This is related to the same vulnerability and package as https://github.com/jeremylong/DependencyCheck/issues/517 but is not exactly the same problem.
I have all the Jackson dependencies at version 2.7.6, which according to the NVD entry and CPE is not affected by the vulnerability. Still, I'm getting the following output on my check dependencies log:
One or more dependencies were identified with known vulnerabilities in <redacted>:

jackson-core-2.7.6.jar (com.fasterxml.jackson.core:jackson-core:2.7.6, cpe:/a:fasterxml:jackson:2.7.6) : CVE-2016-3720

These are the dependencies that triggered this:
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-databind</artifactId>
            <version>2.7.6</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.core</groupId>
            <artifactId>jackson-annotations</artifactId>
            <version>2.7.6</version>
        </dependency>
        <dependency>
            <groupId>com.fasterxml.jackson.dataformat</groupId>
            <artifactId>jackson-dataformat-cbor</artifactId>
            <version>2.7.6</version>
        </dependency>

What version of dependency-check are you using? I just tested these three dependencies (with the current snapshot) and they were not flagged as vulnerable.

                <groupId>org.owasp</groupId>
                <artifactId>dependency-check-maven</artifactId>
                <version>1.4.2</version>

Can you delete the dependency-check database and retest this? While there is a CPE match for jackson-core - no vulnerabilities are showing up (because we are using a safer version) when I run this exact same test with a fresh database. Just wondering if something got out of sync with the NVD.

Unable to reproduce. Additional fixes have been implemented around CVE-2016-3720.


Wiki: Instructions on creating a PDD from the template

https://github.com/RIT-Space-Exploration/SPEX-Standard-Proposal/wiki/Creating-a-PDD-from-the-Template

I can probably help with that. Do you still need it?

We still need it. The page should describe the [ fork -> copy -> edit -> pull request ] process as used in #10

Covered the process via CLI. We should probably do a guide with Github Desktop as well.

Git basics tutorial belongs in a new issue. PDD creation tutorial looks good.


"Non-decomposable matrix transform" error logged every frame, slows down performance

While trying to import Apple's event AR model, I noticed that there's an error message logged every frame.

While I understand that the matrix might not be decomposable and that's an issue, logging every frame seems excessive.
Model is attached:
apple_event.usdz.zip

Yeah, that was certainly not intended, it's a side effect of the importer spewing an error + playback.


WIP: cross-namespace snapshot populator for csi-hostpath driver

What type of PR is this?
/kind feature
What this PR does / why we need it:
This is an example implementation for "provisioning volumes from cross-namespace snapshots" KEP by using populator approach. lib-volume-populator needs more adaption for GA and this use case will be a good candidate.
Which issue(s) this PR fixes:

Fixes #30
Special notes for your reviewer:
@bswartz @xing-yang @Elbehery
Does this PR introduce a user-facing change?:

Example implementation of cross-namespace snapshot populator for csi-hostpath driver is added.

@bswartz @xing-yang @Elbehery As I implemented this PR, I noticed below three points:

As a driver specific implementation, cross-namespace snapshot populator can be implemented (at least for CSI hostpath driver).
Please also see README for how it can be used and tested.

Current lib-volume-populator doesn't allow below. So, it would be better adding such feature (This PR directly modified the library codes, which won't be the right way)

Adding extra volumes
Mouting extra volumes
Modifying ServiceAccount

It is better to provide common implementation, not driver specific implementation like this. To achieve it by utilizing the existing populator approach, we may need to add a new CSI call to populate the already provisioned volume, instead of only allowing creating pre-populated volume in CreateVolume.

I will create another issue for (2) in this repo, and let's continue discussion related to (1) and (3) on cross-namespace snapshot KEP (but any comments on this PR are still welcome).

@mkimuram I've read through most of this patch, and it's difficult to understand everything its doing.
My first complaint is that this repo shouldn't be used for any actual populators. I understand this is a WIP and it's easier to try out something new inside the repo, but the understanding should be that we'll eventually put the actual code somwhere else.
I'm still trying to understand why we need to patch the pod. It could be that the current library interface isn't flexible enough (in fact I strongly suspect that) but I need specific use cases to understand how we can improve it. What were you trying to do that you couldn't achieve with the existing interface?

@bswartz Thank you for checking the codes and giving feedback.

My first complaint is that this repo shouldn't be used for any actual populators. I understand this is a WIP and it's easier to try out something new inside the repo, but the understanding should be that we'll eventually put the actual code somwhere else.

This PR is just to share the idea, so the codes won't be necessary in this repo. I agree that we need another new repo if we implement this way.

I'm still trying to understand why we need to patch the pod. It could be that the current library interface isn't flexible enough (in fact I strongly suspect that) but I need specific use cases to understand how we can improve it. What were you trying to do that you couldn't achieve with the existing interface?

For this particular use case, this populator is trying to:

Copy the data from the hostpath that needs to be mounted on the populator Pod,
Access to other CRDs like VolumeSnapshot, VolumeSnapshotContents, and ReferencePolicies to find from where the data should be copied and whether it is allowed

So, it needs to mount volumes and to add extra RBAC, therefore it needs to modify the populator Pod's spec.
These requirements won't be special, because if we try to implement a simple populator that copies data from Configmap or Secret, for example, we would at least need either of the above.


[Feature request] args optional setup argument

Hi
Can we get optional setup argument args like in neotest-python to provide extra_args from setup ?
For example:
require('neotest-go')({
    args = {"-timeout=60s","-count=1"}
})

Because providing them via neotest.run.run({extra_args={...}})  forces them to be specified in key bindings, which is not necessary when using neotest in other languages and may conflicts

@Malefaro FYI 👉🏿 https://github.com/nvim-neotest/neotest-go#contributing

https://github.com/nvim-neotest/neotest-go/pull/11

closed by #11


[cowboy_http] I try to set idle_timeout to 'infinity'

Like this, I use on the elixir.
    { :ok, _ } = :cowboy.start_clear(:dev_files_server,
      [{ :port, port }],
      %{ :env => %{ :dispatch => build_dispath_config() }, :idle_timeout => :infinity }
    )

More
Use 6_000_000integer work very well. But i find idle_timeout is timeout() type.

I confirm it's missing a case for infinity.

I think you're right, thanks!

I mean it's a bug so leave open if you want it fixed eventually. :-)

My fault, I just misunderstood what you mean. 😆  thank you again.

This should be fixed in Cowboy master, thanks!


Enable auth_state for NASA VEDA

This will help complete https://github.com/NASA-IMPACT/veda-jupyterhub/issues/19.
VEDA uses GitHubOAuthenticator, but currently does not have auth_state and populate_teams_in_auth_state enabled. We need to turn both on, and log everyone out, so we can offer separate profile options to different users in the future more easily.

The "log everyone out" isn't trivial, but I think it can be done by resetting the cookie secret for the hub like described in https://z2jh.jupyter.org/en/stable/resources/reference.html#hub-cookiesecret (kubectl edit on a k8s secret, then remove a key/value pair related to cookie secret, then redeploy).
I'll explore the consequences of doing this for a user with a running server in openveda staging now.

@consideRatio We have documentation on the hub cookie secret here https://infrastructure.2i2c.org/hub-deployment-guide/configure-auth/github-orgs/#enabling-team-based-access-on-hub-with-pre-existing-users


Use isinstance instead of checking type equality

Scheduled checks run failed on master due to an explicit comparison between type evaluated on an object an a type rather than using isinstance (or is with type).

@willGraham01 tagging you for a review if that's okay as this should hopefully be quick as it's a couple of line change!


Add invocation seed to HostData, fill washboard widgets with real data

Working on https://github.com/wasmCloud/wasmCloud/issues/216 (widgets)
This PR also adds the invocation seed to the expected HostData struct for both httpserver and redis providers. These both broke in some aspect, but now they are back to working status and are published at the following URLs.

wasmcloud.azurecr.io/httpserver:0.13.1
wasmcloud.azurecr.io/redis:0.13.1

@brooksmtownsend can't get these tests to pass

Hah, the tests pass but now the DCO check failed.


Add generic version of RandomChoice

RandomChoice does not accept lists of strings, numbers, and other non-interface types.
This commit adds a generic variant RandomChoiceG that accepts any collection (of a single type), useful for choosing a random string or number in a set of options.
Also add simple tests for both the original method and the new one.

@youhanaNaseim

This commit adds a generic variant RandomChoiceG that accepts any collection (of a single type), useful for choosing a random string or number in a set of options.

Looks like a good improvement - thanks Marco.  I'll work on getting this tested and merged.


move MR from actinia-core "Check actinia modules #23"

this PR was originally opened here: mundialis/actinia_core#23
It is now moved to the actinia-gdi plugin.

See also https://github.com/mundialis/actinia_core/pull/24

you can merge :)

Ok, I'll merge now


[mi-label] Test B12.1 Bug Fixes from Sprints 15 and 16

🟢 Issues Ready For I&T

[ ] https://github.com/nasa-pds/mi-label/issues/21

📜 Test Plan / Procedure

⚙ Automated Tests

This can mark as closed.

@gxtchen can you please add a copy or link to the test report here so we have some traceability?


Ensure that there is a dataset in the corpus with multiethnic terms, and verify that multiethnic terms don't show up in the Self-Reported Ethnicity filter, nor do they show up when grouping by Self-Reported Ethnicity

Verifies that this ticket works as expected: https://app.zenhub.com/workspaces/single-cell-5e2a191dad828d52cc78b028/issues/gh/chanzuckerberg/single-cell/596

We'll have to wait til there's a schema 4 version of census before we can test this.

Datasets in this collection contain rows with "HANCESTRO:0005,HANCESTRO:0008"

This collection in prod has 11,725 cells with self_reported_ethnicity=European,Asian, so it should be in our corpus. It is successfully filtered out in both (1) the self-reported ethnicity dropdown and (2) if you do a groupby self reported ethnicity


Filtering by expression/specificity weights - Fig 3 A-D

Hi Rui,
Thanks for this great tool!
I am wondering how could one go about filtering out the edges based on expression weights or specificity weights? Essentially to generate Fig. 3A from Fig. 2A from the NATMI paper.
Is this option available in any of the python scripts (I couldn't find one to the best of my knowledge) ?
Thanks,
Somesh

Hi Somesh,
When you run VisInteractions.py, please specify "--expressionThreshold" and/or "--specificityThreshold" to filter out edges based on expression weights and/or specificity weights.
Best,
Rui


[VL] Add independent operator for top-n processing in TakeOrderedAndProjectExecTransformer

This PR adds a new physical operator TopNTransformer in Velox backend mapping to Velox's core::TopNNode.
By doing this, we can remove the hacky limit + sort coherent validation code, and the proxied executed plan used by TakeOrderedAndProjectExecTransformer will correctly map to the actual physical plan in Velox task.
This PR is a phase 1 because the actual Velox plan is still hidden by TakeOrderedAndProjectExecTransformer although limit+sort was replaced by top-n. We may eventually deprecate TakeOrderedAndProjectExecTransformer and expose more execution details to query planner.


Missing label on "listbox" UL generated by Awesomplete

I'm using the Axe Coconut Chrome extension (https://chrome.google.com/webstore/detail/axe-coconut/iobddmbdndbbbfjopjdgadphaoihpojp?hl=en) to test for accessibility and ADA compliance, and I'm seeing an issue being raised on the UL generated by Awesomplete with the role "listbox". Here is the error:

ARIA input fields have an accessible name
To solve this violation, you need to:

Fix at least one (1) of these issues:
aria-label attribute does not exist or is empty
aria-labelledby attribute does not exist, references elements that do not exist or references elements that are empty
Element has no title attribute or the title attribute is empty

Possible solutions:

It seems like the least repetitive experience for the user would be to use aria-labelledby on the listbox and have it point back to the label associated with the input element
Plucking the text from the associated label and using it inside aria-label or title on the listbox
Allowing another attribute to be passed through to Awesomplete via the input, similar to how the data-list works, and then using that inside a new attribute aria-label or title on the listbox

Hi, has this issue been solved by #17203 ? And are there plans to make a new release soon?
Since the Joomla project is using this library, we are interested on an upstream solution :-)


Add support for new Gildings?

Hi, JRAW is missing the new guildings object,
with support for reddit silver and platinum.
I notice that this repo is getting stale, do you want any help? PR?
I know this has been asked before, but accessing fields that are not mapped would help in cases like this.
Thank you in advance.

I notice that this repo is getting stale, do you want any help? PR?

Yes please. A PR will be helpful

PR done, if you can put out a minor version here and with JRAW-Android would be nice nice.

I'm thinking about doing a PR with a version bump while we are at it. What do you think?

Also interested in this feature. A new release to get access to it would be great!

You can use Jitpack specifing the latest commit, to access this in the mean time.


Kotlin: anagram detection

@mre note that my approach is very different from yours.

Very cool solution. I dig the functional style.


Add Source Link to Nuget Package

Not sure if it's worth it...

https://learn.microsoft.com/en-us/dotnet/standard/library-guidance/sourcelink


Last modified timestamp will not update after update

Bug report
Describe the bug
A replacment of a file with upload (upsert: true) or update will not update the last modified timestamp. The file itself has been updated.
To Reproduce
Steps to reproduce the behavior, please provide code snippets or a repository:
const avatarFile = event.target.files[0]
const { data, error } = await supabase
  .storage
  .from('avatars')
  .update('public/avatar1.png', avatarFile, {
    cacheControl: 3600,
    upsert: false
  })

Expected behavior
A replacement of a file should update the timestamp.
System information
supabase-js 1.22.0

I ran into this today as well with 1.29.0


Where can I get compiled builds

Thanks for the great work continuing this project, I've looked through some of the latest gits and they fix some problems I have been having but I can't seem to be able to compile this version correctly, is there builds on Travis? If so I could not find them, is there anywhere I can download the current build? Thanks!

unfortunately the current build is currently not available yet...
btw, what errors you get when compiling materialize?

When are you planning to release a new version? I'm still waiting on the select fix. https://github.com/Dogfalo/materialize/issues/6464

Probably when we find some free time to do that.

We could do nightly builds pretty easily with github actions, I could do that if wanted.

We could do nightly builds pretty easily with github actions, I could do that if wanted.

Do you mean on npmjs? Because this and the CDNs are the main source for consumers.
I'm not sure if nightly builds make so much sense in general as there are not that many changes per day.

By nightly I just mean with each change to master. The builds could be here as releases or just at a link (still hosted by github) so not to spam the releases with every commit

Hm, I'm not sure. I don't see much benefit in there so far.
I would also prefer semantic-releases or similar.

When can i use the newest version as cdn?

When can i use the newest version as cdn?

When it is released on npmjs. But I recommend to download the files then and host them yourself - especially regarding GDPR and CDNs can also have outages.

Ok is there any time shedule? I prefer weekly releases for dev version so everyone and I can easily use the latest release and we can improve faster as a team.
So whats the Plan? I want this to get started. Thanks

Ok is there any time shedule?

No, as I already wrote when I find some time to plan and do this.

I prefer weekly releases for dev version so everyone and I can easily use the latest release and we can improve faster as a team.

Please see my previous comments. semantic-releases makes more sense (but not daily or weekly, there is no specific time-interval that I would use).

It might make sense to publish 1.0.0 to npm and cdnjs. Even though it's identical to the upstream release, it'd allow people to get the deps set now in package.json and simply yarn upgrade when you do cut new releases.
I totally understand the time issue, but I'm putting this out there as a lower-hanging fruit.

@DanielRuf Sorry I haven't tried to build this........ but how to build materialize? Is grunt monitor will also compile the framework? Or is there a specific command to compile/build it? 😕

It might make sense to publish 1.0.0 to npm and cdnjs

It already is as already mentioned ;-)
https://www.npmjs.com/package/@materializecss/materialize

@DanielRuf Sorry I haven't tried to build this........ but how to build materialize? Is grunt monitor will also compile the framework? Or is there a specific command to compile/build it? confused

grunt monitor watches only for changes and then compiles.
There are 3 grunt tasks for compiling the files:
https://github.com/materializecss/materialize/blob/v1-dev/Gruntfile.js#L660-L662
We might have to extend https://github.com/materializecss/materialize/blob/v1-dev/CONTRIBUTING.md

update: it's mentioned on the travis file that it's using Node.js v6.10
https://github.com/materializecss/materialize/blob/875719d9874503af266d372fc6c0db37e488382b/.travis.yml#L2-L3
I think this is what OP encountered, it's failing to run npm install because the Node.js that OP uses might be too new. I tried with Node.js v14.11.0 and it's somewhat failing at building node-sass.
So I tried starting from v8 and v9. They can still runs fine. But when I tried with Node.js v10.22.1, it's failing when trying to build node-sass. So I suppose this needs to be written in the documentation that it's required at least v6, but at most v9? But those Node.js versions already EOL. So...... maybe updating the node-sass version number will solve this issue?

You have to upgrade node-sass for node 14, correct.
That's on the roadmap too.

You have to upgrade node-sass for node 14, correct.
That's on the roadmap too.

@nekonenene already did this in some PRs =)

Hey it has been quite a long time, any updates on the build?
I think at least some nightly builds should be released as the old version has some bugs that really need to be fixed asap.
We may need to switch to other libraries if we have to wait indefinitely.

So far no updates as you can see. A new release is planned for this year.

So far no updates as you can see. A new release is planned for this year.

Any updates on the release date? Thanks.

So far no updates as you can see. A new release is planned for this year.

Any updates on the release date? Thanks.

Any updates on the release date? Thanks.

I think with PR #63, we can first try with nightly builds. See if there's any problem with the nightly one, before moving to stable release.

Any updates on the release date? Thanks.

I think with PR #63, we can first try with nightly builds. See if there's any problem with the nightly one, before moving to stable release.

That's been merged so you can now get the latest nightly build here: https://nightly.link/materializecss/materialize/workflows/nightly/dev/build.zip

That's been merged so you can now get the latest nightly build here: https://nightly.link/materializecss/materialize/workflows/nightly/dev/build.zip


Not-found-animation + Translating-animation + text #18 #20

I finished 2 components for "Translating text" and "Not Found" with text for each one.

got 62 conflicts at package-lock.json 😥

I made refactoring to Animation component so it possible to reuse it for both animations with text: NotFoundAnimation and TranslatingAnimation

Conflicts resolved

Waiting for approve


[The Troubleshooters] update Nov21

Changes / Comments
Major update to the sheet:

Implementation of Custom Roll Parsing / Roll Templates
Significant layout changes for improved usability
NPC Tab adds 'cut down' sheet to be used for Director Characters or quick PCs
background colour amended to improve look and give more of a 'passport' feel
character avatar displayed in character sheet
Attribute names have been retained as far as possible - some changes to attributes in repeating section on 'Combat' tab to aid with building roll templates.

Roll20 Requests
Comments are very helpful for reviewing the code changes. Please answer the relevant questions below in your comment.

[x] Does the pull request title have the sheet name(s)? Include each sheet name.
[ ] Is this a bug fix?
[x] Does this add functional enhancements (new features or extending existing features) ?
[x] Does this add or change functional aesthetics (such as layout or color scheme) ?
[x] If changing or removing attributes, what steps have you taken, if any, to preserve player data ?
[ ] If this is a new sheet, did you follow Building Character Sheets standards ?

If you do not know English. Please leave a comment in your native language.

Character Sheet Info Roll20 Internal Use only.


Fix scalar jacobi generate on different precision and add DiagonalLinOpExtractable

This pr adds DiagonalLinOpExtractable and fix scalar Jacobi issue on generation on different precision matrix.
the failed test can be found in https://gitlab.com/ginkgo-project/ginkgo-public-ci/-/pipelines/336902618

rebase!

I think the omp/debug/shared job was failing ?

yes


uucore: move printf::memo module to uucore

This pull request moves the printf::memo module to uucore so that it can be used by other programs, not just printf. For example, the -f option to seq requires parsing and formatting numbers according to the same logic as printf (see issue #2616).
I could use some help with this. After this change, I see the following warnings:
warning: struct is never constructed: `Remainder`
  --> src/uucore/src/lib/features/tokenize/num_format/formatters/base_conv/mod.rs:35:12
   |
35 | pub struct Remainder<'a> {
   |            ^^^^^^^^^
   |
   = note: `#[warn(dead_code)]` on by default

warning: struct is never constructed: `DivOut`
  --> src/uucore/src/lib/features/tokenize/num_format/formatters/base_conv/mod.rs:41:12
   |
41 | pub struct DivOut<'a> {
   |            ^^^^^^

warning: function is never used: `arrnum_int_div_step`
  --> src/uucore/src/lib/features/tokenize/num_format/formatters/base_conv/mod.rs:46:8
   |
46 | pub fn arrnum_int_div_step(
   |        ^^^^^^^^^^^^^^^^^^^

warning: function is never used: `unsigned_to_arrnum`
   --> src/uucore/src/lib/features/tokenize/num_format/formatters/base_conv/mod.rs:144:8
    |
144 | pub fn unsigned_to_arrnum(src: u16) -> Vec<u8> {
    |        ^^^^^^^^^^^^^^^^^^

warning: field is never read: `as_num`
  --> src/uucore/src/lib/features/tokenize/num_format/formatters/cninetyninehexfloatf.rs:12:5
   |
12 |     as_num: f64,
   |     ^^^^^^^^^^^

warning: function is never used: `to_hex`
  --> src/uucore/src/lib/features/tokenize/num_format/formatters/cninetyninehexfloatf.rs:94:4
   |
94 | fn to_hex(src: &str, before_decimal: bool) -> String {
   |    ^^^^^^

I believe this is related to the fact that the %a formatting option is not implemented yet. See issue #2776. What do you recommend I do about this?

Aha, I see how the previous code dealt with this: https://github.com/uutils/coreutils/blob/f7584cb755c98da64861e6a7f3b3d8f67679e3e8/src/uu/printf/src/printf.rs#L1
I can just reproduce that #![allow(dead_code)].


Improve UserDataModule documentation and clarity

The Userdata section of the README can be improved by adding more examples of the different types of userdata supported. An example of an acceptable shell script and/or non-executable data would help flush out the misunderstanding before folks launch instances.
This aims to clarify the differences between what the UserDataModule currently supports and the documentation found in https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/user-data.html.

This is a duplicate of (#6). Closing in favor of the other.


feat: display container's logs to user if there is an error during co…

Display container's logs to user if there is an error during compilation

Merged into another branch and will be included in the next release


RFP - GB Studio

GB Studio
A free and easy to use retro adventure game creator for your favourite handheld video game system
Checklist

[x] The package I am requesting does not already exist on https://chocolatey.org/packages;
[x] There is no open issue for this package;
[x] The issue title starts 'RFP - ';
[x] The download URL is public and not locked behind a paywall / login;

Package Details

Software project URL
https://www.gbstudio.dev/

Direct download URL for the software/installer
https://github.com/chrismaltby/gb-studio/releases/download/v1.1.0/GB.Studio-win32-x64-squirrel-1.1.0.zip (64-bit installer)

Alternative downloads
https://www.gbstudio.dev/download/ or https://github.com/chrismaltby/gb-studio/releases

Status: Review

https://chocolatey.org/packages/gbstudio
https://chocolatey.org/packages/gbstudio.install
https://chocolatey.org/packages/gbstudio.portable

Status: Published

https://chocolatey.org/packages/gbstudio
https://chocolatey.org/packages/gbstudio.install
https://chocolatey.org/packages/gbstudio.portable

Can be closed.


Keep seeg and eeg seperated in butterfly mode

Due to the different signal characteristics, I propose to keep seeg and eeg channels seperated in butterfly mode.

closing in favor of #4848
thanks @stfnrpplngr


Error: ModuleFactory not set - Gesture recognizer running on iOS WKwebview does not work

Have I written custom code (as opposed to using a stock example script provided in MediaPipe)
No
OS Platform and Distribution
iOS 16.4.1
Mobile device if the issue happens on mobile device
Iphone 12 pro
Browser and version if the issue happens on browser
No response
Programming Language and version
Javascript
MediaPipe version
No response
Bazel version
No response
Solution
gesture recognizer
Android Studio, NDK, SDK versions (if issue is related to building in Android environment)
No response
Xcode & Tulsi version (if issue is related to building for iOS)
No response
Describe the actual behavior
GestureRecognizer.createFromOptions returns "Error: ModuleFactory not set" when running the module on Waterview. It works on the regular safari.

Describe the expected behaviour
GestureRecognizer.createFromOptions should work when running on wkwebview

Standalone code/steps you may have used to try to get what you need
import { GestureRecognizer,FilesetResolver, DrawingUtils } from "./tasks-vision.js"

  const vision = FilesetResolver.forVisionTasks(
      "https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>    ).then((resolver) => {

      GestureRecognizer.createFromOptions(vision, {
        baseOptions: {
          modelAssetPath:
            "/gesture_recognizer.task",
        },
        runningMode: "VIDEO",
        numHands: 2
      }).then((gestureRecognizer) => {
      }).catch((error) => {
        console.log("error"+error)

      });

    }).catch((error) => {

        console.log("error"+error)

     })

Other info / Complete Logs
No response

It was a bug in my code.
The correct code:
`import { GestureRecognizer,FilesetResolver, DrawingUtils } from "./tasks-vision.js"
FilesetResolver.forVisionTasks(
"https://cdn.jsdelivr.net/npm/<EMAIL_ADDRESS>).then((vision) => {
  GestureRecognizer.createFromOptions(vision, {
    baseOptions: {
      modelAssetPath:
        "/gesture_recognizer.task",
    },
    runningMode: "VIDEO",
    numHands: 2
  }).then((gestureRecognizer) => {
  }).catch((error) => {
    console.log("error"+error)

  });

}).catch((error) => {

    console.log("error"+error)

 })

`
The "vision" variable needs to be passed properly.


Update Onfido sdk to 6.0, ditch fork

Details
We recently standardized on using node 16 / npm 8 in this project. NPM 8 changed the way peer dependencies were handled, such that any unmet peer dependencies became errors instead of warnings.
However, at the time we had conflicting peer dependencies where we needed to upgrade to React 18, but the Onfido SDK listed a peer dependency with React 17. (issue). To work around this, we forked the Onfido repo and used our own version with a more flexible peer dependency (allowing for React 18).
10 days ago, Onfido released a new version of their react native SDK that fixed this problem, so we no longer need to maintain our own fork. Instead, we can just upgrade Onfido to the latest upstream version. That's what this PR does.
Fixed Issues
$ n/a
Tests

Apply the following diff in NewDot:
diff --git a/src/pages/EnablePayments/EnablePaymentsPage.js b/src/pages/EnablePayments/EnablePaymentsPage.js
index 4ebbb982a..7e0821db3 100644
--- a/src/pages/EnablePayments/EnablePaymentsPage.js
+++ b/src/pages/EnablePayments/EnablePaymentsPage.js
@@ -71,7 +71,7 @@ class EnablePaymentsPage extends React.Component {
             );
         }

-        const currentStep = this.props.userWallet.currentStep || CONST.WALLET.STEP.ADDITIONAL_DETAILS;
+        const currentStep = CONST.WALLET.STEP.ONFIDO

         return (
             <ScreenWrapper>
diff --git a/src/pages/EnablePayments/OnfidoPrivacy.js b/src/pages/EnablePayments/OnfidoPrivacy.js
index 921d85e14..5d4b4849b 100644
--- a/src/pages/EnablePayments/OnfidoPrivacy.js
+++ b/src/pages/EnablePayments/OnfidoPrivacy.js
@@ -46,9 +46,9 @@ class OnfidoPrivacy extends React.Component {

     openOnfidoFlow() {
         BankAccounts.openOnfidoFlow(
-            this.props.walletAdditionalDetailsDraft.legalFirstName,
-            this.props.walletAdditionalDetailsDraft.legalLastName,
-            this.props.walletAdditionalDetailsDraft.dob,
+            'Roreth',
+            'Goodingsplat',
+            '1990-01-01',
         );
     }

diff --git a/src/pages/EnablePayments/OnfidoStep.js b/src/pages/EnablePayments/OnfidoStep.js
index 776576346..6d7a8ca25 100644
--- a/src/pages/EnablePayments/OnfidoStep.js
+++ b/src/pages/EnablePayments/OnfidoStep.js
@@ -36,9 +36,9 @@ const defaultProps = {
 class OnfidoStep extends React.Component {
     componentDidMount() {
         // Once in Onfido step, if we somehow don't have the personal info, go back to previous step, as we need them for Onfido{
-        const firstName = lodashGet(this.props, 'walletAdditionalDetailsDraft.legalFirstName');
-        const lastName = lodashGet(this.props, 'walletAdditionalDetailsDraft.legalLastName');
-        const dob = lodashGet(this.props, 'walletAdditionalDetailsDraft.dob');
+        const firstName = 'Roreth';
+        const lastName = 'Goodingsplat';
+        const dob = '1990-01-01';

         if (!firstName || !lastName || !dob) {
             Wallet.updateCurrentStep(CONST.WALLET.STEP.ADDITIONAL_DETAILS);

Run the app

Use a deeplink to go to the enable-payments page:

iOS: xcrun simctl openurl booted new-expensify://enable-payments
Android: adb shell am start -a android.intent.action.VIEW -d new-expensify://enable-payments

Click Continue on the Verify Identify page

Verify that the Onfido SDK opens correctly.

[x] Verify that no errors appear in the JS console

PR Review Checklist

Contributor (PR Author) Checklist

[x] I linked the correct issue in the ### Fixed 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 added steps for Staging and/or Production testing in the QA steps section
[x] I added steps to cover failure scenarios (i.e. verify an input displays the correct error message if the entered data is not correct)
[x] I turned off my network connection and tested it while offline to ensure it matches the expected behavior (i.e. verify the default avatar icon is displayed if app is offline)

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

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[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 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 any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[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] 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] Any functional components have the displayName property
[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] 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 a new CSS style is added I verified that:

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

[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 PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR author checklist, including those that don't apply to this PR.

PR Reviewer Checklist
The Contributor+ will copy/paste it into a new comment and complete it after the author checklist is completed

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

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

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

[x] iOS / native
[x] Android / native
[x] iOS / Safari
[x] Android / Chrome
[x] MacOS / Chrome
[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 verified proper code patterns were followed (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 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 any copy / text shown in the product was added in all src/languages/* files
[x] I verified any copy / text that was added to the app is correct English and approved by marketing by tagging the marketing team on the original GH to get the correct copy.
[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 verified that this PR follows the guidelines as stated in the Review Guidelines
[x] I verified other components that can be impacted by these changes have been tested, and I retested again (i.e. if the PR modifies a shared library or component like Avatar, I verified the components using Avatar have been tested & I retested again)
[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] 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] Any functional components have the displayName property
[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] 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 a new CSS style is added I verified that:

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

[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 PR modifies a component related to any of the existing Storybook stories, I tested and verified all stories for that component are still working as expected.
[x] I have checked off every checkbox in the PR reviewer checklist, including those that don't apply to this PR.

QA Steps

Follow the steps in this SO to test Onfido on staging. If you only have access to an iOS OR Android device, find someone else to test the other platform.

 Can't seem to get it to pass.

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

🚀 Deployed to staging by @arosiclair in version: 1.2.7-0 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅

🚀 Deployed to production by @roryabraham in version: 1.2.7-2 🚀

platform
result

🤖 android 🤖
success ✅

🖥 desktop 🖥
success ✅

🍎 iOS 🍎
success ✅

🕸 web 🕸
success ✅


CI: test building libbpf-rs with libbpf-sys

libbpf-sys aims to adhere to semantic versioning rules and indicate incompatible changes by bumping major version numbers. However, it is sometimes hard to identify breaking changes in advance and so breakage may happen unintentionally. Detecting of such breaking changes also becomes harder with auto-generated code, and libbpf-sys has a bunch of that, owing due to it binding to a C library. For example, in libbpf-rs [0] we have encountered a case where we were relying on a bindgen generated type exported by libbpf-sys that got removed because bindgen changed its behavior, which effectively is a semver violation.
To aid with the detection such unintended incompatibilities, this change adds a CI step that builds the most recent published version of libbpf-rs with the current libbpf-sys snapshot, to flag accidental breakage.
[0] https://github.com/libbpf/libbpf-rs/issues/303
Closes: #53
Signed-off-by: Daniel Müller<EMAIL_ADDRESS>

Here is a test run with a problem similar to what we saw earlier with size_t and how this step detected the incompatibility: https://github.com/danielocfb/libbpf-sys/actions/runs/3897219774

Apologies for the late follow-up. This looks great. I'm going to merge this and then go a bit further by making it a prerequisite for the publish step.


ActiveMQ Artemis Scalar: ScaledJob not scaling correctly

Report
The ScaledJob spec.
Ten messages are posted one by one in the ActiveMQ Artemis queue. Out of 10, 9 jobs spin up correctly and execute to completion. One job never spawned. I waited for 30 minutes. I verified that the unconsumed message is present in the queue. There are no Running jobs. But the KEDA operator pod logs always says:
Number of running jobs = 1, Number of pending jobs = 1.
To overcome this, I deleted the message in the queue. Even then, the KEDA operator pod logs always says:
Number of running jobs = 1, Number of pending jobs = 1.
I had to delete the ScaledJob and apply it back again to get rid of the erroneous log messages.  I think the queue information is cached within KEDA operator and its not refreshed.
This issue was not observed in the next execution. But seen again in the third run. This scaling issue is often seen when there are more than 10 messages in the queue.
The same issue is seen for other ScaledJob specs also.
Expected Behavior

The scaling of jobs must happen accurately, irrespective of the number of messages in the queue.
Keda operator must report correct information in the logs.

Actual Behavior
KEDA operator is not scaling the jobs correctly. Incorrect info is cached in it.
Steps to Reproduce the Problem

Create a ScaledJob spec as per the attachment. Post 10 or more messages into the ActiveMQ Artemis queue
Observe the scaling of Jobs
Repeat the steps

Logs from KEDA operator
2024-08-06T11:11:38Z	INFO	scaleexecutor	Scaling Jobs	{"scaledJob.Name": "fe-supervised-job", "scaledJob.Namespace": "road", "Number of running Jobs": 1}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Scaling Jobs	{"scaledJob.Name": "fe-supervised-job", "scaledJob.Namespace": "road", "Number of pending Jobs ": 1}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Creating jobs	{"scaledJob.Name": "fe-supervised-job", "scaledJob.Namespace": "road", "Effective number of max jobs": 0}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Creating jobs	{"scaledJob.Name": "fe-supervised-job", "scaledJob.Namespace": "road", "Number of jobs": 0}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Created jobs	{"scaledJob.Name": "fe-supervised-job", "scaledJob.Namespace": "road", "Number of jobs": 0}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Scaling Jobs	{"scaledJob.Name": "fe-unsupervised-job", "scaledJob.Namespace": "road", "Number of running Jobs": 1}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Scaling Jobs	{"scaledJob.Name": "fe-unsupervised-job", "scaledJob.Namespace": "road", "Number of pending Jobs ": 1}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Creating jobs	{"scaledJob.Name": "fe-unsupervised-job", "scaledJob.Namespace": "road", "Effective number of max jobs": 0}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Creating jobs	{"scaledJob.Name": "fe-unsupervised-job", "scaledJob.Namespace": "road", "Number of jobs": 0}
2024-08-06T11:11:38Z	INFO	scaleexecutor	Created jobs	{"scaledJob.Name": "fe-unsupervised-job", "scaledJob.Namespace": "road", "Number of jobs": 0}

THis log
KEDA Version
2.13.0
Kubernetes Version
1.28
Platform
Other
Scaler Details
ActiveMQ Artemis
Anything else?
Kindly let me know if there is any configuration missed in the spec that needs to added or modified, or any other workaround. Please treat this issue with high priority as this problem is seen in the customer deployment.
Is this issue fixed in the newer version of KEDA?

Hello
Is there any reason to use accurate as strategy? IDK how ActiveMQ works but I'd say that default is enough and should work better in your case. Are you picking & locking messages? AFAIR, ActiveMQ doesn't expose locked messages as visible.

Please treat this issue with high priority as this problem is seen in the customer deployment.

This is an OSS project and we are in summer, we will try to help as much as we can, but don't expect any kind of priority rather than the best effort. If you are in hurry, I'd suggest contacting the vendors which offers enterprise support for KEDA 😄

After setting scaling strategy to "default", it works as expected. Thank you. I am closing this issue.


Anaconda cloud now free to use

https://anaconda.cloud/
It loads a Jupyter Lab environment and it seems you can just conda install packages.
It has limits on storage/cpu but maybe a nice easy platform students can use.

Hah, well maybe nevermind. It gives you 100MB of storage on the free:

It seems like a nice snappy experience though. I guess if you pay the $9 per month it would be a good service.


wide tables

If a table contains many and/or wide columns, the data is not complete visible in the viewport of the window.
In order to let the user view those hidden columns on the right, it would require the feature to do horizontal scrolling (cursor left and right).
Below is a snapshot of your modified example code. I have repeated the columns 5 times to demonstrate it.

Thanks for opening the issue.
I'll look on how to implement horizontal scrolling.
This table bubble uses the viewport bubble internally so we may need to tackle the issue there maybe 🤔

👍  great

Currently, scrolling is by single character (left, right) ; it may take a time to see the last column values.
Would be nice to support the behaviour of what could be called PageLeft, PageRight, HomeLeft and EndRight.
For example shift + ← PageLeft,  option + → for EndRight etc.
WDYT?

Yeah, it is a little bit slow.
I'll check what we can do ;)


[BUG]dlrm script has quite a lot compatibility issues.

Script path: samples/dlrm/dgx_a100.py
Using nvcr.io/nvidia/merlin/merlin-hugectr:23.02 to run, and this error is reported:
python dgx_a100.py:
Traceback (most recent call last):
  File "dgx_a100.py", line 4, in <module>
    solver = hugectr.CreateSolver(max_eval_batches = 51,
TypeError: CreateSolver(): incompatible function arguments. The following argument types are supported:
    1. (model_name: str = '', seed: int = 0, lr_policy: hugectr.LrPolicy_t = <LrPolicy_t.fixed: 0>, lr: float = 0.001, warmup_steps: int = 1, decay_start: int = 0, decay_steps: int = 1, decay_power: float = 2.0, end_lr: float = 0.0, max_eval_batches: int = 100, batchsize_eval: int = 2048, batchsize: int = 2048, vvgpu: List[List[int]] = [[0]], repeat_dataset: bool = True, use_mixed_precision: bool = False, enable_tf32_compute: bool = False, scaler: float = 1.0, metrics_spec: Dict[hugectr.MetricsType, float] = {<MetricsType.AUC: 0>: 1.0}, i64_input_key: bool = False, use_algorithm_search: bool = True, use_cuda_graph: bool = True, async_mlp_wgrad: bool = False, gen_loss_summary: bool = True, train_intra_iteration_overlap: bool = False, train_inter_iteration_overlap: bool = False, eval_intra_iteration_overlap: bool = False, eval_inter_iteration_overlap: bool = False, device_layout: hugectr.DeviceLayout = <DeviceLayout.LocalFirst: 0>, use_embedding_collection: bool = False, all_reduce_algo: hugectr.AllReduceAlgo = <AllReduceAlgo.NCCL: 1>, grouped_all_reduce: bool = False, num_iterations_statistics: int = 20, perf_logging: bool = False, drop_incomplete_batch: bool = True, kafka_brockers: str = '') -> hugectr.Solver

Invoked with: kwargs: max_eval_batches=51, batchsize_eval=1769472, batchsize=55296, vvgpu=[[0, 1, 2, 3, 4, 5, 6, 7]], repeat_dataset=True, lr=24.0, warmup_steps=2750, decay_start=49315, decay_steps=27772, decay_power=2.0, end_lr=0.0, use_mixed_precision=True, scaler=1024, use_cuda_graph=False, async_mlp_wgrad=True, gen_loss_summary=False, overlap_lr=True, overlap_init_wgrad=True, overlap_ar_a2a=True, eval_overlap=False, use_holistic_cuda_graph=True, use_overlapped_pipeline=True, all_reduce_algo=<AllReduceAlgo.OneShot: 0>, grouped_all_reduce=False, num_iterations_statistics=20, metrics_spec={<MetricsType.AUC: 0>: 0.8025}

After I delete extra args, other interface compatibility issues are reported again.
As far as I can see, this file is updated only 2 months ago. Can you run this test successfully in your container?

Hi, which branch of hugectr did you use? I can't reproduce the problem on branch 'release-23.02' and image 'nvcr.io/nvidia/merlin/merlin-hugectr:23.02'.

Thanks!
I will check the version and retry later.
Currently I'm using ETC to train 1TB criteo data with, could you please check this issue? I'm kind of stuck in training multiple day's of data. It seems some problem with my  slot_size_array setting.


Verifying cfm bug

What this PR does / why we need it:
Which issue(s) this PR fixes (optional)
Closes #
Special notes for your reviewer:

Closing as the verification is done


build: update actions/github-script to version 6.0.0

:tada: This PR is included in version 2.0.4 :tada:
The release is available on:

GitHub release
npm package (@latest dist-tag)

Your semantic-release bot :package::rocket:


added diaper to some of the most common occurrences besides toilets

added diaper to some of the most common occurrences besides toilets
see also http://wiki.openstreetmap.org/wiki/Key:diaper

I don't see how "diaper" is a relevant term for the "Cafe" or "Restaurant" presets. Is there a particular reason you think it should be added?

Ah sorry, I misread this as adding to the search terms.

I would say it is relevant since these are one of the top places to find these.

Adding the diaper field to amenity=toilets in #2890 makes a lot of sense and I think that was a great addition to the preset.  But I think adding a diaper field to other things that happen to have toilets (like restaurants and cafes) is unnecessary, and it makes it more work to edit those other features.  We should be encouraging people to tag consistently, especially given that diaper is a relatively new tag with only about 1000 uses.  If a person really wants to add a diaper changing table to a restaurant, we should encourage them to add a node for the restroom, then tag the restroom details on that node.

There is an ongoing proposal to enhance tagging of baby changing tables. Please share with whoever may be concerned and feel free to comment:
https://wiki.openstreetmap.org/wiki/Proposed_features/baby_changing_tables


i want to add a back button on the nav Bar

Hi Sir,
First of all this is amazing and its easy to use, Thanks.
I would like to know how do i add a back button, because doing the same on the storyboard moves the name of the controllers to the right where i want to show the cancel or back button.
Also when i try to change the height of navBar to show my cancel button, the buttons are moved more upwards.
So now the changes has to be done in :
UIButton *button = [[UIButton alloc]initWithFrame:CGRectMake(X_BUFFER+i*(self.view.frame.size.width-2*X_BUFFER)/numControllers-X_OFFSET, Y_BUFFER, (self.view.frame.size.width-2*X_BUFFER)/numControllers, HEIGHT)];

 [navigationView addSubview:button];

Is there any other way around.
Thanks in Advance.

i am Sorry, my mind is not working, offcourse i can add the buttons to another view.
Thanks


Test interface

Interface working on openGL

Still needs to be generalized to remove the need for opengl folder altogether

Oops sorry I meant to merge this to my fork not to your repo


Relationship with VisualViewport

Coming here from the TAG review thread.
In terms of solving the general problem of informing the web page about occlusions, it does seem like VisualViewport is trying to solve some of the same problems, but is extremely limited (for example, it assumes the visual viewport is a rectangle).
I'm a little lost as to whether VisualViewport is intended to account for whether or not the virtual keyboard is overlaying page content or not - to me it reads as if it assumes the keyboard is overlaying page content, since otherwise it will be the same as the layout viewport.
These comments of Maciej's strike a chord:

I think Visual Viewport API could be enhanced to report individual overlay rects. That way, authors who want to adapt to available screen space won't have to juggle two different APIs. And we won't need to invent still other new APIs for other forms of onscreen overlays, like PIP, or the iPadOS Universal Callout Bar which appears even with a hardware keyboard attached.

Indeed, the "geometrychange" event is very similar to the "onresize" event on VisualViewport.
It would be a shame to miss an opportunity to design a general purpose API for these various types of screen occlusions. I wonder whether VisualViewport could contain a collection of objects with a common interface, of which virtualKeyboard could be one.
We would still need to figure out how to expose useful CSS environment variables for each one, or indeed if environment variables are the best way forward. I think the CSSWG may have some thoughts there.

In terms of solving the general problem of informing the web page about occlusions, it does seem like VisualViewport is trying to solve some of the same problems, but is extremely limited (for example, it assumes the visual viewport is a rectangle).

The VisualViewport only solves the problem of knowing when the visual viewport is changing.  It is not a general purpose reporter of occlusions and provides no information today about occlusions.  I mean specifically that things which overlay the visual viewport don't change the visual viewport and therefore don't report any events via the VisualViewport API.  Examples of things overlaying the visual viewport and therefore not affecting it include a floating keyboard, overlapping windows on the desktop, and picture-in-picture.
The user can tell when something changes the size of the visual viewport (and the layout viewport is not updated to match) because it will result in user perceivable "slop" that allows the layout viewport to be panned around in a smaller visual viewport.  Additionally, part of the layout viewport will not be visible to the user (at least not without a change in scale).
In contrast, when a window overlaps and doesn't resize the visual viewport, no such "slop" will exist.  It will be on the author to trigger an update to the layout of the page if they want content to be repositioned (assuming that there is some event to inform them of this occlusion).
In general I don't think we want to report all the things layered over top of the visual viewport.  I wouldn't want web pages updating their layout as I ALT+TAB to another application that overlaps my browser, or have a web page fight me as a drag around a floating keyboard or a picture-in-picture window.
The "docked" virtual keyboard is a special case.  When it appears, users do expect to be able to see what they're typing, but authors may not want the experience we offer by default.  L-shaped viewports aside, adjusting the visual viewport means we'll be creating the "slop" I describe above and jumping part of the page out of the visual viewport to ensure the user can see the blinking caret.  If I'm an author that has created a web application whose UI fits in 100vw x 100vh, I might rather adjust the height of one of my subscrollers rather than "unglue" my UI so that the user can start panning it around.
The VirtualKeyboard API allows the author to handle that special case by declaring that the virtual keyboard overlay the browser window instead of changing the size of its visual viewport.  Since the size of the visual viewport won't be changing in this case, I think its inappropriate for it to be dispatching any events describing that overlay.

I'm a little lost as to whether VisualViewport is intended to account for whether or not the virtual keyboard is overlaying page content or not - to me it reads as if it assumes the keyboard is overlaying page content, since otherwise it will be the same as the layout viewport.

I'm unsure exactly what you mean when you say account for it.  Maybe I answered your question already above?  If not, help me understand what you'd like to know and I can probably write a better response.

These comments of Maciej's strike a chord:

I think Visual Viewport API could be enhanced to report individual overlay rects. That way, authors who want to adapt to available screen space won't have to juggle two different APIs. And we won't need to invent still other new APIs for other forms of onscreen overlays, like PIP, or the iPadOS Universal Callout Bar which appears even with a hardware keyboard attached.

Indeed, the "geometrychange" event is very similar to the "onresize" event on VisualViewport.

I disagree on two points: one I explained above about there being no need for a general purpose overlay API, and the other is the notion that its inherently bad to create a more specialized API surface for something as important as the virtual keyboard.  You are likely aware of this complementary proposal that allows authors to hide and show the virtual keyboard.  Creating a separate VirtualKeyboard interface allows for a cohesive API surface where all things virtual keyboard related can be gathered.

We would still need to figure out how to expose useful CSS environment variables for each one, or indeed if environment variables are the best way forward. I think the CSSWG may have some thoughts there.

I'll write a separate response for this point soon.

@alice the explainer has recently been updated and includes a proposal for CSS environment variables along with examples showing how to apply them.

TAG reviewed the explainers and the discussions we had in TPAC and supported the proposal.

Just to clarify - we were happy with the show/hide policy. (https://github.com/w3ctag/design-reviews/issues/498)
We still have some concerns regarding the design when it comes to occlusions. https://github.com/w3ctag/design-reviews/issues/507 Just noticed that it was lumped together.

Just to clarify - we were happy with the show/hide policy. (https://github.com/w3ctag/design-reviews/issues/498)
We still have some concerns regarding the design when it comes to occlusions. https://github.com/w3ctag/design-reviews/issues/507 Just noticed that it was lumped together.

Reopening this issue based on this comment from @cynthia .

Reopening this issue based on this comment from @cynthia .

This has been copied into the Editing WG issues list as https://github.com/w3c/editing/issues/325


Properties of matter

Description
Create the markdown file for Properties of matter as per the reference content.
Lesson PDF (Tamil and English)
7. Properties of matter.pdf
7. பருப்பொருளின் பண்புகள்.pdf

assigning to @pndineshwaran

assinging to @Vishvahariharan


Fallback: Exceptions are wrapped in FailsafeException

Hi, my usecase is that I want to throw my own custom exception as a fallback:
Failsafe.with(retryPolicy)
   .withFallback(new CheckedConsumer<Throwable>() {
       @Override
       public void accept(Throwable throwable) throws Exception {
           throw new MyCustomException(throwable);
       }
   })
   .get(...);

The issue is that whenever I use any of the checked functional interfaces, my custom exception gets wrapped in a FailsafeException. Only when I use a non-checked functional interface like Callable my custom exception is thrown unwrapped. The problem with using Callable is that I no longer get access to the failure (Throwable), and I want to wrap the failure in my custom exception, like in my example code above.
Thanks in advance, and thanks for a great library.

Without doing a sneaky throws (which I'd prefer not to do), the only way for Failsafe to throw checked exceptions is to wrap them in FailsafeException. So for the sake of consistency, the intended behavior is to wrap all failures in FailsafeException, similar to how the executors framework wraps asynchronous failures in ExecutionException. Hopefully that works for you?
As for this behavior:

Only when I use a non-checked functional interface like Callable my custom exception is thrown unwrapped

...I'm not able to reproduce it. Can you share a little test or reproducer?

A change was just made via issue #66 where only checked exceptions are wrapped in FailsafeException now. So in your example, MyCustomException will only be wrapped if it's a checked exception. Hopefully this helps.
Closing for now unless you're still hitting any problems related to this, then feel free to reopen.

Great! thanks!

Hm... FailsafeException isn't a checked exception though. Is there a way to make Failsafe throw a checked exception?

@IevgenRagulin The drawback of making FailsafeException checked is that calling code would be forced to handle it, which is not great. An alternative would be to use the sneaky throws technique to forcefully throw checked exceptions, but that also has drawbacks. This is why Failsafe uses the current approach of wrapping checked exceptions in an unchecked FailsafeException.

@jhalterman, forcing the code to handle the exception is exactly why I would like to use a forced exception. Changing the type of the exception that was thrown prior to retries feels unintuitive. If the code has thrown an SQLException, this is what I believe Failsafe should rethrow (it's probably ok if it's wrapped in a FailsafeException, but it would be great if at least the type - checked vs unchecked remained the same)

Thanks @IevgenRagulin. While some users might prefer to have checked exceptions thrown (ex: run(CheckedSupplier<T>) throws E), most users probably do not want to have to handle checked exceptions and/or aren't using them in their Failsafe executions. And unfortunately we had to choose one approach or the other, so we chose to wrap.

It would have made the API much more complicated, too.
You could create your own utility method around the Failsafe call to unwrap your custom exception, e.g., something like this (uncompiled, untested):
public class CustomFailsafe {
    public static <R> R customGet(FailsafeExecutor<R> exec, CheckedSupplier<R> supplier) throws MyCustomException {
        try {
            return exec.get(supplier);
        } catch (FailsafeException ex) {
            Throwable cause = ex.getCause();
            if (cause instanceof MyCustomException)
                throw cause;
            throw ex;
        }
    }
}

@Tembrel love it, thank you, I think that's what I will do


Resolve symlinks if project root has them.

I use a symbolic link for my work directory (e.g go/src/github.com/my_org -> gocc) and I imagine others do as well.  This patch is intended to solve for that by resolving the symlinks before executing the project root split and avoiding the below error.
~/gocc/common(master) » dep ensure -update
split absolute project root: /Users/brianstarke/gocc/common not in any $GOPATH

I signed it!

Closing and reopening to see if failure goes away

Looks like that's a real error - we need to consider Windows portability here.

I was worried that the fail might be real.  I don't have a Windows dev environment set up at this time, but I can throw something together and see what's up.
Thanks for the review!  I'll make the changes later today.

The Windows failure isn't happening anymore, hopefully this fixes the issue.  I've not tried it on Windows yet.

This get's complicated though if the location we are also working in is in $GOPATH, along with the target. What is our package name then? The original or the target?

I might not understand your comment fully, but basically the package names shouldn't be effected by this change, it basically just uses the full path in place of the symbolic one.
If you mean the package path listed in the manifest... something like symlink/my-project would have been resolved to github.com/my-org/my-project which seems like it would be preferable.
(Also, this is a contrived example - using dep from within a symlinked directory doesn't actually work at all.)
Totally happy to provide more test cases to address your concerns, I just don't quite grok them yet.

It may not matter atm, but consider this ...
$GOPATH=~/go
current directory: ~/go/src/github.com/foo/bar
~/go/src/github.com/foo/bar is a symlink to ~/go/src/github.com/baz/bibble.
At that point, which package/project is deps with? github.com/foo/bar or github.com/baz/bibble?

I do agree that intra-GOPATH symlinking does make this seem confusing. To your example, the answer would be github.com/baz/bibble. I think the big question is in what cases other go commands would agree or disagree.

Interestingly go (1.8 anyway, older versions have various issues with symlinks and I haven't fully re-evaluated in years) handle both cases as good as can be expected, although there are some gotchas. For instance your main package that imports child packages of the project root needs to do so by name, so imagine (using the example situation above) ~/go/src/github.com/foo/bar/cmd/thing imports github.com/baz/bibble/hahaha. Is that then part of the the current project (it is, but the symlink confuses things) ? Or something that needs to be vendored? Symlinks from outside of the $GOPATH seem to DTRT with the go tool currently w/o these complications. Maybe gps just already deals with this though?

bump

Apologies, things got hectic...
The intent of this patch was only to be able to use dep from a symlinked directory, which currently just fails.  So it looks like the issue with fixing that is that expectations are set when it succeeds now, and we're not clear on what those expectations would be?

OK, let's back this up a tic, and see if we can actually enumerate the possibilities here.
When the tail element of the directory hierarchy is a symlink, I can imagine five basic possibilities:

cwd is not in a GOPATH, and the target directory is not in a GOPATH. (cwd is $HOME/code/dep, and dep -> $HOME/code/other)
cwd is in a GOPATH, and the target directory is not in a GOPATH. (cwd is $GOPATH/src/github.com/golang/dep, and dep -> $HOME/code/dep)
cwd is not in a GOPATH, and the target directory is in a GOPATH. (cwd is $HOME/code/dep, and dep -> $GOPATH/src/github.com/golang/dep)
cwd is in a GOPATH, and the target directory is in the same GOPATH. (cwd is $GOPATH/src/github.com/golang/dep, and dep -> $GOPATH/src/github.com/sdboyer/dep)
cwd is in a GOPATH, and the target directory is in a different GOPATH. (cwd is $GOPATH[0]/src/github.com/golang/dep, and dep -> $GOPATH[1]/src/github.com/golang/dep)

It seems to me that four of these have clear answers, and one's a bit murky.

For both 2 and 3, there's only one possible outcome that could work - we take the option that's in a GOPATH. This seems fine.
For 1, there's no GOPATH in sight, so that's clearly an error.
5 is a subtly different situation, but the GOPATH we're working in matters, and because we're not crazy people who delight in inviting chaos into our lives, we need to work within one GOPATH at a time. So, let's also treat this one as an error.
4 is the case @freeformz raised, and is the only one that seems a little ambiguous. Because I can't think of a real, substantial use case for doing this at the moment, I say we opt for the conservative choice and also make this one an error. Someone can always come along later and present a compelling argument, but if we allow it now without good reason, it's harder to put the cat in the bag (even if we are experimental).

That covers the cwd's tail element, which is most important here (I think). However, there's still the question of symlinks within the parent directory structure. That could be either in the cwd, or in the named target of the symlink. That is, if cwd is $HOME/code/dep, and dep -> $GOPATH/src/github.com/golang/dep, then it's possible that $HOME/code -> $HOME/other, and/or that  $GOPATH/src -> /mnt/gocode/src, or whatever.
But I'm hoping we can ignore all that, and care only about whatever the literal path identified by cwd, and the literal path pointed to by the symlink. That is, no recursive link-walking to make it all the way down to a canonical path. It seems like that would be adequate for our purposes, since our main goal here is doing name inference.
At first blush, it seems like this would cover almost all typical cases, while maybe insulating us from the unknown crazy that might happen from letting filesystems become full-on graphs. The flipside, though, is that this would put us out of line with how current go tooling works, and I'm not sure how much point there is to having the package manager work in places that the rest of the toolchain doesn't.
None of this touches on relative symlinks, of course, particularly ... I need to read https://9p.io/sys/doc/lexnames.html again.

Ah, now I get the issue with case 4.  That's a sticky wicket.  There are legitimate reasons why someone might symlink within the same GOPATH, but I agree that this should error out.  What if I check for that case, and return the same error you'd get now?

@brianstarke that sounds like a good next step.

Ok, my approach may be naive - but I split out the resolve functionality and check if real path and symbolic path are both within the GOPATH and error out.
As for cases 2,3,5 as outlined above - I'll add those to the test and make sure they work, hopefully later tonight or tomorrow - depending on how strong of a martini I make.

Not sure why the :tip build is failing, it looks like an issue with gps dependency?

Looks like a bug in tip.

I suspect this may work now, can we spark a rebuild and check?

duly kicked!

Nice!  Looks like it passes now.

quick bump 😄 i'd really like to get this in soon, after such a long delay.

Oh :poop: I didn't notice the review, my bad!  I'll hit these changes in
the afternoon.
On Thu, Apr 6, 2017 at 6:02 AM sam boyer<EMAIL_ADDRESS>wrote:

quick bump 😄 i'd really like to get this in soon, after such a long
delay.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/golang/dep/pull/247#issuecomment-292127471, or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAY4Uh1mngIy-_NsyBpthlebSkLgbW0Zks5rtLgngaJpZM4MCgsw
.

The tests are failing because fmt isn't found?  Weird.

Fixed the nits and took a swing at including all GOPATHs in the search - hopefully that's what you meant

Yep! That's what I was picturing. 🦄
Let's get one last test case in to cover the situation where the link points to a different GOPATH, then we're good to go.

bump for laaaaast little bit 😄

Sorry!  I'm on vacation and didn't pick up a laptop until tonight.  I added a case within the current test.

OK, LGTM, merging. Thanks so much, and double-thanks for your patience through the process!


Always use Job/Agent id as secondary order key

When ordering agents or jobs by non-unique keys, the ordering of items
with equal values for that key among themselves is not stable, and may
change between requests.  This breaks pagination.  By always using the
id as a secondary order key, we can avoid that problem.

Makes sense to me, I thought using last_heard_from as the secondary order_by made sense but that's something we may already be ordering by depending on the request.

last_heard_from may change between requests, and since agents keep reannouncing themselves and the master keeps polling them, there's a reasonable likelihood that it will.


Doc for non self-contained aggregate application

Resolves #818

Would you mind adding more info what non self-contained actually means. There is the sample PR for this which I didn't merge as it's missing readme for same reason. Maybe non self-contained is wrong wording as at least I don't connect with its meaning. It may be obvious to you but not to me.

@jvalkeal sure thing.

Thx, much better. Merging...

Squashed/merged per https://github.com/spring-cloud/spring-cloud-stream/commit/347cac75f2bd2d8a61dba2f8332f3502ddc374f6