Allow setting build env variables such as GOOS=windows GOARCH=amd64

We have a windows-specific app that needs to be built from both our local machines (MacOS) as well as our CI (Linux). We can set environment variable in CI however local development is hindered with this limitation and doesn't really fall within the NX approach if you have to set variables outside of the build tooling.
One suggestion is to pass the cwd option to the runGoCommand when building. This would allow you to set any environmental variables required.
I'm not sure how you cater for this in https://github.com/nx-go/nx-go/blob/main/packages/nx-go/src/executors/build/executor.ts as the file naming logic is looking at the platform to decide whether to set the file extension.

@the0rem I think you can set Nx environment variables in files and before the command, does this link help at all? https://nx.dev/recipes/tips-n-tricks/define-environment-variables

This issue is stale and should be closed.
There is a direct way to handle this now by adding the environment variables to the project.json file, for example:
{
  "name": "goxample",
  "$schema": "../../node_modules/nx/schemas/project-schema.json",
  "projectType": "application",
  "sourceRoot": "apps/goxample",
  "tags": [],
  "targets": {
    "build": {
      "executor": "@nx-go/nx-go:build",
      "options": {
        "main": "{projectRoot}/main.go",
        "env": {
          "CGO_ENABLED": "0",
          "GOOS": "linux"
        }
      }
    },
    "serve": {
      "executor": "@nx-go/nx-go:serve",
      "options": {
        "main": "{projectRoot}/main.go"
      }
    },
    "test": {
      "executor": "@nx-go/nx-go:test"
    },
    "lint": {
      "executor": "@nx-go/nx-go:lint"
    },
    "tidy": {
      "executor": "@nx-go/nx-go:tidy"
    }
  }
}

@abramsimon
This issue is stale and should be closed.
There is a direct way to handle this now by adding the environment variables to the project.json file, for example:

Thank you for the feedback! So you think we won't need these environment variables dynamically depending on the current runtime environment? Because in your example, they are static regardless of the operating system.

@utarwyn Thanks for the reply! You're correct that my example didn't really address the original issue as stated. Oops! I do believe that my point stands and that you shouldn't put any more effort into this particular issue. Let me elaborate...
My team is using nx-go in the same way that OP described: we use MacOS for development and deploy to a linux container environment.
For local development and testing we either:

run the code via the nx serve target with no environment variables (the underlying go run command works without them)
add a secondary nx target called build-local that has the correct env vars set, for example:

  "targets": {
    "build-local": {
      "executor": "@nx-go/nx-go:build",
      "options": {
        "main": "{projectRoot}/main.go",
        "env": {
          "CGO_ENABLED": "0",
          "GOOS": "darwin",
          "GOARCH": "arm64"
        }
      }
    },
  }

This allows the original build target to be used in CI. Or you could do the reverse and add a new target for CI and use the original for local development.
The point being that the nx-go plugin doesn't need to do anything special to support OP's use-case.

@abramsimon thank you for the detailed explanation! Much appreciated 👍
In fact, several targets can be created to meet the initial need. So I'm closing this ticket, and if you have a bit of time it would be quite relevant to have a discussion here to explain how to do it.


release: bump configuration to v0.1.0-rc.9, update changelog

dev config is currently broken, closing. Will make another release PR once fixed


Possible overlap between SIM300 and PLC2201

From my understanding the rules C2201 (PLC2201 in ruff) and SIM300 are pretty much the same.
If that's the case I'd suggest to drop one in favour of the other.
PLC2201 got introduced in #1023, SIM300 in #1539.

Yeah I agree with this. My gut reaction is to remove PLC2201. In the future, we should be able to map rules to multiple codes for compatibility purposes (see, e.g., #1941 which lays the foundation), although there are some questions to answer around how that works with --select ALL, # noqa` , etc.

These rules are actually slightly different because the Pylint rule flags any comparison (e.g., i >= 5).

I'll probably extend SIM300 to flag those cases too.


client: fixup JSON names for ofac.AlternateIdentity

Codecov Report

Merging #61 into master will not change coverage.
The diff coverage is n/a.

@@          Coverage Diff           @@
##           master     #61   +/-   ##
======================================
  Coverage    62.1%   62.1%
======================================
  Files          17      17
  Lines        1338    1338
======================================
  Hits          831     831
  Misses        418     418
  Partials       89      89


Adventure game code

It could be nice to have the Adventure game source code from the "Imperial Programming Lectures 15 October 2015" available right here in /examples.

In the online lecture for 22 October, the source code related to the Adventure game is mostly not to be seen, only briefly now and then.

Jon Kleiser wrote:

In the online lecture for 22 October, the source code related to the
Adventure game is mostly not to be seen, only briefly now and then.

I think he was showing it in the live-coding view, which (for me)
appeared only for a few seconds at the beginning of the recording.
I guess a problem with Imperial's video site.
Jim

I think it's here https://github.com/sylvanc/pony-lecture

Great! Thanks.
On 24. okt. 2015, at 10.15, Kamil Chmielewski <notifications<EMAIL_ADDRESS>wrote:
I think it's here https://github.com/sylvanc/pony-lecture
—
Reply to this email directly or view it on GitHubhttps://github.com/CausalityLtd/ponyc/issues/325#issuecomment-150774929.


Zoom Option for full screen viewing

Acknowledgements

[X] I have searched the existing issues and this is a new ticket, NOT a duplicate or related to another open issue.
[X] I have written a short but informative title.
[X] If this is an issue with an extension, I should be opening an issue in the extensions repository.
[X] I have updated the app to the latest version.
[X] I will fill out all of the requested information in this form.

Describe your suggested feature
When we watch animes on phone it is not full screened in the original size, so usually apps provide a zoom to fill or resize option which helps to make the video fullscreen in phone with notch...
I am currently watching One Piece in aniyomi, as the video shape of one piece is square i am having problems, so it would be really nice if aniyomi had resize/zoom to fill option.
Other details
No response

If you are watching anime in dub, then the idea is excellent! But if it is on sub, then if the video is zoomed-in, it will be harder to read the subtitles “if you can’t understand Japanese” since the subtitles are hardcoded. Unless a service supports soft subtitles that are not burned in the video but just an overlay, the subtitles will adjust their location even if you zoom in on the video.
P.S. I might be wrong, but this is my idea. Please correct me if I am wrong.

Closing because this feature was added


Metadata table

Fixes #80

Failed check is due to a schema breaking change in the PCM-DPC data set. Merging despite airflow test fail.


Package libjpeg and libpng within torchvision

With the addition of image-reading functions enabled by default in torchvision #1632 #1881 #1909, we will need to properly package libjpeg and libpng (and other libraries will be used soon as well, like ffmpeg) so that users of {Windows, Linux, OSX} x {pip, conda, source} can use those new functionalities in torchvision without issues.
I believe the current recommended way that PyTorch deals with 3rd-party libraries is the following:

for conda, we use conda's package manager to handle the dependencies. Both libjpeg and libpng are available in standard channels, although I'm not sure if using the conda-forge channel would bring problems due to conflicts with other libraries we use.
for pip, I believe the preferred way is to include the libraries together with the torchvision wheel
for source, we would need to handle the common installation locations, or at least provide clear instructions on how to provide the path to the libraries, either via CMake or performing the handling via python like Pillow does (although the logic seems quite intricate).

We will also need to make sure our CI (which is fairly tied to binary builds) is updated.
cc @seemethere @rgommers

although I'm not sure if using the conda-forge channel would bring problems due to conflicts with other libraries we use.

It may right now I think, we really need to improve that situation. It would also force the users to mix channels. libpng is available in defaults. libjpeg-turbo is in defaults as well, but it looks outdated. Needs a more detailed look at what the best option is here.

for pip, I believe the preferred way is to include the libraries together with the torchvision wheel

@fmassa said that size of the wheels isn't critical, and just bundling in libpng and libjpeg should be fine for now. So using auditwheel (Linux) and delocate (macOS) seems like the way to go. There's no such tool for Windows, so there the right libs need to be copied in by hand.

@fmassa, is it possible to have assignment permissions on this repository?

@andfoy I gave you and @rgommers triage permissions to torchvision

@jjhelmus is it possible to update libjpeg-turbo to the latest version on the default channel in Anaconda? It seems that the current version (1.2.1) is older than the one found on conda-forge.

Is there a way to force the system to use a system libraries for instance libjpeg instead of the one with Pillow (default)?
I am asking this because the libjpeg library available in Pillow does not have debug symbols available which makes it hard to profile.


PT-6909 Extracted reader options to builder from private methods

One more piece extracted from https://github.com/hellofresh/klepto/pull/110
This time - reader options extracted from implementations private methods to a builder function.

:+1:


Last minute bug fixes in master.

https://clusterhq.atlassian.net/browse/FLOC-1328
https://clusterhq.atlassian.net/browse/FLOC-1330
https://clusterhq.atlassian.net/browse/FLOC-1329

Thanks @tomprince
I think:

the additional of sudo in the ubuntu installation instructions is fine
the ssh-agent changes need more thought (see above)
the instructions to revisit the web app need further explanation (see comment above)

Ignore previous comment.
I hadn't realised that this was a proposed forward merge of already reviewed changes in the 0.3.2doc5 release branch.
I'll merge it.


sd ui遇到的奇怪的问题

我发现奇怪的bug，我秋叶启动器那打开这个扩展，webui就进不去，必须关闭然后进webui然后开启这个插件，重新加载，这样可以用。但是如果没关这个插件用秋叶启动器结束进程再重启启动就不行了。
必须每次启动webui前把这个扩展关闭

Some other extension may cause conflict with tipo such as supermerger
try to turn off some other ext and find which one have conflict
if you have something observed, please report later

Some other extension may cause conflict with tipo such as supermerger try to turn off some other ext and find which one have conflict
if you have something observed, please report later

发现一个问题，cuda12,4无法使用，编译轮子会跳转到https://jllllll.github.io/llama-cpp-python-cuBLAS-wheels/AVX2/cu124，然而没有这个版本，我强制指定122就好了

will check this


Move integration tests to different packages

While keeping unit tests in the same package as code is useful (so that we can test package scope code), this is less important for integration tests.  Moving integration tests to a separate package would provide some benefits, such as allowing us to catch issues related to member variable access.

The example brings up a fair point -- tough to argue with that. Is this at all standard is other libraries like ours ?

I have seen other projects (hibernate?) putting integration tests in a different module and package with respect to the code they test, so this is a good suggestion IMO.


Hide/Minimize the Add-ins

When I load the Add-in and start using it, there is no way to minimize or hide it. If I close it (click on x) I need to add the Add-in again:

The ping/upping functionality is not clear how works at least in Excel Web. If I close the excel file and open it again I need to install the Add-ins again.
I think it is a good idea, to have a way to minimize it, without the need to install it again, the Add-in uses a significant portion of the screen, so it would be nice to minimize it when you want to focus on the content of the excel file itself.

This is probably something controlled by the add-in host, rather than something AFE can control. Do you use any other add-ins? Do they behave the same?

thanks @jack-williams I use other add-ins, and they behave similarly, but at least I have the option to open it again:

but I don't have the option to re-open AFE.

I understand the issue more, thanks for the extra info.
Unfortunately, I do not think there is anything actionable in the short-term. We recently moved AFE from the Home tab to the Formulas tab based on some user feedback. We are unlikely to move it back unless there is some extra related change that would justify the location being in the Home tab.
I'll keep an eye on this though, I do understand the usability challenges you are facing.
Thanks again for the feedback.

@dlealv you can add the AFE icon on the home tab if you edit the ribbon. You can also add it to the quick access toolbar if you use it, so it will always be visible regardless of which ribbon tab you are on. This would have to be done on each device, or export the ribbon/quickaccess then import in another excel install.
Excel Options, then "Customize Ribbon" > Select "all commands" on left side > Create custom group in Home using "new group" button > Select AFE on left side and press "add" in the middle.

Thanks @gbin for the tip, but I use Excel for Web, I don't see such options. This is what I see from File->Option:

Regards,
David


:white_check_mark: test(core): Add some basic EVMtsContract tests

Description

Add basic tests for EVMts contract
Fix missing types

Testing
Explain the quality checks that have been done on the code changes
Additional Information

[ ] I read the contributing docs (if this is your first contribution)

Your ENS/address:

Current dependencies on/for this PR:

main

PR #219   👈

This comment was auto-generated by Graphite.


pythonPackages.python-miio: fix build

Motivation for this change
python-miio does not build-
ERROR: No matching distribution found for pytz<2020.0,>=2019.3 (from python-miio==0.5.3)

Things done
patch setup.py so any version is allowed
add some new dependencies
remove failing (broken?) test
testing:

remaining tests pass on python3.8

exeutables seem to function correctly

[x] Tested using sandboxing (nix.useSandbox on NixOS, or option sandbox in nix.conf on non-NixOS linux)

Built on platform(s)

[x] NixOS
[ ] macOS
[ ] other Linux distributions

[ ] Tested via one or more NixOS test(s) if existing and applicable for the change (look inside nixos/tests)

[ ] Tested compilation of all pkgs that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review wip"

[x] Tested execution of all binary files (usually in ./result/bin/)

[ ] Determined the impact on package closure size (by running nix path-info -S before and after)

[ ] Ensured that relevant documentation is up to date

[x] Fits CONTRIBUTING.md.

@jonringer thanks, applied and rebased

@jonringer importlib_metadata seems to be required on python 3.8:
Traceback (most recent call last):
  File "/nix/store/2xaplvp6mhnmacxx1z0xcxrn361mbc36-python3.8-python-miio-0.5.3/bin/.mirobo-wrapped", line 6, in <module>
    from miio.vacuum_cli import cli
  File "/nix/store/2xaplvp6mhnmacxx1z0xcxrn361mbc36-python3.8-python-miio-0.5.3/lib/python3.8/site-packages/miio/__init__.py", line 2, in <module>
    from importlib_metadata import version  # type: ignore
ModuleNotFoundError: No module named 'importlib_metadata'

then upstream incorrectly packaged it, it's part of the standard library, and should not be imported

superseded by https://github.com/NixOS/nixpkgs/pull/102183


Release pipeline broken

Release of containerd-shim-wasm failed at cargo publish step: https://github.com/containerd/runwasi/actions/runs/6237777084
Release of wasmtime shim succeeded. It's failure on cargo publish is expected: https://github.com/containerd/runwasi/actions/runs/6237783420
Release of wasmer and wasmedge shims failed at integration tests on Ubuntu 20.04.: https://github.com/containerd/runwasi/actions/runs/6237788078, https://github.com/containerd/runwasi/actions/runs/6237793051

The wasmer and wasmedge integration tests failures are a known issue.
The reason is that the release pipeline is invoking cargo test directly.
There are two options:

Parse the crate name, and use make test-{wasmtime,wasmedge,wasmer}
Copy what the makefile is doing, and use cargo test ... -- --test-threads=1

Option 2 would be simpler than doing string parsing on crate name, but means maintaining the test runner in both places.
It might also be worth noting that when we do docker buildx bake ... in the release pipeline, that is building all the binaries for all shims, instead of running only for the target shim. It's also a bit odd that we are building the shim in that step, after we succesfully built the shim with cargo build a few steps earlier.

The first point is really weird, can we re-run that workflow?

Going to re-release the crates

Noticed that wasmtime release does not container the shim binaries.
https://github.com/containerd/runwasi/releases/tag/containerd-shim-wasmtime%2Fv0.2.0

since we now generate gnu and musl build, I believe the name of the tar files have changed

containerd-shim-wasm failed again on cargo publish step
https://github.com/containerd/runwasi/actions/runs/6260852252/job/16999820595

Is libseccomp missing?

I think you are spot on @0xE282B0
https://github.com/containers/youki/issues/1454
I believe this is introduced by enabling seccomp unconditionally, which was not the case before.
Maybe that was a bad idea? That would break building the shims in containerd-wasm-shims that use cross, since libseccomp doesn't have a vendor feature.

Ah this reminds me that I've done something similar to the containerd-wasm-shims repo where the libseccomp feature was not turned on for linking with musl libc. Perhaps we could do something similar in this repo after PR https://github.com/containerd/runwasi/pull/236 that added Alpine build.
Btw, is alpine build using musl or glibc? I am getting a feeling that it's using musl and that's the cause of the issues with our release pipeline.
https://github.com/deislabs/containerd-wasm-shims/blob/main/containerd-shim-spin-v1/Cargo.toml#L15C80-L15C120

For runwasi, the simple solution would be to install libseccomp in the runner :-)

