Replace BlobVec's swap_scratch with a swap_nonoverlapping

Objective
BlobVec currently relies on a scratch piece of memory allocated at initialization to make a temporary copy of a component when using swap_remove_and_{forget/drop}. This is potentially suboptimal as it writes to a, well-known, but random part of memory instead of using the stack.
Solution
As the FIXME in the file states, replace swap_scratch with a call to swap_nonoverlapping::<u8>. The swapped last entry is returned as a OwnedPtr.
In theory, this should be faster as the temporary swap is allocated on the stack, swap_nonoverlapping allows for easier vectorization for bigger types, and the same memory is used between the swap and the returned OwnedPtr.

hmm I was imagining just using swap_nonoverlapping and checking if len == 1 then we dont have to store a fn ptr :thinking:

swap_nonoverlapping needs a concrete type as generic parameter. As BlobVec is untyped, that still needs a function pointer.

we can use MaybeUninit<u8> and give it a length in bytes. Probably sus provenance wise but its no worse than what bevy is already doing

Without something like stackalloc or unsized locals, runtime length determined and stack allocated buffers are going to be difficult. Unfortunately that crate adds a C job to the dependency tree, which might not be desirable.

We could simply allocate a [MaybeUninit<u8>; N] on the stack and copy over multiple iterations.

What has the stack got to do with this, we can just use the memory in the blobvec cant we ?

we can just use the memory in the blobvec cant we ?

That is what was already happening before this PR. The motivation of this PR is that using the stack may be slightly faster due to cache locality reasons. I have no clue if this would indeed be the case. I think benchmarking will be needed.

Before this PR the swap scratch was a separate allocation, wheras with this PR it's part of the same buffer as the rest of the blobvec. The part where the stack comes in is how to swap two different elements on the blobvec, and for that I think a simple swap_nonoverlapping with u8 type should work.

Ran some benchmarks. Looks to be non-regressing for the affected benchmarks with a significant improvement for adding/removing bigger components.

```
group                                                    main                                     yeet-swap-scratch
-----                                                    ----                                     -----------------
add_remove_component/sparse_set                          1.01  1326.2±83.48µs        ? ?/sec      1.00  1310.9±75.15µs        ? ?/sec
add_remove_component/table                               1.05  1667.2±95.69µs        ? ?/sec      1.00  1586.3±14.45µs        ? ?/sec
add_remove_component_big/sparse_set                      1.03  1533.4±307.70µs        ? ?/sec     1.00  1493.4±376.44µs        ? ?/sec
add_remove_component_big/table                           1.24      3.5±0.45ms        ? ?/sec      1.00      2.8±0.21ms        ? ?/sec
fake_commands/2000_commands                              1.02      7.3±0.04µs        ? ?/sec      1.00      7.2±0.05µs        ? ?/sec
fake_commands/4000_commands                              1.00     14.3±0.15µs        ? ?/sec      1.02     14.5±0.17µs        ? ?/sec
fake_commands/6000_commands                              1.01     21.7±0.11µs        ? ?/sec      1.00     21.5±0.11µs        ? ?/sec
fake_commands/8000_commands                              1.01     29.1±0.15µs        ? ?/sec      1.00     28.9±0.14µs        ? ?/sec
get_or_spawn/batched                                     1.00   408.2±20.63µs        ? ?/sec      1.02   415.3±46.97µs        ? ?/sec
get_or_spawn/individual                                  1.03   931.3±81.29µs        ? ?/sec      1.00   904.5±91.18µs        ? ?/sec
insert_commands/insert                                   1.02   791.9±34.36µs        ? ?/sec      1.00   780.2±34.76µs        ? ?/sec
insert_commands/insert_batch                             1.00   403.2±48.73µs        ? ?/sec      1.03   413.4±45.14µs        ? ?/sec
simple_insert/base                                       1.00  616.8±107.65µs        ? ?/sec      1.02  628.0±108.75µs        ? ?/sec
simple_insert/unbatched                                  1.03  1367.2±80.74µs        ? ?/sec      1.00  1321.9±65.69µs        ? ?/sec
sized_commands_0_bytes/2000_commands                     1.00      4.5±0.04µs        ? ?/sec      1.00      4.5±0.07µs        ? ?/sec
sized_commands_0_bytes/4000_commands                     1.00      9.0±0.03µs        ? ?/sec      1.00      9.1±0.04µs        ? ?/sec
sized_commands_0_bytes/6000_commands                     1.01     13.6±0.11µs        ? ?/sec      1.00     13.5±0.08µs        ? ?/sec
sized_commands_0_bytes/8000_commands                     1.00     18.2±0.22µs        ? ?/sec      1.00     18.2±0.48µs        ? ?/sec
sized_commands_12_bytes/2000_commands                    1.04      7.3±0.03µs        ? ?/sec      1.00      7.0±0.19µs        ? ?/sec
sized_commands_12_bytes/4000_commands                    1.04     14.5±0.08µs        ? ?/sec      1.00     13.9±0.52µs        ? ?/sec
sized_commands_12_bytes/6000_commands                    1.04     21.7±0.09µs        ? ?/sec      1.00     20.9±0.10µs        ? ?/sec
sized_commands_12_bytes/8000_commands                    1.05     29.0±0.25µs        ? ?/sec      1.00     27.6±0.23µs        ? ?/sec
sized_commands_512_bytes/2000_commands                   1.01    164.4±5.20µs        ? ?/sec      1.00    162.6±7.88µs        ? ?/sec
sized_commands_512_bytes/4000_commands                   1.02   335.7±22.85µs        ? ?/sec      1.00   328.9±20.53µs        ? ?/sec
sized_commands_512_bytes/6000_commands                   1.01   515.2±60.79µs        ? ?/sec      1.00   512.1±74.67µs        ? ?/sec
sized_commands_512_bytes/8000_commands                   1.02   682.4±73.22µs        ? ?/sec      1.00   670.4±63.50µs        ? ?/sec
spawn_commands/2000_entities                             1.01   269.6±26.87µs        ? ?/sec      1.00   267.2±25.52µs        ? ?/sec
spawn_commands/4000_entities                             1.03   535.3±46.75µs        ? ?/sec      1.00   521.6±28.16µs        ? ?/sec
spawn_commands/6000_entities                             1.02   782.7±70.84µs        ? ?/sec      1.00  766.4±126.23µs        ? ?/sec
spawn_commands/8000_entities                             1.03  1020.1±109.07µs        ? ?/sec     1.00   992.9±51.14µs        ? ?/sec
```

On a deeper inspection, it seems like we're doing one extra copy on BlobVec moves:

Initial swap_remove_and_forget_unchecked swaps with the last element int the BlobVec
BlobVec::push then copies that last element into the target.

Ideally, we could just allocate in the target BlobVec first, get a OwningPtr targeting that element, and pass that pointer into swap_remove as a copy destination instead, eliminating the swap altogether.

bors try

I really don't want us to be adding miri exceptions this deep in the stack. Marking this as blocked on https://github.com/rust-lang/miri/issues/2181

Caved in: disabling the pointer based types in miiri tests for now via #[cfg(not(miri))], until the upstream issue is fixed with miri itself, as this issue seems to be pretty deep and likely might take a while to resolve.

Nevermind, this seems to impact pretty much every test moving data into or out of BlobVec, which involves pretty much every add/remove component test. Going to have to shelve this until that issue is resolved at least in nightly.

bors try

Revived this since there was an interest in optimizing the commands used in rendering. The components added/removed there can be quite big (140+ bytes), which lines up with some of the add/remove component benchmarks that saw a notable improvement here. Profiled this with tracy on many_cubes and saw a ~100us improvement in Prepare stage times and it directly corresponds to the improvement in commands perf.
Stage timings:

Command timings:

rust-lang/rust#104054 should fix the miri issue. Once this is ready in nightly, this PR should be mergable.

bors r+


feat: support dynamic metadata

This is a first pass at a scheme for supporting dynamic metadata in a generic way. It keeps everything as simple as possible by using entry-points with a very simple signature to provide each value. I am happy to discuss the proposed interface and make changes, but thought it would be best to get an implementation out there to have something concrete to discuss.
Scikit-build-core's settings have been extended to have an additional metadata field which is just an optional list mapping string keys to string values. For each entry in this list, if the key is also included in the project.dynamic list, scikit-build-core will look up an entry-point from the "skbuild" group where the name matches the value (entrypoint group is up for discussion, but Python doesn't seem to like hypens or underscores in the name for some reason). This entry-point should be a function that accepts the path to pyproject.toml (this seemed like a minimum but the final chosen signature is very much up for debate, for example, maybe the project root should be passed, and then the parsed toml file) and returns the entry that should be inserted into the pyproject["project"][key] entry in the loaded toml config.
Also included are a couple of core "plugins" which provide entry-points for setuptools_scm and hatch-fancy-pypi-readme, essentially just adapters as neither tool provides an explicit function matching the proposed entry-point signature.
For tests, I have created a fixture which mocks the entrypoints list with fake functions to give more direct control over what values we want to test. I have duplicated most of the "simplest_c" test package to allow the complete build process to be applied, but it is also possible to test with only a pyproject.toml file, and in fact most of the tests I have currently implemented do only use the pyproject.toml file and stop at testing the calculated metadata, although this can of course be changed. There is also a simple test for the setuptools_scm and hatch-fancy-pypi-readme plugins to make sure they are working correctly.
Adding setuptools_scm as a test dependency to test the plugin had the unexpected effect of making setuptools backend tests fail because of the file finder hook setuptools_scm provides which includes unexpected files (because they are under source control) in the sdist. To solve this, I have modified those tests to copy the package files to a temporary location before building so that the build source is not under git.

One thing I'm very curious about would be adding a function / hook that would read metadata from CMake. Not sure there's a good way to reuse the initial CMake run in this system, but you could run cmake, get the FileAPI output, then read it to get the version and such. Not required for an initial implementation, but something to keep in mind.

One thing I'm very curious about would be adding a function / hook that would read metadata from CMake. Not sure there's a good way to reuse the initial CMake run in this system, but you could run cmake, get the FileAPI output, then read it to get the version and such. Not required for an initial implementation, but something to keep in mind.

