Initial psABI atomics specification

Define an ABI for RISC-V atomics that allows for eventual migration to the Table A.7 mapping in the unprivileged architecture spec. Our main spec differs from A.6 only in that it requires an additional fence in the  store(..., memory_order_seq_cst) instruction sequence.
We believe that the Table A.7 mapping, together with the new instructions it requires, will be necessary to be performance competitive with other architectures for seq_cst operations, especially for processor designs similar to current out-of-order mobile cores. Starting with the ABI described here will allow some platforms to completely avoid an ABI break when switching to A.7. Platforms that already have code compiled to (unmodified) A.6 will get more time to gradually replace that code in preparation for such a switch.
More discussion can be found around https://lists.riscv.org/g/tech-unprivileged/message/382 .

We have prototypes for LLVM out for review.
https://reviews.llvm.org/D149486
https://reviews.llvm.org/D149488

Gcc patches to implement this version of the atomics ABI were just committed by Patrick O'Neill, See<EMAIL_ADDRESS>for the final discussion of strengthened seq_cst stores.

LGTM in the sense that the text does what it claims (copying across table A.6 with the change of the additional fence for a sequentially consistent store).

As discussed in one of the LLVM patches, I am extremely concerned about the prospect of breaking the atomics ABI that has been employed by LLVM for years and many releases, and do not believe the model should be slowed down by additional fences that aren’t necessary for the current ABI unless we are absolutely sure we want to take on the pain of introducing concurrency bugs that are hard to reproduce, hard to debug, go away when recompiling, etc.; having broken atomics is a world of hurt.

Re: Jessica's comment:
I understand the concern. This has certainly been discussed before. The goal here is precisely to avoid future breakage. Here's where I'm coming from:

AFAICT, there are currently relatively few production RISC-V systems that care about ABI stability, at least relative to what I would expect in the future. (That's certainly true for Android, which I work on, where the first number is currently zero. I'm not counting very large numbers of embedded systems without major software ecosystems.) Corollary: Any breaking ABI changes are much easier now than later. Informed conjecture: We're talking about slightly difficult vs. nearly or completely impossible.
The psABI document did not contain an atomics ABI. The atomics implementations in gcc and llvm were inconsistent and incompatible until now, so there was no real stable ABI. The Table A.6 mapping in the architecture spec was the closest to one, and I assume the one that's under discussion here.
There appears to be a consensus that we need essentially the table A.7 mapping to get good portable performance in the future. I particularly want to see as little overhead as possible for sequentially consistent and acquire loads. Commonly used idioms like double-checked locking rely on that. And it is already quite common to code around performance issues in this area with ugly hacks. Thus I don't want to regress from the current situation on x86 and ARM where these operations are commonly cheap, and rapidly getting more so. (There exist implementations of other architectures on which "fence rw,rw" is close to free, and there is no need to move to A.7. But that is nowhere near true on most existing mainstream systems that care about ABIs.)
The RVWMO work in the architecture spec also considered A.6 to A.7 compatibility, and partially addressed it, but seems to have overlooked the issue addressed here (?) (I wasn't part of that effort, so I'm guessing.) Thus Table A.6 and A.7 in the architecture spec are incompatible. This proposes a minimal fix and otherwise adheres to A.6. Without this fix, an eventual change to A.7 would be far more difficult. And it's hard to see how it would avoid significantly more breakage.
This "strengthened A.6" mapping here is compatible with "A.6 classic". (Except for the aqrl -> aq optimization, which I suggested delaying where it matters.) If an existing implementation moves from "A.6 classic" to "strengthened A.6" to A.7, the only problem is if "A.6 classic" code still coexists with A.7. There is some danger of that. It increases as we delay.

Of course, if anyone has technical disagreements with any of this, please discuss.

This atomic change is definitely an ABI incompatible change - since it is inconsistent with existing LLVM and GCC implementation; so one intuition solution is adding a flag to indicate the atomic implementation, e.g., adding a new flag EF_RISCV_ATOMIC_ABI_V2 to e_flags; However, the unfortunate fact is that current LLVM and GCC*1 are implemented differently, so adding a new flag doesn't help the situation IMO.
RISC-V GCC got several feedbacks in past years that indicate there might have some potential issues with atomic sequence (hard to reproduce and confirm, so I use might); however, we never fixed that since all RISC-V GCC maintainers are not an atomic expert.
That might be a little bit like a word game, but I am treating this as a bug fix for atomic stuff rather than an incompatible change from the RISC-V GCC aspect.
Unfortunately, we didn't standardize the atomic sequence before, and now it's time to standardize and fix the incompatible issue between different compiler implementations.

My understanding is that the preferred atomic sequences were effectively standardised in table A.6 of the ISA spec, though it's since been decided the psABI spec would be a better home. LLVM implemented that table, but GCC's atomics implementation predated it. I think it was hoped that GCC's atomics implementation lowering was just stronger than required, but it sounds like there's actually compatibility issues.
I defer to the experts on the merits of compatibility with the A7 table vs the cost of slightly longer instruction sequences). But this proposal seems to have involved multiple RISC-V implementers who haven't voiced concerns.

LLVM implemented that table, but GCC's atomics implementation predated it. I think it was hoped that GCC's atomics implementation lowering was just stronger than required, but it sounds like there's actually compatibility issues.

The GCC patch notes suggest that previous implementation also had some subtle correctness issues, which is why the patch was accepted as a bug fix rather than just a change to the ABI.  Since they already had to break ABI w/ the previous implementation to fix the bug, the rationale seems to be that they would rather just limit future breaks.  GCC's implementation was (and still is) ABI incompatible with the one in LLVM, and that is going to become a source of subtle bugs.

It's worth emphasizing that this is not an ABI break for implementations that used A.6 (since renumbered, but let's stick with that name), i.e. LLVM. This is A.6 with an additional fence to avoid a future ABI break. There appears to be a consensus that we're moving to A.7 eventually. (Since there is/was and A.7 in the ISA spec, that seems to have been anticipated.) A.6 to A.7 is unavoidably an ABI break. The goal of this proposal is to minimize its impact.
This version minimizes the impact of that unavoidable ABI break in two ways:

It avoids it for environments that haven't yet shipped to production, and minimizes it for those ramping up.
It gives us a much longer transition period, making the transition feasible for systems currently using A.6. A.6 is compatible with this proposal, and this proposal is compatible with A.7. We just need to make sure that A.6 code doesn't mix with A.7 code.

