matchPath didn't work if we pass query params

Hey @wellyshen :)
When passing query params to the URL I encountered a problem, the matchPath function doesn't work in this case. A solution is simple, just putting request.path into matchPath instead of request.url. Is it possible that I missed something?

@forwardomg Here's a (way)[https://codeburst.io/react-router-v4-unofficial-migration-guide-5a370b8905a#27d7] for parse query parameters by React-Router v4

@wellyshen Yeap, I know how to parse query parameters. My English not so great, so probably I poorly explained the problem.
For example, I have the path like so "/user/1", on server "loadData" starts to fetch user data because "matchPath" worked well, but if someone request "/user/1?param=1, matchPath cant match these URL addresses so the "loadData" won't work and server won't  be able to fetch data.

Hey @forwardomg thanks for pointing this out - it is important to fix this because external websites will reference you with UTM parameters and the like - which as you say breaks the loadData for server side rendering.
I have fixed this in my version with this commit: https://github.com/iamacup/sliips-ui/commit/c15cf0c2925b16f22740eb674d4e2fbe65d812bc
I changed this line in server.js:
const match = matchPath(req.url, route);
to this:
const match = matchPath(req.path, route);
what I don't know is if we need to also change this line: <StaticRouter location={req.url} context={routerContext}> or anything else - @wellyshen will need to advise as I really don't know about the router :)

Hi Guys,
I did some survey, there's no specific solution on sever-side for React-Router v4. I think your solution might be OK. But, I'm wondering why use req.path instead of req.url can work? Can you guys explain the flow or something for me?
BTW, <StaticRouter location={req.url} context={routerContext}>, it works fine as the way to parse query on client-side.

This is my use case:
I have a route like this:
{
  path: '/get-started/:id',
  exact: false,
  component: GetStartedPage,
  loadData: (dispatch, params, cookies) => Promise.all([
    dispatch(doLoginWithCookieData(cookies.authentication)),
    dispatch(wizzardDoFetchData(cookies.authentication, Number.parseInt(params.id, 10), null, false)),
  ]),
}

which means this link will work, and the loadData method will run from server.js - www.sliips.com/get-started/2
If i post this link to something like medium.com - the link will automatically get converted to something like this: www.sliips.com/get-started/2?utm_content=comments&utm_medium=hot&utm_source=medium&utm_name=blog-post
When someone visits the page with all the UTM tags on it - the page will load, but the server will not have run any of the loadData items because it could not match against them in matchPath, so it will fall to the client to execute the loadData methods in the componentDidMount or path React lifecycle methods.
The solution is to pass the path to the matchPath, so the server knows what page it is on - basically matchPath does not strip any query parameters in the URL and so any loadData methods won't work if there are query paramters on the req.url string.

@iamacup Did you mean, if an URL with UTM parameter that use matchPath(req.url, route) with loadData with cause api fetching failure? Because of req.url including all the UTM parameters?

@wellyshen Won't be fetching if URL has at least one query parameter.

Yep - the API call does not happen at all because matchPath can not find a matching route
try this:
http://localhost:3000/UserInfo/4
http://localhost:3000/UserInfo/4?thisVariable=ThisValue
the second one does not provide the API response in the server side render and instead the client has to make the API call.

OK, I think I should fix this issue for matchPath(). Thank you guys :)


fix(sauce): use same hostname for Sauce rest API as for Sauce backend

Problem
SauceLabs has now a DC in Europe with backend url ondemand.eu-central-1.saucelabs.com:443/wd/hub. If people want to run their tests in this DC the job report should also be done their.
Solution
Parse sauce selenium address and set hostname for SauceLabs client accordingly.
Comment
It should not be called "selenium address" and rather "webdriver address" or "webdriver endpoint" but this is a separate PR.

@cnishina
Can you also cover this in your milestone https://github.com/angular/protractor/milestone/45?
Tnx!

Going to close this in favour of a new PR that will handle multiple EU/US cases with Sauce Labs


setRetry with request delay

Hi, would it be possible to set attempts and retries with delayed requests?

sleep or usleep ?

Use sleep or usleep to delay.
$max_retries = 3;
$delay = 10; // seconds

$curl = new Curl();

$curl->setRetry(function ($instance) use ($max_retries, $delay) {
    if ($instance->retries < $max_retries) {
        sleep($delay);
        return true;
    }
    return false;
});

$curl->get('https://httpbin.org/status/503');

if ($curl->error) {
    echo 'Error: ' . $curl->errorCode . ': ' . $curl->errorMessage . "\n";
    echo 'attempts: ' . $curl->attempts . "\n";
    echo 'retries: ' . $curl->retries . "\n";
} else {
    echo 'Response:' . "\n";
    var_dump($curl->response);
}


POXRequest replaceResult: oauth_body_hash

I believe this fixes #3. I've tested against Canvas and Sakai. I apologize for the long delay.
I did a little refactoring here to make testing easier. I tried to keep the diff small.

Thanks so much for doing this, @bluej100, I really appreciate all of your work!

The least I can do, fixing the bug I added. I really appreciate your maintaining this.

Would you like me to deploy this to the Maven repository, or is there anything currently in flux?

No, that would be perfect, thanks. Just bump the patch number

(I hope I understood correctly that you meant bump the version to 1.1.1.)

Yup!

I think it's done? I'm getting strangely small release jars in my target directory.
https://oss.sonatype.org/content/groups/public/org/imsglobal/basiclti-util/1.1.1/

Fixed. Sorry about that.
https://oss.sonatype.org/content/groups/public/org/imsglobal/basiclti-util/1.1.1/

For our future reference:
mvn install
mvn source:jar
mvn javadoc:jar
cd target
cp ../pom.xml .
gpg -ab basiclti-util-1.1.1.jar
gpg -ab basiclti-util-1.1.1-javadoc.jar
gpg -ab basiclti-util-1.1.1-sources.jar
gpg -ab pom.xml
jar -cvf bundle.jar basiclti-util-1.1.1.jar basiclti-util-1.1.1.jar.asc pom.xml pom.xml.asc basiclti-util-1.1.1-javadoc.jar basiclti-util-1.1.1-javadoc.jar.asc
Log into https://oss.sonatype.org/#stagingRepositories with your credentials from their JIRA, click on Staging Upload, upload bundle.jar as an Artifact Bundle. Next, click on Staging Repositories, find your repository, verify that its contents are correct, and click Release.

The new artifacts have been synced to http://repo.maven.apache.org/maven2/org/imsglobal/basiclti-util/1.1.1/ , and I've confirmed them with my local project.


Revert "Upgrade Nats Image for test-infra to version 2.9.0"

This reverts commit e1695527bd6869b77c23403df28ae3743bfd0fa8.
Container for 2.9.0 seems to break TLS tests. It appears something may
have changed on the new version and it needs to be adjusted to work
with our tests.

See
https://issues.apache.org/jira/browse/CAMEL-18537


same customer name is listed multiple times while choosing customer under sales transaction

https://github.com/techgebra/polosys-books-mobile/assets/138277245/bef42d6c-57e4-4576-ad23-aa0f3040558c

issue closed


Failing to set SO_REUSEADDR is not a fatal error

Library can still run perfectly fine without setting this option.
Needed because Windows Subsystem for Linux (WSL) does not yet support this option.

Hello DrChat,
Which errno code is returned by WSL on  SO_REUSEADDR ?

Code 22 (invalid argument)


How does cldr generate YML file

How does cldr generate YML file

Please avoid generic programming questions. All sources are published.


Walkthrough: Symbols to close feature editor do not match

In the explanation one should use "✓" to close the feature editor, but in the feature editor there is a "✘":

I just tested this again, and it doesn't look like it does this anymore.  @manfredbrandl if you are still seeing this, can you let me know which browser you use?

@bhousel I tried now (2019-02-08, 16:10 UTC) on Windows 10 (64 bit) the latest Versions of the following Browsers: Chrome, Firefox, Edge, Opera and Vivaldi. Only Firefox shows the "✓" in the top, all others show a "✘" which is not what it should be to close the feature editor. There cant be a cache problem on edge, opera and vivaldi, because i did not use them on this computer before.


Assert::isList does not work for a list containing NAN

I've tried to optimize the polyfill of symfony/polyfill-php81 which provides array_is_list function.
Since I've seen how Assert::isList is doing the assertion, I've thought thats a smart way of doing so.
Sadly, PHP is a bit ... special when working with the NAN value.
https://3v4l.org/8I0Du
Thus said, the Assertion from this library might not be accurate when it comes to arrays with NAN.
I've worked around it by using:
array_keys($array) === range(0, count($array) -1);

Sadly, this will slow down the check a bit: https://3v4l.org/QGiu0
Not sure if its worth to use the new implementation as having arrays containing NAN might be rare. But at least I wanted to share my todays WTF moment.

Given the current implementation gives false negatives - one optimisation could be only perform a slow recheck if the main fast check returned false.
So, if $array !== \array_values($array) is false -> do extra array_keys($array) === range(0, count($array) -1).
Given negative branch incurs throwing an exception, extra slowness does not really matter then.
And the positive case would be as fast.

This has been fixed, and will be released in 1.11.0


how to use mysql as database

this image use squlite3 as default database, so does anyone know how to config the images to use mysql database instead!
thanks for any help!

You can setup MySQL by editing grafana/custom.ini


Move alert to Blade component

use view composer for determining the classes to use

[x] I've read the guidelines for Contributing to Roots Projects

Resolved in #2267 👍


Update NPM

Hi @mlochbaum
Thanks so much for helping out with those new options. I'd love to use those in my project now! Can you publish the changes to NPM? Or is that something I can do?
Thanks much :)

Okay, I've updated.

Thanks so much!


WIP/RFC: Add access logging to tcp_proxy

fixes #1159

This still needs tests and doc changes, but I wanted to make sure this is roughly the way we want to implement this.  @mattklein123