Alpine uses musl, the release pipeline builds both, gnu and musl binaries.

This should be fixed now


Dapr Client API: a unreasonble design for Shutdown  method

SDK API design:
Dapr Client API:
// Client is the interface for Dapr client implementation.
type Client interface {
	// InvokeBinding invokes specific operation on the configured Dapr binding.
	// This method covers input, output, and bi-directional bindings.
	InvokeBinding(ctx context.Context, in *InvokeBindingRequest) (out *BindingEvent, err error)

	// Shutdown the sidecar.
	Shutdown(ctx context.Context) error

	// WithTraceID adds existing trace ID to the outgoing context.
	WithTraceID(ctx context.Context, id string) context.Context

	// WithAuthToken sets Dapr API token on the instantiated client.
	WithAuthToken(token string)

	// Close cleans up all resources created by the client.
	Close()

        ......

	// GrpcClient returns the base grpc client if grpc is used and nil otherwise
	GrpcClient() pb.DaprClient
}

Dapr Service API
// Service represents Dapr callback service.
type Service interface {
        // AddServiceInvocationHandler appends provided service invocation handler with its name to the service.
        AddServiceInvocationHandler(name string, fn ServiceInvocationHandler) error
        // AddTopicEventHandler appends provided event handler with its topic and optional metadata to the service.
        // Note, retries are only considered when there is an error. Lack of error is considered as a success
        AddTopicEventHandler(sub *Subscription, fn TopicEventHandler) error
        // AddBindingInvocationHandler appends provided binding invocation handler with its name to the service.
        AddBindingInvocationHandler(name string, fn BindingInvocationHandler) error
        // RegisterActorImplFactory Register a new actor to actor runtime of go sdk
        RegisterActorImplFactory(f actor.Factory, opts ...config.Option)
        // Start starts service.
        Start() error
        // Stop stops the previously started service.
        Stop() error
        // Gracefully stops the previous started service
        GracefulStop() error
}

Problems
There are several parts to the incoming traffic of Dapr Sidecar:

Non-Dapr ecological external service traffic;
The outgoing traffic of the local MicroLogic;
Dapr standardizes the InputBinding of component capabilities and the subscribe message of pubsub;
RPC requests from other Dapr Sidecars;

For the first and fourth points above, it is primarily served by the Dapr Client API, that is:

For the first point, external services can establish a connection with a Dapr Sidecar of the remote POD (Dapr Sidecar+MicroLogic) through the Dapr Client API(the remote address and port, such as a dapr sidecar service vip ), and then access all services in the Dapr cluster, including standardized component capabilities and RPC capabilities;

For the fourth point, MicroLogic accesses the local Dapr Sidecar through the Dapr Client API, and then accesses standardized component capabilities and RPC capabilities;

For the Dapr Client API, there will be a method: Shutdown, which is used to close the Dapr Sidecar that appears in MicroLogic's local pair, that is, when the MicroLogic Client actively closes Shutdown first, stops the Dapr Sidecar from providing services to the outside world, and then passes the Close method. Close the connection between MicroLogic and Dapr Sidecar;
But there is a big problem here. When the non-local MicroLogic external service establishes a connection with the Dapr Sidecar through the remote address port, it seems that the Shutdown method of the Dapr Client API can be called, which directly closes the remote POD ( Dapr Sidecar+MicroLogic), this is too dangerous.
So here I think it exists some unreasonable designs:

For business services using Dapr Client API, it is not necessary to provide services externally through Dapr Sidecar;

For Dapr Service API, when MicroLogic provides external services, the external traffic can be routed into the local MicroLogic through Dapr Sidecar, and the traffic will be processed at the same time. When MicroLogic does not want to provide external services, the Dapr Sidecar should be prevented from receiving traffic and forwarded to the closed MicroLogic service. Therefore, when MicroLogic does not want to provide external services, it should first Shutdown the Dapr Sidecar to reduce traffic loss, and then close the connection between the Dapr Sidecar and MicroLogic.

Solutions:
solution 1:
The Shutdown channel of MicroLogic and Dapr Sidecar requires a specific token to complete the operation, and the token cannot be leaked to the outside world
solution 2:
Hide the Shutdown method. The Shutdown method should be placed in the Dapr Service API, not the Dapr Client API. Or we may delete Shutdown method in Dapr Client API, and be added to Stop/GracefulStop methods in Dapr Service API.  When MicroLogic actively closes the connection, firstly create a client connection between MicroLogic and Dapr Sidecar, and then use the Shutdown method of DaprClient API to close the Dapr Sidecar service.
/cc @yaron2 @daixiang0 @msfussell @artursouza

@1046102779 does this solve the issue? https://docs.dapr.io/operations/security/api-token/

@1046102779 does this solve the issue? https://docs.dapr.io/operations/security/api-token/

@1046102779 does this solve the issue? https://docs.dapr.io/operations/security/api-token/

I'm going to try it, but I think the second solution is better.

No matter 'Shutdown' or proposed 'GracefulShutdown', it is too dangerous to deploy dapr apps in production env if they are not secured, and I believe that's where api-token kicks in as @yaron2 points out.
And this issue cannot be solved by removing the corresponding admin commands from client SDK, since these APIs can be accessed without SDK.
I think the idea of 'graceful shutdown' is necessary for daprd, @yaron2 your opinion on this?


add riscv64 backend for cranelift.

