text:
RFC: Client side load balancer

Within gRPC, one big feature is service discovery via xDS and other client side load balancing features. This is actually one of the biggest selling points imo for running gRPC internally for communication between services without needing to introduce another external proxy such as Envoy to facilitate this.
Now, I understand with connect-go, we are free to use a gRPC client and maintain these features, but would be nice to see a more official connect-go implementation.
Granted, one nice part about connect-go is the fact that you can just use a normal http.Client or specifically, an HTTPClient interface which the default http.Client implements.
What I'd like to propose is some general purpose, likely an http.RoundTripper that implements some basic features of the gRPC load balancer. I believe the gRPC implementation is too... much, but having basic connection pooling and round robin behavior per-IP address opens up the door to basic service discovery and getting the max value out of it.
For example, between internal services, let's say in Kubernetes, it's common to reference an A record that represents the service itself. This A record contains multiple IP addresses. A naive http.Client opens up one persistent connection to the hostname, and then directs all requests to the same IP address internally. Granted, the client will open up concurrent connections and potentially bind connections to another host, but there's no predictability in this behavior.
Having a RoundTripper that was intelligent enough to do a DNS lookup, then round robin, or other load balancing algorithms across the IPs would be super nice.
I understand this isn't necessarily in the scope of connect-go since this is sorta being outsourced to the larger Go community by adopting net/http as the interface, but I think having some official RoundTripper provided by connect-go would be super useful.
I'm going to be working on a POC for this, unrelated to connect-go with not necessarily the intention for it to be upstreamed, but if we can come to agreements on if this is something connect-go should provide (even in a separate repo), I'd be happy to help contribute there.
In general, I personally want a RoundTripper for generic HTTP, which would happen to be also ideal within the context of connect-go. Right now, this is the barrier of entry to adopting connect-go to replace our gRPC clients. We've already replaced our gRPC servers. :)
I'm happy to provide more insight or suggestions as needed.

🎉 We intended to do exactly this, right down to focusing on the http.RoundTripper interface! We haven't started work yet, so the timing is perfect - PlanetScale's requirements can help inform our design.
I think it probably makes sense to keep all this in a separate repository - it's useful for any HTTP client, and I bet we'll end up with some dependencies on connect-grpchealth-go.
Some questions:

I have a soft spot for load balancing algorithms. I'd probably start with round robin & fewest pending but I'd love to get to more interesting approaches eventually. Does that work for you, or do you depend on something like peak EWMA or sophisticated subsetting today?
I'd prefer to start with DNS, as you suggested, despite all the downsides of such a heavily cached, poll-based system - it's the lowest common denominator of discovery. Does that work for your use case, vs. some more k8s-specific approach? (I'm a relative Kubernetes novice, but there must be some high-level API that's effectively a watch on the underlying etcd key.)
Discovery naturally leads to health checking, especially since DNS records are often stale. Would you want gRPC-specific health checks, classic HAProxy-style GETs, something else, or no health checks at all?

In short, yes we're planning on this, and yes we'd love some input from real Connect users.

We intended to do exactly this, right down to focusing on the http.RoundTripper interface! We haven't started work yet, so the timing is perfect - PlanetScale's requirements can help inform our design.

This is great, would love to help out here however I can. :) And glad we're on the same page on where to start.

I think it probably makes sense to keep all this in a separate repository - it's useful for any HTTP client, and I bet we'll end up with some dependencies on connect-grpchealth-go.

Agreed, in my case, I also would like this as a generic HTTP handler. I think overall this is a useful tool to standalone.

I have a soft spot for load balancing algorithms. I'd probably start with round robin & fewest pending but I'd love to get to more interesting approaches eventually. Does that work for you, or do you depend on something like peak EWMA or sophisticated subsetting today?

Yeah, tbh, we only need Round Robin, and it's what we're using today in gRPC. More is better, but I don't particularly have a need personally.

I'd prefer to start with DNS, as you suggested, despite all the downsides of such a heavily cached, poll-based system - it's the lowest common denominator of discovery. Does that work for your use case, vs. some more k8s-specific approach? (I'm a relative Kubernetes novice, but there must be some high-level API that's effectively a watch on the underlying etcd key.)

Agreed, we just use A records paired with a headless service in kube. So what that means is each pod gets a unique IP address which is surfaced in the DNS record. This can also be done with SRV records, so I'd say DNS support with A + SRV would cover most use cases. Having the discovery mechanism be pluggable would be ideal.

Discovery naturally leads to health checking, especially since DNS records are often stale. Would you want gRPC-specific health checks, classic HAProxy-style GETs, something else, or no health checks at all?

I hadn't thought about this, since this opens the door to a lot more complexity. In gRPC today, we don't use any active health checking. We rely on the DNS records to add/remove IPs as things become unhealthy, and kubernetes ends up being the source of truth. I think some primitive stuff would be nice to have, and just go to "next" IP based on actual network level errors. If the IP itself cannot be reached, mark dead, and try the next.
With all this said, I think the gRPC side of things are lacking too and we've done a number of hacks there as well. One of them being DNS refreshing. Once gRPC did a Dial() and resolved IPs, it never re-resolves until there are no healthy subconnections. This is a pretty... not very open repository, but here's an example of our substituted DNS resolver for gRPC: https://github.com/planetscale/psdb/blob/main/core/resolver/resolver.go to simply support refreshing DNS records periodically.
It's also common that gRPC pairs with a connection pooler of it's own as a pool of higher level gRPC objects, so there's mess like this. https://github.com/planetscale/psdb/blob/main/core/pool/pool.go
I have lots of opinions here. :)

And just for additional context, our other use case for a generic HTTP RoundTripper that supports this functionality is an HTTP proxy component. In our case, we run an effectively, reverse proxy frontend for gRPC that handles connections from clients, then routes to the correct backend internally based on Authorization headers, etc. This in turn, is effectively a transparent HTTP proxy, but in gRPC land this was a mess. Adding connect-go into the mix here makes this pretty difficult to port over currently, but instead making it a generic HTTP proxy and just have our ServeHTTP handle... any HTTP connection would be ideal. Similar to the httputils.SingleHostReverseProxy except, we'd shove this load balanced RoundTripper into the ReverseProxy instead and it'd work the same as using it in connect-go.

Will there be any alternative to channelz? I would like to see up-to-date information about the work of connections in the likeness of this https://github.com/rantav/go-grpc-channelz

Will there be any alternative to channelz? I would like to see up-to-date information about the work of connections in the likeness of this https://github.com/rantav/go-grpc-channelz

No, there won't: connect-go delegates to the standard library's HTTP implementation, which manages TCP connections under the hood. net/http clients can get many similar insights from net/http/httptrace - there's no need for connect-go to get involved.

Will it support scheme dns:/// to load balance?

@cyriltovena is using connect-go in Grafana Labs' Phlare product, and also ran into a situation where a library like this would be useful.

I've been working on making my version a bit more... good, and capable of being consumed by the public, just has been taking time.

@mattrobenolt and anyone else following this issue, @jhump and @jchadwick-buf are now actively working on this. We've got some internal use cases, and our Knit project is running into many of the same reverse proxy problems as PlanetScale.
Our intention is to:

Do this work as a completely separate package that constructs net/http Clients (or possibly RoundTrippers). Clients should have defaults suited to intra-region, service-to-service use:

Disable cookie jars and redirects by default.
Support the HTTP_PROXY and HTTPS_PROXY environment variables by default.
In addition to the stdlib's redirect-handling function pointer, support a simpler "follow N redirects" option.
Encourage setting a timeout.
Eventually (but probably not in v1) make httptrace more discoverable.

Make h2c easier and safer for clients. Rather than completely bypassing TLS, we can support a URL scheme like h2c://api.mycompany.com that uses h2c just for that pool of connections.
Build a pluggable, layered set of discovery and load balancing abstractions with reasonable defaults.

Pluggable discovery, defaulting to DNS A records with periodic refreshes. We might add SRV record support after v1. The APIs we expose should enable users to plug in other discovery mechanisms like xDS, local hostfiles, or custom ZooKeeper setups.
Pluggable subsetting, defaulting to using all the discovered IPs. We'd like the subsetting APIs to enable simple use cases, like a fixed subset size (with some basic mechanisms to help each client choose a distinct subset). The APIs may be flexible enough to support complex approaches like Twitter's deterministic aperture or Uber's dynamic subsetting.
Pluggable active health checking, defaulting to none. The APIs should be flexible enough for users to opt into gRPC health checks, simple GET /health checks, or anything in between.
Pluggable load balancing. We'd like to implement at least random, round-robin, and fewest pending, with enough flexibility for users to implement more exotic balancers like peak EWMA. By default, clients should use one of the built-in algorithms.

We'll inevitably come across situations where the net/http APIs make handling some scenarios awkward or impossible. In those situations, we'll either back off and leave the problem unsolved (after all, people manage to use net/http in all sorts of environments today!) or we'll work with other interested parties to propose improvements to the standard library. At GopherCon last year, @rhysh expressed some interest in this - Twitch has apparently run into many sharp edges while using Twirp, especially with HTTP/2.

