tabula.jar not found error

I am trying to use the tabula installation out of the box. So, when I start the application. I see the following command line screen with the error

and then the the <IP_ADDRESS>:8080 page shows the following:

Note: This happens with both 1.1.1 and 1.1.0c versions. Also, I have updated my java 8.0.1510.12
Any help would be great. Thanks!

anyone?

@g0rd: The "not found" error is a red herring; Tabula is almost certainly functioning correctly. (I see that same error sometimes and even when I see it, Tabula still works.) The problem is that you have another piece of software -- EDB Postgres, evidently -- that's running on the same port. See if you can exit that program and then start Tabula again, and then Tabula should work.

Thanks @jeremybmerrill
I stopped the Postgres on my machine and restarted it and I still see the screen on localhost:8080

So, after some failed attempts at trying to compile and build through the source code I came back to the out-of-box solution and changed the port and I am seeing the issue at #730


'Synchronous operations are disallowed' on .NET Core 3

Hi, thx or gread tool.
After migrate to ASP.NET 3 i go this error:
System.InvalidOperationException: Synchronous operations are disallowed. Call WriteAsync or setAllowSynchronousIO to true instead.

Temporary fix for this is set this flag:
                    .UseKestrel(
                        options =>
                        {
                            options.AllowSynchronousIO = true;
                        })

Thanks for the report, haven't upgraded any projects to 3.0 so I hadn't noticed this. I've published version 1.1.0 which fixes this.


ISSUE<259> CHANGED NAMING OF API PATH VARIABLE FROM QUERY TO PATH

Pull Request
What does this PR do?
Fixes #<259>
(https://github.com/meilisearch/meilisearch-swift/issues/259)
This commit will make a basic change to the variable name from query to path where it was called in the Documents Swift file.
I also added a dependency package (.package(url: "https://github.com/meilisearch/meilisearch-swift.git", from: "0.12.0") to the Package file at the top of the file in Xcode when trying to resolve some errors when trying to run meilisearch. If this was not necessary please tell me.
If there are any problems please contact me on here. I am a new contributor so I apologise if there are any issues with this PR.
Thank you for your time.
PR checklist
Please check if your PR fulfills the following requirements:

[x] Does this PR fix an existing issue?
[x] Have you read the contributing guidelines?
[x] Have you made sure that the title is accurate and descriptive of the changes?

Thank you so much for contributing to Meilisearch!

Could you build and run the test locally to ensure your changes are working?

Yes I'll do a run of the tests while making changes before another commit. Once again sorry for the trouble!

Could you build and run the test locally to ensure your changes are working?

Hey bidoubiwa, I've made the changes from let query into let path in the Documents file, but I just have a question regarding the Integration Tests. If I run them via Xcode, they fail instantly with this error
2022-02-17 15:55:06.350508+0000 xctest[3134:145966] Task <58D62956-EE18-42C6-B662-EF22240984F1>.<1> HTTP load failed
The regular Unit Tests work absolutely no problem but the integration tests all start failing. I presume it's a connection error but I'm not quite sure what the reasoning may be. Is there something I'm missing? Also apologies it's taken this long and thanks for your time.

Hey @AE542 no problem! Sorry I was on holiday.
Are you running a Meilisearch instance while running the integrations tests ?

Hey @AE542 I would really like to merge your PR! Are you still working on it? If you have no time could you fix the conflicts so that I can merge it in another branch and finish your PR?
You'll still have the credit :)

I'm closing this issue as it is stale! If you'd like to work on it please tell me in which case we will re-open


adding power spectrum utils functions

Adds code to compute power spectrum from a map and generate the ps_map useful for decoder renormalization.
Code renormalizing map1 with map2's power spectrum
from learn2map.utils import measure_power_spectrum, make_ps_map

# N = map1.shape[0]
ps_map1 = make_ps_map(measure_power_spectrum(map1), N)
ps_map2 = make_ps_map(measure_power_spectrum(map2), N)

cancel_ps_map = jnp.fft.ifft2(jnp.fft.fft2(map1) / jnp.sqrt(ps_map1)).real
apply_ps_map = jnp.fft.ifft2(jnp.fft.fft2(map1) / jnp.sqrt(ps_map1) * jnp.sqrt(ps_map2)).real

There is an issue while jiting with bincount from the doc:

length (int | None) – the length of the output counts array. Must be specified statically for bincount to be used with jax.jit() and other JAX transformations.

We should to something like this (similarly to this)
jit_bincount = jax.jit(jnp.bincount, static_argnames=['length'])

@jax.jit
def radial_profile(power_spectrum_2d):
    """
    Compute the radial profile of 2d image
    :param data: 2d image
    :return: radial profile
    """
    center = power_spectrum_2d.shape[0]/2
    v, u = jnp.indices((power_spectrum_2d.shape))
    k = jnp.sqrt((u - center)**2 + (v - center)**2)
    k = k.astype('int32')

    length = max(0, k.size and jnp.array(k.max(), int) + 1)
    tbin = jit_bincount(k.ravel(), power_spectrum_2d.ravel(), length=length)
    nr = jit_bincount(k.ravel(), length=length)
    radialprofile = tbin / nr
    return radialprofile

but now I have issues because I am using bool

Forgot to test jit 🤦♂Should be working now and do exactly the same operations as before!

ok it works :)


Client Challenge + contract freezing

Commit a82b91149fe17023f17a03e52c49483e6b6fcc1e has the wrong gitmoji, should be :sparkles: Note that we don't really use gitmoji in Erdstall so you can also just stop using it ^^ I use the more common style pkg: Do stuff here.

Commit a82b911 has the wrong gitmoji, should be  Note that we don't really use gitmoji in Erdstall so you can also just stop using it ^^ I use the more common style pkg: Do stuff here.

Changed it to :sparkles: now.


--undo should accept a value of zero

Shouldn't it be possible for the --undo flag to accept a value of zero so that undo functionality is disabled?

It's possible, but is it worth bothering with?
In theory a game could behave differently if undo is disabled, but it hasn't come up.

I came up with this while testing a solution to a problem with the Inform6 Standard Library offering UNDO after death when the interpreter might not support that.  Frotz has always reported that it doesn't support UNDO if zero undo slots are specified, so I thought perhaps it would be useful here too.  I'll submit a pull request in a couple days as the change for Glulxe is quite simple.

Done.


Do not pluralize the JSDoc model names

Right now, when we generate JSDocs for models e.g.
/**
     * The data used to create many Activateds.
...

As you can see, it does not always make sense to pluralize.
It would be preferable to keep the model name unaltered:
/**
     * The data used to create many `Activated`.
...

I think it's some tech-debt topic to cleanup.
Pluralizing does not always work, and can produce really weird results, it seems we still have some pluralization that can be easily removed.

See search for plural https://sourcegraph.com/search?q=context:global+repo:^github\.com/prisma/prisma%24+plural&patternType=literal


Update to Keycloak 25

Update Keycloak version to 25.0.0
Update java version to 21, now the Keycloak standard per https://www.keycloak.org/2024/06/keycloak-2500-released.html#_java_21_support and https://www.keycloak.org/2024/06/keycloak-2500-released.html#_java_17_support_is_deprecated
Change dependency from keycloak-model-legacy to keycloak-model-storage per https://github.com/keycloak/keycloak/issues/26657

Hi! Thanks for the contribution!
For the changes to work, you will also need to update:

.env (KEYCLOAK_IMAGE, MAVEN_IMAGE and OPENJDK_IMAGE)
maven.yml (the Set up JDK 17 step)
release.yml (the Set Up Java step)
README.md (the Compatibility history table - the plugin version should be SNAPSHOT)

Here's a link to the "Keycloak version upgrade quickstart guide", for future reference:
https://github.com/daniel-frak/keycloak-user-migration/blob/master/CONTRIBUTING.md#quick-guide-to-upgrading-keycloak-compatibility

Thanks!
I just noticed that the end-to-end tests are failing, however :/
It seems that the "should migrate user" test cannot find the .pf-c-alert__title element.
Do you fell like you can tackle that as well, or would you like me to help?

Looks like a theme change. But sorry to say I have no frontend competency at all. Please help if you have time. Otherwise I ca ask one of my colleagues later this week.

Ok, I'll try to carve out some time near the end of this week to take a look.

Ok, this is a bit weird. I cloned your repo locally and ran the E2E tests, and they pass.
Looking at the code, the issue is at this place (docker/e2e/cypress/e2e/migrating_users.cy.js:69):
        cy.get('#kc-forgot-pw-switch').then(($checkbox) => {
            if (!$checkbox.prop('checked')) {
                cy.wrap($checkbox).check({ force: true });
                cy.get('.pf-c-alert__title').should('contain', "Forgot password changed successfully");
            }
        });

For whatever reason, when checking the "Forgot password" checkbox in Keycloak's "Realm settings", the confirmation popup is not being detected by Cypress, but seemingly only on CI.
Unfortunately I'm also not too adept in frontend technologies, so we'll have to play this one by ear, a bit.

Could you try modifying the test so that it intercepts a GET request, like below? Perhaps that will coax it to behave:

        cy.get('#kc-forgot-pw-switch').then(($checkbox) => {
            if (!$checkbox.prop('checked')) {
                cy.intercept('GET', '/admin/realms/master') // Add this
                    .as("reload");
                cy.wrap($checkbox).check({ force: true });
                cy.wait("@reload"); // And this
                cy.get('.pf-c-alert__title').should('contain', "Forgot password changed successfully");
            }
        });

Could you run the tests locally, as described in CONTRIBUTING.md? That way we can make sure that this is strictly a CI issue (and therefore most likely a race condition or something similar).

@daniel-frak regarding running the tests locally, I get the same error:
DevTools listening on ws://<IP_ADDRESS>:41043/devtools/browser/4c62d347-9a73-4a35-9aa3-995824169efa

====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:        13.11.0                                                                        │
  │ Browser:        Electron 118 (headless)                                                        │
  │ Node Version:   v20.11.0 (/home/garth/.nvm/versions/node/v20.11.0/bin/node)                    │
  │ Specs:          1 found (migrating_users.cy.js)                                                │
  │ Searched:       cypress/e2e/**/*.cy.{js,jsx,ts,tsx}                                            │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

────────────────────────────────────────────────────────────────────────────────────────────────────

  Running:  migrating_users.cy.js                                                           (1 of 1)

  user migration plugin
    1) "before all" hook for "should migrate user"

  0 passing (24s)
  1 failing

  1) user migration plugin
       "before all" hook for "should migrate user":
     AssertionError: Timed out retrying after 20000ms: Expected to find element: `.pf-c-alert__title`, but never found it.