I am been trying to add riscv64 backend for cranelift these days.
right now I have pass all run test in filetests.
some features not implemented right now.
i128 mul div  rem, all simd type  and compare overflow.
some test need platform support.
like bitrev need qemu-riscv64 support bitmanip and zbkb extension (don't know how to enable it.).

ci did not pass because I used  is_riscv_feature_detected which is in std library.

Hi @yuyang-ok -- thanks for this! I will take a detailed look next week when I'm back in the office. At a high level, my initial feedback is that new backends need to use ISLE for all instruction lowerings; we're working on migrating the others, and we don't want to create more work for ourselves by adopting a half-migrated backend. So, the lower_inst.rs file should be essentially empty (right now it has a bunch of handwritten lowerings). But now that you have a working backend, hopefully doing this is a bit easier than starting from scratch!

ok I will improve this.

@cfallin I didnot using isle to write a very much logic , I think isle is very good at match.turns out lower_inst.rs and isle.rs is quit large now!

@cfallin are you reviewing this?

hi @yuyang-ok -- no, not yet; I just got back this morning. I would expect this to take some time, especially for a 21k-line PR.
At a high level, though, three questions:

My question about ISLE is I think still unanswered: are you planning to update this PR to use only ISLE lowering patterns, and not handwritten code? That is our standard for all new backend code and we cannot merge a new backend that uses the legacy approach.

Grepping for "todo" in this code, I still see a bunch of comments -- picking one example, "//todo what is this??" We unfortunately can't merge things like that (they are fine for draft PRs but not for production code): please make a pass through the PR and resolve all TODOs or uncertainties.

I think it would also be good to talk about ongoing expectations once a new backend is merged. I mentioned this in some earlier feedback as well, but: we want to make sure that every backend has some person or people who specialize in the architecture actively involved in the project. This is part of why I'm asking about your future plans: this PR is the start, but shouldn't be the only step. To this end, would you be willing to attend the Cranelift biweekly meeting at some point so we can talk about your new backend and plans?
Thanks for all your hard work on this so far!

@cfallin I think it is fine to use ISLE to lowering inst instead of handwritten code, I think maybe the way I am using ISLE is not very good right now,I should  doing this part of work after the review.
yes,software is never an one time job,software will evolve from time to time,I think at least I can maintain riscv64 backend, I am happy  attend the Cranelift biweekly meeting at some point.

@cfallin I think need provides an extractor.
(decl value_inst(Inst)Value)
(extern extractor value_inst value_inst)

look like I will need them in "trapff" ... lowering.
So I can get compare parameters.

@cfallin still waiting for you review. :)

@yuyang-ok unfortunately, I still have not gotten to it, sorry.
It looks like you still have code in legacy handwritten lowerings, though you're slowly moving it over to ISLE -- that's good, please keep doing that. I think it makes the most sense to review this PR once that is done.
LIkewise, I still see large blocks of commented-out code. As a random example, I see
        // println!("xxxx : {}", buffer.disasm.unwrap());
        let code = buffer.buffer.data();
        // write_to_a_file("/home/yuyang/tmp/code.bin", code);
        //0:   000015b7                lui     a1,0x1
        //4:   23458593                addi    a1,a1,564 # 0x1234
        //8:   00b5053b                addw    a0,a0,a1
        //c:   00008067

Please carefully go over your code and remove anything you would not want merged into the main branch.
Regarding your continued pings: unfortunately, reviewing a 21,000-line PR is not a small task. It will probably take me a few days to a week to read through all of your code in detail. I have an enormous amount of work on my plate, with varying levels of priority. I also spent all last week with COVID and am still working through some backlog from that time away. So, I haven't gotten to this yet, and pinging me will not make the TODO list go faster.
While we very much appreciate the contribution -- having a RISC-V backend will be very valuable for Cranelift -- this process will require patience as well. Thanks!

@cfallin  ok ,thanks,take care of yourself.

@cfallin ok.

Hi @yuyang-ok, it's great that you've started the work on this, and thanks @cfallin for the mention. I do indeed have an interest in seeing this through.
I'll be able to give a thorough pass of this later today and throughout the rest of the week.

abi document I found it at https://github.com/riscv-non-isa/riscv-elf-psabi-doc

some part of wasmtime cannot compiler on target riscv64.
@cfallin @afonso360 @bjorn3 @bjorn3

@yuyang-ok a port of wasmtime's CPU-dependent bits -- the fiber library, and the trap handler details, at least -- would probably not be too much work beyond a pure Cranelift-only port, and is needed in any case for the port to be useful: otherwise, all we can do is exercise it with filetests. Enabling wasmtime on the platform allows us to run the Wasm test suite as well. So, yes, you've run into that missing support; would you be willing to build it? Or if not, perhaps another contributor could help?

@cfallin I like to give it a try.

can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.

can Someone help to port https://github.com/bytecodealliance/wasmtime/tree/main/crates/fiber to riscv64,
I am not very understand of this lib.
thanks.

I would suggest leaving that for a future PR. We can merge the backend independently and then start working on a port for wasmtime later. That would also make it a lot easier to review, since this is already a lot of code to review.

@cfallin is this project rely on v8,there are still some part not compile.

If v8 doesn't support riscv, it should be fine to disable the fuzzers that check wasmtime against v8.

@cfallin @bjorn3 @afonso360 @afonso360  I think  it's the time to review.I think I fix most of the problems.

@cfallin @bjorn3 @afonso360 @afonso360 I think it's the time to review.I think I fix most of the problems.

@yuyang-ok I scanned through the diff at places where I had left comments before, and it looks like almost none of my comments have been addressed. Some of them are fairly small things, like formatting and typo fixes; others are more substantial, like "no commented-out code, please" or a general indication that some code needs to be cleaned up. Could you please address all of these comments, and then let us know when that is done?
Also, above (in this comment I see @dunxen expressed interest in making a clean-up pass over this PR. @dunxen, are you still willing to do this? If so, it seems that either after @yuyang-ok makes a pass or beforehand (coordinating with them as necessary) might be a good time for this. Thanks (and no worries if no longer able)!
I'm happy to see the qemu CI job added (does this mean Wasmtime fully works now?); I look forward to seeing this merged eventually, once it is cleaned up a bit!

@cfallin ok , I will do a full check.

wasmtime is not fully workd,because rusty_v8 cannot be compiler on riscv64.

wasmtime is not fully workd,because rusty_v8 cannot be compiler on riscv64.

That's fine, as @bjorn3 mentions above V8 is only needed for one fuzzing target. You can disable it on riscv64.

why I cannot find all conversations.

some comment not show. why?

Running cargo test --target riscv64gc-unknown-linux-gnu from the root of the repository it looks like we are also missing some other stuff for wasmtime, such as trampolines and trap handling.

Output:
error: unsupported architecture
  --> crates/runtime/src/trampolines.rs:55:9
   |
55 |         compile_error!("unsupported architecture");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: unsupported architecture
  --> crates/runtime/src/traphandlers/backtrace.rs:46:9
   |
46 |         compile_error!("unsupported architecture");
   |         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: unsupported platform
   --> crates/runtime/src/traphandlers/unix.rs:232:13
    |
232 |             compile_error!("unsupported platform");
    |             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

error: cannot find macro `wasm_to_libcall_trampoline` in this scope
   --> crates/runtime/src/libcalls.rs:100:17
    |
100 |                 wasm_to_libcall_trampoline!($name ; [<impl_ $name>]);
    |                 ^^^^^^^^^^^^^^^^^^^^^^^^^^
...
130 |     wasmtime_environ::foreach_builtin_function!(libcall);
    |     ---------------------------------------------------- in this macro invocation
    |
    = note: this error originates in the macro `libcall` (in Nightly builds, run with -Z macro-backtrace for more info)

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:227:9
    |
227 |         arch::assert_entry_sp_is_aligned(first_wasm_sp);
    |         ^^^^ use of undeclared crate or module `arch`

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:230:13
    |
230 |             arch::assert_fp_is_aligned(fp);
    |             ^^^^ use of undeclared crate or module `arch`

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:242:16
    |
242 |             if arch::reached_entry_sp(fp, first_wasm_sp) {
    |                ^^^^ use of undeclared crate or module `arch`

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:252:18
    |
252 |             pc = arch::get_next_older_pc_from_fp(fp);
    |                  ^^^^ use of undeclared crate or module `arch`

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:258:24
    |
258 |             assert_eq!(arch::NEXT_OLDER_FP_FROM_FP_OFFSET, 0);
    |                        ^^^^ use of undeclared crate or module `arch`

error[E0433]: failed to resolve: use of undeclared crate or module `arch`
   --> crates/runtime/src/traphandlers/backtrace.rs:260:57
    |
260 |             let next_older_fp = *(fp as *mut usize).add(arch::NEXT_OLDER_FP_FROM_FP_OFFSET);
    |                                                         ^^^^ use of undeclared crate or module `arch`

error[E0308]: mismatched types
   --> crates/runtime/src/traphandlers/unix.rs:167:73
    |
167 | unsafe fn get_pc_and_fp(cx: *mut libc::c_void, _signum: libc::c_int) -> (*const u8, usize) {
    |           -------------                                                 ^^^^^^^^^^^^^^^^^^ expected tuple, found `()`
    |           |
    |           implicitly returns `()` as its body has no tail or `return` expression
    |
    = note:  expected tuple `(*const u8, usize)`
            found unit type `()`

Some errors have detailed explanations: E0308, E0433.
For more information about an error, try `rustc --explain E0308`.
error: could not compile `wasmtime-runtime` due to 11 previous errors
warning: build failed, waiting for other jobs to finish...

@afonso360  I will give a try to fix these.

a little update.
cranelift can pass test on riscv64.
@cfallin I think I resolved most of modify that you request.
wasmtime test test_successful_compile not pass.

since I am not familiar with wasmtime's code . maybe still need some time to fix.

hey @cfallin @bjorn3  maybe need a little help here.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/as.20help.20about.20utf8_to_latin1.2E/near/293465163

https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return  address from stack if frame is set up?

https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?

I think so.

https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/cranelift.20opcode.20get_return_address.2E
should load return address from stack if frame is set up?

I think so.

but I think I can't get if_frame_is_set_up at isle lowering stage. maybe I am not find the current function????

I think iadd_ifcout can't be lowering.
https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/ask.20help.20for.20iadd_ifcout.2E/near/293648283

Yes, But My local qemu-riscv64 emulator doesn't implement it, I can't test it. right now I have two implemetion,
One rely on B extension , One don't.

It's nice that we have both lowerings. Usually it's fine to select extensions in the runtest suite that the host does not implement. What we do is, at runtime check if the host has those features and skip them if they don't, so we could for example do something like:
target riscv64
target riscv64 has_b

Which would test both versions of the instruction. However it looks like we are missing cranelift-native support, and we can't implement that because is_riscv_feature_detected! is unstable.
I'm not sure if there is a way around this, but it would be nice to test those instructions.

a little update. finally there is not segfault. :-)
but still some test will fail.

https://github.com/bytecodealliance/regalloc2/issues/72

https://gitlab.com/qemu-project/qemu/-/issues/1178

Left a comment on https://gitlab.com/qemu-project/qemu/-/issues/1173. It was incorrectly closed based on my reading of the riscv spec.

By the way which test is https://gitlab.com/qemu-project/qemu/-/issues/1178 for?

So this isn't a qemu bug after all. https://gitlab.com/qemu-project/qemu/-/issues/1173#note_1079580087:

Ah, I see what you mean now. I am pretty sure this is the result of a bitcast from i32 -> f32 using FMV.D.X as move instead of FMV.W.X as required for 32bit floats. This is because f64 is passed as type at https://github.com/bytecodealliance/wasmtime/pull/4271/files#diff-6ce7e9721c05ddbf92ec1a5e11518e9833cd3f6c12d30f3131c4baf4d8ca2127R171-R172

By the way which test is https://gitlab.com/qemu-project/qemu/-/issues/1178 for?
related to https://gitlab.com/qemu-project/qemu/-/issues/1178

a little update.
test wast::Cranelift::spec::skip_stack_guard_page ... ok

failures:

failures:
    memory::offsets_static_dynamic_oh_my
    pooling_allocator::table_limit
    wast::Cranelift::misc::memory64::simd
    wast::Cranelift::misc::simd::almost_extmul
    wast::Cranelift::misc::simd::canonicalize_nan
    wast::Cranelift::misc::simd::cvt_from_uint
    wast::Cranelift::misc::simd::issue_3173_select_v128
    wast::Cranelift::misc::simd::issue_3327_bnot_lowering
    wast::Cranelift::misc::simd::replace_lane_preserve
    wast::Cranelift::misc::simd::spillslot_size_fuzzbug
    wast::Cranelift::misc::simd::unaligned_load
    wast::Cranelift::misc::simd::v128_select

test result: FAILED. 626 passed; 12 failed; 10 ignored; 0 measured; 0 filtered out; finished in 616.44s

error: test failed, to rerun pass '--test all'

Getting very close, @yuyang-ok -- that's very exciting!

https://bytecodealliance.zulipchat.com/#narrow/stream/206238-general/topic/target-riscv64.20.20decommit_table_pages.2E

@cfallin @bjorn3 @afonso360  right now only simd test failed.
failures:
    memory::offsets_static_dynamic_oh_my
    wast::Cranelift::misc::memory64::simd
    wast::Cranelift::misc::simd::almost_extmul
    wast::Cranelift::misc::simd::canonicalize_nan
    wast::Cranelift::misc::simd::cvt_from_uint
    wast::Cranelift::misc::simd::issue_3173_select_v128
    wast::Cranelift::misc::simd::issue_3327_bnot_lowering
    wast::Cranelift::misc::simd::replace_lane_preserve
    wast::Cranelift::misc::simd::spillslot_size_fuzzbug
    wast::Cranelift::misc::simd::unaligned_load
    wast::Cranelift::misc::simd::v128_select

test result: FAILED. 627 passed; 11 failed; 10 ignored; 0 measured; 0 filtered out; finished in 793.71s

@cfallin maybe another review?

@yuyang-ok I'll give it another review sometime in the next week -- thank you very much for your patience and hard work here!
I will say overall that given that the backend passes tests for Wasm-MVP now, it's very likely we will be able to merge it; it's probably just a matter of some cleanup. We have precedent for disabling SIMD tests on platforms until SIMD is complete, so that should be fine.

@cfallin ok,thanks.

@yuyang-ok I spent some time today going through this PR again. It's looking quite good overall; thank you again for the work!
I pushed a few fixups and a merge of the latest main to your branch. With this, I'm now happy with all the Rust code in cranelift/codegen/src/isa/riscv64, and I'll take a look soon at the remainder.
My main feedback now -- and I promise we're really close -- is:

The ISLE code has some strange formatting in places. I think I made some comments earlier about this, but it would be great if you could make a pass through it all and normalize it. Things like: spaces before opening parentheses (so (decl term (A) B), not (decl term(A) B)), removing extraneous spaces otherwise (no ((a b  )  )), and putting closing parentheses on the same line.
Maybe there is an autoformatter out there somewhere that can help; I haven't looked closely. Anyone else have ideas?

There are a few extractors like iadd_ifcout_parameters that serve to unwrap an instruction, just like (iadd_ifcout ...) would; it's unclear why they exist. Could you remove these or add comments noting why they are needed otherwise?

If there are any other tests that don't pass, we need a completely clean CI run to merge. I went ahead and disabled SIMD tests in my changes I just pushed; it's fine to merge a backend initially without this, as long as there is a plan to add it eventually.

I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.

We should ensure that we fail cleanly on modules with SIMD, just like s390x did before it gained SIMD support.

And I think that's it! Let me know if anything above is unclear; happy to help further.

@cfallin That is true the ISLE formatting is strange.
I have aleardy remove extraneous spaces.
The reason I didn't pay much attention to ISLE formatting is that I am not very get used to the ISLE grammar.
I think maybe leave some space let me clearly to see where parenthesis starts and ends.
I write like this deliberately.
(decl gen_float_round(FloatRoundOP Reg Type) Reg)
(rule
  (gen_float_round op rs ty)
  (let
    (
      (rd WritableReg (temp_writable_reg ty))
      (tmp WritableReg (temp_writable_reg $I64))
      (tmp2 WritableReg (temp_writable_reg $F64))
      (_ Unit (emit (MInst.FloatRound op rd tmp tmp2 rs ty)))
    )
    (writable_reg_to_reg rd)
  )
)

this makes me see the structure clearly. where add temporary variable and where to return.
iadd_ifcout_parameters is because of  riscv has no iflags, I need extrac the inputs to generate overflow.

I think maybe leave some space let me clearly to see where parenthesis starts and ends.
I write like this deliberately.

@yuyang-ok I'd prefer that we standardize on formatting. I agree that it can take a bit of work to get used to reading ISLE, as with any other language; but that's not a reason to do things differently in one part of the codebase vs somewhere else, IMHO. I also see some extra spaces in cases like this at the end of the line: ... (smulhi x y )) (the space after y). It's not a huge deal, but I also don't want to loosen standards here without a good reason. Thanks!

iadd_ifcout_parameters is because of riscv has no iflags, I need extrac the inputs to generate overflow.

The implementation here looks like it is equivalent to using (iadd_ifcout x y) to get the args, and then getting the type of x; so instead of writing (iadd_ifcout_parameters a b ty) here, you could write (iadd_ifcout a @ (value_type ty) b) instead. Then we can get rid of the custom extractors. Does that make sense?

@cfallin  seens work to me. look like ifcmp_parameters and ffcmp_parameters have this problem too.

@cfallin I already remove (smulhi x y ))  in y .