The way that I originally envisaged this was that the plugin entrypoint would return a dict of all the dynamic metadata that it knew how to generate, so perhaps both the version and the readme, for example. That would obviously fit better with running CMake in the hook, where you would probably only want to run it once to pick up all the metadata you wanted. You could still specify that a particular metadata parameter take its value from a different entrypoint though, if you had two plugins that both provided version, but you want version from one and readme from the other. Again, it makes sense to agree on this early on.
To be honest, I wonder whether this is a proposal which could become a PEP and part of the standard way to define dynamic metadata. It seems to me that with the proliferation of build backends, we are going to end up with plugins like setuptools_scm either having to write hooks to various different backends, or a whole bunch of adapter packages, whereas if we had a single specification that could be used to describe how to resolve dynamic metadata that would simplify the whole process. Backends could still offer their own custom interfaces as well, of course, but this simple pattern would at least be sorted out.

I like the idea of returning a dict with all metadata a plugin knows about, with it then being opt-in via the config. If you listed the same item twice, we could just run it once and pull both pieces of information from the return dict.
Writing a more general spec for multiple backends would be great, though we might want to have a proof of principle running first. This might be the only way Flit would ever gain support for dynamic versions. ;)

I am having some issues getting the constraints.txt file sorted out - bringing in the hatch-fancy-pypi-readme project adds hatchling as a dependency which in turn requires at least a bump of tomli==1.2.2, and apparently something else which pip has been working on my system for over an hour so far to try and resolve (and seems to be expected to take even longer based on some of the cancelled CI test runs). Obviously this is only a test time dependency unless the user wants to use the plugin, so perhaps it makes sense to pull the [test] extra from the constraints testing rather than bumping the minimum versions up higher than they are? Otherwise we probably need to add some extra minimum constraints on other test dependencies like build - I feel like setting reasonably recent version constraints on the test dependencies is more acceptable than the runtime dependencies?

You could (and maybe should?) make those tests importorskip on the packages (setuptools_scm & hatch-fancy-readme), then the minimal test could just not include them. That's probably a good idea also because some systems (like Spack) can't avoid leaking dependencies, and you never want to leak setuptools_scm, as it changes builds for packages that don't use it.

Ok, I think we are pretty close to something useful now. Sorry for the noise with the last few commits - I have been struggling with   mainly the minimum version tests where it turns out that we need at least pyproject-metadata 0.6.0 in order for the license information to get written out, as this is one of the metadata fields I was dynamically testing setting. All test envs are now passing except for one, with Python 3.8 on ubuntu-latest, where bizarrely the test_abi3_wheel test has started failing and I have no idea why. From the logs, the wheel is correctly built, and even installed, but then we get a PytestUnraisableExceptionWarning that seems to emerge from the subprocess.run() from executing the command in the venv. I am developing on Windows and don't have ready access to an ubuntu box to try and debug this, @henryiii do you have any ideas about what might be going on?

Ok, I figured out the problem, having setuptools-scm installed is what causes the test_setuptools_abi test to fail, but only on Py3.8 on Ubuntu, for some reason. My latest commit copies the ABI test directory out of the source tree before building it in the test, which fixes the problem, so it should now pass all tests. At this point we need to decide if we are happy with the current interface specification and usage, in which case I will draft some documentation to go with this change, and we should be pretty much done.

So, the first question: Why entry points over directly listing the module and function to call? If this was implemented in a PEP, I'd highly expect it would be something like this:
[project.metadata.plugins]  # ([tool.scikit-build-core.metadata] for now for us)
version = "setuptools_scm.dynamic:metadata"

(Where this was implemented in setuptools_scm/dynamic.py as metadata(...)). If we did something similar, we would obviously have to call scikit_build_core.<stuff> for our built-in methods, but if setuptools_scm or hatch-fancy-readme implemented this, there wouldn't be a conflict in entry point names, and it's a lot more likely we could talk these into providing a function somewhere with the right API than we could talk them into adding a custom entry point with scikit-build-core in it.
I think the main point of entry points is to allow something to automatically happen without opting into it, which we don't want - we want to explicitly opt-into dynamic metadata from a specific source.
Totally okay to be wrong here, just wondering if you've thought of this and if there's some special reason entry points are superior for this.

Second question: Do we want some way to for these to be able to declare dynamic dependencies? I don't think it's very important for now for metadata, but it's important for implementing a extension building plugin (extensionlib), and I could see some utility here too - for example, if we did implement such a system, we could use it to add dependencies automatically if you use the built-in plugins we provide. No need to request setuptools_scm or hatch-fancy-readme unless you were using their (eventual/hypothetical) implementation. Maybe a SCM plugin would want to add gitpython if git wasn't available, etc.
If we did want to do this, then we'd have a specification for the object that is pointed to by the entry above or by the entrypoint; maybe .__call__() (or we pick a required method name) is used for the normal usage, and if .get_requires_for_*() is defined, then those are supposed to be called and added to the build system's matching hooks.
That would be a followup I could do later if we did want it, though. The question really is, do we?

Last thought: It might be worth bringing this up with a few backend developers to see if they'd be interested in supporting such a design as a PEP.

Why entry points over directly listing the module and function to call?

What you describe is, of course, exactly what an entry point is under the hood. My thoughts:

using entry points is kind of a contract by the provider that they implement the required specification of the function call, so you know that any entry point you use is designed to be used in that way, as opposed to taking a random function and hoping it works correctly.
it is also a bit more convenient for a user to enter an entry-point name rather than a package:function string e.g. version=vcs-versioning instead of version=vcs_versioning:get_dynamic_metadata
with the modified plugin interface where we return a dictionary of metadata entries per plugin that is cached and used to lookup individual items that specify that plugin, it no longer makes sense to have functions like vcs_versioning:get_version. We could revert to the previous approach of returning a single metadata value, but would lose the ability to run e.g. CMake once and extract multiple pieces of metadata. Note that it is difficult to support both, because how do we tell the difference between a dictionary of metadata values and a dictionary as the value for one piece of metadata (I suppose we could make a generally good guess based on keys). That means that getting direct support from vcs-versioning et al. to provide their own implementations of our function, entry point or otherwise, are less likely unless it were to become a universal standard. (Follow-up thought, we could have a specification like vcs_versioning:get_version where we expect a single entry, or scikit_build.cmakemeta:get_metadata.version where we can specify a key of version from the returned value from the get_metadata() function, with the other values being cached against use in other dynamic metadata fields. That starts to get complicated, but is very flexible)
My thought for a PEP was perhaps to go directly into the dynamic list like:
dynamic = ["version=vcs-versioning", "readme=hatch-fancy-pypi-readme", "license"]]
(where license would in this case then have to be filled in via some other backend specific mechanism). That would work for either specification method, of course.

So I don't have strong feelings about that at all - happy to implement whichever solution is preferred.

Do we want some way to for these to be able to declare dynamic dependencies?

I believe that dependencies can be dynamic in the same way as other metadata. What you are proposing is more like appending to a list, rather than having one single source of dependencies the way that we do for e.g. version. We could special case the dependencies list (or indeed allow any field to have a list of entry points or package:function entries that would be merged) but it does become complicated when you start seeing different versions of the same dependency being requested, particularly if two plugins are asking, which one gets precedence etc. I would prefer to avoid this if possible. Also, I do not see it as a problem in general to have to add vcs-versioning to the [build-system]requires field if I want to use the vcs-versioning entry point for version, that avoids the potential for "dependency bleeding" that we have seen so much with setuptools-scm. I am happy to be persuaded of the need, but only if we can define how to handle all the edge cases.

should these plugins have access to config-settings?

I hadn't considered that, having not really used config-settings myself I had just ignored it so far. I suspect that they probably should, I can certainly imagine more complicated plugins like the putative CMake based one might like to allow some extra config values. Arguably just keeping everything in pyproject.toml is cleaner, put wiser heads than mine decided on the need for config_settings to start with, so we might as well pass it through. I don't think we would need to bother with validating it ourselves, it would be the job of a plugin to decide if the bits it cared about were valid (which is also true for pyproject.toml anyway).

It might be worth bringing this up with a few backend developers to see if they'd be interested in supporting such a design as a PEP

I completely agree, submitting this PR was the first step in that process, and hopefully involving @RonnyPfannschmidt and @hynek by trying to get them to agree to provide plugins directly will also give some guidance, but if you have any good contacts with backend developers then do invite them to get involved. Otherwise, I will probably open a few issues on e.g. hatch etc. to see if we get any interest.

Hatch has also some ideas around that
It would be nice if a common standard could be agreed on
Then all build tools could integrate common Metadata sources
I would recommend some reach out on the pypa discord, ideally setuptools and flit also join

exactly what an entry point is under the hood