Another thing we talked about, though maybe it would be in a post-v1 version, is configuring a minimum number of connections. This is useful for cases where address resolution returns few addresses -- or more to the point, exactly one, like when using virtual IPs and hardware load balancers.
For HTTP/layer-7 load balancers, it's not a real concern. But when the VIP is effectively a TCP load balancer (which happens to be the case for typical Kubernetes Service IPs), it's a real issue if resolving to one IP also means creating only one connection. When HTTP/2 is used in this case -- so all requests get sent as concurrent streams on the same connection -- you have effectively no load distribution; everything is sent to a single backend. Having a minimum number of connections (configurable by backend host name or address, for example) could work around this: if you create three connections to the same VIP, chances are reasonable that they are connected to different backends. (That's the whole point of the TCP load balancer after all.)
I've done work on this sort of load balancing in the past, and it is rife with edge cases. In particular, it is still possible for all connections, regardless of how many, to end up on the same backend host. (This could happen, for example, if health checks in the load balancer were not perfectly configured and/or a rolling deploy/restart proceeded too quickly.) The "easiest", or dumbest, way to combat that is to do random reconnections: every so often pick a random connection from the pool, close it, and open a new one to replace it. Even better is if they can be non-random, like having servers add a response header to all responses with some notion of their "identity". Then the client can actually tell what kind of backend diversity it has in its connections, and use that info to make better choices about how often to reconnect and which connections to close (e.g. ones whose corresponding backend are over-represented).

Final related tidbit: it would be ideal if we could override the "maximum concurrent streams" in the server's settings frame -- like to tell the client to only allow a single concurrent stream per connection. With that, it would behave effectively like HTTP 1.1 connection pools, which don't have quite as many load balancing pathologies due to the fact that they naturally create multiple connections (and thus tend to have better backend diversity for better load distribution).
But this would likely be something we'd try to get fixed/added in golang.org/x/net/http2 rather than something we'd provide in a separate library.

👋 I am going to go through everything here tomorrow and give all the feedback I can based on my experiences so far. This is exciting.

We've just cut the first public release of 'httplb - it brings configurable load balancing, name resolution, and subsetting to net/http clients! We're looking forward to your feedback over in that repository :)

authors: FlymeDllVa akshayjshah haunt98 jhump mattrobenolt

repo: bufbuild/connect-go


text:
Add protoc_args attribute to buf_lint_test and buf_breaking_test

Closes https://github.com/bufbuild/rules_buf/issues/37

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

The CLA assistant doesn't provide a button for me to actually accept the CLA...

@sushain97 Can you share the OS and browser (with version info) that you tried this on?

@sushain97 The commit was made using a different github account @sushain-stripe and the pr was opened by your personal account. That could be the issue

@srikrsna-buf wow, great catch! Thanks. Should be fixed now.

source: gharchive/pull-request

authors: CLAassistant srikrsna-buf sushain97

license_type: permissive

license_source: github-api


text:
Release v6.3.0

Prepping release.

CI does not like slashes in branch names

repo: bugsnag/bugsnag-js

license: mit

license_source: bigquery


text:
Ignore query params when searching for a bundle file

Description

Hello BugSnag team 👋
I am having trouble setting up sourcemaps for a remix project that is being run via remix-serve (default remix server). The thing is that remix-serve by default adds a query param while loading a file, this in turn - as far as I understand - makes it impossible for BugSnag to load previously uploaded source maps.
The uploaded bundle file format is index.js, source map format is index.js.map. index.js has a proper reference to the map one at the end of the file - //# sourceMappingURL=index.js.map
However, due to the the addition of extra query param added by remix-serve, the file referenced in the error looks like below:
***/build/index.js?t=1711562424160.4358:1415:4

If my assumption that BugSnag doesn't allow for extra query params in the file name is true, do you consider adding support for that in the future?
Describe the solution you'd like

I would like BugSnag to allow wildcards/file patterns for bundle files while uploading the source maps. Alternatively, BugSnag could be looking for a bundle file ignoring query params.
Describe alternatives you've considered

N/A
Additional context

Fun fact: when I rename the bundle file to include some query param (let's say I name it index.js?foo=bar) and upload it like that (let's say via bugsnag-source-maps upload-node CLI), the UI shows the file without query param being presence (it's present as index.js). It suggests to me that query parameters shouldn't be taken into consideration while BugSnag is looking for a bundle file.
And yes, I have verified that uploaded source maps have the same appVersion as my notifier, so this is not the issue.

It turned out this can be done using BugSnar REST upload API. The API allows you to specify minifiedUrl and it does support wildcards. Previously I was using the CLI and couldn't find that option. It might be reasonable to add the support for that to CLI too.

It turned out this can be done using BugSnar REST upload API. The API allows you to specify minifiedUrl and it does support wildcards. Previously I was using the CLI and couldn't find that option. It might be reasonable to add the support for that to CLI as well.

source: gharchive/issue

repo: bugsnag/bugsnag-source-maps

license: MIT


text:
Coprime id obfuscation - submodule

Obfuscate numeric ids by using coprime multiplicative inverses. https://ericlippert.com/2013/11/14/a-practical-use-of-multiplicative-inverses/
Not particularly fond of this implementation. Ideally we would have a designated django db field type for this to do this transparently. But I wasn't entirely sure how. And if it's a field type, how would it be applied to foreignkeys without actually getting the object (outcome.request_id vs outcome.request.id). I guess this approach though can be a bit of a headache when using a more automated api.
This is part1. part2 is the in the validate repo.
COPRIMESECRET currently has a hardcoded default, which is not very secure maybe, but as long as we don't forget to set something unique on PROD it's fine I guess?

Added two commits (one here, one in other repo). Some additional changes to hide internal id, add admin fields/navigation properties and fix email template rendering

authors: aothms rw-bsi

repo: buildingSMART/ifc-validation-data-model


text:
InjectBot decorator not working in modules

Somewhere in blablabla.update.ts telegram bot controller:
constructor(
  @InjectBot() private bot: TelegrafProvider,
) {}

Error:
[Nest] 87272   - 09/08/2020, 10:22:19 PM   [ExceptionHandler] Nest can't resolve dependencies of the BlablablaUpdate (?). Please make sure that the argument TelegrafProvider at index [0] is available in the BlablablaModule context.

Potential solutions:
- If TelegrafProvider is a provider, is it part of the current BlablablaModule?
- If TelegrafProvider is exported from a separate @Module, is that module imported within BlablablaModule?
  @Module({
    imports: [ /* the Module containing TelegrafProvider */ ]
  })

Fixed by https://github.com/bukhalo/nestjs-telegraf/commit/e2b81b0ad59a9fdfdb34e6bbe16c2e6f920e2f76

repo: bukhalo/nestjs-telegraf


text:
[WIP] Add bundle add command to add gems into the Gemfile

Continuing the work done to implement bundle add GEM from bundler/bundler#4546
To do:

[x] Cherry-pick commit from @ognevsky
[x] Run specs
[x] Use Bundler.definition to resolve last_version_number
[x] Pattern bundle add implementation after bundle inject
[x] Add option to specify added gem's group
[x] Add option to specify added gem's source
[x] Modify existing specs & add additional specs

@RochesterinNYC

Is there any reason this couldn't just be a plugin?

I actually want this on a regular basis, and have planned on adding it (when I get around to it 😝) for years... this is also a standard-ish feature in RubyGems, NPM, etc. I feel like it's got a pretty good case for being in core.

Should a source argument be supported? And if the Gemfile is organized in source blocks ... I guess this command wouldn't be able to add the line within an existing source block very reliably (esp. in the case with a mix of blocks and same-line and no specified source).

@chrismo, that's a fair point. For the baseline implementation, I might just expect a source argument to add the gem with the proper source explicitly at the end. I'm not sure the current Bundler classes have the ability to inject a gem into a source block for a Gemfile. Are there any use cases where the injection of the added gem into the source block is necessary as opposed to being a nice-to-have?

@RochesterinNYC Made a few changes. Can you review this? :smile:

hey @b-ggs, some things that @indirect and I discussed:
There is a bundle inject command. bundle add will be like a more user-friendly, advanced version of bundle inject. You've already covered the two main UX differences:

version is not required to be passed to bundle add
the default version constraint is ~> <latest_version>
However, it'd be nice if the bundle add and bundle inject commands could use the same underlying class (maybe the Injector https://github.com/bundler/bundler/blob/master/lib/bundler/injector.rb) as the overall functionality is very similar. Does that make sense?

:umbrella: The latest upstream changes (presumably #4608) made this pull request unmergeable. Please resolve the merge conflicts.

@RochesterinNYC Still need to add specs, but how's this?

@RochesterinNYC Code Climate seems to be complaining that this is too similar to the code in bundle inject. Maybe I should just call Inject.new([...]).run from within add.rb? Do you have any suggestions for this?

A --pre flag sounds compelling.
Yup, I don't think the Add class needs to exist. Rather, inject with certain flags/options passed in could serve for both commands.

@RochesterinNYC Removed the Add class, and moved everything into the Inject class. I also implemented the --pre flag for adding prerelease gems. Also, I added the appropriate specs. Could you check it out and let me know if I've missed anything? Thanks!

Great, what does the output for this look like? Additionally, does this print out the timestamp line in the Gemfile like bundle inject will? We'd want to avoid printing that line for bundle add.

@RochesterinNYC It originally also appened the timestamp. To remove the timestamp, I had to edit the Injector class to add an option to omit the timestamp from the lines appended to the Gemfile.
Here's the output for this:
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile
source 'https://rubygems.org'
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  dbundle add rack 1.5.0
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Added to Gemfile:
  rack (= 1.5.0)
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile
source 'https://rubygems.org'

gem 'rack', '= 1.5.0'

I also made sure that it didn't affect how bundle inject appended lines to the Gemfile.
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  dbundle inject rack 1.5.0
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Added to Gemfile:
  rack (= 1.5.0)
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile
source 'https://rubygems.org'

# Added at 2016-06-16 12:36:59 +0800 by boggs:
gem 'rack', '= 1.5.0'

@RochesterinNYC For some reason, if I don't include a version number, it seems to fetch gem metadata twice. I'll look into this.
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile                                                                                1 ↵
source 'https://rubygems.org'
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  dbundle add rack
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Resolving dependencies...
Fetching gem metadata from https://rubygems.org/
Fetching version metadata from https://rubygems.org/
Resolving dependencies...
Added to Gemfile:
  rack (= 1.6.4)
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile
source 'https://rubygems.org'

gem 'rack', '= 1.6.4'

But, so far, do you have any comments regarding the implementation?

Added some comments, I think source and group flags are also very useful for bundle add for specifying a source or group on the new gem line in the Gemfile.

How is this progressing?

@RochesterinNYC I've yet to add specs for --groups and --source, but it's pretty much working now.
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  touch Gemfile
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  dbundle add thin 1.0 --groups foobar barbaz --source file:///home/boggs/dev/bundler/tmp/gems/remote1
Fetching source index from file:/home/boggs/dev/bundler/tmp/gems/remote1/
Resolving dependencies...
Added to Gemfile:
  thin (~> 1.0)
╭─boggs@archbook ~/dev/4632-bundle-add-test ‹ruby-2.3.0› ‹node-v4.4.1›
╰─➤  cat Gemfile

gem 'thin', '~> 1.0', :group => [:foobar, :barbaz], :source => 'file:///home/boggs/dev/bundler/tmp/gems/remote1'

@RochesterinNYC I've added the appropriate specs. I cover too much on issues such as gem duplicates, etc. since inject_spec pretty much covers those kinds of issues.
As soon as the specs pass, I think this is good to go. Do you have any feedback or is there something you'd like me to add?

@RochesterinNYC This is odd - Travis seems to have stopped running specs for this PR.

@b-ggs that is odd, try to force push the PR to update it and see if that triggers a new build?

@b-ggs travis is running right now....

@segiddins @RochesterinNYC Yeah, it just showed up on my end. A few minutes ago it had only listed codeclimate as one of the checks, and was telling me that it had passed all 1 of 1 checks.

Great, I'll take another look at this and review later tonight.

Added a few more comments/small feedback points. This looks really good and about ready :+1:

@segiddins Oops, slight misunderstanding of the --pre flag. gem install cocoapods --pre gives the latest stable despite it not being a prerelease, since it's the latest available.
I've reverted back to how I was originally checking for prereleases, and have added the appropriate specs.

@segiddins @indirect can I have homu access on this PR?

@homu delegate=RochesterinNYC

:v: @RochesterinNYC can now approve this pull request

@homu r+

:pushpin: Commit ecd55e5 has been approved by RochesterinNYC

:hourglass: Testing commit ecd55e5 with merge 2439ac8...

:sunny: Test successful - status

authors: RochesterinNYC b-ggs chrismo homu indirect segiddins

repo: bundler/bundler


text:
Actually switch the default behavior of github sources.

This fixes #6910. I also took this opportunity to remove some other code
that the comments imply should have been removed in 2.0, but it looks
like never actually got removed.

I have now have a plan on how to tackle these deprecations. For starters let's do this and I'll follow up from here!

@bundlerbot r+

@bundlerbot retry

Sounds good, thanks!

We don't seem to have a setup to merge PRs to 2-0-stable. So for the moment I'm going to close this and I'll backport upon the next release.
This is fixed (and your attribution kept) in #6975 anyways.

Many thanks, @deivid-rodriguez!

authors: deivid-rodriguez jfly


text:
Segmentation Fault with recognize.py with pre-trained model

I am running the pre-trained model in a docker container. After doing the speech-to-text conversion and printing the output, the code always dumps core.
python recognize.py --file xxx.wav
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE3 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.1 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use SSE4.2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX2 instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use AVX512F instructions, but these are available on your machine and could speed up CPU computations.
W tensorflow/core/platform/cpu_feature_guard.cc:45] The TensorFlow library wasn't compiled to use FMA instructions, but these are available on your machine and could speed up CPU computations.
speech to text conversion shows up here
Segmentation fault (core dumped)

😢 Same problem here. Is there any new information?

authors: licia-tia sanzgiri

repo: buriburisuri/speech-to-text-wavenet


text:
ValueError: Shape must be rank 1 but is rank 0 for 'CTCBeamSearchDecoder' (op: 'CTCBeamSearchDecoder') with input shapes: [?,1,28], [].

When I run the file recognize.py the following errors appear:
python recognize.py --file asset/data/wav48/p225/p225_003.wav
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcublas.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcudnn.so.5 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcufft.so.8.0 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcuda.so.1 locally
I tensorflow/stream_executor/dso_loader.cc:135] successfully opened CUDA library libcurand.so.8.0 locally
INFO:tensorflow:0225:23:55:48.653:data.py:41] VCTK vocabulary loaded.
Traceback (most recent call last):
File "recognize.py", line 77, in
decoded, _ = tf.nn.ctc_beam_search_decoder(logit.sg_transpose(perm=[1, 0, 2]), seq_len, merge_repeated=False)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/ctc_ops.py", line 258, in ctc_beam_search_decoder
merge_repeated=merge_repeated))
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/ops/gen_ctc_ops.py", line 66, in _ctc_beam_search_decoder
merge_repeated=merge_repeated, name=name)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/op_def_library.py", line 763, in apply_op
op_def=op_def)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 2397, in create_op
set_shapes_for_outputs(ret)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 1757, in set_shapes_for_outputs
shapes = shape_func(op)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/ops.py", line 1707, in call_with_requiring
return call_cpp_shape_fn(op, require_shape_fn=True)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/common_shapes.py", line 610, in call_cpp_shape_fn
debug_python_shape_fn, require_shape_fn)
File "/usr/local/lib/python2.7/dist-packages/tensorflow/python/framework/common_shapes.py", line 675, in _call_cpp_shape_fn_impl
raise ValueError(err.message)
ValueError: Shape must be rank 1 but is rank 0 for 'CTCBeamSearchDecoder' (op: 'CTCBeamSearchDecoder') with input shapes: [?,1,28], [].