@cfallin  look like offsets_static_dynamic_oh_my need simd too.
test wast::Cranelift::spec::skip_stack_guard_page ... ok

failures:

failures:
    memory::offsets_static_dynamic_oh_my

test result: FAILED. 626 passed; 1 failed; 32 ignored; 0 measured; 0 filtered out; finished in 752.18s

error: test failed, to rerun pass '--test all'
[1]+  已完成               nohup ~/software/firefox/firefox-bin  (工作目录: ~)
(当前工作目录：~/projects/wasmtime/tests)

@cfallin look like offsets_static_dynamic_oh_my need simd too.
test wast::Cranelift::spec::skip_stack_guard_page ... ok

failures:

failures:
    memory::offsets_static_dynamic_oh_my

test result: FAILED. 626 passed; 1 failed; 32 ignored; 0 measured; 0 filtered out; finished in 752.18s

error: test failed, to rerun pass '--test all'
[1]+  已完成               nohup ~/software/firefox/firefox-bin  (工作目录: ~)
(当前工作目录：~/projects/wasmtime/tests)

It shouldn't, anymore: I excluded v128 loads from the test with the cfg directive in tests/all/memory.rs in this commit. Have you pulled the changes that I pushed?

@cfallin  I pulled your commit, only this test failed.

Ah! OK, I do remember this failure, sorry; it gets past an earlier issue and now is hitting a trapif that is not lowered for some reason. It's not SIMD-related, I don't think. Here's what I see (cross-compiling from Ubuntu/aarch64 and running under emulation with qemu-risc64):
---- memory::offsets_static_dynamic_oh_my stdout ----
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9
thread '<unnamed>' panicked at 'internal error: entered unreachable code: implemented in ISLE: inst = `trapif uge v5, heap_oob`, type = `None`', cranelift/codegen/src/isa/riscv64/lower_inst.rs:37:9

You'll probably need to look at what CLIF is being generated and make sure that the pattern is properly matched?

@cfallin  ok, thanks. solved.

it this another qemu wrong implementation??
 RUST_BACKTRACE=1  cargo test   --target    riscv64gc-unknown-linux-gnu --test host_segfault
    Finished test [unoptimized + debuginfo] target(s) in 0.83s
     Running tests/host_segfault.rs (/home/yuyang/projects/wasmtime/target/riscv64gc-unknown-linux-gnu/debug/deps/host_segfault-0362e2365a90b3f7)
thread 'main' panicked at '

expected a stack overflow on `hit async stack guard page with pooling allocator`
got status: signal: 9 (SIGKILL)

', tests/host_segfault.rs:213:13
stack backtrace:
   0: rust_begin_unwind
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/std/src/panicking.rs:584:5
   1: core::panicking::panic_fmt
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/panicking.rs:142:14
   2: host_segfault::run_test
             at ./tests/host_segfault.rs:213:13
   3: host_segfault::main
             at ./tests/host_segfault.rs:177:17
   4: core::ops::function::FnOnce::call_once
             at /rustc/4b91a6ea7258a947e59c6522cd5898e7c0a6a88f/library/core/src/ops/function.rs:248:5
note: Some details are omitted, run with `RUST_BACKTRACE=full` for a verbose backtrace.
error: test failed, to rerun pass '--test host_segfault'

I got a SIGKILL test on host_segfault.

@cfallin is this project rely on v8,there are still some part not compile.

I took a look at why CI's not working. It looks like rusty_v8 does not produce precompiled binaries for riscv. I disabled it for riscv and CI now runs tests, but its failing somewhere. I've also added a build CI job for riscv.
See these two commits:

https://github.com/afonso360/wasmtime/commit/636d0c3409845d04ddce01b375b548462ce8eb5d
https://github.com/afonso360/wasmtime/commit/1f2b5210b17736270a151f02fdd8e8d06ea739d4

@afonso360 ok, thanks a lot.

@cfallin I want disable host_segfault a little while  due to https://github.com/bytecodealliance/wasmtime/issues/4912.

@cfallin
diff --git a/tests/host_segfault.rs b/tests/host_segfault.rs
index 7a761678b..616430289 100644
--- a/tests/host_segfault.rs
+++ b/tests/host_segfault.rs
@@ -144,6 +144,10 @@ fn main() {
             },
             true,
         ),