Not exactly. An entry point is a mapping with several layers (and it's can be really slow to iterate over them due to file accesses if you have many of them - not that we'd be likely to, but this is why Jupyter can't use them).

random function and hoping it works correctly

You'd not take a random function any more than build-backend is a random function. You'd specify a location that follows the protocol we've defined.  I think most users would be more comfortable with something they can look up and investigate themselves, vs. an entrypoint that could come from anywhere. The main feature of an entrypoint is that you can iterate over all of them, which is useful for flake8/pytest plugins, but isn't a feature we are using here.
If we chose reasonable names, it could be exactly like how build-backend is now. Specifying a function name could be optional.

it no longer makes sense to have functions like

I'd follow the current approach, with caching if the same method is called for multiple metadata entries. There's still be one function that gets metadata, and returns all that it can. In fact, I don't think the implementation would change at all, other than removing the one layer of indirection and removing the question about the name's dashes vs. underscores.

perhaps to go directly into the dynamic list

This could break existing tooling reading the dynamic list. I think it would probably be more backward compatible as a new field a build backend could learn, rather than changing an existing one and forcing all tooling to adapt.

I believe that dependencies can be dynamic in the same way as other metadata.

Sorry, I wasn't clear - I meant allowing a plugin to have custom dependencies for itself - think adding "gitpython" to the get_requires_for_build_wheel hook if git is not installed, for example. This is very important for a plugin building binaries (allowing it to add ninja and cmake), not sure it it's all that critical for a metadata plugin. But maybe we could design metadata and extensions (extensionlib) to share the same interface.

I can make a PR to a PR to demonstrate the idea, or I can merge this then make a new PR to discuss it (since this is in a separate repo, the PR to PR would be in that repo).
PS: documentation is pretty light at the moment, since it's still in flux, so this doesn't need too much in the way of docs until we build all the docs, which will happen after editable installs are in.

You can see what I'm thinking in https://github.com/bennyrowland/scikit-build-core/pull/7.

This could break existing tooling reading the dynamic list.

Agreed, although a dynamic list as currently used would continue to be valid (and continue to expect some other mechanism to provide the actual value). I suspect you are right that a new field is probably necessary, it is just a bit less elegant because you end up specifying the dynamic fields twice (once in each field).

allowing a plugin to have custom dependencies for itself

I am afraid I still don't really understand what the issue that needs solving here is - surely if you want to use e.g. the vcs-versioning plugin then you add vcs-versioning to the [build-system]requires list in pyproject.toml. That would then install its own dependencies as normal. So if we created a CMake metadata reading plugin (as a standalone package), that would have cmake as a dependency, and install automatically. I will take a look at extensionlib and see if it makes more sense to me after that.

Ok, I now understand your point. Of course, if you are running on e.g. Android and don't have CMake, then your proposed plugin will try and install it at that point and fail anyway. I would probably approach that by having a [cmake] extra in the plugin, then users that want to install CMake independently can do that, and others can add the extra to the build-requires for the plugin. Running the plugin would then produce a message saying "can't find CMake, either install manually or add the cmake extra to your build-requires". Granted, this adds one level of complexity for users on a system where the CMake wheel is available, but it allows the metadata plugin system to be simpler at the same time.
I do agree that there may be other examples where the system you propose would be necessary for some use case, and I am not opposed to adding such functionality, particularly with the "module providing interface functions" paradigm, but I think we need to solicit some more opinions before writing that code.
Just a quick heads up also that I am away for the next week or so, so don't expect much progress on this PR during that time, but I haven't lost interest and will definitely get it finished as soon as I get back.

plugin, then users that want to install CMake independently can do that

This doesn't work, because the person that decides to put the plugin in pyproject.toml's build requires is not the person on WebAssembly or whatever that is trying to install it. And if they pip install cmake, that still doesn't work, since it's in an isolated environment and not in the host environment. And if cmake is listed, then it's never going to pass dependency checks, which will have all the package managers down our backs about shipping a fake "cmake" and "ninja" package that just silences those tests.
Checking to see if there's a system cmake/ninja and only requesting the Python package if they are not present provides an easy solution for these other systems - they can just make sure they pre-install these apps. And "normal" (wheel-supported) systems don't have to have them pre-installed.
This one of the key reasons to use scikit-build-core, since it auto-includes cmake and ninja using these hooks only if not present, enabling it to support all sorts of environments that often are not supported properly. It's also why I'm pushing forward with the 3.6 drop on scikit-build classic, so users can use scikit-build-core's include system with scikit-build classic if they want.
A "extension builder" plugin would clearly need to be able to do this as well. A metadata one, not so sure. The "cmake" one would likely only be used inside a system like scikit-build, which already ensures cmake is present. The git one is the only "realistic" example I can think of so far, and I don't think git packages are binary usually, so just having a dependency on a pure Python package wouldn't be that bad.
We don't need to think about or support this until working on a PEP, and then we'll have a lot more options and people with packaging experience that likely would be able to provide more input on this.

Checking to see if there's a system cmake/ninja and only requesting the Python package if they are not present provides an easy solution for these other systems

Small comment, if the user first installs scikit-build-core without having cmake installed (or having it bundled like with CLion), then it will install pip install cmake right? But then if they install cmake on the system (or want to link it to the CLion version for example), will scikit-build-core still default to the locally built version or would it still use the pip installed one?

No, scikit-build-core will never install cmake or ninja when you pip install it, they are not dependencies. It will only add those when called as a PEP 517 backend in an isolated environment. If the cmake or ninja packages are separately pip installed, though, it will use those versions over the system ones.

(The hook is get_requires_for_build_wheel, which is called by all PEP 517 builders in isolated mode - that gets to return a list of requirements for building and being a function, it is dynamic. There's also an sdist and editable version of that hook.)

Ok, so that hook would control how you get scikit-build-core within the pyproject.toml, which will be for the production packaging. That makes sense. But otherwise, for local development, if the user simply installs scikit-build-core on their own environment, it will not be fully functional unless they provide a cmake either from system or pip. And if they added it via pip then they can go back to the system by uninstalling it. Ok this makes sense, thanks for the clarification.
Maybe this point should be documented because it is not entirely intuitive.

Yes, exactly.
And documentation is planned. :) As soon as we get editable installs going, docs will be fair game.
This works exactly the same way in meson-python (ninja only, obviously).

I think we can merge this, and think about a couple of followups: a little docs in the README at least, and do we want to include the config-settings dict? Especially if we try to propose this as a more general mechanism.

I think that we may as well include the config-settings dict. Given that the PEP originally decided it was necessary for this kind of thing, it makes sense to follow the same path.
What is the current status of the docs now? I have seen a few commits going in recently referring to them, when do you expect they will be ready for adding this kind of content to?

Docs are being built on RtD now. No real pages yet, other than the README, changelog, and API docs. I'll be working on docs and editable installs off and on this week.
Do you want to add the config-settings pass through to this PR, then?

Thanks! I'll open a discussion to prepare a more general proposal.

Opened (as issue, actually, so I don't have to enable discussions in this repo) at #230.


MissingFileException: File '' could not be found while mvn cluecumber-report:reporting run

Describe the bug
Caused by: com.trivago.cluecumber.exceptions.filesystem.MissingFileException: File '' could not be found while mvn cluecumber-report:reporting run
To Reproduce
Steps to reproduce the behavior:

Add based plugin to pom
com.trivago.rta
cluecumber-report-plugin
2.0.0

report
post-integration-test

reporting

${project.build.directory}/cucumber-report
${project.build.directory}/cluecumber-report

Run tests and get .json result

Run  mvn cluecumber-report:reporting

Result: Go to the screen

I can be wrong with my settings and I will be grateful for the help.

Hi! This issue was fixed in version 2.0.1 but you are using the one before.
By the way, the most recent version is 2.2.0 🙂

It works! Thanks a lot!


Include include_global_state in Snapshot status API. Closes #3258.

Needs porting to 6.x and part of 6.2 release.
Relates to: https://github.com/elastic/elasticsearch/pull/26853
Example reference: https://github.com/liketic/elasticsearch/blob/ab0b127efd47b06aefea0eda27b99fd9d92abbe5/core/src/test/java/org/elasticsearch/action/admin/cluster/snapshots/status/SnapshotStatusTests.java

Ported to 6.x


Re-order Effects Blocks to Intended Order

For this I thought we could sort the preset.data.tone.dsp0/1 arrays using orderBy but apparently it doesn't work in Vue 2.x.  I couldn't get lodash's implementation to work for me.   But if we could sort by the '@position' key then we can print the blocks in order, including split/merge blocks for routing.
https://vuejs.org/v2/guide/migration.html#Replacing-the-orderBy-Filter
Ultimately, if we could draw two path's per DSP this would help and draw the blocks per the '@path' key.
I think this will work because there is ALWAYS a SPLIT and a JOIN key at the same level of each BLOCK.  It's just a matter of placing them in the correct position by the sort.  So I would include those in the sort, and with a simple IF for each object to check as we read the array.
Then add in the INPUTs and OUTPUTs afterwards and that should take care of routing, no?

Yep - sounds correct after reviewing the JSON structure. To start I'll update the rendering so that all blocks get split into their correct sub path (@path) - I think I'll need to refactor the path template a little.

Ok split into 4 paths for now - I can refactor the css a little later to make them "sub paths". May make it easier to draw path split lines as well - now just need to figure out how to sort.

Looking good so far.  Yea... that sort seems crucial.
I did notice that Stereo pre-amp may exist on both paths in the same position?  Or at least I have a preset that seems to have a position 4 for both paths.  So might also need to think about how to display that.

This one has position 4 on both paths of dsp0
Yin Yang.txt

Cool this will be a good preset to test with:

Looks like the block position count is always 8 - in this case it makes sense that the other speaker block is at position 4 so we can display it in the same spot according to it's position. For split/joins it looks like they appear just before or just after the block that is assigned to the same position number.
Slowly but surely the logic unravels :)

After spending way too much time trying to write a working sort function yesterday - I’m thinking now that I will try to use css/flexbox ordering - since each block is aware of its own position it may work...

Wow - Just looked up flexbox.   This could be the solution also!

Woah - looks like CSS worked! Will commit shortly.

Wicked!  Glad you're doing all the hard stuff :)


Review filterable dropdown component

Thomas Schlage implemented in Blockorder already a component that can filter multiple values for selection. Needs to be adapted to the latest Design System styles, and aligned with the filterable dropdown pattern.

@AdrianDampc Can you please check whether the Block Order implementation conforms to our latest spec?

@schluchter it fits latest spec for old tables. The only limitation is that all dropdowns in BO allow you to select only one option at the time.

This is wanted from us


Repo is just for PHP client issues. This is about the reCAPTCHA service.


Dev 0.4

Codecov Report

Merging #181 (a1c0b90) into main (d5b79fa) will decrease coverage by 15.48%.
The diff coverage is 5.85%.

:mega: This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more
@@             Coverage Diff             @@
##             main     #181       +/-   ##
===========================================
- Coverage   26.74%   11.26%   -15.48%
===========================================
  Files          70       35       -35
  Lines        2879     1269     -1610
  Branches      636      219      -417
===========================================
- Hits          770      143      -627
+ Misses       1568      914      -654
+ Partials      541      212      -329

Flag
Coverage Δ

unittests
11.26% <5.85%> (-15.48%)
:arrow_down:

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

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


Add tini deps for deb and rpm

This PR adds the missing build deps to the deb and rpm build Dockerfile's in the contrib/builder dir.

ping @andrewhsu @mlaventure PTAL as well

LGTM

hmm...with the latest 053738f commit I have issue building fedora-24 rpms:
$ time make DOCKER_BUILD_PKGS=fedora-24 rpm
...
Successfully built c663d6668485
docker run --rm \
        -v /go/src/github.com/docker/docker:/go/src/github.com/docker/docker/ \
        docker-manpage-dev
# github.com/docker/docker/api/server/httputils
api/server/httputils/httputils.go:85: enc.SetEscapeHTML undefined (type *json.Encoder has no field or method SetEscapeHTML)
Makefile:109: recipe for target 'manpages' failed
make: *** [manpages] Error 2
---> Making bundle: .integration-daemon-stop (in bundles/1.13.0-dev/build-rpm)
+++++ cat bundles/1.13.0-dev/build-rpm/docker.pid
++++ kill 5351
make: *** [rpm] Error 1

real    19m54.369s
user    0m2.931s
sys     0m0.985s

@andrewhsu looks like it has old Go version

@LK4D4 yes but it's within the manpages
why only fedora would fail ?

and it doesn't look like it's related to this PR to me

My bad, I think my build error is invalid. I was building off of crosbymichael's master branch instead of tini-deps branch.

LGTM once @andrewhsu builds are successful :angel:

LGTM
Totally works for me now:
$ time make DOCKER_BUILD_PKGS=fedora-24 rpm
...
Successfully built 0f7a3c015e21
RPMS/
RPMS/noarch/
RPMS/noarch/docker-engine-selinux-1.13.0-0.0.20161109.193335.git053738f.fc24.noarch.rpm
RPMS/x86_64/
RPMS/x86_64/docker-engine-1.13.0-0.0.20161109.193335.git053738f.fc24.x86_64.rpm
RPMS/x86_64/docker-engine-debuginfo-1.13.0-0.0.20161109.193335.git053738f.fc24.x86_64.rpm
SRPMS/
SRPMS/docker-engine-selinux-1.13.0-0.0.20161109.193335.git053738f.fc24.src.rpm
SRPMS/docker-engine-1.13.0-0.0.20161109.193335.git053738f.fc24.src.rpm
Untagged: docker-temp/build-rpm:fedora-24
Deleted: sha256:0f7a3c015e21ca03f137e1b3d359df4b39ded42b362c1ab25a674053947376c0
...


Set acceptable delay for ScheduledManipulator

To prevent auto practices to be run after the practice list is updated.

ac2f78f3aa3b1e4624e8ecf3a4a0dc8668b4c881


setExpanded not working

Initializing the parent ViewHolder with setExpanded wont work.
@Override     public void onBindParentViewHolder(OTDFavoriteBusRouteParentExpandableViewHolder otdParent, int i, Object o) {         OTDExpandableParent parent = (OTDExpandableParent) o;         parent.setExpanded(true);         otdParent.parentTitle.setText(parent.getParentTitle());     }
And isInitiallyExpanded does not exist.
Using 1.0.3

@poldz123 isInitiallyExpanded was introduced for our 2.0.0 release, a snapshot is available until we make a final release (should be this week)

Resolved in 2.0.0.


Default Mask option

Hi,
I wanted to know if you have a option to mask a component instead of hiding it when permissions does not satisfy.
I would need this since I want the user to see the particular component / element / button but cannot do any operation associated to it, and also would like to show an alert that they need to contact admin for required permissions.
In short similar to renderOtherwise is there renderMasked?.

Hi @praveenkutty,
I apologize for responding so late. Basically, there's no such functionality implemented. But you can create two components (one would be "masked"). Or to make it more reusable render the same component twice (with and without the masked prop).
Best,
Krystian


[AVM Module Issue]: Required version of azurerm is wrong

Check for previous/existing GitHub issues

[X] I have checked for previous/existing GitHub issues

Issue Type?
Bug
(Optional) Module Version
No response
(Optional) Correlation Id
No response
Description
Readme shows required version of azure rm as azurerm (~> 3.71)
Needs to be >= 3.105.0 to successfully run. Prior to that version  public_network_access_enabled is not a configurable attribute.

│ Error: Value for unconfigurable attribute
│
│   with module.postgres.azurerm_postgresql_flexible_server.this,
│   on .terraform/modules/postgres/main.tf line 14, in resource "azurerm_postgresql_flexible_server" "this":
│   14:   public_network_access_enabled     = var.public_network_access_enabled
│
│ Can't configure a value for "public_network_access_enabled": its value will
│ be decided automatically based on the result of applying this
│ configuration.

Thank you for raising this issue, it has been addressed by #15


References to ODBC 13  - which is now not supported on current OS's

This document refers/links to the ODBC 13 driver which is not supported on OS's past Server 2012 and SQL 2016 as per this article - https://docs.microsoft.com/en-us/sql/connect/odbc/windows/system-requirements-installation-and-driver-files?view=sql-server-ver16
This should probably be updated to utilise multiple options based on the OS and SQL version in use. This would also help address the "official supportability" question of if ODBC 18 (for example) is supported specifically with a RDS HA config.

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

ID: 5238c11b-240b-ff1c-42f1-8381048912f9
Version Independent ID: 98ec3637-8be0-5500-8b8d-cf1062c3271d
Content: Add an RD Connection Broker server to configure high availability in RDS
Content Source: WindowsServerDocs/remote/remote-desktop-services/rds-connection-broker-cluster.md
Product: windows-server
Technology: remote-desktop-services
GitHub Login: @lizap
Microsoft Alias: elizapo

We hugely appreciate your contribution, feedback, and support to our technical documentation.
We’ve phased out GitHub Issues on this repository as the feedback mechanism for content and have replaced it with a new feedback system. For more information see, Content User Feedback. As part of this rollout, we are migrating your issue where our team will use your comments to improve the documentation experience. Unfortunately, this does mean you won't be able to access this issue after the migration is complete.
All issues will be migrated by Thursday 29th August 2024.
Once again, thank you for your valuable feedback, we hope you’ll continue to contribute using our new feedback system.


C/AL Object/Text to Visual Studio Code

During the Dynamics NAV March webinar, a tool was demonstrated to convert existing NAV objects to VS Code.
Can you please identify where to find the Tool in the development preview.

The tool will be available in the April Update coming out later this month. More details about the tool will be available in the blog post announcing the release.

Thanks for the update.
Can you make the existing C/AL objects for the NAV 2017 development preview available in VS Code, this would assist in testing especially with reports.

You can have a look at some samples under c:\demo\new develop experience\AL if I remember correctly. If you change the name and ID you can deploy most of these samples from VS Code.
With the April Update you will be able to convert all of the base object using the conversion tool

@alanb999 does the vscode supports the reports and the menuisuite?

Extensions V2 in VS Code do support reports, see the docs.
Menusuites are not available, see the FAQ for more details


Publishing Policy Worksheet for Authors

NRG_Publishing_Worksheet_Griffith_1571679324_1.docx

[ ] Reporting Summary
[ ] License to Publish
[ ] Color Fee Form
[ ] Competing Interests Statement
[ ] Author Approval List  (if applicable)
[ ] Third Party Rights Table (if applicable)
[ ] Institutional Open Access Waiver (if applicable)
[ ] Inventory of Supplementary Information (required)

Requested review and signature from @obigriffith and @malachig on GriffithLab Slack.

This was completed and returned on Slack. Closing.


FCP template related changes

Introduce the FCP template concept into z/vm Cloud connector in order
to manage the FCP devices on z/VM.
These set of changes provide the lifecycle management APIs to FCP template
and allocation/deallocation of FCP devices based on FCP template.

Using PR https://github.com/openmainframeproject/feilong/pull/635 to merge fcp template related changes


indent_style is not working (showing auto even though I specify it)

Here's my .editorconfig file:
# EditorConfig sets a style guide supported by most editors:
# Get plugins here: http://editorconfig.org/#download
root = true

[*]
end_of_line = lf
insert_final_newline = true
trim_trailing_whitespace = true

[*.py]
indent_style = space
indent_size = 4

[Makefile]
indent_style = tab

[*.yaml, *.yml]
indent_style = space
indent_size = 2

As you can see, the indent_style is specified for different files.  I'm currently editing a .yml file but it indents with tab even though it should be with space.  When I check the state, I get this:
http://screencast.com/t/TlpAFiOxE
docker-compose.override.yml
The editorconfig was applied successfully and the editor for this file should work as expected. If you face any unexpected behavior please report us the issue. ♥

Active Configuration

Editorconfig-Property	Applied Setting
end_of_line	\n
charset	auto
indent_style	auto
indent_size/ tab_width	auto
insert_final_newline	true
trim_trailing_whitespace	true
max_line_length	auto
(auto: atom-editorconfig is not influencing that behavior. A full description of the properties can be found on editorconfig.org.)

Note that indent_style is showing auto even though I specify what it should be in the editorconfig file.  Please help!  I looked through all the issue threads leading up to https://github.com/sindresorhus/atom-editorconfig/issues/89 and it doesn't seem like this should still be an issue.

Hi @d3ming,
thanks for reporting this issue.
I need a listing of your file/directory-structure to be able to help you seriously.
However, you could try setting the yaml-section like this:
[*.{yaml,yml}]
indent_style = space
indent_size = 2

I know there were some issues with the glob-patterns, unfortunately we're not parsing the editorconfig-files ourselves but rely on https://github.com/editorconfig/editorconfig-core-js

Ah your suggestion for worked!
As for the directory structure, I was editing a the docker-compose.yml file in the root directory of a project that has the .editorconfig file that I pasted above.

project:

docker-compose.yml
.editorconfig

Thank you very much for your response! 🎁
I am sorry that the globbing didn't work as expected. We will see if the future changes that. I will close tis issue for now. If there is anything you'd like to add, feel free! ☕


mbed-cli is misinterpreting return codes from child tools

For example:
mbedgt: exited with code -10
[mbed] ERROR: "mbedgt" returned error code 246.

Here, mbed-cli has reported (unsigned)rc & 0xFF.

Bump
@bremoran @PrzemekWirkus @bridadan

I have no problems with changing greentea to return positive codes. But if we're changing return codes we should probably go ahead and document them at the same time :smile:
@mazimkhan Any chance we could get this work scheduled?

@bridadan @mazimkhan Any update on this?

Bump
This is causing our internal Jenkins environment to return false positives. One or more tests fail but python (mbed test) returns 0 which causes the job to report success instead of failure.
Seems to possibly be platform or test dependent. I have one platform where a RTOS test is failing and python correctly returns non-zero which causes the job to fail.
`
mbedgt: test case results: 156 OK / 1 ERROR
mbedgt: completed in 930.63 sec
mbedgt: exited with code 1
[mbed] Working path "C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test" (library)
[mbed] Exec "python -u C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test\mbed-os\tools\test.py -t GCC_ARM -m XDOT_L151CC -c --source C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test --build C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test\BUILD\tests\XDOT_L151CC\GCC_ARM --test-spec C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test\BUILD\tests\XDOT_L151CC\GCC_ARM\test_spec.json -v" in C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test
[mbed] Exec "mbedgt --test-spec C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test\BUILD\tests\XDOT_L151CC\GCC_ARM\test_spec.json -V" in C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test
[mbed] ERROR: "mbedgt" returned error code 1.
[mbed] ERROR: Command "mbedgt --test-spec C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test\BUILD\tests\XDOT_L151CC\GCC_ARM\test_spec.json -V" in "C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test"
C:\Users\Jenkins\workspace\mbed\platform-xdot-unit-tests\test>exit 1
Build step 'Execute Windows batch command' marked build as failure
Finished: FAILURE
`
Another platform has a RTC test that is failing, but python returns 0 and the job appears to succeed.
`
mbedgt: test case results: 162 OK / 1 ERROR
mbedgt: completed in 745.27 sec
[mbed] Working path "C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test" (library)
[mbed] Exec "python -u C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test\mbed-os\tools\test.py -t GCC_ARM -m MTS_DRAGONFLY_F411RE -c --source C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test --build C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test\BUILD\tests\MTS_DRAGONFLY_F411RE\GCC_ARM --test-spec C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test\BUILD\tests\MTS_DRAGONFLY_F411RE\GCC_ARM\test_spec.json -v" in C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test
[mbed] Exec "mbedgt --test-spec C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test\BUILD\tests\MTS_DRAGONFLY_F411RE\GCC_ARM\test_spec.json -V" in C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test
C:\Users\Jenkins\workspace\mbed\platform-dragonfly-unit-tests\test>exit 0
Finished: SUCCESS
`


SOAP - It is not possible to proxy a SOAP endpoint.

It is not possible to proxy a SOAP endpoint.  Is that by-design or is it easily overcome?

This seems to resolve my problem.  Now the proxy can GET using a "token" as a query string parameter.  It also required modifying proxy.ashx to not require /rest/ or /sharing/:
                else if (reqUrl.ToLower().Contains("/services/")) {
                    log(TraceLevel.Info," Adds support for WSDL-based endpoint");
                    infoUrl = reqUrl.Substring(0, reqUrl.IndexOf("/services/", StringComparison.OrdinalIgnoreCase));
                }
                else
                    throw new ApplicationException("Unable to determine the correct URL to request a token to access private resources.");

Hi @ca0v,
I'm curious about the use case for getting the token via SOAP instead of REST.  Is there a case when the REST endpoint isn't working for getting a token?

We have a legacy product that uses the SOAP endpoint and we want to prefix that endpoint with the proxy.  How would I use the REST endpoint without writing additional code?
The current solution configuration expects something like this:
<config geomservice="https://machine.acme.com/arcgis/services/Utilities/Geometry/GeometryServer"/>

But when that service is secure there's no way to setup a proxy and re-configure this endpoint like this:
geomservice="https://machine.acme.com/proxy.ashx?https://machine.acme.com/arcgis/services/Utilities/Geometry/GeometryServer"/>

So swapping in the /rest/ in the proxy does get a token using REST instead of SOAP but I can still proxy a SOAP endpoint.


Cannot find module 'ecctrl'" indicates that TypeScript cannot find the declaration file for the 'ecctrl' module.

I recently deleted the 'node_modules' folder and reinstalled the project. However, only the 'ecctrl' library is unable to find TypeScript type declarations. Below is my 'package.json' file. I hope to receive help and welcome any suggestions.
package.json

Which version are you currently using, and what version were you using before?

it seems like , i delete package-lock.json file case this probelm. version never change it aways is 1.0.75

i reback to my old package-lock.json and install . it work ok now!


Remove almost-offending giphy attachments

Seriously, although we had a good laugh, this is almost PEGI 18. My team thought I did it on purpose =_=

@Startouf the default rating seems to be set as "G", by any chance was the config changed in your app?
As an aside, I can confirm that the image is currently rated "r", although there doesn't seem to be a way to verify if this was changed since the image was uploaded:

I decided it's time to remove support for Giphy in #261, especially given the acquisition by Facebook. If anyone cares to do the work, go for it!

Support for GIFs was removed in #263.


AOT compilation fails with "unresolved external symbol __svml_log2_ha"

I'm trying to do AOT compilation for a Python module but keep running into the follow or similar errors:
error LNK2001: unresolved external symbol __svml_log2_ha
fatal error LNK1120: 1 unresolved externals

I also get similar errors but with log4, exp2, and exp4 in my project. There seems to be something missing in my build environment such that the SVML functions can't be found. I have tried changing cpu_target, adding intel and numba channels to conda, installing Parallel Studio from Intel etc.
Here's a minimal reproducible example:
import setuptools

import numpy as np
from numba.pycc import CC

cc = CC("min_ex")

@cc.export("foo", "f8[:]()")
def foo():
    z = np.ones(10_000_000)
    return np.log(z)

setuptools.setup(
    name="min-example", packages=setuptools.find_packages(), ext_modules=[cc.distutils_extension()]
)

My meta.yml file is as follow:
package:
  name: min-example
  version: "0.1"

source:
  path: .

requirements:
  build:
    - {{ compiler('c') }}
    - {{ compiler('cxx') }}

  host:
    - python>=3.7
    - setuptools
    - numpy>=1.14.6
    - scipy
    - numba==0.49

  run:
    - python

System Information:
Window 10
Anaconda (fresh install)
Intel® Xeon® Processor E3-1245 v5
VS Build Tools installed

Thanks for the report. Expect some SVML related things need passing into cc.distutils_extension() to provide the symbols. kwargs keys are:
extra_compile_args
extra_link_args
include_dirs
libraries
library_dirs

all of which are lists of strings. I think the SVML dll needs adding, does this get you started in debugging/fixing this?

I have located the svml_dispmd.dll which seems to include the missing function, but adding the folder path to include_dirs or library_dirs does not solve the linking issue. Not really sure how to proceed.

Did you try adding to the link line too, expect that'd be needed along with the library_dirs? extra_link_args=['-lsvml,'] or something? might be '-llibsvml', I don't recall the details of the windows linker from memory. See target docstring: https://github.com/python/cpython/blob/master/Lib/distutils/extension.py#L61-L65

Neither of the two args solved the issue. I have no experience with linkers in general, especially not the one for MSVC. Setting NUMBA_DISABLE_INTEL_SVML=1 to avoid using the svml instructions works, but I'm guessing there may be a performance hit.

Same issue for me. I have tried to add the path to the SVML DLLs with the library_dirs key, but the issue is not solved.

Ignoring the recipe for now, I've just tested this on a windows machine and cannot reproduce,  code compiles correctly. Questions:

Does doing python <your python code>.py build work?
What is the compilation environment, windows version, MSVC etc?

The icc_rt package provides SVML libraries and IIRC on windows it appears when NumPy is installed as numpy-base in the Anaconda distribution depends on it.

Trying a normal cc.compile() fails with the following LinkError:
Traceback (most recent call last):
  File ".\setup.py", line 16, in <module>
    cc.compile()
  File "C:\Users\handerss\Anaconda3\lib\site-packages\numba\compiler_lock.py", line 32, in _acquire_compile_lock
    return func(*args, **kwargs)
  File "C:\Users\handerss\Anaconda3\lib\site-packages\numba\pycc\cc.py", line 229, in compile
    extra_ldflags=extra_ldflags)
  File "C:\Users\handerss\Anaconda3\lib\site-packages\numba\pycc\platform.py", line 159, in link_shared
    extra_preargs=extra_ldflags)
  File "C:\Users\handerss\Anaconda3\lib\distutils\_msvccompiler.py", line 523, in link
    raise LinkError(msg)
