Fix stale BSP diagnostics

The BSP server didn't reset old diagnostic messages sent to BSP clients under certain circumstances. This commit mitigates this edge case and ensures that diagnostics for files that previously had compilation problems are properly reset when fresh diagnostics messages are sent.
The culprit was a mismatch of map keys: Files with problems were sometimes recorded under an absolute path, but later attempted to be retrieved by virtual path.
That the fix works can be tested end-to-end on a repro project under:
https://github.com/SlowBrainDude/sbt-bsp-bug-reproducer
Clone the repo and open it in VSCode with Metals installed. In case Metals isn't configured to do automatically so, switch to the SBT build server. (Bloop doesn't show any issues with the project). Let Metals import the project and do the initial compilation. Everything should work fine so far. Now navigate to the JavaClass file. There is a commented block of code. Delete the * as the comment says. SBT will send diagnostics for the now failing build and you'll get a lot of red squiggles in the Java file after compile finishes. Now restore the comment. The errors reported by the SBT BSP will still be shown in the file (and in the problems pane and file explorer). By commenting things in and out you can actually multiply the errors. You can create a few hundred or even more just by commenting things in and out. The reported errors will never go away even when the file compiles fine again.
With my fixed version of SBT the errors get reset properly again and don't get stale.
(Even Metals does some questionable things that may cause sending the reset diagnostic to take quite some time. I've seen compile times of 5 - 15 ms on the Java file, but it could take over 1 minute until the reset diagnostics got sent. But that's a Metals issue which implements some algo that explodes with line count and error count in a file quite quickly, maybe even exponential, at least high polynomial, given that this issue can make a 2 second CLI compile of very large file with only one syntax error into 20 minutes of all CPUs grilling on max when running Metals).
So far so good, but this PR is just a draft as some things aren't clear to me still.
Maybe I've hunted down somethings that shouldn't exist in the first place, and the real bug is even deeper. Because the bug doesn't surface in all cases actually.
I've tried to write a test for the case affected by this code change. But I've failed in doing so; at least so far.
On my repro project the problem.position.sourcePath extracted from the Problem passed to publishDiagnostic is definitively an absolute path. I had log output more or less around every line of code in BuildServerReporter and traced the whole BSP communication while debugging. (It took actually quite some time to realize that the cause of the problem is a harmless looking but failing getOrElse… And it took even longer to see the difference in file path, as I only looked at the file name at first without paying much attention to what is written before it; also the log output was far apart so I just didn't see the difference between absolute path and something that starts with ${BASE}/ for a long time).
But the test I've written didn't fail in such way. I was wondering why the test gets green no matter my fix is applied or not. It turns out that in the test project problem.position.sourcePath is a "virtual path" (with a ${BASE}/ prefix), even for Java files which I thought at first was actually the trigger condition for the bug.
Now I need help to understand why my repro project behaves differently from the test projects in SBT. I've tried to trace how Problemss get constructed, and where the source path is initialized, but honestly I wasn't able to look though all this indirection. There is logic in DiagnosticsReporter but I don't understand where and why the source is sometimes feed in as proper file and sometimes as virtual file (which may have a possibly "virtual" path).
The main question is: Why do the "file descriptors" feed into sendFailureReport and publishDiagnostic differ sometimes in how the path looks like (even they are the same file in the end). Is this something that's expected, or is the actual bug that this differs? Should the sourcePath extracted from Problems always be a "virtual" one maybe, and is it already wrong that some absolute path ends up there?
In case it's expected that the form of the path may differ between sendFailureReport and publishDiagnostic I still need a way to write a test that exhibits this behavior, to have a proper negative test (one that fails without the patch applied).
Sorry for the very long description, but the issue wasn't easy to find and understand either. I hope I described it here in a way that can be understood.
TASKS to make this mergable:

[ ] Investigate whether this is actually the proper fix, and not just "healing symptoms"
[ ] Fix the regression test, or write a proper one in case this is not the right fix

Thanks for opening this PR. Is it ready to be reviewed? Do you need any help?

I think i made it clear that I need help here.
This fixes a bug (see lined demo project). But I'm not sure I'm fixing the root cause.
Also, no matter whether this is already the right fix or not, I wasn't able to write a negative test.
So I need input on the two points I left here already as checklist:
I'm not sure whether this fix just heals symptoms or is actually the right one.

The main question is: Why do the "file descriptors" feed into sendFailureReport and publishDiagnostic differ sometimes in how the path looks like (even they are the same file in the end). Is this something that's expected, or is the actual bug that this differs? Should the sourcePath extracted from Problems always be a "virtual" one maybe, and is it already wrong that some absolute path ends up there?

Also no matter what, I need a way to reproduce the bug that can be seen on my demo project (and some other projects of my) in the SBT tests in this codebase. But the bug doesn't manifest on the test projects in this repo. I don't know why. I thought it always happens with Java files (that was my observation in some other projects) but this doesn't seem to be true.

Maybe this is difficult to understand for anybody who didn't look at log files for a few days like me, so I try to rephrase the main questions again:
SBT accumulates published compiler diagnostics. This accumulation happens through a Map, keyed by the path to the affected file. (Please see the file this commit updates). But the path can have two distinct forms (even it's a handle to the same file in the end). It can be an absolute path, or it can be a relative path prefixed by something like ${BASE}/.
The assumption that causes this bug is that the path has always the same form in the calls to sendFailureReport and publishDiagnostic (so the key into said accumulating Map be the same). But this assumption is wrong. It has sometimes a different form (even it references the same file in the end) and lookup by such key in said Map fails then (even it should not as there are entries already for the file in question, just with a different form of path specifier as key).
The different path specifier manifested for me just on Java files. But that's not the only condition it seems, as it does not happen in the project used for testing SBT itself (see my attempt to write a regression test for this commit). I'm not sure what the trigger could be. My repro project is absolutely minimal. (Hmm… Maybe that's actually (part of) the trigger: I have no projects / modules defined explicitly in the build… Need to check this. Still I would not know why it can make the form of paths returned by the compiler different; maybe they come in already different; but I wasn't able to trace that as there is just too much indirection; the stacktrace is half a mile long and goes through SBT, zinc, compiler bridge, the Scala 2 compiler, and hell knows where the path gets actually injected, as this is an async action).
There is logic to handle both path forms in the compiler bridge. So it is expected to have both forms in general. But whether both forms are actually valid as the input to sendFailureReport and publishDiagnostic is still unclear to me. (Whoever written the code in the first place assumed it's always of the same form. I can't judge whether this was an oversight or is a valid assumption!) This could be a pointer to a bug sitting somewhere deeper. But I don't know enough about SBT to assume anything here. That's why I left an draft and hopped someone with more knowledge about the inner workings of SBT can clarify this part.
Also it's unclear to me how having a simple module-less project, or project modules respectively, could affect the form of paths to source files. Why it's not always of the form ${BASE}/relative/path/to/File.java, but sometimes an absolute path? Is the "root module" somehow different to other modules? Should it be like that actually?
If nobody actually knows what's going on here in fact we can just merge the fix, leave out the test, and call it a day. It will fix a bug.
But maybe this bug is just a symptom of something else? But if nobody knows how things are supposed to actually work having a bugfix is better than not having one at all…
BTW: The bug is in the category of a full show stopper. Just go and try my repro project! If you run into it it's almost impossible to edit a Java file in a Scala project. Metals will hang quite quickly, and all errors, including syntax errors as you type, will just pile up and never go away; red squiggles everywhere after a few keystrokes that never go away until you restart Metals. It's supper annoying and makes for the most terrible first impression possible. So I would really like to have a bugfix for it. But I also usually try to fix root causes, and not just heal symptoms. Because just healing symptoms makes things worse in the long run. If you hidden all your bugs behind some "quick fixes" this will fire back sooner or later in bad ways. So I would really like to understand what's happening here before proceeding. But I just don't know enough about how SBT is supposed to work to decide whether this path here is the right one or some deeper digging is still required. I published the patch in the hope that for some people more knowledgeable about SBT than me some bell will ring when reading the description. But actually I had the impression my input is getting ignored instead…

@SlowBrainDude thanks a lot for reporting this issue and proposing a fix for it.
Indeed it seems that the root cause of the issue is the Java compiler reporting errors in plain source files (absolute path) instead of virtual source files (${BASE}/.../Hello.java). But this does not seem to be always the case and that's why you are struggling to reproduce it in the tests.
After further investigation in your reproduction repo, I found that the issue disappear when I remove the sbt-metals plugin, that is automatically added by Metals. Meaning the Java compilation errors are suddenly reported in virtual files (${BASE}/.../Hello.java) which is what is expected by the BuildServerReporter.
More specifically it seems that the javaHome setting that is set here triggers the bug. javaHome is None by default, but as soon as it gets a value (Some(File())) the errors are reported in plain files. I don't know if that's a bug in itself: maybe it is hard to get an arbitrary Java compiler to compile virtual files (and I don't really want to spend time figuring this out).
All of that being said, it seems that your changes make the  BuildServerReporter more robust. Assuming that sourcePath: String is always the id of a VirtualFile was somewhat hazardous. Making the round-trip converter.toPath(VirtualFileRef.of(id)) seems safer.
My suggestion is to add the sbt-metals plugin in the buildserver test project, and that should reproduce the bug:
addSbtPlugin("org.scalameta" % "sbt-metals" % "1.2.2")

The buildserver test is kind of an integration test, and so it seems reasonable to test the integration with Metals.

Thank you very much @adpi2 for figuring out the part I did not manage to understand!!! :+1:
Now I have time for that again; I'll try to update this PR soonish, applying your suggestions.
But I think I will have a closer look at the Metals plugin before doing that. I think it should not change the semantics of a build, this seems pretty wrong. (That's already the second time that this is the root cause of something. I reported another issue here that turned out to be caused by the Metals plugin just shortly before, see #7608).
In case the problematic part can be fixed in Metals, would you still suggest to include the changes here?
I just don't know enough about SBT internals to judge whether this here is something that could happen also for other—valid—reasons, or something that should never happen at all. In case it should never happen I think this "fix" here would just hide other potential errors, and I would actually omit it. (I'm a big proponent of "fail early"; if something unexpected happens it should imho instantly explode, loudly. Imho such things should never be "painted over" by some workarounds. But opinions may vary of course. Some people think it's better to keep running no matter what).
I've spend three days digging first though Metals and than through SBT (which I did not do ever before, so at least this part was not a wast of time) to figure out this here. But if fixing the right thing means digging even deeper so it be. :slightly_smiling_face:

BTW, how did you find out that it's the Metals plugin, @adpi2?
Is this already a kind of "usual suspect"? (Because for the other issue eed3si9n also was quick to diagnose an issue with the plugin.)
Or do you have some "secret debugging techniques" I should be aware of? Happy to learn some new tricks! :smile:

BTW, how did you find out that it's the Metals plugin, @adpi2?

It took me some time, but to make it short:

I added some logs in BuildServerReporter and published a SNAPSHOT version of sbt locally.
I copied the buildserver test to a new folder and configured project/build.properties to use the SNAPSHOT version of sbt
I imported it in Metals and saw that I could reproduce the bug, which puzzled me. How was it possible that the bug occurred when importing the build but not in the test?
I remembered that Metals injects some different settings in project/metals.sbt file. I commented out the sbt-metals plugin and saw that it made the bug disappear.
I then tried the setting in MetalsPlugin one by one to find out that javaHome was triggering the bug.

Is this already a kind of "usual suspect"?

No I wasn't expecting that. For #7608 though, it's different because we know that Metals needs semanticdb and enables it by default.

But I think I will have a closer look at the Metals plugin before doing that.

Metals is clearly not the problem here: javaHome is a valid setting and we should be able to configure it. The problem is in sbt itself: why does setting the javaHome change the path of reported errors? It would be useful to investigate that but I don't know if it is easy to fix or not. Maybe we cannot ask an arbitrary Java compiler (from a custom javaHome) to compile virtual sources, because it may not support the feature. As you said, it could be a valid reason.

In case the problematic part can be fixed in Metals, would you still suggest to include the changes here?

Yes I think we should still include the changes here. The BuildServerReporter looks quite fragile to me and I would take anything to make it more robust.

Thanks for the detailed information!
For the first part I was doing the same. It's the usual thing to do. Just publish local SNAPSHOTs and run from that, adding logs and stuff.

How was it possible that the bug occurred when importing the build but not in the test?

Oh, yeah, that puzzled me also massively. I've gave up after half a day. Had no idea left where to look.
For the second part I see you just smelled it… :smile:
I know that Metals is adding a SBT plugin, but I would have not suspected it to change anything about the build. This still seems wrong.

Metals is clearly not the problem here

Thanks for pointing that out. So I think I don't need to look there. Great!

The problem is in sbt itself: why does setting the javaHome change the path of reported errors? It would be useful to investigate that

Let's see what I find out.

Yes I think we should still include the changes here. The BuildServerReporter looks quite fragile to me and I would take anything to make it more robust.

OK. So I'll make this PR mergable. (Fix the test, include the requested changes)
To be honest, I also think this whole diagnostics reporter thingy is very brittle, and a quite bad design. Streaming diagnostics is just such an ill idea. (Not sure though this isn't already messed up in the BSP "protocol"…) We're talking here about something that takes just a few milliseconds. "Optimizing" that with a very complex streaming mechanic seems wrong. Eclipse (the "RedHat Java plugin) does it much smarter, and just locks the editor for this short time and submits all diagnostics for a file as batch. (I didn't know about the editor looking until at some point under very high load I've got once some "loading indicator" in the editor when typing instead of chars appearing on screen. But usually you never run into that). Additionally I think the whole idea of "snapshots" and diffing them implemented in Metals is also ill. Actually I think this is the cause of a massive performance degradation because the algo is likely very high complexity, and explodes with longer files and "many" errors. (I don't have formal prove of this suspicion right now. But I think I will come up with some. But that's something for the Metals project, as that part of the issue is not SBT's problem.)
Thanks again for taking time to look into that. I'm sorry I could not come up with a full solution in the first place.

I've investigated the questionable things and made a small update to the PR. It's now ready for review. (Sorry for the long delay!)
First of all I think it makes no sense to try to change the behavior around what happens when you set javaHome. The whole point of this setting is to use an external compiler. Now aligning the inner workings of it with the programmatically called compiler available in the JVM process SBT runs in would make things quite complex. You would need to change simply shelling out to a system process with something like RMI. I see no convincing reason to even try. (A change the other way around, shelling out in any case, and not using the compiler service programmatically would be even a bigger change. I don't see this happening. That would touch the core of SBT and looks very risky to me).
Having two ways to call the Java compiler is unfortunate, has some side effects (like different compiler diagnostic formats—see the updated test), but looks all in all like the better trade-off to introducing quite a lot of complexity. (There is also another small, likely cosmetic difference, which is the different implementations of XPosition, which has different .toString implementations. This does not show up in the test, but I've seen it in debug logs; no clue whether this can cause trouble ever, though. I think at worst the displayed messages in the error pane of an IDE will look slightly different. Didn't investigate this further).
Regarding the other things:
I did not pick up the idea to add the Metals plugin to the build. Instead I'm testing with the root cause, which is the javaHome setting. Adding the Metals plugin would add a maintenance burden as it would require constant updates of the plugin just to keep tests in shape.
I have a question though: Did I introduce some kind of race condition by adding a second .sbt file to the test project? I mean, it gets picked up, otherwise the test would fail (alone for the different diagnostics message formats), but will this work in any case? I was not able to find a definite answer to what SBT does when there are more than one .sbt files in a project root directory.
Besides that I kept the test separate to the others. It's already one of the biggest test on its own, and as even the messages you need to check are different there would be imho nothing to win by merging it into the other test. Having this separate also makes it easier to see whether something failed while using the JVM compiler service, or respectively the compiler called as regular system process.
So summarized, in case you don't see any issue with adding a second .sbt file to the test project, this PR is ready from my viewpoint. But I'm of course open to further suggestions or change request.


The isce2 package is incompatible with newer versions of numpy

I get the following error:
  File "/home/jth/code/hyp3-isce2/src/hyp3_isce2/topsapp.py", line 175, in run_topsapp_burst
    insar.run()
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/isce/components/iscesys/Component/Application.py", line 142, in run
    exitStatus = self._processSteps()
                 ^^^^^^^^^^^^^^^^^^^^
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/isce/components/iscesys/Component/Application.py", line 405, in _processSteps
    result = func(*pargs, **kwargs)
             ^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/isce/components/isceobj/TopsProc/Factories.py", line 40, in __call__
    return self.method(self.other, *args, **kwargs)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/isce/components/isceobj/TopsProc/runFineResamp.py", line 387, in runFineResamp
    azCarrPoly, dpoly = secondary.estimateAzimuthCarrierPolynomials(secondaryBurst, offset = -1.0 * offset)
                        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/isce/components/isceobj/Sensor/TOPS/TOPSSwathSLCProduct.py", line 285, in estimateAzimuthCarrierPolynomials
    x = np.arange(0, burst.numberOfSamples,xstep,dtype=np.int)
                                                       ^^^^^^
  File "/home/jth/jth-apps/miniconda3/envs/hyp3-isce2/lib/python3.11/site-packages/numpy/__init__.py", line 305, in __getattr__
    raise AttributeError(__former_attrs__[attr])
AttributeError: module 'numpy' has no attribute 'int'.
`np.int` was a deprecated alias for the builtin `int`. To avoid this error in existing code, use `int` by itself. Doing this will not modify any behavior and is safe. When replacing `np.int`, you may wish to use e.g. `np.int64` or `np.int32` to specify the precision. If you wish to review your current use, check the release note link for additional information.
The aliases was originally deprecated in NumPy 1.20; for more details and guidance see the original release note at:
    https://numpy.org/devdocs/release/1.20.0-notes.html#deprecations. Did you mean: 'inf'?

The issue is resolved by including the following lines in environment.yml:
- python>=3.8,<=3.10
- numpy<1.20

Numpy must be pinned to <1.20 because of the isce2 incompatibility, and Python must be pinned to <=3.10 because the older version of Numpy is incompatible with Python 3.11.
However, I have isce2 version 2.6.1 installed, and I just noticed that 2.6.2 is available from https://anaconda.org/conda-forge/isce2. So perhaps the newer version of isce2 resolves the numpy issue.
TODO:

[ ] Determine if installing isce2 version 2.6.2 solves the issue.
[ ] If not, pin python and numpy as shown above.

Based on the 2.6.2 release notes it looks like this problem should be fixed. Maybe we should pin isce2 instead?

The problem is not fixed, we're still seeing the same error with the following versions installed:
numpy 1.24.2
isce2 2.6.2

I opened https://github.com/isce-framework/isce2/issues/696 to hopefully get this fixed.


Game_and_Dices_Implementation

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 73 (0.0%)  changed or added relevant lines in 2 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage decreased (-11.3%) to 4.04%

Changes Missing Coverage
Covered Lines
Changed/Added Lines
%

repository/IngSoft2-Model/SpaceShip.class.st
0
23
0.0%

repository/IngSoft2-Model/Game.class.st
0
50
0.0%

Totals

Change from base Build<PHONE_NUMBER>:
-11.3%

Covered Lines:
4

Relevant Lines:
99

💛  - Coveralls


MenuSuite Properties

MenuSuite Properties link is broken. But I guess they do not apply to extensions anyway.

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

ID: 4749e121-b119-f67b-0887-992ead0f8a0a
Version Independent ID: f058fd88-5704-72b5-11ae-4f12a06edf05
Content: Properties - Business Central
Content Source: dev-itpro/developer/properties/devenv-properties.md
Service: dynamics365-business-central
GitHub Login: @SusanneWindfeldPedersen
Microsoft Alias: solsen

Thanks for catching this bug, you're completely right, MenuSuite properties do not apply to extensions and in the next refresh, I've removed the link. Thanks again.


flutter-3.2-candidate.5 presubmits are failing on vpython failure

The following changes need to be CP'd to the branch:

https://flutter-review.googlesource.com/c/recipes/+/32820
https://flutter-review.googlesource.com/c/recipes/+/32931

Marking P1 as this is blocking the release.

To cherrypick these, I tried using the Gerrit cherrypick feature in the UI. It showed the generated commit as having merge conflicts.
I went ahead and downloaded the patch, resolved the merge conflict, and regenerated the expectations. However, that got the commit into a bad state and put it onto master.

Thank you @nehalvpatel for fixing this!


Formatted (JSON) logs have duration with no unit

When collecting logs from JSON format into Grafana we get logs such as these (reformatted for beauty and legibility):
{
  "file": "usr/local/go/src/net/http/server.go:2047",
  "func": "net/http.HandlerFunc.ServeHTTP",
  "host": "treeverse.eu-central-1.lakefscloud.io",
  "level": "info",
  "log_audit": "API",
  "method": "GET",
  "msg": "HTTP call ended",
  "path": "/api/v1/repositories/something",
  "request_id": "a296ebfe-eb9f-4856-b59f-cd82b7e1cf36",
  "sent_bytes": 155,
  "service_name": "rest_api",
  "status_code": 200,
  "time": "2022-07-17T20:53:23Z",
  "took": 295165694
}

The duration field "took" is a pure number with no units.  I suspect that time.Duration is an integer, so it gets JSON-serialized.  When logs are output in text format, it does get stringified so it gets a number.
As a temporary workaround we could figure out the units and use those for now.

@idanovo this is what we saw on Grafana. :-(

@idanovo this is what we saw on Grafana. :-(

... About time displayed in logs.  This should not affect the time displayed from metrics in any way whatsoever, it's a separate reporting path.

High priority because affects any perf debugging.

This also occurs in the "duration" field of database logs :-(

Actually fixed by #6934 :-)


Add default user-agent to huggingface-cli

This PR sets library_name="huggingface-cli" in the upload CLI command (similar to the download command). The goal is to be able to track usage of CLI vs script to upload files.

The docs for this PR live here. All of your documentation changes will be reflected on that endpoint.

Thanks for the review! :)


Compile Error

Hey im getting errors by just compile it i use VS19 can you help me pls

Can you give us more information about the error?
Please add the output


Re-enable vault deployment CI

After RBAC certificates were introduced, vault deployment broke because it does not generate the necessary certificate file names. For now, vault CI is disabled until this is fixed.

@chapsuk thanks for fixing this!


Implement Numba (JIT Compiling) natively into pynecone

Since you're most likely recalling event functions a ton, might as well take advantage of some JIT for performance gains (especially in large apps)

Currently our bottle neck of performance is network lag and front-end repaint.

Numba wouldn't help here, since we don't have any heavy number crunching code (or indeed any code that would benefit from vectorization or SIMD).


Dateparser online demo

Hi there!
The first time I used dateparser I missed a simple way to try it out for my use case. Since it is an awesome package, I've built an online demo of the library so users can try it out.
Here it is
Maybe you want to add it to your docs 😉

Hi @vimtor!
Thank you for building this! You did a really nice job!
I would love to add it to the README, but would you mind adding a small note like "powered by dateparser" or something similar pointing to this Github repository and/or the PyPI package link? I found a link to the docs when clicking the image, but it's a little bit hidden.
I also would love if you add a Free/Open Source license to your Github project, in that way we will be able to submit PRs like adding support for settings, etc, and the process will be more transparent. :)
Of course, both things are up to you, this doesn't block adding this link to our Readme. I added a PR with the URL: https://github.com/scrapinghub/dateparser/pull/883 Let me know what you think! :)

Hey @noviluni! Thanks! Glad you liked it ❤
I did it on twitch while streaming, so it was quite improvised.
I will add both things you mention, once they are online I'll let you know

Done! I added both the copy on the web and the license in the repo.

I merge the PR. thanks @vimtor ! :smile:

Hi all,
The demo site is currently returning a 404 with the following error (copy-pasted from Chrome's dev tools)

Access to fetch at 'https://dateparser-demo-production.up.railway.app/?text=three days ago&timezone=America/New_York' from origin 'https://dateparser-demo.netlify.app' has been blocked by CORS policy: No 'Access-Control-Allow-Origin' header is present on the requested resource. If an opaque response serves your needs, set the request's mode to 'no-cors' to fetch the resource with CORS disabled.

Firefox gives a similar error:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://dateparser-demo-production.up.railway.app/?text=three days ago&timezone=America/New_York. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 404.

I am not well-versed in these kinds of errors, but I assume this is a server-side rather than a client-side problem. Would you like an issue opened here, or in @vimtor's repository?

With the whole Heroku thing I had to move it to other place but I don't want it to consume my free tier.
Could you host it yourself and I change the endpoint?

Sadly, I don't have the skills or the wherewithal to host it, no. Perhaps the thing to do is remove it from the README (for now) and open a new issue to see if somebody else has ideas for the hosting?


[Feature][subtask] Add the documentation page about yarn queue management.

Search before asking

[X] I had searched in the feature and found no similar feature requirement.

Description
Add the documentation page about yarn queue management.
Usage Scenario
No response
Related issues
#2324
Are you willing to submit a PR?

[X] Yes I am willing to submit a PR!

Code of Conduct

[X] I agree to follow this project's Code of Conduct

https://github.com/apache/incubator-streampark-website/pull/196


Feat/organization activity logs

Description
Implemented an API endpoint to fetch activity logs for users within an organization. The endpoint is accessible at api/v1/organizations/:orgId/users/:userId/activity-logs. This feature allows for retrieving user activity logs, ensuring that the user has appropriate permissions and that the organization and user IDs are valid.
How Has This Been Tested?

Unit Testing: I have written unit tests to cover various scenarios, including:

Successful response with valid orgId and userId.
Handling invalid orgId or userId.
Missing orgId or userId.
Valid request with no activity logs found.
Appropriate status codes for different conditions.

The tests were executed in a local development environment using PHPUnit. All tests passed successfully, confirming that the endpoint functions correctly under different conditions.

Integration Testing: The API endpoint was tested using Postman to ensure it integrates well with other parts of the application and meets the expected functionality.

Types of changes

[ ] Bug fix (non-breaking change which fixes an issue)
[x] New feature (non-breaking change which adds functionality)
[ ] Breaking change (fix or feature that would cause existing functionality to change)

Checklist:

[x] My code follows the code style of this project.
[x] My change requires a change to the documentation.
[x] I have updated the documentation accordingly.
[x] I have read the CONTRIBUTING document.
[x] I have added tests to cover my changes.
[x] All new and existing tests passed.

Resolve your merge conflicts

Resolve your merge conflicts, and attach screenshots of your code/business logic and API/endpoint and test implementations for evidence.

Did you look at the migration, hope it won't break some code on production.


Migrate rpn_fn interface to BytesRef, JsonRef

Roadmap: https://github.com/skyzh/tikv/issues/2
Migration Status

[x] Compile impl_arithmetic
[x] Compile impl_cast
[ ] Compile impl_compare
[ ] Compile impl_compare_in
[ ] Compile impl_control
[ ] Compile impl_encryption
[ ] Compile impl_json
[ ] Compile impl_like
[ ] Compile impl_math
[ ] Compile impl_miscellaneous
[ ] Compile impl_op
[ ] Compile impl_other
[ ] Compile impl_string
[ ] Compile impl_time
[ ] Compile types/expr_builder
[ ] Compile types/expr_eval
[x] Test impl_arithmetic
[x] Test impl_cast
[ ] Test impl_compare
[ ] Test impl_compare_in (test_in_complex panic)
[ ] Test impl_control
[ ] Test impl_encryption
[ ] Test impl_json
[ ] Test impl_like
[ ] Test impl_math
[ ] Test impl_miscellaneous
[ ] Test impl_op
[ ] Test impl_other
[ ] Test impl_string
[ ] Test impl_time
[ ] Test types/expr_builder
[ ] Test types/expr_eval

Draft of CHANGELOG:
tidb_query_codegen

Modify RpnFnRefEvaluableType an enum that accepts two kinds of types: "Ref" &Int and "Type" JsonRef
Store RpnFnRefEvaluableType instead of TypePath in RpnFnSignatureParam and VargsRpnFnSignatureParam
Add some workarounds that enable developers to use JsonRef and BytesRef in vectorized functions. They will be removed after we fully migrate copr to the new Chunk-based interface. This includes

A trait IntoEvaluableRef with a function into_evaluable_ref(). &Json, &Bytes implements this trait to return JsonRef and BytesRef. Other primitives types reference are implemented to return themselves.
is_ref_type checks if a TypePath is JsonRef or BytesRef. If yes, the generated rpn_fn implementation will call into_evaluable_ref() on arguments from copr framework, so as to transform &Json into JsonRef.

Update documentation and compile error message of rpn_fn macro.

tidb_query_datatype

ConvertTo<f64>, ConvertTo<Decimal> and ConvertTo<f64> are implemented on JsonRef. Original Json implements simply calls the implementations on their reference.
Add IntoEvaluableRef trait (as described above)

tidb_query_vec_expr

Migrate all functions to have signature like func(data: Option<BytesRef>)
In impl_cast, helpers like test_as_string_helper now accepts T instead of &T. In this way, helper_get_cs_ref was added to transform cs Vec<(U, V, W)> in original tests to be Vec<(&U, V, W)>, hence fitting into new generic function.

Mark: https://github.com/skyzh/tikv/pull/7/commits/23e18c8ae5100f7d9e1de00018adb6acb3f8a201


pxbind needs update

See https://github.com/EmbarkStudios/physx-rs/issues/210#issuecomment-1751766240, this could be due to any number of factors, but most likely a change in clang versions resulting in different AST output.

From my experience with #223 this is actually just symptom of being run on an unsupported platform (/clang++/libc++ version)
It would probably be nice to document which clang++ versions will work (13.0 didn't work on macos for me, 14.0 on popOS/linux did, I've seen you talk about 15.0 on linux before), and not sure if libc++ matters but I needed to install g++-12 on my linux install to make it work.


Vagrantfile for libvirt boxes should not set "connect_via_ssh" and "username"

The Vagrantfiles for the libvirt boxes (in tpl/vagrant) set the connect_via_ssh and username settings of the vagrant-libvirt plugin. This is a problem because of the way the vagrant-libvirt plugin determines the libvirt URI to use: if any of the connection settings are set (it can't distinguish between the user Vagrantfile and a Vagrantfile supplied by the box), it ignores the LIBVIRT_DEFAULT_URI env var and only uses the settings in the Vagrantfile.
This means that merely by setting connect_via_ssh and username (regardless of value), the Alma Linux baseboxes implicitly disable the use of LIBVIRT_DEFAULT_URI. vagrant-libvirt will always use the system QEMU driver even if that environment variable is set unless the URI settings are overridden again in the user Vagrantfile.
For that reason connect_via_ssh and username should be removed from the Vagrantfile templates. (Note that while driver is also a connection setting, it's specialcased and can stay.)
I'm also skeptical of the storage_pool_name setting. I suspect it might also cause unnecessary and difficult to debug problems for people with nonstandard libvirt setups.

Thanks a lot for such useful report and suggestions for making the libvirt boxes more portable.
If I build the box without providing custom Vagrantfile, the NFS will be used as the synced folder type.
So, we need to use rsync or disable it. What do you think about that? :thinking:
I am testing this template:
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure('2') do |config|
  config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end

And it ends up like this inside the box:
# The contents below were provided by the Packer Vagrant post-processor

Vagrant.configure("2") do |config|
  config.vm.provider :libvirt do |libvirt|
    libvirt.driver = "kvm"
  end
end

# The contents below (if any) are custom contents provided by the
# Packer template during image build.
# -*- mode: ruby -*-
# vi: set ft=ruby :

Vagrant.configure('2') do |config|
  config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end

As you see, packer adds driver setting even we provide our custom Vagrantfile. Hopefully, What I observe on my tests, is the driver settings in the user's Vagrantfile is honored on the vagrant up.
These settings was added with the intention of an out of the box experience when using vagrant init $box and vagrant up. Looks like they are not needed anymore, at least on the 0.12.2 version of vagrant-libvirt plugin.

From: Elkhan Mammadli @.>
Sent: Saturday, November 18, 2023 12:31:26 AM
To: AlmaLinux/cloud-images @.>
Cc: Subscribed @.***>
Subject: Re: [AlmaLinux/cloud-images] Vagrantfile for libvirt boxes should not set "connect_via_ssh" and "username" (Issue #157)
Thanks a lot for such useful report and suggestions for making the libvirt boxes more portable.
If I build the box without providing custom Vagrantfile, the NFS will be used as the synced folder type.
So, we need to use rsync or disable it. What do you think about that? 🤔
I am testing this template:
-- mode: ruby --
vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end
And it ends up like this inside the box:
The contents below were provided by the Packer Vagrant post-processor
Vagrant.configure("2") do |config|
config.vm.provider :libvirt do |libvirt|
libvirt.driver = "kvm"
end
end
The contents below (if any) are custom contents provided by the
Packer template during image build.
-- mode: ruby --
vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end
As you see, packer adds driver setting even we provide our custom Vagrantfile. Hopefully, What I observe on my tests, is the driver settings in the user's Vagrantfile is honored on the vagrant up.
These settings was added with the intention of an out of the box experience when using vagrant init $box and vagrant up. Looks like they are not needed anymore, at least on the 0.12.2 version of vagrant-libvirt plugin.
—
Reply to this email directly, view it on GitHubhttps://github.com/AlmaLinux/cloud-images/issues/157#issuecomment-1817285830, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAUK5RGZPI2J7PA6L5MZTLDYE76V5AVCNFSM6AAAAAA5NC445GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGI4DKOBTGA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
.........................................................................................................................................
Join online meetinghttps://join.skype.com/k3hKRpveNJ7D
.........................................................................................................................................

From: betty kanabee
Sent: November 17, 2023 10:22 PM
To: AlmaLinux/cloud-images @.>; AlmaLinux/cloud-images @.>
Cc: Subscribed @.***>
Subject: RE: [AlmaLinux/cloud-images] Vagrantfile for libvirt boxes should not set "connect_via_ssh" and "username" (Issue #157)
When: November 18, 2023 12:00 AM-12:30 AM.
Where:

From: Elkhan Mammadli @.>
Sent: Saturday, November 18, 2023 12:31:26 AM
To: AlmaLinux/cloud-images @.>
Cc: Subscribed @.***>
Subject: Re: [AlmaLinux/cloud-images] Vagrantfile for libvirt boxes should not set "connect_via_ssh" and "username" (Issue #157)
Thanks a lot for such useful report and suggestions for making the libvirt boxes more portable.
If I build the box without providing custom Vagrantfile, the NFS will be used as the synced folder type.
So, we need to use rsync or disable it. What do you think about that? 🤔
I am testing this template:
-- mode: ruby --
vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end
And it ends up like this inside the box:
The contents below were provided by the Packer Vagrant post-processor
Vagrant.configure("2") do |config|
config.vm.provider :libvirt do |libvirt|
libvirt.driver = "kvm"
end
end
The contents below (if any) are custom contents provided by the
Packer template during image build.
-- mode: ruby --
vi: set ft=ruby :
Vagrant.configure('2') do |config|
config.vm.synced_folder '.', '/vagrant', type: 'rsync'
end
As you see, packer adds driver setting even we provide our custom Vagrantfile. Hopefully, What I observe on my tests, is the driver settings in the user's Vagrantfile is honored on the vagrant up.
These settings was added with the intention of an out of the box experience when using vagrant init $box and vagrant up. Looks like they are not needed anymore, at least on the 0.12.2 version of vagrant-libvirt plugin.
—
Reply to this email directly, view it on GitHubhttps://github.com/AlmaLinux/cloud-images/issues/157#issuecomment-1817285830, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BAUK5RGZPI2J7PA6L5MZTLDYE76V5AVCNFSM6AAAAAA5NC445GVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTQMJXGI4DKOBTGA.
You are receiving this because you are subscribed to this thread.Message ID: @.***>
.........................................................................................................................................
Join online meetinghttps://join.skype.com/k3hKRpveNJ7D
.........................................................................................................................................

The synced_folder setting is fine. It's certainly something a lot of other baseboxes do. I think the libvirt.driver that Packer adds is also ok. I've never seen any issue with it in my own baseboxes.
It could be that the other settings in the libvirt block were necessary in the past, but I'm confident they're not necessary with current versions of libvirt and vagrant-libvirt. Removing them shouldn't change the default behaviour of the box (i.e. vagrant init + vagrant up should still work as before with no customization), but it would make vagrant-libvirt's LIBVIRT_DEFAULT_URI support work with the box.

I just published the 9.3 box. Please, let me know how it works on your environment: https://app.vagrantup.com/almalinux/boxes/9/versions/9.3.20231118

I just published the 9.3 box. Please, let me know how it works on your environment: https://app.vagrantup.com/almalinux/boxes/9/versions/9.3.20231118

Can confirm, with the new version LIBVIRT_DEFAULT_URI works. Thanks!


Add classes Asset & AssetList

Create a new class Asset:
class Asset {
  ...
  delete()
  parent()
  subtree()
  children()
  timeSeries()
  events()
  files()
}

const assetList = [Asset, Asset, Asset];
assetList.delete = () => {...}
assetList.timeSeries = () => {...}

Moved to Jira https://cognitedata.atlassian.net/browse/DEVX-11?atlOrigin=eyJpIjoiNGI5NTQwODg1Njg2NGUwZjkwN2M0Mzk0MmZmYmFjMWUiLCJwIjoiaiJ9


Demonstrate usage of foreign arrow function

Pull Request Description
Including arrow language in the distribution by default. Added a basic example for creating an Arrow array.
Making sure that memory layout agrees with Arrow specification (padding, continuous allocation of memory chunks).
Related to #9118.
This should unblock work on allowing serialization/deserialization to/from Parquet but I'd like to delay it to a follow up ticket as it is going to be a significant amount of specialized work.
Checklist
Please ensure that the following checklist has been satisfied before submitting the PR:

[x] All code follows the
Scala,
Java,
and
Rust
style guides. In case you are using a language not listed above, follow the Rust style guide.
All code has been tested:

[x] Unit tests have been written where possible.

We have designed, implemented and packaged the Arrow language as a separate, Enso independent entity. This PR puts Arrow Array Builder into Standard.Base. That's not right!

Despite the name, there is nothing Arrow-specific in that module.  And I think it would make sense to make it generic. I will update the PR.

@JaroslavTulach As I mentioned, there was nothing in the builder that made it arrow-specific. In fact this can serve as a generic polyglot array builder. The changes now reflect that.
But I also added a case where you can use Polyglot API to do the modifications in place. Then the sky is the limit (the potential damage as  well).

Assuming @jdunkerley main requirement is the: don't let mutable arrays float thru the computation, then ...

.... Simplest idea is to ....

Change the syntax of the Arrow language to create the builder itself:
foreign arrow new_array_int8 = """
    new[Int8]

b10 = new_array_int8 10
b10.append 2
b10.append 4
arr = b10.build # or to_array?

arr.length . should_equal 10
arr.at 0 . should_equal 2
arr.at 1 . should_equal 4
arr.at 5 . is_nothing . should_be_true # maybe?

Polyglot.write_array_element arr 6 33 # raises an exception as the arr is already immutable

if this is what we want, then it all can be implemented in the Arrow language itself without any need for so many builtins in the Enso engine.


Update sbt-jmh to 0.3.5

Updates pl.project13.scala:sbt-jmh from 0.3.4 to 0.3.5.
I'll automatically update this PR to resolve conflicts as long as you don't change it yourself.
If you'd like to skip this version, you can just close this PR. If you have any feedback, just mention @scala-steward in the comments below.
Have a nice day!

Ignore future updates
Add this to your .scala-steward.conf file to ignore future updates of this dependency:
updates.ignore = [{ groupId = "pl.project13.scala", artifactId = "sbt-jmh" }]

closed in favor of https://github.com/sphereio/sphere-scala-libs/pull/99


add docker for windows support

This has been working on lab environment for approx 1 month using docker edge version.  Tested using both linux and windows containers.

Could you take a look to the conflict? Thanks Jerry!

Looks like it's fixed and passing now.

Awesome! Thanks guys!


[Rollouts] RC interop implementation

RC interop Implementation

This change is for interop and RCComponent.
Interop and its unit tests are written in Swift under FirebaseRemoteConfig/Interop and FirebaseRemoteConfig/Tests/SwiftUnit
Updated dependency for SPM and CocoaPod for the new Interop.

Note: this change will merge to our feature branch not master
#no-changelog

Yes. The spectesting tests can't pass on a new pod until after the PR merges. The icore team needs to stage the pod and retag after you merge. You can merge without it. Sorry about the confusion.

Yes. The spectesting tests can't pass on a new pod until after the PR merges. The icore team needs to stage the pod and retag after you merge. You can merge without it. Sorry about the confusion.

Thank you for the confirming!


Remove resend_confirmation_email command and related templates

Now we no longer require confirmation, and now that we've sent the final
round of reminders, this command is no longer required.
Before remove the file, this PR also adds a simple log file to prevent
double-sending which was used in the final round of reminders -- just in
case we ever need to resurrect this command.

Coverage increased (+0.1%) to 70.275% when pulling 4303c9daa615a71edfe1398cec8615406d1ca034 on remove_resend_confirmation_email_command into cb591d59e25710f765f4234c102822fada48a613 on master.

There's also tempate_override settings.  Could these be removed?


20240421

Release with support for CUDA 12.3.2, TensorFlow 2.16.1, PyTorch 2.2.2 and OpenCV 4.9.0

Self-approved, tested locally


Update dependencies for ASE

Required for Azure Resource Graph Integration

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

This doc does not list every service and the possible integrations.  It just lists the areas that need to be exposed for the ASE to run.  There are other services that would need to be exposed if you were using them.  Event grid falls into that scenario if you are using Graph.  There are other dependencies based on the feature/service that your apps use.  This doc does not attempt to cover all of them.  With ASEv3, there are no networking requirements.  Details such as to use Graph you need to allow traffic to Event Grid needs to be tracked in the resource graph documentation for any/all services that inject into a Vnet.


mini.clue: Add ability to ignore key maps for display.

Contributing guidelines

[X] I have read CONTRIBUTING.md
[X] I have read CODE_OF_CONDUCT.md

Module(s)
mini.clue
Description
which-key.nvim has functionality where if the description of a mapping is which_key_ignore, that map will be ignored in the display. I use this for <leader>N buffer switch mappings, where N is 0-9.
It'd be great if mini.clue had something similar. In key-menu.nvim, this is hidden.

Thanks for suggestion!
I somewhat strongly believe in "show all mappings" approach. But I'll think about it.

Sorry, I think allowing ignoring some keys but not others is not a good idea long term. Both for 'mini.clue' and users who manage their own config.
Closing as not planned.

Is there any way, that can be possible right now ? Like I don;t want to show 1..10 keymaps.

Is there any way, that can be possible right now ? Like I don;t want to show 1..10 keymaps.

Sorry, no. If there is a mapping, it will be shown.


All logs appearring as stderr in stream field

When I run my containers with the TTY set to none all of my logs are showing up in Logstash as coming from stderr.  If I attach a TTY to the container then the logs don't show up at all.

Is there some configuration piece I'm missing?

This was due to the way I had my application logs set up.


Added: Nested #ifdef

This version is now able to handel nested #ifdef clauses. If you are intrested you can look and and we can discuss about. Are test files available? Until now I only tested the new features.

I resolved some problems and tested the changes. The Test file is also changed, becuase this version (nested #ifdefs) need #endif. For nicer code a function as #elseif may can help.

Now sorry for my late reply. I was fine with my version and was to busy to look at GitHUB.
Thanks for merging and the detailed answer. Before I never programmed on such a project and the comment that

don't change the names of existing features, it breaks code for users who rely on this lib

really makes sense.


Modified server-side streaming behavior

I'll leave it to @ryanolson to look at the nvrpc changes. But can you add a description to your commit message describing what you change does. I think it is allowing multiple outstanding requests from the stream to be processed instead of serializing them, but you should put some detail in the description.


Update global-json.md

global.json reference was missing entries and examples.
Pending questions:
Does the packages property work? Or should we add a note about this dotnet/cli#3816?
What happens if runtime is not specified?
What happens if architecture is not specified?
/cc @blackdwarf @livarcocc

Open Publishing Build Service: The pull request content has been published and here are some sample preview links:

Docset 1: core-docs

Open Publishing Build Service: The pull request content has been published and here are some sample preview links:

Docset 1: core-docs

@mairaw if the runtime and the architecture are not set, it will default to coreclr and x64. In all honesty, I haven't see these being set on many global.json files.

Even if they are not used much, I think it's important to have them all documented @blackdwarf. Right?
However, I was reading online that the default architecture depends on which runtime you configured. Not sure if this still holds true, for example: https://github.com/aspnet/dnvm/issues/468

@gkhanna79 Can you confirm the SDK options? I know that version is correct. Not sure about architecture though.

The host does not own the SDK options - tools (e.g. CLI) own setting it up. The only configuration of SDK that host is aware of "version" that it uses to determine which SDK to load CLI from.

So, should I leave the other options out of the document then, @gkhanna79?
These were the options listed in the global.json schema and was trying to determine their default values.

@gkhanna79 can you help with my previous question or know someone who can? Thanks.

@livarcocc should be able to help. @schellap may have some ideas.

"/sdk/version" this json path gets the value of the SDK version to use to compile the app etc.
I'm not sure about the other two options. Runtime and architecture.

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/global-json?branch=pr-en-us-996

Status: Succeeded.
Open Publishing Report.

I've removed the controversial properties.
Is the topic accurate from what you guys know about global.json now?
/cc @blackdwarf @gkhanna79 @schellap

Open Publishing Build Service: The pull request content has been published and here are some changed files links of this time:

Docset 1 - core-docs
https://review.docs.microsoft.com/en-us/dotnet/articles/core/tools/global-json?branch=pr-en-us-996

Status: Succeeded.
Open Publishing Report.

I'm merging this and deal with any feedback later if this is inaccurate.

So is this suppose to be merged and released ?
Because https://docs.microsoft.com/en-us/dotnet/articles/core/tools/global-json still not up to date!

@johnsimons yes! What do you see missing?

There is no doco for "projects" and "packages", all I see is the "sdk".

So it looks like it was removed in https://github.com/dotnet/docs/commit/c2722327c3ca213309cae5e0d0417b0f0e9ea514#diff-250d1d2a2050498b0df08adc4609d9c0

projects and packages are no longer relevant in msbuild world. The only value in global.json that is still honored is the sdk version.

@livarcocc thanks for the clarification


CodeGen: Preserve known tags for LOAD_TVALUE synthesized from LOADK

When lowering LOADK for booleans/numbers/nils, we deconstruct the operation using STORE_TAG which informs the rest of the optimization pipeline about the tag of the value. This is helpful to remove various tag checks.
When the constant is a string or a vector, we just use LOAD_TVALUE/STORE_TVALUE. For strings, this could be replaced by pointer load/store, but for vectors there's no great alternative using current IR ops; in either case, the optimization needs to be carefully examined for profitability as simply copying constants into registers for function calls could become more expensive.
However, there are cases where it's still valuable to preserve the tag. For vectors, doing any math with vector constants contains tag checks that could be removed. For both strings and vectors, storing them into a table has a barrier that for vectors could be elided, and for strings could be simplified as there's no need to confirm the tag.
With this change we now carry the optional tag of the value with LOAD_TVALUE. This has no performance effect on existing benchmarks but does reduce the generated code for benchmarks by ~0.1%, and it makes vector code more efficient (~5% lift on X64 log1p approximation).

This change results in ~4% lift on A64 and ~5% lift on X64 for vector approximation which is the main goal here, but it seems like it doesn't hurt for strings (the code size reduction on benchmark code is due to strings exclusively - I don't have access to a large Luau codebase so can't measure broad impact but assume it's a slight codesize reduction as well) so it's applied unconditionally.

fwiw assembly diff for A64 for vector approximation:
     8: 	local r: vector = vector(0, 0, 0)
 LOADK R1 K0 [0, 0, 0]
 vector <- vector, any
-#   %4 = LOAD_TVALUE K0                                       ; useCount: 2, lastUse: %14
+#   %4 = LOAD_TVALUE K0, 0i, tvector                          ; useCount: 1, lastUse: %14
  ldr         q31,[x22]
-#   STORE_TVALUE R1, %4                                       ; %5
- str         q31,[x25,#16]
     9: 	local a: vector = x
 MOVE R2 R0
 vector <- vector, any
 .L22:
-#   %6 = LOAD_TVALUE R0                                       ; useCount: 8, lastUse: %123
+#   %6 = LOAD_TVALUE R0                                       ; useCount: 7, lastUse: %123
  ldr         q30,[x25]
-#   STORE_TVALUE R2, %6                                       ; %7
- str         q30,[x25,#32]
    10: 	r += a -- todo: * 1 doesn't fold yet
 ADD R1 R1 R2
 vector <- vector, vector
 .L23:
-#   %8 = LOAD_TAG R1                                          ; useCount: 1, lastUse: %9
- ldr         w17,[x25,#28]
-#   CHECK_TAG %8, tvector, exit(2)                            ; %9
- cmp         w17,#4
- b.ne        .L24
 #   %14 = ADD_VEC %4, %6                                      ; useCount: 1, lastUse: %39
  fadd        v31.4s,v31.4s,v30.4s
    11: 	a *= x
 MUL R2 R2 R0
 vector <- vector, vector

I think this change triggers a bug in another optimization and causes tests on Ubuntu to fail.
I believe it will be fixed by the sync PR today, so will have to be rebased on that.

My prediction is that the sync will hit the same issue but we'll see :)
The error shows up in a slightly different run every time afaict - the first run of this PR actually failed the main test execution (no codegen). A rerun just now failed in a flags=false no-codegen run:

The failure happens before any tests actually run (no doctest banner which is printed first). This is an ASAN issue with ASLR that I also have locally on my system, it's spuriously failing test runs on master as well as on this branch. It's been reported here https://github.com/google/sanitizers/issues/1614 and fixed in some versions of clang/gcc but if you don't have the latest build then you're going to run into issues...
Locally, sudo sysctl -w vm.mmap_rnd_bits=28 fixes the issue completely - if the sync still sees it we may need to add this to the build steps before running any tests for the time being...

https://github.com/luau-lang/luau/pull/1203

Thanks for figuring that out.


how to zoom the map when mouse in a html element

I use a div element replace the entity cover the map，when mouse in the div and rolling the wheel，it can't zoom the map.
if set the div 'pointer-event:none'，it will be work good ,but the div can't trigger click event，Is there a solution to solve the problem.

Hello @chengang0621, please ask questions like this on our community forum


[test-triage] otbn_multi

Hierarchy of regression failure
Block level
Failure Description
  UVM_FATAL @<PHONE_NUMBER>8 ps: (csr_utils_pkg.sv:577) [csr_utils::csr_spinwait] timeout otbn_reg_block.status (addr=0xd76c0018) == 0x0

Steps to Reproduce

GitHub Revision: 8cb25a6867
dvsim invocation command to reproduce the failure, inclusive of build and run seeds:
./util/dvsim/dvsim.py hw/ip/otbn/dv/uvm/otbn_sim_cfg.hjson -i otbn_multi --tool xcelium --build-seed<PHONE_NUMBER>0898561482658723926798947801831709189350919955228328310045202344042 --fixed-seed<PHONE_NUMBER>507457242826380278942798517380184863003163683118482721461099382809 (requires xcelium 21.09)

A quick check of the changes in hw/ip/otbn/ showed me the following recent commits:
https://github.com/lowRISC/opentitan/commit/f1a4691b1a6f731a8c96ee315869c0e56ad84415 * [otbn,dv] Waive some secure wipe assertions when they won't hold
https://github.com/lowRISC/opentitan/commit/e504585e9b445c6335ec9f1224b63bb4afb2a37e * [otbn,dv] Tidy up timing waiting for call stack corruption errors
https://github.com/lowRISC/opentitan/commit/ccd5d991df1d1c2c825b48831e0e973720eb8f57 * [otbn,dv] Correct timing in when corrupting top of loop stack
https://github.com/lowRISC/opentitan/commit/fcafc77dfb89cd90b611762e985d3a99f7082314 * [otbn,dv] Rewrite otbn_stack_addr_integ_chk_vseq
https://github.com/lowRISC/opentitan/commit/f70443076e0b41748249584b903b419fb2d6caa1 * [otbn,dv] Factor out a wait_for_run_completion task in base vseq
https://github.com/lowRISC/opentitan/commit/856e402f740d40dbdb06013320f1697670154fc0 * Earlgrey-PROD-M4-RC0 [rtl] MuBi encoding of iCache memory ctrl signals
This test failure is not present at https://github.com/lowRISC/opentitan/commit/856e402f740d40dbdb06013320f1697670154fc0, so the cause is likely in this range.
Tests with similar or related failures

[ ] #23417 : Similar error message

Looking at the latest regression logs (Thursday May 30 2024 19:02:59 UTC), the following vseq's also have at least one seed failing by the same error condition.

otbn_illegal_mem_acc
otbn_reset
otbn_imem_err
otbn_escalate
otbn_stress_all

otbn_multi_err failed in today's regression run and error message is the same as the OP.

The behaviour described is no longer happening (fixed by #23496). The test is actually still failing occasionally. For example (4/6/24):

    9.otbn_multi.73056072195384395817935344147963117303608402675902929131839633533267994074560
    Line 350, in log /container/opentitan-public/scratch/os_regression/otbn-sim-xcelium/9.otbn_multi/latest/run.log

      UVM_FATAL @<PHONE_NUMBER> ps: (otbn_base_vseq.sv:484) [uvm_test_top.env.virtual_sequencer.otbn_multi_vseq] Timed out waiting for OTBN run to complete by polling status
      UVM_INFO @<PHONE_NUMBER> ps: (uvm_report_catcher.svh:705) [UVM/REPORT/CATCHER]
      --- UVM Report catcher Summary ---

This is because I added a rough guess of a reasonable timeout in otbn_base_vseq, and the runs I was waiting for were in the otbn_multi_err test, which only run a few instructions. The timeout is a pretty arbitrary 1ms. I suspect that we can improve things by bumping it up by a factor of 10: the tests still won't take a ridiculous time to fail if they are going to time out.
I'll file a PR now to increase this timeout and mark it as closing this issue.


Codablock F improvements

[x] FNC1 mode
[x] FNC4 extended ASCII

FNC4 extended ASCII added to version 2015-05-23.

FNC1 already supported.


Package on PyPi not in sync with Github

When deploying, I get:
Error: Unable to import your app.py file: cannot import name UnauthorizedError
Because, in __init__.py in the pip-package, lno. 2:
from chalice.app import ChaliceViewError, BadRequestError, NotFoundError

In __init__.py on Github (https://github.com/awslabs/chalice/blob/c9bef0c4e7d1aa6bb8f8bb3df110c52dc91e5798/chalice/init.py#L2-L5):
from chalice.app import (
    ChaliceViewError, BadRequestError, UnauthorizedError, ForbiddenError,
    NotFoundError, ConflictError, TooManyRequestsError
)

I'd like to get a few more changes together, I'll be getting a pypi release out shortly.

I was hoping to get CORs support in this release, but it's going to take a little more time and I'd prefer to get all the bug fixes pushed sooner rather than later.  pypi now has version 0.2.0 release which includes the fix for the issue your'e seeing.


chore(deps): upgrade configuration

Upgrades project dependencies. See details in workflow run.

Automatically created by projen via the "upgrade-configuration-2.x" workflow

⚪ Backport skipped
The pull request was not backported as there were no branches to backport to. If this is a mistake, please apply the desired version labels or run the backport tool manually.
Manual backport
To create the backport manually run:
backport --pr 1114

Questions ?
Please refer to the Backport tool documentation


[v9.0.0rc3]Issues with the dialog when trying to delete an activity

in dashboard/system/automation/activity there are 2 issues with the modal when trying to delete an activity:
Clicking on the cancel button or on the top-right close button does nothing and the modal doesn't go away. Clicking on the overlay, however, makes it go away.
The top-right close button is all wrong (not the proper BS class names). See screenshot attached:

This is fixed in 9.0.0rc4


PCA9685 driver

Also adds PCA9685 based Adafruit PWM/Servo shield

@gmarull could you take a look?

@jfischer-no @galak @gmarull could you please have another look, thanks

@galak could you please check again?


License missing

Is this plugin under the Apache-2.0 License as stated in the npm page? (https://www.npmjs.com/package/x2js)
I can't find the license file nor is it mentioned in the readme file.

The source code has embedded license disclaimer which confirms the license to be Apache-2.0


Adding $[taskcat_current_region] magic parameter.

Overview
This PR adds the $[taskcat_current_region] magic parameter. It returns the region passed into the ParamGenerator class.
Brief description of what this PR does, and why it is needed (use case)?
Testing/Steps taken to ensure quality
Unit tests. Live tests.
BucketRegion | us-east-2
-- | --

/do-e2e-tests


Powershell snippets run in reverse order and do not complete

Bug description
Powershell .ps1 snippets run in reverse order and do not complete
Screenshots

Steps to reproduce

Create any Powershell snippet
Run in SSH session on Microsoft machine
Error as in screenshot

Hello @RichardBurt65 👋
Thank you a lot for your issue 👍
I will take a look at it in order to find and fix the trouble.

Could you run this :

Remove-PSReadlineKeyHandler Ctrl+Enter

=> Before running the snippet.
Does the snippet is pasted in good order?
If so I will be able to make a fix.

I'll try it in the morning and let you know.
Sent from my iPhone

On 15 Aug 2022, at 21:16, Arnaud Mengus @.***> wrote:

Hello @RichardBurt65
Have you some time to do a test?
Could you run this :
Remove-PSReadlineKeyHandler Ctrl+Enter
=> Before running the snippet.
Does the snippet is pasted in good order?
If so I will be able to make a fix.
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

Morning Arnaud,
Screenshot attached of results. Snippet still doesn’t run but at least it’s in the correct order (barring the excess >> signs)
￼

On 15 Aug 2022, at 21:16, Arnaud Mengus @.***> wrote:
Hello @RichardBurt65 https://github.com/RichardBurt65
Have you some time to do a test?
Could you run this :
Remove-PSReadlineKeyHandler Ctrl+Enter
=> Before running the snippet.
Does the snippet is pasted in good order?
If so I will be able to make a fix.
—
Reply to this email directly, view it on GitHub https://github.com/isontheline/pro.webssh.net/issues/708#issuecomment-1215631324, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74V464AS54C62Y4XYZ3VZKJRZANCNFSM555G4M7A.
You are receiving this because you were mentioned.

Good Morning ☀
Thank you a lot for your feedback!
Screenshots seems not to be attached when sending them through email.
Good news if commands are now in correct order : seems to be a "bug" inside PowerShell due to carriage return characters between macOS and Windows.
I will implement a hack inside WebSSH.

Try again with attachment.
￼

On 16 Aug 2022, at 08:12, Arnaud Mengus @.***> wrote:
Good Morning ☀
Thank you a lot for your feedback!
Screenshots seems not to be attached when sending them through email.
Good news if commands are now in correct order : seems to be a "bug" inside PowerShell due to carriage return characters between macOS and Windows.
I will implement a hack inside WebSSH.
—
Reply to this email directly, view it on GitHub https://github.com/isontheline/pro.webssh.net/issues/708#issuecomment-1216190017, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74X5LJV34PFNHUWPESDVZMWLXANCNFSM555G4M7A.
You are receiving this because you were mentioned.

I think attachments could only be put from GitHub.

Does the snippet is executed when pressing ENTER after the last statement?

Yes
Sent from my iPhone

On 16 Aug 2022, at 10:19, Arnaud Mengus @.***> wrote:

Does the snippet is executed when pressing ENTER after the last statement?
—
Reply to this email directly, view it on GitHub, or unsubscribe.
You are receiving this because you were mentioned.

If you add an empty line to the end of tour snippet does it execute it?
Snippets should not execute statements if they are no carriage return at the end because some users don't want to launch them automatically.

The snippet already has an empty end of line.

On 16 Aug 2022, at 10:39, Arnaud Mengus @.***> wrote:
If you add an empty line to the end of tour snippet does it execute it?
Snippets should not execute statements if they are no carriage return at the end because some users don't want to launch them automatically.
—
Reply to this email directly, view it on GitHub https://github.com/isontheline/pro.webssh.net/issues/708#issuecomment-1216320974, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74RAS674PEWPPXZW6ODVZNHSRANCNFSM555G4M7A.
You are receiving this because you were mentioned.

Last question please : instead of executing the snippet => when you copy your statements and paste them to the terminal, does the paste works as expected?

@RichardBurt65 Please also try out WebSSH 19.7 :
https://testflight.apple.com/join/QSrBK59z
You will also need to change the default carriage return to "\r\n" :

Will do once I can get it installed (on the latest public Ventura beta) which won’t install apps via TestFlight)

On 16 Aug 2022, at 21:44, Arnaud Mengus @.***> wrote:
@RichardBurt65 https://github.com/RichardBurt65 Please also try out WebSSH 19.7 :
https://testflight.apple.com/join/QSrBK59z
You will also need to change the default carriage return to "\r\n" :
https://user-images.githubusercontent.com/44212923/184970178-59037d05-a501-4691-8ab5-9440ffdde23c.png
—
Reply to this email directly, view it on GitHub https://github.com/isontheline/pro.webssh.net/issues/708#issuecomment-1217087651, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74WV34FLM4U2A7ZH753VZPVTDANCNFSM555G4M7A.
You are receiving this because you were mentioned.

I will release WebSSH 19.7 in a few days so you will be able to test it through the App Store

Many thanks.

On 24 Aug 2022, at 07:19, Arnaud Mengus @.***> wrote:
I will release WebSSH 19.7 in a few days so you will be able to test it through the App Store
—
Reply to this email directly, view it on GitHub https://github.com/isontheline/pro.webssh.net/issues/708#issuecomment-1225205314, or unsubscribe https://github.com/notifications/unsubscribe-auth/A2NS74RZBAUT3OYVUDKMG5TV2WWF3ANCNFSM555G4M7A.
You are receiving this because you were mentioned.

After installing todays Ventura latest beta and WebSSH beta I can now confirm that the powershell issue has been tested and fixed.
Perfect and many thanks.

Hello @RichardBurt65 👋
Great to hear that!
You're Welcome.
Many thanks for your feedback 🙏


funding: PSBT based external channel funding capabilities

Related to #3085. Now that we have our set of funding abstractions implemented within lnd, we can expose a much higher level (and safer!) RPC interface for our users. The end goal here is to be able to initiate channel funding within lnd (negotiation of parameters, keys, etc), the mid-way through carry out an interactive protocol with an external wallet to obtain signed inputs to fund the new channels.
Some ground work has already been laid here as btcutil now has a feature complete (and bitcoind compatible) PSBT package. The work in this issue will be to leverage some yet to be created btcwallet APIs (useful for testing) to create a new funding flow for PSBT based funding within lnd.
Steps to Completion

[ ] Create a new chanfunding.Assembler, and chanfunding.Intent which will house the new logic for this new type of funding shim within the codebase.

[ ] A likely location for the new more interactive funding protocol is likely the new chanfunding.Intent to be created. As we don't need to perform coin selection ourselves, the chanfunding.Assembler will mostly just be constructing the funding transaction once we have the relevant inputs.

[ ] From there a new multi-step protocol will need to be constructed within the wallet and the RPC interface. A possible outline may look something like this:

User initiates funding with a new FundingShim which specifies that they wish to have the funding input selection and signing take place outside of lnd.
We carry out the normal funding flow right up to the point that we need to obtain the funding transaction. Using the new abstractions, we'll now carry out an interactive protocol to create a PSBT w/ no inputs (only funding output present), present that to the user for funding and signing, then finally verify the validity of the created funding transaction before proceeding.
Extend the current FundingStateStep method to expose a new state machine to implement the protocol outlined above. A set of sample transition messages may resemble something along the lines of:

FundingPsbtCreate -> takes the pendingChanID used earlier and returns our PSBT template for the funding transaction.
FundingPsbtComplete -> takes the pendingChanID, and the completed serialized PSBT packet, then progresses the funding flow.

Put it all together and we'll be able to use lnd to fund channel directly from any wallet (even hardware wallet) that supports PSBT!

Fixed by https://github.com/lightningnetwork/lnd/pull/4079.


Add Karma package

As per the PR title, I'm adding Karma as part of the monitoring module.
There aren't official Karma manifests for Kubernetes yet, so this is a simple standard setup.
Any comment or suggestion is more than welcomed 😄

No problem! That's the reason for reviews 😄 I'm fixing it!


Add documentation for workspace flag

This PR adds documentation for the workspace flag.
This text was introduced in PR #81 which was not merged, in favor of #80. This PR reintroduces the README.md update to keep the documentation in line with the implementation.
Resolves #91

Thanks and apologies for this omission.


Consider adding support for Odo

This appeared on HN yesterday: http://odo.readthedocs.io/en/latest/
I haven't tried it out, but from the description it looks like some sort of semistructured data copy multitool analogous to ImageMagick's convert (except for semistructured data rather than Images).   The gimmick seems to be that if you give it two pointer to a semistructured data file (CSV, JSON) somewhere (Local, S3, Hadoop, ...) or other similar representation (or python internal representations like a pandas sequence or frame), it will figure out how to transform one into the other.
In particular, this could be useful for loading data into backend databases, replacing our current LoadCSV module.

Connecting to Spark addressed most of our ingestion needs for now.


[2.0.0-preview1] Core: Initial work on model-level entity type filters

Core: Initial work on model-level entity type filters. E.g.
modelBuilder.Entity<Customer>().HasFilter(c => !c.IsDeleted);
modelBuilder.Entity<Order>().HasFilter(o => o.CustomerId == this._tenantId);

Such filters are automatically applied by the query compiler to any query targeting the corresponding EntityType.
Some key aspects of impl. so far:

Client eval'd expressions are allowed.
Nav references are not allowed. This is mostly to constrain the impl. cost.
Evaluatable sub-trees in filter expressions are eval'd early (not parameterized) except for member accesses on DbContext objects. This permits the pattern in the second example above.
Filters are only allowed on the root of hierarchies, again to constrain the impl. cost.

Open questions:

Should Find ignore filters when hitting the store?
We likely need to add an opt-out query operator.
Update: What is required for owned types?

Are you planning to enable filters for owned types or is it scoped out for 2.0?

@AndriySvyryd I need to chat with the...owner of that :trollface:

Lets discuss about the invalid filters in person.

Updated.

Few questions:
Metadata:
Presently, the filters are via fluent API only. And we are not storing ConfigurationSource. Should we store it just to future guard if we add some attribute or convention for it later. (soft-delete does not sound totally bad convention). It can be YAGNI also in which case this is fine.
Query:
With include compiler and above changes, we have a good bunch of code going through OptimizeQueryModel method. Perhaps the method name should be different. IFF user opt-out of query optimization, (first question would be how? 😝 ) what parts should be removed or unavailable.

@smitpatel

YAGNI is fine for this.
Agreed. I will add an item to query refactoring bug


chore(core): auto-update vendored lockdown.umd.js

This changes the lint-staged configuration so that when package-lock.json is updated, the vendored packages/core/lib/lockdown.umd.js is copied from the currently-installed ses and added to the commit.
I'm not sure if this is something we want to be doing or not, but needing to run the lib:ses script in lavamoat-core after a ses upgrade is non-obvious for maintainers (me).

Yeah, I mean, why do we vendor lockdown.umd.js, anyway?

Closing in lieu of a PR which removes it


merge upstream main at

Merge https://github.com/prometheus/prometheus/commit/ee2b7fdf9d4d4a7fa8d1d9eccae55e5dc802213c to main
Many conflicts:
Conflicts:

.github/workflows/ci.yml   - trivial delete
storage/remote/otlptranslator/prometheusremotewrite/histograms.go   - simple, keep context
storage/remote/otlptranslator/prometheusremotewrite/metrics_to_prw.go   - simple, keep context
storage/remote/otlptranslator/prometheusremotewrite/metrics_to_prw_test.go   - simple, keep context
storage/remote/write_handler.go  - simple, keep context
storage/series_test.go  - simple, comment
tsdb/head.go  - ended up removing chunkDiskMapper type, why was is there?
tsdb/head_append.go  - ended up removing chunkDiskMapper type, why was is there?
tsdb/head_read.go - ended up removing chunkDiskMapper type, why was is there?
tsdb/ooo_head_read.go - had to change OOOCompactionHeadIndexReader.LabelValuesFor and .LabelValuesExcluding as they were unimplemented upstream, copied solution from .ShardedPostings
tsdb/querier.go - trivial change or not?
tsdb/querier_bench_test.go - tried running benchmark BenchmarkQuerierSelectWithOutOfOrder but already takes too long on upstream, so no luck there. Runs fine with reduced number of series, maybe there's a regression upstream?

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you all sign our Contributor License Agreement before we can accept your contribution.10 out of 15 committers have signed the CLA.:white_check_mark: aknuds1:white_check_mark: bboreham:white_check_mark: krajorama:white_check_mark: pracucci:white_check_mark: roidelapluie:white_check_mark: ywwg:white_check_mark: dtrejod:white_check_mark: jcreixell:white_check_mark: leizor:white_check_mark: beorn7:x: fatsheep9146:x: patilsuraj767:x: machine424:x: NeerajGartia21:x: riskroleYou have signed the CLA already but the status is still pending? Let us recheck it.


Implement support for Cucumber

Cucumber is a framework for BDD testing

see cucumber branch for work in progress.


#2645 - Program Deactivation - API Changes

Created new API endpoints to deactivate the program available for Institutions and the Ministry. The controller was created to specifically deactivate the program and the service was created to be generic to also allow the reactivation in case we need to work in the requirement in the future.
Created a new role institution-deactivate-education-program.
Created E2E tests for the new endpoints.

Ministry

Should allow an education program to be deactivated when the program is active.
Should return an unprocessable entity HTTP status when the program is already deactivated.
Should return a not found HTTP status when the program id does not exists.
Should return a bad request HTTP status when payload is invalid.

Institutions

Should allow an education program to be deactivated when the program belongs to the institution and the program is active.
Should return a not found HTTP status when a different institution accesses the program.
Should return an unprocessable entity HTTP status when the program is already deactivated.

Good job @andrewsignori-aot . Some minor comments.


Adds shim for sorbet-coerce

Type of Change

[x] Add RBI for a new gem
[ ] Modify RBI for an existing gem
[ ] Other:

Changes
I'm an interim maintainer for  sorbet-coerce and am adding a shim! This is what we use internally @chanzuckerberg. This shim is valid for the latest version of sorbet-coerce and works across various Tapioca/Sorbet versions.
I did want to ask about including Elem = type member. In our internal codebase, including that line causes a duplicate definition of the type_member; however, if I remove that line, then bundle exec repo check static sorbet-coerce fails with
$ bundle exec repo check static sorbet-coerce
Error: rbi/annotations/sorbet-coerce.rbi:5: Unable to resolve constant Elem https://srb.help/5002
     5 |  sig { params(args: T.untyped, raise_coercion_error: T.nilable(T::Boolean), coerce_empty_to_nil: T::Boolean).returns(Elem) }

which locally no longer exists in the file, but should be defined by Tapioca's generated file from bin/tapioca gems. How should I proceed here?
Note: I used a slightly different definition for sorbet-coerce on sorbet-typed: https://github.com/sorbet/sorbet-typed/pull/396.

Hm ... I'm now second-guessing this type signature (since it doesn't play as nicely with tapioca's sorbet-coerce.rbi). Perhaps don't merge yet?

Thanks for the suggestion @Morriar! I think we did have RBIs directly within the gem, but I'm not sure if they work properly with tapioca. Let me look into that and see if it's possible. Appreciate the suggestion, I'm definitely not very familiar with best practices on maintaining sorbet-related gems!


ENH: faster region building in spatial.SphericalVoronoi

In the spatial.SphericalVoronoi module, regions can be built faster by offloading more of the calculation to numpy.
Benchmarks:
============ ============= =============
 num_points      master       this PR
------------ ------------- -------------
     10         546±1μs       494±4μs
    100         1.69±0ms      1.32±0ms
    1000      13.6±0.02ms   10.2±0.08ms
    5000       71.7±0.3ms   53.6±0.07ms
   10000       148±0.7ms     112±0.6ms
============ ============= =============

@tylerjereddy Sorry for git amateur hour again.  I will try to rewrite the git history into a single commit...


Put all callbacks in the same Reentrant Callback Group

Description
In service of #62 .
As far as I can tell, our code is not at risk of any race conditions or deadlocks that would require mutually exclusive callbacks. (e.g., calling a synchronous service from a callback is an example of a situation that may cause deadlock.) However, our code does require callbacks to be received simultaneously, e.g., we should still receive watchdog messages while deciding whether or not to accept a goal.
Therefore, for every node in ada_feeding and ada_feeding_perception, this PR puts all the callbacks into the same ReentrantCallbackGroup, so they can be executed in parallel.
Paired with ada_ros2#19.
Testing procedure

[x] Launch the code as documented in the README. Run all actions. Ensure they behave as expected.
[x] Launch the web app. Test SegmentAnything. Ensure it behaves as expected.

[x] Run your code through pylint and address all warnings/errors. The only warnings that are acceptable to not address is TODOs that should be addressed in a future PR. From the top-level ada_feeding directory, run: pylint --recursive=y --rcfile=.pylintrc ..

Before Merging

[ ] Squash & Merge

@egordon You should consider doing something similar for ada_feeding_action_select

The MoveToMouth and MoveFromMouth actions in this were tested by rebasing #72 on top of this PR. All tests succeeded on t0b1


feat(api/v2): implement TOTP session check

This change implements Time-based One-Time Password (TOTP) on the v2alpha session API.
Closes #5477
Definition of Ready

[x] I am happy with the code
[x] Short description of the feature/issue is added in the pr description
[x] PR is linked to the corresponding user story
[x] Acceptance criteria are met
[x] All open todos and follow ups are defined in a new ticket and justified
[x] Deviations from the acceptance criteria and design are agreed with the PO and documented.
[x] No debug or dead code
[x] My code has no repetitions
[x] Critical parts are tested automatically
[x] Where possible E2E tests are implemented
[x] Documentation/examples are up-to-date
[x] All non-functional requirements are met
[ ] Functionality of the acceptance criteria is checked manually on the dev system.

Hello. My version is 2.35. I've just tried TOTP + password. I've added TOTP and created session with 3 checks (username, password, totp). When i request /auth/v1/users/me, I get an error "mfa required (AUTHZ-Kl3p0)". Unfortunately I'm not a GO developer, I can't find an exact problem on myself. But it looks that a problem is in file "token_verifier.go" line 203, there is a comment left, pointing to head issue of this task. Can someone confirm please?

Hei @dimyle
It looks like on the organisation mfa is required, in that case your user needs to authenticate with a factor and not only password.

Hei @dimyle It looks like on the organisation mfa is required, in that case your user needs to authenticate with a factor and not only password.

Hello @hifabienne!
That's true, organization MFA is required. In my tests it was set up and working. I've created session with 3 checks (login/password/TOTP) - that is working good. But, when I try to get user info, as i mentioned in my message above, this call fails. There is a commented piece of code in file, that prevent normal work of TOTP. If I use Email as MFA (not TOTP), everything works good.

can you please raise an issue, so we can track and solve it. It's hard to keep track of closed PRs. Also, can you include a permalink to the suspected code, it makes it easier for everybody.
I will try to pick it up this Friday. (our bugfix day).
Thanks.


Internals update request

Update internals for classes:
Modding

(+) RescanModsFolder() or RefreshAvailableModsList()
as it says, refresh available mods - scan folder for subfolders/*.civ5mod files
(+) RefreshSubscribedModsList()
scan for new available to download mods from previous scan or DB update and download if possible
(+) ResetDatabase()
clean mods cache database without erasing user settings (created by Modding.SetSystemProperty)
(+) string GetCachePath()
return user-related game cache path

ModDetails (properties)

(+) true|false SupportsMac
(+) true|false SupportsHotSeat
(+) string Categories
return categories to which it mod belongs, separated by commas

It will fix some bugs and add new filtering possibilities, but there's still one confusing bug with the mod database, after mod's .modinfo file is edited, game recognizes the mod as new, which leads to another:

The mod will be deactivated
The gamesave will no longer load, instead causing crash after attemption to load it with this mod

When testing i didn't edit mod id or name, so it must be related to hash routines.

This sounds good, would help some issues.
Maybe also automatically detect mods that require updates on start, and give some kind of a notification.
Have to bother people to check Mods>Scroll to mod > Check if 'Update' button is there
And then of course constantly hit issues such as:

Subscribed to mod, but it doesn't download. Have to delete all other mods to get it to recognize it needs to be downloaded.
Mod has had an update but update button doesn't appear

Random caching issue is my guess.

This sounds good, would help some issues. Maybe also automatically detect mods that require updates on start, and give some kind of a notification. Have to bother people to check Mods>Scroll to mod > Check if 'Update' button is there
And then of course constantly hit issues such as:

Subscribed to mod, but it doesn't download. Have to delete all other mods to get it to recognize it needs to be downloaded.
Mod has had an update but update button doesn't appear

Random caching issue is my guess.

Exactly, by the time i was writing it i was modifying  UI & functionality of the mods window, i've got it to work with filters, added ability to use & create modlist(modpack) files and  a few fixes.
But i do not reach my main goal - to make it work on Linux, Linux version of the game just reject any content that i try to add either as the mod or as the fake DLC, neither i could get to work regular modification or such of my own.
Also, @Lymia  can we discuss modding & your particular creation on any social network or by e-mail?