scrollwheel zoom to cursor

Currently the scrollwheel zooms in/out to the center point of the axes. Modify this behavior to center where the cursor is. This will let you hover over a region of interest and zoom into that region without having to move the cursor.

98ac57a2666b42e0f3e8f4a20d77a0346f08a7ff


getData([]) unable to work for me.

When I'm trying to feel static data in jsuites sheel. And feel data manually the in sheet then how to get cell value and cell id. Please help me to solve this.

Sorry, I am not sure if I understood your question.

Hi Paul,
I think you did not understand my question. Not an issue, When I'm
integrating blank excel and at that time I select a single cell and add
data init. That data I want in data = [...] available in "
jexcel(document.getElementById('spreadsheet'){ data: data  } "  like that
every cell data i want in data = []. Hope you understood and i'm waiting
for you reply. Thank you so much.
Thanks & Regards -
Ritesh Mahesh Shroff
On Thu, May 7, 2020 at 1:36 AM Paul Hodel<EMAIL_ADDRESS>wrote:

Sorry, I am not sure if I understood your question.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
https://github.com/paulhodel/jsuites/issues/30#issuecomment-624861784,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOYYZ44I3YHGMBIS4MLR5X3RQG7KVANCNFSM4MNGVQ6A
.

Sorry, still not sure. Can you see this one?


Null pointers should not be dereferenced

This pull request is focused on resolving occurrences of Sonar rule squid:S2259 - Null pointers should not be dereferenced
You can find more information about the issue here:
https://dev.eclipse.org/sonar/coding_rules#q=squid:S2259
Please let me know if you have any questions.
Kirill Vlasov

This cleanup doesn't add much value. We'd rather dereference things assuming non-nullness, and fix crashes when they occur. We'd rather add preconditions checks for things we expect to be non-null, than have the explicit checks everywhere in the code.

I understand, anyway thanks for considering my PRs!


fix password reset workflow

This fixes the password reset workflow so that it works on 5.x. Illuminate\Http\Request wasn't imported causing some of the methods to fail since it wasn't able to locate the class. Also, Password::remind was changed to Password::sendResetLink.

thanks @oohnoitz


Use non-docker actionlint commit hook

Description
The actionlint-docker commit hook has some issues when running using podman from macos, it tries to mount the repository in a way that is not supported and fails. Because fixing this upstream would be annoying and installing actionlint locally shouldn't be a big deal, we should start using the native binary option. This is also preferable to committing with --no-verify and relaying on people running the check manually.
For instructions on how to install actionlint see: https://github.com/rhysd/actionlint/blob/main/docs/install.md
Checklist

[ ] Investigated and inspected CI test results

Testing Performed
This is a change that only affects developer workflow.

I think we'll need to install actionlint in the GHA runner for the lint workflow (unless it is there by default?)

I think we'll need to install actionlint in the GHA runner for the lint workflow (unless it is there by default?)

You are right, it's not in the list of installed software, I'll run some tests and get back to you.


refactor worker

Closes #933

Successful PR Checklist:

[x] Tests

[ ] (not applicable?)

[ ] Documentation

[ ] (not applicable?)

PR label(s):

[x] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A breaking 💥
[x] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A feature ⭐
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A bugfix 🕵
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A miscellaneous 👾
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A dependencies 🤖
[ ] https://github.com/procrastinate-org/procrastinate/labels/PR type%3A documentation 📚

Worker refactoring
Goals
This is a rewrite of the worker implementation with the intent of reducing the number of SQL queries while keeping the same intent of low latency processing thanks to Postgres notifications, combined with occasional polling.
Implementation
The Worker class fetches and dispatches new jobs.
When running in wait mode, it also starts any side subroutine (notification listener, periodic task generator) and waits for new jobs to be available.
For every job, it creates a new asyncio task that eventually completes.
The worker keeps on fetching jobs as long as the number of jobs being processed has not reached the configured concurrency.
When all job processors are busy, the worker waits until one of those asyncio tasks is done.
When no job is available, the worker waits until it receives a notification from postgres or up to the specified polling frequency, whichever comes first.
Cancellation
If the worker is in wait mode, it will keep on going until its run task is cancelled (generally by the App).
When that happens, it will wait for all pending jobs to complete.
Remaining work
The documentation still needs to be amended.
I initially renamed the timeout option to polling_interval as I find the former name rather confusing but eventually reverted that change given it would introduce breaking changes in multiple parts of the API.

I'm surprised (and impressed) that you didn't have to change the listen/notify implementation. I would have bet that it was much too tightly coupled with the implementation of the worker, but it seems not.
Overall, very nice job so far.

I see something that might need fixing:
Whenever we have fetched a job, we should execute it, even if we cancel the worker between the moment the job has been fetched and the moment it's started.
If possible, I'd much rather see the graceful stop scenario rely on ending the while True loop at startegically chosen spots than it being stopped instantaneously by an exception and having the finally take care of cleaning it. I've seen that the task execution itself is shielded from cancellation, but thinking about all the places where the CancelledError might raise, I'm a bit afraid that there are plenty of spots where this would leave a broken state (e.g. task in doing but not actually running, potentially blocking the following tasks with the same lock).
I think a better approach would be to shield the whole worker coroutine, and on stop, switch a boolean (or an asyncio.Event) to indicate to the current coroutine and to the children processor that they should stop. Note that, according to my first point above, the workers should only (gracefully) stop when the queue is empty, and if the worker really needs to stop immediatly, we should do our best to mark any fetched task that wasn't ran as such (either back as todo but it might be problematic with queueing locks, or as failed/cancelled/...).

I will have a think about all the possible edge cases you mentioned and how it plays out, an opportunity to add further tests.
You make some good points 👍

Would it make sense to do the queue the other way around ?
The processors would put things (or themselves) in the queue to indicate they're ready to take a job.
The worker would get a processor from the queue and then fetch a job for that processor, and loop.
It seems it would avoid entirely the idea of having to check in advance the state of the queue.

That is an interesting take.
Wouldn't that require to then keep track separately of what is being processed (since those busy processors would no longer be in the queue) when a stop request comes in?

You can have, separately, a list of all existing processors, and a queue of processors awaiting their next job.
When a stop request comes in, the worker would indicate to each processor that they need to stop, and would stop processing the queue and gather the processors asyncio tasks.
The processors, when being told to stop, would immediately log the status of the task they're processing, and then either they were waiting in the queue and they stop immediately, or they were already given a job, and at the end of processing, they'll stop.
It this case, it's even possible that the processors wouldn't have a loop. Just a coroutine where they'd execute a job and put themselves back in the queue at the end.
But then if we run a new coroutine each time, is it even worth using a queue ? Each time we have a job to execute, we can spawn a processor. This just adds a single problem: how to ensure we respect the concurrency factor. And I'd say: that's where we would use a semaphore the right way:
The worker would then:

while not stopping:
acquire the semaphore (await if need be)
fetch a job (wait for the next job if need be)
launch a processor asyncio task on the job and give it the semaphore
(loop)

(Alternatively, we could imagine the worker not waiting for the job to be available and just releasing the semaphore and looping as long as it waits the polling interval at some point, and we ensure that stopping the worker interrupts this wait)
The processor would:

process the job
release the semaphore

I think the whole model would be simpler. The only thing is that in that case, we'd have the problem you initially mentioned: the worker wouldn't know which processors are running so when stopping, it would be harder to log the running tasks.
I'd say we could keep a WeakSet of processors we've launched. This way, as long as they're running, they'd be in the set, and when they've stopped, nothing will be referencing them and they'd disappear from the WeakSet.
What do you think ?

Sounds like a whole different implementation 😅.
I guess we need to code that alternative so we can compare approaches and see which is simpler.
It might take me a while but that's ok 👍

It's conceptually very different, but I think it's not very different in terms of lines of code. I might be mimizing things though, as it's only in my head.

@ewjoachim I have pushed an update where I got rid of the queue and followed some suggestions. It does look simpler.
I kept the logic of relying on asyncio cancellation instead of introducing a stop event.

Still a few things I need to fix. Will resume next week...

The last big topic I want to address is:

I kept the logic of relying on asyncio cancellation instead of introducing a stop event.

I've seen you insist on this aspect, so I understand this is something you'd prefer compared to the alternative. Also, note that it's not something I consider a firm decision on my side or whatever, but I'd appreciate if we can ensure we have a common understanding of the pros and cons of each alternative. I don't want to be annoying you on that matter if it's not worth it :).
My questions would be:

Is my understanding correct that you prefer the asyncio cancellation?

Is it because it's already coded this way and you want to avoid large changes again in this PR or is it because there is a reason it's better?

What would be, if applicable, the reason it's better?

From my point of view, the issue with this approach (and I'm definitely not saying it's a fatal flaw) is that both now and in the future, it forces us to be mindful when we change the code of the worker to ensure that at any place where we await (or async with or async for), we will respect the graceful stop ability, and not leave the task in an inconsistent state, whereas if we use a stop event, there will be explicit points where we break and we can reason individually on all those points. For me it's about "Explicit is better than implicit" and about what we need to have in mind in future evolution of the worker. My gut feeling would be that this makes evolution of the worker somewhat more brittle, though I have nothing strong and factual to support this claim.
That said, I might be completely missing an important point that balances out this entirely. And in the case where you agree but don't want to do the change in this PR, it's perfectly acceptable as well (though it's perfectly ok too if you don't agree)

So far, the main reason I have kept the asyncio cancellation is that I could not find a similar way to express that using the stop event construct.
Right before I was to ask how that would work, I just discovered I can pass in an iterable of tasks to asyncio.wait and also specify to stop at first completed task.
Now that I found the missing piece of the puzzle, let me try out a version with a stop event 😅
Stay tuned

Still a few things I need to fix. Will resume next week...

No worries, and no pressure. I've said all the important points I wanted to convey, and it looks like we agree, so once the PR is good for you, I imagine there will only be minor stuff (if any). Let me know when you're ready for the last (🤞) round 😀

@ewjoachim Let me know what you think.

There is another thing we need to tackle @ewjoachim.
I think the Worker documentation is incorrect. It suggests to use wait_for and that a timeout indicates that the worker was not stopped gracefully.
However, I have tested it in the current version (and in this PR) and this is not what happens.
When the timeout occurs, it will still wait for the cancellation of the task. Effectively it will still wait for a graceful shutdown.
There is where I think we need to introduce a shutdown/stop timeout that we respect.
We can keep the behaviour of cancel performing a graceful shutdown. Not sure using asyncio.wait_for would work because there doesn't seem to be a way to capture the passed in timeout within the run task, which is why I am suggesting a shutdown/stop timeout option.