distutils.errors.LinkError: Command "C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.25.28610\bin\HostX86\x64\link.exe /nologo /INCREMENTAL:NO /LTCG /DLL /MANIFEST:EMBED,ID=2 /MANIFESTUAC:NO /LIBPATH:C:\Users\handerss\Anaconda3\libs /LIBPATH:C:\Users\handerss\Anaconda3\PCbuild\amd64 /LIBPATH:C:\\Users\\handerss\\Anaconda3\\lib\\site-packages\\numpy\\core\\lib /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.25.28610\ATLMFC\lib\x64 /LIBPATH:C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\VC\Tools\MSVC\14.25.28610\lib\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\NETFXSDK\4.8\lib\um\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\ucrt\x64 /LIBPATH:C:\Program Files (x86)\Windows Kits\10\lib\10.0.18362.0\um\x64 python37.lib msvcrt.lib npymath.lib /EXPORT:PyInit_min_ex C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\min_ex.cp37-win_amd64.o C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\pycc\modulemixin.obj C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\pycc\../_math_c99.obj C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\cext\dictobject.obj C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\cext\listobject.obj C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\cext\utils.obj C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\Users\handerss\Anaconda3\lib\site-packages\numba\pycc\../runtime/nrt.obj /OUT:.\min_ex.cp37-win_amd64.pyd /IMPLIB:C:\Users\handerss\AppData\Local\Temp\pycc-build-min_ex-hqxsjwjb\min_ex.cp37-win_amd64.lib" failed with exit status 1120

