Website global search feature

Description
This PR implements the website global search feature outlined in this GitHub issue. It added a fully functional search bar powered by DocSearch, capable of searching across all site in any version, located on the right side of main Nav bar with a drop down menu attached that contains all available version options.
Checklist
Essentials

[x] Changes are complete (i.e. I finished coding on this PR)
[x] Code is well-documented
[x] To the best of my knowledge, examples are either not affected by this change, or have been fixed to be compatible with this change

Changes
M docs/static_site/src/_includes/head.html
M docs/static_site/src/_includes/header.html
M  docs/static_site/src/assets/main.scss
M docs/static_site/src/_sass/minima/_layout.scss
Add docs/static_site/src/assets/img/search-icon.svg
Add docs/static_site/src/assets/js/globalSearch.js
Add docs/static_site/src/_sass/globalSearch.scss
Comments

Preview link<EMAIL_ADDRESS>Please note the preview only has global search on master version, in production 1.6 will also be supported
This PR is ready to merge

@mxnet-label-bot add pr-work-in-progress

Search feature looks great.
Nice to see we leveraging third-party to solve our search problem.
Q1. This feature is currently only for landing page right?
It isn't available on other pages right?
For e.g. not available in Python API > NDArray page right?
http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/api/python/docs/api/ndarray/index.html
Can we document this point. And also add this functionality to rest of the pages in upcoming PRs?
Q2
When I search for copyto in 1.6 version on a laptop browser
It navigates to  https://mxnet.apache.org/versions/1.6/api/python/docs/api/ndarray/ndarray.html?astype=#ndarray
Isn't it supposed to go to the copyto operator specifically instead of the head of the div [ndarray]

Search feature looks great.
Nice to see we leveraging third-party to solve our search problem.
Q1. This feature is currently only for landing page right?
It isn't available on other pages right?
For e.g. not available in Python API > NDArray page right?
http://ec2-34-219-134-42.us-west-2.compute.amazonaws.com/api/python/docs/api/ndarray/index.html
Can we document this point. And also add this functionality to rest of the pages in upcoming PRs?
Q2 Is search suggestion pointing to the correct place?
When I search for copyto in 1.6 version on a laptop browser
It navigates to https://mxnet.apache.org/versions/1.6/api/python/docs/api/ndarray/ndarray.html?astype=#ndarray
Isn't it supposed to go to the copyto operator specifically instead of the head of the div [ndarray]