I think the idea I had (maybe there's a bug) is that if you call cancel once, you can await a graceful shutdown, and if you call cancel twice, you will get a hard shutdown (that's why run_worker_async was awaiting the shielded worker and upon CancelledError was then awaiting the worker again but without shielding)
I see multiple things in your message:

did this actually work before?
does this still work?
is it properly documented?
and then, as a separate question, is there a way to know whether the worker was gracefully stopped or not
and then, as another different question, do we want to add an internal shutdown timeout mechanism

I think I'd like to avoid 5. If we can for now if it can easily be done without doing it ourselves. I'm not sure I've understood enough of the situation to understand why it's necessary, but I probably need to play with it myself.
I think that 4. Is likely to require a change on our side, especially since we now raise CancelledError even if we stop gracefully

The typical scenario is that a worker is requested to stop.
When that happens, all jobs in progress will be stalled, which is not ideal.
It might be preferable to give the worker the opportunity to cancel remaining jobs and update their status in the database.
I don't know about the double cancellation because there are multiple ways to initiate the shutdown (calling stop on the worker, receiving a stop signal, cancelling the run task).

I will push a draft of what I had in mind to help the conversation

I probably did not explain it very well, so here is an example of what currently happens:
            @app.task()
            async def do_stuff():
                await asyncio.sleep(20)

            try:
                await asyncio.wait_for(app.run_worker_async(wait=True), 5)
            except asyncio.TimeoutError:
               # this will be called after 20 seconds when the job completes

I've looked at your proposal. Seems good. I'm afraid I'm starting to be a little bit lacking of strong design inputs, but it seems good.
If I understand correctly, the test you've added explores what happens when the task itself raises TimeoutError (you call asyncio.wait_for inside the task). I'm not sure I understand why that should be different from any other user-generated exception that should not bubble outside of the task,, but maybe I missed something (maybe I'm confused by the fact you're awaiting worker.run_task and not run_task ? The fact that those 2 are named identically is not helping)
I'm starting to wonder whether we will be doing heavy breaking on this PR. Is it worth releasing a major version? Can you summarize what behaviour will be different ?

If I understand correctly, the test you've added explores what happens when the task itself raises TimeoutError (you call asyncio.wait_for inside the task)

I will add a comment to make it clearer.
The wait_for inside the task in the test is only there as a fail-safe (if the test fails and the tasks did not have a timeout, pytest will keep on waiting).
If you pay attention to the sleeping time, that timeout of 200ms never occurs because the test is configured to cancel tasks after 20ms

@ewjoachim Apologies. Allow me to backtrack on what I wrote above.
Somehow, I missed that the example of stopping the worker is first calling .cancel() on the run task before calling wait_for().
I amended the shutdown timeout logic.

I say: we merge this in v3. We'll get some opportunities to discuss the details before it's written in stone.
Deal ?

Congratulations :)


Add chown to permissions page

See https://www.openmicroscopy.org/community/viewtopic.php?f=4&t=8381
The fact that group owners (and admins) can change the ownership of data was not included in the permissions table.

Remove "now easily" from the https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR16 - "now" is very dated, and "easily" is not totally accurate (the action is easy to trigger, but the consequences are non-trivial under circumstances)

In https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR50, "This would typically be a PI..." refers to Group Owner. But as the previous sentence is also mentioning administrators, this is not completely clear.

In https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR79 "...as somewhere to store their data..." - maybe a bit clumsy formulation, why "somewhere"

This https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR81 "...copied..." strongly suggests there is such thing as copy between groups in OMERO. But there is not. Maybe change to "moved"

In https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR91

remove "some" in "...some annotations..." - all possible annotations are possible to do for Group Owner in this situation.

after this line https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR100 I would add a bullet point saying something like:
Read-only group is a part of the Publication workflow in OMERO, see http://help.openmicroscopy.org/publish.html#public

Removed my previous comment about publications and Read-only. The statement is there in the next bullet point. But I would still cite http://help.openmicroscopy.org/publish.html#public
in https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR104

I am not sure about the intermediate in ...This is an intermediate option.... We have four group levels, thsi is the second one. https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR87

..a more collaborative group. Maybe ...a group where some collaboration on other members data is enabled https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR107

In here https://github.com/openmicroscopy/ome-documentation/pull/1794/files#diff-3c1d6113c0b3e790090e598763e385caR297 there is a missing comma before ROIs

Finished reading, couple of reformulation suggestions in the whole doc.

@pwalczysko I think I've caught all of those in my latest commit, I'll rebuild the merge docs once Travis is green.

https://ci.openmicroscopy.org/view/Docs/job/OMERO-DEV-merge-docs/886/ includes the latest changes here

One typo found https://github.com/openmicroscopy/ome-documentation/pull/1794#discussion_r145916654.
After fixing the typo, can be merged. Thanks @hflynn


[Bug]: URLSearchParams snapshots in node 20 are wrong

Version
29.6.2
Steps to reproduce
With node 18:
it("symbols in snapshots", () => {
  const a = new URLSearchParams({ foo: "foo", bar: "bar" });
  expect(a).toMatchInlineSnapshot(`URLSearchParams {}`);
});

With node 20
it("symbols in snapshots", () => {
  const a = new URLSearchParams({ foo: "foo", bar: "bar" });
  expect(a).toMatchInlineSnapshot(`
URLSearchParams {
  Symbol(query): [
    "foo",
    "foo",
    "bar",
    "bar",
  ],
  Symbol(context): null,
}
`);
});

It seems to omit the Symbols within URLSearchParams.
Expected behavior
Same Snapshot for node 18 and 20, where both contain the Symbols query and context...
Actual behavior
node 20 shows an empty object.
Additional context
No response
Environment
System:
    OS: macOS 13.5
    CPU: (10) arm64 Apple M1 Max
  Binaries:
    Node: 20.5.0 - ~/.nvm/versions/node/v20.5.0/bin/node
    npm: 9.8.0 - ~/.nvm/versions/node/v20.5.0/bin/npm
  npmPackages:
    jest: ^29.6.1 => 29.6.2

Grab the code below and run on both versions of Node.js (outside of Jest):
// url-search-params.js
const x = new URLSearchParams({ foo: "foo", bar: "bar" });

console.log(Reflect.ownKeys(x));

You will see that the constructed object is indeed different. Seems like a breaking change on their side. That is normal and expected between major versions, but you can open an issue in their repo. That is not a bug in Jest, it just handles the data you provide.

For anyone interested, the underlying reason is that they changed the two class fields from regular fields with symbols to private fields, which apparently makes them disappear from snapshots.
https://github.com/nodejs/node/blob/v18.x/lib/internal/url.js#L186
https://github.com/nodejs/node/blob/v20.x/lib/internal/url.js#L305

@mrazauskas The real problem is that private fields become invisible to snapshots. Is there any way to address that, or is that just a limitation we have to live with?
class Foo {
  #bar = "bar";
  [Symbol("symbar")] = "symbar";
}
it("snap", () => {
  expect(new Foo()).toMatchInlineSnapshot(`
Foo {
  Symbol(symbar): "symbar",
}
`);
});

I don't know.
Why would you need to have private fields included in a snapshot? What does that test?

I don't know.
Why would you need to have private fields included in a snapshot? What does that test?

That's a fair point. I found a nice way to change my code and work around this.


School Management System In C

Description
My documentation includes a SCHOOL MANAGEMENT SYSTEM!
It is a menu driven program which includes:

The basic information of a student(Name,Roll Number, Marks)
Shows the students records
Sorts file on the basis of marks
Prints student's information using Roll no.
Calculates the average marks of the student

Hope this Student Records Management System helps you and your prestigious institution as well! :)
Domain
C/CPP
Type of Contribution
Documentation
Code of Conduct

[X] I follow Contributing Guidelines & Code of conduct of this project.

/assign


Integration tests do not pass in local environment

Bug Description
When running integration test command using environments degined in tox.ini (tox -e integration) tests fail to pass.
It should be noted that in recent PR these tests successfully passed in CI (GH runners). In particular test_ingress_url test.
The following is a PASSED test in GH runner, but never finishes in local testing (see To Reproduce section for more details):
tests/integration/test_charm.py::TestCharm::test_ingress_url
-------------------------------- live log call ---------------------------------
INFO     httpx:_client.py:1013 HTTP Request: GET https://<IP_ADDRESS>:16443/api/v1/namespaces/testing/services/istio-ingressgateway-workload "HTTP/1.1 200 OK"
PASSED

To Reproduce
Execute tox -e integration and observe errors and not passed tests. It looks like running this particular command mlflow-server application is deleted in one set of tests and another set of tests fails. See relevant log section for more details.
When model for excuting integration tests is created and option to keep models is given (to prevent destruction of mlflow-server) Running the following command tox -e integration -- --model test --keep-models produces different error. This time test_ingress_url test never completes. See relevant log section for more details.
Environment
Local development environment, in this repository, on main branch.
Relevant log output
# results of tox -e integration
____________________ TestCharm.test_add_relational_db_with_relation_expect_active _____________________
Traceback (most recent call last):
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/runner.py", line 341, in from_call
    result: Optional[TResult] = func()
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/runner.py", line 262, in <lambda>
    lambda: ihook(item=item, **kwds), when=when, reraise=reraise
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_hooks.py", line 433, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_manager.py", line 112, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_callers.py", line 155, in _multicall
    return outcome.get_result()
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_result.py", line 108, in get_result
    raise exc.with_traceback(exc.__traceback__)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_callers.py", line 80, in _multicall
    res = hook_impl.function(*args)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/runner.py", line 177, in pytest_runtest_call
    raise e
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/runner.py", line 169, in pytest_runtest_call
    item.runtest()
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/python.py", line 1788, in runtest
    self.ihook.pytest_pyfunc_call(pyfuncitem=self)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_hooks.py", line 433, in __call__
    return self._hookexec(self.name, self._hookimpls, kwargs, firstresult)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_manager.py", line 112, in _hookexec
    return self._inner_hookexec(hook_name, methods, kwargs, firstresult)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_callers.py", line 155, in _multicall
    return outcome.get_result()
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_result.py", line 108, in get_result
    raise exc.with_traceback(exc.__traceback__)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pluggy/_callers.py", line 80, in _multicall
    res = hook_impl.function(*args)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/_pytest/python.py", line 194, in pytest_pyfunc_call
    result = testfunction(**testargs)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/pytest_asyncio/plugin.py", line 532, in inner
    _loop.run_until_complete(task)
  File "/usr/lib/python3.8/asyncio/base_events.py", line 616, in run_until_complete
    return future.result()
  File "/home/ichvets/cw/dev/mlflow-operator/tests/integration/test_charm.py", line 200, in test_add_relational_db_with_relation_expect_active
    await ops_test.model.relate(OBJECT_STORAGE_CHARM_NAME, CHARM_NAME)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/juju/model.py", line 1448, in relate
    result = await app_facade.AddRelation(endpoints=endpoints, via_cidrs=None)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/juju/client/facade.py", line 483, in wrapper
    reply = await f(*args, **kwargs)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/juju/client/_client13.py", line 946, in AddRelation
    reply = await self.rpc(msg)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/juju/client/facade.py", line 656, in rpc
    result = await self.connection.rpc(msg, encoder=TypeEncoder)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/juju/client/connection.py", line 629, in rpc
    raise errors.JujuAPIError(result)