Environment info:
Windows 1903 (19025.1051)
Tried with MSVC from the 2017 and 2019 build tools (vs2015 and vs2017 as the c and c++ compiler in conda).
Also tried adding the icc_rt package under host in the meta.yml, tried this with the intel anaconda channel too.

@stuartarchibald could you please paste the call to the linker (link.exe in MSVC) in order to see how the SVML libraries are linked?
Thank you!

@stuartarchibald  I have SVML libraries installed and they are correctly detected by Numba, given that they are used with @njit. However, if I carry out AOT compilation, I get the same linker error as @hnra.

I have found the solution to the issue.
The problem is that Intel SVML static library is needed. The icc_rt package only includes SVML runtime libraries (.dll on Windows), but for AOT compilation to work, static libraries are needed (.lib on Windows).
I have managed to download these libraries by downloading Intel Parallel Studio XE (trial version). Once the svml_dispmd.lib is located, it must be copied to a known folder, so the linker can search for it.
Finally, the extra keyword libraries=['svml_dispmd'] must be added in setup.py. This is working on Windows 10 with Python 3.8.2 and Numba 0.49.1rc1.

Why does numba need the .lib files for AOT but not JIT? Or does JIT detect that the lib files are missing and disable SVML?

Intel® Xeon® Processor E3-1245 v5

is a sandybridge chip. this may be interacting with our disabling of AVX on this chip.

Intel® Xeon® Processor E3-1245 v5

is a sandybridge chip. this may be interacting with our disabling of AVX on this chip.

My CPU is a skylake and I had the same issue

Has there been any updates on this issue?
@cmartinezdem could you share the svml_dispmd.lib file please.

Has there been any updates on this issue?