Also not present is moving source/common/http/access_log/* to source/common/access_log/*, and re-namespacing all of those things out of Http.  But I'll do that as a separate PR so as to not mix real changes and code movement.

My main question is whether we should try to jam everything to the same interface.

That was my biggest question as I was doing this.
Pros of jamming together:

Maximum code reuse.  We're reusing all the code for parsing the format string, building up the structure to emit the log lines (and extracting the needed data from RequestInfo), config parsing and validation, etc.
Could use the exact same format string for http and tcp access logs if you wanted to (with missing fields getting printed as "-")

Cons of jamming together:

RequestInfo is the union of all fields needed for all types of access logging, which is kind of clunky.
tcp access log format strings can contain fields that will never have data (like http response code). This could be overcome by having some additional validation by the instantiator of the access logs, probably a whitelist of fields that can be used.

I guess the other way to do it would be to have some downcasts in the field extractors (probably dynamic_cast for safety), but that doesn't feel like it's any better than this.
Also, if we change our minds later, there's nothing preventing us from breaking it up later.
Having looked at the code, I'm in favor of RequestInfo being the big union, and jamming it all together.  It saves a large amount of code, both in the implementation, and in the tests, and in the v2 api.

Also, if we change our minds later, there's nothing preventing us from breaking it up later.

Yeah I think potentially it could be factored in such a way as to have a base set of extractors, etc. and then allow derived implementations to add others, but I don't feel that strongly about it. Let's just start with this and see how it goes. If it gets too awkward we can split it up later as you say.

Related API PR: https://github.com/envoyproxy/data-plane-api/pull/214

@ggreenway, @goaway has some concerns about a unified access log type for HTTP vs. TCP vs. whatever (Redis/Mongo/etc.) at least at the proto level. He can share his concerns here and perhaps you two can quickly chat offline. I'm happy to split the AccessLogEntry proto into a base proto as well as an HTTP proto, but now is about the last time we can easily make this change.

Thanks for looping me in, @mattklein123. To expand on the above summary, we've internally struggled for a while with managing datasets that have inconsistently-populated content (generally due to many special-cased fields appropriate only for a single context). It's hard to work on these datasets without having a lot of domain knowledge, and over time people make bad assumptions about what will be present and what won't, due to a lack of visibility. (Can go into more depth about this and other issues we've encountered when going down the "unified" route, if you're interested.) In general, I think one of the major advantages to structured logging is consistency, and we start lose that as we add an increasing number of "optional" fields.
My feeling at this point is that it might make more sense to have some sort of Base access log struct to capture generalizable context, and then have protocol-specific exchange structs that capture case-specific data. HTTP would be one, TCP could be another, and other special cases could expose their own useful information. These structs would then drive case-specific access logs with internally-consistent data.

I think there are two intersecting issues here:

Text-file logging.  For this, the final format is supplied in the configuration.  Users are free to only define the fields that make sense in their logging format, so making the set of available fields be the union of all logging types is harmless.

Protobuf/structured logging.  For this, we're defining the final output format.  Having fields present that don't make sense in the context makes it harder to deal with.

I hadn't thought much about (2) because I'm most interested in (1) for my current needs.  There are also 3 changes (that I'm aware of) that affect logging right now: this one, upstream logging, and defining a protobuf logging format.  I agree it's important to figure out the correct format for protobuf logging right now.  Do we need to defer work on this PR until that is sorted out?

I don't think we need to block work on this PR, but we do need to sort out the proto situation ASAP. I think I'm in favor of splitting the access log protos into a base, HTTP, and TCP (which might just be base). Does that work for you @ggreenway ?

@mattklein123 that's fine with me.

Sounds good to me, too - thanks @ggreenway , @mattklein123 .

@mattklein123 @htuch This is now ready for further review.
The only known-work from this that's missing is the bulk move and renamespacing of source/common/http/access_log, but as discussed earlier, I'll put that into it's own PR.

@ggreenway P.S., thanks for all the work on the docs. This is great.

@mattklein123 the "big move" is merged into this now, and schema validation is done in a common place.  Please take a look.

@ggreenway one other random thought: I think for TCP logging there is probably value in having a log line at the beginning of a connection as well as the end, since it may be common to have very long lived connections. I might throw a TODO to that effect in the TcpProxy filter destructor.

@mattklein123 I think logging at the beginning of a connection should probably be filed as a new GH issue.  A few thoughts:

http connections can also be long-lived, so this would probably apply there too
there isn't much information to log at the beginning of the connection, especially for tcp connections.  Pretty much just when, and the upstream/downstream addresses involved.

@mattklein123 I think logging at the beginning of a connection should probably be filed as a new GH issue. A few thoughts:

Sure sounds good. I do think that IP address is useful for long lived. I need to see for our use case whether that becomes an issue or not.


Add issue number output

What you want to add
An output with the issue number would be awesome.
Why this is needed
It would allow further steps to complete actions on the same issue with ease.
Personally, I want to chain a step using your add comment action after the step containing this action.
Thanks for this action, it's great.

+1


eigenvalues calculation

Hi, I am running the "Segment two object populations and relate Parent to Child" protocol for one nuclei and corresponding RNA image. When I click "Relate and Measure", I get this error:
`<skimage.measure._regionprops.RegionProperties object at 0x3a8204fd0>]
column_buffer = array([0.00000e+000, 1.16699e+000, ..., 3.89789e-310, 3.89832e-310])
i = 5
regions[i] = <skimage.measure._regionprops.RegionProperties object at 0x43964d130>
856     out[orig_prop] = np.copy(column_buffer)
857 else:
858     # precompute property column names and locations
File ~/anaconda3/envs/napari/lib/python3.9/site-packages/skimage/measure/_regionprops.py:723, in RegionProperties.getitem(self=<skimage.measure._regionprops.RegionProperties object>, key='axis_minor_length')
722 def getitem(self, key):
--> 723     value = getattr(self, key, None)
self = <skimage.measure._regionprops.RegionProperties object at 0x43964d130>
key = 'axis_minor_length'
724     if value is not None:
725         return value
File ~/anaconda3/envs/napari/lib/python3.9/site-packages/skimage/measure/_regionprops.py:574, in RegionProperties.axis_minor_length(self=<skimage.measure._regionprops.RegionProperties object>)
571 elif self._ndim == 3:
572     # equivalent to _inertia_eigvals_to_axes_lengths_3D(ev)[-1]
573     ev = self.inertia_tensor_eigvals
--> 574     return sqrt(10 * (-ev[0] + ev[1] + ev[2]))
ev = [4.2975, 3.479680712884784, 0.8178192871152158]
ev[2] = 0.8178192871152158
ev[1] = 3.479680712884784
ev[0] = 4.2975
575 else:
576     raise ValueError("axis_minor_length only available in 2D and 3D")
EmitLoopError:
While emitting signal 'magicgui.widgets.PushButton.changed', a ValueError occurred in a callback:
Signal emitted at: /Users/margaretconde/anaconda3/envs/napari/lib/python3.9/site-packages/magicgui/widgets/bases/_value_widget.py:71, in _on_value_change
>  self.changed.emit(value)
Callback error at: /Users/margaretconde/anaconda3/envs/napari/lib/python3.9/site-packages/skimage/measure/_regionprops.py:574, in axis_minor_length
>  return sqrt(10 * (-ev[0] + ev[1] + ev[2]))
Local variables:
   ev = [4.2975, 3.479680712884784, 0.8178192871152158]`

Hi @margaretcondep, I've checked and this error is caused by skimage.measure when small objects are measured, as you can see here:
https://github.com/scikit-image/scikit-image/issues/6630
I have implemented a workaround that measures regions one by one and when the minor axis length measurement gives the error caused by scikit-image (because too small), it substitutes the value with zero.
This allows measuring all the other properties of RNA spots, or small child objects in general, avoiding the error and completing the measurement process, to get the results written in the .csv table. I think this should close this issue. Please let me know whether it helps with your analysis.


observation: rust-bitcoin does not impl Encodable for Vec<T> because they prefer Vec<u8> specialization for perf. reasons.

https://github.com/rust-bitcoin/rust-bitcoin/issues/2390
You can't have both impl Decodable for Vec<T : Decodable> and impl Decoable for Vec<u8>. Implementing Vec<u8> in terms of reading things byte by byte is kind of slow. Not having Vec<T> inconvenient...
Something tells me we actually don't use Vec<u8> very often, but maybe I'm wrong. Something to remember, maybe we could add some workarounds in places where this matters.

we can always replace Vec<u8> with a custom type Bytes if it is a big performance issue.

Need to see if https://github.com/rust-bitcoin/rust-bitcoin/issues/2390#issuecomment-1906713853 works.

Wait, might that be the reason for our rather poor decode performance? :grimacing: It might not have been a problem at the beginning, we mostly avoided writing variable length byte strings, but now with a lot of TLV encoding it might actually become a problem.

Possibly.

https://github.com/fedimint/fedimint/pull/4145


Raspberry Pi 5 + Raspberry Pi 7inch Display is not working

Description
The official Raspberry Pi 7 inch display does not show anything or illuminate the blacklight when building for and deploying on a Raspberry Pi 5. The HDMI display does show the correct output however. Pictures attached.
Steps to reproduce the issue:
MACHINE = "raspberrypi5"
DISTRO = "poky"
EXTRA_IMAGE_FEATURES = "debug-tweaks"
ENABLE_UART = "1"
IMAGE_INSTALL:append = " kmscube"
LICENSE_FLAGS_ACCEPTED += "synaptics-killswitch"

bitbake core-image-base

Describe the results you received:
The Raspberry Pi 5 never illuminates or shows anything on the official RPi 7inch display including during the boot process.
Describe the results you expected:
During the boot process the display should illuminate the backlight, show the rainbow screen, and then show four raspberry graphics. Then after boot, it should show the console and kmscube when executed.
Additional information you deem important (e.g. issue happens only occasionally):

Attempted using RPi OS - does work correctly.
Attempted using FKMS driver - no change.
Attempted replacing touchscreen, Pi, cable, reseating everything - no change.
Attempted RPi display independently of HDMI - no change.

Additional details (revisions used, host distro, etc.):

poky - scarthgap/kirkstone - latest
meta-raspberrypi - scarthgap/kirkstone - latest

@ykuzma1  what settings for VC4DTBO are you using? Have you tried with vc4-kms-dsi-7inch?

@leon-anavi I am using the default VC4DTBO value. But I have also tried setting VC4DTBO = vc4-fkms-v3d in local.conf with the same results.
Setting dtoverlay=vc4-kms-dsi-7inch in config.txt also has the same issue.


next/release

:tada: This PR is included in version 1.27.0 :tada:
The release is available on GitHub release
Your semantic-release bot :package::rocket:


Change to RecoveryCallback<? extends Object>

It looks ? extends  part missed in 6d2e7341265bd3ce0dd7d3b5aa1ff1fc875e78a8 .

Good catch, @izeye !
Merging....
Anyway I wonder what has driven you to spot such an omission?

@artembilan I'm just watching this repo 😄

... and cherry-picked, BTW


python38Packages.databricks-connect: 8.1.13 -> 8.1.14

Automatic update generated by nixpkgs-update tools. This update was made based on information from passthru.updateScript.
meta.description for python38Packages.databricks-connect is: "Client for connecting to remote Databricks clusters"
meta.homepage for python38Packages.databricks-connect is: "https://pypi.org/project/databricks-connect"
meta.changelog for python38Packages.databricks-connect is: ""
Updates performed

Ran passthru.UpdateScript

To inspect upstream changes
Impact

Checks done (click to expand)

built on NixOS

Warning: a test defined in passthru.tests did not pass

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/beeline passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/beeline.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/docker-image-tool.sh passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/find-spark-home passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/find-spark-home.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/find_spark_home.py passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/load-spark-env.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/load-spark-env.sh passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/pyspark passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/pyspark-bazel passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/pyspark.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/pyspark2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/quicksilver passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/run-example passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/run-example.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-class passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-class.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-class2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-shell passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-shell-bazel passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-shell.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-shell2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-sql passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-sql.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-sql2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-submit passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-submit.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/spark-submit2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/sparkR passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/sparkR.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/sparkR2.cmd passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/databricks-connect passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/.find_spark_home.py-wrapped passed the binary check.

/nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/bin/.databricks-connect-wrapped passed the binary check.

7 of 34 passed binary check by having a zero exit code.

32 of 34 passed binary check by having the new version present in output.

found 8.1.14 with grep in /nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14

found 8.1.14 in filename of file in /nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14

directory tree listing: https://gist.github.com/5a7e4900b319e78a65a8a12dacec8283

du listing: https://gist.github.com/ef5526cffc3b57f8a0860fdd1dbcaacb

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

8 total rebuild path(s)

2 package rebuild(s)

2 x86_64-linux rebuild(s)
2 i686-linux rebuild(s)
2 x86_64-darwin rebuild(s)
2 aarch64-linux rebuild(s)

First fifty rebuilds by attrpath
python38Packages.databricks-connect
python39Packages.databricks-connect

Instructions to test this update (click to expand)

Either download from Cachix:
nix-store -r /nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14 \
  --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 python38Packages.databricks-connect https://github.com/r-ryantm/nixpkgs/archive/5ffc897238e5cef63795a06a028f1e6afbff97f1.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/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14
ls -la /nix/store/l0v4y8d61r64lwpmdpbs1mr01j61dcr5-python3.8-databricks-connect-8.1.14/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

2 packages built:

python38Packages.databricks-connect
python39Packages.databricks-connect

Maintainer pings
cc @kfollesdal for testing.

Result of nixpkgs-review pr 139275 at 5ffc8972 run on aarch64-linux 1

2 packages built successfully:

python38Packages.databricks-connect
python39Packages.databricks-connect


PyPy3 test fixes

Type of changes

[x] Bug fix
[ ] New feature
[ ] Documentation / docstrings
[x] Tests
[ ] Other

Checklist

[x] I've run the latest black with default args on new code.
[x] I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
[ ] I've added tests for new code.
[x] I accept that @willmcgugan may be pedantic in the code review.

Description

Fix test_syntax to compare strings via == rather than is, in order to fix test failure on PyPy3.
Skip a few test_inspect tests on PyPy3 that fail due to different output.

Codecov Report

Merging #1904 (4b8d607) into master (e839bfb) will decrease coverage by 0.02%.
The diff coverage is 98.98%.

:exclamation: Current head 4b8d607 differs from pull request most recent head 8e3a0be. Consider uploading reports for the commit 8e3a0be to get more accurate results

@@            Coverage Diff             @@
##           master    #1904      +/-   ##
==========================================
- Coverage   99.82%   99.79%   -0.03%
==========================================
  Files          71       71
  Lines        6943     6972      +29
==========================================
+ Hits         6931     6958      +27
- Misses         12       14       +2

Flag
Coverage Δ

unittests
99.79% <98.98%> (-0.03%)
:arrow_down:

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files
Coverage Δ

rich/default_styles.py
100.00% <ø> (ø)

rich/markdown.py
100.00% <ø> (ø)

rich/syntax.py
99.27% <97.72%> (-0.34%)
:arrow_down:

rich/pretty.py
99.71% <98.88%> (-0.29%)
:arrow_down:

rich/__main__.py
100.00% <100.00%> (ø)

rich/_inspect.py
100.00% <100.00%> (ø)

rich/color.py
100.00% <100.00%> (ø)

rich/console.py
100.00% <100.00%> (ø)

rich/segment.py
99.33% <100.00%> (+0.04%)
:arrow_up:

rich/table.py
100.00% <100.00%> (ø)

... and 10 more

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 94273ee...8e3a0be. Read the comment docs.

Ping.

Thanks.


Incorrect targets in theory of mind dataset

The theory of mind example dataset contains a few samples that I think have an incorrect target.
I think samples 27, 30, 33 and 99 all have the target of the "true belief" (that is, where the item truly is) whereas the question is asking for the "false belief" that is held by an actor who is not in the room when the item is moved.
For example, in sample 27, because Owen exits the room and then Evelyn moves the shoes from the cupboard to the bucket, Evelyn should think that Owen thinks that the shoes are in the cupboard. However, the target answer of the sample is "bucket".

Interesting! This data was originally taken from OpenAI Evals (https://github.com/openai/evals/blob/main/evals/registry/data/theory_of_mind/LICENSE) which in turn seems to have drawn them from the SocialIQA dataset (https://allenai.org/data/socialiqa).
If there are problems in the targets, maybe best to take them up with the upstream? (just to confirm that there isn't something we are missing).

If there are problems in the targets, maybe best to take them up with the upstream? (just to confirm that there isn't something we are missing).

Thanks, will do 👍

Will close this for now, feel free to re-open once we've established what the right thing is.

What is the status of this @jrhender?
I checked the openai dataset (https://github.com/openai/evals/blob/main/evals/registry/data/theory_of_mind/tomi/test.jsonl) and looks like the aisi dataset is just the first 100 samples from that dataset. It includes the same mistake in sample 27.
OpenAI references a facebook repo https://github.com/facebookresearch/ToMi/tree/master which has somewhat intricate code to automatically generate scenarios. Decent chance there was bug from that - but repo has been archived. (The facebook repo credits another repo https://github.com/kayburns/tom-qa-dataset/blob/master/data/tom.zip)
I think we should manually adjust the examples in AISI. What is the downside of this? @jjallaire

Just wanted to run it doen upstream in case that was a better place for the fix. Given that we've done that, I'd be fine fixing locally


Auth still not working

What

https://world.openfoodfacts.org/product/3665468600260
Auth still not working
This is a continuation of : https://github.com/openfoodfacts/smooth-app/issues/1966
Link for a scannable barcode: barcode-3665468600260 to add a product
<-- add the barcode after the hyphen like barcode-1234 -->

No product there

It might be a problem of server side, I verified in the code that the user has been sent correctly.
In order to test, I added a new product https://fr.openfoodfacts.org/cgi/product.pl?type=edit&code=9771473968012, and made a modification via smooth at 14:21:12
On the product page, we have the good user id:

But on the product edition page :

@stephanegigandet @alexgarel

@cli1005 is right, it's a server side issue.


openstack-service-checks using keystoneclient instead of keystoneauth1

Charm openstack-service-checks is using keystoneclient (which is deprecated) instead of keystoneauth1
Noticed this issue while running openstack-service-checks functional tests, we can see the following warning messages in the logs
unit-openstack-service-checks-4: 18:12:32 WARNING unit.openstack-service-checks/4.identity-notifications-relation-changed /usr/lib/python3/dist-packages/keystoneauth1/adapter.py:179: UserWarning: Using keystoneclient sessions has been deprecated. Please update your software to use keystoneauth1.
unit-openstack-service-checks-4: 18:12:32 WARNING unit.openstack-service-checks/4.identity-notifications-relation-changed   warnings.warn('Using keystoneclient sessions has been deprecated. '
unit-openstack-service-checks-4: 18:12:32 INFO juju.worker.uniter.operation ran "identity-notifications-relation-changed" hook (via explicit, bespoke hook script)
unit-nagios-3: 18:12:53 INFO juju.worker.uniter.operation skipped "update-status" hook (missing)
To reproduce this issue please use the bundle.yaml attached and add any of the following relations
juju add-relation keystone:identity-credentials openstack-service-checks:identity-credentials
juju add-relation keystone:identity-notifications openstack-service-checks:identity-notifications
And use "juju debug-log" to watch log output and the above warning messages
juju-crashdump file is attached
The following application versions were used
cs:keystone-323
cs:nagios-44
cs:nrpe-73
cs:~canonical-bootstack/openstack-service-checks-32
cs:percona-cluster-29

(by hernandanielg)

(by hernandanielg)


Serial editor (back button) UI fixes

Put text near the back button. Make it the size of the menu bar icons, and add text “Back to Code”, use primary color.
As per feedback from David.

https://github.com/Microsoft/pxt/pull/4089


LogoDesign

Have you read the Contributing Guidelines on Pull Requests?
(Write your answer here.)
Description
This design of logo is better because It is much more modern.
Checklist

[x] I've read the contribution guidelines.
[x] This PR mets all the requirements like Clean Code, proper README and Documentation

Related Issues or Pull Requests
(Write your answer here.)
Screenshots (if any)

@ashishsahu1 Attach the image in the description, under screenshots section.

@ashishsahu1 Please write the issue number it solves fromthe next PR onwards. Else, great logo : )


[feature request] Update instructions

Describe the solution you'd like
Hi. I know this is something really straightforward, but when i was starting with lnxlink a while ago i had issues caused by not following the official installation instruction, so i think that we also should have an official update instruction just to be confident that nothing will be broken in the process.
Additional context
No response

I have been working on how to make the installation as easy as possible, but every distribution has it's own dependencies, so it's hard finding what needs to be installed.
I've created a script that makes it easy to install it which can also work as an update script. As far as I am aware, it works on most Linux distributions:
curl -L https://raw.githubusercontent.com/bkbilly/lnxlink/master/install.sh | bash

My recommended and faster way to update is to use the update module on your configuration which is enabled by default.
This checks for the latest release every 24 hours and if a new version is found, an install option is shown on Home Assistant.
If you don't use Home Assistant, or want to do this manually, you can start the update process with an MQTT message as described here.

When was the update module introduced? Im running 2023.10.0 and publishing the message doesnt work

It was first used on version 2023.12.0 that worked if it was installed with pip on the system.
It became more generic, including PIPX and manual virtual environment, on the version 2024.2.1.

The latest versions of LNXlink can auto update, so I consider this issue fixed and I'll close it.
If you still have issues updating, feel free to reopen it.


Revert "Build(deps): Bump ioredis from 5.1.0 to 5.2.0"

Reverts microlinkhq/keyv#121

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

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

Files with Coverage Reduction
New Missed Lines
%

packages/redis/src/index.js
2
96.43%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1228

Relevant Lines:
1247

💛  - Coveralls


fix: open the http port for web access without using a certificate

Codecov Report
All modified and coverable lines are covered by tests :white_check_mark:

Project coverage is 75.45%. Comparing base (654f70b) to head (537e6ae).

Additional details and impacted files
@@           Coverage Diff           @@
##             main       #7   +/-   ##
=======================================
  Coverage   75.45%   75.45%
=======================================
  Files           9        9
  Lines         220      220
=======================================
  Hits          166      166
  Misses         45       45
  Partials        9        9

:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.

http://quintus.sh 👀


Problem on other phones ?

Is there a problem in the camera running on some  phones ? I tried on HTC one e8 and an one plus one. Works fine on the HTC on the one plus one it shows the preview but app stops as soon as I press capture But video recording works fine.
Any idea why ?

Any idea why ?

No. You did not provide me with a stack trace. You also did not provide me with a description of how to reproduce the problem, including code if this is not reproducible via the demo app. Without those things, there is nothing that I can really do.


Update http4s-blaze-client, ... to 0.21.25

Updates

org.http4s:http4s-blaze-client
org.http4s:http4s-blaze-server
org.http4s:http4s-circe
org.http4s:http4s-core
org.http4s:http4s-dsl
org.http4s:http4s-prometheus-metrics

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

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [ { groupId = "org.http4s" } ]

labels: library-update, semver-patch

Superseded by #1011.


UC1 ACP WAC comparison

I would suggest to create one fenced code block per resource. Alternatively using Trig would allow to keep statements in apropiate named graphs. I think having a fenced code block with turtle for each resource might be the simplest.


Hardcoded wrap run alignment

Is there an existing issue for this?

[X] I have searched the existing issues

Flutter Quill version
9.x
Other Flutter Quill packages versions
Quill 9.x
Steps to reproduce
All this effort at wasted customization and there is a hardcoded runalignment on the toolbar wrap of '4'.
Why is that?
We cannot accurately control the space between icon widgets and then we are also force to maintain a blank Sizedbox wasting memory on top of it.
Expected results
Remove a run alignment int he wrap when you have already wasted so much resources on the spacer widget
Actual results
Something more sensible
Code sample
Code sample
[Paste your code here]

Screenshots or Video

Screenshots / Video demonstration
[Upload media here]

Logs
Logs
[Paste your logs here]

Are you talking about the QuillSimpleToolbar? As we said in the PR, we want to confirm with Quill js
We want to encourage the developer to create his own toolbar just like React Quill or quill js
The final decision is from @singerdmx
You can use the QuillToolbar and use the buttons and customize them using the childBuilder
Besides I think you are talking about changes from the old versions before 8.0.0
because it was like that when the library first started so it's not related to the customization options

That's not really a bug but I just added the option to change the value
It was with no customization option in the first place
I didn't touch it
The commit is to the dev branch
If you have any other questions feel free to ask us at any time.


Getting "failed to check whether build ID symbol exists error" for parca-agent

Deployed parca into my v1.21.9 cluster using:
kubectl create namespace parca
kubectl apply -f https://github.com/parca-dev/parca/releases/download/v0.8.1/kubernetes-manifest.yaml
kubectl apply -f https://github.com/parca-dev/parca-agent/releases/download/v0.5.0/kubernetes-manifest.yaml

No profiles are generated and parca-agent repeatedly has the errors:
level=warn ts=2022-03-17T20:43:04.616549742Z caller=debuginfo.go:154 component=debuginfoextractor msg="failed to check whether build ID symbol exists" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: lookup parca.parca.svc.cluster.local: no such host\""
level=error ts=2022-03-17T20:43:09.063871255Z caller=write_client.go:85 msg="Write client failed to send profiles" err="rpc error: code = Unavailable desc = connection error: desc = \"transport: Error while dialing dial tcp: lookup parca.parca.svc.cluster.local: no such host\""

The DNS name appears to work fine when using nslookup:
# nslookup parca.parca.svc.cluster.local <IP_ADDRESS>
Server:        <IP_ADDRESS>
Address:    <IP_ADDRESS>#53

Name:    parca.parca.svc.cluster.local
Address: <IP_ADDRESS>

Hello @dnoland1, thanks for reporting the issue.
It seems odd. It looks like agent failed connecting to parca-server. Rather, I would say it has connected when it's started its lifecycle but failed to send data on later stages. Could you please share more information on your setup?

@kakkoyun I'm running a v1.21.9 RKE cluster on SLES 15 SP3 nodes on AWS. I've tried two other distributions - K3s and RKE2 and experienced the same problem. However, if I try Ubuntu 20.04.4, it works fine. So I suspect it's related to something in the OS. I'm using the public AMI ami-064b1c0dca9a64b20 in us-west-2 which is a vanilla SLES. I've been discussing on discord as well.

@dnoland1 Thanks for the detailed information. I have also seen the discussions on the Discord. We'll look into it.

Thanks so much! If you need more information or anything I can do to help, please let me know.

@dnoland1 Have you had a chance to test the latest stable versions of Parca and Parca Agent? Does the error persists?

@kakkoyun I tried again, but could not get far. After running:
kubectl create namespace parca
kubectl apply -f https://github.com/parca-dev/parca/releases/download/v0.13.0/kubernetes-manifest.yaml

The parca pod was crashing:
NAME                     READY   STATUS             RESTARTS     AGE
parca-7f87f45f9d-7n8bt   0/1     CrashLoopBackOff   1 (6s ago)   16s

Logs:
$ kubectl logs -n parca parca-7f87f45f9d-7n8bt
ooooooooo.
`888   `Y88.
 888   .d88'  .oooo.   oooo d8b  .ooooo.   .oooo.
 888ooo88P'  `P  )88b  `888""8P d88' `"Y8 `P  )88b
 888          .oP"888   888     888        .oP"888
 888         d8(  888   888     888   .o8 d8(  888
o888o        `Y888""8o d888b    `Y8bod8P' `Y888""8o

level=error name=parca ts=2022-11-07T22:47:44.664594609Z caller=parca.go:138 msg="failed to read config" path=/var/parca/parca.yaml
level=error name=parca ts=2022-11-07T22:47:44.66467657Z caller=main.go:59 msg="Program exited with error" err="parsing YAML file /var/parca/parca.yaml: yaml: unmarshal errors:\n  line 1: field debug_info not found in type config.Config"

Thanks for trying :) This is an issue we need to fix on the server-side.


SOLR-17153: CloudSolrClient should not throw "Collection not found" with an out-dated ClusterState

…ted cluster state
https://issues.apache.org/jira/browse/SOLR-17153

Description
At present, when CloudSolrClient is instructed to send a request to a collection it deems non-existent due to its outdated local ClusterState view, it fails locally, which is undesired. This failure should be addressed. Moreover, many SolrCloud tests should remove their waitForState calls following collection creation. Matters concerning other stale states are not addressed here.
Similar changes will be required on the server side to handle "Collection Not Found" errors resulting from outdated cluster state.
Solution
If neither CloudSolrClient nor HttpSolrCall (server) can locate a collection, trigger a forced fetch of the collection from ZooKeeper and update the local cluster state accordingly.
Tests
Please describe the tests you've developed or run to confirm this patch implements the feature or solves the problem.
Change existing tests to eliminate waitForState() and waitForActiveCollection() calls that were previously present after collection creation. These calls are unnecessary due to the enhancements introduced in this PR. All modified tests have been thoroughly verified to ensure their successful execution. These changes will be part of a separate commit to follow.
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.
[] I have added tests for my changes.
[] I have added documentation for the Reference Guide

I'm glad to see the logic that was in V2HttpCall made more common (move to base class) as it should not have been specific to V2. Perhaps my oversight 6 years ago.
Updating ZkClientClusterStateProvider is only one of the two ClusterStateProviders. I suspect the other Http one can be tested to show that this problem existed (and still exists now!) whereas probably too hard to bother with ZkClientClusterStateProvider; unclear how to trigger a pause in ZK watching without being too invasive.
Assuming we address this for both providers, the javadocs for this method ought to communicate the guarantee on not returning null if the collection exists.

The reason I did not make the logic consistent across both providers is because BaseHttpClusterStateProvider, where the logic for getState() is implemented for the http version, checks all livenodes for presence of the collection/collectionRef via a SolrQuery. I felt that was comprehensive enough.
I can update the javadoc for the method as per your suggestion.

I'm glad to see the logic that was in V2HttpCall made more common (move to base class) as it should not have been specific to V2. Perhaps my oversight 6 years ago.
Updating ZkClientClusterStateProvider is only one of the two ClusterStateProviders. I suspect the other Http one can be tested to show that this problem existed (and still exists now!) whereas probably too hard to bother with ZkClientClusterStateProvider; unclear how to trigger a pause in ZK watching without being too invasive.
Assuming we address this for both providers, the javadocs for this method ought to communicate the guarantee on not returning null if the collection exists.

I also noticed javadoc for ClusterStateProvider.getState() does mention null means collection does not exit. I refined the wording a bit.

The reason I did not make the logic consistent across both providers is because BaseHttpClusterStateProvider, where the logic for getState() is implemented for the http version, checks all livenodes for presence of the collection/collectionRef via a SolrQuery. I felt that was comprehensive enough.

OMG I didn't look; so glad to see the correct implementation there already :-)
Please add a CHANGES.txt for the next 9.x version under Improvements. I suppose this may be ready to merge.
In a separate PR, I'd like to see most waitForState calls that follow collection creation to be removed.

I pushed a commit to exclude waitForState() calls after collection creation. Will do another pass to identify other hidden calls.

Proposed CHANGES.txt under 9.6 Bug Fix:

CloudSolrClient and Solr could in rare circumstances report that a collection does not exist right after it was actually just created (an eventually consistent race issue).  Now it double-checks before yielding such an error.

It's tempting to call it an improvement but this ought to have been an explicit guarantee all along for such a trivial create-then-index (as seen in tests we have on a high scale cluster).
I plan to merge late Tuesday, or maybe sooner if I get another +1.

I'd be careful removing all the waits in tests without some pretty thorough testing in some slow environments - for one, it's a bandaid rather than a fix, there is still a race, it's just harder to hit, and for two, the bug does not just apply to the collection level. Collections are created piecemeal, and the collection can exist but, for example, a necessary shard may not yet.

I was aware we may just be moving to a new problem, albeit a situation that is even more rare than what we have today.  @markrmiller can you recommend a specific test or a way to make a test that has an incomplete DocCollection and tries to use it client side to route?  As I write that; maybe it's not too hard to create a cluster state provider in a SolrJ test that has the state we want.  The behavior we want to see client side is that it gets routed to Solr; don't give up client-side.  In practice this gives even more time for the server to get the subsequent request and for this DocCollection to become complete.  But if it's incomplete, I suspect an error.  I've not seen this happen in practice, at least to my knowledge.

Not off hand, but you can likely just create a collection, create a DocCollection with the state you want, convert it to json with the code that does that, and then overwrite cluster state straight to ZK.
But my point is, at least when I glanced at the change, it looked like it retried if the collection wasn't there. If that is the case, even if that worked 100%,it would only cover a fraction of the fails the waitFor calls handle in tests. They wait for every shard and every replica that a collection api call will create (it's not just collection create calls).
Without ensuring every shard and replica is there, rare, hard to debug timing fails will return (less rare on CI runs or in resource constrained envs), as a test will often do something that expects all parts of what they just said to create to exist once that call has returned.

Maybe in this PR or another we'll add a test like you (Mark) describe to ensure that CloudSolrClient directs requests to Solr in all circumstances (giving up on smart routing to a core if this can't be determined) so long as we have confirmed the collection in fact exists (which again requires talking to the backend).  My concern is that, as we saw here before the changes, CloudSolrClient would yield an error prematurely.
Hmmm; I wonder what the state.json looks like at each incremental step of a trivial one-shard 2-replica collection.  Something to investigate.  If it's a bit incremental; it'd be cool if Solr might be improved to get the collection to exist with at least a core in one-shot, thus eliminating the possibility a Solr node having a collection's state that is so partial that it can't even route a request to it.
It'd be nice to remove so many waitForState's but maybe we can't in good conscience.

@markrmiller , thinking back to your feedback, I have an idea of a solution in several steps:
(A)  In https://issues.apache.org/jira/browse/SOLR-17601 I propose using HTTP response headers to inform the client of the state version of a collection that the client is interacting with.  Imagine if collection admin commands participated in this (not just handlers on the core) like create collection.  Thus when CREATE returns, the header indicates the version of the final created state.   Let's also assume waitForState=true[1].
(B) Even though the CloudSolrClient's cache[2] wouldn't yet have a DocCollection, let's imagine an enhancement to this cache in which it can hold a cache entry without a DocCollection but with a version to indicate we now want this version (or greater).  At least for HTTP ClusterStateProvider, it will fetch the CLUSTERSTATE from Solr via HTTP.  What's new -- imagine it adds the _stateVer_ parameter.
(C) HttpSolrCall will see the _stateVer_ param.  If it's DocCollection isn't as high as this version, it forces an update.  I think this part works as-is but perhaps some work may be needed.
[1] why the heck is waitForState not true by default?
[2] the CSC's cache should move to ClusterStateProvider -- https://issues.apache.org/jira/browse/SOLR-17604

Yeah, that’s how I would do it. For any command that alters the state, return the version of the modified state and have the client make sure that’s at least the version it’s using for the next command. The Cloud client does something like this for some case(s), (if I remember right, as something that kicks in on retries), but I don’t recall it properly covering this stuff.


Update Character.cs

Should this be an error obsolete? I assume the function call just doesn't work at all since it will pass chara as a1.


RouteAware should have didReplace callback

Use case
RouteAware class have didPopNext, didPush, didPop, and didPushNext callback,
but if a route is replaced, it will not be notified.
Proposal
I think we should add a didReplace callback to RouteAware and RouteObserver class.

Also need to have didRemove callback

Also need to have didRemove callback

We already have a didPop callback, what's the difference?

@crizant
pushNamedAndRemoveUntil does not trigger didPop, only didRemove. 🙃


Added docker-compose w/ ownCloud & readme.

Supports issue #70
Added docker-compose & readme.

Includes ownCloud services for self hosting

Hello, I am sort-off new to this project.
Is possible to use webrcade in docker by mounting the roms/bios directories (ideally readonly) without having to setup a owncloud?

Hello, I am sort-off new to this project.
Is possible to use webrcade in docker by mounting the roms/bios directories (ideally readonly) without having to setup a owncloud?

Check out the following:
https://github.com/webrcade/webrcade/issues/7#issuecomment-1314400463
It supports mounting a content portion that is exposed, thus can be used for hosting, etc.
Chris.


Inline source maps in dev build

This was changed in https://github.com/microsoft/azuredatastudio/pull/18781/files
Unfortunately, not inlining the source maps breaks debugging. For some reason the JS debugger isn't able to properly load the map.js files, which results in breakpoints not being able to be bound.
So to unblock that I'm reverting this change by default and will follow up with trying to understand why that isn't working and whether there's a better fix we can make. The SQL_NO_INLINE_SOURCEMAP environment variable controls the inlining so we can disable it during CI runs to enable reporting to coveralls to still generate the correct coverage.

@caohai @corivera This should fix the issues you were seeing with debugging

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
3 unchanged lines in 1 file lost coverage.
Overall coverage decreased (-0.002%) to 42.355%

Files with Coverage Reduction
New Missed Lines
%

extensions/machine-learning/src/common/processService.ts
3
77.78%

Totals

Change from base Build<PHONE_NUMBER>:
-0.002%

Covered Lines:
27568

Relevant Lines:
60839

💛  - Coveralls


Compiling on ARM architecture

I am working on a jetson nano platform (ARM). I get this error while compiling
cc: error: unrecognized command line option ‘-msse2’
make: *** [Makefile:51: ksw2_ll_sse.o] Error 1

The original Minimap2 uses the SSE2 instruction set, so does the test data generator in this project.  You may want to run the generator on an x86 computer to generate the data and copy the data to your ARM platform.
Note that we did not test on Jetson and I am not sure if the CUDA code works.  The CPU acceleration may not work either because it was optimized for Intel CPU.

The original Minimap2 uses the SSE2 instruction set, so does the test data generator in this project.  You may want to run the generator on an x86 computer to generate the data and copy the data to your ARM platform.
Note that we did not test on Jetson and I am not sure if the CUDA code works.  The CPU acceleration may not work either because it was optimized for Intel CPU.


CUDA pytorch installation breaks entire pipeline because of numpy 2.0

This is not so much an issue from your side, but just for future reference: On Windows, when using conda install pytorch==2.1.1 torchvision==0.16.1 monai=1.3.0 pytorch-cuda=12.1 -c conda-forge -c pytorch -c nvidia, after running pip install instanseg-torch, numpy 2.0.2 gets installed through conda - on top of pypi's numpy 1.26.4...
Both installations are present, and since numpy 2 is not backwards compatible with 1.x, many operations fail.
The way we found to solve this was to essentially reinstall numpy 1.26.4:

conda install pytorch==2.1.1 torchvision==0.16.1 monai=1.3.0 pytorch-cuda=12.1 -c conda-forge -c pytorch -c nvidia
pip install cupy-cuda12x
pip uninstall numpy
pip install numpy==1.26.4

Would love to hear if there is a more straightforward way, but in any case I hope this helps someone else struggling with setting up their virtual environment with GPU acceleration!
Edit: Just to add to this: if you want to just perform inference (e.g., using the "fluorescence_nuclei_and_cells" model), you might be able to avoid all of this by not installing torchvision and monai, since those conda packages are primarily used for model training. Can't say anything about future developments, though.

Apologies if this wasn't clear in the documentation.
pip install instanseg-torch is a replacement of the conda install. It contains all the libraries for inference.
For training you can install pip install instanseg-torch[full] OR follow the conda/mamba setup.

I suppose I was too used to having to install pytorch-cuda etc separately through conda! Thank you for the clarification!
P.S. pip install instanseg-torch[full] failed to run for me when I ran it in a fresh Python3.9 environment.

Actually, scratch that. I just did the following:

conda create -n temp python=3.9 & conda activate temp
pip install instanseg-torch

Then, using this environment, I tried to run an image through .eval_small_image(), where I got the following output:
Model fluorescence_nuclei_and_cells downloaded and extracted to [...]\miniconda3\envs\temp\lib\site-packages\instanseg\utils\../bioimageio_models/
Requesting default device: cpu
[...]\miniconda3\envs\temp\lib\site-packages\pydantic\_migration.py:283: UserWarning: `pydantic.error_wrappers:ValidationError` has been moved to `pydantic:ValidationError`.
  warnings.warn(f'`{import_path}` has been moved to `{new_location}`.')
[...]\miniconda3\envs\temp\lib\site-packages\torch\amp\autocast_mode.py:266: UserWarning: User provided device_type of 'cuda', but CUDA is not available. Disabling
  warnings.warn(

Then, I ran the following line in the environment:
python -c "import torch; print('CUDA is available') if torch.cuda.is_available() else print('CUDA is not available')"

Output: CUDA is not available
Then, when I run the conda install commands, I get the output: CUDA is available. And the model inference runs over CUDA (i.e., the GPU).
Clearly, there is no GPU support in the regular installation of instanseg-torch. So, the command conda install pytorch==2.1.1 pytorch-cuda=12.1 -c conda-forge -c pytorch -c nvidia must be run.
This issue concerns the one command on GPU acceleration, that instructs end-users to also install torchvision and monai, which essentially break the entire code because those packages force-install numpy 2.x as their dependency.

This is strange (and really annoying). We have tested this on multiple (linux) machines and it works for me every time.

We're on Windows here, and I suppose the fix for those machines is to leave out torchvision and monai from the conda install command, unless the user wants to train their own model (where they'd need torchvision and monai).
Overall, this is a pretty minor issue, but it caused us a lot of headache setting it up for large filesize & high throughput analysis. Especially since neither conda list nor pip list will display the numpy 2.x installation, it will just list the one installed by pip beforehand (1.26.4).


QEMU guest agent fails to start

Describe the bug
I'm running a NixOS QEMU VM in which I enable the guest agent and spice-vdagent to get, among other things, copy and paste between host and guest
  virtualisation = {
    cores = 4;
    diskImage = "/home/.../vm-disk.qcow2";
    diskSize  = 1024;
    hypervGuest.enable = true;
    memorySize = 8192;
    qemu.guestAgent.enable = true;
    qemu.options = [ "-display sdl,gl=on" "-vga virtio" ];
  };

  # Enable clipboard sharing with host
  services.spice-vdagentd.enable = true;

Copy and paste doesn't work and if I check the status of the guest agent I see that it fails

In particular the directory /run/qemu-ga doesn't exist in the guest disk image. I suppose that's the reason for the failure.
The spice-vdagentd.service does run.
Steps To Reproduce
Steps to reproduce the behavior:

Create a NixOS QEMU VM with virtualisation.qemu.guestAgent.enable = true; and services.spice-vdagentd.enable = true; in the configuration.nix file.
Start the VM and check the status of the guest agent service systemctl status qemu-guest-agent.service.
Check copy/paste between host and guest.

Expected behavior
With the guest agent and spice-vdagent service I would expect copy and paste to work between host and guest.
Notify maintainers
@teto @pennae

Metadata
Please run nix-shell -p nix-info --run "nix-info -m" and paste the result.
[user@system:~]$ nix-shell -p nix-info --run "nix-info -m"
 - system: `"x86_64-linux"`
 - host os: `Linux 6.0.11, NixOS, 22.11 (Raccoon), 22.11.726.04a75b2eecc`
 - multi-user?: `yes`
 - sandbox: `yes`
 - version: `nix-env (Nix) 2.11.0`
 - channels(root): `"nixos-22.11"`
 - nixpkgs: `/nix/var/nix/profiles/per-user/root/channels/nixos`

Starting the agent manually, seems to suggest that the problem is that it can't find the channel to the host


Generate certificates for ceph_hci_pre service

By using the feature [1] to generate certs, this PR will enable tlsCertsEnabled for ceph_hci_pre service which should generate certs for the service on each node in the nodeset.
[1] https://github.com/openstack-k8s-operators/dataplane-operator/pull/553

recheck

/ok-to-test

The ceph_hci_pre EDPM service prepares EDPM nodes to host Ceph. Right now that only consists of opening firewall ports though the space is there for it to do more.
https://github.com/openstack-k8s-operators/edpm-ansible/blob/main/roles/edpm_ceph_hci_pre/tasks/firewall.yml
My understanding from the following PR is that hasTLSCerts: True results in certs being generated and mounted to the AEE pod so that the playbook could copy those certs to EDPM nodes if needed.
https://github.com/openstack-k8s-operators/dataplane-operator/pull/553
I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to be encrypted, unless the intent is for Ceph to somehow use those certificates.

I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the >ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to >be encrypted, unless the intent is for Ceph to somehow use those certificates.
Yes the intent here is just to generate a certificate (via some ceph related dataplane service) and use it for ceph dashboard/RGW if needed.

The ceph_hci_pre EDPM service prepares EDPM nodes to host Ceph. Right now that only consists of opening firewall ports though the space is there for it to do more.
https://github.com/openstack-k8s-operators/edpm-ansible/blob/main/roles/edpm_ceph_hci_pre/tasks/firewall.yml
My understanding from the following PR is that hasTLSCerts: True results in certs being generated and mounted to the AEE pod so that the playbook could copy those certs to EDPM nodes if needed.
#553
I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to be encrypted, unless the intent is for Ceph to somehow use those certificates.

So (just to make sure I understand this part correctly) what the hasTLSCerts: True  does is basically creating crt/key and get them mounted to AEE: if you don't have the logic to use them those files are not synced anywhere in the EDPM nodes, right?
I agree that ceph_hci_pre is not the right place to manage this part, and I was hoping to use crt/key already present in the EDPM nodes (w/o  regenerating them explicitly), but I suspect it depends on the strategy.
If they're "per service" generated, then we might want to have a little playbook that put them in the right place (e.g. dataplane-operator generates them and once they get mounted to AEE we can invoke a ceph related playbook to sync them in the EDPM nodes).
Not sure we can simplify this model further: the ci-framework ceph playbook assumes both crt/key exist in a given path, but I'm wondering if we can simply request a new crt/key for the Ceph services.

There are  a couple of reviews currently in flight that will affect how all of this will be put together.

https://github.com/openstack-k8s-operators/edpm-ansible/pull/525  (just merged)
https://github.com/openstack-k8s-operators/dataplane-operator/pull/585

Once these land, there will be a new dataplane service ("install-certs") which will take any certs generated for a particular service (per node) and copy them to specific locations on that node.  Specifically,

cert at /var/lib/openstack/certs//tls.crt
key at /var/lib/openstack/certs//tls.key
cacert bundle at /var/lib/openstack/cacerts//tls-ca-bundle.pem

The  that is there corresponds to services which has set tlsCertsEnabled and the issuer as you've done in this patch.  At this point, we have certs generated for nova and libvirt.
These certs/keys/cacerts will be available for any of the edpm_* roles to use as they see fit.  In the nova role, for instance, they use kolla to mount the certs to the locations they want in the container.  In libvirt, they copy to /etc/pki/... directly on the host because that's where libvirt is running.
Because the install-certs service runs first, nova also has access to and can mount libvirt certs as needed.
Ping me here on or on slack, and we can discuss what your requirements are and how to meet them.

I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the >ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to >be encrypted, unless the intent is for Ceph to somehow use those certificates.

Yes the intent here is just to generate a certificate (via some ceph related dataplane service) and use it for ceph dashboard/RGW if needed.

I'm not sure that EDPM should be doing that though.

I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the >ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to >be encrypted, unless the intent is for Ceph to somehow use those certificates.

Yes the intent here is just to generate a certificate (via some ceph related dataplane service) and use it for ceph dashboard/RGW if needed.

I'm not sure that EDPM should be doing that though.

Me neither. EDPM isn't installing ceph dashboard right? Shouldn't cephadm be used for that? Is that your concern as well?

I agree that we will want certs on EDPM nodes for any service which is deployed that needs those certs. I don't see what the >ceph_hci_pre EDPM service would do with certificates however. It doesn't deploy a service listening on a port which needs to >be encrypted, unless the intent is for Ceph to somehow use those certificates.

Yes the intent here is just to generate a certificate (via some ceph related dataplane service) and use it for ceph dashboard/RGW if needed.

I'm not sure that EDPM should be doing that though.

Me neither. EDPM isn't installing ceph dashboard right? Shouldn't cephadm be used for that? Is that your concern as well?

yes, same concerns.

As per the discussions , as Ceph is not part of the deployment, EDPM is not supposed to generate certificates .
Ceph is deployed outside the product,  cifmw itself should generate it (may be self-signed) or use existing certs in EDPM node
This change can be abandoned.


Winget does nothing -- progress bar stays at 0%

Brief description of your issue
Winget appears to do nothing. It gets stuck at 0% when attempting to do anything involving a progress bar.

Steps to reproduce

Run a command, such as winget search winget or winget upgrade or winget export output.txt

Expected behavior
Something should happen
Actual behavior
The progress bar stays at 0%.
In order to exit, I must press Ctrl-C twice.
Environment
Windows Package Manager v1.4.11071
Copyright (c) Microsoft Corporation. All rights reserved.

Windows: Windows.Desktop v10.0.22000.1817
System Architecture: X64
Package: Microsoft.DesktopAppInstaller v1.19.11071.0

Logs: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\DiagOutputDir

User Settings: %LOCALAPPDATA%\Packages\Microsoft.DesktopAppInstaller_8wekyb3d8bbwe\LocalState\settings.json

Links
---------------------------------------------------------------------------
Privacy Statement   https://aka.ms/winget-privacy
License Agreement   https://aka.ms/winget-license
Third Party Notices https://aka.ms/winget-3rdPartyNotice
Homepage            https://aka.ms/winget
Windows Store Terms https://www.microsoft.com/en-us/storedocs/terms-of-sale

Can you try uninstalling WinGet with the Windows Store, then reinstalling from https://aka.ms/getwinget ?

I can, but I'm filing an issue here because it's not working correctly, and it can be improved. The winget CLI isn't properly handling something, and is getting stuck in some sort of loop. My system is in a state where we can work to identify the source of the problem rather than papering over it.
I feel that it shouldn't get into a state where it doesn't do anything, which is why I have filed the bug. "Reinstall the program" is a deeply unsatisfactory solution, but if there isn't interest in solving the cause of these issues then I can simply try working around it by reinstalling.

We've done some work in WinGet 1.5 to catch a few of the edge cases where this happens. Can you try just upgrading to WinGet 1.5 and see if this problem persists?

How do I get WinGet 1.5? The link at https://aka.ms/getwinget installs Version 1.20.1881.0, not 1.50:

How do I get WinGet 1.5? The link at https://aka.ms/getwinget installs Version 1.20.1881.0, not 1.50:

The version 1.20.1881.0 of AppInstaller should be the 1.5 version of WinGet. The reason for the discrepancy is because WinGet is bundled inside of AppInstaller. You can verify the version of WinGet is installed after the upgrade using winget --version

Alright, that's a bit confuising then. Regardless, the installer is taking a long time. Here is how far it is after four hours:

Any update to this? I am reinstalling winget, and it is stuck at 10%.
Mine is v1.22.x

We've released WinGet 1.8.
Is this problem still happening?

My theory is that this was due to a failure in the Windows Installer service, which had zero feedback on the failure.
Because Winget didn't have a timeout, it would just sit there.
The fix would be to prevent the Windows Installer Service from breaking, and provide information on why that service failed. However, within the confines of Winget, the workaround would be to detect that things are not right and put up an error.
As the original reporter, I am no longer experiencing this issue since I have since restarted the entire system and things are working again. I can't say whether Winget 1.8 fixes the issue since I can no longer reproduce it myself.


Missing CPU HW counters in perfetto traces

It appears that CPU HW counters are not showing up in perfetto traces. The source of this issue appears to be an empty array of labels for HW counter labels.

Unfortunately this cannot be caught in standard CI bc the perf_event_paranoid is set to 4 on the machines the CI runs on and cannot be modified


Add .NETCoreApp 1.1 runtime packages to FrameworkPackages

These packages are referenced when building RID-specific / self-contained applications and referencing 1.x era .NET Core packages.

I think I might have some duplicates I can remove.  Will test locally and reduce.


Spring - Add eventhub binder health indicator

In this PR, I'm going to add the health indicator implementation for azure-spring-cloud-stream-binder-eventhubs.
Spring Cloud Stream provides the default BindersHealthIndicatorAutoConfiguration, it will:

Register a DefaultBinderFactory.Listener
DefaultBinderFactory will call the listener's afterBinderContextInitialized function after binder context's initialized. In this function, the BindersHealthContributor will add the health indicator implementation of each binder.

So what we need to do is to add an EventHubHealthIndicator and inject this bean into the binder context.
Ideally, the health indicator will hold an instance of the EH client to test the connectivity between EH and the application. But since all EH clients are created by and cached in the EventHubClientFactory, and one EH client only related to an Event Hub instead of the Event Hub Namespace, so in my implementation, a new EH producer client will be created to test the connectivity.
https://github.com/Azure/azure-sdk-for-java/blob/6bc09878bc7fd49ff76611ac604d30fae2defb50/sdk/spring/azure-spring-integration-eventhubs/src/main/java/com/azure/spring/integration/eventhub/api/EventHubClientFactory.java#L19-L30
@stliu mentioned that the connection string could hold different claims (LISTEN, SEND, MANAGE), and a connection string only with SEND claim might not be used to create a producer client. I did some tests locally, and it turned out that we could create the producer with a SEND claim successfully.

There're several configurations related to show bindings/binders info in the actuator endpoint.
management:
  health:
    binders:
      enabled: true              // whether to enable the binders in the health endpoint, default is true
  endpoint:
    health:
      show-details: always     // when to show full health details, default is never
  endpoints:
    web:
      exposure:
        include: health, info, bindings        // whether to include the bindings in the actuator endpoint, default to health, info

More discussions with the EH sdk team, https://github.com/Azure/azure-sdk-for-java/issues/19578
TODOs:

[ ] Add integration tests.
[ ] Allow users to configure the health indicator timeout.

@stliu mentioned that the connection string could hold different claims (LISTEN, SEND, MANAGE), and a connection string only with SEND claim might not be used to create a producer client. I did some tests locally, and it turned out that we could create the producer with a SEND claim successfully.

how about the other way, producer with LISTEN claim?

@stliu
The case I tested was producerClient + LISTEN claim, was wrong in the description, I updated the description too.


Button Design Improvement

Describe the Feature you want to end
Working on the styling of the button to make it consistent with overall theme of the website.
Expected behavior
Improved design
Screenshots (optional)
Current Design

Expected Updated Design

Additional context (optional )
No

Hi @MohitGupta121
Kindly assign me this issue.

Hi @MohitGupta121
Kindly assign me this issue.

@MohitGupta121 Kindly assign me this issue


i386 Rusdesk build for Linux is not supported by mouce >>>>"expected u32, found u64"

Compiling clang-sys v1.3.3
error[E0308]: mismatched types
--> /root/.cargo/git/checkouts/mouce-da81cbdbeafc6640/26da8d4/src/nix/uinput.rs:186:23
|
186 | ioctl(fd, UI_DEV_DESTROY as u64);
| ^^^^^^^^^^^^^^^^^^^^^ expected u32, found u64
|
help: you can convert a u64 to a u32 and panic if the converted value doesn't fit
|
186 | ioctl(fd, (UI_DEV_DESTROY as u64).try_into().unwrap());
| + +++++++++++++++++++++
For more information about this error, try rustc --explain E0308.
error: could not compile mouce due to previous error

This issue was already fixed with #10 . After this merge I can compile for 32 bit systems. It looks like you are referencing to and old version of the project, can you clone from the master branch and try again with latest version?

Closing the issue due to inactivity.


Follow up on why some compliance documents are in AMS

Description:
Research task is to follow up on why some compliance documents are in AMS

Louise is investigating

We got the okay to remove these. I will ensure the Systems team has done so before closing this issue :)

I just checked and they are no longer showing up. Closing this as completed :)


hotkeys: Support non latin keyboard layouts.

This fix makes certain assumptions and has limitations. We aren't able to detect whether capslock is enabled or disabled, so we always assume it is disabled and detect 'r' vs 'R' using the e.shiftKey modifier.
This behavior is miles better than hotkeys not working at all, but can still be improved upon by some clever logic down the lane.
Fixes #19605.

Fixes:

Screenshots and screen captures:

Self-review checklist

[ ] Self-reviewed the changes for clarity and maintainability
(variable names, code reuse, readability, etc.).

Communicate decisions, questions, and potential concerns.

[x] Explains differences from previous plans (e.g., issue description).
[ ] Highlights technical choices and bugs encountered.
[x] Calls out remaining decisions and concerns.
[x] Automated tests verify logic where appropriate.

Individual commits are ready for review (see commit discipline).

[x] Each commit is a coherent idea.
[x] Commit message(s) explain reasoning and motivation for changes.

Completed manual review and testing of the following:

[x] Visual appearance of the changes.
[ ] Responsiveness and internationalization.
[ ] Strings and tooltips.
[x] End-to-end functionality of buttons, interactions and flows.
[ ] Corner cases, error conditions, and easily imagined bugs.

Works for me in manual testing with Cyrillic! @timabbott do you want to review this directly?

Test-deploying this on chat.zulip.org.

I see my oversight was in the definition of "ASCII letter/punctuation", and that should fix this issue.
But with this condition replacing the <256 test, isn't this similar to the algorithm defined?
I'm pasting the relevant bit here for ease (with some bits removed):

First, look at event.key, which identifies the character that key would type in a text input.

If this is an ASCII letter or ASCII punctuation, then use that.
Also if this is a "named key attribute value", like "Escape" or "End", then use that.

Otherwise, use event.code, i.e. the identity of the physical key.
This will look like "KeyN" for the key that a QWERTY user would use to type the letter "n". So we'll want to treat an event.code of "KeyN" (with no modifier keys) the same way as an event.key of "n", and so on.

Here's the code with some implementation details removed for ease:
function get_key_from_event(e) {
   const {key, code, shiftKey} = e;

   // Return ASCII chars and punctuation
   if (key.codePointAt(0) < 256) { //TODO correct this check.
       return key;
   }

  // Handle KeyA, KeyB type codes as if it was QWERTY.
   if (code.startsWith("Key") && code.length === 4) {
       let inferred_key = code.charAt(3);
       if (!shiftKey) {
           inferred_key = inferred_key.toLowerCase();
       }
       return inferred_key;
   }

   // Handle the punctuations as if it was QWERTY.
   if (shiftKey) {
       if (shifted_codes_to_keys[code]) {
           return shifted_codes_to_keys[code];
       }
   } else {
       if (unshifted_codes_to_keys[code]) {
           return unshifted_codes_to_keys[code];
       }
   }

   // If our logic above didn't capture it, let's just bail and return the original.
   return key;
}

This PR hasn't yet tackled the keydown shortcuts yet, so Escape keys etc aren't covered but they would also add very logically to this anyway. I'm confused about the claim that this isn't the algorithm you defined.

I see my oversight was in the definition of "ASCII letter/punctuation", and that should be fixed.
But with this condition replacing the <256 test, isn't this similar to the algorithm defined?

Yes, that will bring it a lot closer.

This PR hasn't yet tackled the keydown shortcuts yet, so Escape keys etc aren't covered

Yes. As long as that's true, the PR is only fixing part of #19605 at best. It's described as fixing the whole issue.
I think those aren't fundamentally any harder, so it'd be best to include them in the same PR. If you want to do them as a followup, though, I'd be OK with that. In that case this PR should be edited so that it doesn't close the issue.

Is there a way to move this one forward?
@aero31aero , is there a chance you get back to this?


feat(auth): httpsig request validation

Changes proposed in this pull request

Adds httpsig validation to requests where the client must present a public key.

Context

Closes #274.
Bumped jest to 28 to fix: https://github.com/facebook/jest/issues/10221#issuecomment-1090157337, which was affecting one of the tests using fake-timers.
https://github.com/facebook/jest/releases/tag/v28.0.0

[jest-config] [BREAKING] Rename config option name to id (https://github.com/facebook/jest/pull/11981)

Checklist

[x] Related issues linked using fixes #number
[x] Tests added/updated
[ ] Documentation added
[x] Make sure that all checks pass

I just came across this TODO to use httpsig in the backends token introspection request to the AS.
https://github.com/interledger/rafiki/blob/main/packages/backend/src/open_payments/auth/service.ts#L47-L68
Should that be added in this PR or should we open an issue to do it separately?

I just came across this TODO to use httpsig in the backend's token introspection request to the AS. https://github.com/interledger/rafiki/blob/main/packages/backend/src/open_payments/auth/service.ts#L47-L68 Should that be added in this PR or should we open an issue to do it separately?

https://github.com/interledger/rafiki/pull/442 adds auth as a dependency of backend which could be useful for allowing to backend to use httpsig in requests.


chore: update crate dependencies

closes #501

are we not able to remove lazy_static dependency?

While removing rusqlite_migration I also deleted the only use of lazy_static so that dependency is no longer needed.


1.2.x fails to build with error: expected a type

Bug
After updating to 1.2.0 from 1.1.1, the module fails to build in Xcode with the following error:
RNCPushNotificationIOS.h:22:41: error: expected a type  + (void)didReceiveNotificationResponse:(UNNotificationResponse *)response API_AVAILABLE(ios(10.0));

Environment info
react-native info output:
info
  React Native Environment Info:
    System:
      OS: macOS 10.15.3
      CPU: (12) x64 Intel(R) Core(TM) i7-9750H CPU @ 2.60GHz
      Memory: 1.29 GB / 16.00 GB
      Shell: 3.2.57 - /bin/bash
    Binaries:
      Node: 12.4.0 - ~/.nvm/versions/node/v12.4.0/bin/node
      Yarn: 1.5.1 - /usr/local/bin/yarn
      npm: 6.9.0 - ~/.nvm/versions/node/v12.4.0/bin/npm
    SDKs:
      iOS SDK:
        Platforms: iOS 12.4, macOS 10.14, tvOS 12.4, watchOS 5.3
    IDEs:
      Android Studio: 3.6 AI-192.7<IP_ADDRESS>41897
      Xcode: 10.3/10G8 - /usr/bin/xcodebuild
    npmPackages:
      react: 16.13.1 => 16.13.1
      react-native: 0.59.10 => 0.59.10

Library version: 1.2.0

Hi @grit96
#import <UserNotifications/UserNotifications.h>
import above one in RNCPushNotificationIOS.h file then it will works.
If you want you can take fork and change the file and then install library through your git url

It's not working. Could someone help with this? Have the same error. It happened after updating to 1.2.0 from 1.1.1.

after a clean install of my project it stop working because it update to 1.2.0 with this error.

Thank you @sairam-405 it's working fine after importing #import <UserNotifications/UserNotifications.h> ✌

Are you planning to do some fix? I have this issue on appCentre build

It seems it is working after updating XCode from 10 to 11.5 on AppCentre

I've landed the fix and released it as 1.2.2 :tada: thanks @grit96 !


Bump<EMAIL_ADDRESS>and<EMAIL_ADDRESS>

Current coverage is 61.52%

Merging #298 into next will not affect coverage as of 5b28b2c

@@             next    #298   diff @@
=====================================
  Files          40      40
  Stmts         525     525
  Branches        0       0
  Methods
=====================================
  Hit           323     323
  Partial         0       0
  Missed        202     202

Review entire Coverage Diff as of 5b28b2c

Powered by Codecov. Updated on successful CI builds.

Can you rebase + add a note in the CHANGELOG under a ##Boilerplate  ?

I saw you rebased this branch. Do I need to do anything now ?

waiting for CI

:+1:


No clear error message, when writing comment in config definition line

import sacred
ex = sacred.Experiment('test')

@ex.config
def config():   # some comment
    a = 1

@ex.automain
def main(a):
    print(a + 1)

The above code example create an AssertionError in the following sacred file:

sacred/config/config_scope.py", line 102, in get_function_body

without any further information.
Is this desired behavior?

Definitely not intendend. Thanks for reporting.


service Fabric 7.1

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

Contribution checklist:

[ ] I have reviewed the documentation for the workflow.
[ ] Validation tools were run on swagger spec(s) and have all been fixed in this PR.
[ ] The OpenAPI Hub was used for checking validation status and next steps.

ARM API Review Checklist

[ ] Service team MUST add the "WaitForARMFeedback" label if the management plane API changes fall into one of the below categories.
adding/removing APIs.
adding/removing properties.
adding/removing API-version.
adding a new service in Azure.

Failure to comply may result in delays for manifest application. Note this does not apply to data plane APIs.

[ ] If you are blocked on ARM review and want to get the PR merged urgently, please get the ARM oncall for reviews (RP Manifest Approvers team under Azure Resource Manager service) from IcM and reach out to them.
Please follow the link to find more details on API review process.

/azp run automation - sdk

Can one of the admins verify this patch?

@lmazuel am I missing anything else? I checked the open api hub and it says its at review.

@jeffj6123 can you update line 28, the default API tag to 7.1 so automation can create the corresponding language PR?
Thanks!

/azp run automation - sdk

@jeffj6123 I can't write in the PR review, the file is too big. A few comments:

"entrypoint" has been renamed "entryPoint" in ApplicationMetricDescription. I want to confirm you actually change the JSON format and it's not case-sensitive, otherwise you'll break SDKs (they are mostly case-sensitive, only C# is not). Also, if you want to make it less breaking for customers you can add "x-ms-client-name: entrypoint", that will keep the old SDK name while updating the JSON wire name

Otherwise, LGTM, let me know your thought on entrypoint

@jeffj6123 I can't write in the PR review, the file is too big. A few comments:

"entrypoint" has been renamed "entryPoint" in ApplicationMetricDescription. I want to confirm you actually change the JSON format, otherwise you'll break SDKs (they are mostly case-sensitive, only C# is not). Also, if you want to make it less breaking for customers you can add "x-ms-client-name: entrypoint", that will keep the old SDK name while updating the JSON wire name

Otherwise, LGTM, let me know your thought on entrypoint

Hey,
I can confirm this is actually a correction. It appears that previously this was the wrong casing name for that property.


SVG module dependency is broken

The PR #18, Make svg2mod installable via pip has broken manual installation of svg2mod. Although package managers are convenient, it should still be possible to install and run this script without one.
Steps to reproduce (Python 2.7 environment)

Clone repo
Run python setup.py install
In the svg2mod subdir run python svg2mod.py -i ../examples/dt-logo.svg

I expected the script to work and output a kicad_mod file but instead saw this error:
$ python svg2mod.py -i ../examples/dt-logo.svg
Traceback (most recent call last):
  File "svg2mod.py", line 10, in <module>
    import svg2mod.svg as svg
  File "svg2mod/svg2mod/svg2mod.py", line 10, in <module>
    import svg2mod.svg as svg
ImportError: No module named svg

I have the same issue "import svg2mod.svg as svg" Error.. even though I operate on macOS..


Update quickstart-load-balancer-standard-public-portal.md

Fixed typo.

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


possible bug with emitter.end

I have an AJAX helper function as follows,
function fetch (url, payload) {
	return kefir.stream(function (emitter) {

		var jqXHR = $.ajax({
			url: url,
			data: payload || {}
		});
		jqXHR.done(function (data, textStatus, jqXHR) {
			emitter.emit(data);
			emitter.end();	//- this invocation triggers the error
		});
		jqXHR.fail(function (jqXHR, textStatus, errorThrown) {
			emitter.error(textStatus);
			emitter.end();
		});

		return function () {
			jqXHR.abort();
			emitter.end();
		};

	});
}

When this function is used, I get the following message on the console,
Uncaught TypeError: Cannot read property 'cleanup' of null
_clear @ kefir-v2.7.1.js?ver=20150709:613
_clear @ kefir-v2.7.1.js?ver=20150709:1511
_emitEnd @ kefir-v2.7.1.js?ver=20150709:644
end @ kefir-v2.7.1.js?ver=20150709:1429
(anonymous function) @ search_products_async.js?ver=20150709:17

This occurs in v2.7.1 but not in v2.7.0. When the emitter.end() statement is commented out, everything works just fine.
The app functionality doesn't break; only this message pops up.

Thanks! Also found another bug when was fixing this, although the fix was the same :smile:
Can you check if it works for you (it's in master)?

yes, it's working fine now. thanks!

:+1: I've released 2.7.2 with this fix.


Add CORS middleware to FastAPI application

This update introduces the CORSMiddleware to the FastAPI application, allowing cross-origin requests from any source. The middleware configuration permits all methods and headers, enhancing the application's flexibility for client interactions.

ok

Not a bad idea to add this functionality, but we should be encouraging the use of a reverse proxy.


Supporting custom errors

Loosely related to #238
Twirp is opinionated with respect to the error generation and serialization, with it's own:

Error interface
Error codes
Error code to status code mapping and,
Error serialization interface.

... and this is fairly sufficient for internal services. However, for a Twirp service exposed externally to REST consumers, I'd like to be able to customise my errors. For example,
An error message whose corresponding JSON encoding will be exposed to clients:
message Error {
    // Error type, for classification
    string type = 1;

    // public error code
    string code = 2;

    // description of the error, in text
    string description = 3;

    // Request field that caused the error
    string field = 4;

    // Reserved for future cases
    reserved 5 to 10;

    // Other details/metadata
    repeated google.protobuf.Any details = 11;
}

Would Twirp consider support for custom error type definitions and serialization extensions?

Twirp errors do not seem like the right fit for the use case you describe of presenting a message with a specific shape to end users. Even in the case of internal service-to-service communication, adding an additional field that contains error data to an RPC's response message may be practical than including such data in an error (depending on the use case).
Unfortunately, I don't think Twirp will support custom error definitions (beyond what is already available) or mechanisms to customize the serialization of errors.
It seems more practical to implement a layer in front of your Twirp service that prepares Twirp responses for presentation to end users than it would be to modify Twirp to support that use case. Have you considered that approach? Some folks at Twitch have implemented such solutions and may be able to respond to specific concerns you may have.

Even in the case of internal service-to-service communication, adding an additional field that contains error data to an RPC's response message may be practical than including such data in an error (depending on the use case).

Agree with this, and I would have taken this route if I was able to control the HTTP status code on the response. Inspecting the response payload for an "error" message at the client end, when the status_code=200, would be bad practice.

It seems more practical to implement a layer in front of your Twirp service that prepares Twirp responses for presentation to end users than it would be to modify Twirp to support that use case. Have you considered that approach?

Yes. For some quick context, we (@razorpay) have been using Twirp for internal services pretty well. However, widespread internal adoption is not possible since we have a public REST API. Reg other options:

Transform before Twirp, within a service: either fork Twirp, or with a custom ResponseWriter -- both have maintainability issues.
Transform at an API gateway (@kong in our case) - requires us to rely on Twirp error's limited details. For example, with Meta being map[string]string, trying to send out a native float field would require hacky inspection.

These are do-able of course, but it comes down to us patching and adding layers of indirection to workaround Twirp limits, going against why we chose Twirp in the first place: the out-of-the-box simplicity over gRPC. IMO, extensibility does not have to be a trade-off over simplicity -- would have been great if we could have extended on Twirp when needed.
Would be interesting to know how others workaround this and #238.


README: update with information about RB3G2 and compose-apps

Here is the first cut at a README for this branch. I've documented our compose-apps, along with how to deploy them to a device.

Should we add the content from https://github.com/foundriesio/meta-partner/blob/qualcomm/recipes-firmware/firmware/renesas-upd720201/README.txt here as well?