Because this error occurred during a `before all` hook we are skipping the remaining tests in the current suite: `user migration plugin`

Although you have test retries enabled, we do not retry tests when `before all` or `after all` hooks fail
      at Context.eval (webpack://e2e-tests/./cypress/e2e/migrating_users.cy.js:72:45)

  (Results)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Tests:        4                                                                                │
  │ Passing:      0                                                                                │
  │ Failing:      1                                                                                │
  │ Pending:      0                                                                                │
  │ Skipped:      3                                                                                │
  │ Screenshots:  1                                                                                │
  │ Video:        false                                                                            │
  │ Duration:     23 seconds                                                                       │
  │ Spec Ran:     migrating_users.cy.js                                                            │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

  (Screenshots)

  -  /home/garth/projects/saascrud/keycloak-user-migration/docker/e2e/cypress/screens     (1280x720)
     hots/migrating_users.cy.js/user migration plugin -- should migrate user -- befor
     e all hook (failed).png

====================================================================================================

  (Run Finished)

       Spec                                              Tests  Passing  Failing  Pending  Skipped
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ✖  migrating_users.cy.js                    00:23        4        -        1        -        3 │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘
    ✖  1 of 1 failed (100%)                     00:23        4        -        1        -        3

Inspecting the HTML, it looks like the style has changed (Keycloak team upgraded to Patternfly 5) from pf-c-alert__title pf-v5-c-alert__title. When I replace all occurrences of that, it passes that error, but then fails with another error:
DevTools listening on ws://<IP_ADDRESS>:32863/devtools/browser/bb9e67a5-2fca-4309-a779-927dc880b362

====================================================================================================

  (Run Starting)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Cypress:        13.11.0                                                                        │
  │ Browser:        Electron 118 (headless)                                                        │
  │ Node Version:   v20.11.0 (/home/garth/.nvm/versions/node/v20.11.0/bin/node)                    │
  │ Specs:          1 found (migrating_users.cy.js)                                                │
  │ Searched:       cypress/e2e/**/*.cy.{js,jsx,ts,tsx}                                            │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

────────────────────────────────────────────────────────────────────────────────────────────────────

  Running:  migrating_users.cy.js                                                           (1 of 1)

  user migration plugin
    1) "before all" hook for "should migrate user"

  0 passing (7s)
  1 failing

  1) user migration plugin
       "before all" hook for "should migrate user":
     CypressError: Timed out retrying after 5000ms: `cy.wait()` timed out waiting `5000ms` for the 1st request to the route: `realm`. No request ever occurred.

https://on.cypress.io/wait

Because this error occurred during a `before all` hook we are skipping the remaining tests in the current suite: `user migration plugin`