Thank you for reviewing! Good questions.
Q1: Yes, it is available on all landing pages (that don't have a search bar currently), and not on any of the API docs pages. The reason is that while there is already a search bar on all API docs pages, in my opinion adding another one can confuse users. Here is an example, I think 1 search bar per page looks clear.
Q2: Good point. This is related to improvement of search result, I am currently working on these issues. It is mainly about how we configure the web crawler to grab data from our website, and it does not require any code changes to MXNet website.

Looks good.

Should we use offsite js files or host locally?
Should the API key be in a js file are can it be in a config file so we keep this stuff in someplace central?
Wonder if we could have the list of versions also in a config file and not in .js, so it is more obvious and easier to maintain... then other parts of the site like the install selector or other things that need the list of versions can share?

Just some thoughts... otherwise this looks good to me.
Good work!

Should we use offsite js files or host locally?

Based on the research, the CDN works pretty well in China. I will keep an eye on it, if there is problem loading this file in some country, I will switch to host the file locally.

Should the API key be in a js file are can it be in a config file so we keep this stuff in someplace central?

Thanks for the suggestion. I will move API key to Jekyll config file

Wonder if we could have the list of versions also in a config file and not in .js, so it is more obvious and easier to maintain... then other parts of the site like the install selector or other things that need the list of versions can share?

Great idea, let me remove it from JS and set these common variables as Jekyll global var

@mxnet-bot run ci [unix-cpu]

@szha / @leezu - FYI.

Very nice. Thank you @ys2843 This will be very helpful for the community.
Please update the release manager checklist for changing the defaults.
Should we change anything with algolia (like default version) whenever there is a new release?
Also, for updating the search results, what is the process? What do you mean by improving the search result.
Overall, this is really nice improvement for easily finding the content. Thank you.

Thank you for reviewing. Will update the release manager checklist.

Should we change anything with algolia (like default version) whenever there is a new release?

No, we don't need any change from algolia. We only need to update website code to set the default version. I will document this part.

Also, for updating the search results, what is the process? What do you mean by improving the search result.

To make the search result more relevant and accurate, the process is to update the configuration of DocSearch's web crawler.
Currently the config is not ideal, and the best way to update and test the config is to run the web crawler locally. I have set up the crawler on an ec2 and run it with new config, and then make adjustment according to the result from the crawler.

@mxnet-bot run ci [unix-cpu]

@mxnet-bot run ci [unix-cpu]

@mxnet-bot run ci [unix-cpu]

@mxnet-label-bot add [website]

Thank you!
Is it intended that the search queries entered while on the master version of the website yield results on 1.6 branch? I think it's better to be consistent
What's the plan to add the search button on other parts of the page besides the index page?

Thanks for the feedback!
Is it intended that the search queries entered while on the master version of the website yield results on 1.6 branch? I think it's better to be consistent

The search UI is consistent across all pages. There is a version select drop down on the right side of the search input field. It is currently set to 1.6 by default and the search results are only relevant to that version.

What's the plan to add the search button on other parts of the page besides the index page?

This feature is added to all information pages (tutorials, blogs, ecosystem, FAQ etc) on version master and 1.6 website. Not planned to add it to API pages while there is already a search bar on those pages.

Should the version dropdown been made consistent with the global version dropdown? Or at least default to the same version number as used in the global version dropdown?

Not planned to add it to API pages while there is already a search bar on those pages.

Should we replace that search bar? It seems your search implementation is superior?

Should the version dropdown been made consistent with the global version dropdown? I mean at least default to the same version number as used in the global version dropdown?

Not planned to add it to API pages while there is already a search bar on those pages.

Should we replace that search bar? It seems your search implementation is superior?

Good point, I will make the default version the same as the dropdown version.
There is plan to improve the search bar in API sites, but that wasn't discussed in this project. For this project the objective is to add search for main site.

@mxnet-bot run ci [unix-cpu, website]


chore(datasets): Revert spark pin back to 4.0

Description

Revert spark pin.
Development notes

Checklist

[ ] Opened this PR as a 'Draft Pull Request' if it is work-in-progress
[ ] Updated the documentation to reflect the code changes
[ ] Added a description of this change in the relevant RELEASE.md file
[ ] Added tests to cover my changes

Sphinx docs are broken because we shuffled around the data catalog docs, see https://github.com/kedro-org/kedro/pull/2966/commits/48677866115ba1ce1b1cf56e939232a6afc0eaec


WARN  |  PaymentKit/PaymentKit/PTKTextField.h:25:54: warning: auto property synthesis will not synthesize property 'delegate'; it will be implemented by its superclass, use @dynamic to acknowledge intention [-Wobjc-property-synthesis]

Hi,
I am trying to update my Pod & I cannot get my podspec to validate.
Podfile
platform :ios, '6.1'
pod 'Stripe'
pod 'Stripe/ApplePay'
pod 'ApplePayStubs', :git => 'https://github.com/stripe/ApplePayStubs.git'
pod 'PaymentKit', :git => 'https://github.com/stripe/PaymentKit.git'
podspec:
Pod::Spec.new do |s|
s.name              = 'paywith-iphone-sdk'
s.version           = '1.0.12'
s.summary           = 'PayWith SDK'

s.platform     = :ios, '6.1'
s.homepage          = 'http://paywith.com'
s.license           = {
:type => 'BSD',
:file => 'LICENSE'
}
s.author            = {
'YOURNAME' =><EMAIL_ADDRESS>}
s.source            = {
:git => 'https://github.com/Wantsa/paywithsdk-ios-pod-source.git',
:tag => s.version.to_s
}
s.resources = 'PayWithSDK.framework/PWResources/'
s.public_header_files    = 'PayWithSDK.framework/Headers/.h'
s.source_files = 'PayWithSDK.framework/Headers/*.h'
s.vendored_frameworks = 'PayWithSDK.framework'
s.frameworks = 'AVFoundation'
s.dependency 'AFNetworking'
s.dependency 'Stripe'
s.dependency 'Stripe/ApplePay'
s.dependency 'ApplePayStubs'
s.dependency 'PaymentKit'
s.dependency 'CardIO'
s.requires_arc      = true
end
Pod::Spec.new do |s|
s.name              = 'paywith-iphone-sdk'
s.version           = '1.0.12'
s.summary           = 'PayWith SDK'

s.platform     = :ios, '6.1'
s.homepage          = 'http://paywith.com'
s.license           = {
:type => 'BSD',
:file => 'LICENSE'
}
s.author            = {
'YOURNAME' =><EMAIL_ADDRESS>}
s.source            = {
:git => 'https://github.com/Wantsa/paywithsdk-ios-pod-source.git',
:tag => s.version.to_s
}
s.resources = 'PayWithSDK.framework/PWResources/'
s.public_header_files    = 'PayWithSDK.framework/Headers/.h'
s.source_files = 'PayWithSDK.framework/Headers/*.h'
s.vendored_frameworks = 'PayWithSDK.framework'
s.frameworks = 'AVFoundation'
s.dependency 'AFNetworking'
s.dependency 'Stripe'
s.dependency 'Stripe/ApplePay'
s.dependency 'ApplePayStubs'
s.dependency 'PaymentKit'
s.dependency 'CardIO'
s.requires_arc      = true
end
Warning:
- WARN  |  PaymentKit/PaymentKit/PTKTextField.h:25:54: warning: auto property synthesis will not synthesize property 'delegate'; it will be implemented by its superclass, use @dynamic to acknowledge intention [-Wobjc-property-synthesis]

Hey @fionaom,
This code has moved to https://github.com/stripe/stripe-ios, which now has a class called STPPaymentCardTextField that has similar behavior to PTKView. That class shouldn't suffer from the issue you're describing, so I'd encourage you to migrate (it should take just a few minutes, and we've written a brief guide at https://github.com/stripe/paymentkit#migration). Of course, if that doesn't work for you, or you have any trouble migrating, reply here and I'll be happy to help.
Unrelated, but I'd also strongly suggest removing any references to ApplePayStubs from the podspec you're publishing - that library is meant for testing only, and shouldn't be included in App Store submissions.
Cheers!


Using verify! on a type that does not implement Copy

The borrow checker does not allow this, because the name is moved to the lambda:
const KEYWORDS: [&'static str; 1] = ["yield"];
named!(pub name<StrSpan, String>,
  verify!(
    // a subparser that returns a String
    |name: String| !KEYWORDS.contains(&&name[..])
  )
);

A solution would be change verify! to expect a lambda whose argument is a reference to the value, but that would be a breaking change.
Workaround:
const KEYWORDS: [&'static str; 1] = ["yield"];
named!(pub name<StrSpan, String>,
  do_parse!(
    name: /* the subparser */ >>
    verify!(tag!(""), |_| !KEYWORDS.contains(&&name[..])) >>
    (name)
  )
);

This seems to be a duplicate of #510
But anyway, I made my own input type that is non-copy and i have problems with other combinators...
Maybe an issue about making combinators working with non-copy input would be more generic and a good fit for nom 4.1

Indeed, thanks for the ref. (If no one minds, I'll keep this issue open as a reminder to myself in case I have time to fix it)

I have a different workaround for this. Instead of verify!, I use map! with a function that return Ok(data) on valid data, and Err(_) otherwise,

it is done in 717e7f0595de for the upcoming nom 5, verify will now take a reference in all cases


Setup database user model

Setup database and defined basic user model

Good work :+1: Can merge.


Add incremental MD5 function (feature request)

The suggestion by @stejacob in https://github.com/kikito/md5.lua/issues/4#issuecomment-158112037 would not have fixed the issue reported there, but it is sound. Usual C implementations use md5_init, md5_update and md5_done (the names may vary), where md5_update can be called as often as necessary, and md5_done does the padding and calculates the final result. With Lua, the API can be something that is used like this:
-- this should print the MD5 of "Hello, World!" which is 65a8e27d8879283831b664bd8b7f0ad4
state = md5.new()
state:update("Hello")
state:update(", World!")
result = state:finish()
print(md5.tohex(result))

The advantage is that when the files are long, it's not necessary to send the whole file in one go: it can be calculated on the fly instead (only the last A,B,C,D and up to 63 bytes of buffer are necessary to be kept between calls, thus saving memory). This would allow calculating the MD5 of files larger than those that fit in memory

I am not opposed to this, but the time I have very little time to spare on this project. If someone sends me a pull request I can review it and accept it, but I honestly don't have the time to develop a new feature such as this on my own.

Implemented in #10


Support GETFPREGS and SETFPREGS ptrace calls

Added two new functions to the ptrace module: getfpregs and setfpregs gets and sets the floating point registers of the tracee.

Would it be possible to add a test?

Yes, sure. What kind of test do you have in mind? I see that most ptrace related tests just call ptrace and then check that it doesn't return Error::UnsupportedOperation. Would a similar check be sufficient, or would you like some more thorough testing? (e.g. creating a subprocess, then modify one of the XMM reigsters with setfpregs, and reading it with getfpregs to check that we successfully modified it).

Would it be possible to add a test?

Yes, sure. What kind of test do you have in mind? I see that most ptrace related tests just call ptrace and then check that it doesn't return Error::UnsupportedOperation. Would a similar check be sufficient, or would you like some more thorough testing? (e.g. creating a subprocess, then modify one of the XMM reigsters with setfpregs, and reading it with getfpregs to check that we successfully modified it).

That would be perfect.

Thanks for the very good tests!  As for the test failures, both should be fixed if you rebase your changes onto master.

Looks good, but I forgot one thing: this needs a CHANGELOG entry.  And you can go ahead and squash while you're at it.

Closing in favor of https://github.com/nix-rust/nix/pull/1844


De

VSCode Version: 1.6
OS Version: OSX Sierra

In 1.6 features that allowed using custom runtimes was added. I tried using it to debug my program that is usually started with a grunt script. Although grunt does start, run and execute correctly debugger never gets attached to the process.
Steps to Reproduce:

Setup Grunt Launch config per 1.6 release note.
This is my launch configuration:
{
"name": "Launch via Grunt",
"stopOnEntry": true,
"type": "node",
"request": "launch",
"runtimeExecutable": "grunt",
"cwd": "${workspaceRoot}",
"preLaunchTask": null,
"runtimeArgs": [
"--nolazy",
"run"
],
"env": {
"NODE_ENV": "development"
},
"console": "internalConsole",
"sourceMaps": false,
"outFiles": []
}

Start the process. Program runs and does what it supposed to, but debugger never gets attached. No break points are ever hit. I tried adding "port" argument into configuration but it had no effect.

My old way of doing it still works great. Here is my old launch config:
{
"name": "Launch via Node",
"stopOnEntry": false,
"type": "node",
"request": "launch",
"program": "${workspaceRoot}/node_modules/grunt/bin/grunt",
"args": ["run"],
"cwd": "${workspaceRoot}",
"preLaunchTask": null,
"runtimeExecutable": null,
"runtimeArgs": [
"--nolazy"
],
"env": {
"NODE_ENV": "development"
},
"console": "internalConsole",
"sourceMaps": false,
"outFiles": []
}

@GlacianNex with your "Launch via Grunt" configuration VS Code will run grunt like this:
grunt --debug-brk=12345 --nolazy run

I don't think that this makes any sense. Does grunt accept a '--debug-brk' or '--nolazy' argument? I don't think so.
Please use the correct grunt arguments to run grunt in debug mode and specify a port.
And BTW, why are you using a new approach to run grunt in debug mode if you already have found a good way to do this?


fix(api-key): add password requirement to generate api key [EE-6140]

EE-6140

Hi @jamest-portainer  and @hookenz :)  i know this issue is already closed, but instead of creating a new one, perhaps a more suitable place to ask is here :
due to the user's password being reequired when creating access tokens(api-keys) what does this mean for Oauth users, it is my understanding that when linking portainer to your Oauth provider, it  will bring over the user accounts from the Oauth provider to portainer, as described here : https://docs.portainer.io/v/2.20/admin/settings/authentication/oauth - under "automatic user provisioning"
hence my user id - bob and password: bobspassword (set at the time of the linking of the oauth provider) becomes the password for bob inside portainer which will then be used to create an access token for bob - however does this password get updated in portainer when it changes on the oauth provider end ? - i.e bob's password changes to bobsnewpassword
and if it does not, what is the password that is required to create access tokens for bob - will it be the password at the time of linking the oauth provider to portainer i.e bobspassword ? or will it be whatever the current password of bob is on the oauth provider's end i.e bobsnewpassword ?
thanks :)

@Shailen31, the password requirement when generating an API token was introduced but a mistake was made where it incorrectly prompts for the password when external authentication (such as OAuth) is in use. Actually, we do not want it to require the password in that case. This has been fixed in 2.20.2, so if you can upgrade to that version you'll be ok.
I assume you're on 2.20.0 (when the original change was introduced) or 2.20.1.

@jamest-portainer thanks for your response, I can confirm I am using v2.20.1 - will upgrade, thanks

Great stuff @Shailen31. Apologies for the misstep on our part!


Node socket.io. websocket: RSV1 set, FIN not set on control

Hello, I trying to connect to socket.io server on node js with express, but I catch error new reader: websocket: RSV1 set, FIN not set on control. What could be the problem here?
I used client code from example and this code for starting node server
import express from "express";
import http from "http";
import {Server} from "socket.io";

const app = express();
const server = http.createServer(app);
const io = new Server(server, {cors: {origin: '*'}});

io.on("connection", (socket) => {
    console.info(`connect ${socket.id}`);

    socket.on("ping", (status) => {
        socket.emit("pong");
    });

    socket.emit("hello");
});

server.listen(3000, () => {
    console.log('listening on *:3000');
});

Thank you so match!

Running into the same issue here, I'm guessing the client code is just buggy

One solution here is to request V4 (in my case, it was returning the error "Unsupported version", so you can use the query parameters ?EIO=4&transport=websocket since in theory V3 is still compatible with V4


Add a virtual cluster stat for when a downstream stream termination occurs

Description:
Add a virtual cluster stat that's emitted when a downstream stream is terminated before a given stream (request) completes. This is important from the perspective of Envoy Mobile and mobile clients in general. In mobile environment it a request - an Envoy downstream stream - can be started and terminated soon after (before the stream has a chance to finish) as a result of certain user's interaction in the mobile app.
Currently, virtual cluster's stats do not capture information about the termination of such request. When a request starts, upstream_rq_total stat is incremented but there is not corresponding "request completion" stat that gets incremented when a downstream stream is terminated.
Some of the ideas for the proposed stat name (ordered list):

upstream_rq_dropped
upstream_rq_destroyed
upstream_rq_canceled

Relevant Links:
The list of currently available virtual cluster stats can be found at https://www.envoyproxy.io/docs/envoy/latest/configuration/http/http_filters/router_filter#virtual-clusters.

cc @jmarantz


fix(add): Ensure users know a feature is being created

Inspired by #13430 and #13411

:pushpin: Commit 877b8e4cf6a1c3bd631adbf26408ec59a2446349 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit 877b8e4cf6a1c3bd631adbf26408ec59a2446349 with merge 53b5a5811309a97566f1b46939895fc9099bbed5...

:broken_heart: Test failed - checks-actions

@bors r=weihanglo

:pushpin: Commit dbdebc378a5f77e346e01c4d9dd14ab9ef870a76 has been approved by weihanglo
It is now in the queue for this repository.

:hourglass: Testing commit dbdebc378a5f77e346e01c4d9dd14ab9ef870a76 with merge 30addeaa9028b28b533f29636a9705c4ac834afe...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 30addeaa9028b28b533f29636a9705c4ac834afe to master...

:sunny: Test successful - checks-actions
Approved by: weihanglo
Pushing 30addeaa9028b28b533f29636a9705c4ac834afe to master...

:eyes: Test was successful, but fast-forwarding failed: 422 Changes must be made through a pull request.


Add warrior score next to its health when printing the play log

It could be a good addition to see the current score of the warrior in the play log. Example:
--------------------------------------- turn 005 ---------------------------------------
♥ 14
⬥ 0
╔════════╗
║   @s  >║
╚════════╝
> Spartacus attacks forward and hits Sludge
> Sludge takes 5 damage, 2 health power left
> Sludge attacks forward and hits Spartacus
> Spartacus takes 3 damage, 14 health power left
--------------------------------------- turn 006 ---------------------------------------
♥ 14
⬥ 12
╔════════╗
║   @   >║
╚════════╝
> Spartacus attacks forward and hits Sludge
> Sludge takes 5 damage, 0 health power left
> Sludge dies
> Spartacus earns 12 points
--------------------------------------- turn 007 ---------------------------------------
♥ 14
⬥ 12
╔════════╗
║    @  >║
╚════════╝
> Spartacus walks forward

To make that possible, the core will need to include the unit's score along with the currently included fields.

What color would you like the score line to be?

Bright Yellow looks good to me.

I like it! My only concern is that it looks like if it was more important than the health... Maybe regular yellow, or making the health bright red?

Regular yellow is already being used, see the captive being unbound. Figured you wanted to have as many elements uniquely coloured.

Having the health bright red should be better, I'll make the PR tomorrow.

The bright red looks perfect.

I only added score to the .toJSON() method of the Warrior, since - for now at least - only the Warrior needs it's score at the moment.

I think the only documentation that needs updating due to the change is the Preview .gif. on the README.md
If you could tell me what color scheme is being used, I can update it. (I'm also a user of VSCode)
Or, another issue could be created to have the .gif updated at a later date, up to you.

Thanks @RascalTwo!

I think the only documentation that needs updating due to the change is the Preview .gif. on the README.md

Good call. Don't worry about it, I will update it later! (The color scheme is Nord, if you're still curious.)

@RascalTwo I'm going to update the GIF later, but I already added a screenshot to the homepage that shows your change!


Remove tensorflow from the supported runtimes in OOTB Serving Runtimes

Description

Based on the outcome of https://issues.redhat.com/browse/RHODS-8874 it seems that ovms is not supporting tensorflow as previously suggested.
Removing the runtime selection for the OOTB models.
How Has This Been Tested?

Deploy the runtimes with oc apply -k odh-dashboard/modelserving
Deploy a new model
Select OOTB Serving Runtime
Check that the Serving Runtime doesn't include tensorflow

@lugi0 I haven't tested the upgrade, I'll try to do it on Monday, I'm working in other things.
Merge criteria:

[X] The commits are squashed in a cohesive manner and have meaningful messages.
[ ] For commits that came from upstream, [UPSTREAM] has been prepended to the commit message.
[ ] JIRA link(s):
[ ] The Jira story is acked.
[ ] Live build image:
[X] Testing instructions have been added in the PR body (for PRs involving changes that are not immediately obvious).
[X] The developer has manually tested the changes and verified that the changes work.
[ ] QE contact acknowledges that this has been tested and is approved for merge.

We did eventually find the model that was working with TF support, https://storage.googleapis.com/download.tensorflow.org/models/tflite/model_zoo/upload_20180427/inception_resnet_v2_2018_04_27.tgz
That being said, it does seem compatibility for TF is very narrow, maybe we should list it as tech preview or something in the UI instead

I'm gonna close this PR then, we don't have the ability to mark runtimes with labels, but it should be a good idea, I'm gonna ask Jeff if that's something we might wanna be interested in.


[TypeScript 2] Relative paths in typeRoots not resolved (tsconfig.json)

Hi,
I'm having trouble with type definitions being picked up using TypeScript 2/atom-typescript when the tsconfig.json is not in the same directory as node_modules. I have a src folder containing tsconfig.json, refrencing ../node_modules/@types in the typeRoots, and a Jasmine test in src/app. atom-typescript does not pick up the Jasmine declarations (e.g. describe, it etc) and highlights them as errors.
My folder structure is as follows (some folders removed):
- node_modules
-- @types
- src
-- tsconfig.json
-- app
--- app.component.spec.ts
--- app.component.ts

My tsconfig.json in src is as follows:
{
  "compilerOptions": {
    "declaration": false,
    "emitDecoratorMetadata": true,
    "experimentalDecorators": true,
    "lib": ["es6", "dom"],
    "mapRoot": "./",
    "module": "es6",
    "moduleResolution": "node",
    "outDir": "../dist/out-tsc",
    "sourceMap": true,
    "target": "es5",
    "typeRoots": [
      "../node_modules/@types"
    ],
    "types": [
      "jasmine"
    ]
  }
}

app.component.spec.ts:
import { AppComponent } from './app.component';

describe('Example', () => {
  beforeEach(() => {
    // Stuff
  });

  it('should create the app', () => {
    expect(true).toBeTruthy();
  });
});

Environment info:
OS: OS X El Capitan 10.11.6
Node.js: 6.3.1
Typescript: 2.0.0
Atom: 1.9.8
atom-typescript: 10.1.6
This configuration works with tsc on the command line (either tsc -p src in the project root, or tsc -p . in src). It also works in atom-typescript if I put the entire path in typeRoots - e.g. /Users/sean/someProject/node_modules/@types - which makes me think that this is an atom-typescript specific issue in resolving relative paths.
Is this a bug or just something I'm doing wrong with my config?

Yes, I confirm it.
Environment info:
OS: Debian x64 stretch
Node.js: 5.11.0
Typescript: 2.1.0-dev.20160812
Atom: 1.5.3
atom-typescript: 10.1.6

Also seeing the same thing. OSX, node v 5.1

Same thing here, none of the jasmine types are resolved.
I confirm it's working when typeRoots is set to the absolute path to node_modules/@types (with jasmine listed in types) in the tsconfig.json.
OS : Fedora 24
Node v6.6.0
NPM 3.10.3
Atom 1.9.9
atom-typescript 10.1.6

similar problem with angular2-seed project (mgechev/angular2-seed).
type core-js not recognized by atom typescript.
defined in src/client/tsconfig.json with
    "typeRoots": [
      "../../node_modules/@types",
      "../../node_modules"
    ],
    "types": [
      "core-js",
      ...

Array.from or Object.assign etc. is not recognized when used.
if I replace the the relative path in typeRoots with absolute path, it works.
OS: Windows 7
Node: 5.6.0
NPM: 3.10.8
Atom: 1.10.2
atom-typescript: 10.1.7

Having the same problem with jasmine, but in VSCode. I don't know if ts plugin for VSCode and for atom are related, but looks suspicious...

Same issue here. To fix this as a hack until plugin is changed, I pulled in the node_modules/@types directory to be direct relative to the tsconfig.json file. Looking at the source code for the atom package, there is a default typeRoots path that is always set in relation to the read tsconfig file. I wonder if this is the issue as it does not get overwritten.
Seems dirty, but works and the Angular-cli project I am running does not care as it still looks to the node_modules directory outside the src directory.

Looks like this is the same issue I'm facing right now.
Excluding node_modules due to performance issues results in compiler errors within atom-typescript only.
In the screenshot you can see that<EMAIL_ADDRESS>as well as<EMAIL_ADDRESS>compile the same code without any problems (as it should be). Browserify with tsify don't throw any errors either.

I think this is definitely a bug - or rather it had been implemented correctly and then the new functionality of TypeScript wasn't accounted for.  PRs definitely accepted.

This works as a temporary solution for me:
  "exclude": [
    "!/node_modules/@types"
  ]

Did not work for me in the angular2-seed project (mgechev/angular-seed) I mentioned.
But the following workaround did it:
in src/client/tsconfig.json  change
    "typeRoots": [
      "../../node_modules/@types",
      "../../node_modules"
    ],
    "types": [
      "core-js",
      ...

to
    "baseUrl": "../../",
    "typeRoots": [
      "node_modules/@types",
      "node_modules"
    ],
    "types": [
      "core-js",
      ...

+1

+1

Using include instead of exclude is working too:
{
    "compilerOptions": {
        "target": "es5",
        "module": "commonjs",
        "moduleResolution": "node",
        "sourceMap": true,
        "emitDecoratorMetadata": true,
        "experimentalDecorators": true,
        "removeComments": false,
        "noImplicitAny": false,
        "typeRoots": [
            "node_modules/@types"
        ],
        "types": [
            "jasmine",
            "node",
            "core-js",
            "selenium-webdriver"
        ]
    },
    "include": [
        "src/**/*.ts",
        "node_modules/@types"
    ],
    "atom": {
        "rewriteTsconfig": false
    }
}

Why was this closed when the issue has not been resolved?

@Shijir I can confirm removing the exclude array fixed it for me. Thanks.


[Event Modification] Codeunit 23 Item Jnl.-Post Batch - OnBeforeCheckLines

Hi, would it be possible to modify the event OnBeforeCheckLines in codeunit 23, procedure CheckLines, to add WindowsIsOpen parameter like this :
    local procedure CheckLines(var ItemJnlLine: Record "Item Journal Line")
    begin
        OnBeforeCheckLines(ItemJnlLine, WindowIsOpen );

        with ItemJnlLine do begin
            LineCount := 0;
            StartLineNo := "Line No.";
            repeat
                LineCount := LineCount + 1;
                if WindowIsOpen then
                    Window.Update(2, LineCount);
                CheckRecurringLine(ItemJnlLine);

    [IntegrationEvent(false, false)]
    local procedure OnBeforeCheckLines(var ItemJnlLine: Record "Item Journal Line", var WindowIsOpen: Boolean)
    begin
    end;

thanks

Thanks for reporting this. We agree, and we’ll publish a fix asap, either in an update for the current version or in the next major release. Please do not reply to this, as we do not monitor closed issues. If you have follow-up questions or requests, please create a new issue where you reference this one.


Endless loop when trying to create a new node

I have an issue that seem to be related to the types plugin. My tree works fine, but as soon as I enable types and try to  create a new node on a node that has children, jstree runs into an endless loop.
Here's a jsfiddle: http://jsfiddle.net/mike_haertl/yh08vyoz/
Try to right click on "id: 24 test" and then "Create".
I found that it never leaves the do {...} while() here: https://github.com/vakata/jstree/blob/a0767ceb3fffe1c0b2774d28c811116892a071b8/src/jstree.types.js#L165
Am I doing something wrong or is this a bug?

Your data is wrong - here is the corrected fiddle: http://jsfiddle.net/yh08vyoz/14/
When jstree wants the children of c24 - return just that - the children, not the whole node and its children. What you were doing caused a second node with the same c24 ID to be added to the structure, which basically brakes the tree, as there can not be two nodes within the same tree with the same ID.
Best regards,
Ivan

Alright, thanks.


Add default_action param for rule-group

Hi! Cool module, but we need this also in the rule-group, could you add it? (Just dynamic default_action) and new variable)
╷
│ Error: Unsupported argument
│
│   on ../../modules/waf/rulegroup/main.tf line 9, in module "this":
│    9:   default_action = var.default_action
│
│ An argument named "default_action" is not expected here.
╵

Hello 👋
According to the link below, it appears that the rule group module does not support 'default_action', is this still a problem?

https://registry.terraform.io/providers/hashicorp/aws/latest/docs/resources/wafv2_rule_group


Sema: Simplify AST representation of key path literals as functions.

Previously, we would turn a key path literal like \.foo in function type context into a double-wrapped closure like this:
  foo(\.x) // before type checking
  foo({ $kp$ in { $0[$kp$] } }(\.x)) // after type checking

in order to preserve the evaluation semantics of the key path literal. This works but leads to some awkward raw SIL generated out of SILGen which misses out on various SILGen peepholes and requires a fair number of passes to clean up. The semantics can still be preserved with a single layer of closure, by using a capture list:
  foo({[$kp$ = \.x] in $0[$kp$] }) // after type checking

which generates better natural code out of SILGen, and is also (IMO) easier to understand on human inspection.
Changing the AST representation did lead to a change in code generation that interfered with the efficacy of CapturePropagation of key path literals; for key path literals used as nonescaping closures, a mark_dependence of the nonescaping function value on the key path was left behind, leaving the key path object alive. The dependence is severed by the specialization done in the pass, so update the pass to eliminate the dependence.

@swift-ci Please test

@swift-ci Please test

@swift-ci Please benchmark


There is no way to get rid of instances in the UI

Instances end up accumulating, cluttering, and getting the way.
Ideas that could help:

Provide a mini drop-down menu that allows a user to remove a remote instance. And maybe include a last-seen mini-timestamp somewhere in the UI.
Sort the instances: make the most recently seen online instances appear at the top
When there is more one instance, for the least seen instance that hasn't been seen for more than a week (make the timeout configurable), we could either:

automatically remove it
show something in the UI that prompt the user if they want to remove it

Instance of what?  Do you have a screenshot?

automatically removing instances might seem buggy to users.
Drop down menu would be useful, @zahoriea could be related to #874

We could also hide instances if they have not signed online in some time
frame, but not actually delete them.  Then if they ever appear online again
they could reappear in the buddylist with the same permissions as before.
On Tue Feb 10 2015 at 12:22:55 PM salomegeo<EMAIL_ADDRESS>wrote:

automatically removing instances might seem buggy to users.
Drop down menu would be useful, @zahoriea https://github.com/zahoriea
could be related to #874 https://github.com/uProxy/uproxy/issues/874
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/878#issuecomment-73753327.

I'm a big fan of hiding them, as @dborkan suggests

Then how do I remove privileges from someone I haven't seen recently?
On Thu, Feb 26, 2015 at 1:03 PM, Izzie Zahorian<EMAIL_ADDRESS>wrote:

I'm a big fan of hiding them, as @dborkan https://github.com/dborkan
suggests
—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/878#issuecomment-76230738.

Just to be clear, we're talking about devices not users, right? (instance = device)
At a high level, I find it strange that permissions currently exist at a device level rather than at a user level. If you want to revoke access, it's likelier you will want to revoke access from a person and all of their devices, rather than just one of a person's devices.
I propose that if a user is offline, you should still be able to see them on the UI and revoke access from them. When you revoke access, you revoke access from all of their devices. If a device is offline, it does not appear on the UI. If a device is online, you see it and can choose which you'd like to start proxying from.
To answer @bemasc's question more directly, I don't think it's a common use case to want to remove privileges on a specific device you haven't seen recently. I think it's more common to not want to see it in the UI.

I completely agree that permission should be per-user, not per-device.  I don't think we can really fix this without fixing that first.

If someone has an idea for how to support user-level consent, let's write it up as a design proposal (I've love to support it!) But at the moment, I don't see how to that without various other bigger challenges (mostly I don't see how to solve the problem of each server instance having it's own consent state; how can a truly distributed system have consensus without communication? With communication you fall into a world of having to do distributed DB/state management which seems like more work than v1).
But I can see how we could provide some reasonable UX for (hiding/managing) old instances. e.g.

provide an 'X' to remove an instance (which I think we should have anyway - I strongly believe that users should be able to revert state changes).
Sort instances by use
Provide a '...' to show more than the 2 most recently seen instances.

On Thu, Feb 26, 2015 at 8:57 PM, iislucas<EMAIL_ADDRESS>wrote:

If someone has an idea for how to support user-level consent, let's write
it up as a design proposal (I've love to support it!)

OK.  https://github.com/uProxy/uproxy/issues/1014

But at the moment, I don't see how to that without various other bigger
challenges (mostly I don't see how to solve the problem of each server
instance having it's own consent state; how can a truly distributed system
have consensus without communication? With communication you fall into a
world of having to do distributed DB/state management which seems like more
work than v1).

You're thinking too hard.  It's trivial.

But I can see how we could provide some reasonable UX for
(hiding/managing) old instances. e.g.

provide an 'X' to remove an instance (which I think we should have
anyway - I strongly believe that users should be able to revert state
changes).
Sort instances by use
Provide a '...' to show more than the 2 most recently seen
instances.

—
Reply to this email directly or view it on GitHub
https://github.com/uProxy/uproxy/issues/878#issuecomment-76317024.

Good point, it's easy if you break the symmetry of give/get as you suggest in https://github.com/uProxy/uproxy/issues/1014
And this would make it safe to throw away old serving instances because there's no security risk that way around. I like it.

Closing as this is not a priority right now


Revert "Fit DenseNet examples to Keras-2"

Reverts farizrahman4u/keras-contrib#53

Please merge this. The changes to DenseNet (such as concatenate are buggy in Keras 2). It is better to keep it at Keras 1 code for now until the bug is fixed.
Also, I cannot push my bugfix for DenseNetFCN until the code is reverted.

@kemaswill Instead of merging this, merge the above PR #55 which includes a revert to Keras 1 api for densenet.py as well as the bugfix

This can be closed, the issues have been fixed via other PRs


[Tree, Repeater]: Fixed some issue in RTL direction

Hi,
Trre
Play icon(glyphicon-play) in both RTL(right to left) and LTR is same shape, also bootstrap not have left direction for glyphicon-play.
In my  opinion using glyphicon-triangle-right instead glyphicon-play for tree is a right choise, because this icon have right/left/up/down direction in bootstrap.
Repeater
Fixed action and frozen columns position in RTL direction

Added new option to repeater-list for set bidi-direction.
name: list_direction
type: string
default: 'ltr'
values: either 'ltr' or 'rtl'

Thanks for the updates. On further review can we adjust the approach to be similar to that of the wizard control introduce with #1161. You'll notice a rtl class was added to .wizard container to drive any necessary changes. This is more consistent with the declarative nature of fuelux.
Please provide a screenshot and codepen of your expected results
For verification it appears what you are attempting to do is...

tree - point the arrow to the left
repeater - swap the select and action columns in repeater

Also because this is regarding two different controls there should be two PRs.

@vernak2539 was the author of #1161. i'd like his feedback as well.

Hey @afz, thanks for the PR. I have a few items on feedback.

Don't mind the change of the icon due to the situation as you explained, but I would argue .glyphicon-chevron-right and .glyphicon-chevron-left are better choices

Or if you keep the play icon, you can just use a CSS transform to rotate it

I think this entire PR (minus HTML changes) could be accomplished purely as a CSS change (please see PR #1161). Creating a .rtl class would allow someone to just add or remove the class and not have to re-instantiate the control to update the text direction.
In your CSS/LESS you will have to add direction: rtl;, if we truly want this to be easy for other to implement

Hi,
about .glyphicon-chevron-left/right, is also OK.
But about repeater-list(action and frozen), when repeater horizontal scrolled, you changed left/right in js file, so there is no way via css to fix this for RTL .

@afz you're correct. It looks good to me then aside from the fact that you'll need to actually add the CSS class that changes the text direction, which I've put in my comment above.

@afz when you are able to implement @vernak2539 class suggestion please let us know and we'll reopen.


Revert "*: initial wire in of crictl from cri-tools"

This reverts commit 49bdd594060c923e4f5254565f6fcbd4838aa9b8.
Want to confirm that this fixes the tests.
cc: @runcom

I'll look into this today, I may have missed something silly as the old PR passed old tests.

Found the cause https://github.com/kubernetes-incubator/cri-tools/pull/123 - I'll update tests and stick to a commit so we won't fail next time (commit was in Dockerfile but not CI)


PubSub: notify all instances of an application (rather than "competing consumers")

In what area(s)?
/area runtime

/area operator
/area placement
/area docs
/area test-and-release

Describe the feature
Currently, Dapr's PubSub implements the "competing consumers" pattern: if there's more than one instance of an application, one and only one of them will receive a message from a topic.
However, there are situations when it is necessary for all subscribers to a topic to receive all messages; you may call this "fan-out". For example, this can be used for alerting or sending notifications.
Today, that's not possible if the applications all have the same application ID.
Release Note

RELEASE NOTE:

@ItalyPaleAle
On page https://docs.dapr.io/developing-applications/building-blocks/pubsub/pubsub-overview/ it says

That means that when an application publishes a message to a topic using the publish/subscribe API, Dapr ensures that this message will be delivered at least once to every subscriber.

Are you sure that "Dapr's PubSub implements the 'competing consumers' pattern"?
My understanding is the other way round. DAPR provides fanout and we could ask for additional support for "competing consumer" or, to use another name, "workload distribution".

A typical impülementation of this would be to add a consumer group (a string) to each subscription. The behaviour would then be:

each subscription with empty consumer group gets a copy
for every subcribed consumer group only one member gets a copy

But this wouldn't work with auto-scaled consumers. See #814.

I've been thinking about this more and I've also been doing some research.
First: while I wrote this as part of a request for PubSub, in reality it may not need to be done asynchronously and it could be done synchronously too. The underlying goal is that I need a "notifier" that allows me to send a message to all services of the same time (like, all apps scaled out) - a "fanout" pattern. Because I need to notify all services that are running at that specific point in time (no need to notify those who may be created by auto-scaling in the future), there's no reason why this couldn't be synchronous.
So, it may be possible to do this via the messaging part of Dapr rather than PubSub, which would make it much easier too! The proposal could then be about creating a new capability like /v1.0/invokeall/cart/method/add (see the all). The difference is that invoke sends the message to one app for each type, while invokeall sends a message to all (that are alive at that time). An alternative name could be notify.
At this point, I'm actually thinking doing this synchronously would make most sense.
Second: I've done a bunch of research on the Dapr codebase to see how this could be implemented.
Regardless of whether we would go with synchronous ("invokeall") or an async PubSub, the first thing that would have to change is....... you guessed, name resolution (it's always DNS right? :) ).
Both PubSub and invoke use the directMessaging.Invoke to send messages. That method [ends up using](	request := nr.ResolveRequest{ID: id, Namespace: namespace, Port: d.grpcPort}) the github.com/dapr/components-contrib/nameresolution components.
When you look at them, you can see that the Resolver interface exposes one method:
ResolveID(req ResolveRequest) (string, error)

This returns a single address if there are more than one; if you look at the components, you'll see that they are doing round-robin internally.
So no matter what we choose do, the first thing would be to expose a method that returns all addresses for a given service:

mdns: should return the list of all m.appAddressesIPv4[appID] (and/or m.appAddressesIPv6[appID]? unclear if should return both or just one - right now, if there's an IPv4, that has priority over IPv6) - after doing the proper refreshing
kubernetes and dns: this needs to implement a DNS client that makes a request to resolve all A records for a given hostname: fmt.Sprintf("%s-dapr.%s.svc:%d", req.ID, req.Namespace, req.Port) - in case of multiple services, the DNS resolver should return multiple IP addresses (usually the order is changed on every response, and clients normally pick the first one only, and that's how round-robin works)
consul: this already returns all addresses by default, and then the component shuffles them and picks the first one. So this new method would just return the slice of addresses without any shuffling etc.

Thankfully none of those things appears to be particularly complex (although the devil may be in the details)
The next step then would be creating a method like directMessaging.Invoke in pkg/messaging which uses the new method from the name resolver to retrieve a slice of addresses, then it would invoke the method on each address. Signature could be something like:
InvokeAll(ctx context.Context, targetAppID string, req *invokev1.InvokeMethodRequest, limit int) (*invokev1.InvokeMethodResponse, error)

(Added also a limit to set an optional maximum number of addresses (services) that are invoked)
Once that method is implemented, it's just a matter of deciding how to expose that to end users.

If using synchronous methods, it would be a new HTTP and gRPC endpoint like invokeall or notify or something else.
If using async, it needs to be implemented in PubSub somehow.

@yaron2 would love your thoughts on this proposal... and then I can look into making a PR :)

Personally, I'd like to see it be /v1.0/notify/[name]/method/[method]. If the pubsub route is chosen, how is this issue different from #3176?
Here's a couple of my thoughts:

If the call is synchronous, how would failures in say 1% of the calls be handled, would they be retried?
What if the sidecar making the call dies while retrying?
What about if callee takes a really, really long time, would that cause issues?
Is the response important?
Is there some way to broadcast the notification? (maybe broadcast a simple message over UDP instead of HTTP/TCP or multicast?)

@withinboredom I did not find #3176 but it looks very similar to this issue indeed, at least in the first post which was just about PubSub.
As I sent my message yesterday, I actually realized that what I needed was more "higher level", and it could be either synchronous or asynchronous to solve my use case (or both). I believe the first part would be to improve the nameresolver to be able to return multiple addresses, and that would be required no matter what route is taken.
To answer your questions:
If the call is synchronous, how would failures in say 1% of the calls be handled, would they be retried?
I can tell you an answer that would work for me and for the use case of #3176: in case of failure (assuming that means the app crashed), it would be ok to just drop the message.
For me, I need this to notify all consumers that a task has completed. The consumers need this info to respond to clients. So, if an app has crashed, it can't respond to clients anyway. If clients retry the request after the app has restarted, the app can pick up the final state from persistent stores.
For the example of configuration changes on 3176, the assumption is that apps would look up the latest configuration from the configuration store.
Additionally, the idea behind broadcasting (fanout) is that it should hit all consumers that are currently running. The service that invokes the broadcasting method doesn't know (and shouldn't need to know) how many services are listening: could be 1, 10, 100,000. It shouldn't matter how many clients receive the message as long as every one that is alive receives it.
However, It may be more of an issue if the failure isn't due to an app crashing but for example a transient network failure. In that case, maybe retrying could be necessary.
How does Dapr handle those failures right now for PubSub and synchronous invocations?
What if the sidecar making the call dies while retrying?
Same considerations as above.
What about if callee takes a really, really long time, would that cause issues? and Is the response important?
I would argue that in a broadcasting scenario, sync or async, response shouldn't matter. TVs and radios don't have a way to respond to broadcasts, after all, and if people watching TV need to contact the station, they know they need to use a separate way (like making a phone call).
If sync (invoke), then my answer to your questions would be "caller shouldn't wait on the response" and "no".
If async (pubsub), the answer to the questions is N/A.
Is there some way to broadcast the notification? (maybe broadcast a simple message over UDP instead of HTTP/TCP or multicast?)
There may be, but I would personally prefer to go through Dapr's usual channels to leverage all the "infrastructure" that Dapr offers, including re-using HTTP/gRPC servers, tracing, mTLS, etc.

Returning a list of addresses for service to service calls is my least favorite option.
I think we can easily enable Pub/Sub fanout by allowing an opt-in feature that'll create a consumerID per instance. that'll cause fan out to be enabled, however on platforms like Kubernetes, if a pod dies and is rescheduled, messages will be lost as it'll come up with a different consumerID.

To add on to what @yaron2 said, you need to be careful PubSub (durable brokers) fanout with unbounded consumerIDs for two reasons.

You may start consuming from the beginning of the stream and receive messages the app is no longer interested in
Creating random/unbounded consumerID creates subscriptions that could overload the broker and just be wasteful

Obviously behaviors vary by broker but I'm just calling out this warrants careful consideration.
Just thinking out loud: If the messages do not need to be durable, this would be a job for bindings w/ something like NATS doing broadcasting. Since it is at most once delivery, generating random consumerIDs is perfectly fine.
Right now, we don't have a NATS binding but it would be pretty simple to code one. It exists now as a PubSub component but was removed from the runtime because it does not have durability. One could just retrofit it into an input/output binding.

Pub/Sub would be fine IMHO.

on platforms like Kubernetes, if a pod dies and is rescheduled, messages will be lost as it'll come up with a different consumerID.

This isn't a problem for the scenario I have and for other common scenarios I read about, as explained above.
For what @pkedy  said: yes, that is a valid concern.
In part that could be mitigated by enforcing a TTL on those messages (could be an actual enforcement hardcoded in the code, like 1hour, or could be a strong recommendation made in the docs). All queues should support TTLs so messages won't linger around forever.
However, expiring messages may not automatically delete the topic in the queue. For example, in Redis I think topics remain forever. Not sure how much of an issue that would be, it may depend on the store... Maybe that may require periodic GC?
As for NATS... it may work. I would prefer having to avoid adding yet another dependency to my project, which requires more ops.
PS: As I wrote on Discord, I'd be happy to look into making a PR for this, when we reach an agreement on what it should look like (and assuming it's something I'm able to do :) ). If there's no agreement, I may end up implementing something for my app. My current thinking is to create another service (say, "notifier") which is the only one listening on a pubsub topic. Front-end services would then use a persistent gRPC steam (which is going to be possible with Dapr 1.3) and receive notifications through that stream. It's not ideal, but it should scale up to a few dozen front-end services, so it is fine for the medium-term.

@ItalyPaleAle The gRPC streaming idea to a single "hub" service is an interesting idea. The devil may lie in the details though. Could your app tolerate skipping/missing messages (e.g. if the hub/notifier dies or is shutdown by the cloud provider and the gRPC needs to reconnect).

@pkedy if the hub is shut down, it's not consuming messages from the pubsub topic, so they will be sent again once the service restarts and connections are re-established (but good callout, I should set a timer so at startup, messages aren't processed for N seconds, so all services have a chance to reconnect).
The only issue that would cause skipped messages is when the hub crashes after receiving a message but before it can send it to the gRPC stream. This is a concrete risk, but it's tolerable in my case: messages are just notifications and frontends can always retrieve the state by polling the persistent store (really, I'm just trying to avoid polling by adding a notifier solution).
The biggest problem I see is the need to maintain a persistent gRPC stream. This is fine while there are limited numbers of frontends, but it won't scale. IIRC, it should certainly be kept below 100 (which I don't see my app exceeding in any near future)

Shouldn't we merge this issue with #3176?
Both issuse discussions highlight different implementation details but the requirement seems to be the same. Or do I get it wrong?

👋 bot. Still a very relevant issue to me 😄

Same here! We have many use cases where a lot of instances (inside the same application) all have to receive the same messages.

This feature is enabled via the '{uuid}' keyword in the consumer ID atribute in MQTT. This must be solved per component. Which component are you referring to? Like I said, we have one that works well in MQTT.

Documentation for MQTT: https://docs.dapr.io/reference/components-reference/supported-pubsub/setup-mqtt/#consuming-a-shared-topic

👋 @dapr-bot

Hi bot 👋 Still relevant to me

And we're back one month later. Hi bot!

👋 boy

Hi @ItalyPaleAle - did you ever get a chance to test Arturs suggestion https://github.com/dapr/dapr/issues/3332#issuecomment-896927761?
Thanks.

Hehehe, cool!

However it looks like it depends on the broker you use. Some brokers do notify all subscribers in all consumer groups.  Some notify one subscriber per consumer group. Some notify a single subscriber only.

Which is bad, given the original promise of Dapr :-/

Dapr's promise is "at least once delivery" and that's true in all of our pubsub components (except Hazelcast, and that's why we're deprecating it).
I'm afraid some things are outside of the control of Dapr.

Isn't another promise, that it abstracts away the APIs and SDKs for the pub-sub brokers and we can have the same semantics (maybe with different config) for them?

This scenario can be realized using the subscription capabilities of the configuration building block

@heavenwing

This scenario can be realized using the subscription capabilities of the configuration building block

I'm eager to understand the expectations/behaviour for GCP.
I can see this in https://docs.dapr.io/developing-applications/building-blocks/pubsub/howto-subscribe-statefulset/:

On scaling the number of subscribers of a given topic, each Dapr component has unique settings that determine the behavior. >Usually, there are two options for multiple consumers:

Broadcast: each message published to the topic will be consumed by all subscribers.
Shared: a message is consumed by any subscriber (but not all).

This supports your statement and indicates that I should go digging into specific GCP pub/sub component docs.
The GCP pub/sub docs  then has this to say:

The Consumer ID organizes one or more consumers into a group. Consumers with the same consumer ID work as one virtual consumer; for example, a message is processed only once by one of the consumers in the group...

It seems to me that the expectation is that, to achieve this Broadcast behaviour for GCP, each distinct consumer instance should reference their own pubsub.yaml with a unique ConsumerID that survives across restarts?


Doesn't handle 509 bandwidth exceeded errors[BUG]

When downloading a comic if the response to the app is "509 bandwidth exceed", program throws an error - see screenshot.

error text.txt

When did you get this error?
Was it during a download or after?

When did you get this error?
Was it during a download or after?

action to recreate error:

Launch app (I know...but wanted to list all steps :)
Click Search
List of comics shown
Choose a comic
download without issue
eventually after downloading a few comics (perhaps a bunch) - I expect the hosting site responds with "509 out of bandwidth"
Choose comic - click download
above error displayed -
will happen over and over


How to use this project?

Hi, thanks for your nice job. Could you write a simple usage?

Have you read this? https://localjoost.github.io/HoloLens-AI-using-Yolo-ONNX-models-to-localize-objects-in-3D-space/

I'm sorry to reply to you too late. There are some problems while opening the project, click "continue"-"Ignore" can open the project. Thanks for your wonderful work.


link to VS2022 version of Project System Tools ext

add link in docs to VS 2022 project system tools

/azp run


[Feature request] Detect changes in apps list.

Is there any way to trigger getInstalledApplications() once an app is removed or installed?
One way is to create a periodic function to get the apps but I don't think that's a good idea.

this is also my question once i get all of the installed apps how do i detect changes if another app is installed by the user how do i get that app information without running getInstalledApplication because it's a heavy operation if a user has 300 or 400 apps its a very heavy resource operation to run this method again & again...hope someone will ans our questions...

this is also my question once i get all of the installed apps how do i detect changes if another app is installed by the user how do i get that app information without running getInstalledApplication because it's a heavy operation if a user has 300 or 400 apps its a very heavy resource operation to run this method again & again...hope someone will ans our questions...

I add this to feature to my TODO list :)

Hey I want one more thing I want to create a file observer who watches
recursively for file changes and receive events to the dart and this work
needs to be done in background please help me about this. I have
implemented a file observer but it's just watching the root path not the
whole file system I have made a plugin storage_details there I implemented
this you can check if you want.
On Sat, 6 Mar, 2021, 7:59 pm Edouard Marquez<EMAIL_ADDRESS>wrote:

I add this to feature to my TODO list :)
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
https://github.com/g123k/flutter_plugin_device_apps/issues/58#issuecomment-791962107,
or unsubscribe
https://github.com/notifications/unsubscribe-auth/AOTM2LKXSYTDXW3D545T7RTTCI35RANCNFSM4WJCNU7A
.

Don't worry, I already how to write the feature ;)

It's now available in the 1.3.0 release


Infographic Widgets - Support widget selection also according to current input

Currently the decision whether a widget is included takes place after its items are generated, before insertion to cache. Cache is based only on location
We want to add the ability to select widgets also according to current request parameters that are not location, e.g. news-flash text.

Implementation suggestion:

Widgets that need to be included according to current data, will set their is_included() to return True whenever their data is not empty.
We will add a method is_included_after_cache(), that will receive the current request parameters, and the data that was retrieved from cache. In this method the logic of whether the widget should be included will take place, according to both the items, and the current request parameters.

@atalyaalon , is this along the lines you intended?

Implementation suggestion:

Widgets that need to be included according to current data, will set their is_included() to return True whenever their data is not empty.
We will use Shani's method update_result(), that receives the current request parameters, and the data that was retrieved from cache. In this method the logic of whether the widget should be included will take place, according to both the items, and the current request parameters.

@atalyaalon , is this along the lines you intended?

Yes, I assume that in some cases we would like to have an "AND" between data logic and request parameters logic (for example, X pedestrians were injured in street AND "הולך רגל" is in news flash text) and in some cases we would like to have an "OR between them (for example, X pedestrians were injured in street OR "הולך רגל" is in news flash text)
If we have an "OR" the result of each trigger will be the same - the appearance of the widget in the cache data.

Implementation suggestion:

Widgets that need to be included according to current data, will set their is_included() to return True whenever their data is not empty.
We will use Shani's method update_result(), that receives the current request parameters, and the data that was retrieved from cache. In this method the logic of whether the widget should be included will take place, according to both the items, and the current request parameters.

@atalyaalon , is this along the lines you intended?

Yes, I assume that in some cases we would like to have an "AND" between data logic and request parameters logic (for example, X pedestrians were injured in street AND "הולך רגל" is in news flash text) and in some cases we would like to have an "OR between them (for example, X pedestrians were injured in street OR "הולך רגל" is in news flash text)
If we have an "OR" the result of each trigger will be the same - the appearance of the widget in the cache data.

It is supported by the current structure. The update_result() of the widget can implement the needed logic of that widget. It can alter the widget's data, and it can return None, to remove the widget from the result of the current request.


program terminates when write fails

I get this error:
terminate called after throwing an instance of 'influxdb::ConnectionError'
  what():  influx-cxx [treatCurlResponse]: Couldn't connect to server

I put the write to influx inside a try catch but still the program terminates.

I had another function that wasn't using try catch.


BUG in Quick.Commons

//checks if need include signs // signs!
if pfIncludeNumbers in Complexity then // pfIncludeNumbers!

// QuickLib 2.1
Here is the bug-fix:

Thanks, now is fixed.

Thanks, now is fixed.


Build fails: cannot find symbol class SwipeRefreshLayout

When I add implementation lines
implementation 'com.google.android.gms:play-services-maps:17.0.0'
implementation 'com.sucho:placepicker:0.1.8'

implementation 'com.google.android.material:material:1.1.0-alpha09'

to my app build gradle file I get multiple errors of the following type: error: cannot find symbol class SwipeRefreshLayout. These errors are all related to my project. Everzthing works if I remove implementation lines.
I just updated Android Studio to the latest version 3.5 and I also updated gradle to the altest version 3.5.0
I think this might be causing build errors. Do you have any idea how to fix this or where to look?

Seem like it was a mistake to update
implementation 'com.google.android.gms:play-services-maps:17.0.0'
This works fine now:
implementation 'com.google.android.gms:play-services-maps:16.1.0'
implementation 'com.sucho:placepicker:0.1.8'

implementation 'com.google.android.material:material:1.1.0-alpha09'


Open specific pages

It would be very nice to be able to tell the viewer to open the PDF on a specific page or section (anchor). This enables more interactivity between the streamlit app and the PDF

HI @Vinno97 and thanks for your interest in this component.
I will try to give you an answer, however we are learning streamlit on the way with our development.
We have been thinking about opening the PDF in a new window (#21), instead of in an iframe within the application window or tab, however, as with other features (e.g. getting the height/width of the iframe) there are quite a lot of limitations.
I think, at the moment you can do that by placing the pdf_viewer() call in the corresponding section (for example under a st.column() or a st.component()).
Are you aware of other components that can be opened in a targeted page or section?

Thanks for your quick response! I think there may be a misunderstanding. What I meant, was that it would be nice to have the ability to have the PDF viewer focus its view on a specific section of the PDF.
For example, I now did something like this as a workaround:
from io import BytesIO

import streamlit as st
from pypdf import PdfReader, PdfWriter
from streamlit_pdf_viewer import pdf_viewer

# Get the PDF
pdf = st.file_uploader("PDF Report")
if pdf is None:
    st.stop()

# Let the user choose a page number
pagenum = st.number("Page number")

# Create a new one-page PDF of the selected page
reader = PdfReader(pdf)
writer = PdfWriter()

writer.add_page(reader.pages[pagenum])

new_pdf = BytesIO()
writer.write(new_pdf)
new_pdf.seek(0)

# Show the new PDF
pdf_viewer(new_pdf.read(), height=800)

Hi @Vinno97, thanks for the clarification, now I understand.
What we could try to do, is to verify whether it is possible to switch to a specific page when calling pdf_viewer(...).
However, I'm not sure we can control the javascript in this way, so your workaround might be the only solution.
@t29mato maybe you can check whether it's feasible to pass an additional parameter page and see if we can scroll down automatically after we load the pdf?

@Vinno97 about your example, once the modified PDF is visualised it needs to be re-built again if the user wants other pages. Do you have a specific use case for this kind of feature?

Yes my workaround is really crude. I wouldn't advocate for this being the actual solution. If you guys agree that allowing the user to focus on a specific page is  a nice feature, I think something like this would be better.
My use case was that I was debugging PDF data extraction logic for some very large documents. I had the PDF viewer in one streamlit column and some extracted information in another column. The code I sent before allowed me to quickly focus on the exact page that corresponded to an element I was interested in. Otherwise i would have had to scroll through 100 pages until I found it.

@Vinno97 Thanks to @t29mato who has implemented a selective rendering on the javascript should be more efficient. It's released in version 0.0.7 (please skip version 0.0.6 😅).
You can see it in action here.

Thanks, guys! Made quick work of it 😄

I close the issue. Feel free to reopen or comment if needed.


Do not use a regex to validate e-mail addresses

This is a bad idea.
Having an (extension) method that "promises" (by it's name alone) to check validity of an e-mail address should either work reliably or not exist at all.
Having said that; I also think it shouldn't be in this library at all; all other methods (as far as I've seen) provide string (handy) operations that the BCL doesn't provide for whatever reason. IsValidEmail is not in the same (sub)set of all the operations and it feels slapped on, because we can: "Hey, IsValidEmail may come in handy, let's put it in!". This library, IMHO ofcourse(!), should focus on string operations that can be applied on any "generic" string. You could even argue that an e-mailaddress should have it's own type like Uri but that's a whole other discussion. But if it had, then that would be the place to have an IsValidEmail (extension) method.

A good extension method should:

Apply to any possible instance of the type it extends.
Simplify logic and improve readability/maintainability.
Apply to the most specific type or interface applicable.
Be isolated in a namespace so that it does not pollute IntelliSense.

(Source)

Hi @RobThree,
All fair points. I agree that IsValidEmail doesn't really belong in here, and if I wrote the library today, I wouldn't include it. That being said, I'm not going to remove it for now, because it would be a breaking change for people using it. I can deprecate it, though; and if I ever release another major version (pretty unlikely, but who knows...), I will remove it.
In the meantime, I guess I could try to improve the regex; I know it's not the ideal way to validate an email address, but at least I could change it to support the new TLDs.

Since validating an e-mail address is very hard, you're better off sending a confirmation link.

Actually, the method isn't very well named; it doesn't check that the address exists, but only that it's well formed. It should probably be named IsWellFormedEmail instead. Obviously, a confirmation link is necessary if you want to check that the address exists, but sometimes you don't want to (or can't) wait for the user to click the confirmation link (which is a valid approach only for web apps anyway).

I can deprecate it, though; and if I ever release another major version (pretty unlikely, but who knows...), I will remove it.

Well, the unlikely happened. I strong-named the assembly, which is a breaking change, so I bumped the version to 2.0.0 and took the opportunity to remove IsValidEmail.

It's still mentioned in the README. Not sure if that's intentional but you may want to take it out?

Oops. Thanks, I'll remove it.


Problem with Aqara Wireless Switches and TRADFRI ON/OFF switch.

Describe the bug
Hi. I don't know why, but three shortcut keys stopped working at the same time today, namely two Aqara wireless switches and one TRADFRI ON/OFF switch. Strangely enough, the temperature sensors in the Aqara wireless switch work properly, but the switches themselves do not respond. They are visible in Homekit. I had a second Micro SD card with a clean Homebridge system and Zigbee2MQTT. I launched it and added one of the Aqara shortcut keys and it turned out that the problem was identical, i.e. the temperature sensor worked properly but the switch did not. I didn't change anything in the system. As I wrote, the same thing happens on the new system. What could be the problem?

This plugin
1.9.2
Homebridge
1.7.0
Zigbee2MQTT
1.33.2
Homebridge Config UI X (if applicable)
4.53.0 or 4.52.3

What is the mapping shown for these devices in the Homebridge log when it starts?
Do you see updates for these devices in the Zigbee2MQTT front-end?

In the Zigbee2MQTT frontend or by looking at the MQTT messages (with something like MQTT Explorer).
Just to be clear: the issue you are facing is that no actions are triggered in HomeKit when you press the buttons? If not, please clarify what's problem is (expected vs actual behavior).

@itavero The strange thing is that it only applies to these devices. The rest works fine. I didn't change anything in the system. The second strange thing is that the temperature sensors still transmit the correct value and change with the Aqara Button.
As you can see in the photos I sent, the switches do not respond.

@itavero Everything is OK in MQTT Explorer. See the photo. I also reconfigured the Ikea Button as you can see in the photo.

@itavero The problem resolved itself after a few hours. In my opinion, it must have been the fault of Apple's servers. As if these switches did not see the accessory center without which they cannot function. Thanks for the help


Support closed fd in grpc_fd_orphan()

C-ares library manages fds by itself, and may close its used fd inside a grpc_fd object. The closed fd may be picked up by the system before we call grpc_fd_orpahn() on the grpc_fd object. In this case, grpc_fd_orphan() should not close the fd again or remove it from the epoll set.
This PR adds already_closed in grpc_fd_orphan. If already_closed is true, grpc_fd_orphan will not close the fd again or remove it from the epoll set.

[trickle] No significant performance differences

Why the previous approach (setting release_fd) does not work?

@yang-g Setting release_fd will make polling_island_remove_fd_locked think that the fd is not closed. It will try to remove the fd from the polling island, and cause an error when calling epoll_ctl.

Jenkins: test this please

[trickle] No significant performance differences

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

[microbenchmarks] No significant performance differences

[trickle] No significant performance differences

Jenkins: test this please

[trickle] No significant performance differences

[microbenchmarks] No significant performance differences

Basic Tests Mac: #11213
Basic Tests Windows: #10643, #11109
gRPC_interop_pull_requests: 10686


Refactor: Remove global AE Middleware initialization

I'm closing this PR as there is another one that uses this code to fix one more issue: https://github.com/superhero-com/superhero-wallet/pull/2598


Move listen addresses to be set in config file (vs on run command)

The run_rollapp.sh has changed and as such doesn't support configuring the listen addresses.
see ref: https://github.com/dymensionxyz/dymension-rdk/pull/63#pullrequestreview-1265614164

I think in the docker env it doesn't need to be changed at all
The app can use the default values, which will be exposed differently by docker


loading sparse matrix with only null values in v4 format

It is no longer possible to load a sparse matrix that contains only null values in v4 format.
This zip file contains the matfile.
spds.zip

Thanks for reporting? What exatly do you meean by "no longer"? Do you have a reference version where it worked last? Did you run git bisect to locate the bad commit? Could you please also provide the code snippet how to generate the file such that I can add it to the acceptance tests? Thansk again.

We are upgrading from Matio 1.5.9 to 1.5.27 which is a big step :)
I did not use git bisect, but I investigated the code, and if I've well understood the v4 format, sparse data are stored in a "table" with one line by non-zero values and an extra line that contains the sparse dimension.
The condition on dimensions is now checking that there are at least two rows, that is not true in case of sparse that contains only null values.
see mat4.c:368 in 1.5.27
if ( matvar->dims[0] < 2 ) {
    return MATIO_E_FILE_FORMAT_VIOLATION;
}

I think that commit introduced the bug https://github.com/tbeu/matio/commit/aefd09e9d20aebb4a0b0a5e5c619f46038dba3bc
The file has been generated by Scilab, which does not use matio to generate mat files in v4 format.
Here is the Scilab code:
spbs = sparse(0);
file = TMPDIR + "/spbs.mat";
savematfile(file, "-v4", "spbs");

Bug confirmed and fixed by bc0044dd1ff73f2f89b981dad33420fbea3b6eef.


Save Favorite Poems

USER STORY: Save Favorite Poems
URL: https://github.com/suwebdev/wats2020-fq15/wiki/User-Story%3A-Save-Favorite-Poems
SIZE: Sm
REASONING: Having the ability to save poems will allow returning users to easily retrieve their favorite poems.
PRIORITY: Low
HOW DOES THIS FIT IN THE PROJECT?: After the content is added, the "save poem" functionality can then be implemented.
WHY THIS SPRINT: This is not a key feature, but it is useful and should be done if there is time for it.

Added code to main.js which will save a poem's relevant information(title, author, url to poem) to localStorage as an object.  We need to decide where to display saved poems in the UI.  Should also implement a feature in future sprint to allow users to delete saved poems from their list.


Metadata should return /self/host for net host

When running a container with net: host we should be able to get at the /self/host/agent_ip from the metadata service.

There are a couple of issues here:

Host container record in the metadata service has incorrect ip address - I'm going to fix it to reflect the ip address of the host where container resides (agent_ip), just the way we do for DNS service.

Even with correct ip address set, I'm not sure if metadata service would return self as the ip of the host container might not be equal to client ip that metadata service reads from the request. Going to test it after 1) is fixed.

The fix would be is to introduce following sections under "default":
/self/host
/hosts
@vincent99

Should we also include host in the container response?

@cloudnautique thinking if it should rather be a name of the host, just like we include service.name/stack.name to the container data, not the entire service/stack objects. So using hostName, you can retrieve desired host object from /hosts target.

@sangeethah new fields have been added to metadata
Added uuid field to host in metadata
Added host_uuid/hostname fields to container metadata
Also have to verify that for host networking container, self/host returns the container's host info

Tested with build from master - Oct 7
From a container that is launched with  net: host ,  querying rancher-metadata for self and self/host returns container's host info.
Host info now includes uuid as well.
{"agent_ip":"<IP_ADDRESS>","labels":{},"name":"sangeemaster-10acre-1","uuid":"
f9aa9c7f-63d5-4f03-aff6-71e460ce33f8"}root@sangeemaster-10acre-1:/# cat self
{"host":{"agent_ip":"<IP_ADDRESS>","labels":{},"name":"sangeemaster-10acre-1",
"uuid":"f9aa9c7f-63d5-4f03-aff6-71e460ce33f8"}}root@sangeemaster-10acre-1:/#

Also container metadata now retruns  host_uuid/hostname fields:
root@900f9393d623:/# cat container
{"create_index":2,"host_uuid":"8a402b1f-1464-4a7f-b591-0c36fef8916b","hostname":
"sangeemaster-10acre-2","ips":["<IP_ADDRESS>"],"labels":{"io.rancher.project.na
me":"Default","io.rancher.project_service.name":"Default/test1","io.rancher.sche
duler.affinity:container_label_soft":"io.rancher.service.deployment.unit=1e8714d
5-a4f5-478c-b85b-6cf98a984157","io.rancher.service.deployment.unit":"1e8714d5-a4
f5-478c-b85b-6cf98a984157","io.rancher.service.launch.config":"io.rancher.servic
e.primary.launch.config","io.rancher.stack.name":"Default","io.rancher.stack_ser
vice.name":"Default/test1"},"name":"Default_test1_2","ports":[],"primary_ip":"10
.42.135.235","service_name":"test1","stack_name":"Default"}root@900f9393d623:/#
root@900f9393d623:/#


Add Snowflake authenticator param to docs

Add Snowflake authenticator details to docs (from #644)

Thanks for catching this @foundinblank. Just a small comment on the docs for username.


Refactor labeling gui

Codecov Report

Merging #24 (8ac55fa) into main (c674295) will increase coverage by 0.01%.
The diff coverage is 100.00%.

:exclamation: Current head 8ac55fa differs from pull request most recent head 4b7bfdf. Consider uploading reports for the commit 4b7bfdf to get more accurate results

@@            Coverage Diff             @@
##             main      #24      +/-   ##
==========================================
+ Coverage   86.22%   86.23%   +0.01%
==========================================
  Files          44       44
  Lines        1691     1693       +2
==========================================
+ Hits         1458     1460       +2
  Misses        233      233

Impacted Files
Coverage Δ

src/morphometrics/_gui/_qt/labeling_widgets.py
47.31% <100.00%> (+1.15%)
:arrow_up:

Continue to review full report at Codecov.

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


No Docker-Support in Manifest-File

High five for submitting a report!
To avoid additional back and forth, please include the following details as relevant:
Issue
Sadly there is no way to define a Docker-image in manifest.yml at the moment.
Instead you have to define it on every cf push, via -o.
Possible Fix
Add anything like docker_image to manifest.yml

Please follow #696.


GCC 9 doesn't support SVE2

Judging by release notes of GCC 9.4 and GCC 10 it looks like support for SVE2 was introduced in the latter series, but https://github.com/xianyi/OpenBLAS/blob/934a0e5397f04e215573d8288a9f575bd7040e82/Makefile.arm64#L125-L128 assumes SVE2 is already available in GCC 9.4.  Someone reported having troubles building OpenBLAS with Spack using GCC 9.5, running into the
invalid feature modifier 'sve2' in '-march=armv8.5-a+sve+sve2+bf16'

error, which confirms the hypothesis that GCC 9 never supported SVE2.

duplicate of #3805


Upgrade to Rust 2021, update dependencies

- **Breaking** Updated to half 1.8, smallvec 1.7, winit 0.26, raw-window-handle 0.4.

- Upgraded to Rust 2021.

Rust 2021 is a much smaller change than 2018 was, but it's still nice to have, especially for the ability to call into_iter on arrays properly now. This does mean that Vulkano 0.28 will require Rust 1.56 to compile. Because of how editions work, Vulkano can still be included in other projects using the 2018 or 2015 editions, compatibility is not broken.

@Rua Looks good. No regressions detected. Merged :+1:


An Exekube project inside gpii-infra, round 1

This is an early version so that:

You can see what I think this will look like structurally
You can (hopefully) actually use exekube to deploy something and play with it (check the README) :)

This starts with the latest exekube and exekube examples. It deploys a Kubernetes cluster and a Tiller.

Created https://github.com/exekube/exekube/pull/66 for the k8s-namespace module. Until then, please use my fork of exekube as described in the README.

In my exekube PR, Ilya says I'm doing it wrong :) so I'm going to re-evaluate my approach here based on his notes.
However, I'm also merging this to master so that others can base work off the structure (which I don't expect to change).


[✨ feature] Custom Error pages for ZaneOps

Is your feature request related to a problem? Please describe.
We want to add custom error pages for more fun and polish.
Describe the solution you'd like
We need to make sure to handle :

502 Bad Gateway the application failed to respond at this address (maybe the service isn't up yet)
503 Service Unavailable the server the proxy is installed has a problem, it requires assistance from the admin.

Additional context

we will use handle_errors directive for that :  https://caddyserver.com/docs/caddyfile/directives/handle_errors
Ideas :

[x] Are you willing to make a PR for this ?

For later


The Rollable Table selection dropdown does not filter out tables that the user does not have permission to see.

I've assigned rollable tokens to my player's tokens, and we've found that they're able to view all rollable tables in the game through the Token Image Rollable Table dropdown menu, even tables they have no permission to view. Preventing players from seeing tables they don't have permission to view in the dropdown menu would be a helpful addition!
Attached are images showing the issue (Player view and GM view)

Needs a permission check for observer permission against the current user when enumerating available tables.


Create documentation on the verification process of prescription codes

First of all, thanks a lot for creating this repository! We at xbird just started to explore how we can verify the diga prescription codes and are very happy that you are sharing both your code and information about it.
Problem
From the official documentation it is hard to figure out how requests can be sent to verify prescription codes. There is an openapi definition of the diga endpoint but it is not obvious how the request and the response data should look like. (Billing is also not clear but probably deserves it's own documentation/issue)
Solution
It would be great to have a documentation which includes:

high-level information about how the prescription code can be verified and used for billing
how the request data for billing and verification must look like, ideally with some examples of the nutzdaten before encryption and encoding

also how the decrypted nutzdaten response looks like

how nutzdaten can be encrypted/decrypted
how insurance information can be extracted from the mapping file based on the prescription code
how fields like diga manufacturer id should look like in test requests when the diga is not approved yet and therefore the id is still unknown

similar for the diga manufacturer IK number = iksender

I'd be up for writing down my current understanding of the diga verification api and creating a PR to this repository. Could be some markdown files within a docs folder or as wiki pages. Not sure though if it's also in your interest to collect documentation in this repository or just the code for the api client :)

Hi @SebastianRehfeldt !
I understand what you mean, the information is still really scarce (and it was even worse before). When building this, I was intending to write a blog post about what I learned about these things, but other stuff got in the way...
In case you haven't figured everything out yet, you can find the answers to your questions by looking at the source code for this library or by running some test requests in debug mode and inspecting what comes out. The library has been shown to work in production for a few of the APIs by now thanks to @gtuk who also fixed several things we couldn't catch with test requests, so it is getting to a more reliable stage.
I think I like the idea to gather information and documentation about the DiGA API in this repository if you wish to contribute to that. I've already written some things in the Wiki here and ideally I would like to continue using the Wiki but it is my understanding that you cannot make pull requests against it, so maybe a 'doc' folder with markdown is better. What do you think?
By the way, are you intending to use this client or are you writing your own?

Hi @fongie,
We are not sure yet if we want to use this client or write our own solution (most likely in Python and with a first focus on code verification). We are no Java developers and cannot really integrate the client as it is right now. A docker container which exposes the verification/billing logic via an api could be a solution though :) This also seems to align with your long term ideas and plans for this repository as far as I can see from your Readme?
In any way, contributing to this repository with documentation makes sense to us. Based on a more detailed documentation, it will also be easier to build solutions in other languages. Regarding the wiki, I also doubt that we can open Pull Requests. Therefore, I'd go with a doc folder. To avoid building and publishing a new version of the client, we could also close the PR once it is accepted and transfer the content to the wiki. Would that work for you as well?

We only build & release on creating a "github release" to keep some control of the releases, so it is no problem to merge doc requests to master. But I still think the second option is best to keep the "general" documentation separate from the source code of the library, so let's try that. When you (or someone else) make a doc PR, I will transfer that to the wiki and close the PR with a link to the new wiki page, or the old one that was updated.
Regarding the docker container, yes, that is a long-term idea and something I thought of to help people like yourself who can't use it as a java library, but unfortunately I don't have time to do it myself right now. Perhaps we can make some progress there during the summer as it shouldn't be too hard but I can't promise anything. It would be nice though 😄

Ok sounds good! I'll try to work on the documentation this week and keep you posted :)
And yes the docker container would be amazing! Although there are some things which might get a bit tricky. Ideally we would like to have some control about the logging or define how to handle eventual problems with billing etc. Nothing impossible though. Depending on whether we want to integrate the client or write something ourselves, we might create another issue for the docker container.

By the way, are you intending to use this client or are you writing your own?

Regarding your initial question: seeing how much effort you already put into this and seeing that it gets stable, we'd like to integrate this client instead of writing our own. We are currently exploring options how to best integrate it into our system. The probably best and most universal solution would be to wrap the client into an api and put it into docker. As already said, we are no Java developers but would like to give it a try. More likely we will write the server in Kotlin but lets see :)
I think it would be cleanest to create a fresh repository for the server and leave this repository for the package and documentation only. I can also ping you once we have some more concrete plans for the server. What do you think? :)

I had some spare time yesterday and quickly hacked a small kotlin api around the client. https://github.com/gtuk/diga-api-service
Maybe it is already useful like this, if you have questions let me know. I will continue working and improving the service in the upcoming weeks

That looks great @gtuk ! Thanks a lot :)

Wow that was quick @gtuk , great job! I will watch the repository and give it a little bit of time to be tested by @SebastianRehfeldt and co, then add a link to it in the readme in this repo 😄

We will definitely give it a try as soon as we have all the prerequisites, like IK number and certificate from ITSG, ready and let you guys know :)
I have a general comment regarding one of the TODOs from @gtuk : More validation.
Is that related to code validation in general, e.g. validating the checksum or used characters in the code? Then I guess this is something which could directly go to the client into this repository? What do you think? Also there is some utils functionality to check if the code is within the provided DiGA test codes. Just in case we have some time to contribute, we could maybe discuss where we want to put these things. As that might also go directly to the client.

I would totally agree that validation of the code should be inside the client instead of my api wrapper (there is actually already a small validation in the client -> https://github.com/alex-therapeutics/diga-api-client/blob/7a8ac66edc6be9397e8c5db40ba36af3ff0c2f7a/src/main/java/com/alextherapeutics/diga/implementation/DigaCodeDefaultParser.java#L95).
Inside our production api wrapper we additionally use https://github.com/bitmarck-service/base32check-java to validate the code. There is already an open issue here https://github.com/alex-therapeutics/diga-api-client/issues/24 and I am planning to create a PR for this in the upcoming weeks if @fongie is not already working on it

closed in #54


chore: release 1.28

quic/s2n-quic-tls has a MINOR bump because of
        feat(s2n-quic-tls): adds server session resumption functionality (#1930)
quic/s2n-quic-transport has a MINOR bump because of
        feat(s2n-quic-tls): adds server session resumption functionality (#1930)
quic/s2n-quic has a MINOR bump because of
        feat(s2n-quic-tls): adds server session resumption functionality (#1930)
quic/s2n-quic-crypto has a MINOR bump because of
        feat(s2n-quic-crypto): use scatter API with AWS-LC (#1947)
quic/s2n-quic-core has a PATCH bump because of
        refactor(s2n-quic-transport): simplify packet processing (#1952)
        docs: describe mitigations for QUIC§21.11 in stateless reset token provider  (#1948)
        fix(s2n-quic-transport): invoke on_packet_loss for all lost packets (#1944)

quic/s2n-quic-platform has a bump because of
        TRANSITIVE UPDATE
tools/xdp/s2n-quic-xdp has a bump because of
        TRANSITIVE UPDATE
quic/s2n-quic-tls-default has a bump because of
        TRANSITIVE UPDATE
quic/s2n-quic-rustls has a bump because of
        TRANSITIVE UPDATE

Testing:
CI should pass, and builds locally.
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license.

qns failure is not related to this PR. Created #1969 to track the issue.


Language Server Protocol support

I'd love to see this support the Language Server Protocol, so existing LSP clients could be re-used to add intelligence to the editor :)

It will solve #17 too

Well, this is pretty nice way to implement some "smart" functions for editor.
Thank you!


doubt

can this be seen by other players if one has set a sign to show a video/image? if yes please mind telling me, if not explain (;
server-side fork? maybe server&client side fork someone?
ggs

Yes, other players will be able to see pictures, assuming they have also installed the mod on their end.


Lane width imputation

Current code only support basic imputation but there is lane width with more than standard length (3.5-4 metres).
Ideally it should increase/decrease the lane numbers based on the oversized/undersized lane width.

added lane width multipliers based on standard length, a long time ago.


Enhancement: order_by to define top row

For order_by option I would like to have an additional option to define the all time first row.
In my example I have solar power and several consumers. I would like to have the solar on top and the consumer sorted by consumption below.
Thank you!

@GeraldPape this is a edge use-case, but I will have a look if I'm going to implement this or not.
In the meanwhile you could use custom CSS to do this for you, each element has a unique class.


Bug: Infinite loading when opening extension

Traces:

UI has to wait background (serviceworker) init ready
Table asset in indexDB has about ~ 64000 records, after caching Rune data
Bottleneck happens with method initChains in chain-service/index.ts

Solution: Add top Runes and BRC-20 to decrease records