Got the same error here.

Same error too.

I fixed it by just downgrading sugartensor 1.0.0.1 to 0.0.2.3
pip install sugartensor==0.0.2.3
Worked for me.

I fix it by pip install sugartensor==0.0.2.3, but come up with another error:
INFO:tensorflow:0306:12:16:00.644:data.py:73] VCTK corpus loaded.(total data=36395, total batch=2274)
Traceback (most recent call last):
File "/home/frankchen/IdeaProjects/speech-to-text-wavenet/train.py", line 79, in
loss = logit.sg_ctc(target=y, seq_len=seq_len)
File "/home/frankchen/anaconda2/envs/ml3/lib/python2.7/site-packages/sugartensor/sg_main.py", line 151, in wrapper
out = func(tensor, tf.sg_opt(kwargs))
File "/home/frankchen/anaconda2/envs/ml3/lib/python2.7/site-packages/sugartensor/sg_loss.py", line 225, in sg_ctc
out = tf.nn.ctc_loss(tensor, opt.target.sg_to_sparse(), opt.seq_len, time_major=False)
File "/home/frankchen/anaconda2/envs/ml3/lib/python2.7/site-packages/sugartensor/sg_main.py", line 151, in wrapper
out = func(tensor, tf.sg_opt(kwargs))
File "/home/frankchen/anaconda2/envs/ml3/lib/python2.7/site-packages/sugartensor/sg_transform.py", line 256, in sg_to_sparse
shape=tf.shape(tensor).sg_cast(dtype=tf.int64))
TypeError: init() got an unexpected keyword argument 'shape'

Try replacing dims with axis in line 35 of train.py if you are using TF 1.0. The argument name dims has changed to axis in many functions.
seq_len = tf.not_equal(x.sg_sum(dims=2), 0.).sg_int().sg_sum(dims=1)

thanks @Kyubyong, changing 'dims' to 'axis' works for me

should be closed now with new version

authors: ChristofHenkel IsuruDilhan Kyubyong cfk1990 eurismarpires kenyeung128


text:
Plans for lighter / LGPL version?

Hello, I really like your application and would like to include it in a project. However I only release MIT / BSD licensed code, so can only use stuff with similar or dynamically linked with LGPL licenses.
I was curious if you perchance had a lighter version of its core functionally that you may be releasing in the future that is more friendly licensed?
Thanks for the great program either way!

I received a similar request when I first released this program. At that time I dismissed it because of 2 reasons:

It didn't make sense to me to want a lighter license for a standalone application (as opposed to a library).
PyQt5 was licensed under GPLv3 so I chose it as the safest option and didn't think much of it.

The second point was dealt with now that you can choose to use PySide2 instead (which is LGPL).
But regarding the first point... If I understand licensing correctly, if you just want to use the program or redistribute it as is then there's no issue (since whatever you'd be doing wouldn't really be a derivative work). But I assume you're asking because you want to modify it or use the code in some other way? I don't have a problem with that, but I can see how the license may deter you.
I wouldn't have much of an issue re-licensing the project if it was fully mine, but it isn't -- I'd have to ask the people who have contributed to it, who may or may not agree (or even reply).
So, before bothering them, it'd be great if you could explain how GPLv3 restricts you in your case. I tried looking up some info about legal implications of using GPLv3 standalone applications in projects and couldn't find anything concrete, seemed legally wishy-washy. But it sure made me feel a glimpse of pain that this infamous license inflicts on people.

I actually don't want to modify it, however the program the I am working on will be compiled into a binary file. From what I understand (not anything close to a lawyer) that by merely including it and using it as part of the bundle would force it into a GPL license. So I am actually right there with you on having to use PySide2 over PyQT and allowing it to be overwritten (dynamically linked).

I noticed the relevant project in your profile mere seconds before you responded, so now I have some context.
I would like to consider such use case not a derivative work since you'd be using the program for my intended purpose, but that's not how licenses work. I guess the only option is re-licensing.
Tomorrow I'll put together a pull request with the necessary changes and ask the contributors for permission before merging. Thankfully there are only two of them but one doesn't seem to be active on GitHub. So we'll see how it goes.

That would be amazing! It might also be possible to build cutelog it into it's own executable so it's not reliant upon the compiled python version?
Just to show where I planning to use it:  https://github.com/cdgriffith/FastFlix/tree/develop#fastflix  (can test and see it's current pathetic log viewer window under the 'help' section https://ci.appveyor.com/project/cdgriffith/fastflix/builds/24308550/artifacts)

The license has successfully been changed to MIT.

authors: busimus cdgriffith

repo: busimus/cutelog


text:
fetched data from base api and renderd it to front end

what was done

i queried the base movie API and render 16 movies out of 200 movies

good review i like your work

repo: businesskaniki/microflix


text:
Entering logograms issues in macOS

This is the issue from the Ghost project.
https://github.com/TryGhost/Ghost/issues/8319
(The issue was submitted by @mach)
Issue Summary
On Ghost Alpha's new text editor, Japanese text can't be typed correctly with Japanese IME (input method).

Steps to Reproduce
Select Japanese IME (either Apple's JapaneseIM or Google's Japanese IME)
Type "watasi"
Press Enter key

Expected Result
At step 2: "watasi" should be converted to "わたし"
At step 3: "わたし" should be converted to "私"
Actual Result
At step 2: "watasi" is converted to "wあたし"
At step 3: "wあたし" is converted to "w"
Technical details:
Ghost Version: 1.0.0-alpha.19
Node Version: v6.10.2
Browser/OS: Google Chrome / macOS Sierra
Database: MySQL 5.7.17

From testing it seems that it only occurs in an empty paragraph.

Korean has the same problem.

When will they fix it?
I'm tired of waiting.

When will they fix it?
I'm tired of waiting.

Haha not fix.

It’s still half a year before 2020. But still not fixed, who knows what other editors?

It’s been two years, still this error

@soulteary addressed the problem, ref: Issue 9801.
However it's still not merged. The bug still there.

uuuum...
The bug still there.

Insert markdown block as a workaround.

we are still enjoying this bug :)

we are still enjoying this bug :)

what's the essential thing of human being?
we are still enjoying this bug :)

The bug has been in ghost for two years, now 3.0 released...

@gpoitch Hi, want to know can this PR be merged? The bug has broken the editor of the ghost blog for more than one year https://github.com/TryGhost/Ghost/issues/9801

@bin16 this is just an issue not a PR.  Happy to merge a PR and release if someone fixes it.

I thought at least there was a partial fix https://github.com/bustle/mobiledoc-kit/pull/661

@bin16 this is just an issue not a PR. Happy to merge a PR and release if someone fixes it.

Oh, sorry, please see #661

@bin16 this is just an issue not a PR. Happy to merge a PR and release if someone fixes it.

It has been fixed and PR one year ago, not been merged yet.
Please have a look at
soulteary comment  on Jan 27 in following post
https://github.com/TryGhost/Ghost/issues/9801
This issue caused very bad experience in all asian language user group.

Please have a look at soulteary's bugfix. It works!
https://github.com/soulteary/mobiledoc-kit/commit/47ac0160f26de646f7e8f19c1a3026fb3636f8ca