Unfortunately not no, any updates would have been posted to this issue.


⚠ Empornium has degraded performance

In bf97faa, Empornium ($EMP) experienced degraded performance:

HTTP code: 200
Response time: 4400 ms

Resolved: Empornium performance has improved in aaa09ea after 9 minutes.


DOC: Fix :ref: format

Change ref format from {ref}working-with-pytrees to :ref:working-with-pytrees.  The old version just renders literally,  not as a link.  It appears to be a markdown-style reference.  I'm not familiar with reST, but :ref: is how the other references are formatted.
Introduced in d1235fa (DOC: add key concepts doc).

@jakevdp


[explore] table viz should sort by first metric

it does for me, not sure what I'm missing...

i checked this locally and i'm not able to repro. when i looked at at hahn's slice in production tho, it didn't seem to be working. will have to get more details from her.

Oh I remember this, it's fixed


ng serve don't work on windows

run 'ng serve' command in terminal, but it only run in a while and then directly break.
E:\test_project>ng serve
** NG Live Development Server is running on http://localhost:4200. **
9013ms building modules
19ms sealing
2ms optimizing
0ms basic module optimization
260ms module optimization
1ms advanced module optimization
20ms basic chunk optimization
1ms chunk optimization
2ms advanced chunk optimization
0ms module and chunk tree optimization
96ms module reviving
4ms module order optimization
4ms module id optimization
5ms chunk reviving
1ms chunk order optimization
17ms chunk id optimization
87ms hashing
1ms module assets processing
173ms chunk assets processing
5ms additional chunk assets processing
1ms recording
1ms additional asset processing
1677ms chunk asset optimization
110ms asset optimization
49ms emitting
E:\test_project>

please the issue template so we can have more information about your environment.

I'm on windows 10, followed the MS guide and it works fine for me...
$ ng version
angular-cli: 1.0.0-beta.21
node: 7.0.0
os: win32 x64

I do everything on Windows, haven't come across this issue yet. I think it must be something in your environment.
If you can find a way to repro on other machines, I'll gladly reopen and investigate.


Integrate LLVM FileCheck in our test infrastructure

We have a lot of tests that are based on stringent string comparisons, and maintaining the expected results for these test has become a huge burden as we develop new IR features that changes the way we emit final code.
LLVM FileCheck is a tool that allows us to specify patterns to verify against in a result text file and can signifacantly reduces the chances that a test will break in case there is a irrelavent change in the file. We can build it as a part of slang-llvm library and use it for our cross-compile and diagnostics tests.

This is done.


jsx shouldn't throw an exception for trailing bytes

:jsx.decode(<<"{} {}">>) will throw an ArgumentError exception.
it would be more useful to return a tuple with what it could decode and the rest
{Obj, Rest}

there's now an option for this. see https://github.com/talentdeficit/jsx/pull/83


Extra escape characters being added to strings

When strings include "'s, slashes, etc., escape characters are being added when written out and should not be needed.

Raptor library parses literal strings in n-triples encoding of unicode. See https://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntrip_strings.  This raises the question, what is the proper encoding for standard RDF/XML?
A limited solution based on regular expressions to convert ntriples encoding down to ascii is implemented in bed25631587addabb2e0310e2ee3f2864b2c7086.  Test files now pass, but this may not be a comprehensive solution.

I’ve checked with an RDF validator and both with and without escape characters are valid.  My feeling is whatever is read should be preserved on write.  The strings should not be modified during a read/write process.  So, if escapes are present, they should be kept, if not, they should not be added.

On Jan 17, 2017, at 10:26 PM, bbartley<EMAIL_ADDRESS>wrote:
Raptor library parses literal strings in n-triples encoding of unicode. See https://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntrip_strings https://www.w3.org/TR/2004/REC-rdf-testcases-20040210/#ntrip_strings. This raises the question, what is the proper encoding for standard RDF/XML?
A limited solution based on regular expressions to convert ntriples encoding down to ascii is implemented in bed2563 https://github.com/SynBioDex/libSBOL/commit/bed25631587addabb2e0310e2ee3f2864b2c7086. Test files now pass, but this may not be a comprehensive solution.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub https://github.com/SynBioDex/libSBOL/issues/123#issuecomment-273320615, or mute the thread https://github.com/notifications/unsubscribe-auth/ADWD90AXdzTAa-Qf7mwGdPHllCumy2Jmks5rTUAggaJpZM4LhMND.


⚠ Bofrost.be has degraded performance

