python311Packages.linien-common: fix build by using rpyc4

Motivation for this change
Things done

Built on platform(s)

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

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

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

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

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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 283482 run on x86_64-linux 1

2 packages marked as broken and skipped:

python312Packages.linien-client
python312Packages.linien-client.dist

4 packages failed to build:

python312Packages.linien-common
python312Packages.linien-common.dist
python312Packages.rpyc4
python312Packages.rpyc4.dist

8 packages built:

linien-gui
linien-gui.dist
python311Packages.linien-client
python311Packages.linien-client.dist
python311Packages.linien-common
python311Packages.linien-common.dist
python311Packages.rpyc4
python311Packages.rpyc4.dist

Thanks for the report :) I disabled rpyc4 for python versions >=3.12.


Merge SMC and PG?

Is it possible to somehow merge the code of SMC and PG and let SMC run as PG with iteration num = 1

Yes, that sounds possible. We used to have two different replaying mechanisms (TraceR, TraceC) for SMC and PG, but this does not seem necessary anymore.

[ ] Make Trace produce vi instead of weights.

Closing now since particle samplers have been refactored into AdvancedPS.jl

Closing now since particle samplers have been refactored into AdvancedPS.jl


Just some Grammar

NOTE: Only file GitHub issues for bugs and feature requests.  All other topics will be closed.
For general support from the community, see StackOverflow.
To make bugs and feature requests more easy to find and organize, we close issues that are deemed
out of scope for GitHub Issues and point people to StackOverflow.
For bugs or installation issues, please provide the following information.
The more information you provide, the more easily we will be able to offer
help and advice.
What related GitHub issues or StackOverflow threads have you found by searching the web for your problem?
Environment info
Operating System:
Installed version of CUDA and cuDNN:
(please attach the output of ls -l /path/to/cuda/lib/libcud*):
If installed from binary pip package, provide:

A link to the pip package you installed:
The output from python -c "import tensorflow; print(tensorflow.__version__)".

If installed from source, provide

The commit hash (git rev-parse HEAD)
The output of bazel version