juju.errors.JujuAPIError: application "mlflow-server" not found

# result of tox -e integration -- --model test --keep-models
tests/integration/test_charm.py::TestCharm::test_ingress_url
-------------------------------------------- live log call ---------------------------------------------
INFO     httpx:_client.py:1013 HTTP Request: GET https://<IP_ADDRESS>:16443/api/v1/namespaces/test/services/istio-ingressgateway-workload "HTTP/1.1 200 OK"
. . .
INFO     httpx:_client.py:1013 HTTP Request: GET https://<IP_ADDRESS>:16443/api/v1/namespaces/test/services/istio-ingressgateway-workload "HTTP/1.1 200 OK"
FAILED
_____________________________________ TestCharm.test_ingress_url ______________________________________
Traceback (most recent call last):
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/aiohttp/connector.py", line 1155, in _create_direct_connection
    hosts = await asyncio.shield(host_resolved)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/aiohttp/connector.py", line 874, in _resolve_host
    addrs = await self._resolver.resolve(host, port, family=self._family)
  File "/home/ichvets/cw/dev/mlflow-operator/.tox/integration/lib/python3.8/site-packages/aiohttp/resolver.py", line 33, in resolve
    infos = await self._loop.getaddrinfo(
  File "/usr/lib/python3.8/asyncio/base_events.py", line 825, in getaddrinfo
    return await self.run_in_executor(
  File "/usr/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/lib/python3.8/socket.py", line 918, in getaddrinfo
    for res in _socket.getaddrinfo(host, port, family, type, proto, flags):
socket.gaierror: [Errno -5] No address associated with hostname

Additional context
Need to verify in some other development environment to exclude possible broken development environment on the reporter's development machine.

I was able to reproduce the first part of the issue when running tox -e integration, the reason this is failing because we are not specifying a model name with -- model <model_name>, and due to how the tox file is written if we don't specify the model name then each test file will be executed in a different model.
See in the .tox:
https://github.com/canonical/mlflow-operator/blob/f18c4e667bbf2e7a7e4b92c6bba487e8966e5990/tox.ini#L76-L82
causing the error we see in the first part of the logs above:
juju.errors.JujuAPIError: application "mlflow-server" not found

the application is not found in this model, because it was deployed in a different model.

Thank you @NohaIhab for nailing down the root cause of this. We should thus make a sufficient improvement in our code (e.g. add a relevant comment in tox environment or configure it to use the same model name by default) in order to avoid future misunderstanding about when/how the tests work.


Dark Souls Remastered - Heavy Texture Flickering

Upon entering into the Blight town area of the game, textures start to flicker heavily all around the screen making the game unplayable.
Software information
Arch Linux, kernel 4.16.11
Dark Souls Remastered, Steam version.
System information

GPU: GeForce GTX 770
Driver: 396.24
Wine version: Wine Staging 3.9
DXVK version: 3b70e23e2c81e7ac7870e703523c82331a646c66

Apitrace file(s)

Put a link here

Log files

d3d11.log:
DarkSoulsRemastered_d3d11.log

dxgi.log:
DarkSoulsRemastered_dxgi.log

Here's the trace file (hope, I did it right) https://www.dropbox.com/s/7bhdhvvnp8nffxk/DarkSoulsRemastered.trace?dl=0

Thanks. I'm not seeing any texture flickering though, might be a driver-specific issue - can you take a screenshot what it looks like for you?

BTW, in d3d11.log  err:   D3D11DeviceContext::SetPredication: Stub and the Wiki says that Predication is not supported.
Could this be what's causing the glicthes?

The trace seems to work fine on radv and amdgpu-pro.
I tested the trace and it seems to be an nvidia-only issue.

@Progman-DT 621aed5fdbaf92764944be7b3a27cbb3df63ba94 should fix this, feel free to re-open this issue if the problem persists.
Basically the game is broken and tries to render something with an incorrect vertex buffer. The new commit doesn't change that, but it should behave the same as on Windows now. AMD seems to be doing this by default, which is why I wasn't able to reproduce the issue.

@doitsujin Unfortunately, this didn't fix it for me, at least with 396.24.0 drivers. Should I try with 396.24.02 beta drivers?

You should always be using the .02 update with DXVK since it contains a bunch of fixes.

Are you sure you compiled the latest version of master?
It's fixed in the trace, so I am not sure if you are actually running 621aed5.

Well, I downloaded the latest build from here https://haagch.frickel.club/files/dxvk/ from the folder r1176.621aed5, so it should be the needed build.
But, unfortunately, even with 396.24.02, it's still the same problem

Can you replay your own trace and see if it's broken there as well?
you can use wine apitrace.exe replay /path/to/DarkSoulsRemastered.trace

@varris1 Just replayed the trace, and it's still broken, textures are flickering like crazy :(

I double checked everything, the sizes match. Deleting the cache doesn't do anything either.

Did you try to launch the game without Lutris? Use your system's Wine installation and set WINEPREFIX by hand. Afaik Lutris ignored the in-prefix DXVK installation a while ago and used its own version. Not sure if this is still the issue.

As Varris said, this seems to be Kepler-specific, it seems to be fixed on all other GPU architectures. Which means that I won't be able to fix the problem unless someone with a Kepler GPU starts debugging it.

@rstrube
Doitsujin had to revert the fix because it broke Dishonored 2: https://github.com/doitsujin/dxvk/commit/217399926d1c44d8c2532de62579bf9b23fa9adc

@rstube the original fix was not part of DXVK 0.53.

@varris1 @doitsujin thanks for the clarifications.  It's too bad that the fix breaks other games.  Would the only solution at this point be to compile a local version of DXVK for dark souls remastered with the fix in place? Or do you see a long term solution where both games operate correctly?

@Progman-DT
It looks like Haagch's build server is broken. The DXVK dlls have the same md5sum since 24th of May, so you may not have received the fix after all.
Can you try those DLLs and see if they work?
dxvk-darksouls.tar.gz

@varris1 can confirm it works fine here.

@varris1 @doitsujin Yes, it's working fine now! Thank you all! I hope this fix will make it to the main branch in some form one day.

@rstrube officially publishing multiple different "versions" of dxvk that work with some games but not with others is never going to be an option, sorry.

@doitsujin I understand, that makes sense.
Question, based on your knowledge of Direct X and Vulkan, is there any way this particular issue could ever be fixed in DXVK directly, or would the issue really need to be fixed on the Nvidia driver side and/or game code side?
My guess is that it's the latter, and that the issue will most likely remain indefinitely, but I'm curious what the process is for handling problem games like this.

It certainly could be worked around in DXVK, but I can't really think of a workaround that closely emulates native D3D11 behaviour while not reducing performance considerably for all games.
I might actually re-implement the old workaround as a game-specific option, or at least something similar which has the same effect. But I'm not exactly happy with that kind of solution, especially since other games might have similar bugs.
The main issue here is that D3D11 has defined out-of-bounds access behaviour for constant buffer reads, whereas Vulkan just assumes that you stay within the bounds. My previous workaround implemented bound-checking using the constant buffer length specified in the shader, but you can actually read past that as long as you stay within the bound buffer range. Dishonored 2 relies on that and breaks as a result with that workaround enabled.

@doitsujin I find it really fascinating that D3D11 provides such strange behavior.  So if I'm reading this correctly, with vulkan you're not able to access a specific constant buffer (e.g. a shader buffer) in an out of bounds fashion.  In my simplistic understanding you have a buffer with a length of 100000 (byte array) with vulkan doing something like shader_buffer[100000] would not be allowed, the last element in the buffer you could access would be 99999.
But with Direct X 11, you can access the constant buffer outside it's bounds, provided your still within some max buffer range.  Furthermore, Direct X handles this specific out of bounds access on constant buffers in a specific documented way.  Still seems really strange to me, it's almost as if the API provides a work around or "fallback" for developers being sloppy.  Why not just instantiate the constant buffer larger to begin with?
Either way, really fascinating that you run into these types of idiosyncrasies.  I'm a developer myself (web development + C# mostly), but I get the impression that these sorts of APIs are on a whole different level.
Thanks again for all the great work you're doing!

@doitsujin Is it possible now to put this fix into the main branch and turn it on and off when needed with dxvk config files?

The fix unfortunately is not trivial and not really suited for a configuration option, since the two code paths would be very different.

I hate to be the bearer of bad news, but this bug is very much back in business in the latest CrossOver / DXVK builds on MacOS on Apple Silicon/M1. Could it have been reintroduced somehow with a patch? Bizarrely, for one of my recent playthroughs, I didn't experience it at all in my first run through those areas. But now both in that save file and in the rest of my DS1 saves, the issues appears in both Blighttown and parts of the Depths. I will soon try to build a new WINE bottle from scratch to see if that fixes it. Would greatly appreciate any help troubleshooting it, and I'll be happy to assist however I can with diagnostic info or logfiles etc. Thanks.

I hate to be the bearer of bad news, but this bug is very much back in business in the latest CrossOver / DXVK builds on MacOS on Apple Silicon/M1. Could it have been reintroduced somehow with a patch? Bizarrely, for one of my recent playthroughs, I didn't experience it at all in my first run through those areas. But now both in that save file and in the rest of my DS1 saves, the issues appears in both Blighttown and parts of the Depths. I will soon try to build a new WINE bottle from scratch to see if that fixes it. Would greatly appreciate any help troubleshooting it, and I'll be happy to assist however I can with diagnostic info or logfiles etc. Thanks.

and p.s. I am loath to use the custom build linked in the comment above mine, as it warns that using it could get one's Steam account banned.

and p.s. I am loath to use the custom build linked in the comment above mine, as it warns that using it could get one's Steam account banned.

MoltenVK doesn't support robustBufferAccess2. DXVK relies on that to fix this issue because D3D11 guarantees that out of bounds buffer reads return 0. So this requires a hack to workaround the issue. We don't support Mac OS so this should be done in the Mac OS fork of DXVK.

MoltenVK doesn't support robustBufferAccess2. DXVK relies on that to fix this issue because D3D11 guarantees that out of bounds buffer reads return 0. So this requires a hack to workaround the issue. We don't support Mac OS so this should be done in the Mac OS fork of DXVK.

Oh okay, that makes sense. I didn't see a suitable fork after a quick search on Github but I am all ears if you have any idea where I should direct my comments.
Just to make sure I understand (I also have Linux boxes) – is this issue in fact fixed on Linux in DXVK 1.0.3 and later?
Thanks for the reply!

Oh okay, that makes sense. I didn't see a suitable fork after a quick search on Github but I am all ears if you have any idea where I should direct my comments.
Just to make sure I understand (I also have Linux boxes) – is this issue in fact fixed on Linux in DXVK 1.0.3 and later?
Thanks for the reply!

Just to make sure I understand (I also have Linux boxes) – is this issue in fact fixed on Linux in DXVK 1.0.3 and later?

Yes. I even played DS Remastered 2 months ago on Proton and it worked perfectly.

Just to make sure I understand (I also have Linux boxes) – is this issue in fact fixed on Linux in DXVK 1.0.3 and later?

Yes. I even played DS Remastered 2 months ago on Proton and it worked perfectly.

I read some previous threads, folks were talking as its nvidia driver's issue. But its not. The flickering issue is still happening in Blightown area of the game, and my system is Macbook Air M1. So not a driver issue.

The Nvidia driver can be configured to return 0 for uniform buffer accesses that go out of bounds. Back in the day, this was not possible, hence why it was kind of a driver issue. On AMD that's the default behavior anyway.
So what I wrote earlier still holds true:

MoltenVK doesn't support robustBufferAccess2. DXVK relies on that to fix this issue because D3D11 guarantees that out of bounds buffer reads return 0. So this requires a hack to workaround the issue. We don't support Mac OS so this should be done in the Mac OS fork of DXVK.

Oh, thx for clarifying!

I have the same problem on a MacBook Pro with an M1 chip, running with CrossOver, how can I fix it?

You'd have to ask CodeWeavers. DXVK itself doesn't support macOS.

https://www.reddit.com/r/macgaming/comments/qt4e1b/you_can_run_the_latest_dxvk_with_crossover_on_mac/
Am I thinking in the right direction?

Yeah, @Gcenx's MoltenVK fork might be a better place to ask. If you're seeing problems with stock MoltenVK, I'd also suggest filing an issue there.

@cdavis5e not really I’ve removed all MoltenVK-DXVK packages now only providing stock packages.
In providing modified versions of DXVK that work with stock MoltenVK.

macos_dxvk_patched.tar.xz no longer found?

macos_dxvk_patched.tar.xz no longer found?

See the comment to Chip

@cdavis5e not really I’ve removed all MoltenVK-DXVK packages now only providing stock packages.
I’m providing modified versions of DXVK that work with stock MoltenVK.

As I understand it, I need to replace the libMoltenVK.dylib file in the /Applications/CrossOver.app/Contents/SharedSupport/CrossOver/lib64 folder and replace the DXVK files in the bottle at the location windows/system32

I was able to solve the problem!

https://mega.nz/file/EHhhWYYZ#cxOOM_bA9ILODaazs9swWjQRk0K6DVlUxiT9FCKjHd8 paste the files from the x64 folder into the system32 folder in the bottle

MoltenVK doesn't support robustBufferAccess2. DXVK relies on that to fix this issue because D3D11 guarantees that out of bounds buffer reads return 0. So this requires a hack to workaround the issue. We don't support Mac OS so this should be done in the Mac OS fork of DXVK.

@K0bin do you happen to have an updated version of this hack?

No, DXVK works around it by using SSBOs which are tightly bound checked. Metal doesn't differenciate between buffer types and doesn't have bounds checking so this doesn't work there.

It works, try it, I was able to fix this bug on my MacBook Pro M1

What did you do to fix it?

https://mega.nz/file/EHhhWYYZ#cxOOM_bA9ILODaazs9swWjQRk0K6DVlUxiT9FCKjHd8 paste the files from the x64 folder into the system32 folder in the bottle
I wrote about it above

But where does that "dxvk-dsr-0.96" build come from and what kinds of changes does it have over regular DXVK 0.96?

This is a modification that I found specifically to solve this problem

The most important thing is that after these steps everything works on M1

It's a build with 621aed5fdbaf92764944be7b3a27cbb3df63ba94 reverted. That does indeed fix Dark Souls Remastered but it's not a correct fix and breaks other games.

The specificity of Crossout is such that it will not affect other games, each game has its own bottle

The specificity of CrossOver is such that it will not affect other games, each game has its own bottle, the system can be customized for each game and application individually and this solution is great for Mac

That’s not really the point that K0bin was making, that note was lightly aimed towards anyone maintaining a macOS target fork to not revert this commit as it will break other games.

In any case, I hope I helped someone, as a last resort, you can keep a backup with a different version of the files and change it when you play other games


Description of Tools format within Documentation

System Info
v2.1.1
Information

[X] Docker
[ ] The CLI directly

Tasks

[X] An officially supported command
[ ] My own modifications

Reproduction
With respect to training/fine-tuning models that are compatible with tool use with TGI (via the openai endpoint):

It is unclear how "tools" are injected into the prompt that used for generation.

It is unclear how the model's responses is parsed by the server from tokens (or string of tokens) into the openai formatted response that includes tool calls.

I have reviewed the messages documentation/

I have tried to search within the server code to find out "tools" are handled by the server.

Would it be possible to provide links in documentation to each of these things.
Expected behavior

How tools are injected into the prompt.

It would be ideal to see code (or a code snippet) of how the prompt is formatted to include tools (if that is even the case).

How the tokens generated by the LLM are parsed into a response from the server.

What kind of regex matching or special token detection is the server using to parse the string from the LLM into tool calls and/or the model response.

Hi @RonanKMcGovern!
Yeah the documentation is unfortunately up to the standard we'd like to be. Apologies from out side.
I don't want to give false promises of having bandwidth to improve the documentation this week but hopefully I'll get to it as soon as possible.
In the meantime, this is the server code that's responsible for the tool
The Tool struct:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/lib.rs#L925
Which is part of the ChatRequest:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/lib.rs#L812
Which is what's deserialised in the v1/chat/completions endpoint:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/server.rs#L1009
Is this a good start on answering some of your questions?

Thanks Erik, I appreciate the response. That does help.
I've only spent a few minutes looking at this but I think I can see how a
chat template is used to serialise everything, and then there is extraction
logic to deserialise.
I don't see it yet, but I suppose there is a modified chat template that
handles tools that is being imported somewhere.
Understood it may take some time to have documentation ready. When you get
to it, it would be great if you can show some examples of a) calls to the
api, b) serialised prompts are used for generation, c) raw LLM responses,
d) de-serialised LLM responses, with the tool response extracted, e) the
full api response.
Many thanks
On Mon, Jul 15, 2024 at 11:25 AM Erik Kaunismäki @.***>
wrote:

Hi @RonanKMcGovern https://github.com/RonanKMcGovern!
Yeah the documentation is unfortunately up to the standard we'd like to
be. Apologies from out side.
I don't want to give false promises of having bandwidth to improve the
documentation this week but hopefully I'll get to it as soon as possible.
In the meantime, this is the server code that's responsible for the tool
The Tool struct:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/lib.rs#L925
Which is part of the ChatRequest:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/lib.rs#L812
Which is what's deserialised in the v1/chat/completions endpoint:
https://github.com/huggingface/text-generation-inference/blob/dbb23fbfa868ad8f961c60896e346fad3d2ab440/router/src/server.rs#L1009
Is this a good start on answering some of your questions?
—
Reply to this email directly, view it on GitHub
https://github.com/huggingface/text-generation-inference/issues/2210#issuecomment-2228171399,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASVG6CUM46YYFZFDCJJ4SVLZMOPP7AVCNFSM6AAAAABKTGHYNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEMRYGE3TCMZZHE
.
You are receiving this because you were mentioned.Message ID:
@.***>

Thank you for the feedback @RonanKMcGovern 🙌
I'll note these and try to combine with other similar feedback, and see what way we could package it nicely.
If you don't object I'll close this issue for now. Of course, feel free to reopen it if you want 👍

Sounds excellent
On Mon, Jul 22, 2024 at 9:37 AM Erik Kaunismäki @.***>
wrote:

Thank you for the feedback @RonanKMcGovern
https://github.com/RonanKMcGovern 🙌
I'll note these and try to combine with other similar feedback, and see
what way we could package it nicely.
If you don't object I'll close this issue for now. Of course, feel free to
reopen it if you want 👍
—
Reply to this email directly, view it on GitHub
https://github.com/huggingface/text-generation-inference/issues/2210#issuecomment-2242399669,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/ASVG6CUJRTPMVTCQBNZ7G3DZNTAD7AVCNFSM6AAAAABKTGHYNWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDENBSGM4TSNRWHE
.
You are receiving this because you were mentioned.Message ID:
@.***>


Use common HTTP server creation logic

The removes the gazillion ways we had to create an HttpServer instance. All slightly different, all lacking an option here and there. Now all use the same logic.
Remaining tasks:

[x] In server, create a single, combined API endpoint
[x] Change Helm charts to use new configuration, and create a macro there too
[x] Allow serving the frontend too

@lulf next version, this time with the composite API, updated helm charts, and an option to serve the UI folder too

/test

/test

/test


Closes #942

Fixes some issues related to update:

Closes #942.

Please do this in the Postgres branch instead.


Add point in time api

Description
Add  the Point in Time API.
https://opensearch.org/docs/latest/search-plugins/point-in-time-api/
Issues Resolved
Closes #251
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.
For more information on following Developer Certificate of Origin and signing off your commits, please check here.

@dblock does this lib aim to be a low level lib or should it be more user friendly?
I am asking because I added some custom Response types for Point In Time requests and also avoid the user to build the delete body.

@dblock does this lib aim to be a low level lib or should it be more user friendly? I am asking because I added some custom Response types for Point In Time requests and also avoid the user to build the delete body.

I definitely think we want to minimize the amount of work a user has to do. So as much user friendly as possible, but also letting users go deep into low level constructs.


[e2e]: container-based push main default slsa3

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/11099176926
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Mon Sep 30 04:48:30 UTC 2024

Repo: https://github.com/slsa-framework/example-package/tree/main
Run: https://github.com/slsa-framework/example-package/actions/runs/11118423911
Workflow file: https://github.com/slsa-framework/example-package/tree/main/.github/workflows/e2e.container-based.push.main.default.slsa3.yml
Workflow runs: https://github.com/slsa-framework/example-package/actions/workflows/e2e.container-based.push.main.default.slsa3.yml
Trigger: push
Branch: main
Date: Tue Oct  1 04:29:01 UTC 2024
Tests are passing now. Closing this issue.


⚠ Samsung has degraded performance