I'm not sure whether that was the intended meaning, but I would disagree that the eventual switch to the "A.7" atomics ABI is a minor performance improvement.
From my perspective, probably the most common and convincing reason for using atomics, rather than lock-based synchronization, in production code is to avoid cache contention among readers for read-mostly data structures. Most accesses require acquire-like semantics which, in standard-conforming code, rely on acquire or seq_cst code, depending on the language, etc. (Dependency ordering sometimes suffices, but can't really be used in portable code.)
Based on the ARM Cortex microbenchmark results posted in https://lists.riscv.org/g/tech-unprivileged/message/382, the current mappings are significantly off the mark compared to what could be expected from the A.7 mappings, at least based on current out-of-order ARM processors. In the seq_cst case, we're adding on the order of a dozen cycles to what's probably the most common atomics operation, and one that (in the uncontended cache hit case measured here) normally takes much less than that.
Granted, this is muddied up a bit by large hardware and application differences. But I would expect this is easily the most significant atomics performance issue we're likely to encounter, possibly outside large system LR/SC scalability issues. The fact that we're adding a penalty someplace where ARM and x86  commonly don't have much of one, is particularly painful.

I'll just point out that:
* FreeBSD uses LLVM as its system toolchain

* FreeBSD has supported RISC-V since its 12.x release, but as of 13.x it is a Tier 2 architecture (only amd64 and arm64 are Tier 1) (https://www.freebsd.org/platforms/)

* For Tier 2 architectures, "the ABI should not be broken gratuitously" (https://docs.freebsd.org/en/articles/committers-guide/#_tier_2_developmental_and_niche_architectures)

* Minor performance improvements for atomics may or may not be gratuitous

Though you agree that the change in this PR isn't actually an ABI break? It just (from my perspective) makes a potential future ABI break less disruptive my providing forwards compatibility. Even if FreeBSD opted not to change to something based on the A.7 mapping, the improved compatibility with that table could still be an advantage to users compiling code for the system (if the benefit outweighs the cost of slightly longer lowerings in some cases).

The proposed LLVM patches are not an ABI break, but they add pointless overhead if the ABI is not later broken to move to A.7, therefore they should only be applied for FreeBSD if FreeBSD is willing to break ABI for this.

The proposed LLVM patches are not an ABI break, but they add pointless overhead if the ABI is not later broken to move to A.7, therefore they should only be applied for FreeBSD if FreeBSD is willing to break ABI for this.

I think there probably are reasons to go ahead with it even if there's no interest in a future ABI break:

Avoids alternate codegen paths for different architectures, which might not be a cost worth paying if the performance difference is minimal.
Allows more flexibility for users of the target platform, as they can compile their own userspace code with A.7 and have it be compatible with other libraries compiled against the strengthened A.6. (I suppose you could describe this as users choosing to "break" the ABI, but it's still an option they'd have they wouldn't have with the old A.6 lowerings).

What do you think is the path forwards for this proposal?

To be clear about the concern here: we're worried about FreeBSD packages that will not get recompiled between the LLVM change, and when enough load-acquire store-release capable hardware appears to make the A.7 mapping interesting? My presumption is that interval (unfortunately, in other respects) will be measured in years.
Are you worried about having to recompile those packages during those years, or not detecting the incompatibility if you miss one? I think the latter could be addressed fairly easily with some kind of ELF annotation to record ABI conformance, something that was suggested in a comment in earlier versions of this pull request. I'd welcome such an addition. I'm not enough of an ELF expert to suggest the right way to do this.
I think there are strong arguments for keeping these conventions consistent not only across compilers and languages, but also across mainstream operating systems. Otherwise not only would default compiler configurations have to vary by OS, but something like OpenJDK's JIT compiler would have to generate different code depending on which OS it's running on, so that it interacts fully correctly with platform JNI code. This does mean that e.g. gcc's mapping conventions effectively matter, even on a platform that only uses clang/llvm.

My concern is that it is a userspace ABI break, which must be suitably justified for a Tier 2 architecture in FreeBSD.

I updated the PR, as planned. The new version gives a single set of mapping tables, with multiple compatible mappings for some of the C++ constructs. Some of those mappings are marked as not implementable without new instructions, and some are marked as incompatible with "A.6 classic". Aside from the marked "A.6 classic" issues, unrestricted mix-and-match is allowed. This changes the presentation into a format that I like better. And it sounded like it might be better received here. It is not intended to change the actual described mappings, except perhaps by making some options and relationships more explicit.

We currently don't have an agreed upon mapping for Ztso so I'm not sure what we would include as the TSO mappings. There was some discussion on the GCC mailing list about A.7 compatibility of Andrea Parri's proposed mappings. The mapping proposal does not include the discussed changes for A.7 compatibility.

I think we should try hard to minimize the number of "ABIs" we define here to keep it as clear as possible what new code should do, and to maximize the degree to which code interoperates.
I'm happy to define additional properties of generated code that can be mentioned in the ELF flag specification. This is kind of similar to defining additional ABIs, but it makes it clearer that the alternative conventions are not ABIs that should be exposed to users by new systems. There is (for atomics ) one ABI, and there are also legacy compatibility issues.
Ignoring TSO for now, I agree we need 2 ABI compatibility flag bits, which I would define something like the following:
Define "legacy compatible" as "conforms to this ABI and does not use Note 3 mappings". I can add that definition to this PR. Then the 4 possible values are:

unknown, no compatibility guarantees at all. (E.g. old gcc-generated code.) By implication, this does not use Note 3 mappings.

uses a combination of ABI compatible  mappings, as defined here, and the old seq_cst store mapping without trailing fence. (Effectively A.6, current clang code)  By implication, this does not use Note 3 mappings. It's free to use any other mappings here, even if they weren't originally in A.6. (I think that's currently only the store->amoswap mapping, which was mentioned before, but not actually in A.6.)

"legacy compatible"

May use any mapping listed here. (Or compatible mappings added in the future.)

Each one is compatible with itself. ( (0) really isn't, but that's water under the bridge, and best ignored.) (1) is compatible with (2), and (2) is compatible with (3). All other pairs, particularly (1) and (3) are incompatible. I expect gcc to (continue to) migrate (0)->(2)->(3) and clang to migrate (1)->(2)->(3).
I would hope that we do not need to extend this in the future. And, in the absence of some terrible bug, I wouldn't expect us to be able to agree on such an addition once we have a much larger number of ABI-sensitive systems deployed. I expect that we will add relevant instructions, which will add mappings to the table. Some of these will need Note 3 because they are also incompatible with A.6. Some of them may not fully follow RVWMO rules, and will need fences to hide that fact, basically following the current model for IO. But I don't expect them to introduce new kinds of atomics compatibility issues that would prevent linking to older code. Thus such new code should continue to be labelled as (3), or possibly even (2).
Future extensions may need some way to ensure that they are only used on hardware with the right kind of support, but I think that's orthogonal to what we're trying to do here?
It seems to me that we can also make TSO fit into the above framework, though I haven't followed the recent discussion there: The current table has some rows that are only valid with additional hardware extensions (in this case the load-acquire/store-release one). Similarly we can add rows to the table that are only valid with Ztso, and will thus typically involve shorter instruction sequences. (These would probably be presented as another table, but they're not logically distinct.) But whenever they are supported by hardware, they are compatible with the rest. Thus TSO does not introduce another ABI in my current sense. (Though I still think there may be some ecosystem fragmentation issue.) This would argue that the "TSO bit" is really something different from the two "atomics ABI" bits discussed above.
It sounded like the TSO mappings are still in flux? But if someone wants to point me at the consensus set, and we agree that they should go here, I can attempt that integration.

@patrick-rivos

We currently don't have an agreed upon mapping for Ztso so I'm not sure what we would include as the TSO mappings. There was some discussion on the GCC mailing list about A.7 compatibility of Andrea Parri's proposed mappings. The mapping proposal does not include the discussed changes for A.7 compatibility.

Thanks for correction, I guess I have such wrong impression is because it's ratified and LLVM has landed some code gen.

@patrick-rivos

We currently don't have an agreed upon mapping for Ztso so I'm not sure what we would include as the TSO mappings. There was some discussion on the GCC mailing list about A.7 compatibility of Andrea Parri's proposed mappings. The mapping proposal does not include the discussed changes for A.7 compatibility.

Thanks for correction, I guess I have such wrong impression is because it's ratified and LLVM has landed some code gen.

ztso remains behind an experimental flag, so the partial codegen changes that were merged in LLVM are very explicitly not considered stable, and are open to change as the mappings are agreed.

@hboehm
For A6C mapping into table:
My intention is I don't want to make A.6 (Classical) mapping implementation (e.g. existing LLVM stable releases) is look like ABI noncompliance, but I agree minimize the number of "ABIs", so I think we could mention the A.6 (Classical) when we describe those flags.
For TSO:
Yeah, let's skip that for now, and integrate into this table once it settle down.
For flags:
Will update https://github.com/riscv-non-isa/riscv-elf-psabi-doc/pull/385, and that move the flag related discussion their.
@asb @jrtc27 want to make sure again it looks good to you from the view of LLVM / FreeBSD.

@asb @jrtc27 want to make sure again it looks good to you from the view of LLVM / FreeBSD.

The main thing I'm checking from an LLVM perspective is that the text concerning the compatibility with the old a.6 table (and hence the compatibility with the current LLVM implementation) is sufficiently clear. Looks good to me.

@hboehm For A6C mapping into table: My intention is I don't want to make A.6 (Classical) mapping implementation (e.g. existing LLVM stable releases) is look like ABI noncompliance, but I agree minimize the number of "ABIs", so I think we could mention the A.6 (Classical) when we describe those flags.

do you have a specific suggestion for the text here, so we can move forward with the llvm change?

awesome, thanks! (timed well to match our preliminary ABI announcement at the risc-v summit in barcelona today :-) )


Error in building cheddar-cdm

When building cheddar-cdm, I get an error:
...\Cheddar-workspace\Cheddar-master\cheddar\cheddar-cdm\build\generated\jaxb\com\clicktravel\schema\canonical\data\model\v1\common\Error.java:1: Line does not match expected header line of '/*'.
error.java looks like this:
//
// This file was generated by the JavaTM Architecture for XML Binding(JAXB) Reference Implementation, v2.2.4
// See http://java.sun.com/xml/jaxb
// Any modifications to this file will be lost upon recompilation of the source schema.
// Generated on: 2015.07.08 at 02:37:22 PM CEST
//
package com.clicktravel.schema.canonical.data.model.v1.common;
import java.io.Serializable;
import javax.xml.bind.annotation.XmlAccessType;
import javax.xml.bind.annotation.XmlAccessorType;
import javax.xml.bind.annotation.XmlElement;
import javax.xml.bind.annotation.XmlType;
/**

Java class for Error complex type.

The following schema fragment specifies the expected content contained within this class.

That is Checkstyle complaining about a lack of copyright banner text at the top of the source file. This error should not occur as we've configured Checkstyle to ignore JAXB generated source files, see https://github.com/ClickTravel/Cheddar/blob/master/config/checkstyle/suppressions.xml I suspect this is a Windows/*nix incompatibility. Can you confirm you are compiling in a Windows environment?

Indeed, I am compiling on a windows environment.
thx

Adding

to the

node of
master/config/checkstyle/suppressions.xml
is in fact the only thing you need to do to fix the project for Windows.


Creating a gotest framework

I saw in the README you are hoping to get some tests going eventually, and I could tell the pretty glaring complexity in how could you test throw-away gitlab environments not on your workstation or using the managed service.
So I tinkered with Travis-CI and Docker-Compose, and I have something that might intrigue you. Within the build environment a docker container of gitlab-ce is spun up using Omnibus configurations to set an initial root password. Then the tests that need to authenticate against the API can do a quick Oauth shake to get a PAT generated. Then on to the rest of your tests.
=== RUN   TestGoodRunEngine
2018/05/10 13:01:17 TEST: Retrieving test gitlab oauth token
2018/05/10 13:01:17 TEST: Succesfully retrieved test gitlab oauth token: fba4bd3cfeeaa2e38f98652b8bc36cf2060fd3fca8c54b0a9ff56fc432e42a9e
2018/05/10 13:01:17 TEST: Retrieving test impersonation token
2018/05/10 13:01:17 TEST: Succesfully retrieved test gitlab impersonation token: y7vps5XHnz3JLS8nNdda
2018/05/10 13:01:17 INFO Retrieving default configurations
2018/05/10 13:01:17 INFO Parsing configurations from environment
2018/05/10 13:01:17 INFO Validated credentials
--- PASS: TestGoodRunEngine (0.40s)

My repo: https://github.com/tinyzimmer/gitlab-crawler - the docker-compose and .travis.yml are the nuts and bolts.
https://github.com/tinyzimmer/gitlab-crawler/blob/master/engine/gitlabclient_test.go - line 94 is the function that uses the temporary root password to get the Oauth token. I may have looked over it, but I didn't see a raw credentials call in go-gitlab yet, not that you'd really ever want it except just for this.
If you like this idea I'm happy to help get those tests written and we could use Travis to offload the work. Let me know what you think.

Hi @tinyzimmer! This sounds like a really good plan 👍
I do notice that you only spin up one container, so wouldn't just docker run ... work as well? And it so happened that there was an open issue for using this package with a username/password so I was just wrapping up adding that to the package (just merged it).
So now you can just create a new client with username/password and it will manage fetching and refreshing the token for you 😀

Can definitely just use docker run. That's how I was initially tinkering with it at home. Just think the compose file looks cleaner is all and is baked into travis so why not 😛

Yeah, agree on that...

I'll get a fork goin over the weekend

Does this mean that the existing Test suites will poiny the api call to the running local Gitlab?

In our gitlab-cli project, https://github.com/devopsctl/gitlabctl, we use a local gitlab instance to test our commands. This way, we are doing a unit test and some sort of integration test as well.
We have testdata, curl scripts that populates our Gitlab instance. See the .travis.yml for reference.

Any updates on this one @tinyzimmer? If looking to do an end-of-year cleanup on stale issues, so if you abandoned this issue I'm going to close it before the new year starts :wink: So please let me know if this is still work in progress. Thanks!

Crap. I got busy with a new job a while back and haven't been getting as
much exposure to Gitlab these days. You can probably just close the issue.
My apologies.
On Thu, Dec 27, 2018, 3:50 AM Sander van Harmelen<EMAIL_ADDRESS>wrote:

Any updates on this one @tinyzimmer https://github.com/tinyzimmer? If
looking to do an end-of-year cleanup on stale issues, so if you abandoned
this issue I'm going to close it before the new year starts 😉 So please
let me know if this is still work in progress. Thanks!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
https://github.com/xanzy/go-gitlab/issues/391#issuecomment-450136815,
or mute the thread
https://github.com/notifications/unsubscribe-auth/AksSM7tFS4pDg4fyb6xobCVDeBvmYbpCks5u9LQRgaJpZM4T533V
.

No problem at all! Same here actually :wink: Enjoy your holidays!


How to change month with code

I did not find how to change the month part with code.

Hi @barisatalay you can change the current month using setCurrentMonth method of AUCalendar object

i used setCurrentMonth,but when i scroll to next it jump to first month


layer-shell: Move surface to desired layer

TODO: Update the submodule version

Yes this is, I just haven't worked on Way Cooler for a little while now. I tend to work on Way Cooler in bursts (as is evident by this graph) so I plan to get back to this when I feel like it.


Directives doesnt get processed

Hi,
first I tried using the timepicker and it didnt work (I copyed the exact code from the example).
Now I am trying to use accordion and it doesnt work too.
At the moment I am using modal and datepicker too and both of them work great.
But when I use directives with custom html tags they dont get processed.
I have included the following files:
bower_components/bootstrap/dist/css/bootstrap.min.css
bower_components/angular-bootstrap/ui-bootstrap-tpls.min.js
bower_components/angular-bootstrap/ui-bootstrap.min.js

And my accordion markup is very basic:
<uib-accordion>
  <uib-accordion-group heading="Lorem ipsum dolor sit amet">
    <p>
      Lorem ipsum dolor sit amet, consectetur adipisicing elit.

      Facere nobis ipsum temporibus quidem expedita qui placeat,
      et aspernatur incidunt ex debitis, voluptatum fuga facilis
      porro, dicta at, dolor vitae officiis.
    </p>
  </uib-accordion-group>
</uib-accordion>

My app is grouped into several subpages. Each page has an own Controllers-Module.
These modules are registered as depenencies in an main app.js to the app module.
And in the app module ui.bootstrap gets registered as a dependency, too.
And the rendered Markup in Chrome is exactly the same.
So why does the markup does not get processed but modals and datepickers work?

+1 same thing happening for me

+1, even the simplest  is not processed
(I'm trying to use this in a Rails app)

Since there is no plunk demonstrating the problem which makes it extremely difficult to help resolve problems.
I'm going to take a guess at what the problem is and close this issue.  You are loading both the templates package (bower_components/angular-bootstrap/ui-bootstrap-tpls.min.js) and the non-template package (bower_components/angular-bootstrap/ui-bootstrap.min.js), you should only be loading 1, most likely the package with the templates - bower_components/angular-bootstrap/ui-bootstrap-tpls.min.js

Found it: 'uib-' prefix was added just a month ago.
I'm using a Rails gem that has not been updated, so it uses just <accordion> not <uib-accordion>.

Same issue here. This from bower.json
"version": "1.1.1",
"main": ["./ui-bootstrap-tpls.js"],

And I have this in a directive template
        <uib-accordion>
            <uib-accordion-group heading="Area x">
                Location Y
            </uib-accordion-group>
            <uib-accordion-group heading="Area x">
                Location Y
            </uib-accordion-group>
            <uib-accordion-group heading="Area x">
                Location Y
            </uib-accordion-group>


logctx: sub-loggers should only replace the logger in a child context

Ran into an issue where tracing info in the context was being discarded when creating a sub-logger.

Closing while waiting on: https://pkg.go.dev/context@master#WithoutCancel


[bug] [v2] Cargo assertion failure during consecutive Tauri builds

Describe the bug
I've just migrated my project to tauri v2 and cargo fails to build the project because of the following assertion mtimes.insert(output.clone(), mtime).is_none()
This only happens in consecutive builds. The first build after running cargo clean always works. The rebuild triggered by saving a file while tauri dev is running, fails the same way.
These errors occur on both windows & liunx with the same behavior.
Reproduction
You can find the project itself at https://github.com/fabiankachlock/zwoo
Follow these steps to reporduce:

Clone the repo: git clone git@github.com:fabiankachlock/zwoo.git
cd ./zwoo/frontend
checkout the branch git checkout feat/ZWOO-458-migrate-tauri
yarn (install frontend deps)
yarn vite --mode tauri --port 8070 (start frontend)
yarn tauri dev should work fine the first time, but running it a second time fails

Expected behavior
The project builds just fine even after consecutive calls to tauri dev/build or saving a file while tauri dev is active.
Full tauri info output
The windows machine:
[✔] Environment
    - OS: Windows 10.0.22631 X64
    ✔ WebView2: 123.0.2420.97
    ✔ MSVC: Visual Studio Community 2022
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (bbb9276d2 2024-03-08)
    ✔ Rust toolchain: stable-x86_64-pc-windows-msvc (environment override by RUSTUP_TOOLCHAIN)
    - node: 20.11.0
    - pnpm: 8.15.6
    - yarn: 1.22.19
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.15
    - tauri-build [RUST]: 2.0.0-beta.12
    - wry [RUST]: 0.39.1
    - tao [RUST]: 0.27.0
    - tauri-cli [RUST]: 2.0.0-beta.13
    - @tauri-apps/api [NPM]: 2.0.0-beta.8
    - @tauri-apps/cli [NPM]: 2.0.0-beta.13

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist-tmp
    - devUrl: http://localhost:8070/
    - framework: Vue.js
    - bundler: Rollup

The linux machine:
[✔] Environment
    - OS: Linux Rolling Release X64
    ✔ webkit2gtk-4.1: 2.44.1
    ✔ rsvg2: 2.58.0
    ✔ rustc: 1.77.2 (25ef9e3d8 2024-04-09)
    ✔ cargo: 1.77.2 (e52e36006 2024-03-26)
    ✔ rustup: 1.27.0 (2024-03-12)
    ✔ Rust toolchain: stable-x86_64-unknown-linux-gnu (default)
    - node: 20.11.1
    - pnpm: 8.15.6
    - yarn: 1.22.21
    - npm: 10.2.4

[-] Packages
    - tauri [RUST]: 2.0.0-beta.15
    - tauri-build [RUST]: 2.0.0-beta.12
    - wry [RUST]: 0.39.1
    - tao [RUST]: 0.27.0
    - tauri-cli [RUST]: 2.0.0-beta.10
    - @tauri-apps/api [NPM]: 2.0.0-beta.8
    - @tauri-apps/cli [NPM]: 2.0.0-beta.13

[-] App
    - build-type: bundle
    - CSP: unset
    - frontendDist: ../dist-tmp
    - devUrl: http://localhost:8070/
    - framework: Vue.js
    - bundler: Rollup

Stack trace
thread 'main' panicked at src/cargo\core\compiler\fingerprint\mod.rs:1111:13:
assertion failed: mtimes.insert(output.clone(), mtime).is_none()
stack backtrace:
   0:     0x7ff6f9a012d2 - git_midx_writer_dump
   1:     0x7ff6f9a2b85d - git_midx_writer_dump
   2:     0x7ff6f99fa661 - git_midx_writer_dump
   3:     0x7ff6f9a010fa - git_midx_writer_dump
   4:     0x7ff6f9a03f79 - git_midx_writer_dump
   5:     0x7ff6f9a03c35 - git_midx_writer_dump
   6:     0x7ff6f9a04494 - git_midx_writer_dump
   7:     0x7ff6f9a0432b - git_midx_writer_dump
   8:     0x7ff6f9a01bd9 - git_midx_writer_dump
   9:     0x7ff6f9a04036 - git_midx_writer_dump
  10:     0x7ff6f9ae0227 - git_midx_writer_dump
  11:     0x7ff6f9ae0302 - git_midx_writer_dump
  12:     0x7ff6f8d597f1 - git_filter_source_repo
  13:     0x7ff6f8d51ace - git_filter_source_repo
  14:     0x7ff6f8e10e79 - git_odb_object_id
  15:     0x7ff6f928b329 - git_filter_source_path
  16:     0x7ff6f8d52677 - git_filter_source_repo
  17:     0x7ff6f8d4d61a - git_filter_source_repo
  18:     0x7ff6f912d787 - git_filter_source_path
  19:     0x7ff6f920f770 - git_filter_source_path
  20:     0x7ff6f8b5a97d - git_filter_source_repo
  21:     0x7ff6f8b5a679 - git_filter_source_repo
  22:     0x7ff6f88e53cc - git_libgit2_prerelease
  23:     0x7ff6f89500c5 - git_filter_source_repo
  24:     0x7ff6f8947b2e - git_filter_source_repo
  25:     0x7ff6f892de06 - git_libgit2_prerelease
  26:     0x7ff6f894cb2c - git_filter_source_repo
  27:     0x7ff6f99f0622 - git_midx_writer_dump
  28:     0x7ff6f894ae5c - git_filter_source_repo
  29:     0x7ff6f9a344dc - git_midx_writer_dump
  30:     0x7fff8170257d - BaseThreadInitThunk
  31:     0x7fff8384aa48 - RtlUserThreadStart

Additional context
No response

After digging a bit more into the problem, it seems to be directly related to the following warning:
warning: output filename collision.
The lib target `zwoo_lib` in package `zwoo v1.0.0-beta.17 (C:\dev\csharp\zwoo\frontend\src-tauri)` has the same output filename as the lib target `zwoo_lib` in package `zwoo v1.0.0-beta.17 (C:\dev\csharp\zwoo\frontend\src-tauri)`.
Colliding filename is: C:\dev\csharp\zwoo\target\debug\deps\libzwoo_lib.rlib
The targets should have unique names.
Consider changing their names to be unique or compiling them separately.
This may become a hard error in the future; see <https://github.com/rust-lang/cargo/issues/6313>.

Although I tried to ignore that warning, after removing lib from lib.crate-type it works just fine on both windows and linux.
After revisiting the docs, this is actually the intended configuration. Since I don't have a glue, how the extra crate type ended up there, I guess this issue can be closed.

Same for me, after removing lib  from lib.crate-type it worked again.
I don't know how it ended up there, but my app stopped working right after I ran npm install @tauri-apps/api@next (it was missing, since I used the old way of extending an existing project instead of running npm create tauri-app@latest -- --beta, so I had only the cli installed).


lemmatization issue

left_strip_tokenized_noPunct_lemmat error or there is a problem in lemmatization
parked -> parked
laying -> laying
posing -> posing
etc

from nltk.corpus import wordnet as wn
nltk.download('averaged_perceptron_tagger')
In [28]: lemmatizer.lemmatize("parked")
Out[28]: 'parked'
if token POS (part-of-speech) is not correctly set, lemmatization is not correct
Solution is to use NLTK resources to try to guess correct POS
In [30]: nltk.pos_tag(["parked"])
Out[30]: [('parked', 'VBN')]
In [31]: lemmatizer.lemmatize("parked", wn.VERB)
Out[31]: 'park'


Error when running plugins: FATAL FIPS SELFTEST FAILURE

Hello,
This is probably an obvious issue to solve, as I am not a Linux expert.
I have downloaded the Linuxfabrik plugins and installed them on my test RHEL 8.8 server.  Most of them are giving me this FIPS error (exit code of previous command within parentheses):
(0) lut01# ./about-me
fips.c(145): OpenSSL internal error, assertion failed: FATAL FIPS SELFTEST FAILURE
Aborted (core dumped)
(134) lut01# ls -la ./about-me
-rwxr-x---. 1 jean jean 1053608 May 12 14:33 about-me
(0) lut01# uname -r
4.18.0-477.15.1.el8_8.x86_64
(0) lut01#

Any help to make the plugins work would be highly appreciated.
Thank you,
Jean

Output of update-crypto-policies --show?

What is the output of update-crypto-policies --show?

DEFAULT:NO-SHA1

If I start RHEL in FIPS mode

How can this be done?  Is it at least as secure as the current mode?

So this is not a bug and beyond the scope of this monitoring-plugins project, but this should help you get started:

DEFAULT:NO-SHA1 means you have the default crypto policy running, with a custom modification of NO-SHA1 (obviously you have turned off SHA1 support). Now something seems to be broken on your system.
The `FIPS' mode ensures that your RHEL system generates and uses all cryptographic keys only with FIPS approved algorithms. See Wikipedia and RHEL's documentation.

One more question, please: is it mandatory to enable the FIPS mode in order to be able to run the Linuxfabrik plugins on RHEL 8.8?

No. But whether you use DEFAULT, FIPS, or any other cryptographic mode, they work fine, so it looks like something is broken on your end.


"Undefined param." in ---@overload function

Describe the bug

Environment:

OS: Windows,
Is WSL remote? no
Client: VSCode,

---@param cannot used for ---@overload.

OK. then i will make more simple 😃
-- `tbl` - table array of `topic, anything` pairs to unsubscribe from.
---@overload fun(tbl: table, callback: function): boolean```

Suggest using: ---@param topic string|table, then ---@overload is unecessary

Yes, you are right. Thank you.


Please add nginx configuration to the documentation

I try to reverse-proxy on nginx and don't know how it should look such that it's nip-11 compliant aka without using a different url for page and ws. Please amend https://github.com/scsibug/nostr-rs-relay/blob/master/reverse-proxy.md accordingly.

I'm happy to add documentation, but I don't actually use NGINX for front-ending any nostr relay instances.
If anyone has a config they like, please feel free to open a PR or send a patch.

I host  nostr.drss.io on ubuntu 20.04 using the following:
http {
	server {
		listen 443 ssl;
		server_name nostr.drss.io;
		ssl_certificate /etc/letsencrypt/live/nostr.drss.io/fullchain.pem;
		ssl_certificate_key /etc/letsencrypt/live/nostr.drss.io/privkey.pem;
		ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
		ssl_ciphers HIGH:!aNULL:!MD5;
		keepalive_timeout 70;

		location / {
			proxy_pass http://localhost:<local port>;
			proxy_http_version 1.1;
			proxy_set_header Upgrade $http_upgrade;
			proxy_set_header Connection "Upgrade";
			proxy_set_header Host $host;
		}
	}
}

with the <local port> bit replaced with the port I config nostr-rs-relay to run on. obviously I am using letsencrypt for ssl keys, so you'll need to get all that setup if you want https connections. I found this resource to be particularly useful in getting that done.

Yes, please open a PR and add content to the reverse-proxy.md file.  That would be a great addition as it seems more people run nginx than haproxy.  Thanks!


generate compatible interfaces for exchangeable sql dialects

It is a bit related to #444 but not exactly: I wonder, how you plan to exchange the sql dialect implementation e.g. postgresql vs mysql vs sqlite? A similar discussion related around code generation can be found also at https://github.com/golang/go/issues/8082.
possible solutions:

A partial solution may be to generate anonymous structs or interfaces or
to extract equal structs and interfaces into a common package

How to solve it?

To elaborate that with an example:
mysql schema and query:
CREATE TABLE user (
  id   binary(16) PRIMARY KEY,
  firstname varchar(255) NOT NULL,
  lastname varchar(255),
  login  varchar(255) NOT NULL
);

/* name: ListUsers :many */
SELECT * FROM user;

/* name: CreateUser :exec */
INSERT INTO user (id,firstname,lastname,login) VALUES (?,?,?,?);

/* name: DeleteUser :exec */
DELETE FROM user WHERE id = ?;

postgresql schema and query
CREATE TABLE "user" (
  id   UUID PRIMARY KEY,
  firstname varchar(255) NOT NULL,
  lastname varchar(255),
  login  varchar(255) NOT NULL
);

-- name: ListUsers :many
SELECT * FROM "user";

-- name: CreateUser :exec
INSERT INTO "user" (id,firstname,lastname,login) VALUES ($1,$2,$3,$4);

-- name: DeleteUser :exec
DELETE FROM "user" WHERE id = $1;

Expected to work:
	var pgsUsers postgresql.Querier
	pgsUsers = postgresql.New(db)

	var mysqlUsers mysql.Querier
	mysqlUsers = mysql.New(db)

	pgsUsers = mysqlUsers // <- not assignable

Quickfix:
...
type User = struct { // instead of type User struct
...

type CreateUserParams = struct { // instead of type CreateUserParams struct
...

how you plan to exchange the sql dialect implementation e.g. postgresql vs mysql vs sqlite?

You're actually the first person to ask this question! And it's a good one.
I think there's two ways sqlc can support this going forward. The first is enforcing a strict subset of SQL such that your queries do not need to be modified to run on a different database engine. While a laudable goal, I don't think in practice this would be very helpful, especially if you're including SQLite.
The second is to borrow from protocol buffers and have some concept of a service definition with structs. The difficult part here is that sqlc currently doesn't require defining input and output structs for queries; those are inferred automatically. We'd need to either define those structs up front, or have an option to mark two different packages as implementing the same interface and return an error when queries of the same name do not match the expected types.
Notice in your example that the user structs for MySQL and PostgreSQL aren't the same; the ID columns are different types.

Notice in your example that the user structs for MySQL and PostgreSQL aren't the same; the ID columns are different types.

Well, I used your great package override option to solve that ;-)
...
 "overrides": [
        {
          "column": "user.id",
          "go_type": "github.com/google/uuid.UUID"
        }

And now, if I set the type-def of the generated structs to aliases by hand, the go compiler is happy to assign them (and the interfaces) vice-versa, as long as I can ensure that the generated (anonymous) structs have identical fields (e.g. per override).
What do you think about a generator option, to create aliases instead of structs? It is clear, that there is no guarantee that generated things will match, but at least the compiler will let me know...


world map: add remaining map icon info for issue #18488

Close #18488 (and consequently #18336)
Added remaining map icon info requested in issue #18488

Added in c42b3f00d18d1bc094b595f2648ae399d8939326


Make the dependency resolution pluggable

createContainer(modules: IServiceModule[], options: ServiceContainerOptions)...

I think we could expose some sort of plugin model that lets you participate in the auto-wire factory resolution. For context, I'm thinking about how to integrate @fromAppStorage and @fromProjection

Got this in 0.3


bug in reduce

https://github.com/RyanAmeri/FrontEnd-Masters/blob/6caa229c2e1fe24fee8d41ee89565c8f3376c045/js_the_hard_parts_v2/callback_exercises.js#L83
The case where initialValue is not provided is not considered.
When initialValue is initialized as array[0], the callback function will receive (array[0], array[0]) as its arguments in first iteration.

Thank you for the bug report! Should be fixed now!


java.lang.illegalAccessError when trying to launch map

Hi All
I seem to have another issue with the google maps plugin.
After implementing this fix for compilation:
https://github.com/dapriett/nativescript-google-maps-sdk/issues/222
I now receive a java.lang.illegalaccess error when trying to load the map (see screenshot). It basically says that com.google.android.gms.maps.model.latlng is inaccessible.

Any ideas?
Thanks again!

I somehow resolved this by creating a new project.


Serialize Form Data

Current Situation
Currently, onSubmit events for form elements do not serialize the data contained within them. To do this we need to serialize the form.elements attribute.
Proposed Changes
diff --git a/src/client/packages/idom-client-react/src/event-to-object.js b/src/client/packages/idom-client-react/src/event-to-object.js
index b11e653..80b098b 100644
--- a/src/client/packages/idom-client-react/src/event-to-object.js
+++ b/src/client/packages/idom-client-react/src/event-to-object.js
@@ -49,6 +49,13 @@ const elementTransformCategories = {
       return {};
     }
   },
+  hasElements: (element) => {
+    const result = {};
+    for (key in element.elements) {
+      result[key] = serializeDomElement(element.elements[key]);
+    }
+    return result;
+  }
 };

 function defaultElementTransform(element) {
@@ -69,6 +76,7 @@ const elementTagCategories = {
   ],
   hasCurrentTime: ["AUDIO", "VIDEO"],
   hasFiles: ["INPUT"],
+  hasElements: ["FORM"],
 };

 const elementTransforms = {};

Implementation Details
No response

There's going to need to be considerations made for file fields. We're also going to need to make considerations related to backpressure, especially since there's the potential to upload files with an uncapped size.
Probably worth generalizing the data serialization (perhaps even as a separate package?). If it's generic enough, there's a possibility that down the line it would allow for using the WS to stream video.

I think there's an issue (or discussion) about serializing files.
Could you make file serialization into an issue if it isn't one and create an separate issue for dealing with back-pressure?

@acivitillo this seems like a less-trivial first issue.

File serialization issue appears to exist: https://github.com/idom-team/idom/issues/574
Shouldn't backpressure be handled within the file serialization issue? Feels strange creating a new issue to handle an not yet developed limitation.

I think back-pressure is a general problem. Any event, not just those with files, could take a long time for the network to send and the server to process which would thus cause things to back up.

Something else I'm generally thinking about on this PR is there's going to need to be some degree of consideration for Django here.
Django forms have a validator function that is run to verify the form's data. I'm not sure how we'd work that in to an "IDOM form"...
Maybe we need some sort of concept of form middleware? Would also need some class mixins within Django IDOM, most likely.

Well, from my end I can take a stab at the initial PR idea, but I am not sure if I can also consider all the other cases. Could we implement form serialization incrementally via multiple PRs?

Yeah it can be handled incrementally.

ok so I started working on this, there is a problem with keys. This is because a form can have an indefinite number of elements, so target will be a json of multiple targets.
We can go with index keys, but then I need to understand how to build a test case for FORM in event-to-object.test.js
  hasElements: (element) => {
    const result = {};
    Object.keys(element).forEach((key) => {
      result[key] = serializeDomElement(element.elements[key])
    });
    return result;
  }

gives the below json
{
  "target": {
    "0": {
      "boundingClientRect": {
        "x": 8,
        "y": 8,
        "width": 149,
        "height": 22,
        "top": 8,
        "right": 157,
        "bottom": 30,
        "left": 8
      },
      "value": ""
    },
    "1": {
      "boundingClientRect": {
        "x": 8,
        "y": 80,
        "width": 52,
        "height": 22,
        "top": 80,
        "right": 60,
        "bottom": 102,
        "left": 8
      },
      "value": "Submit"
    },
    "2": {
      "boundingClientRect": {
        "x": 60,
        "y": 80,
        "width": 149,
        "height": 22,
        "top": 80,
        "right": 209,
        "bottom": 102,
        "left": 60
      },
      "value": ""
    },
    "boundingClientRect": {
      "x": 8,
      "y": 8,
      "width": 408,
      "height": 128,
      "top": 8,
      "right": 416,
      "bottom": 136,
      "left": 8
    },
    "__reactInternalInstance$6poh51syf6f": null,
    "__reactEventHandlers$6poh51syf6f": null
  },
  "currentTarget": {
    "0": {
      "boundingClientRect": {
        "x": 8,
        "y": 8,
        "width": 149,
        "height": 22,
        "top": 8,
        "right": 157,
        "bottom": 30,
        "left": 8
      },
      "value": ""
    },
    "1": {
      "boundingClientRect": {
        "x": 8,
        "y": 80,
        "width": 52,
        "height": 22,
        "top": 80,
        "right": 60,
        "bottom": 102,
        "left": 8
      },
      "value": "Submit"
    },
    "2": {
      "boundingClientRect": {
        "x": 60,
        "y": 80,
        "width": 149,
        "height": 22,
        "top": 80,
        "right": 209,
        "bottom": 102,
        "left": 60
      },
      "value": ""
    },
    "boundingClientRect": {
      "x": 8,
      "y": 8,
      "width": 408,
      "height": 128,
      "top": 8,
      "right": 416,
      "bottom": 136,
      "left": 8
    },
    "__reactInternalInstance$6poh51syf6f": null,
    "__reactEventHandlers$6poh51syf6f": null
  },
  "relatedTarget": null
}

I tried playing with a FORM test case but I get Cannot read property 'tagName' of undefined
  ...["AUDIO", "VIDEO"].map((tagName) => ({
    case: `adds 'currentTime' attribute for ${tagName} element`,
    tagName,
    output: { target: { currentTime: allTargetData.currentTime } },
  })),
  ...["FORM"].map((tagName) => ({
    case: `adds 'value' attribute for ${tagName} element`,
    tagName,
    output: { target: { value: allTargetData.value } },
  })),

Can you put up PR so I can look at the diff?

https://github.com/idom-team/idom/pull/699/files#diff-3f303c8e01a070d03f718729164a7cfefc2d103cb460777a178d35c11ac99169


Enhancement/issue 57 migrate rule page

Rule Definition page

Could you please fix the CI checks ( Building and Linting)


Migrate to Vite

to get rid of CRA and to speed up development :racehorse:
Helpful links

Vite - Getting started https://vitejs.dev/guide/
Migrating a Create React App project to Vite https://darekkay.com/blog/create-react-app-to-vite/
Migrate from create-react-app (CRA) to Vite (ViteJS) with TypeScript https://egor-xyz.medium.com/migrate-from-create-react-app-cra-to-vite-vitejs-with-typescript-68d653c221c3
Misc. Vite templates (search for Electron) https://github.com/vitejs/awesome-vite#react
pat-frontend-template -> CRA -> Vite migration guide https://github.com/nordcloud/pat-frontend-template/blob/master/docs/CRA_MIGRATION_GUIDE.md

Production build issues could not be fixed (see https://github.com/thorchain/asgardex-electron/pull/1997#issuecomment-1012406178) and nees much more time than expected to fix. Will stick with webpack + craco (CRA) - closing for now...


python3Packages.trimesh: 3.23.5 -> 4.0.0

Description of changes
Changelog: https://github.com/mikedh/trimesh/releases/tag/4.0.0
I use this actively in my work, and also depend on it downstream in pyrender, as such i added myself as maintainer.

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

[x] 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.11 Release Notes (or backporting 23.05 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

[x] Fits CONTRIBUTING.md.

Result of nixpkgs-review pr 260883 run on x86_64-linux 1

9 packages built:

cura
python310Packages.pyrender
python310Packages.pyrender.dist
python310Packages.trimesh
python310Packages.trimesh.dist
python311Packages.pyrender
python311Packages.pyrender.dist
python311Packages.trimesh
python311Packages.trimesh.dist

Looks good to me. Waiting 24h in case the current maintainer has a comment.


OSS License

@erez-rabih Hi, would you consider adding an OSS License to this project? Thanks!

sure, done


feature: filter class definition

This pull request introduces a class TimeDomainFilter, which is a superclass for the definition of time domain filters, as well as a set of Butterworth filters based on the TimeDomainFilter.
This pull request serves mainly as a proposal for the boilerplate for time domain filters.

Is this a draft PR on purpose? Do you want me to review it already or will you still make some adjustments?

I wanted to add tests and docstrings before having it reviewed. This seemed like a good practice. I've added tests for the creation of filters, but not the actual workings.
I think you can review it as is, but we should add at least tests for the workings of filters before merging.
Do we have a convention about adding documentation before merging PRs?

I prefer reviewing everything at once, tbh.
So if you want to add more tests (which is always a good idea), I will wait a bit. Would using some (noisy?) sinusoids as test data work for this? Or do you want to use real sample data as it comes from the wild?
So far we've been using the google style docstrings (see e.g. this: https://stackoverflow.com/questions/65768215/type-annotations-with-google-style-docstrings), which I am used to from other projects as well.

Then I will add more tests and docs, and remove the draft status when that's done.
I think some simple noisy sinusoid data is indeed best. The point is not to test the quality of the output data (because scipy does the heavy lifting), but test the flow of data through the filters.

@DaniBodor Thanks for all the comments. I've addressed them all. Could you re-review them?

I've addressed all your comments, @DaniBodor. Could you review them again? Thanks!


404 error on Telegraf Documentation - Getting Started

Describe the issue here.
Relevant URLs
On this page, https://docs.influxdata.com/platform/#telegraf at the very bottom under the title Getting Started I clicked on "Installation and Configuration" and got a 404.
Cheers
Tim

Thank you, @GH4TP - fixed!


Prevent remove_lockfile_packages_name_attribute from being called with nil

What are you trying to accomplish?

Dependabot::NpmAndYarn::FileUpdater::NpmLockfileUpdater.remove_lockfile_packages_name_attribute takes a parameter current_name. Previously, I had typed this as String, but we're seeing warnings in production that this is passed a nil:
Parameter 'current_name': Expected type String, got type NilClass
Caller: /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:764
Definition: /home/dependabot/npm_and_yarn/lib/dependabot/npm_and_yarn/file_updater/npm_lockfile_updater.rb:808 (Dependabot::NpmAndYarn::FileUpdater::NpmLockfileUpdater#remove_lockfile_packages_name_attribute)

This change prevents remove_lockfile_packages_name_attribute from being called if current_name is nil
Anything you want to highlight for special attention from reviewers?

I decided to guard this function instead of change the parameter of current_name to T.nilable(String) because I don't think it makes sense to try and remove a name attribute from a lockfile if the name is nil. This is a guard clause to prevent the function from being called with a nil value.
How will you know you've accomplished your goal?

Tests pass and warning goes away
Checklist

[x] I have run the complete test suite to ensure all tests and linters pass.
[x] I have thoroughly tested my code changes to ensure they work as expected, including adding additional tests for new functionality.
[x] I have written clear and descriptive commit messages.
[x] I have provided a detailed description of the changes in the pull request, including the problem it addresses, how it fixes the problem, and any relevant details about the implementation.
[x] I have ensured that the code is well-documented and easy to understand.

@JamieMagee, @abdulapopoola,
After thoroughly investigating the issue and writing unit tests, I found that the problem occurs when package.json lacks a name field, while package-lock.json includes one. Through various test scenarios, I was able to handle the NilClass as well. The check added by @JamieMagee effectively covers the scenario where remove_lockfile_packages_name_attribute is called, but when replace_lockfile_packages_name_attribute is called current name can be empty and that is causing NillClass as well. So, I've combined both sollutions as you can see in the PR and write a spec validate it. @JamieMagee , please let me know if I am missing anything out for that situation.
The other related PR: https://github.com/dependabot/dependabot-core/pull/10215 (We are going to close that one if we fix all together here)

@abdulapopoola I can't approve this PR as I created it, but I think it's good to merge.


Install tiny-cuda-nn failed

pip install git+https://github.com/NVlabs/tiny-cuda-nn/#subdirectory=bindings/torch
Collecting git+https://github.com/NVlabs/tiny-cuda-nn/#subdirectory=bindings/torch
Cloning https://github.com/NVlabs/tiny-cuda-nn/ to c:\users\hm\appdata\local\temp\pip-req-build-2u1e_ok0
Running command git clone --filter=blob:none --quiet https://github.com/NVlabs/tiny-cuda-nn/ 'C:\Users\HM\AppData\Local\Temp\pip-req-build-2u1e_ok0'
Resolved https://github.com/NVlabs/tiny-cuda-nn/ to commit c91138bcd4c6877c8d5e60e483c0581aafc70cce
Running command git submodule update --init --recursive -q
Preparing metadata (setup.py) ... done
Building wheels for collected packages: tinycudann
Building wheel for tinycudann (setup.py) ... error
error: subprocess-exited-with-error
× python setup.py bdist_wheel did not run successfully.
│ exit code: 1
╰─> [25 lines of output]
C:\Users\HM\AppData\Local\Temp\pip-req-build-2u1e_ok0\bindings/torch\setup.py:5: DeprecationWarning: pkg_resources is deprecated as an API. See https://setuptools.pypa.io/en/latest/pkg_resources.html
from pkg_resources import parse_version
Building PyTorch extension for tiny-cuda-nn version 1.7
Obtained compute capability 86 from PyTorch
Detected CUDA version 11.8
Targeting C++ standard 17
running bdist_wheel
running build
running build_py
creating build
creating build\lib.win-amd64-cpython-38
creating build\lib.win-amd64-cpython-38\tinycudann
copying tinycudann\modules.py -> build\lib.win-amd64-cpython-38\tinycudann
copying tinycudann_init_.py -> build\lib.win-amd64-cpython-38\tinycudann
running egg_info
creating tinycudann.egg-info
writing tinycudann.egg-info\PKG-INFO
writing dependency_links to tinycudann.egg-info\dependency_links.txt
writing top-level names to tinycudann.egg-info\top_level.txt
writing manifest file 'tinycudann.egg-info\SOURCES.txt'
reading manifest file 'tinycudann.egg-info\SOURCES.txt'
writing manifest file 'tinycudann.egg-info\SOURCES.txt'
copying tinycudann\bindings.cpp -> build\lib.win-amd64-cpython-38\tinycudann
running build_ext
error: [WinError 2] The system cannot find the file specified
[end of output]
note: This error originates from a subprocess, and is likely not a problem with pip.
ERROR: Failed building wheel for tinycudann
Running setup.py clean for tinycudann
Failed to build tinycudann
ERROR: ERROR: Failed to build installable wheels for some pyproject.toml based projects (tinycudann)

Unfortunately, I got the exact output too, can you please come back if you solved the issue

Unfortunately, I got the exact output too, can you please come back if you solved the issue

It hasn't been resolved, but I switched to Ubuntu 22.04 using Docker, and at least it worked.

From my side, it worked on 22.04 and failed on 24.04

Check https://stackoverflow.com/questions/76043689/pkg-resources-is-deprecated-as-an-api
For me, it solved the issue (running Ubuntu 22.04 using Docker) :
pip uninstall setuptools
pip install setuptools==66.1.1


Add installation method for archlinux

Arch Linux has hub in its official repository. But I spent an hour installing go and other things because I thought hub would not be in the official repository.

@sinisterstuf thanks. Done exactly that.


⚠ ClamAV has degraded performance

In 4c597f5, ClamAV (https://spamassassin.apache.org/) experienced degraded performance:

HTTP code: 200
Response time: 68 ms

Resolved: ClamAV performance has improved in 1476fb8.


Tabs in iPhone X not displayed at the bottom of the screen until interaction

Bug Report
Ionic Info
Run ionic info from a terminal/cmd prompt and paste the output below.
Ionic:

   ionic (Ionic CLI)          : 4.1.1 (/usr/local/lib/node_modules/ionic)
   Ionic Framework            : @ionic/angular 4.0.0-beta.3
   @angular-devkit/core       : 0.7.4
   @angular-devkit/schematics : 0.7.4
   @angular/cli               : 6.1.4
   @ionic/ng-toolkit          : 1.0.7
   @ionic/schematics-angular  : 1.0.5

Capacitor:

   capacitor (Capacitor CLI) : 1.0.0-beta.6
   @capacitor/core           : 1.0.0-beta.6

System:

   NodeJS : v8.11.1 (/Users/gabrielm/n/bin/node)
   npm    : 6.4.0
   OS     : macOS High Sierra

Describe the Bug
Initially, there's a large gap between the tabs and the bottom of the screen. Once the user taps anywhere, the tabs are positioned correctly.
https://www.youtube.com/watch?v=niYPKcfvuJA

Steps to Reproduce
Create an app based on the tabs template: ionic start myApp tabs --type=angular, add Capacitor, and run on the iPhone X simulator (Xcode 9.4).

Hi this might help, it's a similar issue.
https://github.com/ionic-team/ionic/issues/15147

@osman144 you're right, it's the same issue. Gonna close this one in favor of #15147. Thanks!


Changed the height of the wedge to be outer height

Previously the wedge (put in place to stop the page shifting up when the stuck element becomes fixed) was the inner height of the stuck element. It should probably be the outer height instead (which includes margins). Otherwise there's a judder as the page height changes when the element becomes stuck/unstuck.

I'm surprised I didn't notice this when I first wrote it...

I have a nasty feeling there's a reason for it, maybe related to collapsed margins? Unfortunately that depends on what's next to it. Originally it did use inner height, but that was before the wedge element was introduced. So I think it's ok.
I've rebased this, should be ok to merge now...

Hmmm, only one way to find out!


Missing files

What is your question?
When I try to launch the game it shows back when I leave and come back it say I don’t have files to run the game

that's weird, that's probably your issue can't do anything

Try manually extracting the assets from the android apk and add a logs folder too

(I had the same problem on iOS)


DashboardClient#List behaves inconsistency when resource is not available in cluster

What steps did you take and what happened:
Using the Knative plugin and a clean kind cluster kind create cluster. When viewing the overview page for the plugin, the layout flip-flops between an error page and an empty listing. The error page is rendered if any of the DashboardClient calls throw, the empty listing is returned if all calls to DashboardClient#List return an empty array.
What did you expect to happen:
The DashboardClient should consistently throw errors when the CRD is not installed.
Environment:

Octant version (use octant version): 0.16.1
Kubernetes version (use kubectl version): 1.19.1
Knative Plugin: v0.2.0

Originally I was going to try to put this in to 0.16.2 but after some investigation this issue is more systemic.
In our list call we are doing an access check. This access check is actually masking the IsNoMatch error from the API, intern, we treat it like an access denied error and start the backoff process.
if err := dc.access.HasAccess(ctx, key, "list"); err != nil {
	if meta.IsNoMatchError(err) {
		return &unstructured.UnstructuredList{}, false, err
	}
	if !dc.isBackingOff(ctx, key) {
		dc.backoff(ctx, key)
	}
	return nil, false, fmt.Errorf("check access to list %s: %w", key, err)
}

So normally we just return an empty list if the CRD is not installed at all, this was put in place a while back, to allow Octant to
short circuit the HasAccess checks all together for requests that weren't even installed.
The problem is, this short circuit should exist in the HasAccess method itself, not in the List/Get/Watch calls. So if this was working as it was originally intended, you'd only get the empty list as return values.
This is fine behavior for core Octant, since it will never attempt to query for a CRD that isn't part of the list of CRDs Octant fetches at startup. That behavior is not really great for a plugin, especially if you want to explicitly look for that IsNoMatch error and offer to install the CRDs from the Error Page.

The proper way to fix this is fix how the Octant client current works. We are trying to do too much and should just be returning errors up the stack and dealing with them accordingly in the describers for our modules.


Introduce native ParquetReader

This commit introduces the native ParquetReader, which loads the file
metadata. It makes use of Apache Thrift included in Arrow, therefore
Arrow support was turned on when Parquet is enabled.
Depends on https://github.com/facebookincubator/velox/pull/2026

It makes use of Apache Thrift included in Arrow.

Building Arrow just for thrift is overkill. Building thrift as an ExternalProject in Velox should be straightforward.

@Yuhta Jimmy, I tried the code block you suggested and it ran fine on my laptop. However CircleCI fails with the following:
CMake Error in velox/vector/arrow/tests/CMakeLists.txt:
  Imported target "arrow" includes non-existent path

    "/root/project/_build/debug/third_party/arrow_ep/src/arrow_ep-build/thrift_ep-install/include"

  in its INTERFACE_INCLUDE_DIRECTORIES.  Possible reasons include:

  * The path was deleted, renamed, or moved to another location.

  * An install or uninstall procedure did not complete successfully.

  * The installation package was faulty and references files it does not
  provide.

-- Generating done
CMake Generate step failed.  Build files cannot be regenerated correctly.
make[1]: *** [Makefile:68: cmake] Error 1
make[1]: Leaving directory '/root/project'
make: *** [Makefile:81: debug] Error 2

The same error also happens on my laptop if I just run "make clean" in CLion and not delete the cmake-build-debug/third_party/arrow_eq folder.  The error went away after I removed the third_party/arrow_eq completely and then rebuild the velox_arrow_bridge_test. Do you have any idea why? Many thanks!

@yingsu00 Not sure why, you probably want to check where the include directory is in CircleCI and adjust the path.

@Yuhta Jimmy I couldn't figure out why this PR fails with the change you suggested. The paths look good to me. I'm going to close this one in favor of https://github.com/facebookincubator/velox/pull/2054 if you are ok with it.

@Yuhta Thank you for importing this PR! I just rebased it and removed the old commit of fixing the nullability warnings. The latest of that fix is in https://github.com/facebookincubator/velox/pull/2026 and we need to import that one first.

@yingsu00 #2026 is small and we can do both at same time

@Yuhta Thank you very much Jimmy!


Recommended Approach for Gradient Accumulation

Opening an issue for the discussion linked below.
The proposal that @marcvanzee and I discussed today is:

Create a minimal example (e.g. MNIST) that uses gradient accumulation, likely the Optax one.
In the example, try to demonstrate how it works -- display/explain the intermediate outputs, add more documentation where needed.
Based on the experience of creating and running the above, consider opening up a discussion with Optax about whether they could update their implementation to address the pain points, or if not then whether we should implement our own. The former would be preferable.

Discussed in https://github.com/google/flax/discussions/2030

Originally posted by sanchit-gandhi April  6, 2022
I'm working on a training script for a Speech model in Flax, and was wondering if I could get an opinion from the community on what the best way is of implementing gradient accumulation in JAX/Flax. To my understanding, there are two viable options:

Optax MultiSteps: the wrapper can incorporated with another Optax optimizer (e.g. Optax Adamw) to provide gradient updates at a prescribed number of gradient accumulation steps, without any change to the training step itself.
A custom gradient accumulation training step: for each training step, a superbatch is formed comprising of all the batched data for N gradient accumulation steps. Gradients are computed and manually accumulated over the N gradient accumulation steps, and only applied once following this.

The simpler of the two approaches, I initially trialled using Optax MultiSteps. Keeping the per-device batch size fixed, I was not able to increase the number of gradient accumulation steps to be any greater than 1 (equivalent to no gradient accumulation!). Thus, I implemented a version of gradient accumulation by hand (see here). Once again, I was not able to increase the number of gradient accumulation steps to be any greater than 1 keeping the per-device batch size fixed. Are there any caveats with using Optax MultiSteps in regards to memory that people have experienced before? As for the custom approach, is there a 'standard' way of going about doing this? Many thanks for all your help!

Closing this since gradient accumulation can be done in Optax, and we should not explain how to use Optax in Flax. @jheek


incorrect intersection results from same two objects in different relative positions

When intersecting the same two objects with different relative positions, certain positions result in an incorrect intersection object.
How to reproduce
At this point it is not clear to me what is a minimal repro. I am intersecting a pyramidal shape representing a camera frustum with an L shaped "room" object.
When the camera is at certain positions in the room the returned intersection is clearly incorrect while the individual room and frustum objects (when rendered separately) are correct.
Possibly I am using CSG incorrectly, but then I cannot explain why other positions in the room do render correct intersections.
Both of the objects I'm intersecting are created programmatically. The room is an ExtrudeBufferGeometry extruded from a programmatically created THREE.Shape, while the frustum is a BufferGeometry with vertices set from a dynamically created array like this:
  const geometry = new THREE.BufferGeometry()
  geometry.setAttribute('position', new THREE.BufferAttribute(vertices, 3))
  geometry.computeVertexNormals()

Screenshots
animated gif showing that in some positions everything works great, while in others there's a clear problem:

In positions that cause the intersection to break, the individual objects render as expected:

frustum only (green):

lines-of-sight / room object only (red):

wireframe materials illustrating the broken intersection: room (red), frustum (yellow), intersection (green)

Additional context
I'm using react-three-fiber, but I don't think this is relevant as the CSG code is outside of react and dealing directly with threejs objects:
export const createConstrainedFOVMesh = props => {
  const { id } = props
  const fovMesh = createSimpleFOVMesh(props)
  const linesOfSightMesh = createLinesOfSightMesh(props)

  if (linesOfSightMesh) {
    const bspLinesOfSight = CSG.fromMesh(linesOfSightMesh)
    const bspFOV = CSG.fromMesh(fovMesh)

    const bspResult = bspFOV.intersect(bspLinesOfSight)
    const result = CSG.toMesh(bspResult, fovMesh.matrix)
    result.material = fovMesh.material
    result.name = id

    return result
  }
  return fovMesh
}

update:
I oversimplified initially when I talked about the "room" object. It isn't really the shape of the room, it is a generated object that is a sub-set of the room that would be visible to a camera if it were to pan around (ie the "visibility polygon" or total visible portion of the room from the camera's position).
When the camera moves I have to update this object to reflect the visibility polygon from the camera's new position. This naturally creates different extruded geometries at different camera positions, and it appears that certain of those geometries are what cause the broken intersections, despite the extruded visibility polygon / room object being perfectly valid.
correct intersection:

broken intersection:

In all cases the individual objects for my visibility polygon and camera frustum render correctly.
I suspect I could now create a minimal repro test-case if that is useful?

replicated in codesandbox here with a simple geometry extruded from a THREE.shape intersected with a THREE.ConeBufferGeometry.

update:
I tried several other three csg libs and encountered the same issue in all of them.
@darkwave found a neat workaround to the issue I reported in THREE-CSGMesh by using a CylinderGeometry with a very small radiusTop.
I have tested and confirm that this workaround also applies to three-csg-ts! (sandbox)
@darkwave also noted that setting the cylinder's radiusTop to 0 exhibits the same problem as using a cone directly, which may shed some light on the source of the problem, and again this is true with three-csg-ts.

@steveliles please could you confirm whether the issue is still present with v3.0.0?

@samalexander confirmed - still present with 3.x (codesandbox showing problem with v3.1.3 here).

Pretty sure you've found the cause. I haven't verified it directly, but it sounds like the ConeGeometry actually makes a zero sized end cap. That endcap has an undefined face normal, and probably blows the whole algorithm, because if multiple planes share edges with a degenerate faces, the whole recursive slicing operation would break since the object isn't considered a watertight solid any more.
We could perhaps write a routine to check for bad inputs.. but it's not something you would want to run all the time unless you can't control the shape of your data.
Such a routine could perhaps collapse degenerate faces into a single vertex..

I'm gonna leave this open for now if someone wants to discuss it further? Thanks @steveliles and @darkwave for chasing this down... :)

doing this cleanup on the bsp tree seems to fix this case for conegeometry:
    bspFrustum.polygons = bspFrustum.polygons.filter( p => !isNaN(p.plane.normal.x)  );
we could perhaps add this to CSG.fromMesh...

I made a branch and pr with that filter/check added to CSG.fromMesh, but I haven't tested it very well..
I could use some eyeballs/testing if anyone has some cycles... @steveliles @samalexander @darkwave
https://github.com/Jiro-Digital/three-csg-ts/pull/30
Open to feedback/suggestions/opinions...

@steveliles your test case appears to be fixed by v3.1.4 (credit to @manthrax for the fix) - see updated sandbox.
Please could you confirm this issue can now be closed?

Let's close it! :D


Update ProjAcctCostManagement.md

fixing SS

Docs Build status updates of commit 1d9f2bf:
:x: Validation status: errors
Please follow instructions here which may help to resolve issue.

File
Status
Preview URL
Details

:x:Error

Details

[Error] Cannot sync git repo to specified state. Please make sure the pull request is mergeable. Details: Git merge results in conflict, repository remote url: https://github.com/MicrosoftDocs/msftdynamicsgpdocs, working directory: W:\y2cr-s, target branch: HEAD, target branch commit: e6a36e6591be7106d70308ac7baeb8b2574ea45e, source commit: 1d9f2bfb400cf9a2047eb8b3aca3a3e8e0c663ac.

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.

Docs Build status updates of commit 5c02398:
:warning: Validation status: warnings

File
Status
Preview URL
Details

dynamics-gp/distribution/ProjAcctCostManagement.md
:warning:Warning
View
Details

dynamics-gp/distribution/ProjAcctCostManagement.md

Line 258: [Warning] Invalid file link:(~/distribution/media/051e992556a8e343d2f4096c675d8d78.jpg).
Line 292: [Warning] Invalid file link:(~/distribution/media/cda73ddeb4591455fa24b58d7a78f98c.jpg).
Line 351: [Warning] Invalid file link:(~/distribution/media/d8b89b896044100f36b1b958e7a7dc2c.jpg).
Line 388: [Warning] Invalid file link:(~/distribution/media/4349318b6074383318b47ccdb75c20fb.jpg).
Line 428: [Warning] Invalid file link:(~/distribution/media/86e0c89ef872f6fbbbc4b8ccdb52f4bb.jpg).
Line 460: [Warning] Invalid file link:(~/distribution/media/e904916f422da929fc7a080fafd70233.jpg).
Line 527: [Warning] Invalid file link:(~/distribution/media/b72ae65a548ccd7de909fcef542bd876.jpg).
Line 596: [Warning] Invalid file link:(~/distribution/media/153b8b891ea7eca8abd9dea356704d69.jpg).
Line 618: [Warning] Invalid file link:(~/distribution/media/e0ca55484b39509f048f2965d619c21e.jpg).
Line 643: [Warning] Invalid file link:(~/distribution/media/20ef112b6a2f11329b9bc8c716e2c908.jpg).
Line 745: [Warning] Invalid file link:(~/distribution/media/440792b76abaf3ddd8871e077ae22066.jpg).
Line 785: [Warning] Invalid file link:(~/distribution/media/83df8e4dc0425a7a50e20576b2f9fe93.jpg).
Line 811: [Warning] Invalid file link:(~/distribution/media/8fdf934bcfaf86ada62cd2e20d89438c.jpg).
Line 865: [Warning] Invalid file link:(~/distribution/media/8928b33a3547bae98e9d69d7b26a243a.jpg).
Line 927: [Warning] Invalid file link:(~/distribution/media/25966d693da1a9be845dbe936e6ceae1.jpg).
Line 957: [Warning] Invalid file link:(~/distribution/media/48e08b71a2ff599f1e0b07e8ba8b499b.jpg).
Line 1002: [Warning] Invalid file link:(~/distribution/media/919311ca836400f112815f77c239d0a1.jpg).
Line 1101: [Warning] Invalid file link:(~/distribution/media/c384f0cc8a7ee7e2e9cb38e456791270.jpg).
Line 1244: [Warning] Invalid file link:(~/distribution/media/c455e81242ba6fc6a21a2b23fe4df466.jpg).
Line 1271: [Warning] Invalid file link:(~/distribution/media/52ffca86ab9102e7c71245d9412bc314.jpg).
Line 1460: [Warning] Invalid file link:(~/distribution/media/60df6b2a725402ca4541f74cf287604b.jpg).
Line 1484: [Warning] Invalid file link:(~/distribution/media/baad6b9551b7a05290f642545adfc5db.jpg).
Line 1562: [Warning] Invalid file link:(~/distribution/media/83f90b4dac44c7671e549ef9d3029015.jpg).
Line 1598: [Warning] Invalid file link:(~/distribution/media/5fdb882a62bee24ed223b5569d72689a.jpg).
Line 1648: [Warning] Invalid file link:(~/distribution/media/f758239c31b573391cf6c8c059ce30fb.jpg).
Line 1723: [Warning] Invalid file link:(~/distribution/media/b2d7f77a6063fe7d96ffd2b01c4f6d31.jpg).
Line 1903: [Warning] Invalid file link:(~/distribution/media/206ae5d8deefcc108c1a08b23dc3e275.jpg).
Line 1950: [Warning] Invalid file link:(~/distribution/media/206ae5d8deefcc108c1a08b23dc3e275.jpg).
Line 2060: [Warning] Invalid file link:(~/distribution/media/4bb6d6184354988e1735deab0bc8a2e0.jpg).
Line 2121: [Warning] Invalid file link:(~/distribution/media/2effd7a4f400a7543699d31420ebe0f4.jpg).
Line 2165: [Warning] Invalid file link:(~/distribution/media/237e387149c618873c57f67f43528b9d.jpg).
Line 2257: [Warning] Invalid file link:(~/distribution/media/23989310712cf59a6f0ebd98b5a16cbc.jpg).
Line 2400: [Warning] Invalid file link:(~/distribution/media/2432376bce9e4653a8d56937dc77ed30.jpg).
Line 2505: [Warning] Invalid file link:(~/distribution/media/711906c69a5bdf16843cda1df66dc0df.jpg).
Line 2550: [Warning] Invalid file link:(~/distribution/media/f79f7fa9757f831aed3b9130758bdba0.jpg).
Line 2576: [Warning] Invalid file link:(~/distribution/media/f79f7fa9757f831aed3b9130758bdba0.jpg).
Line 2610: [Warning] Invalid file link:(~/distribution/media/92bae8d4430fd86eaafff4c0c0ac968e.jpg).
Line 2696: [Warning] Invalid file link:(~/distribution/media/a7adcbeeab02088b387680a8f88fd924.jpg).
Line 2792: [Warning] Invalid file link:(~/distribution/media/6e7190fab0e32fe7d1286ccd655aaa30.jpg).
Line 2900: [Warning] Invalid file link:(~/distribution/media/dbfc3573d05284d99da4d35b44f4da01.jpg).
Line 2963: [Warning] Invalid file link:(~/distribution/media/d909084f610a6323ee2a1f908c3467cb.jpg).
Line 3005: [Warning] Invalid file link:(~/distribution/media/23e5b41d1d92279635da0a427e685193.jpg).
Line 3050: [Warning] Invalid file link:(~/distribution/media/0db207251297d78216b92fca5d5a409b.jpg).
Line 3090: [Warning] Invalid file link:(~/distribution/media/414aecd31afcf23f7f79f4ae237c5916.jpg).
Line 3140: [Warning] Invalid file link:(~/distribution/media/099d321aec60a035f33006f21d116216.jpg).
Line 3181: [Warning] Invalid file link:(~/distribution/media/6e54ff9c4c0b5e11c1ef75563502a750.jpg).
Line 3227: [Warning] Invalid file link:(~/distribution/media/d8024522ae87b851f6e2f1914dd9934f.jpg).
Line 3247: [Warning] Invalid file link:(~/distribution/media/1c295763e23b2cd5091a34aa54a3dd9b.jpg).
Line 3309: [Warning] Invalid file link:(~/distribution/media/18f74f0f7d7dd2bb1f1bb9079cf91cfb.jpg).
Line 3324: [Warning] Invalid file link:(~/distribution/media/5456a6afe79aaad2773493e9bdadc9ea.jpg).
Line 3651: [Warning] Invalid file link:(~/distribution/media/b63bbff3736340d72cd573d980cf133b.jpg).
Line 3688: [Warning] Invalid file link:(~/distribution/media/66033321857d496ab9f9ee4d022e1ec0.jpg).
Line 3791: [Warning] Invalid file link:(~/distribution/media/ad8f14587d13adfeb7b0b3d6821047d1.jpg).
Line 3852: [Warning] Invalid file link:(~/distribution/media/b2bd77d9fcb526ff49b692bb70fc0026.jpg).
Line 3910: [Warning] Invalid file link:(~/distribution/media/32d4d5a451858f0460f7a776c7cd630b.jpg).
Line 3934: [Warning] Invalid file link:(~/distribution/media/8cde689d9612b16d989b3a48dc0a7928.jpg).
Line 4001: [Warning] Invalid file link:(~/distribution/media/5dc241e1406fac3fcaf134bb3c8b5d64.jpg).
Line 4046: [Warning] Invalid file link:(~/distribution/media/c480881236d97d4f76c7a5ed1e3cf9f8.jpg).
Line 4065: [Warning] Invalid file link:(~/distribution/media/fe20974744f3acd3708f0ab26f3b3e25.jpg).
Line 4081: [Warning] Invalid file link:(~/distribution/media/65e8f62548a259d6111b4a25daa9c361.jpg).
Line 4118: [Warning] Invalid file link:(~/distribution/media/5c6cd6cbf9a696169099cf9bdf0b859c.jpg).
Line 4176: [Warning] Invalid file link:(~/distribution/media/11e074f225dfe2bbf1cf003a1caa1b9c.jpg).
Line 4210: [Warning] Invalid file link:(~/distribution/media/ffe2ace3c55ebd83d90f623a30a44922.jpg).
Line 4395: [Warning] Invalid file link:(~/distribution/media/268df7f7f022249982e3905ad421d303.jpg).
Line 4467: [Warning] Invalid file link:(~/distribution/media/41489c774f3dc5aa181a01e08ca35c81.jpg).
Line 4625: [Warning] Invalid file link:(~/distribution/media/50198e93985d4f37e685d5ec9e0110b7.jpg).
Line 4695: [Warning] Invalid file link:(~/distribution/media/b7147292688c76ae43e4ad6818de1ae7.jpg).
Line 4795: [Warning] Invalid file link:(~/distribution/media/c1a6cd822a91a88556951c5b207c254e.jpg).
Line 4840: [Warning] Invalid file link:(~/distribution/media/6af2dc88ef52429faa773229996417c2.jpg).
Line 4888: [Warning] Invalid file link:(~/distribution/media/4d08715503d646aa98139ee357603d57.jpg).
Line 4942: [Warning] Invalid file link:(~/distribution/media/971da95e84eac89cccd6405e4e8ef4ba.jpg).
Line 5024: [Warning] Invalid file link:(~/distribution/media/557a32765f4d3647867160e8fde5cda9.jpg).
Line 5050: [Warning] Invalid file link:(~/distribution/media/a39618325b94d250e39bf523b7e15f79.jpg).
Line 5204: [Warning] Invalid file link:(~/distribution/media/36adc9fa28870d1325d6060d5d33e210.jpg).
Line 5288: [Warning] Invalid file link:(~/distribution/media/ada93c7ebc38499698458cd9f732295d.jpg).
Line 5392: [Warning] Invalid file link:(~/distribution/media/4e2db0e9219c7ed69183a5a671d24dcf.jpg).
Line 5434: [Warning] Invalid file link:(~/distribution/media/cb882cdeaa38cf5d3049b4ea2b4b3f4c.jpg).
Line 5468: [Warning] Invalid file link:(~/distribution/media/1f8a87142f15da927fdcecaa329186bd.jpg).
Line 5553: [Warning] Invalid file link:(~/distribution/media/1b1565b5cb227a9cf8f6070524ae4bb1.jpg).
Line 5660: [Warning] Invalid file link:(~/distribution/media/bf7989dfde3adde5e771b5a77c6332e6.jpg).
Line 5681: [Warning] Invalid file link:(~/distribution/media/5ef9827fb8d30029283d9fdd30eafc4e.jpg).
Line 5706: [Warning] Invalid file link:(~/distribution/media/7c1e858bd21786ee82f222a3faadcd0e.jpg).
Line 5731: [Warning] Invalid file link:(~/distribution/media/963e061bebdeeab68aa90ced14783102.jpg).
Line 5756: [Warning] Invalid file link:(~/distribution/media/a048fe2d3fac7d25a0ccd1b89c87a415.jpg).
Line 5787: [Warning] Invalid file link:(~/distribution/media/e468da8ee74550badc04c544f63bee8a.jpg).
Line 5821: [Warning] Invalid file link:(~/distribution/media/db8547c5647efb6f0ccd5090a013b5bd.jpg).
Line 5836: [Warning] Invalid file link:(~/distribution/media/4c1af9913e6f6fb7d69677cc9726ac7f.jpg).
Line 5860: [Warning] Invalid file link:(~/distribution/media/f87c88369b720d78bc2e69855547efdd.jpg).
Line 5905: [Warning] Invalid file link:(~/distribution/media/b7f8fdb9a440dae59cee4d0362e02c51.jpg).
Line 5948: [Warning] Invalid file link:(~/distribution/media/0f40a54b9178cc4dbc172dea6480f334.jpg).
Line 5967: [Warning] Invalid file link:(~/distribution/media/03779c402557bb6e6a80a494e1053dd0.jpg).
Line 5996: [Warning] Invalid file link:(~/distribution/media/2c2fb690aab1b245360145ee4c242ced.jpg).
Line 6042: [Warning] Invalid file link:(~/distribution/media/b653166875d6757e68e917814b906f16.jpg).

For more details, please refer to the build report.
Note: If you changed an existing file name or deleted a file, broken links in other files to the deleted or renamed file are listed only in the full build report.


Ensure error is returned if network or HTTP error occurs during command execution

Currently if an error occurs during command execution (such as a non-200 status code from WinRM server or a network interruption), WinRM will exit with an error code of 0 and not indicate that an error has occurred.
This ensures the error is passed through from slurpAllOutput to the return code of the program.
This is also how I discovered that with a Windows 8.1 remote host, I was getting the following error (due to the command not outputting data to stdout / stderr frequently enough):
http error: 500 - <s:Envelope xml:lang="en-US" xmlns:s="http://www.w3.org/2003/05/soap-envelope" xmlns:a="http://schemas.xmlsoap.org/ws/2004/08/addressing" xmlns:x="http://schemas.xmlsoap.org/ws/2004/09/transfer" xmlns:e="http://schemas.xmlsoap.org/ws/2004/08/eventing" xmlns:n="http://schemas.xmlsoap.org/ws/2004/09/enumeration" xmlns:w="http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd" xmlns:p="http://schemas.microsoft.com/wbem/wsman/1/wsman.xsd"><s:Header><a:Action>http://schemas.dmtf.org/wbem/wsman/1/wsman/fault</a:Action><a:MessageID>uuid:B151B169-93FA-4738-8826-A929F0DB280F</a:MessageID><a:To>http://schemas.xmlsoap.org/ws/2004/08/addressing/role/anonymous</a:To><a:RelatesTo>uuid:f608b328-26a1-4de5-6e4b-a812045fde6c</a:RelatesTo></s:Header><s:Body><s:Fault><s:Code><s:Value>s:Receiver</s:Value><s:Subcode><s:Value>w:TimedOut</s:Value></s:Subcode></s:Code><s:Reason><s:Text xml:lang="en-US">The WS-Management service cannot complete the operation within the time specified in OperationTimeout.  </s:Text></s:Reason><s:Detail><f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150858793" Machine="<IP_ADDRESS>"><f:Message>The WS-Management service cannot complete the operation within the time specified in OperationTimeout.  </f:Message></f:WSManFault></s:Detail></s:Fault></s:Body></s:Envelope>

Closing because merged from #25.


Cannot compile  GNU Hello in outside linux filesystem image

Your Windows build number:  (Type ver at a Windows Command Prompt)
Microsoft Windows [Version 10.0.15063]

What you're doing and what's happening:  (Copy&paste specific commands and their output, or include screen shots)

It's a very simple test. I compiled GNU Hello in linux filesystem image and outside that. In linux filesystem image, I can compile it, but outside that, I cannot comile, with same condition and command but position.

@MikeGitb - In CASE2 only, not in CASE1;
SUNJOONG-DESKTOP hello-2.10 # make
CDPATH="${ZSH_VERSION+.}:" && cd . && /bin/sh /mnt/c/Users/sunjoong/Desktop/hello-2.10/build-aux/missing aclocal-1.14 -I
 m4
/mnt/c/Users/sunjoong/Desktop/hello-2.10/build-aux/missing: line 81: aclocal-1.14: command not found
WARNING: 'aclocal-1.14' is missing on your system.
         You should only need it if you modified 'acinclude.m4' or
         'configure.ac' or m4 files included by 'configure.ac'.
         The 'aclocal' program is part of the GNU Automake package:
         <http://www.gnu.org/software/automake>
         It also requires GNU Autoconf, GNU m4 and Perl in order to run:
         <http://www.gnu.org/software/autoconf>
         <http://www.gnu.org/software/m4/>
         <http://www.perl.org/>
make: *** [Makefile:1450: aclocal.m4] Error 127

I found why this will happens.
I did not modify 'acinclude.m4' or 'configure.ac' m4 files included by 'configure.ac'.
But, make knew those files were modified because of VFS design.
https://github.com/Microsoft/BashOnWindows/issues/1939#issuecomment-294972527
That's worthy to be called bug because  it will make many potential problems.
Now, I understand why that happened and  knew @SvenGroot had been self-assigned to this bug,
so I'll close this issue.


Copy changes after Spanish translation

After providing the en.json to the translation team, we've made some copy changes (there may be others) that may not be captured in the original es.json.

#2076
#2141
#2134
#2118
#2135
#2110
#2170

These may be a part of a second batch to the translation team or maybe we can translate it ourselves.

Can we lump the changes to the readme and installation files into this?

FAQ number 5
beta version download button


CameraEntity and PlayerEntity in ECS and Renderer

Those will be new reserved entities (static number below 512). Documented at https://github.com/decentraland/sdk/blob/main/docs/static-entities.md
Those entities will receive CRDT messages from the renderer with Transform components to replace the positionChanged and rotationChanged events.
The CRDT messages for transforms of both entities will be ignored by the renderer. We can leverage this to later setup a permission system for whom can update which components of each entity.
Entities children of PlayerEntity and CameraEntity will be used achieve the feature parity of the attach to camera and avatar functions of the SDK6

https://github.com/decentraland/unity-renderer/pull/2663
renderer is sending the Transform for Camera and Player entities


Blank CONJUR_SSL_CERTIFICATE gives error

If I try to use the Ruby API with a CONJUR_SSL_CERTIFICATE environment variable set to a blank value, I get the error:
ERR OpenSSL::X509::CertificateError: header too long
Ideally the Ruby API will treat a blank value for this env var the same as if this env var were unset.

The Ruby API is actually handling this quite elegantly - the issue I experience appears to be related to some code in the Conjur service broker. I've opened a new issue in that repo here, and will be closing this issue.


Predicted Output Groundtruth Images is 0

I tried to train and test unet3D with
"epoch", 90
"number_train_images", 5
but the output of CSF,GM,WM are all 0 (I have already checked the input image and label, Label unique:[0 10 150 250])

I also  train and test proposed_model and the output image is as follows

Ask for help！Thanks a lot！

Hi !  I have encoutered the same questions with you and I havn't fix it. I have noticed that  the two UndefinedMetricWarning ，maybe the problem is in this  place.
@ @kurodasho

UndefinedMetricWarning

Hi, have you fixed it? I have encoutered the same questions.

Hi, have you fixed it? I have encoutered the same questions.

Hi ! I have encoutered the same questions with you and I havn't fix it. I have noticed that the two UndefinedMetricWarning ，maybe the problem is in this place.
@ @kurodasho
Hi ! I have encoutered the same questions with you and I havn't fix it.Hava you fixed it?

Hi, have you fixed it? I have encoutered the same questions.

Hi, have you fixed it? I have encoutered the same questions.


Pauli expansion protocol

Logic for expanding an operator in the Pauli basis extracted from #1299 into a protocol.

This is ready for re-review. Coverage fails because protocol consistency checks have been disabled for parametrized code. They should pass once #1399 is merged here.

(Blocked on https://github.com/quantumlib/Cirq/pull/1396)


Cannot merge lines with same relations in it when the relations have different order

URL
No response
How to reproduce the issue?
When adding a line with relations (e.g. separate multipoly away from some feature like footpath) I cannot merge the new line with another line containing same relations, when those relations are in different order.
This should normally work as the relation list contains same elements.
example: selected are 2 connected lines (sharing point on top-left):

line1 relations:

line2 relations:

Workaround: Edit the relations so they are in the same order then merge option is active and merge works.
Workaround2: Commit eventual changes (or restart editor) -> the merge option is available (also the relations are now in same order)
To reproduce (simple version): just split any line with 2+ relations, select one of the lines, delete first relation, add the same relation (will be added at the end). Merge the lines (will not work).
Screenshot(s) or anything else?
No response
Which deployed environments do you see the issue in?
version 2.24.2
What version numbers does this issue effect?
No response
Which browsers are you seeing this problem on?
No response

It's been like that for quite some time, and annoys the hell out of me; it was introduced with validation of relations on way merging. There's a set of related outstanding bugs - see also #8167, #9311.


[ADD]: PyShell Tool

AIM
Remote Access Trojan - RAT
Features

Upload And Download Files
Execute os Command
Get Victim Address
openfile in victim device
open url in Victim Browser
print message in Victim terminal
see who is up on the victim network
Take screenshot from victim device

Checklist

[X] I have checked the existing issues
[X] I have read the Contributing Guidelines
[X] I am willing to work on this issue (optional)
[X] I am a GSSoC'23 contributor

/assign