If possible, provide a minimal reproducible example (We usually don't have time to read hundreds of lines of your code)
What other attempted solutions have you tried?
Logs or other output that would be helpful
(If logs are large, please upload as attachment or provide link).

I'm assuming this is the retraining tutorial, the grammar seems to be fixed at head -- https://github.com/tensorflow/tensorflow/blob/4172ca2cd7ac34be67bda2600944d284e8907b95/tensorflow/g3doc/how_tos/image_retraining/index.md


ExtractS3HTMLFlow

A new HTML flow to allow S3 download

@SayaZhang Could you please help review this PR.


use of puppet agent --enable and puppet agent --disable

I'm investigating mcollective and it is aware of the Puppet3 --enable and --disable flags.
root@test3:~# puppet agent --disable "this is a test message"
root@test3:~# cat /var/lib/puppet/state/agent_disabled.lock
{"disabled_message":"this is a test message"}#

using these flags allows mcollective to perform puppet runs on enabled hosts but not disabled hosts. in my current infrastructure using puppetctl, mcollective will run on puppetctl disabled hosts.
puppet agent --disable isn't as smart as puppetctl: there's no timed disables or motd modification.
if I wind up modifying puppetctl to support mcollective, are you interested in including the changeset in upstream? I think it might be as simple as also doing a puppet agent --{en,dis}able for the corresponding puppetctl actions.

doing a scrub of my open Github issues...
I've been running this in production for over a year now. I don't think I've had any problems.
are there any updates from Mozilla that you can publish? no new updates since Sep 2013!

Yeah of course. I'll push an update now. Although, we're still not using puppet's internal enable and disable toggle as we run puppet from cron.

I've been building a lot of automation with mcollective, but so far, I don't think I actually need the puppet mco agent at all. massive Puppet runs cause all kinds of bottlenecks (VM disk IO, HTTP request timeouts on Puppetmaster, HTTP requests/disk IO on rpm repos, etc).
I could probably remove the --enable/--disable stuff with no negative impacts. in fact, it annoys a few of my team mates because puppet agent --test --noop will refuse to run in disabled state!

I just merged an update for you

awesome. I currently have a lot of disabled hosts, so I might not push it out for a few weeks.
are you able to explain why the path was changed? just good housekeeping?

There is a comment inside puppetctl explaining the reason for the change. On RHEL /var/run is cleared at boot, so that had the unintentional side effect of re-enabling puppet. It wasn't a common use case, but it was a surprise for sure.


SecurityAlert status not updating

Problem
The Security Alert table does not always update the status of an alert, especially not for Sentinel.
Duplicate
Create an Incident, change the incident status, close the incident. wait for days to see that the status has not changed within The Security Alert table.
Example

Disclosure
I'm unsure whether this is supposed to be closed by Product side, but even if it is supposed to be closed product side the sentinel alerts should say dismissed/closed.

@oshezaf and @Ronmarsiano - Can you please have a look.

@Lodewyk-Git : alerts in Sentinel are immutable. Specifically, Sentinel alerts are never closed. The "managed" entity which is assigned or closed is the incident, and you should query the incident table. For details refer to https://docs.microsoft.com/en-us/azure/sentinel/manage-soc-with-incident-metrics

@oshezaf Hi Ofer, the problem here is that when you change the properties of an incident it adds duplicate rows to the SecurityIncident table.
Screenshot


remove cargo Lock from the repo

While this makes sense for an executable, for the library we do not want to tie to specific points.
Depends on #238

I kind of disagree here. Libraries also have upstream dependencies.
Without a cargo.lock any incompatible changes in upstream dependencies would break things.
Maybe I am missing some details?

We're still open to discussion, but the basic ideas behind this is:

Each application will chose their own dependencies on an application-by-application case
The SDK part (cardano, cardano-storage, cardano-network, ..) is really striving to have minimum dependencies as possible; we'll very likely will remove things, than add dependencies in the future.
With less dependencies, we should lower the incidences of incompatible changes in upstream dependencies
If upstream dependencies have incompatible changes, it's very likely we need to catch up anyway; maybe having to do it sooner than later is not a bad plan

In general terms, I would assume any SDK I rely on has gone through integration testing and has been verified to work with a set of upstream dependencies. SDKs promise both reliable interfaces and behavior. If dependencies are not well defined, the problem is passed to every single application that depends on the SDK. This means a lot of trouble, specially to anyone that has experienced configuration management issues.
Moreover, I assume that the SDK will be published as a crate. Something standard in the rust world. And crates are very clear about their requirements at the moment of being published.

The dependencies semantics defined in Cargo.toml is independent from the Cargo.lock which pin down specific dependencies. We're not planning to remove the Cargo.toml or not maintain the dependencies properly.

Yes, I get that. Without the lock, continuous integration results are not really reproducible, however, locking can result in multiple different copies being used, etc.
I guess that you are not planning to release any binaries in this project, just source code, so I see why it makes sense. I suppose that executables/deliverables in binary form will then be moved out from this project, right?

correct. we already have https://github.com/input-output-hk/cardano-cli as our first real application where we'll have the right thing pin down; more repositories will follow, likely in the same spirit.


Login improvements

Improvements to the logic of the login. Now it will use the ID and TOKEN information if they are present, avoiding one round trip to github.

Should close issue #43


flv运行报错

{"path":"/group/door","rurl":"rtsp://<IP_ADDRESS>:554","type":"pull"}
ERROR 2022-03-17 17:36:36.912308 github.com/cnotch/ipchub/service/flv/httpflv.go:67: http-flv: stream not support flv
系统ubuntu20.04

The RTSP must have video stream and only support H264 or H265 video stream. You can add some debug logs for better diagnostics

The RTSP must have video stream and only support H264 or H265 video stream. You can add some debug logs for better diagnostics


feat: primitive TypeScript support

This PR enables primitive TypeScript support by:

processing .js and .ts files
adding esdoc-typescript-plugin

This solution is not perfect, but good enough to at least enable documenting TypeScript code, until ember-cli-addon-docs-typedoc is or ember-cli-addon-docs-tsdoc are a real thing.

It seems that for TypeScript files all @tags are ignored.
For instance, this yields:
class Foo {
  /**
   * this is method3.
   * @param n - this is the param desc.
   * @return this is the return desc.
   * @private
   */
  private method3(n: number): string {}
}

Aha! https://github.com/esdoc/esdoc-plugins/issues/25
class Foo {
  /**
   * @desc this is method3.
   * @param n - this is the param desc.
   * @return this is the return desc.
   * @private
   */
  private method3(n: number): string {}
}

However, this the breaks the type information.
(The @private tag is also not automatically inferred.)

There also seems to be trouble with Generics<T> and <Type>casts: https://github.com/esdoc/esdoc-plugins/issues/74

@buschtoens @tstormk do either of you know if enabling the TS plugin effects normal JS output from ESDoc at all? This looks fine to me, but I would like to double check we are not messing anything up for JS users.

Can we cut a release with this improvement? I tested in a fairly large project which migrates some .js to .ts, and this PR works pretty well.

@nightire I mainly wanted to make sure it did not break plain JS. Does it work well for both vanilla JS and TS for you?

@rwwagner90 Yes, it works well for both vanilla JavaScript and TypeScript.


Change title of "A brief introduction to the bash shell" module

Work to be done
We can consider removing "bash" from A brief introduction to the bash shell module title. Possible suggestions:

"A brief introduction to the shell"
"A brief introduction to the terminal"

The rationale for this is that some people use other shells like zsh, especially on Macs where zsh is the default shell starting with macOS Catalina.
The module's exercise seems already compatible with both bash and zsh.

The choices of software used at brainhack school are very intentional and opinionated.
To accommodate this change means all the developed material will have to change.
What I would suggest is to edit the installation module for mac and show how people can use bash shell as default. Of course this will not effect the evaluation of the course if people wish to use any other shell.

@FrancoisPgm is a Mac user, do you have something to chip in?

The differences between bash and zsh are minor, everything presented in the module is compatible with both. I agree that renaming the module to somthing like "A brief introduction to the terminal" would be a bit more evocative to newcomers, and it would prevent people on mac to unnecessarily install bash in addition to zsh. We can briefly mention the existance of the main shells (bash, zsh and powershell) and state that the module is meant to be used on bash compatible shells, including zsh, excluding powershell.


Error

librealsense
2.51.1 RELEASE

OS
Windows

Intel RealSense Viewer / Depth Quality Tool has crashed with the following error message:
Unhandled exception escaping from a worker thread!
Error type: Access Violation!

Hi @Nimma-shravan-kumar-reddy  Does this error occur as soon as the RealSense Viewer is launched or when making an option change such as enabling the depth stream, please?  For example, in https://github.com/IntelRealSense/librealsense/issues/10249 a RealSense user found that it would occur for them when selecting 1920x1080 as the depth resolution.

Now I don't see the error message.
On Thu, Sep 1, 2022, 10:33 AM MartyG-RealSense @.***>
wrote:

Hi @Nimma-shravan-kumar-reddy
https://github.com/Nimma-shravan-kumar-reddy Does this error occur as
soon as the RealSense Viewer is launched or when making an option change
such as enabling the depth stream, please? For example, in #10249
https://github.com/IntelRealSense/librealsense/issues/10249 a RealSense
user found that it would occur for them when selecting 1920x1080 as the
depth resolution.
—
Reply to this email directly, view it on GitHub
https://github.com/IntelRealSense/librealsense/issues/10856#issuecomment-1234368064,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ALQDIA7FYOHYDCIZJ22QMDTV4C5E5ANCNFSM6AAAAAAQCM3FWU
.
You are receiving this because you were mentioned.Message ID:
@.***>

Hi @Nimma-shravan-kumar-reddy  Do you require further assistance with this case, please?  Thanks!

Case closed due to no further comments received.


Fixed #57 caused by overflow in length_hint while reading sprite data

While reading some sprite data using ByteConvertable proc_macro, a helper attribute is used to give hints about the length of the buffer containing data of RgbaImageData. This hint was being calculated multiplying width and height attributes of said struct, both declared as u16, and causing a overflow while calculating the total size of the buffer.
In order to calculate the size of the buffer, both parameters are casted to u32 before the multiplication.

Good catch, is this related to #57?

As for the code: I would prefer casting to a usize since that is what is happening behind the scenes as well.
Also there are in total 4 occurrences of #[repeating(self.width * self.height)] in the code base, three in the sprite loader and one in the map loader. It would be awesome if you could fix the other ones as well

Good catch, is this related to #57?

I think so. Bug appeared on a particular sprite that, coincidentally, had version 2.1. This got me thinking the bug was about RLE encoding. However, RLE decoding happens while reading EncodedData from PaletteImageData.
Anyhow, once this patch has been applied, the conflicting sprite seems to work okay-ish, despite presenting some visual glitches in some frames. But this PR fixes the crashes thus improving stability.


Don't merge before Circle CI tests pass: Re-enable Android e2e test

Disabled earlier today, a fix for HMR landed so let's test it works.
Test plan: Circle CI tests pass on this PR.

Looks good! ^_^


Webpack's worker loading is failing with PR builds

The puppeteer performance tests are failing on PR builds because the worker entrypoint assets aren't being requested with the branch_name URL param.

Closed by #1818


Clean up typos and grammar a bit

Just nitpicky fixes really.

Thank you! Just wrote it down in one go and didn't proof read it :D


https://kubernetes.io/zh/docs/concepts/ page not updated

This is a Bug Report

Problem:
https://kubernetes.io/zh/docs/concepts/ this page is not updated. Chinese content not correspond to English version.
Proposed Solution:
Update Chinese version page
Page to Update:
https://kubernetes.io/zh/docs/concepts/

The existing Chinese page is different and (slightly) misleading.
/kind bug
/language zh
/priority backlog

I've been working on it.
/assign

Done.
/close


Why does the entrypoint script copy files to /var/www, when the image build could do that?

Dear maintainers,
while trying to get OpenCost running on OpenShift, I had a look at the UI image.
Once thing I noticed is this line:
https://github.com/opencost/opencost-ui/blob/459ddc5a5005a575a382379c25a7a39785c29930/docker-entrypoint.sh#L4
Why is this not part of the image build process? Why is done at runtime (which requires write permissions to /var/www/ which causes problems on e.g. OpenShift?
Or, if I understand this line from the Dockerfile properly, why is this done again in the entrypoint?
COPY --from=builder /opt/ui/dist /var/www

https://github.com/opencost/opencost-ui/blob/main/Dockerfile#L30
Kind Regards,
Johannes

Checked on it further. Seems like this was done to allow opencost-ui to run in a read only file system https://github.com/opencost/opencost-ui/commit/dbfea70e43f101d207e997a1cb486cead89083eb
Also to the question on https://github.com/opencost/opencost-ui/blame/main/Dockerfile#L30
I am not sure how this line has been added there. as according to this commit the Dockerfile had overwritten that line this year itself. Then from where is blame telling me that it was a 2 year old change.


Add experiments on spherical clusterings of DCSBM embeddings

Reference Issues/PRs

Closes #602
What does this implement/fix? Briefly explain your changes.
Adds experiments performed on spherical clusterings of DCSBM

@bdpedigo I just created a PR with my Notebook and the experiments performed. Let me know what you think :  )


Discussion: how many kubernetes versions should we support directly?

As we generate images based both on the kubectl version (directly tied to the Kubernetes release version) and the version of this tool, we need to decide how many versions of Kubernetes we should support.
I mean the MINOR version numbers - so, for example, LATEST is currently 1.13.4, LATEST-1 is 1.12.6 - at time of writing.
My suggestion is to support LATEST, LATEST-1, LATEST-2 at their highest PATCH version level.
This would involve creating version branches for the MINOR k8s, and applying tags in these branches, after backporting new features.
We would create branches 1.13, 1.12, and 1.11 and figure out the easiest way to port changes to them.
Thoughts?

For example, what other versions should actually be included in #22 ?

A few notes:

AFAIK, the upstream Kubernetes project supports 4 minor versions including the latest release, currently 1.13, 1.12, 1.11, 1.10. Using something older than 1.10 means that we can't receive patches for critical bugs if any.

Also, if you rely on a new feature only available in recent kubectl versions, it raises the lower version req. In case you rely on kubectl apply to configure any field relevant to "alpha" features of Kubernetes, it raises the lower ver req as well, because kubectl get -o yaml something --export | kubectl apply -f - throws away all the fields unknown to the old kubectl!

That being said, can we safely use the oldest possible kubectl and only release one docker image per the project version, not per kubectl?
If I remember correctly, I think it was me who introduced the current versioning scheme for kube-spot-termination-notice-handler? Shamelessly throwing away my previous decisions and habits, can we just start from a semver 1.0.0 PLUS the rule to use the oldest supported kubectl ver, which will result in tags like the followings?

kubeaws/kube-spot-termination-notice-handler:1.0.0 (includes the oldest supported kubectl at the time
kubeaws/kube-spot-termination-notice-handler:1.1.0
kubeaws/kube-spot-termination-notice-handler:1.1.1

It was me that introduced the current naming, I think.. 😉
Happy to switch to a semver scheme like you propose.
To clarify, we will only generate one image, being for the "oldest supported kubectl" (1.10.x at time of writing).
Version increments

Each time kubernetes releases, we will increment the major version number.
Each time we add a feature to the tool itself, we'll bump the  minor number, and
for any bugfix or security patch, we increment the patch number.

Correct?


When Import Purl Metadata jobs fail due to data validation the operation should be marked as failed but the job should succeed (or at least not returned to the queue)

When a worker processes an Import Purl Metadata job, if validation of the data to be imported fails, the operation should be considered a failure and marked as such in the database. Given that we know the data is bad, there is no reason to return the job to the queue and have it fail again for the same reason. This eventually results in the job landing on the dead letter queue.
As long as the fact that the import failed (for a known reason) is captured as part of the operation output, there is no reason for the job itself to be retried or be pushed to the dead letter queue.

The import purl job is not in this repository. it's in projecthyra-labs/hyku.  In that job all the data is coming from the PURL service, which should always have titles (right @atz?), so if its complaining about missing a title, the true cause is probably something else entirely. Can you please send a logged backtrace of where you are seeing these errors or otherwise let us know how to duplicate this issue?

Duplicate of https://github.com/projecthydra-labs/hyku/issues/621 ?

https://github.com/projecthydra-labs/hyku/issues/621 does appear to be the issue that resulted in this ticket being created. While it would be great to fix the source data, the primary purpose of this ticket is to consider how the import job should operate when it encounters input data that is not valid. The assumption here is that we will usually not have control over the source data, so we want to expose validation problems in a way that allows the data owner can resolve them and also have the import function not cycle unnecessarily on known bad data.
If this ticket belongs under the hyku project, I'd be happy to move it there.

@bbranan the Import from purl job is not a general purpose tool. It is specifically used for collecting data from stanford for the purpose of testing the site.  It is not something that anyone will be using in production.

Deciding to close this issue since it's a concretion of #358, which is now post-MVP, plus this job is only for Stanford-specific testing.


SOLR-17145: Add 'requestid' to INSTALLSHARD response

https://issues.apache.org/jira/browse/SOLR-17145
Description
Many Solr 'admin' APIs that can be run asynchronously include a 'requestid' field to echo the identifier back to users.  This isn't strictly necessary as these identifiers are user-provided anyways, but it is a nice quality-of-life thing that some users rely on.
Unfortunately, INSTALLSHARDDATA breaks this norm and doesn't include the field.
Solution
This commit adds the missing field to the response.
Tests
N/A
Checklist
Please review the following and check all that apply:

[x] I have reviewed the guidelines for How to Contribute and my code conforms to the standards described there to the best of my ability.
[x] I have created a Jira issue and added the issue ID to my pull request title.
[x] I have given Solr maintainers access to contribute to my PR branch. (optional but recommended)
[x] I have developed this patch against the main branch.
[x] I have run ./gradlew check.

Tests and check pass, will aim to merge in a few days if no one has feedback.


No transpiler support for export of default components

Probably need to better handle errors when the component hasn't been transpilled. Current error cannot read property soandso of undefined isn't helpful.

Pretty sure this was fixed, but please reopen if it's still a problem.


Performance Update

Fixed a bug where particles were not removed when they were no longer needed, resulting in spamming the memory with unused table entries.
Synced the pdParticles.lua lib in the example folders with the main pdParticles.lua.
Added a new function total() that returns the total number of particles in the table.

I updated the pdParticles.lua files in the examples to sync them with the main pdParticles.lua. I hope that is okay...


fix(runtime-core): ensure app instance can be garbage collected after unmount. (close #2907)

When unmounting an app, we need to remove the __vue_app__ property from the container element, otherwise the app instance can't be garbage collected for as long as that element exists.
closes #2907

will send a new, clean one.


Transparency Visual Bug / Alpha Artifact

Bevy version
0.6.1
Operating system & version
Fedora Linux 35 (Workstation Edition), 64-bit
Gnome 41.5
Wayland Windowing System
What you did
I have a sprite with a transparent background. The transparent part looks 'glitchy'
I'm attaching a screen capture of how it looks.
It seems like this bug only happens specifically on my PC.
Also, I have another machine that also runs Fedora and the bug doesn't happen there, so my guess is that it has to do with the hardware I'm using, or the very specific combination of hardware and software.
Hardware Specification
Hardware Model:
Micro-Star International Co., Ltd. MS-7C77
Processor:
Intel® Core™ i7-10700T CPU @ 2.00GHz × 16
Graphics:
Mesa Intel® UHD Graphics 630 (CML GT2)
Examples:
https://user-images.githubusercontent.com/103264822/162453261-843e51c4-2b59-48f9-94b2-9e8780803d88.mp4

It would be useful if you can try to see if the issue also occurs with the latest bevy from the git main branch. Or, you could also wait a little, as 0.7 is planned to be released in a few days / next week, and test it with Bevy 0.7 when it comes out.
I suspect it would (I don't remember an issue like yours being encountered and fixed), but a confirmation would be nice. 0.6 is kinda old at this point.

Looks like a duplicate of #3593

Looks like a duplicate of #3593

ahh thanks, disabling MSAA fixed it : )


Revised design for status codes

A comment from @markcowl on my cadl-autorest changes for status codes made me rethink the approach we've implemented in the core. He raised concerns about using "default" as a status code value.  Given that we have implemented @statusCode in the http library, I think this concern is warranted. We should restrict @statusCode to just values consistent with the http standard, and not mix in OpenAPI concepts.
So I propose:

Moving the validation of the status code value to the http library. I think it is a good general practice that the implementing library should define and enforce that values / meaning of its arguments -- and it eliminates the duplicate validation logic we have today across several emitters.

Introducing new decorators in the OpenAPI emitter for "pseudo-status-codes": @default, @2XX, @4XX, @5XX (possibly others). These decorators would only be valid on models. When present on a model used as a return type, the OpenAPI emitter will:

Issue a diagnostic if the model also contains a status code
Otherwise it will use the corresponding "pseudo-status-code" to define the response.

I can hear you asking: How will this interact with the @error decorator? I think:

If both @error and an "pseudo-status-code" decorator are both present, the response key will be set based on the "pseudo-status-code" (on the principle that it is more explicit).
@error alone without a status-code will use response "default"

I wonder in which scenario we prefer to use "pseudo-status-codes" to define a response model
As if we implement @error  per  https://github.com/microsoft/cadl/issues/155 , we already have a mechanism about when to  generate the "default" error response in swagger

I agree that we could use @error to specify the "default" response -- and in the absence of anything else we should make @error be "default".  But I think we want an explicit mechanism for this. We have said many times that we want to avoid "magic". This was  our rationale for requiring http verbs to be specified explicitly. I think the same rationale applies here.

Fixed in #199 and #210.


Update test script to run package tests in parallel

From a few runs, running process in parallel speeds up testing time by 46%
Before:
ok  	github.com/Comcast/webpa-common/concurrent	2.147s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/conlimiter	2.984s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/device	8.739s	coverage: 77.0% of statements
ok  	github.com/Comcast/webpa-common/fact	1.040s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/garbagetruck	1.021s	coverage: 9.1% of statements
ok  	github.com/Comcast/webpa-common/handler	1.061s	coverage: 92.9% of statements
ok  	github.com/Comcast/webpa-common/hash	1.029s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/health	1.055s	coverage: 92.0% of statements
ok  	github.com/Comcast/webpa-common/httperror	1.038s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/httppool	4.192s	coverage: 96.3% of statements
ok  	github.com/Comcast/webpa-common/httppool/health	1.038s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/logging	1.033s	coverage: 69.4% of statements
ok  	github.com/Comcast/webpa-common/logging/golog	1.703s	coverage: 0.0% of statements
ok  	github.com/Comcast/webpa-common/resource	1.063s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/secure	1.140s	coverage: 89.0% of statements
ok  	github.com/Comcast/webpa-common/secure/key	1.301s	coverage: 90.5% of statements
?   	github.com/Comcast/webpa-common/secure/tools/cmd/jwt	[no test files]
?   	github.com/Comcast/webpa-common/secure/tools/cmd/keyserver	[no test files]
ok  	github.com/Comcast/webpa-common/server	1.061s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/service	1.553s	coverage: 94.6% of statements
?   	github.com/Comcast/webpa-common/service/cmd/endpoint	[no test files]
ok  	github.com/Comcast/webpa-common/store	2.138s	coverage: 97.9% of statements
ok  	github.com/Comcast/webpa-common/types	1.022s	coverage: 83.3% of statements
?   	github.com/Comcast/webpa-common/webhook	[no test files]
ok  	github.com/Comcast/webpa-common/webhook/aws	1.036s	coverage: 90.0% of statements
ok  	github.com/Comcast/webpa-common/wrp	1.104s	coverage: 100.0% of statements
It took 298 seconds to finish running tests

After:
?   	github.com/Comcast/webpa-common/secure/tools/cmd/jwt	[no test files]
ok  	github.com/Comcast/webpa-common/types	1.030s	coverage: 83.3% of statements
ok  	github.com/Comcast/webpa-common/garbagetruck	4.033s	coverage: 9.1% of statements
ok  	github.com/Comcast/webpa-common/logging/golog	1.034s	coverage: 0.0% of statements
ok  	github.com/Comcast/webpa-common/concurrent	2.173s	coverage: 100.0% of statements
?   	github.com/Comcast/webpa-common/webhook	[no test files]
ok  	github.com/Comcast/webpa-common/logging	1.049s	coverage: 69.4% of statements
ok  	github.com/Comcast/webpa-common/hash	1.089s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/httperror	1.049s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/resource	1.098s	coverage: 100.0% of statements
?   	github.com/Comcast/webpa-common/secure/tools/cmd/keyserver	[no test files]
ok  	github.com/Comcast/webpa-common/conlimiter	1.837s	coverage: 100.0% of statements
?   	github.com/Comcast/webpa-common/service/cmd/endpoint	[no test files]
ok  	github.com/Comcast/webpa-common/secure/key	1.354s	coverage: 90.5% of statements
ok  	github.com/Comcast/webpa-common/health	1.084s	coverage: 92.0% of statements
ok  	github.com/Comcast/webpa-common/httppool/health	1.053s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/webhook/aws	1.058s	coverage: 90.0% of statements
ok  	github.com/Comcast/webpa-common/store	2.151s	coverage: 97.9% of statements
ok  	github.com/Comcast/webpa-common/secure	1.289s	coverage: 89.0% of statements
ok  	github.com/Comcast/webpa-common/server	1.086s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/service	2.054s	coverage: 94.6% of statements
ok  	github.com/Comcast/webpa-common/httppool	5.870s	coverage: 96.3% of statements
ok  	github.com/Comcast/webpa-common/wrp	1.118s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/fact	1.040s	coverage: 100.0% of statements
ok  	github.com/Comcast/webpa-common/handler	1.057s	coverage: 92.9% of statements
ok  	github.com/Comcast/webpa-common/device	7.925s	coverage: 77.0% of statements
It took 136 seconds to finish running tests

Codecov Report

Merging #273 into master will not change coverage.
The diff coverage is n/a.

@@           Coverage Diff           @@
##           master     #273   +/-   ##
=======================================
  Coverage   68.14%   68.14%
=======================================
  Files         160      160
  Lines       10680    10680
=======================================
  Hits         7278     7278
  Misses       2694     2694
  Partials      708      708

Impacted Files
Coverage Δ

device/device.go
71.11% <0%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


fixed pytest warning

PytestDeprecationWarning: The hookimpl LoggerPlugin.pytest_runtest_makereport uses old-style configuration options (marks or attributes).
Please use the pytest.hookimpl(hookwrapper=True) decorator instead
to configure the hooks.
See https://docs.pytest.org/en/latest/deprecations.html#configuring-hook-specs-impls-using-markers

can this be merged?

Sure, let's merge this :+1:

@aurzenligl can you please create new version with above change? I see the warning and it might lead to failure in later version of pytest

@jthakurH, I'm working on ci (github workflows) and soon will release new pytest-logger

@jthakurH, infrastructure modernized, 1.0.0 released along with the fix.

Awesome. Thanks @aurzenligl


NEST client is failing to Index documents larger than 700MB

NEST/Elasticsearch.Net version: 7.14.1
Elasticsearch version: 7.14.1
.NET runtime version: 4.8
Operating system version: Windows Server 2016
Description of the problem including expected versus actual behavior:
NEST client is failing to Index documents larger than 700MB with System.ArgumentOutOfRangeException exception
Expected behavior
Should successfully index 1GB document as Lucene Index/Elasticsearch shard is capable of Indexing till 2GB per document
Stack trace:
System.ArgumentOutOfRangeException: Too many characters. The resulting number of bytes is larger than what can be returned as an int.|
Parameter name: charCount|
at System.Text.UTF8Encoding.GetMaxByteCount(Int32 charCount)|
at Elasticsearch.Net.Utf8Json.JsonWriter.WriteString(String value)|
at Elasticsearch.Net.Utf8Json.Formatters.NullableStringArrayFormatter.Serialize(JsonWriter& writer, String[] value, IJsonFormatterResolver formatterResolver)|
at Serialize(Byte[][] , Object[] , JsonWriter& ,  , IJsonFormatterResolver )|
at Elasticsearch.Net.Utf8Json.Resolvers.DynamicMethodAnonymousFormatter`1.Serialize(JsonWriter& writer, T value, IJsonFormatterResolver formatterResolver)|
--- End of inner exception stack trace ---|
Observation:
While serializing the input document represented by POCO using Utf8Json, a call(System.Text.UTF8Encoding.GetMaxByteCount) is made to calculate the max number of bytes that will be produced after encoding the characters
where the estimate representing that max count roughly assumes the value of input length times 3 (as code points from the basic multilingual plane will be encoded to 1-3 bytes) and is finally made to throw an ArgumentOutOfRangeException exception if the value is larger than 0x7fffffff(2GB) thus the overall call will fail if we are focusing on anything larger than 2GB/3(~680MB).(https://github.com/microsoft/referencesource/blob/master/mscorlib/system/text/utf8encoding.cs). Is there any way to deal with documents larger than 680MB with the Elasticsearch .NET client?

Hi, @EVINDX. This is unfortunately a limitation in the encoding API the serialization path relies on, which is limited to returning a max size of int.MaxValue as the length. Please see #5172 which also details the same limitation. There are some links there for guidance on splitting large data into multiple documents.
For 7.x, I don't think there's anything we can practically do to enable this scenario. A potential workaround you could attempt is to implement and register your own source serializer where you can fully control how the data is serialized. For v8 we're moving to depend on System.Text.Json which may avoid this limitation, although I've yet to test that capability.

Hi, @stevejgordon. Thank you for the clarification, we will explore these options and take favorable action accordingly.


Fundamentally change how RxEspresso increments/decrements counter

Instead of every subscription incrementing the counter, any class can now call RxIdlingResource.increment(). Instead of decrementing on every stream completion/error, we now decrement only for completion/error on the main thread.

Not happy with these changes. Dumping this for #12 instead.


Fix minor typos in comments

Thanks very much for go-sqlite-3 -- I used it to build rqlite. While reading the docs, I noticed some small typos. Here are the fixes, but feel free to close if you prefer.

Commit history fixed up.

thank you


QR Scanner

Goal:
Staff and attendees will need to scan QR codes during HackIllinois. This feature will be accessed by clicking the middle button in the navbar. Then, a QR scanner should pop up.
Steps:

Replace HICodePopupViewController with a new view controller for scanning QR codes. Reference the code in HIBaseScannerViewController, HIEventScannerViewController, and HICheckInScannerViewController for this.
Save the data from the QR code locally.
Create a dropdown picker for selecting the event that you are scanning for. For now, make the fields the name of every event. The code for fetching the events is in HIScheduleViewController.
Filter the events. Staff will be scanning for check-in and meals. Attendees will scan all other events. Each event has an event type. We can use this event type to do the filtering.

Note: attendees won't need a dropdown picker since the QR code that they scan will identify the event that they are attending.
Endpoints:
POST /checkin/ - Staff checking in attendees at the beginning. Refer to CheckInService in HIAPI for this request.
POST /event/track/ - Staff scanning for meals. Needs eventID and userID
POST /event/checkin/ - Attendees scanning for workshops, QNA, etc. Needs eventCode (acquired from scanning QR code).
(There already is code for calling these endpoints)
Additional Comments:
No need to worry about the design for this pop-up.

Branch created with first two steps completed - https://github.com/HackIllinois/iOS/tree/aryan/qr-scanner

Been merged.


Android -> disabled prop can't be toggled

Environment
Binaries:
Node: 16.17.1
Yarn: 1.22.19
npm: 8.15.0
Watchman: 20220924.070135.0
npmPackages:
@react-native-community/cli: Not Found
react: 18.2.0 => 18.2.0
react-native: 0.69.7 => 0.69.7
react-native-windows: 0.69.14 => 0.69.14
Description
In the example app example\src\Examples.tsx at the Disabled slider section, if you toggle the disabled prop, it will get stuck on always being active.
E.g
  {
    title: 'Disabled slider',
    render() {
      return <SliderExample disabled={true} value={0.6} />;
    },
  },

to:
  {
    title: 'Disabled slider',
    render() {
      return <SliderExample disabled={false} value={0.6} />;
    },
  },

to:
  {
    title: 'Disabled slider',
    render() {
      return <SliderExample disabled={true} value={0.6} />;
    },
  },

Doing the above enough times will result in the slider being stuck as enabled.
Reproducible Demo
This is reproducible in the example app.

Hello @cgibson-emesent!
Thank you for checking on example app and taking the time to report - I'm surprised I didn't notice that issue, so thanks!
I'll take a look into that.

Hello @cgibson-emesent!
Unfortunately I have some troubles reproducing the issue you reported. I'm attaching the video of my tries below, so you can verify if I get the scenario right:
https://user-images.githubusercontent.com/70535775/215532170-1ca730b3-8dc5-4700-95e2-1739c9fd942c.mov
Please let me know if you are able to still see the issue and please post a full repro code so I can try it out.
Just in case: you can always clone the rn-slider-repro-app and check this issue on your own setup so we have a common playground.

Thanks for looking into that @BartoszKlonowski. I'm trying to create a project that reproduces the issue. At the moment though on two projects, the disabled prop isn't working on Android. As in, hard coding disabled={ true } doesn't disable the slider. So I'm trying to work out if that's a bug or not.

@BartoszKlonowski I haven't had a chance to replicate this and I've since moved to another plugin because I needed to change the thumb size and click zone which this plugin doesn't support.


Add Zebra Puzzle exercise

Forum thread: https://forum.exercism.org/t/add-zebra-puzzle-exercise-48in24/10368
Note that I've disabled a RuboCop rule in part of the example solution. LMK if that's something we should avoid.

Sorry if the force push was badly timed! I didn't realize the PR was reopened already.
I didn't actually make any changes from when I submitted the PR. I only cleaned up the commit history to simplify it.


support all subscriber fields

Codecov Report

Merging #5 into master will not change coverage.
The diff coverage is 100%.

@@          Coverage Diff          @@
##           master     #5   +/-   ##
=====================================
  Coverage     100%   100%
=====================================
  Files           4      4
  Lines          35     38    +3
=====================================
+ Hits           35     38    +3

Impacted Files
Coverage Δ

lib/ex_campaign_monitor/subscriber.ex
100% <100%> (ø)
:arrow_up:

Continue to review full report at Codecov.

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


feat(frontend): support alter shared source

I hereby agree to the terms of the RisingWave Labs, Inc. Contributor License Agreement.
What's changed and what's your intention?

Checklist

[ ] I have written necessary rustdoc comments
[ ] I have added necessary unit tests and integration tests
[ ] I have added test labels as necessary. See details.
[ ] I have added fuzzing tests or opened an issue to track them. (Optional, recommended for new SQL features #7934).
[ ] My PR contains breaking changes. (If it deprecates some features, please create a tracking issue to remove them in the future).
[ ] All checks passed in ./risedev check (or alias, ./risedev c)
[ ] My PR changes performance-critical code. (Please run macro/micro-benchmarks and show the results.)

[ ] My PR contains critical fixes that are necessary to be merged into the latest release. (Please check out the details)

Documentation

[ ] My PR needs documentation updates. (Please use the Release note section below to summarize the impact on users)

Release note
If this PR includes changes that directly affect users or other significant modifications relevant to the community, kindly draft a release note to provide a concise summary of these changes. Please prioritize highlighting the impact these changes will have on users.

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#19649  👈 (View in Graphite)
#18935
#19630
main

This stack of pull requests is managed by Graphite. Learn more about stacking.


Zephyr sdk improvement doc

Doc changes moved from: PR #24143.

@nashif @carlescufi @galak @mbolivar With Zephyr SDK 0.11.3 out, https://github.com/zephyrproject-rtos/zephyr/pull/25414, we should get the docs updated.


Use vscode-single-select instead of vscode-select

This PR fixes #1253 by replacing all instances of vscode-select with vscode-single-select.  #1265 introduced the #1253 bug by upgrading @bendera/vscode-webview-elements which claims in the release notes that 0.17.2 shouldn't have Single/Multi Select until v1.0.0 in the new NPM package (https://www.npmjs.com/package/@vscode-elements/elements), but nevertheless, this PR does fix the issue.
A separate issue/effort should likely be considered to upgrade<EMAIL_ADDRESS>to @vscode-elements/elements@latest (where latest is 1.3.0 at the time of writing).

@Tatsinnit fixed the sign-off, sorry about that


basex: 9.7.3 -> 10.0

Automatic update generated by nixpkgs-update tools. This update was made based on information from https://repology.org/metapackage/basex/versions.
meta.description for basex is: "XML database and XPath/XQuery processor"
meta.homepage for basex is: "https://basex.org/"
meta.changelog for basex is: ""
Updates performed

Version update

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS
The tests defined in passthru.tests, if any, passed
found 10.0 with grep in /nix/store/krqq3lydpl09mgni9pf22v931qqmivbc-basex-10.0
found 10.0 in filename of file in /nix/store/krqq3lydpl09mgni9pf22v931qqmivbc-basex-10.0

Rebuild report (if merged into master) (click to expand)

1 total rebuild path(s)

1 package rebuild(s)

First fifty rebuilds by attrpath
basex

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/krqq3lydpl09mgni9pf22v931qqmivbc-basex-10.0 \
  --option binary-caches 'https://cache.nixos.org/ https://nix-community.cachix.org/' \
  --option trusted-public-keys '
  nix-community.cachix.org-1:mB9FSh9qf2dCimDSUo8Zy7bkq5CX+/rkCWyvRCYg3Fs=
  cache.nixos.org-1:6NCHdD59X431o0gWypbMrAURkbJ16ZPMQFGspcDShjY=
  '

(The Cachix cache is only trusted for this store-path realization.)
For the Cachix download to work, your user must be in the trusted-users list or you can use sudo since root is effectively trusted.
Or, build yourself:
nix-build -A basex https://github.com/r-ryantm/nixpkgs/archive/71ba3646a31daee747fcbab77d2c5606b383face.tar.gz

After you've downloaded or built it, look at the files and if there are any, run the binaries:
ls -la /nix/store/krqq3lydpl09mgni9pf22v931qqmivbc-basex-10.0
ls -la /nix/store/krqq3lydpl09mgni9pf22v931qqmivbc-basex-10.0/bin

Pre-merge build results
We have automatically built all packages that will get rebuilt due to
this change.
This gives evidence on whether the upgrade will break dependent packages.
Note sometimes packages show up as failed to build independent of the
change, simply because they are already broken on the target branch.
Result of nixpkgs-review run on x86_64-linux 1

1 package built:

basex

Maintainer pings
cc @bjornfor for testing.

Result of nixpkgs-review pr 186232 run on x86_64-darwin 1

1 package built:

basex


Production build with --standalone mode get error on server build

Environment
System:
OS: Windows 10 10.0.19044
CPU: (8) x64 Intel(R) Core(TM) i7-7700HQ CPU @ 2.80GHz
Memory: 3.66 GB / 15.87 GB
Binaries:
Node: 16.17.0 - C:\Program Files\nodejs\node.EXE
Yarn: 1.22.19 - C:\Program Files\nodejs\yarn.CMD
npm: 8.18.0 - C:\Program Files\nodejs\npm.CMD
Browsers:
Edge: Spartan (44.19041.1266.0), Chromium (110.0.1587.41)
Internet Explorer: 11.0.19041.1566
npmPackages:
nuxt: ^2.16.1 => 2.16.1
Reproduction

I see the<EMAIL_ADDRESS>use a new dependency:
https://www.npmjs.com/package/node-fetch-native 1.0.1
The nuxt 2.15.8 use node-fetch, and with this package is working fine.
Describe the bug
If I run the production build with --standalone flag, I got this error. The normal production build is working fine.
Additional context
No response
Logs
No response

let's track in https://github.com/nuxt/nuxt/issues/10751

Thanks.


reproduce #1491 on kitchen-sink

Just the reproduction of the issue on kitchen sink

issue #1491

Continue: #1558


commenting out check-eol

It turned out that currently it do not work as alias, works from comand line directly.
There is a problem with \r. double escaping it (\r) produce wrong results.
Funny thing is, that if you replace \r with \n it works some how, but of course we do not want
to have \n here. :(

@jakubnabrdalik please merge it :)

+1

Instead of commenting consider removing.
Keeping unused lines only pollute files and if you want to re-enable this alias later on use VCS history capabilities to re-introduce it.

Jakub promised to investigate this "\r magic", so it was temporary commented instead of removing.
If you fire this command from terminal it works, but it stops working if you put it in alias.

Sorry for the lag.


[issue-7499]: Migrate from Joda Time to Java Time API

Description
Migrate Joda time to Java's Time API
Upgrade Notes
Does this PR prevent a zero down-time upgrade? (Assume upgrade order: Controller, Broker, Server, Minion)

[ ] Yes (Please label as backward-incompat, and complete the section below on Release Notes)

Does this PR fix a zero-downtime upgrade introduced earlier?

[ ] Yes (Please label this as backward-incompat, and complete the section below on Release Notes)

Does this PR otherwise need attention when creating release notes? Things to consider:

New configuration options
Deprecation of configurations
Signature changes to public methods/interfaces
New plugins added or old plugins removed

[ ] Yes (Please label this PR as release-notes and complete the section on Release Notes)

Release Notes

Documentation

@siddharthteotia there will be incompatibilities. I was thinking whether a new config property could be introduced to select the compatibility mode so existing queries can still work with Joda formats and eventually migrated to use Java formats if needed, I'm not sure how easy introducing the setting would be as I'm still not very familiar with the code and I can see all thee methods are static.
With regards to other types, they are supported in Java with slightly different names: a Timestamp is an Instant and and Instant can be timezoned to convert it into a ZonedDateTime. Intervals are represented with Period and Duration.
I will edit the PR description to include more details later on

I can see the Joda Interval class is used in the contract of quite few places. Replacing those won't be straight forward, the author suggests using Threeten-Extra. Are we happy with this?

@richardstartin @siddharthteotia is it worth keep working on this? I'll decline the PR if not, I don't like to keep open if it's not going to be merged. Otherwise, I'll rebase and wait


Create Sprite for Bazooka

Please see CONTRIBUTING.md first.
Happy Hacking! :smiley:

I would love to work on this one! May not turn out good however since it'll be my first pixel art(literally) :)


Correct link to segmented bar documentation

Clicking on the documentation link for the SegmentedBar takes you to a 404. This PR fixes that.

Thank you for the correction!


Constant TYPO3_version already defined

In case one uses conditional PHPStan config like:
phpstan.neon
includes:
    - vendor/saschaegerer/phpstan-typo3/extension.neon
    - PHPStan/conditional.config.php

PHPStan/conditional.config.php
<?php

declare(strict_types=1);

use TYPO3\CMS\Core\Information\Typo3Version;

$config = [];

$typo3Version = new Typo3Version();
if (version_compare($typo3Version->getVersion(), '11.5.0', '<')) {
  $config['parameters']['ignoreErrors'][] = [
    'message' => '#Call to an undefined method TYPO3\\\\CMS\\\\Core\\\\Database\\\\Query\\\\QueryBuilder::executeQuery\(\).#',
    'path' => '../Classes/ViewHelpers/path.php',
    'count' => 1,
  ];
}

return $config;

PHP Notice is shown:
PHP Notice:  Constant TYPO3_version already defined in vendor/saschaegerer/phpstan-typo3/phpstan.bootstrap.php on line 20

I'm not sure if this should be done in the configuration like that as we're now loading code in the configuration that should only be loaded in the bootstrap. This could lead to other problems deep inside of PHPStan. It could possibly end up in unexcpected behavior like broken caches or so. Not sure if something will break but nobody knows. It just feels wrong doing it like that.
Do you have more details where any why you wan't to do it like that? DO you have a TYPO3 Extension that is compatible with multiple TYPO3 versions? Could you not just add a separate config file that ins used in CI when TYPO3 version is < 11.5?

Yes, I have an extension that supports 9.5 , 10.4 and 11.5 and where it just for CI I wouldn't bother. But this is for lokal testing and having just one command to run that then figures out the rest is just convenient.
But I'm open for suggestions if you have a better way to do this.

How do you trigger you local testing for these TYPO3 versions? You're doing a composer install somehow to install the TYPO3 version?

Yes, I found myself switching between 9.5, 10.4 and 11.5 quite a lot, while backporting stuff, my team and I had written for 11.5, we needed in older projects too.
And for triggering the testing, I've mapped a VSCode button to the command "php -d memory_limit=512M vendor/bin/phpstan analyse -c phpstan.neon"
As I said, this is just a convenience thing, but I don't want to mess with phpstan or introduce bugs I then have to look for.
You are right, I could create separate config files and hope to remember to use them. :)
Or I change my approach and figure out which Typo3 version is currently active another way. I have to think about that.

@sascha-egerer I think we can close this issue, right? Feel free to open it again.


MS SQL SERVER

Dear All,
thank you for this tutorial.
I want to use your code with a SQLServer DB. I did some needed changes and the system is running.
Select, Update and Delete are working fine, but Insert doesn't work. When I click at the button nothing is happening. It happens with all Insert forms.
Please, could you help me to know where should I look/fix?
As you could see in the picture below, I tried with a JavaScript PopUp to get a feedback, but without success.
echo ('<script>window.alert("ENTROU!");</script>');
Thank you very much in advanced.
Best regards,
Dante Dantas

aku dapat masalah yang sama


Add .plugins-ml-connector to system index

Description
[Describe what this change achieves]
Add .plugins-ml-connector to system index
Issues Resolved
NA
Is this a backport? If so, please add backport PR # and/or commits #
No
Testing
NA
Check List

[ ] New functionality includes testing
[ ] New functionality has been documented
[ ] Commits are signed per the DCO using --signoff

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

@zane-neo Is this targeted for 2.9?

@zane-neo Can you also add this to the batch script version of install_demo_configuration.bat as well?

done

@zane-neo Is this targeted for 2.9?

Yes, this is targeted for 2.9.


OpenTelemetry spec v1.10 that Dapr uses needs to be updated to v1.25

In what area(s)?

/area runtime
What version of Dapr?

1.13.2
Expected Behavior
The current OpenTelemetry specification is v1.25 and compliance with this version is required with some Observability platforms like Cisco Cloud Observability or else they do not understand how to visualise endpoint flow maps.
Changes to the v1.25 specification of trace spans for http server and client contexts state that the spans SHOULD contain the attributes :
http.request.method
server.address
server.port
url.full
There are additional attributes recommended and advisories for handling previous specifications so it would be worthwhile reviewing the implementation and the new specification and supporting some of the recommended attributes as well.
HTTP Sever: The following attributes can be important for making sampling decisions and SHOULD be provided at span creation time (if provided at all):
url.path
url.scheme
server.port
url.query
client.address
server.address
user_agent.original
http.request.header.
http.route MUST be provided at span creation time if and only if it's already available. If it becomes available after span starts, instrumentation MUST populate it anytime before span ends.
See v1.25.0/docs/http/http-spans.md
Additionally these attributes are required on all OpenTelemetry data:

telemetry.sdk.language | string | The language of the telemetry SDK. | cpp | Required |
-- | -- | -- | -- | -- | --
telemetry.sdk.name | string | The name of the telemetry SDK as defined above. [1] | opentelemetry | Required |
telemetry.sdk.version | string | The version string of the telemetry SDK. | 1.2.3 | Required |

Actual Behavior
http.request.method is missing from http client span attributes
server.address is missing from http client span attributes
server.port  is missing from http client span attributes
url.full is missing from http client span attributes
http.request.method is missing from http client span attributes
http.request.method is missing from http server t span attributes
server.address is missing from http server span attributes
server.port  is missing from http server span attributes
url.path is missing from http server span attributes
url.scheme   is missing from http server span attributes
Steps to Reproduce the Problem
Collect and trace info from Dapr and inspect the span attributes
Release Note

RELEASE NOTE: UPDATE OpenTelemetry specification to v1.25

As part of this update suggest that we also update to the latest OTEL v0.101.0
Also see issue https://github.com/dapr/dapr/issues/7703


Fix maven tests: Set resources location

Fix tests with maven.
Reported by @VladRassokhin on #846.

Yep, all 553 tests are green

BTW, If you are interested, I could give you access to 'TestNG' project on our public TeamCity server, so you could edit it settings. Anyway it have configurations to build and run tests for TestNG using maven and ant (looks like there no more ant builds, will replace with gradle one) and more important - inspections and duplicates reports.

@VladRassokhin I've just created an account -> juherr

@juherr I was going to point out that this missing property was probably the reason why tests were failing on Maven but you beat me to it. Thanks!

@VladRassokhin I played a bit with TeamCity but I didn't find how to specify minimum java version on build.

@juherr If you're talking about kobaltw problem - that's because JAVA_HOME on agent points to Java 1.6. That could be solved by settings env.JAVA_HOME=env.JDK_18 as build configuration parameter.
Unfortunately there no way to set parameter like "Any Java newer that 1.X".
Also there is problem in kobalt, since it not check java version prior to execute java code.


Publish<EMAIL_ADDRESS>

Summary

https://github.com/slackapi/bolt-js/compare/@slack/bolt@3.10.0...seratch:release-3.11.0
https://github.com/slackapi/bolt-js/milestone/18?closed=1

 🎁 🐛 New features / improvements:
  * #1391 Fix #1335 Proper use of state parameter for the OAuth CSRF protection - Thanks @seratch
  * #1359 Fix #1358 Expose common utilities for building HTTP module based receivers - Thanks @seratch
  * #1392 Fix #1385 Create a signature validation function that is not tied to the request - Thanks @seratch @danerwilliams
  * #1393 Fix #1376 CustomRoute interface should be accessible from developers - Thanks @seratch
  * #1381 Fix #1380 by adding more event payload types - Thanks @seratch @aasiddiq
  * #1340 #1334 Export `EnvelopedEvent` interface to users - Thanks @martin-cycle
  * #1366 Fix #1364 Update axios to latest 0.26.1 - Thanks @seratch @msrivastav13
  * #1369 #1368 Log httpServer.close error only when the `server` exists - Thanks @sbcgua
  * #1336 Organize the test assets - Thanks @seratch

📝  Document updates:
  * #1384 Deploy the App to Heroku with one click - Thanks @MaurizioBella

Here are [all the issues / pull requests](https://github.com/slackapi/bolt-js/milestone/18?closed=1) included in the release.

Requirements (place an x in each [ ])

[x] I've read and understood the Contributing Guidelines and have done my best effort to follow them.
[x] I've read and agree to the Code of Conduct.

@mwbrooks Thanks for checking this. All the changes in the release are fine! but I found a new bug at the last minute: https://github.com/slackapi/bolt-js/issues/1397 I will resolve this and release a new version including the fix tomorrow or later.


Added Blazor as WIP Frontend

See https://github.com/gothinkster/realworld/issues/191

@torhovland thanks for the PR 😄
We've updated our process for adding repos to the readme to try to make it a little easier. Updating the label on the issue to wip now adds it automatically during a build. You should already see this on the readme in wip section now.
I'm closing this since it's already complete, thanks for taking the time though.


Form plugin error

Expected behaviour:
<login to rss feed (http://feeds2.feedburner.com/newpctorrent) in order to download torrents from url http://www.newpct.com/entrar/>
Actual behaviour:
From
Steps to reproduce:

Step 1: ...

Config:
    rss: http://feeds2.feedburner.com/newpctorrent
    form:
      url: http://www.newpct.com/entrar/
      userfield: userName
      passfield: userPass
      username: myuser
      password: mypassword

Log:
2017-05-26 20:22 CRITICAL task          series_sigo     BUG: Unhandled error in plugin form: expected name token at '<!<31?106:(132,0x0))'
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/flexget/task.py", line 486, in __run_plugin
    return method(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/flexget/event.py", line 23, in __call__
    return self.func(*args, **kwargs)
  File "/usr/local/lib/python2.7/dist-packages/flexget/plugins/operate/formlogin.py", line 77, in on_task_start
    for form in br.forms():
  File "/usr/lib/python2.7/dist-packages/mechanize/_mechanize.py", line 420, in forms
    return self._factory.forms()
  File "/usr/lib/python2.7/dist-packages/mechanize/_html.py", line 557, in forms
    self._forms_factory.forms())
  File "/usr/lib/python2.7/dist-packages/mechanize/_html.py", line 237, in forms
    _urlunparse=_rfc3986.urlunsplit,
  File "/usr/lib/python2.7/dist-packages/mechanize/_form.py", line 844, in ParseResponseEx
    _urlunparse=_urlunparse,
  File "/usr/lib/python2.7/dist-packages/mechanize/_form.py", line 981, in _ParseFileEx
    fp.feed(data)
  File "/usr/lib/python2.7/dist-packages/mechanize/_form.py", line 760, in feed
    raise ParseError(exc)
ParseError: expected name token at '<!<31?106:(132,0x0))'

Additional information:

FlexGet version: 2.10.54 today and yesterday 2.10.40 it fails too
Python version: Python 2.7.9
Installation method: pip repository
Using daemon: NO
OS and version:Linux raspberrypi 4.9.24-v7+ #993 SMP Wed Apr 26 18:01:23 BST 2017 armv7l GNU/Linux , Raspbian GNU/Linux 8 (jessie)
Link to crash log:

test https://github.com/Flexget/Flexget/pull/1838

Fix #1838 don't solve the login problem.

New Fix #1847 solve the login problem.

Hello,
I have an issue with form login too. I'm unable to login to yggtorrent.com.
Conf:
    cfscraper: yes
    form:
      url: https://yggtorrent.com/user/login
      userfield: id
      passfield: pass
      username: '{? ygg.usr ?}'
      password: '{? ygg.pwd ?}'
    html:
      url: "https://yggtorrent.com/torrents/filmvideo/2183-film?per_page=10&order=desc&sort=publish_date&page=0"
      title_from: link

LOG:
2017-10-22 11:09 DEBUG formlogin yggtorrent_1080p Exception posting login form.
Traceback (most recent call last):
File "/opt/rh/python27/root/usr/lib64/python2.7/site-packages/flexget/plugins/operate/formlogin.py", line 66, in on_task_start
br.open(url)
File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/mechanize/_mechanize.py", line 254, in open
return self.mechopen(url_or_request, data, timeout=timeout)
File "/opt/rh/python27/root/usr/lib/python2.7/site-packages/mechanize/_mechanize.py", line 310, in mechopen
raise response
httperror_seek_wrapper: HTTP Error 403: Forbidden
2017-10-22 11:09 CRITICAL formlogin yggtorrent_1080p Unable to post login form
2017-10-22 11:09 WARNING task yggtorrent_1080p Aborting task (plugin: form)
2017-10-22 11:09 DEBUG task_queue task yggtorrent_1080p aborted: TaskAbort(reason=Unable to post login form, silent=False)

$ flexget -V
2.10.102
You are on the latest release.

Thanks

Looks like the fix in #1847 is no longer relevant as per https://github.com/python-mechanize/mechanize/blob/master/ChangeLog#L50


Chocolatey Package

A Chocolatey package would be pretty useful to auto update and for moving PCs

I've never tried doing this. I'll see what I can do :)

especially considering that Chatterino's choco package isn't working atm

I haven't seen any feedback of this. Since I manage the package, it would be cool if I was made aware of it.

@brian6932 I just tried Chatterino's choco package last week and it worked perfectly, please define "isn't working". Thanks!

@zneix it was for a short time, it was fixed months ago

Here you go, pending approval from chocolatey: https://community.chocolatey.org/packages/dankerino

dankClappers

@ALazyMeme Is this supposed to happen?

@ALazyMeme Is this supposed to happen?

Not usually, I'll check on what failed when I get home.

It was literally just a url missing. Sometimes I hate this standard.
I've pushed a new build now


[Spark] CDC reader accept case insensitive Boolean option values

Which Delta project/connector is this regarding?

[x] Spark
[ ] Standalone
[ ] Flink
[ ] Kernel
[ ] Other (fill in here)

Description
DeltaOptions are equipped to accept case-insensitive values of boolean flags, but CDCReader was not, resulting in not-accepting 'True'. Make it case insensitive.
A separate bug in Spark Connect was causing "True" to be passed from Python boolean True. That is being fixed by https://github.com/apache/spark/pull/47790
How was this patch tested?
Tests added.
Does this PR introduce any user-facing changes?
Datasource option to enable CDC should now accept "True" and other mixed-case variants and not only "true".

@larsk-db


try to show/hide text field using the value attribute of the select

Maybe the submitform works without js.

Not even with CSS from what I can tell.


[$1000] Web - Tooltip not visible for task assignee

If you haven’t already, check out our contributing guidelines for onboarding and email<EMAIL_ADDRESS>to request to join our Slack channel!

Action Performed:

Create a task
Assign it to some one
Go to task page
Take the cursor to assignee
Not tooltip

Expected Result:
Tooltip should be shown
Actual Result:
Tooltip not present
Workaround:
Unknown
Platforms:

Which of our officially supported platforms is this issue occurring on?

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

Version Number: 1.3.30-5
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
https://github.com/Expensify/App/assets/93399543/474e6711-ffd3-451d-ac0f-43c1a469ebeb
https://github.com/Expensify/App/assets/93399543/8754a242-0f79-4c18-9490-7d63c361aef9
Expensify/Expensify Issue URL:
Issue reported by: @BhuvaneshPatil
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1687543065679319
View all open jobs on GitHub
Upwork Automation - Do Not Edit

Upwork Job URL: https://www.upwork.com/jobs/~01e9a87fc35eb2547b
Upwork Job ID:<PHONE_NUMBER>264049664
Last Price Increase: 2023-06-27

Proposal
Please re-state the problem that we are trying to solve in this issue.
Tooltip not visible for task assignee.
What is the root cause of that problem?
We does not wrap task assignee with UserDetailsTooltip.
What changes do you think we should make in order to solve the problem?
We should wrap task assignee with UserDetailsTooltip in TaskHeader.js as below.
                                {assigneeAccountID && assigneeAccountID > 0 && (
                                    <UserDetailsTooltip accountID={assigneeAccountID}>
                                        <View style={[styles.flex1, styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween]}>
                                            <Avatar
                                                source={assigneeAvatar}
                                                type={CONST.ICON_TYPE_AVATAR}
                                                name={assigneeName}
                                                size={CONST.AVATAR_SIZE.HEADER}
                                            />
                                            <View style={[styles.flexColumn, styles.ml3]}>
                                                <Text
                                                    style={[styles.headerText, styles.pre]}
                                                    numberOfLines={1}
                                                >
                                                    {assigneeName}
                                                </Text>
                                            </View>
                                        </View>
                                    </UserDetailsTooltip>
                                )}

What alternative solutions did you explore? (Optional)
None.

I can replicate on Staging v32-5, even with a user with a name (which should have a tooltip):
https://github.com/Expensify/App/assets/30815269/a09100d3-5e7a-4877-bd36-b3ef98b89a2b

I would suggest we hold this issue or close it as we are redesigning task details page.
https://github.com/Expensify/App/issues/19330

Proposal
Please re-state the problem that we are trying to solve in this issue.
Tooltip not visible for task assignee
What is the root cause of that problem?
We don't wrap task assignee with Tooltip component
I see we use Tooltip component for other pages so I think we should reuse this component
What changes do you think we should make in order to solve the problem?
Wrap task assignee with Tooltip component
More details:

<View style={[styles.flexRow, styles.alignItemsCenter, styles.justifyContentBetween]}>
  {props.report.managerEmail && (
       <>
            <Tooltip text={assigneeName}>
                  <Avatar
                      source={assigneeAvatar}
                      type={CONST.ICON_TYPE_AVATAR}
                      name={assigneeName}
                      size={CONST.AVATAR_SIZE.HEADER}
                   />
             </Tooltip>
              <View style={[styles.flexColumn, styles.ml3]}>
                  <Text
                       style={[styles.headerText, styles.pre]}
                       numberOfLines={1}
                   >
                       {assigneeName}
                   </Text>
               </View>
         </>
   )}
</View>

Result:

I have asked here https://github.com/Expensify/App/issues/19330#issuecomment-1612069160 whether we should put this one on hold or proceed

Looks we should put this on hold. cc @jliexpensify

Still on hold

Still on hold

Dropping to Weekly since we're on hold.

@jliexpensify We can lift the hold now. https://github.com/Expensify/App/pull/20841 is now merged.

@StevenKKC @phuchoang23 Can you please update your proposals to reflect the current state?

@s77rt I updated my proposal.

@StevenKKC Thanks for the update. I think we don't need to do anything here. The avatar already has the correct tooltip showing.

@s77rt Task assignee does not have tooltip. Please check again.

@StevenKKC Can you please share a video/screenshot?

@s77rt
This is a screenshot on main branch.
https://github.com/Expensify/App/assets/131836113/936287d0-fe79-4181-bcb8-b957a43e42a9
This is a screenshot after change code based my proposal.
https://github.com/Expensify/App/assets/131836113/03761f3e-fd5c-4482-b94b-40ec0e33bfe3

@StevenKKC That's a different bug and your change makes the icon having a different size.

@s77rt This issue is that the task page does not display a tooltip for the task assignee. Could you please explain why that is a different bug?

@StevenKKC The issue was reported for the header view (see the videos in the OP). That seems fixed already.

@s77rt I checked the videos in the OP. Task detail page is redesigned and the page in the video is the previous task detail page.

@shawnborton Can you please help decide whether we should add a tooltip on the assignee avatar? Check the first video here https://github.com/Expensify/App/issues/21713#issuecomment-1642579573

We can add a tooltip but please do not change the avatar size there.

@StevenKKC Thanks for the update. Instead of wrapping Avatar with UserDetailsTooltip, can we pass icons as an array so we use MultipleAvatars instead of Avatar? MultipleAvatars already have the mentioned logic https://github.com/Expensify/App/blob/be2c81fb1e0b27517451a6d00be097c8d3954ef6/src/components/MultipleAvatars.js#L110-L131

@s77rt Thanks for your reply. I updated my proposal. Please review again. Thanks.

@s77rt Please check alternative solution.

@StevenKKC Thanks for the update. That's not what I meant, we already have a logic that displays MultipleAvatars if icons is an array. We should pass the icon prop as an array from TaskView to MenuItem.

Proposal
Please re-state the problem that we are trying to solve in this issue.
Web - Tooltip not visible for task assignee
What is the root cause of that problem?
For displaying avatar in MenuItem in TaskView, to display tooltip, we need array of icons to be provided as prop. But we are not passing the icon as an array.
https://github.com/Expensify/App/blob/99519f2347f91a2328f0e143e8a2859628412ffa/src/components/MenuItem.js#L148-L160
What changes do you think we should make in order to solve the problem?
We need to pass the icon prop for MenuItem in TaskView as an array, this can be done like following -
icon={OptionsListUtils.getAvatarsForAccountIDs([props.report.managerID], props.personalDetails)}

What alternative solutions did you explore? (Optional)

@s77rt I updated my proposal.

@BhuvaneshPatil Thanks for the proposal. Your RCA is correct. The solution looks good except the avatar icon is bigger than it's supposed to be.

@StevenKKC Thanks for the update. Overall looks good, but why are we constructing the assigneeTooltipIcon object manually? Is there any specific case where OptionsListUtils.getAvatarsForAccountIDs (as suggested by @BhuvaneshPatil) won't work as expected?

@s77rt Updated the proposal for handling size changes.

@s77rt I think using OptionsListUtils.getAvatarsForAccountIDs would be a good idea.

@BhuvaneshPatil Thanks for the update. I think we reached the same solution as proposed by @StevenKKC.

@StevenKKC Thanks for the update. I think we can go with your proposal as it was the first complete one.
:ribbon: :eyes: :ribbon: C+ reviewed
Link to proposal

thanks for the update @s77rt , on to the next bug hunting. Good luck @StevenKKC .

@s77rt PR is ready for review.

The PR that introduced the bug has been identified: https://github.com/Expensify/App/pull/18806
The offending PR has been commented on: https://github.com/Expensify/App/pull/18806#discussion_r1275560750
A discussion in #expensify-bugs has been started: We already have a discussion about adding tooltip to the checklist https://expensify.slack.com/archives/C02NK2DQWUX/p1689013364759179
Determine if we should create a regression test for this bug: No

Payment summary:

Bug Reporter: @BhuvaneshPatil $250
Contributor: @StevenKKC $1000 + $500 (speed bonus)
C+: @s77rt $1000 + $500 (speed bonus)

Upwork job
Is that all correct? It looks like this was merged in a day

@jliexpensify Looks correct!

Everyone's paid and job removed, thanks!


Fix: React wrapper

Based on #83.
I decided to fix it by myself.
It turns out the implementation didn't consider react lifecycle specifics, and the library itself wasn't happy about it.
Based on my case, I also decided to improve the react demo.
I would like to add prettier, easier code style management, but I wonder whether you are good with it.
If you need a detailed breakdown and explanation of the changed LoCs - just let me know.

By the way, I would like to mention two more things:

I think demos should read the local version of the library, not the npm. Then it would be easier to check whether it works fine or not.
I see you bumped 0.0.17 on 09.08.23, but it looks like you still need to publish it.

Thank you for this! I am pretty busy the next couple of days but will review as soon as possible!

Hi @tarsinzer!
Thank you so much for this, I think the changes to the react component are excellent.
Regarding the demos, I built the demos as the minimum barebones shell that someone could copy and paste directly into their own project to get started, which is why I have the demos set to read from npm and not locally. If someone were to simply copy paste the react code onto their computer and run it, having the package linked locally would break the starter code. And in the same vein, I purposely left the demos blank without controls or any of those other bells and whistles.
That said, maybe there's a separate folder I can add for developing and testing the various framework components.

I was also curious if I could add prettier to the project. Then, it would be easier for contributors to align with code style and auto formatters, especially after Eslint decides to move away from formatting the files and focus on linting only.
One more thing I want to ask regarding the API: is there any chance I can manipulate it with speed linearly, like default video play? Let's say I want to play video naturally from 0% to 15%, and then enable the default jump to the end after some delay (with the default transitionSpeed of 8). I was just playing with numbers and couldn't achieve linear easing behaviour. If I set the transition speed to 1, it plays normally but ends very slowly... not something what I'm looking for.

@tarsinzer sure! If you'd like to add prettier go ahead. I'm happy to merge that into the codebase.
Regarding easing, maybe there's a way we can add an option that takes one of D3's easing functions that it uses for easing. That way, anyone can specify their own custom easing function to use.
Feel free to open more PRs, I'm happy to review!


Consider AccessManager functionality for WebSocket

@SE7-KN8 I think there have to be another AccessManager because Handler and Context can't be used from WebSockets.

It's true that Handler and Context can't be used from WebSockets, but they can be used with the handshake request that establishes the WebSocket connection. I think this feature might be pretty straightforward to implement by intercepting that request.

The problem, in this case, is, that ServletUpgradeResponse (which is used to perform the handshake) has no method to get the underlying HttpServletResponse. So it's no possible to instantiate a Context.

If you look at line line 40 in EmbeddedJettyServer, you see that I ignore WebSocket requests in the default HTTP-handler. At this point you have access to the standard HttpServletRequest and HttpServletResponse, and you know that the request is to establish a WebSocket connection. I haven't thought about how to best solve this, but I think all the pieces are there.

We could add a special verb for upgrade-requests that can be used with the AccessManager, technically WebSocket communication will happen outside of the AccessManager, so it makes sense, sort of?
app.wsUpgrade("/websocket", ::defaultUpgrade, roles(ADMIN))

app.ws("/websocket", ws -> {
    ws.onConnect(session -> System.out.println("Connected"));
});

`

Maybe this functionality could be achieved by implicitly setting up additional handler for requests with upgrade header. Basically it will do the same as proposed wsUpgrade (check if request.isWebsocket and do access management) using the existing code in JavalinServlet.


Update PPL describe command

Description
Add EXTENDED flag to the desc command for better visibility
Add command description in the README.md file
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

2024-08-16T21:15:06.3943009Z [info] *** 1 TEST FAILED ***
2024-08-16T21:15:06.3944202Z [error] Failed tests:
2024-08-16T21:15:06.3945643Z [error] 	org.opensearch.flint.spark.ppl.FlintSparkPPLBasicITSuite
2024-08-16T21:15:07.2421358Z [error] (integtest / IntegrationTest / test) sbt.TestsFailedException: Tests unsuccessful

LGTM. Will approve after addressing the comments.


No Exchanges showing

I have placed the following into my YAML, all create entities except the exchanges. It does not appear to be creating the exchange entities
binance:
name: My Binance
api_key: ***********
api_secret: *************
domain: com
native_currency: AUD
balances:
- BNB
- LINK
- MATIC
- SHIB
- BTC
exchanges:
- BTCUSD
- ETHUSD
- MATICUSD

To whom it may concern,
Exchange pairs used in the readme aren't valid (anymore?).
Instead use, for example:
exchanges:
  - BTCUSDT
  - ETHUSDT


Vector element not implemented for Point2d

So I've been trying to upgrade an internal project to newest opencv-rust to make use of the feature gating to decrease build size. And a few bits of previously working code have now ceased to work. Namely anything which was using Vector::<Point2d>. As far as I can tell there's no issue with this code and it shouldn't have became an error - instead the required trait bounds should have been automatically generated. However, I may be wrong - if so I'd be interested in how to get around this issue without compromising on accuracy.
Below is a sample of error messages:
error[E0599]: the function or associated item `new` exists for struct `Vector<Point_<f64>>`, but its trait bounds were not satisfied
  --> engine/src/foo.rs:82:51
   |
82 |         let mut image_points = Vector::<Point2d>::new();
   |                                                   ^^^ function or associated item cannot be called on `Vector<Point_<f64>>` due to unsatisfied trait bounds
   |
  ::: /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.76.4/src/manual/core/vector.rs:20:1
   |
20 | pub struct Vector<T: VectorElement>
   | ----------------------------------- doesn't satisfy `Vector<Point_<f64>>: VectorExtern<Point_<f64>>`
   |
  ::: /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.76.4/src/manual/core/point.rs:13:1
   |
13 | pub struct Point_<T> {
   | -------------------- doesn't satisfy `Point_<f64>: VectorElement`
   |
   = note: the following trait bounds were not satisfied:
           `Point_<f64>: VectorElement`
           `Vector<Point_<f64>>: VectorExtern<Point_<f64>>`

error[E0277]: the trait bound `Point_<f64>: VectorElement` is not satisfied
  --> engine/src/foo.rs.rs:82:32
   |
82 |         let mut image_points = Vector::<Point2d>::new();
   |                                ^^^^^^^^^^^^^^^^^ the trait `VectorElement` is not implemented for `Point_<f64>`
   |
   = help: the following other types implement trait `VectorElement`:
             Point_<f32>
             Point_<i32>
note: required by a bound in `Vector`
  --> /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.76.4/src/manual/core/vector.rs:20:22
   |
20 | pub struct Vector<T: VectorElement>
   |                      ^^^^^^^^^^^^^ required by this bound in `Vector`

error[E0277]: the trait bound `Vector<Point_<f64>>: VectorExtern<Point_<f64>>` is not satisfied
  --> engine/src/foo.rs.rs:82:32
   |
82 |         let mut image_points = Vector::<Point2d>::new();
   |                                ^^^^^^^^^^^^^^^^^ the trait `VectorExtern<Point_<f64>>` is not implemented for `Vector<Point_<f64>>`
   |
   = help: the following other types implement trait `VectorExtern<T>`:
             <Vector<DMatch> as VectorExtern<DMatch>>
             <Vector<FlannIndexType> as VectorExtern<FlannIndexType>>
             <Vector<GpuMat> as VectorExtern<GpuMat>>
             <Vector<KeyPoint> as VectorExtern<KeyPoint>>
             <Vector<PlatformInfo> as VectorExtern<PlatformInfo>>
             <Vector<Point3_<f32>> as VectorExtern<Point3_<f32>>>
             <Vector<Point3_<f64>> as VectorExtern<Point3_<f64>>>
             <Vector<Point3_<i32>> as VectorExtern<Point3_<i32>>>
           and 27 others
note: required by a bound in `Vector`
  --> /home/daniel/.cargo/registry/src/github.com-1ecc6299db9ec823/opencv-0.76.4/src/manual/core/vector.rs:22:8
   |
22 |     Self: VectorExtern<T>,
   |           ^^^^^^^^^^^^^^^ required by this bound in `Vector`

Some errors have detailed explanations: E0277, E0599.
For more information about an error, try `rustc --explain E0277`.

Also not sure if it's related but I get an error building in a dockerfile where it generates this code for core:
	/// ## C++ default parameters
	/// * params: FunctionParams()
	#[inline]
	pub fn copy_mat_and_dump_named_arguments(src: &dyn core::ToInputArray, dst: &mut dyn core::ToOutputArray, params: &core::FunctionParams) -> Result<String> {
		extern_container_arg!(src);
		extern_container_arg!(dst);
		return_send!(via ocvrs_return);
		unsafe { sys::cv_utils_copyMatAndDumpNamedArguments_const__InputArrayR_const__OutputArrayR_const_FunctionParamsR(src.as_raw__InputArray(), dst.as_raw__OutputArray(), params.as_raw_FunctionParams(), ocvrs_return.as_mut_ptr()) };
		return_receive!(unsafe ocvrs_return => ret);
		let ret = ret.into_result()?;
		let ret = unsafe { String::opencv_from_extern(ret) };
		Ok(ret)
	}

Which results in this error:
error[E0412]: cannot find type `FunctionParams` in module `core`
    --> /server/target/release/build/opencv-40047abbaa18fde0/out/opencv/core.rs:7873:123
     |
7873 | ...dst: &mut dyn core::ToOutputArray, params: &core::FunctionParams) -> Result<String> {
     |                                                      ^^^^^^^^^^^^^^ not found in `core`

Docker file grabs and builds opencv like this which I'm working on fixing as I really do not like the "4.x" archive download:
# opencv install
RUN mkdir opencv && cd opencv \
    && apt update && apt install -y cmake g++ unzip libclang-6.0-dev \
    && wget -O opencv.zip https://github.com/opencv/opencv/archive/4.x.zip \
    && unzip opencv.zip \
    && mkdir -p build && cd build \
    && cmake -DBUILD_TESTS=OFF -DBUILD_PERF_TESTS=OFF -DBUILD_opencv_apps=OFF -DBUILD_LIST=calib3d,core  ../opencv-4.x \
    && cmake --build . \
    && make install

Yeah, the error is likely stems from the fact that you're using development build on 4.x branch, I'll check it out as we will most probably have to face it in the future when there is a new release in 4.x branch.
Regarding the vector issue I suspect it's because you not building some modules any more. Those Vector<T> bindings are generated as needed and if none of the generated OpenCV functions use Vector<Point2d> then it won't be included. But there is a special manual tweak list that allows to generate those anyway so if you would please tell me why (for which OpenCV function) you need Vector<Point2d> I will tweak the settings.

calib3d::solve_pnp_ransac I provide a vec of Point2d

Can you please check the rel branch and tell me if it solves the problem with Vector<Point2d> for you?

Can confirm the rel branch fixes the issue :+1:

I've released v0.77.0 with that fix

Awesome thanks :heart:

0.77.0


Implement Network queries

In the GraphQL design and prototype, there is a new root function called Network{}
Description
Like the Local{} implementation the Network{} implementation should become part of the GQL API and it should resolve to this resolver.
Docs

Docs: https://github.com/creativesoftwarefdn/weaviate/blob/develop/docs/graphql_network.md
Prototype: https://github.com/creativesoftwarefdn/weaviate/tree/feature/travis-docs/graphqlapi/prototype
Schema: https://github.com/creativesoftwarefdn/weaviate/tree/feature/travis-docs/test/graphql_schema

Note: locations of these files might change during development

Network queries are implemented as in the Prototype. Closing this issue.


Difference with macOS Sonoma Web Apps?

Homework

[X] I took the time to write a good, descriptive issue title
[X] I read nativefier --help and API.md.
[X] I checked CATALOG.md for community suggestions & workarounds.
[X] I searched existing issues, open & closed. Yes, my question is new.
[X] I'm running the latest version.

Your question
Been a long-time fan and user of Nativefier—as plenty of older solutions have limitations and aren't kept up to date—thanks for all the work!
I noticed that the new macOS Sonoma (Safari) is going to support Web Apps—and it appears to work a lot like the Chrome "apps", but might be a bit better?
https://www.macrumors.com/2023/06/14/how-web-apps-work-macos-sonoma/
I'm curious if anyone that is a nativefier user has seen it or tried it on macOS Sonoma Beta and would compare it in any way to Nativefier.
Steps to reproduce
nativefier --verbose --some-option https://mysite.com
<paste your verbose build logs, if relevant to your question>

Debug info
No response
Nativefier version
50.1.1
Node.js version
v20.2.0
npm version
9.8.1
OS
macOS Sonoma Beta

Not answering your questiobm but check multi, I think it based on webkit, it may offer similar capabilites to the new safari webapps
https://github.com/kofigumbs/multi


see #236; working on batch processing

Pull Request Test Coverage Report for Build 1094

0 of 0   changed or added relevant lines in 0 files are covered.
15 unchanged lines in 1 file lost coverage.
Overall coverage remained the same at 92.218%

Files with Coverage Reduction
New Missed Lines
%

src/controllers/DatabaseController.ts
15
90.06%

Totals

Change from base Build 1092:
0.0%

Covered Lines:
3003

Relevant Lines:
3200

💛  - Coveralls


WinApp driver not clicking elements sometimes and sometimes after opening app giving 500 error.

Getting this error after opening app.

@BgopikrishnaSabbineni This is a known issue, use try cache, then attach to the app by process


S3 endpoints are not accepted in security group rules

S3 endpoints cannot be added as a source/destination using the puppetlabs-aws module.
as an example running puppet resource against a security group with only a rule allowing egress to a s3 endpoint results in:
root@testymctesttest ~ # puppet resource ec2_securitygroup S3Test
ec2_securitygroup { 'S3Test':
ensure      => 'present',
description => 'Test for S3 Endpoint',
egress      => [{'from_port' => '443', 'protocol' => 'tcp', 'to_port' => '443'}],
id          => 'sg-abc123',
region      => 'ap-southeast-2',
vpc         => 'TEST VPC',
}
note that the destination is entirely missing from the egress rule.

May we get a sanitized output of aws ec2 describe-security-groups for the securitygroup please?  I've not seen this use case.

S3 endpoints? Hmm sockeye attached
On Jan 5, 2017 9:42 AM, "zleslie"<EMAIL_ADDRESS>wrote:

May we get a sanitized output of aws ec2 describe-security-groups for the
securitygroup please? I've not seen this use case.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
https://github.com/puppetlabs/puppetlabs-aws/issues/393#issuecomment-270707442,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AThRIHwYCjt65GvRnmq3FJOfyKPkOjGOks5rPSuNgaJpZM4LbQuy
.

@PeterHiggins had explained this to me recently ( we work together ).  Because our company insists on defining egress rules for our SGs, We have to account for S3 enpoints. I think what the module is missing is logic for PrefixListIds.


Git Modified shows files that don't show modified with git status

In this screenshot, you can see that it Git Modified shows 3 files as changed.

When running git status you can see local.xml is the only file shown.

Atom Version: 1.4.3
System: Microsoft Windows 10 Pro
Installed packages
# User
aligner, v0.18.1
bottom-dock, v0.3.7
emmet, v2.4.1
file-icons, v1.6.14
goto-definition, v1.1.7
linter, v1.11.3
minimap, v4.19.0
minimap-autohide, v0.10.1
minimap-git-diff, v4.1.8
pigments, v0.22.1
todo-manager, v0.2.6
tree-view-git-modified, v0.6.2

# Dev
No dev packages

Is there something I'm missing? Thanks!

Is this bug still valid?


Suppress inner diagnostic scopes in DPG clients

Per this discussion we want to find a general and efficient solution to suppressing inner diagnostic scopes when HLC clients call through to an inner DPG client.
This issue tracks the work to implement @lmolkova's solution in DPG.

@annelo-msft what would be inner scope looks like? I think we cannot modify it when adding grow-up method right?

If we are create DiagnosticScope in the outer method(grow-up method) as well as in the inner method(DPG generated method)  live tests fail because for some methods we are creating outer and inner scopes with the same name.
For example:
Outer scope: MetricsAdvisorAdministrationClient.CreateDataFeed
Inner scope: MetricsAdvisorAdministrationClient.CreateDataFeed
Live test failure:

Live test failure in the pipeline:
https://dev.azure.com/azure-sdk/public/_build/results?buildId=1436751&view=logs&j=df47e0b9-f7f0-5a6d-001b-395452402a29&t=a918488f-3fbc-5b68-faba-d1917c3f3686&l=581
To workaround this issue I'm removing outer scope created in grow-up method which is handwritten and responsible for serialization and deserialization until we implement @lmolkova's solution in DPG based on this discussion.

Great, thank you @ShivangiReja!  We will want to make sure to put the outer scope back and suppress the inner scope so we can document that this is the correct approach to library authors.

@annelo-msft what would be inner scope looks like? I think we cannot modify it when adding grow-up method right?

@pshao25, as I understand it, we would leave the inner scope the way it is, for example, here in WebPubSubServiceClient.
What @ShivangiReja and @lmolkova proposed in this discussion, was to make a change to one of the following types:

https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/Azure.Core/src/Shared/DiagnosticScopeFactory.cs
https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/Azure.Core/src/Shared/ClientDiagnostics.cs
https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/Azure.Core/src/Shared/DiagnosticScope.cs

Once this is complete, can we remove https://github.com/Azure/azure-sdk-for-net/blob/main/sdk/core/Azure.Core/src/Shared/ForwardsClientCallsAttribute.cs ?

Closed with https://github.com/Azure/azure-sdk-for-net/pull/28066.  Thanks, @lmolkova!!


tileset_edit.xml tiles moved in last build

It looks like this

Tested in platformer demo on current build it looks good now, so probably not valid anymore. Closing this issue.


Fixed a problem with the bind address not being used as the source address on outgoing TCP packets

Fixes https://github.com/mitmproxy/mitmproxy/issues/877

Note: merging https://github.com/mitmproxy/netlib/pull/110 will fix the integration checks.

Thanks for the PR and sorry for the late reply - holidays! :smile:
I added a few minor comments above. Please let me know once things are in place.

I fixed them. I was not sure if I understood your request regarding the constructor (which constructor were you referring to, the ServerConnection or the ServerConnectionMixin constructor?), so please check if that's how you pictured it.

Thanks! :smiley: My point was to use
self.server_conn = ServerConnection(server_address, (self.config.host, 0))

in the ServerConnectionMixin, so that we can keep all the modes as-is. Once that's done, LGTM!
For the record, binding to two differents interfaces is another feature we may want to support at some point, but I'll leave that for a further PR.

I am afraid that will not work. All the proxy modes inherit from the Layer and ServerConnectionMixin classes, and then use:
super(<classname>, self).__init__(ctx, server_address=server_address)

in the constructor. This will, however never call ServerConnectionMixin's constructor.

Yes, this is a tricky part of Python's inheritance system. ServerConnectionMixin will get called here, no need to worry. :smiley:
Here's how that translates to your example (py3 notation):
class A:
	def __init__(self):
		print("A")
		super().__init__()

class B:
	def __init__(self):
		print("B")
		super().__init__()

class C(A,B):
	def __init__(self):
		print("C")
		super().__init__()

Ah, ok, I see what you mean. Sorry, I totally missed that call to super() in ServerConnectionMixin. I have made the necessary changes now.

No problem, thanks!


Add<EMAIL_ADDRESS>

Since https://github.com/bazelbuild/bazel-central-registry/pull/466 was committed, unless we particularly want this intermediate version, I recommend closing this.