Although you have test retries enabled, we do not retry tests when `before all` or `after all` hooks fail
      at cypressErr (http://localhost:8024/__cypress/runner/cypress_runner.js:75613:18)
      at Object.errByPath (http://localhost:8024/__cypress/runner/cypress_runner.js:75668:10)
      at checkForXhr (http://localhost:8024/__cypress/runner/cypress_runner.js:135230:84)
      at <unknown> (http://localhost:8024/__cypress/runner/cypress_runner.js:135256:28)
      at tryCatcher (http://localhost:8024/__cypress/runner/cypress_runner.js:1807:23)
      at Promise.attempt.Promise.try (http://localhost:8024/__cypress/runner/cypress_runner.js:4315:29)
      at whenStable (http://localhost:8024/__cypress/runner/cypress_runner.js:143678:68)
      at <unknown> (http://localhost:8024/__cypress/runner/cypress_runner.js:143619:14)
      at tryCatcher (http://localhost:8024/__cypress/runner/cypress_runner.js:1807:23)
      at Promise._settlePromiseFromHandler (http://localhost:8024/__cypress/runner/cypress_runner.js:1519:31)
      at Promise._settlePromise (http://localhost:8024/__cypress/runner/cypress_runner.js:1576:18)
      at Promise._settlePromise0 (http://localhost:8024/__cypress/runner/cypress_runner.js:1621:10)
      at Promise._settlePromises (http://localhost:8024/__cypress/runner/cypress_runner.js:1701:18)
      at Promise._fulfill (http://localhost:8024/__cypress/runner/cypress_runner.js:1645:18)
      at <unknown> (http://localhost:8024/__cypress/runner/cypress_runner.js:5450:46)
  From Your Spec Code:
      at visitMigrationConfigPage (webpack://e2e-tests/./cypress/e2e/migrating_users.cy.js:96:11)
      at configureMigrationPlugin (webpack://e2e-tests/./cypress/e2e/migrating_users.cy.js:78:8)
      at Context.eval (webpack://e2e-tests/./cypress/e2e/migrating_users.cy.js:42:8)

  (Results)

  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ Tests:        4                                                                                │
  │ Passing:      0                                                                                │
  │ Failing:      1                                                                                │
  │ Pending:      0                                                                                │
  │ Skipped:      3                                                                                │
  │ Screenshots:  1                                                                                │
  │ Video:        false                                                                            │
  │ Duration:     7 seconds                                                                        │
  │ Spec Ran:     migrating_users.cy.js                                                            │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘

  (Screenshots)

  -  /home/garth/projects/saascrud/keycloak-user-migration/docker/e2e/cypress/screens     (1280x720)
     hots/migrating_users.cy.js/user migration plugin -- should migrate user -- befor
     e all hook (failed).png

====================================================================================================

  (Run Finished)

       Spec                                              Tests  Passing  Failing  Pending  Skipped
  ┌────────────────────────────────────────────────────────────────────────────────────────────────┐
  │ ✖  migrating_users.cy.js                    00:07        4        -        1        -        3 │
  └────────────────────────────────────────────────────────────────────────────────────────────────┘
    ✖  1 of 1 failed (100%)                     00:07        4        -        1        -        3

Weirdly, I'm getting the same error (which I probably should have mentioned) when running your code, unless I increase the wait time of cy.get('.pf-c-alert__title') or change the code like I did above.
What happens if you change the code like I did (adding the @saveRealmSettings check)? Does it also fail in the same way?

@pnzrr Can you look at this?

Upon a closer look, it seems that the E2E tests have become generally flaky (even on the master branch).
I've improved them somewhat on the main branch. Could you pull from master and see if the CI passes this time?
In the meantime, I'll do some more investigating regarding the tests...

Ah, shucks :/
I'll try to find some time to confirm if the tests are just flaky here. If that's the case, I'll merge the PR and try to fix the test flakiness later...

@xgp Ok, so I took a look at your branch and it seems that the change you made, where you replaced pf-c-alert__title with .pf-v5-c-alert__title is causing the tests to fail. Reverting that change makes the tests pass, at least locally.

I still can't get tests to pass locally, even when reverting that change. I'm somewhat out of my element on these tests. As much as I've tried, I'm really unable to grok what's going on.

Yeah, frontend's a bit of a mystery for me as well XD
But it does pass on my machine after the revert, so let's get it to that state and I'll merge it in, to not waste more of your time on the E2E test side.
Then I'll try to find some free time to stabilize the tests on the main branch.


OnAnchorDisable() has now been renamed "OnDisable()" so it will be called when the class is Disabled.

Summary
This renames the previous "OnAnchorDisabled" to OnDissabled so that it is called automatically by the unity event when the object is disabled.
Contributor Tasks
These tasks are for the merge request creator to tick off when creating a merge request.

[x] Pair review with a member of the QA team.
[x] Add any release testing considerations to the MR for the next release.
[x] Check any relevant CHANGELOG files have been updated.
[x] Ensure documentation requirements are met e.g., public API is commented.
[x] Consider any licensing/other legal implications for this MR e.g. notices required by any new libraries.
[x] Add any relevant labels such as breaking to this MR.
[ ] If this MR closes a Jira issue, make sure the fix version on the JIRA issue is set to the correct one.

Reviewer Tasks
Add any instructions or tasks for the reviewer such as specific test considerations before this can be merged.
Use emojis in review threads to communicate intent and help contributors.

[x] Code reviewed.
[x] Non-code assets e.g. Unity assets/scenes reviewed.
[x] Documentation has been reviewed. Includes checking documentation requirements are met and not missing e.g., public API is commented.
[x] Checked and agree with release testing considerations added to MR for the next release.

Closes JIRA Issue
If this MR closes any JIRA issues list them below in the form Closes PROJECT-#

@MattGrayUL looks good. Did you check against any existing scenes where this is used as well?

@Greg-UL I did, the hand menu anchors worked as usual, the other anchor scene doesn't use disabling anchors so isn't impacted by this change


presence:Made it so that stats of even invisible users are been recorded

This PR makes it so that the statistics of users who set their status to invisible are included in the analytics page of the organization.
Also updated the help page to notify the users that even when they set their status to invisible their stats will be recorded in the organization analytics.

Fixes: #32605

Screenshots and screen captures:

Self-review checklist

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

Communicate decisions, questions, and potential concerns.

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

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

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

Completed manual review and testing of the following:

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

@alya I did not make any changes in the documentation my test failed for some reason is there any way to fix that?

Thanks for the fix!
You should also include a screenshot of the help center changes.

I don't think we need to document this on the usage statistics page. It does need to be noted on https://zulip.com/help/status-and-availability#invisible-mode.

The commit message is missing a period.

@alya made the changes and updated the image in the pr


PartitionKey.None.ToString() raises NRE

PartitionKey.None.ToString() raises a NullReferenceException.

Closed by https://github.com/Azure/azure-cosmos-dotnet-v3/pull/3498


add Identity support for RSA PKCS#8 nocrypt

Hi @str4d,
I realize that this feature is unlikely to see much use in practice, but I picked an old issue that seemed simple enough for a very new rustacean to be able to tackle (first real attempt at Rust).

fully parse unencrypted PKCS#8 RSA private key
parse encrypted PKCS#8 enough to recognize it as an unsupported key format
add test coverage for key format support

PEM (PKCS#1) unencrypted RSA (supported)
PEM (PKCS#1) encrypted RSA (never support)
PKCS#8 unencrypted RSA (supported)
PKCS#8 encrypted (not supported, yet?)

fixes #14

You could use the following crates for this, rather than implementing these standards yourself:

pkcs1
pkcs5
pkcs8

Hi @tarcieri,
Thanks for the direction to prior work. I carried on in the existing style of the codebase with the use of nom, but the complexity of following in that style is ramping up.
Would a reasonable starting point be to pause on PKCS#8 and instead go back and replace what is already there (linked below) with pkcs1?

https://github.com/str4d/rage/blob/729d9dada194a4d9c9b710d168d54beb31e5d761/age/src/ssh/identity.rs#L300-L328
https://github.com/str4d/rage/blob/729d9dada194a4d9c9b710d168d54beb31e5d761/age/src/ssh.rs#L155-L270

That's what I'd personally suggest.
PKCS#5 support is fully integrated into the pkcs8 crate, and there's blanket impl of pkcs8 support for anything that impls pkcs1::{FromRsaPrivateKey, FromRsaPublicKey, ToRsaPrivateKey, ToRsaPublicKey}. So if you impl the pkcs1 traits you get PKCS#8 and optionally PKCS#5 for free.

@tarcieri
While I have your attention,

https://github.com/str4d/rage/blob/729d9dada194a4d9c9b710d168d54beb31e5d761/age/src/ssh.rs#L260
https://github.com/str4d/rage/blob/729d9dada194a4d9c9b710d168d54beb31e5d761/age/src/ssh/identity.rs#L313

rage uses rsa::RsaPrivateKey and that implements the ToRsaPrivateKey trait (trait impl), so that simplifies the original code in rage that I linked to above down to a one-liner?

Yep, as of v0.5 the rsa crate impls the pkcs1 traits I just mentioned.

https://docs.rs/rsa/0.5.0/rsa/#pkcs1-rsa-key-encoding
https://docs.rs/rsa/0.5.0/rsa/#pkcs8-rsa-key-encoding

I appreciate the review and the pointers @tarcieri
I followed up in PR #261


Find in File: filter unmatched lines

When looking a large text files (AKA logs), it can be very helpful filter out the unmatched lines.  This allows you to view all the matched lines side by side.

In the above example only the two matches would be shown
There are extensions that allow something similar, but the number of clicks/keystrokes required is too high when needing to run quick, subsequent searches.
The ideal experience would be filtering as you type and without creating a "temporary" file.  When the Find in file dialog is closed or the "filter" button unchecked, the lines would return.

in terms of an implementation example, less has this feature with the &<regex> operator.


Entrega 1

Agrego el link al informe

Codecov Report

Merging #21 (2c5ab16) into Entrega-1 (071ad0e) will not change coverage.
The diff coverage is n/a.

@@             Coverage Diff              @@
##             Entrega-1      #21   +/-   ##
============================================
  Coverage        74.26%   74.26%
  Complexity          40       40
============================================
  Files               11       11
  Lines              171      171
  Branches            14       14
============================================
  Hits               127      127
  Misses              41       41
  Partials             3        3

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 071ad0e...2c5ab16. Read the comment docs.


Add [Kvaesitso]/[Android Launcher]

Service Name

Kvaesitso - Kvaesitso is a search focused, free and open source launcher for Android.
License: GPL-3.0 license
Why do you think this helps users privacy?: A great launcher that is not only private but also allows a lot of customizability. its simple design makes it easy to use.
Under what section should this service be listed?: <Section (e.g. Cloud Storage)>

+1, amazing launcher


Problem: omni_httpd doesn't support SSL

This is because this was out of the scope of the initial prototype. For any real use, this is necessary.
Ideally, two options are needed:

User-supplied certificate (easy, follow what h2o does)
ACME (harder, but very good for adoption)

The closer we get to a user experience of Caddy, the better. Local certificate provisioning know-how can be found in smallstep/truststore

Moved this to the next milestone as this problem can be temporarily mitigated by putting a reverse proxy in front of omni_httpd (which is prudent while omni_httpd is not mature)

Superseded by #405


Fix handling of block2 reponses to multicast requests

This PR offers a potential fix for #236. As mentioned in the issue (and suggested by RFC 7959), the agent now switches to unicast requests if a response containing a block2 option is given to a multicast request.
This solves a problem that occured if two servers offering providing the same resource path are reachable over the same multicast address leading to confusion in the agent as the same block numbers are requested over and over again from the multicast address once a new reponse arrives.
This PR is still a bit WIP as the new _convertMulticastToUnicastRequest function could probably be refactored if there is a more elegant way to perform a deep copy of the initial request. I am also still working on corresponding unit tests. However, I performed a lot of manually testing/debugging which makes me confident that the solution should already work. In any case, feedback is highly appreciated :)

@mcollina @Apollon77 The PR still needs the test to be added but could you maybe already have a look on it? (I hope it is okay that I ping you this way.)

Works for me! Add the test! There is probably some maintainance to do on this repo as well, let me know if you'd like to be added here.

Works for me! Add the test!

Great :) Will do!

There is probably some maintainance to do on this repo as well, let me know if you'd like to be added here.

I'd be very glad!

I added now a new test case and actually was able to find (and fix) a small bug. I think this PR should now be ready to be merged :)

Pull Request Test Coverage Report for Build 651174001

8 of 10 (80.0%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-0.1%) to 90.965%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

lib/agent.js
8
10
80.0%

Totals

Change from base Build 649957306:
-0.1%

Covered Lines:
933

Relevant Lines:
992

💛  - Coveralls

I think this is good to go!

Great! :) Do you want to hit merge button?


SMHE-590 Add validation and tests for Set activity calendar

Retest this please

Retest this please

Retest this please

Retest this please


[iOS][MSTeams][EventID] [Select action covers Submit action]

Platform
What platform is your issue or question related to? (Delete other platforms).

iOS

Author or host
Microsoft Teams iOS app
Version of SDK
Pod 1.0.3
Details
Hello, I'm a SDE from Cortana in Teams iOS team of Microsoft. We use adaptive cards for Cortana skills like join meeting

Currently we added a deep link in the flight, this link will bring user to meeting details page if user tapped whole card(except join button).

But we found after we added this deep link, it would covers the link that join button would respond, so tapping join button would user to meeting details page too, that's not we want, join button should bring user to pre-join page like

We have verify in Android and they do not have this issue, and after debug primarily, we found both card and join button respond meeting details event, so we believe that the event of join button has been covered.
Here is the payload:
https://microsoft-my.sharepoint.com/:u:/p/jili15/EbhWz8n4WHlIrCRph08yywgBCmn5S3udBfhLKAQTsGy5tg?e=l3XZUV

@jwoo-msft thoughts on this one? Are we still planning on investigating for 20.09?

@jwoo-msft does anybody Investigating this bug?

@GrayLeee
Hi, yes, I can repro. Let me get back to you shortly.

@jwoo-msft
Thanks for your help! If you have any question, ping me in Teams by<EMAIL_ADDRESS>I'm sorry for bothering you, but a feature of Cortana is blocked by this issue.

@GrayLeee / @jwoo-msft  moving this out to 20.11 given our tight timeline here.. @VikrantSingh01 FYI


fix(eslint-plugin): improve object property checks

fixes https://github.com/TanStack/query/issues/5069

Codecov Report
Patch coverage: 100.00% and no project coverage change

Comparison is base (8d23513) 91.88% compared to head (381ea96) 91.89%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
Additional details and impacted files
@@           Coverage Diff           @@
##             main    #5079   +/-   ##
=======================================
  Coverage   91.88%   91.89%
=======================================
  Files         111      111
  Lines        4179     4184    +5
  Branches     1082     1083    +1
=======================================
+ Hits         3840     3845    +5
  Misses        318      318
  Partials       21       21

Impacted Files
Coverage Δ

.../src/rules/exhaustive-deps/exhaustive-deps.rule.ts
100.00% <100.00%> (ø)

...ackages/eslint-plugin-query/src/utils/ast-utils.ts
96.12% <100.00%> (+0.12%)
:arrow_up:

Help us with your feedback. Take ten seconds to tell us how you rate us. Have a feature suggestion? Share it here.

:umbrella: View full report at Codecov.
:loudspeaker: Do you have feedback about the report comment? Let us know in this issue.


Install MCAD on OKD

OKD is an open distribution of Kubernetes. we need to make sure MCAD can be installed on OKD through operator.

I was not familiar with OKD but it doesn't look like I have anything easily at my disposal to run it on.  Best I can tell, it's an Open Source version of OpenShift, but requiring the same kind of cluster setup (multiple masters, multiple worker nodes, etc.) So it's nothing like kind, which is more of a quick and easy single-server kubernetes dev cluster.

I did try kind on my cluster, just to see what I could do.  It's possible with helm to install MCAD.  I was also able to install the codeflare operator on kind.  But the opendatahub is missing OpenShift specific items (ImageStream, BuildConfig, DeploymentConfig) and therefore wasn't able to start:
oc get pods
NAME                                                       READY   STATUS             RESTARTS         AGE
codeflare-operator-controller-manager-b7d7b5967-vkv5x      2/2     Running            0                6h59m
opendatahub-operator-controller-manager-865ddbfff7-wptsj   1/2     CrashLoopBackOff   89 (4m39s ago)   7h48m

Because the opendatahub didn't start, it's not able to process the kfdefs to apply instascale or ray.

I don't think there focus on installing MCAD on OK at this point. Closing this issue for now.


Suggestion

You should make something that if the player wants it so when the player walks in the portal it closes the portal they just walked through
(Please Consider)

I am going to check whether commandsOnTeleported can make it


Can layer number be added to Status?

What would you like to see added?
I did review the wiki and the sample config, but did not find this feature.

I exactly wanted to ask the very same question +1
Should be configurable in
https://github.com/nlef/moonraker-telegram-bot/wiki/Sample-config#status_message_content
Perfect would be
Layer  :  14 of 122
Thanks for a short feedback

also interested in sending the layer number in status message...

@PhilBaz
you could send custom message using gcode
take a look at wiki


closes brunch/brunch#938

closes gh-938

in some cases the result is: 'D:\wamp\www\prices\cache\market.html\market.html'

I have moved the function to https://github.com/paulmillr/quickly-copy-file


Feature request : Version / Migration

I'm having some issue on my application.
Every time the structure of the reducers changes, or the initial state must be updated (ex: When a new version of the app is released), the users that has saved some of his store in a storage may have some issue between states version.
It could be nice to have a system that can handle the versioning between saved state.
My proposition is to save the version (incremented manually when the storage need to be updated)
If the version doesn't match:

Another argument can handle the migration between versions
If no migrations provided, we skip the rehydration.

For the moment i do it on my side but i think it could be nice to have that kind of feature in redux-phoenix.
What do you think ?

Hi @ThibautMarechal,
The idea sounds really cool. Do you know some reliable libraries that can be used for that? I'd like to avoid writing the whole functionality if migrations as it seems more like a topic for another library.
Also, I'm wondering if it won't be possible for you to implement and use custom autoRehydrate function for migrations. Of course, you should have information about state's version somewhere in the redux state and compare it somehow.
const autoRehydrate = next => (reducer, initialState, enhancer) => {
  if (typeof initialState === 'function' && typeof enhancer === 'undefined') {
    enhancer = initialState;
    initialState = undefined;
  }
  function rehydrateReducer(state, action) {
    if (action.type === REHYDRATE) {
      const newState = action.payload.version !== state.version
        ? migrate(action.payload) // handle migrations
        : action.payload;

      return reducer(_.merge({}, state, newState), action);
    }
    return reducer(state, action);
  }
  return next(rehydrateReducer, initialState, enhancer);
};

Nevertheless, I'll try to implement it in a simple way in my free time.

We do not a way to have the information in the "autoRehydrate" Enhancer. I Think the migration should happend here :
export default function persistStore(store, {
  key = 'redux',
  whitelist = null,
  blacklist = null,
  storage = window.localStorage,
  expireDate = null,
  serialize = JSON.stringify,
  deserialize = JSON.parse,
  map = {},
  disabled = false,
  throttle = 0,
  migrations = {},
} = {}) {
  return Promise.resolve(storage.getItem(key)).then(persistedJson => {
  const migratedJson = migrate(persitedJSon, migrations);
  [...]
}

The migrations may look like this :
{
  0: {
    up: state => ...,
  },
  1: {
    down: state => ...,
    up: state => ...,
  },
  2: {
    down: state => ...,
  },
}

Handle migrations is pretty easy, i don't think the usage of an external package is needed except if we find the package matching the need.

@ThibautMarechal I opened a PR with the first draft of the migrations feature. Feel free to take a look and give some feedback, it will be really appreciated.
After updating CircleCI config to the version 2 I'll merge it to the next release.

Closing in favor of #5


SLider Initial value gets ignored - fix need in 2.x

Detailed description

Describe in detail the issue you're having.
Setting value="30" as an initial value gets ignored and shows the slider thumb at 0 instead.

This issue is related to #545 which is fixed in carbon angular 3.x. Could this be delivered in 2.x?

Is this a feature request (new component, new icon), a bug, or a general issue?
bug

Is this issue related to a specific component?
slider

What did you expect to happen? What happened instead? What would you like to see changed?

What browser are you working in?

What version of the Carbon Design System are you using?

What offering/product do you work on? Any pressing ship or release dates we should be aware of?

Steps to reproduce the issue

Step one
Step two
Step three
etc.

Additional information

Screenshots or code
Notes

#800 should have fixed this ... let me know if you're still seeing this @sparikh1594 👍


Common Lisp/ros/swank not behaving as expected

Hi,
Don't know quite how to formulate this, as I'm new to the CL ecosystem, but I am able to run this code within a ros repl with no issue:
(ql:quickload :cl-collider)
(in-package :sc-user)
(named-readtables:in-readtable :sc)

(setf *s* (make-external-server "localhost" :port 48800))
(server-boot *s*)

(defvar *synth*)
(setf *synth* (play(sin-osc.ar [320 321] 0 0.2)))

However, when running it in nvim/conjure with
❯ ros run --eval '(ql:quickload :swank)' --eval '(swank:create-server :dont-close t)'

I get this:
; <IP_ADDRESS>:4005 (connected)
; with-protoent
; --------------------------------------------------------------------------------
; eval (root-form): (ql:quickload :cl-collider)
; To load "cl-collider":
;   Load 1 ASDF system:
;     cl-collider
; ; Loading "cl-collider"
;
;
(:CL-COLLIDER)
; --------------------------------------------------------------------------------
; eval (root-form): (in-package :sc-user)
#<PACKAGE "SC-USER">
; --------------------------------------------------------------------------------
; eval (root-form): (named-readtables:in-readtable :sc)
#<NAMED-READTABLE :SC {1005AB0633}>
; --------------------------------------------------------------------------------
; eval (root-form): (setf *s* (make-external-server "localhost...
; The function COMMON-LISP-USER::MAKE-EXTERNAL-SERVER is undefined.
; --------------------------------------------------------------------------------
; eval (root-form): (server-boot *s*)
; The variable *S* is unbound.
; --------------------------------------------------------------------------------
; eval (root-form): (defvar *synth*)
*SYNTH*
; --------------------------------------------------------------------------------
; eval (root-form): (setf *synth* (play(sin-osc.ar [320 321] 0...
; The function COMMON-LISP-USER::SIN-OSC.AR is undefined.

Running on arch linux with ros-installed sbcl:
❮ ros config
sbcl.version=2.4.2
setup.time=3918183544
sbcl-bin.version=2.4.1
default.lisp=sbcl

Not sure if it's got to do with cl-collider only, or if it's a general issue... Any help much appreciated!

Hey sorry about the bug, it's because Conjure is swapping the package to "common-lisp-user" on each eval because it's looking for a defpackage form and not finding it. It's related to https://github.com/Olical/conjure/discussions/557
I'm just trying to add a fix now that is a best effort contextual eval that should support multiple defpackage / in-package forms in a file. Conjure's context system was designed with Clojure in mind with one ns form at the top and you generally keep the link of file-namespace name. It looks like in CL people swap the package a lot in some files, so I haven't accounted for that yet.
I'm not a CL user so it's a bit unfamiliar to me, but I'll add a best effort fix for this to develop now.

Great, thanks! I'm also brand new to the whole world of CL, so it's all a bit confusing :-)

Pushed a change to develop that I think addresses this? We now search up through the lines from your cursor position for the nearest in-package or defpackage then try to assume that package name with the eval you're doing. So it should support multiple regions in your files where you swap between packages for different calls.
I think that's useful for CL? But I'm really not sure! Let me know if that works for you. I can call the functions you listed in your example now but I do run into some other kind of errors, I think because I don't have whatever dependencies it needs installed.

Wow, that seems to work! Thanks a lot.
A couple of initial tests:
(in-package :sc-user)
(named-readtables:in-readtable :sc)

(setf *s* (make-external-server "localhost" :port 48800))
(server-boot *s*)

(defvar *synth*)

(setf *synth* (play(sin-osc.ar [320 321] 0 0.2))) ;; evaluating root form here...
(free *synth*) ;; ... also evaluates this.

(server-quit *s*) ;; evaluating root form on this also evaluates the previous two forms.

Not sure if this is expected behavior....

Cool! That eval capturing other forms is definitely not expected though.
Are you using Tree Sitter? If not, well worth a try, it's so much more
robust.
On Fri, 1 Mar 2024, 14:02 Kenneth Flak, @.***> wrote:

Wow, that seems to work! Thanks a lot.
A couple of initial tests:
(in-package :sc-user)
(named-readtables:in-readtable :sc)
(setf s (make-external-server "localhost" :port 48800))
(server-boot s)
(defvar synth)
(setf synth (play(sin-osc.ar [320 321] 0 0.2))) ;; evaluating root form here...
(free synth) ;; ... also evaluates this.
(server-quit s) ;; evaluating root form on this also evaluates the previous two forms.
Not sure if this is expected behavior....
—
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/561#issuecomment-1973260281,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACM6XJ6NIBX7B4WX66F5NTYWCC6ZAVCNFSM6AAAAABD7POJBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZTGI3DAMRYGE
.
You are receiving this because you commented.Message ID:
@.***>

OK, so treesitter is to blame here, I think :-) Tried updating it, but seems it hasn't seen an update for 4 months, so there may be some breaking changes in the treesitter since then. When I disable treesitter for commonlisp the evaluation works as expected. If I have a bit more time I'll open an issue over at cl-treesitter!

Ah, figured out where treesitter stumbles: it doesn't like the square brackets in this expression:
(setf *synth* (play(sin-osc.ar [320 321] 0 0.2))) ;; evaluating root form here...

When I change those to regular parentheses it all works fine.

@Olical commented:

I'm just trying to add a fix now that is a best effort contextual eval that should support multiple defpackage / in-package forms in a file. Conjure's context system was designed with Clojure in mind with one ns form at the top and you generally keep the link of file-namespace name. It looks like in CL people swap the package a lot in some files, so I haven't accounted for that yet.

I think that it should be the nearest preceeding in-package form from the form or item being evaluated. I've put a comment regarding this on the discussion #557.
But I will try the fix added to the develop branch to see how things works so far.

I tried the fix added to the develop branch (https://github.com/Olical/conjure/commit/20df0e0c4dc41654cf7276801e0aa2f4931cce6f) and it seems to work.

Oh okay, so defpackage does NOT swap your current package like Clojure's na
form? You NEED both?
On Sat, 2 Mar 2024, 08:03 Russ Tokuyama, @.***> wrote:

I tried the fix added to the develop branch (20df0e0
https://github.com/Olical/conjure/commit/20df0e0c4dc41654cf7276801e0aa2f4931cce6f)
and it seems to work.
—
Reply to this email directly, view it on GitHub
https://github.com/Olical/conjure/issues/561#issuecomment-1974698334,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AACM6XM3I2VW6Q6CD7CTBN3YWGBTLAVCNFSM6AAAAABD7POJBGVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSNZUGY4TQMZTGQ
.
You are receiving this because you were mentioned.Message ID:
@.***>

No, just in-package should be OK.

So are we happy with this now? I'm going to merge anyway and get it in more hands, I think it's solid theoretically from what I understand of CL now. Thanks for doing research, sharing it and testing this @russtoku ❤

Closing this issue because I think we did it! Please re-open if you run into issues!


(Re-) Add "Open in VS Code" to the windows 11 context menu first layer

Windows 11 is a great OS but what I am missing is the "Open in VS Code" Option in the first context menu. I know it is there under "Show more options" but as a developer that opens projects 100 times a day this is very annoying. I also know that there are third party solutions, but this should be there by default as it was in Windows 10

It's already in Insiders builds.
/duplicate of #204696 for stable

Thanks for creating this issue! We figured it's covering the same as another one we already have. Thus, we closed this one as a duplicate. You can search for similar existing issues. See also our issue reporting guidelines.
Happy Coding!


store_item can result in excessive stack allocations

Because of the algorithm used for buffering a to-be-erased block, this means that an entire flash block is buffered on the stack. For the STM32H7 series, each flash block is 128KB (8 sectors total, 1MB flash), which is a prohibitively large stack allocation.
Some possible work-arounds:

Accept a user-provided buffer for storage instead, allowing the buffer to either be statically allocated (i.e. from some memory location not on the stack)
Modify the algorithm used to accept an N-sized buffer, where we scan the to-be-erased block for elements that only exist in it, and then store them in the buffer. That way, we likely do not need to store the full block. If the user-provided buffer is insufficient, return an error.

Thoughts here @diondokter ?

1 is pretty easy to do. And yeah 128kb is excessive! It was meant for chips with like 4k blocks. Still doesn't really solve the problem that it uses a lot of memory, it only moves it off the stack.
2 would be nicer, but there's a concern. There's a reason the algo is recursive.
The erased page could be full of unique items that take up the full page. So if you erase it, and then add everything back again, you're in the same situation as before except that it's now no longer the oldest page, but the newest. But you're still left with wanting to add the new item and so you have to continue with the next page. (which can have that problem again).
2 could work, but it'd be unclear how much smaller than a page you could make it. That would really depend on how many different keys there are (and how big their corresponding values are) and some randomness.

I guess there's an option 3 as well. And additional page could be left open at all times as well. That way you'd just transfer items to the new page directly one by one instead of buffering it all first...

I guess there's an option 3 as well. And additional page could be left open at all times as well. That way you'd just transfer items to the new page directly one by one instead of buffering it all first...

This is an interesting one as well. I.e. use a spare flash block as the working space when erasing the oldest buffer - I like this idea personally, as I think it's the simplest and creates a non-breaking API change.

3 does effectively require a minimum page count of 3 and loses you some storage space. I'd consider that a breaking change. But it'd be easy to upgrade to.

Having 3 flash pages would already imply that your flash pages are massive, which means that the existing architecture likely wouldn't support it anyways (since it wouldn't fit on the stack).

That's true yeah

I implemented option 3 in the linked PR. Now released as 0.5.0

Wonderful, thanks! I'll give this a try now, as I think that was the major blocker for me. I tried rearranging our memory usage, but it was causing perfomance issues in other areas because the new stack ram was slower.


[react-lazyload] Please add height props to  for better performance.

Could anyone please explain why this is impacting performance?
My usage:
I'm always rendering a placeholder that has the exact size of the element that will created by lazy load. The browser will not push other content around.

If the height isn't a requirement and entirely optional then it would be better not to output the warning since its just creating unnecessary logging. +1 for removal.


Merging data within dynamically added script tags

I am trying to integrate Green Turtle with an XForms application (XSLTForms) and would like to be able to merge Turtle data that has been dynamically loaded within an embedded <script type="text/turtle"> tag. With RDFa-encoded data, it's possible to update the default graph by calling GreenTurtle.attach(document). Is it possible to do the same with embedded Turtle that has been dynamically added after the initial page load?

The turtle is automatically detected and loaded into the graph.  If you dynamically add a script element, you just need to call attached again:
document.data.implementation.attach(document)

or
GreenTurtle.attach(document)

Thanks, that's what I thought. My problem seems to have been with DBpedia's default Turtle output, which interweaves prefixes and triples. For example, the query
DESCRIBE <http://dbpedia.org/resource/Turtle_(syntax)> WHERE {<http://dbpedia.org/resource/Turtle_(syntax)> ?p ?o} ORDER BY ?p LIMIT 1
results in output like this:
@prefix dbpprop:	<http://dbpedia.org/property/> .
<http://dbpedia.org/resource/TriG_(syntax)>	dbpprop:extendedFrom	<http://dbpedia.org/resource/Turtle_(syntax)> .
@prefix dbpedia-owl:	<http://dbpedia.org/ontology/> .
<http://dbpedia.org/resource/Turtle_(disambiguation)>	dbpedia-owl:wikiPageDisambiguates	<http://dbpedia.org/resource/Turtle_(syntax)> .
@prefix ns2:	<http://www.w3.org/2006/03/wn/wn20/instances/> .
<http://dbpedia.org/resource/Turtle_(syntax)>	dbpprop:wordnet_type	ns2:synset-format-noun-1 .
@prefix owl:	<http://www.w3.org/2002/07/owl#> .
<http://dbpedia.org/resource/Turtle_(syntax)>	owl:sameAs	<http://rdf.freebase.com/ns/m.0gkp12> ,
    <http://es.dbpedia.org/resource/Turtle_(sintaxis)> .

The parser throws the following errors:
2: No prefix mapping for dbpprop
2: Terminating: Cannot parse predicate IRI.
2: Missing end . triples.  Found: ...

DBpedia does offer a pretty-printed Turtle serialization (which they qualify as "slow!"), but this "alternative" format doesn't have a standard MIME type that can be requested (as far as I can tell).


General contractions have repeated blocks (and should be condensed)

Somewhat related to #63
Some raw data does not nicely condense general contractions. This results in repeated blocks within a single angular momentum block.
For example, here is a snippet from aug-cc-pVTZ-PP for Pt
Pt    S
     36.0064000              0.0156030              0.00000000
     22.4991000             -0.1396000              0.00000000
     14.0609000              0.3994690              0.00000000
      8.7816100             -0.1277440              0.00000000
      4.9923800             -0.7514510              0.00000000
      1.3838500              0.8633270              0.00000000
      0.6616170              0.4975940              0.00000000
      0.2048820              0.0347580              0.00000000
      0.0922300             -0.0065890              0.00000000
     36.0064000              0.00000000            -0.0056780
     22.4991000              0.00000000             0.0507550
     14.0609000              0.00000000            -0.1500300
      8.7816100              0.00000000             0.0639820
      4.9923800              0.00000000             0.2704110
      1.3838500              0.00000000            -0.4346570
      0.6616170              0.00000000            -0.3372900
      0.2048820              0.00000000             0.2814460
      0.0922300              0.00000000             0.6455790

Fixed in 9b9db7b536dce7598b05db8947e3822d118e9b21


Remove version: FreeCiv.FreeCiv version 3.0.0

[Automated] It returns code over 400 in all urls
Microsoft Reviewers: Open in CodeFlow

URL: https://sourceforge.net/projects/freeciv/files/Freeciv 3.0/3.0.0/Freeciv-3.0.0-msys2-win64-gtk3.22-setup.exe/download
Status Code: 200
(Automated message - build 896)

Close with reason: Package still available.;


Issue with Job timed out after 10000 seconds. [5201]

What is the expected behavior?
I am working on implementing an image classifier following this tutorial: https://github.com/Qiskit/qiskit-tutorials/blob/master/legacy_tutorials/aqua/machine_learning/qsvm_classification.ipynb.
I was able to run the code and get results using a virtual quantum computer in my local computer. But when I run the same code in "ibmq_qasm_simulator" it is giving me this error: "Job timed out after 10000 seconds. [5201]".  any idea how to solve this? I am using 10 qubits (i.e., number of features after PCA). Thanks in advance. (edited)

@jyu00 Jessie, do you have any thoughts here. Maybe the algorithm and resulting job is just too complex as the 5201 would suggest. Its certainly a long time to run to determine that before failing.

The 5201 is a safeguard designed to ensure a job doesn't get stuck for some reason (hence the long timeout). I ran the same notebook on ibmq_qasm_simulator and got the same error. However it ran fine locally on Aer qasm_simulator, so it's not an issue with the job itself. I've opened an issue with the IQX dispatcher team.

@woodsp-ibm This should be working now.

@jyu00 Thanks for looking into this and having a resolution so quickly.
@mahfuz195 Please give your notebook another try as it should work now.

@mahfuz195 Since this should be working I am going to close this issue. If the same problem is still happening then please feel free to re-open this issue.


Bookmark links choose zoom level

The TOC feature is really nice! :+1: As it is it helps me a great deal. Thanks :heart_eyes:
Currently the zoom for each link is "Fit Page" and only goes to a specific page (I think) rather than the exact section location.
The pdf spec provides a range of options:

I would suggest that what the user is looking for is /page XYZ <left> <top> null or /page XYZ  <left> <top> 0 where left and top are the coordinates of the section on the pdf. Otherwise navigating a document via hyperlinks causes constant need to change/modify the zoom level and the user is not taken to the exact location of interest.
I'm not currently able to see where this is done in the code or at which layer in this stack... but am quite curious.

Oh dear. Whoopsie, bad me. I take it all back. None of the above is true -- I was post-processing the output and in fact another tool was adversely affecting the bookmarks. Lies. All lies. :sob: :cry: :smiley:


Update README.md

Adding information regarding NAE-XML operations metrics.

The README should also be updated to match the name of the dashboard. Btw, it would be easier if the README and the updated dashboard were in the same merge request.


Fix Ruby 3.1 on CI for dependent builds (this time for real)

Follow-up to #2553 I've quite missed the fact that dependent builds specify no RAILS_VERSION, and another case branch was used, causing net- dependency failures.
Also, add Ruby 3.1/Rails 6.x to CI matrix, since Rails 6.0 is what our dependent builds use.

This depends on this fix from #2552


Create Common opensearch/ elasticsearch core package

Related Issue(s):

#167

Description:
Create a common opensearch/ elasticsearch core package. Create separate stac-fastapi.opensearch and stac-fastapi.elasticsearch packages.
PR Checklist:

[x] Code is formatted and linted (run pre-commit run --all-files)
[x] Tests pass (run make test)
[x] Documentation has been updated to reflect changes, if applicable
[x] Changes are added to the changelog

Looks great. After #187 is merged, the only backend-specific code will be in the *_config.py and the *_database_logic.py files. Everything else can be contained in the core module, right?

Looks great. After #187 is merged, the only backend-specific code will be in the *_config.py and the *_database_logic.py files. Everything else can be contained in the core module, right?

I think I have moved everything around properly. I am not a git expert so I didn't know the easiest or best way to do this. Have a look. I think the main thing we need to do is update the update_collection method in opensearch/database_logic.py. I haven't updated the Makefile yet either ....

If you want we can merge your branch into main before we merge this. Up to you. Another thing to think about too is how the tests are duplicated right now. Maybe we want a separate package for the tests?

Looks great. After #187 is merged, the only backend-specific code will be in the *_config.py and the *_database_logic.py files. Everything else can be contained in the core module, right?

I think I have moved everything around properly. I am not a git expert so I didn't know the easiest or best way to do this. Have a look. I think the main thing we need to do is update the update_collection method in opensearch/database_logic.py. I haven't updated the Makefile yet either ....

Merged those changes into the add-opensearch branch. I included a couple changes to the makefile to run tests on one or both backends

If you want we can merge your branch into main before we merge this. Up to you. Another thing to think about too is how the tests are duplicated right now. Maybe we want a separate package for the tests?

Cool, I think #188 is ready go. I will let you take a look and commit to main. Right now they are both using the same set of tests all the ES/OS calls are wrapped in the database_logic, so it seems to work fine for both.

@jamesfisher-gis Hi. I think this is ready for review now.

@gadomski @philvarner Adding you guys if you have time to review or even share your thoughts.

This is actually a really long pr but the vast majority of it is only moving code around.


Resolution on Mac with Retain screen

#4 Mac Layout
The resolution of icons and text is a little on the blurry side.  I'd like to see higher resolution of the icons and text so that they are sharp.
Possible solution

Font awesome or some other Icon font would allow for vectorized standard so that all resolutions can be accommodated.  But then the user would need to install a font with the package.
I might volunteer to redesign a higher rez icon, if someone could tell me what kind of formats are needed.  I'm also not necessarily a very good designer but i'd be happy to take a stab at it!  Let me know.

Love the skin =)

Hey man
All icons are already in SVG format which is vector based, so they don't have inherent resolution. The blurriness is probably caused by a QT issue not rendering in full dpi (retina support?).
Try using the latest development build of mumble which includes an updated QT version. Otherwise try seeing if the issue happens on other skins such as omega.
If possible, provide a screenshot ;)


WIP: weighted hamming distance in C

@magnusja if you have multiple little fixes/changes, it's best to all push them in one go rather than one by one. otherwise you're swamping our CI system with requests. and you can run tests locally first (e.g. python -c "import scipy.spatial as s; s.test()").

@magnusja accelerating the current implementation of hamming with w not None seems like a good idea, but there is no need for a new whamming metric. hamming itself already provides the API for weights.

Hey @rgommers, thanks for the feedback. You mean more like this? https://github.com/magnusja/scipy/tree/feature/weighted-hamming

Hi @magnusja, that looks about right from a quick browse. API wise definitely okay, will have to look at the C code later but looks reasonable. Can you push that branch to this PR?

Unfortunately I cannot easily, so I am closing this in favor of: https://github.com/scipy/scipy/pull/9813
(some tests still fail unfortunately, I am still trying to figure out why)


[NEW ALGORITHM] Increasing Triplet Subsequence

Overview
This pull request introduces a C program that determines whether an increasing triplet subsequence exists in a user-provided array of integers. The algorithm efficiently checks for the presence of the triplet using a linear-time approach, leveraging a prefix minimum and a suffix maximum.
Changes Made

Program.c: Contains the C implementation of the increasing triplet subsequence algorithm.
README.md: Provides comprehensive documentation including:

Description of the problem and solution approach.
Detailed structure of input data and function parameters.
Time and space complexity analysis of the algorithm.
Example inputs and outputs demonstrating functionality.

How to Test

Compile the Program.c using a C compiler (e.g., GCC).
Run the executable and follow the prompts to enter the number of elements and the array elements.
Verify the outputs to confirm the presence or absence of an increasing triplet subsequence.

Issue Resolved

Issue #1348

Additional Notes

The implementation is designed to handle a variety of input lengths and values, ensuring robustness and efficiency.
This program operates in O(n) time complexity and O(n) space complexity due to the auxiliary array for suffix maximums.

Please review my PR and add labels as per my work @pankaj-bind.

Hi @pankaj-bind, I've submitted the PR. Could you please review it? If you notice any issues or have suggestions for improvements, I'd be happy to address them. Thanks!


Build a CI/CD pipeline

Check against UI unit test

@Georgie-RedBadger we are closing this issue because is too broad and @DimplePatel @anubha22 and myself are creating more refined tickets


Give padding when clicking on settings button

Some padding from the border and some padding from the bottom So That It can look more prettier.
While changing the theme I found this I think it should have some padding

Which part are you talking about here? The settings gear icon in the activity bar? Or the menu content itself?

Yes  The settings gear icon in the activity bar

I don't think we're likely to add any padding-bottom to the gear icon here. From the screenshot and issue title ("..clicking on..") it may be that the concern is coming from the positioning of the context menu though?
Hard to tell if this is a subjective visual ask or if there's a functional issue.


api/v1beta1/hosted_controlplane: Godocs for ReleaseImage and IssuerURL

These made it into v1alpha1 via b758e90f46 (#1742), with the following timeline:

2022-08-25, #1703 opened adding v1beta1.
2022-09-13, #1742 opened adjusting v1alpha1 Godocs.
2022-10-18, 1742 merged.
2022-11-29, 1703 merged.

Ideally 1703 would have rebased and picked up any intervening v1apha1 improvements before merging, but it missed these (and possibly more?), so I'm catching it up now.

/lgtm
/approve