In b0db596, Bofrost.be (https://www.bofrost.be) experienced degraded performance:

HTTP code: 200
Response time: 2440 ms

Resolved: Bofrost.be performance has improved in 03ca530.


common/htime: Fix localization of abbreviated month names

Fixes #11267

Thanks @jmooring @bep, that was fast!


Remove 5 second munging of command timeouts

This is a revert of 2bbbd2a9 which doesn't make sense to have anymore. As a user, I expect the timeout I give to the command will be what I set in the resource.
Signed-off-by: Lance Albertson<EMAIL_ADDRESS>

Figured there was a 50/50 I was going to click on that link and see my name. Dodged that one

Released as: 11.1.0


Clarify the use of basedOn

comments by @costateixeira
basedOn should only be used (see description in standard) if the ServiceRequest is a request to (partially) fulfill another request (in our case a proposal).
If we want to link a prolongation (order/proposal)  to a previous prescription we need an extra extension

Why do we need an extra extension ? Can you please explain ?

@Mcobbaert @annenerenhausen It is about semantic interoperability. ServiceRequest.basedOn (http://hl7.org/fhir/R4/servicerequest-definitions.html#ServiceRequest.basedOn) refers to another item that is being fulfilled by this one. It can thus refer to a proposal, careplan, ... . A prolongation of a request does not fulfill the other request, it is an addition to the other request. That is semantically different. Therefore we propose a new extension.

WG: "replaces" will be used for prolongations -> see the detailed comments in the standard. "basedOn" will be used in case of a proposal, reference to a Careplan, or any other prior resource that causes this request. "duplicate": is still open.

WG: in case of a "duplicate", we don't need the link between the new ServiceRequest and the ServiceRequest it is based on. So we can drop the third option.


catalog view - move all buttons to top

In the ISV's catalog view - we must move all buttons to top space of that respective area in order make them uniform with other pages.

[ ] update, unregister button of service details
[ ] refresh and add button of service policies.

I'll take this.


squirrel-sql: use supported JRE

Description of changes
The current version of squirrel doesn't support the current default JRE in nixpkgs (19). Since this is a property of squirrel-sql, changed it in squirrel-sql's default.nix.
Things done

Built on platform(s)

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

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

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

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

[ ] (Package updates) Added a release notes entry if the change is major or breaking
[ ] (Module updates) Added a release notes entry if the change is significant
[ ] (Module addition) Added a release notes entry if adding a new NixOS module

[ ] Fits CONTRIBUTING.md.

/cc @khumba

Hello @raboof,
Have you seen [1]?  The current version of Squirrel, the Java parts at least, do actually support Java 19 (as announced in the release notes[2])...however the launcher scripts are out of date and as far as I can tell just need to have newer version numbers added to a version check.  I mean to add a patch for this, but it fell off my radar, so thanks for the reminder.  Do you mind if we continue with this approach instead?  I think it would be preferable to forcing users to have an older, extra JVM on their systems.  I've created a PR for this fix: https://github.com/NixOS/nixpkgs/pull/235096
Thanks!
[1] https://github.com/NixOS/nixpkgs/pull/209299#pullrequestreview-1246995881
[2] http://www.squirrelsql.org/#latestnews


How to generate a image signature

Hi!
Imagemagick generate a image signature (properties -> signature) with command "magick identify", like this example
$ magick identify -verbose rose.jpg

  Properties:
    jpeg:colorspace: 2
    jpeg:sampling-factor: 1x1,1x1,1x1
    signature: aea65c9b557d779d142f26d04abe7008bab50f1e9647faae20afdcc6c15140d5
  Image: rose.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Mime type: image/jpeg
  Class: DirectClass
  Geometry: 70x46+0+0
  Units: Undefined
  Type: TrueColor
  ... others props ...

Is it possible to have/generate same signature with sharp?

I hope this information helped. Please feel free to re-open with more details if further assistance is required.


Unable to install/enable Virtual Machine Platform

I'm on build 19008.  Whenever I try to install/enable Virtual Machine Platform I get a green screen (attached).  I did not install either Windows Subsystem For Linux or Virtual Machine Platform prior to this attempt, on any previous versions of Windows - this is the first time.
I am able to successfully enable Windows Subsystem for Linux and install a distro.  It is only Virtual Machine Platform that causes the green screen.  I've updated all my drivers and there are no "!" alerts in Device Manager.  I've unplugged all peripherals.  Nothing seems to work.

tmcomm.sys is not owned by Microsoft, it is the Trend Micro Internet Security driver by Trend Micro.

You're right, my bad - I didn't see the "What failed" line.  I've disabled that, and now I get a green screen that does not have the line "What Failed", but the same Stop Code: PAGE_FAULT_IN_NONPAGED_AREA.  Like I mentioned, I've updated all my drivers and I have no alerts in device manager, so I'm stumped as to what else could cause this on my end.

I've disabled Trend Micro

Disabling generally has little effect on kernel drivers.

would it make a difference if I tried booting into Safe Mode and installing it from there?

Dunno if WSL runs in safe mode. Even if it did, if WSL ran successfully, you'd learn: "there is some third-party thing installed in the kernel that is faulting". Which you already know.

Thanks so much for the feedback, I sincerely appreciate it.  I'll get rid of Trend Micro and give it a shot!

A quick follow-up: uninstalling Trend Micro fixed the issue.  I haven't tried reinstalling Trend Micro yet.


How do I successfully generate signed URLs to cloud storage objects when using workload identity federation?

TL;DR

Some of my tests generate signed URLs to Google Cloud Storage objects, but this does not work with workload identity federation
My GitHub CI workflow uses workload identity federation to authenticate, which has worked fine with all other cloud operations carried out in the tests
The tests pass when using an actual service account file locally

Expected behavior
The signed URLs to be generated normally
Observed behavior
As seen here, I get the following failed test
ERROR: test_create_signed_url (tests.cloud.storage.test_client.TestGoogleCloudStorageClient)
Test that a signed URL to a cloud object can be created and used to access the file.
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/tests/cloud/storage/test_client.py", line 323, in test_create_signed_url
    url = self.storage_client.generate_signed_url(
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/octue/cloud/storage/client.py", line 280, in generate_signed_url
    return blob.generate_signed_url(expiration=expiration, **api_access_endpoint)
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/.tox/py/lib/python3.8/site-packages/google/cloud/storage/blob.py", line 621, in generate_signed_url
    return helper(
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/.tox/py/lib/python3.8/site-packages/google/cloud/storage/_signing.py", line 396, in generate_signed_url_v2
    signed_query_params = get_signed_query_params_v2(
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/.tox/py/lib/python3.8/site-packages/google/cloud/storage/_signing.py", line 80, in get_signed_query_params_v2
    ensure_signed_credentials(credentials)
  File "/home/runner/work/octue-sdk-python/octue-sdk-python/.tox/py/lib/python3.8/site-packages/google/cloud/storage/_signing.py", line 52, in ensure_signed_credentials
    raise AttributeError(
AttributeError: you need a private key to sign credentials.the credentials you are currently using <class 'google.auth.identity_pool.Credentials'> just contains a token. see https://googleapis.dev/python/google-api-core/latest/auth.html#setting-up-a-service-account for more details.

Action YAML
https://github.com/octue/octue-sdk-python/blob/main/.github/workflows/python-ci.yml
Log output
https://github.com/octue/octue-sdk-python/runs/6006955054?check_suite_focus=true
Additional information
I found this similar issue for the google-cloud-go package and attempted some of the solutions, but they didn't work.

Hi @cortadocodes
Thank you for opening an issue. When using an exported service account key, the URL is signed with the private key embedded in the service account (there's no API to GCP). When using WIF, there is no private key material stored locally, so you need to use the iamcredentials API's signBlob function to generate the signature.
This process is documented in the GCS documentation for signing:

Your programming language should have a library for performing RSA signatures. Alternatively, you can use the IAM signBlob method provided by Google Cloud if your expiration time is 12 hours or less.

So the algorithm is:

Build the canonical request
Build the string to sign
Sign it with signBlob
Concatenate to the URL

Unfortunately it doesn't look like there's a native function in the Python SDK to do this yet.
Does that make sense?

Thank you for your quick reply @sethvargo! That makes sense. Do you know if there will be a native function in the python SDK anytime soon to do this?

Hi @cortadocodes - I'm not sure. It would be best to file an issue against the Python library directly: https://github.com/googleapis/python-storage

Hi @cortadocodes
I'm going to close this out. Let me know if you need any more assistance!


Add PPC64 and s390x testing to Travis

This commit adds PPC64 and s390x testing to Travis.
Signed-off-by: Jeffrey Walton<EMAIL_ADDRESS>

Hi, Jeffrey.  Thanks for the patch!
The one thing here though is that since Travis CI practically dropped support of OSS projects, we had to switch to GitHub Actions and remove the Travis integration from the main repository. We left the yml file for the time being just in case someone else has a Travis account and uses it for testing.
At this point Travis CI is not part of our actual CI and therefore no-one is tracking if it still works.  This means that adding new architectures will not help us to avoid their build breakages.
If you want to have PPC64 and s390x arches added to the yml, so you personally can test them periodically, that is OK, and I can accept this patch if you promise that it works. :)  Otherwise, it doesn't have a big value for the project as we don't have a way to actually run these checks.

Thanks @igsilya,

If you want to have PPC64 and s390x arches added to the yml, so you personally can test them periodically, that is OK, and I can accept this patch if you promise that it works.

Ah, sorry to hear that. Travis got me too. I lost testing on about 6 open source projects. I got so fed up with Travis I had Travis delete my accounts and I removed access to my GitHub.
So yeah, it is probably better to close the request.


Move CSV stats printer gevent spawn up a few lines

Resolves https://github.com/locustio/locust/issues/2075
The problem is that if --headless is used with LoadTestShape then the  stats_csv_writer greenlet is never spawned. By moving the gevent.spawn(stats_csv_writer.stats_writer) part up a few lines I think it solves the problem? Let's wait for the tests 🙏

All checks have passed

Alllriiight 🎉

Nice


fix(centerTour):fixed tour bug

#614
@wski @rkenyon1969 @clarkjefcoat

Duplicating the entire tour seems like a very bad idea for long term maintainability. Let's investigate this further and see if we can't fork the bootstrap tour library and fix the error all together.


Retain MCTS tree in memory

closes issue  #153

At retention stage of tree the Grid.getCopy() method provides a grid where the remaining tiles are depleted to 0, despite there being many tiles left empty on the board.

Test required for getCopy()
Test required for getRemainingTiles()  (difficult atm due to private method)

C value over 1 seems to drill down to very deep. 0.5 is currently providing some decent results.


Move HsDocString to ByteString in time for GHC-8.6!?

I already have a WIP patch moving HsDocString from FastString to ByteString at https://github.com/sjakobi/ghc/commit/c4066e2160c28a60ac9e36ded1d8eb3ba45a3d0d.
As this does seem to help with performance I'm wondering if there was a point in doing this switch already in GHC-8.6.
Obviously this also requires changes to haddock-api. But as I'm only seeing 4 places where HsDocStrings are deconstructed, I think this should be doable in these time constraints.
What do you think about this?
The corresponding GHC ticket is https://ghc.haskell.org/trac/ghc/ticket/15157.

Do it! But do it fast the merge window is closing slowly but surely /cc @bgamari


waybar popups shown behind windows even when set layer to top

archlinux
waybar 0.9.13-2.1
hyprland r1918 (latest git at this moment) or 0.16.0beta-1

// waybar-clock
    "clock": {
		"interval": 60,
		"align": 0,
		"rotate": 0,
        //"timezone": "America/New_York",
        "tooltip-format": "<big>{:%B %Y}</big>\n<tt><big>{calendar}</big></tt>",
        "format": " {:%H:%M}",
        "format-alt": " {:%a %b %d, %G}"
    },

    "include": "~/.config/waybar/modules",
    "name": "main-bar",
    "id": "main-bar",
    "layer": "top",
    "mode": "dock",
    "exclusive": true,
    "passthrough": false,
    "position": "top",
    "output": "eDP-1",
    "height": 36,
    "width": "",
    "spacing": 6,
    "margin": 0,
    "margin-top": 0,
    "margin-bottom": 0,
    "margin-left": 0,
    "margin-right": 0,
    "fixed-center": true,
    "ipc": true,

Sway already has this pull request merged. May be releavant

They already said the layer is set to top

cant even repo, lol

The waybar version is said above btw.

i still dont know what's v0.9.13-2.1 but it still doesnt happen to me on the official waybar package on the community repo.

That is the wrong version. Tried 0.9.13-1 and git version (right now), the same.

tried "passthrough":true, but still doesn't work

If the layer popups render below windows, it's safe to assume waybar is NOT on the top layer (you can see for yourself that it is not with hyprctl layers)
This means that this is purely your fault (either misconfiguration or forgetting waybar does NOT hot-reload the config and you need to restart it)

If the layer popups render below windows, it's safe to assume waybar is NOT on the top layer (you can see for yourself that it is not with hyprctl layers)
This means that this is purely your fault (either misconfiguration or forgetting waybar does NOT hot-reload the config and you need to restart it)

Firstly I've checked that no layer is set in modules. Then the config file. Then I killed and restarted waybar. Then hyprland layers.
I don't think that is the case.

You can clearly see waybar is on layer 1 which is the BOTTOM layer, when it needs to be on layer 2, which is the TOP layer:

Since the layer is decided 100% by the app itself, it's an issue in your config without a shed of doubt.

You can clearly see waybar is on layer 1 which is the BOTTOM layer, when it needs to be on layer 2, which is the TOP layer:

Since the layer is decided 100% by the app itself, it's an issue in your waybar config (or an issue in waybar, but it works without any for me) without a shed of doubt.

I've figured out why. Setting "mode": "dock" causes the issue. Since it's quite confusing even after reading waybar wiki, maybe you can add it to the document.

That's down to waybar, no clue why we should make waybar's docs for them

That's down to waybar, no clue why we should make waybar's docs for them

https://wiki.hyprland.org/FAQ/#waybar-popups-render-behind-the-windows
here

You can clearly see waybar is on layer 1 which is the BOTTOM layer, when it needs to be on layer 2, which is the TOP layer:

Since the layer is decided 100% by the app itself, it's an issue in your waybar config (or an issue in waybar, but it works without any for me) without a shed of doubt.

I've figured out why. Setting "mode": "dock" causes the issue. Since it's quite confusing even after reading waybar wiki, maybe you can add it to the document.

had the exact same issue, any chance on adding this to the documentation?
I know this is up to waybar but still would have been nice to know

make a pr to the wiki it's a public repo?

You can clearly see waybar is on layer 1 which is the BOTTOM layer, when it needs to be on layer 2, which is the TOP layer:

Since the layer is decided 100% by the app itself, it's an issue in your waybar config (or an issue in waybar, but it works without any for me) without a shed of doubt.

I've figured out why. Setting "mode": "dock" causes the issue. Since it's quite confusing even after reading waybar wiki, maybe you can add it to the document.

Was having the exact problem and fixed it by changing "mode" to "mod". I'm pretty sure this isn't the right way but hey, works.


Missing Zip framework and some magic after adding that

Hello,
I installed framework with attached documentation with Carthage. After adding code, when I want to run project, app stops and shows problem:
dyld: Library not loaded: @rpath/Zip.framework/Zip
  Referenced from: /private/var/containers/Bundle/Application/.../Frameworks/iOSDFULibrary.framework/iOSDFULibrary
  Reason: image not found

OK, project want to add Zip.framework. Nope.
After adding marmelroy/Zip framework, Xcode returns errors with redefinition od module 'minizip'. I checked that - Zip and IOS-Pods-DFU-Library using minizip and there is problem.
/.../Zip/Zip/minizip/module.modulemap:1:8: error: redefinition of module 'minizip'
module minizip [system][extern_c] {
       ^
/.../IOS-Pods-DFU-Library/Example/Pods/Zip/Zip/minizip/module.modulemap:1:8: note: previously defined here
module minizip [system][extern_c] {
       ^
<unknown>:0: error: could not build Objective-C module 'Zip'

Any solutions?

I fixed that 👍


Migrate Magnifier to Lit

[x] Convert JS to Lit
[x] Convert CSS to be extendable
[x] Create description page

Implemented in https://github.com/YuraVolk/Js-Library/commit/23adb8cbe6d269979645a6e1f862adb65eb56d0a.


[ignore] something

Signed-off-by: perdasilva<EMAIL_ADDRESS>

/hold just trying to see something

/retest


Syncing Items to Notion

When syncing from Zotero I get following Error Message:
TypeError:
this.itemProgress.setlcon is not a
function
It does not seem to interfere with the syncing progress since everything I want to have synced is being synced, however the error messages are quite annoying since they stay around and stack on top of each other. When trying to remove the error message it always switches back into the Zotero App which further hinders workflow.
This happens when manually syncing via right click -> Sync and also while automatically syncing, it does not seem to pop up for every sync while syncing multiple items however

Im using the Advanced Notero template and have the latest Zotero and Notion Update. Im on Mac OS Sequoia.
Thanks in Advance

Hi @DavidTetz, this sounds like #500 which was fixed in Notero v0.5.16. Can you check to see if you're on the latest version of Notero?

Hey @DavidTetz, Notero supports syncing notes as page content in Notion. Please see the Syncing Notes and PDF Annotations section of the README for instructions on how to use it, and let me know if you have any questions!

Issue is fixed and notes are syncing, thanks a lot!! One Last question, is there a way to make the notes appear in the table like the other properties? 😀

I created #590 to track the request for syncing notes as a database property.


Improve PA advection coefficient handling

Speed up the evaluation of coefficients like VectorGridFunctionCoefficient for the velocity field of ConvectionIntegrator in the PA assembly by batching over all integration points in each element.
Change the handling of discontinuous velocity fields in PA assembly of DGTraceIntegrator to match that of the legacy integrator (always evaluate velocity in "element 1").
Properly handle PA upwinding of the density coefficient according to the velocity field.
Add unit test to ensure the PA results match the legacy results.

PR
Author
Editor
Reviewers
Assignment
Approval
Merge

#1745
@pazner
@tzanio
@YohannDudouit + @tzanio
09/08/20
⌛due 09/22/20
⌛due 09/29/20

Merged in next for testing...


fix script reference in dev html

Script was renamed to be consistent in when packaged, but forgot to update the corresponding dev index.html test page. Addendum to #59
I've also updated the readme for #61

Great, thanks!


chore: add crd categories

with this patch, you can get all eg resources with following command:
kubctl get envoy-gateway

Maybe also add the gateway-api category?

I think we should different with upstream.


[DO NOT MERGE] Upload Brakeman output to GitHub Code Scanning

Saves the output of Brakeman runs to a sarif file and uploads it to GitHub Code Scanning.
Only merge this after permissions have been added to all repos that use this workflow. (Example)
https://trello.com/c/AFw2LOkY/3457-integrate-brakeman-findings-with-github-code-scanning-5

pro tip: GitHub's draft feature is a better "do not merge" flag, cos it actually prevents accidental merging (and saves renaming / keeps the PR title clear and readable in lists)

pro tip: GitHub's draft feature is a better "do not merge" flag, cos it actually prevents accidental merging (and saves renaming / keeps the PR title clear and readable in lists)

Thanks, I meant to make it a draft but forgot


feat(quantic): Added disableDynamicNavigation in quanticRefineToggle and quanticRefineModalContent components

SFINT-5087
This PR is linked with this ticket: https://coveord.atlassian.net/browse/SFINT-5044
We are passing the disableDynamicNavigation property to support a new (yet to be added) Dynamic Navigation Experience config in the Hosted Insight Panel

Other than me wondering why there's so many files changed for just 1 small thing, everything looks good?
Might want to set the default value like I suggested so you don't have to type "true" all the time.

🤣  11/18 files are due to e2e tests and I believe 4 files were affected by the templates used thats why... Got to love e2e...


Fix: cli allow name with dash

If create page/stream/nano/component with name include hyphen/underscore/space will throw error

This fixes #40


[enhancement](query exec) should print error status when query meet error

Proposed changes
Issue Number: close #xxx
Problem summary
If BE is in heavy load, the query may failed, but BE will try to connect to FE using thrift, if FE is also in heavy load the thrift connection will failed. And the status is rewritten at line 342, and the actual failure reason for the query is lost. Should print the error status every time during update.

Checklist(Required)

[ ] Does it affect the original behavior
[ ] Has unit tests been added
[ ] Has document been added or modified
[ ] Does it need to update dependencies
[ ] Is this PR support rollback (If NO, please explain WHY)

Further comments
If this is a relatively large or complex change, kick off the discussion at<EMAIL_ADDRESS>by explaining why you chose the solution you did and what alternatives you considered, etc...

run buildall

TeamCity pipeline, clickbench performance test result:
the sum of best hot time: 33.42 seconds
stream load tsv:          451 seconds loaded<PHONE_NUMBER>9 Bytes, about 158 MB/s
stream load json:         24 seconds loaded<PHONE_NUMBER> Bytes, about 93 MB/s
stream load orc:          71 seconds loaded<PHONE_NUMBER> Bytes, about 14 MB/s
stream load parquet:          30 seconds loaded 861443392 Bytes, about 27 MB/s
https://doris-community-test-1308700295.cos.ap-hongkong.myqcloud.com/tmp/20230331051907_clickbench_pr_123250.html


Version 2

Drop support for Go version less than 1.16
Upgrade golang-jwt/jwt to v4
Update tests to run on Go 1.17.x and 1.16.x

Pull Request Test Coverage Report for Build<PHONE_NUMBER>

0 of 0   changed or added relevant lines in 0 files are covered.
No unchanged relevant lines lost coverage.
Overall coverage remained the same at 92.55%

Totals

Change from base Build<PHONE_NUMBER>:
0.0%

Covered Lines:
1205

Relevant Lines:
1302

💛  - Coveralls


Keep trailing newline

Configures Jinja2 to keep a trailing newline when rendering templates. Removing those causes some really subtle problems with certain config files, e.g. ssmtp.conf just ignores the last line if the trailing newline is missing.

This could be the default. This let users total control over the generated file without j2 interfering.


Add 'scaffold' task to generate metadata and tests for a library

What does this PR do?
Adds a task to create metadata and tests.
Run with gradle scaffold --coordinates com.example:my-library:1.0.0.
Closes #88.

The CI is broken as it uses the default java version (which is not 17). I used java 17 features in the task. See https://github.com/oracle/graalvm-reachability-metadata/pull/97/commits/9a74417813fdda3b2337c47e8ebbc827f8fcc10d

Looks great.

The CI is broken as it uses the default java version (which is not 17). I used java 17 features in the task. See https://github.com/oracle/graalvm-reachability-metadata/commit/9a74417813fdda3b2337c47e8ebbc827f8fcc10d

@mhalbritter I am not sure to understand why the CI is broken despite 9a74417813fdda3b2337c47e8ebbc827f8fcc10d, and I don't think it will be merged until this is fixed. Could you please elaborate on this?

Yes, this is my understanding, but I'm confused why my change from https://github.com/oracle/graalvm-reachability-metadata/commit/9a74417813fdda3b2337c47e8ebbc827f8fcc10d isn't applied to this PRs pipeline.

@mhalbritter can you try with setup-graalvm? It'd be great if as many GraalVM bits as possible are tested with GraalVM JDK.

I've update the CI to use setup-graalvm. The CI still fails, and now I'm quite sure that the CI takes the config from master, as there's a 3rd step ("Validate library and framework list"), which is not in my branch.

The CI should be trying to build the merge of this PR into master. It seems that the JSON validating job fails because it's using a JDK that doesn't support records?

I've rebased your branch and added https://github.com/oracle/graalvm-reachability-metadata/pull/97/commits/77203858848b20d848e783a5ae2ac9c4fe1f77ae and, more importantly, https://github.com/oracle/graalvm-reachability-metadata/pull/97/commits/67a706173054c3d3f55b0c9e5a3147ecd423ca17.

I've rebased your branch and added https://github.com/oracle/graalvm-reachability-metadata/pull/97/commits/f3d052df653ccfcc4e6b403e97c7735f50853376 and a few other commits.

Ok, now this is blocked by missing permissions...let me get that fixed...

I'm just curious, after the current PR is merged, will another PR modify the content of CONTINBUTING. md ?

Ok, now this is blocked by missing permissions...let me get that fixed...

That's now working.

I've squashed the commits and the CI is green, too. Ready to merge from my side.

I will merge this PR, but just one note: I refactored usage of coordinates across the project with this pr #54. Once that PR is ready to be merged, I will probably refactor some parts here as well.

I'm just curious, after the current PR is merged, will another PR modify the content of CONTINBUTING.md ?

I've updated the CONTRIBUTING.md.


Fix for Sensibo with missing temperature

Description:
Fix for Sensibo climate with missing target temperature.
Related issue (if applicable): fixes #10767
If the code does not interact with devices:

[x] Local tests with tox run successfully. Your PR cannot be merged unless tests pass
[ ] Tests have been added to verify that the new code works.

Is it certain that
https://github.com/andrey-git/home-assistant/blob/bb92f271c15099b244f5338762a85fefe0bf4b2b/homeassistant/components/climate/sensibo.py#L206-L208
are not run if the _temperatures_list is set to empty? If so, that will raise an exception.

@tinloaf That code searches for targetTemperature in the array. Since it is not there - index will be -1

Oops, missed the -1 after the len(…) . :+1:


Parameterize PKI certs location

For manual PKI exchange, certificates are stored under 'cert' directory inside workspace by default. This PR decouples the location of certificates from workspace in that the user can now specify certificate path to store certs which can reside outside the workspace.

For CA, cert_dir can be passed, where all CA certs and keys can reside. To store signing-ca.crt, certificate chain (cert_chain.crt) and signing-ca.key, use cert_pathand key_path   to specify locations.
For both aggregator and collaborator, use cert_path and key_path to store aggregator (or collaborator) certificate and key, respectively.
Introducing fx workspace participants that let's the CA/aggregator select a subset of certified collaborators for a federation by modifying plan/cols.yaml.

@mansishr can you please resolve the conflicts and request for review again?


CFFL

CFFL

Linter check found the following problems:
The following problems have been found:
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:31: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:33: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:34: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:35: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:36: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:37: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:38: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:39: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:41: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:43: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:44: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:45: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:47: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:48: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:48: host_section_needs_exact_pinnings: Packages in host must have exact version pinnings, except python build tools.
ERROR: /tmp/abs_82nybisiw6/clone/recipe/meta.yaml:86: http_url: http://kivy.org/ is not https
Errors were found