+        #[cfg(not(any(target_arch = "riscv64")))]
+        // Due to `InstanceAllocationStrategy::pooling()` trying to alloc more 6000G memory.
+        // https://gitlab.com/qemu-project/qemu/-/issues/1214
+        // https://gitlab.com/qemu-project/qemu/-/issues/290
         (
             "hit async stack guard page with pooling allocator",
             || {

@yuyang-ok did you hit this error while using the patched qemu as our CI builds? (Start with qemu 6.1.0, then apply ci/madvise.patch) If yes, and still an error, then we can disable the test temporarily. But I'd prefer not to if our patched qemu runs it properly.
Otherwise, please go ahead and apply any other fixes (from Afonso above and any others needed) to get to green CI, make sure the other items in the list here are covered, and then ping me when ready -- thanks!

@cfallin  I still hit this error using the patched qemu.  I think we are ready.

@cfallin I still hit this error using the patched qemu. I think we are ready.

Well, no, if tests don't pass then we aren't ready. We need to somehow either find and fix the issue or disable tests.
Going back to my checklist from my previous comment:

The ISLE code has some strange formatting in places. I think I made some comments earlier about this, but it would be great if you could make a pass through it all and normalize it. Things like: spaces before opening parentheses (so (decl term (A) B), not (decl term(A) B)), removing extraneous spaces otherwise (no ((a b ) )), and putting closing parentheses on the same line.
Maybe there is an autoformatter out there somewhere that can help; I haven't looked closely. Anyone else have ideas?

There are a few extractors like iadd_ifcout_parameters that serve to unwrap an instruction, just like (iadd_ifcout ...) would; it's unclear why they exist. Could you remove these or add comments noting why they are needed otherwise?

If there are any other tests that don't pass, we need a completely clean CI run to merge. I went ahead and disabled SIMD tests in my changes I just pushed; it's fine to merge a backend initially without this, as long as there is a plan to add it eventually.

I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.

We should ensure that we fail cleanly on modules with SIMD, just like s390x did before it gained SIMD support.

I see that iadd_ifcout_parameters is now removed, so that's good, but can you confirm that you have addressed the other points, with comments or links to code you've added for each one?
I also see some unresolved comments from long ago for simple things like typos in comments. Can you make sure there are no open code-review comments, and they are all addressed?
Once all of these things are done, then we can proceed!

@cfallin
(decl gen_div_by_zero(Reg)InstOutput)
(rule
  (gen_div_by_zero r)
  (gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero))
)

this codestyle remove all extra space will not ok.
must be like this???
(decl gen_div_by_zero(Reg)InstOutput)
(rule
  (gen_div_by_zero r)
  (gen_trapifc (IntCC.Equal) (zero_reg) r (TrapCode.IntegerDivisionByZero)))

I stubbed out the "is feature compatible" code in Wasmtime's AOT object loader but we probably want something better there.
Yes, this is because is_riscv64_feature_detected not stable,I perfer not use it.

@cfallin  I think we  are ready.

I think you could do the same that for s390x, i.e. calling getauxval by yourself.
You can find a RISC-V example in std_detect (the implementation of is_riscv64_feature_detected!) here.

I think you could do the same that for s390x, i.e. calling getauxval by yourself.
You can find a RISC-V example in std_detect (the implementation of is_riscv64_feature_detected!) here.
still look a little hard to use to me. look like need use C???

@cfallin what do you think appropriate to solve is_riscv64_feature_detected???

@cfallin what do you think appropriate to solve is_riscv64_feature_detected???

If we want to wait for stabilization of the feature-detection macro in the standard library, I don't see anything wrong with assuming a baseline RISC-V ISA level for now (in other words, running with no features ever detected). Does this seem reasonable or would it result in important optimizations going missing?

Does this seem reasonable or would it result in important optimizations going missing?

popcnt,ctz,rev8,brev8 will fallback to loop implementation, seen reasonable to me, I think there instructions are used rare to me.

@cfallin ok,thanks. :-)

@cfallin ok,thanks. :-)

Congratulations!

How can I use this feature, is there documentation?
How can I set a target risc5 and produce Linux  risc5 elf binary?
I would want to use it like that:
wasmtime exampleProgram.wasm --target risc5

This work is for RISC-V not risc5.
You'll likely need to use riscv64gc as per the changes in this PR.

I see that we have binaries riscv64gc here: https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.2 therefore It should probably work on riscv64 Linux. So I tried to install wasmtime in riscv64 Linux but without success.
Probably there is a difference between riscv64 and riscv64gc  but I'm kinda new to these things, where can I learn it, any good resources?
[root@localhost ~]# curl https://wasmtime.dev/install.sh -sSf | bash
Error: Sorry! Wasmtime currently only provides pre-built binaries for x86_64 (Linux, macOS, Windows), aa
rch64 (Linux, macOS), and s390x (Linux).

[root@localhost ~]# uname
Linux
[root@localhost ~]# uname -p
riscv64

The script at https://wasmtime.dev/install.sh hasn't been updated yet for riscv64 support. You should probably directly download the binary from https://github.com/bytecodealliance/wasmtime/releases/tag/v2.0.2.


[REQUEST] Request github to activate discussions

In order to avoid cluttering the issue tracker with user questions it would be a good idea to ask github team to enable discussions for this repository.
When enabled it looks like https://github.com/ansible-community/molecule/discussions -- and you have the power to on/off at any time but because is in feature-preview mode you need to add a comment on https://github.community/t/can-one-apply-for-github-discussions-beta/121120/170 thread. It make take a couple of days for them to activate it. I am surprised they still monitor this long standing thread but I guess they want to slow-down the adoption in order to have enough time to scale it or implement other features.

I've applied. 👍


Support React Native

The first thing i want to say thank you so much to you tradingview/lightweight-charts team for create an awesome open source for us.
I'm currently using this lib as well for my business.
I hope that you guys can start to create a new version for mobile, react native. Because i know that for now, don't have to much chart lib support for mobile as well, like the way you did with this lib.
Best regards

I hope that you guys can start to create a new version for mobile, react native

Did you try to integrate the library with react native yourself?
Also, I think it'd be better to create a discussion for that instead of the issue.

I hope that you guys can start to create a new version for mobile, react native

Did you try to integrate the library with react native yourself?
Also, I think it'd be better to create a discussion for that instead of the issue.

@kentdev92 you can try self-hosting library implementation in a website and use it as a webview in react-native. I have Implemented it this way currently.
You can communicate using post messages between react-native and website.

Let's continue in #733

The first thing i want to say thank you so much to you tradingview/lightweight-charts team for create an awesome open source for us.
I'm currently using this lib as well for my business. I hope that you guys can start to create a new version for mobile, react native. Because i know that for now, don't have to much chart lib support for mobile as well, like the way you did with this lib.
Best regards

Can you please give me the exact tradingView  package name for react native


Use Bedrock-style folder structure on publicPath by default

Use Bedrock-style folder structure on webpack publicPath by default, yet still overridable via config.json.

The last time this was brought up, we discussed it and decided that that users have to edit the devUrl anyway, so it's not an issue for them to just edit the publicPath while they're at it.


What are the outputs in the on_train_batch_end callback?

❓ Questions and Help
Before asking:

Try to find answers to your questions in the Lightning Forum!
Search for similar issues.
Search the docs.

What is your question?
For my application, I need to save the raw outputs of the model to disk for every training and validation example. I think a callback is the right thing to use for this-- PL already has hooks in "on_train_batch_end". According to the latest docs, this method takes an outputs arg, which I presume to be the outputs of the pl_module, or the value returned by the training_step function. However, no matter what I change in the training_step, outputs is always an empty list. Likewise, the outputs in on_train_epoch_end is an empty list of lists.
class SaverCallback(Callback):
    def __init__(self):
        super().__init__()

    def on_train_epoch_end(self, trainer, pl_module, outputs):
        print('train epoch outputs: {}'.format(outputs))

    def on_train_batch_end(self, trainer, pl_module, outputs, batch, batch_idx, dataloader_idx):
        print('train outputs: {}'.format(outputs))

    def on_validation_batch_end(self, trainer, pl_module, outputs, batch, batch_idx, dataloader_idx):
        # import pdb; pdb.set_trace()
        print('val outputs: {}'.format(outputs))

    def on_validation_epoch_end(self, trainer, pl_module):
        pass

Here are the relevant portions of my Lightning Module:
    def training_step(self, batch_dict, batch_i):
        ...
        return {'loss': loss, 'testing': 'testing'}

    def validation_step(self, batch_dict, batch_i):
        ...
        return {'loss': loss, 'testing': 'testing'}

Results:
train outputs: []
val outputs: {'loss': tensor(0.0395, device='cuda:0', dtype=torch.float64), 'testing': 'testing'}
train epoch outputs: [[]]

Where are train outputs defined?
Possibly related issues:
https://github.com/PyTorchLightning/pytorch-lightning/issues/3864
https://github.com/PyTorchLightning/pytorch-lightning/issues/3592
https://github.com/PyTorchLightning/pytorch-lightning/issues/4609
What's your environment?

OS: Linux
Packaging pip
Version 1.0.4, installed from master

https://github.com/PyTorchLightning/pytorch-lightning/pull/4369 will fix it.

I have a similar issue where I'm trying to make a callback for logging many of the same metrics across different modules. However, #4369 doesn't fix it when applying it to the stable 1.0.6 branch or master branch. Even when the module has training_epoch_end defined (with just a pass) this happens. With or without that function in the module (when the PR has been applied), I get [['extra':{'pred': tensor(...) }, 'minimize': tensor(...), 'meta': { ... }]].
The dict being wrong seems to be how the training step output gets processed in _process_training_step_output_1_0. Plus, it still gets returned as a list of list of the incorrect dict, rather than just the original, correct dict. A hacky fix seems to be to force the deprecated pre-1.0.0 processing. Unfortunately, this still gives a list of list of the now correct dict to on_train_batch_end, unlike what on_validation_batch_end receives.
Unless I applied #4369 wrong, but it's a pretty simple set of commits that don't seem to fix this issue.

Any updates on this issue? I use PL 1.1.2 and this issue still persists. Please fix!

Any updates on this issue? I use PL 1.1.2 and this issue still persists. Please fix!

I am seeing the same issue! Though on_validation_batch_end's outputs is returning correctly. :)

I am seeing the same issue! Though on_validation_batch_end's outputs is returning correctly. :)

I am seeing the same issue and found comments when tracking code stack.  So just try adding an empty training_epoch_end implement at Lightning Module.

I am seeing the same issue and found comments when tracking code stack.  So just try adding an empty training_epoch_end implement at Lightning Module.


Added Chainstack as fourth provider

Added Chainstack RPC provider functionality. Updated README accordingly.
Tested beforehand; working across all four providers. (do note that Chainstack is rpc_provider_url only, and will not accept an api_key parameter)

Awesome! Thanks @TABASCOatw for putting up this pull request. I made some small edits to resolve some conflicts and merged in as is. 🥳


TypeError on Mac OS X 10.10 using python 2.7