In ff9a82c, Samsung (https://samsung.com) experienced degraded performance:

HTTP code: 200
Response time: 1963 ms

Resolved: Samsung performance has improved in 83230b1.


Do you object (disagree) with the appointment of a guardian in this case? Your explanation | The affidavit auto-populates certain text which is not specified to the writer at this point in the form. Ie. “I, (parent name), hereby affirm under the pains and penalties of perjury as follows: I object to the appointment of a guardian for (child name)”Since the explanation box does not specify that this will already be included, I typed without realizing there would be this preamble.

This seems very unlikely to be something anyone other than a lawyer would expect to have to type manually.


Add _ver variables to module files?

Would it make sense to add {name}_ver variables to our modulefiles? I don't remember if we've discussed this previously. These will be useful for our NCO work as far as testing different spack-stack versions without having to do a bunch of rewriting of the model module files. I think it would also be useful to developers wanting to test the latest spack-stack, because again they won't need to modify anything (the UWM module files, for example, already look for these environment variables before using the specified defaults). I'm happy to just make these changes for the Acorn config, but if no one objects it might make sense to update the common lmod/tcl configs.

What would these variables contain? The version of the package?

Correct. I'll update the description to clarify.

But that version is already available as part of the module? module load g2/3.5.1 ?

Right, d'oh. I guess it wouldn't help unless it was in the metamodule. I'll ponder it more and update the issue.

I remember that a while ago I came across a modulefile (tcl or lmod, can't remember) that determined the version internally from the name of the module.

Circling back to this later


Can't build Android

I build it like this: build.cmd  --feature-sets android.
The front can work normally,but then there is a error:NotSupportedException: Desktop MSBuild is not available.
The tip says that the error is in build/nuke/Project.cs After I tried to delete that paragraph, the error disappeared.
After that, I encountered a new error: processexception: process' dotnet.exe ' exited with code 1.

D:\ Silk.NET -2.0.0\.tmp\dotnet-win\ dotnet.exe clean D:\ Silk.NET -2.0.0\build\sln\t3 ncvyff.azy.gen .sln --configuration Debug
@ D:\ Silk.NET -2.0.0
at Nuke.Common.Tooling . ProcessExtensions.AssertZeroExitCode (IProcess process
at Nuke.Common.Tools . DotNet.DotNetTasks.DotNetClean (DotNetCleanSettings toolSettings)
at Nuke.Common.Tools . DotNet.DotNetTasks.DotNetClean (Configure1 configurator) at Build.<get_ Clean>b__ 30_ 1() in D:\ Silk.NET -2.0.0\build\nuke\ Build.cs :line 158 at Nuke.Common.Execution .TargetDefinition.<>c__ DisplayClass61_ 01.b__ 0()
at Nuke.Common.Execution .BuildExecutor.<>c.b__ 4_ 0(Action x)
at Nuke.Common.Utilities . Collections.EnumerableExtensions.ForEach [T](IEnumerable1 enumerable, Action1 action)
at Nuke.Common.Execution . BuildExecutor.Execute (NukeBuild build, ExecutableTarget target, IReadOnlyCollection`1 previouslyExecutedTargets, Boolean failureMode)
Repeating warnings and errors:
ProcessException: Process ' dotnet.exe ' exited with code 1.
D:\ Silk.NET -2.0.0\.tmp\dotnet-win\ dotnet.exe clean D:\ Silk.NET -2.0.0\build\sln\t3 ncvyff.azy.gen .sln --configuration Debug
@ D:\ Silk.NET -2.0.0
I am Chinese, so some places may not be good.

error:NotSupportedException: Desktop MSBuild is not available.
This to me indicates you don't use windows and/or don't have Visual Studio installed.
For the time being we need to use xamarin to run on android, so tools that are otherwise not needed are required for android.

@Perksey may be able to say more

Okay

If the build is successful, what will I get?

Desktop MSBuild (i.e. the MSBuild version that ships with Visual Studio 2019) is required to build the Android and iOS feature sets.
This is because Xamarin is not cross platform yet. In addition, you'll need the Android C# workloads installed for Visual Studio 2019
It's recommended you run the build scripts either from a developer command line or add MSBuild to your PATH and run it normally.

Closing as question. If you'd like more help getting Silk.NET to build when targeting Android, please open a GitHub Discussion in the Discussions tab or join our Discord server.


Add Mashable Extractor

Before submitting a pull request make sure you have:

[x] At least skimmed through contributing guidelines including yt-dlp coding conventions
[x] Searched the bugtracker for similar pull requests
[x] Checked the code with flake8 and ran relevant tests

In order to be accepted and merged into yt-dlp each piece of code must be in public domain or released under Unlicense. Check one of the following options:

[x] I am the original author of this code and I am willing to release it under Unlicense
[ ] I am not the original author of this code but it is in public domain or released under Unlicense (provide reliable evidence)

What is the purpose of your pull request?

[ ] Fix or improvement to an extractor (Make sure to add/update tests)
[x] New extractor (Piracy websites will not be accepted)
[ ] Core bug fix/improvement
[ ] New feature (It is strongly recommended to open an issue first)

Description of your pull request and other information
This pull request addresses #3420 issue/feature request for mashable.com support. This is my first contribution to the project, so I realize there is likely feedback and changes that need to be made before merging, but am motivated and happy to make any required changes.
One aspect of the extractor I was a bit unsure if I was handling correctly was the "formats" list of dictionaries. I used malltv.py as reference for this, but would greatly appreciate an extra set of eyes to see if this was done correctly.

[x] At least skimmed through contributing guidelines including [yt-dlp coding conventions]

Read again!

As per the discussion in #3420, the generic extractor is already able to extract the video and other information from the webpage of Mashable.
I've performed the test with version 2024.08.06:
[debug] Command-line config: ['--no-simulate', '--list-formats', '--list-thumbnails', '-vU', 'https://mashable.com/video/why-life-on-venus-is-better-than-mars', 'https://mashable.com/video/who-took-the-first-selfie-ever']
[debug] Encodings: locale UTF-8, fs utf-8, pref UTF-8, out utf-8, error utf-8, screen utf-8
[debug] yt-dlp version<EMAIL_ADDRESS>from yt-dlp/yt-dlp [4d9231208] (pip)
[debug] Python 3.12.3 (CPython x86_64 64bit) - Linux-6.8.0-41-generic-x86_64-with-glibc2.39 (OpenSSL 3.0.13 30 Jan 2024, glibc 2.39)
[debug] exe versions: none
[debug] Optional libraries: Cryptodome-3.20.0, brotli-1.1.0, certifi-2024.08.30, mutagen-1.47.0, requests-2.32.3, sqlite3-3.45.1, urllib3-2.2.3, websockets-13.1
[debug] Proxy map: {}
[debug] Request Handlers: urllib, requests, websockets
[debug] Loaded 1830 extractors
[debug] Fetching release info: https://api.github.com/repos/yt-dlp/yt-dlp/releases/latest
Latest version<EMAIL_ADDRESS>from yt-dlp/yt-dlp
yt-dlp is up to date<EMAIL_ADDRESS>from yt-dlp/yt-dlp)
[generic] Extracting URL: https://mashable.com/video/why-life-on-venus-is-better-than-mars
[generic] why-life-on-venus-is-better-than-mars: Downloading webpage
WARNING: [generic] Falling back on generic information extractor
[generic] why-life-on-venus-is-better-than-mars: Extracting information
[debug] Looking for embeds
[debug] Identified a JSON LD
[generic] Extracting URL: https://zmgvideos.mashable.com/cms/2022/2/50319e30-a4ce-084d/mp4/1080.mp4#__youtubedl_smuggle=%7B%22force_videoid%22%3A+%22why-life-on-venus-is-better-than-mars%22%2C+%22to_generic%22%3A+true%2C+%22referer%22%3A+%22https%3A%2F%2Fmashable.com%2Fvideo%2Fwhy-life-on-venus-is-better-than-mars%22%7D
[generic] why-life-on-venus-is-better-than-mars: Downloading webpage
[debug] Identified a direct video link
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available thumbnails for why-life-on-venus-is-better-than-mars:
ID Width   Height  URL
0  unknown unknown https://zmgvideos.mashable.com/cms/2022/2/50319e30-a4ce-084d/thumb/00001.jpg
[info] Available formats for why-life-on-venus-is-better-than-mars:
ID  EXT RESOLUTION │ PROTO │ VCODEC  ACODEC
────────────────────────────────────────────
mp4 mp4 unknown    │ https │ unknown unknown
[debug] Default format spec: best/bestvideo+bestaudio
[info] why-life-on-venus-is-better-than-mars: Downloading 1 format(s): mp4
[debug] Invoking http downloader on "https://zmgvideos.mashable.com/cms/2022/2/50319e30-a4ce-084d/mp4/1080.mp4"
[download] The ultimate case for living on Venus [why-life-on-venus-is-better-than-mars].mp4 has already been downloaded
[download] 100% of  156.87MiB
[generic] Extracting URL: https://mashable.com/video/who-took-the-first-selfie-ever
[generic] who-took-the-first-selfie-ever: Downloading webpage
WARNING: [generic] Falling back on generic information extractor
[generic] who-took-the-first-selfie-ever: Extracting information
[debug] Looking for embeds
[debug] Identified a JSON LD
[generic] Extracting URL: https://zmgvideos.mashable.com/cms/2022/2/5cee6e38-f9c8-5ceb/mp4/1080.mp4#__youtubedl_smuggle=%7B%22force_videoid%22%3A+%22who-took-the-first-selfie-ever%22%2C+%22to_generic%22%3A+true%2C+%22referer%22%3A+%22https%3A%2F%2Fmashable.com%2Fvideo%2Fwho-took-the-first-selfie-ever%22%7D
[generic] who-took-the-first-selfie-ever: Downloading webpage
[debug] Identified a direct video link
[debug] Formats sorted by: hasvid, ie_pref, lang, quality, res, fps, hdr:12(7), vcodec:vp9.2(10), channels, acodec, size, br, asr, proto, vext, aext, hasaud, source, id
[info] Available thumbnails for who-took-the-first-selfie-ever:
ID Width   Height  URL
0  unknown unknown https://zmgvideos.mashable.com/cms/2022/2/5cee6e38-f9c8-5ceb/uploaded_thumbnail.png
[info] Available formats for who-took-the-first-selfie-ever:
ID  EXT RESOLUTION │ PROTO │ VCODEC  ACODEC
────────────────────────────────────────────
mp4 mp4 unknown    │ https │ unknown unknown
[debug] Default format spec: best/bestvideo+bestaudio
[info] who-took-the-first-selfie-ever: Downloading 1 format(s): mp4
[debug] Invoking http downloader on "https://zmgvideos.mashable.com/cms/2022/2/5cee6e38-f9c8-5ceb/mp4/1080.mp4"
[download] Who took the first selfie ever？ [who-took-the-first-selfie-ever].mp4 has already been downloaded
[download] 100% of   39.54MiB

.


Expose WASM bindings for key backup

A re-do of https://github.com/matrix-org/matrix-rust-sdk/pull/2196, against the new repository, with a whole bunch of updates.
Closes: https://github.com/vector-im/crypto-internal/issues/100

@AndrewFerr thanks for the review! I think I've either accepted your suggestions or replied, so please could you take another look?


Table doesn't load for LFI dataset

Describe the bug
Table view doesn't load for LFI data cube but gives unexpected error as of now.
To Reproduce
Steps to reproduce the behavior:

Go to https://test.visualize.admin.ch/browse/dataset/https%3A%2F%2Fenvironment.ld.admin.ch%2Ffoen%2Fnfi%2F49-20-None-None%2Fcube%2F1?previous={"includeDrafts"%3Atrue%2C"order"%3A"SCORE"%2C"search"%3A"lfi"}
Click on Start a visualization
Select chart type 'Table'
Click 'next'
see error 'No data available for current filter selection - Please try with another combination of filters.'

Expected behavior
The default table view has all categories enabled. (colum 1-7 every filter enabled)
Thus the data shall be shown in a table view as it was the case last week.
Screenshots

Environment (please complete the following information):

Visualize environment and version: TEST v3.4.1 (040ed03)

Additional context
Oddly enough the table view starts to work after in column 2 (stage of stand development) clicking on 'Select none' and after selecting one of those filters again...
cc @sandrobischof

maybe related to #386

I am having timeouts on the observations query. We did not make change to it, so I am asking Zazuko if the timeouts can be solved, maybe this is something that we'll only see on the int environment. @l00mi

It is just at the limit of a size which can be handled. (This query does with the DISTINCT look at the whole cube, only to show the first 10 lines.) You could add the optimization as once communicated https://github.com/zazuko/rdf-cube-view-query/pull/69

I tried without distinct directly in lindas query editor and still had a timeout.

Its pretty quick here: http://cube-viewer.zazuko.com/?cube=https%3A%2F%2Fenvironment.ld.admin.ch%2Ffoen%2Fnfi%2F49-19-None-None%2Fcube%2F1&endpointUrl=https%3A%2F%2Fint.lindas.admin.ch%2Fquery&user=&password=&sourceGraph=

I guess it's quick because the labels are not considered in the cube viewer and related to the optional that are added to the query to pull the labels.

The data now loads with no problem (with no changes on our part), it might have been a fluck from the database, I am closing right now, we'll reopen if necessary.


compile: duplicate case error reports position of constant definition rather than position of previous case

What version of Go are you using (go version)?

$ go version
go version go1.12.7 linux/amd64

Does this issue reproduce with the latest release?
It reproduces on the playground.
What operating system and processor architecture are you using (go env)?
go env Output
$ go env
GOARCH="amd64"
GOBIN=""
GOCACHE="/home/jadenw/.cache/go-build"
GOEXE=""
GOFLAGS=""
GOHOSTARCH="amd64"
GOHOSTOS="linux"
GOOS="linux"
GOPATH="/home/jadenw/GOPATH"
GOPROXY=""
GORACE=""
GOROOT="/usr/lib/go"
GOTMPDIR=""
GOTOOLDIR="/usr/lib/go/pkg/tool/linux_amd64"
GCCGO="gccgo"
CC="gcc"
CXX="g++"
CGO_ENABLED="1"
GOMOD=""
CGO_CFLAGS="-g -O2"
CGO_CPPFLAGS=""
CGO_CXXFLAGS="-g -O2"
CGO_FFLAGS="-g -O2"
CGO_LDFLAGS="-g -O2"
PKG_CONFIG="pkg-config"
GOGCCFLAGS="-fPIC -m64 -pthread -fmessage-length=0 -fdebug-prefix-map=/tmp/go-build531868898=/tmp/go-build -gno-record-gcc-switches"

What did you do?
package main

import (
	"fmt"
)

const (
	a = iota
	b
	c
	d
)

func main() {
	var v int
	v = a
	switch v {
	case a, b:
		fmt.Println("ab")
	case b, c:
		fmt.Println("bc")
	case d:
		fmt.Println("d")
	default:
		fmt.Println("other")
	}
}

https://play.golang.org/p/Y241bHQreUg
Note: b is used twice in the switch statement
What did you expect to see?
./prog.go:20:2: duplicate case b (value 1) in switch
	previous case at ./prog.go:18:10

where ./prog.go:18:10 is the position of b in the first case statement
What did you see instead?
./prog.go:20:2: duplicate case b (value 1) in switch
	previous case at ./prog.go:9:2

where ./prog.go:9:2 is the position of the declaration of the constant b

Nice catch!
I'd guess that the intention is to catch different untyped consts with the same value, so I would rather see an addition to the expected error message:
./prog.go:20:2: duplicate case b (value 1) in switch
	previous case as b at ./prog.go:18:10

Thank you for reporting this bug @jadr2ddude and thank you for chiming in @leitzler!
This bug has existed since at least Go1.9.
The issue here is that we rely on the constant expressions being declared inline during switches e.g.
switch {
case 1, 2:

case 2:
}

and reported the position but as you've shown, we've got the usual constant variables and the previous logic used their declaration position.
I got some time this afternoon, I've mailed https://golang.org/cl/188899 and it'll be fixed for Go1.14.


Access point: Set correct country code

/etc/hostapd/hostapd.conf should contain a correct country code. For Switzerland it would be country_code=CH.

Fixed in 23127e06cb9e1fa7aee973b19b327d400bddd88e


Warn during build process

I get this warn during the build process
WARN  Export "serverSupabaseClient" of module "node_modules/.pnpm/@nuxtjs+supabase<EMAIL_ADDRESS>was reexported through module "node_modules/.pnpm/@nuxtjs+supabase<EMAIL_ADDRESS>while both modules are dependencies of each other and will end up in different chunks by current Rollup settings. This scenario is not well supported at the moment as it will produce a circular dependency between chunks and will likely lead to broken execution order. Either change the import in "server/api/openAI/send.post.ts" to point directly to the exporting module or reconfigure "output.manualChunks" to ensure these modules end up in the same chunk.
Does it matter any sense?

Getting same warning, but no error regarding it catch yet.

We also get this warning, apparently for each usage in server routes and apis
@nuxtjs/supabase 1.3.2

Also getting these warnings @nuxtjs/supabase: 1.3.5

Also seeing this warning in build logs. No obvious impact in production at this time.

Does this warning also occur in v1.4.1? If it does, could you provide a reproduction repo or StackBlitz?


[docs] Restructure

Preview: https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/getting-started/first-app/

Closes #1981

Closes #2052

This PR attempts to:

restructure the docs into the sections mentioned in #2052
change content in most existing pages
add many new pages
change all of the existing media to adhere to a 1440x796 DPR 2.0 resolution
add an option to view images in full size.
Remove unused media files
Move the landing page content into the data folder

Deviations from the structure in #2052 have been made in two places:

"Deploy to Render" has been placed in Tutorials
A section on "Display mode" has been added to Concepts

The image open interaction on https://www.lennysnewsletter.com/p/how-figma-builds-product feels quite nice, with the complementary hover icon on the corner:

I can't preview / zoom into images in the preview
There seems to be no footer at the bottom of the docs pages, or even any padding at all? We used to have a footer there.

This should finally be resolved with the current version of the deploy preview

Maybe our tutorials section will be mixing up too many unrelated topics. Could we somehow have a Deployment section somewhere with subsections on different services we can deploy to?

We could list each Tutorial page in the main "Deployment" page, which is this one https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/deployment/ ?

Not sure what we agreed on about "display mode" - maybe it could be under "Embedding a Toolpad page?"

I was going by the thumb rule that we create a page in the Concepts section for anything that has its own configuration, while the guides are to explain how to use existing configurations to accomplish specific tasks. Which is why I thought it made sense to have a "display mode" page which explains both the modes, as well as a guide that explains how to use the standalone mode to accomplish iframing a Toolpad page.

This should finally be resolved with the current version of the deploy preview

Yep, seems great now. I like the way the zooming works, simple and straightforward, of course it could have more features like the example from Olivier but I feel like this works for now.

We could list each Tutorial page in the main "Deployment" page, which is this one https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/deployment/ ?

Yeah, i guess we should have a list of links from that deployment page to the tutorial for each service.

I was going by the thumb rule that we create a page in the Concepts section for anything that has its own configuration

That's right, the display mode can also be seen as a broader concept, and eventually we might have more use cases... On second though I think it works to have it under Concepts.

Looking good, I noticed a couple more things:

We can improve this later but maybe we could find a way to make the previews even bigger as long as it's still easy to go back to the normal view
The video here is really blurry and small https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/display-mode/. And the preview is even smaller than the outside the preview.

Looking good, I noticed a couple more things:

The video here is really blurry and small https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/display-mode/. And the preview is even smaller than the outside the preview.

Good catch on the video, I'll fix this.

We can improve this later but maybe we could find a way to make the previews even bigger as long as it's still easy to go back to the normal view (no need to do it now though imo, not even sure we should do it, just a thought)

I think we can do this now, I agree that the full-size images can be bigger. I can do this along with the dedicated zoom button appearing on hover that Olivier suggested.

Yeah, i guess we should have a list of links from that deployment page to the tutorial for each service.

https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/deployment/ does it work to have the link to the Render tutorial as an information card at the end for now, or should it be a different section?

Yeah, i guess we should have a list of links from that deployment page to the tutorial for each service.

https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/deployment/ does it work to have the link to the Render tutorial as an information card at the end for now, or should it be a different section?

Oh I see, it might work for now, but I think it would be better to have a list of items where each item would have the name of the service and then the link to the respective tutorial.
If the Render tutorial includes more general information that doesn't just apply to deploying to Render, then maybe that information should be in this page instead.

https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/concepts/deployment/ does it work to have the link to the Render tutorial as an information card at the end for now, or should it be a different section?

Oh I see, it might work for now, but I think it would be better to have a list of items where each item would have the name of the service and then the link to the respective tutorial. If the Render tutorial includes more general information that doesn't just apply to deploying to Render, then maybe that information should be in this page instead.

Agree, I'll modify the page

Oh I see, it might work for now, but I think it would be better to have a list of items where each item would have the name of the service and then the link to the respective tutorial. If the Render tutorial includes more general information that doesn't just apply to deploying to Render, then maybe that information should be in this page instead.

A list of this sort for now seems okay to me:

A list of this sort for now seems okay to me:

Looks good!

https://deploy-preview-2082--mui-toolpad-docs.netlify.app/toolpad/how-to-guides/customize-datagrid/

You're right, I'll do another pass on all the images to fix the aspect ratio/blurry GIF issues

Shall we center the images in the page?

I've centred the uncentered images and replaced all blurred GIFs


Add diagnostic checks in LVT  ISMN soil moisture reader when soil profile interpolation provides zero weights

This code was updated: lvt/interp/compute_vinterp_weights.F90
Does that mean that previous analysis with other soil moisture datasets (SCAN, etc.) are affected as well?
Is the surface soil moisture analysis affected, or just levels below the surface?

I do not expect any changes to the interpolation weights except it screens out zero weights that are output.
-S
=========================================
Sujay Kumar, Ph.D.
Research Physical Scientist
Hydrological Sciences Laboratory
Code 617, Bldg 33, Rm G219
Ph:<PHONE_NUMBER>
Sujay.V.Kumar<EMAIL_ADDRESS>http://neptune.gsfc.nasa.gov/hsb/personnel/index.php?id=170
From: David Mocko<EMAIL_ADDRESS>Reply-To: NASA-LIS/LISF<EMAIL_ADDRESS>Date: Thursday, April 4, 2019 at 12:42 PM
To: NASA-LIS/LISF<EMAIL_ADDRESS>Cc: "Kumar, Sujay V (GSFC-6170)"<EMAIL_ADDRESS>State change<EMAIL_ADDRESS>Subject: Re: [NASA-LIS/LISF] Add diagnostic checks in LVT ISMN soil moisture reader when soil profile interpolation provides zero weights (#95)
This code was updated: lvt/interp/compute_vinterp_weights.F90
Does that mean that previous analysis with other soil moisture datasets (SCAN, etc.) are affected as well?
Is the surface soil moisture analysis affected, or just levels below the surface?
—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHubhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_NASA-2DLIS_LISF_issues_95-23issuecomment-2D479974193&d=DwMCaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=F_5OVaHH7LvKtHALXneUaNCq8AEGjlqQaOsr45F7lQs&m=htNGu_mcvKvmvwXfdR1A_Bj9Hn1yDZR8g4BPuhefVTA&s=XLPfZitLMxa4S2OJuIHms6Yux7eGHrJVcRhyp5dql8Y&e=, or mute the threadhttps://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_notifications_unsubscribe-2Dauth_AMWro11rCMJ1yEe5eO1PXXkJEF0cWKrpks5vditWgaJpZM4cdOJV&d=DwMCaQ&c=ApwzowJNAKKw3xye91w7BE1XMRKi2LN9kiMk5Csz9Zk&r=F_5OVaHH7LvKtHALXneUaNCq8AEGjlqQaOsr45F7lQs&m=htNGu_mcvKvmvwXfdR1A_Bj9Hn1yDZR8g4BPuhefVTA&s=LTmHGvEHC_FicM-yZySekesQdzkIF-k6UIoysN7Mnnw&e=.


⚠ St. Lawrence Global Observatory CKAN Sitemap has degraded performance

In a4d91cd, St. Lawrence Global Observatory CKAN Sitemap (https://catalogue.ogsl.ca/sitemap/sitemap-1.xml) experienced degraded performance:

HTTP code: 200
Response time: 13113 ms

Resolved: St. Lawrence Global Observatory CKAN Sitemap performance has improved in 4bebd26 after 19 minutes.


5.0 pie下 tooltip 的textStyle.color 设置无效

Version
5.0.0
Steps to reproduce
5.0 pie下 tooltip 的textStyle.color 设置无效，官方网站中的试一试也无效。
Chrome 86.0.4240.111
OS: deepin 20.1Beta
What is expected?
What is expected?
What is actually happening?
What is actually happening?

Yes, I had this problem too. I changed the font color, but it didn't work

Thanks for report, I'will take a look


Allow preservation of null fields when using projections

Using OrientDB-community 1.7.9, fieldB gets dropped in the second query below.  It would be useful to have an optional keyword that instructs Orient to include/retain null fields when using projections (or any applicable operation).  This capability should also be exposed via the Java API.
See also this Group topic.
select * from SomeObject where @rid=#13:0
----+-----+---------------------
#   |@RID |fieldA |fieldB|fieldC
----+-----+---------------------
0   |#13:0|"foo"  |null  |#15:19
----+-----+---------------------

select *, @rid as id from SomeObject where @rid=#13:0
----+-----+-------------------
#   |@RID |fieldA|fieldC|id
----+-----+-------------------
0   |#13:0|"foo" |#15:19|#13:0
----+-----+-------------------

Just want to confirm that it happens on any earlier version as well. It is very annoying, but It seems to be a default behavior.

This is definitely a bug. I'm working on it.

Ivca, it seems this issue was supposedly fixed, but I'm encountering the same issue now using version:  2.0.9.  When the first record contains null fields, those fields are missing even if later records contain values in these fields.  Changing only the sort order so first record contains no null fields, all fields are returned in result set.


Scheduled claim setup

Hi,
this is not really an issue, but using the env file I tried with different settings to try to set crunch so that it only does one payout every 12h. But I am not succeeding. What is the setting to do to handle one payout every 12h or one every 24h?
Many thanks for your work

Hey, you can replace the mode operandi to daily rather than era. Replace the word era to daily, it will trigger payouts every 24h since the time it starts. If you want every 12h you have to use the mode once and than set-up a cronjob to launch crunch every 12h.
Example of your last service file with daily mode activated:
ExecStart=/home/myusername/crunch-bot/crunch --config-path /home/myusername/crunch-bot/.env rewards daily --seed-path /home/myusername/crunch-bot/.private.seed --disable-matrix


Add a license

Thanks for sharing this on Github :)
Can you add a license to this repo? It looks like some of the code referenced is MIT License so that seems like a good choice.

Done, thank you for pointing this out :)


feat: allow skipping nvidia gpu driver install

What type of PR is this?

What this PR does / why we need it:
Which issue(s) this PR fixes:

Fixes #
Requirements:

[ ] uses conventional commit messages

[ ] includes documentation
[ ] adds unit tests
[ ] tested upgrade from previous version

Special notes for your reviewer:
Release note:
none

nice. should try to run nvidia-smi and assert it fails.
+ echo Fri Apr 28 19:51:41 UTC 2023,abtestsbhw000000, 'Start configuring GPU drivers'
Fri Apr 28 19:51:41 UTC 2023,abtestsbhw000000, Start configuring GPU drivers
+ [[ true = true ]]
+ [[ true != \t\r\u\e ]]
++ date
++ hostname
+ echo Fri Apr 28 19:51:41 UTC 2023,abtestsbhw000000, 'End configuring GPU drivers'
Fri Apr 28 19:51:41 UTC 2023,abtestsbhw000000, End configuring GPU drivers

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

15 of 19 (78.95%)  changed or added relevant lines in 1 file are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 61.884%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

pkg/agent/baker.go
15
19
78.95%

Totals

Change from base Build<PHONE_NUMBER>:
0%

Covered Lines:
2536

Relevant Lines:
4098

💛  - Coveralls


Is Azure Cloud Shell actually supported?

The doc says Azure Cloud Shell can be used but this does not look compatible with the requirement to install Helm:

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: df16df9a-a855-2512-5e26-baec15e3be88
Version Independent ID: c77f255b-57c9-7e2d-2b10-98a8fe538376
Content: Quickstart: Connect an existing Kubernetes cluster to Azure Arc - Azure Arc
Content Source: articles/azure-arc/kubernetes/quickstart-connect-cluster.md
Service: azure-arc
Sub-service: azure-arc-kubernetes
GitHub Login: @MGoedtel
Microsoft Alias: magoedte

@mmaitre314 14 Thanks for the question! We are investigating and will update you shortly.

Hi @mmaitre314 - first off, I apologize for the extremely long delay in responding. I believe this topic has been updated to address your concern, so I'll close this issue now. If you still have questions or if anything isn't clear, please let us know. Again, I'm sorry about the long time to respond and thank you for taking the time to share your feedback with us.
#please-close


No such property: TinkerGraph for class: Script2

Hi,
I followed steps from 'Run Gremlin on Gremlin Server in EC2 using CloudFormation templates'.
Stack got created after considering : https://github.com/awslabs/dynamodb-janusgraph-storage-backend/issues/244
But there is an issue with gremlin remote console.
Please refer the screenshot attached.
Thank You.

Explanation of https://github.com/awslabs/dynamodb-janusgraph-storage-backend/issues/250  solved this issue.
I used to execute graph = TinkerGraph.open()
Output: No such property: TinkerGraph for class: Script2
After reading https://github.com/awslabs/dynamodb-janusgraph-storage-backend/issues/250, I executed graph = JanusGraphFactory.open('/usr/local/packages/dynamodb-janusgraph-storage-backend-1.1.1/conf/gremlin-server/dynamodb.properties')
Output : ==>standardjanusgraph[com.amazon.janusgraph.diskstorage.dynamodb.DynamoDBStoreManager:[<IP_ADDRESS>]]


PyWhatKit creating issue with Tkinter

Describe the bug
I am making a virtual assistant and using PyWhatKit for playing youtube videos. I am also usinng Tkinter for GUI interaction with my assistant. When I import my GUI and PyWhatKit modules, the the GUI window reduces in size (something like 30% reduction in total size). I have checker multiple times by commenting out each moude one by one and its 'import pywhatkit' which is causing problem. I am also using threading to run GUI and local server.
My GUI is in server. When server is opened seperatly and the client is connected after wards there is no issue, but when trying to open two scripts (GUI-server and main assistant script) by importing them togeather in third script, the problem presents itself.
To Reproduce
I am unable to reproduce it in simple way.
This is expected outcome----

This is what happens after PyWhatKit imports----

Desktop (please complete the following information):

OS: [windows10]
Browser [chrome]
Version [88.0.4324.150]

Hey @AmulyaParitosh , It would be easier to resolve the issue if you can please provide more information on this, like what other libraries are you using, python version etc.

I am using many libraries-
socket
threading
tkinter
json
pydictionary
speech_recodnition
pynewsapi
datetime
wikipedia
webbrowser
pyjokes
wolframalpha
random
pickle
numpy
nltk
tensorflow.keras.modles
pyttsx3
requests
and PyWhatKit
these are all that i am using

I think the file chr_to_handwriting.py is messing with the screen size because of the globally declared height and width variable's in it. Try to debug your code by setting a breakpoint at the line where PyWhatKit is loaded.

No luck!
Same thing happned.  What is chr_to_handwriting.py ?

It stands for Character to Handwriting and allows you to get written text images of characters that you want. See the README.md for reference. If you don't want all the functions of this library then just copy the function code you want and paste it in your own script to use it from. Till then I'll take a look into what's causing this.

I looked into chr_to_handwriting.py bt was unable to understand what to do and what functions I specifically.
Thanku for looking into it.
Hopefully @Ankit404butfound can help me.

I think it has to do with environmental variables, although I am not using any environmental variable but I am very sure that some inner packages are changing it. You need to verify which variable is changing and then you could redefine the variable after importing the package.
Something like this
import os
import pywhatkit

os.environ["Var-Name"] = "Expected-var-value"

I checked the environment variables using print(os.environ) printing before importing PyWhatKit then after importing PyWhatKit and compaired but found no difference b/w both.

I use the required function from mainfunctions.py  in PyWhatKit and now it's working flawlessly. Thanku

Hello, I'm some wheat new with Python and have the same issue described above, I'm unable to make that my GUI doesn't change the layout even after using just the code for the "sendwhatmsg_instantly" function in my own script, will appreciate if you can provide some guidance. Thank you.

Hey @lcampos777 , If you are directly using the code of that function you will have these lines in it,
width, height = pg.size()
pg.click(width / 2, height / 2)

Remove these and try again

@aaryanrr Thanks for the prompt response, already tried what you mentioned (did not remove the lines, instead just commented both) but unfortunately the issue remains. I'm adding a screenshot of how the code looks like to see if maybe by looking at it you can identify if I'm doing something wrong. Again, thanks for looking into this

Wanted to mention that for the functions showing in the above screenshot to function I had to do some imports (see below screenshot), after testing one by one the line import pyautogui as pg seems to be the one causing that the layout in the GUI changes.

Can you try to import only the required functions from pyautogui like
from pyautogui import press, hotkey

and then modify the code accordingly.

Already try but no luck, this is how the code will look like after doing what you suggested, however this still changes the GUI

Just to give you an idea, this is how the GUI changes if I import anything from "pyautogui"
This is how it should look like:

and this after importing pyautogui:

There is something called DpiAwareness which is responsible for making your GUI sharp, you might have notice that tkinter is quite blurry because by default it is set to false, when you import pyautogui, it messes up with the value of DpiAwareness and make it true, which in turn mess up the positioning and sizes of your window, you may try to first add these lines to your code then you should proceed to create your tkinter app, this will do two things, make your UI better, your app will not be affected by pyautogui import.
import ctypes
ctypes.windll.shcore.SetProcessDpiAwareness(1)

Thanks @Ankit404butfound already tried but unfortunately same issue, the GUI continues changing its size. Notices something odd in the process, if I comment the "pyautogui" import and include the code just as you suggested:
import ctypes
ctypes.windll.shcore.SetProcessDpiAwareness(1)
The GUI still changes its size, see below:

However, if the the "pyautogui" import is still as a comment and change the "1" in your suggested code by a "0", the GUI doesn't change its size and all looks good.

As soon as I remove the hash sign from the "pyautogui" import line, no matter if "SetProcessDpiAwareness" is set to 1 or 0, the GUI changes

Yes that's exactly what I tried for one of my app and it didn't work either, so I have to resize the entire app, it was really irritating.
One solution would be to copy the required part from pyautogui source code and include it in the code instead.

You know what, after running some tests tried to move things around and moving your suggested code, but setting it to Zero instead of One, before the "pyautogui" import does the trick, it should look like this:

You may want to give it a try for your app too, hope this helps.
Thank you very much @Ankit404butfound and @aaryanrr for your help!

Oh well, why didn't I think of that. Thanks to you now. 😅


v10.1.0

@jsimmonds2 With regards to the ENV vars, I had to shelve it for this release but would like to add it in v10.1.1. Unfortunately, root caused analysis took so much time for Express firmware resets that it did not leave me any time to investigate the ENV issue (or the USB serial port bug that some DIY users have reported). I will circle back once the dust settles.


supermonkey seems to not suit the higher version of golang

Now we are using Go 1.14.2. It seems to be okay with Patch function. But when we need to upgrade our golang version to 1.15 or higher, the supermonkey.Patch seems not okay. Mock is ineffective. Do you konw why, or do you have a plan for suiting golang higher version.
Thank you.

I tried this patch demo in go 1.15.14, and it worked well
package main

import (
	"fmt"

	sm "github.com/cch123/supermonkey"
)

func main() {
	fmt.Println("original function output:")
	heyHeyHey()

	patchGuard := sm.PatchByFullSymbolName("main.heyHeyHey", func() {
		fmt.Println("please be polite")
	})
	fmt.Println("after patch, function output:")
	heyHeyHey()

	patchGuard.Unpatch()
	fmt.Println("unpatch, then output:")
	heyHeyHey()
}

//go:noinline
func heyHeyHey() {
	fmt.Println("fake")
}

can you provide a reproducible demo for your problem?

I write golang code with go 1.17.8. Codes are down below. But the result is "hello" instead of "yeah
func hello() {
println("hello")
}
func TestName(t *testing.T) {
supermonkey.Patch(hello, func() {
println("yeah")
})
hello()
}

I write golang code with go 1.17.8. Codes are down below. But the result is "hello" instead of "yeah func hello() { println("hello") }
func TestName(t *testing.T) { supermonkey.Patch(hello, func() { println("yeah") }) hello() }

did you run your demo with proper flags？
Warning : use go test -ldflags="-s=false" -gcflags="-l" to enable symbol table and disable inline.


scripts for ics721 setup

from scripts/README.md:
# Setup ICS721

For ICS721 it requires these contracts:

- ICS721: the bridge itself
- Incoming Proxy: optional contract for filtering incoming packets
- Outgoing Proxy: optional contract for filtering incoming packets

NOTE:
Below scripts use [select-chain.sh](./select-chain.sh). For each selected chain there is an `.env` file like `stargaze.env` and `osmosis.env`.

## Scripts

### Initial Setup

Scripts for setup must be executed in this order:

1. ICS721 without proxies: [instantiate-ics721.sh](./instantiate-ics721.sh)
2. Incoming Proxy: [instantiate-incoming-proxy.sh](./instantiate-incoming-proxy.sh)
3. Outgoing Proxy: [instantiate-outgoing-proxy.sh](.instantiate-outgoing-proxy.sh)

After instantiation:

- update `ADDR_ICS721`, `ADDR_INCOMING_PROXY`, `ADDR_OUTGOING_PROXY` in env file
- Note: ICS721 is instantiated without(!) proxies, proxies are added via migration (velow)

### Migration

1. ICS721 : [migrate-ics721.sh](./migrate-ics721.sh)
2. Incoming Proxy: [migrate-incoming-proxy.sh](./migrate-incoming-proxy.sh)
3. Outgoing Proxy: [migrate-outgoing-proxy.sh](.migrate-outgoing-proxy.sh)

### Outgoing Proxy Messages

Usage:

```sh
$ ./scripts/whitelist-outgoing-proxy.sh
Usage: ./scripts/whitelist-outgoing-proxy.sh stargaze|osmosis [--add WHITELIST|--remove WHITELIST|--enable true_or_false] --type collection|channel|checksum|fees
Example:
./scripts/whitelist-outgoing-proxy.sh stargaze|osmosis --add channel-1 --type channel
./scripts/whitelist-outgoing-proxy.sh stargaze|osmosis --enable false --type collection

The owner of the outgoing proxy contract can add, remove and enable whitelists for collections, channels, collection checksums, and collection fees.

This looks pretty good, can we get a demo video? When Empower did their interchain CLI they provided a demo video to demonstrate how its used. Either that or some screenshots of deploying ICS721 on a chain.


Question on transfer or forking

@ndip007 Would you like to transfer this repo to SPDX or should I create a forked copy?  Transfer has the advantage of moving over the issues.

As you said it's advantageous to transfer the repo.
On Fri, Sep 6, 2019, 12:35 PM goneall<EMAIL_ADDRESS>wrote:

@ndip007 https://github.com/ndip007 Would you like to transfer this
repo to SPDX or should I create a forked copy? Transfer has the advantage
of moving over the issues.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/ndip007/spdx-tools-js/issues/8?email_source=notifications&email_token=AGLRRIXRO3N3SD43V3ABVMTQIKBDVA5CNFSM4IUK4H42YY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4HJ3GGBQ,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AGLRRIQLHSFOMP2U6P4AO7LQIKBDVANCNFSM4IUK4H4Q
.

@ndip007 Go ahead and transfer it to SPDX: https://help.github.com/en/articles/transferring-a-repository  If you have any permissions problems, you can transfer it to my account (goneall) and I'll transfer it again to SPDX.

@ndip007 Pinging you again on transferring the repo.   @jeffmcaffer expressed interest in the library and I would like to move it over to the official SPDX.

Yay, this would be great. Thanks @ndip007 for driving the work. Moving it to SPDX will drive more exposure and collaboration on the base you have created. Let us know if there is anything we can do to help with the transfer.

@ndip007 I went ahead and forked the repository to SPDX.  If you would like transfer the repo instead, let me know.  If you run into any access issues, you can transfer it to @goneall  and I can transfer it to @spdx since I have access to both.


Incorrect IntelliSense if file encoding and d.ts is not UTF-8

From @ocheretnyy on November 15, 2017 3:30

VSCode Version:1.18.0
OS Version:Windows 7

Incorrect IntelliSense if file encoding and d.ts is not UTF-8. If d.ts file alredy opened when IntelliSense work correctly.
Steps to Reproduce:

In user settings file set    "files.encoding": "windows1251",
Create  d.ts file (encoding = windows1251) with russian symbols:

declare namespace qt_workbench
{
/** Add dock-window
* Добавить Dock-окно
*/
function add_window(widget : QWidget,title : string,width : number,height : number,is_visible : boolean);
}
3. Create file and write:
workbench .add_window()
3. Move mouse on function add_window for IntelliSense

If workbench.d.ts file opened IntelliSense work correctly

Reproduces without extensions: Yes
Copied from original issue: Microsoft/vscode#38373

This works when the d.ts file is open because VS Code sends the correct text content of the file to the TS Server. When the d.ts file is no open, the TS Server reads the file directly from disk and cannot know the encoding.
Not sure what we can do about this. Any thoughts @mhegazy?

When the d.ts file is no open, the TS Server reads the file directly from disk and cannot know the encoding.

May be the TS Server should use user encoding setting by default? (file settings.json, parameter "files.encoding")

This is not about user settings, but about the text APIs the server uses. The server uses the node APIs to read files. we do support UTF8, UTF16 BE and LE. other than that, the server can not read the files correctly.
if the file is open, the text comes from the editor, and convert it to utf8, which the server understands.
It is worth nothing that the compiler will not generate files that are not UTF8. so the .d.ts is manually generated, and for that i suggest using UTF8 or UTF16 with a BOM.

ok. Thanks for the info