@bin16 this is just an issue not a PR. Happy to merge a PR and release if someone fixes it.

Please have a look at soulteary's bugfix. It works!
https://github.com/soulteary/mobiledoc-kit/commit/47ac0160f26de646f7e8f19c1a3026fb3636f8ca

Anyone who wants to push Ghost to fix this issue, please leave a message and show your support under this issue. https://github.com/TryGhost/Ghost/issues/11460

Please review and try my pull request: https://github.com/TryGhost/mobiledoc-kit/pull/11, hope it could help.

Is this the same and will it take time to correct?
I think everyone is doing their best!

There will never fix it!

If the line breaks and input do not work in Japanese, do you mean that there is no plan to correct it?

This problem had existed for two years. 😞

😭😭

I am shocked this issue did not fixed for two years

3 years now... :-(

Work around: insert a markdown block then input & edit in this block.

When will this problem be resolved ... I am looking forward to it.

3 years now... :-(

Another solution: type a space first, then input what you want.

^ That method doesn't work well in my environment. (macOS 10.5.5beta Safari)
It seems to work well on iOS.

Finally, it has been three years.
I guess that means we should just give up on the solution.

Instead of just flooding this issue and annoying the contributors.. how about someone of the "+1" and "will this ever be fixed" crowd invest their time into providing a pull request with a fix instead? 😊

@kwmr yeah maybe they're like "f**k it, it's been three years and those who experienced this bug might already found an alternative way to solve this. I'll pretend this bug non-exist "
btw, try IA writer, it's great to have a local post file and u can publish the post in it.

Great we now have another great PR fix here. Let's see how long will they wait until that PR goes outdated. Or will someone merge it and slap in my face🤪

authors: JianpingZong Smith-Cruise apfelbox bin16 bobby285271 cmsax disordinary donamk gclove gpoitch iLoveBug imyhui ksuk kwmr ooohawk quxiaolong1504 secsilm sxueck taking wbpmrck wuliaopage xiao99xiao xufangda

repo: bustlelabs/mobiledoc-kit


text:
[v1.0.0+] Copy Paste issue (mostly with Firefox)

Hi,
In Firefox v58, selecting text for copying it is possible with the mouse but when right-clicking for pasting, this is no more possible as the menu does not contain the paste item. This problem does not occur in Chrome v64+.
I do not see errors in the developer's console.
For all browsers, it seems Ctrl+C and Ctrl+V is no more possible, is it an intended behaviour (Ctrl+C currently binds to SINGINT like many shells) or something to be fixed ?

ctrl+c and ctrl+v should be handled like a terminal, so ctrl+shift+v and ctrl+shift+c , should copy and paste.
ill have a look at the right click. now

I missed to indicate in my issue, Ctrl-Shift-C (and V) is no more working in Firefox, sorry.

confirmed that this happens in my own ff will loo in to it

i see to be able to copy just not paste

so this seems to be a issue with firefox https://github.com/xtermjs/xterm.js/issues/292

authors: butlerx mirtouf

repo: butlerx/wetty


text:
Swap shufflebags for weighted random

I like shufflebags, but a weighted random function would be better since it still allows for minigames that played previously to play as well, albeit with less chance of that happening.

Added in the latest version. Will close this once the Wiki's updated.

license: WTFPL


text:
Create camelcase rule

http://eslint.org/docs/rules/camelcase

I think we have variable-name for that in TSLint, don't we?

Yes, you're right.  Good catch.

The behavior seems a little different.  It's picking up functional parameters (dependency injections especially) and consts in the tslint rule.  I don't believe that eslint had that scoping.  It seemed to only inspect var and let statements.

authors: buzinas nfriend vort3xxx

repo: buzinas/tslint-eslint-rules


text:
Add onHeaderClick callback to FlexColumn

This isn't a complete PR, but I wanted to start a discussion about the feature.
For my project I need some external side effects to occur when clicking the header of a particular column, which are not related to sorting. This adds a prop onHeaderClick to FlexColumn that fires regardless of whether sorting is disabled, and in addition to any sort callback.
Questions:

Does the API make sense? Would this be better placed on the FlexTable level (like sort) and get the column data as args?
If the prop stays at the Column level, what args would be useful in the callback?

Hey @olslash,
Thanks for sharing your use-case and this PR with me. I think this feature makes sense. :)

Does the API make sense? Would this be better placed on the FlexTable level (like sort) and get the column data as args?
If the prop stays at the Column level, what args would be useful in the callback?

IMO my initial thought is that this probably makes more sense being defined on FlexTable because (a) a similar onRowClick property is there and (b) it prevents you from having to explicitly attach the callback to each header (assuming there's a good chance you want to know about more than one header).
My thoughts on the signature of this function would be that it should probably only receive a single parameter- the dataKey (to identify which header was clicked). I don't think we should pass any sorting related information because (a) the header might not be sortable and (b) the sort callback could be used to listen for that type of information anyway.
What are your thoughts?

Cool, i can agree on both things. Getting the dataKey in the callback would work for me and is consistent with the signature of sort as well. I'll make those edits.

Thanks so much :)
On Tuesday, January 12, 2016, Mitch Robb notifications@github.com wrote:

Cool, i can agree on both things. Getting the dataKey in the callback
would work for me and is consistent with the signature of sort as well.
I'll make those edits.
—
Reply to this email directly or view it on GitHub
https://github.com/bvaughn/react-virtualized/pull/57#issuecomment-171127729
.

Should be ready to look at now

@olslash ~ one minor suggestion and otherwise it looks great

fixed, thanks

Release 3.1.1 is available with this feature. Thanks again @olslash !

authors: bvaughn olslash

repo: bvaughn/react-virtualized


text:
🛑 Trifecta Esplanade Multipurpose Hall is down

In 20c806a, Trifecta Esplanade Multipurpose Hall (https://cloud.tymly.in/status/1169) was down:

HTTP code: 521
Response time: 20668 ms

Resolved: Trifecta Esplanade Multipurpose Hall is back up in 567bd32.

repo: bvenkysubbu/tymlymonitor


text:
🛑 Prestige Jade Pavilion Tower 2 is down

In 3fe716d, Prestige Jade Pavilion Tower 2 (https://cloud.tymly.in/status/1172) was down:

HTTP code: 521
Response time: 222 ms

Resolved: Prestige Jade Pavilion Tower 2 is back up in 1d53eba.


text:
🛑 PSR Aster 1 is down

In 481a457, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20232 ms

Resolved: PSR Aster 1 is back up in f40ae53.


text:
🛑 VBHC Serene Town B Block is down

In 81a22f5, VBHC Serene Town B Block (https://cloud.tymly.in/status/1130) was down:

HTTP code: 0
Response time: 0 ms

Resolved: VBHC Serene Town B Block is back up in 2c1d368.


text:
🛑 PSR Aster 1 is down

In d1e1524, PSR Aster 1 (https://cloud.tymly.in/status/1059) was down:

HTTP code: 521
Response time: 20228 ms

Resolved: PSR Aster 1 is back up in 2969c08.


text:
🛑 Ruchira Lilium v2 is down

In db36565, Ruchira Lilium v2 (https://cloud.tymly.in/status/1048) was down:

HTTP code: 521
Response time: 20220 ms

Resolved: Ruchira Lilium v2 is back up in b4cd6e9.


text:
🛑 Sterling Villa Grande is down

In fdee7f1, Sterling Villa Grande (https://cloud.tymly.in/status/1068) was down:

HTTP code: 521
Response time: 218 ms

Resolved: Sterling Villa Grande is back up in eda1557.


text:
🛑 SMR Vinay Cascade A Block is down

In 6a9add5, SMR Vinay Cascade A Block (https://cloud.tymly.in/status/1094) was down:

HTTP code: 521
Response time: 20547 ms

Resolved: SMR Vinay Cascade A Block is back up in 1f9cec5.


text:
🛑 SBB Touchstone A1 Block is down

In 4ba0dcf, SBB Touchstone A1 Block (https://cloud.tymly.in/status/1186) was down:

HTTP code: 521
Response time: 219 ms

Resolved: SBB Touchstone A1 Block is back up in 12066ac.


text:
🛑 Hinduja Park 1 is down

In d574105, Hinduja Park 1 (https://cloud.tymly.in/status/1067) was down:

HTTP code: 521
Response time: 20234 ms

Resolved: Hinduja Park 1 is back up in 5c80d00.


text:
🛑 Trifecta Esplanade P Block is down

In 17a97d9, Trifecta Esplanade P Block (https://cloud.tymly.in/status/1017) was down:

HTTP code: 521
Response time: 285 ms

Resolved: Trifecta Esplanade P Block is back up in 2948db3.


text:
🛑 Trifecta Esplanade Security is down

In 483e0bf, Trifecta Esplanade Security (https://cloud.tymly.in/status/1168) was down:

HTTP code: 521
Response time: 269 ms

Resolved: Trifecta Esplanade Security is back up in f2a4a79.


text:
🛑 SBB Touchstone D Block is down

In 5901624, SBB Touchstone D Block (https://cloud.tymly.in/status/1185) was down:

HTTP code: 521
Response time: 20221 ms

Resolved: SBB Touchstone D Block is back up in 6b11282.


text:
🛑 Brigade Cosmopolis Clubhouse End is down

In 1980ea3, Brigade Cosmopolis Clubhouse End (https://cloud.tymly.in/status/1145) was down:

HTTP code: 521
Response time: 240 ms

Resolved: Brigade Cosmopolis Clubhouse End is back up in a0f1a7b.


text:
🛑 SMD Altezz Block B is down

In 1baf1f5, SMD Altezz Block B (https://cloud.tymly.in/status/1176) was down:

HTTP code: 521
Response time: 20229 ms

Resolved: SMD Altezz Block B is back up in b2ae508.


text:
🛑 Dasta Concerto Clubhouse Gym is down

In bb6737f, Dasta Concerto Clubhouse Gym (https://cloud.tymly.in/status/1189) was down:

HTTP code: 521
Response time: 227 ms

Resolved: Dasta Concerto Clubhouse Gym is back up in 376bac6.


text:
🛑 Trifecta Esplanade P Block is down

In 1ab2755, Trifecta Esplanade P Block (https://cloud.tymly.in/status/1017) was down:

HTTP code: 521
Response time: 20220 ms

Resolved: Trifecta Esplanade P Block is back up in df0e6a2.


text:
🛑 VBHC Serene Town D Block is down

In b2d3198, VBHC Serene Town D Block (https://cloud.tymly.in/status/1131) was down:

HTTP code: 521
Response time: 20236 ms

Resolved: VBHC Serene Town D Block is back up in 5398675.


text:
Sonoff TH10/16 Switch (Power On/Off) is shown as Temperature. So the Icon doesnt change color if power is turned to on.

In the original Homekit App by Apple the Switch Status Power On or Power Off is written on the Symbol, but if the Status is On, the Symbol doesn’t change color to white. That’s because the Switch is shown as Temperature.

Hi,
have you tried the home app option to “show as separate tiles”? then you should have a power switch tile that behaves exactly as you are asking about.

Hey Ben,
there is no option „show as separate titles“. I am on iOS 14.2.

Would you be happy to share this device to my ewelink account so i can look into this more easily?
thanks

How can I do this?

Through the ewelink app try sharing to:
country code 44 (uk)
email bwp91@icloud.com

Done!

Can I turn it on/off?

Yes

Are you running homebridge? homebridge-config-ui? hoobs?

Homebridge with Homebridge-Config-UI. Everything updated to latest version yesterday.

Fab.
Can I get you to use this guide to install a beta version, v3.12.0-6, and then
Use this guide to remove the current TH10/16 device from the homebridge cache, so it is readded.

I am on 4.32.0
Do i have to downgrade?
I don’t want this.

No, it’s a beta version of this plugin :)

:-)) Okay. I've installed the latest beta v3.12.0-6.
Everything is the same. But Homebridge loaded the cache.
The Menu to clean the cache doesn't show on my Homebridge-ui.
I realised that my Homebridge is not running as a service.
I will try to change this. I hope it isn't to complicated. I'll try this in 1 or 2 hours.
When I got it, i'll write here a message...

It worked. One time. Now I am in trouble. I've installed the hb-service but i have systemd too. Than I hab 2 instances of Homebridge running. One on port 8181 and one on port 8581 (the new one with hb-service). The Config-UI showed me the new options. On HomeKit nothing worked any more. So I deleted the HomeBridge in the Home App and scanned the one I've started with hb-service. Now I could install the new Items. The Buttons worked now. When I restarted my Raspberry. I'm back on the old version of Homebridge. I've to deleted this anyway and use the new one.

I think I got it running. Now with hb-service. I had fear because my whole house is controlled over the Homebridge. Now it works again and I've new options in the Config-UI Interface. Great. Now your ewelink devices are shown correctly. Thank you!!

Amazing :) Glad it’s working for you!


text:
H6127 not currently supported. Details as requested in log

[Govee] [Study Led] is not currently supported, do create a Github issue with the following info:
[29/07/2021, 11:33:29] [Govee] {
device: 'abee96bd0fe2dc98',
deviceName: 'Study Led',
model: 'H6127',
httpInfo: {
device: 'abee96bd0fe2dc98',
sku: 'H6127',
spec: '',
versionHard: '1.00.03',
versionSoft: '1.06.10',
deviceName: 'Study Led',
deviceExt: {
deviceSettings: '{"address":"A4:C1:38:00:7F:D9","bleName":"ihoment_H6127_7FD9","pactType":1,"pactCode":1,"ic":50,"sku":"H6127","device":"abee96bd0fe2dc98","deviceName":"Study Led","versionHard":"1.00.03","versionSoft":"1.06.10"}',
lastDeviceData: '{"online":false}',
extResources: '{"skuUrl":"","headOnImg":"https://d1f2504ijhdyjw.cloudfront.net/sku-img/7497e9e37fb1d7461581173195ffcf3e-new_light_title_home_on.png","headOffImg":"https://d1f2504ijhdyjw.cloudfront.net/sku-img/871d58cc47b99af39dead92abd2acd01-new_light_title_home_off.png","ext":"","ic":50}'
},
pactType: 1,
pactCode: 1,
goodsType: 0
},
isAPIDevice: false
}

Hi @Subivan1
Thanks for this. What platform are you running homebridge on? Would you be interested in the bluetooth control (it can sometimes take a bit of extra manual setup)?

Hi,
I am using a raspberry pi 3+  Homebridge UI, And I think I am up to date on Node etc.
Yes I would be interested in Bluetooth control and I am happy to give the extra setup a go and play around with things.
Cheers
Mike
Cheers
Sent from my iPad

On 29 Jul 2021, at 11:53, Ben @.***> wrote:

Hi @Subivan1
Thanks for this. What platform are you running homebridge on? Would you be interested in the bluetooth control (it can sometimes take a bit of extra manual setup)?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

Can you update to beta version of the plugin, v3.8.1-beta.1 and then use the plugin settings screen to add an entry for your lights in the 'Light Devices' section.
Use device ID AB:EE:96:BD:0F:E2:DC:98.
And tick the "Enable BLE" box.
It might also be worth ticking the 'Debug Logging' box in the optional settings just until you get it to work.
Restart the plugin and the device should be added to homebridge. You can try to control it from the home app, if it doesn't work then the homebridge log should offer a reason why not.
There may be a couple of commands you need to run in the homebridge terminal, try this if it doesn't initially work:
https://github.com/bwp91/homebridge-govee/wiki/Bluetooth-Control
Let me know how you get on!

I will give that a go this evening. I will let you know how I get on.
Sent from my iPad

On 29 Jul 2021, at 12:37, Ben @.***> wrote:

Can you update to beta version of the plugin, v3.8.1-beta.1 and then use the plugin settings screen to add an entry for your lights in the 'Light Devices' section.
Use device ID AB:EE:96:BD:0F:E2:DC:98.
And tick the "Enable BLE" box.
It might also be worth ticking the 'Debug Logging' box in the optional settings just until you get it to work.
Restart the plugin and the device should be added to homebridge. You can try to control it from the home app, if it doesn't work then the homebridge log should offer a reason why not.
There may be a couple of commands you need to run in the homebridge terminal, try this if it doesn't initially work:
https://github.com/bwp91/homebridge-govee/wiki/Bluetooth-Control
Let me know how you get on!
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.

everything worked on the Beta and have now updated to latest release and everything is still fine. Thanks very much.

Brilliant response and update works fine.


text:
Not able to install ha-bridge in hassio 0.91.4

I am not able to install ha- bridge  add-on in hassio 0.91.4 , did a full wipe out & re installed the hassio even then it's not getting installed, any help here would be appreciated, thanks in advance

If this is part of the Hass.io install, please post in their forum. We did not build that add on install.

I'm assuming you have posted this issue on the hass.io forums.

authors: bwssytems pradeepmilly

repo: bwssytems/ha-bridge


text:
[MDL=> Material2] Get rid of mdl classes (mdl-data-table)

We need to get rid of MDL components.
Need to replace them by angular-material component: Get rid of mdl classes (mdl-data-table)

same as #329

authors: ershovaelena wowshakhov

repo: bwsw/cloudstack-ui


text:
Additional imports in generated component

A WebAssembly component generated with cargo-component has additional imports not mentioned in the world.wit (I suspect because of the Rust standard library?), namely
wasi:cli/environment@0.2.0;
wasi:cli/exit@0.2.0;
wasi:io/error@0.2.0;
wasi:io/streams@0.2.0;
wasi:cli/stdin@0.2.0;
wasi:cli/stdout@0.2.0;
wasi:cli/stderr@0.2.0;
wasi:clocks/wall-clock@0.2.0;
wasi:filesystem/types@0.2.0;
wasi:filesystem/preopens@0.2.0;

That came as a surprise to me when I tried to run the component in Wasmtime (without including wasmtime_wasi):
Error: component imports instance `wasi:cli/environment@0.2.0`, but a matching implementation was not found in the linker

Maybe I missed it, but I think this behavior is not documented in the README, in which case I would suggest mentioning it somewhere.
Also, I was wondering if it is possible to avoid these additional imports, possibly by using #![no_std] and thus not linking libstd..?

You are correct that, by default, certain WASI interfaces are automatically imported based upon the component's use of the Rust stdlib.
It is possible to avoid this by not using the wasm32-wasi target (which is the default target of cargo-component).
If you pass --target wasm32-unknown-unknown, the component will not import any WASI interfaces, by default, but it still may import any WASI interfaces that were explicitly imported by the target world.

authors: kaivol peterhuene

repo: bytecodealliance/cargo-component


text:
Unexpected Behavior in JIT Mode

Build commands
I compile the code with commit id 8b8c59589dc725b04754018173463c388e7a29ea.
Platform: Ubuntu 20.04
CPU: amd64
compile:
export CC=/usr/lib/llvm-16/bin/clang
export CXX=/usr/lib/llvm-16/bin/clang++
cd product-mini/platforms/linux/;rm -rf build
cmake  -DWASM_ENABLE_AOT=1 -DWAMR_BUILD_JIT=1 -DWAMR_BUILD_FAST_JIT=0   -DCMAKE_INSTALL_PREFIX="xxx" -DWAMR_BUILD_REF_TYPES=1 -DCMAKE_BUILD_TYPE=Release  -DWASM_ENABLE_BULK_MEMORY=1 -DWAMR_BUILD_LIBC_WASI=0 -DWAMR_BUILD_LIBC_BUILTIN=1 -DWAMR_BUILD_SIMD=1 -Bbuild

execute:
iwasm --heap-size=0 --llvm-jit -f to_test <tc_name>

Cases
iwasm_jit_select_exception.zip
(module
  (type (;0;) (func (result funcref)))
  (func (;0;) (type 0) (result funcref)
    ref.func 0
    ref.null func
    memory.size
    br_if 0 (;@0;)
    i32.const 1
    select (result funcref))
  (memory (;0;) 1 5)
  (export "_start" (func 0))
  (export "to_test" (func 0)))

Actual behavior:
No exception
func:ref.null

Expected behavior:
Exception
WASM module load failed: Error: invalid stack values with different type

Hi, I think this bug is because of spec update, I used the low version wabt and there is the same exception. I will look into it.

Hi, I think this bug is because of spec update, I used the low version wabt and there is the same exception. I will look into it.
Wamr on different modes (e.g., interpreter mode, fast JIT mode) will not raise this exception.

@erxiaozhou the issue was fixed with https://github.com/bytecodealliance/wasm-micro-runtime/pull/3169, please try again. Thanks for spotting the issue!

Close the issue since it had been fixed.

authors: TianlongLiang erxiaozhou wenyongh

repo: bytecodealliance/wasm-micro-runtime


text:
Cranelift: hit unreachable case while lowering fcvt_to_uint

.clif Test Case
function %f13(f32x4) -> i32x4 {
block0(v0: f32x4):
  v1 = fcvt_to_uint.i32x4 v0
  return v1
}

Steps to Reproduce
Compiling this causes an unreachable case to be reached: https://github.com/bytecodealliance/wasmtime/blob/380db48ce6b7a754025e33bde02a8d14897376f3/cranelift/codegen/src/isa/x64/lower.rs#L800-L804
Expected Results
Either an error or a successful compilation.
Actual Results
Panic
Versions and Environment
Cranelift version or commit: 0c2e0494bdc63518962ad2773abc13d7d1d1dd8a
Operating system: linux
Architecture: x86_64

Hi @elliottt . Does this unreachable case get hit before patch https://github.com/bytecodealliance/wasmtime/pull/4684 ?
I have not tried, but the comments here say this unreachable is guarded by both the Opcode::FcvtToUnit and Opcode::FcvtToSint. It looks like 4864 removed one of those branches and if so I wondering if that patch (removing that code) introduced the possibility of this fall through?

I hit the panic at c4fd6a95da582a4a21802d981062c9202746ef19, which is the direct parent of #4684. This panic is from fcvt_to_uint, vs fcvt_from_uint which was ported to ISLE in #4684.

Hi @elliottt. I went to try and reproduce this issue and noticed that I was seeing the unreachable code but not where this original bug filing notes it. Looks like code has changed with https://github.com/bytecodealliance/wasmtime/pull/4704. Was that patch supposed to resolve this issue? I can reproduce still with this file:

test run
target x86_64
function %f13(f32x4) -> i32x4 {
block0(v0: f32x4):
v1 = fcvt_to_uint.i32x4 v0
return v1
}
; run: %f13([0x1.0 0.0 0x1.0 0x75bcd18.0]) == [1 0 1 123456789])

run with:
RUST_BACKTRACE=1 ./target/debug/clif-util test cranelift/filetests/filetests/runtests/test.clif

repo: bytecodealliance/wasmtime


text:
Cranelift: fcvt_to_sint_sat.{i8,i16} wrong result on riscv64

👋 Hey,
Fuzzgen found this, Its hard to minimize because changing an unrelated instruction spontaneously causes the test to start passing again.
.clif Test Case
test interpret
test run
target riscv64gc

function %a(i32 sext, f64, f32, i64 uext) -> f32, i8, i8 system_v {
block0(v0: i32, v1: f64, v2: f32, v3: i64):
    v12 -> v1
    v14 -> v2
    v16 -> v2
    v4 = iconst.i16 0x4242
    v5 = iconst.i64 0x0042_4242_4242_4242
    jump block1

block1:
    v13 = fcvt_to_sint_sat.i8 v12
    v15 -> v13
    brif v13, block2, block1

block2:
    return v14, v15, v15
}

; run: %a(1111441986, -0x1.ffa8b425b4242p128, 0x0.00859ep-126, 0) == [0x0.00859ep-126, -128, -128]

Edit: This testcase segfaults instead of going into an infinite loop
test interpret
test run
target riscv64gc

function %a(i8 sext, i128 sext, f32, f64, f64, f64, f64, f64, f64, i32 uext, i16 uext, i64 sext) -> f64, f32, i64 sext, i64 sext, i32, f32, f32, f32, f32 system_v {
block0(v0: i8, v1: i128, v2: f32, v3: f64, v4: f64, v5: f64, v6: f64, v7: f64, v8: f64, v9: i32, v10: i16, v11: i64):
    v24 -> v4
    v25 -> v11
    v16 = iconst.i8 0
    v17 = iconst.i16 0
    v18 = iconst.i32 0
    v19 = iconst.i64 0
    v20 = uextend.i128 v19  ; v19 = 0
    v21 = fcvt_to_sint_sat.i16 v5
    v23 -> v21
    v22 = sshr v9, v9
    v26 -> v22
    brif v22, block1(v2, v2), block1(v2, v2)

block1(v12: f32, v13: f32):
    brif.i16 v23, block2(v13, v13), block2(v13, v13)

block2(v14: f32, v15: f32):
    return v24, v15, v25, v25, v26, v15, v15, v15, v15
}

; run: %a(47, 19850, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0, 0, 0) == [0.0, 0.0, 0, 0, 0, 0.0, 0.0, 0.0, 0.0]
; run: %a(0, 0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0, 0, 0) == [0.0, 0.0, 0, 0, 0, 0.0, 0.0, 0.0, 0.0]

Steps to Reproduce

clif-util test ./the-above.clif

Expected Results
The test to pass
Actual Results
The test case goes into an infinite loop due to a wrong result from fcvt_to_sint_sat
Versions and Environment
Cranelift version or commit: main
Operating system: Linux
Architecture: riscv64
cc: @yuyang-ok

@afonso360 Yeah,This is a bug.

You might need to rebase on main, we replaced brz/brnz with brif recently.

@elliottt ok, thanks.

I tested it,The latest code works fine.

authors: afonso360 elliottt yuyang-ok


text:
wasi-parallel: implement CPU parallelism

This change implements wasi-parallel in Wasmtime. It addresses only the CPU parallelism (not GPU), since this would introduce additional complexity to an already difficult review (if you're interested about the GPU progress, talk to @egalli). Each commit implements a separate piece to the puzzle. Though most of the changed lines are not the core implementation (see tests, LICENSE, etc.), due to the size of the PR, it may be convenient to look at this commit by commit.
I see several issues highlighted by this change:

lacking toolchain support: in the absence of any other feasible path, the WebAssembly bytes of the kernel code to be executed in parallel are embedded in the host WebAssembly module itself. This is problematic for many reasons, not least of which is the ability for the host WebAssembly module to tamper with the kernel (on the flip side: an intra-module JIT compiler feature!). But that is not the end of it: toolchain support is also lacking simply to produce modules that use atomics and shared memory. For C programs: https://github.com/WebAssembly/wasi-libc/issues/326. For Rust programs: https://github.com/rust-lang/rust/issues/102157. Due to all this, most tests and examples in this crate are meticulously hand-crafted WAT files — once toolchain support improves these difficult-to-maintain files should be replaced.
uncomfortable Wasmtime/Wiggle APIs: this implementation of wasi-parallel works by creating new instances of the kernel in each thread of a thread pool — the host module exports a shared memory and the kernel imports it. Getting access to the shared memory from within a wasi-parallel invocation is difficult with Wasmtime/Wiggle: the best way I could think to resolve this is to teach Wiggle to skip a WITX function and then manually implement add_to_linker for that function. This is tedious and error-prone, so I would be excited to discuss better solutions. Note that an almost identical version of this problem will arise when I try to implement wasi-threads.

Why now? The rationale behind merging this code behind the wasi-parallel feature flag is to enable users to try this out locally and to iterate on this in-tree (e.g., toolchain, GPU parts).

lacking toolchain support: in the absence of any other feasible path, the WebAssembly bytes of the kernel code to be executed in parallel are embedded in the host WebAssembly module itself. This is problematic for many reasons, not least of which is the ability for the host WebAssembly module to tamper with the kernel (on the flip side: an intra-module JIT compiler feature!). But that is not the end of it: toolchain support is also lacking simply to produce modules that use atomics and shared memory. For C programs: How to distribute THREAD_MODEL=posix builds? WebAssembly/wasi-libc#326. For Rust programs: Fail to compile with WebAssembly atomics and shared memory rust-lang/rust#102157. Due to all this, most tests and examples in this crate are meticulously hand-crafted WAT files — once toolchain support improves these difficult-to-maintain files should be replaced.

I think it is important to note that this PR does not depend on toolchain - implementing an API in consumer should not require a particular producer to be on board; multiple memories are a a different example of this. Also keep in mind that libc support is already implemented, WebAssembly/wasi-libc#326 is strictly about packaging and detecting it.

That's true, yes, and I feel pretty similarly to the wasi-threads proposal as what's here as well. I also don't see a future for the wasi-threads proposal as-is in the component model right now. If these proposals want to integrate with the component model I think work needs to happen in the component model itself rather than assuming the functionality can be implemented with special host functions.

Just out of curiosity, as I haven't been following wasi meetings very closely, what is the background of the requirement that wasi interfaces only use component model?

My understanding of how wasi-parallel is expected to fit into the component model is that it could be packaged as an import of a core-module, with the core-module importing the linear memory and exporting functions that operate on it directly. That isn't supported in wit or wit-bindgen today, so we'll need interim approaches, but eventually we should be able to pull these into the wit framework.

@alexcrichton thank you for the detailed answers.

I'm not sure what you mean though by if this only applies to wasmtime.

I meant to ask whether this is the approach adopted specifically by wasmtime or by component model, but you have answered that.

My understanding of how wasi-parallel is expected to fit into the component model is that it could be packaged as an import of a core-module, with the core-module importing the linear memory and exporting functions that operate on it directly. That isn't supported in wit or wit-bindgen today, so we'll need interim approaches, but eventually we should be able to pull these into the wit framework.

Does component model allow this yet? What can the interim approaches be? Maybe we should take it the component-model repo though.

The component model does support importing a core wasm module, but that's not reflected in the *.wit textual description of APIs at this time. For interim things I suspect that'd be good to bring up on the component model repo yeah.

@alexcrichton, I think there are several points you should reconsider:

In the component model the hack you've implemented here with getting the shared memory to work will not work and has no way of working, there's no escape hatch to implement as you've done here.

Then there's a bug in the component model specification. If there is no way to support multiple WASI proposals (wasi-parallel, wasi-threads), no way to satisfy the recurring requests for access to the host (latest of which is https://github.com/bytecodealliance/wit-bindgen/issues/313), and no way to then make use of the core WebAssembly threads proposal, then the WIT specification is not complete enough. If there isn't an escape hatch, then one should be built.

Additionally the existing wasi-common, wasi-nn, and wasi-crypto will likely all need to get removed or refactored or something with a transition away from wiggle

Sure, but that should not block progress. The issue you point out is not with those WASI contributions but rather with the unstable state of wit-bindgen. I tried to refactor wasi-nn to use WIT a month or two ago and the tools were simply not ready. If the spec is not ready and the tools are not ready, it seems unreasonable to block all other work on that. I think the more productive approach would be to allow WASI proposals to continue and ensure that both the WIT spec and tooling can do everything wiggle could.

I am not sure how useful it's been to have wasi-nn and wasi-crypto in this repository, I am not aware of how much usage they're getting and feedback they're providing to the upstream proposals.

You should talk to @geekbeast, also a Fastly employee. He was attempting to use wasi-nn in Viceroy and was able to do so based on the reference implementation here.

I also don't see a future for the wasi-threads proposal as-is in the component model right now. If these proposals want to integrate with the component model I think work needs to happen in the component model itself rather than assuming the functionality can be implemented with special host functions.

I am not involved in component model design... but you are 😁. This PR — along with https://github.com/WebAssembly/wasi-parallel/issues/4, https://github.com/bytecodealliance/wit-bindgen/issues/130, https://github.com/bytecodealliance/wit-bindgen/issues/313 — should be great feedback for a component model issue that you would know how to craft but I would not. I don't understand all of the component model requirements, history, etc. so my ability to contribute there is limited. Why not just take this PR as feedback to the component model and propose a solution so that these WASI proposals can have a future?

Agreed with @sunfishcode above that the right way to support various kinds of shared-memory multi-threading in WASI in a component-model world is by expressing the imported threading functionality as core module imports, which are then instantiated by the component to explicitly share core memory with the other core modules inside the component.  When core wasm eventually gets a fork instruction for creating threads purely from within core wasm, then these core module imports would even be virtualizable from core wasm, satisfying WASI's general goal to specify virtualizable interfaces.
This does raise the question of how to write the interface of a core module in Wit, since there currently isn't any syntactic support for this.  But it's easy to imagine a Wit-like syntax for core:moduletype with a new top-level module keyword that can then be mentioned via import in a world.  IIUC, this same Wit syntax would be independently useful for reflecting the types of components that import shared-everything dynamically-linked libraries, like a libc or libspidermonkey, using CanonicalABI.md saying how things get linked up by default, which is something @sunfishcode have also been talking about recently.  So it's good to have 2 rather-symmetric motivating use cases for this new Wit functionality.
I don't have enough understanding (particularly around Wiggle) to say what we should do in the right-now term before the above Wit functionality gets implemented.  But switching out Wiggle for Wit does seem like it should be our goal state.

Thanks @sunfishcode and @lukewagner for pointing out that the shared memory import/export will be expressible with WIT core modules. I still have questions on this (When and how can the core module syntax be implemented? Is help needed there and, if so, what? Should that block this PR?) but it seems like long term there should not be a problem with wasi-parallel moving to WIT related to shared memory import/export.
But, to take up what I think is @alexcrichton's point, the issue is actually about host access. Proposals like this one and wasi-threads and other use cases (like the ones linked above) want to touch the host itself, e.g., Wasmtime APIs like Caller, Module, Store, Engine. In wasi-threads, e.g., wasi_thread_spawn will need access to the Module of the parent thread in order to create new instances of it and access to the SharedMemory in the Store to import that in each new child thread. I think what @alexcrichton is saying is that the WIT syntax and tooling do not support this and never will (?), which I was asking him to reconsider.
I actually see several possibilities along a continuum:
a. dead in the water: the WIT syntax never has knowledge of "host access," the tools don't support it, and this class of proposal is dead in the water (from @alexcrichton's argument that engines like Wasmtime will not want to support non-WIT-able proposals)
b. hack: the WIT syntax still has no knowledge of "host access," the tools still don't support it, but this class of proposal can be implemented as a core module with some hacking on the linker (as done in this PR) to get access to the host (I don't understand how this would look in WIT!)
c. escape hatch: the WIT syntax still has no knowledge of "host access," the tools do support it as an escape hatch (e.g., an additional parameter to the WIT macros like host_access_functions: ["..."]), and this class of proposal can be more cleanly implemented
d. full support: the WIT syntax does gain knowledge of "host access" (perhaps with a new host keyword in the signature of functions, e.g., wasi_foo(host, x: i32, y: i32)), then the tools would support it, etc.
I've implemented "b" and I believe @alexcrichton was suggesting "a." I would prefer "c." @lukewagner, @sunfishcode: I can't tell from your comments but I think you are not saying "a"?

(Also, please prefix every sentence above with "IIUC" since I am not too familiar with the details of the component model and I'm reading into some of @alexcrichton's comments).

To some degree I'm trying really hard here to be an impartial messenger, along the lines of "please don't shoot the messenger". I'm pretty intimately aware of all the constraints here ranging from the threads proposal to the desire for WASI threads to the component model itself, but I am trying to not take on the design myself and leave that to others. To that end I don't have great responses to comments such as:

If there isn't an escape hatch, then one should be built.

I'm pointing out the systems that are in play and their various designs, and all of these systems have intentional design behind them. I am not personally going to go to the component model repository and open a "please add a small escape hatch" issue because I'm aware of why one hasn't been added yet. Furthermore I'm not going to go to the wasi-parallel proposal and open an issue saying "you will never work with the component model" because I'm aware of the strong motivations for such a proposal. I'm trying to ideally state impartial facts here without trying to solve everything myself.
That being said I naturally have a lot of opinions about how this should all work. If a parallelism story for wasm requires an "escape hatch" that seems like a fundamental problem because parallelism is such a foundational part of any runtime environment that if it's not designed for from day one it seems to me like it has little chance of gaining any amount of larger traction. For example just because Wasmtime is capable of implementing escape hatches like this in no way means other runtimes can do so. The Caller context is not available on the web, for example, meaning that if the wasi-parallel proposal crucially relies on such an escape hatch then that would be unimplementable or otherwise problematic for the web.
Personally I even have hesitation about the whole kernel model in wasi-parallel. I don't understand how anyone could productively write a kernel that literally only imports shared memory and nothing else. Virtually no language can target a world where nothing is imported and if nothing is imported then a language can't even do something like print a line to standard out. While it's theoretically possible and technically possible to get something working here I feel that this is a far cry from a productive developer experience.
Again though I'm trying hard to not insert myself into the design here. These are some thoughts of mine but honestly I don't consider them relevant since I'm not the one championing or being involved in the proposal. At the same time though I feel like someone has to point out the actual limitations of the systems that are being built at some point as otherwise it feels like things are carried on as everyone's just blindly merging everyone else's work without thought to the consequences.

Why not just take this PR as feedback to the component model and propose a solution so that these WASI proposals can have a future?

My hope is that design issues like running wasi-parallel in the component model would have come up much earlier in the design process long before a PR came to Wasmtime here. This isn't really the right place to discuss deep design details of the proposal or modifications to the component model. Otherwise though I don't really think it's a productive developer process to create a proof of concept and then turn around to the component model and say "you figure out how to get this working it can't regress". The design here should be a collaborative process of all parties involved which doesn't just shove all the work onto one person to figure out everything.

Sorry for the long post, I have a lot of thoughts on this but now's probably not the time or the place. I'll reiterate that I personally would like to see threads-on-wasm via a standard like WASI. I don't think that the component model and WASI are in a state where things can be plucked off the shelf, mashed together, and a workable standard created. I feel there are deeper designs that need to be implemented and accounted for before moving forward with this iteration of wasi-parallel. For example the import-a-core-wasm-module idea seems plausible, but AFAIK the wasi-parallel proposal has not been designed with this in mind, runtime support in Wasmtime has not been implemented with this in mind, and support in developer tooling (a la *.wit) has not been designed with this in mind. That's a lot of hypothetical work to leave on the table while asking to merge this as an interim solution.

I'd be curious to see how others feel about this though. I am not sure how useful it's been to have wasi-nn and wasi-crypto in this repository, I am not aware of how much usage they're getting and feedback they're providing to the upstream proposals. In that sense I'm not sure how beneficial it will be to land this here vs have it externally.

Is there a good mechanism to track usage of various features in Wasmtime? Usually I have no knowledge of certain features being used by a customer until they contact us with some issues, or they present/publish their usage somewhere. And these are probably a subset of total user base. For example, I know a big device manufacturer is in the process of embedding wasi-nn into their products. For wasi-crypto, it is an essential function for a Wasm runtime to be selected for a SASE project we are involved.
Here are a few links of wasi-nn usages from googling (not all on Wasmtime):
https://deislabs.io/posts/wasi-nn-onnx/
https://www.secondstate.io/articles/openvino-inferencing-using-wasmedge-wasi-nn/
https://wasmedge.org/book/en/write_wasm/rust/wasinn.html
https://cfp.cloud-native.rejekts.io/cloud-native-rejekts-eu-valencia-2022/talk/NXLTRQ/
https://www.youtube.com/watch?v=48ORmla7mak&list=PLj6h78yzYM2Ni0u-ONljTkv4uOutyjwq9&index=11

Just as an update: I realized my comment above was forgetting that we're talking about the core-instance-per-thread approach to multi-threading, for which the core module import approach I suggested above would need the imported core module to itself have a module import (the module to be instantiated for each new thread), which is not yet possible in core wasm.  So that might not be the right approach here.
It does really seem like the best approach to exposing multi-threading to core wasm in a standard way is as proposed by Watt & Rossberg, as a core wasm feature.  Although what we do to allow short-term experimentation and prototyping in Wasmtime is a different question.

For example just because Wasmtime is capable of implementing escape hatches like this in no way means other runtimes can do so. The Caller context is not available on the web, for example, meaning that if the wasi-parallel proposal crucially relies on such an escape hatch then that would be unimplementable or otherwise problematic for the web.

Web engines support this via a JavaScript callback which creates another copy of the instance. Web polyfill was part of the motivation for wasi-threads proposal, the other part being the fact that at least one more standalone engine supports it as well. Core spec supports multiple instance executing in parallel, this isn't an unknown either.

@mingqiusun for sure yeah, I don't mean to say definitively whether or not those proposal should be removed from the repository, and it's great to hear that wasi-nn is getting such usage!
@penzn indeed you are correct. There are a huge number of caveats with the support on the web for threading, however, including:

The threads proposal is not offically merged into the wasm spec yet
I'm not aware of any general purpose "spawn a thread library" due to the instance-per-thread model which requires somehow getting a module's instance imports onto web workers. All solutions I know of are very runtime-specific or specific to the shape of module and what it imports. Everything I'm aware of at least is very far from "just call pthread_create and it all works"
The web's abstraction layer is not components, which I believe wasi-{parallel,threads} want to target at this time. The component abstraction layer, at this time, does not allow for precisely the same capabilities of what core wasm allows.

One point that's probably worth clarifying is that it's not like I think Wasmtime shouldn't be able to implement a web-style threading scenario. In fact you can, already today, implement "threading" with Wasmtime since you as the host can spawn threads and figure out how to instantiate modules on new threads and share host state. There's nothing inherent to Wasmtime preventing this with Wasmtime's core wasm embedding API.

I talked with @abrown at great length yesterday about this and we're going to try to allocate time next week to discuss what it might look like for wasi-parallel to get integrated into the component model more completely. In the meantime my personal feelings on this PR is that I would like to make sure that this iteration of wasi-parallel and wasi-threads can be implemented with Wasmtime's embedding API, but otherwise this implementation I think might be best to reside in a different repository than the main Wasmtime repository.

@abrown, @lukewagner, @sunfishcode, and I talked last week at great length about this PR and the various issues here, zooming out mostly to threads in the component model. We concluded a number of things that I hope to summarize here, and please correct me y'all if I miss anything.
Our general topic was what to do with threads, the component model, and having the two work in harmony with each other. To that end we broke down a possible plan of action in to three "stages" ordered from shorest-time-to-implement to longest-time-to-impelment.
Stage 1
The first thing for Wasmtime and threads is to get anything working all. The goal here would effectively, through some wasm-defined API using Wasmtime's embedding API, achieving the functionality proposed by wasi-{threads,parallel} today (I'm going to say only wasi-threads from now on but I mean both). There's a lot of things even here that need implementing/deciding such as:

How are existing WASI hostcalls synchronized?
How is a Store<T> created on the new thread?
How does the new thread acquire a Module to instantiate?
How does the new thread acquire a Linker<T> to create a new instance on this thread?

This is all just the bare bones of getting anything working, but should hopefully provide valuable implementation feedback to Wasmtime, the component model, and the wasi-threads proposal. All of this is likely design work that needs to be done anyway for any eventual formal wasi-threads proposal is the hope.
This local maximum, however, is not immediately compatible with the component model. Some of the fundamental abstractions here, such as importing a shared linear memory, do not work the same way in the component model (components can't import a linear memory). This means that this stage does not have access to host APIs defined by the component model, such as a hypothetical wasi-snapshot-preview2.
Stage 2
This stage is intended to be sequenced after the prior stage with the goal of hooking up component-model-level host definitions into a core wasm module that wants to use threads. As a base assumption the idea here is that the user-supplied "thing" is still a core wasm module. The high-level idea is that host-defined component-model definitions are "automatically lowered" into the corresponding core wasm functions to get imported into a core wasm module.
This sort of means that a wasmtime::Linker could be blended with a wasmtime::component::Linker to instantiate a wasmtime::Module. The thinking is that the work from stage 1, probably mostly present in a wasmtime::Linker, could pull in definitions from a wasmtime::component::Linker to get access to all host APIs while still retaining access to the abstraction layer of threads.
The main body of work in this stage would be to figure out how to robustly take a component-model level API and translate it into a core wasm API. This is roughly already done with the canonical ABI but I personally believe there's a lot of fiddly bits to work out such as how to reuse the lifting/lowering in Wasmtime without duplicating it. For example somehow a VMContext and a VMComponentContext need to be bridged between one another or ... something like that.
In discussing this though we wondered but weren't sure of how important such feature would be for migrating from wasi preview1 to preview2. There will, for a long time, be binaries that import wasi_snapshot_preview1 and there's a number of strategies to load that into a preview2-supporting runtime, but something it might be quite useful to allow merging of newly-defined and implemented APIs into older modules.
The downside of this stage is that there still isn't full integration with the component model. Everything is still working at the level of abstraction of a core wasm module and inherently continues to be incompatible with components. The main distinction from stage 1 is that component-model-level functionality, which is the presumed path that WASI is going, can still be imported into the module.
Stage 3
The next stage of evolution for support here would be to integrate threads into the component model proposal itself. This is a far-in-the-future vision though where there's a difference between a func and a shared func for example. there's a ton of design questions here that (at least to me) don't have obvious answers. There's quite a lot of design work here not only for core wasm but also the component model. This is the hypothetical end goal of components that support threads, but I'm mostly listing this here for completeness as the timescale for implementing this in in the many-numbers-of-years.

Given the possible staging here I concluded that my original stance of "we probably don't want to merge this" is no longer true. The staging here would explicitly continue to work at the core wasm layer and not the component layer. Furthermore for the time  being there would be no path forward to implement this in the component layer but there would be a path to taking some of the major benefits of the component layer and bringing them to core wasm. I'd revise my previous stance, then, to it's ok to merge this into the main Wasmtime repository along the lines of all other WASI proposals.
That's not to discount the technical review here, however. This is an example of a fundamental issue in wiggle which will need to get ironed out before landing. Furthermore I personally at least feel that wasi-parallel may not be a best fit for the first proposal implemented here (the kernel feels a bit odd, it's JIT compiled so doesn't work with AOT compilation, the kernel itself can't import anything useful, unclear how toolchains will produce this kernel from "real" source code, etc). @abrown what would you think of implementing wasi-threads first? That feels like a more low-level proposal which would, for now at least, subsume the functionality implemented here for wasi-parallel I think?

Thanks @alexcrichton for the detailed write-up; I think it's a pretty accurate reflection of what we discussed and a decent high-level vision for how to move forward. I agree that wasi-threads is a more foundational proposal and, actually, I think it highlights some of the issues to overcome to get to stage 1 better than wasi-parallel does. wasi-parallel side steps a few things with its "bag of bytes" paradigm. I'll see if there's a way to get wasi-threads done first.
The current issues to get to stage 1 that @alexcrichton describes above are many and span multiple repositories (this one, wasi-libc, LLVM, Rust, etc.). For anyone else interested in progress on getting wasi-threads to the stage 1, this Zulip channel has the latest discussion. @haraldh has taken some of the pieces I and others have been working and has a working PoC! I will post my take on the remaining items to upstream, probably in an issue on the wasi-threads spec repository.

I'm going to close this as this is a pretty old PR at this point and efforts have shifted significantly in the intervening two years. Nowadays most things are happening around "shared-everything-threads" which is the most likely path forward I think. If others disagree though I'm happy to reopen.

authors: abrown alexcrichton lukewagner mingqiusun penzn sunfishcode


text:
Refactor Dictionary Page and Data Page Zero Copy Release

This commit is to use Drop trait to control the releasing of both zero copied Dictionary Page and Data Page.

 Thank you for your submission! We really appreciate it. Like many open source projects, we ask that you sign our Contributor License Agreement before we can accept your contribution.You have signed the CLA already but the status is still pending? Let us recheck it.

authors: CLAassistant liushengxuan

repo: bytedance/bolt-parquet-reader


text:
hotfix/parking

This change is

Reviewed 2 of 2 files at r1.
Review status: all files reviewed at latest revision, 1 unresolved discussion.

byuSuite/Apps/Parking/controller/AddVehicleViewController.m, line 111 at r1 (raw file):

	textField.text = [textField.text stringByReplacingCharactersInRange:range withString:[string uppercaseString]];
    //Remove all spaces from user input for license plates
    if (textField == [self getTextFieldForRow:LICENSE_FIELD_INDEX]) {

Models shouldn't have to have upper case letter either. And they should be able to have special characters... Could you test those?

Comments from Reviewable

Review status: 1 of 3 files reviewed at latest revision, 1 unresolved discussion.

byuSuite/Apps/Parking/controller/AddVehicleViewController.m, line 111 at r1 (raw file):
Previously, romrell4 (Eric Romrell) wrote…
Models shouldn't have to have upper case letter either. And they should be able to have special characters... Could you test those?

Done.

Comments from Reviewable

Reviewed 2 of 2 files at r2, 1 of 1 files at r3.
Review status: all files reviewed at latest revision, all discussions resolved.

Comments from Reviewable

repo: byu-oit-appdev/ios-byuSuite


text:
Read Only & Required properties are improperly handled.

According to the OpenAPI Specification "If the property is marked as readOnly being true and is in the required list, the required will take effect on the response only". However, error are being thrown if a required, read only property is missing from the request body.
The current work around is not marking a property as required, but that work around changes the API contract and can make it harder to integrate with APIs.
Example Schema:
Pet:
  type: object
  required:
    - id
    - name
  properties:
    id:
      type: string
      readOnly: true
    name:
      type: string

Request (should work, but throws error):
{
  "name": "Bobby"
}

This has been fixed and published to npm as version 1.12.6.

This has been fixed and published to npm as version 1.12.6.

repo: byu-oit/openapi-enforcer


text:
🛑 Wodemo的一楼 is down

In 918ce42, Wodemo的一楼 (https://bywhite.wodemo.net) was down:

HTTP code: 0
Response time: 0 ms

Resolved: Wodemo的一楼 is back up in 7140873.


text:
Add notes functionality

Description
To extend user experience please add ability to add notes to a contact
User should be able to add more than one note
User should be able to change or remove note
Add new Field Note to a fields
Extend Record class with note attribute (type Note), add new methods to add, change and remove
Extend AddressBook class with new method to add, change and remove notes
Extend main.py - add command to add, change and remove notes, and extend help
Commands example:
> add-note bob
> input note: Bob is a good person
> change-note bob
$ current note:  Bob is a good person
> input note: Bob is a very good person
> note bob
$ Bob is a very good person
> delete-note bob
$ Done, note for a bob is deleted

Comment from mentor

repo: byymster/telium


text:
🛑 byzocker.de is down

In d391bf7, byzocker.de (https://byzocker.de) was down:

HTTP code: 0
Response time: 0 ms

Resolved: byzocker.de is back up in 44e632c.

Resolved: byzocker.de is back up in 44e632c.


text:
Sync using shared (not published) link

This would be a great feature for syncing without it having to be published on the web  :-)

I'm don't sure I understand the motivation for using the share link instead of the published one. Maybe if you could expand upon it
The main issue is that the html format for a shared page is a lot more complicated then the published page. I also think it would have to be a public link anyway

Hi Conor,
I thought that this might be the case but thought I would ask anyway  :-)
I am thinking along the lines of having an option for private flashcards is all.  This would mostly be for flashcards containing sensitive information that they do not want published to the web.

Hey ohn8,
So the really issue is that you would like a way to have a private doc that you can share between a small group?
I doubt  that the public pages are indexed but very hard to know tbh.
The probably solution would be to allow some kind of download from the normal edit page and allow you to manually sync with that?

Hi Connor,
I can't speak for others but in my case I couldn't see a need to share the doc.
If what you described is possible it sounds like that would be a good solution  ;-)

Hey,
So the main reason for sharing the document it that you have a publicly accessible link that you can scrape from. I don't think the link is index so it probably is quite hard to find without someone specifically sharing it with you.
If you are more just thinking of something that is all local then I have another add-on https://ankiweb.net/shared/info/1029306148 that might be a better fit to your usecase?

So I have a development plan for half tested but it will be a while until I can get around to completing it unfortunately.
I will update the issue once I have started working on it though

repo: c-okelly/anki-remote-decks


text:
mdview update

Fix table rendering
Style for table

Few things to note,
Images like the one in storage/architecture go beyond the width, even though it has max-width:100%, and if given max-width:* it will not render.
If the theme was changed then a user navigate back (with arrow) the old document still has text in the old theme color.
print/style.css, no such file, I changed it to print/print.css, don't see why you would need it anyway, since it's linked to frame|pager.

mdview update

render HTML
scroll #Elements into view

There is one issue Element.scrollIntoView(true) scroll element to bottom, in fact it scrolls to bottom no matter the options.
behavior: "smooth" does work though.

repo: c-smile/sciter-js-sdk


text:
🛑 www.zisk.eu is down

In 5d99ecc, www.zisk.eu (https://www.zisk.eu/sk/Home.alej) was down:

HTTP code: 403
Response time: 804 ms

Resolved: www.zisk.eu is back up in ddea198.


text:
🛑 cms2.alejtech.eu is down

In 6d4bce6, cms2.alejtech.eu (http://cms2.alejtech.eu/UserSystem/login/login.alej) was down:

HTTP code: 403
Response time: 502 ms

Resolved: cms2.alejtech.eu is back up in 265cc82.