I've tried
Mac OS X 10.10.2 (Yosemite)
Traceback (most recent call last):
  File "/usr/local/bin/icon-font-to-png", line 8, in <module>
    from icon_font_to_png import command_line
  File "/Library/Python/2.7/site-packages/icon_font_to_png/__init__.py", line 2, in <module>
    from .icon_font_downloader import (
  File "/Library/Python/2.7/site-packages/icon_font_to_png/icon_font_downloader.py", line 15, in <module>
    class IconFontDownloader(object, with_metaclass(ABCMeta)):
  File "/System/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/abc.py", line 87, in __new__
    cls = super(ABCMeta, mcls).__new__(mcls, name, bases, namespace)
TypeError: Error when calling the metaclass bases
    Cannot create a consistent method resolution
order (MRO) for bases NewBase, object

The following is the output of installing icon-font-to-png (and dependencies) using pip:
Downloading/unpacking icon-font-to-png
  Downloading icon_font_to_png-0.3.2-py2.py3-none-any.whl
Downloading/unpacking tinycss>=0.3 (from icon-font-to-png)
  Downloading tinycss-0.3.tar.gz (72kB): 72kB downloaded
  Running setup.py (path:/private/tmp/pip_build_root/tinycss/setup.py) egg_info for package tinycss
    Building without Cython.

    no previously-included directories found matching 'docs/_build'
Downloading/unpacking requests>=2.9.1 (from icon-font-to-png)
  Downloading requests-2.9.1-py2.py3-none-any.whl (501kB): 501kB downloaded
Downloading/unpacking pillow>=3.0.0 (from icon-font-to-png)
  Downloading Pillow-3.1.1-cp27-none-macosx_10_6_intel.macosx_10_9_intel.macosx_10_9_x86_64.macosx_10_10_intel.macosx_10_10_x86_64.whl (2.9MB): 2.9MB downloaded
Downloading/unpacking six>=1.10.0 (from icon-font-to-png)
  Downloading six-1.10.0-py2.py3-none-any.whl
Installing collected packages: icon-font-to-png, tinycss, requests, pillow, six
  Running setup.py install for tinycss
    Building without Cython.
    building 'tinycss.speedups' extension
    cc -fno-strict-aliasing -fno-common -dynamic -arch x86_64 -arch i386 -g -Os -pipe -fno-common -fno-strict-aliasing -fwrapv -DENABLE_DTRACE -DMACOSX -DNDEBUG -Wall -Wstrict-prototypes -Wshorten-64-to-32 -DNDEBUG -g -fwrapv -Os -Wall -Wstrict-prototypes -DENABLE_DTRACE -arch x86_64 -arch i386 -pipe -I/System/Library/Frameworks/Python.framework/Versions/2.7/include/python2.7 -c tinycss/speedups.c -o build/temp.macosx-10.10-intel-2.7/tinycss/speedups.o
    tinycss/speedups.c:705:14: warning: explicitly assigning value of variable of type 'PyObject *' (aka 'struct _object *') to itself [-Wself-assign]
      __pyx_self = __pyx_self;
      ~~~~~~~~~~ ^ ~~~~~~~~~~
    tinycss/speedups.c:1571:14: warning: explicitly assigning value of variable of type 'PyObject *' (aka 'struct _object *') to itself [-Wself-assign]
      __pyx_self = __pyx_self;
      ~~~~~~~~~~ ^ ~~~~~~~~~~
    tinycss/speedups.c:5348:33: warning: unused function '__Pyx_PyInt_FromSize_t' [-Wunused-function]
    static CYTHON_INLINE PyObject * __Pyx_PyInt_FromSize_t(size_t ival) {
                                    ^
    tinycss/speedups.c:5362:29: warning: unused function '__Pyx_PyInt_AsSize_t' [-Wunused-function]
    static CYTHON_INLINE size_t __Pyx_PyInt_AsSize_t(PyObject* x) {
                                ^
    tinycss/speedups.c:469:32: warning: unused function '__Pyx_GetItemInt_Tuple_Fast' [-Wunused-function]
    static CYTHON_INLINE PyObject *__Pyx_GetItemInt_Tuple_Fast(PyObject *o, Py_ssize_t i) {
                                   ^
    tinycss/speedups.c:509:26: warning: unused function '__Pyx_NegateNonNeg' [-Wunused-function]
    static CYTHON_INLINE int __Pyx_NegateNonNeg(int b) {
                             ^
    tinycss/speedups.c:512:32: warning: unused function '__Pyx_PyBoolOrNull_FromLong' [-Wunused-function]
    static CYTHON_INLINE PyObject* __Pyx_PyBoolOrNull_FromLong(long b) {
                                   ^
    tinycss/speedups.c:4481:36: warning: unused function '__Pyx_PyInt_AsUnsignedChar' [-Wunused-function]
    static CYTHON_INLINE unsigned char __Pyx_PyInt_AsUnsignedChar(PyObject* x) {
                                       ^
    tinycss/speedups.c:4500:37: warning: unused function '__Pyx_PyInt_AsUnsignedShort' [-Wunused-function]
    static CYTHON_INLINE unsigned short __Pyx_PyInt_AsUnsignedShort(PyObject* x) {
                                        ^
    tinycss/speedups.c:4519:35: warning: unused function '__Pyx_PyInt_AsUnsignedInt' [-Wunused-function]
    static CYTHON_INLINE unsigned int __Pyx_PyInt_AsUnsignedInt(PyObject* x) {
                                      ^
    tinycss/speedups.c:4538:27: warning: unused function '__Pyx_PyInt_AsChar' [-Wunused-function]
    static CYTHON_INLINE char __Pyx_PyInt_AsChar(PyObject* x) {
                              ^
    tinycss/speedups.c:4557:28: warning: unused function '__Pyx_PyInt_AsShort' [-Wunused-function]
    static CYTHON_INLINE short __Pyx_PyInt_AsShort(PyObject* x) {
                               ^
    tinycss/speedups.c:4595:34: warning: unused function '__Pyx_PyInt_AsSignedChar' [-Wunused-function]
    static CYTHON_INLINE signed char __Pyx_PyInt_AsSignedChar(PyObject* x) {
                                     ^
    tinycss/speedups.c:4614:35: warning: unused function '__Pyx_PyInt_AsSignedShort' [-Wunused-function]
    static CYTHON_INLINE signed short __Pyx_PyInt_AsSignedShort(PyObject* x) {
                                      ^
    tinycss/speedups.c:4633:33: warning: unused function '__Pyx_PyInt_AsSignedInt' [-Wunused-function]
    static CYTHON_INLINE signed int __Pyx_PyInt_AsSignedInt(PyObject* x) {
                                    ^
    tinycss/speedups.c:4652:26: warning: unused function '__Pyx_PyInt_AsLongDouble' [-Wunused-function]
    static CYTHON_INLINE int __Pyx_PyInt_AsLongDouble(PyObject* x) {
                             ^
    tinycss/speedups.c:4776:35: warning: function '__Pyx_PyInt_AsLongLong' is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static CYTHON_INLINE PY_LONG_LONG __Pyx_PyInt_AsLongLong(PyObject* x) {
                                      ^
    tinycss/speedups.c:4846:42: warning: function '__Pyx_PyInt_AsSignedLongLong' is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static CYTHON_INLINE signed PY_LONG_LONG __Pyx_PyInt_AsSignedLongLong(PyObject* x) {
                                             ^
    tinycss/speedups.c:4896:27: warning: unused function '__Pyx_ErrFetch' [-Wunused-function]
    static CYTHON_INLINE void __Pyx_ErrFetch(PyObject **type, PyObject **value, PyObject **tb) {
                              ^
    19 warnings generated.
    tinycss/speedups.c:705:14: warning: explicitly assigning value of variable of type 'PyObject *' (aka 'struct _object *') to itself [-Wself-assign]
      __pyx_self = __pyx_self;
      ~~~~~~~~~~ ^ ~~~~~~~~~~
    tinycss/speedups.c:1571:14: warning: explicitly assigning value of variable of type 'PyObject *' (aka 'struct _object *') to itself [-Wself-assign]
      __pyx_self = __pyx_self;
      ~~~~~~~~~~ ^ ~~~~~~~~~~
    tinycss/speedups.c:5348:33: warning: unused function '__Pyx_PyInt_FromSize_t' [-Wunused-function]
    static CYTHON_INLINE PyObject * __Pyx_PyInt_FromSize_t(size_t ival) {
                                    ^
    tinycss/speedups.c:5362:29: warning: unused function '__Pyx_PyInt_AsSize_t' [-Wunused-function]
    static CYTHON_INLINE size_t __Pyx_PyInt_AsSize_t(PyObject* x) {
                                ^
    tinycss/speedups.c:469:32: warning: unused function '__Pyx_GetItemInt_Tuple_Fast' [-Wunused-function]
    static CYTHON_INLINE PyObject *__Pyx_GetItemInt_Tuple_Fast(PyObject *o, Py_ssize_t i) {
                                   ^
    tinycss/speedups.c:509:26: warning: unused function '__Pyx_NegateNonNeg' [-Wunused-function]
    static CYTHON_INLINE int __Pyx_NegateNonNeg(int b) {
                             ^
    tinycss/speedups.c:512:32: warning: unused function '__Pyx_PyBoolOrNull_FromLong' [-Wunused-function]
    static CYTHON_INLINE PyObject* __Pyx_PyBoolOrNull_FromLong(long b) {
                                   ^
    tinycss/speedups.c:4481:36: warning: unused function '__Pyx_PyInt_AsUnsignedChar' [-Wunused-function]
    static CYTHON_INLINE unsigned char __Pyx_PyInt_AsUnsignedChar(PyObject* x) {
                                       ^
    tinycss/speedups.c:4500:37: warning: unused function '__Pyx_PyInt_AsUnsignedShort' [-Wunused-function]
    static CYTHON_INLINE unsigned short __Pyx_PyInt_AsUnsignedShort(PyObject* x) {
                                        ^
    tinycss/speedups.c:4519:35: warning: unused function '__Pyx_PyInt_AsUnsignedInt' [-Wunused-function]
    static CYTHON_INLINE unsigned int __Pyx_PyInt_AsUnsignedInt(PyObject* x) {
                                      ^
    tinycss/speedups.c:4538:27: warning: unused function '__Pyx_PyInt_AsChar' [-Wunused-function]
    static CYTHON_INLINE char __Pyx_PyInt_AsChar(PyObject* x) {
                              ^
    tinycss/speedups.c:4557:28: warning: unused function '__Pyx_PyInt_AsShort' [-Wunused-function]
    static CYTHON_INLINE short __Pyx_PyInt_AsShort(PyObject* x) {
                               ^
    tinycss/speedups.c:4595:34: warning: unused function '__Pyx_PyInt_AsSignedChar' [-Wunused-function]
    static CYTHON_INLINE signed char __Pyx_PyInt_AsSignedChar(PyObject* x) {
                                     ^
    tinycss/speedups.c:4614:35: warning: unused function '__Pyx_PyInt_AsSignedShort' [-Wunused-function]
    static CYTHON_INLINE signed short __Pyx_PyInt_AsSignedShort(PyObject* x) {
                                      ^
    tinycss/speedups.c:4633:33: warning: unused function '__Pyx_PyInt_AsSignedInt' [-Wunused-function]
    static CYTHON_INLINE signed int __Pyx_PyInt_AsSignedInt(PyObject* x) {
                                    ^
    tinycss/speedups.c:4652:26: warning: unused function '__Pyx_PyInt_AsLongDouble' [-Wunused-function]
    static CYTHON_INLINE int __Pyx_PyInt_AsLongDouble(PyObject* x) {
                             ^
    tinycss/speedups.c:4776:35: warning: function '__Pyx_PyInt_AsLongLong' is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static CYTHON_INLINE PY_LONG_LONG __Pyx_PyInt_AsLongLong(PyObject* x) {
                                      ^
    tinycss/speedups.c:4846:42: warning: function '__Pyx_PyInt_AsSignedLongLong' is not needed and will not be emitted [-Wunneeded-internal-declaration]
    static CYTHON_INLINE signed PY_LONG_LONG __Pyx_PyInt_AsSignedLongLong(PyObject* x) {
                                             ^
    tinycss/speedups.c:4896:27: warning: unused function '__Pyx_ErrFetch' [-Wunused-function]
    static CYTHON_INLINE void __Pyx_ErrFetch(PyObject **type, PyObject **value, PyObject **tb) {
                              ^
    19 warnings generated.
    cc -bundle -undefined dynamic_lookup -arch x86_64 -arch i386 -Wl,-F. build/temp.macosx-10.10-intel-2.7/tinycss/speedups.o -o build/lib.macosx-10.10-intel-2.7/tinycss/speedups.so

    no previously-included directories found matching 'docs/_build'
Successfully installed icon-font-to-png tinycss requests pillow six
Cleaning up...

I've been able to successfully install and run icon-font-to-png on a linux machine however and it appears the issue might be related to the install of pillow. I'm not too familiar with pip and I might be posting this in the wrong repository, if so, please let me know!

From the traceback it seems that the problem is with my abstract class code. I'll try to look into it, but I don't really have a Mac to play with ; - )
From the look of pip install it seems that everything was installed, but could you run pip freeze and paste the results here?

As requested, the result of pip freeze:
Pillow==3.1.1
Twisted==13.2.0
altgraph==0.10.2
bdist-mpkg==0.5.0
bonjour-py==0.3
icon-font-to-png==0.3.2
macholib==1.5.1
matplotlib==1.3.1
modulegraph==0.10.4
numpy==1.8.0rc1
py2app==0.7.3
pyOpenSSL==0.13.1
pyobjc-core==2.5.1
pyobjc-framework-Accounts==2.5.1
pyobjc-framework-AddressBook==2.5.1
pyobjc-framework-AppleScriptKit==2.5.1
pyobjc-framework-AppleScriptObjC==2.5.1
pyobjc-framework-Automator==2.5.1
pyobjc-framework-CFNetwork==2.5.1
pyobjc-framework-Cocoa==2.5.1
pyobjc-framework-Collaboration==2.5.1
pyobjc-framework-CoreData==2.5.1
pyobjc-framework-CoreLocation==2.5.1
pyobjc-framework-CoreText==2.5.1
pyobjc-framework-DictionaryServices==2.5.1
pyobjc-framework-EventKit==2.5.1
pyobjc-framework-ExceptionHandling==2.5.1
pyobjc-framework-FSEvents==2.5.1
pyobjc-framework-InputMethodKit==2.5.1
pyobjc-framework-InstallerPlugins==2.5.1
pyobjc-framework-InstantMessage==2.5.1
pyobjc-framework-LatentSemanticMapping==2.5.1
pyobjc-framework-LaunchServices==2.5.1
pyobjc-framework-Message==2.5.1
pyobjc-framework-OpenDirectory==2.5.1
pyobjc-framework-PreferencePanes==2.5.1
pyobjc-framework-PubSub==2.5.1
pyobjc-framework-QTKit==2.5.1
pyobjc-framework-Quartz==2.5.1
pyobjc-framework-ScreenSaver==2.5.1
pyobjc-framework-ScriptingBridge==2.5.1
pyobjc-framework-SearchKit==2.5.1
pyobjc-framework-ServiceManagement==2.5.1
pyobjc-framework-Social==2.5.1
pyobjc-framework-SyncServices==2.5.1
pyobjc-framework-SystemConfiguration==2.5.1
pyobjc-framework-WebKit==2.5.1
pyparsing==2.0.1
python-dateutil==1.5
pytz==2013.7
requests==2.9.1
scipy==0.13.0b1
six==1.10.0
tinycss==0.3
vboxapi==1.0
wsgiref==0.1.2
xattr==0.6.4
zope.interface==4.1.1

I tried to add OS X to Travis CI, but unfortunately with no luck (travis-ci/travis-ci#2312).
I tinkered around with the metaclass code - could you uninstall the package, then install it again via pip install git+https://github.com/Pythonity/icon-font-to-png.git command and see if anything changes? Thanks.

@pawelad After investigating a bit, it appears that when pip tries to install the six dependencies, it cannot uninstall the one that comes with OSX since it is protected from being removed. (see related issue that pointing me in the right direction: https://github.com/pypa/pip/issues/3165)
Using either --ignore-installed six or --user when running pip under OSX makes icon-font-to-png work properly.

So the version from PyPI works with those arguments, and does not without?
Hm, that's very weird - Successfully installed icon-font-to-png tinycss requests pillow six seems to let us know that everything went OK...
Anyway, I'm glad it's working : - )


Single translation file per language

Thanks for the library.
Is it possible to have just one file per language? I have just a few texts per page and it doesn't make much sense to have then separate files. I'd like to use a js file instead of json and separate the pages with comments.
I tried this config
const lang = { en: 'English', cs: 'Česky' }
export const config = {
  translations: { en: { lang }, cs: { lang } },
  loaders: [
    { locale: 'en', loader: async () => await import('./en.js') },
    { locale: 'cs', loader: async () => await import('./cs.js') }
  ]
}

it doesn't throw any errors but the t method just returns the argument string.

Hi @EskelCz!
This library is meant to be module-based, so every translation "module" should have a specific key (so the lib can identify later which modules are already loaded). This means that you can use this config:
const lang = { en: 'English', cs: 'Česky' }
export const config = {
  translations: { en: { lang }, cs: { lang } },
  loaders: [
    { locale: 'en', key: 'common', loader: async () => await import('./en.js') },
    { locale: 'cs', key: 'common', loader: async () => await import('./cs.js') }
  ]
}

which results in $t('common.your.translations') inside your .svelte file.
Hope this helps!.)

Perfect, thanks :)


Support for anyhow/thiserror?

Is there something like this that can be used with anyhow/thiserror? :)

What things from this crate are you looking for? Anyhow's error can already be used as the return type of main without an additional crate.

@dtolnay This:

ExitDisplay: a wrapper around E: std::fmt::Display to allow the error message from main to use Display and not Debug.

Anyhow already does that.
use anyhow::Result;

fn main() -> Result<()> {
    std::fs::read("/nonexistent")?;
    Ok(())
}

Error: No such file or directory (os error 2)


Dependency "guzzlehttp/guzzle" conflict with aws-sdk

I'm using both aws-sdk and shipwire-api in my project.
shipwire-api requires "guzzlehttp/guzzle": "5.0.3"
but aws-sdk-php "guzzlehttp/guzzle": ">=5.3|~6.0.1|~6.1"
Could you please fix this? thx

Did you try the shipwire api with newer versions of guzzle.


rsactftool: init at unstable-2022-07-28

Description of changes

RSA multi attacks tool : uncipher data from weak public key and try to recover private key Automatic selection of best attack for the given public key.
Things done

Built on platform(s)

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

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

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

[ ] Tested compilation of all packages that depend on this change using nix-shell -p nixpkgs-review --run "nixpkgs-review rev HEAD". Note: all changes have to be committed, also see nixpkgs-review usage
[x] Tested basic functionality of all binary files (usually in ./result/bin/)
22.11 Release Notes (or backporting 22.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
[ ] (Release notes changes) Ran nixos/doc/manual/md-to-db.sh to update generated release notes

[x] Fits CONTRIBUTING.md.

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

5 packages built:

msieve
python310Packages.egcd
python39Packages.egcd
rsactftool
yafu

Result of nixpkgs-review pr 184550 -c commit run on x86_64-linux 1

7 packages built:

msieve
python310Packages.egcd
python39Packages.egcd
rsactftool
yafu
ysieve
ytools

It failed when merging into master, due to broken dependencies


Update repos.md

Thank you, @fthomas, for this awesome tool!
👍 👍 👍

Thanks @sirthias! 😊
Do you mean to add borer to Scala Steward? I don't see a PR it.

Ahm, yes, apparently I messed sth up.
Will PR in a sec...
Thank you!


use:enhace break hot module reload and routing in development with input name="method"

Describe the bug
Creating a form with and input with the name of "method" breaks both hot module reloading and routing in development mode. The pages build and run just fine on preview, but you get this message in the developer's console and navigating to and from this page freezes navigation (again only in development mode). It seems to stem from these lines, where it checks form.method

Reproduction
https://github.com/awenzel5/sveltekit-enhance-method
Logs
No response
System Info
System:
    OS: Linux 5.10 Ubuntu 20.04.5 LTS (Focal Fossa)
    CPU: (20) x64 12th Gen Intel(R) Core(TM) i9-12900H
    Memory: 21.68 GB / 24.79 GB
    Container: Yes
    Shell: 5.0.17 - /bin/bash
  Binaries:
    Node: 18.12.1 - ~/.nvm/versions/node/v18.12.1/bin/node
    npm: 9.2.0 - ~/.nvm/versions/node/v18.12.1/bin/npm
  npmPackages:
    @sveltejs/adapter-auto: ^1.0.0 => 1.0.0
    @sveltejs/kit: ^1.0.0 => 1.0.11
    svelte: ^3.54.0 => 3.55.1
    vite: ^4.0.0 => 4.0.4

Severity
annoyance
Additional Information
No response

This feels like #7593 and is I'm guessing another instance of a similar sort of thing.


feat: a few lemmas on continuous functions

Topological prerequisites for Rademacher theorem in #7003.

Thanks!
bors r+


GeneratedInfoPlistDotEnv.h file not found

Error on iOS only:
../GeneratedInfoPlistDotEnv.h file not found
Command Preprocess failed with a nonzero exit code
A google mentions another library (the react-native-config issue) gets this error and the solution seems to be to manually link the dependency.  But there is no project file in this library to do that with.
Is there a step to install for xcode that I'm missing?

Hey, faced with the same issue on making Archive step, any updates here?

Also facing the same issue after updating.

If you're still using 0.11.7
Setting Preprocessor Prefix File to ${SRCROOT}/../node_modules/react-native-config/ios/ReactNativeConfig/GeneratedInfoPlistDotEnv.h fixed this for me


docs: update getting-started and httproute guides for v1alpha2

What type of PR is this?
/kind documentation
What this PR does / why we need it:
This updates the examples in the HTTPRoute guide for v1alpha2, and does some spacing cleanup for the getting started guide (but that guide did not appear to need any special updating for v1alpha2).
Which issue(s) this PR fixes:
Resolves the first two tasks in https://github.com/kubernetes-sigs/gateway-api/issues/783

/ok-to-test

/assign @shaneutt

LGTM pending CI, nice work @shaneutt!

@robscott I think you had asked earlier for the spec to be removed from an example GatewayClass however this ended up failing CI verification for the manifest, so I put that back in. Verification is successfull locally now, and I've rebased against recent master changes and squashed. Ready for re-review.

I think you had asked earlier for the spec to be removed from an example GatewayClass

@shaneutt sorry for the confusion there! I was actually just suggesting that the GatewayClass resource was unnecessary for an example. Most users won't be creating a new GatewayClass for each Gateway, Route, etc. In the text before and after the example, there's no mention of the GatewayClass, so I think it could safely be removed.

I think you had asked earlier for the spec to be removed from an example GatewayClass

@shaneutt sorry for the confusion there! I was actually just suggesting that the GatewayClass resource was unnecessary for that example. Most users won't be creating a new GatewayClass for each Gateway, Route, etc. In the text before and after the example, there's no mention of the GatewayClass, so I think it could safely be removed from that example.

Sounds good, that's now removed.

Thanks!
/lgtm

/approve


Failed to run tpch test after modify root@sys password by SQL

It will report
obd test tpch 3node  --tenant=test -s 100 --remote-tbl-dir=/data/ob/tpch100
Get local repositories and plugins ok
Open ssh connection ok
Cluster status check ok
Connect observer(server1(172.30.62.xxx):2881) x
[ERROR] Failed to connect to the server
See https://open.oceanbase.com/docs/obd-cn/V1.3.0/10000000000099584.

Due to obd failed to connect ob server with root@sys, once the password of root@sys has been modified by SQL
Suggest:

provide more log error message.
provate one error code.

When running tests with OBD, it uses its own managed cluster and connection information. If you directly modify the OceanBase password using SQL, OBD will be unable to detect it and will lead to inability of maintenance management. To modify the OceanBase password, you need to use the obd edit-config command to make changes.


Update readme to improve clarity for --rules option

Add some clarifications to the readme.
https://github.com/FriendsOfPHP/PHP-CS-Fixer/issues/5198

thanks for the PR, changes have been in https://github.com/FriendsOfPHP/PHP-CS-Fixer/pull/3475 for ease of merging


refactor: route groups

[!WARNING]
This pull request is not mergeable via GitHub because a downstack PR is open. Once all requirements are satisfied, merge this PR as a stack on Graphite.
Learn more

#514  👈
#513
#511
#509
#507 : 1 other dependent PR (#508 )
#505 : 1 other dependent PR (#506 )
main

This stack of pull requests is managed by Graphite. Learn more about stacking.

Join @hi-ogawa and the rest of your teammates on  Graphite


BOBA fee minor smoothing; more comments, minor tweeks

Also tried to simplify the logic to make it more clear what is being charged when

Codecov Report

:exclamation: No coverage uploaded for pull request base (boba-fee@025dd3a). Click here to learn what that means.
The diff coverage is n/a.

:exclamation: Current head 35d341f differs from pull request most recent head b55e307. Consider uploading reports for the commit b55e307 to get more accurate results

@@             Coverage Diff             @@
##             boba-fee      #41   +/-   ##
===========================================
  Coverage            ?   48.29%
===========================================
  Files               ?       98
  Lines               ?     3860
  Branches            ?      738
===========================================
  Hits                ?     1864
  Misses              ?     1996
  Partials            ?        0

Flag
Coverage Δ

boba-contracts
20.15% <0.00%> (?)

contracts
78.87% <0.00%> (?)

core-utils
86.77% <0.00%> (?)

data-transport-layer
29.25% <0.00%> (?)

message-relayer
83.17% <0.00%> (?)

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

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 025dd3a...b55e307. Read the comment docs.


Updated and Added New Icons

Updated and added new icons to fix issues:
$pac (fixes #193 )
actn (fixes #120 )
arg (fixes #188 )
bsd (fixes #157 )
bts (fixes #159 )
cmm (fixes #121 )
ctxc (fixes #167 )
dht (fixes #128 )
dock (fixes #164 )
fjc (fixes #189 )
gmr (fixes #132 )
gsc (fixes #184 )
gzr (fixes #116 )
hight (fixes #144 )
iotx (fixes #183 )
loom (fixes #163 )
moac (fixes #174 )
nexo (fixes #170 )
ok (fixes #156 )
pasc (fixes #130 )
payx (fixes #175 )
rap (fixes #192 )
shift (fixes #158 )
sib (fixes #190 )
soc (fixes #171 )
tern (fixes #124 )
trtl (fixes #180 )
wicc (fixes #166 )
xin (fixes #165 )
xsg (fixes #191 )
PNGs are ImageOptim Optimized. I put SVGs through ImageOptim (without svgcleaner) but I don't think they got optimized.

Looking good! Nice work, @NadiaSotnikova 🙌


Namespace handling directly with the uuid module

Can we improve the use of the uuid module so that it handles namespaces directly instead of manually indicating the namespace urn each time?
Describe the solution you'd like
A complete management of uuids and namespaces by a particular module (maybe uuid)
Describe alternatives you've considered
If we add the urn namespace manually then we will have to declare it somewhere, in the context and in the RDF python library.
Additional context
Context : https://github.com/bids-standard/BEP028_BIDSprov/pull/83#discussion_r1067985133

From a few tests:

We can't use the uuid directly without the conversion to str otherwise the following error : TypeError: Object of type UUID is not JSON serializable when writing the jsonld in output
Some functions of the uuid module can use a namespace like uuid3 which takes as parameter a namespace and a name
Example :

uuid.uuid3(uuid.NAMESPACE_DNS, 'python.org')
UUID('6fa459ea-ee8a-3ca4-894e-db77e160355e')

but I'm not sure the output does anything for namespace management

see also satra's comment in https://github.com/bids-standard/BEP028_BIDSprov/pull/83#discussion_r1068141790


Update handling of Terms of Service

Issue:

bcgov/entity/issues/23100

Description of changes:

Update handling of Terms of Service
Add new middleware and composable

By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of the namex license (Apache 2.0).

/gcbrun

Temporary Url for review: https://strr-ui-dev--pr-141-sjh9ibfs.web.app

@rstens I had to make sure the user gets redirected from any page to the ToS, and eliminate extra API calls, etc. and as I worked through it, I had to improve from what it was before.


running problem

Hello. I installed crpyto signal and i have a problem when i m running.
I followed a guide that is in github page. and i want to show my problem.

this is a picture when i run docker. (when i run this program)
and i put config.yml in this path.

and i copied a config.yml example code and changed telegram token and chat id. and Docker is installed.
i want to know everytime i run this program, this program couldn't find enabled notifiers, exchange etc.. (if you see my first picture.)
i think this is my config.yml problem but i can't find what is wrong.
settings:
    log_level: INFO
    update_interval: 180
    market_pairs:
        - BTC/USDT
        - ETH/USDT
        - SOL/USDT
        - RLC/USDT
        - INJ/USDT
        - CTSI/USDT
        - RNDR/USDT

exchanges:
    huobipro:
        required:
            enabled: true
    binance:
        required:
            enabled: true

indicators:
    rsi:
        - enabled: true
          alert_enabled: true
          alert_frequency: once
          signal:
            - rsi
          hot: 30
          cold: 70
          candle_period: 1h
          period_count: 10
        - enabled: true
          alert_enabled: true
          alert_frequency: once
          signal:
            - rsi
          hot: 30
          cold: 70
          candle_period: 5m
          period_count: 10
    stoch_rsi:
        - enabled: false
          alert_enabled: true
          alert_frequency: once
          signal:
            - stoch_rsi
          hot: 20
          cold: 80
          candle_period: 5m
          period_count: 14
    momentum:
        - enabled: false
          alert_enabled: false
          alert_frequency: once
          signal:
            - momentum
          hot: 0
          cold: 0
          candle_period: 1d
          period_count: 10
        - enabled: true
          alert_enabled: false
          alert_frequency: once
          signal:
            - momentum
          hot: 0
          cold: 0
          candle_period: 1h
          period_count: 12
    macd:
        - enabled: false
          alert_enabled: false
          alert_frequency: once
          signal:
            - macd
          hot: 0
          cold: 0
          candle_period: 15m
        - enabled: true
          alert_enabled: false
          alert_frequency: once
          signal:
            - macdsignal
          hot: 0
          cold: 0
          candle_period: 15m
    obv:
        - enabled: false
    mfi:
        - enabled: false
          alert_enabled: true
          alert_frequency: once
          signal:
            - mfi
          hot: 20
          cold: 80
          candle_period: 5m
          period_count: 14
    ichimoku:
        - enabled: false

informants:
    ema:
        - enabled: false
          signal:
            - ema
          candle_period: 1d
          period_count: 10
        - enabled: true
          signal:
            - ema
          candle_period: 1d
          period_count: 30

crossovers:
    std_crossover:
        - enabled: false
          alert_enabled: true
          alert_frequency: once
          key_indicator: ema
          key_indicator_index: 0
          key_indicator_type: informants
          key_signal: ema
          crossed_indicator: ema
          crossed_indicator_index: 1
          crossed_indicator_type: informants
          crossed_signal: ema
        - enabled: false
          alert_enabled: true
          alert_frequency: once
          key_indicator: macd
          key_indicator_index: 0
          key_indicator_type: indicators
          key_signal: macd
          crossed_indicator: macd
          crossed_indicator_index: 1
          crossed_indicator_type: indicators
          crossed_signal: macdsignal

notifiers:
    telegram:
        required:
            token: "i wrote token from here and erase it just in case"
            chat_id: "i wrote chat_id from here and erase it just in case"
        optional:
            parse_mode: html
            template: "[{{analysis.config.candle_period}} / {{analysis.config.period_count}}] {{exchange}}-{{market}}-{{indicator}}-{{indicator_number}} is {{status}}! ({{values}}){{ '\n' -}}"

this is my config.yml code too. i upload it just in case.
im really thank you for helping me.

You can try this fork: https://github.com/krypt0ra/station
It's under an active support and there are dozens of errors fixed and there is completed dockerization. If you will still have an issue there, just create a issue: https://github.com/krypt0ra/station/issues/new?assignees=alkhachatryan&labels=&projects=&template=bug_report.md&title=[BUG]


Update github-developer-program.md

Why:
Closes ISSUE

What's being changed (if available, include any code snippets, screenshots, or gifs):

Check off the following:

[ ] I have reviewed my changes in staging (look for the "Automatically generated comment" and click the links in the "Preview" column to view your latest changes).
[ ] For content changes, I have completed the self-review checklist.

@Soumikdas96 Thanks for submitting a PR! However, we are not going to accept this change 💛. Our titles and headers are punctuated in compliance with Microsoft's style guide.
Please take a look at our help wanted section to find open issues you can work on.
Thank you for your interest in improving GitHub Docs! :sparkling_heart:


Date Range Picker - Date format and validation issues

When using the date range picker in 'popup' mode we are seeing irregularities in the date format being applied to the date controls.
My agents date format is set to English (United Kingdom).  The format is DD/MM/YYYY.
However, sometimes when opening the Requests page the date picker is rendered in a different format like this:

This causes issues with date validation as well, as I may enter in a date that is valid in my region, but the date range picker indicates that it is invalid:

Refreshing the page often corrects this formatting:

Please check the latest styleguide for the API you want.

Can this be closed or is there further changes needed?

Yes, I haven't seen this issue occur since Yanyi's changes.


missing exported_namespace label in gotk_reconcile_duration_seconds_*

Hi. We are revisiting a few flux dashboards, and noticed that most recent ones from this repo do not show a few views that depend on the exported_namespace label of e.g. gotk_reconcile_duration_seconds_sum and gotk_reconcile_duration_seconds_count metrics.
Should that label still be available in recent flux versions?
(Still trying to figure out whether there's something wrong with our setup, or things have changed in flux.)

Okay it was unrelated to flux at all.
In case someone would land here from search engines, the reason was in alloy's honor_labels parameter - https://grafana.com/docs/alloy/latest/reference/components/prometheus/prometheus.scrape/#arguments - it has to be disabled for metrics collected from namespaces different from the one where flux controllers are running; that way you should get both original namespace and exported_namespace labels populated, and dashboards from this repo will work as expected.


failed to save private key to disk: open : no such file or directory

With the default config cfg.PrivateKeyPath will be set to empty string. With that readOrCreatePrivateKey function will fail so I would suggest to set a default value.

https://github.com/juanfont/headscale/pull/247

Thank you for merging that quickly!


grunt minify task on ngStorage.js does not work

I run $grunt on my vendors scripts, ngStorage.js is one of them.
after grunt is done, the vendor.js file is created with error. Once I removed ngStorage, the error disappeared from the vendor.js file

Closing. No follow up from requester.